Reliable multicast protocol windows 7 что это
Обновлено: 05.07.2024
Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.
В этой серии статей сосредоточимся на следующем:
Содержание серии статей про мультикаст
На заре моего становления, как инженера, тема мультикаста меня неимоверно пугала, и я связываю это с психотравмой моего первого опыта с ним.
«Так, Марат, срочно, до полудня нужно пробросить видеопоток до нашего нового здания в центре города — провайдер отдаст его нам тут на втором этаже» — услышал я одним чудесным утром. Всё, что я тогда знал о мультикасте, так это то, что отправитель один, получателей много, ну и, кажется, протокол IGMP там как-то задействован.
В итоге до полудня мы пытались всё это дело запустить — я пробросил самый обычный VLAN от точки входа до точки выхода. Но сигнал был нестабильным — картинка замерзала, разваливалась, прерывалась. Я в панике пытался разобраться, что вообще можно сделать с IGMP, тыркался, тыркался, включал мультикаст роутинг, IGMP Snooping, проверял по тысяче раз задержки и потери — ничего не помогало. А потом вдруг всё заработало. Само собой, стабильно, безотказно.
Это послужило мне прививкой против мультикаста, и долгое время я не проявлял к нему никакого интереса.
Уже гораздо позже я пришёл в к следующему правилу:
И теперь с высоты оттраблшученных кейсов я понимаю, что там не могло быть никаких проблем с настройкой сетевой части — глючило конечное оборудование.
Сохраняйте спокойствие и доверьтесь мне. После этой статьи такие вещи вас пугать не будут.
Общее понимание Multicast
Как известно, существуют следующие типы трафика:
Раз уж мы решили поговорить о мультикасте, то, пожалуй, начнём этот параграф с вопроса, где и как он используется.
Первое, что приходит на ум, — это телевидение (IPTV) — один сервер-источник отправляет трафик, который хочет получать сразу много клиентов. Это и определяет сам термин — multicast — многоадресное вещание. То есть, если уже известный вам Broadcast означает вещание всем, мультикаст означает вещание определённой группе.
Второе применение — это, например, репликация операционной системы на множество компьютеров разом. Это подразумевает загрузку больших объёмов данных с одного сервера.
Возможные сценарии: аудио и видеоконференции (один говорит — все слушают), электронная коммерция, аукционы, биржи. Но это в теории, а на практике редко тут всё-таки используется мультикаст.
Сформулируем два основных принципа мультикастовой рассылки:
- отправитель посылает только одну копию трафика, независимо от количества получателей;
- трафик получают только те, кто действительно заинтересован в нём.
В данной статье для практики мы возьмём IPTV, как наиболее наглядный пример.
Пример 1
Начнём с самого простого случая:
На сервере-источнике настроено вещание в группу 224.2.2.4 — это означает, что сервер отправляет трафик на IP-адрес 224.2.2.4. На клиенте видеоплеер настроен принимать поток группы 224.2.2.4.
При этом, заметьте, клиент и сервер не обязательно должны иметь адреса из одной подсети и пинговать друг друга — достаточно, чтобы они были в одном широковещательном домене. Мультикастовый поток просто льётся с сервера, а клиент его просто принимает. Вы можете попробовать это прямо у себя на рабочем месте, соединив патчкордом два компьютера и запустив, например, VLC.
Надо заметить, что в мультикасте нет никакой сигнализации от источника, мол, «Здрасьте, я Источник, не надо немного мультикаста?». Сервер-источник просто начинает вещать в свой интерфейс мультикастовые пакеты. В нашем примере они напрямую попадают клиенту и тот, собственно, сразу же их и принимает.
Если на этом линке отловить пакеты, то вы увидите, что мультикастовый трафик — это ни что иное, как море UDP-пакетов.
Содержимое мультикастового трафика
Мультикаст не привязан к какому-то конкретному протоколу. По сути, всё, что его определяет — адреса. Однако, если говорить о его применении, то в абсолютном большинстве случаев используется именно UDP. Это легко объясняется тем, что обычно с помощью многоадресной рассылки передаются данные, которые нужны здесь и сейчас. Например, видео. Если кусочек кадра потеряется, и отправитель будет пытаться его послать повторно, как это происходит в TCP, то, скорее всего, этот кусочек опоздает, и где его тогда показывать? Поезд ушёл. Ровно то же самое со звуком.
Соответственно не нужно и устанавливать соединение, поэтому TCP здесь ни к чему.
Чем же так разительно отличается мультикаст от юникаста? Думаю, у вас есть уже предположение. И вы, наверняка, правы.
В обычной ситуации у нас 1 получатель и 1 отправитель — у каждого из них один уникальный IP-адрес. Отправитель точно знает, куда надо слать пакет и ставит этот адрес в заголовок IP. Каждый промежуточный узел благодаря своей таблице маршрутизации точно знает, куда переслать пакет. Юникастовый трафик между двумя узлами беспрепятственно проходит сквозь сеть. Но проблема в том, что в обычном пакете указывается только один IP-адрес получателя.
Что делать, если у одного и того же трафика несколько получателей? В принципе можно расширить одноадресный подход и на такую ситуацию — отправлять каждому клиенту свой экземпляр пакета. Клиенты не заметят разницы — хоть он один, хоть их тысяча, но разница будет отчётливо различима на ваших каналах передачи данных.
Зависимость нагрузки на сеть от количества пользователей при передаче юникаст и мультикаст трафика
Предположим у нас идёт передача одного SD-канала с мультикаст-сервера. Пусть, он использует 2 Мб/с. Всего таких каналов 30, а смотрит каждый канал по 20 человек одновременно. Итого получается 2 Мб/с * 30 каналов * 20 человек = 1200 Мб/с или 1,2 Гб/с только на телевидение в случае одноадресной рассылки. А есть ведь ещё HD каналы, где можно смело умножать эту цифру на 2. И где тут место для торрентов?
Вот почему в IPv4 был заложен блок адресов класса D: 224.0.0.0/4 (224.0.0.0-239.255.255.255). Адреса этого диапазона определяют мультикастовую группу. Один адрес — это одна группа, обычно она обозначается буквой «G».
То есть, говоря, что клиент подключен к группе 224.2.2.4, мы имеем ввиду, что он получает мультикастовый трафик с адресом назначения 224.2.2.4.
Пример 2
Добавим в схему коммутатор и ещё несколько клиентов:
Собственно, все эти устройства становятся членами данной мультикастовой группы. Членство в ней динамическое: кто угодно, в любой момент может войти и выйти из неё.
Обратите внимание, что в данном случае от сервера-источника приходит только одна копия трафика на коммутатор, а не по отдельной копии на каждого клиента. И в нашем примере с SD каналами загрузка порта между источником и коммутатором будет не 1,2 Гб/с, а всего 60 Мб/с (2Мб/с * 30 каналов).
Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать. Ну, почти весь — первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы.
| Адрес | Значение |
|---|---|
| 224.0.0.0 | Не используется |
| 224.0.0.1 | Все узлы данного сегмента |
| 224.0.0.2 | Все мультикастовые узлы данного сегмента |
| 224.0.0.4 | Данный адрес выделялся для покойного протокола DVMRP |
| 224.0.0.5 | Все OSPF-маршрутизаторы сегмента |
| 224.0.0.6 | Все DR маршрутизаторы сегмента |
| 224.0.0.9 | Все RIPv2-маршрутизаторы сегмента |
| 224.0.0.10 | Все EIGRP-маршрутизаторы сегмента |
| 224.0.0.13 | Все PIM-маршрутизаторы сегмента |
| 224.0.0.18 | Все VRRP-маршрутизаторы сегмента |
| 224.0.0.19-21 | Все IS-IS-маршрутизаторы сегмента |
| 224.0.0.22 | Все IGMP-маршрутизаторы сегмента (v2 и v3) |
| 224.0.0.102 | Все HSRPv2/GLBP-маршрутизаторы сегмента |
| 224.0.0.107 | PTPv2 — Precision Time Protocol |
| 224.0.0.251 | mDNS |
| 224.0.0.252 | LLMNR |
| 224.0.0.253 | Teredo |
| 224.0.1.1 | NTP |
| 224.0.1.39 | Cisco Auto-RP-Announce |
| 224.0.1.40 | Cisco Auto-RP-Discovery |
| 224.0.1.41 | H.323 Gatekeeper |
| 224.0.1.129-132 | PTPv1/PTPv2 |
| 239.255.255.250 | SSDP |
Диапазон 224.0.0.0/24 зарезервирован под link-local коммуникации. Мультикастовые пакеты с такими адресами назначения не могут выходить за пределы одного широковещательного сегмента.
Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы.
Вот, собственно, самые базисные вещи касательно мультикаста.
Мы рассмотрели простую ситуацию, когда источник и получатель находятся в одном сегменте сети. Трафик, полученный коммутатором, просто рассылается им во все порты — никакой магии.
Но пока совсем непонятно, как трафик от сервера достигает клиентов, когда между ними огромная провайдерская сеть линкмиап? Да и откуда, собственно, будет известно, кто клиент? Мы же не можем вручную прописать маршруты, просто потому что не знаем, где могут оказаться клиенты. Не ответят на этот вопрос и обычные протоколы маршрутизации. Так мы приходим к пониманию, что доставка мультикаст — это нечто совершенно новое для нас.
Вообще, чтобы доставить мультикаст от источника до получателя на данный момент существует много протоколов — IGMP/MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.
Мы остановимся на двух из них, которые используются в настоящее время: PIM и IGMP.
С помощью IGMP конечные получатели-клиенты сообщают ближайшим маршрутизаторам о том, что хотят получать трафик. А PIM строит путь движения мультикастового трафика от источника до получателей через маршрутизаторы.
Использование протоколов PIM и IGMP на участках сети
Мультивещание (multicasting) в региональном масштабе позволяет значительно снизить требования приложений к полосе пропускания, однако многоадресные передачи нельзя отнести к разряду надежных, и это создает серьезные проблемы.
Уже предложено свыше двух десятков протоколов, специально разработанных для надежного мультивещания. Однако достичь этой цели невозможно без решения целого ряда сложных вопросов, связанных с перегрузкой источника за счет обратной связи с получателем, восстановлением утраченных пакетов, порядком следования пакетов и разработкой организационной структуры групп получателей. Кажется весьма маловероятным, что устранить все эти трудности сможет один-единственный протокол.
Когда обмен информацией происходит между одним отправителем и одним получателем (так называемая одноадресная передача), с исправлением ошибок и контролем за последовательностью пакетов вполне справляются TCP и другие протоколы. Но в сеансах мультивещания, где обратная связь осуществляется сразу с несколькими источниками, подобный метод может привести к чрезмерной перегрузке отправителя.
Но у проблемы надежности есть и другой аспект. Его суть заключается в том, как система мультивещания восстанавливает утраченные пакеты. Самый простой способ - отправитель повторяет передачу информации для всей группы получателей. При этом повторно ретранслируемые данные вынуждены принимать все получатели, независимо от того, дошли до них повторяемые пакеты или нет.
Существует и другой путь, получивший название локального восстановления, основанный на так называемом "ограничении", при котором запросы на ретрансляцию распространяются лишь по заданной части сети.
Классификация и сравнение протоколов
Один из ключевых вопросов, возникающих при создании надежных протоколов мультивещания, состоит в том, кто из корреспондентов - отправитель или получатель - должен контролировать соединения и управлять повторной передачей утраченных пакетов.
В системах, где контроль за передачей осуществляют получатели, задача повторной передачи пакетов распределяется между несколькими (а то и всеми) получателями. Отправитель не следит за состоянием каждого получателя, его функции ограничены ответами на получаемые запросы. Правда, при такой схеме мультивещания отправителю, возможно, придется опрашивать получателей перед тем, как удалить данные из своего буфера.
В целом же протоколы, в которых главная роль отводится получателям, гораздо более масштабируемы, чем те, где системой управляет отправитель. Причина здесь проста: пропускная способность протоколов с ключевой функцией отправителя зависит от количества получателей информации. Это может перегрузить не только сетевые ресурсы (например, значительную часть полосы пропускания займет передача подтверждений), но и вычислительные ресурсы отправителя (потребуется дополнительная оперативная память для контроля за состоянием каждого получателя и буферизации ранее посланных пакетов - их придется хранить до тех пор, пока подтверждение о приеме данных не поступит от каждого получателя).
Системы на базе получателей различаются между собой способом организации получателей и тем, как созданная организационная структура используется для рассылки пакетов. Это может быть бессистемное "облако" получателей, древовидная структура, корнем которой служит отправитель, либо кольцевая схема. Структурная организация получателей способна оказать огромное влияние на масштабируемость протокола - в наибольшей степени масштабируемы бессистемные "облака" получателей, в наименьшей - кольцевые структуры.
В некоторых случаях для надежной передачи информации необходим строгий порядок следования данных. Существует три уровня упорядочения данных. Протокол первого уровня, где данные передаются вообще без упорядочения, не может гарантировать, что пакеты поступят к получателю в требуемой последовательности.
Когда упорядочиванием пересылки пакетов занимается отправитель (второй уровень), протокол поддерживает последовательность передачи данных каждому получателю. Однако и здесь нет никаких гарантий, что пакеты от различных отправителей будут приняты получателем в должном порядке.
Промежуточные получатели снижают трафик обратной связи
Промежуточные получатели могут восстанавливать пакеты, утраченные другими
получателями их области. Если промежуточный получатель не находит у себя
требуемого пакета (область А), он посылает запрос другому промежуточному
получателю ( область Б).
Гарантировать последовательность приема пакетов всеми получателями способен лишь полностью упорядоченный протокол (третий уровень), который основан на глобальных правилах.
Большинство начальных экспериментов по спецификации IP Multicasting проводилось в рамках проекта Multicast Backbone, т. е. по цепочке специализированных маршрутизаторов, образующих подсеть Интернет. Основная часть программных средств многоадресной передачи данных свободно доступна для исследователей уже многие годы, однако коммерческие продукты, специально предназначенные для обеспечения надежного мультивещания, появились лишь в прошлом году.
Сегодня все они базируются на пяти протоколах: протоколе на базе кольцевых структур под названием RMP (Reliable Multicast Protocol - надежный протокол мультивещания), двух протоколах на базе бессистемных "облаков" - MFTP (Multicast File Transfer Protocol - протокол многоадресной передачи файлов) и SRM (Scalable Reliable Multicast - масштабируемое надежное мультивещание), а также двух протоколов на базе древовидных структур - RMTP (Reliable Multicast Transport Protocol - надежный транспортный протокол мультивещания) и PGM (Pragmatic Group Multicasting - практичное мультивещание в практических группах).
Протоколы RMP, SRM и RMTP включены в комплект разработки приложений, выпущенный фирмой Globalcast Communications, которая открыла доступ к ним посредством одного-единственного интерфейса прикладного программирования.
Представители Globalcast Communications считают, что протокол RMP в наибольшей степени пригоден для тиражирования серверов и баз данных. Подходит он и для доставки информации в реальном масштабе времени, причем обслуживаемая группа может содержать до сотни членов. Протокол SRM рассматривается как средство потоковой трансляции мультимедийных передач и проведения видеоконференций с участием тысяч получателей, а протокол RMTP планируется использовать для пересылки файлов и данных в реальном масштабе времени на тысячи приемных компьютеров.
Фирма Lucent Technologies, предложившая протокол RMTP, производит сейчас бета-тестирование e-cast, приложения под Windows, специально предназначенного для пересылки файлов. Проблему многоадресной передачи файлов решает и корпорация Starburst Communications, заложившая в основу своих проектов разработанный ею же протокол MFTP. Продукты этой корпорации уже используются крупными компаниями для обмена финансовой информацией и отчетами инвентаризации, а также для обновления ПО через наземные и спутниковые линии связи.
Новейший протокол надежного мультивещания под названием PGM разработан совместно фирмами TIBCO и Cisco Systems. Как и другие протоколы этого класса, он представлен в Целевую группу инженерной поддержки Интернета (IETF) для утверждения в качестве стандарта. Фирма TIBCO уже использует протокол PGM в своей линии продуктов TIBnet (они предназначены для публикации данных и абонентской подписки на них в разнообразных приложениях, в первую очередь финансовых).
Современный человек на каждом шагу сталкивается с большим потоком визуальной и звуковой информации: домашнее телевидение, рекламные цифровые билборды, мультимедийные системы в поездах и самолетах, информирование в аэропортах и вокзалах и многое другое. Все эти системы требуют быстрой и эффективной передачи данных от одного источника до множества получателей. Такой же принцип работы используется при осуществлении видеоконференций, а в промышленном секторе востребован в системах видеонаблюдения и звукового аварийного оповещения.
На схеме изображена система, в которой источник информации отправляет три одинаковых экземпляра данных для трех получателей на их индивидуальные IP-адреса. Именно так выглядит одноадресная (unicast) рассылка.
Даже человеку, далекому от сетевых технологий, понятно, что в такой сети источнику приходится формировать несколько идентичных пакетов. А если получателей не три, а сотни или тысячи? В подобных системах необходимо применить совершенно другой подход – многоадресную (multicast) рассылку.
Multicast обеспечивает доставку трафика группе клиентов на IP-адрес группы многоадресной рассылки. Схема передачи данных выглядит следующим образом:
Независимо от того, сколько клиентов заинтересованы в получении данных, сервер-источник будет отправлять только один пакет, тем самым избегая излишнего дублирования. Плюсы такого подхода очевидны:
- рациональное использование пропускной способности;
- экономия вычислительных возможностей сервера;
- снижение нагрузки на сеть.
Более подробно рассмотрим механизм работы многоадресной рассылки.
Инструменты технологии multicast
Static Multicast – отслеживание и добавление статических многоадресных MAC-адресов вручную для фильтрации многоадресного трафика. Некоторые устройства не поддерживают динамическую регистрацию в мультикаст-группе, но в то же время способны получать многоадресный трафик. Чтобы это было возможно, такие устройства нужно зарегистрировать вручную: создать запись с групповым адресом и номерами портов в таблице многоадресной рассылки маршрутизатора.
IGMP (Internet Group Management Protocol) – протокол управления многоадресной передачей данных. Используется для динамической регистрации узлов-получателей в многоадресной группе. С его помощью хосты-клиенты оповещают маршрутизатор о своем желании получать многоадресный трафик (т.е. подписаться на рассылку). На сегодняшний день существует три версии данного протокола, все они совместимы между собой.
Механизм работы IGMP
Роутер получает IGMP-Report и заносит в свою таблицу мультикаст маршрутизации информацию о том, что на данном интерфейсе присутствуют клиенты, заинтересованные в получении трафика.
Групповой IP-адрес . Сервер-источник отправляется пакеты не на индивидуальные IP-адреса узлов, а на IP-адрес группы (выделенные специально для этих целей адреса в диапазоне от 224.0.0.0 до 239.255.255.255).
Групповой MAC-адрес . Для того, чтобы передавать кадры по локальной сети, каждому групповому IP-адресу должен соответствовать групповой MAC-адрес. Он всегда начинается с префикса 01:00:5Е, а оставшаяся часть формируется из 23 младших бит IP-адреса группы по определенному алгоритму.
Функция IGMP Snooping используется для того, чтобы избежать перенаправления трафика на все, даже не заинтересованные в его получении, узлы, т.е. для предотвращения флуда.
Маршрутизация Multicast трафика
Зачастую стоит задача транслирование многоадресного потока данных через несколько подсетей, разделенных маршрутизаторами. Каждый интерфейс маршрутизатора является широковещательным доменом, поэтому многоадресные пакеты маршрутизироваться между ними не будут. Именно для таких систем используют специализированные протоколы многоадресной маршрутизации. Например, протокол PIM.
PIM ( Protocol Independent Multicast ) – набор протоколов многоадресной маршрутизации, которые строят путь передвижения многоадресного трафика от сервера до клиентов через маршрутизаторы. Имеет два основных режима - Dense и Sparse , отличающихся принципом работы.
Организация многоадресной рассылки на маршрутизаторе Moxa
Типовая схема
Рассмотрим следующую типовую схему подключения сервера и клиентов, которые находятся в разных сегментах сети:
Различные аспекты многоадресности Надежные многоадресные приложения Многоадресные транспортные протоколы Встраивая поддержку многоадресной IP-передачи (multicast) в последние версии своих продуктов, ведущие производители маршрутизаторов и коммутаторов высокого уровня заложили основы нового поколения приложений, предоставляющих возможности многоадресной передачи.
Встраивая поддержку многоадресной IP-передачи (multicast) в последние версии своих продуктов, ведущие производители маршрутизаторов и коммутаторов высокого уровня заложили основы нового поколения приложений, предоставляющих возможности многоадресной передачи. Многоадресная IP-передача идеально подходит для тех случаев, когда необходимо направлять информацию из одного или нескольких источников многим адресатам; трафик, исходящий из одного источника, будет тиражироваться по мере его прохождения по сети, причем каждый адресат получит свою собственную копию потока данных. Используя ресурсы сети и сервера, можно доставлять данные одновременно многим получателям так же эффективно, как и одному.
Различные аспекты многоадресности
Большинство пользователей не задумываясь связывают многоадресность с потоковыми мультимедийными приложениями реального времени, такими как настольное видео, видеоконференцсвязь и аудио по Internet. Для работы сложных приложений необходима сеть, предоставляющая определенное качество сервиса. Это означает, что нужно обеспечить неизменность задержки и гарантированную пропускную способность для передачи потока в реальном времени. Но для таких приложений не требуется 100-процентная надежность сквозной передачи, поскольку потеря нескольких пакетов в аудио- и видеопотоке, не вызывающая ухудшения качества, считается приемлемой.
С многоадресными приложениями, для которых требуется 100-процентная надежность сквозной передачи, многие знакомы хуже, чем с потоковыми системами. К ним относятся совместные вычисления и передача информационных потоков в реальном времени и распространение больших объемов информации. Чтобы удовлетворить потребности таких приложений, не поддерживаемых существующими транспортными и сервисными протоколами TCP/IP, разрабатываются новые надежные протоколы многоадресной передачи.
В ближайшие год-два будут определены и приняты в качестве стандартов надежные многоадресные протоколы, удовлетворяющие потребности каждого отдельного класса приложений.
Многие распространенные одноадресные приложения, такие как File Tranfer Protocol (FTP), telnet и Web-браузеры, работают на основе протокола ТСР. Он обеспечивает надежную адресную доставку через прямые IP-соединения. Однако использование ТСР-транспорта для передачи данных из одного источника по многим адресам неэффективно, поскольку для каждого получателя требуется отдельное ТСР-соединение с источником, что требует значительных сетевых и серверных ресурсов.
Многоадресные IP-приложения, в отличие от одноадресных, работают под управлением протокола User Datagram Protocol (UDP), который достаточно просто обеспечивает наилучшую доставку пакета к конкретному порту и, к тому же, способен выявлять в пакете ошибки. Однако UDP не гарантирует 100-процентной доставки каждого пакета, необходимой, например, для систем распространения ПО. Он предоставляет лишь минимальный уровень сервиса, поэтому в многоадресном приложении любую специализированную транспортную функцию, в том числе и надежность, приходится обеспечивать на более высоком уровне, чем в протоколе UDP.
Обобщенный многоадресный протокол TCP сможет решить эти проблемы и обеспечить надежную упорядоченную доставку информации из одного источника многим адресатам. В принципе, можно было бы разработать единый протокол для управления любыми надежными многоадресными приложениями, но скорее всего, для новых классов надежных многоадресных приложений будет создано несколько различных протоколов. В конце прошлого года комитет IETF обратился к исследовательской группе Internet Research Task Force с просьбой взять на себя руководство разработкой стандартов Internet для надежной многоадресной передачи. Необходимо разработать хорошо отлаженные и эффективные протоколы для приложений каждого класса, а не единый обобщенный универсальный протокол, не обеспечивающий эффективной работы. Подобные специализированные многоадресные протоколы должны учитывать специфические требования каждого многоадресного приложения - в зависимости от топологии, масштаба, типа распространяемой информации и необходимости доставки в реальном времени.
Надежные многоадресные приложения
Рассмотрим в качестве примера совместные вычисления. Для их выполнения потребуется многоадресное приложение, обеспечивающее обмен информацией между многими участниками, причем их число даже в больших сеансах, скорее всего, не превышает 50 человек. В подобных приложениях требуется надежная доставка таких данных, как движения курсора по общей электронной "доске" или сигналы джойстика в интерактивных играх. Поскольку эти приложения работают в реальном времени, данные должны надежно доставляться в течение ограниченного времени.
Другим классом надежных многоадресных приложений является многоадресное распространение файлов. Это приложение типа "один источник - много адресатов" может охватывать многие тысячи получателей. В отличие от совместных вычислений и доставки данных в реальном времени передача файлов не относится к приложениям реального времени. Поскольку здесь не требуется соблюдать определенный временной интервал, для повторной передачи потерянных пакетов можно применить более эффективный метод. Вместо того чтобы непрерывно посылать отправителю запросы на повторную передачу, как это происходит в приложении реального времени, при передаче файлов получатели могут не посылать свои запросы на повторную передачу до тех пор, пока от отправителя не поступит приглашение. Это помогает предотвратить резкий рост числа запросов на повторную передачу от многих адресатов одному отправителю.
Корпорация StarBurst Communications разработала надежный многоадресный FTP-протокол (MFTP), в котором используется данная схема. Совместно с компанией Cisco Systems она представила соответствующую спецификацию в комитет IETF в качестве проекта нового стандарта.
Многоадресная IP-передача сулит существенное снижение требований к пропускной способности, поэтому важно, чтобы сетевые администраторы имели представление об этой относительно новой технологии и были в курсе разработок протоколов для надежной многоадресной передачи.
Многоадресные транспортные протоколы
Различные требования многоадресных приложений обуславливают необходимость в разработке нескольких протоколов многоадресной передачи.
Читайте также: