On Mon, 24 Mar 2003, Markus Hofmann wrote:
> [...] One way to avoid the deadlock is to support the following
> confirmation/dialog:
>
> server: I want to get out of the loop!
> processor: OK, you can get out of the loop after
> processing first N bytes of this application
> message (N could be zero). I will stop
> sending you more data as of now.
> server: here is the data you asked for (could be
> several data messages)
> server: I am out of the loop
>
> Unfortunately, supporting this kind of dialog efficiently
> requires dedicated/priority connection: The primary data
> connection may be clogged by (yet unprocessed) data messages to
> the callout server, preventing the "OK" response from reaching
> the server fast. If the "OK" response is slow, there may be
> little gain from the optimization because a lot of data messages
> would be processed by then.
OK, let me see whether I understood the scenario correctly: The
callout server has decided that it has seen enough and wants to get
out of the loop as quickly as possible. This is signaled to the OPES
processor and happens at "Time A". After receiving the signal from the
callout server, the OPES processor sets a specific "end" flag in the
next outgoing message, indicating to the callout processor the end of
the specific transaction.
Yes. This message can be sent on a "high priority" connection, but in
that case, it has to tell the callout server if there are any
(possibly queued) data messages _without_ the [copied] flag. The
protocol needs to make sure that no data is lost when the callout
server "disconnects".
If that message is not sent on a "high priority" connection, no
special steps are needed. However, the delay between A and B can be
significant in that case. The longer the delay, the smaller is the
benefit of getting the callout server out of the loop...
This message is received by the callout server at "Time B". Between
"Time A" and "Time B", the callout server can discard any message it
receives for this transaction and that has the [copied] flag set
(doesn't seem to be too much overhed).
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. Only the OPES processor knows whether such messages
exist (because it has already sent them). The callout server does not
know (because it has not receive them yet).
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.
Messages without the [copied] flag set have to be sent back to the
OPES processor (which has to be done anyway...).
Yes.
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.
Or are you more concerned about messages that might be stuck in the
local queues at the OPES processor? But this seems to be more of a
local implementation issue...
I am concerned about messages without the [copied] flag that were
"sent" but has not been "processed" by the callout server yet. These
messages can be in TCP or application buffers on either side. The
above scheme avoids [I-will-always-copy] commitment to prevent
deadlocks. As a side effect, we can never be sure that all unprocessed
messages have [copied] flag. The scheme lets OPES processor inform the
server when it is safe to ignore unprocessed messages (if any). Again,
the processor knows whether there are any data chunks that were sent
to the server without copying and were not sent back.
I am not saying the above scheme is the best solution. It is just an
example that may inspire better schemes.
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.
Summary:
0) no [copied] flag does not allow for any optimizations
but is very simple
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
Thanks,
Alex.