Sì, puoi invertirlo e non ci sono svantaggi nell'usare tale strategia di connessione ... purché sia adatta al tuo scopo.
In ZMQ, il concetto di guida dietro "vincolante" e "collegamento" è che una parte è spesso considerata più affidabile (e in genere ci saranno meno nodi), e l'altra parte è considerata più transitoria (e potrebbero esserci più nodi numerosi). Il lato affidabile sarebbe considerato il tuo "server", e dovresti bind() da quel lato, il lato transitorio sarebbe considerato il tuo "cliente" (o client s), e dovresti connect() da quel lato.
In genere, pensiamo a un "server" stabile che pubblica informazioni costantemente, a molti abbonati "client" che possono andare e venire. Questo è rappresentato negli esempi che vedi: bind on pub, connect on sub.
Ma, si potrebbe facilmente avere un "server" stabile che si abbona a qualsiasi output da molti editori "client" che si connettono ad esso, accettando qualsiasi informazione che stanno inviando mentre sono disponibili. Collegati su sub, collegati al pub.
Non sei limitato a un solo server, è solo l'esempio più semplice, tuttavia, sei più limitato se stai eseguendo tutte le tue prese sullo stesso computer. Il binding sullo stesso indirizzo con più di un socket produce un conflitto, ma è possibile connettere tutti i socket allo stesso indirizzo desiderato.
In molti casi, entrambi i lati della comunicazione sono realmente pensati per essere affidabili e di lunga durata, nel qual caso è utile pensare al nodo che invia le informazioni come server e quello che lo riceve come client . Nel qual caso, siamo tornati a legare su pub, connettersi su sub.