[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
I don’t see the current draft as
directly specifying that acks are “on receipt”, although clearly an
implementation could take that approach, and it’s probably the more
intuitive one – but, specifically I think the current draft allows an RMD
to defer acking until the messages are “in order” i.e. not acking
those messages that are still sitting “behind gaps”. There is
a specific benefit to the “ack when deliverable” (note deliverable,
not delivered) approach for low-resource situations (I can elaborate if needed,
let me know), so I would hesitate to assume that ack-on-receipt is the model
used by all implementations at all times. Now, of course, if my “ack
when deliverable” approach is in use by the RMD, then the final ack will
be accurate: all the messages that have been acked are safely deliverable
after a close. It’s the “ack immediately on receipt”
approach that has that problem – but to be clear, I do not want the spec
to impose an ack strategy, I think the freedom the spec gives the RMD on
choosing an ack strategy is one of the coolest things in the current spec. I think the general way out of this may be
the following: If the original use case was “I want to close the
sequence and have an accurate final ack so I know which ones to resend in a
different sequence later”, then it seems to me that this is really only
viable for sequences that do not have InOrder requirements: If I will
send some of them in sequence S2 later there is no guarantee that they will be
delivered in order with respect to the ones I sent in sequence S1 earlier, and
I am going to break the InOrder requirement anyway. The RMS knows from the final ack which
messages the RMD “has”; if it knew the the RMD<->AD DA, then
it would know what to do: -
If the
DA is InOrder, it knows that it cannot close and then restart a new sequence at
all without violating the underlying ordering requirements -
If the
DA is not InOrder then it can close and restart a new sequence later, and if so
it should resend all messages not in the final ack. But, the RMS does not know the RMD-AD DA; I
guess we could propose that the target endpoint publish its DA in its policy
(or createSequence, whatever), and I personally think it would be a good thing
even for unrelated reasons – but I suspect there could be a lot of
opposition – You have to go back to a 2002 version of the member
submission to find DA in the policy, and I think this was removed very much
intentionally. But maybe we could propose it and see? A minor point on wording: I think
rather than “MUST not accept” we should say “MUST not deliver
to the AD” as in the original text below – “accepting”
is not something that we define anywhere and it could be misconstrued.
Not delivering is what matters. G. From: Jacques Durand
[mailto:JDurand@us.fujitsu.com] Inline <JD> From: Doug Davis
[mailto:dug@us.ibm.com]
<JD>
InOrder DA in itself does allow delivery of non-contiguous messages (
"...it says nothing about duplications or omission..." Section 2,
Core spec) So, getting an ACK+Final
guarantees to the RMS which messages were not just ACKed but delivered - and
any messages after the first gap can be recovered (e.g. resent in a new
sequence if it wants) without fear of them being processed twice by the RMD's
app. <JD>
but again, because the semantics of Ack is just "on receipt" and not
"on delivery", an honest RMD developer may decide to Ack these late
messages, rendering the final Ack incorrect (or unstable, depending when it is
requested...). Another way to avoid adding this text is to make the statement
below more general, not limited to "new application messages": "...can send a <wsrm:Close> element, in the body of a
message, to the RM Destination to indicate that RM Destination MUST NOT accept
any new application messages for the specified sequence." Replace
with: "...can send a <wsrm:Close> element, in the body of a
message, to the RM Destination to indicate that RM Destination MUST NOT accept
any application messages for the specified sequence, other than those already
received at the time the <wsrm:Close> element is interpreted by the RMD." -jacques
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]