Skip to content

Multiple Destinations

todo: work in progress, a lot of this is just rough notes

Publications

MDC publication is either in dynamic or manual mode.

3 diagrams:

  1. normal publication and subscription. show channel string. SMs and NAKs flow to the publication's endpoint
  2. dynamic mode. publication has a control address aeron:udp?control=localhost:40456|control-mode=dynamic. SMs and NAKs go to the control address, along with requests to add new subscriptions. Subscriptions need to specify the control address in addition to their own endpoint address for receiving data. subscription channel: aeron:udp?endpoint=localhost:40457|control=192.168.0.1:40456|control-mode=dynamic.
  3. manual mode. The publishing side uses Publication.addDestination(endpoint)/removeDestination(endpoint). Example: aeron:udp?control=localhost:40456|control-mode=manual. Subscriptions don't need to specify the control address. Example on the publishing side: Publication.addDestination("aeron:udp?endpoint=localhost:30567").

Multi-Destination Subscriptions

Referring back to the Channels, Streams and Sessions Diagram, each Image log buffer is normally identified by a Channel, StreamId and SessionId tuple. The Channel that the Receiver listens on for a Subscription is known as a destination, as it's the destination for a Publication. Aeron supports Multi-Destination Subscriptions, shown below. Subscription 1 has multiple destinations - the endpoints for Channels 1 and 2. The Subscription is created with no destinations and destinations can be added or removed later.

Machine 2 Machine 1 Subscription 1 (Channel 1 & 2, Stream 4) Publication 1 (Channel 1, Stream 4, Session 56) Publication 2 (Channel 2, Stream 4, Session 56) Publication logbuffer (Channel 1, Stream 4, Session 56) Publication logbuffer (Channel 2, Stream 4, Session 56) Image logbuffer (Channel 1 & 2, Stream 4, Session 56) Sender Receiver Channel 2 Channel 1

Note this is not the same as a ConcurrentPublication. That is where there are multiple Publication objects writing to one Publication log buffer on the sending machine, which is replicated to one Image log buffer on the target machine.

This is different. This is where more than one Publication log buffer is be replicated into one Image log buffer, which obviously raises questions. Won't Publications 1 and 2 be competing to write in the Image? What if they overwrite each other's messages? What if their positions in the log buffer are far apart and don't fit in the same term in the Image log buffer?

This is actually used in the very constrained scenario of Replay Merge, which will be covered later in the Aeron Archive section. For the purpose of this section, replay merge is where one Channel, e.g. Channel 1 above, is a live stream of data, which is also being recorded in Aeron Archive. Subscription 1 wants to listen to the live stream, but wants to go back and start from an earlier position, so it starts by replaying the recorded live stream on Channel 2. The Channel 1 destination is not added to begin with.

Any messages from Channel 2 at a given position are identical to the original messages on Channel 1 at that position when they were live, so there is no conflict of different messages competing for the same position.

At the start, the Subscription only has Channel 2 as a destination. It consumes those messages (faster than the live stream is progressing), then when the position on Channel 2 is within 1/4 of a term length of the live messages, the live Channel 1 destination is added. Both Channels write to the Image log buffer. Channel 2 will be writing to an earlier position than Channel 1. Eventually, messages from Channel 2 will meet the start of the messages from Channel 1. At this point, the Channel 2 destination is removed, leaving the Subscription only reading from the live stream on Channel 1.

Multi-Destination-Cast Publications

Multiple Destinations

While it is possible to have more than one Subscription for an Image on the receiving machine, MDC is about sending to multiple receiving machines.

Here, the way connections are established is in reverse. Rather than the Sender sending a SETUP message to the single Receiver, instead, the Sender sets up a control channel and listens for Receivers adding themselves to the Sender. When a new message is published, the Sender will send to all attached Receivers. This is not broadcast - there are n messages sent for n attached Receivers.