🔒 Locked

Handling lost connections(TCP)

Started by Icebone1000 May 14, 2011 at 4:09 AM 3 replies 1.9k views

Original Post

May 14, 2011 at 4:09 AM

Hey, Im still with that simple class for handling networking..If my connections are all TCP, is the behavior of lost connections well defined? for example, if a connection is lost( the client exploded its computer), will I get an error when attempting to send() from the server( [font="Verdana"][size=2]WSAECONNRESET or [/font][font="Verdana"][size=2]WSAECONNABORTED ) or it can just hang without noticing me?[/font]

[font="Verdana"] Should I create a method only for testing if the sockets are still connected or I can relly on the failures when sending(if send fails, close the socket)?[/font]

hplus0603

May 14, 2011 at 4:35 AM

Hey, Im still with that simple class for handling networking..If my connections are all TCP, is the behavior of lost connections well defined? for example, if a connection is lost( the client exploded its computer), will I get an error when attempting to send() from the server( [font="Verdana"][color="#000000"]WSAECONNRESET or [/font] [font="Verdana"][color="#000000"]WSAECONNRESET ) or it can just hang without noticing me?[/font]

[font="Verdana"] Should I create a method only for testing if the sockets are still connected or I can relly on the failures when sending(if send fails, close the socket)?[/font]

If the remote end goes away without sending FIN or RST, then the TCP connection will "hang" until it times out. The time-out time on the sending side varies by implementation, and has been known to be measured in hours for certain server systems.

Sirisian

May 14, 2011 at 6:04 AM

[font="Verdana"]Should I create a method only for testing if the sockets are still connected or I can relly on the failures when sending(if send fails, close the socket)?[/font]

This is generally known as a keep-alive packet. On the server every packet that is received resets the keep alive counter for that client. On the client every time a packet is sent it resets the send keep alive counter. Now if the send keep alive reaches a certain level it'll send a nop (no operation) keep alive packet which would thus reset both the client's send keep alive and the server's keep alive counter. How you implement this is up to you. In a game environment something as simple as an integer per client works well where the decrement and check is done every update on both the client and server.

Icebone1000

May 14, 2011 at 4:19 PM

Since TCP have its all time checks(for resending packets that werent ACK ) why is this not a standard thing, where you could just set the time until it considers a lost connection? Wouldnt this make things easier?

-edit-
Just noticed a keep_alive socket option in msdn..

hplus0603

May 14, 2011 at 5:49 PM

Since TCP have its all time checks(for resending packets that werent ACK ) why is this not a standard thing, where you could just set the time until it considers a lost connection? Wouldnt this make things easier?

-edit-
Just noticed a keep_alive socket option in msdn..

Yes, there is to SO_KEEPALIVE option. The problem is that parts of the network between your program and the server may not agree. For example, NAT translation tables may time out, or firewall timed rules may expire.

In general, if you're using a game, if a user hasn't been able to send commands for, say, 30 seconds, chances are the user isn't getting up to date with the game, and you might as well disconnect that user, saving server resources for users that are actually active.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.