TCP comms without specification

[UncleRonin]

I have an app which listens to a certain port indefinitely. It accepts requests from whatever clients or other applications and reads the data and dumps it. These clients and apps won't always be on Windows or whatever so there's none of the cool .NET stuff for serializing and all those good things.

What I'd like to know is what is the best way to determine when to stop reading from a stream/socket? At the moment I've set a receive timeout so that if all the data isn't read with 100ms between characters it'll throw a SocketException and I'll finalise everything else in a finally block. I have no idea what length the data will be.

To me this doesn't seem very good because I'm actually forcing and using an Exception to tell the state of the stream/socket.

Is there not a better way to do this? There are all the .Connected and .EndOfStream states but they don't cater for this, at least not as far as I can tell. I've tested with them and they're pretty crap to be honest.

Does anyone know of a better way to handle this situation? It's really quite a nuisance.

 

[UncleRonin]

As far as this goes I've resorted to relying entirely on the StreamReader (you can't really use a combination of checks since the socket and stream tend to act independently as far as I've seen).

After testing a bit more and, i guess you could say enumerating the behaviour, I use StreamReader.EndOfStream to loop and receive data. This forces the client to reconnect once it has stopped transmitting data but all's fair in love and war! Can easily build in timers and wait periods to cater for this anyway. I have completely removed any read timeouts since it can delay and slow down the application and throw unnecessary errors as well.

All I can say is Streams are very very nifty things in .NET.