killing NAT timeouts, for fun and profit Options

[Guest_eltee_*]

Given a number of users are stuck behind annoying timeout prone routers these days (and unfortunately that the number of us are growing not shrinking) it would be nice to have a 'world' option to kill NAT timeouts.

This is pretty easily done by jus sending an empty packet to the connected world every x minutes. The packet, being empty, is discarded, but after it fools the NAT device into realizing the connection is still live.

A bonus (over using ##task) is that there is no indication its happened at all within the actual mu*. If you are idle 10 minutes and an empty packet is bounced, you are still idle 10 minutes. This helps by not leaving connections open indefinately (the mu* timeout will still apply) and lets people know when you are infact, idle.

Once something like this is in place, those of us with these routers will *NEVER* suffer another NAT timeout again. Not bad, ending months or nigh on years of frustration for lots of people with a single little quick change. ^.^

[jay]

Well, I dusted off my efforts on implementing this again. Last time I tried was over a year ago (mention of it in the old Savitar conference.) I hit a brick wall when I last tried, and had forgotten about it. Tried getting back into it again last night and hit the same brick wall. This snippit of a chat I had sums it up best:

/jay

----

Jay is trying to add a sort of "keepalive" ping to his moo client -- so connections through NAT devices (for example) don't time out on idle.

Charkes [to you]: so far that has only been implemented by MOO features

You say, "I looked at TCP_KEEPALIVE but it's not really part of the tcp spec, and there's lots of mention that the minimum keepalive time is 2 hours on my implementation (Open Transport)"

Charkes [to you]: what you should do is send a string and block the known reply

You [to Charkes]: Been doing that for years.

You [to Charkes]: My moo client isn't really a moo client -- its a M* client, so I'm trying to come up with a solution that doesn't use the server. I'm now trying to generalize it.

Charkes [to you]: good luck

You [to Charkes]: It's that bad, huh?

Charkes is on 4 different MOOs which means 4 different features programmed by 4 different people... 4 strings to gag on the client side

You say, "man. so much for TCP_KEEPALIVE"