Yes, you can cancel it, and there are no shortcomings in using this connection strategy ... provided that it meets your goal.
In ZMQ, the concept of driving "bindings" and "connections" is that one side is often considered more reliable (and usually there will be fewer nodes), and the other side is considered more transitional (and there may be more nodes). The trusted side will be considered your "server", and you must bind() on this side, the transition side will be considered your "client" (or client s ), and you must connect() on this side.
As a rule, we constantly publish stable "server" publication information for many "client" subscribers who may come and go. This is presented in the examples you see: bind in pub, connect on sub.
But you can just as easily have a stable "server" that subscribes to any output from many "client" publishers who connect to it, accepting any information that they send while they are available. Tie to the south, connect to the pub.
You are not limited to one server, this is just the simplest example, however you are more limited if you use all your sockets on one computer. Binding to the same address with multiple sockets will lead to conflict, but you can connect as many sockets to the same address that you like.
In many cases, both sides of the communication really need to be reliable and durable, and in this case it is useful to think about a node that sends information as a server, and one that receives it as a client. In this case, we will return to the binding in the pub, connect to the sub.
Jason source share