Next in thread → Next in month →

RE: [wsrm] Group Termination without group timing parameters - again

From
Kacques Eurand
Date
2003-11-08T02:20:36+00:00
ID
Thread
RE: [wsrm] Group Termination without group timing parameters - again
Title: RE: [wsrm] Group Termination without group timing parameters - again

Tom:

I would propose a very simple and bold solution to your problem,

when users do not care specifying GroupExpiryTime or MaxGroupIdleTime for 

an ordered group:

- the sequence will be terminated as soon as there is an out-of-order message 

on receiver side.

The Sender can avoid this very easily: always wait for previous Ack before

sending the next in-order message.

We can't rely on message ExpiryTime in any way here, if we agree that

ExpiryTime means nothing more than latest date an RMP can accept a message.

(no further semantics, once accepted.)

Regards,

jacques

-----Original Message-----

From: Tom Rutt [mailto:]

Sent: Friday, October 31, 2003 9:48 AM

To: wsrm

Subject: [wsrm] Group Termination without group timing parameters -

again

I picked the wrong example last time.

This is the troubesome example from the meeting

Ordered example 2

without GroupExpiryTime and without GroupIdleInterval

1 – exp4pm (start) sent at 0 pm –

2 – exp8pm (continue) sent at 0 pm –

3 – exp 4pm (end) sent at 0 pm

receive 1 - at 1pm ack, derived get=4pm then make avialable to user -

recieve 3 – 1.05 pm then ack – derived get=4pm, and buffered (not made 

available yet, waiting for 2

4pm – group terminated, 3 removed from messageOrder queue, will not be 

made available to use.

receive 2 – at 6:00 PM – acked and start new sequence. Derived get=8pm, 

will be buffered waiting for 1

8pm – terminate new sequence, remove 2 from buffer will not be made 

available to user.

Ordered example 2 has the problem that the sender has all three messages 

acked, however 2 was not made available.

--

This is the one which could be avoided by having the sender ensure that 

the expiry times

for messages in a sequence are monotonic increasing (i.e., greater or 

equal the maxExpiryTimeOfReceivedMessegesInGroup). This could be the 

corresponding check to

the one we already have for when groupExpiryTime is present (expiryTime 

less or equal to GroupExpiryTime).

Tom Rutt

-- 

----------------------------------------------------

Tom Rutt                email: ; 

Tel: +1 732 801 5744          Fax: +1 732 774 5133

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.
Next in thread → Next in month →