[Spread-users] spread local message patch

[Yair Amir]

Hi Daniel, Tracy,

In terms of scalability with the number of groups, Spread is quite good
and adding these groups should not make a difference in terms of performance.

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
> 
>