NetworkStream.Read - Thread freezes

hello out there,

I use a thread data from a linuxserver. i ask for data, i read the
data (fix in size) - so far so good. this works great for the first 61
datapackages, then my thread abruptly freezes, because of the read
method. i can't locate the real reason. if I reconnect the tcpClient
after each package it works fine, but after several minutes the linux
programm quits (not my fault, not my code, not to change). has anybody
any clues about reason why this happens?

On Aug 14, 7:35 am, ohmmega <sho...@gmx.atwrote:

hello out there,

I use a thread data from a linuxserver. i ask for data, i read the
data (fix in size) - so far so good. this works great for the first 61
datapackages, then my thread abruptly freezes, because of the read
method. i can't locate the real reason. if I reconnect the tcpClient
after each package it works fine, but after several minutes the linux
programm quits (not my fault, not my code, not to change). has anybody
any clues about reason why this happens?

Have you used a packet sniffer (eg wireshark) to determine whether any
more data has actually been sent?

Jon

furthermore i thought that the use of networkStream.dataAvailable
should prevent from such deadlocks [...]

On Aug 14, 9:49 am, ohmmega <sho...@gmx.atwrote:

furthermore i thought that the use of networkStream.dataAvailable
should prevent from such deadlocks [...]

Technically, it's a blocking call, not a deadlock, but you're right;
NetworkStream.Read() should return immediately if DataAvailable (which
is why it doesn't necessarily read as many bytes as you wanted). Are
you sure the parameters to Read() are all valid, and that nobody else
is using the stream?

concerning the parameters: i've just tried out the code from the msdn.
they are using a StringBuilder instead of an byte array - ok.

On Aug 14, 2:42 pm, ohmmega <sho...@gmx.atwrote:

concerning the parameters: i've just tried out the code from the msdn.
they are using a StringBuilder instead of an byte array - ok.

Well, myReadBuffer in the MSDN example is a byte[1024]; the
StringBuffer is not relevant to the NetworkStream.Read() call.

Things to try:

1. Try the code reading from a local port on your own machine.
2. To make sure no other part of your code is somehow tampering with
your Socket/NetworkStream, make a new test (perhaps using the Snippet
Compiler) using only what's needed to actually test the Read() against
the server.
3. Try outside the debugger.
4. Run the code on a different machine.

i've just tested the direct communication [...]

1. you mean writing my own server in c#, arn't you?

2. this overrates myself: what do you mean with snippet compiler?

On Aug 14, 3:52 pm, ohmmega <sho...@gmx.atwrote:

i've just tested the direct communication [...]

What's "direct communication"?

1. you mean writing my own server in c#, arn't you?

Yeah, anything that behaves like a simple server, so you can test the
Read(). What the server does is not important. Or just Read() from an
existing server, since you don't care about the results: connect to
the IIS, Send() a HTTP request (or something that will make IIS
respond with an error message) and Read() some bytes. If that blocks
too, then the problem is not the server.

2. this overrates myself: what do you mean with snippet compiler?

Snippet Compiler compiles snippets. It's a mini-environment for
testing code.http://www.sliver.com/dotnet/SnippetCompiler/

[...]
can you tell me why my code blocks, even after checking for available
data?

NetworkStream doesn't even behave like other streams in the framework.