Simplified message flow
Figure 10 is a simplified version of Figure 9 with
the optional messages and responses omitted.
Figure 11 shows how publish and subscribe messages flow between
the publisher, the subscriber, and the broker queues. In Figure 12 this
is extended to a two-broker system.
The flow of messages when retained publications are used is shown in Figure 13. In this case, the subscriber receives the current retained
publication as soon as it registers a subscription. In Figure 14,
the subscriber registers with the 'Publish on Request Only' option,
so it doesn't receive the publication until it sends a Request Update command message. (Note that the first publication is not delivered to
the subscriber, because it is updated by the second publication before the
update request is received).
Figure 11. Flow of messages in a single-broker system. The subscriber registers
a subscription by putting a message on the broker's control queue (1).
Subsequently, a publisher puts a publication message, for the same topic,
on the corresponding stream queue in the broker (2). The broker forwards the
publication by putting the same message on the subscriber queue (3), from
where the subscriber application can get it (4).
Figure 12. Flow of messages in a multi-broker system. The subscriber registers
a subscription as in Figure 11(1). Broker 2 forwards the subscription
by putting a message on the control queue of Broker 1 (2). Subsequently, a
publisher puts a publication message, for the same topic, on the corresponding
stream queue in Broker 1 (3). The publication is forwarded to Broker 2 (4),
and then to the subscriber queue (5), from where the subscriber application
can get it (6).
Figure 13. Flow of messages using retained publications. A publisher sends
a retained publication by putting a message on the appropriate stream queue
in the broker (1). The broker stores the publication on an internal queue
(2). Subsequently, a subscriber registers a subscription, to the same topic
and stream, by putting a message on the broker's control queue (3). The
broker sends the current retained publication for this topic by putting a
message on the subscriber queue (4), from where the subscriber application
can get it (5).
Figure 14. Flow of messages using publish on request only. A publisher sends
a retained publication to a stream queue in the broker (1). The broker stores
it on an internal queue (2). A subscriber registers a subscription, to the
same topic and stream, by putting a message on the broker's control queue
(3), but it uses the 'Publish on Request Only' option so the broker
takes no action. Subsequently, the publisher sends a second retained publication
to the broker (4), which replaces the first one on the internal queue (5).
The subscriber then sends a request update message to the broker's control
queue (6). This causes the broker to send the current retained publication
to the subscriber queue (7), from where the subscriber application can get
it (8).