Кратко

  • RFC 2443 позволял нескольким ATM-серверам разрешения multicast обмениваться сведениями о клиентах и группах, но каждый клиент регистрировался только на одном сервере.
  • После двух подряд пропущенных обновлений состояния сервера остальные узлы должны были удалить полученные от него записи членства. Клиенту затем следовало зарегистрироваться на резервном сервере и снова войти в прежние группы.

Три одинаковых кэша — и молчащий источник

Представим три сервера MARS с одинаковой строкой: клиент состоит в multicast-группе. Совместная картина выглядит исправной. Затем сервер, который первым зарегистрировал клиента, перестаёт присылать очередное обновление записи перенаправления. У двух других остаются совпадающие записи, но RFC 2443 не считает такое совпадение доказательством того, что исходный сервер или связанный с ним клиент всё ещё работают. Если подряд не пришли два обновления, эти серверы обязаны удалить членство, полученное от этого источника.

В этом различии и заключался замысел. RFC 2022 описывал MARS — сервер разрешения multicast-адресов — как способ распределять сведения о соединениях и членстве сетевого уровня поверх ATM. В распределённой схеме каждый сервер внутри Logical IP Subnet (LIS) должен был отвечать о любой группе в этой подсети. Опубликованный в ноябре 1998 года как Experimental RFC документ RFC 2443 приспособил Server Cache Synchronization Protocol (SCSP) для репликации этих записей между серверами MARS.

Реплицировались записи, но не исходная привязка

SCSP задавал механизм синхронизации: серверы устанавливали соседство, выравнивали кэши, а затем распространяли обновления. RFC 2443 назначил для состояния MARS идентификатор протокола 0x0003, а границей группы серверов сделал LIS. После регистрации клиента сервер передавал запись и дальнейшие изменения членства соседям. Но клиент по-прежнему регистрировался только на одном сервере MARS и подключался через его Cluster Control Virtual Circuit или Server Control Virtual Circuit. Реплики расширяли общую видимость, не превращая одну исходную связь клиента в несколько независимых регистраций.

Сама репликация не решала и вопрос распределения идентификаторов. Каждому клиенту MARS требовался уникальный Cluster Member ID в пределах всего LIS. RFC 2443 предполагал отдельные диапазоны идентификаторов для каждого сервера; внешняя схема назначения допускалась, но оставалась за пределами документа. Синхронизация может одинаково воспроизвести конфликтующий идентификатор, но не создаёт орган, который гарантирует уникальность.

Heartbeat был правилом отзыва устаревшего знания

Каждый сервер должен был обновлять MARS Server Redirect Entry не реже одного раза в две минуты; рекомендовался интервал в одну минуту. Если сосед пропускал два последовательных обновления от одного сервера, он должен был очистить все сведения о клиентах и группах, полученные от этого источника. Это было не просто обновление списка резервных серверов: действительность информации связывалась с конкретным источником, а удаление ограничивалось зависимыми от него данными.

Дальнейшее восстановление зависело от самого клиента. Обнаружив отказ своего MARS, клиент выбирал резервный сервер и пытался зарегистрироваться. Только после успешной регистрации он возвращался в прежние группы. Если попытка не удавалась, клиент пробовал следующий сервер. Карта перенаправления показывала возможные точки входа, но не доказывала, что конкретный клиент уже переехал, зарегистрировался, восстановил членство или снова получает multicast.

И восстановленная запись членства не подтверждает, что ATM-соединение «точка — много точек» построено или что пакеты достигли приложения. Это отдельные операционные переходы. В работающей сети строка реплицированного control plane — лишь вход для следующего действия, а не квитанция о его успехе.

Аутентификация ограничила вход, но расширила радиус доверия

RFC 2443 не шифровал специфичные для MARS поля записи состояния кэша и ссылался на базовые средства безопасности общего слоя SCSP. Аутентификация могла отбрасывать неподтверждённые пакеты. Однако RFC прямо указывал и обратную сторону: сведения от любого корректно аутентифицированного сервера считались доверенными и распространялись по всей группе. Компрометация одного такого сервера могла повредить общую базу изнутри. Аутентификация ограничивала круг отправителей, но не гарантировала истинность их данных и не локализовала последствия взлома узла.

В 2004 году RFC 3790 отмечал, что RFC 2443 задаёт значения по умолчанию для IPv4 и может быть расширен на IPv6 с подходящими определениями IANA. Это зафиксированное намерение, а не свидетельство реализации или распространения. RFC описывает требования и предостережения, но не доказывает, как часто система работала и соблюдали ли правила все реализации.

Поэтому главный урок — не просто «репликация повышает доступность». Важно знать, кто создал каждую запись, когда источник в последний раз наблюдали живым, какие данные следует признать недействительными после истечения этого подтверждения и кто выполнит следующий шаг. Отдельно проверяются регистрация, возврат в группы, построение соединения, пересылка пакетов и приём приложением. Три кэша могут совпасть в описании прошлого. О возвращении multicast-сервиса говорят только активный клиент и действительно работающий тракт данных.

Источники