send() function behavior when link goes down in a TCP connection

Question

Following is the scenario:

A <-------------------------> B

I am using non-blocking Sockets on both A and B (linux based machines). A and B have a TCP connection and suddenly the link connecting them goes down (The link may not be direct link). Now after the link is down, when send() function is called on side A to send some data to B , It returns successfully (i.e it returns the number of bytes that are to be sent).

What is the reason for this behavior, when we know the remote side will not be able to receive this data, when the link is down?

Answer 1

This is normal and expected behaviour.

when we know the remote side will not be able to receive this data

Well, maybe you know, because you are the one you pulled the cable and you aren't about to plug it back in again, but the computer (or, in particular, the TCP stack) doesn't know.

The first reason why it doesn't know the data won't make it is that by the time the send() call completes, the data haven't gone on the wire yet: they've only been queued in a buffer.

The second reason why it doesn't know the data won't make it is that it can't (at least at first) tell the difference between a link that has simply dropped a packet and the packet may get through when it tries to retransmit it, versus a cable that has been well and truly cut. Even for a cable cut, TCP will keep retransmitting for a while, hoping that either (1) the link comes back, or (2) routers will converge on another network path that works.

Even if you could know instantly when a link is down (although you can in some very specific cases, you can't in general, you must wait for a timeout to figure this out), you wouldn't want TCP to instantly break connections every time it happened: it would be way too fragile if TCP connections broke every time a packet was lost in the network.