Title: Rev "d" of Rel52, 57
A few
comments:
ExpiryTime: The sender's bid for a time beyond which there is no need to
persist the message. Receivers that cannot honor this request must fault.
Note that for messages contained in a group, any rmp state related to groups
must be held at least as long as there exists an unexpired
message.
GroupEnd: a marker with application semantics ONLY which may usefully
signify a conceptual end of file. It serves no fundamental protocol role
other than it may be used by implementers as a hint for optimization
purposes.
GroupID: An identifier that may be used by the application to identify a
collection of messages.
RemoveAfter: Since RemoveAfter must be set equal to or larger than
ExpiryTime, it only serves the function of extending the lifetime of group
information that may be held in the RMP even though all prior messages in the
group have expired. Since it is an optional attribute, then receivers must
in any case implement a policy-driven mechanism that gracefully terminates a
group after all messages expire. In the case of many concurrent
groups with large RemoveAfter times, implementers will be forced to implement
another policy based mechanism to prevent group information from growing
without bounds. Since these two mechanisms must exist then RemoveAfter has
the role of requesting resources that potentially the receiver does not
have. Of course this case dictates the introduction of another
fault. Perhaps this is just the point. Without this optional
attribute in an incoming group header, the group must function anyway. Is
the juice worth the squeeze?
RetryInterval: The time, that a sender waits before re-transmitting an
unacknowledged message. There is no protocol relevance to this parameter
other than to avoid anomalous behavior, the Retryinterval must be longer than
the round-trip message time and much shorter by factors than
ExpiryTime-NOW. The sender may calculate this parameter from observed
network and receiver behavior in the manner similar to that described in TCP
Extensions.
Security/Robustness:
Receivers shall continue to operate with respect to normal operation even
though one or more senders may be hitting it with bad parameters. This I
presume would be extra-important for any protocol describing itself as reliable.
Consider varying values of every parameter in message re-tries and near infinite
expiryTime and RemoveAfter.
Ramble:
Proper
protocol operation, I assume, must occur even with a dormant or inactive
application. That means that typically the RMP's persistence mechanism
thus will operate as a queue of messages waiting to be processed by the
application. That makes us look for ways to reduce state and state
persistence for the sake of efficiency. We have not discussed application
to RMP interactions which may be useful to implementers. There
are a number of potential optimizations (such as, message payloads may be
deleted for any message that has been acted upon by the application), but they
have no bearing on the protocol specification since they relate to APIs which
are not part of the specification. I am feeling that RemoveAfter and its
cousin MaxGroupIdle fall in the category of implementation optimization hints as
well.
-bob
-----Original Message-----
From: Jacques Durand
[mailto:]
Sent: Sunday, November 30, 2003
3:35 AM
To: ''
Subject: [wsrm]
Rev "d" of Rel52, 57
Rel52 and Rel57 reworded and adjusted to
late comments, (tagged "rev d")
though nothing radical:
- Still makes use of Group termination
timeouts:
I really find it
hard to overload message ExpiryTime with group termination
semantics: ExpiryTime is about the delivery cycle
for messages, which is orthogonal
to how long a group should be active.
- Agree that ExpiryTime should be set, as
Bob suggested, based on expected
transport performance and network monitoring (e.g. round-trip timing)
and should
normally be opaque to
users.
[<Bob Freund>] My comment was related to
message retry interval. that is the amount of time that a sender should
wait prior to re-transmission of an unacknowledged message. Round trip
timing is most important for this parameter.
[<Bob Freund>] ExpiryTime should
be the time after which a message in persistent storage may be
deleted
It is a tuning
parameter that says: "normally the delivery cycle (transport + RMPs)
for
this message should not exceed
this time. If it does, this means that the communication
conditions are too bad for doing reliable messaging.
In that case the RMP will not
deliver it, and notify the app instead."
- Unlike ExpiryTime, group termination
parameters have an application semantics:
In the same way a reliability QoS associated with a group is based on
application needs,
(e.g. ordering),
limit on group duration is also based on application profiles:
some apps will be able to mark the
last message with "end", some will not.
Among these, some will be able to cap the duration of their groups
(GroupExpiryTime),
some will only
be able to say what idle time can safely be considered as terminating
a group (GroupMaxIdleTime). Finally, some
groups are not supposed to terminate ever...
which is fine as long as an implementation can
handle the space overhead (group states)
in case of many of these
- So in Rel52 I still propose the 4
termination cases:
They may not
make for a concise spec, but they look very implementable to me:
in all cases, Sender and Receiver can
synchronize group termination without
need of notification (thanks partially to the Ack semantics
(Rel33)).
To me this is by far the
most important enhancement.
Regards,
Jacques
<<Time-Rel57d.txt>> <<Time-Rel52d.txt>>
