Не читать данные из сокета очереди ввода

Question

У меня есть программный код на C ++ с использованием websocket. Серверная часть, которую я использую: recv (sSocket, szBufferTmp, 99990, 0) для получения данных от клиента Когда клиент отправляет данные с более высокой скоростью, чем может прочитать сервер, мой сервер блокируется функцией recv (), а данные все еще находятся в очереди ввода. Я использую recv (sSocket, szBufferTmp, 99990, MSG_PEEK), чтобы проверить и увидеть, что мои данные все еще находятся в очереди ввода. Почему recv (sSocket, szBufferTmp, 99990, 0) не может читать данные, а recv (sSocket, szBufferTmp, 99990, MSG_PEEK) возможен? И как я могу это исправить? Моя ошибка такая же, когда клиент отправляет сообщение 1,2,3. Сервер получения 1,2. Клиент посылает 4-> сервер получает 3. 5-> 4, ... Он задержал данные, все еще находящиеся во входной очереди. Я могу получить это с помощью "MSG_PEEK" Это мой код:

Client is JavaScript: 

> var m_cWebsocket = new WebSocket("Servername"); 
> if (m_cWebsocket == null) { return false; } 
> m_cWebsocket.onopen = onWebsocketOpen(m_cWebsocket); 
> m_cWebsocket.onmessage = onWebsocketMessage; 
> m_cWebsocket.onerror = onWebsocketError; 
> m_cWebsocket.onclose = onWebsocketError; 
> I using m_cWebsocket.send(strMsg) to send data. 

Сервер:

время (правда) { recv (sSocket, szBufferTmp, 99990, 0);
// recv (sSocket, szBufferTmp, 99990, MSG_PEEK); // какой-то процесс }

Answer 1

Должно быть так, что когда send () отправляет данные быстрее, чем recv () может прочитать, он будет блокировать send () , пока recv () сервера не очистит канал, а не recv ().

Таким образом, если ваш сервер блокирует recv после того, как клиент работает слишком быстро, то, вероятно, происходит следующее:

Client sending data too fast, but pipe not full yet. Server receiving data.
Pipe fills up. Server->recv getting data. Client->send blocking.
Server->recv gets all the data while Client->send is still blocking.
Pipe empties out. Server->recv blocks until pipe is full again.
    Client->send is still blocking, waiting for a signal to go check if the pipe is ready.

Однако вы сказали, что в вашей входной очереди еще есть данные. Вы не сказали, где реализовали упомянутый вами msg_peek, но при условии, что ваш инструментарий реализован правильно, возможно ли, что ваш буфер szBufferTmp заполнен, не очищается после его использования, и у вас есть логика, предотвращающая перезапись когда он заполнится?

Требуется больше данных, чтобы определить, так ли это. Нам нужно увидеть код вашего сервера и клиента, и не мешало бы включить код для вашего вызова через сокет, вызова getaddrinfo и вызовов bind / listen / accept / connect, просто чтобы убедиться, .