I agree and will fix the current wording to imply "AME". The following
TE will have a "normal" 200 code.
However, please note that "I want out of the loop" has a transaction
scope, not application message scope. It is not possible to continue
the transaction once the server is out of the loop.
Proof by contradiction: If it were an application message-scoped
mechanism it would be possible to get one application message out of
the loop while still processing remaining application messages within
the same transaction as usual. The latter is only possible for
profiles that support multiple adapted AMs per single original AM
(e.g., SMTP). To support such a mode, the processor would have to
maintain at least two original data flows: one short-circuited due to
Want-Out and one to feed remaining adapted flows. That is probably too
much complexity and goes way beyond the current "one transaction, one
original data flow" approach.
Correct.
But in future we may have a message that could be sent between AME and TE,
maybe a message with which the OPES processor informs the callout service
about the shutdown procedure on the application message size.
In this case the callout server wants to get out of the loop for the
application
message but keeps the transaction alive until it receives the additional
meta info.
Therefore, as we already ageed upon, put the result code to AME and we are
better prepared for future extensions.
Should the callout server confirm by sending also a special (the
same 206) result code?
Yes, I believe so. Both agents send AMEs/206 and TE/200. If the
callout server sends AME/200, it means the adapted application message
should stop at that point instead of being continued from the original
data flow (i.e, once processor gets AME/200, the loop is over).
Agreed.
In other words, "I want out of the loop" does not mean "I am not going
to adapt starting now". Imagine a situation where an overloaded
non-essential service wants to get out of the loop, but does not mind
keeping adaptation algorithms alive (or cannot disable them) and those
algorithms decide to terminate the message "early" for reasons
unrelated to the overload condition.
If you agree with the rationale, I should document the above caveat.
There are three normal cases for transaction termination. We may
want to discuss this together in one section of OCP core and define
result codes for all three. What do you think?
1. Complete application message is sent to callout server and
terminated with AME 200, callout server returns a complete message
and also ends with AME 200.
2. At some time callout server decides to only echo the rest of the
message. It sends a Want-Out message, echos all data until it
receives an AME 206 and then responds also with an AME 206.
3. The callout server sends a response (e.g. an error message for
the client). Sending is done before complete application message has
been received. The callout server will send its AME message and by
design does not longer care about DUM/DUY messages being transferred
for this transaction. OPES processor can stop sending the
application data when it sees the AME message. It will terminate the
transaction.
In #3, the server will terminate the transaction first: it will send
TE right after AME.
For SMTP maybe not immediatly. See below.
We should also have a special 2xx result for this case, I think.
Could you explain why a special 2xx result would be needed for #3?
To ease statistics collection? Requests, responses,
and short-circuiting is application specific. Do you propose to add
a special status code to HTTP Adaptations draft?
For HTTP this special code is not needed for direct functionality but for
better statisticy and debugging possibilities:
If the OPES processor wants to count for cases #3 a special result code
will even count then for the case in which both AMEs are sent
simultaniously.
If in a debugging session someone checks the data sent by the OPES
processor (not seeing the data sent by the callout server), he may wonder
that
an application message is not sent completly.
A result code other than 200 with the AME message, will help to understand
why.
For other application protocols, such as SMTP, the special code sent by the
callout service can even make functional sense.
A service may want to send several error messages, all not longer depending
on
the rest of the application data, to multiple recipient and therefore it
will send
several application messages. By indicating with the first AME that the OPES
processor can stop sending more application data it helps to increase
performance.
This case will be different from an error message which is sent in the first
application message but another application message which builds on the
complete
original message will follow; in that case, the callout server will send a
result 200
with the first AME.
If you agree in all this, I would prefer to have some general status codes
for the
three cases in OCP core.
Note, that in cases 1 and 2 the OPES processor sends the AME message
first
and in case 3 it's the callout server sending AME first.
Of course beside these three cases there are other scenarios, but I
think they all deal with transaction terminations due to error
conditions.
If I have time, I will enumerate the above scenarios in a informative
(non-normative) way.
I have a related question: Do you think a callout server may send AME
if it thinks that the message is completed (e.g., the original body
has been received and processed, and no trailers are expected)? Or
should the server wait for AME from the processor before sending its
own AME, under normal conditions? In other words, do we want to
support concurrent close optimization OR do we want to allow for
larger-than-expected messages to be adapted successfully? In yet other
words, what does constitute application message end (AME from the
other agent only OR that and some other information like AM-EL)?
Simulatanious AMEs are possible as you discribe but I would like to
discourage their usage.
Implementations that want to have max performance can probably add
the AME and TE messages to the same TCP frame that contains the
last DUM in most cases (unless the few bytes for AME/TE do not fit).
In this case we have no extra waiting after the last DUM message has
been received and there is no need for clever counting which may sometimes
lead to problems.
The length of an application message SHOULD only be determined by the
length of the DUM message's payload (and the DUY message's size param)
and terminated by the AME message. AM-EL values are important for better
HTTP adaption but they SHOULD NOT be used for message length counting
for OCP purposes, IMO.
Regards
Martin