Fwd: [Spread-users] multigroup_multicast

[Yair Amir]

Hi,

This is a rare occasion where I can improve Ryan's answer a bit.

In my opinion, group membership messages are originated locally
by each daemon. Single join/leave messages are agreed ordered so
they should be usually ordered as soon as they are received and should
appear at the same time (almost) an all daemons in a segment regardless
of their position in the segment.

Multi-segment configurations should usually get the messages based on
the latency from the joining process' daemon to their segments with slight
increased latency based on the order of the segments.

For memberships that are caused by network, there will be slight preference
for installations of them based on the order, but we are talking about
sub-milliseconds in the same segments.

Another note is that in general for agreed ordering (or lower), Spread does not wait
for other daemons, so there is no need for the daemon to determine that all
other daemons have met required guarantees. Waiting for required
guarantees is correct for Safe ordering.

     Cheers,

   :) Yair.

Ryan Caudy wrote:
> Sorry, forgot to reply to all.
> ---------- Forwarded message ----------
> From: Ryan Caudy <rcaudy at gmail.com>
> Date: Jan 6, 2006 7:19 PM
> Subject: Re: [Spread-users] multigroup_multicast
> To: prubel at bbn.com
> 
> 
> In answer to the question concerning multigroup multicast, delivery
> guarantees (ordering, safety) are across the entire spread network.
> That is, the causally-consistent total ordering that is imposed by
> AGREED messages is is global, not at a per-group level.  Delivery to
> individual members is done by the daemon to which they are connected
> when that daemon determines that all other daemons have met the
> required guarantee.  The advantage of this is that causal ordering is
> guaranteed across groups (e.g. if member A sends a message to group 1
> = {A,B,C} and member B sends a message in response to group 2 =
> {B,C,D}, member C would get the two messages in the correct order).
> 
> With respect to the membership message question, configuration change
> messages are originated at the configuration leader (ranked by
> ordering in the configuration file), and delivered by conf order to
> the rest of the ring.  Hence, although no temporal delivery guarantee
> is made, it is likely that members connected to daemons earlier in the
> conf file will receive membership messages earlier, assuming that very
> few are connected to each daemon and that they are all processing
> their messages quickly.
> 
> Cheers,
> Ryan
> 
> On 1/6/06, Paul Rubel <prubel at bbn.com> wrote:
> 
>>Hello,
>>
>> I've been moving along with Spread. Before the new year I had some
>>questions about tweaking the timeouts to achieve sub-second detection
>>of failures. Lowering the parameters by a factor of 100 across the
>>board seems to have done the trick. I'm able to detect failure in ~.2
>>seconds using 12 daemons in 3 LANS.
>>
>>Moving forward I'd like to use the multigroup_multicast calls. We were
>>looking for something like that and lo and behold it was already there,
>>thanks! I'm curious about the semantics when a message is sent to
>>multiple groups. Are the messages delivered as if all the members of
>>the groups were in one large group? In the multigroup case does the
>>notion of the individual groups mean anything? For example, could a
>>message be delivered to the members of one group while still trying to
>>reach agreement for members of another or does Spread wait until all
>>the members are in agreement as it would with a multicast to a single
>>group?
>>
>>On a related topic, when we have been measuring the detection time for
>>failures it seems like the first members of a segment, as listed in
>>the spread.conf, get the message before members further down in the
>>segment list. We're guessing this is caused by the first daemon listed
>>in each segment receiving the message/token first and then passing it
>>to the others, who receive (and therefore process) it later. Is the
>>correct that the ordering of daemons in the file affects the order in
>>which daemons get messages?
>>
>>
>>       thank you,
>>        Paul
>>
>>_______________________________________________
>>Spread-users mailing list
>>Spread-users at lists.spread.org
>>http://lists.spread.org/mailman/listinfo/spread-users
>>
> 
> 
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
> 
>