Bueno, ZeroMQ es un poco complicado de leer como socket -"contraparte"
¿Por qué?
Clásico socket es un recurso gratuito.
ZeroMQ es una jerarquía bastante compleja de ideas y principios de comportamientos (comportamientos mejor distribuidos), que ayudan a diseñar sistemas informáticos distribuidos inteligentes, sin tocar los detalles de bajo nivel (ZeroMQ bien resumido), que controlan el flujo real de eventos en las tormentas. de duras condiciones que todos los sistemas informáticos distribuidos están expuestos a enfrentar (y tienen que manejarse a bajo nivel en consecuencia, si las abstracciones de alto nivel "prometidas" por ZeroMQ para mantener se cumplen y tranquilizan las mentes de los diseñadores para que se concentren más bien en su / su parte principal de la aplicación, no rediseñar las ruedas (con todos los ensayos y errores) para mover los hilos de los recursos de O/S y sacudir los servicios de los sistemas para recolectar solo unos pocos tipos de frutas maduras).
Por estas razones, es mejor olvidarse directamente de que ZeroMQ es "algo-como- socket "
Jerarquía ZeroMQ en menos de cinco segundos
ZeroMQ promete una fácil reutilización de algunos arquetipos de patrones de comunicación formal escalable triviales ofreciendo un comportamiento distribuido particular { PUB/SUB | PUSH/PULL | PAIR/PAIR | XPUB/XSUB | ... | REQ/REP } .
Excepto en el caso de usar exclusivamente un sin dispositivo inproc:// clase de transporte, en todos los demás casos, ZeroMQ necesita una o más instancias de un "motor ajustable " - un Context( nIOthreads = N ) , N >= 1 .
Teniendo esto, cualquier ( futuro socket ) Punto de acceso podría ser instanciado, teniendo un arquetipo de comportamiento desde el mismo momento del nacimiento:
aSubscribeCHANNEL = aLocalCONTEXT.socket( zmq.SUB ) # this is NOT a <SOCKET>
# ^^^^^^__________________ even it was typed in
Tener un "Punto de acceso " instancia lista "dentro" del "motor local ", uno puede bloquear su materialización en la realidad externa, usando uno o más (sí, más ... ¡GUAU! Lo que significa más cuerdas entrantes / silbatos que suenan desde un único punto de acceso "nodo de comportamiento") llamadas a cualquiera de estos métodos:
.bind( <transport-class>://<a-class-specific-address> )
o
.connect( <transport-class>://<a-class-specific-address> )
Si y solo si un .bind() -El punto de acceso A listo para RTO "es visitado " por un primer vivo .connect() -Punto de acceso B listo para RTO, con cualquier emparejamiento de comportamiento coincidente, el arquetipo de mensajería/señalización ZeroMQ se activa (nombrándolo también un socket probablemente se usó por razones históricas, para facilitar una explicación en tiempos)
( PUB/PUB nunca encajará, por razones obvias, mientras que PUB/SUB y muchos otros pares de comportamiento-arquetipo coincidirán y formarán los comportamientos mutuamente "compatibles" que finalmente se activarán y permanecerán así)
Entonces,
¿Cómo hago lo mismo con un socket Python ZeroMQ?
dada una máquina que tiene múltiples direcciones?
Simplemente use la especificación completamente calificada en una llamada a
.bind( "{ tcp | pgm | epgm }://<ip>:<port#>" ) método y listo.
Así de fácil.
Genial, ¿no?
Muchas más sorpresas agradables bajo el capó de ajuste de rendimiento, reducción de latencia y ajustes de seguridad.