[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: RM Group Definitions
OK, if the upper layer is not supposed to establish the end of a sequence of reliable messages, then we need to decide how the MSH will do this. Do you have a particular algorithm to propose? (My personal favorite solution *is* to let the upper layer have an opportunity to tell the MSH that a sequence of messages should be sent in a reliable mode. To do this, we need to agree on the Message Service Interface that would permit this... But if the group decides that, architecturally, we cannot have this link, then we need a resolution for solving this in the MSH.) Jim At 04:42 PM 8/28/2000 -0400, mwsachs@us.ibm.com wrote: >Jim, > >Correct - the upper layer BP should not establish the group size. Each >process in the BP layer has a view only to itself. With the BP processes >requesting group size, the RM service would have to somehow resolve >conflicts. Using the largest requested group is one approach - but that >would be larger than most processes want and therefore impair their >latencies. Note also that once the RM service is into resolving conflicts >on group size, no BP process knows what the actual group size is anyway. > >The trivial case which you mention is probably not the best answer. If the >RM service, on its own, can only set the group size to 1, we might as well >simplify the definition and have only a group size of 1. That would be the >worst case for the number of ACKs and the best case for message latency. > >Regards, >Marty
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC