Re: 2.1.PRE1: Range requests far avay [new limit]

Alex Rousskov wrote:
 
> Requires a lot of changes, IMO. Store should be OK with one
> client fetching bytes 0-100, the second client fetching 300-400,
> and http.c fetching 150-200 and 175-250 (!) for the fourth and
< fifth clients. How are you going to store those on disk?
> You will have to support some kind of meta-table that
> describes the location of all ranges...

First, I do not care if there is two simultaneous clients. Both can be
handled separately with hopefully only a minor loss of bandwidth.

Merging should be done on each request to keep things simple.

First client requests 0-100. Stored

Second client requests 300-400. Range not available and thus it is
fetched from the origin server and merged with the previous request into
a object with ranges 0-100,300-400.

Third client requests 150-200. Also not available. Fetched and merged
into 0-100,150-200,300-400.

Fourth client requests 175-250. Ranges 175-199,201-250 fetched and
merged. Object is now 0-100,150-250,300-400.

Yes, changes are required to make the store aware of ranges. In core
meta data requires one additional flag that marks the object as valid
but incomplete. And perhaps the major part: Squid needs to be able to
extract ranges from a incomplete object.

There are at least two ways to do the merging. Either generate new a new
object based on the old and what's being fetched, or use sparse files
and update the on-disk object (also requires reserving space in the
header to be able to update it). My vote for the time beeing is
generating a new object. Sparse files is not supported on all
platforms/file systems.
Received on Tue Jul 29 2003 - 13:15:54 MDT