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

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
.

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
    ... underlying mechanism for the ReceiveTimeout property): ... socket, the socket state is indeterminate, and ... than using the ReceiveTimeout property. ... a timeout explicitly, rather than having the socket manage the timeout ...
    (microsoft.public.dotnet.framework)
Loading