Re: Storing of information

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sun, 12 Feb 2012 03:59:25 +1300

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