я прочитал следующее:ПОЧЕМУ/КОГДА используется скорее DDS вместо ZeroMQ?
И, кажется, что нет benfit с помощью ДДС вместо zmq:
Итак:
Благодаря
В моем (по общему признанию, предвзятый) опыт работы в качестве DDS реализатора/поставщика много приложений найти существенные преимущества использования ДДСА более промежуточные уровень технологий, в том числе ZeroMQ. На самом деле я вижу много больше «критических приложений» с помощью DDS, чем ZeroMQ ...
Первая пара уточнений:
(1) ДДС и протокол RTPS он использует под стандарты, а не конкретные продукты. Существует множество реализаций этих стандартов. Насколько мне известно, существует как минимум 9 различных компаний, которые имеют независимые продукты и кодовые базы, которые реализуют эти стандарты. Не имеет смысла говорить о «производительности» DDS против ZeroMQ, вы можете говорить только о производительности конкретной реализации. Я рассмотрю проблему производительности позже, но с этой точки зрения ваше утверждение «латентность zmq лучше» явно неверно. Разумеется, противоположное утверждение было бы совершенно неправильным.
(2) Я не нашел много объективной информации в первой ссылке, которую вы указали. Основной момент заключался в том, что DDS, по-видимому, наилучшим образом подходит для этого приложения, и существует обеспокоенность по поводу того, насколько широко он использовался, что ответ от AC разъяснил. Но аргументы казались немного субъективными. Был отрицательный ответ на публикацию AC, основанный на чьем-то субъективном изучении кодовой базы конкретного продукта. Даже если предположить, что лицо, опубликованное отрицательными комментариями, имеет действительный момент, комментарии будут применяться только к одной конкретной реализации/продукту DDS, а не к DDS в целом. Лично я не придавал бы большого значения этому комментарию, его тон кажется слишком враждебным, чтобы основываться только на указанных фактах.
(3) Что касается ясности/простоты API. Ваши комментарии основаны на стандартном примере, который вы указали во второй ссылке? Этот код не использует стандартные API DDS. Я не уверен, почему OCI (компания, которая написала эту статью) сделала это так - возможно, они адаптировали другой предыдущий код.
Хорошее место, чтобы посмотреть примеры API, которые совместимые со спецификацией ДДСА являются следующими:
В любом случае, как я упоминание позже, уровень абстракции, предоставляемый DDS и ZeroMQ, совсем другой, поэтому API не сопоставимы напрямую ...
В ответ на конкретные вопросы.
1. Когда лучше использовать DDS?
Трудно дать короткий/объективный ответ на такой широкий вопрос. Я уверен, что ZeroMQ - хороший продукт, и многие люди счастливы. То же самое можно сказать о DDS.
Я думаю, что самое лучшее, что нужно сделать, это указать на некоторые из различий и позволить людям решить, что для них важно.
DDS и ZeroMQ отличаются с точки зрения управления, экосистемы, возможностей и даже уровня абстракции.
Некоторые важные отличия:
1,1 управления, стандарты & экосистем
ДДС и ИУП открытые международные стандарты от объекта Management Group (OMG). ZeroMQ - это «свободная структура, контролируемая ее вкладчиками».
Это означает, что есть открытое управление и четкие процессы OMG, которые контролируют спецификацию и ее эволюцию, а также правила IPR.
ZeroMQ IPR менее ясна ИМО. На их веб-странице (http://zeromq.org/docs:features) говорится: «Ядро libzmq ZeroMQ принадлежит его вкладчикам» и «Организация ZeroMQ - это свободная конфедерация без четкой структуры власти, которая в основном живет на GitHub. Страница Wiki-страницы организации объясняет, как кто-либо может присоединиться к Собственная команда просто привнесла интересную работу ».
Эти «свободная структура» может быть более проблематичной для пользователей, которые заботятся о том, как IPR породистой, гарантия и компенсация и т.д.
, связанные с этим. если я правильно понял, есть только одна основная реализация ZeroMQ (одна в github) и только компания, которая стоит за ней (iMatix). Оттуда, кажется, всего 4 коммиттера выполняют большую часть работы по разработке в ядре (libzmq). Если iMatix должен был быть приобретен или решил изменить свою бизнес-модель, или основные коммитеры потеряли интерес, пользователи немного обратились бы за поддержкой самой кодовой базы.
Конечно, существует много успешных проектов/технологий, основанных на совместной собственности на код. С другой стороны, наличие экосистемы компаний, конкурирующих с независимыми продуктами, кодовыми базами и бизнес-моделями, обеспечивает хорошую уверенность в будущем технологии ... Все зависит от того, насколько велики сообщества и экосистемы, и насколько они не склонны к риску.
1.2 Особенности & уровень абстракции
Оба DDS и ZeroMQ поддержка шаблонов, как публикация-подписка и Request-Reply (это новое дополнение к СОД, так называемой ДДС-RPC). Но, вообще говоря, уровень абстракции DDS выше. что означает, что промежуточное программное обеспечение делает более «автоматически» для приложения. В частности.
DDS обеспечивает автоматическое обнаружение
В DDS вы просто Publish/Subscribe для имен темы. Вам никогда не придется указывать IP-адреса, имена компьютеров или порты. Все это обрабатывается встроенным открытием. И он делает это автоматически без дополнительных услуг. Это означает, что приложения могут быть повторно развернуты и интегрированы без перекомпиляции или реконфигурации.
ZeroMQ - нижний уровень. Необходимо указать порты, IP-адреса и т. Д.
DDS pub-sub ориентирован на данные.
Приложение может публиковать в теме, но связанные данные могут быть обновлены до нескольких объектов данных, каждый из которых идентифицируется ключевыми атрибутами. Например, при публикации позиций самолета каждое обновление может идентифицировать «идентификатор самолета», а промежуточное ПО может обеспечивать историю, обеспечивать QoS, скорость обновления и т. Д. Для каждого самолета отдельно. Среднее ПО понимает и сообщает, когда появляются новые самолеты, или исчезает из системы.
В связи с вышеуказанным DDS может храниться кэш соответствующих данных для приложения, которое он может запрашивать (по ключу или содержимому) по своему усмотрению, например, читать последние 5 позиций самолета. Приложение уведомляется об изменениях, но оно не вынуждено немедленно их использовать. Это также может помочь уменьшить объем кода, который должен написать разработчик приложения.
DDS обеспечивает дополнительную поддержку для "применения" QoS
DDS поддерживает более 22 политики сообщений и данных доставки QoS, такие как надежность, Endpoint живость, Message Постоянство и поставка конце-столяров, истечения срока действия сообщения, Отказоустойчивость, мониторинг периодических обновлений, фильтрация по времени, заказ и т. Д. Все они настроены с помощью простых параметров политики QoS. Приложение использует один и тот же API для чтения и записи, и вся дополнительная работа выполняется под ним.
ZeroMQ подходит к этой проблеме, предоставляя строительные блоки и паттеры. Он довольно гибкий, но приложение должно программировать, собирать и настраивать различные шаблоны для получения поведения более высокого уровня. Например, чтобы получить надежный pub-sub, необходимо комбинировать несколько шаблонов, как описано в http://zguide.zeromq.org/page:all#toc119.
DDS поддерживает дополнительные возможности, такие как контент-фильтрация, время фильтрация, перегородки, домены ...
Они не доступны в ZeroMQ. Они должны быть построены на уровне приложения.
DDS обеспечивает систему типов и поддерживает тип расширяемость и переменчивость
Вы должны объединить ZeroMQ с другими пакетами типа буферов протокола Google, чтобы получить аналогичную функциональность.
безопасность
Существует спецификация ДДСА-Security, которая обеспечивает мелкозернистую (Тема уровня) безопасность, включая аутентификацию, шифрование, подпись, распределение ключей, безопасную многоадресную рассылку и т.д.
2 . Лучше ли производительность DDS над ZMQ?
Обратите внимание, что этапы, на которые вы ссылаетесь, предназначены для реализации ObjectDirect Object Computing Inc. Насколько я знаю, это, как известно, не является одной из самых быстрых реализаций DDS. Я бы порекомендовал вам взглянуть на некоторые из них, такие как RTI Connext DDS (наша реализация), PrDSTech OpenSplice DDS или CoreDX DDS от TwinOaks. Конечно, результаты очень зависят от фактического тестирования, сети и используемых компьютеров, но типичные показатели латентности для более быстрых реализаций DDS с использованием C++ составляют порядка 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)?
Ну, да ... во многих приложениях он обеспечивает лучший компромисс с точки зрения производительности, масштабируемости, возможностей, простоты приложений, надежности, снижения риска и общей стоимости владения. В последние несколько лет тысячи проектов пришли к такому выводу :)
Херардо
Хорошая работа, Херардо. Спасибо как за обмен, так и за шедевр аргументации и популяризации в области, где несколько SLOC создают иллюзию того, как подойти к чему угодно. **БЛАГОДАРЯ** – user3666197
угадать вашу деталь [3] прочтет утвердительной, как ** '" я могу использовать ZMQ ... для передачи данных между потоками/процессами/station "' ** (С полным уважением, если вы все еще настаиваете на опубликованном негативе, то это определенно не из-за ZeroMQ) PF2015 – user3666197
Да, в основном, опиум основан, но это тот тип информации, который использовался для создания stackoverflow полезного. было бы интересно услышать мнение с другой стороны. –