It’s easy to focus on the reliable UDP protocol and the multicast support, but what’s important about Aeron is its system architecture. As noted elsewhere, it all combines together in “mechanical sympathy” and once you have that you can interconnect with high performance transports [1].
So you set up an Aeron Server on your machine. That handles all external network communication at the message layer (NAKs, etc). Every “Aeron Client” process communicates with that Server to stand up shared memory pipes. The messaging client solely deals with those pipes (cache efficient, etc). They subscribe to channels at host:port/topic but it is not direct network delivery to them (the client is transport agnostic, besides the subscription). The network service directs data to the clients shared memory queue.
Once they have that base networked-IPC setup, you can maximize performance with it using reliable UDP and fan out common data (eg marlet data) using multicast.
Then Aeron further adds Archiving (to persist) and Clustering (to scale late join / state replication) components. This stuff works well with kernel bypass :)
[1] It could work with RDMA as well, but the ticket regarding that was closed 8 years ago. Maybe if there was AI/GPU workload interest.
A whole different tamale, but Apache Iggy feels similar-ish, as a persistent message streaming system. Also using UDP, this time with QUIC, which is a pretty future-forward protocol that I love to see targetted (also has a rest API and its own binary protocol). https://iggy.apache.org/
I had not heard of Iggy, love the mascot! Looks to be pretty comprehensive messaging system focusing on persistent streams; lots of batteries included like auth and monitoring.
While that has some sick throughput benchmarks, it is a pretty different architecture and Aeron will have way (orders) lower and more stable latencies. But it won’t work on as many networks as Iggy.
Iggy client SDKs are easy to make because they just need to speak socket. Aeron client SDKs are “easy” to make because they just need to figure out framing shared memory. (And the orchestrator handles the network getting it there).
So you set up an Aeron Server on your machine. That handles all external network communication at the message layer (NAKs, etc). Every “Aeron Client” process communicates with that Server to stand up shared memory pipes. The messaging client solely deals with those pipes (cache efficient, etc). They subscribe to channels at host:port/topic but it is not direct network delivery to them (the client is transport agnostic, besides the subscription). The network service directs data to the clients shared memory queue.
Once they have that base networked-IPC setup, you can maximize performance with it using reliable UDP and fan out common data (eg marlet data) using multicast.
Then Aeron further adds Archiving (to persist) and Clustering (to scale late join / state replication) components. This stuff works well with kernel bypass :)
[1] It could work with RDMA as well, but the ticket regarding that was closed 8 years ago. Maybe if there was AI/GPU workload interest.