On Mon, 15 Nov 2010 11:29:31 -0800, RM <bearmeat@xxxxxxxxx> wrote: > Hi Amos, > > It was my understanding that my quick_abort settings would do the > exact opposite. The manual states the following: > > "If you do not want any retrieval to continue after the client has > aborted, set both 'quick_abort_min' and 'quick_abort_max' to '0 KB'." > > I did however play around with both of these settings changing them to > '1 KB' and '100 KB' and the client is still able to transfer at > 5Mbps+. > > I am almost certain the client is not tech savvy enough to perform any > of the described tricky behavior. > > Any other suggestions would greatly be appreciated! > Okay, may be knowledgeable enough to use a downloader that does fancy things. The only other thing I can think of that would get around that config is if the client is using IPv6 to connect to you (thus outside that IPv4 "all" definition). Which is not supported in 2.6. I'm afraid you are going to have to do some deep traffic analysis and find out what the heck is being sent to/from Squid. Amos > Thanks again, > Ron M. > > On Mon, Nov 15, 2010 at 5:40 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> > wrote: >> On 15/11/10 20:05, RM wrote: >>> >>> Hello all, >>> >>> I am running Squid Cache: Version 2.6.STABLE21 on CentOS 5.5 and have >>> been using delay pools to limit clients' bandwidth usage. Here is the >>> delay pool section and related ACL of the squid.conf file. I have >>> included the entire squid.conf at the end of the message: >>> >>> acl all src 0.0.0.0/0.0.0.0 >>> delay_pools 1 >>> delay_class 1 1 >>> #1Mbps >>> delay_parameters 1 131072/131072 >>> delay_access 1 allow all >>> >>> I have used the above delay pool configuration countless times >>> previously and I did not have any issue but for some reason there is a >>> client that is able to bypass the delay pool bandwidth restriction and >>> transfter at rates of 5Mbps+. >>> >>> Any help would greatly be appreciated. >>> >>> Thanks in advance! >>> >>> Ron M. >>> >> >> More likely that those requests are ones where the client actualy >> disconnected. Your quick_abort setting configure Squid to keep going >> after a >> disconnect. This happens outside the pooling since there is no client to >> pool. >> >> It *might* be a client doing some tricky request behaviour. You could >> pick >> this up by a) these requests are *all* MISS requests (indicating >> only-of-cached header preventing slow network access), or b) these >> requests >> following an earlier request within a very short time (indicating a leach >> re-attachment once the above pool detachment has been done by Squid). >> >> Amos >> -- >> Please be using >> ÂCurrent Stable Squid 2.7.STABLE9 or 3.1.9 >> ÂBeta testers wanted for 3.2.0.3 >>
