[zeromq-dev] Actor Model

Mon Dec 17 10:58:32 CET 2012

Let me add some more patterns here from what you said. The details will
require more experience from my part to be understood.

A)actors and relations between them are static.

solution: a) use the disruptor pattern.
          or b) explicitly link specific actors together,"merging" similar
actors together.

B) dynamic, random number of actors, links

main problem: load balancing

solution:
          a)consistent hashing (uses virtual nodes in the hash ring to load
balance, see riak)
balancing works by changing the virtual nodes that represent the servers in
the hash ring

           b) location resolution(each server has a local location
resolution broker that routes msgs)
transferring an actor requires updating the location to each broker.

In case you know who will send msgs to the transferred actor(even if the
topology is dynamic, ex. graph processing)
           c)have the specific actors update the location at which they
will find the transferred actor.

>From my understanding erlang is solution B b), otherwise the virtual
machine wouldnt be able to transfer processes from one sheduler to the
other.

( I omitted the previous thread pool pattern(2) because it can work only
locally, maybe someone can fix it?)

2012/12/15 Gleb Peregud <gleber.p at gmail.com>

> Erlang solves this the following way:
> - one OS thread is run per cpu core (such thread is called a scheduler)
> - each erlang actor (called "process") is a very lightweight thread
> - each scheduler has it's own independent run queue
> - Erlang virtual machine handles load balancing of erlang processes
> between schedulers by migrating them between
> - if scheduler's run queue is empty it steals work from other
> schedulers (get's an erlang process from another scheduler and adds it
> to own run queue)
> - if scheduler's run queue is too long it gives away some erlang processes
>
> Sockets are handled by some sort of kernel polling and each socket is
> assigned to specific erlang process.
>
> I am a developer of two Erlang systems which are capable of handling
> 1MM+ TCP sockets on one physical server. Google for "Oortle erlang
> factory" to see a presentation about it. It was optimized for
> broadcast speed. It sends 1MM of 500 byte messages to 1MM of users
> from one physical server and end-to-end latency over LAN is < 1.5s
> (i.e. last client gets the message in at most 1.5 second after
> broadcast has been initiated).
>
> On Sat, Dec 15, 2012 at 2:29 PM, Apostolis Xekoukoulotakis
> <xekoukou at gmail.com> wrote:
> > This question is of interest to me as well.
> >
> > Let me give some answers, I havent really implemented them yet:
> >
> > 1. Each thread has one socket. You hash the unique name of the actor and
> > assign it accordingly to a thread.
> > advantages: no contention.
> > disadvantages: it cannot work if actors have different processing needs.
> >
> > You rely on the randomization of the hash function to balance the work.
> >
> > this is pretty useful for a graph processing system(millions++ of actors)
> >
> > 2.You have a central broker which implements a locking mechanism. Threads
> > ask for work, they receive the actors name plus the message that needs
> to be
> > processed.
> > All the actors data are shared by all the threads.
> >
> > advantage:load balancing works all the time
> > disadvantage: latency because each thread has to request for work.
> >
> >
> > From an algorithmic point of view, how is a disruptor pattern faster
> than a
> > queue when we want to implement an actor model?
> >
> > I would be interested to know how akka or erlang solve the above problem
> of
> > distributing actors to threads.
> >
> >
> > 2012/12/15 Min Yu <miniway at gmail.com>
> >>
> >> Akka on zeromq would be an another fun for you.
> >>
> >> http://doc.akka.io/docs/akka/snapshot/scala/zeromq.html
> >>
> >>
> >> Thanks
> >> Min
> >>
> >> Dec 15, 2012 9:01 PM Gleb Peregud <gleber.p at gmail.com> 작성:
> >>
> >> If you want the most natural way to code your program according to
> >> actor model, just use Erlang. It has a zeromq library, hence you can
> >> communicate with outside world using zmq.
> >>
> >> On Sat, Dec 15, 2012 at 12:27 PM,  <wilfried at hafner.ws> wrote:
> >>
> >>
> >> hi peeps,
> >>
> >>
> >> i would like to ask you for some ideas/hints on an actor-model
> >>
> >> design on top of zeromq. zeromq ships with everything i need,
> >>
> >> a mailbox, message routing, i don't have to worry about threads etc.
> >>
> >>
> >> i think the straightforward way would be to give every actor
> >>
> >> one or more sockets for sending and receiving messages, depending
> >>
> >> on the used patterns (pub-sub, req-rep). but it seems to be a big
> >>
> >> overhead, since the max. number of sockets per context is limited.
> >>
> >> on the other hand, i would have to share some sockets and write
> >>
> >> a lot of messaging features by myself. so zeromq would be useful
> >>
> >> just for the communication between some processes or nodes.
> >>
> >>
> >> it's similar to an component based entity system, communication between
> >>
> >> entities<->entities, entities<->system and system<->system
> >>
> >> should be handled through an event/message bus. Although it's not for
> game
> >>
> >> development, 10k+ entities are possible, which would require
> >>
> >> at least more than 10k sockets.
> >>
> >>
> >> thank you for your suggestions!
> >>
> >>
> >> best regards,
> >>
> >>
> >> wil
> >>
> >>
> >> _______________________________________________
> >>
> >> zeromq-dev mailing list
> >>
> >> zeromq-dev at lists.zeromq.org
> >>
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>
> >>
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>
> >
> >
> >
> > --
> >
> >
> > Sincerely yours,
> >
> >      Apostolis Xekoukoulotakis
> >
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>

-- 

Sincerely yours,

     Apostolis Xekoukoulotakis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121217/e0f39337/attachment.htm>