OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: NEW ISSUE: rewording of Proposed-01 (twin sister of i019)


Rewording of Proposed-01:

 

 

Title: Accuracy of final acknowledgement reflecting termination state of a sequence.

 

Description: When a Source decides to stop using a sequence, there is no way the RMS can get

a sequence ack that it knows will accurately reflect the final state of the sequence, i.e. the state the sequence will have at actual termination time. No matter how long an RMS waits after its last sending and before requesting its last Ack, some past message that was previously sent and never acknowledged (for which RM Source had stop any resending effort) could be received late by RMD (e.g. after being stuck in a router), i.e. after the sending of the last SequenceAcknowledgement and before the sequence is actually terminated so that the RMD can reclaim resources. This is the twin sister of issue i019 which deals with a similar problem but in case of sequence fault (which gives no chance to RMS to get this final seq ack.)

 

Justification: An RMS (or SA) may decide to stop using a sequence even though some messages were not received (not acked). But in all cases, it is important that the RMS gets a final accurate account of which messages have been received and which have not for this sequence. The RMS may have to raise an error for those not received. Also if the SA decides to take remedial action for these (e.g. some resending on its own) it must be given some means to avoid treating messages that it did not know were already received in a previous sequence (e.g. avoid resending them later in a new sequence as they would become undetectable duplicates.)

 

Target: core

Type: design

 

Proposal: TBD. Outline of a solution:

(a) give an RMS a way to trigger a SeqAck that will be associated with the "closing" of the sequence i.e. no more message will be accepted by the RMD after this Ack is generated.

(b) give an RMS a way to reiterate this trigger in case it is lost, so that it can get this last SeqAck.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]