двунаправленная асинхронная связь между процессами

Не совсем понимаю, как ты хочешь обойтись без вспомогательного потока.

Ну, если есть колбэки, то я же могу вычитывать данные потом, когда придет время? Просто будет флаг что типа «насяльника там пакетама пришла» и я в основном потоке вычитаю что надо. Это ведь для этого: «zmq_socket_monitor - register a monitoring callback»?

Ладно, колбэки это второстепенный вопрос, ну будет у меня второй поток - не беда.

Главный вопрос: какая модель из всех доступных в ZeroMQ позволяет схему как мне надо - 100% асинхронное двунаправленное через одно соединение.

очевидно, два PULL/PUSH. И да, одного соединения не будет. ZeroMQ нужен чтобы написать быстро, а не правильно по фен-шую.

Точно? Просто у меня не сильно большой опыт с ZeroMQ. Таким образом мне следует использовать два PUSH/PULL соединения, одно в одну сторону, второе - в обратном направлении? Чем это отличается от PUB/SUB?

А на счет колбэков... Я вот подумал, ведь ZeroMQ хранит пакеты в своих недрах пока я их не вычитаю. Есть ли какие-то способы сигнализации о том что там в сокете завалялись новые пакеты?

Да, раз уж ты об этом, а правильно - это как? Подскажи, возможно второе более правильное решение я и выберу.

Таким образом мне следует использовать два PUSH/PULL соединения, одно в одну сторону, второе - в обратном направлении?

да, PULL это входяшие запросы процессу от всех других процессов, PUSH - отправка сообщения другому конкретному процессу.

чем это отличается от PUB/SUB?

они синхронные, тебе нужен асинхронный метод. Сам zmq полностью твою задачу не решит. Нужно придумать формат отправляемых пакетов так, чтобы вунтри каждго пакета был тип (REQUEST или REPLY) и request_id. Т.е. хочешь сделать асинхронный запрос, то

1. генерируешь request_id,

2. шлёшь через PUSH сокет REQUEST запрос нужному процессу,

3. сохраняешь в ассоциативном массиве { request_id -> callback },

4. получаешь REPLY с request_id, дёргаешь свой callback из таблицы

Кроме PUSH/PULL можно заюзать примерно аналогично DEALER/ROUTER, здесь даже получается один сокет. Но, имхо, для всего двух процессов проще будет PUSH/PULL.

Есть ли какие-то способы сигнализации о том что там в сокете завалялись новые пакеты?

там же, по сссылке выше, zmq_poll() или zmq_getsockopt(socket, ZMQ_EVENTS, ...)

Это ведь для этого: «zmq_socket_monitor - register a monitoring callback»?

нет, это скорее для дебага. В списке поддерживаемых эвентов нет аналогов POLLIN/POLLOUT

Это пойдёт?

пришло время для gearman, а не этого говна(впрочем gearman еще тем кусочком может оказаться)

да, я пользовался уже zmq_poll - оно может проверить есть ли данные в сокете, но оно само ведь не может сообщить - колбэков как мы уже выяснили - нету

вот еще человек подсказывает что ZMQ_PAIR - двунаправленное, но мне не нравится это «then any zmq_send(3) operations on the socket shall block until the peer becomes available for sending; messages are not discarded», но что если второй процесс отвалится?

а для PUSH/PULL «then any zmq_send(3) operations on the socket shall block until the exceptional state ends or at least one downstream node becomes available for sending; messages are not discarded»

мне надо чтобы оно быстро принимало данные (без блокировки) в себя и если есть подключенный другой - то слало ему, а если нету - дискардило и возвращало -1

хочется чтобы тупо асинхронно неблокирующе оно падало в сокет и вылетало с другой стороны

еще пара вопросов: 1) число перепосылок (попыток) в случае неудачной отсылки пакета - оно регулируется? и где-то сообщается если я неблокирующе кинул пакет а через какое-то время стало ясно что он не дошел - где это смотреть инфу о неудаче? 2) «The zmq_send() function shall queue a message created from the buffer referenced by the buf and len arguments» - это значит что буфер должен быть актуальным до наступления удачной отправки или данные zmq_send (3.2.2) - кинул и забыл, делается копия внутри?

а ты работал с gearman? как оно? там пишут «libgearman is a small, thread-safe client library for the gearman protocol» - вот это шикарно

потому что сокеты в ZeroMQ уже вы не thread-safe

в общем, интересуют отзывы, равно как и описание как называется нужный мне сценарий в терминологии gearman

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

пришло время для gearman,

для нескольких процессов оно точно не нужно

ну да. это же таск сервер. но кто сказал что он не легковесен?

какой там сценарий? создал таск, забрал таск, отдал результат, обработал результат. Все должно быть ассинхроно.

ок, присмотрюсь к gearman

благодарю за просветительскую деятельность :)

ассинхроно

я упорот

мне надо чтобы оно быстро принимало данные (без блокировки) в себя и если есть подключенный другой - то слало ему, а если нету - дискардило и возвращало -1

Есть же ZMQ_POLLOUT:

For ØMQ sockets, at least one message may be sent to the socket without blocking.

или это тоже не помогает? У zmq_send() есть флаги, в частности ZMQ_NOBLOCK (ZMQ_DONTWAIT).

число перепосылок (попыток) в случае неудачной отсылки пакета - оно регулируется?

По идеологии zmq не положено заморачиваться такими вопросами, так или иначе какой-то узел должен получить сообщение если это не анонимный PUB/SUB. Всё что можно подтюнить находится в zmq_setsockopt()

если я неблокирующе кинул пакет а через какое-то время стало ясно что он не дошел - где это смотреть инфу о неудаче

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

это значит что буфер должен быть актуальным до наступления удачной отправки или данные zmq_send (3.2.2) - кинул и забыл, делается копия внутри?

хз, должно быть 'кинул и забыл', как в обычных сокетах. Здесь же нет возможности узнать момент отправки и освободить ресурс.

ну да. это же таск сервер. но кто сказал что он не легковесен?

какая разница какой он лёгкости, без него задача ТСа решается намного проще практически на чём угодно, хоть на пайпах.

А может на пайпах и решить её?

я делал pub-sub в обе стороны, возможна реализация с dealer, но там придётся руками разбирать пакеты, чтобы правильно отвечать, крайне не рекомендуется документацией.

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

так все правльно. а зачем gearman? ради плюшек и удобства.

ладно, убедил :) начну с gearman ^_^

если что - я буду тут задавать вопросы тебе же, мало ли там трудность какая-то возникнет :)

ненене. иди пили пайпы. а у gearman версия 1 уже была(когда я смотрел - 0.22)