[Multicast] Как направляются пакеты конечному получателю?

роутер - роутит.Вы где-то видели таблицу маршрутизации в которой используется «UDP-сокет»?

мультикаст это 3 и 2 уровени osi

Хорошо, в итоге этот пакет попадает без адреса порта назначения внутри пакета или с каким-то стандартным для мультикаст адресом. А дальше куда его ядро направит?

Приложение просит мультикаст сокет у ядра. Ядро шлет джойн в ту группу которую попросило прилодение. Свитч запоминает что с этого порта был джойнт в такую то группу. Роутер видит джойн и начинает подавать поток на MAC адрес/интерфейс соответствующий этой мультикаст группе. Когда поток этот попадает на свитч у которого включен igmp снупинг, свитч смотрит какие порты подписаны на этот поток( с каких был раньше джойн) и льет поток только на эти порты.

Если приложение запросит поток с портом не тем который в потоке, поток все равно будет лететь. Только приложение ничего не получит.

Время от времени, роутер если он является квериером шлет запросы ко всем хостам которые включены в мультикаст группу с целью определения их живости. В ответ на квери, ядро шлет igmp репорт.

Очевидно что если ядро выдало приложению сокет, то оно знает чего туда слать.

Я вообще плавно подвожу всё это к тому, что на самом деле согласованный между получателем и отправителем порт на стороне получателя слушает ОДНО приложение, его не могут слушать несколько приложений. Отсюда печальный немного вывод: на одном IP одну мультикаст-группу может слушать только ОДНО приложение.

И да, роутер не будет слать поток два раза.

Роутер-то может и не слать, но на стороне ядра можно было бы организовать igmp-proxy, который раздавал бы один и тот же пакет всем приложениям, на него подписанным. То есть получателем должно быть не тупое конечное приложение, а некий диспетчер, который бы раздал локально пакет всем, кто его «хотел».

мультикаст поток летит не на ваш IP, в пакете dstip = ip группы.

Хорошо, в итоге этот пакет попадает без адреса порта назначения внутри пакета или с каким-то стандартным для мультикаст адресом. А дальше куда его ядро направит?

в мультикаст трафик можно инкапсулировать не только tcp|udp, так что порты это частный случай, не смотрите на это однобоко (со стороны iptv)

что на самом деле согласованный между получателем и отправителем порт на стороне получателя слушает ОДНО приложение, его не могут слушать несколько приложений

бинго,само собой разумеется. от чего у rip v2 своя мультикаст группа, от чегу у ospf свои, от чего обычно различные каналы это обычно отдельная группа? Все вокруг этого и пляшет.

Ни что не мешает vlc подключиться в группу но слушать не тот порт, трафик все равно прилетит

Ни что не мешает vlc подключиться в группу но слушать не тот порт, трафик все равно прилетит

Что за, апростите, бред? VLC будет слушать один сокет, а трафик прилетит в другой

Ни что не мешает vlc подключиться в группу но слушать не тот порт, трафик все равно прилетит

Что за, апростите, бред? VLC будет слушать один сокет, а трафик прилетит в другой

простите, где ? речь о том что мультикаст трафик попадет на порт хоста который подключился в группу.

Ну да, попадёт, это очень хорошо. Вот только он попадёт приложению в сокет, а не ядру. И чтобы это приложение с кем-то ещё поделилось на этом же хосте... Ну, это довольно нетривиально будет... А как считаете, если нужно всё-таки нескольким приложениям на одной машине раскидать поток, igmp-proxy проблему решит? По мне, вроде не должен, он просто эмулирует поведение свитча.

ну так тебе это и надо, разве нет?

igmp-proxy проблему решит?

этот софт решает другую задачу и такое делать не должен. лучше всего проверить и расставить все точки

В итоге я компромиссно решил проблему, понасоздавав физическому адаптеру кучку алиасов. Если один мультикаст-клиент биндится к алиасу, а другой - к IP интерфейса или тоже к алиасу, всё отлично работает благодаря тому, что на разных IP стек «разветвляется» и один пакет с уровня 2 OSI попадает в несколько стеков 3-го уровня, по одному на IP.
С учётом того, что нам нужно было всего 2 приложения запускать параллельно, а этих алиасов можно насоздавать целую кучу - проблема решена.

мультикаст поток летит не на ваш IP, в пакете dstip = ip группы.

Кстати, весьма важное и полезное замечание. Это нужно не только понимать, это нужно обязательно увидеть снифером для закрепления эффекта. Большое спасибо Вам, ventilator!

BIND нужно делать с IN_ADDR_ANY
Обязательна опция сокета SO_REUSE_ADDR
Уже при подписке можно указывать один из IP-адресов того интерфейса, с которого подписываетесь

То есть:
BIND: IP=0.0.0.0, port=portN, option=SO_REUSE_ADDR
Подписка: SRC=Interface_IP