On Fri, 30 May 2003, Martin Stecher wrote:
Some thoughts regarding items on the to-do list:
- meta-trailer
Since we have the meta-have message, OCP core has a method to send
meta data after body data. I think application protocol binding has
to define whether meta-have messages are only allowed before
data-have messages or can also occur at the end to transfer message
trailers as meta data.
You are right. This to-do item was added before we had meta-have
approach. It is now obsolete and will be deleted. While we will no
longer have meta-have messages, it is still possible to transmit
metadata at any time, using data-have messages and
application-specific metadata encoding/rules.
- copied
OCP core should not artificially limit the usage of preserved data
while application protocol binding may of course define shorter
times to keep copied data. Some application protocol bindings may
benefit from allowing to refer to the original application message
start through data-as-is at the end of the application message in
the response. Some application protocol bindings will allow multiple
application messages in the response and a later message may want to
refer to the original message through data-as-is. So, I think, the
only limit OCP core can set is xaction-end.
I agree. I think we should add a data-wont-use message to OCP Core to
allow a simple way for a callout server to tell the processor that a
particular piece of copied data will not be used. Application bindings
may extend or just use this mechanism to do what is right for them.
The to-do item is now changed to
copy destruction: Add data-wont-use message. Document that an
OPES processor can destroy data copy when data-wont-use or
xaction-end message is received.
- break
Option 1: Reuse data-as-is and allow the character '*' as the size
parameter to indicate that the callout processor would like to use
data-as-is for all upcoming data-have messages or will send
identical data-have messages back if the "copied" flag is not set.
The OPES processor can use this information and stop sending further
data-have messages
Problems if the copied flag is not set. Callout server must continue
to send back all data-have messages that it receives after sending
the data-as-is message and OPES processors that do not support this
feature may be confused by the data-as-is message and stop with an
error due to unexpected data-as-is message
I do not like this because it overloads one message for two very
different purposes: optional copying optimization and breaking out of
the loop optimization. As you noted, this immediately created problems
when the processor does not support copying optimization.
Option 2: Add a new message. Will work but may be a waste of
messages.
I do not think we would be wasting any resources by adding a simple
message.
Option 3: Use the modp parameter. Callout processor can send the
value zero with modp and therefore commit to not modifying any
future data of that message. It should be safe for an OPES processor
to stop sending any other data-have message.
I do not like this because it overloads one parameter for two rather
different purposes: indication of no future modifications and breaking
out of the loop optimization. A simple example where such overloading
will not work is a logging or "passive analysis" callout service
(e.g., for an FBI/CIA/Echelon/whatever applications that become
mandatory in many countries). A passive service does not modify
anything but also does not want to get out of the loop!
Personally, I favor option 2. I think there was some discussion about
this already. Please see the noisy "copying commitment and deadlock"
thread around March 24th and 25th. Here is a gist of what seemed as a
good solution at that time:
- To get out of the loop early, a callout server
sends a i-want-out message to the processor
- To let a callout server out of the loop,
the processor must send xaction-end message
to the server
- A callout server cannot get out of the loop
nicely until it receives a xaction-end message
The above scheme is simple and deadlock free. Note that it does not
rely on processor supporting copying of data; there is no copying
commitment involved. The scheme is efficient unless there are a lot of
unprocessed messages buffered between the processor and the server. To
increase efficiency, a more complex scheme with priority communication
channels would be required (to bypass a long chain of unprocessed
messages).
Would you like us to proceed with this i-want-out/xaction-end scheme?
Do you favor any other option?
Thanks,
Alex.