On 02/11/2012 12:57 AM, Pieter De Wit wrote: > <snip> >> I like the idea of pushing it off into ICAP. That does being up the >> problem that things like auth loops, errors and related self-DoS >> events are omitted from the quota counts. Also tunnels are adapted >> only for the HTTP headers portion, once they get to the blind-tunnel >> parts its direct byte shuffling between two TCP sockets. >> > <snip> >> In squid it would have to be a AsyncJob to start with, since the >> memory spaces are still too much twisted together to add threading >> cleanly. When that is working, splitting process or thread away may be >> an option for improving over the Job. >> > Scrap that idea then :) > > From my limited playing with the ICAP protocol, what would be the short > comings ? I looked at RESPMOD mode, which seems to be "Respond Mode", as > in, modify the response. I can't see the short fall here, it had the > length and all that ?
ICAP is not ideal for implementing control points other than at the beginning of messages. It would be awkward and performance-expensive to use ICAP for quota control if you want to change things in the middle of a transaction. ICAP also lacks proactive notifications from the ICAP server to Squid, which would be nice for certain quota operations. Compared to ICAP, eCAP has a much lower performance overhead, but has a similar beginning-of-message design limitation. If you want to do this using loadable modules, we could discuss extending eCAP, but I am not sure it is the best approach. I recommend considering reshaping client_db code to work with shared memory so that it can work correctly in SMP mode. I do not think that would be very difficult to do and it would be immediately useful. Once that is done, you can add a control message queue and use external processes to manage the quota database as needed. This design would minimize performance impact while allowing for any external quote management programs to co-exist with Squid. HTH, Alex.
