[Spread-users] spread local message patch

[Camp, TracyX E]

I've been thinking about the suggestion that I could do the same thing
with two groups.  One for local members and one for global members
(local meaning the spread daemon instance and all clients that connect
with it, and global meaning all spread daemon instances and all
clients).

The first problem I'm having with this suggestion is that there is a
race condition between joining and leaving two groups that does not
exist in the case of just one group.  This _can_ be sorted out, but
requires additional barrier messages to be sent and additional protocol
stages in the case of a non-joined client sending messages to either of
the two groups (such as a message indicating that the group memberships
are not stable since fewer members than expected exist in either the
local or global group).  This strikes me as the sort of topology
problems that spread is supposed to generally solve for applications.

The second problem is probably more my ignorance than anything else.  I
thought I had constructed the patch such that the delivery and ordering
semantics would not differ from a message being sent to a private group,
except that in this case the sender does not need to know the private
group name(s) (such as a non-joined client sending to an open group).
The meat of the LOCAL_MESS flag is that in the down queue processing it
ucasts rather than mcasts if the flag is set.

t.


Assuming all the group members are always local to one daemon, the
LOCAL_MESS
flag can be implemented to preserve Spread semantics across groups (not
sure
whether the current patch preserves this - to do this, the daemon needs
to wait
for other messages that are on the way to be delivered prior to
delivering this
message, depending on the desired service). It will, in this case has
the
performance benefit of not sending messages on the net at all.

However, there is no way for the daemon to know that all group members
will
be local at the time of initiating the message. This creates a problem
in that
the daemon has to trust the application that all members will be local -
otherwise
non-local members will see the semantics violated. It probably could be
solved
as well, but for a relatively high complexity price.

Interesting issue non the less.

Cheers,

	:) Yair.

Daniel F. Savarese wrote:
> In message
<102A51607473A4449F0D3E2EF6FFCAD69B7018 at orsmsx416.amr.corp.intel.com
>> , "Camp, TracyX E" writes:
>> where 'found useful'.  Your argument could also be applied to the
>> existing SELF_DISCARD flag, the point is to avoid common duplication
of
> 
> My comment is based on preserving the semantics of group
communication.
> SELF_DISCARD doesn't change the semantics because all members of the
group
> see the message.  In other words, SELF_DISCARD doesn't behave as
though there
> were a group within a group.
> 
> My comments aside, where performance or resource utilization is a
concern,
> I don't object to optimizing common operations at the expense of
consistent
> semantics.  I just don't see the performance or resource utilization
issue
> being resolved.  In general, an extra group for each node is not a lot
of
> overhead, but it may be for your particular case.  The change seems
more
> like a convenience.  If it doesn't break anything (e.g., message
ordering
> behavior) it's a bonus feature, so what's not to like?  But I think
you
> may have to respecify message ordering semantics in the documentation.
I
> haven't walked the code to see how your patch behaves, but in the
abstract,
> it seems as though message ordering across the entire group will
behave
> differently for some message service types because off-node spread
daemons
> don't know a message was sent.  I'm sure John Schultz will know if
there's
> a problem or not.  I'm just a kibitzer :)
> 
> daniel
> 
> 
> _______________________________________________
> 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