[Spread-users] Question about behavior on network merge

[Ryan Caudy]

It is NOT possible that C will receive message m before it receives
the membership message that notifies it of the merge with the sender
of m.  In fact, if m is sent by the daemon prior to the merge, it's
not possible that C will ever receive the message.  The only
uncertainty is caused by the client-daemon nature of Spread's
architecture.

C's daemon won't accept messages from A or B's daemon until after the
daemon-level EVS protocol completes, and the new membership is
installed.  That membership is delivered to the clients in a
CAUSED_BY_NETWORK regular membership message message RMM with AGREED
delivery semantics.  So, if m was sent by the daemon prior to the
initiation of the membership protocol (which blocks reads from all
clients), it will be delivered to A and B prior to RMM.  Otherwise it
will be received by all 3 daemons after RMM.

Cheers,
Ryan

On 7/3/07, Uma Chingunde <umac at jhu.edu> wrote:
> Hi,
>
> I had a question about the way membership messages are delivered to spread
> groups after a network merge.
> This came up as a result of trying to think of a method for synchronizing
> state among group members after a network merge.
> For e.g.
> If there exists a group with 3 members {A, B, C}.
> A partition occurs with members now {A, B} and {C}
> A message m is sent in Agreed order in group {A,B}
> At some point a merge occurs with membership now being {A,B,C}
> The way I think it works, is that message m could either be delivered to all
> members before the group view change or after so could be delivered to
> either {A,B} or {A,B,C}. Is this correct?
> If so, is it possible that C will receive message m before it sees the
> membership change for the merge?
> Or will the membership change always be the first message it receives before
> receiving any other messages from the new members?
>
> I am essentially trying to ensure that new members to a group do not start
> seeing messages sent to that group before they are done synching with other
> members. But I do not want to use the Flush APIs since I will need the Open
> Group semantics.
>
> Thanks for your time.
>
> Regards,
> Uma
>
>
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
>
>