Какой протокол является наиболее эффективным для надежной многоадресной рассылки?

Question

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

Буду признателен за примеры из реальной жизни, и я с радостью приму субъективные ответы, т. Е. Какой ваш любимый протокол многоадресной рассылки, если вы сможете объяснить его плюсы и минусы.

Answer 1

Пример из реальной жизни: TIBCO Rendezvous.

Данные отправляются через многоадресную передачу с порядковым номером. Клиент, который обнаруживает отсутствующий порядковый номер, отправляет сообщение группе многоадресной рассылки «эй, я пропустил пакет 12345». Сервер повторно многоадресно передает эти данные. На сервере имеется настраиваемый объем данных для буферизации в случае, если клиент запрашивает его.

Проблема:

Представьте себе, что у вас есть один клиент, который отбрасывает половину своих пакетов, и 100 здоровых клиентов. Этот клиент отправляет запрос на повторную передачу для каждого другого пакета. Сервер начинает вызывать достаточную нагрузку на одного из исправных клиентов, так что он начинает отбрасывать пакеты и запрашивать повторные передачи. Дополнительная нагрузка приводит к тому, что другой исправный клиент начинает запрашивать повторные передачи. И так далее. Результатом коллапса заторов.

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

Другой обходной путь, ограничивающий риск возникновения перегрузки, - это ограничение объема данных, которые сервер готов повторно передать.

Tibco также должна обеспечить эвристику на клиенте и сервере в отношении того, следует ли выполнять многоадресную или одноадресную передачу запроса на повторную передачу, а также самой повторной передачи. Они не (Для сервера вы можете выполнить одноадресную ретрансляцию, если только один клиент запросил ее в определенном временном окне, для клиента вы можете выполнить индивидуальную передачу запроса на повторную передачу, если сервер сказал вам - в ретранслируемом пакете - что вы единственный, кто запрашивает повторные передачи и, пожалуйста, одноадресные запросы в будущем)

По сути, вам придется выбирать между тем, насколько сильно вы хотите гарантировать, что клиенты будут получать данные, и риском обрыва перегрузки. Вам нужно будет угадать, куда был отброшен пакет и была ли ретрансляция наиболее эффективно отправлена ​​в одноадресной или многоадресной рассылке. Если сервер понимает данные и может принять решение не отправлять повторную передачу, если обновленные данные все равно должны быть отправлены (что делает повторную передачу неактуальной), вы находитесь в гораздо лучшем положении, чем структура, такая как Tibco RV.

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

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

Answer 2

Как следует из протокола TIBCO, протокол PGM представляет собой надежную многоадресную рассылку открытого стандарта со множеством оптимизаций для эффективной работы в очень больших масштабах с ускорением сетевых элементов. PGM был разработан TIBCO и CISCO и является дополнительным протоколом под TIBCO Rendezvous, протокол по умолчанию TRDP, который очень похож по дизайну.

Вы можете рассчитать теоретическую эффективность, как указано здесь для PGM,

http://code.google.com/p/openpgm/wiki/PgmPerformance

К сожалению, реальные сетевые элементы, сетевые адаптеры и общие компьютерные архитектуры работают намного меньше теоретических максимумов.

Answer 3

Могу ли я предложить UFTP . Он использует механизм на основе NAK для определения того, какие пакеты следует повторно передать, и имеет возможность либо фиксированной скорости передачи, либо управления перегрузкой с использованием TFMCC .

Каждый файл отправляется в проходах, где при первом проходе передается весь файл, а при последующих проходах отправляются только повторные передачи. Каждый клиент отслеживает, какие пакеты он получил, а какие пропустил. В определенных контрольных точках (и в конце прохода), если получатель пропустил какие-либо пакеты со времени последней контрольной точки, он отправит NAK, перечисляющий пропущенные пакеты. Это имеет преимущество в том, что приемники с низкими потерями будут заканчиваться раньше, чем приемники с высокими потерями. UFTP также может быть настроен для отбрасывания получателей, процент NAK которых превышает определенный порог.

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

Раскрытие: автор УФТП.

Answer 4

http://www.jgroups.org/

Answer 5

BitTorrent!

Нет, серьезно. Возможно, вы захотите прочитать об этом .

UDP полезен для многоадресной рассылки, но он не дает требуемых гарантий - BitTorrent потребует от вас передачи более одной полной копии из исходного источника, но он все еще довольно эффективен и предоставляет полезные гарантии, особенно с учетом сколько контрольной суммы выполняется для каждого «фрагмента» передаваемых данных.

Answer 6

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

Answer 7

Это открытый вопрос исследования; Существуют коммерческие решения, но они чрезмерно дороги. Удачи.