Вопросы по ZeroMQ, RabbitMQ и message broker'ах вообще.

на zeromq: коннектишь всех пользователей к брокеру по REQ-RESP. когда клиент создаёт задачу брокер посылает PUB-запрос, на который подписаны все серверы и они выдают из состояние, на по которому брокер определяет где запускать задачу и по REQ-RESP отправляет задание. Соотв. затем при выполнении серверы посылают по REP-RESP сообщение брокеру. (Тут возможны варианты, в зависимости от того нужна ли асинхронность между брокером и пользователем, и будет ли там постоянный коннект).

В общем-то всё смотрится не сложно.

Paranoid Pirate и так кажется подходящим в общем то.
RESP в zeromq нет в общем то.

REP, очепятка.

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

Да вроде нет. Только передача файлов с клиентов на воркеры и наоборот нужна и асинхронность.

ну ок..

По твоему, есть лучшее решение?

ну я написал, как бы я делал, но я не профессионал в zeromq.

 +----------+
 | client   |
 +-[REQ]-|--+ [2]
[1] |    +---------------+
    +------------+       |
                 |       |
            +----|----+--^------+
 INTERM:    | PROXY   |         |
            +----|----+PUB-REP--+
        +--------+   [4]|   | [5]
   +----|---------------+   |
   |    |    +--------------+
 +-SUB-REP--REQ---+
 | server         |
 +----------------+

по каналу [2] идёт запрос создать задачу, далее промежуточная нода оповещает все сервера [4], и они скидывают инфу о себе [5] (статистика, кол-во задач, свободная оперативка) на основе этой инфы пользователю даётся ответ куда идёт его задача (это лучше чем стандартный dealer, который тупо делает round-robin)*. Далее по каналу [1] на сервер уходит файл через PROXY на сервер на промежуточной ноде сохраняем номер задачи. клиент может отключаться, когда он закончит, то передаст инфу о выполнение на промежуточную ноду [5].

может быть переусложнено но всё же. Плюс к этому можно добавить сердцебиение для хранения инфы о том, какие ноды живы.

*). если я тут не прав, то меня можно смело поправить.

По идее язык сервиса значения не имеет, в данном случае С++.

странно, что никто не вспомнил erlang.

Я эрланг не знаю, да и думаю не позволят в проекте использовать.
RabbitMQ и так на erlange.

Я точно не уверен. Но в PP не round-robin можно легко внедрить, так то там делается выбор какому серверу идёт запрос с клиента.
Интересная схема, посмотрю преимущества перед PP. Спасибо.

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

А почему ты выбрал zeromq, а не что-то другое?

1). есть всё для требуемого функционала и возможных расширений

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

3). лицензия позволяющая использовать либы в закрытых продуктах (хотя скорее всего результат будет выложен под открытой лицензией).

4). «рабинович напел», т.е. в среднем положительные отзывы о данной библиотеке.

5). наличие примеров кода в документации, т.е. можно было прогнать proof-of-concept достаточно быстро.

6). есть завершенные проекты близкие проекты.

rabbitmq - это, ЕМНИП, amqp версии 0-8. Флагманская реализация amqp - qpidc - написана на C++.

Здравствуй!

По сути, брокер обмена сообщениями должен:

• Обеспечивать асинхронный обмен сообщениями с подключенными узлами - для этого обычно каждое соединение обслуживается 2-мя потоками (threads): один на прием сообщений, другой на отправку. При этом желательно использовать заранее созданный пул «спящих» на условной переменной пар потоков ибо операция создания потока достаточно ресурсоемкая;
• Осуществлять программно управляемую маршрутизацию сообщений между узлами по определенным правилам - для этого обычно реализуется набор определенных потокобезопасных, «взаимоподсоединяемых» программных компонент: очередь (queue), шина (bus), «вентилятор» (fan-out) сообщений с соответствующими гибкими механизмами их фильтрации.
• Предоставлять клиентскую библиотеку асинхронного (опять 2 потока) доступа, позволяющую любому потоку (thread) клиентского приложения:
  • Отправить сообщение брокеру;
  • В течение некоторого времени осуществлять «прослушку» соединения и получение сообщений от брокера, желательно с гибким механизмом фильтрации (например, переопределением виртуального метода);
  • (комбинация двух предыдущих) Отправить сообщение брокеру и в течение некоторого времени ожидать от него ответа(-ов), также с использованием фильтрации - это для реализации синхронного взаимодействия с брокером «поверх» асинхронного;

Вследствие особенностей стоявших передо мной на месте труда задач я не имел возможности использовать существующие брокеры сообщений (нужна сертификация на использование в ИС особого назначения, а ее ни у одного не было) мне пришлось заняться «велосипедостроением», что выросло в нижеследующий набор классов:

• Очередь сообщений, MessageQueue;
• Шина сообщений, MessageBus;
• Вентилятор сообщений, MesageFan;
• Абстрактная служба сообщений, AbstractMessageBrokerService;
• Абстрактное соединение для обмена сообщениями, AbstractMessageBrokerConnection;

Т.о., переопределив лишь методы записи/чтения сообщений из/в транспорт, нужные обработчики событий и реализовав маршрутизацию можно достаточно легко разработать брокер сообщений любой архитектуры (хоть AMQP, если уж хочется). Для сериализации сообщений и передачи их по каналам связи я в основном использую XML (обычно запакованный и сопостовляющийся XML-схеме), обернутый в HTTP-сообщения (вообще говоря, HTTP удобен для передачи бинарных данных и данных заранее неизвестной длины - был бы подходящий потоковый сериализатор/десериализатор). Понимаю, что на фоне наличия такого разнообразия брокеров сообщений мое предложение может выглядеть несколько неадекватным, но лично для меня такая схема оказалась предпочтительней, ибо появилась возможность сколь угодно тесно интергировать функционал брокера сообщений в любое серверное приложение и к тому же весь базовый код всегда «под рукой» и «в голове». Вот пример простого брокера сообщений, определяющего конец сообщения по символу возврата каретки и рассылающего широковещательно все полученные сообщения.

Что касается выполнения неких «долгоиграющих» вычислительных задач, то (для случая конкретного серверного процесса) для этого можно взять за основу паттерн проектирования Active Object, где пул «спящих» на условной переменной потоков «пробуждает» один поток (или более) и передает ему поступившую на выполнение задачу (задачи). Для этого имеются классы TaskDispatcher и MultiTaskDispatcher.