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
Received on Sat Feb 11 2012 - 14:59:32 MST
This archive was generated by hypermail 2.2.0 : Sun Feb 12 2012 - 12:00:11 MST