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 -
