[Spread-users] spread local message patch
Camp, TracyX E
tracyx.e.camp at intel.com
Wed Sep 20 14:17:16 EDT 2006
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
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.
Assuming all the group members are always local to one daemon, the
flag can be implemented to preserve Spread semantics across groups (not
whether the current patch preserves this - to do this, the daemon needs
for other messages that are on the way to be delivered prior to
message, depending on the desired service). It will, in this case has
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
be local at the time of initiating the message. This creates a problem
the daemon has to trust the application that all members will be local -
non-local members will see the semantics violated. It probably could be
as well, but for a relatively high complexity price.
Interesting issue non the less.
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
> My comment is based on preserving the semantics of group
> SELF_DISCARD doesn't change the semantics because all members of the
> see the message. In other words, SELF_DISCARD doesn't behave as
> were a group within a group.
> My comments aside, where performance or resource utilization is a
> I don't object to optimizing common operations at the expense of
> semantics. I just don't see the performance or resource utilization
> being resolved. In general, an extra group for each node is not a lot
> overhead, but it may be for your particular case. The change seems
> like a convenience. If it doesn't break anything (e.g., message
> behavior) it's a bonus feature, so what's not to like? But I think
> may have to respecify message ordering semantics in the documentation.
> haven't walked the code to see how your patch behaves, but in the
> it seems as though message ordering across the entire group will
> differently for some message service types because off-node spread
> don't know a message was sent. I'm sure John Schultz will know if
> a problem or not. I'm just a kibitzer :)
> Spread-users mailing list
> Spread-users at lists.spread.org
Spread-users mailing list
Spread-users at lists.spread.org
More information about the Spread-users