Zugg Software :: View topic - NO-OP Protocol

Apprentice Joined: 12 Jun 2006 Posts: 106

CRT has an option where you can send the protocol no-op every N seconds. It keeps a connection alive by asking the server for a response without having to send anything else. Without it I will get disconnected in short time(10-15 minutes I think) on one mud if I haven't received any text from the server. And it doesn't count as input from the user so I'll keep my idle time and people will still know I'm not there.

Any chance this could be added to CMUD? Or perhaps #NOOP for this?

Also, would it be possible to make the Tab key macroable in CMUD or is it still undoable like in zMUD?

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

I've asked for these nat keep alive packets to be sent as well, so I think its on the to-do list but not yet implemented. In the mean time I am using a tick timer of 90 seconds which sends a backspace keypress. Usually the MUD doesn't consider this as 'new input' so it keeps your idle time etc - the command is:

#sendprompt %char(8)

Posted: Mon Aug 07, 2006 10:51 pm

Yes, sending the NAT keep alive packets is still on the to-do list.

And sorry, but the Tab key still won't be macroable in CMUD. The tab-expansion features are being expanded in CMUD (you don't need to hold down the shift key to expand a word from the screen anymore). I suppose I could consider making the tab-expansion feature an option, but it seems like there are plenty of other keys on the keyboard that you can assign macros to.

Apprentice Joined: 12 Jun 2006 Posts: 106

Definitely understand. I'm probably the only zMUD user who would need such a feature. I can't use more than a key mapped to a single command and CR anyways, so zMUD is a bit overkill. My whole reason for wanting it was just color highlights ;)

Magician Joined: 29 Nov 2005 Posts: 482

well many muds actually started banning people using idle killing abilities. I suppose each mud is different but some even go as far as banning the account for having anti idle features.

It would be nice to see for those that could use it but i would hope this isnt in the priority column. ^^

Apprentice Joined: 12 Jun 2006 Posts: 106

keep alive doesn't kill idling. That's the whole point of it. It just makes sure that the mud won't disconnect you if there has been nothing sent or received. If the mud logs you out if you've been idle for a certain amount of time this will not affect it.

Posted: Tue Aug 08, 2006 2:07 am

Right...what Saet said is what Rainchild conviced me via email. There is a big difference between sending NAT KeepAlive packets and sending actual data to the MUD. NAT packets are handled at a low level and are *intended* for telnet sessions in order to keep a persistent socket connection open that spans routers. Without the NAT Keepalive packets, a router can decide to get rid of a socket connection. Since web browsing and email (the largest uses of the Internet) do not require persistent socket connections, this allows routers to better load balance and handle lots of connections.

The NAT Keepalive stuff is really only for routers. It does not cause any additonal load on the MUD server itself and does not defeat any MUD's idle timeout system. MUD idle timeouts rely on actual data input from the client, and the NAT packets do not satisfy this requirement. So even with NAT you can still get disconnected from a MUD that has an idle system.

So this achieves the best of both. It prevents routers from messing up the socket connection and causing wierd disconnects, but still allows the MUD server to implement their own idle timeouts.

At least that's the way I currently understand it. Definitely let me know if I'm wrong.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

You understand it right, and with more and more people using home broadband it is getting necessary. A lot of the home routers drop connection after 15 mins of inactivity - eg when new data comes in from the MUD after that 15 min of idle, the firewall says "I don't know you" and blocks it, but it never actually sent a "this connection is terminated" packet so both z/cmud and the mud server think you're still connected. So even though technically you have lost link, you won't find out until you try to type something and the router goes 'huh I know of no such connection'.

Magician Joined: 29 Nov 2005 Posts: 482

hmm weird. I havent run into any routers that will by default drop a telnet connection unless there is no activity from the mud. And since all muds send things intermittantly from auction channels and shouts to tells people walking through rooms etc I havent experienced that problem. I leave my muds connection both at home and at work for 2 hours at a time and they only drop when the mud kills it. Could be how i have it configured. As an IT professional its possible i have mine setup to avoid this problem. I would have to check.

It just makes sure that the mud won't disconnect you if there has been nothing sent or received.<-- wouldnt that be why a mud would disconnect you and thus you would be circumventing it.

I really didnt realize that was even an issue. Most muds default to 15 or 30 minute inactivity timers.

Apprentice Joined: 12 Jun 2006 Posts: 106

Ahh yes. I was definitely wrong with saying the mud disconnects you.

Is it possible for the cable/dsl modem to do this also? I have always had a router set up to them and when I switched from cable to dsl I'm pretty sure I used the same router. That is when I started getting the 15 minute connection drop. I never had that happen with my cable.

Apprentice Joined: 12 Jun 2006 Posts: 106

edb,

Yeah, I want to maintain my idle time so people don't think I've recently been active and try to talk to me. It's real annoying, one guy always used to always send a look every 10 minutes and it was impossible to tell whether he was active or not. Plus he would always show up on "who active". It's basically a chat mud now so it's a nice thing to have.

I can't get that link to work by removing the ) at the end or changing projekt to project.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

It definately needs to be a toggle-able option, but it should be there none the less. PuTTY has keep alive packets, so why shouldn't CMUD? It's an IAC xxx xxx sequence so any mud engine worth a grain of salt will have some kind of 'ignore unknown IAC sequence' and not translate it as user text.

These packets are to keep alive the connection but not intefere with MUD idle-out policy, for example gods on my MUD do not ever get idle-disconnected, however if they're sitting in a quiet room with the main player channels turned off, NAT will drop them due to inactivity.

For a player we have a 30 minute policy, but to keep their connection alive a player might put in some kind of 'issue a look command every 5 minutes' which will also keep their idle time at less than 5 minutes thereby circumventing the 30 minute inactivity timer. If there was keep alive packets then they wouldn't need a 'look' timer and they would be dropped at the 30 minute interval as they should.

And for a business / zTelnet implementation they will need keep alives for things like command shells that do not have idle timeout policies.

Magician Joined: 29 Nov 2005 Posts: 482

I am not arguing the fact that it should or shouldnt be there at all. I dont think its priority thats the only statement i have made to that regard. However i do think its un-necessary. Heres more info for you that may help understand why.

However it sounds more like they need to fix a setting somewhere. Out of the 38 machines i have in my office none of them drop. Neither do the 4 i have at home.

That is what i am confused about. This should be a setting in the router or operating system and both have to be set properly. It would be ashame to add some unnecessary coding simply because someone doesnt want to adjust their settings. That is what i am trying to understand.

Most routers have a keep alive setting (Idle Time out Setting) etc. In addition the default on almost all linksys and dlink routers is 2 hours idle timeout on telnet ftp and ssh. Also realize firewalls can institute and modify that setting as well. What this means is even if instituted it would default to the operating systems defaults and without making changes to the specific settings for Windows or Linux the problem would still exist. Routers and firewalls can also block the return packets and sent packets of this nature without configuration as the defaults arent normal. Routers default typically to 2 hours etc. But the problem doesnt change cause zugg adds a send packet command. In the end the operating systems control such things. Adjusting defaults to below the connection break limit you are trying to surpass to defeat nat tends to help.

Posted: Tue Aug 08, 2006 4:37 pm

From what I've seen from some support email where this was causing a problem, it wasn't the end-users computer or router that was dropping the connection, but was a router/firewall being used by an ISP. Seems that some ISPs set the timeouts lower and assume that home users are doing web surfing and email and don't need persistent connections.

As you mentioned, in Windows the default value is 2 hours and I've dealt with users who's ISP was dropping them after 15 minutes. And as Rainchild said, the problem was that the connection still thought it was open until the user came back and tried to send a command to the MUD, at which point the connection timed out.

And what we are talking about here is not messing with the TCP settings, but simply sending the IAC sequence that Rainchild mentioned. Any MUD that handles telnet will support this. And any MUD server that doesn't ignore IAC is a really old, bad MUD code base. Even if MUDs don't understand telnet option negotiation, the vast majority know that they need to at least ignore IAC sequences.

But yes, it would still be an option, and would be off by default. It's not a big deal. It's going to get implemented when I strip out the 10-year old home-grown Winsock code that I've been using and update it to use Indy and the SecureBlackBox SSH stuff. Once the network code has been swapped, supporting KeepAlive is just a matter of turning on that property in the Indy code. So it's not very much work at all.

Adept Joined: 04 Feb 2005 Posts: 246

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

Some of my SSH connections have 5 minute threshholds.

It would be nice to be able to specify when these keep-alive packets should be sent :)