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)

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

> почему не просто протокол взаимодействия

протокол взаимодействия есть, построенный как раз поверх модели сообщений (mom).

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

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

только бы не приводить примеры применения.

я привёл же: компонента А системы (одинэска) связана с кучей экземпляров компоненты Б (заправочных колонок) посредством подобного middleware. так же в первой строчке результата гугления есть ссылка на вики: http://ru.wikipedia.org/wiki/Подпрограммное_обеспечение#.D0.9F.D1.80.D0.B8.D0...

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

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

это похоже на обывателя, рассуждающего о том, что «напридумывали тут всяких ЭВМ, когда давно уже есть амбарная книжка и счёты».

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

http://technet.microsoft.com/ru-ru/library/cc738386(WS.10).aspx - тут пример перечня возможностей, предоставляемых подобными middleware. надеюсь, хотя бы несколько пунктов ты будешь способен оценить по полезности и трудоёмкости в реализации.

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

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

если надо просто распаралелить работу одного приложения/сервера так что-бы к нему не обращались с миллионами запросов и не «укладывали» его - другое дело. наверное просто прослойка в виде сервера или кластера будет надёжнее.

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

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

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

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

вот как было с C++ - костыли костылями. пытались объяснить что это нужно и полезно - но тщетно. припарка и нормальному языку только тормозящая всё и приводящая к феерическим глюкам при ошибках в коде. но вот придумали Qt - и все поняли для чего нужен C++. всего лишь надо было создать удобный тулкит который задействует даже ещё больше возможностей чем планировалось изначально в C++.

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

> если кто-то не может внятно объяснить

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

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

ну похоже разговор окончен. впаривайте клиентам маны и гуглы по middleware. хоть бы в спорах на LOR-е научились внятно объяснять что-то.

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

> впаривайте клиентам маны и гуглы по middleware.

клиентам впаривают не middleware, а работу по интеграции их парка программного обеспечения. и какими средствами это будет сделано, для клиента, в общем случае, не важно. или ты привык впариваешь своим клиентам qt и си++, когда им нужна программа для заполнения векселей?

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

> хоть бы в спорах на LOR-е научились внятно объяснять что-то.

Два раза уже дали ссылку на презентацию, в которой на пальцах описано что это, зачем нужно, и чем отличается от enterprise-решений типа MQSeries/AMQP.

Человеку, которому лениво пройти по ссылке и посмотреть презентацию, наверное просто не особо интересен обсуждаемый предмет :)

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

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

Расскажите о своих опасениях клиентам биржевых площадок. И их клиентам, внезапно, тоже. Только «гигоф чужого трафика» не через, а для них. За доступ к этой инфе, во-первых, заплатят сами, во-вторых, отобьются на клиентах - и будут щасливы. Но вы-то, конечно, лучше знаете, как пилить бабло. Поучите дядей-то, поучите. (Опубликуйте на ЛОРе, например, свои представления об оптимальности, например. «Хоть бы один» (с) Или не уверены, что они оптимальны?)

выбить пытаются бабло крупные компании

Не пытаются, а делают. Если б это не работало - кому б оно было нужно? Или вы за жрат и любофь к искусству работаете?

если надо просто распаралелить работу одного приложения/сервера так что-бы к нему не обращались с миллионами запросов и не «укладывали» его - другое дело. наверное просто прослойка в виде сервера или кластера будет надёжнее.

Угу. Все взять и поделить. «сервера или кластера» чего? Сферических коней?

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

Учебники в школе тоже не читали, потому что «много пустых слов»? Ну видите вы панацею в асечках и почте - лишь бы в радость, как говорится. Завтра с утра в сбере и газпроме получат гигабайты биржевых сводок... в эксельных таблицах, - аськой и почтой. Дешево и сердито. И так тридцать раз - вслед за колебаниями курсов и индексов. То-то будут рады.

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

Делегации из ОБЭП и корпоративных «служб безопасности» отправлять к tommy - он разрешил же. (Вот тогда разговор будет окончательно окончен)

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

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

Подумалось, что можно сделать что-то вроде «брокера-волонтера», суть существования которого будет не в том, чтобы заниматься роутингом сообщений, а в том, чтобы поддерживать на узлах кластера актуальность информации о его составе. Типа, приходит новый узел, обращается только к этому «брокеру», получает (по req-rep) список узлов, подписывается (очевидно, по pub-sub) на обновления, брокер при этом рассылает всем живым подписчикам сообщение о новом узле, подписчики на лету подхватывают изменения. Также можно поддерживать выпиливание умерших нодов.

Если такой «брокер» умрет, всего-навсего перестанет работать динамическое перестроение кластера.

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

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

>Завтра с утра в сбере и газпроме получат гигабайты биржевых сводок... в эксельных таблицах, - аськой и почтой.

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

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

>кем только не обзывают, только бы не приводить примеры применения

Объясняю для твердолобых: представь себе RPC. Знаешь что это? Славно.

Представь, что запросов много, тысячи в минуту. Представь, что одна машина способна в минуту обработать на порядок меньше. Какие твои действия?

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

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

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

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

>прозрачно для клиентов поставлю кластер серверов

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

в реально жизни вы пробовали это всё с миллинами обращений в минуту, ли по теории только

С миллионами в минуту - нет. Сейчас стоит задача обеспечить несколько тысяч в минуту.

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

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

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

Если такой «брокер» умрет, всего-навсего перестанет работать динамическое перестроение кластера.

Такой брокер можно и не делать. Новая нода при вхождении в сеть говорит всем по pgm «Здрасьте», остальные ноды с ней здороваются (а сами ставят новую ноду у себя в книжечке на учёт). При выходе/умирании ноды она говорит «До свидания». Чтобы гарантированно сказала, даже при получении необрабатываемых сигналов, либо при полном разрушении программы, можно эту программу запускать в скрипте-враппере, который «До свидания» после её выхода будет сам говорить.

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

>серверы доступа

Т.е. все клиенты будут ходить к серверам через некий центральный сервер доступа? Муахаха :)

на кой тут аналог p2p понять совершенно нереально

Не обобщай. Тебе может и нереально :)

протокол взаимодействия всё равно какой то использовать

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

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

но на кой тут аналог p2p понять совершенно нереально.

Вы оба не в теме, похоже. Тип сокета P2P в 0MQ используется для коммуникации строго между двумя хостами, т.е. под одному соединению на один сокет. Если использовать REP/REQ или PUB/SUB, то 0MQ позволяет к сокету сервера подключаться любому количеству клиентов, что не всегда нужно.

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

Я да, не совсем в теме, но стараюсь не упускать возможности знания расширить :)

Я под p2p подразумевал отказ от использования брокера.

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

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

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

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

В 0mq, насколько понял, ситуация отключения ноды обрабатывается автоматически (т.е. выбирается следующий сервер по round-robin). Ну, естественно, все хорошо если удаленный сокет сделал shutdown. Если физически оборвался кабель - ждать можно долго. Но такая проблема присутствует при абсолютно любой конфигурации кластера.

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

> Удар шваброй тёти Маши-уборщицы по сетевому проводу тоже смертелен будет.

Конечно.

Но такова жизнь, ничему доверять нельзя.

Но это не оправдывает полумеры вроде скрипта-враппера.

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

> Если физически оборвался кабель - ждать можно долго.

Вовсе нет. Узел считается отвалившимся, если он не ответил на запрос «ты жив?» за некоторое заранее определенное время.

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

>Т.е. все клиенты будут ходить к серверам через некий центральный сервер доступа? Муахаха :)

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

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

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

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

> Но это не оправдывает полумеры вроде скрипта-враппера.

Ваши предложения?

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

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

Чую, что поллитра, но доказать не могу?

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

>вряд ли в реальной жизни это тестировалось с реально большим числом обращений.

Ты к ним на сайт сходи, в раздел «performance».

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

>по доменному имени где будет выдавать разные IP

В условиях необходимости малой латентности ты предлагаешь на каждое сообщение (!) добавлять еще оверхед днс-запросов? Ты явно еще больше не в теме, чем я :)

по списку IP

Во-о, начало доходить ;)

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

Вовсе нет. Узел считается отвалившимся, если он не ответил на запрос «ты жив?» за некоторое заранее определенное время.

Keepalive - это тоже полумера, ибо интервал ожидания подтверждения либо закладывается в латентность системы (ответ на запрос клиента), либо система должны быть спроектирована так, чтобы можно было работать через голову потенциально мёртвой ноды.

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

>> Вовсе нет. Узел считается отвалившимся, если он не ответил на запрос «ты жив?» за некоторое заранее определенное время.

Keepalive - это тоже полумера

Это скорее heartbeat, и это не полумера, а 0.9-мера :)

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

Всё вместе.

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

Всё вместе.

Тяжела и неказиста жизнь distributed-программиста...

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

>>man middleware.

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

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

это означает, что объяснять просто волом =)

MOM - это средство интеграции приложений или способ реализации приложения. Коррелирует с ESB.

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

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

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

на практике так и получается ;) если в вашей конторе МОМ не используется, значит и не нужно :)

Как только вам перестанет хватать обычных возможностей для интеграции приложений ИЛИ потребуется увеличить скорость обработки данных за счет параллелизации процессов ИЛИ сделать workflow обработки данных изменяемым без остановки системы за счет включения новых серверов в обработку... тогда и МОМ и ESB стает понятным и нужным )))

PS http://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%BD%D0%B0...

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

> если надо просто распаралелить работу одного приложения/сервера так что-бы к нему не обращались с миллионами запросов и не «укладывали» его - другое дело. наверное просто прослойка в виде сервера или кластера будет надёжнее.

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

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

да, это сложная и громоздкая технология которая нужна только большим или очень большим фирмам. У нас из проектов - только проект для почтовой службы соседнего государства применял ESB-модель. Все что меньшего размера не требует такого усложнения IT-системы.

PS примерное как NoSQL - нужно только там, где нормальные РСУБД уже не справляются с нагрузкой. Вот и приходится применять альтернативы типа Apache Cassandra.t

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

> не можете зачем там p2p и почему просто каким то протоколом обойтись нельзя. с обычным клиент/серверным взаимодействием по запросу.

ГЫ

p2p это принцип соединения, а не протокол. ESB-софт может применять любой протокол для соединения между нодами.

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

Еще минус клиент/сервера в том, что сервер - один. в ESB серверов - несколько и каждый может реализовать одинаковые функции или разные - в зависимости от поставленных задач.

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

> Потому что не всем нравится, что с протоколом случилось после версии 0-8.
А... Понятно. Но они, собственно, обещали, что до 1.0 стабильности не будет.

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

>Еще минус клиент/сервера в том, что сервер - один

это если он один. но ведь не надо ставить один когда предполагается большая нагрузка.

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

>ведь не надо ставить один когда предполагается большая нагрузка

Ты так и не объяснил внятно, как собираешься балансировать нагрузку между несколькими серверами.

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

А... Понятно. Но они, собственно, обещали, что до 1.0 стабильности не будет.

Да дело не в стабильности протокола, а в его изменениях. 0-8 - достаточно простая вещь (поэтому RabbitMQ, реализующий только 0-8 такой популярный), а 0-10 (фактически, pre-1.0) - семиголовый монстр. После 0-8, кстати, один из пяти оригинальных авторов AMQP ушёл из комитета и начал делать 0MQ. Он жалуется, что когда в AMQP пришёл Red Hat, то начал жёстко продавливать свои решения, с которыми не все согласны. Это, кстати, к вопросу, на сколько можно доверять капитализму с человеческим лицом... ;)

В процессе написания 0MQ1 автор вообще переосмыслил идею enterprise-мессейджинга и начал делать 0MQ2, который на типичные MQ не похож. Переосмысление получилось неплохим, что видно на взрыве интереса к 0MQ2 и буйном росте биндингов к различным языкам. Буквально за 3-4 месяца появилась поддержка в Common Lisp, Haskell, Lua и Ruby. А самостоятельно изготовить биндинги к языку, в котором более-менее разбираешься, не составляет большого труда, т.к. есть внешний сишный API, и он невероятно простой.

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

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

Тогда это слишком узкая ниша, такой фреймворк нельзя применять даже для ICQ.

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


Так и знал, что придётся тыкать в картинки!

<IMG SRC="http://zeromq.wdfiles.com/local--files/code:examples-chat/im1.png«>
В 'Box B' кто по-вашему сидит? (пример ихнего чата http://www.zeromq.org/code:examples-chat)

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

А у кого эти задачи есть и снижают производительность очереди?? MS MQ - что, например, у них неправильного?

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


Это детали, я их смешиваю как раз на уровне „отослал сообщение - принял сообщение“ - любой ORB может быть построен поверх этого.

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

> такой фреймворк нельзя применять даже для ICQ.

«Даже», какая прелесть.

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

> Неужели там вообще нет никаких проблем с этим модулем под виндой?

Ну ты нашёл великого спеца по винде. Откуда я знаю :)

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

>А у кого эти задачи есть и снижают производительность очереди?? MS MQ - что, например, у них неправильного?

Ну вот и реклама MSMQ. Мужик-2, перелогинься!

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

В 'Box B' кто по-вашему сидит?

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

А у кого эти задачи есть и снижают производительность очереди??

Возьмём AMQP:

1. Железно встроена авторизация. Что делать, если авторизация не нужна?

2. Железно встроена сериализация/десериализация. Что делать, если она не нужна, либо передаваемые структуры гораздо сложнее, чем те примитивы, описанные в AMQP?

3. Железно присутствует брокер, железно увеличивающий латентность в два раза. Что делать, если брокер не нужен?

MS MQ - что, например, у них неправильного?

Ко всему с буквами MS, если это не единица времени, отношусь отрицательно.

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

Это детали, я их смешиваю как раз на уровне «отослал сообщение - принял сообщение» - любой ORB может быть построен поверх этого.

Ололо! Обощайте дальше!

mv ★★★★★
() автор топика

Чёй-то посмотрел и не нашёл у них аутентификации и авторизации.
И нафига оно? Только для закрытых сетей?

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