12

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.

barrymac
  • 2,750
  • 1
  • 20
  • 32
  • @Viktor Klang Ideally as many as possible really, on the scale of things like a single bittorrent , but a fairly big one. – barrymac Apr 12 '13 at 13:00
  • 1
    I think AKKA was designed having in mind highly coupled distributed systems (such as clusters) and not the scenario you describe (such as sensor networks or decentralized social networks, although these still lie in the distributed computing area but in the heterogeneous/decentralized field). But since I am not an expert lets wait for a better answer :D – vasilakisfil May 03 '13 at 16:31

1 Answers1

3

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.

Nick Palmer
  • 2,589
  • 1
  • 25
  • 34
  • Interesting that you mention bitcoin because the application that I had in mind was about distributed exchange and price discovery of digital assets such as bitcoin! So there's not a lot of computation, but a lot of realtime data passing. The approach to the version of the truth I was thinking about was to have rules about the quality of information, based on some confidence factors, such as historical reputation – barrymac May 15 '13 at 13:45
  • Relying on reputation is a good start, but reputation systems are open to collusion based attacks. Sounds like you are trying to crack a very hard nut. Best of luck. – Nick Palmer Jul 10 '13 at 04:11