[Spread-users] Current view number

[John Lane Schultz]

Pablo, 

One other thing: the extra semantics that the Flush Layer provides do not come for free.  

They require extra messaging and blocking at your clients.  For example, if a new client tries to join a group, then after a member of the existing view of that group authorizes the view to change, it will each be blocked from sending new messages until ALL of the members of the previous view authorize it (or fail).

So, if you can achieve what you want using Spread’s EVS semantics rather than the Flush Layer’s VS semantics, then I’d recommend using Spread rather than the Flush layer.  In general, you should only prefer the Flush layer over Spread if it’s sending-view semantics REALLY simplify your application.

Doing something like marking all messages with the view in which they are sent and then ignoring them if they are delivered in a different view is a very good example of how you might continue to use Spread rather than the Flush layer to achieve what you want.

Cheers!

-----
John Lane Schultz
Spread Concepts LLC
Cell: 443 838 2200

On Feb 27, 2014, at 2:38 PM, John Lane Schultz <jschultz at spreadconcepts.com> wrote:

> I know that message delivery occurs asynchronously for … But, what about … message delivery? I think that they will be synchornized with view change messages ?  

What I meant by "message delivery and view changes occur asynchronously” is that when a Spread / Extended Virtual Synchrony (EVS) client sends, it cannot know in which view their message will ultimately be delivered (and, therefore, to which clients it might be delivered).  View changes can happen and are ordered into the stream of delivered messages without any coordination with clients.

What I believe you are referring to is that with Spread an UNRELIABLE, RELIABLE, FIFO or CAUSAL message can be delivered in different views at different receivers while an AGREED or SAFE message can only be delivered in the same view at all receivers.

==================

>> then you may want to look into the flush layer of Spread that provides exactly such a service.
> I don't understand this statement. Can you explain me about it?

Some applications want a simpler Group Communication System model than what Spread provides and instead demand sending-view / Virtual Synchrony (VS) semantics.  With sending-view semantics, a client does know in which view its messages will be sent+delivered.  A client’s messages are sent and delivered in the view most recently delivered to it. Because of that, the sending client also knows that its messages can be delivered to at most the members of that view in that view.  View changes are explicitly coordinated with each client.  A view change at a client can only occur once the client affirmatively agrees to allow a view change.

Spread comes with an alternative API that we call the Flush Library that provides sending-view / VS semantics instead of Spread’s normal semantics.  The API for this service is contained in fl.h and is very similar looking to Spread’s API with some additional signaling between the client application and the library to affirmatively allow for view changes.  If you are interested, then the documentation can be found in your distribution in docs/flush/.

Cheers!

-----
John Lane Schultz
Spread Concepts LLC
Cell: 443 838 2200

On Feb 27, 2014, at 2:09 PM, Pablo Pessolani <ppessolani at hotmail.com> wrote:

Hi John:

I am working on a project with similarities to wackamole (a distributed resources allocation algorithm).

>> Or are you just marking messages so that they can be easily ignored if they are delivered in a different view than the one in which the client thought they were sent?
PAP: Yes, I am interesting to know the view version to discard messages outside the current view.


>> However, in EVS (Spread) semantics, message delivery and view changes occur asynchronously. That is, there is little ordering dependence between them. A message is not necessarily ordered and delivered in the view in which the client *thinks* it is sending. Several views might be installed between the time a client sends a message and it gets to delivered in EVS.

PAP:  I know that message delivery occurs asynchronously for 
• UNRELIABLE_MESS
• RELIABLE_MESS
• FIFO_MESS
• CAUSAL_MESS
But, what about.
• AGREED_MESS
• SAFE_MESS
message delivery? I think that they will be synchornized with view change messages ?  

>>> then you may want to look into the flush layer of Spread that provides exactly such a service.
PAP: I don't understand this statement. Can you explain me about it?

Thanks John.
PAP

_______________________________________________
Spread-users mailing list
Spread-users at lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users