[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
Giovani: I believe there is more in what you say
below than what is needed to resolve i019 and i028. I am commenting on some of your
points below - but I believe they can be largely dissociated from the
current issues at hand, and be treated separately. Regards, Jacques From: Giovanni Boschi
[mailto:gboschi@sonicsoftware.com] 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". <JD>
this is a very important point to clarify. What you are in effect suggesting,
is an Ack on delivery (since once in order, they can be delivered.). But the
spec is clear: Acknowledgement: The
communication from the RM Destination to the RM Source indicating
the successful receipt of a message. (and in the messaging model, there is a clear distinction between
Receipt and Delivery, see Fig 1) 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. <JD> Join the club. I have been favoring
"ack on delivery" from the start, but that seems to clash with the
WS-RM model: the protocol would become involved in the RMD-AD delivery
assurance. Please try to convince Chris... 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. <JD> well... too much choice is
not necessarily good here: an RMS must preferably know what Ack means to the
other party. I prefer the spec to be clear one way or the other about this. I
think it is now. Just not the way I prefer - because as drafted today, I
maintain, it is OK to acknowledge a message that will never be delivered, and
there is no provision for the RMS to know about this. But that is another
issue. 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. <JD> I think if InOrder is required
but not AtLeastOnce, that means we accept message loss - and therefore we
would not have any qualms not resending these in S2. Even if InOrder+ AtLeastOnce
is required, some gap may still be there when closing the sequence S1. But
again, S2 can forget about the missing messages in S1: the DA is still
satisfied if a delivery failure has been notified for the missing, 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. <JD> These behaviors are somehow
out of scope of the spec: there is no requirement on dealing with missing
messages across sequences. That is an optimization that can indeed rely
on out-of-band knowledge of the DA. 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. <JD> Right for the loose
terminology. But again, you are opening a can of worms: we do NOT want these
messages to be acknowledged (not juts "not delivered") as soon as
the closing is effective. Maybe this would do: ...RM Destination MUST NOT acknowledge nor deliver any received
messages with a Sequence header for the specified sequence, other than those
already received at the time the <wsrm:Close> element is processed by the
RMD "-Jacques G. From: 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]