[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] RE: some optimization:
Jacques Durand <JDurand@us.fujitsu.com>
10/06/2005 01:27 AM |
|
If we admit that the RMD should have the option of acking the gaps - meaning in effect the option of no longer reflecting the real status of these -, then I'd prefer the equivalent - yet less confusing - solution of letting the RMD move up the lower-bound of its acknowledgement window. So the lower AckRange element could have a @Lower that is greater than 1, and keep moving up at the discretion of RMD as the sequence gets bigger, just ignoring the old remaining gaps.
That way, the RMS knows that these gaps are not acknowledged - just no longer reported on. That could be combined with a "Cancel" policy for these ignored gaps.
Jacques
-----Original Message-----
From: Paul Fremantle [mailto:paul@wso2.com]
Sent: Wednesday, October 05, 2005 8:03 PM
To: Jacques Durand
Cc: 'Christopher B Ferris'; ws-rx@lists.oasis-open.org
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]