Re: OPES protocol, pre-draft

On Mon, 17 Mar 2003, Alex Rousskov wrote:

>       We probably need a "sticky" [copied] flag meaning "I am going
> to have a copy of every byte from now on, until further notice".
> This way the callout server can remove itself from the loop earlier.
The "until further notice" part is a stupid idea, of course. Since the
callout server cannot see messages still in the [TCP] pipe, it would
never not be possible for the server to remove itself from the loop --
the server cannot guarantee that one of the still-unprocessed
data-have messages was not sent with the "notice: now I am not
copying!"  flag.

Once declared, the copying commitment has to be persistent for the
life of the data stream. What we need to support loop cuts is a
[copying-all] flag/state.  Once that application message flag is sent,
all further data messages MUST have a [copied] flag.

Sorry for not thinking this through well enough on the first try.
Hopefully there are no bugs in the revised version above.

Alex.


> On Sun, 16 Mar 2003, Markus Hofmann wrote:
>
> > Please apologize my late reply, but this just came to mind when
> > catching-up with all the emails after coming back from vacation and
> > reading through them for a second time on the plane...
> >
> >
> > Martin Stecher wrote:
> > > Example 2:
> > > Callout server analyzes beginning of application message and detects
> > > that it is not interested in this app. message:
> > >
> > > A. Traditional approach, ICAP/1.0 like with multiple preview
> > >     0. C: Start of app. message 1
> > >     1. C: Here is preview chunk 1
> > >     2.                                S: Need another preview chunk
> > >     3. C: Here is preview chunk 2
> > >     4.                                S: Not interested (204 resp.)
> > >     5. C: Start of app. message 2
> > >
> > > B. Proposed OPES protocol
> > >     0. C: Start of app. message 1
> > >     1. C: Chunk 1 of data             S: Start of app. message 1
> > >     2. C: Chunk 2 of data
> > >     3. C: Chunk 3 of data             S: Not interested
> > >     4. C: Chunk 4 of data
> > >     5. C: Start of app. message 2
> > >
> > > In this case B sent more data and data chunks 3 and 4 will be ignored
> > > by the callout server.
> > This might be obvious, but please allow me to add the following for
> > clarification only... Chunks 3 and 4 can only be ignored (i.e.
> > discarded) by the callout server if the OPES processor has sent them
> > with the [copied] flag set in the respective <data-have amid offset
> > size [copied]> message(s). If the [copied] flag was not set, the
> > callout server must not ignore chunk 3 and 4, but simply copy/send
> > them back to the OPES processor. Obviously, this can be done without
> > further processing (i.e. servicing), but they still need to be sent
> > back, since the OPES processor might no longer have a copy of these
> > chunks. Note, that this is true even if chunks 1 and 2 were sent with
> > the [copied] flag set.
> >
> > Thanks,
> >    Markus