[Spread-users] replicated state machine with spread

Dan Mihai Dumitriu dmd17 at cornell.edu
Wed Feb 27 11:18:49 EST 2008

Thanks for the quick reply!

That was basically my suspicion, since Flush Spread is actually plain
Virtual Synchrony, and closed group semantics are needed so that
senders can be blocked during view changes...  Actually we are using
the Java API, so is there any way for us to use Flush Spread at all?

More generally, how would one implement a replicated state machine
using basic Spread...?  I was thinking that new members could buffer
all incoming messages until such time as they get a state transfer
(which would need to include the id (lamport time) of the last message
applied to the state) from the leader, install that state, and then
apply all buffered messages, which have not already been applied to
the state.  Senders, including the leader, would need to send messages
using the AGREED semantics.  Hmm, I wonder if that would work...


On Wed, Feb 27, 2008 at 10:48 AM, John Lane Schultz
<jschultz at spreadconcepts.com> wrote:
> In basic spread (SP_* interface) there is no way to guarantee
>  what is the first message that a new member will deliver.
>  However, you can implement this behavior if you use the flush interface (FL_*
>  interface).  The problem with this approach though is that the flush
>  interface only supports closed group semantics, which means your
>  senders would also have to join the group in question.
>  If that is possible, then after a flush request, flush ok and the subsequent
>  membership is delivered have your leader send the synchronization message(s) and have
>  all other senders wait until they get said message(s).  All of this
>  will get a tricky though if there are cascading group changes around the
>  time of the join.
>  Cheers!
>  John
>  ---
>  John Lane Schultz
>  Spread Concepts LLC
>  Phn: 443 838 2200
>  Fax: 301 560 8875
>  Wednesday, February 27, 2008, 10:23:13 AM, you wrote:
>  > Hi all,
>  > I am implementing a replicated state machine using Spread (Java API)
>  > and I would like to know how I can do a proper state transfer when a
>  > new replica joins the group.  (New replica joins, it has no state, it
>  > must get a copy of the current state from an existing member, and
>  > then all replicas must process all input messages in the same order.)
>  > Is it possible to guarantee that a certain message (from the group
>  > leader) is delivered first after a view change, before any other
>  > messages?  In my system, I have several senders (which are in fact
>  > not part of the spread group) and two receivers, which implement the
>  > RSM.
>  > Cheers,
>  > Dan
>  > _______________________________________________
>  > 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

More information about the Spread-users mailing list