SIGPIPE not being generated immediately after 1st send

Question

I want to know whether its possible for tcp socket to report any broken pipe error immediately. Currently i am catching the sigpipe signal at the client side when server goes down ... but i found that the sigpipe signal is generated only after 2nd msg is sent from client to server . what could be the possible reason for this?? If the other socket end went down , then the 1st send must return sigpipe .. y isnt that signal generated immediately..?? Is there any possible explanation to this peculiar behaviour?? And any possible way to get around this??

Answer 1

The TCP stack will only throw an error after some number of retransmission attempts. IIRC, the TCP retransmission timer is initialized to some small number of seconds and the number of retransmissions is typically 5-10. The protocol does not support any other means of detecting a peer that has become unreachable during a data exchange, (ie. someone tripped over the server power cable).

Answer 2

I think using SO_KEEPALIVE option may speed up broken link detection.

Answer 3

I want to know whether its possible for tcp socket to report any broken pipe error immediately

The other end of the pipe is across a network. That network could be slow and unreliable. So one end of the pipe can never instantly tell whether its partner still there. The delay could be quite long, so the O/S is also likely to do some bufferring. These considerations make it practically impossible to immediately detect a broken pipe.

And any possible way to get around this

But why would you want to? The pipe could be broken at any time during trans mission, so you have to handle the general case anyway.