OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: RM Group Definitions


What we discussed in San Jose and what appears in the current RM draft
specification includes multiplexing in the sense that a single RM group
includes messages from any and all applications (e.g. TPAId and
conversationId) that share a particular transport path.


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

Henry Lowe <hlowe@omg.org> on 08/30/2000 12:26:42 PM

To:   ebxml-transport@lists.ebxml.org
Subject:  Re: RM Group Definitions


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,
At 11:20 AM 08/30/2000 -0400, mwsachs@us.ibm.com wrote:
>Believe it or not, we may be in agreement.
>I want to very carefully distinguish between the group size and a series
>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
>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
>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
>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.

>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
>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
>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.)
>At 04:42 PM 8/28/2000 -0400, mwsachs@us.ibm.com wrote:
>>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
>>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
>>RM service, on its own, can only set the group size to 1, we might as
>>simplify the definition and have only a group size of 1.  That would be
>>worst case for the number of ACKs and the best case for message latency.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC