I have what I imagine is a well-known .Net networking problem, but even
though I've Googled for some time I've not yet come across a thread
where this has been fully explained...
There is a fairly common idiom (at least in the Java/UNIX/Win32 worlds)
where a socket connection is established and the program then utilises
two threads: one dedicated to reading from the socket and the other one
concurrently writing to the socket - both using blocking i/o. These
two streams of data are probably related, but the protocol is arranged
to allow pipelining of requests so that the full-duplex nature of the
socket can be fully utilised.
What I'd like to know most of all is whether this pattern is supported
in .Net. A secondary question is, if it's not supported, then how do
people cope with the additional complexity that the asynchronous
beginXXX/endXXX methods introduce.
To start with, I note from the Microsoft documentation [1] that the
Socket class is thread-safe, so it would be reasonable to assume that
what is valid for a Winsock socket is also valid for a .Net socket.
However, the same documentation states that if you need to access the
socket in a multi-threaded program you should use the asynchronous
methods. Even so, I think the document leaves some element of doubt as
to whether concurrent access by a separate reader and writer thread is
allowed (especially as it is such a common pattern in other
environments).
In order to follow this pattern, I would expect to see something like
the following (in C#)
NetworkStream ns = new NetworkStream(s ocket);
BinaryWriter writer = new BinaryWriter(ns );
BinaryReader reader = new BinaryReader(ns );
startReaderThre ad(reader);
startWriterThre ad(writer);
Now, a further inspecation of the Micorosft documentation reveals that
NetworkSocket [2] is not safe for concurrent access. I can understand
this as this class could potentially have some internal state (such as
a buffer) which would make multithreaded access unsafe. In that case,
perhaps we should modify the example to use two separate
NetworkStreams. e.g.:
BinaryWriter writer = new BinaryWriter(ne w NetworkStream(s ocket));
BinaryReader reader = new BinaryReader(ne w NetworkStream(s ocket));
...
This seems reasonable, the output stream would hold a separate buffer
to the input stream and everything is fine.
Certainly the above is possible, and in my test program it appears to
work (most of the time). But I believe it may not be correct because
my test program occasionally reads invalid input from it's reader - and
I can only imagine this is due to some data corruption at the stream
level.
So, on to the second part of my question: how does one go about
converting an application that's been designed to use blocking I/O and
layered streams to the asynchronous model? We have many message
parsing routines, all of which expect a stream as input and each
routine works on the expectation that it will read the data it needs
from the stream and then return. I'd love to know how this model could
be changed to use asynchrous i/o without greatly adding to the
complexity. I realise this may not be a simple question to answer
(hopefully someone will tell me that part (1) is okay so there's no
need).
Thanks in advance.
Rob Lugt
[1]
http://msdn2.microsoft.com/en-us/lib...ts.socket.aspx
[2]
http://msdn2.microsoft.com/en-us/lib...orkstream.aspx
