ID:1427500
 
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
I'm not entirely sure where this should be implemented, possibly in the server code.

Basically we have found that some poorly designed routers categorize by known and unknown ports. If there's no activity from connections to these unknown remote ports after a specified period of time, the connection is dropped. For some routers, this value is as low as 120 seconds by default. As such, games where there are no-activity pauses may drop users.

It would be very good to avoid disconnects, if the server process (DreamDaemon or DreamSeeker, hosting the DMB) would send TCP keep-alives, in a configurable period. I'm not sure how this would be presented, probably just in BYOND's config file, or as a command line option in Linux.

I imagine a default of 60 seconds would (although be useful for the scenarios I've seen) be excessive, hence the requirement for some kind of way to configure this value.

Took me a while to find how you actually adjust this on Winsock, but I believe this would do it?

http://msdn.microsoft.com/en-us/library/windows/desktop/ dd877220(v=vs.85).aspx

For Linux, setsockopt() should do it.

http://tldp.org/HOWTO/html_single/ TCP-Keepalive-HOWTO/#programming

As a workaround, I can set it at the kernel level in Linux, and via registry on Windows, but the problem of course is these are then applied across the board, so my HTTP server will end up sending 60 second keep-alives, or my MySQL server internally on it's socket connection yadda yadda. This obviously introduces a fair bit of overhead.
If a serious lag spike hit, couldn't a keep-alive also drop the connection more frequently?
If enabled, yes. However it's a guaranteed drop a the moment for some people, regardless of the quality of the connection.

This is pretty much why I've suggested the ability to adjust the timeout value by some means. In worlds I'm looking after, such a serious lag spike (60 second+) on the server's end is a data-centre problem, and particularly rare, as the worlds themselves are extremely bare of CPU activity, and the machine is very lightly loaded. In other world for other people of course, it might well be more common, if not guaranteed.