UDP одноадресный: два процесса прослушивания на одном и том же порту udp; только один прием пакетов

Назначение: для приема одноадресных пакетов UDP, отправленных в один порт в двух разных процессах.UDP одноадресный: два процесса прослушивания на одном и том же порту udp; только один прием пакетов

система: Linux, язык: C

Я могу связать два разъема в двух разных процессов к одному порту, используя SO_REUSEADDR. Но, как и ожидалось, пакеты принимаются только в одном (один из них позже).

Возможно ли получать пакеты в обоих процессах? Если нет, то как tcpdump способен читать, но не потреблять пакеты.

источник

2012-03-15 epandit

Что вам нужно? Проверять датаграммы? → используйте гнездо AF_PACKET или libpcap. Выполнять обработку и отправлять ответы? → использовать многоадресную рассылку. Чтобы выполнить некоторую балансировку нагрузки? → используйте некоторый прокси-маршрутизатор с балансировкой нагрузки. – ninjalj

Почему одноадресная рассылка? Это именно то, для чего нужна многоадресная рассылка.

Чтобы ответить вам второй вопрос - tcpdump получает копию каждого пакета он прослушивает через что-то под названием bpf, и что должно быть явно поддерживается драйвером сетевой карты.

источник

2012-03-15 14:19:01

'tcpdump' получает пакеты через« кран », размещаемый путем открытия сокета AF_PACKET (или эквивалентного), который подключается чуть выше драйверов сетевых карт (IIRC в' netif_rx' на Linux). Вы можете поместить фильтр BPF поверх этого сокета для фильтрации интересующих вас фреймов/датаграмм. – ninjalj

Да, я Linux отличается от традиционного мира BSD. Спасибо за комментарий. –

re "копия каждого пакета, который он прослушивает через что-то, называемое bpf", должна читать "копию каждого пакета, который он прослушивает, через нечто, называемое [слоем 2 AF_PACKET сокета]" –

Это невозможно с помощью API сокетов, а tcpdump выбирает пакеты прямо из сетевого интерфейса перед обработкой TCP/IP.

Ваш единственный шанс получить пакеты в одном процессе и отправить их другому.

источник

2012-03-15 14:00:17 blaze

Это в основном правда, хотя в прошлом были некоторые ОС (похоже, что Solaris приходит на ум, хотя я могу ошибаться), что позволило нескольким процессам открывать и читать один и тот же TCP-порт (и, я полагаю, UDP-порт) и читать. Это была дешевая полупрозрачная форма балансировки нагрузки, которая на практике не всегда хорошо работала. К OP: вы должны пересмотреть дизайн своего приложения, если считаете, что вам это нужно. Хотя я признаю, что, вероятно, существуют законные способы использования того, что вы описываете, гораздо более вероятно, что вы идете по неправильному пути. –

Это было действительно возможно, но каждое TCP-соединение было прочитано только одним процессом, который сначала принимал() его. OP хочет дважды прочитать те же данные из двух сокетов. Увы, не могу. – blaze

Если вы открываете сокет, связываете, слушаете, а затем выполняете форк(), входящие запросы на соединение будут передаваться каждый раз произвольно выбранному, одному из этих процессов (я никогда не потрудился выяснить стратегия, которую использует Linux, потому что она хорошо балансирует нагрузку).

В настоящее время я тестирую такое же поведение с UDP-сервером.

источник

2012-12-28 22:44:25

UDP одноадресный: два процесса прослушивания на одном и том же порту udp; только один прием пакетов

ответ

Смежные вопросы