введение в групповую передачу

Групповая передача (мультикастинг, многоадресная рассылка) – возможность одновременно передавать один поток многим подписчикам. В отличие от обыкновенной потоковой передачи данных, здесь нет необходимости выделения потока каждому подписчику. Вместо этого в сегмент сети, где находится подписчик, направляется лишь один поток. Задачей маршрутизаторов является отслеживание подписки и создания копий только по требованию. В отличие от широковещания, сегменты, в которых отсутствуют подписчики, не получают поток.
Протокол мультикастинга предлагает ненадежную передачу, так как базируется на UDP. Далее будет рассказано, как увеличить надежность, но это будет лишь оберткой для механизма, который ненадежен в своей основе.

как настроить клиентскую машину для групповой передачи?

Первым делом, нужно настроить ядро для ее поддержки. Под Linux вы можете зайти в настройки сети в ядре и включить возможность мультикастинга. Затем необходимо заново собрать ядро, установить и перезагрузиться. В большинстве BSD-систем групповая передача включена по умолчанию. Следующим шагом нужно будет сконфигурировать таблицу маршрутизации. Под дистрибутивами Linux с iputils2, вам нужно ввести команду:

ip route add 224.0.0.0/4 dev eth0

Для более старых Linux-ов и некоторых других юниксоподобных систем используйте команду:

route add -net 224.0.0.0 netmask 240.0.0.0 gateway default dev eth0

(подразумевается, что ваше сетевое устройство – eth0, а поддержка мультикастинга включена на маршрутизаторе).
Для проверки этой конфигурации введите:

ping -c 2 224.0.0.1

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

где найти софт для пользования мультикастингом (не маршрутизации)?

Зайдите наhttp://www-mice.cs.ucl.ac.uk/multimedia/software/. Там есть три программы, без которых вам не обойтись при проведении видеоконференций (самый популярный вид применения мультикастинга): VIC, RAT и SDR. VIC и RAT отвечают за видео и аудио при проведении видеоконференций. SDR – менеджер сессий, позволяющий вам выбирать желаемую сессию групповой передачи.

у меня есть софт, но я не вижу мультикастинговых сессий. где их взять?

У провайдера. Не все провайдеры поддерживают групповую передачу, хотя у всех есть нужное оборудование и им ничего не стоит включить эту возможность. Так что понадоедайте провайдеру по этому поводу. Если это не работает, у вас должна быть возможность установить туннель с провайдером MBone. В конференции MBone (alt.mbone) вас просветят по этому вопросу.

маршрутизация групповой передачи

Мультикастинг задействует две стороны: подписчики и маршрутизаторы. Вообще, вы не можете быть и подписчиком, и маршрутизатором одновременно. Возможности подписчика ограничены возможностями самого «слабого» подписчика для этого потока. Таким образом, если подписчик использует IGMP версии 1, все машины будут ограничены возможностями IGMPv1. Не до конца ясно, что происходит, когда самые ограниченные подписчики отписываются от потока (например, неизвестно, увеличиваются ли возможности потока).
Вследствие этого, обратная совместимость абсолютна, но за счет необходимости отслеживания очень сложных сетевых процессов в данный период, а также за счет снижения устойчивости среды.

управление группами

Это сердце мультикастинга. Каждый маршрутизатор отслеживает подписчиков данного потока и передает соответствующую информацию следующему маршрутизатору, принимающему этот поток. Таким образом, для каждого передаваемого потока строится и поддерживается виртуальное дерево сети.
Передавать информацию по этому дереву могут многие люди – это вам не VPN с единственным источником. Пожалуй, любое количество машин может делать свой вклад в поток, при условии, что они являются подписчиками.

IGMP (версия 3)

Интернет протокол управления группами (Internet Group Management Protocol, IGМP) привносит некоторые дополнительные возможности, а именно: аутентификацию и мультикастинг от источника (source-based). Аутентификация позволяет вам потребовать у передающих машин доказательств того, что они являются теми, за кого себя выдают, тем самым, предотвращая возможность несанкционированного доступа.
Мультикастинг от источника дополняет возможности аутентификации и позволяет вам задавать разрешенные или запрещенные адреса: остальные же потоки с этого мультикаст-дерева будут попросту проигнорированы.

EAP

Расширяемый аутентификационный протокол (Extensible Authentication Protocol, EAP) – это механизм, по которому проходит аутентификация. Как видно из названия, протокол является наращиваемым. Он работает как часть IGMP версии 3, и, собственно, является расширением этого протокола. По очевидным причинам расширение EAP вместе с используемым аутентификационным механизмом должны поддерживаться всеми машинами-подписчиками для корректной работы. Если оные механизмы не поддерживаются, аутентификацию произвести не удается.
Так как EAP является особенностью IGMP версии 3, у подписчиков, использующих IGMP версий 1 или 2, аутентификация не будет работать, так как эта возможность будет закрыта маршрутизаторами групповой передачи.

Multicast Listener Discovery версии 2

MLD версии 2 – это IGMP версии 3 для IPv6 :) Он описывает те же механизмы и обладает теми же ограничениями, а именно, если пользователи MLD версии 1 используют поток, возможности версии 2 будут отключены.

мультикастинг из определенного источника

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

протокол независимой групповой передачи версии 2 (Protocol Independent Multicast v2, PIM)

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

«редкий» режим

В «редком» режиме используется предположение, что подписчиков очень немного, и они подключаются к очень небольшому количеству потоков. Это, по большому счету, является моделью работы Интернет-бэкбона. Кроме того, режим очень эффективен для отслеживания отдельных пользователей и отдельных потоков, нежели множества в пулах.

«плотный» режим

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

двунаправленный режим

В этом случае мы полностью забываем о топологии «дерево». Множество пользователей могут быть подключены к нескольким потокам, несколько пользователей – к множеству потоков, в любом варианте. Все это работает в режиме, похожем на «плотный», за исключением того, что обе стороны могут иметь большую плотность соединений.

эникастинг

Эникастинг (anycasting, в досл. переводе «всевещание») – любопытный вариант группового вещания. Запрос отправляется мультикастингом всем подписывающим сервисам. «Ближайший» сервис, который может обработать запрос, отвечает при помощи соединения с прямой однонаправленной передачей (юникастинг). Идея эникастинга заключается в том, что машины должны уметь обрабатывать определенные запросы без наличия информации о топологии сети или местонахождении серверов. На практике же серверов с возможностями эникастинга очень мало (если есть вообще).

работа в мобильных сетях, мобильные и ad-hoc-сети

Мобильные сети с постоянной инфраструктурой подразумевают свободное перемещение компьютеров, но статичность инфраструктуры.
Мобильные сети с динамической инфраструктурой– сети, в которых соединения по локальной сети постоянны, но маршрутизаторы и инфраструктура – мобильны.
Ad-hoc сети – такие, в которых все члены мобильны.
Мультикастинг не предназначен для работы в мобильных сетях с постоянной/динамической инфраструктурой. Тем не менее, он может применяться для ad-hoc сетей.

«надежный мультикастинг»

Надежный мультикастинг – слой («обертка»), который можно «одеть» на обычную групповую передачу. Он поддерживает ACK/NAK, создавая иллюзию TCP при мультикастинге. Таким образом, можно достаточно просто использовать FTP и HTTP через мультикастинг.

резервирование пропускной способности

Существует множество методов резервирования пропускной способности канала. Среди них наиболее широко применяется, пожалуй, RSVP. Это позволяет пользователям заранее выделять определенную часть пропускной способности канала. Им гарантируется эта ширина канала между ними и любыми оконечными точками, куда они передают или откуда получают информацию.
RVSP очень дорог для применения в сетях, так как требует передачи большого количества служебной информации. По существу, он не слишком популярен в Internet в целом, но вполне эффективен при использовании в Intranet-е.

материалы для дальнейшего изучения

Следующие рабочие группы IETF разработали огромное количество RFC и набросков, относящихся к мультикастингу. Очень рекомендуется ознакомиться с ними, если вас интересует низкоуровневая информация.
http://www.ietf.org/html.charters/magma-charter.html 
http://www.ietf.org/html.charters/pim-charter.html 
http://www.ietf.org/html.charters/ssm-charter.html 
http://www.ietf.org/html.charters/msec-charter.html 
http://www.ietf.org/html.charters/rmt-charter.html 

Jonathan Day, перевод Щетько Николая АКА Nickky,me@nickky.com.