[Spread-users] replicated state machine with spread

José Orlando Pereira jop at lsd.di.uminho.pt
Thu Feb 28 05:17:56 EST 2008


On Wednesday, February 27, 2008, Dan Mihai Dumitriu wrote:
> >
> > 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?

On Wednesday 27 February 2008, John Lane Schultz wrote:
> Currently, there is no Java interface to the FL_* calls.  However, a JNI
> wrapper wouldn't be too hard to implement.

There is such JNI wrapper in jGCS (http://jgcs.sf.net). jGCS is a common 
Java interface for multiple GC implementations (think "JDBC for group 
communication"). Both SP_* and FL_* are supported with JNI.

On Wednesday, February 27, 2008, Dan Mihai Dumitriu wrote: 
> > 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

This is probably the best option, but...

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

... when performing full state transfer, there is no need for timestamps, 
just: (i) transfer the state immediatly after processing the view change 
event; and (ii) buffer and apply all messages from the view change event.
Note that view change events are always totally ordered regarding regular 
messages, even when not using AGREED.

-- 
Jose Orlando Pereira




More information about the Spread-users mailing list