[Spread-users] replicated state machine with spread

Rick Cobb rcobb at KnowNow.com
Wed Feb 27 16:22:29 EST 2008


We do it that way, and it's worked pretty well for us. 

-- ReC

-----Original Message-----
From: spread-users-bounces at lists.spread.org
[mailto:spread-users-bounces at lists.spread.org] On Behalf Of Dan Mihai
Dumitriu
Sent: Wednesday, February 27, 2008 8:19 AM
To: spread-users at lists.spread.org
Subject: Re: [Spread-users] replicated state machine with spread

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...

Cheers,
Dan


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
>

_______________________________________________
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