Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=3977
eAthena implements a custom application-level connection keepalive/timeout mechanism. It keeps track of when the remote side last sent some data, and if it's past a timeout value it closes its socket. The purpose of this feature is not documented, however I'm guessing it has something to do with disconnecting players that lag out but the system does not feel like closing the socket, and with dropping connections to servers that freeze.
A consequence of this feature is that servers and clients need to send out artificial traffic (pings) often, otherwise they get forcibly disconnected. This puts extra requirements on the code and complicates the protocol (and packet traces).
I traced this feature back to
r924, where MouseJstr added it to deal with "some NAT based routers that are not dropping the TCP connection when the aliased machine goes offline abnormally". If this is the only purpose, then he's handling a TCP-level issue as an application-level problem.
My suggestion is to remove this timeout and keepalive thing, and instead delegate the task of managing the connection timeout to TCP and the OS. If we can control a socket's tcp timeout (and I hear we can), then all that's needed is a bunch of setsockopt() calls.
One thing I'm wondering about is, how would such a setup behave if the remote side goes into an infinite loop. Currently, the connection times out after 1 minute. Would a tcp-level connection do the same? We want to avoid situations where the charserver freezes, and the mapserver keeps shoveling data into the send buffer until all memory runs out.