[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Small point on DF RE: Intermediary support in the 1.1 version of theMSG and CPP/A specs
David Fischer writes: "Forwarding to the first IM is easy. If the From Party is not sending directly to the To Party, then the From Party simply adds a Via with another CPAId (different from the end-to-end CPA). The MSH sees a Via and instead of sending to the To+PartyId the MSH looks up a url in the CPA specified by Via+CPAId. So far, so good. The IM gets the message -- now what. If the IM can send to the To+PartyId (one IM) then everything works, what if it can't (multiple IMs)? How does the IM know where to send the next hop? This needs some serious consideration. We also need to deal with Dale's issue of backing out Acks. If the IM receives the message and sends an Ack, this does not mean the message reached the To Party. If there is a failure (DFN) later in the path, then the Ack for each previous hop should be Backed Out. I see the following options: 1. Don't send the Ack until the Ack from the next hop is received. 2. Don't send IM Acks, end-to-end Acks only. 3. Send DFN to each hop and rescind the Ack at each hop. 4. Don't bother. 5. Don't do Multi-hop. Option 1 is the Cascading Ack we discussed earlier which has the potential for a Retry Flood downstream. Option 2 effectively eliminates IM RM. It actually seems to me that option 1 and 2 are almost the same. .." David, if Option 1 gets in the running, I suggest dealing with the cascading retry problem by stipulating that all retries stem from the original sender only. The IMs do not retry until prodded, in other words."
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC