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: [i032] some optimization


Title: RE: [i032] some optimization

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



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