Re: Requests, replies, HTTP messages.
On Mon, Mar 19, 2007, Alex Rousskov wrote: > On Sat, 2007-03-17 at 19:33 +0800, Adrian Chadd wrote: > > http://wiki.squid-cache.org/RequestQueues > > > > Just thinking about how to handle processing HTTP requests, replies and > > HTTP messages after my initial storework modifications. This stuff would > > lead itself to look like "clientstreams" but with all the messages > > abstracted out. It'd make it much easier to stuff processing in the middle. > > IIRC, we have discussed similar ideas at the dawn of Squid3. I still > believe that the "post the request and have the Request Resolution > Engine orchestrate the next processing step" design has its merits. > However, do you really think that implementing such a huge change is now > practical? Its not something that I'm slating to put into squid-2 or squid-3 in their current forms. I'll prototype it a whole lot more before I decide to build something in the existing codebase. I've also posted possible client and server flows, ie: http://wiki.squid-cache.org/NewClientSide http://wiki.squid-cache.org/NewServerSide Adrian
Re: Requests, replies, HTTP messages.
On Sat, 2007-03-17 at 19:33 +0800, Adrian Chadd wrote: > http://wiki.squid-cache.org/RequestQueues > > Just thinking about how to handle processing HTTP requests, replies and > HTTP messages after my initial storework modifications. This stuff would > lead itself to look like "clientstreams" but with all the messages > abstracted out. It'd make it much easier to stuff processing in the middle. IIRC, we have discussed similar ideas at the dawn of Squid3. I still believe that the "post the request and have the Request Resolution Engine orchestrate the next processing step" design has its merits. However, do you really think that implementing such a huge change is now practical? Alex.
Requests, replies, HTTP messages.
http://wiki.squid-cache.org/RequestQueues Just thinking about how to handle processing HTTP requests, replies and HTTP messages after my initial storework modifications. This stuff would lead itself to look like "clientstreams" but with all the messages abstracted out. It'd make it much easier to stuff processing in the middle. This sort of thing should be implemented with threading in mind. There's well-understood producer/consumer lockless queue implementations available for single thread reader/single thread writer situations which leads itself to this kind of thing. Comments? Adrian
