[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
Date: Fri, 17 Aug 2001 09:01:51 -0700 From: Arvola Chan <arvola@tibco.com> I agree that if intermediate MSHs do not perform duplicate elimination, then achieving end-to-end reliable messaging is easy. I also agree that simpler is better. Do you see a real adavantage in retaining the use of intermediate Acks? With the two-layer approach, it's easy to do acks, duplicate elimination, etc. hop-to-hop if you want to, although it's entirely optional. Is there a real advantage? For each hop, the less reliable the hop, the more advantage. If a hop is less reliable (statistically) than some threshold, then the extra costs of doing acks and retransmits and duplicate elimination are more than offset by the savings of not having to do the whole end-to-end trip multiple times. I find it cumbersome for the sending MSH to deal with two sets of retry parameters, one for the next MSH, the other for the destination MSH. With the two-layer approach (and using reliability in the lower layer), each protocol implementation only deals with one set of retry parameters. (The MSH pretty much corresponds to what I called the HLPI in my previous mail.) Each end party runs both the HLPI and the LLPI, and each has its own retry parameters, but they don't know about each other. CPA's currently don't work with intermediaries. The retry and retryInterval parameters to intermediaries can only be configured through proprietary means. I guess I am in favor of doing away with intermediate Acks altogether, or at least until they can be specified through CPA's. So, you might ask me, is there both a high-layer CPA and a low-layer CPA? Certainly there's a high-layer CPA, which is basically the CPA we have now. I think it would be good if we could avoid the need for a low-layer CPA (mainly to reduce the administrative burden of creating and distributing low-layer CPA's all over the place). The IP protocol gets away without anything like a CPA, and so does TCP. The LLP does not need to be cognizant of a lot of the interesting stuff that the CPA deals with, and so I think that an LLP connection would need relatively few parameters, and they could be negotiated dynamically. I agree. Now I see the advantage of XMLDSIG which allows the exclusion of certain elements from the signature. That's a good thing about XMLDSIG, but with the two-layer approach I don't think it's needed. The HTPI constructs its HLP message, signs and/or encrypts the whole thing, and passes it into the LLP. The LLP sees it as an opaque octet array. All the stuff that you don't want signed is in the LLP headers, and all the stuff that you do want signed is in the HLP headers and payload. So you don't need to use the "sign some but not all" stuff, so everyting is simpler. -- Dan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC