Could AKKA remoted actors be a used in a p2p swarm context?

Question

Most of the use cases I've seen for Akka actors are highly performing multicore servers or local clusters.

I'm curious about it's applicability to more remote high latency and highly failing swarm structures such as p2p networks.

The application I have in mind would have rules about the trustability and or resourcefullness of the swarm nodes giving them some status, as bittorrent would. It would also need to be able to propogate transactions across the swarm as well as possible, but eventual or partial consistency would be acceptable. Scalability would be a higher priority than consistency.

Is AKKA a potential solution for building something like this? Would it have any specific advantages or disadvantages over other approaches.

Answer 1

The main problem with using Akka in this context is that the Actor system does not have an appropriately maleable membership management system for such decentralized distributed computing.

You need something that can handle the node churn you describe in your scenario. In particular you need something that can monitor when nodes join, leave, and are presumed dead and disconnected due to faults. I would recommend looking at Ibis: http://www.cs.vu.nl/ibis/ with a gossip based registry. You still need one well known bootstrap node to bring the system up, but otherwise the Join, Elect, Leave model Ibis uses will provide the scalability you are looking for when combined with the Gossip based registry. That system is similar to Akka actors in a way in that it is based on a system of up or down calls and unidirectional pipes over which you pass messages. Very easy to program distributed stuff once you get the Fu of it.

In terms of eventual consistency, that is a known hard problem in such large distributed environments. I would need to know more about the kinds of transactions you want to distribute and the level of consistency and history preservation required to make more recommendations there. Some recent papers have proved that the best you can come up with though in such a hostile environment is fork-causal-consistency, where at least everybody can see that history has forked, if not determine the "winning" fork, without some other fork resolution mechanism.

Bitcoin is an interesting example in this space, where "winning" is determined by longest chain, but there are other solutions in this space that may or may not work depending on application semantics. Your question is a little too vague to give specific recommendations in such a large design space.