ietf-openproxy
[Top] [All Lists]

OCP: Getting Out Of The Loop optimization broken

2003-10-24 22:51:37

Hi,

        I used to think that Wont-Use parameter is sufficient for a
callout server to get out of the loop safely. I now believe that it is
not true because Wont-Use can be used to tell the processor that
original data is no longer needed, but it does not tell the processor
that the service is not going to _generate_ more adapted data. I tried
to fix this logic in the new OCP Core section, quoted below.

Please see it I am still missing something important or if the
interface can be simplified again:


8. 'Out Of The Loop' Optimization

   Many services are applicable to a small percentage of application
   messages and yet have to see the beginning of every application
   message to decide on applicability (e.g., services that adapt based
   on declared or guessed MIME type). Many services adapt application
   message "headers" or "prefix" only and are not interested in the
   remaining parts of an application message (e.g., URL blocking and ad
   insertion services). 'Getting Out Of The Loop' optimization allows a
   callout server to get out of application message processing loop when
   the server is confident that it does not need to see remaining data.

   Two conditions are necessary for the callout server to get out of the
   loop nicely:

   No adaptation need: The callout server must finish its primary work.
      It should sent all adapted data to the processor and should
      require no more original data from the processor. Since
      adaptations and adaptation needs might not depend on original
      data, only the server can evaluate this condition.

   No copying need: The OPES processor must receive back all unpreserved
      data chunks that were sent to the callout server for adaptation.
      Note that data chunks that are not preserved and are not returned
      by the callout service would be lost. Since the server may not
      have seen all the original data sent, only the processor can
      evaluate this condition.

   Since no single agent can determine both conditions, the agents have
   to cooperate.  The service has to tell the processor when the first
   condition is true. This is done via the Want-Out message (XXX:
   document Want-Out). The processor has to tell the service that there
   are no pending unpreserved data chunks.  The latter is done by
   terminating the transaction with a 206 "Get Out" result (XXX:
   document 206). Between the above two conditions or messages, the
   callout server returns all original data unmodified back to the OPES
   processor, draining pending data queue (if any).


Thank you,

Alex.