Re: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo

[Arvola Chan <arvola@tibco.com>]

David:

I have a couple of questions / comments on your proposal:

1. Is it possible for an intermediary to receive a message with retry count
    n+1 when its retries for the same message with retry count n have not
    yet been exhausted? In other words, after an intermediary has forwarded
    a message with retry count n+1, should it refrain from retrying the same
    message with retry count n because it has not yet received the Ack for
    retry count n?

2. The From Party should stop retrying as soon as it receives any DR for
    a given message. It does not have to wait for a DR with a matching
    retry count.

3. In your example, Ack/ID 1.1 and DR/ID 1.1 can be packaged into the
    same ebXML message. Presumably the Ack element should be
    included in the Via element so that it is not passed on to other MSHs.

4. Should the From Party be aware of the existence of intermediaries?
    Should it refrain from asking for DeliveryReceipt when there are no
    intermediaries? In that case, retransmission on Ack timeout is
    sufficient.

Cheers,
-Arvola

-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Date: Wednesday, September 19, 2001 5:16 PM
Subject: FW: T2, Proposed solution for ... Re: SyncReply and
ReliableMessagingMethod in QualityOfServiceInfo


As Chris pointed out, we need to carefully consider this.  So, I am sending
this
out again (slightly modified -- retryCount goes in Via).  Does anyone see
any
problems with this or does anyone have an alternative proposal?

Regards,

David Fischer
Drummond Group.
===============
Proposal:
A retryCount attribute on Via.  This parameter can only be set by the From
Party
MSH and MUST start at zero.  The first retry, retryCount is set to one, etc.

Discussion:
Duplicate detection, as always, is detected by the To Party and From Party
based
upon MessageId.  Duplicate detection by the Intermediary is based upon
MessageId
plus retryCount.

For example (see attached flow chart):

Let's say there are three intermediaries (nodes B, C, D).  A is the From and
E
is the To.  A sends a message with MessageId of 1 and retryCount of 0 (let's
call this ID 1.0).  We will assume two failures occur during send -- the
message
makes it to D but has problems sending to E.  The Ack from C also fails
going
back to B.  Since A did not get a DR within retryInterval, it decides* to
retry
using ID 1.1.  B will not see this as a duplicate and will pass it on.  B
will
also retry to C using ID 1.0.  C will see ID 1.0 as a duplicate so it will
not
send on but C will send an Ack back to B (who gets it).  C will also receive
ID
1.1 and send it on since it is not a duplicate.  Meanwhile D has finally
made
the send to E and the DR and Ack have come back from E.  D then receives ID
1.1
from C and sends it on since it is not a duplicate.  E receives ID 1.1 but
since
E is the end, it sees ID 1.0 and ID 1.1 as duplicates (it only uses
MessageId).
E sends an Ack to D for ID 1.1.  E sees ID 1.1 as a duplicate so it does not
pass on to its application but it does send another DR back to A.  A finally
receives two DRs, one for ID 1.0 and another for ID 1.1.

*The retry on lack of DR may be either manual or automatic -- implementation
dependant.