Python ZMQ много клиентов ко многим шаблонам сообщений обнаружения серверов - PullRequest
Новая
       32

Python ZMQ много клиентов ко многим шаблонам сообщений обнаружения серверов

0 голосов
/ 01 мая 2019

Задумайтесь над этой проблемой какое-то время, так что, наконец, попросите помощи у экспертов.

Язык: питон

Проблема / настройка:

У меня много клиентов, клиент [n], клиент [n] .. и т. Д.
У меня много серверов, сервер [n], сервер [n] .. и т. Д.

Каждый сервер может подключаться к 5 внешним ws-соединениям. В любое время мне может понадобиться открыть [x] ws соединения; может быть 2, а может и 32, общее количество подключений ws, которое мне нужно, а значит и серверы, является динамическим ...

Каждый клиент может подключаться 1 соединение с сервером [1], 1 соединение с сервером [2] .. .etc

Как я себе представляю поток, работающий

  • Загружен новый клиент [1], требующий 2 канала
  • Новый клиент [1] передает сообщение [xpub / xsub?] Всем серверам, говоря: «Эй, мне нужны эти 2 ws-соединения, у кого они есть?»
  • Сервер [1] с ws-соединениями отвечает клиенту [1] (и только этому клиенту) - «Я получил то, что искал, поговори со мной»
  • client [1] участвует в обмене req / reply с сервером [1], так что клиент [1] может использовать соединение ws сервера [1] для выполнения запросов к нему, например, «эй, сервер [1] с доступ к ws [1], вы можете запросить [x] '.. server [1] ответы клиенту [1]' вот ответ от ws-запроса, который вы сделали '

tldr

  • клиенты будут иметь несколько запросов / ответов со многими серверами
  • серверы будут иметь дело со многими клиентами
  • клиент должен передать / найти подходящих клиентов для обмена сообщениями с

Ответы [ 2 ]

1 голос
/ 21 мая 2019

Протокол Zyre специально разработан для обнаружения «сплетен» без посредников. Pyre (https://github.com/zeromq/pyre) - это реализация Python. Он предоставляет механизмам для узлов присоединяться к «группе обнаружения» и обмениваться информацией. Среди прочего, он позволяет членам группы WHISPER отдельным членам или SHOUT (многоадресной рассылки) всем участникам .

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

Вы можете использовать zyre для распространения информации о топологии (в данном случае, вашего списка серверов) среди ваших клиентов.

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

  1. Определение группы Zyre.
  2. Каждый сервер ...
    • Присоединяется к группе.
    • Устанавливает адрес своего сервера (ip или fqdn и, возможно, порт) в своем заголовке маяка.
  3. Каждый клиент ...
    • Присоединяется к группе.
    • Считывает адрес сервера из сообщений HELLO, которые он получает от серверов.
    • Создает REQ-соединения с сервером (-ами).
    • Добавляет / удаляет соединения с сервером на основе сообщений HELLO / LEAVE / AVOID, полученных с течением времени.

Если серверы не находятся в одной подсети (, например, , возможно, они находятся в разных зонах доступности AWS), вы можете предварительно сконфигурировать серверы , чтобы знать, каковы все IP-адреса серверов, периодически проверяйте их работоспособность (через REQ / REP или PUB / SUB между серверами) и передавайте информацию активных серверов в локальную группу. Клиенты могут использовать эту информацию для информирования / корректировки своего списка активных серверов / соединений.

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

0 голосов
/ 03 мая 2019

Я сосредоточусь на проблеме обнаружения.Как клиенты узнают, какие серверы доступны и какие ws-соединения есть у каждого?

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

Когда сервер запускается, он регистрируется у брокера: «У меня есть каналы w, x, y, z и я принимаю запросы на 1.2.3.5: 1234" .Посредник отслеживает это состояние, возможно, в хеш-таблице.

Когда клиенту нужен канал ws y, он сначала связывается с посредником: «Какой сервер имеет канал ws y?»Если брокер знает, у кого есть канал y, он сообщает клиенту IP-адрес и порт сервера.Клиент может затем связаться с сервером напрямую.(Если несколько серверов могут получить доступ к каналу y, брокер может вернуть список серверов вместо одного.)

Если серверы работают «долго», клиенты могут кэшировать «сервер X имеет канал y"информация и общаться с брокером только тогда, когда им нужно получить доступ к новому каналу.

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

HTH.И, к сведению, я определенно не эксперт.

...