Есть ли у DDS брокер? - PullRequest
       23

Есть ли у DDS брокер?

2 голосов
/ 30 декабря 2011

Я пытался читать по стандарту DDS, в частности, по OpenSplice, и меня интересует архитектура.

Требуется ли для DDS запуск брокера или какого-либо конкретного демона для управления обменом сообщениями и координации между различными сторонами? Если я просто запустил один процесс, публикующий данные для темы, и запустил другой процесс, подписавшийся на ту же тему, достаточно ли этого? Есть ли какая-то причина, по которой может понадобиться другой процесс?

В альтернативе использует ли она многоадресную передачу UDP для какого-либо автоматического обнаружения между издателями и подписчиками?

В общем, я пытаюсь противопоставить это традиционным архитектурам очередей, таким как MQ Series или EMS.

Я бы очень признателен, если бы кто-нибудь мог помочь пролить свет на это.

Спасибо

Фахим

Ответы [ 3 ]

3 голосов
/ 31 декабря 2011

DDS не имеет центрального брокера, он использует протокол обнаружения на основе многоадресной рассылки.OpenSplice имеет модель со службой для каждого узла, но это деталь реализации, если вы, например, проверите RTI DDS, у них этого нет.

2 голосов
/ 16 февраля 2012

Спецификация DDS разработана таким образом, что реализации не должны иметь каких-либо центральных демонов. Но, конечно, это выбор реализации.

Такие реализации, как RTI DDS, MilSOFT DDS и CoreDX DDS, имеют децентрализованную архитектуру, которая является одноранговой и не требует каких-либо демонов. (Обнаружение выполняется с помощью многоадресной рассылки в сетях LAN). Эта конструкция имеет много преимуществ, таких как отказоустойчивость, низкая задержка и хорошая масштабируемость. Кроме того, это позволяет очень просто использовать промежуточное программное обеспечение, поскольку нет необходимости администрировать демоны. Вы просто запускаете издателей и подписчиков, а остальное автоматически обрабатывается DDS.

OpenSplice DDS раньше требовал, чтобы службы демонов работали на каждом узле, но они добавили новую функцию в v6, так что вам больше не нужны демоны. (Они все еще поддерживают опцию демона).

OpenDDS также одноранговый, но, насколько я знаю, ему нужен центральный демон, работающий для обнаружения.

1 голос
/ 23 июля 2013

Думаю, что действительно полезно проводить различие между архитектурой «централизованного посредника» (где этот посредник может быть / становится единственной точкой отказа) и услугой / демоном на каждой машине, которая управляет потоками трафика на основе DDS-QoS.такие как важность (DDS: транспортный приоритет) и срочность (DDS: бюджет задержки).

Интересно отметить, что большинство людей считает абсолютно необходимым иметь планировщик процессов (в режиме реального времени) на машине, которая управляет ЦП как критическим / общим ресурсом (на основевременная привязка, классы приоритетов и т. д.) Однако, когда дело доходит до DDS, который заключается в распространении информации (а не в обработке кода приложения), люди часто находят «странным», что « сетевой планировщик * 1006»* «пригодится» (наименьшее), которое управляет сетью (-интерфейсом) как разделяемым ресурсом и планирует трафик (на основе «упаковки», управляемой политикой QoS, и использования множества приоритетных полос трафика).

И это именно то, что делает OpenSplice при использовании своего (необязательного) режима федеративной архитектуры, где несколько приложений, работающих на одном компьютере, могут обмениваться данными с использованием сегмента общей памяти и где есть сетевая служба (демон) для каждого физического сетевого интерфейса, который планирует входящий и исходящий трафик на основена его фактические политики QoS срочности и важности.Тот факт, что такая служба имеет «доступ» ко всей узловой информации, также облегчает объединение различных выборок из разных тем из разных приложений в (потенциально большие) UDP-кадры, возможно, даже используя часть доступного бюджета задержки для этой «упаковки» ичто позволяет правильно сбалансировать эффективность (пропускную способность) и детерминизм (задержка / дрожание).Сквозной детерминизм, кроме того, облегчается за счет планирования трафика по заранее настроенным « приоритетным линиям » в форме трафика с «частными» потоками Rx / Tx и настройками DIFSERV.

Итакналичие демона network-scheduling-daemon на узел, безусловно, имеет некоторые преимущества (также поскольку оно отделяет сеть от неисправных приложений, которые могут быть либо «чрезмерно производительными», то есть взрывающими систему, либо «недостаточно реактивными», вызывая повторные передачи в масштабе всей системы.... аспект, который часто забывают, когда спорят о том, что «сетевой график-демон» можно рассматривать как «единую точку отказа», тогда как «другим представлением» может быть то, что без какого-либо арбитража любойавтономное»приложение, которое напрямую общается с проволокой можно рассматривать как потенциальную систему-нить, когда он начинает плохо себя так, как описано выше, по любой причине.

1014 * Во всяком случае .. его всегда спорный обсуждение, то почему OpenSplice DDS (какиз v6) поддерживает оба режима развертывания: федеративный и не федеративный (также called 'standalone' или 'single process').

Надеюсь, это несколько полезно.

...