On Wed, 26 Nov 2008 12:25:52 -0900 Chris Robertson <crobertson@xxxxxxx> wrote: > Perhaps it's because Squid is a HTTP caching server, as spelled out > quite clearly in the FAQ > (http://wiki.squid-cache.org/SquidFaq/AboutSquid), not a generic > bandwidth shaper. Squid may be your only route to the internet, or you may not want to configure NAT just to access one imap server. You may want to use squid's acls to control access. There are many good reason for wanting to do this. The faq isn't a religious document, you wont go to hell for trying to use squid creatively, or get any credit for being rude to heretics. > Perhaps in this case it was due to the sheer persistence of the > original requester. Six different people told julian that Squid is > not capable of handling the IMAP protocol[1] in response to five > separate email messages He actually only asked once, and he wrote once explaining why he wanted to do it; the other posts where in response to Amos's answer "configure all the mail clients to use a HTTP proxy and wrap the requests into HTTP first". Thunderbird has an http proxy setting that's right next to the socks proxy setting. Thunderbird can connect to IMAP via a socks proxy, but not via an http proxy CONNECT. This juxtaposition is a little confusing IMO. The multiple posts saying it's impossible were labouring the point that squid can't directly proxy the IMAP protocol. > If you want to throttle random traffic traversing your internet > connection, there are free applications that work in Windows, tc on > Linux, and pf under BSD. You mean altq or dummynet, pf is a firewall. > If you are willing to spend a little cash, > there are any number of appliance vendors and software consultants > who would be happy to help you. How would that third-party app co-ordinate its traffic shaping with squid's? And if you are already using delay pools for 99% of your traffic why waste money and effort on an unsatisfactory solution for the remaining 1%? Note that I wrote "download bandwidth". Most bandwidth-shaping software works at the IP level and so is only good at shaping packets going into a connection, not coming out. Squid shapes traffic over TCP so it's very effective and efficient at shaping downloads. I'll give you a concrete example of why it might be desirable to put all tcp through delay pools. My ADSL connection is a bit slow and usually saturates on downloading large files. That results in poorer latency with which altq cannot help. Setting up a delay pool that runs at 85% of maximum is a good solution to this, ordinary browsing operates well below that on average, but on heavy downloading the bucket empties after a few seconds causing rate-limiting and restoring decent round-trip times. The problem with this is that additional incoming packets outside of squid's control can use-up the reserved bandwidth. I did seriously think of putting additional tcp traffic through squid myself, but decided not to bother since the worst offender in my case is bittorent, and there's little I can do about that.
