LINUX.ORG.RU

Вышла версия 2.0.6 системы передачи сообщений ØMQ

 messaging middleware,


0

0

ØMQ - легковесная реализация системы асинхронной передачи сообщений. Отличительными чертами являются программный интерфейс, схожий с BSD-сокетами, а также преднамеренный отказ от использования специальных серверов-брокеров для устранения единой точки отказа.

В качестве транспортных протоколов поддерживаются TCP, PGM (надёжный мультикаст) и IPC (Unix-сокеты, разделяемая память). Система поддерживает различные конфигурации обмена сообщениями, например точка-к-точке (point-to-point), подписка (publish-subscribe), запрос-ответ (request-reply), параллельный конвейер (paralellized pipeline) и другие.

ØMQ обладает низкими задержками: 13.4 мкс из (конца в конец), и высокой пропускной способностью: 4,100,000 сообщений в секунду. ØMQ работает на процессорах x86, AMD64, SPARC, IA-64, ARM под операционными системами HP-UX, Linux, Mac OS X, *BSD, OpenVMS, Solaris, Windows.

Исходники (на языке C++) доступны по лицензии LGPL, а крайне простой внешний API на C привел к созданию большого числа биндингов к различным языкам: Common Lisp, Haskell, Java, Lua, Python, Ruby, C#.

В этой версии все привязки к языкам были вынесены в отдельные проекты, переписана документация, добавлена поддержка новых ОС (FreeBSD, NetBSD, HP-UX и Cygwin), упрощён процесс сборки, добавлен новый тип соединения (peer-to-peer), реализован контроль над потоком сообщений (watermarks), а также проведены многочисленные оптимизации и исправления ошибок.

>>> Подробности

★★★★★

Проверено: svu ()
Последнее исправление: svu (всего исправлений: 1)

Ответ на: комментарий от I-Love-Microsoft

> А разве D-BUS работает между разными компьютерами???

Работает.

Кроме того, пока нету QtDBUS для винды кажется... жаль...

А KDE на виндах, по твоему, как работает?

Aceler ★★★★★
()
Ответ на: комментарий от Displacer

Затем, что похоже проще, чем CORBA.

0MQ - это не ORB.

mv ★★★★★
() автор топика
Ответ на: комментарий от boo32

на языке C++

такие вещи лучше на си, имхо.

Там Си с классами. Причём, классов очень мало.

mv ★★★★★
() автор топика
Ответ на: комментарий от mv

>>Такой результат, iirc, был получил в Интеловской лабе на спец.железе.

На кубическом компютере по 10см гранями и в весом в 1кг?

White_Mouse
()
Ответ на: комментарий от White_Mouse

На кубическом компютере по 10см гранями и в весом в 1кг?

И в 10-мерном пространстве.

mv ★★★★★
() автор топика
Ответ на: комментарий от mv

> На кубическом компютере по 10см гранями и в весом в 1кг?

И в 10-мерном пространстве.

при помощи парового пресса

shty ★★★★★
()

Асько и жаберо капец близок

elf
()

Хорошая библиотека, в связке с google Protocol Buffer является хорошим и эффективным средством передачи структур данных между приложениями, использую ее еще с версии zmq 0.6. При проектировании приложений нужно учитывать, что доставка мессаг не гарантируется.

Так же очень радует поддержка. Обнаруженные баги оперативно фиксятся.

pavel5
()

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

«While traditional messaging systems tend to use one of the models described above („broker“ model in most cases) ØMQ is more of a framework that allows you to use any of the models or even combine different models to get the optimal performance/functionality/reliability ratio».

Во-первых, «асинхронность» - лишь один из вариантов, т.е. не главная заслуга «диаметрMQ» (вариант «запрос-ответ»). Во-вторых, брокер(посредник) таки есть! Отсюда минус ещё одно «преимущество» «диаметрMQ»: «отсутствие узкого места» - оно таки есть! И в случае отказа, страдает аналогично broker модели. Третье - это непонятное «lightweight»: давайте уже либо конкретно укажем, за счёт чего «облегчился» «диаметрMQ», либо не будем писать лишние buzzwords.

Вощем, «диаметрMQ» - очередной классный велосипед. Возможно, в лучшей реализации, чем идиотичная Corba, но это всё надо писать и проверять - отклик, размеры сообщений, надёжность... Не зря коммерческие системы настолько «медлительные» - реализация полноценных очередей не может быть «легковесной».

matumba ★★★★★
()

Не-ANSI символы не люблю.

zenden
()
Ответ на: комментарий от matumba

>Вощем, «диаметрMQ» - очередной классный велосипед. Возможно, в лучшей реализации, чем идиотичная Corba, но это всё надо писать и проверять - отклик, размеры сообщений, надёжность... Не зря коммерческие системы настолько «медлительные» - реализация полноценных очередей не может быть «легковесной».

Если с чем и сравнивать «идиотичную корбу», то с ейным «похудевшии» вариантом - ZerocICE))) Но «вощем» да. С 0MQ может получиться так же: «Дррр! - сказала японская лесопилка. Ага! - сказали архангельские мужыки и пошли дальше пилить... » IBM-ный MQ и тошнить в пакетик.

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

> Чем лучше?

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

boo32
()
Ответ на: комментарий от mv

> Там Си с классами. Причём, классов очень мало.

я успокоен, спасибо :).

boo32
()
Ответ на: комментарий от matumba

Во-первых, «асинхронность» - лишь один из вариантов, т.е. не главная заслуга «диаметрMQ» (вариант «запрос-ответ»).

Фреймворк асинхронный.

Во-вторых, брокер(посредник) таки есть!

Укажите, где в 0MQ брокер.

Третье - это непонятное «lightweight»: давайте уже либо конкретно укажем, за счёт чего «облегчился» «диаметрMQ», либо не будем писать лишние buzzwords.

За счёт отказа от задач, непосредственно не связанных с обменом сообщений.

Возможно, в лучшей реализации, чем идиотичная Corba

Вы ORB и MOM не путаете?

mv ★★★★★
() автор топика
Ответ на: комментарий от pavel5

Икаса еще рекламировал, «хорошую библиотеку» и гуглобуфера для обоснования отказа от поддержки WCF в mono. Через пару годиков прозрел, однако... Под довлением спонсоров)))

Ну и «гуры КОРБЫ» как всегда находят чем порадовать:

http://steve.vinoski.net/blog/2008/07/11/protocol-buffers-no-big-deal/ http://steve.vinoski.net/blog/2008/07/13/protocol-buffers-leaky-rpc/

slackwarrior ★★★★★
()
Ответ на: комментарий от boo32

>аргументы на уровне «теплее и ламповее», конечно.

Идеалы такие идеалы) В конкретной реализации IBM MQ, C++ обертка хотя бы выглядит не так страшно, как Си-шный API. Доки на ихнем сайте вообще моск выносят (главным образом версткой)))

slackwarrior ★★★★★
()

И вообще, где Мужык-2 с рекламой MSMQ?

slackwarrior ★★★★★
()
Ответ на: комментарий от matumba

>у кого-то английский хуже, чем русский
У тебя, похоже :)

«While traditional messaging systems tend to use one of the models described above („broker“ model in most cases) ØMQ is more of a framework that allows you to use any of the models or even combine different models to get the optimal performance/functionality/reliability ratio»

Тогда как традиционные системы сообщений стремятся использовать одну из моделей описанных выше (модель «брокеров» в большинстве случаев) ØMQ больше похож на фреймворк, который позволяет вам использовать любую из моделей или даже объединять разные модели чтобы получить оптимальное соотношение производительности/функциональности/надежности

eugene2k
()
Ответ на: комментарий от slackwarrior

>man middleware.

никто так и не может объяснить что это и для каких целей применяется, полагаю.

когда человек посылает читать некие маны или в гугл это означает что он сам не понимает

Асечки и чятики для офиса тут вообще непричом... Или где-то сбоку.

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

tommy ★★★★★
()
Ответ на: комментарий от tommy

>никто так и не может объяснить что это и для каких целей применяется, полагаю. Солипсизм такой солипсизм.

когда человек посылает читать некие маны или в гугл это означает что он сам не понимает

Капчу дяди Брина неасилил?

ну ты сказал.
почта - это...

До-до. Спасибо кэп. So what? Какое отношение частный случай всей этой клиентской прикладухи имеет к обсуждению очередного MQ фреймворка? Купи весы, начни бегать по утрам... Хотя бы по ссылкам.

без асек работа офисов и контор остановится.

Не. Производительность временно резко повысится.:) Особенно в офисах и конторах, где непуганых клерков богато.

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

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

хотя вы всё равно не сможете внятно ответить. потому что вероятно всё это можно сделать проще и надёжнее используя инструменты суть работы и применения которых можно легко объяснить.

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

tommy ★★★★★
()
Ответ на: комментарий от tommy

Да, конечно. Датацентры создаются специально для тех приложений, которым позарез нужна низкая латентность сетевых коммуникаций - для достижения высоких значений TPS (биржевая торговля и т.п.) или просто высокой производительности. В противном случае собственный хостинг + вебсервисы/корба/mq пока еще предпочтительнее хотя бы по соображениям безопасности.

– Low latency, small messages, multicast, thin envelopes, no security, no persistence.

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

aist1 ★★★
()
Ответ на: комментарий от tommy

>ты понимаешь применение этого инструмента - другие нет. не у всех такая работа - писать нечто непонятно что используя «MQ фреймворк»-и

клиентам как раз понятно - они ж заказали)

хотя вы всё равно не сможете внятно ответить. потому что вероятно всё это можно сделать проще и надёжнее используя инструменты суть работы и применения которых можно легко объяснить

Ты внятно определись, ты на «вы» или вы на «ты»? Упомянутые вами применения - частный случай (который да, можно сделать проще, что собственно в случае IM-клиентов и происходит. (Что-то навскидку не припоминаю, где там применяется MOM, между серваками разве что) На танке клопов давить обычно не ездят. Хотя биржевую инфу клиентам через аську (или почтой) тоже обычно не доставляют. (Или спаморезка умрет, не успев понять, «что это было?», или почтовый сервак упадет, подавившись, бедненький, несколькими гигами чьих-то сделок)). В общем, если кратко, чаще это софт не для личного общения p2p (Вася-Вася), а для «общения» b2b (Бизнес-Бизнес) - с автоматической прокачкой вагонов нужной конторам инфы.

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

Еще с tommy чятиться на ЛОРе. Хочешь(те) еще об этом поговорить?

slackwarrior ★★★★★
()
Ответ на: комментарий от tommy

> в паре фраз описать можно?

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

просто любой конкретный пример применения.

на гипотетической АЗС, к примеру, конфа на одинэс взаимодействует с программой управления заправочным оборудованием посредством подобного middleware.

boo32
()
Ответ на: комментарий от MS

Конец там не очень длинный. Судя по величине латентности, там был InfiniBand + RDMA. Но утверждать не возьмусь))

aist1 ★★★
()

Там насколько я понял нет гарантии доставки сообщений и нет персистентности. Нафига такая штука вообще нужна в труэнтерпрайзе? Где она может быть полезнее RabbitMQ?

anonymous
()

В дебиан её ещё вообще нет, как я понимаю?

sv75 ★★★★★
()

Потратил пару часов на беглый осмотр, судя по всему супер круть, обязательно попробую, когда дойдет дело до оптимизации rpc-механизмов в проекте!

Автор, я правильно понимаю, если мне нужен req-rep с балансировкой, мне нужно на каждом узле-клиенте поддерживать список узлов-серверов? Брокера-то нет. И если появляется в кластере один узел нужно обновлять конфигурации всех клиентов, чтобы они начали его видеть? Или можно как-то проще?

anonymous
()
Ответ на: комментарий от anonymous

MQ4CPP

> И если появляется в кластере один узел нужно обновлять конфигурации всех клиентов, чтобы они начали его видеть? Или можно как-то проще?

Если не брезгуешь C++, то лучше возьми MQ4CPP (MOM). Там всё автоматически настраивается плюс есть ещё пара-тройка хороших плюшек типа MemoryChannel, синхронный и асинхронный вызовы, гарантия доставки и т.п. http://www.sixtyfourbit.org/mq4cpp.htm

Ptomaine
()
Ответ на: комментарий от melkor217

>Моя альфа с Tru64 UNIX как всегда в пролёте (

Скомпилируй и потести. Надежда всегда есть)

annulen ★★★★★
()
Ответ на: комментарий от slackwarrior

>В конкретной реализации IBM MQ, C++ обертка хотя бы выглядит не так страшно, как Си-шный API.

я лично не знаю случаев, когда с++ API был бы страшнее сишного

annulen ★★★★★
()
Ответ на: комментарий от boo32

>на гипотетической АЗС, к примеру, конфа на одинэс взаимодействует с программой управления заправочным оборудованием посредством подобного middleware.

типа того что у одной АЗС есть доступ к инету (или просто куда то дальше), а у другой - нет. и вторая использует первую для связи с центром? так оно так может без старанных ненадёжных посредников типа 0MQ.

tommy ★★★★★
()
Ответ на: комментарий от slackwarrior

>В общем, если кратко, чаще это софт не для личного общения p2p (Вася-Вася), а для «общения» b2b (Бизнес-Бизнес) - с автоматической прокачкой вагонов нужной конторам инфы.

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

tommy ★★★★★
()
Ответ на: комментарий от boo32

"

Области применения middleware

Наиболее часто в разговоре о промежуточном ПО возникает вопрос, какое ППО должно быть применено в тех или иных случаях. Сама постановка этого вопроса показывает, что сомнений в том, применять ППО или нет, остается все меньше и меньше ..."

ну та же вода что и тут. ну типа круто, чувак! ты заинтересовался - значит надо тебе это использовать.

tommy ★★★★★
()
Ответ на: Ø от scaldov

Kan du triforce?

anonymous
()
Ответ на: комментарий от BSD

>Так кто-нибудь объяснит для чего эта вещь? Аналог D-BUS'а?
для этого надо читать Танненбаума, но уже книжку про распределённые системы

dimon555 ★★★★★
()
Ответ на: комментарий от anonymous

Автор, я правильно понимаю, если мне нужен req-rep с балансировкой, мне нужно на каждом узле-клиенте поддерживать список узлов-серверов? Брокера-то нет. И если появляется в кластере один узел нужно обновлять конфигурации всех клиентов, чтобы они начали его видеть? Или можно как-то проще?

Можно req делать по pgm, чтобы все узлы его видели. С единственным rep сложнее, т.к. серверам нужно договориться, кто из них будет отвечать. Без знания топологии это будет несколько сложно. У Таненбаума в книжке однозначного ответа, кстати, нет.

mv ★★★★★
() автор топика
Ответ на: комментарий от atrus

AMQP мало где нужен.

Почему?

Потому что не всем нравится, что с протоколом случилось после версии 0-8.

mv ★★★★★
() автор топика
Ответ на: комментарий от Aceler

> Работает.

Это хорошо, не знал. Между различными ОС стало быть работает?

А KDE на виндах, по твоему, как работает?

Только сейчас заметил в Qt Creator 1.3.1 при создании программы для GUI доступен QtDBUS. Буквально недавно наблюдал в документации ахтунги что это технология доступна только для UNIX... Неужели там вообще нет никаких проблем с этим модулем под виндой?

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от tommy

> типа того что у одной АЗС есть доступ к инету (или просто куда то дальше), а у другой - нет. и вторая использует первую для связи с центром? так оно так может без старанных ненадёжных посредников типа 0MQ.

связь с интернетом тут вообще не в тему. связывается одинэс с оборудованием в рамках локальной сети (и выхода у этой сети в интернет нет ни в коем случае). а «странные посредники» - это как раз _надёжные_ посредники (ценность их именно в надёжности). ты же тролль, да?

boo32
()
Ответ на: комментарий от tommy

> ну та же вода что и тут.

примеры middleware из статьи в виде corba, com/dcom, ibm mqseries, microsoft msmq ты до сих пор не смог отличить от асечки и битторента? не понятна твоя настойчивость, с которой ты повторяешь «я нифига не понял». ты пытаешься выбить пособие по инвалидности?

boo32
()
Ответ на: комментарий от boo32

>связывается одинэс с оборудованием в рамках локальной сети

а эта p2p образная хрень тогда зачем? почему не просто протокол взаимодействия а надо какой то распределённый (куда то там непонятно зачем)

и выхода у этой сети в интернет нет ни в коем случае

при проложенном туннеле - почему нет. но ладно, интранет, что угодно.

а «странные посредники» - это как раз _надёжные_ посредники

тут как раз пишут что гарантии доставки нет.

ты же тролль, да?

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

tommy ★★★★★
()
Ответ на: комментарий от boo32

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

tommy ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.