From: Christos Tsantilas Date: Mon, 25 Oct 2010 18:25:19 +0000 (+0300) Subject: Author: Alex Rousskov X-Git-Tag: take1~143 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b4cd430a2d6dcd470e61f39deee6cab0681b74a6;p=thirdparty%2Fsquid.git Author: Alex Rousskov Client-side bandwidth limit (a.k.a., quota or delay pool) implementation. In mobile environments, Squid may need to limit Squid-to-client bandwidth available to individual users, identified by their IP addresses. The IP address pool can be as large as a /10 IPv4 network (4 million unique IP addresses) and even larger in IPv6 environments. On the other hand, the code should support thousands of connections coming from a single IP (e.g., a child proxy). The implementation is based on storing bandwidth-related "bucket" information in the existing "client database" hash (client_db.cc). The old code already assigned each client IP a single ClientInfo object, which satisfies the client-side IP-based bandwidth pooling requirements. The old hash size is increased to support up to 32K concurrent clients if needed. Client-side pools are configured similarly to server-side ones, but there is only one pool class. See client_delay_pools, client_delay_initial_bucket_level, client_delay_parameters, and client_delay_access in squid.conf. The client_delay_access matches the client with delay parameters. It does not pool clients from different IP addresses together. Special care is taken to provide fair distribution of bandwidth among clients sharing the same bucket (i.e., clients coming from the same IP address). Multiple same-IP clients competing for bandwidth are queued using FIFO algorithm. If a bucket becomes empty, the first client among those sharing the bucket is delayed by 1 second before it can attempt to receive more response data from Squid. This delay may need to be lowered in high-bandwidth environments. This feature has been documented at http://wiki.squid-cache.org/Features/ClientBandwidthLimit --- diff --git a/doc/release-notes/release-3.3.sgml b/doc/release-notes/release-3.3.sgml index 0f4f158e9b..6e2c26914d 100644 --- a/doc/release-notes/release-3.3.sgml +++ b/doc/release-notes/release-3.3.sgml @@ -34,14 +34,40 @@ The 3.3 change history can be Client-side pools are configured similarly to server-side ones, but there is + only one pool class. See client_delay_pools, + client_delay_initial_bucket_level, client_delay_parameters, and + client_delay_access in squid.conf. The client_delay_access matches the client + with delay parameters. It does not pool clients from different IP addresses + together. +

+ Special care is taken to provide fair distribution of bandwidth among clients + sharing the same bucket (i.e., clients coming from the same IP address). + Multiple same-IP clients competing for bandwidth are queued using FIFO + algorithm. If a bucket becomes empty, the first client among those sharing + the bucket is delayed by 1 second before it can attempt to receive more + response data from Squid. This delay may need to be lowered in + high-bandwidth environments. Changes to squid.conf since Squid-3.2

@@ -59,7 +85,22 @@ This section gives a thorough account of those changes in three categories: New tags

- + client_delay_pools +

New setting for client bandwith limits to specifies the number + of client delay pools used. + + client_delay_initial_bucket_level +

New setting for client bandwith limits to determine the initial + bucket size as a percentage of max_bucket_size from + client_delay_parameters. + + client_delay_parameters +

New setting for client bandwith limits to configures client-side + bandwidth limits. + + client_delay_access +

New setting for client bandwith limits to determines the + client-side delay pool for the request. Changes to existing tags