Nun, ZeroMQ ist etwas schwierig als socket zu lesen -"Gegenpartei"
Warum?
Klassisches socket ist eine frei nutzbare Ressource.
ZeroMQ ist eine ziemlich komplexe Hierarchie von Ideen und Verhaltensprinzipien ( besser verteilte Verhaltensweisen ), die beim Entwurf intelligenter verteilter Computersysteme helfen, ohne die Details auf niedriger Ebene ( ZeroMQ gut abstrahiert ) zu berühren, die den tatsächlichen Ablauf von Ereignissen in den Stürmen steuern rauen Bedingungen sind alle verteilten Computersysteme offen gegenüber ( und müssen entsprechend auf niedriger Ebene damit umgehen, wenn die von ZeroMQ "versprochenen" High-Level-Abstraktionen erfüllt werden sollen und den Geist der Designer erleichtern sollen, sich eher auf seine/ihre/ ihr Kernanwendungsteil, nicht das Neugestalten von Rädern (mit allen Versuchen und Irrtümern), das Ziehen von Fäden an O/S-Ressourcen und das Schütteln von Systemdiensten zum Sammeln von nur ein paar niedrig hängenden Arten von Früchten).
Aus diesen Gründen vergiss ZeroMQ besser gleich, "sowas- zu sein socket "
ZeroMQ-Hierarchie in weniger als fünf Sekunden
1:
ZeroMQ verspricht eine einfache Wiederverwendung einiger trivialer Archetypen von skalierbaren formalen Kommunikationsmustern ein bestimmtes verteiltes Verhalten anbieten { PUB/SUB | PUSH/PULL | PAIR/PAIR | XPUB/XSUB | ... | REQ/REP } .
2:
Außer in dem Fall, dass ausschließlich nur ein gerätloses verwendet wird inproc:// Transportklasse, in allen anderen Fällen benötigt ZeroMQ eine oder mehrere Instanzen einer abstimmbaren "Engine " - ein Context( nIOthreads = N ) , N >= 1 .
3:
Mit diesem, jedem (zukünftigen socket ) Zugangspunkt könnte instanziiert werden und seit dem Moment der Geburt einen Verhaltensarchetyp tragen:
aSubscribeCHANNEL = aLocalCONTEXT.socket( zmq.SUB ) # this is NOT a <SOCKET>
# ^^^^^^__________________ even it was typed in
4:
Mit einem "Zugriffspunkt " Instanz bereit "innerhalb" der lokalen "Engine ", man kann seine Materialisierung in der externen Realität einschließen, indem man einen oder mehrere verwendet ( ja, mehr ... WOW! Das heißt, mehr eingehende Fäden ziehen / Pfeifen aus einem einzigen Access Point "Verhaltensknoten") Aufrufe einer dieser Methoden:
.bind( <transport-class>://<a-class-specific-address> )
oder
.connect( <transport-class>://<a-class-specific-address> )
5:
Nur wenn ein .bind() -RTO-fähiger Access Point A "wird besucht " von einem ersten live .connect() - RTO-fähiger Access Point B, der über eine passende Verhaltenspaarung verfügt, der ZeroMQ-Nachrichten-/Signalisierungs-Archetyp wird live geschaltet (auch als Socket bezeichnet). wurde wahrscheinlich aus historischen Gründen verwendet, um eine Erklärung in Zeiten zu erleichtern )
( PUB/PUB wird aus offensichtlichen Gründen nie passen, wohingegen PUB/SUB und viele andere Verhaltens-Archetyp-Paare werden und werden wunderbar zusammenpassen und die gegenseitig "kompatiblen" Verhaltensweisen bilden, die schließlich live gehen und bleiben werden )
Also,
wie mache ich dasselbe mit einem Python ZeroMQ-Socket,
einer Maschine gegeben, die mehrere Adressen hat?
Verwenden Sie einfach die vollqualifizierte Spezifikation in einem Anruf an
.bind( "{ tcp | pgm | epgm }://<ip>:<port#>" ) Methode und du bist fertig.
So einfach.
Cool, oder?
Viele weitere angenehme Überraschungen unter der Haube von Leistungsoptimierung, Latenzkorrektur und Sicherheitsoptimierung.