Next in thread → Next in month →

RE: [wsrm] Refiedn Proposal on Group Timing Parameters and Termination Conditions

From
Kacques Eurand
Date
2003-11-03T06:27:22+00:00
ID
Thread
RE: [wsrm] Refiedn Proposal on Group Timing Parameters and Termination Conditions
Title: RE: [wsrm] Refiedn Proposal on Group Timing Parameters and Termination Conditions

Tom:

saw this only after I sent my draft: see inline.

 

My refined proposal for Group Termination Conditions:

·        For all incoming messages in a group, the receiver checks the 

expiry time of incoming messages, and if not expired, uses the value to 

update a running statistic for the MaxExpiryTimeOfMessagesReceivedInGroup

<JD> OK

·        The reliable message MAY contain an optional attributes, 

GroupExpiryTime of GroupId.  Presence of GroupExpiryTime indicates a 

fixed duration group.   All messages in group MUST have expiryTime less 

or equal to GroupExpiryTime

<JD> OK

·        The reliable message MAY contain an optional attribute 

GroupMaxIdleDuration, of GroupId. Presence of GroupMaxIdleDuration 

indicates another condition to terminate group. If the receiver detects 

that no message for that group has been received for an interval of time 

equal to the GroupMaxIdleDuration, the group will be terminated

<JD> OK, in my draft this also has meaning on Sender side.

·        Neither of the two optional attributes of GroupId are allowed 

to be present in singleton groups

<JD> OK

·        If neither GroupExpiryTime nor GroupMaxIdleDuration is present 

as attributes of GroupId, then the expiryTime of the highest sequenceNo 

sent for that group must be greater or equal to the expiryTime of all 

previous messages in the group.  For such a group, the receiver RMP 

MUST  use the MaxExpiryTimeOfMessagesReceivedInGroup as the 

effectiveGroupExpiryTime for that group.

<JD> I think this is too complex a condition - plus, infinite groups are OK !

(see my draft)

·        The presence and values of both attributes of GroupId must be 

identical for every message sent in the group.

<JD> OK

·        If both timing attributes are present, the first criteria that 

fires terminates the group.

<JD> OK (though I gave preeminence to GroupExpiryTime in my draft)

·        Presence of status=end always takes precedence to signal 

termination of a group.

<JD> OK, but this only is the case when all previous messages were received.

·        When a group is terminated for any of the four reasons 

(status=end, reach GroupExpiryTime, GroupMaxIdleDuration passes without 

a received message, reach effectiveGroupExpiryTime) , all messages and 

group state information are held until the GroupExpiryTime if it is 

present, or until the MaxExpiryTimeOfMessagesReceivedInGroup if the 

GroupExpiryTime is not present.

 <JD> messages are not held, unless out-of-order.

The above rule concerns the "group state" , i.e. its message IDs past record,

for the sake of dup check.

Processing order constraints must be clarified, if we can agree to the 

above.

 <JD> I have sent a "state diagram", that mimmics teh processing algo.

Is that enough?

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 →