Re: [squid-users] dansguardian as a patch for Squid

----- Original Message -----
From: "Alex Rousskov" <rousskov@measurement-factory.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-users@squid-cache.org>
Sent: Monday, June 25, 2001 11:53 PM
Subject: RE: [squid-users] dansguardian as a patch for Squid

> Robert,
>
> iCAP seems to gain popularity these days; Squid is likely to
> end up supporting it, eventually. Would it be possible to use iCAP for
> both external modules and internal, compiled-in modules? I think that
> iCAP is transport-layer independent so we could just pass the request
> information to internal modules using function calls as opposed to
> sockets that have to be used for external stuff.

OPES is working on the rule language defining when processing will be
used. They've come up with a proxylet term to refer to in-server (aka
in-process or closely tied to the process) processors, and are still
fighting about whether to just adopt i-CAP as the transport layer of
choice, or not :]. AFAIK from the opesproxy list, i-CAP is not a
contender for in-server processing. It's targeted at letting proxies
access centralised virus scanners, or ad inserters access a
ad-serving-dedicated machine. I.E. to increase the scale-out aspect of
certain services.

i-CAP is a transport layer in the sense that HTTP is a transport layer.
So yes, one could use an internal buffer passing scenario, and force
each internal module to [re]parse the i-CAP headers, and the HTTP
headers and the do the processing. A clever library interface that
handled all the i-CAP stuff could optimise away that overhead internally
I guess.

> If the above is feasible, one could write code that can be
> used both as a stand alone program and as a compiled-in module, with
> 95% of the code and logic being exactly the same. Moreover, we could
> provide a simple ICAP library that completely masks the distinction
> (i.e., transport layer becomes the responsibility of a library).

Thats a nice idea. Hmm. There are some complications that would need
addressing: there are limits on fork() vs threaded vs select loop style
for in-process code, but that doesn't apply for out-of-process code.
Likewise configuration parameters for the service that is being accessed
via i-CAP requires a parser (squid has one) and logging needs
addressing. And the above mentioned potential cpu overhead.

I suspect all those can be worked through... but you may well end up
with such a tight design requirements list that
it's better to just write <item foo> tightly integrated into squid and
remove the i-CAP overhead.

Having said that, it may well be worth the time to write such a set of
libraries _anyway_ as that will serve to further clarify the squid
internals. (I have a nearly-libriased(sic) parser.) Also, a module can
always be written that implements your suggestion, in addition to having
the "squid only" API for squid-specific projects.

> Just a thought...

Very astute one.

Rob

> Alex.
>
> On Mon, 25 Jun 2001, Robert Collins wrote:
>
> > This shouldn't wait - getting agreement/consensus on the
> > architecture for this in squid is quite important. Feedback from
> > folk like you as to how it works, what you need, what you'd like
> > etc is also very important. A couple of hours from you looking at
> > this could save a lot of time alter.
> >
> > Well i-CAP isn't linux specific. I do most of my squid hacking on
> > openBSD|MS Windows :].
> >
> > http://www.i-cap.org/
> > http://www.checkpoint.com/cvpopenspec/CVPOpenSpecification.pdf
> >
> > The archives have a description of what I've done, separate from
what
> > i-CAP is. i-CAP defines a protocol for accessing things like content
> > filters/virus scanners from a proxy. I've written a set of hooks for
> > squid, and a hook API that allow direct access to what squid is
doing
> > for in-process content processors - so my doco is the relvant bit
:].
> > (And it's in the archives - but I couldn't dig it up on a quick
search
> > :-/). So I've included a synopsis of what it does/can do at the end
of
> > this email.
>
>
Received on Mon Jun 25 2001 - 08:07:36 MDT