-----Original Message-----
From:
Sent: Friday, February 28, 2003 1:15 PM
To: 'Alex Rousskov'; OPES Group
Subject: RE: too fast out-of-order messages
see inline,
abbie
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Thursday, February 27, 2003 1:50 PM
To: OPES Group
Subject: too fast out-of-order messages
SNIP
Possible sane solutions:
0) Prohibit out-of-order messages and related
optimizations.
1) Prohibit out-of-order messages until the other
side acknowledges that it received the
<xaction-start> message (and, hence, the
transaction is now known to that other side).
The acknowledgment may be done explicitly
by immediately sending an <i-am-here> message
or implicitly by sending other transaction-dependent
messages as a part of normal operation.
We may even require immediate ACKs.
2) Require <xaction-end> message to always be sent
via the usual [slow] channel, even if another
copy of the message was sent via a "fast" channel.
This way, if fast message is too fast, we have
no optimization but preserve the same semantics.
Same carbon-copy rule can be applied to all
future out-of-order messages. Note that it is
OK to send two <xaction-end> messages because
the second one will be ignored by the recipient.
Personally, I favor (2) because it allows for an
optimization, is simple, has no overheads for those that do
not support the optimization, and does not require creation
of the "other side heard us" state.
Note that we can inform implementors that they may _want_ to
send explicit ACKs as an optional feature (they are allowed
to do that already), especially if the callout server does
not expect to send any other transaction-dependent messages
for some time. Again, the ACKs should use existing
<i-am-here> messages.
Comments/opinions?
SNIP
Personally, I would prefere option 0 for now (simply for
protocol simplicity reasons).
However, I do see your reasoning for option 2.
Abbie