Home/ Questions/Q 963827
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T01:43:48+00:00

I am writing a multi-threaded .Net application in which many callers need to concurrently

  • 0

I am writing a multi-threaded .Net application in which many callers need to concurrently read from a single Socket.

Data read from the socket is split into records / chunks of data – each record is targetted at a specific caller identified by a CallerID in the header, so for example the stream of bytes read from the socket might be something along the lines of:

Header: CallerId = 1, Length = 5
Data:   "Hello"
Header: CallerId = 2, Length = 6
Data:   "Stack "
Header: CallerId = 1, Length = 7
Data:   " World!"
Header: CallerId = 2, Length = 8
Data:   "Overflow"

In which case the stream of data read by caller 1 should read “Hello World!”, while the stream of data read by caller 2 should read “Stack Overflow”.

  • My thoughts are that each callers data stream should be exposed through some class inheriting from Stream, so that callers are able to use both synchronous (Read) and asynchronous (BeginRead) programming models.
  • I’d like to avoid having a dedicated reading thread per socket, as my application will be dealing with many such sockets at any one time.
  • The callers shouldn’t block each other, so for example in the above example the following shouldn’t deadlock:

caller1Stream.Read(12) // Hello world!
caller2Stream.Read(14) // Stack Overflow

I've had a go at figuring out to do this however I found that things quickly became complicated, in particular; as the data needs to be read sequentially, and so while reading data for callers needs to be buffered - this makes the act of reading the stream for a given caller much more complicated:

  • Readers must first check their buffer to see if someone else has already read enough data
    • I'm struggling to find a suitable FIFO memory buffer / stream (does one exist already or do I need to write one?)
  • If not enough data has been read then the reader needs to read data from the socket until enough data intended for the given caller has been read, buffering data intended for other callers as it goes.
    • The buffering of data is fine (I can maintain a list of readers and look up the correct buffer by caller ID) however,
    • How do I prevent deadlocks where multiple threads attempt to read from the socket at the same time, however read each others data?
    • How do I notify callers that are waiting for data that their data has been read by another caller?
  • How do I make sure that the header and the data blocks of messages are read together? (The data block is of variable length, and so it is necessary to read the fixed-length header block first to determine how much data to read)

Surely this must be a fairly common problem - is there not a .Net class that can make this whole thing a lot simpler? (Note that I'm not able to change the transport mechanism / protocol). Is there any way to use one of the listener-style classes to do the above?

If not, how might I go about solving these problems?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Based on you’re post, I assume you’re using TCP/IP since you’re referring to streaming, but a socket can be used for UDP connectionless protocol as well (and others). UDP is very easy, since you only send around fixed messages (no streaming).

    Anyways, since you’re referring to receive a stream of messages, I must assume you’re using TCP/IP, and if you’re using the socket directly, there are some major problems with what you’re looking for.

    TCP/IP is a stream solution, so sort of what I drop in one end comes out the other, and it will always be in order, but not necessarily together. So if on one end you write “Hello World”, when reading you might get “Hello World”, or “Hello” and “World”, or even “H” “ello World”. The point is, there is no way to call read and expect to receive the entire message.

    The way I have done this in the past, is to just have an intermediary thread (or in my case, I simply used the .net thread pool), that reads the socket quickly, re-assembles messages, and then passes them on to a queue to be processed. The trick is the re-assembly, since you don’t know what you receive. Say in you’re header, the message length is an int32, that’s 4 bytes. When you call read, you may even need to re-assembly this length, since you only received the first byte out of the 4 bytes you need to tell the length.

    It sounds like you’re header is fixed length, so basically what you need to do, assuming callerid and length are uint32’s. Try and read 8 bytes, if less than 8, put into a buffer, until we read 8 bytes. Once we read the 8 bytes, take the 4 bytes and get the length, allocate a buffer for the length of the message. Try and read until we’ve filled the buffer, once we have, put that onto the queue for the specific callerid, and signal the thread that there is a new message in case it’s sleeping. Then take whatever is left over, and start over, or wait for more data.

    I have used this with success in the past, and it adds relatively little overhead.

    • 0