Question

I have a client that will send a lots of data to server from different threads.

The packet uses the following format:
PACKET_ID
CONTENT
END_OF_PACKET_INDICATOR

I have the following onDataRecieved function:

    public void OnDataReceived(IAsyncResult asyn)
    {

            SocketPacket socketData = (SocketPacket)asyn.AsyncState; 

            int iRx = 0;
            iRx = socketData.m_currentSocket.EndReceive(asyn);

            char[] chars = new char[iRx + 1];
            System.Text.Decoder d = System.Text.Encoding.UTF8.GetDecoder();
            int charLen = d.GetChars(socketData.dataBuffer, 0, iRx, chars, 0);


            MessageBox.Show("Incoming data: " + socketData.dataBuffer.Length.ToString() + " from socket(" + socketData.socket_id + ")");

            char[] PACKET_END_IDENTIFIER = { (char)2, (char)1, (char)2, (char)1 };

            for (int i = 0; i < iRx; i++)
            {

                GLOBAL_BUFFER.Add(chars[iRx]);
            }

            if (PacketEndReached(chars, PACKET_END_IDENTIFIER))
            {
                // done reading the data
                PROCESS_PACKET(GLOBAL_BUFFER);
            }

            WaitForData(socketData.m_currentSocket, socketData.socket_id);
    }

My socket buffer size is set to 100. If I send 1000 bytes, they would be split up in 10 chunks and onDataRecieved would get triggered 10 times.

All I need to do is keep reading the data into buffer for each individual packet sent my client until PacketEndReached gets triggered
then pass the buffer to another function that will process the data.

If I define a GLOBAL_BUFFER for storing incoming data, then if client sends data from multiple threads, wouldn’t the data get mixed up? I need a way to read all the data for each individual packet sent my client.

Thanks!

UPDATE:

This is my current class:

public partial class TCP_SERVER
{
    const int MAX_CLIENTS = 3000;
    const int MAX_SOCKET_BUFFER_SIZE = 10;

    public AsyncCallback pfnWorkerCallBack;
    private Socket m_mainSocket;
    private Socket[] m_workerSocket = new Socket[MAX_CLIENTS];
    private int m_clientCount = 0;

    public GLOBAL_BUFFER; 

    public void StartServer(int listen_port)

    public void OnClientConnect(IAsyncResult asyn)

    public void ProcessIncomingData(char[] INCOMING_DATA, int CLIENT_ID)

    public void OnDataReceived(IAsyncResult asyn)
}

As you can see GLOBAL_BUFFER is defined ‘globally’. If client sends packet_1 that takes 10 seconds to send and at the same time packet_2 that takes 2 secs to send data would get mixed up. I need to collect data for each packet individually.

Answer 1

If at all possible, I would recommend allowing each client thread to have their own connection to the server. Doing so will help the Winsock stack differentiate the messages from each thread and avoid any bleeding of packets between messages. This will effectively allow you to benefit from the stack’s ability to decipher which messages (and message segements) are intended to be grouped together before passing them to your application as a complete message.

The message design you describe while very primitive can only work (reliably) if you separate your threads to different connections (or otherwise provide a guarantee that only a single message will be sent from the client at a time). You employee a very primitive message framing technique to your communication which will aide in your effort to determining message boundries but the reason it is failing is because socketData.m_currentSocket.EndReceive(asyn); will only tell you the number of bytes received when the event is raised (not necessarily the total number of bytes in the message). Rather than relying on it to tell you how many bytes have been read, I’d suggest reading the incoming message incrementally from a loop within your async handler reading very small message segments until it discovers your end of message byte sequence. Doing so will tell your event when to quit reading and to pass the data on to something else to process it.

The way I typically approach message framing is to have a before message eye-catcher (some value that will rarely if ever be seen in the messaging), followed by the length of the message (encoded to taste, I personally use binary encoding for it’s efficiency), , the message content, and finally a second eye-catcher at the end of your message. The eye-catchers serve as logical queues for message breaks in the protocol and the message length tells your server explicitly how many bytes to wait for. Doing it this way, you are guaranteed to receive the number of bytes necessary (if you don’t it is a problem so discard and/or throw exception) and it provides a very explicit boundary between messages that you can code to, which allows intermittent spot checking and validation.