UDP ориентирован на сообщения, а не на поток, как TCP.
В UDP только способ, которым recv()
вернул бы 8 байтов, если либо:
Вы устанавливаете для параметра len
значение > 8
, и принимается датаграмма, содержащая ровно 8 байтов.
вы устанавливаете для параметра len
значение == 8
, и принимается дейтаграмма, содержащая более 8 байтов.
Учитывая ваше утверждение, что вы устанавливаете len
на 1500, единственная возможность состоит в том, что полученная дейтаграмма содержит только 8 байтов, а не 299 байтов, как вы заявляете.
В отличие от TCP, в UDP вы не можете читать дейтаграммы по частям, чтение - это операция «все или ничего» (если вы не просматриваете данные, которые вы не делаете). В UDP recv()
/ recvfrom()
считывает целые дейтаграммы за раз, и если предоставленный буфер слишком мал для приема данных (чего в данном случае нет), то сообщается об ошибке WSAEMSGSIZE
, и данные усеченный, отбрасывая остальные данные, которые не помещаются в буфер.
Нулевые байты 00
, которые вы описываете, не оказывают никакого влияния на способность recv()
/ recvfrom()
читать всю дейтаграмму. Дейтаграмма имеет длину полезной нагрузки, и recv()
/ recvfrom()
будет считывать до этой длины полезной нагрузки или указанного размера буфера, в зависимости от того, что меньше, независимо от фактического содержимого полезной нагрузки.
Так что, скорее всего, в вашем коде recv()
просто не получает дейтаграмму, которую вы ожидаете.
Например, чтобы вообще использовать recv()
в UDP, необходимо сначала connect()
сокет UDP связать его с конкретным одноранговым IP / портом, что позволит recv()
игнорировать входящие дейтаграммы от других одноранговых узлов. (и для send()
для отправки дейтаграмм конкретному узлу). Может быть, вы connect
'выводите свой сокет UDP не к тому узлу и, таким образом, читаете дейтаграммы, предназначенные для чего-то другого. Или, может быть, вы connect
обращаетесь к правильному узлу, и он действительно отправляет 8-байтовую дейтаграмму, которую вы не ожидаете.
Так как вы не предоставили никакой контекстной информации о вашей настройке, участвующем узле, протоколе, перехвате Wireshark, ничего, здесь действительно никто не сможет с уверенностью диагностировать вашу ситуацию , Но то, что я описал выше, объясняет описанный вами симптом. Если вы считаете, что это не так, вам нужно отредактировать свой вопрос, чтобы предоставить более подробную информацию.