Eh bien, ZeroMQ est un peu difficile à lire en tant que socket -"contrepartie"
Pourquoi ?
Classique socket est une ressource gratuite.
ZeroMQ est une hiérarchie assez complexe d'idées et de principes de comportements (comportements mieux distribués), qui aident à concevoir des systèmes informatiques distribués intelligents, sans toucher aux détails de bas niveau (ZeroMQ bien abstrait), qui contrôlent le flux réel des événements dans les tempêtes des conditions difficiles auxquelles tous les systèmes informatiques distribués sont exposés (et doivent gérer à bas niveau en conséquence, si les abstractions de haut niveau "promises" par ZeroMQ à conserver doivent être remplies et apaiser l'esprit des concepteurs pour se concentrer plutôt sur son / sa partie principale de l'application, et non la refonte des roues (avec tous les essais et erreurs) sur la traction des ficelles sur les ressources O/S et les services des systèmes de secouage pour la collecte de quelques types de fruits à portée de main).
Pour ces raisons, mieux vaut oublier que ZeroMQ est "quelque chose comme- socket "
Hiérarchie ZeroMQ en moins de cinq secondes
1 :
ZeroMQ promet une réutilisation facile de quelques archétypes de modèles de communication formels évolutifs triviaux offrant un comportement distribué particulier { PUB/SUB | PUSH/PULL | PAIR/PAIR | XPUB/XSUB | ... | REQ/REP } .
2 :
Sauf un cas d'utilisation exclusive d'un sans appareil inproc:// transport-class, dans tous les autres cas, ZeroMQ a besoin d'une ou plusieurs instances d'un "moteur réglable " - un Context( nIOthreads = N ) , N >= 1 .
3 :
Ayant ceci, n'importe quel (futur socket ) Point d'accès pourrait être instancié, portant un archétype comportemental depuis le moment même de la naissance :
aSubscribeCHANNEL = aLocalCONTEXT.socket( zmq.SUB ) # this is NOT a <SOCKET>
# ^^^^^^__________________ even it was typed in
4 :
Avoir un "point d'accès " instance prête "à l'intérieur" du moteur local ", on peut verrouiller sa matérialisation dans la réalité externe, en utilisant un ou plusieurs (oui, plus ... WOW ! Cela signifie plus de cordes à tirer entrantes dans / des sifflets soufflant depuis un seul point d'accès "noeud de comportement" ) appels à l'une de ces méthodes :
.bind( <transport-class>://<a-class-specific-address> )
ou
.connect( <transport-class>://<a-class-specific-address> )
5 :
Si et seulement si un .bind() -Le point d'accès A prêt pour le RTO "est visité " par un premier live .connect() -Point d'accès B prêt pour le RTO, ayant tout appariement de comportement correspondant, l'archétype de messagerie/signalisation ZeroMQ devient actif (en le nommant également un socket a probablement été utilisé pour des raisons historiques, pour faciliter une explication dans le temps )
( PUB/PUB ne conviendra jamais, pour des raisons évidentes, alors que PUB/SUB et de nombreuses autres paires comportement-archétype vont et vont bien correspondre et former les comportements mutuellement "compatibles" qui vont finalement être mis en ligne et le rester)
Alors,
comment faire la même chose avec un socket Python ZeroMQ,
donné une machine qui a plusieurs adresses ?
Utilisez simplement la spécification complète dans un appel à
.bind( "{ tcp | pgm | epgm }://<ip>:<port#>" ) méthode et vous avez terminé.
C'est facile.
Cool, n'est-ce pas ?
De nombreuses autres surprises agréables sous le capot du réglage des performances, de la réduction de la latence et des ajustements de sécurité.