DTF>Не будет ли так, что один кусок датаграммы уйдет в один поток, а другой кусок — в другой поток?
да так и будет
куда читаете туда и уйдет
какой вообще смысл использовать recvfrom на одном сокете с разных потоков ?
как вы потом те данные клеить будете ?
вообще нужно уточнять винда или юникс, у них все по разному устроено
Здравствуйте, DTF, Вы писали:
DTF>Коллеги, привет. DTF>Подскажите, пожалуйста, можно ли из нескольких потоков читать данные из одного и того же UDP-сокета?
Можно, будет работать безопасно. Но не очень быстро, так как блокировки в ядре будут съедать время.
В Линуксе более правильно в каждом потоке создать свой сокет с SO_REUSEPORT и повесить их на один и тот же порт. Ядро будет пытаться отправить потоки пакетов в детерминированные сокеты в зависимости от тройки получатель/отправитель/порт: https://lwn.net/Articles/542629/
Здравствуйте, DTF, Вы писали:
DTF>И какую документацию можно на эту тему почитать?
Про сокеты...
DTF>Но что будет с данными, которые они читают?
Вернется очередная датаграмма (если влезет во входной буфер)
DTF>Не будет ли так, что один кусок датаграммы уйдет в один поток, а другой кусок — в другой поток?
Протокол UDP не бьет датаграммы на части.
Здравствуйте, reversecode, Вы писали:
R>нет никакой гарантии что recvfrom вернет вам 100% полный кусок R>причин может +10500 R>внутри ОС дейтаграмма бьется на мелкие буферы mbuf
Это внутренние проблемы ОС. recvfrom() из датаграмного сокета делает одно из двух: либо вычитывает одну целую датаграмму, либо возвращает ошибку. Датаграмма никогда не бьется между двумя последовательными recvfrom()
Здравствуйте, Teolog, Вы писали:
T>Можно, но глупо. Лучше читать в одном и распределять по потокам, как положено.
Нет, не глупо. На 10ГБ будет более миллиона пакетов в секунду, один поток не справится. Просто умрёт на переключениях контекстов.
Далее, сетевые карты в нынешний момент имеют несколько аппаратных очередей. В случае нескольких слушающих сокетов в разных потоках/процессах всё получается просто — очереди равномерно распределяться между ними. В fastpath'е в ядре там нынче даже нет никаких глобальных блокировок.
DTF>>Не будет ли так, что один кусок датаграммы уйдет в один поток, а другой кусок — в другой поток? R>да так и будет
Не вводите в заблуждение. Датаграммы не бьются на части.
Здравствуйте, reversecode, Вы писали:
DTF>>Не будет ли так, что один кусок датаграммы уйдет в один поток, а другой кусок — в другой поток? R>да так и будет
Не так не будет. Вы вводите человека в заблуждение.
См.: IEEE Std 1003.1, 2004 Edition: For message-based sockets, such as SOCK_RAW, SOCK_DGRAM, and SOCK_SEQPACKET, the entire message shall be read in a single operation. man 2 socket: SOCK_DGRAM and SOCK_RAW sockets allow sending of datagrams to correspondents named in sendto(2) calls. Datagrams are generally received with recvfrom(2), which returns the next datagram along with the address of its sender. MSDN: recvfrom function: The recvfrom function receives a datagram and stores the source address.
И дальнейшее апеллирование к mbuf в корне неверно. R>куда читаете туда и уйдет R>какой вообще смысл использовать recvfrom на одном сокете с разных потоков ? R>как вы потом те данные клеить будете ?
Если дейтаграмы можно обрабатывать параллельно, то всё это приемлемо масштабируется.
R>вообще нужно уточнять винда или юникс, у них все по разному устроено
Логика работы того API что скопировали у BSD у них отличается разве что в shutdown/close. Всё остальное поразительно идентично.
R>я в буферах не путаюсь, это вы запутались о каких буферах я каждый раз говорю
Я с самого начала говорил про то, что или копируется в буфер recvfrom или отбрасывается. Вы приплели какие-то mbuf и прочее...
А когда Вы зашли в Гугл прочитали про то, что я сказал опять не поняли, про какой буфер идет речь...
R>в контексте кернел буфера, я имел ввиду уже распаковку данных дейтаграммы для подготовки в буфер откуда уже данные уйдут юзер левел
Я Вам уже указывал, что на каждом уровне свои буферы... И на каждом уровне свои правила. И с самого начала я говорил про правила работы функции recvfrom
R>понятно что если не хватило памяти или ошибка на езернет или айпи уровне то юзеру что то та говорить смысла нет, все в тихую мочится
Вот только к вопросу автора темы это не имеет отношения от слова совсем
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, reversecode, Вы писали:
R>>я в буферах не путаюсь, это вы запутались о каких буферах я каждый раз говорю N_C>Я с самого начала говорил про то, что или копируется в буфер recvfrom или отбрасывается. Вы приплели какие-то mbuf и прочее... N_C>А когда Вы зашли в Гугл прочитали про то, что я сказал опять не поняли, про какой буфер идет речь...
вашими словами это выглядит как если буфер в который читаем будет меньше — то отбросится
что уже заставило сомневаться
не отбрасывается, а читается размером с буфер, а остальная часть отбрасывается
про mbuf были просто развитие темы в которую вы начали тянуть))
Коллеги, привет.
Подскажите, пожалуйста, можно ли из нескольких потоков читать данные из одного и того же UDP-сокета?
Будут ли данные потеряны и/или повреждены?
И какую документацию можно на эту тему почитать?
Я смог нагуглить, что recv/recvfrom являются потокобезопасными, т.е. их можно вызывать одновременно.
Но что будет с данными, которые они читают?
Не будет ли так, что один кусок датаграммы уйдет в один поток, а другой кусок — в другой поток?
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Про сокеты...
Это понятно... но в статьях, которые я нагуглил, про это подробно не расписано.
МОжно ссылку на конкретное место в документации?
N_C>Вернется очередная датаграмма (если влезет во входной буфер)
А если не влезет? Остаток будет отброшен или попадет в другой recv?
N_C>Протокол UDP не бьет датаграммы на части.
Так и вопрос-то не про сетевой протокол UDP, а про API, через который данные читаются.
Здравствуйте, DTF, Вы писали:
N_C>>Про сокеты... DTF>Это понятно... но в статьях, которые я нагуглил, про это подробно не расписано. DTF>МОжно ссылку на конкретное место в документации?
Я привык ориентироваться на MSDN... Там есть обширная глава Windows Sockets...
N_C>>Вернется очередная датаграмма (если влезет во входной буфер) DTF>А если не влезет? Остаток будет отброшен или попадет в другой recv?
В никсах не силен, а в Windows по умолчанию копируется максимально возможное количество, остальное отбрасывается, т.е. теряется навсегда. Понятное дело, что при этом генерится ошибка — переполнение буфера.
N_C>>Протокол UDP не бьет датаграммы на части. DTF>Так и вопрос-то не про сетевой протокол UDP, а про API, через который данные читаются.
Есть две парадигмы — датаграммы и потоки. API сокетов работает в этих парадигмах.
N_C>>Не вводите в заблуждение. Датаграммы не бьются на части. R>нет никакой гарантии что recvfrom вернет вам 100% полный кусок
Есть. Если датаграмма не получена полностью, recvfrom не вернет вам ничего. В этом и отличие датаграмм-парадигмы от потоков TCP.
R>причин может +10500 R>внутри ОС дейтаграмма бьется на мелкие буферы mbuf
Э... UDP-датаграмма бьется на IP-датаграммы, которые, в свою очередь, бьются на Ethernet-фреймы... TCP, кстати, тоже бьется.
И что, это как-то меняет парадигму датаграмм и потоков?
изначально моя мысль была другая
если UDP используется для отправки какого то пакетированного потока
то
1) ловля пакетов recvfrom с разных потоков и закидывания в общую очередь (поток то отправлен один) — никак не ускорит
2) буфер для ловли может быть меньше чем самый большой кусок отправленного пакета,
и тогда мы ловим меньший кусок, выходим с recvfrom И ? другим потоком ловим оставшуюся часть ?
в ту же тему куда свернули вы, допустим максимальный размер который ловим в юзермоде 65536 байт, почти 65 кил
mbuf если я не ошибаюсь 4096 байт, 4 килобайта
пришедшая дейтаграмма в 65536 байт,
и случайно не хватившей места в буфере (начала кластеры аллочить по 4к и не хватило, ну да всяко бывает в ОС)
вряд ли будет мочиться уже на принятой стороне (лишь предполагаю)
вариантов два, 1) замочит отдав юзеру ошибку(коварная ОС)
2) не мочить а отдать юзеру столько сколько пришло (дружелюбная ОС)
лезть смотреть хотя бы в линукс о том как вообще ведут себя в таких ситуациях ОС, не хочу
в никсах они не iocp
а в винде posix лежит сверху iocp насколько я знаю, т.е. емуляция
автор не уточнил какая ос и какие функции
но с IOCP есть мысли что будет работать все по другому, ну т.е. там винда сама все по потокам раскидает
вообще еще в никсах есть recvmsg, так что может есть смысл с ими поиграться для ловли большего числа буферов
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-сокеты не работают.
R>в никсах они не iocp R>а в винде posix лежит сверху iocp насколько я знаю, т.е. емуляция
А какая разница? recvfrom где где, а на Винде уж точно работает именно так, как я написал.
R>автор не уточнил какая ос и какие функции R>но с IOCP есть мысли что будет работать все по другому, ну т.е. там винда сама все по потокам раскидает
recvfrom — это POSIX вроде как...
R>вообще еще в никсах есть recvmsg, так что может есть смысл с ими поиграться для ловли большего числа буферов
Каких буферов, извините? Есть входящий буфер сокета и туда складываются датаграммы. Их не одна, не две а много...
N_C>Мы не можем ловить меньшую или большую часть... Мы выбираем очередную датаграмму из пришедших. N_C>Если она не влезает в буфер то мы теряем датаграмму полностью. Никакая Ось не будет выбирать из входящих датаграмм именно ту, что влезет в переданный recvfrom буфер.
ок. заставили старичка залезть в гугл
гугл говорит что если дейтаграмма больше чем буфер, то в буфер попадает то что влезает, остальное отбрасывается
N_C>А стоит Потому, что Вы описали варианты мифического поведения, которого нет в POSIX-сокетах. По крайней мере я о таком поведении никогда не слышал. Может и есть какая-то опция, которая заставляет сокеты так работать, но по умолчанию они работаю по другому.
N_C>Если датаграмма не принята полностью на клиенте (т.е. она не заложена во входящий буфер сокета), recvfrom блокирует исполнение программы (если его не перевели в неблокирующий режим). И не будет ни первого ни второго варианта. Первого — клиент не получает ошибки о том, что какая-то датаграмма не влезла в буфер сокета из входящей сети. Второго — потому, что так UDP-сокеты не работают.
мочить дейтаграмму уже на клиенте из за того что проблемы с памятью не комильфо
вот лень мне лезть в ядра юникса что бы увидеть как они поступают
Здравствуйте, reversecode, Вы писали:
N_C>>Мы не можем ловить меньшую или большую часть... Мы выбираем очередную датаграмму из пришедших. N_C>>Если она не влезает в буфер то мы теряем датаграмму полностью. Никакая Ось не будет выбирать из входящих датаграмм именно ту, что влезет в переданный recvfrom буфер.
R>ок. заставили старичка залезть в гугл R>гугл говорит что если дейтаграмма больше чем буфер, то в буфер попадает то что влезает, остальное отбрасывается
Ну так а я о чем? Только это буфер, который Вы передали в recvfrom...
По-моему Вы путаетесь в буферах... А их там много — на каждом уровне свои. Ethernet, IP, UDP, SOCKET...
И на каждом уровне датаграмма (или что-то иное) своя. И пока на очередном уровне не будет принята полностью датаграмма вышележащего уровня она не поднимается вверх.
Здравствуйте, m2l, Вы писали:
m2l>Здравствуйте, reversecode, Вы писали:
DTF>>>Не будет ли так, что один кусок датаграммы уйдет в один поток, а другой кусок — в другой поток? R>>да так и будет m2l>Не так не будет. Вы вводите человека в заблуждение. m2l>См.: m2l>IEEE Std 1003.1, 2004 Edition: For message-based sockets, such as SOCK_RAW, SOCK_DGRAM, and SOCK_SEQPACKET, the entire message shall be read in a single operation. m2l>man 2 socket: SOCK_DGRAM and SOCK_RAW sockets allow sending of datagrams to correspondents named in sendto(2) calls. Datagrams are generally received with recvfrom(2), which returns the next datagram along with the address of its sender. m2l>MSDN: recvfrom function: The recvfrom function receives a datagram and stores the source address.
уже ниже по теме разобрались
m2l>И дальнейшее апеллирование к mbuf в корне неверно. R>>куда читаете туда и уйдет R>>какой вообще смысл использовать recvfrom на одном сокете с разных потоков ? R>>как вы потом те данные клеить будете ? m2l>Если дейтаграмы можно обрабатывать параллельно, то всё это приемлемо масштабируется.
треад сейф еще не означает что два потока могут вызвать recvfrom и сразу получить по дейтаграмме
R>>вообще нужно уточнять винда или юникс, у них все по разному устроено m2l>Логика работы того API что скопировали у BSD у них отличается разве что в shutdown/close. Всё остальное поразительно идентично.
Здравствуйте, reversecode, Вы писали:
R>треад сейф еще не означает что два потока могут вызвать recvfrom и сразу получить по дейтаграмме
Потокобезопасность не гарантирует наличия данных... Это как бы из разной оперы вещи...
R>я про IOCP а не про обмазанный posix сверху
А библиотека SOCKETS работает на уровне POSIX
N_C>Ну так а я о чем? Только это буфер, который Вы передали в recvfrom... N_C>По-моему Вы путаетесь в буферах... А их там много — на каждом уровне свои. Ethernet, IP, UDP, SOCKET... N_C>И на каждом уровне датаграмма (или что-то иное) своя. И пока на очередном уровне не будет принята полностью датаграмма вышележащего уровня она не поднимается вверх.
я в буферах не путаюсь, это вы запутались о каких буферах я каждый раз говорю
в контексте кернел буфера, я имел ввиду уже распаковку данных дейтаграммы для подготовки в буфер откуда уже данные уйдут юзер левел
понятно что если не хватило памяти или ошибка на езернет или айпи уровне то юзеру что то та говорить смысла нет, все в тихую мочится
Pzz>Это внутренние проблемы ОС. recvfrom() из датаграмного сокета делает одно из двух: либо вычитывает одну целую датаграмму, либо возвращает ошибку. Датаграмма никогда не бьется между двумя последовательными recииииvfrom()
читаем по теме, либо читает максимально заданный размер который ей сказали
а то в вашем случае она вернет ошибку, что в корне не верно
вообще мне ничего объяснять не надо, я с ядром на ты
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, reversecode, Вы писали:
R>>треад сейф еще не означает что два потока могут вызвать recvfrom и сразу получить по дейтаграмме N_C>Потокобезопасность не гарантирует наличия данных... Это как бы из разной оперы вещи...
я говорил о том что если один поток вошел в recvfrom, то второй может сидеть и ждать пока первый выйдет
в таком контексте вообще смысла нет по потокам раскидывать
R>>я про IOCP а не про обмазанный posix сверху N_C>А библиотека SOCKETS работает на уровне POSIX
а автор не уточнял какими сокетами он пользуется )) в винде есть они и IOCP
Здравствуйте, reversecode, Вы писали:
Pzz>>Это внутренние проблемы ОС. recvfrom() из датаграмного сокета делает одно из двух: либо вычитывает одну целую датаграмму, либо возвращает ошибку. Датаграмма никогда не бьется между двумя последовательными recииииvfrom()
R>читаем по теме, либо читает максимально заданный размер который ей сказали
Эту фразу понять нельзя
recvfrom никогда не бьет датаграмму между двумя своими вызовами. Конкретно для UDP и венда и unix, насколько я помню, если буфер слишком маленький, молча обрежут датаграмму. Для других типов датаграмных сокетов могут вместо этого и ошибку вернуть. Но на два read'а датаграмму не разрежут.
R>а то в вашем случае она вернет ошибку, что в корне не верно R>вообще мне ничего объяснять не надо, я с ядром на ты
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, reversecode, Вы писали:
R>>в никсах они не iocp R>>а в винде posix лежит сверху iocp насколько я знаю, т.е. емуляция N_C>А какая разница? recvfrom где где, а на Винде уж точно работает именно так, как я написал.
ну ? а я сказал о том что есть еще сокеты IOCP
автор не уточнял какие он использует, а я в первом ответе намекнул что если виндовые но не posix — то все может быть по другому
R>>автор не уточнил какая ос и какие функции R>>но с IOCP есть мысли что будет работать все по другому, ну т.е. там винда сама все по потокам раскидает N_C>recvfrom — это POSIX вроде как...
само собой
R>>вообще еще в никсах есть recvmsg, так что может есть смысл с ими поиграться для ловли большего числа буферов N_C>Каких буферов, извините? Есть входящий буфер сокета и туда складываются датаграммы. Их не одна, не две а много...
пользовательский буфер
если recvmsg позволяет сразу забирать по 5 дейтаграм, это лучше чем два потока будут пихаться в один recvfrom на одном сокете
R>читаем по теме, либо читает максимально заданный размер который ей сказали R>а то в вашем случае она вернет ошибку, что в корне не верно
Нет, не в корне... Она скопирует то, что можно и все-таки вернет ошибку.
R>вообще мне ничего объяснять не надо, я с ядром на ты
Зато с верхним API Сокетов Вы не очень разбираетесь, уж извините.
Здравствуйте, reversecode, Вы писали:
R>на два не бьет, уже давно разобрались R>но читать меньше чем было принято в сокет — можно, остальное отбросится навсегда(если верить гуглу)
Здравствуйте, reversecode, Вы писали:
R>а автор не уточнял какими сокетами он пользуется )) в винде есть они и IOCP
функция recvfrom относится к POSIX...
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, reversecode, Вы писали:
R>>а автор не уточнял какими сокетами он пользуется )) в винде есть они и IOCP N_C>функция recvfrom относится к POSIX...
я и не отрицал что она не posix
лучше скажите как с форума удалится с контентом, уже пол года прошу модераторов а они меня не отпускают
Здравствуйте, reversecode, Вы писали:
R>если recvmsg позволяет сразу забирать по 5 дейтаграм, это лучше чем два потока будут пихаться в один recvfrom на одном сокете
Вы с "параллельными" алгоритмами обработки данных знакомы? Забрать 5 сразу и потом их по очереди лопатить не всегда будет лучше, чем сделать в одном потоке забор по одной датаграмме и запустить столько потоков, сколько надо для скорости.
Почему Вы считаете, что поток только делает, что забирает датаграммы? он же их еще обработать должен. Вот, пока он обрабатывает можно и другим потоком читать.
Здравствуйте, DTF, Вы писали:
DTF>Коллеги, привет. DTF>Подскажите, пожалуйста, можно ли из нескольких потоков читать данные из одного и того же UDP-сокета? DTF>Будут ли данные потеряны и/или повреждены? DTF>И какую документацию можно на эту тему почитать?
DTF>Я смог нагуглить, что recv/recvfrom являются потокобезопасными, т.е. их можно вызывать одновременно. DTF>Но что будет с данными, которые они читают? DTF>Не будет ли так, что один кусок датаграммы уйдет в один поток, а другой кусок — в другой поток?
Можно, но глупо. Лучше читать в одном и распределять по потокам, как положено. Или создать несколько сокетов на одном порту и получать на каждый по копии датаграммы, можно даже в разных процессах. Вот только зачем все это? В скорость получения данных никогда ничего не упиралось, скорее в скорость передачи.
T>Вот только зачем все это? В скорость получения данных никогда ничего не упиралось, скорее в скорость передачи.
Вот изза таких взглядов и появляются потом такие темы
Здравствуйте, Sharov, Вы писали:
C>> Просто умрёт на переключениях контекстов. S>Каких, системных вызовов?
Их самых. Каждый recvfrom — переключение в ядро и обратно. Потом ещё полученные данные надо будет раскидать по потокам-обработчикам — ещё синхронизация.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
C>>> Просто умрёт на переключениях контекстов. S>>Каких, системных вызовов? C>Их самых. Каждый recvfrom — переключение в ядро и обратно. Потом ещё полученные данные надо будет раскидать по потокам-обработчикам — ещё синхронизация.
Передача-lock-free очередь, ноль синхронизации и переключений контекста. Можно балансировать количество обрабатывающих потоков по длине очереди вплоть от нуля до N.
Конечно, если не предполагается пилить на коленке зверский экскаватор данных для дата-центра,что было бы крайне череповато, то на всю эту чушь можно наплевать и передавать данные через эвент и std:queue с критической секцией одному рабочему потоку.
Здравствуйте, Teolog, Вы писали:
C>>Их самых. Каждый recvfrom — переключение в ядро и обратно. Потом ещё полученные данные надо будет раскидать по потокам-обработчикам — ещё синхронизация. T>Передача-lock-free очередь, ноль синхронизации и переключений контекста. Можно балансировать количество обрабатывающих потоков по длине очереди вплоть от нуля до N.
Lock-free требует атомарных операций, которые совсем недёшевы. Кроме того, они могут местами работать медленнее обычных блокировок, если есть конкурентные чтения/запись.
Методы борьбы с этим есть (см.: disruptor), но они добавят ещё тонну сложности.
T>Конечно, если не предполагается пилить на коленке зверский экскаватор данных для дата-центра,что было бы крайне череповато, то на всю эту чушь можно наплевать и передавать данные через эвент и std:queue с критической секцией одному рабочему потоку.
Это было бы так, если несколько слушающих сокетов требовали бы гигатонны кода 80-го уровня сложности. Но в данном случае такой код будет проще кода с отдельным потоком, раскидывающим сообщения.
Здравствуйте, Cyberax, Вы писали:
C>Lock-free требует атомарных операций, которые совсем недёшевы. Кроме того, они могут местами работать медленнее обычных блокировок, если есть конкурентные чтения/запись.
Дороговизна на железном уровне -- cache coherence и т.д. А так, вполне себе метод.
Здравствуйте, Nikolay_Ch, Вы писали:
R>>если recvmsg позволяет сразу забирать по 5 дейтаграм, это лучше чем два потока будут пихаться в один recvfrom на одном сокете N_C>Вы с "параллельными" алгоритмами обработки данных знакомы? Забрать 5 сразу и потом их по очереди лопатить не всегда будет лучше, чем сделать в одном потоке забор по одной датаграмме и запустить столько потоков, сколько надо для скорости. N_C>Почему Вы считаете, что поток только делает, что забирает датаграммы? он же их еще обработать должен. Вот, пока он обрабатывает можно и другим потоком читать.
Я как раз очень понимаю топик стартера, сами сталкивались, что поток "не успевал" читать данные через recvfrom в преаллоцированные буфера и ставить эти буфера в очередь на процессинг. После долгих изысканий перешли на нативные асинхронные сокеты (винда), в юниксах такой проблемы не было.
