Web Socket messages not all being received

Question

I have implemented a web socket server using Alchemy web sockets, and am now trying to stress test it. I have written the following method in C# to create numerous clients to connect to the server and send some data:

private void TestWebSocket()
{
    int clients = 10;
    long messages = 10000;
    long messagesSent = 0;
    String host = "127.0.0.1";
    String port = "11005";

    WSclient[] clientArr = new WSclient[clients];
    for (int i = 0; i < clientArr.Length; i++)
    {
        clientArr[i] = new WSclient(host, port);
    }

    Random random = new Random();
    var sw = Stopwatch.StartNew();

    for (int i = 0; i < messages; i++)
    {
        clientArr[i % clients].Send("Message " + i);
        messagesSent++;
    }
    sw.Stop();

    Console.WriteLine("Clients " + clients);
    Console.WriteLine("Messages to Send" + messages);
    Console.WriteLine("Messages Sent " + messagesSent);
    Console.WriteLine("Time " + sw.Elapsed.TotalSeconds);
    Console.WriteLine("Messages/s: " + messages / sw.Elapsed.TotalSeconds);
    Console.ReadLine();

    for (int i = 0; i < clientArr.Length; i++)
    {
        clientArr[i].Disconnect();
    }

    Console.ReadLine();
}

However the server is receiving less messages (even with a small number e.g. 100). Or sometimes multiple messages are received as a single message e.g.:

Message1 = abc Message2 = def

Received As = abcdef

I am trying to more or less replicate the example shown here . At the moment both the server and the client are running locally. Any ideas on what the problem is or on how to improve the test method?

Answer 1

There are two open issues on the github project that sound similar:

• Server drops inbound messages and receives corrupted input
• JSON messages truncated

One of the commenters reported better luck with Fleck

Answer 2

TCP is a streaming protocol, not a message oriented protocol. That means that the receiver is responsible for finding the beginning/end of each message contained within the stream. It also means that the receiver is responsible not only for breaking apart large reads into individual messages, but sometimes it will also need to collect small reads until a complete message is received. The example messages provided show that two were sent and TWO were received, but apparently your server cannot determine where one message ends and the other begins. You probably need to add some sort of internal protocol with your data to mark the beginning and end of each message. If your messages are always exactly the same length, you could just work with the size, but that's less reliable and potentially difficult to port reliably to other communication methods (if that is ever needed later in the program's life -- something that almost always happens to me!)

If your messages are all the same length, the receiver can normally limit the read size (I don't know your library, though) to that length so that picking apart large reads is not necessary. HOWEVER, small reads may still occur due to the way the TCP/IP stack may collect data from the stream into packets for transmission on the physical network. If you don't want to write collection code, then you need to find a peek function that will tell you how much data is available to read before you actually perform the read, allowing your program to wait until there is at least enough for one whole message ready to read.