Categories

Socket buffering is my bane (pt 1)

I mentioned in a previous post that my gtelnetd implementation was failing to recognize a non explicit disconnect.

By non explicit I mean that a client becomes unavailable but does not send notification of its intent to be unavailable.

The first question I asked is whether or not a FIN packet is sent when a client goes into hibernate/suspend.

I wrote a little toy app and was able to get it to recognize a disconnect after about 15 minutes…

From what I can tell from the trace, the server sent 8 retransmissions over about 50 seconds. After that, it began sending out arp requests looking for the client.

It sent requests out for 4.5 minutes, then did nothing for about a minute or two, then sent out another group of arp requests for about 6.5 minutes.

Then, the server *FINALLY* recognized that it failed to send() data…

The entire time up to this point, the server was send()ing data and everything looked fine as far as it was concerned.

At least we confirmed that sending the client to hibernate/suspend does *NOT* send a FIN.

In fact, it would appear that as far as a server is concerned, a client going to hibernate/suspend is indistinguishable from a physical connection loss.

Comments are closed.