[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue i005
Issue i005 was originally brought up at the F2F, not necessarily by me, but I was an active part of the discussion and therefore would like to continue that discussion on the list. I've included some background information to expound upon the description and I've followed with a concrete proposal that I hope the TC will consider as a starting point for resolving the issue. Cheers, Steve Background The asynchronous nature of acks, as well as line 336/337 of the spec indicate that 'The RM Destination MAY send a <SequenceAcknowledgement> header block at any point.' In certain cases, this could result in an Ack for a given message overtaking an Nack for the same message. The rationale given for the Nack is that the gap analysis can be performed on the RMD side resulting in performance enhancements (see lines 376-378). In the case that the Nack overtakes an Ack, the Nack could actually go against the spirit of the spec and result in performance degradation by triggering the retransmission of a message that has already been received by the RMD. It should be noted that receipt of this message by the RMD a second time is in no way an error, but simply an unnecessary inefficiency in the protocol for this edge case. Better implementations would have probably avoided this anyway. Several people during the discussion at the F2F mentioned that there may be some benefit in Nacking a message to trigger resending of a message that has already been received by the RMD. Whereas I can see that this may be true, it seems like this kind of functionality would need to happen at a layer above RM (i.e. it's out of scope for this spec). However, given that messages can be delivered multiple times anyway, it would not be the end of the world to retransmit a message that has already been delivered to the RMD. Therefore I would not want to preclude an implementation that wants to '(ab)use' this fact from being allowed to use the RM machinery already in place to achieve this. I also noticed while investigating this issue that there doesn't seem to be any explicit indication in the spec that a Nack message should trigger the resend of a message. I believe that this is implied, but since it's an optimization, it is also most likely not intended to be a requirement. Proposal: Add text to the spec to explicitly state what an RMS should do when it receives a Nack message and tighten the spec for the edge case described above in the following manner (wordsmithing can be done later, but you get the gist): In Section 3.2, after line 338 add something like this: 'If the RM Source should receive a <SequenceAcknowledgement>containing a Nack, the RM Source SHOULD retransmit the message corresponding to the Nack. After the notification of successful receipt of a given message by the RM Destination, the RM Source SHOULD NOT attempt to retransmit the message in the event that it receives a negative acknowledgement for it at a later point in time.' ------------------ Steve Winkler SAP AG
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]