Re: client-store interface

On Thu, 30 Oct 2003, Robert Collins wrote:

> > Merging of partial responses should (at least until we have a middle
> > layer, allowing forwarding between server/client without using the store)
> > be done into a new store object.
>
> I don't agree on this - but it's largely irrelevant at this point, as
> I've no short term plans for merging of ranges - when someone starts to
> work on this we can finalise the design.

Some reasons just scratching the surface:

 * read-ahead gap logics
 * store merge logics when there is multiple data feeds (different clients
requesting different not yet cached ranges)

> > * when a store client is initiated it must indicate if a ranged/partial
> > response is acceptable, and in such case what ranges it wants.
>
> This is sort of in place - the client simply asks for the ranges it
> wants, one at a time. The range metadata is passed through to http.cc,
> which then obtains those ranges or the full object as appropriate and as
> per policy.

Here we differ considerably.

What I propose is an API where the store dictates to the client what the
client gets. The client just gives the guidelines on what it wants at
start.

> The data ordering is only a SHOULD for multipart requests, it's a MUST
> for single-part requests.

Right, which is a special case of the non-ranged store client logics.

> Case 1:
> the upstream returns a partial response with invalid Range metadata -
> the range request (such as -50) cannot be normalised for whatever
> reason.

If the response is invalid we should either pass the response as is (if
composed as a valid HTTP message and compatible with the request) or an
error.

If/when we start doing merging of partial responses then there will be
situations where such invalid responses is not compatible with the
request.

> Case 2:
> the upstream returns multi-part data and we parse it. The order doesn't
> match what we requested (which is valid).
> Our request for specific bytes in the store may end up deadlocking:
> - if the object isn't cached.
> - the data we need to send isn't inside the readahead gap.
> - the memory flush algorithm is aware of non lowest-highest retrieval
> patterns.
> then we will never read the bytes the client needs.

this is indeed a problem, and is why I say it is the store who should tell
the client what the client gets.

However, special care needs to be considered in the cases where the
request does not allow for a multi-part response. I don't really see any
other option than to make sure the forwarded request does not allow for
multi-part responses unless the original request allows for such
responses.

Doing downgrading from multi-part to single-part responses will always be
open to corner cases of this type.

> Case 3:
> the upstream response isn't actually compatible with what the client
> requested - and ETag violation. Again, dealing with a buggy server, we
> should pass through the data or display an error.

In this case we should pass throught the data if possible, and discard the
response. Only in cases where the response is incompatible with the
request due to modifications applied by Squid (i.e. Squid initiated range
request to fill in an incomplete object etc) should an error be returned
in this case.

> The notification approach (combined with a couple of query methods that
> already exist) allows the client side to examine the memory store as
> data arrives, rather than needing to know which data is going to arrive
> next.

Which basically is the same thing that I propose, but from a different
angle.

> > ** Partial object cached. Normal request **
> >
> > Partial cache miss. Request forwarded but with a reference to the partial
> > object given to server-side.
>
> .. Not done, still on the drawing board. Note that If-Range must be used
> here by the server side.

Of course.

merging or partial responses is always subject to strict ETag checks in a
shared cache. This implies both If-Range to hint to the upstream and a
strict ETag verification on the responses.

> Effectively, we have this. It's a little baroque and could be improved.

I need to read up a little on the Squid-3 design it seems. Been to much in
2.5 lately..

If we really have this then this whole discussion is a bit upside down as
the store should in such case not need to care about any of this (except
the ability to store sparse data). Most the issues discussed here should
such case be in the Client-side<->forward/broker<->Server-side API chain,
not the store client interface.

Regards
Henrik
Received on Wed Oct 29 2003 - 18:25:29 MST