Come controllare l'indirizzo IP di origine di un pacchetto ZeroMQ su una macchina con più IP?

Beh, ZeroMQ è un po' complicato da leggere come socket -"controparte"

Perché?

Classico socket è una risorsa gratuita.

ZeroMQ è una gerarchia piuttosto complessa di idee e principi di comportamento (comportamenti meglio distribuiti), che aiutano a progettare sistemi di calcolo distribuito intelligenti, senza toccare i dettagli di basso livello (ZeroMQ ben astratti), che controllano il flusso effettivo di eventi nelle tempeste di condizioni difficili tutti i sistemi di elaborazione distribuiti sono aperti ad affrontare (e devono gestire di conseguenza a basso livello, se le astrazioni di alto livello "promesse" da ZeroMQ di mantenere devono essere soddisfatte e facilitare le menti dei progettisti a concentrarsi piuttosto sulla sua / la sua parte principale dell'applicazione, non la riprogettazione delle ruote (con tutte le prove e gli errori) per tirare i fili sulle risorse del sistema operativo e i servizi dei sistemi di scuotimento per raccogliere solo pochi tipi di frutta a bassa quota).

Per questi motivi meglio dimenticare subito che ZeroMQ è "qualcosa-come- socket "

Gerarchia ZeroMQ in meno di cinque secondi

1:
ZeroMQ promette un facile riutilizzo di alcuni banali archetipi di modelli di comunicazione formale scalabili offrendo un particolare comportamento distribuito { PUB/SUB | PUSH/PULL | PAIR/PAIR | XPUB/XSUB | ... | REQ/REP } .

2:
Tranne il caso di utilizzo esclusivo di un senza dispositivo inproc:// classe di trasporto, in tutti gli altri casi, ZeroMQ necessita di una o più istanze di un "motore sintonizzabile " - a Context( nIOthreads = N ) , N >= 1 .

3:
Avendo questo, qualsiasi (futuro socket ) Punto di accesso potrebbe essere istanziato, portando un archetipo comportamentale fin dal momento stesso della nascita:

aSubscribeCHANNEL = aLocalCONTEXT.socket( zmq.SUB )      # this is NOT a <SOCKET>
#                                 ^^^^^^__________________ even it was typed in

4:
Avere un "Punto di accesso " istanza pronta "all'interno" del "motore locale ", si può bloccare la sua materializzazione nella realtà esterna, usando uno o più (sì, più ... WOW! Significa più stringhe in entrata / fischi che escono da un singolo "nodo di comportamento" del punto di accesso) chiamate a uno di questi metodi:
.bind( <transport-class>://<a-class-specific-address> )
o
.connect( <transport-class>://<a-class-specific-address> )

5:
Se e solo se un .bind() -RTO-ready Access Point A "viene visitato " da un primo .connect() attivo -RTO-ready Access Point B, con qualsiasi abbinamento di comportamento corrispondente, l'archetipo di messaggistica/segnalazione ZeroMQ diventa attivo (denominandolo anche socket è stato probabilmente utilizzato per ragioni storiche, per facilitare una spiegazione in tempi )

_{( PUB/PUB non andrà mai bene, per ovvie ragioni, mentre PUB/SUB e molte altre coppie comportamento-archetipo si abbinano e si abbinano in modo adorabile e formano i comportamenti mutuamente "compatibili" che alla fine andranno a vivere e rimarranno tali )}

Quindi,
come faccio a fare la stessa cosa con un socket Python ZeroMQ,
data una macchina che ha più indirizzi?

Basta utilizzare la specifica completa in una chiamata a
.bind( "{ tcp | pgm | epgm }://<ip>:<port#>" ) metodo e il gioco è fatto.

Così facile.

Fantastico, vero?

_{Molte altre piacevoli sorprese sotto il cofano dell'ottimizzazione delle prestazioni, della riduzione della latenza e delle modifiche alla sicurezza.}