how to handle socket timeout?
in [Unix Programming]
|
From: Arkadiy on 11 Jan 2008 16:22 Hi all, My client code connects a TCP socket, and then uses it to send requests and recieve responces many times. What should I do when I get a timeout? The examples I saw so far seem to suggest to continue using the socket, however somehow I doubt this is correct, at least in my case. If recv() times out, this just means socket didn't get readable -- no data in the TCP buffer. This doesn't necessarily mean this data won't appear in this buffer after the timeout have happened. So, if I continue using the socket, and send another request, the next response I get (if I get it) will be to my old request... So, my options would be to either keep track of the number of timed- out requests, so that I can discard correct number of responses, or re- create and re-connect the socket. Is this correct? Am I missing something? Also, with UDP, my server in its responce echoes the request ID that I send. If I just discard the datagrams with request ID that doesn't match, will it handle the timeout? Regards, Arkadiy
From: Barry Margolin on 11 Jan 2008 22:38 In article <45b2a0bb-cc60-4a45-8aa3-8b62ed7b6636(a)d21g2000prf.googlegroups.com>, Arkadiy <vertleyb(a)gmail.com> wrote: > Hi all, > > My client code connects a TCP socket, and then uses it to send > requests and recieve responces many times. What should I do when I > get a timeout? The examples I saw so far seem to suggest to continue > using the socket, however somehow I doubt this is correct, at least in > my case. > > If recv() times out, this just means socket didn't get readable -- no > data in the TCP buffer. This doesn't necessarily mean this data won't > appear in this buffer after the timeout have happened. So, if I > continue using the socket, and send another request, the next response > I get (if I get it) will be to my old request... recv() doesn't time out by default. So if you don't know what to do about a timeout, don't use the SO_RECVTIMEO option in the first place. > > So, my options would be to either keep track of the number of timed- > out requests, so that I can discard correct number of responses, or re- > create and re-connect the socket. Or just wait for the response and process it when you get it, rather than timing out. > > Is this correct? Am I missing something? The full answer is that it depends on the application protocol you're implementing. > > Also, with UDP, my server in its responce echoes the request ID that I > send. If I just discard the datagrams with request ID that doesn't > match, will it handle the timeout? Again, it depends on the application. If you only care about the response to the most recent request, this will work. But if you pipeline requests, you may need to process all the responses even if they arrive out of order. -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: Arkadiy on 11 Jan 2008 23:27 On Jan 11, 10:38 pm, Barry Margolin <bar...(a)alum.mit.edu> wrote: > recv() doesn't time out by default. So if you don't know what to do > about a timeout, don't use the SO_RECVTIMEO option in the first place. Actually I do want rather short timeout. If it happens, I want to discard the response. > > So, my options would be to either keep track of the number of timed- > > out requests, so that I can discard correct number of responses, or re- > > create and re-connect the socket. > > Or just wait for the response and process it when you get it, rather > than timing out. No, this wouldn't work in my case. The whole thing is performance- critical. If it times out, I want to take an alternative route. > > Also, with UDP, my server in its responce echoes the request ID that I > > send. If I just discard the datagrams with request ID that doesn't > > match, will it handle the timeout? > > Again, it depends on the application. If you only care about the > response to the most recent request, this will work. Yes. My protocol is -- send request, get response, if it times out, forget the whole thing, send the next request, get the next response, and so on... Regards, Arkadiy
From: Rainer Weikusat on 12 Jan 2008 03:44 Arkadiy <vertleyb(a)gmail.com> writes: [TCP] > On Jan 11, 10:38�pm, Barry Margolin <bar...(a)alum.mit.edu> wrote: >> recv() doesn't time out by default. �So if you don't know what to do >> about a timeout, don't use the SO_RECVTIMEO option in the first place. > > Actually I do want rather short timeout. If it happens, I want to > discard the response. > >> > So, my options would be to either keep track of the number of timed- >> > out requests, so that I can discard correct number of responses, or re- >> > create and re-connect the socket. >> >> Or just wait for the response and process it when you get it, rather >> than timing out. > > No, this wouldn't work in my case. The whole thing is performance- > critical. If it times out, I want to take an alternative route. > >> > Also, with UDP, my server in its responce echoes the request ID that I >> > send. �If I just discard the datagrams with request ID that doesn't >> > match, will it handle the timeout? >> >> Again, it depends on the application. �If you only care about the >> response to the most recent request, this will work. � > > Yes. My protocol is -- send request, get response, if it times out, > forget the whole thing, send the next request, get the next response, > and so on... Since your application protocol is already unreliable in nature and you want realtime behaviour, ie no (unlimited) retransmissions of old data which didn't make it "across the net" the first time, you should IMO not be using TCP for this, but rather UDP.
From: David Schwartz on 12 Jan 2008 04:17
On Jan 11, 8:27 pm, Arkadiy <vertl...(a)gmail.com> wrote: > Yes. My protocol is -- send request, get response, if it times out, > forget the whole thing, send the next request, get the next response, > and so on... If the protocol permits the other side to not respond, it should also require the other side to specifically identify what request each response is to. If it doesn't do that, the protocol is broken. I agree with Rainer Weikusat. It sounds like TCP was a bad choice, as it provides you no ability to control the transmit timing. DS |