client-side delay pools

G'day,

One of the items in my commercial work queue is client-side delay pools.
The client wishes to restrict the throughput of certain items - hit or miss -
back to the client. They're currently using Squid-2.6.18 and are probably
going to upgrade to Squid-2.7 once its released.

I have a tentative plan, which is:

* include the client writing code into the delay pools logic, which shouldn't
  require all that much extra work as the 'pool' code doesn't care much what
  the FD is;
* include a "pool" id for the client-side connection, seperate from the server-side
  pool ID;
* enforce delay pools being either "server" or "client" for now - there's no reason
  they can't be shared, but I think it'd be easier to enforce each pool to be one
  or the other!
* add in ACL lookups for request and reply to map the client into a pool, with an
  optional "burst" delay in bytes or seconds (ie, client gets X bytes/seconds at
  full speed, then the connection gets dumped in the pool)

This is enough to test the idea.

The big thing is to implement at least a per-IP "pool" and quite potentially a
per-connection "pool". I envisage these will be trees of some sort, keyed on
the ipv4 (and later ipv6) + optional fd or src/dest port information restricting
the pool. These would be "class 5" and "class 6" pools, not to clash with
the "class 4" pool which Squid-3 has (and I haven't yet really looked at
integrating back to Squid-2.)

Comments?

Adrian

-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -