On 11/02/2012 8:57 p.m., 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 ?
* the parsing bottleneck gets crunched several times: on first arrival,
in the ICAP server, and on return to Squid,
* the ICAP server bypass optimization can't be used since quote needs to
measure every byte,
* tunneled data does not get sent to ICAP services,
Not exactly perfect service, but it offers the most complete quota
control without adding complexity to Squid.
eCAP might be a slightly better. It sill runs inside Squid and has some
processing overhead, but should reduce the parse problems and network
delays involved with ICAP.
Points to reading URL's are more than welcome, also, so is examples of
libicapapi :)
Hopefully someone else knows some then, because I dont :(
Amos
