[En-Nut-Discussion] How do we use TCP Socket timeout to detect a dead connection?

[Harald Kipp]

Hi,

On 08.07.2010 14:26, Lost Jedi wrote:
> If using NutTcpSetSockOpt to set receive timeout, for eg:
> 
>    u_long rx_to = 10000;
> 
>    NutTcpSetSockOpt(sock, SO_RCVTIMEO, &rx_to, sizeof(rx_to));
> 
> All it does is flush the buffer/dump the data - a blank - after the timeout, much like the way the serial port timeout works.
> 
> How does one actually detect the dead connection? (apart from using some form of keep-alive mechanism)

I assume, that the local side is receiving only, while the remote side
is a pure transmitter. Otherwise you'd get an error when trying to send
data to the remote.

As this had been answered often in all kind of TCP/IP related (not
Nut/OS specific) lists, forums etc., I'll try it the other way round,
asking more questions.

What kind of dead connection do you expect to detect? Broken cable?
Router crashed? Ethernet switch broken? Remote crashed?

How long do you expect the other side not sending anything while still
healthy? 10 seconds, 1 hour, 5 days, 2 years?

Lets assume, you've connected your home in London with your smartphone
being in Johannesburg. An application running on the smartphone waits on
a TCP socket for a burglar alarm message from your home server. Suddenly
somewhere between these two locations an Internet router died. After a
few minutes this was fixed. Hours later a bad guy breaks into your house
and the alarm message is sent to your smartphone. Until then nothing had
been exchanged between the two end points except the very first
connection handshake, possibly many days ago.

This is, what TCP/IP is designed for: Reliable connections in an
unreliable environment with minimal traffic.

Regards,

Harald

P.S.: If you regularly want to check, that the route to the remote is
still available, you need to send some kind of probes, like ICMP echo
requests. However, the most reliable way is to send these probes on the
same TCP connection you are listening on. Otherwise you may miss a close
on the remote side during a temporary network breakdown or, more likely,
a remote reboot without connection close.