Кратко

  • RFC 1112 сделал членство в multicast видимым через локальные запросы и отчёты, но случайные таймеры позволяли одному сообщению представлять всю группу, не перечисляя её участников.
  • В IGMPv1 не было сообщения о выходе: маршрутизатор узнавал, что ушёл последний получатель, лишь после прекращения отчётов и истечения таймера. RFC 2236 позднее добавил более быстрый сигнал выхода.

Адрес группы — не список приглашённых

IP-адрес multicast-группы мог быть постоянным, даже если в ней не было ни одного узла. Узел мог также отправлять пакеты группе, не вступая в неё. В RFC 1112 Stephen Deering разделил эти факты: адрес назначения указывал группу, а членство учитывалось отдельно для каждого узла и сетевого интерфейса. Приложение могло попросить IP вступить в группу или выйти из неё. Соседнему маршрутизатору требовалось другое: остался ли в этой локальной сети кто-то, кому нужна группа?

Стандарт описывал два уровня поддержки. Узел Level 1 мог отправлять multicast, но не вступал в группы и не реализовывал IGMP. Level 2 добавлял членство и протокол, сообщавший соседнему multicast-маршрутизатору о локальном интересе. Поэтому один адрес не показывал, кто получит пакет: требовался свежий сигнал от локального сегмента.

Почему первый отчёт не приходил один

Маршрутизатор отправлял Host Membership Query на адрес всех узлов 224.0.0.1. Каждый узел Level 2 проверял группы на интерфейсе, откуда пришёл запрос. Немедленный ответ всех создал бы всплеск одинаковых служебных пакетов. RFC 1112 назначал каждому членству случайный таймер задержки отчёта. Если до его срабатывания узел слышал корректный отчёт для той же группы, он отменял свой ожидающий ответ. Одного сообщения хватало, чтобы сообщить маршрутизатору: на локальной сети остался хотя бы один участник.

Это было сознательное сжатие информации. Маршрутизатор не получал число участников, список машин или доказательство готовности каждого приложения к приёму трафика. Он получал признак присутствия группы в одной локальной сети. Дубликатов становилось меньше, но исчезали сведения, не нужные для решения о пересылке.

При вступлении в новую группу действовало другое правило: узел должен был сообщить об этом сразу, поскольку мог оказаться первым в сети. Стандарт рекомендовал повторить отчёт один-два раза через короткую паузу на случай потери первого. Но multicast оставался best effort, как обычный IP unicast: никто не гарантировал целостную доставку всем участникам или одинаковый порядок пакетов. Сообщение о членстве уведомляло маршрутизатор, но не гарантировало доставку.

Молчание после ухода последнего получателя

IGMPv1 определил Query и Report, но не сообщение Leave Group. Когда узел выходил из группы, его локальный IP-модуль переставал учитывать членство; маршрутизатор немедленного уведомления не получал. Периодические запросы обновляли его знания. Если никто больше не сообщал о группе, таймер членства в конце концов истекал. Простота протокола оставляла состояние после ухода последнего получателя на некоторое время.

Маршрутизатор не ошибался навсегда: задержку ограничивали интервалы Query и таймер членства. Но для высокоскоростной группы или сегмента с частой сменой участников трафик мог продолжать поступать в сеть без получателей до истечения состояния.

RFC 2236 добавил в IGMPv2 сообщение Leave Group, чтобы ускорить уведомление. Узел-querier после него отправлял запросы для конкретной группы и ждал ответа, прежде чем объявить сегмент пустым. Это не превращало молчание в уверенность, а сокращало интервал неопределённости и проверяло, не осталось ли другого слушателя.

Компромисс 1989 года понятен. IGMPv1 сокращал служебный трафик, превратив членство в вопрос о присутствии. Один отчёт мог остановить ответы соседей и всё же оставить маршрутизатору достаточно данных, чтобы решать, пересылать ли группу в локальную сеть. Но он не раскрывал, сколько участников стояло за одним сообщением и когда ушёл последний.

Источники