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).

Home