Я использую TcpClient для подключения к простому эхо-серверу TCP. Сообщения состоят из размера сообщения в 4 байта, за которым следует само сообщение. Например, чтобы отправить сообщение «привет», сервер будет ожидать «0005hello» и ответить «0005hello». При тестировании под нагрузкой (примерно 300+ одновременных пользователей) смежные запросы иногда приводят к «скоплению» ответов, например, отправка «0004good» с последующим «0003day» может привести к тому, что клиент получит «0004good0003», а затем «day».
В обычном TCP-клиенте, не основанном на WebFlux, обычно можно прочитать первые 4 байта из сокета в буфер, определить длину сообщения N, а затем прочитать следующие N байтов из сокета в буфер перед возвратом ответа. Возможно ли достичь такого детального управления, возможно, используя базовый канал TcpClient?
Я также рассмотрел подход накопления ответов в некоторой структуре данных (Queue, StringBuffer, et c.) И наличия демон анализирует результат, но на практике это не дает желаемой производительности.