Then the condition is that a stream is opened in copy mode by the OPES
processor and the callout server needs to signal "copy mode on this
stream will cease."
If the underlying transport is reliable, like TCP, there's no problem
if you adopt the rule that acked data on a copied stream MUST be
copied by the callout server and un-acked data cannot be deleted by the
OPES processor.
If the underlying transport is not reliable, then I submit that the decision
has already been made that it is OK to lose some data. In that case, there's
no need to have strong commitments - some data might be lost in a transition,
but that's OK.
We need to be careful not to reinvent things already solved at the
transport layer.
Hilarie
On Tue, 25 Mar 2003 at 07:27:17 -0700 (MST) Alex Rousskov sent this missive:
> What's the compelling reason for message by message copy directives?
The reason for per-message [copied] flag is to optimize for the common
case where callout server does not modify the data. OPES processor
will often keep a copy anyway, for many reasons. There is no need to
send the same data back and forth; one direction is enough in this
case.
The reasons for copying commitment or a similar mechanism is to
optimize for the common case where the callout server wants to get out
of the loop because it does not expect any/further modifications.
Alex.