RE: [ws-rx] New Issue; SequenceAcknowledgement:Final assumption ofdeliverability

No, I am NOT describing any delivery
assurance mechanism, or attempting to re-open any issue in that regard.
 The introductory assertion that the spec supports reliable in-order
delivery is patently false if the corner case of a gap remaining at close of
sequence provides misleading and inaccurate information to the RMS.  I
liken this cse to acknowledging a message with a checksum error which was
received, but will be tossed.

 

I guess then, that the wording in the spec
introduction concerning enabling in-order delivery is inaccurate (at least in
the reliability sense) and should be stricken.  Those statements are sort
of DA-ish as well

-bob

 

From: Doug Davis
[mailto:] 

Sent: Thursday, March 23, 2006
8:23 AM

To: 

Subject: RE: [ws-rx] New Issue;
SequenceAcknowledgement:Final assumption of deliverability

 

Bob - this gets into the entire DA issue which is out of scope.
 All the RMD can/should say is whether or not it got the messages - and
that list of messages should never decrease.  If there are gaps in the
sequence then the RMS will know which messages will be delivered (or not) based
on the DA in use.  How it knows the DA is out of scope  :-)

thanks,

-Doug

 

  
  
"Bob Freund-Hitachi" <> 

  
03/23/2006
  06:35 AM 

  
  
  
   

    
    
To

    
    
    
Doug Davis/Raleigh/IBM@IBMUS, "[WS-RX]"
    <> 

    
   

   

    
    
cc

    
    
    
 

    
   

   

    
    
Subject

    
    
    
RE: [ws-rx] New Issue; SequenceAcknowledgement:Final
    assumption of deliverability

    
   

  
  
 

  
   

    
    
 

    
    
    
 

    
   

  
  

  
 

Doug 

If “taking responsibility” for a message implies
that at least an attempt to deliver the message will be made, then I guess that
the previous ack of a message with a sequence number larger than a gap is
untruthful if in-order delivery is enforced. 

The proposal allows the rmd to correct the previous
misstatement, which it had no way of knowing was untruthful at the time it was
made.  The RMS had the expectation at the previous acknowledgement that
further messages may be coming which was shattered when the sequence was closed
without that expectation being met. 

The RMS has no way of knowing that ordered delivery was in
effect, so it cannot second guess the RMD. 

Alternatively, we could say that all messages that have been
acknowledged will be delivered, on at least a best-efforts basis, independent
of in-order delivery and the existence of gaps in the sequence. 

Or, we could define durable persistence and a way for
sequences to be resumed after closure (I think just too complicated)

Thanks 

-bob 

  

  

 

From: Doug Davis
[mailto:] 

Sent: Wednesday, March 22, 2006 10:54 PM

To: Bob Freund-Hitachi

Cc: [WS-RX]

Subject: Re: [ws-rx] New Issue; SequenceAcknowledgement:Final
assumption of deliverability 

  

Bob, 

 I'm confused - doesn't the sending of an Ack for a certain message number
already imply that the RMD is taking responsibility for it?  If only
SeqAck+Final means that, then does that mean that a SeqAck (non-final) means
something less?  like a lie? 

-Doug 

 

  
  
"Bob Freund-Hitachi" <> 

  
03/22/2006
  02:07 PM 

  
  
  
 

  
   

    
    
To

    
    
    
"[WS-RX]" <>
    

    
   

   

    
    
cc

    
    
    
  

    
   

   

    
    
Subject

    
    
    
[ws-rx] New Issue; SequenceAcknowledgement:Final
    assumption of deliverability

    
   

  
  

    

  
 

  
   

    
    
  

    
    
    
 

    
   

  
  

  
 

Description

Modify definition of SequenceAcknowledgement:Final to reflect accurate ending
delivery capability status. 

Justification

The protocol defines the SequenceAcknowledgement:Final element which contains
the final summary of message acknowledgements at the closure of a sequence. It
is assumed that the RMD has taken responsibility for all messages that have
been acknowledged.  Depending upon the operation of the RMD and its
interface with the application, Messages that have been previously acknowledged
as received by the RMD, may never be deliverable.  One such case of note
that comes to mind is the situation of a message sequence that is being
delivered in-order to an application which is closed at the time when one or
more gaps that may exist in the sequence.  If this situation occurs, the
RMS will have incorrect information concerning exactly which messages have been
or will be deliverable at the conclusion of a sequence. 

Note that there is nothing in the spec that states what the RMS is to do with
the information contained in SequenceAcknowledgement:Final.  This proposal
does not add any such statement, but it does permit the information to be
potentially interpretable. 

Target: core 

Proposal:

Reference Core Spec CD03

insert after line 613:

SequenceAcknowledgemnt:Final shall identify only those messages that have been
delivered or which the RMD has taken responsibility for delivery without regard
to the previous acknowledgement status of any message. 

State Table impact: None