Alex Rousskov wrote:
Not exactly. The callout server must send either <data-as-is> or
<data-have> messages until Time B (at least). The server is still in
the loop. Recall that there is no commitment -- some of the [still
queued] data messages from the OPES processor may not have a [copied]
flag; we need to make sure the loop does not break until there are no
such messages.
You're right, I ignored that the callout server has to send
<data-as-is> rather than just discarding the messages. I somehow
assumed the OPES processor would implicitly interpret "gaps" in the
returned message stream as <data-as-is> (since we've reliable and
ordered transport). Probably not a good idea...
Also, "Time B" is not the time when "OK, disconnect" message is
received by the callout server. It is the time when the last uncopied
data is forwarded back to the processor. The information about still
unforwarded data will be present in the "OK, disconnect" message. If
there is no such data (at the time the OK message has been received),
the callout server may disconnect without processing any further
messages.
Sure, if you assume the "disconnect" signal can be send on a "high
priority" connection, I assumed it would be send with the same
priority as the other transaction messages (which might give a smaller
benefit, as you sated correctly).
We could say that <data-as-is> messages are not required in the above
case, but it complicates the protocol (essentially creates multiple
sources of data) without much benefit. <data-as-is> messages as small.
To keep things simple, both <data-as-is> and <data-have> messages need
to be sent, as usual.
That's sort of what I had in mind, but I now agree that the overhead
of <data-as-is> messages is small and that it would probably not
justify added complexity.
Here is a simplified version that is almost as "fast":
server-to-processor: <I-want-to-disconnect-ASAP>
processor stops sending more data
processor waits for all pending data up to the last
uncopied chunk to be forwarded via
<data-have> or <data-as-is> messages from
the server
processor-to-server: <app-message-end reason=disconnect>
There is only one new message needed (<I-want-to-disconnect-ASAP>) as
long as <app-message-end> message can be sent on a "high-priority"
connection (the latter will be done only when there is no pending
uncopied data, of course).
This scheme is simpler because the OPES processor does not have to
tell the server about the last uncopied chunk. On the other hand, this
scheme is slower because the server cannot disconnect until it
receives that <app-message-end> message. The first scheme allowed the
server to disconnect immediately after sending the last uncopied
chunk. The delay difference is one "round trip" time.
Yup, agreed. I'm somehow leaning towards the second, simplified
alternative - simply for simplicity :) But these are just my 2 cents.
Summary:
0) no [copied] flag does not allow for any optimizations
but is very simple
I consider the [copied] flag useful enough to keep it!
A) plain [copied] flag alone does not allow for the
callout server to get out of the loop (scheme A)
B) copying commitment is the most efficient optimization
but has deadlocks (scheme B)
C) <I-want-out-of-the-loop> scheme with details about
the last uncopied chunk exchanged is more complex
than copying commitment (scheme C)
D) <I-want-out-of-the-loop> scheme without details about
the last uncopied chunk exchanged is simpler but
slower than scheme C
Option (D) seems to be reasonable tradeoff between complexity and
efficieny...
-Markus