Zeromq, какой сокет должен связываться с шаблоном PubSub

Я читал о ZeroMQ, в частности о NetMQ, и почти все примеры Pub/Sub, которые я видел, использовались для привязки сокета издателя, а затем сокет подписчика подключался к другому.

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

Это возможно ? (Я не нашел ничего ясного в документации) Каковы недостатки этой стратегии подключения?

Любая помощь будет полезна.


person mmarques    schedule 20.04.2015    source источник


Ответы (1)


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

В ZMQ движущая концепция «связывания» и «соединения» заключается в том, что одна сторона часто считается более надежной (и обычно будет меньше узлов), а другая сторона считается более временной (и может быть более многочисленные узлы). Надежная сторона будет считаться вашим "сервером", и вы должны bind() на этой стороне, временная сторона будет считаться вашим "клиентом" (или клиентами), и вы должны connect() на этой стороне.

Как правило, мы думаем о стабильном «сервере», который постоянно публикует информацию для многих «клиентских» подписчиков, которые могут приходить и уходить. Это представлено в примерах, которые вы видите: привязка к пабу, подключение к подписке.

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

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

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

person Jason    schedule 21.04.2015