At least in terms of open-source, I often say that the Aeron code base is one of the best projects to study in terms of software quality (especially Java). The real-logic (now Adaptive) guys are a skilled and knowledgeable bunch.
One of the greatest things about Aeron is just the fact it exists. If one goes e.g. to StackOverflow or a place with the same patronizing attitude of "experts", they will tell you no one needs UDP, even in the same DC on reliable network, especially no one needs multicast. Any sane person should use TCP with a loop for multiple destinations, they would say, and one should measure before optimizing, they would say. But they themselves probably never had a chance to measure. Yet Aeron guys, who are real expert in low-latency systems, just delivered an ultra-fast thing that is quite simple in design.
Aeron latency histograms vs TCP are quite nice in the same DC on enterprise-grade networking hardware. But it really makes sense to use if a single-digit or low-double digit microsecond latency improvement on P50 is worth the effort. Or if the long tail with TCP is a dealbreaker, as Aeron has much nicer P99+ regardless of how well optimized a TCP setup is. Also, if one can leverage multicast that's nice, but not only clouds have it disabled, and Aeron works fine with unicast to N.
However, there are gotchas with threading and configuration overall. Cross-DC setup may surprise in a bad way if buffers are not configured to account for bandwidth-delay product. Any packet loss on high-latency network leads to a nasty NACK storm that is slow to recover under load. It's better to set the highest QoS and ensure the network is never dropping packets, e.g. calculate the real peak instant load vs hardware capacity. Relative latency savings cross-DC become less interesting the longer the distance, so there's nothing wrong with TCP there. Another note is that, e.g. ZMQ is slow not because of TCP but because of its internals, almost 2x slower for small packets than raw well-tuned TCP sockets, which are not that bad vs Aeron. Also, Aeron is not for sending big blobs around, the best is to use it with small payloads.
Aeron is designed with mechanical sympathy in mind by the guys who coined this term and have been evangelizing it for years, and it's visible. Lots to learn from the design & implementation (tons of resources on the web) even without using it in prod.
>Also, if one can leverage multicast that's nice, but not only clouds have it disabled, and Aeron works fine with unicast to N.
How did that happened? Seems multicast is already built in, just use that for massive broadcast. Is TCP used just so we can get an ACK that it is received. Seems multicast and UDP shouldn't be a problem if we just want massive people to listen in on it, but if we want to also track these people then that is another story.
From a user perspective, use UDP/multicast all the way. Let the client to request something if it is dropped or missing or otherwise just multicast for everything.
I mean multicast is often disabled not only in the cloud DCs, but on-premises as well, intentionally for different reasons.
> Relative latency savings cross-DC become less interesting the longer the distance, so there's nothing wrong with TCP there.
Long fat pipe sees dramatic throughput drops with tcp and relatively small packet loss. Possibly we were holding it wrong; would love to know if there is some definitive guide to doing it right. Good success with UDT.
I would not recommend using Aeron on long fat pipes with a chance of packet loss for hight throughput. It was several years since I stress tested this, maybe there have been improvements. I saw some work on that in release notes after. But that was the worst case as recovery was slow.
I would think of UDP with redundant encoding / FEC, to avoid retransmits.
After years of maintaining and using an application suite that relies on multicast for internal communication, I would hesitate to use "reliable" and "multicast" in the same sentence. Multicast is great in theory, but comes with so many pitfalls and grievances in practice. Mostly due to unreliable handling of switches, routers, network adapters and TCP/IP stacks in operating systems.
Just to mention a few headaches I've been dealing with over the years: multicast sockets that joins the wrong network adapter interface (due to adapter priorities), losing multicast membership after resume from sleep/hibernate, switches/routers just dropping multicast membership after a while (especially when running in VMs and "enterprise" systems like SUSE Linux and Windows Server, all kinds of socket reuse problems, etc.
I don't even dare to think about how many hours I have wasted on issues listed above. I would never rely on multicast again when developing a new system.
But that said, the application suite, a mission control system for satellites, works great most of the time (typically on small, controlled subnets, using physical installations instead of VMs) and has served us well.
"reliable" means that if one of the recipients observes a gap, it can ask for a replay of the missing packets.
Sure. But if you don't have reliability at the network layer you don't have any chance to have a reliable transport layer.
I wonder how many times reliable UDP has been implemented? It's gotta be gazillions...
Millions of times every year by all university students doing introduction to UNIX networking protocols projects across the planet.
In general most people don't do networking right, especially within real-time systems.
As people discover the problems with their approach, they rewrite it.
I'm my experience it's generally better not to have transparently reliability for lost data as well. The correct handling should be application-specific.
With Aaron I would think the focus should be on 'efficiënt', not reliable. Within a datacenter they are orders of magnitude faster than plan UDP. You get this crazy efficiency at the cost of reduced flexibility in how you send messages.
I haven't seen the makers of Aeron (or anyone else) claim it's "orders of magnitude faster than plain UDP." Do you have a link to something about this? It doesn't pass the smell test for me unless you're talking specifically about using Aeron within a single machine (where it uses shared memory instead of the network)...but you said "Within a datacenter" not "Within a computer."
It has been a while since I saw their presentation. What I remember is that Aaron has an insanely low delay even in the high percentiles, that is orders of magnitude better. Throughput for a large stream of data is probably similar to plain UDP. Please correct me if I remember wrong.
It does have great tail latency. But it's not a silver bullet, but careful engineering. And you pay for the latency with spinning threads. It's the architecture that makes it to stand out. In the end, it's just the same old UDP sockets, not even io_uring at least in the free public version. But one can use LD_PRELOAD if hardware has this trick - but again, it's not specific to Aeron.
I like the idea of muticast.