[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] i130 - what does ack interval refer to
Taking it down a level, we have two proposed wordings: 1. This element, if present, specifies the maximum duration, after receipt of a reliably sent message, which the RM Destination will wait before transmitting an acknowledgement. If omitted, there is no implied value. 2. This element, if present, specifies the maximum duration between acknowledgements for this Sequence. The RM Destination will transmit an acknowledgement at intervals at most this far apart. If omitted, there is no implied value. Another question for the group: In either case, are we introducing the word "transmit" in a way which prevents use with Make Connection? This isn't quite like "generating" a fault (versus sending it) but might need similar handling in the specification. I favour option 2 above because it supports a use case Doug is concerned about (the RMS deciding to retry based on not receiving an expected acknowledgement), provides more information than option 1 for that scenario, and also provides that heartbeat Doug mentioned below. Not sure a heartbeat is always or often required (might be a SLA concern) but it comes somewhat for free in this case. Of course in option 2, a particular sent acknowledgement could duplicate earlier acknowledgements, and the RMS may actually not have tried to deliver anything in that interval. This "waste" seems minor when compared with the RMS making decisions based on provided information instead of the absence of information. The absent information is the acknowledgement clearly listing all of what the RMD received. The RMD and RMS may have different perspectives on "dead air" (outbound messages may have been lost). Option helps to distinguish lost messages from other conditions. thanx, doug PS. Doug and I argued me out of any suggestions related to minimum intervals. The main use case for such a value would be dynamically scaling the RMS Acks To end point in preparation for an expected flood of acknowledgements or some similar message flood planning. If such a dynamic enterprise were in place, the scaling could happen as incoming messages *actually* increase in number but still well in advance of overloading the RMS. On 21/06/06 18:32, Doug Davis wrote: > > All, > Doug Bunting and I have been discussing issue 130 ("what does ack > interval refer to") > and we've hit a bit of a roadblock. There are two (perhaps more) ways > of interpretting > what the AckInterval (AI) value is meant to be used for, or what its > intended meaning is supposed > to be. The two, most likely, options are: > 1 - the maximum time the RMD will wait, after receipt of a message, > before an Ack will be sent > 2 - the maximum time the RMD will wait before between sending Acks > > Option 1 means that the RMD will wait no longer than the AI value > before it sends an Ack. The > RMS can be assured that if it doesn't get an Ack from the RMD after > that time then the Ack > was lost. Note: a new msg into the RMD initiates the timer and the > sending of an Ack stops it. > > Option 2 means that the RMD will send out an acknowledgement, at > least, every AI milliseconds. > Sort of like a heartbeat. The RMS can be assured that it will not > need to wait any longer than the > AI before an Ack will be resent. Note: the sending of an Ack will > reset the timer and it will only stop > upon termination of the sequence. > > Note: in both options the RMD is always free to send more acks and the > RMS is always free to > send an AckReq - but we're not worried about those situations. > > The current wording is a bit ambiguous.So, the question for the TC > is....which option do we > want to present in the spec? Thoughts? > > thanks, > -DougD
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]