Re: GetStream.Read behavior changed in .Net 2.0 with respect to ReceiveTimeout

On Jul 31, 8:55 pm, Peter Duniho <NpOeStPe...@xxxxxxxxxxxxxxxx> wrote:
Keith Langer wrote:
Can you explain this indeterminate state?

From the Winsock documentation for SO_RCVTIMEO (which I believe is the
underlying mechanism for the ReceiveTimeout property):

If a send or receive operation times out on a
socket, the socket state is indeterminate, and
should not be used; TCP sockets in this state
have a potential for data loss, since the
operation could be canceled at the same moment
the operation was to be completed.

I have always been able to

reuse the connection without any problems in 1.1.

This is the sort of thing that could work an arbitrarily large number of
times before you actually see a problem. But that doesn't mean that the
problem isn't worth worrying about.

Now if I have a

series of serial devices I'm polling, for every serial timeout, I have
to add a few more seconds to reestablish the tcp connection. This is
going to slow things down quite a bit. Plus, in cases where someone
else makes the connection, I'm forcing them to reconnect.

If disconnecting is not suitable, then you need a different mechanism
than using the ReceiveTimeout property. It is fairly easy to implement
a timeout explicitly, rather than having the socket manage the timeout
for you, and doing so not only addresses the above issue, it gives you
much more control over how the timeout works (including how to handle
the case of having data arrive on the socket immediately after the
timeout was signaled).

That said, IMHO if having the socket disconnected isn't a reasonable
response to the timeout, I have to question whether what you really want
is a timeout in the first place. A timeout is essentially an error
condition. If you are going to continue to try to wait for data (that
is, the timeout doesn't represent an error), then you don't really want
a timeout...you just want some sort of notification that a certain
amount of time has gone by without any data being received on the
socket. That can be easily done without involving the socket at all,
and IMHO it _should_ be done instead of getting the socket involved.

This latter point is more philosophical than anything, but it is IMHO a
design point worth considering.

Pete

Pete,

Could you show me some code which uses these alternatives for checking
if data has arrived? The only other way I know to check for data on
the socket is to keep checking the DataAvailable property and sleeping
for a small period of time, then exit out when my timeout period has
elapsed without receiving data.

thanks,
Keith

.

Relevant Pages

  • Re: GetStream.Read behavior changed in .Net 2.0 with respect to ReceiveTimeout
    ... I only mentioned alternatives to implementing a timeout. ... Most socket i/o code does not bother with a timeout at all. ... Via a BeginXXX method you tell .NET to call a specific method when the i/o completes, and when it completes, your method is called. ...
    (microsoft.public.dotnet.framework)
  • Re: Socket recv() question?
    ... You might be doing something crazy, writing the data to the file one byte ... socket function correctly? ... The PC would send the data and Pocket PC would receive it. ... Configure tx timeout ...
    (microsoft.public.windowsce.app.development)
  • Re: Threads and socket.setdefaulttimeout
    ... settimeout on the socket) was because it seemed like the only way (and ... > their timeout period to allow other runnable threads to proceed. ... making the since-bad choice of using setdefaulttimeout to get timeouts ... code needs to check the lock to avoid conflict. ...
    (comp.lang.python)
  • Re: Socket recv() question?
    ... You might be doing something crazy, writing the data to the file one byte at ... socket function correctly? ... How come when I use the IE on the Pocket PC and started IIS on my PC. ... Configure tx timeout ...
    (microsoft.public.windowsce.app.development)
  • Re: GetStream.Read behavior changed in .Net 2.0 with respect to ReceiveTimeout
    ... I only mentioned alternatives to implementing a timeout. ... socket i/o code does not bother with a timeout at all. ... you call the BeginXXX method again to repeat the sequence. ...
    (microsoft.public.dotnet.framework)