aeron | Efficient reliable UDP unicast , UDP multicast

Run the following command from the Aeron base directory to simplify the build:

$ cppbuild\cppbuild

Thinking about Aeron in those terms doesn't really help your understanding as Aeron is flexible with regards to it's reliability options - especially when Archive and Cluster are also considered. The best response would be "at most once", but that hides a lot of detail.

As it states in the README.md, Aeron is a layer 4 protocol. So the reliability options are similar to what you would get with TCP. Lost messages are redelivered as long as the remote ends are alive and heartbeating. However this general requirement can be loosened. For multi-node distribution (multicast and MDC) the flow control setting can affect reliability. For example using max strategy means that if one of the receivers reports that it is up to date the flow control window can move forward and other slower receivers may end up missing data that can not be nakked. Even using the min strategy slower receivers that are unresponsive for long enough can drop out of the flow control group and be left behind. There is also options to disable nakking from receivers so any loss will be gap-filled.

To allow recovery in these situations is where Archive comes in as it allows messages to be stored to enable "late join" behaviour. Therefore if once the archive has acknowledged that a message is stored, then you could consider this to be "exactly once" in practical terms.

Cluster takes this to the next level by using a quorum agreement to prevent message loss in the case of node failure.

Yes it can. Returning a positive position value indicates only that the message has been written to the term buffer. The term buffer is generally stored in a memory only file system. E.g. on Linux this is /dev/shm.

Note that fsyncing /dev/shm has no effect as it is not backed by non-volatile storage.

Aeron Archive is the means to persistently store messages.

Yes, the Aeron C Media Driver does have the features to support Aeron Cluster. It also has the benefit of lower and more predictable latency when configured correctly plus access to extensions to provide transport encryption and reduced latency via ef_vi and DPDK native support.

Yes, it is possible! The context should be built like this:

Currently Aeron Cluster requires that logic to process events from Cluster's replicated log has to be implemented as a ClusteredService.

Having Cluster run without services and providing a replay feature similar to how replay from the Archive works is a feature that is being considered.

RSocket provides a common programming interface to multiple transports. You can choose the transport based on the qualities of service the transport provides. For example, if you require ease of firewall traversal then choose WebSocket, if you require low-latency and high-throughput transfer choose Aeron. All things are relative. Aeron can traverse firewalls but configuration is more specialised and WebSocket can give reasonable performance but it is not in the same category as Aeron.

Many other factors come into play so you need to understand the underlying transports with the qualities they provide and match these up against your requirements.

I was able to make it work with adding a ttl config option.

Publisher

Yes, Archive tagged replicate does work with both the Java and C media drivers. It is possible you have something not configured correctly. This system test runs against the Java and C media drivers.