I’ve wondered about doing this in the past, but for the workloads I’ve worked with, I/O time has been relatively low compared to processing time. I’d guess there’s some combination of message frequency, cluster size and message size that makes it compelling.
The idea is interesting, though, because it could enable things like distributed JavaSpaces, where we’d be distributing the search queries, etc. I would guess the mechanism would look like: -Member nodes want to form a multicast group. -They elect a leader -Leader figures out a balanced notification tree, and passes it on to each member -Leader receives multicast message and starts the message passing into the tree -Recipients pass the message to local recipients, and also to their designated repeater recipients (how many?) -Somehow we monitor for disappearing members and then recast the leader election if necessary. Paxon protocol would be involved, I’d guess. Does anyone have references to any academic work on presence monitoring and leader election, beyond Lamport’s original paper? I also wonder, is there a reason not to just use Multicast if it’s available (I realize that it isn’t always supported - Amazon EC2, for instance). Interesting question! Cheers, Greg Trasuk > On Jul 29, 2015, at 12:40 PM, Bryan Thompson <br...@systap.com> wrote: > > Hello, > > I am wondering if anyone has looked into creating tree based algorithms for > multi-cast of RMI messages for river. Assuming a local cluster, such > patterns generally have log(p) cost for a cluster with p nodes. > > For the curious, this is how many MPI messages are communicated under the > hood. > > Thanks, > Bryan
