Есть ли у DDS брокер?
Я пытался прочесть о стандарте DDS, и в частности об OpenSplice, и меня интересует архитектура.
Требует ли DDS, чтобы был запущен брокер или какой-либо конкретный демон для управления обменом сообщениями и координации между различными сторонами? Если я просто запустил один процесс, публикующий данные для темы, и запустил другой процесс, подписавшийся на ту же тему, достаточно ли этого? Есть ли какая-то причина, по которой может понадобиться запустить другой процесс?
В качестве альтернативы использует ли она многоадресную передачу UDP для какого-либо автоматического обнаружения между издателями и подписчиками?
В общем, я пытаюсь противопоставить это традиционным архитектурам очередей, таким как MQ Series или EMS.
Я был бы очень признателен, если бы кто-нибудь мог помочь пролить свет на это.
Спасибо,
Фахим
3 ответа
У DDS нет центрального брокера, он использует протокол обнаружения на основе многоадресной рассылки. OpenSplice имеет модель со службой для каждого узла, но это деталь реализации, если вы посмотрите, например, на RTI DDS, у них этого нет.
Подумайте, действительно ли хорошо проводить различие между архитектурой "централизованного посредника" (где этот посредник может быть / становится единственной точкой отказа) и сервисом / демоном на каждой машине, который управляет потоками трафика на основе DDS-QoS, например важности (DDS: транспортный приоритет) и срочность (DDS: бюджет задержки).
Интересно отметить, что большинство людей считают абсолютно необходимым иметь (в режиме реального времени) планировщик процессов на машине, которая управляет ЦП как критическим / общим ресурсом (на основе временного среза, классов приоритетов и т. Д.), Но когда Что касается DDS, который занимается распространением информации (а не обработкой кода приложения), людям часто бывает "странно", что "сетевой планировщик" оказывается "удобным" (наименьшим), который управляет сетью (- интерфейс) в качестве общего ресурса и планирует трафик (на основе "упаковки", управляемой политикой QoS, и использования множества полос трафика в форме трафика).
И это именно то, что делает OpenSplice при использовании своего (необязательного) режима федеративной архитектуры, когда несколько приложений, работающих на одном компьютере, могут обмениваться данными с использованием сегмента общей памяти, и где есть сетевая служба (демон) для каждой физической сети. -интерфейс, который планирует входящий и исходящий трафик на основе его фактических политик QoS срочности и важности. Тот факт, что такой сервис имеет "доступ" ко всей узловой информации, также облегчает объединение различных выборок из разных тем из разных приложений в (потенциально большие) UDP-кадры, возможно, даже используя часть доступного бюджета задержки для этой "упаковки" и что позволяет правильно сбалансировать эффективность (пропускную способность) и детерминизм (задержка / дрожание). Сквозной детерминизм, кроме того, облегчается планированием трафика через предварительно сконфигурированныеприоритетные полосы в форме трафика с "частными" потоками Rx/Tx и настройками DIFSERV.
Таким образом, наличие демона network-scheduling-daemon для каждого узла, безусловно, имеет некоторые преимущества (также, поскольку оно отделяет сеть от неисправных приложений, которые могут быть либо "чрезмерно производительными", то есть разрушающими систему, либо "недостаточно реактивными", вызывая повторные передачи в масштабе всей системы.... аспект, который часто забывают, когда спорят о том, что "сетевой график-демон" можно рассматривать как "единую точку отказа", тогда как "другой взгляд" может заключаться в том, что без какого-либо арбитража любой "Автономное" приложение, которое напрямую общается с проводом, может рассматриваться как потенциальный системный поток, когда оно начинает работать не так, как описано выше по ЛЮБОЙ причине.
Во всяком случае.. его всегда спорное обсуждение, то почему OpenSplice ДДС (по v6) поддерживает режимы развертывания: федеративные и не федеративные (также называемые "автономные" или "один процесс").
Надеюсь, это несколько полезно.
Спецификация DDS разработана таким образом, что реализации не должны иметь каких-либо центральных демонов. Но, конечно, это выбор реализации.
Такие реализации, как RTI DDS, MilSOFT DDS и CoreDX DDS, имеют децентрализованные архитектуры, которые являются одноранговыми и не требуют каких-либо демонов. (Обнаружение выполняется с помощью многоадресной рассылки в сетях LAN). Эта конструкция имеет много преимуществ, таких как отказоустойчивость, низкая задержка и хорошая масштабируемость. Кроме того, это очень упрощает использование промежуточного программного обеспечения, поскольку нет необходимости администрировать демоны. Вы просто запускаете издателей и подписчиков, а остальное автоматически обрабатывается DDS.
OpenSplice DDS раньше требовал, чтобы службы демонов работали на каждом узле, но они добавили новую функцию в v6, чтобы вам больше не нужны демоны. (Они все еще поддерживают опцию демона).
OpenDDS также одноранговый, но, насколько я знаю, ему нужен центральный демон, работающий для обнаружения.