[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: a draft for discussed Time and Group issues
Two things in this mail, separate but not unrelated, for review:
(1) a state diagram for messages (.GIF) on the receiver side, plus comments (State-diagram-comments.txt)
I thought this was a more illustrative and abstract way to express the algorithm-like description we made during the f-2-f,
which also makes it possible to pin a precise terminology to states and transitions, that we can reuse in the spec.
Let me know if you think so.
(2) A proposal for final wording of time-related issues we discussed last week.
- Last Thursday, we ended up with a slightly different semantics for ExpiryTime (max time at which the message should be
"received" by RMP, not anymore delivered to the application.) This needed a few adjustments.
- a complete proposal for when to decide to discard an out-of-order sequence (previous proposal for Rel 57 revisited).
We started on this, but did not finish.
- a refined proposal and wording for group termination (t1, t2, t3, t4) which did not address the Sender
side before. Also, it appeared to me that we need to distinguish between "group termination", and removal of a group state
that allows for duplicate elimination.
<<RM-states-receiver.gif>> <<State-diagram-comments.txt>> <<Time-and-Group-related-issues.txt>>
States of the message on Receiver Side: --------------------------------------- [in-transfer]: still in transport, or in a queue out of reach of the RMP. [in-transfer]--- receive --->[ready]: make the message available to the RMP. (e.g. decrypted, authorized). [ready]: the message is under control of the RMP, i.e. in a state where RM processing can start. [ready]--- accept --->[in-process]: verify that the message has schema-valid RM extensions, is not expired, and is not a duplicate. If this is the case, a positive ack is generated at this time, or is made available to future poll requests (if poll replyPattern). [in-process]: The accepted message is processed further for reliability requirements. [ready]--- reject --->[discarded]: either the message has bad RM extensions, or has expired, or is a duplicate. An RM Fault is generated at this time, or is made available to future poll requests (if poll replyPattern). [discarded]: the message has been eliminated, because it failed reliability requirements, e.g. invalid, expired, duplicate, out-of-order, or removed for resource shortage reasons. [in-process]--- hold --->[Out-of-order]: the message belongs to an ordered sequence which misses previous messages. [Out-of-order]--- reprocess --->[in-process]: The message is reconsidered for either delivery or discarding, due to its sequence being completed, or terminated. [Out-of-order]: the message is persisted by the RMP, waiting for missing messages in the same sequence. [in-process]--- discard --->[discarded]: although initially accepted, the message is failing other reliability requirements, e.g. is hopelessly out-of-order. [in-process]--- deliver --->[available]: the message is made available in some way (callback, queue, released from handler...) to the receiver application. [available]: The RMP processing for this messages is over. The message is now available to the application. At that point, the message is no longer under RMP responsibility, and considered delivered.
ExpiryTime: ---------- ExpiryTime indicates the ultimate date after which the receiver RMP will NOT accept a message (see meaning of "accept" in state diagram). - An RMP receiving a message after its ExpiryTime date, MUST NOT accept the message. - Once a message is accepted by the RMP, the fact that the message expires while being processed by the RMP MUST NOT affect its processing, nor its final availability status to the receiver application. NOTE about the use of ExpiryTime for Duplicate Elimination: Although ExpiryTime will not affect the processing of accepted messages, it is useful for an RMP to remember it in order to later reduce the number of duplicate checks, when "at most once" delivery is required. Given the above definition of ExpiryTime, it should not be necessary to compare the ID of a newly received message with the ID of past expired messages. An refinement to this rule is when a message has been received before its ExpiryTime, but is expiring before its duplicate check is performed. In this case an RMP MUST also extend the duplicate check of this message, with the ID of some past messages that are also expired, but were not yet expired at the time the newly received message had been moved to "ready" state. Acknowledgement semantics: -------------------------- A positive acknowledgement is generated when a message has been accepted by the receiver RMP. This means that (1) the RM extensions of the message header were valid, (2) the message has not expired, (3) the message was not a duplicate (transition "accept" to the state "in-process"). The acknowledgement means to the Sender RMP that its role in the reliability contract for this message is over, and that the Receiver RMP has now full responsibility to satisfy the reliability agreement. Note that this does not guarantee that the message will eventually be delivered to the receiver application. If any of the three conditions above was not satisfied, an RM Fault will be generated instead. Synchronization Sender-Receiver: -------------------------------- A Sender and a Receiver are synchronized, when they have both the same awareness of the outcome of a message transaction, i.e. whether or not the message was delivered or made available to the receiver application. A Sender and a Receiver are "failure-synchronized", if they have both the same awareness of a failed message transaction. This specification does not support full synchronization of a Sender and a Receiver, but provides a reasonable guarantee of failure-synchronization. Two RMPs implementing this specification may not be synchronized in the following case: A message may be sent, received, made available to the receiver application, but never acknowledged properly even after resending it. In which case, the Sender will conclude that the delivery failed, while the Receiver knows that the delivery was successful. Two RMPs implementing this specification will always be failure-synchronized: If a Receiver fails to deliver a message (invalid, expired, duplicate, out-of-order) sufficient notification will be generated to the Sender so that the Sender can infer that the delivery failed. NOTE: a message may be positively acknowledged, and yet never delivered to the receiver application, if it has been held by the receiver RMP as out-of-order then discarded. In such a case however, a fault would be generated to notify the Sender of the delivery failure. It is the absence of such fault, not just the presence of a positive Acknowledgement, that allows a Sender to conclude that a message was delivered to the receiver application. Termination of a group vs. Removal of its state: ------------------------------------------------- Termination of a group, and removal of its state are two distinct events. - When a group terminates, both in sender and receiver, no message is expected to be sent or received for this group anymore. If a message is received after the termination of a group, with same GroupId as the terminated group, it is considered by the Receiver as belonging to a new group. (Note that such a message would never be delivered to the receiver application if guaranteed ordered delivery was required, but may be delivered if not.) - Removal of the state of a group, means that all trace of the message IDs (GroupId and SequenceNumber for all received messages) is removed, and therefore not available anymore for duplicate checks. However, duplicate checks are still necessary some time after a group terminates. Next sections establishes the rules for when these two events should occur. Discarding an "out-of-order" set of messages, and failure-termination of an ordered group. ------------------------------------------------------------------------------------------- In case a set of messages of the same sequence are held in "out-of-order" state, the RMP will need to decide how long these messages should be held before being either discarded, or delivered. These messages belong to a group or sequence for which ordered delivery, and therefore guaranteed delivery, were required. Given the definition of Guaranteed Ordered Delivery, a message must not be delivered to the receiver application if not all previous messages were. Therefore in case a Receiver RMP decides to not wait any longer for a missing message, the already received out-of-order messages MUST be discarded and not delivered to the application. An RM Fault will be made available to the Sender. Discarding an out-of-order group occurs in the following cases (d1, d2, d3). Note that the ExpiryTime of out-of-order messages will not intervene in their discarding, as ExpiryTime only has meaning for initial acceptance or rejection of a message. Case d1: the group had GroupExpiryTime specified in its messages. On the Receiver side, the out-of-order messages MUST be discarded as soon as this date expires, and the group MUST be terminated. Indeed, any missing message received after this date, will not be accepted by the RMP (as GroupExpiryTime is always greater than ExpiryTime of any message in the group), and the group will never be complete. On the Sender side, an RM Fault will warn of the failed sequence. In case the Sender must take the initiative to poll for such a fault, it will do so when: (1) GroupExpiryTime is over, and (2) some Acks are still missing. Once the Fault has been obtained, the Sender MUST NOT send further messages for this group, and MUST communicate instead a delivery failure to its application. Case d2: the group did not have GroupExpiryTime specified, but had GroupMaxIdleTime. On the Receiver side, the out-of-order messages MUST be discarded if this maximum idle time from the last received message expires, and the group MUST be terminated. On the Sender side, an RM Fault will warn of the failed sequence. In case the Sender must take the initiative to poll for such a fault, it will do so when: (1) GroupMaxIdleTime from the last received Ack is over, and (2) not all Acks were received. Once the Fault has been obtained, the Sender MUST NOT send further messages for this group, and MUST communicate instead a delivery failure to its application. Case d3: neither GroupExpiryTime nor GroupMaxIdleTime were specified for messages of this group. In this case, any out of order message will be discarded, and the group terminated. In order to avoid this situation in the absence of termination criteria for the group, a Sender SHOULD always wait for a message to be acknowledged, before sending the next message in the sequence. NOTE: the cases above (d1, d2, d3) decide of the discarding of out-of-order messages of a group, and therefore of the termination of a failed ordered group. This does not mean yet the removal of the group state, as message IDs may still be needed for duplicate checks. The rules for group state removal (t1, t2, t3, t4) are described in another section. General rule for persisting the ID of a message: --------------------------------------------- The duplicate elimination feature requires persisting the message ID (GroupId and optionally the Sequence Number), after the message has been processed and delivered to the application (state: "available"). The general rule about message ID persistence, is that an RMP MUST persist the ID of a message until the message expires. It is RECOMMENDED that an RMP removes the ID of a singleton message (message with GroupId but no SequenceNumber) from its persistent store after it expires. However, unlike for singletons, it is RECOMMENDED to NOT remove the message ID from the state of its group, when the message expires. Duplicate checks would be made over all past messages for the group, whether expired or not. There is no added cost here, as these IDs are remembered as sequence number intervals. The check will in fact be faster, as not discarding means fewer intervals. General rules for terminating a group, removing the state of a group: ----------------------------------------------------------------- NOTE: these termination rules apply to both ordered and unordered groups. NOTE: In all termination cases (t1, t2, t3, t4) below, it is not necessary to remember the ExpiryTime of all messages of a group, as only the maximum of all ExpiryTime values needs to be maintained. Termination (t1): Triggering event: GroupExpiryTime is over. Receiver side: The group is immediately terminated, and its state is removed from the RMP. No duplicate check is done against that group ever. If a "late duplicate" arrives, it would be automatically rejected due to its ExpiryTime. Sender side: The group is immediately terminated, and its state is removed from the RMP. Termination (t2): Triggering event: GroupMaxIdleTime is over. Receiver side: The group is immediately terminated. But unlike (t1), some of its past messages may not be expired yet. The RMP will keep the max of all expiryTimes of messages received so far for the group. The max(ExpiryTime) will determine the date at which the state of the group is removed. Sender side: GroupMaxIdleTime is counted between two sent messages. If it is over, the group is immediately terminated, and its state is removed from the RMP. Termination (t3): Triggering event: the RMP receives a status="end" message. The group had either GroupExpiryTime or GroupMaxIdleTime specified. Note that this only tells us that "no greater seq number will be received after", but that late messages may still arrive for this group. Subcase t3.1: The group was complete on receiver side. Receiver side: The group is immediately terminated. However, its state is removed according to (t1) or (t2), depending which termination criterion was given. Sender side: The group is also known to be complete. If either ordered delivery or guaranteed delivery was required, all Acks must have been received. Then only the group is terminated. Subcase t3.2: The group was not complete on receiver side. Then the receiver RMP and sender RMP MUST apply rules of (t1) or (t2), depending which one of GroupExpiryTime or GroupMaxIdleTime was specified. Termination (t4): Triggering event: the RMP receives a status="end" message. The group had neither GroupExpiryTime nor GroupMaxIdleTime specified. Subcase t3.1: The group was complete on receiver side. Receiver side: The group is immediately terminated. The date of removal of its state is based on rules for (t2), using max(ExpiryTime) of all its messages. Sender side: The group is also known to be complete. If either ordered delivery or guaranteed delivery was required, all Acks must have been received. Then only the group is terminated and its state removed. Subcase t3.2: The group was not complete on receiver side. The group is immediately terminated, and its state is removed from both RMPs.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]