Определите, остались ли Данные в сокете, и отбросьте их. - PullRequest
0 голосов
/ 04 августа 2011

Я пишу интерфейс под Linux, который получает данные из сокета TCP.Пользователь предоставляет буфер, в котором хранятся полученные данные.Если предоставленный буфер слишком мал, я просто хочу вернуть сообщение об ошибке.Первая проблема состоит в том, чтобы определить, был ли буфер малым.Функция recv () просто возвращает мне количество байтов, фактически записанных в буфер.Если я использую флаг MSG_TRUNC, указанный на странице руководства recv (), он все равно возвращает мне то же самое.Вторая проблема - сбросить данные, все еще находящиеся в очереди в сокете.Поэтому, если я решу, что мой предоставленный буфер был маленьким, я просто хочу стереть все, что осталось в сокете.Есть ли другие способы сделать это, кроме как снова закрывать и открывать сокет или просто получать, пока ничего не останется?С наилучшими пожеланиями

Тоби

1 Ответ

1 голос
/ 04 августа 2011

Как указано в справочной странице, MSG_TRUNC действителен только для сокетов пакетов (например, UDP), поэтому он не будет работать так, как вы хотите для вашего сокета TCP, основанного на потоке.Буквально сотни постов в stackoverflow и в других местах говорят о сохранении границ сообщений приложений в TCP (подсказка: вам нужно сделать это самостоятельно, TCP - это интерфейс потока байтов, а не), поэтому я не буду вдаваться в подробности здесьДостаточно сказать, что вам нужен механизм, чтобы знать, насколько велико «сообщение» или «пакет» приложения на стороне recv (), чтобы позволить вам делать то, что вы хотите через TCP (или вам нужно переключиться на UDP).

Для TCP, если вам нужно «истощить» сокет, чтение до тех пор, пока не останется данных, будет работать, однако, опять же, вам нужно учитывать границы сообщений, как упомянуто выше, чтобы вы не читали черезодно «сообщение» и начало переходить к следующему (опять же, самое важное, что следует помнить, это то, что TCP предоставляет интерфейс потока байтов и не обязательно сохранит вашу концепцию пакетов или сообщений уровня приложения).

...