Сообщения веб-сокета не все получаются

Question

Я реализовал сервер веб-сокетов, используя сетевые сокеты Alchemy, и теперь я пытаюсь подчеркнуть его. Я написал следующий метод в C# для создания многочисленных клиентов для подключения к серверу и отправить некоторые данные:

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(); 
} 

Однако сервер получает меньше сообщений (даже с небольшим числом, например, 100). Или иногда несколько сообщений принимаются в виде одного сообщения, например:

Сообщение1 = а message2 = Защита

Received As = ABCDEF

Я пытаюсь более или менее повторить пример, показанный here , На данный момент сервер и клиент работают локально. Любые идеи о том, что проблема или о том, как улучшить метод тестирования?

Answer 1

Есть два открытых вопросов по проекту GitHub, которые звучат похоже:

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

Один из комментаторов сообщили лучше удачи с Fleck

Answer 2

TCP - это протокол потоковой передачи, а не протокол, ориентированный на сообщения. Это означает, что приемник отвечает за , находя начало/конец каждого сообщения, содержащегося в потоке. Это также означает, что приемник несет ответственность не только за разрывание больших чтений в отдельные сообщения, но иногда ему также необходимо собирать . читает до получения полного сообщения. Представленные примерные сообщения показывают, что два отправлены и TWO были получены, но, видимо, ваш сервер не может определить, где заканчивается одно сообщение, а другое начинается. Вероятно, вам нужно добавить какой-то внутренний протокол с вашими данными, чтобы отметить начало и конец каждого сообщения. Если ваши сообщения всегда имеют одинаковую длину, вы можете просто работать с размером, но это менее надежно и потенциально трудно переносить надежно на другие методы коммуникации (если это когда-либо понадобится позже в жизни программы - то, что почти всегда происходит для меня!)

Если ваши сообщения имеют одинаковую длину, ресивер обычно может ограничить размер чтения (я не знаю вашу библиотеку) до такой длины, чтобы отделить большие чтения не нужно. ОДНАКО, small чтение может по-прежнему возникать из-за того, как стек TCP/IP может собирать данные из потока в пакеты для передачи по физической сети. Если вы не хотите писать код коллекции, вам необходимо найти функцию peek, которая сообщит вам, сколько данных доступно для чтения до, которое вы действительно выполняете, чтобы ваша программа могла ждать, пока она не появится менее всего для одного целого сообщения, готового для чтения.