Re: squid rewrite

Well, piggy-backing includes things as delayed-abort... I
agree that piggy-backing from new clients (physical clients)
is perhaps not that important, but delayed-abort is, so that
the client that initiates a fetch can abort, and then resume
the same request (for example following a link on a loading
page, and then go back). I think that we should try to keep
this feature. (I don't think persistant connections will
solve this one..)

And I fully agree that shared mem / semaphores are not needed,
unless we go for a heavy amount of IPC (for example having
disk I/O daemons).

Other reasons is that the store manager has to have full
responcibility of store management, so each frontend has
to ask the store manager where to store. It is not possible
to use a design where the frontends blindly writes infromation
(in a scratch-directory) and then tells the store manager to
move it in place, since the data might be spread across
any number of partitions of different size which the frontends
should know nothing about.

The piggy-back part in the store manager is actually very
simple. The hard parts are in the fronends, but most of
the needed code is there anyway (proxying) and it should
be possible to re-use it for inter-frontend transfers.
It does not add additional requirements, and should not
affect portability in any way.

---
Henrik Nordstr=F6m
Stewart Forster wrote:
 =
> My solution restricts piggy-backing to within the TCP
> front-ends alone.
> The backend won't know about it (and probably shouldn't).
> If the TCP front-ends are serving 1000's of connections
> each, a little bit of double-fetch isn't going to hurt.
> It's a 99.9% solution, and perhaps the easiest and thus
> most efficient to implement.  What's the point of going
> to all the extra complexity to save perhaps .01% of your
> total traffic?  We want a clean solution that's portable,
> not a porting/management nightmare.
> Why are shared mem/semaphores needed?  If we remove locking to
> within each proc, this whole mess is avoided.