[Spread-users] replicated state machine with spread

[John Lane Schultz]

Currently, there is no Java interface to the FL_* calls.  However, a JNI
wrapper wouldn't be too hard to implement.

It sounds like you are on a good track with the method you propose.

Good luck! ;)

Cheers!
John

---
John Lane Schultz
Spread Concepts LLC
Phn: 443 838 2200 
Fax: 301 560 8875

Wednesday, February 27, 2008, 11:18:49 AM, you wrote:

> 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