0

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??

Srinivas
  • 1

3 Answers3

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).

Martin James
  • 24,453
  • 3
  • 36
  • 60
  • *The TCP stack will only throw an error after some number of retransmission attempts.* can you tell me what is that error and after approx what time will tcp throw that error. – Srinivas Jan 20 '12 at 05:42
  • The acual error thrown can vary - you may get ECONNRESET or ECONNABORTED or ETIMEDOUT. Depends on how, and if, the server and/or router/s go away and come back up, and when. The time taken before the error is issued is OS/configuration dependent, but it's going to be tens of seconds on most OS. It has to be long in case some router somewhere is trying to establish an alternative route, eg. by dialling a modem or trying to get a slot on a microwave link. The protocol will try very hard to deliver the data somehow and it has to be given time to try to do so. – Martin James Jan 23 '12 at 13:04
0

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

Michael Krelin - hacker
  • 138,757
  • 24
  • 193
  • 173
  • `SO_KEEPALIVE` generally is sent every two hours or some such. I would not recommended that as a way to check connection status. – Some programmer dude Jan 19 '12 at 11:06
  • It is adjustable, but no, I'm not recommending it, I'm covering options :) – Michael Krelin - hacker Jan 19 '12 at 11:08
  • @user1158242, I guess if you adjust it using `setsockopt`, then not. If you adjust systemwide then, obviously, yes. – Michael Krelin - hacker Jan 19 '12 at 12:41
  • can u give me the syntax to set the particular socket (and not the entire system) to give a signal or error within 1sec of the server going down ... – Srinivas Jan 19 '12 at 13:30
  • Look it up here, http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/ but one second sounds like asking for too much indeed. – Michael Krelin - hacker Jan 19 '12 at 13:38
  • not at all ... i dont know how they implement real time applications , they must be detecting and reconnecting at much faster speeds, some one who has worked on such things might be able to tell us. – Srinivas Jan 19 '12 at 13:49
  • It sounds more like udp, I'd say. – Michael Krelin - hacker Jan 19 '12 at 13:51
  • 'real time' applications have to accept and handle network latency. A video streamer might, for example, maintain a large queue of frames to allow sufficient time for a typical reconnect/resync without any noticeable communication break by the user. The cost for this is latency - the movie is being viewed seconds later than is actually being received. – Martin James Jan 23 '12 at 13:09
0

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.

Raedwald
  • 46,613
  • 43
  • 151
  • 237
  • If not immediately then ASAP would do ..yes but the general case is that sigpipe is returned after 2nd send , and if someone were giving config commands, then there is a possibility that socket gets broken just before he sends the last config cmd and he wudnt know he missed it.. – Srinivas Jan 19 '12 at 13:52
  • @Srinivas "just before he sends the last config cmd and he wudnt know he missed it" so your *real* interest is knowing, on the sender getting a a `SIGPIPE`, how much data has been received by the receiver? Knowing that isn't much use, because the sender probably really wants to know whether the recevier has completed acting upon the commands send. For that you need to build a protocol on top on TCP/IP, which has the receiver sending acknowledgements for completed commands. – Raedwald Jan 19 '12 at 14:01
  • I want the client to reconnect automatically, which is y i am depending on a signal handler to do the job .. yeah der is also a ack response from the receiver after he successfully completes execution ... but say if the client doesnt receive ack for the last cmd , he wudnt know whether it was due to broked socket or due to the incompetency of the receiver to complete the cmd... – Srinivas Jan 19 '12 at 14:24