Путаница с recvfrom () в дизайне протокола уровня приложения

Предположим, что используются Linux и UDP.

На справочной странице recvfrom говорится:

Вызовы приема обычно возвращают любые доступные данные в пределах запрошенной суммы, а не ждут получения всей запрошенной суммы.

Если это так, то весьма вероятно, что из сокета будут возвращены частичные данные протокола уровня приложения, даже если задано желаемое MAX_SIZE.

Следует ли сделать следующий вызов recvfrom?

С другой стороны, также возможно иметь больше данных, чем мне нужно, например два UDP-пакета в буфере сокета. Если в этом случае вызывается recvfrom(), вернет ли он их обоих (предположим, в MAX_SIZE)?

Я полагаю, что в начале каждого сообщения UDP должна быть некоторая информация о размере уровня протокола приложения, чтобы она не испортилась.


c protocols
person Figo    schedule 28.01.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я думаю, что вам нужна справочная страница эта. В нем указано, что лишние данные будут отброшены. Если есть два пакета, вызов recvfrom будет извлекать данные только из первого.

person Mark Wilkins    schedule 28.01.2010
comment
тогда как насчет последующего вызова recvfrom ()? Получит ли он второй, который уже существует в буфере, оставленном первым? - person Figo; 28.01.2010
comment
@Figo: Да, он возвращается по одному. - person Mark Wilkins; 28.01.2010

arrow_upward
1
arrow_downward

Что ж ... Я получил лучший ответ после поиска в Интернете:

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

Если бы вы использовали TCP-сокеты, возник бы другой сценарий ... TCP не имеет какой-либо "концепции" границ, поэтому вы просто читаете столько байтов, сколько хотите, и recv() вернет количество байтов равно MIN(bytes_in_buffer, bytes_solicited_by_your_call)

ССЫЛКА: http://www.developerweb.net/forum/archive/index.php/t-3396.html

person Figo    schedule 28.01.2010