Максим Кульгин
cотрудник компании "Комплит" (Санкт-Петербург)

Открытость стека протоколов TCP/IP, его возможности поддержки локальных и глобальных сетей и сегодня способствуют росту его популярности. TCP/IP превратился в основное средство связи в локальных и глобальных сетях, а также доступа к Internet. Его применение выходит за традиционные рамки UNIX-систем, и он играет все более заметную роль в корпоративных сетях. Основные причины успеха стека протоколов TCP/IP - в доступности его спецификаций и открытости архитектуры. Неслучайно практически все разработчики операционных и сетевых систем включают поддержку TCP/IP в свои продукты.

Однако появление новой многообещающей технологии - режима асинхронной передачи (Asynchronous Transfer Mode, ATM) - грозит лишить стек протоколов TCP/IP его доминирующего положения.

Асинхронный режим передачи - это один из видов коммутации пакетов. В его основе лежит концепция ретрансляции трафика с использованием адреса получателя, содержащегося в самом пакете. Технология коммутации пакетов не нова; некоторые из ее реализаций применяются в глобальных сетях уже с 1970 года (например, X.25).

Прежние реализации имели тот недостаток, что пакеты могли содержать различный объем информации, что приводило к задержкам в сети.

Для устранения задержек и снижения накладных расходов при обработке размер пакетов было предложено сделать фиксированным.

В начале 1992 года этот подход оформился в новую технологию коммутации ячеек, названную ATM. Данная технология предполагает использование относительно коротких (53 байт) ячеек фиксированной длины для передачи информации как через частные сети, так и через сети общего пользования. Ее достоинством является возможность с высокой скоростью передавать большие объемы данных, в том числе аудио- и видеоинформацию.

АТМ существенно отличается от большинства технологий локальных сетей. Одно из важнейших отличий в том, что используемая стратегия передачи данных ориентирована на установление предварительного логического соединения между отправителем и получателем.

Стандарт на протокол TCP/IP был разработан достаточно давно, поэтому он уже не может удовлетворить современным требованиям, например, к передаче аудио- и видеоинформации в реальном времени, так как не имеет возможности резервировать требуемую для приложения часть пропускной способности сети.

Правила обработки информации в протоколе TCP/IP одинаковы для всех приложений, будь то электронная почта или видеоконференция, т. е. данные имеют одинаковый приоритет при обработке и передаются с одинаковой скоростью (хотя очевидно, что данные видеоконференции требуют "более пристального внимания"). Кроме того, важную роль играет тот факт, что пересылка пакетов осуществляется в случайном порядке, а это противоречит концепции передачи критичной к задержкам информации, при которой пакеты должны передаваться в строго определенной последовательности.

Технология ATM имеет значительные преимущества по сравнению с протоколом IP: благодаря ориентации на установление логического соединения между абонентами, она гарантирует эффективную и устойчивую работу, становясь идеальным решением для передачи по сети аудио- и видеоинформации. Протокол IP целесообразно поддерживать "поверх" ATM только в том случае, когда большинство компьютеров в организации не подключены напрямую к сети ATM. Такая ситуация будет иметь место еще достаточно долго, так как чаще всего ATM применяется для построения магистрали, связывающей отдельные локальные сети организации.

Поиском решения данных проблем занимаются рабочие группы IETF, но потребуется время для их нахождения и принятия стандартов. В любом случае протокол TCP/IP будет широко применяться в сетях на базе ATM.

СКОЛЬКО РОБКИХ ПОПЫТОК ПРОЯВИТЬ СМЕЛОСТЬ!

Для выработки стандартов, описывающих механизмы работы протокола IP в сетях ATM, была сформирована рабочая группа ION (Internetworking Over ATM) комитета IETF. Прежде всего она стандартизовала методы передачи пакетов сетевого уровня разных типов через соединения ATM, а также методы мультиплексирования этих пакетов при работе с одним соединением. Для успешной передачи пакетов различных типов через одно соединение получатель должен иметь возможность определить тип полученного пакета и кому он должен быть передан. Следовательно, пакет должен иметь префикс с необходимыми для демультиплексирования полями. Документ RFC 1483 (Multiprotocol Encapsulation over ATM Adaptation Layer 5) от июля 1993 года определяет два метода мультиплескирования и демультиплексирования пакетов.

При первом методе пакеты различных протоколов могут передаваться через одно соединение с добавлением к ним стандартного заголовка LLC/SNAP. Пакеты с таким заголовком инкапсулируются в кадры уровня адаптации ATM (AAL5). Рисунок 1 показывает общий механизм формирования и передачи пакетов протоколов сетевого уровня через виртуальное соединение.

Напомним, что уровень адаптации ATM является самым верхним в модели ATM (см. Рисунок 2). Этот уровень позволяет осуществлять передачу множества типов информации (голос, данные, видео).

Каждый тип трафика предъявляет собственные требования. При передаче голоса поток трафика должен быть постоянным; видеоинформация критична к временным характеристикам; передача данных обычно носит неравномерный характер и допускает доставку с некоторыми задержками.

Уровни адаптации ATM позволяют передавать трафик по сети с требуемыми характеристиками. Разным типам трафика соответствуют разные уровни адаптации (AAL1, AAL3/4, AAL5). Они классифицируются на основе требований, выдвигаемых к предоставляемым ресурсам сети (см. Таблица 1). Для передачи данных используется уровень адаптации AAL5.

Каждый уровень адаптации идентифицируется двумя основными параметрами: характером передачи и режимом соединения. Скорость передачи информации может быть постоянной или переменной, а режим работы - с установлением или без установления виртуального соединения.

ТАБЛИЦА 1 - Уровни адаптации ATM
Характеристика	AAL1	AAL3/4, AAL5
Временное согласование между отправителем и получателем	Требуется	Не требуется
Скорость передачи	Постоянная	Переменная
Режим соединения	С установлением соединения	С установлением соединения/без установления соединения
Тип трафика	Голос, видео	Данные
Класс	Класс A (голос) Класс B (видео)	Класс C и D (данные)

Помимо перечисленных в Таблице 1, не используемый теперь уровень адаптации AAL2 предназначался для поддержки передачи с переменной скоростью синхронного, чувствительного ко времени видеотрафика со сжатием. В настоящее время эта функция выполняется уровнем AAL3/4.

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

Режим с установлением соединения использует детерминированный метод доступа по типу телефонного вызова, когда соединение устанавливается после вызова и поддерживается до окончания разговора. Установление соединения осуществляется с помощью специальных ячеек, содержащих адресную информацию. Режим установления соединения используется уровнями AAL3/4 и AAL5 и работает совместно с протоколом эмуляции локальной сети.

Уровень адаптации состоит из двух подуровней: подуровня схождения (Convergence Sublayer, CS) и подуровня сегментации и сборки (Segmentation and Reassemble, SAR) (см. Рисунок 3).

Пользовательские данные, например файл, передаются с верхних уровней вниз до уровня адаптации ATM, а точнее, до подуровня CS, где разбиваются на кадры (блоки) переменной длины. Размер одного кадра не может превышать 64 Кбайт. К кадру добавляются поля с описанием его типа и размера. После этого кадр передается на нижний подуровень (SAR), где упаковывается в ячейки, передаваемые затем по сети.

Заголовок LLC/SNAP имеет длину 8 байт и состоит из трех полей: LLC (три байта), OUI (три байта) и PID (два байта) (см. Рисунок 4). Именно последнее поле служит для идентификации данных конкретных протоколов. Например, значение 0x0800 указывает на то, что передаются дейтаграммы протокола IP, значение 0x0806 - на служебное сообщение протокола ARP, и т. д. Полный список значений этого поля можно найти в документе RFC 1700.

Структура заголовка LLC/SNAP позволяет передавать данные разных протоколов сетевого уровня через одно виртуальное соединение, что уменьшает количество соединений, необходимых для работы в многопротокольных системах, хотя это сопряжено с дополнительными расходами в размере 8 байт на кадр уровня адаптации. Данный метод используется по умолчанию в классическом IP для ATM (см. ниже).

Второй метод, описанный в документе RFC 1483, называется мультиплексированием виртуальных соединений (multiplexing VC) или нулевой инкапсуляцией (Null encapsulation). При таком методе через соединение передаются данные только одного протокола сетевого уровня, а тип протокола указывается при установлении соединения. В результате мультиплексирования и идентификации протокола не требуется. Такой метод может использоваться, например, когда приложения взаимодействуют напрямую, в обход протоколов нижних уровней. Он применим, только если устройства находятся в пределах сети ATM. Кроме того, в многопротокольных сетях такой метод требует установления множества виртуальных соединений, что не всегда приемлемо.

ХРАНИ ПОРЯДОК, И ПОРЯДОК СОХРАНИТ ТЕБЯ

Рабочая группа ION также разработала стандарт на размер максимальной единицы передачи (Maximum Transfer Unit, MTU) для сетей ATM. Этот стандарт описан документом RFC 1626 от мая 1994 года. Некоторые приложения, например NFS, наиболее оптимально работают с MTU большего размера. Для повышения производительности количество дейтаграмм протокола IP желательно уменьшить. Документ RFC 1209 определяет размер MTU в 9180 байт для SMDS. Данное значение было сочтено приемлемым для использования и в сетях ATM.

Как определено в документе RFC 1626, два клиента, поддерживающие протокол TCP/IP и связанные между собой постоянным виртуальным соединением (PVC), должны использовать MTU с размером 9180 байт, если они заранее не согласовали меньшее или большее значение. В случае коммутируемого виртуального соединения (SVC) клиенты будут договариваться о размере MTU во время установления этого соединения. Отправитель может указать либо значение MTU по умолчанию, либо другое значение в служебном сообщении, посылаемом при установлении соединения. Получатель может принять это значение или указать меньшее в ответном сообщении.

Отправитель и получатель могут также договориться использовать большее значение MTU, чем по умолчанию, если они согласны на фрагментацию посылаемых данных. Специальный метод позволяет определять и использовать максимально возможное значение MTU на пути передачи. Для этого устройства (рабочие станции, маршрутизаторы и т. д.) должны поддерживать механизм, описанный в документе RFC 1191 от ноября 1994 года. Цель введения такого механизма состоит в минимизации объема фрагментирования на промежуточных узлах в сети.

ВСЕ ТАЙНОЕ СТАНОВИТСЯ ЯВНЫМ

В протоколе IP адреса устройств в сети назначаются независимо от их физических адресов. Для доставки информации по сети ATM программное обеспечение должно определить соответствие ATM-адреса устройства его IP-адресу. Причем прикладные программы в большинстве своем используют именно IP-адреса. Соответствие адресов устанавливается с помощью специального протокола.

В локальных сетях, поддерживающих механизм широковещания на канальном уровне, эта задача решается с помощью протокола ARP. Однако сеть ATM относится к классу NBMA (Non-Broadcast Multiple Access Networks) - сетей множественного доступа с виртуальными соединениями, называемых также нешироковещательными сетями множественного доступа.

Для решения вопросов, связанных с работой протокола IP в сетях ATM, рабочая группа ION предложила технологию, названную "классический IP и ARP для ATM" (Classical IP and ARP over ATM), и опубликовала ее в документе RFC 1577 в январе 1994 года.

Данная технология предназначена для поддержки протокола IP в одной логической подсети (Logical IP Subnet, LIS) сети ATM. Логическая подсеть состоит из группы устройств, подключенных к одной сети ATM и использующих единый номер сети/подсети и маску подсети.

Для определения соответствия логических и физических адресов устройств каждая LIS имеет один сервер ATMARP, реализующий одноименный протокол. Каждое устройство (клиент LIS) в логической подсети настраивается на уникальный ATM-адрес этого сервера. Протокол ATMARP базируется на протоколе ARP, но включает ряд дополнений, необходимых для работы в нешироковещательной сети.

Основная задача сервера заключается в управлении специальной таблицей, записи которой содержат пары соответствующих IP- и ATM-адресов устройств. Область действия сервера не ограничивается одной логической подсетью, он может обслуживать клиентов в нескольких подсетях. Внутренняя таблица сервера строится в результате обмена сообщениями между ним и клиентами логических подсетей.

Когда клиент начинает свою работу в логической подсети, он устанавливает виртуальное соединение с сервером по предопределенному ATM-адресу. После обнаружения соединения сервер посылает запрос Inverse ARP (InATMARP) (см. Рисунок 5). Цель этого запроса - получение IP- и ATM-адресов клиента, возвращаемых в ответном сообщении. Сервер проверит существующие записи в своей таблице на наличие совпадений и, если они не будут найдены, добавит новую запись, хранимую минимум 20 минут.

Если другому клиенту (клиенту 2) в этой логической подсети необходимо передать данные клиенту 1, и соединение уже установлено, то информация может быть немедленно отправлена через это соединение. Однако если

соединение не установлено, а ATM-адрес клиента 1 не известен, то клиенту 2 потребуется прибегнуть к услугам сервера ATMARP, которому он пошлет запрос ATMARP, содержащий IP-адрес клиента 1. Если таблица сервера содержит запись с этим IP-адресом, то сервер вернет в ответе ATMARP соответствующий ATM-адрес (см. Рисунок 6). Если в таблице такой записи не окажется, то сервер пошлет сообщение ATM_NAK. Таблица 2 содержит список сообщений протокола ATMARP с описанием их функций.

ТАБЛИЦА 2 - Сообщения протокола ATMARP
Сообщение	Описание
Запрос ATMARP	Посылается от клиента к серверу для получения ATM-адреса получателя. Сообщение содержит IP- и ATM-адреса клиента и IP-адрес получателя.
Ответ ATMARP	Посылается сервером в ответ на запрос ATMARP. Содержит искомый ATM-адрес получателя.
Запрос InATMARP	Посылается от сервера к клиенту для получения его IP-адреса. Содержит ATM-адрес клиента, IP- и ATM-адреса сервера.
Ответ InATMARP	Посылается в ответ на запрос InATMARP от клиента. Содержит IP-адрес клиента.
Ответ ATMARP_NAK	Отрицательный ответ на запрос ATMARP. Посылается от сервера к клиенту.

При очевидной простоте работы классического IP все оказывается не так гладко. Основной недостаток определяется именно классическими методами работы протокола. Он связан с тем, что любые данные, адресованные за пределы логической подсети, должны направляться маршрутизатору по умолчанию. Такая схема работы оказывается неэффективной в сети ATM, где одна сеть может охватывать множество логических подсетей и, главное, поддерживать прямое взаимодействие между двумя клиентами в двух различных подсетях. Однако документ RFC 1577 предусматривает обязательную передачу данных между двумя устройствами в различных подсетях через связующий подсети маршрутизатор.

Другая трудность связана с процессом регистрации адресов. В настоящее время сервер ATMARP использует сообщение InATMARP для определения адресов клиента. Но возможен случай, когда функции ATMARP-сервера выполняются маршрутизатором, обслуживающим множество клиентов, поддерживающих протоколы, отличные от IP (например, IPX, AppleTalk). По определению сервер ATMARP будет посылать запрос InATMARP всем клиентам в логической подсети, даже если они не поддерживают протокол IP. Это приводит к нецелесообразному использованию ресурсов клиентов и маршрутизатора. Решением проблемы может быть упрощение процедуры регистрации, при которой она будет выполняться во время первой посылки запроса ATMARP от клиента. Ожидается, что эти изменения будут внесены в следующую редакцию документа RFC 1577.

Кроме того, IETF рассматривается ограничение, согласно которому логическая подсеть может иметь только один сервер ATMARP. Такая схема может привести к проблемам при выходе из строя данного сервера. Возможность поддержки множества серверов в логической подсети устранит это ограничение и даст возможность реализовать более гибкие решения. Синхронизация содержимого таблиц серверов может выполняться через виртуальные соединения с помощью специального протокола синхронизации (Server Cache Synchronization Protocol, SCSP), работы над которым уже ведутся.

СМОТРИ В КОРЕНЬ

Многоадресная передача - это наиболее эффективный способ передачи информации группе получателей. В протоколе IP поддержка многоадресной передачи информации осуществляется с помощью трех компонентов: группового адреса класса D, протокола управления группой (IGMP) и протоколов многоадресной маршрутизации (MOSPF, PIM и т. д.). Групповой адрес указывает на принадлежность к определенной группе; протокол управления группой извещает маршрутизаторы о наличии членов группы в подключенных к нему подсетях; протоколы многоадресной маршрутизации осуществляют доставку дейтаграмм с групповым адресом членам группы.

Групповая адресация может быть реализована на двух уровнях модели OSI - канальном и сетевом. Протоколы канального уровня, например такие, как Ethernet и FDDI, могут поддерживать единичную, групповую и широковещательную адресацию. Групповая адресация на канальном уровне позволяет получить дополнительные преимущества при доставке дейтаграмм с групповыми адресами. Для этого групповой адрес сетевого уровня необходимо отобразить в физический адрес канального уровня, например в MAC-адрес.

ATM предусматривает эффективный механизм поддержки групповой передачи с возможностью установления двунаправленного виртуального соединения типа "точка-группа". К сожалению, такое решение не может быть реализовано при использовании уровня адаптации AAL5. Данное ограничение связано с тем, что все кадры этого уровня, посылаемые определенному получателю через определенное соединение, должны быть получены им в порядке отправления, без смешения ячеек, принадлежащих к различным кадрам. Иначе в результате процесса сборки на стороне получателя исходный кадр не удастся реконструировать. По этой причине при использовании уровня адаптации AAL5 виртуальное соединение типа "точка-группа" может быть только однонаправленным.

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

В спецификации UNI 3.1 указано, что корень отвечает за добавление листьев к дереву доставки и, следовательно, должен знать их ATM-адреса. Новая спецификация UNI 4.0 определяет возможность для листьев самостоятельно подключаться к уже установленным виртуальным соединениям типа "точка-группа". Однако однонаправленное соединение останется, скорее всего, единственным методом групповой передачи трафика в сетях ATM.

При разработке стандарта на классический IP поддержка механизма многоадресной передачи данных была недостаточно четко определена. Это долгое время рассматривалось как существенный недостаток стандарта. Однако некоторое время спустя (в апреле 1995 года) внесенные добавления позволили уточнить механизм многоадресной передачи. Добавления опирались, преимущественно, на методы поддержки многоадресной передачи с помощью групповых серверов и перекрывающихся виртуальных соединений типа "точка-группа", как это описано в документе RFC 1112 за август 1992 года.

При первом методе отправитель посылает данные напрямую групповому серверу (MultiCast Server MCS) через виртуальное соединение типа "точка-точка", а он уже затем рассылает их всем членам группы через виртуальное соединение типа "точка-группа" (см. Рисунок 8).

При втором методе отправитель устанавливает виртуальное соединение типа "точка-группа" с членами группы-получателя. Если несколько устройств готовы передавать и получать данные для своей группы, то каждое из них должно установить виртуальное соединение, формируя смешанную (перекрывающуюся) топологию (см. Рисунок 9).

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

MARS - ЭТО НЕ ТОЛЬКО ТОЛСТЫЙ-ТОЛСТЫЙ СЛОЙ ШОКОЛАДА

В добавлениях к стандарту, описывающему работу классического IP, вводится понятие сервера разрешения группового адреса (Multicast Address Resolution Server, MARS), который можно рассматривать как аналог сервера ATMARP, предназначенного для работы с групповыми адресами.

Вместо таблицы, содержащей записи соответствия единичных IP- и ATM-адресов, он управляет таблицей с записями, где для каждого группового адреса указываются IP- и ATM-адреса членов этой группы. Например, запись в таблице для устройств, принадлежащих к группе с IP-адресом 232.200.200.1, будет выглядеть следующим образом: {232.200.200.1, ATM-адрес 1, ATM-адрес 2, ..., ATM-адрес N}

Если станция готова отправить данные определенной группе, она устанавливает соединение с сервером MARS и отправляет запрос MARS_REQUEST для данной группы. Если ни один член группы не зарегистрировался на сервере MARS, то он, в ответ на запрос, отправляет сообщение MARS_NAK. Если на сервере MARS уже зарегистрированы один или несколько ее членов, то дальнейшие действия сервера зависят от метода доставки многоадресного трафика.

В случае группового сервера, сервер MARS вернет сообщение MARS_MULTI со ссылкой на один или более групповых серверов, обслуживающих эту группу (так называемую карту серверов - server map). Затем запрашивающая станция может установить виртуальное соединение типа "точка-точка" или "точка-группа" с одним или несколькими групповыми серверами и начать передачу информации (см. Рисунок 10). Использование нескольких групповых серверов целесообразно для распределения нагрузки в сети и в целях повышения надежности работы.

В случае смешанных виртуальных соединений, сервер MARS вернет сообщение MARS_MULTI, со ссылкой на адреса принадлежащих к группе устройств (карта хостов - host map). Затем запрашивающая станция установит с ними виртуальное соединение типа "точка - группа" и начнет передавать информацию.

Наиболее сложной функцией сервера MARS является составление списка входящих в группы устройств. В документе RFC 1112 указано, что если устройство желает стать членом определенной группы, то оно должно послать сообщение протокола IGMP. Цель этого сообщения состоит в информировании всех маршрутизаторов в локальной подсети о существовании в данной подсети устройства, желающего стать членом группы. Маршрутизаторы затем используют эту информацию для направления многоадресного трафика в подсеть, опираясь на многоадресные протоколы маршрутизации.

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

В дополнение к классическому IP вводится поддержка двух служебных виртуальных соединений типа "точка-группа": ServerControlVC и ClusterControlVC. Первое связывает все групповые серверы, второе - все конечные системы (включая маршрутизаторы) в кластере. Под кластером понимается группа устройств, обслуживаемая сервером MARS.

Перед тем как сервер MARS сможет предоставить карты серверов или хостов, он должен их сформировать. Любой групповой сервер, обслуживающий одну или несколько определенных групп, должен сначала сам зарегистрироваться на сервере MARS, используя сообщение MARS_MSERV. С помощью этого сообщения сервер MARS формирует список ATM-адресов серверов, обслуживающих конкретные группы.

Сервер MARS добавит данный групповой сервер к ServerControlVC. Список устройств, желающих получать данные, посланные по определенному групповому адресу, групповые серверы "узнают" с помощью обычного запроса MARS_REQUEST. Сервер MARS определяет, что информацию запрашивает групповой сервер, и возвращает соответствующий список клиентов, на основании которого групповой сервер сможет установить виртуальное соединение типа "точка-группа".

Любое устройство может зарегистрироваться как член определенной группы, отправив сообщение MARS_JOIN серверу MARS. Таких сообщений может быть послано несколько, так как устройство может одновременно принадлежать к нескольким группам. Сервер MARS сохранит ATM-адрес устройства, пославшего этот запрос, в списке, ассоциирующимся с определенной группой. Кроме того, устройство будет добавлено в качестве листа к виртуальному соединению ClusterControlVC.

Для информирования сервера MARS о том, что станции больше не требуется получать информацию, адресованную определенной группе (группам), она должна послать сообщение MARS_LEAVE.

Широковещание - это разновидность групповой передачи данных, при которой все устройства в определенной сети являются членами группы с адресом 255.255.255.255. Он называется широковещательным каналом. Сервер MARS может эффективно поддерживать широковещательную передачу, так как централизованный процесс регистрации дает возможность подключиться к широковещательной группе любому устройству, а использование сообщений MARS_MULTI позволяет значительно уменьшить загрузку сети с помощью информирования о множестве членов группы посредством одного сообщения. Кроме того, групповой сервер может уменьшить количество виртуальных соединений до одного, необходимого для поддержания широковещания.