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

Tech-Archive recommends: Fix windows errors by optimizing your registry

Keith Langer wrote:
This application runs a number of signs (serial devices) connected to
several device servers. Each device server has a dedicated thread and
TcpClient associated with it in my application. There could be
anywhere from 1 to 150 of these device servers,

You may want to reconsider the design. 150 threads is a LOT of threads for Windows. If you can redesign the code so that a single thread can handle all of the server tasks, you will be less likely to run into performance problems when you approach that number.

and each device server
could have 1 to 100 signs (a typical site might have anywhere from 10
to 500 signs in total). Some of the signs respond to messages sent,
but there is no guarantee that all signs are functional.

Nothing unusual about that.

So for each
device server, I must send a message to sign 1, wait for a response or
for a timeout period of X seconds to elapse, then send the next
message to that sign or the next sign.

I don't understand where you get this requirement. It is not something that is implied by anything you wrote so far.

What is it about your application that imposes a requirement that you do not send a message to a given sign until you have resolved the outcome of a message sent previously to a different sign? Does the message that you tried to send to a given sign propagate forward to the next sign if you don't get a response from the first sign?

Hence, this is my need for
some sort of timeout. I either need to keep checking the
DataAvailable property for several seconds, or implement a blocking
operation for several seconds until data is available.

See above. I don't see how you have arrived at this conclusion.

Pete
.