Спать после подключения ZMQ?

В настройке МАРШРУТИЗАТОР-МАРШРУТИЗАТОР после того, как я подключаю один сокет МАРШРУТИЗАТОРА к другому, если я не сплю (скажем, 0,1 с или около того) после того, как я connect() подключился к другому сокету МАРШРУТИЗАТОР, send() обычно не проходит (хотя он иногда бывает случайно).

  1. Есть ли способ убедиться, что я подключен перед отправкой?
  2. Почему send()s не ставятся в очередь и не выполняются должным образом до тех пор, пока не будет установлено соединение?

Кроме того, дело не в том, жив ли сервер на другом конце, а в том, что я send() слишком скоро после connect() и каким-то образом он выходит из строя. Не знаю почему.


python sleep zeromq
person mmtauqir    schedule 02.05.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Есть ли способ убедиться, что я подключен перед отправкой?

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

Почему send () не ставится в очередь и не выполняется должным образом до тех пор, пока не будет установлено соединение?

Маршрутизатор не может отправить сообщение одноранговому узлу, пока обе стороны не завершат внутреннее рукопожатие ZeroMQ. Это просто способ, которым он работает, поскольку МАРШРУТИЗАТОР требует ID своего партнера для «маршрутизации». По-видимому, сон в течение 0,1 секунды - это правильное время для вашей системы разработки. Если вам нужна возможность подключиться, а затем отправить без ожидания или повторных попыток, вам нужно использовать другой шаблон.

Например, с помощью DEALER-ROUTER клиент DEALER может подключиться и немедленно отправить, а ZeroMQ будет ставить сообщение в очередь, пока оно не будет доставлено. Причина работы заключается в том, что ДИЛЕР не требует идентификатора партнера, поскольку он не «маршрутизирует». Когда сервер МАРШРУТИЗАТОРА получает сообщение, это рукопожатие уже завершено, поэтому он может сразу же ответить, не засыпая.

person Guido Simone    schedule 02.05.2014
comment
О, ладно, это имеет смысл ... Итак, вы говорите, что если я попытаюсь отправить слишком рано, он просто не встанет в очередь? Может возникнуть вопрос: если мне нужно соединение «многие ко многим», следует ли мне использовать какой-то другой шаблон или следует использовать ROUTER-ROUTER, как сейчас? - person mmtauqir; 04.05.2014
comment
Да, сообщение сброшено. По крайней мере, так я интерпретировал zguide.zeromq.org. Кроме того, в руководстве есть множество предупреждений о трудностях использования ROUTER-ROUTER, поэтому стоит потратить время на изучение других шаблонов (их много), даже если это означает переосмысление вашего подхода. К вашему сведению - я никогда не использую МАРШРУТИЗАТОР-МАРШРУТИЗАТОР. Для всего использую ДИЛЕР-МАРШРУТИЗАТОР. - person Guido Simone; 04.05.2014
comment
Я действительно хочу «многие ко многим», и, кажется, мне подходит FLP. У меня в основном есть группа серверов, обслуживающих одинаковые / похожие / связанные данные / услуги, и группа клиентов, использующих эти данные для чего-то, и если один из серверов выходит из строя, клиенты могут подключаться к одному из других ... также, клиенты могут подключаться к разным серверам для разных типов запросов. Есть ли какой-нибудь другой шаблон, который я мог бы использовать для этого? - person mmtauqir; 04.05.2014