Se si desidera una comunicazione bidirezionale semplice, è sufficiente impostare un socket di pubblicazione su ciascun nodo e consentire a ciascuno di collegarsi all'altro.
In molti e molti setup questo diventa rapidamente difficile da gestire. In sostanza, sembra che tu voglia una sorta di nodo centrale a cui tutti i nodi possano "connettersi", ricevere messaggi e, se sono soddisfatte alcune condizioni sull'abbonato, inviare messaggi a.
Da ZeroMq è un semplice "power-presa", e non una coda di messaggi (da cui il nome, ZeroMQ - Zero Message Queue) questo è non fattibile out-of-the-box.
Una semplice alternativa potrebbe essere quella di consentire a ciascun nodo di configurare un socket di trasmissione UDP (non utilizzando ZeroMq, solo socket regolari). Tutti i nodi possono ascoltare tutto ciò che accade e "pubblicare" i propri messaggi sul socket, inviandolo efficacemente a qualsiasi nodo in ascolto. Questa configurazione funziona su una LAN e in un'impostazione in cui va bene che i messaggi si perdano (come gli aggiornamenti periodici di stato). Se i messaggi devono essere affidabili (e possibilmente durevoli) è necessaria una coda di messaggi in piena regola più avanzata.
Se è possibile eseguire senza lunghe code di messaggi, è possibile creare una soluzione basata su un nodo centrale, un gestore di messaggi centrale, a cui tutti i nodi possono essere abbonati e inviare dati. Fondamentalmente, creare un "server" con un socket REP (Response) (per i dati in arrivo) e un socket PUB (Publisher) (per i dati in uscita). Ogni client quindi pubblica i dati sul socket REP dei server su un socket REQ (Request) e imposta un socket SUB (Subscriber) sul socket PUB dei server.
Consultare la guida ZeroMq per i vari message patterns disponibili.
Per ravvivarlo un po ', è possibile aggiungere eventi "argomenti", incluso il filtro lato server, suddividendo i messaggi in uscita (sul socket PUB dei server) in due parti di messaggio (vedere multi-part messages) dove specifica la prima parte "argomento" e la seconda parte contiene il carico utile (ad esempio temp | 46.2, velocità | 134). In questo modo, ogni cliente può registrare il proprio interesse in qualsiasi argomento (o tutti) e lasciare che il server escluda solo i messaggi corrispondenti. Vedi this example per i dettagli.
Fondamentalmente, ZeroMq è "solo" un'astrazione su socket regolari, fornendo un paio di schemi di messaggistica per costruire la soluzione. Tuttavia, ti allevia un sacco di lavoro noioso e fornisce scalabilità e prestazioni fuori dal comune. Ci vuole un po 'per abituarsi però. Controlla il ZeroMq Guide per maggiori dettagli.
Leggendo alcune risorse mi sembra che il modo migliore per farlo nel modo in cui intendo sia creare un socket di pubblicazione su ciascun nodo, come hai detto tu. Ciò significa che dovrò inviare messaggi esplicitamente a tutte queste prese?Sto pensando a qualcosa di simile a un MQ simile a un cloud, in cui ogni componente può semplicemente essere in ascolto e scrivere, consentendomi di aggiungere, rimuovere componenti senza la necessità di modificarli a vicenda. Non so se sono chiaro su cosa mi piacerebbe fare. – user1978591
Sì, tutti gli abbonati devono iscriversi a tutti gli altri socket di pubblicazione dei nodi, ecco perché non penso che sia una soluzione fattibile. Come ho accennato nella mia risposta, un altro modo sarebbe quello di creare il proprio servizio MQ o server di messaggistica, come si menziona, basato sui socket ZeroMq. In questo modo i nodi non dovrebbero sottoscrivere tutti gli altri socket dei nodi, solo il socket di pubblicazione di questo server. Non dovrebbe essere troppo difficile crearlo usando ZeroMq. L'alternativa è altrimenti di creare qualcosa di pronto, come RabbitMQ. –
Sì, penso che proverò a costruirlo. Molte grazie, sei stato molto gentile. – user1978591