История изменений
Исправление firkax, (текущая версия) :
For UDP sockets, the use of this option can provide better distribution of incoming datagrams to multiple processes (or threads) as compared to the traditional technique of having multiple processes compete to receive datagrams on the same socket.
Если ты про это, то либо они сами что-то напутали, либо непонятно так выразились. Например, может быть имелось ввиду что можно забиндить для сокета на один локальный порт, но установить им разные адреса пиров (с помощью connect), тогда в зависимости от исходящего адреса на той стороне пакеты будут приходить в разные сокеты. Но прийти в два сокета одновременно udp не может. А где ты это описание прочитал?
Наверно придется открывать один порт и рассылать пакеты в разные потоки pipe-ми
Ну нафига? У тебя один процесс, общее адресное пространство, зачем городить ipc внутри одного процесса? Просто раскладывай пакеты в разные очереди.
А так то, как уже я тебе писал, и потом ещё раз повторили, можешь даже не рассылать ничего а просто делать свои MSG_PEEK из общего сокета. Сокет никак к треду не привязан. Но у этого способа есть два минуса:
1) если идут например сначала 10 пакетов для первого треда, а потом один для второго, то пока первый тред всё не разберёт - второй свой пакет не увидит
2) лишние recv(MSG_PEEK) без которых можно обойтись если читать пакет сразу до конца и уже самостоятельно класть нужному треду на обработку (не пайпами, это опять лишние сисколлы, а просто записью в fifo-список в памяти, со спинлоком (он юзерспейсный) для защиты от race.
Исправление firkax, :
For UDP sockets, the use of this option can provide better distribution of incoming datagrams to multiple processes (or threads) as compared to the traditional technique of having multiple processes compete to receive datagrams on the same socket.
Если ты про это, то либо они сами что-то напутали, либо непонятно так выразились. Например, может быть имелось ввиду что можно забиндить для сокета на один локальный порт, но установить им разные адреса пиров (с помощью connect), тогда в зависимости от исходящего адреса на той стороне пакеты будут приходить в разные сокеты. Но прийти в два сокета одновременно udp не может. А где ты это описание прочитал?
Наверно придется открывать один порт и рассылать пакеты в разные потоки pipe-ми
Ну нафига? У тебя один процесс, общее адресное пространство, зачем городить ipc внутри одного процесса? Просто раскладывай пакеты в разные очереди.
А так то, как уже я тебе писал, и потом ещё раз повторили, можешь даже не рассылать ничего а просто делать свои MSG_PEEK из общего сокета. Сокет никак к треду не привязан. Но у этого способа есть два минуса:
1) если идут например сначала 10 пакетов для первого треда, а потом один для второго, то пока первый тред всё не разберёт - второй свой пакет не увидит
2) лишние recv(MSG_PEEK) без которых можно обойтись если читать пакет сразу до конца и уже самостоятельно класть нужному треду на обработку (не пайпами, это опять лишние сисколлы), а просто записью в fifo-список в памяти, со спинлоком (он юзерспейсный) для защиты от race.
Исходная версия firkax, :
For UDP sockets, the use of this option can provide better distribution of incoming datagrams to multiple processes (or threads) as compared to the traditional technique of having multiple processes compete to receive datagrams on the same socket.
Если ты про это, то либо они сами что-то напутали, либо непонятно так выразились. Например, может быть имелось ввиду что можно забиндить для сокета на один локальный порт, но установить им разные адреса пиров (с помощью connect), тогда в зависимости от исходящего адреса на той стороне пакеты будут приходить в разные сокеты. Но прийти в два сокета одновременно udp не может. А где ты это описание прочитал?
Наверно придется открывать один порт и рассылать пакеты в разные потоки pipe-ми
Ну нафига? У тебя один процесс, общее адресное пространство, зачем городить ipc внутри одного процесса? Просто раскладывай пакеты в разные очереди.