[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