- From: Fred Carter <fcarter@amberpoint.com>
- Date: Fri, 10 Jan 2003 12:58:18 -0800
- To: www-ws-arch@w3.org
An addition or two here... Thus quoth Assaf Arkin (~ 10-Jan-03 11:19 AM ~)... >> [Ricky Ho] Assaf, a few following questions about your comments ... >> >> ... > >>Can you elaborate why (m' follow m) is better than sequence >>number ? > > > Very simple. I send you message m1 in conversation A. I send you message m2 > in conversation B. I send you message m3 in conversation A which I say > follows message m1. I expect you to process m1 ahead of m3, so if you > haven't received m1 one yet, don't begin processing m3. But if you received > m1 and m3 you can start processing them even if m2 is lost. Conversation A > may progress faster than conversation B, but that's ok because the > conversations are not related. So it also provides better failure isolation > A couple of things. First, under (m' follows m) a message has but one id. The proposal requires two: the MessageId itself, and a second id as (group, sequence number). This appears to be error prone, more complex, etc. Second, under (m' follows m), one might be able to join/parallelize conversations. One can easily imagine a situation wherein there are a number of messages that /depend on/ some [single] previous message. Under such a scenario, (m' follows m) requires but one instance of the "trigger message", whereas this is either not possible under (group, sequence) or requires multiple instances of that message (or, more correctly, multiple incarnations, since they'd all have to have different MessageId's, one assumes). > >>I've >>seen some characteristics of your approach >>a) The receiver never know if message ordering need to be >>preserve and also >>don't know when to stop tracking One could use the start/continue/end mechanism w/o the (group, sequence) to deal with lifetime if required. However, it's probably the case that the general time-to-live mechanism is sufficient. In a non-persistent, "best effort" type of environment, all this could be relaxed (somewhat) anyway... >>b) Once message lost happen, the receiver has no idea how many >>messages has >>been lost > > > The receiver doesn't need to know or care whether messages were lost per se. > What you actually need to do is preseve casual ordering of messages. So > messages have to be ordered with respect to each other within a > conversation, but overall messages can be lost, or discarded. Well, 'twould seem that lost messages could be inferred. Moreover, the lost message would be identified by its MessageId, not by its (group, sequence) "alias" -- which would seem better. So policies could be developed wherein some receiver, upon receipt of some ordered set, could request retransmission at some appropriate time. If the retransmitted message was also missing a predecessor, the same work can be applied until the order is fulfilled. > > > >>>For issue 4, receiver should hold to out-of-sequence message until it >>>decides to expire it at which point it should not process any previous >>>message. That would require a denied fault which the received >> >>should be able >> >>>to communicate indicating it received the message, there's nothing wrong >>>with the message, it simply has no intention of processing it. >> >>What is unclear about the spec. is how the "expiry time" is related for >>those messages within a sequence ordering guarantee. >>For example, if the receiver get message 1, 2, 3, 4 and discover >>message 2 >>is already expired, does it still keep 3 and 4. > > > That's my point. If message 2 arrives after it expires that is considered > message loss. Loss doesn't mean just lost in transient. Receipt of message > after its expiration is also considered message loss. The way to counteract > this is to say, 3 you can process after 1 even if 2 was lost, so go right > ahead and process it. 4 you need to process after 2, so we'll deal with loss > of 2 but not preclude processing of 3. > > Not argurable I could get the same behavior by putting 1/3 and 2/4 in > different groups as 1/2 in each group. In this case a group is a sequence > that observes casual order of all messages, in other words a conversation. > But then start/continue/end become problematic. Here's why: > > - The first message in a group is always the start and it's always numbered > 0. So the 'start' identifier is redundant you can derive that from the > message number. +1 > > - Conversations are open ended. For example, I can send message m3 and based > on the reply I may or may not send message m4. So is message m3 'end' or is > there no 'end' message in this group, or do I need to invent an empty > message to signify 'end'? +1 > > arkin > > >>Another case, if the receiver get message 1, 3, 4 and then get message 2 >>later but it already expired, does it throw away 3, 4 (it may >>already send >>ACK for 3, 4) >> >>Best regards, >>Ricky >> >> >> > > -- Fred Carter / AmberPoint, Inc. mailto:fred.carter@amberpoint.com tel:+1.510.433.6525 fax:+1.510.663.6301
Received on Friday, 10 January 2003 15:59:40 UTC