Re: RM Group Definitions

[mwsachs@us.ibm.com]

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