[Spread-users] Questions about CAUSED_BY_NETWORK

Mon Mar 11 14:31:24 EDT 2013

> Is this summary correct?

Yes, I think you've got it!

> Is my assumption right that a "self join" and a "self leave" (i.e. the member owning the connection represented by the "mbox" parameter of SP_receive is joining/leaving a group) is never communicated in a CAUSED_BY_NETWORK message but rather as CAUSED_BY_JOIN, CAUSED_BY_LEAVE or CAUSED_BY_DISCONNECT?

Good question.  Typically, that is how it would work, but I believe there is an edge case where a client's (self) join message is ordered right around the time a network partition is occurring (i.e. - the join message is ordered after a transitional signal -- right on the tail end of a membership that is in the process of partitioning) that then the join message can be translated into a CAUSED_BY_NETWORK membership message to maintain the useful meaning of the VS sets across the entire daemon membership change.

Also, I don't believe a client will ever get a self-leave that is CAUSED_BY_DISCONNECT.  I believe that self-leaves should always appear as special CAUSED_BY_LEAVE membership messages, per the documentation.

> And finally: I guess that the maximum length of a membership message body CAUSED_BY_NETWORK (parameter "mess" of SP_receive) is primarily a function of the number of connections in the whole configuation.  Do you have any estimation of this function for me, so that I don't risk partial membership messages given a known maximum number of connections?

The easiest thing to do is always call SP_receive with a maximally sized groups and body, which for out-of-the-box Spread is less than 150KB (MAX_MESSAGE_BODY_LEN in sess_types.h -- this constant isn't exported as part of the user API because it covers all headers, groups and actual message bodies too, which makes it a bit confusing).  If you don't like having such big buffers (with potentially a lot of memory waste per message) or having to copy the actual message out into a more appropriately sized buffers, then there's another more complicated way.  If you call SP_receive with too small buffers then it will return a GROUPS_TOO_SHORT or BUFFER_TOO_SHORT error and the filled out fields will tell you how big the message you tried to receive actually is.  Then you can re-call SP_receive with appropriately sized buffers and get the message.  All of that is documented in http://www.spread.org/docs/spread_docs_4/docs/sp_receive.html  So, you can always call with zero length buffers and then appropriately allocate, or you can have a first guess that will usually be big enough without too much waste and then allocate only if necessary.  Spread will not give you partial messages nor discard such messages unless you explicitly pass the DROP_RECV flag as part of the service type.

More to your specific question, the thing that takes up the most space in membership messages are the membership list and the VS sets.  The union of all the VS sets must be a subset of the membership list -- indeed, I think that it actually equals the membership list.  The membership list is proportional to the product of the number of members in the group and the size of group names (MAX_GROUP_NAME).  Given all that, I think a conservative estimate of a maximally sized group would be something like (150 KB - 10 KB) / (2 * MAX_GROUP_NAME) ~= 2000 members.  If you called SP_receive with a groups array of your maximum number of clients (max_clients) and a message body >= max_clients * (12 + 2 + MAX_GROUP_NAME), then I think that should suffice.

I hope that helps!

Cheers!

-----
John Lane Schultz
Spread Concepts LLC
Phn: 301 830 8100
Cell: 443 838 2200

On Mar 11, 2013, at 1:16 PM, andreas.ames at de.transport.bombardier.com wrote:

Hi John,

thanks a lot for your explanations which make things much more 
understandable to me.

Nevertheless I have some further questions below.

John Schultz <jschultz at spreadconcepts.com> schrieb am 11.03.2013 16:14:45:

> For a given client, the membership list of their *previous* 
> membership, the new membership list and their new VS set allows a 
> client to calculate exactly what kind of change they just saw. 
> Anyone who was in the previous membership list but is not in their 
> new VS set (even if they are in the new membership list) partitioned
> away and may not have seen the same messages in the previous 
> membership of this client.  Anyone who is in the new membership list
> but not in the VS set is a "new" member that merged in.  Thus, a 
> member that is both in this client's previous membership list and in
> the new membership list but isn't in this client's VS set was both 
> removed and added.  Again, that peculiar case means that member 
> partitioned away from this client and, therefore, might not have 
> seen the same messages in this client's previous membership, 
> installed an intervening membership and may have delivered messages 
> in that intervening membership too.  Thus, additional reconciliation
> likely must be done with such a member, much like any other "new" 
> member that merged in from "out of the blue."
> 
> A client can access its VS set by calling the SP_get_memb_info() on 
> its membership message, which fills out a memb_info structure.  You 
> can then pass that structure's my_vs_set field into 
> SP_get_vs_set_members() to get that client's VS set.  Additionally, 
> a client can actually see all the different VS sets that merged 
> together by using SP_get_vs_sets_info() and then iterating over the 
> returned array of vs_set_info's and calling SP_get_vs_set_members() 
> on each one.  Documentation for these functions can be found here: 
> http://www.spread.org/docs/spread_docs_4/docs/c_api.html

When I call SP_receive and get a membership message that is 
CAUSED_BY_NETWORK:

* the "new membership list" is returned in the "groups" parameter of 
SP_receive

* the VS set that is to be used for the algorithm you described above is 
the VS set at index "my_vs_set"

* the "previous membership list" is not part of the received message but 
has to be maintained by the application itsself

Is this summary correct?

Is my assumption right that a "self join" and a "self leave" (i.e. the 
member owning the connection represented by the "mbox" parameter of 
SP_receive is joining/leaving a group) is never communicated in a 
CAUSED_BY_NETWORK message but rather as CAUSED_BY_JOIN, CAUSED_BY_LEAVE or 
CAUSED_BY_DISCONNECT?

And finally: I guess that the maximum length of a membership message body 
CAUSED_BY_NETWORK (parameter "mess" of SP_receive) is primarily a function 
of the number of connections in the whole configuation.  Do you have any 
estimation of this function for me, so that I don't risk partial 
membership messages given a known maximum number of connections?

Thanks again,

aa

-- 

Please consider the environment before you print / Merci de penser à 
l'environnement avant d'imprimer / Bitte denken Sie an die Umwelt bevor 
Sie drucken 

Bombardier Transportation GmbH 
Vorsitzender des Aufsichtsrats / Chairman of Supervisory Board: Prof. Dr. 
Wilhelm Bender 
Geschäftsführung / Executive Board: Michael Clausecker 
(Vorsitzender/Chairman), Dr. Susanne Kortendick, Luc Charlemagne, 
Gregorius Peters 
Sitz der Gesellschaft / Principal Office: Berlin 
Registergericht / Registration Court: Amtsgericht Charlottenburg, HRB 
64838 

_______________________________________________________________________________________________________________ 

This e-mail communication (and any attachment/s) may contain confidential 
or privileged information and is intended only for the individual(s) or 
entity named above and to others who have been specifically authorized to 
receive it. If you are not the intended recipient, please do not read, 
copy, use or disclose the contents of this communication to others. Please 
notify the sender that you have received this e-mail in error by reply 
e-mail, and delete the e-mail subsequently. Please note that in order to 
protect the security of our information systems an AntiSPAM solution is in 
use and will browse through incoming emails. 
Thank you. 
_________________________________________________________________________________________________________________ 

Ce message (ainsi que le(s) fichier(s)), transmis par courriel, peut 
contenir des renseignements confidentiels ou protégés et est destiné à 
l?usage exclusif du destinataire ci-dessus. Toute autre personne est, par 
les présentes, avisée qu?il est strictement interdit de le diffuser, le 
distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, 
veuillez nous en aviser et détruire ce message. Veuillez prendre note 
qu'une solution antipollupostage (AntiSPAM) est utilisée afin d'assurer la 
sécurité de nos systèmes d'information et qu'elle furètera les courriels 
entrants.
Merci. 
_________________________________________________________________________________________________________________ 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3805 bytes
Desc: not available
Url : http://lists.spread.org/pipermail/spread-users/attachments/20130311/46038ff5/attachment.bin 