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

Re: Can tux 'proxy' for the user space daemon?



Hi,

> Ingo Molnar <mingo@elte.hu> writes:
> 
> > On 6 Oct 2000, Joe Schaefer wrote:
> > 
> > > Is TUX capable of maintaining keepalives on the browser <-> TUX
> > > connection, while maintaining a separate "pool" of (closed) TUX <->
> > > apache connections?
> > 
> > if TUX sees a request that is redirected to Apache, then all remaining
> > requests on the connection are redirected to Apache as well. TUX wont ever
> > see that connection again, the redirection works by 'trimming' all
> > previous input up to the request which goes to Apache, then the socket
> > itself is hung into Apache's listen socket, as if it came as a unique
> > request from the browser. This technique is completely transparent both to
> > Apache and to the browser. There is no mechanizm to 'bounce back' a
> > connection from Apache to TUX. (while connections do get bounced back and
> > forth between the kernel and user-space TUX modules.)
> > 
> > so eg. if the first 2 request within a single persistent HTTP/1.1
> > connection can be handled by TUX then it will be handled by TUX, and the
> > third (and all succeeding) requests will be redirected to Apache. Logging
> > will happen by TUX for the first 2 requests, and the remaining requests
> > will be logged by Apache.
> > 
> > 	Ingo
> 
> Too bad- this means that HTTP/1.1 pages generated by an apache module won't 
> benefit from TUX serving the images and stylesheet links contained therein. I 
> guess disabling keepalives on the apache connection is (still) the only way 
> to go.
> 
> I still think it would be cool if there was some hack to make this work- 
> perhaps a TUX "gateway" module could do it?  Instead of handing off a 
> request directly to apache, maybe a (user-space) TUX module could hand it 
> off and then return control back to TUX when the page has been delivered.
> Is such a "gateway" TUX module viable?

Would it make sense to let dynamic content run under a different
(sub)domain? For example, tux listens at www.domain.org with an apache
'behind' it, and dynamic.domain.org with only an apache at port 80. A
dynamic page can let the images it contains, be fetched from
www.domain.org so tux will still be used for static content.
It seemes to me that this causes all static content to be served by tux
(even when a dynamic page is served by apache), while dynamic content
goes via apache which can still benefit from keepalives. True?

	Ookhoi





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