ietf-openproxy
[Top] [All Lists]

Re: copying commitment and deadlock

2003-03-25 10:59:06

On Tue, 25 Mar 2003, The Purple Streak, Hilarie Orman wrote:

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

Yes, but this simple scheme may lead to a deadlock (which is the
subject of this thread, see below for more info).

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.

I am not sure I understand exactly what you are saying (what is acked
data?), but transport protocol does not solve the higher-level
problems we are discussing here. There are two different problems:

The first problem is about OPES processor deleting its copy of the
data (previously marked with a [copied] OCP flag). Here are some of
the related issues:

        - When a copy of the data can be deleted (explicit
          notification by callout server, implicit order-based
          guess, other)? We have to keep in mind that the
          callout server does not care about processor
          buffering problems so there is a "conflict of interests"
          here.

        - Do we want to support reordering of copied data by the
          callout processor?

        - Granularity of <data-as-is> messages (can callout server
          refer to something other than the exact same data chunk
          sent by the OPES processor? Do we want to support partial
          as-is messages?)


The second problem is that a "stream opened in copy mode" may lead to
a deadlock when the OPES processor is waiting for more buffer space
and, hence, is not sending more data to the callout server, and the
callout server is waiting for more data from the OPES processor to
make a modification decision and, hence, is not returning any messages
back, keeping processor buffers full. Again, transport protocol
(reliable or not) does not solve this deadlock. It is a higher-level
problem that is related to OPES processor buffers for copied messages,
not transport.

Hope this clarifies,

Alex.


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.


<Prev in Thread] Current Thread [Next in Thread>