Re: RM Group Definitions

[Henry Lowe <hlowe@omg.org>]

Marty,

I would agree with your Group Size proposal.

However, unless I missed something, I don't think your 
second concern is a problem as it's based on multiplexing 
of the channel.  I don't think RM proposed multiplexing.

If I'm wrong and there is multiplexing, you are right and 
there is a BIG problem.  If this is a problem, the best 
way to deal with would be to eliminate the muxing (rather 
than try to reinvent all the mechanisms found in transport 
protocols to deal with it -- this is a hard problem).

Best regards,
Henry
--------------------------------
At 11:20 AM 08/30/2000 -0400, mwsachs@us.ibm.com wrote:
>Jim,
>
>Believe it or not, we may be in agreement.
>
>I want to very carefully distinguish between the group size and a series of
>reliable messages sent by the application layer.
>
>The group size is fixed for a given transport path and all reliable
>messages for all application processes (TPAs and conversations or
>equivalent) using that path flow through that group.  No one process knows
>anything about what it is sharing the transport path with, so no one
>process can make the correct decision about the group size for all
>processes sharing the path.  What is too large for one  may be too small
>for another.
>
>On the other hand, any application process has to be able to specify that a
>message, or a series of messages should be sent via reliable messaging.
>There is no reason why the number of messages in the series needs to have
>anything to do with the group size. See caveat below.
>
>My proposal, which I believe is in the comments to the reliable messaging
>spec, is that the application individually flag each message as reliable or
>not.  Alternatively, there can be "start reliable messaging" and "end
>reliable messaging" primitives on the BP-TRP service interface.
>
>Caveat:  There is a possibility that a group is not full while no process
>has any more reliable messages to send.  This would be a hang condition if
>we don't deal with it.  Using "start reliable messaging" and "end reliable
>messaging" primitives on the interface helps to solve this problem since if
>no process has reliable messaging in effect, the reliable messaging
>function could normally terminate the group even if it is not full.  I
>believe there are also other cases for having to normally terminate an
>incomplete group which I called out in the comments.  Note that having the
>application process specify the group size does not solve this problem
>because an application process can have various paths involving different
>numbers of messages and it may not know at the time it issues the first
>reliable message, which path it will follow.
>
>Caveat 2:  None of the above addresses my other concern, that a deadlock
>will occur if all processes are waiting for responses to reliable messages
>at a time when the group is not full.
>
>Regards,
>Marty
>
>****************************************************************************
>*********
>
>Martin W. Sachs
>IBM T. J. Watson Research Center
>P. O. B. 704
>Yorktown Hts, NY 10598
>914-784-7287;  IBM tie line 863-7287
>Notes address:  Martin W Sachs/Watson/IBM
>Internet address:  mwsachs @ us.ibm.com
>****************************************************************************
>*********
>
>
>
>Jim Hughes <jfh@fs.fujitsu.com> on 08/29/2000 04:37:31 AM
>
>To:   ebxml-transport@lists.ebxml.org
>cc:
>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
>
>
>
>