From: Arkadiy on
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
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
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
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
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