Я читал следующее:
И кажется, что нет никакого benfit, использующего DDS вместо zmq:
Итак:
Спасибо
В моем (по общему признанию, предвзятом) опыте в качестве разработчика/поставщика DDS многие приложения находят значительные преимущества использования DDS по сравнению с промежуточными технологиями, включая ZeroMQ. На самом деле я вижу гораздо больше "критических приложений" с использованием DDS, чем ZeroMQ...
Сначала несколько пояснений:
(1) DDS и протокол RTPS, который он использует под стандартами, а не конкретные продукты. Существует множество реализаций этих стандартов. Насколько мне известно, существует как минимум 9 различных компаний, которые имеют независимые продукты и кодовые базы, которые реализуют эти стандарты. Не имеет смысла говорить о "производительности" DDS против ZeroMQ, вы можете говорить только о производительности конкретной реализации. Я рассмотрю проблему производительности позже, но с этой точки зрения ваше утверждение "латентность zmq лучше" явно неверно. Противоположное утверждение было бы точно так же неправильно, конечно.
(2) Я не нашел много объективной информации в первой ссылке, которую вы предоставили. Основной момент заключался в том, что DDS, по-видимому, наилучшим образом подходит для этого приложения, и существует обеспокоенность по поводу того, насколько широко он использовался, что ответ от AC разъяснил. Но аргументы казались немного субъективными. Был отрицательный ответ на публикацию AC, основанный на чьем-то субъективном изучении кодовой базы конкретного продукта. Даже если предположить, что лицо, опубликованное отрицательными комментариями, имеет действительный момент, комментарии будут применяться только к одной конкретной реализации/продукту DDS, а не к DDS в целом. Лично я не придавал бы большого значения этому комментарию, его тон кажется слишком враждебным, чтобы основываться только на указанных фактах.
(3) Что касается ясности/простоты API. Ваши комментарии основаны на стандартном примере, который вы указали во второй ссылке? Этот код не использует стандартные API DDS. Я не уверен, почему OCI (компания, которая написала эту статью) сделала это так - возможно, они адаптировали другой предыдущий код.
Хорошим местом для просмотра примеров API, которые соответствуют спецификации DDS, являются следующие:
В любом случае, как я упоминал позже, уровень абстракции, предоставляемый DDS и ZeroMQ, совсем другой, поэтому API не сопоставимы напрямую...
В ответ на конкретные вопросы.
1. Когда лучше использовать DDS?
Трудно дать короткий/объективный ответ на такой широкий вопрос. Я уверен, что ZeroMQ - хороший продукт, и многие люди счастливы. То же самое можно сказать о DDS.
Я думаю, что самое лучшее, что нужно сделать, это указать на некоторые различия и позволить людям решить, что для них важно.
DDS и ZeroMQ отличаются с точки зрения управления, экосистемы, возможностей и даже уровня абстракции.
Некоторые важные отличия:
1.1. Управление, стандарты и экосистема
DDS и RTPS являются открытыми международными стандартами из группы управления объектами (OMG). ZeroMQ - это "свободная структура, контролируемая ее вкладчиками".
Это означает, что существуют открытое управление и четкие процессы OMG, которые контролируют спецификацию и ее эволюцию, а также правила IPR.
ZeroMQ IPR менее ясна IMO. С их веб-страницы (http://zeromq.org/docs:features) они заявляют, что "ZeroMQ libzmq ядро принадлежит его вкладчикам" и "Организация ZeroMQ - это свободная конфедерация без четкой структуры власти, который в основном живет на GitHub. Страница Wiki-страницы организации объясняет, как кто-то может присоединиться к команде Владельцев, просто введя интересную работу".
Эта "свободная структура" может быть более проблематичной для пользователей, которые заботятся о таких вещах, как родословная прав интеллектуальной собственности, гарантия и компенсация и т.д.
Относительно этого. если я правильно понял, есть только одна основная реализация ZeroMQ (одна в github) и только компания, которая стоит за ней (iMatix). Оттуда, кажется, всего 4 коммиттера выполняют большую часть работы по разработке в ядре (libzmq). Если iMatix должен был быть приобретен или решил изменить свою бизнес-модель, или основные коммитеры потеряли интерес, пользователи немного обратились бы за поддержкой самой кодовой базы.
Конечно, существует много успешных проектов/технологий, основанных на совместной собственности на код. С другой стороны, наличие экосистемы компаний, конкурирующих с независимыми продуктами, кодовыми базами и бизнес-моделями, обеспечивает хорошую уверенность в будущем технологии... Все зависит от того, насколько велики сообщества и экосистемы, и насколько они не склонны к риску.
1.2 Особенности и уровень абстракции
Оба DDS и ZeroMQ поддерживают шаблоны, такие как publish-subscribe и Request-Reply (это новое дополнение к DDS, так называемому DDS-RPC). Но, вообще говоря, уровень абстракции DDS выше. что означает, что промежуточное программное обеспечение делает более "автоматически" для приложения. В частности.
DDS обеспечивает автоматическое обнаружение
В DDS вы просто публикуете/подписываетесь на названия тем. Вам никогда не придется указывать IP-адреса, имена компьютеров или порты. Все это обрабатывается встроенным открытием. И он делает это автоматически без дополнительных услуг. Это означает, что приложения могут быть повторно развернуты и интегрированы без перекомпиляции или реконфигурации.
ZeroMQ - более низкий уровень. Необходимо указать порты, IP-адреса и т.д.
DDS pub-sub является ориентированным на данные.
Приложение может публиковать в теме, но связанные данные могут представлять обновленные данные для нескольких объектов данных, каждый из которых идентифицируется ключевыми атрибутами. Например, при публикации позиций самолета каждое обновление может идентифицировать "идентификатор самолета", а промежуточное ПО может обеспечивать историю, обеспечивать QoS, скорость обновления и т.д. Для каждого самолета отдельно. Среднее ПО понимает и сообщает, когда появляются новые самолеты, или исчезает из системы.
В связи с вышеуказанным DDS может храниться кэш соответствующих данных для приложения, которое он может запрашивать (по ключу или содержимому) по своему усмотрению, например. читать последние 5 позиций самолета. Приложение уведомляется об изменениях, но оно не вынуждено немедленно их использовать. Это также может помочь уменьшить объем кода, который должен написать разработчик приложения.
DDS обеспечивает большую поддержку "приложения" QoS
DDS поддерживает более 22 политик QoS для доставки сообщений и данных, таких как надежность, конечная точка жизни, постоянство сообщений и доставка в поздние столяры, истечение срока действия сообщения, отказоустойчивость, мониторинг периодических обновлений, фильтрация по времени, упорядочение и т.д. Все они настроены с помощью простых параметров политики QoS. Приложение использует один и тот же API для чтения и записи, и вся дополнительная работа выполняется под ним.
ZeroMQ подходит к этой проблеме, предоставляя строительные блоки и шаблоны. Он довольно гибкий, но приложение должно программировать, собирать и настраивать различные шаблоны для получения поведения более высокого уровня. Например, чтобы получить надежный pub-sub, необходимо комбинировать несколько шаблонов, как описано в http://zguide.zeromq.org/page:all#toc119.
DDS поддерживает дополнительные возможности, такие как фильтрация содержимого, фильтрация времени, разделы, домены,...
Они недоступны в ZeroMQ. Они должны быть построены на уровне приложения.
DDS предоставляет систему типов и поддерживает расширяемость и изменчивость типов
Вам необходимо объединить ZeroMQ с другими пакетами, такими как буферы протокола google, чтобы получить аналогичную функциональность.
Безопасность
Существует спецификация DDS-Security, которая обеспечивает мелкозернистую (на уровне уровня) безопасность, включая аутентификацию, шифрование, подписку, распространение ключей, защищенную многоадресную рассылку и т.д.
2. Есть ли лучшая производительность DDS над ZMQ?
Обратите внимание, что те тесты, на которые вы ссылаетесь, предназначены для реализации Object Computing Inc "OpenDDS". Насколько я знаю, это, как известно, не является одной из самых быстрых реализаций DDS. Я бы порекомендовал вам взглянуть на некоторые из них, такие как RTI Connext DDS (наша реализация), PrimsTech OpenSplice DDS или CoreDX DDS от TwinOaks. Конечно, результаты очень зависят от фактического тестирования, сети и используемых компьютеров, но типичные показатели латентности для более быстрых реализаций DDS с использованием С++ составляют порядка 50 микросекунд, а не 180 микросекунд). См. https://www.rti.com/products/dds/benchmarks.html#CPPLATENCY
Уровни промежуточного ПО, такие как DDS или ZeroMQ, выполняются поверх таких вещей, как UDP или TCP, поэтому я ожидаю, что они связаны тем, что может сделать базовая сеть, и для простых случаев они, вероятно, не слишком разные, и они, конечно, будут быть хуже, чем сырьевой транспорт.
Отличия также исходят от того, какие услуги они предоставляют. Таким образом, вы должны сравнить то, что можете получить для одного и того же уровня обслуживания, например, надежно опубликовать масштабирование для многих потребителей, назначать приоритеты информации, отправлять несколько потоков и большие данные по UDP (чтобы избежать блокировки TCP-строки) и т.д.
Основываясь на исследовании OpenDDS, которое вы ссылаетесь, и относительной производительности различных реализаций DDS (http://www.dre.vanderbilt.edu/DDS/), я бы ожидал, что в тесте яблоки-яблоки более эффективные реализации DDS будут соответствовать или превышать ZeroMQ.
Тем не менее люди редко выбирают промежуточное ПО, которое дает им "лучшую производительность". В противном случае никто не будет использовать веб-службы или HTTP. Выбор основан на многих факторах, производительность должна быть такой же хорошей, как требуется для удовлетворения потребностей приложения. Для решения важны надежность, масштабируемость, поддержка, риск, ремонтопригодность, пригодность модели программирования для домена, общая стоимость владения и т.д.
3. Есть ли явная цель использования DDS (а не ZMQ)?
Ну, да... во многих приложениях он обеспечивает лучший компромисс с точки зрения производительности, масштабируемости, возможностей, простоты приложений, надежности, снижения рисков и общей стоимости владения. За последние несколько лет к такому выводу пришли тысячи проектов:)
Герардо