Why Actors in Actor Model can have multiple adresses

Question

Hello this is preety straightforward question, i've seen and read around that people write that the address can point to multiple actors. I'm wondering why? What would be the use case of such.

Let's say router actor can have one address but then, on message it can dispatch the messages to multiple actors but each of it's children still might have only one address.

Thank you

Answer 1

First, let's analyze your example: indeed, a message payload can be delivered to multiple actors, as you have described (i.e. via router), as well as via pub-sub pattern .

I think, pub-sub is better because of convenience as there is no need of additional actor (router) in-between. Another reason, is less coupling in the pub-sub case: to subscribe and publish the message, there is need to know the address only, meanwhile in the router case, the donwstream actors have to know also at least router address and "subscription protocol", (e.g. donwstream.send<subscribe_me, message_type>(router_address, donwstream.address) or the donwstream actors have to know router class instance and (in the worse case) they have to be children of the router (or to be owned by router) - e.g. (router.subscribe(downstream_actor)).

The last reason on the point which might matter and depends on the implementation, that is is not the same message is delivered: in the pub-sub model the original message is delivered for multiple actors, in the router case multiple clones of the original message are delivered.

Second, the multiple patterns with actor multi-addressing are possible. Here are a few examples:

• the actor's behavior might be different, whether a message of the same type is delivered to one or other actor's address, e.g. if actor owns some finite resource, say memory, and when it is about out of the resource, it might answer with rejections on it's "main" address, and still provide the resource on "critical" address. Without multi-addressing, you have to either share the resource between 2 different actors (discouraged) or to have 2 different types of messages (better).
• in rotor (disclaimer: I'm the author), one actor can subscribe to the other service-actor address for some silent-side effects, i.e. for auditing or logging messages which are coming for the service-actor.
• the message supervising can be implemented because of multi-addressing, e.g. in rotor the request-response pattern is implemented the following way: the request is routed via supervisor, which spawns a timer and a new address(X), and sends a payload copy to the original destination; then the response arrives at (X), it is just forwarded to the requesting-actor and timer is cancelled; however if the timer triggers, the supervisor creates a new message with error code (timeout) and delivers it back to the requesting-actor.
• something like NAT is possible, i.e. when 2 nodes are connected, and here is need to deliver a message from actorA from node1 to actorB node2, the message can be actually just delivered to the unique address of NAT-actor on node1 representing actorB, serialized it special way and send over network. The reverse procedure will happen on node2. In that case NAT-actor will have multiple addresses (like ports in real routers), and still will be transparent for actorA and actorB.