( = колву ядер), в каждом треде слушать udp сокет (т.е. recvfrom). Сокет, конечно, един для всех тредов.
Другой вариант - слушать и отправлять все в одном треде, а сообщения распределять по воркерам.
Второй вариант выглядит сложнее, и непонятно, почему вообще его стоило бы использовать.
Неясно, где могут быть подводные камни в первом варианте - может я упускаю какие-то возможные задержки, создаваемые параллельными вызовами recvfrom или что-то в этом роде? Как быть?
ось какая?
допустим, линупс
io_uring
а чем плох более простой уже описанный вариант?
для простого варианта сгодится, для high-perf не очень
делай как проще
у тебя как первый вариант вообще будет работать? ты же в каждом треде рандомный пакет будешь получать. если у тебя будет для remote ip какой-то контекст, то это и будет бутылочным горлышком. если контекст будет вычисляться по содержимому пакета, то второй вариант будет медленнее, т.к. распределитель будет этот контекст искать. вообще, ещё про первый вариант не очень понятно со стороны ОС поведение. есть ли в Линуксе гарантия, что ты не будешь, например, в один поток все пакеты получать?
последние два параметра в recvfrom достают в отдельную структуру инфу об адресе откуда пришла датаграмма
а что предлагаешь? с нескольких сокетов можно слушать один порт разве?
ну я второй вариант всегда использовал. даже больше скажу, работал с высоконагруженными системами, где нужно было 10 ГБ/сек. обрабатывать. там тоже был один поток читающий на интерфейсе, который распределял по потокам трафик.
Как по мне, сыровато ещё для прода. Хотя технология интересная.
Да уже нет, больше 2 лет прошло. Во многих местах уже юзается
Обсуждают сегодня