In reality, not all requests are waiting for a response, but they are not waiting for a response. So compared with the REQ-REP, PUB-SUB mode is much easier to understand. Have you heard of broadcast? Have you used the radio? That's what it means.
Publish-subscribe Pattern: Publish and subscribe mode.
In reality, not all requests are waiting for a response, but they are not waiting for a response. So compared with the REQ-REP, PUB-SUB mode is much easier to understand. Have you heard of broadcast? Have you used the radio? That's what it means.
Correspondingly, there are two sockets in this mode: ZMQ_PUB & ZMQ_SUB. Corresponding to the radio station and the radio station respectively.
ZMQ_PUB
ZMQ_PUB is mainly used by message publishers to send messages. All connected peer nodes can receive messages sent from them. The zmq_recv (3) API cannot be used on this socket. The reason is obvious. Zmq_send will never block the socket. if the subscriber has an exception, the message will be discarded.
Summary of ZMQ_PUB characteristics |
Compatible peer sockets |
ZMQ_SUB |
Direction |
Unidirectional |
Send/receive pattern |
Send only |
Incoming routing strategy |
N/ |
Outgoing routing strategy |
Fan out |
ZMQ_HWM option action |
Drop |
ZMQ_SUB
Obviously, the subscriber uses this socket to receive messages published by the publisher. When using this socket, you must explicitly call zmq_setsockopt and set ZMQ_SUBSCRIBE and filter. If this parameter is not set, no messages are received.
Summary of ZMQ_SUB characteristics |
Compatible peer sockets |
ZMQ_PUB |
Direction |
Unidirectional |
Send/receive pattern |
Receive only |
Incoming routing strategy |
Fair-queued |
Outgoing routing strategy |
N/ |
ZMQ_HWM option action |
Drop |
Summary
PUB-SUB mode generally does not process key data of the system. The publisher does not care whether the subscriber receives the published message or whether the subscriber has received all the messages sent by the publisher. You do not know when the subscriber will receive the message. Therefore, it is not logically reliable.
In fact, even if you start the subscriber first, then start the publisher. The subscriber may not receive all messages either. The reason is that the publisher has started to spread messages, and the subscriber may not have completed the connection. If you need to ensure that, you need to synchronize the two. The most silly way is to let the publisher sleep for a while before sending messages, but this method is just as unreliable as it sounds.
A subscriber can subscribe to multiple publishers. At the same time, the subscriber uses the filter to filter the messages they need. Note that the filter is used at the subscription end. That is to say, all messages will reach all subscribers, and the subscriber will lose the messages they do not need based on the filter.