Skip to content

Aeron Transport

10,000 ft overview

Let's start by looking at Aeron Transport from a very high level to introduce some terminology.

Assume we have a sending application that wants to send messages to a receiving application using Aeron. An application is referred to by Aeron as an Aeron Client and the terms are interchangeable. In this example, Application 1 sends messages to Application 2, which is on a different machine.

Application 1 (Aeron Client 1) Media Driver 1 Shared Memory Sending machine (writing to a) publication sending sending Application 2 (Aeron Client 2) Media Driver 2 Shared Memory Receiving machine receiving receiving (reading from a) subscription API API Network

Use the tabs above to step through the animation.



Application 1 sends a message by writing it to a shared memory buffer that has been dedicated for it to send messages to Application 2. It does this by calling into Aeron Client API code (application code is yellow; Aeron code is blue). This is known as writing to a publication.

Aeron provides a component called the Media Driver (usually referred to as just the Driver) that monitors the shared memory buffer and does the driving of the network. Media Driver 1 on the sending machine polls the shared memory buffer, reads the message and sends it in a UDP packet to Media Driver 2 on the receiving machine. This is known as sending.

Receiving messages is the opposite of sending. Media Driver 2 polls the network for new UDP packets, reads the UDP packet into a shared memory buffer dedicated to messages received from Application 1. This is known as receiving.

Application 2 polls the shared memory buffer for new messages and reads the message. This is known as reading from a subscription.


A few notes

Even at this very high level, it's worth pointing out a few things.

IPC

Aeron can send messages between applications on the same machine, known as IPC (Inter-Process Communication). When doing so, there is no need to incur the overhead of sending messages via UDP. The Media Driver still has some admin responsibilities, including creating the shared memory buffer in the first place, but it is not directly involved in message transfer. The sending application writes messages to the shared memory buffer and the receiving application polls the same buffer to receive messages.

This is very similar to passing messages across threads via a ring buffer, except this also works across processes. Both sending and receiving applications use the same shared memory buffer and access it no differently to their local heap memory.

Using IPC, the publication and subscription steps are present, but the sending and receiving steps are not.

Application 1 (Aeron Client 1) Media Driver Shared Memory Same machine publication Application 2 (Aeron Client 2) subscription API API

Use the tabs above to step through the animation.

Application 1 sends a message by writing it to a shared memory buffer in exactly the same way that it would if it were sending the message to another machine. Again, this is known as writing to a publication.

Application 2 polls the same shared memory buffer that Application 1 wrote to (it is accessible to Application 2 as it is on the same machine). Again, this is known as reading from a subscription.


Unidirectional

Communications are unidirectional. If the receiving application needs to respond to the sending application, it needs to set up a similar channel in the reverse direction. The messages would probably also utilise a protocol that contained a correlation id so responses could be matched with requests.

One Media Driver per machine

A single Media Driver is required per machine that runs applications using Aeron. Several applications on the same machine can read / write their shared memory buffers and a single Media Driver can service them all. The Media Driver's job is to ship messages from the shared memory buffers onto the network and vice versa.

Media Driver execution

The Media Driver can run in a standalone process. It can also run embedded within the (Java) application if required. Either way, the diagram above remains the same. The only thing that changes is how the Media Driver is given processing resources. In fact, there are two implementations of the Media Driver: one written in C, the other in Java. When running standalone, either can be used.

Low overhead sending / receiving

The Media Driver usually runs in its own process / thread. That means the only overhead incurred by an application when sending a message is writing it to a shared memory buffer. That gives the application thread more time to do other application-level processing. The shipping of network traffic is all done in the background by the Media Driver. Receiving data has similar low overhead - just polling a subscription memory buffer to see if it contains new messages.