Feature: multicast

[thespianpy]

Feature: multicast

[kwquick]

Interesting idea... I'd like to take a little time to think through the implications and implementation of this. Thank you for the submission.

[j3hyde]

I'm new to Thespian but having looked into ZeroMQ in the past I had similar thoughts. I found that the Troupe concept is quite similar though. With the grain of salt that I'm not familiar with the underlying architecture, it seems like either the Troupe or the specific .tell()/.send()/.ask() call would specify a policy of send one-by-one/round-robin vs. send-to-all while the transport implementation (such as multicast vs. zmq vs. some other protocols) would be down to the ActorSystem to decide. That way the Actors only know that work is to be submitted to many other Actors at once and a multiprocTCPBase would simply duplicate messages while a multiprocUDPBase could have the option to multicast and a multiprocZMQBase could use it's own messaging paradigm (for example).

[kwquick]

I would like to learn more about the use case(s) for this functionality.

At present, each Actor has an associated Address which uniquely identifies that Actor, and therefore the message sent is processed only once. This is still true for the Troupe scenario: the Address used externally is for the Troupe Leader, which in turn chooses only one of the workers to send the message to. Additionally, some of the transport implementations in Thespian attempt to ensure delivery of the message to the target Actor (asynchronously, and unbeknownst to the Actor itself)

If I understand correctly, there is interest in creating a group of Actors and using a single send() to send a message to all of the Actors in the group. What are the expectations of behavior for this mode?

• Should each Actor be individually addressable as well as receiving "multicast" traffic?
• Message delivery would probably need to be best-effort for all transports. This is currently the way the UDP transport works, although the TCP transport attempts to ensure delivery to the target; the latter would probably need to devolve to a best effort case as well.
• At present, if a target actor encounters multiple exception failures when processing a message, that message is returned to the sender in a PoisonMessage wrapper. When used in this group scenario, there could potentially be a number of PoisonMessage returns for any single send.
• At present, if a child Actor exits, the parent receives a ChildActorExited message. The behavior for a group relates to the first item above: if Actors are individually addressable, then the exited messages can be unique, but if the group appears as a single entity to other Actors, including the parent, there could be multiple ChildActorExited deliveries for what would appear to be the same Actor.

It may be that this use case is better served by a "Router" Actor rather than embedding the functionality into Thespian itself. As j3hyde pointed out, the Router implementation could be similar to the Troupe model, replicating messages to all children rather than to just a single idle worker.

[pjz]

As I said in my original submission, the gain if having Thespian do it is having serialization overhead of O(1) instead of O(n). I don't think the group needs to be reified as a group, it'd just be nice to have an easy way to put the same message in all their inboxes. What that means copy-wise (n copies? Or one copy with n references?) Is probably up to the transport implementation. But even n copies is faster than n serializations.