Re: Proxy code size.

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Fri, 13 Aug 1999 01:11:51 +0200

James A. Donald wrote:
>
> Reading through the email archives I am forming a conjecture about the
> alarmingly large size of caching proxies:

In the case of Squid the size of the code is not as much dependent it
being a proxy as it is on the lifetime of the project. New functions or
features are constantly being added, and new improved methods for
dealing with internal data structures is added from time to time.

A quick estimate of how much of the Squid code is actually related to
request processing and disk storage gives a round figure at about 10K
lines.

If you make a new codebase from ground up then I would estimate a base
caching HTTP proxy to require quite a bit less lines of code.

> My conjecture is:
> A caching proxy attempts to be transparent,
> which means it must simulate the internet as a whole.
> In general this cannot be done, and there is no short
> finite set of rules that if followed will yield
> an acceptable simulation.

I wouldn't say a proxy attemtps to be transparent. Most users using a
proxy will know they are, regardless if they have configured the use
themselves or it is being enforced upon them.

Also there exists a category of proxies which deliberately is not trying
to be transparent: Recoding proxies, for example proxies doing automatic
conversation of images to lower resolutions and similar stuff.
 
> The writer of a caching proxy encounters an unending stream
> of unforeseen and unexpected cases, which he must deal with
> as best he can, with the result that the code of a caching
> proxy tends to grow without limit.

The unforseen or unexpected cases rarely adds a lot to the code size,
unless you are including including protocol changes (as in HTTP/1.0 ->
HTTP/1.1 which is a major difference in code size), but those changes
are rarely unexpected, even if it may happen that a protocol revision
affects the base upon what you have built your software...

> Does this conjecture seem to describe the code growth that you have
> encountered?

Not exacly. The growth is primarily governed by other aspects. I see it
as a natural growth of a actively maintained piece of software which is
evolving and having new features added. The trend is the same regardless
of what kind of software you look at.

--
Henrik Nordström
Spare time Squid hacker
Received on Thu Aug 12 1999 - 16:58:32 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:48:01 MST