Рейтинг:0

Оставляет ли Windows автоматически неиспользуемые группы многоадресной рассылки?

флаг cg

При устранении неполадок многоадресной рассылки я не нашел ссылок на значение полей, возвращаемых этой командой:

C:\Users\Administrator>netsh int ip show joins level=verbose
    
 Интерфейс 5: Ethernet0
    
 Многоадресный адрес: 224.0.0.1
 Объем : 0
 Ссылки : 0
 Последний репортер? : Да
    
 Многоадресный адрес: 224.0.0.251
 Объем : 0
 Ссылки : 2
 Последний репортер? : Да
    
 Многоадресный адрес: 224.0.0.252
 Объем : 0
 Ссылки : 1
 Последний репортер? : Да

Что Объем, использованная литература и Последний репортер иметь в виду?

Наверное использованная литература означает количество процессов, прослушивающих эту конкретную группу многоадресной рассылки. В случае, если приложение останавливается/вылетает до выхода из многоадресной группы, которое оно использовало, это число обнуляется, но на самом деле оно не удаляется из списка, и машина продолжает получать многоадресный поток. Есть ли какие-либо настройки, предотвращающие это, например. через какое-то время мультикаст-группа перестает использоваться каким-либо процессом, ОС покидает ее автоматически?

Это происходит в Windows 10 и Windows Server 2019 с использованием (по умолчанию) IGMPv3.

Рейтинг:0
флаг cn

Формальное название для присоединения/отключения IGMP — отчет о членстве в IGMP. Восходящий маршрутизатор, работающий с протоколом IGMP в сети с множественным доступом, называется Querier. Он действительно периодически опрашивает все хосты (224.0.0.1) для их фактического статуса членства в группе.

Поскольку сеть с множественным доступом может быть довольно большой, это может вызвать поток отчетов о членстве IGMP, которые могут перегрузить сеть или сам Querier; учитывая природу многоадресной рассылки, на самом деле не имеет значения, сколько хостов в сети слушают конкретную группу, достаточно одного, чтобы продолжить потоковую передачу этой группы на интерфейсе.

В этом отношении при получении IGMP-запроса все хосты запускают случайный таймер, и первый из них, у которого истекает срок действия, отправляет свой отчет о членстве на 224.0.0.1, чтобы его могли услышать Запрашивающий и другие. Если хост узнает, что о его группах уже сообщалось, он отменяет таймер. Архитектура построена таким образом, что в большинстве случаев только несколько хостов действительно отвечают на запрос. Хост, который сообщил о группе во время этого процесса, называется последним отправителем отчета для этой группы.

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

Поскольку весь этот материал Query/Report отправляется асинхронно и ненадежно через многоадресную рассылку, существует ненулевая вероятность того, что этот конкретный запрос может не получить немедленный отчет из-за потери пакета или других проблем, поэтому маршрутизатор по умолчанию пытается отправить его. дважды (в течение двух интервалов запроса), и только затем группа многоадресной рассылки сокращается на интерфейсе, и поток трафика останавливается. То же самое применимо, если для стандартного запроса на членство (на 224.0.0.1) конкретная группа не получает ответ дважды, это может произойти из-за сбоя программного или аппаратного обеспечения до отправки отчета о выходе для группы.

Scope как таковой представляет собой область адресов многоадресной рассылки, которая уходит своими корнями во времена старой и славной мечты Global Internet Multicast Routing Dream и указывает область, в которой должна циркулировать эта группа, 0 означает локальную сеть в IPv4.

kuma avatar
флаг cg
_это может произойти, если программное или аппаратное обеспечение выйдет из строя до того, как будет отправлен отчет о выходе для группы_ я думаю, что в этом случае эта группа будет продолжать появляться в выводе `netsh int ip show join` с 0 ссылками и будет получена компьютер до выключения? Если да, то есть ли способ предотвратить это?
Peter Zhabin avatar
флаг cn
Эта группа будет собираться ядром и очищаться через некоторое время. Только что сделал быстрый тест - запустил свой клиент IPTV на ПК с Windows и запустил какой-то канал. Он появился в `netsh int ip show join` с двумя ссылками, так как у клиента есть два процесса. Затем я убил его огнем, то есть принудительно завершил с помощью `TerminateProcess`. Группа, о которой идет речь, показывалась с 0 ссылками примерно 10-15 секунд после этого, а затем полностью исчезала. Какую реальную проблему вы пытаетесь решить?
kuma avatar
флаг cg
рассматриваемая группа отображается с 0 ссылками, никогда не исчезает, и пакеты из этой многоадресной группы принимаются бесконечно. Видимо сборщик мусора не работает? Как это проверить?
Peter Zhabin avatar
флаг cn
В приведенном выше примере «224.0.0.1» — это «все хосты» и обрабатывается самим ядром, поэтому он имеет 0 ссылок, но никогда не исчезнет. Это может быть группа, которую вы ищете, что-то вроде этого, не могли бы вы быть более конкретным, то есть указать адрес группы и сценарий использования?
kuma avatar
флаг cg
мультикаст, о котором я говорю, не был захвачен на скриншоте. Это была многоадресная рассылка административного масштаба (например, 239.10.10.10). Мой сценарий очень похож на ваш предыдущий: запустил пользовательское приложение, которое присоединилось к группе многоадресной рассылки, затем я принудительно завершаю приложение, и рассматриваемая группа многоадресной рассылки отображается с 0 ссылками, никогда не исчезает, и пакеты из этой группы принимаются бесконечно. Я не понимаю, почему это происходит и почему то же самое с VLC (принудительное завершение приложения) приводит к немедленному исчезновению группы.

Ответить или комментировать

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