Здравствуйте, reversecode, Вы писали:


R>изначально моя мысль была другая
R>если UDP используется для отправки какого то пакетированного потока
R>то
R>1) ловля пакетов recvfrom с разных потоков и закидывания в общую очередь (поток то отправлен один) — никак не ускорит
R>2) буфер для ловли может быть меньше чем самый большой кусок отправленного пакета,
R> и тогда мы ловим меньший кусок, выходим с recvfrom И ? другим потоком ловим оставшуюся часть ?
Мы не можем ловить меньшую или большую часть... Мы выбираем очередной пакет из пришедших.
Если он не влезает в буфер то мы теряем датаграмму полностью. Никакая Ось не будет выбирать из входящих датаграмм именно ту, что влезет в переданный recvfrom буфер.

R>в ту же тему куда свернули вы, допустим максимальный размер который ловим в юзермоде 65536 байт, почти 65 кил
R>mbuf если я не ошибаюсь 4096 байт, 4 килобайта
R>пришедшая дейтаграмма в 65536 байт,
R>и случайно не хватившей места в буфере (начала кластеры аллочить по 4к и не хватило, ну да всяко бывает в ОС)
R>вряд ли будет мочиться уже на принятой стороне (лишь предполагаю)
R>вариантов два, 1) замочит отдав юзеру ошибку(коварная ОС)
R>2) не мочить а отдать юзеру столько сколько пришло (дружелюбная ОС)

R>лезть смотреть хотя бы в линукс о том как вообще ведут себя в таких ситуациях ОС, не хочу
А стоит Потому, что Вы описали варианты мифического поведения, которого нет в POSIX-сокетах. По крайней мере я о таком поведении никогда не слышал. Может и есть какая-то опция, которая заставляет сокеты так работать, но по умолчанию они работаю по другому.

Если датаграмма не принята полностью на клиенте (т.е. она не заложена во входящий буфер сокета), recvfrom блокирует исполнение программы (если его не перевели в неблокирующий режим). И не будет ни первого ни второго варианта. Первого — клиент не получает ошибки о том, что какая-то датаграмма не влезла в буфер сокета из входящей сети. Второго — потому, что так UDP-сокеты не работают.

Здравствуйте, reversecode, Вы писали:


R>изначально моя мысль была другая
R>если UDP используется для отправки какого то пакетированного потока
R>то
R>1) ловля пакетов recvfrom с разных потоков и закидывания в общую очередь (поток то отправлен один) — никак не ускорит
R>2) буфер для ловли может быть меньше чем самый большой кусок отправленного пакета,
R> и тогда мы ловим меньший кусок, выходим с recvfrom И ? другим потоком ловим оставшуюся часть ?
Мы не можем ловить меньшую или большую часть... Мы выбираем очередную датаграмму из пришедших.
Если она не влезает в буфер то мы теряем датаграмму полностью. Никакая Ось не будет выбирать из входящих датаграмм именно ту, что влезет в переданный recvfrom буфер.

R>в ту же тему куда свернули вы, допустим максимальный размер который ловим в юзермоде 65536 байт, почти 65 кил
R>mbuf если я не ошибаюсь 4096 байт, 4 килобайта
Да не имеет отношение этот mbuf к буферу хранящему входящие датаграммы сокета...

R>пришедшая дейтаграмма в 65536 байт,
R>и случайно не хватившей места в буфере (начала кластеры аллочить по 4к и не хватило, ну да всяко бывает в ОС)
R>вряд ли будет мочиться уже на принятой стороне (лишь предполагаю)
R>вариантов два, 1) замочит отдав юзеру ошибку(коварная ОС)
R>2) не мочить а отдать юзеру столько сколько пришло (дружелюбная ОС)

R>лезть смотреть хотя бы в линукс о том как вообще ведут себя в таких ситуациях ОС, не хочу
А стоит Потому, что Вы описали варианты мифического поведения, которого нет в POSIX-сокетах. По крайней мере я о таком поведении никогда не слышал. Может и есть какая-то опция, которая заставляет сокеты так работать, но по умолчанию они работаю по другому.

Если датаграмма не принята полностью на клиенте (т.е. она не заложена во входящий буфер сокета), recvfrom блокирует исполнение программы (если его не перевели в неблокирующий режим). И не будет ни первого ни второго варианта. Первого — клиент не получает ошибки о том, что какая-то датаграмма не влезла в буфер сокета из входящей сети. Второго — потому, что так UDP-сокеты не работают.