httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Korthof>
Subject Re: MUX and AJPv2 (was: HTTP-NG)
Date Wed, 11 Feb 1998 07:54:46 GMT
On Tue, 10 Feb 1998, Daniel Veillard wrote:
> > I might have elaborated.  Indeed, MUX was "too much overhead for what we
> > needed" but that was not considered a bad thing about MUX, just a technical
> > analysis of our project's needs.
>   Ok, however MUX isn't that complex (unless you really got an old spec ...
> sorry this should have been linked from the public pages), what did you find
> superfluous/overhead. Obviously, the main problem is flow control.

We may well have seen an old spec -- but the basic issues addressed by MUX
are different from those we need to address w/ the JServ protocol. 

MUX is (IMO, of course) designed to provide a generalized client-server
communications model for heterogeneous clients and servers spread out
across a WAN.  JServ's protocol only needs to deal with a single type of
information exchange, being clients and servers which we're designing (ie.
we have complete control over both), and will generally be over a fast

I can't seem to find the specification anymore, or I'd attempt to offer
specific points which would add to the required processing but which
wouldn't be useful for us.
> > We ended up accepting some influences from MUX and defined a protocol that
> > has multiplexed Apache JServ sessions on a single pipe.  It's now available
> > online in its interim form - we are currently doing implementation
> > experiments so the spec states it's still subject to revision:
> > 
> >    "Apache JServ Protocol Version 2 (AJPv2)"
> >
>  Question, would MUX had been available in the Apache core  (i.e. on the 
> monothreaded client side), would you have moved to this specialized design
> anyway? Was the implementation complexity the main reason to not implement
> a generic multiplexing + a specific protocol on top of it ? I have the feeling
> that on the server-side (java) the implementation complexity wouldn't have
> been that bigger (due to threading, since it simplifies the coding).

That would depend on what you mean by available in the core.  We'd still
need to do nearly as much work regardless of how this was organized, and
building MUX into Apache as a way to talk with clients would mean we were
basically paying the cost of a proxy connection or more.  It could easily
complicate our lives even more than the current model. 

It'd also depend on the current state of MUX, and the amount of time
required to build a sufficiently functional MUX server on the Java side
(as well as related efficiency considerations). 

My main concern in this is that I want to build a high efficiency protocol
for communicating the relevant information -- I want JServ to be
competitive with similar products in terms of speed.  I think MUX rocks
for what it does, but again, I don't think it addresses the problem we're
trying to solve.

     -- Ed Korthof        |  Web Server Engineer --
     --    |  Organic Online, Inc --
     -- (415) 278-5676    |  Fax: (415) 284-6891 --

View raw message