Concurrent reader/writer threads on single socket

  • Thread starter Thread starter roblugt
  • Start date Start date
R

roblugt

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(socket);
BinaryWriter writer = new BinaryWriter(ns);
BinaryReader reader = new BinaryReader(ns);
startReaderThread(reader);
startWriterThread(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(new NetworkStream(socket));
BinaryReader reader = new BinaryReader(new NetworkStream(socket));
...

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/library/system.net.sockets.socket.aspx
[2]
http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx
 
You don't have to use the asynchronous (beginXXX/endXXX ) calls to get the
effect of asynchronous IO. You can work directly with the Socket class
(implements the Berkely socket interface), fire up your own threads, and
make blocking calls on the socket. I haven't tried doing simultaneous reads
and writes, each on their own thread, but I think it ought to work - the
receive and send buffers ought to be logically separate. I don't believe the
Sockets class is inherently thread safe, but it should be ok so long as you
serialize your reads or writes to the socket on the same thread.

The sockets class is a thin wrapper over the Winsock implementation.

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(socket);
BinaryWriter writer = new BinaryWriter(ns);
BinaryReader reader = new BinaryReader(ns);
startReaderThread(reader);
startWriterThread(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(new NetworkStream(socket));
BinaryReader reader = new BinaryReader(new NetworkStream(socket));
...

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/library/system.net.sockets.socket.aspx
[2]
http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx
Click to expand...
 
David said:
You don't have to use the asynchronous (beginXXX/endXXX ) calls to get the
effect of asynchronous IO. You can work directly with the Socket class
(implements the Berkely socket interface), fire up your own threads, and
make blocking calls on the socket. I haven't tried doing simultaneous reads
and writes, each on their own thread, but I think it ought to work - the
receive and send buffers ought to be logically separate.
Click to expand...

Thanks David - this is what I expected. But my occasional program
crashes make me suspect that this might not be the case. I wonder
could anyone from the Microsoft .Net Networking team confirm this is
supported?
 
What kind of crashes?

Rob Lugt said:
Thanks David - this is what I expected. But my occasional program
crashes make me suspect that this might not be the case. I wonder
could anyone from the Microsoft .Net Networking team confirm this is
supported?
Click to expand...
 
David said:
What kind of crashes?
Click to expand...

I'm pretty sure that occasionally the value read from the socket reader
is different from the value that was sent by the sender, which would
indicate some kind of buffer corruption is occurring. It only occurs
when the program is under heavy load (and never when running within the
debugger) - which is why I suspect the thrreading model.
 
I said:
I'm pretty sure that occasionally the value read from the socket reader
is different from the value that was sent by the sender, which would
indicate some kind of buffer corruption is occurring. It only occurs
when the program is under heavy load (and never when running within the
debugger) - which is why I suspect the thrreading model.
Click to expand...

I'm delighted to say that I've found a bug in the test program which
was almost certainly causing these read errors - and it wasn't due to
multi-threading but was caused by the program running faster than the
socket could provide data. I'm sorry for misleading the group.

So I think I can take it that the dual thread concurrent reader/writer
model does indeed work in .Net. I'd still very much like to see
Micorosft document this as a valid case.

Best regards
~Rob
 
I have used the concurrent blocking reader/writer model extensively and
confirm that it is fine. I presume you are not simply seeing the effect of
write blocks not matching read blocks? tcp (if thats what you are using)
makes no guarentee of message boudries.
 
Back
Top