Кратко

  • MARS хранил и выдавал соответствие между группой уровня 3 и ATM-узлами кластера, однако прямо не участвовал в передаче multicast-данных.
  • Даже отправитель, не состоявший в группе, мог собрать полный ответ MARS_MULTI, а затем должен был создать собственный VC либо получить адрес MCS, за которым скрывалась дальнейшая рассылка.
  • Регистрация, полный ответ, добавленный leaf, непрерывный CSN и успешный вызов отправки фиксировали разные этапы. Ни один из них отдельно не доказывал доступность, доставку, личность, полномочия, QoS или безопасность.

В RFC 2022 роль MARS ограничена особенно ясной фразой: сервер не принимает участия в фактическом multicast уровня 3. Он вёл соответствия между адресом IP-группы и ATM-адресами, отвечал на запросы и сообщал об изменениях. Пакеты шли по соединениям, созданным конечными узлами.

Так соединялись две разные модели. IP multicast давал группе один адрес без установления соединения. ATM UNI требовал явно названных конечных точек и сигнализации. Отправитель сначала запрашивал текущий набор адресов, затем создавал point-to-multipoint VC и добавлял каждый адрес как leaf.

RFC 1112 позволял отправлять в группу без вступления в неё. Поэтому успешное разрешение адреса ничего не говорило о членстве источника.

Список становился целым только с последним фрагментом

Большой ответ разбивался на несколько MARS_MULTI. Признак x отмечал конец, а номер y позволял обнаружить разрыв. Без завершающей части и связной последовательности результат следовало отбросить и запросить снова. Один полученный фрагмент ещё не был картой.

Полная карта оставалась снимком момента. После неё начиналась отдельная сигнализация: добавление конкретного leaf могло завершиться неудачей и повторяться. RFC допускал передачу данных, пока некоторые листья ещё добавлялись. Рабочий корневой VC поэтому не означал, что подключены все предполагаемые получатели, а принятый вызов отправки не означал доставку приложению.

MCS скрывал продолжение пути

MARS мог вернуть адрес Multicast Server вместо адресов отдельных участников. Отправителю не требовалось различать обычный leaf и MCS; последовательность действий сохранялась. Но данные принимал и заново распределял MCS, а не MARS.

Такая прозрачность уменьшала сложность и наблюдаемость одновременно. Адрес сервера обозначал промежуточную точку передачи, но не список получателей за ней. Позднейший RFC 2149 исследовал архитектуры и координацию MCS; эти результаты нельзя считать обещанием RFC 2022.

Управляющие уведомления исправляли локальные каналы

Участники асинхронно получали MARS_JOIN и MARS_LEAVE через ClusterControlVC. Каждый отправитель менял листья своих VC. Если уходил последний leaf, канал закрывался, а следующий пакет запускал новую процедуру разрешения и построения.

Cluster Sequence Number помогал заметить возможный пропуск. MARS увеличивал CSN при каждой передаче в управляющем канале, даже без изменения базы. Скачок не раскрывал потерянное событие — он лишь требовал заново проверить все открытые групповые VC по свежим картам. Данные в это время могли продолжать идти.

Непрерывный CSN доказывал наблюдение упорядоченного потока управления, а не успех сигнализации, живучесть получателей или доставку.

Границы документа запрещают широкие выводы

RFC 2022 ограничивался одним MARS Cluster. Межкластерная маршрутизация и перенос QoS уровня 3 в свойства ATM остались за рамками. Координация резервного MARS, удаление неработающих членов и несколько MCS не получили полного решения. Безопасность не обсуждалась.

Поэтому каждое свидетельство имеет узкий смысл. Членство, завершённый ответ, leaf, MCS, последовательность и отправка не превращаются сами по себе в доказательство текущей доступности, сквозного состава группы, получения приложением, реальной личности, полномочий или безопасности.

Исторический урок RFC 2022 — справочник способен направлять построение пути, не становясь самим путём. Эти состояния можно согласовывать, но нельзя без потери смысла слить в один флаг доставки.

Источники