[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] R: [wsrm] Rel YY
Hello Eugene, Much better. I totally agree with you. Thanks, Iwasa > Hello Iwasa, > I agree with you that proposal 2) is more convenient: efficiency, readability... But, even the limitation to one interval SHOULD be removed using a syntax like this: > > Proposal 3): > ----------- > > <RefToGroupId aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/groupIdValue> > <SeqInterval NmbrStart=1, SeqNumbrEnd=5> > <SeqInterval NmbrStart=7, SeqNumbrEnd=7> > <SeqInterval NmbrStart=9, SeqNumbrEnd=10> > </RefToGroupId> > > This covers all patterns: (like here 1-5;7; 9-10)using ONE <RefToGroupId> element. > > Regards, > Eugene > > -----Original Message----- > From: iwasa [mailto:kiwasa@jp.fujitsu.com] > Sent: Mittwoch, 24. September 2003 06:47 > To: Doug Bunting; Paolo Romano > Cc: 'Jacques Durand'; wsrm@lists.oasis-open.org > Subject: Re: [wsrm] R: [wsrm] Rel YY > > > > I also agree with Jacques proposal, > since I was considering a resolution and struggling > to find out a way to send multiple acks in a single Ack message, > which is our requirement. > > See the following example of five Acks in a single > Ack message: > 1) Without SequeceNumber: > <Response> > <RefToGroupId> > aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/group1 > </RefToGroupId> > <RefToGroupId> > aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/group2 > </RefToGroupId> > <RefToGroupId> > aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/group3 > </RefToGroupId> > <RefToGroupId> > aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/group4 > </RefToGroupId> > <RefToGroupId> > aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/group5 > </RefToGroupId> > </Response> > > 2) With SequceNumber > <Response> > <RefToGroupId SeqNmbrStart=1, SeqNumbrEnd=5> > aaaaa.bbbbb.cccccc/xxxxxxx/yyyyyy/zzzzzz/group1 > </RefToGroupId> > </Response> > > In conclusion, SequenceNumber is reasonably > desired to realize multiple Acks in a single Ack message. > Since we should not preclude a possibility of efficient and scalable > way of Duplicate Checking, and Multiple Acking. > > We may want to define default value of "0" as SequenceNumber for > non-ordered delivery, when it was ommitted. > > Thanks, > > Iwasa > > > ----- Original Message ----- > From: "Doug Bunting" <Doug.Bunting@Sun.COM> > To: "Paolo Romano" <paolo.romano@dis.uniroma1.it> > Cc: "'Jacques Durand'" <JDurand@fsw.fujitsu.com>; > <wsrm@lists.oasis-open.org> > Sent: Tuesday, September 23, 2003 9:28 AM > Subject: Re: [wsrm] R: [wsrm] Rel YY > > > > Paulo and Jacques, > > > > This appears to be a standard performance / storage trade off. The > > direction chosen at our last face to face meeting emphasizes simplicity > > of the specification and implementations. The suggestions below > > optimize on the other side, toward reduced storage requirements. The > > included reasoning depends upon the number of messages received overall > > (in some time period) and how many of those messages come from the same > > origin. Without clear numbers applicable to all WS-Reliability use > > cases (something we are not going to get), I find it hard to choose. > > > > Absent concrete numbers, I would probably lean toward the simpler > > solution already chosen by the group. > > > > thanx, > > doug > > > > On 22-Sep-03 16:49, Paolo Romano wrote: > > > > > I like Jacques proposal. We should address both the problems of (1) > > > minimizing the state information that needs to be persistently stored > > > and of (2) how to efficiently acknowledge batches of messages. The key > > > idea of Jacques suggestion is to have a sequential, strictly > > > increasing identifier. Such a property could then be exploited to > > > record/acknowledge continous sequences of messages (i.e. messages with > > > sequential MessageIDs) by referincing only the lower and upper bound of > > > the sequence. > > > With this approach, it is possible to reduce the amount of memory > > > required at the purpose of duplicates elimination even furtherly:in fact > > > if, for a given GroupID, a set of messages with > > > MessageID={0,1,..i..,n-1,n} has been received, then it is only necessary > > > to store the MessageID "n", to indicate that messages up to n have > > > already been received. > > > As an example, consider a receiver RMP which has caught the messages > > > carrying GroupID:X and MessageID={1,2,3,4,5,6,10,15,16}. It should only > > > record that "messageIDs up to 6" and MessageID={10,15,16} have > > > been received. In general, if a sequence of MessageIDs={j,j+1,..,k-1,k} > > > with k>j is received, it is sufficient to store just j and k. Note that > > > this property is independent on having enabled the ordering > > > functionality at the RMP level. > > > On the other hand, GroupID is essential (and sufficient) to allow > > > univoque identification of the "conversation". > > > > > > Paolo > > > > > > > > > > > > > > > > > > Here is a more precise wording of the issue I see with limiting > > > the use of sequence numbers to ordering only. > > > > > > Jacques > > > > > > > > > A new issue, (related to Rel-36, Rel-88) > > > ------------ > > > > > > Precluding the use of sequence numbers, when message ordering is NOT > > > required, > > > will pose serious scalability issues for duplicate elimination > > > algorithms. > > > Indeed, in doing so the GroupID would actually behave as a Message > ID, > > > and will require to be stored for each past message for the > > > duplicate look up. > > > Consider the two following deployment cases of WS-R: > > > > > > Case 1: Assume a messaging Hub, that must guarantee exactly once > > > delivery under > > > the following conditions: > > > Throughput: 1000 messages/sec > > > Size of GroupID values (approximately): 30 bytes > > > Scope of duplicate checks: messages over last 5 days > > > Using a messageID-based duplicate check, this Hub must keep a > > > database of GroupIDs able to store: > > > 1000 mesg * 432,000 (Number of seconds in 5 days) = 432,000,000 > > > GroupIDs to store. > > > Database size: 12.9 GB. > > > Besides the significant resource investment needed, (which may > > > please database vendors!) > > > this solution may simply not be feasible or at least cause quite an > > > additional headache and cost: > > > the database may not keep up with the speed required for duplicate > > > checks: > > > fast retrieval would require indexing. But the high rate of updates > > > of such an index > > > (2000/sec counting additions and removals) offsets the performance > > > gain in indexed search, > > > as we know indexes are costly to update, especially on a large > table. > > > One way or the other, the overhead of duplicate checking may simply > > > be overwhelming. > > > > > > Case 2: Assume a messaging end-point, receiving 10 messages/sec > > > average. > > > Duplicate search is required over the last 30 days. We would still > need > > > a full-fledged database (or B-tree) engine, with data size close to > > > 1 GB. > > > > > > > > > Proposal: (P1 + P2 + P3) > > > --------- > > > > > > P1: Make it possible for Senders to use GroupID + SequenceNo to do > > > any grouping they want, > > > even when ordering is not required. The only requirement is, these > > > elements > > > should be used as they are for ordering, i.e.: > > > - (GroupID + SequenceNo) must be globally unique, > > > - the sender must generate contiguous sequence numbers within a > group. > > > > > > P2:SequenceNo element is mandatory in the header, even when NOT > > > requiring ordering. > > > In both cases, a Sender can at discretion: > > > - (a) send messages with a different GroupID each time (1 message > > > per group, with smallest > > > SequenceNo) > > > - (b) send longer sequences of messages within a group. > > > > > > P3: To signal the Receiver to do ordered delivery on a sequence, the > > > Sender will add > > > messageOrder element in the header (close to option (3) in Rel 88), > > > and is required to > > > do so at least in the first message(s) of a group. > > > > > > NOTE1: On the receiver side, duplicate message elimination would use > > > SequenceNo > > > for fast duplicate elimination within a group, and use an indexed > > > search over a store > > > of GroupIDs for all groups currently active. Clearly, in the extreme > > > case (a) above, > > > duplicate elimination would be as costly as over conventional > > > message IDs. > > > But if Case 1 above actually has only about 1000 "active groups" at > > > any time > > > (e.g. 1000 concurrent senders generating each a single long sequence > > > at rate of 1 mesg/sec), > > > then the GroupID store and seq number info associated with it, can > > > hold in the memory > > > of a small device (estimate: 1 Mb) and does not need a DBMS. > > > > > > NOTE2: The requirement (Rel 26) to allow for "multiple-Ack" > > > messages, can be fulfilled > > > in a simple way when using sequences of messages, by the use of an > > > interval notation to signal > > > groups of messages that are acknowledged. Or, use an upper bound: > > > One Ack message could state > > > that all messages below SequenceNo N are acknowledged. > > > > > > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php. > > > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]