Skip to content

Cardinalities

The diagram below demonstrates the different cardinalities that are allowed between various components. Everything in the diagram is for the same Channel and StreamId. If other Channels or StreamIds were in use, they would not interact with anything in this diagram (other than sharing the underlying UDP channel).

Machine 2 Machine 1 images/ 47.logbuffer images/ 15.logbuffer publications/ 23.logbuffer publications/ 7.logbuffer Aeron Client 3 Application Logic Client Conductor Subscription 5 Subscription 6 Aeron Client 4 Application Logic Client Conductor Subscription 8 Aeron Client 2 Client Conductor Application Logic Publication 23 Aeron Client 1 Client Conductor Application Logic Publication 23 Exclusive Publication 7 Media Driver Receiver Media Driver Sender Channel Session 2 Session 2 Session 4 Session 4

Use the tabs above to step through the animation.



An Application thread publishes the red message on Exclusive Publication 7. Note that the Exclusive Publication 7 API object is the only one writing to this Publication log buffer.

Another application thread publishes the green message on Publication 23, which is a Concurrent Publication.

The Sender iterates through its list of Network Publication log buffers that it needs to send from and sends from Publication 23 first (it iterates from a different starting point each time, so you cannot predict which it will send first). It sends the green message to Machine 2, which uses it to rebuild a copy of Publication 23 in Image 47. These numbers are just registration ids (ids generated within the Media Driver), and are unlikely to be the same.

Before the Sender gets to the red message, Aeron Client 2 publishes the purple message. It does this using a Concurrent Publication that shares the same log buffer as the one in Aeron Client 1. The receiving application will not be able to tell whether the message came from Client 1 or Client 2 as the SessionIds on their messages will be the same.

The Sender now sends the red message to Machine 2. Notice that the green message arrived on Machine 2 first, even though the red message was published first. The ultimate processing order of messages within a Publication log buffer (same SessionId) is guaranteed, but the order across different Publication log buffers (different SessionIds) is not.

The blue message is published from a different thread that published the green message. This is ok as Publication 23 is a Concurrent Publication. There are now two messages that need sending. Note that when the Sender checks a Publication log buffer for messages to send, it will send as many messages as it can fit into one UDP datagram to the Receiver, so it may send more than one message at a time.

🏇 It's neck and neck between the red and green messages! They've both reached Machine 2, but which will be read by the application first? A thread on Aeron Client 3 polls Subscription 5. Subscription 5 is connected to both Images as they are for the same Channel and StreamId, and reads from them in a round robin fashion. The winner is... the green message! As you can see, it could equally have been the red message. This is another point at which message ordering can change for messages across different Sessions.

When the receiving application polls the Subscription, it passes in a FragmentHandler (long messages may be fragmented when writted to the Publication log buffer - it is up to the application to reassemble them) and a limit. The Subscription polls all of the Images it is associated with and passes all the unread messages, up to the limit, to the handler. Within the same poll, the Subscription also passes the red message to the handler, because it was sat waiting in Image 15. The Subscription returns from the poll when all the messages (fragments) have been read, or the limit (count) has been reached.

The Sender polls the Publication log buffers and sends the purple and blue messages in one packet to the Receiver. Image 47 log buffer is now a copy of Publication 23 log buffer.

The same thread in Aeron Client 3 polls Subscription 5 again and receives the remaining messages. You can see that the order of messages Published to Publication 23 is preserved (green, purple, blue) and that messages from different Sessions (red) are interleaved on the receiving end.

Aeron Client 3 has another thread that wants to read from this Channel and StreamId, but Subscriptions are not thread safe, so the thread uses a different Subscription - Subscription 6. When the thread polls Subscription 6, it iterates through the Images in a different order than Subscription 5, reading the red message from Publication 7 first, then the messages from Publication 23. Again, note that the order of messages from Publication 23 is preserved, but the interleaving between Sessions is different.

And finally, there could be another application on the same machine (using the same Media Driver, to access the same log buffer files) that creates a Subscription to the same Channel and StreamId. Again, this might poll the Images in a different order.

So here we have a comprehensive example of multiple Publications, Publication types and Subscriptions, all sending messages with the same Channel and StreamId. This example could be more complicated if there were another sending machine, but it would only be more of the same - another Publication log buffer on the new machine and corresponding Image log buffer on Machine 2. The Subscriptions would iterate over three Image log buffers.

A lot of the above also applies to IPC communications. There would be no Sender or Receiver involved, but it is still possible to have multiple Concurrent and Exclusive Publications over IPC on the same machine. Just cut a vertical slice out of the diagram, removing the Sender, Receiver and Image log buffers, then make the Subscriptions read directly from the Publication log buffers.