[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: HTTP Proxy

"Michael K. Johnson" wrote:

> I expect that the hard part in the kernel would be finding the corner
> cases to push out to user space to handle, and trying to balance speed
> and complexity appropriately in the kernel.  Since Adam's cache is
> event-driven, it might be possible to design a TUX component to work with
> it as an accelerator; tux would take the connections and do anything it
> knew how in the kernel and pass off the hard stuff to Adam's cache to
> deal with.  Adam, I think that would mean making your main loop able to
> use tux() instead of poll() or using completion ports or whatever you
> are doing now as the source of your events.  I don't know whether that
> would fit into your design or not.  Does that make any sense to you?

I think so.  I'll have to look in a little more depth at exactly the
interface/events tux() provides.

The trick, I believe, will be in keeping the view of the universe 
held by any caching logic that gets pushed down in the kernel 
consistent with the view of the universe held by the userspace
implementation.  (f.e., if we hit a "common case" and cache a 
document in kernel logic, and microseconds later an "uncommon case"
request comes in that should produce the same content, how should
the kernel push its state up to userspace.)

>From an architectural standpoint, it should be pretty straight
forward to adapt my proxy logic to use tux() events instead of 
poll()... the hard question is how much knowledge goes where?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []