Okay, I''ve got a shell account on a linux server, and they appear to close completely inactive sockets after 30 minutes or so. The problem is, however, that neither the client nor the server detects the closing until something happens on either end. When I telnet in, and the socket closes, the (WindowsXP) telnet client just sits there, and closes about 1 minute or two after I type something in. What''s even worse, however, is that my server doesn''t detect it until a certain amount of data is sent to the socket. For example, I know the socket is dead, but the server still thinks it''s alive. I try sending data, and it "successfully" sends data to the socket, until I reach a certain amount (I haven''t actually measured how much, but I''m guessing that it''s when the system''s TCP/IP buffer on that particular socket is filled up), at which point it finally figures out the socket is dead, and starts telling me that no data was sent. Does this have something to do with linger options?

It sounds like it''s a problem where shutdown isn''t being called on the socket prior to closure.

Once a socket times out it should really be disabled with shutdown before closing the socket, this disables any read and/or write operations on the socket.

The linger option is for allowing you (or more precisely, the network stack) to send queued data after a socket has been closed, as opposed to receiving data - so I don''t think it''s that.

Well I''ve narrowed it down to my router now; apparently every 30 minutes it clears the routing tables for completely inactive sockets.


Of course what it doesn''t do is tell either end that the socket is closed (I think it just assumes that is implied with 30 minutes of inactivity).


So definitely not a linger problem, and W. Richard Stevens says this thing can''t be solved with anything but a user-layer keepalive scheme, since TCP keepalives are far too infrequent to actually do anything useful.

Glad you sorted it out - this must be a configurable thing in your router though, no?