RE: Implementation question for RM spec!

["Patil, Sanjay" <Spatil@netfish.com>]

Jim,

Could you please also comment on the third question in my original mail.
It's about parallelism between any given sender-receiver pair.
Is this restriction of working on one message at a time between
any given sender-receiver pair a result of some TRP 
decision to get rid of the windowing. I vaguely remember 
your initial RM spec talking about windowing.

Please advise.

thanks,
Sanjay Patil
----------------------------------------------------------------------------
------------------------------
Work Phone: 408 350 9619
http://www.netfish.com


-----Original Message-----
From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
Sent: Friday, September 29, 2000 6:37 PM
To: ebxml-transport@lists.ebxml.org
Subject: Re: Implementation question for RM spec!


Marty's exactly right on the complexity issues.

The current TRP resolution for RM requires each sending MSH to generate 
sequence numbers for each sender-receiver pair (regardless of transport). 
Whether a receiving MSH actually uses the sequence number or the globally 
unique MessageID to detect duplications is implementation dependent. It's a 
lot easier to detect dups using sequence numbers...

Jim

At 06:10 PM 9/27/2000 -0400, Martin W Sachs/Watson/IBM wrote:

>I believe that you correctly understand the intent of the RM protocol and
>its implementation requirements.  There indeed has to be a separate
>"logical channel" for each pair of channels, if not for each conversation,
>using reliable messaging, precisely to avoid the  blocking you mention.
>That's what it takes to get the parallelism you mention.
>
>I believe that the implementation would be simplified and perform better if
>the sequence numbers were eliminated as someone (yourself?) has already
>suggested.  I assume that sequence numbers have been discussed at this
>week's TRP face to face.
>
>Except for the sequence number question, I believe that exactly the same
>implementation considerations would be present if reliable messaging were
>done in the transport layer instead of the message service.
>
>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
>***************************************************************************
**********
>
>
>
>"Patil, Sanjay" <Spatil@netfish.com> on 09/27/2000 02:45:15 PM
>
>To:   "Ebxml-Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
>cc:   "Ebxml-Poc (E-mail)" <ebxml-poc@lists.ebxml.org>, "Askary, Sid"
>       <saskary@netfish.com>
>Subject:  Implementation question for RM spec!
>
>
>
>
>
>I was going through the Reliable Messaging spec for scoping the work
>involved in implementing the spec for the upcoming Tokyo POC.
>Questions about the same ...particularly in the context of the following
>requirement posed by the RM spec ...
>      A sender MSH should not send the next message till it receives
>      an Acknowledgement Message from the Receiver.
>
>   1>This will necessitate instantiating a separate MSH instance for each
>recipient
>      party, as it will not be fair for blocking outgoing messages to
>Parties
>having
>      a clear messaging channel while Messages to Parties with poor links
>are
>
>      successfully sent (tried to send).
>
>   2>This will also mean that separate outbound message queues are to be
>      maintained for each recipient. For each recipient Party, I will have
>to
>manage
>      the lifecycle of a dedicated SequenceCounter i.e.recycling the
>SequenceCounter
>      upon tripping over the max as well as when they get stale after "long
>time".
>      In hub scenarios, this will amount to a lot of runtime objects
>creation
>and
>      will also require an ongoing activity in the server to manage the
>queues and
>      lifecycles of the SequenceCounter objects.
>
>   3>With lots of outbound messages for the same recipient Party, there
>      should be some provision for parallelism. Typically when servers can
>handle multiples
>      of parallel message exchanges, the RM spec will necessitate using a
>single
>      pipeline resulting into underutilization of capacity and slowing down
>of the entire
>      process. Critical messages requiring immediate transfer might get
>stuck
>in the
>      queue for unreasonable amount of time.
>
>Or am I missing something very fundamental. It's been a while I have done
>ebXML,
>and with the Tokyo POC not very far, I got to catch up :-).
>
>thanks,
>Sanjay Patil
>---------------------------------------------------------------------------
-
>
>------------------------------
>Work Phone: 408 350 9619
>http://www.netfish.com