-
Notifications
You must be signed in to change notification settings - Fork 1
Concepts
Both ActorSystem and ActorEngine are subclasses of ActorGroup, which is an abstraction of a group of actors. They are used to spawn actors, i.e., create actor objects and get them running.
The difference between ActorSystem and ActorEngine is that ActorSystem runs each actor with a separated thread (i.e., more actors, more threads) and ActorEngine runs managed actors with a set of threads (i.e., the number of threads are fixed if you want to restrict the computing resources for running the actors).
Each ActorSystem contains one zmq::context that is used to create zmq sockets, e.g., ROUTER for in-memory communication and PUSH/PULL for network communication.
NetGate is design for message delivery among different ActorSystems.
NetGate is independent from ActorSystem. Multiple NetGates can be used simutaneously with one ActorSystem. Customized implementation of NetGate is possible and allowed.
The current implementation of NetGate creates a pair of PUSH/PULL sockets when communicating with another NetGate.
For sending messages, local actors send messages to the Sender of NetGate, then the Sender forwards the messages to the Receiver of peer NetGate, and the Receiver finally forwards the messages to the receiver actors, as shown in the figure below.
+ ActorSystem A ---------------- + + ActorSystem B ---------------- +
| | | |
| + NetGate ------ + + NetGate ------- + |
| | | | | |
| Actor X ------- + --> Sender --- + --- + --> Receiver -- + ------> Actor Y |
| | Receiver <-- + --- + --- Sender | |
| | | | | |
| + -------------- + + --------------- + |
| | | |
+ ------------------------------ + + ------------------------------ +
Messages are serialized/deserialized inside the sender/receiver actor, instead of the Sender/Receiver of NetGate.
Other than sending/receiving messages to/from other ActorSystem, NetGate also support
-
Actor Registration: to register an actor with specified name such that remote actors can find this actor.
-
Actor Lookup: to lookup an named actor that is registered in a remote
NetGate. -
Actor Retrival: to obtain an
Actor(especially a remote one) based onActoInfo.
NetGateClient is a helper class to interact with NetGate actor, which provides a set of functions to send/receive messages to/from the NetGate actor.
Actor is a handle used to send messages to an actor object. An Actor may refer to a local actor object, or a remote actor object in another ActorSystem. Actor is lightweight so as to make it cheap to copy and store Actors.
For local actor object, Actor stores only the actor id. That means, for local in-memory message passing, we only need to know the id of the receiver actor object.
For remote actor object, Actor needs the receiver actor id and the actor id of the Sender in the NetGate.
Actor can be delivered by messages within the same ActorSystem, e.g., Actor a sends Actor b to Actor c such that c knows about b and c can send messages to b.
To deliver Actor from one ActorSystem to another, we need to convert Actor to ActorInfo before delivery and convert ActorInfo to Actor after delivery. ActorInfo stores the id of the actor and the url of the NetGate that can be used to communicate with the actor.
ActorBehavior defines the behavior of an actor object, where the most important behavior is how to process received messages, which basically updates the states of the actor object and/or send messages to other actors.
ActorBehavior is where we customize an actor, either by creating a subclass of ActorBehavior or by using the send/receive APIs of ActorBehavior properly.
ActorBehavior can send a message to an actor by ActorBehavior::send(), or send a request to an actor and actively wait for the reply by ActorBehavior::request(), or send a message after some delay by WithDelayedSend::delayed_send().
ScopedActor keeps a pointer to an ActorBehavior which is used to send/receive messages from other running actors in the current context.
Message is the content of the communication among actors. Each Message carries a Code, which tells what the Message is mainly for and will be used to find correspoding MessageHandler.
MessageHandler is used to process a Message. While Message erases the types of the message elements, the types will be recovered using the argument types of the MessageHandler. Therefore, the types of MessageHandler must match with the types of Message. ZAF calculates the hash values of types for both MessageHandler and Message, and check if the hash values match, to avoid illegal MessageHandler for most of the cases.
MessageHandlers store a set of MessageHandlers to process different kinds of Messages. MessageHandlers is essentially a hash map from Code to MessageHandler. For each Message, MessageHandlers finds the corret MessageHandler by the Code of the Message.