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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> При выходе/умирании ноды она говорит «До свидания»

Ты же понимаешь, что это не выход :)

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

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

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

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

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

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

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

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

Ты же понимаешь, что это не выход :)

Почему?

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

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

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

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

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

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

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

Конечно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

по списку IP

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

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

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

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

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

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

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

Всё вместе.

Всё вместе.

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

>>man middleware.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГЫ

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

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

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

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

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

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

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

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

А... Понятно. Но они, собственно, обещали, что до 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, и он невероятно простой.

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

Тогда это слишком узкая ниша, такой фреймворк нельзя применять даже для 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 может быть построен поверх этого.

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

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

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

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

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

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

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

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

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

Возьмём AMQP:

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

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

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

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

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

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

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

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

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