Как управлять исходным IP-адресом пакета ZeroMQ на компьютере с несколькими IP-адресами?
Стандартная библиотека Python socket.create_connection() Метод имеет опцию адреса источника для управления тем, какой IP-адрес источника используется соединением.
Как мне сделать то же самое с сокетом Python ZeroMQ, если у машины несколько адресов?
В этом случае я использовал Linux iproute2 ip addr add создать адреса и ZeroMQ PUB/SUB штепсельные архетипы.
2 ответа
При попытке .connect()к удаленному, я нашел ответ в документации к протоколу, поставив исходный ip перед точкой с запятой в строке подключения:
rc = zmq_connect( socket, "tcp://192.168.1.17:5555;192.168.1.1:5555" )
В Python это выглядит так:
socket = zmq.Context().socket( zmq.SUB )
socket.connect( 'tcp://192.168.1.17:5555;192.168.1.1:5555' )
Ну, ZeroMQ немного сложно читать как socket -"контрагент" (это не так)
Зачем?
классическая socket это бесплатный ресурс.
ZeroMQ- это довольно сложная иерархия идей и принципов поведения (лучше - распределенное поведение), которые помогают проектировать интеллектуальные распределенные вычислительные системы, не касаясь низкоуровневых (хорошо абстрагированных ZeroMQ) деталей, которые контролируют реальный поток событий в штормах. В суровых условиях все распределенные вычислительные системы открыты к лицу (и должны соответственно обрабатываться на низком уровне, если должны быть выполнены абстракции высокого уровня, "обещанные" ZeroMQ, чтобы сохранить их, и облегчить умы дизайнеров, чтобы сосредоточиться скорее на своем / ее основная прикладная часть, а не перепроектирование колес (со всеми пробами и ошибками) для натягивания строк на ресурсы O/S и службы систем встряхивания для сбора всего лишь нескольких низко висящих видов фруктов).
По этим причинам лучше прямо забыть, что ZeroMQ " что-то вроде socket "
Иерархия ZeroMQ менее чем за пять секунд
1:
ZeroMQ обещает простое повторное использование нескольких тривиальных архетипов Scalable Formal Communication Pattern, предлагающих определенное распределенное поведение { PUB/SUB | PUSH/PULL | PAIR/PAIR | XPUB/XSUB | ... | REQ/REP },
2:
За исключением случая исключительно использования только устройства inproc:// транспортный класс, во всех остальных случаях ZeroMQ требуется один или несколько экземпляров настраиваемого " движка " - Context( nIOthreads = N ), N >= 1,
3:
Имея это, любая (будущая сокетная) точка доступа может быть реализована с поведенческим архетипом с самого момента рождения:
aSubscribeCHANNEL = aLocalCONTEXT.socket( zmq.SUB ) # this is NOT a <SOCKET>
# ^^^^^^__________________ even it was typed in
4:
Имея готовый экземпляр " Точки доступа " внутри "локального" движка ", можно зафиксировать его материализацию во внешней реальности, используя одну или несколько (да, еще... ВАУ! / свистит, выдыхая из единственной точки доступа "поведение-узел") вызывает любой из этих методов: .bind(<transport-class>://<a-class-specific-address>)
или же .connect(<transport-class>://<a-class-specific-address>)
5:
Если и только если .bind() -RTO-готовая точка доступа A " посещается " первым живым .connect() -RTO-готовая точка доступа B, имеющая любое подходящее сопряжение поведения, запускает архетип ZeroMQ-обмена сообщениями / сигнализации (называя его также сокетом, вероятно, использованным по историческим причинам, чтобы облегчить объяснение в разы)
( PUB/PUB никогда не подойдет по понятным причинам, тогда как PUB/SUB и многие другие пары "поведение-архетип" будут прекрасно сочетаться и формировать взаимно "совместимые" поведения, которые, наконец, будут жить и оставаться такими)
Так,
как мне сделать то же самое с сокетом Python ZeroMQ,
дали машину, которая имеет несколько адресов?
Просто используйте полную спецификацию в звонке .bind("{ tcp | pgm | epgm }://<ip>:<port#>") метод и все готово.
Это просто.
Круто, не правда ли?
Еще много приятных сюрпризов под капотом настройки производительности, латентного бритья и настройки безопасности.