OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] RE: some optimization


Jacques

Yes it does go against that invariant! But the question is, if we are 
going to create a model for handling gaps (which was obviously not in 
the original requirements), then does this invariant have value still?
It seems like removing the invariant makes for a much simpler model for 
handling gaps.

Alternatively we can treat the protocol much more as "reliable 
messaging" and not optimise the case where there are persistent gaps.

Paul



Jacques Durand wrote:
>
> Paul:
>
> Right I think that needs to go on another thread from now on...
>
> I am aware that my proposal was "branching" out of scope of a direct 
> resolution of i032. I was just stating  (should have made it clearer) 
> that I would very much like to see a gap-reduction issue resolved 
> first before even discussing further the proposed solution to i032. 
> (you are right I need to make it a separate issue on its own - and it 
> also concerns node-reduction in acks even without the string 
> optimization.)
>
> A bit concerned by your assumption that "ack-ing the gaps " is OK:
> Isn't this going against protocol invariants (2.3): "...Every 
> acknowledgement issued by the RM Destination MUST include within an 
> acknowledgement range or ranges the sequence number of every message 
> successfully received by the RM Destination and MUST exclude sequence 
> numbers of any messages not yet received."
>
> Jacques
>
> -----Original Message-----
> From: Paul Fremantle [mailto:paul@wso2.com]
> Sent: Tuesday, October 04, 2005 7:58 PM
> To: Jacques Durand
> Cc: 'Christopher B Ferris'; ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] RE: [i032] some optimization
>
> Jacques
>
> It seems to me that you are mixing threads :-)
>
> At the meeting there was the most concern with the @ranges attribute,
> not just because of size, but also because of validity, schema checking
> and even readability. I think that the optimisation proposal is unlikely
> to be accepted without a change to that aspect.
>
> However, that is a separate issue from gap handling. I think Stefan's
> proposal is the closest to preserving the intent and model of the
> protocol without great changes. The benefit of Stefan's proposal is that
> it is an RMS initiative. There is no need to have an RMD based approach
> because the RMD can always clear the backlog by "ack"-ing the gaps
> (lying). So I don't see any benefit in a policy based assertion unless
> maybe you are thinking of a client policy?
>
> Paul
>
>
> Jacques Durand wrote:
> >
> > Chris:
> >
> > Regardless of the overall merits of the solution you proposed, our
> > developers are concerned upfront with one aspect of it:
> >
> > - the size of the @ranges attribute string may potentially become
> > itself intractable, if the # of gaps becomes big.
> >
> > For the proposed solution to be worth considering there has to be an
> > additional way to deal with increasing numbers of gaps in seq
> > acknowledgements, and to reduce them (we rule out the option of
> > closing  the sequence and reopening a new one).
> >
> > One approach already mentioned ("Cancel") is based on the assumption
> > that beyond some point in time, the RMS is not interested in getting
> > notification of old gaps over and over again, provided it can be sure
> > they will never be delivered.
> >
> > Considering various ways that can be achieved (only the first one has
> > been discussed so far):
> >
> > 1- Use a "Cancel" operation as proposed by Stefan B.
> >
> > 2- add a protocol parameter in RM PolicyAssertions, that could be
> > named "receptionwindow". It would work like this: Seq-acks will only
> > be issued for the portion of sequence between:
> >
> > [lastReceivedSeqNmber - (minus) receptionwindow] and
> > [lastReceivedSeqNmber].
> > Every non-received message with a lower seq num, would automatically
> > be "cancelled".
> > (less fine-grained than "Cancel", but no need to introduce new
> > protocol signaling).
> >
> > 3- max validity duration parameter in RM PolicyAssertions for
> > messages: when added to their sending time, if the message is received
> > while its validity period is over, it is automatically cancelled.
> >
> > Clock skew adjustment can be done by exchange at sequence creation 
> time.
> > (advantage: tied to elapsed time, which can be set coherently with
> > resending duration, instead of based on number of past messages with
> > receptionwindow)
> >
> > Opinion?
> >
> > - Jacques
> >
> > -----Original Message-----
> > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > Sent: Monday, August 15, 2005 5:37 AM
> > To: ws-rx@lists.oasis-open.org
> > Subject: [ws-rx] some optimization
> >
> > All,
> >
> > I've been thinking a bit about how we might optimize the 
> serialization of
> > the
> > Sequence and SequenceAcknowledgement elements in the protocol; doing so
> > without
> > actually changing the abstract properties of the protocol.
> >
> > Here's what we have today:
> >
> > <wsrm:Sequence xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@";>
> >   <wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier>
> >   <wsrm:MessageNumber>1</wsrm:MessageNumber>
> >   <wsrm:LastMessage/>
> > </wsrm:Sequence>
> >
> > I think that if the properties were serialized as attributes, we would
> > have a much more compact
> > serialization:
> >
> > <wsrm:Sequence xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@";
> >         seqID="http://example.org/mysequence/1234"; msgNum="1"
> > last="true"/>
> >
> > The serilaization savings for a Sequence element is 91 bytes per 
> message.
> >
> > For the SequenceAcknowledgement, we could collapse the acknowledgement
> > range elements into a single
> > attribute value that was a sequence of integers. e.g in the simplest
> > case,
> > here would be an example SeqAck:
> >
> > <wsrm:SequenceAcknowledgement
> > xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@";
> >         seqID="http://example.org/mysequence/1234"; ranges="1 1 3 10">
> >
> > where the @ranges attribute is a list of unsignedLongs. e.g.
> >
> > <xs:simpleType name='rangeType'>
> >   <xs:list itemType='xs:unsignedLong'/>
> > </xs:simpleType>
> >
> > The ranges are expressed as "low hi low hi low hi ..."
> >
> > In the example above, message #2 is missing. Here's an example of a 
> nack:
> >
> > <wsrm:SequenceAcknowledgement
> > xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@";
> >         seqID="http://example.org/mysequence/1234"; nack="2">
> >
> > The savings on the SequenceAcknowledgement are 99 bytes/message 
> using the
> > optimized serialization for a
> > SequenceAcknowledgement with no gaps, 148 bytes for one with one 
> gap, 195
> > bytes for one with two gaps,
> > and 242 for one with three. Basically, it boils down to an 
> additional 47
> > bytes per gap (in this case using namespace
> > prefix of wsrm) or 42 bytes using the default namespace.
> >
> > In terms of creation/serialization performance, I found an average
> > savings
> > (using java) of:
> >
> > Sequence - .0478 ms
> > SequenceAcknowledgement (with 2 gaps) - .19765 ms
> >
> > I haven't had a chance to assess parsing performance benefits yet, 
> but I
> > have to imagine that there
> > would be some benefit.
> >
> > Sure, scoff if you will, but in the context of an server implementation
> > processing a gazillion messages, the
> > performance savings are non-trivial. Think about providing RM 
> support for
> > a customer such as a Ford or FedEx.
> >
> > Of course, in the context of a message with a WS-Security header, 
> the RM
> > performance and bandwidth overhead
> > pales in comparison for the processing of the overall message, but IMO,
> > there's no reason that RM should
> > exacerbate the issue. If there is a performance and bandwidth
> > optimization
> > that we could effect without actually
> > changing the protocol, I think we should give it serious consideration.
> >
> > As for extensibility, we could still have the Sequence and
> > SequenceAcknowledgement elements extensible
> > via both attributes and elements. There's no reason to change that.
> >
> > Thoughts?
> >
> > Cheers,
> >
> > Christopher Ferris
> > STSM, Emerging e-business Industry Architecture
> > email: chrisfer@us.ibm.com
> > blog: http://webpages.charter.net/chrisfer/blog.html
> > phone: +1 508 377 9295
> >
>


-- 

Paul Fremantle
Vice President of Technology
WSO2, "Oxygenating the Web Service Platform", www.wso2.com

OASIS WS-RX TC Co-chair

Yahoo IM: paulfremantle
Cell/Mobile: +44 (0) 7740 199 729
paul@wso2.com




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]