Live TCP connection constraints

[ramusw427]

I am working in a VB6 project that involves TCP Communication using sockets.

Application requires long lived socket connections but i doubt to how much extent it is possible. Application runs in windows OS. If after a socket connection in established and some data is exchanged at regular intervals say 30 sec, will the connection lives forever or is there any constraints from OS or TCP stack or network provider?

[dilettante]

As long as you have network connectivity, TCP connections stay alive until an endpoint closes them. Even when interruptions occur connections don't get terminated until about 2 minutes go by. That's designed into the protocol.

If your programs aren't written correctly all bets are off though. Use the events properly, don't try to treat the Winsock control in TCP mode as some sort of synchronous socket.

[ahenry]

Where do you get 2 minutes from? I thought the default windows keepalive was still 2 hours.

[qvb6]

From the following link: "by default Windows PCs send the first TCP Keepalive packet after 7200000ms (2 hours), then sends 5 Keepalives at 1000ms intervals, dropping the connection if there is no response to any of the Keepalive packets."

https://en.wikipedia.org/wiki/Keepalive#TCP_keepalive

However, anything could happen, and you should have code that re-establishes the connection if needed.

[dz32]

you can set up an intermittent PING / PONG message to poll the connection and ensure its still up and alert/re-establish on the fly if it breaks down.

[Schmidt]

you can set up an intermittent PING / PONG message to poll the connection and ensure its still up and alert/re-establish on the fly if it breaks down.

Since the OP wants to transfer some data only every 30 seconds or so,
there's IMO no need to worry, whether a connection was kept open or not.

Such an interval is long enough, to make the overhead of "re-establishing a connection" insignificant.

The whole "interwebs" worked this way, when http 1.0 was still the commonly use protocol -
(despite the higher latencies, lower bandwidth, lower router- and server-performance at that time).

In the same way as http 1.0 ... just connect-transfer-disconnect ...
(the whole triple shouldn't take much more than 1-2 msec in a local GBit-LAN, when there's not much data to transfer).

Also no need for a "heartbeat-logic" or something - because when you have an interval of 30seconds,
the knowledge of "target not reachable" (due to a failed connection-attempt) will be at most 30secs old.

So, in the OPs scenario (with that larger interval), bothering about "keep-aliveness" is IMO nonessential.

Olaf