[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo
<df>comments inline</df> Regards, David Fischer Drummond Group. -----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Wednesday, September 19, 2001 8:10 PM To: David Fischer; ebXML Msg Subject: Re: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo 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? <df>Good point. Will the IM recognize this? As far as the IM is concerned this is a different message since it's messageId is a concatenation. This would presumably only happen if RetryInterval from end-to-end was less than RetryInterval*Retries for the local hop-to-hop (sum for all hops). It should be: RetryInterval(end-to-end) > Sum(RetryInterval(IM) * Retries(IM)) If this happened, it would be due to a misconfiguration. However, we have decided not to specify when or how the Retries are triggered (manual or automatic) so if someone got impatient and manually triggered a Retry (implementation dependant) then this could happen. Even if it did happen, nothing would go wrong and nothing would break, there might just be some added overhead. Adding this kind of checking code doesn't fix anything but it might be good, added functionality if an IM wanted to do this. It would work but it would not be necessary. Let's discuss this some more. . . </df> 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. <df>The From Party does not use RetryCount at all. It will mark a message as *DR Received* based upon RefToMessageId and not look at RetryCount. We have agreed not to say anything about when or how the Retry decision would be made. DR is no longer a part of the RM discussion. The From Party can perform a Retry at any time it deems appropriate. A Retry decision *might* be determined by Retries & RetryInterval in the CPA but we have agreed not to make that distinction in the specification nor to specify whether this process should be automatic or manual. </df> 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. <df>Yes, I see your point; however, this has been discussed before and rejected since moving Acknowledgement into the Via would take it out of the signature. It does not really matter since Acknowledgement already has Actor=next so it should not be passed to the other MSHs anyway. IMs never pass on an Ack - see 8.6.4. </df> 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. <df>We could make that recommendation. By the same argument, we might forbid the use of Ack in Single-Hop since AckRequested is in Via and thus not used for single-hop. Whichever way we decide, this does not impact the use of RetryCount so it is really another subject. </df> 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. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC