Subject: RE: OCP Core version head_sid8 available

From: "Martin Stecher" <[email-masked]>
Date: Fri, 30 May 2003 11:59:04 +0200

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.

- 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.

- 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

Option 2: Add a new message. Will work but may be a waste of messages.

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.

Regards
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 30 May 2003 14:49:08 -0600 (MDT)

On Fri, 30 May 2003, Martin Stecher wrote:

> 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

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.