[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Discussion Initiation on Minimal Timiing parameters
The proposal from Jacques for Rel 52 includes the following: Termination (t1): Triggering event: GroupExpiryTime is over. Receiver side: The RMP MUST NOT accept any new message for this group and MUST terminate the group. It is RECOMMENDED that its state be removed as soon as possible. No duplicate check needs to be done against that group ever. If a "late duplicate" arrives, it would never be delivered to the application, as its ExpiryTime, which is always earlier than GroupExpiryTime, would have expired. Sender side: The group MUST be terminated, and its state removed from the RMP. Termination (t2): Triggering event: GroupMaxIdleTime is over. Receiver side: Except for an ordered group that is out-of-order (see this case in Rel52), the group MUST be terminated. But unlike (t1), some of its past messages may not have expired yet, and therefore their ID still be needed for duplicate checks. If we define max(all ExpiryTime) as the max of all ExpiryTimes of messages already received for a group, an RMP MUST persist the state of a group even after termination of the group, at least until max(all ExpiryTime), in case duplicate elimination is required. Sender side: The group MUST be immediately terminated, and its state is removed from the RMP when either (1) the time elapsed since the last sent message (including retries) exceeds GroupMaxIdleTime, or (2) for an ordered group, a message has failed to be successfullydelivered (as described in Rel 57), whichever occurs first. Termination (t3): Triggering event: the RMP receives a status="end" message. The group had either GroupExpiryTime or GroupMaxIdleTime specified. Note that such an event only tells that "no greater seq number will ever be received after", but late messages may still arrive for this group. Subcase t3.1: The group was complete on receiver side. Receiver side: The group MUST be 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, and MUST be terminated. However, if guaranteed delivery was required, all sent messages must either have been acknowledged, or been faulted, before termination. 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 oneof 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 t4.1: The group was complete on receiver side. Receiver side: The group MUST be terminated. The date of removal of its state is based on rules for (t2). Sender side: see subcase t3.1 above. Subcase t4.2: The group was not complete on receiver side. This event, by itself, does not cause the termination of the group. Now lets try for argument sake to simplify, and assume all we have is t4. Would this work for the ordered examples from our last face to face meeting? (please give your analysis of the following examples to any proposed solution to simplifying the four termination cases above.) Ordered example 1 group expiry 10pm 1 – exp4pm (start) sent at 0 pm 2 – exp8pm (continue) sent at 0 pm 3 – exp 4pm (end) sent at 0 pm receive 1 - at 1pm ack and made avialble to user recieve 3 – 1.05 pm then ack and buffered (not made available yet, waiting for 2 until group persistence removed due to termination conditions firing, do not terminate at 4Pm 2 is never received. Group is terminate at 10:pm – terminate group, removed 3 from group persistence buffer (i.e, will not be made available to user) Ordered example 2 without GroupExpiryTime and without GroupIdleInterval 1 – exp4pm (start) sent at 0 pm – 2 – exp8pm (continue) sent at 0 pm – 3 – exp 4pm (end) sent at 0 pm receive 1 - at 1pm ack, derived get=4pm then make avialable to user - recieve 3 – 1.05 pm then ack – derived get=4pm, and buffered (not made available yet, waiting for 2 4pm – group terminated, 3 removed from messageOrder queue, will not be made avalable receive 2 – at 6:00 PM – acked and start new sequence. Derived get=8pm, will be buffered waiting for 1 8pm – terminate new sequence, remove 2 from buffer will not be made available to user. Ordered example 2 has the problem that the sender has all three messages acked, however 2 was not made available. Ordered example 3 GroupExpiryTime 8:00pm 1 – exp4pm (start) sent at 0 pm – 2 – exp8pm (continue) sent at 0 pm – 3 – exp 4pm (end) sent at 0 pm receive 1 - at 1pm ack, derived get=4pm then make avialable to user - recieve 3 – 1.05 pm then ack – derived get=4pm, and buffered (not made available yet, waiting for 2 8pm – group terminated, 3 removed from messageOrder queue, will not be made available to use. 8pm – terminate new sequence, remove 2 from buffer will not be made available to user. receive 2 – at 9:00 PM – expired, not acked and do not start new sequence. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]