CODEWITHSUNDEEP
socketstcp
matang
matang

Reputation: 259

tcp connection issue for unreachable server after connection

I am facing an issue with tcp connection..

I have a number of clients connected to the a remote server over tcp . Now,If due to any issue i am not able to reach my server , after the successful establishment of the tcp connection , i do not receive any error on the client side .

On client end if i do netstat , it shows me that clients are connected the remote server , even though i am not able to ping the server.

So,now i am in the case where the server shows it is not connected to any client and on another end the client shows it is connected the server.

I have tested this for websocket also with node.js , but the same behavior persists over there also .

I have tried to google it around , but no luck . Is there any standard solution for that ?

Upvotes: 0

Views: 1722

Answers (1)

selbie
selbie

Reputation: 104559

This is by design.

If two endpoints have a successful socket (TCP) connection between each other, but aren't sending any data, then the TCP state machines on both endpoints remains in the CONNECTED state.

Imagine if you had a shell connection open in a terminal window on your PC at work to a remote Unix machine across the Internet. You leave work that evening with the terminal window still logged in and at the shell prompt on the remote server.

Overnight, some router in between your PC and the remote computer goes out. Hours later, the router is fixed. You come into work the next day and start typing at the shell prompt. It's like the loss of connectivity never happened. How is this possible? Because neither socket on either endpoint had anything to send during the outage. Given that, there was no way that the TCP state machine was going to detect a connectivity failure - because no traffic was actually occurring. Now if you had tried to type something at the prompt during the outage, then the socket connection would eventually time out within a minute or two, and the terminal session would end.

One workaround is to to enable the SO_KEEPALIVE option on your socket. YMMV with this socket option - as this mode of TCP does not always send keep-alive messages at a rate in which you control.

A more common approach is to just have your socket send data periodically. Some protocols on top of TCP that I've worked with have their own notion of a "ping" message for this very purpose. That is, the client sends a "ping" message over the TCP socket every minute and the server responds back with "pong" or some equivalent. If neither side gets the expected ping/pong message within N minutes, then the connection, regardless of socket error state, is assumed to be dead. This approach of sending periodic messages also helps with NATs that tend to drop TCP connections for very quiet protocols when it doesn't observe traffic over a period of time.

Upvotes: 1

Related Questions