Re: TcpClient read/write timeouts do not timeout

[Zytan]

I just had the problem occur again, with NetworkStream.Write() doing
its thing with a timeout... and it just sits and waits and waits and
waits... it never times outs. So, I shut the server down just to see
if THAT will make it at least end the function call and continue
(since it's a synchronous call, so the program is delayed until it
returns), and even THAT doesn't make the call end. It just sits and
waits...

Even IF I have a bug in the server, once the server is not even online
or running any more, there is absolutely no reason why this
NetworkStream.Write() should not end and return. If it has a timeout
of 1 minute, it should return after 1 minute no matter WHAT is
happening.

Hard to say without seeing an actual concise-but-complete code example.

Indeed, but that is going to be nearly impossible to supply. Network
code is just not precise. But, I can say that I'm using the source
code from the TcpClient example on MSDN:
http://msdn.microsoft.com/en-us/libr...tcpclient.aspx
EXCEPT that I implement a delay, and do proper exception handling.

That said, your description isn't all that clear either. Are you having
read/write problems or connection problems? One paragraph says the
former, while another says the latter.

Sorry, the connection IS established, otherwise an exception is thrown
and it wouldn't even GET to the writing/reading stage (see TcpClient
example on MSDN). The issue occurs on reading/writing. It just never
returns from the function call Well, it works 99% of the time, but
when it doesn't work, the call just doesn't end. The server sees the
connection, but never receives any data from the client's Write()
call.

Beware of using the TCP timeout: once the timeout occurs, the socket is no
longer usable.

Thanks for the tip. These are the kinds of things I'd like to know
about.

Depending on your intent, you may be better off
implementing timeout logic yourself elsewhere.

All I desire is to connect to a server, give it some data, it
processes it, and returns the data, and disconnects. A one shot
deal. No repeats. This is why I chose TcpClient, I can: 1. connect,
2. write, 3. read, 4. disconnect, all synchronously, and save the
headaches of writing Asynchronous code.

Zytan

[Peter Duniho]

On Mon, 21 Jul 2008 09:59:45 -0700, Zytan <zy**********@gmail.comwrote:

[...]

>Hard to say without seeing an actual concise-but-complete code example.

Indeed, but that is going to be nearly impossible to supply. Network
code is just not precise.

I disagree. The _code_ can be, and should be, just as "precise" as any
other code.

It's true that the network environment is less deterministic than code
that is affected only by the goings-on of the local computer. But a) that
doesn't mean that it's not possible to reproduce a problem, and b) it's
not possible to verify that your code is correct, even theoretically,
without seeing the code.

If anything, in a situation like this, it becomes that much more important
for you to investigate the exact circumstances under which the problem
occurs. I think the new name for the Ethereal network analysis tool is
Wireshark. You may want to install that to monitor your network traffic,
so that you can figure out what's different between the cases where the
timeout works as expected, and when it doesn't.

But, I can say that I'm using the source
code from the TcpClient example on MSDN:
http://msdn.microsoft.com/en-us/libr...tcpclient.aspx
EXCEPT that I implement a delay, and do proper exception handling.

What "delay"? What does that mean? Do you mean "timeout"? The two words
don't really mean the same thing, even if they are related. It's
confusing to see them used interchangeably, if that's in fact what you're
doing.

Regardless, the link you provided isn't a complete implementation of a
network i/o (at best, it's one half of the implementation), nor is it
actually exactly the code you're using. So it's not useful in this
context (even if it did prove useful to you as a starting point).

>That said, your description isn't all that clear either. Are you having
read/write problems or connection problems? One paragraph says the
former, while another says the latter.

Sorry, the connection IS established, otherwise an exception is thrown
and it wouldn't even GET to the writing/reading stage (see TcpClient
example on MSDN). The issue occurs on reading/writing. It just never
returns from the function call Well, it works 99% of the time, but
when it doesn't work, the call just doesn't end. The server sees the
connection, but never receives any data from the client's Write()
call.

>Beware of using the TCP timeout: once the timeout occurs, the socket is
no
longer usable.

Thanks for the tip. These are the kinds of things I'd like to know
about.

Of course, now that I look more closely, I see that you may not be using
the TCP timeout. It depends on the implementation of NetworkStream's
timeout properties, but I suspect that given that they say they only have
an effect for synchronous calls, it's probably implemented at a higher
level than the socket itself.

If I have time, I may look a little more closely at that. Or you can use
Reflector and/or Microsoft's .NET source server to check yourself.

Pete

[Zytan]

Hard to say without seeing an actual concise-but-complete code example.

>

Indeed, but that is going to be nearly impossible to supply. Network
code is just not precise.

I disagree. The _code_ can be, and should be, just as "precise" as any
other code.

Yes, you're right.

If anything, in a situation like this, it becomes that much more important
for you to investigate the exact circumstances under which the problem
occurs.

I was trying to, and the issue always occurred on the PCs what I
wasn't running my debugger on. Finally it happened on the PC with my
debugger, but I had already solved the problem right when it happened!

I think the new name for the Ethereal network analysis tool is
Wireshark.

Thanks, I do have Wireshark already, great program!

But, I can say that I'm using the source
code from the TcpClient example on MSDN:
http://msdn.microsoft.com/en-us/libr...kets.tcpclient....
EXCEPT that I implement a delay, and do proper exception handling.

What "delay"? What does that mean? Do you mean "timeout"? The two words
don't really mean the same thing, even if they are related. It's
confusing to see them used interchangeably, if that's in fact what you're
doing.

Sorry, I am using a send and receive timeout within TcpClient, which
gets transferred over to NetworkStream, although the data members are
called different things in the two classes, they are the same thing
AFAIK.

Regardless, the link you provided isn't a complete implementation of a
network i/o (at best, it's one half of the implementation), nor is it
actually exactly the code you're using. So it's not useful in this
context (even if it did prove useful to you as a starting point).

Agreed. When I shut down the server, and it didn't affect the client,
I knew the issue was in the client-side.

Of course, now that I look more closely, I see that you may not be using
the TCP timeout. It depends on the implementation of NetworkStream's
timeout properties, but I suspect that given that they say they only have
an effect for synchronous calls, it's probably implemented at a higher
level than the socket itself.

If I have time, I may look a little more closely at that. Or you can use
Reflector and/or Microsoft's .NET source server to check yourself.

No no no, I've wasted enough of your time, already!!

The bug was something REALLY STUPID that I did, I wrote about it in
another reply!

Zytan