Re: cvs commit: httpd-2.0/server protocol.c

[fi...@ebuilt.com]

>   Move the keepalives field out of the conn_rec and into an HTTP specific
>   connection record.  This also moves some HTTP specific back out of the
>   core and into the HTTP module.

-1.  First, as I said at the hackathon, these variables are not specific
to HTTP.  They record and control limitations on the number of requests
per connection.  You can change their names, if you want, but they must
be in the connection record for all protocols.

There are no limitations on requests per connection defined by HTTP.
It is a common tool to avoid denial-of-service (or, more accurately,
enforce fairness-of-service) at the application-layer.

Second, you should never move code and change code in the same commit.

Third, I see no reason to make the Apache httpd code base generic to
all protocols.  If done at all, this work belongs in a different tree.
I understand why it would be nice to have a multiprotocol routing core,
but the current code base is nowhere near efficient enough to support
such a change, certainly not without some justification from real users
that need such a beast.  We need to concentrate on getting it that way
for at least SSL and HTTP.

One of the things that needs to be kept in mind when building a
multi-protocol server is that while many protocols carry the same
elements, the applications that they support may have extremely
different performance profiles.  A server architecture has to be designed
according to the application profile, not the syntax of the protocol that
carries it.  Pools, for example, are not efficient enough to handle a
long-lived stateful exchange -- a memory structure for that needs to
be able to reclaim within the session.  There are many other cases where
the core will have to change radically in order to support those
applications.  Those changes should be proven separate from the 2.0
server before they are inserted in a code base that doesn't even remotely
need them.

Finally, is it really necessary to do this while I am in Maui?

....Roy

Re: cvs commit: httpd-2.0/server protocol.c

[Bill Stoddard <bi...@wstoddard.com>]

Thank you Roy...

> >   Move the keepalives field out of the conn_rec and into an HTTP specific
> >   connection record.  This also moves some HTTP specific back out of the
> >   core and into the HTTP module.
>
> -1.  First, as I said at the hackathon, these variables are not specific
> to HTTP.

<snip>

>
> Third, I see no reason to make the Apache httpd code base generic to
> all protocols.
> If done at all, this work belongs in a different tree.
> I understand why it would be nice to have a multiprotocol routing core,
> but the current code base is nowhere near efficient enough to support
> such a change, certainly not without some justification from real users
> that need such a beast.  We need to concentrate on getting it that way
> for at least SSL and HTTP.

I've been having these thoughts as well.  Building a multiprotocol routing core is interesting but
for now our efforts should be focused on getting a servicable HTTP Server. We are diluting our
efforts spending time "adhoc'ing" the server to accomodate protocols other than HTTP.

>
> One of the things that needs to be kept in mind when building a
> multi-protocol server is that while many protocols carry the same
> elements, the applications that they support may have extremely
> different performance profiles.
> A server architecture has to be designed
> according to the application profile, not the syntax of the protocol that
> carries it.

I agree.  FWIW, I attend an interesting presentation inside IBM over a year ago about porting the
Lotus Notes server to Linux.  There were some serious performance issues that had to be handled in
designing the Notes server. Based on the performance requirements of that application, the Apache
2.0 framework would not come close to doing what is needed.  Apache 2.0 cannot become all things to
all people.  Let's focus our efforts on Apache 2.0 being an excellent HTTP server, like Apache 1.3.

Bill

Re: cvs commit: httpd-2.0/server protocol.c

[fi...@ebuilt.com]

> OK, I was not at the HACKATON, but 'keepalive' is an HTTP
> specific protocol mechanism. If not, please refer me to some
> protocol that uses it?? :-))

keepalive as a name is used in many protocols, including TCP.  The specific
function of those two variables is used by ANY server that places a limit
on requests per connection.  It is not even remotely specific to HTTP.
The only Internet app protocol that I know of which would not use such a
limit is TELNET.

> With respect to moving HTTP specific variables out of the core
> I would follow my above statement. But as I understood
> keepalive is maybe HTTP protocol specific it is to much spread
> over Apache core code which makes the move difficult.
> 
> Although, naming is not a real issue in my opinion.
> Would it not be an option to name it like 'keepconnection'??
> That means other protocols (and thus their module implementing it)
> that expect multiple requests over the same connection. However,
> this would extends the semantics a bit. Even though, you keep
> it as keepalive for HTTP.

As I said, the name can be changed, though I'll repeat that "Keep Alive"
is the common generic term for keeping a connection open for more than
one request. It is not HTTP specific.  The only thing HTTP specific about
that code is the comments above the variable.

> > There are no limitations on requests per connection defined by HTTP.
> > It is a common tool to avoid denial-of-service (or, more accurately,
> > enforce fairness-of-service) at the application-layer.
> 
> I am not sure what you mean here. Is "Limit" not designed for this??
> Or do you think of other limitation functionality??
> 
> > Third, I see no reason to make the Apache httpd code base generic to
> > all protocols.  If done at all, this work belongs in a different tree.
> 
> Roy, but why are there now claims made Apache is capable of doing
> multiple protocols. I envision that protocol module would only
> make use of "ap_hook_process_connection" like mod_echo does.
> For the rest it does whatever it wants itself.

There are claims of it being multiprotocol because that was of the original
design goals that Robert Thau had for 2.0.  By multiprotocol, he meant
HTTP and HTTPng (the original binary HTTP over SCP spec by Simon).
Multiprotocol does not mean every protocol under the sun.

> > I understand why it would be nice to have a multiprotocol routing core,
> > but the current code base is nowhere near efficient enough to support
> > such a change, certainly not without some justification from real users
> > that need such a beast.  We need to concentrate on getting it that way
> > for at least SSL and HTTP.
> 
> Would it not be possible that there are no users, since there is
> nothing (multiprotocol Apache) to use?? :-)))

No.  A server is supposed to be simple.  The only reason to have multiple
protocols within a single server is if you have multiple potential
protocols on the same port.  That is why SSL, HTTP, HTTPng, SOAP, and
waka are all candidates for a multi-protocol httpd, whereas FTP and IMAP
and BXXP are not.  That doesn't mean that someone can't use the Apache
software to create servers that handle those other protocols -- it only
means that the code doesn't belong in httpd.

I have no objections to starting a sandbox for a multiprotocol framework
that, once it proves to be better, can be adopted by the httpd project.
But it doesn't make any sense to do that in httpd-2.0, just as it didn't
make any sense to create APR within the main development tree.

....Roy

Re: cvs commit: httpd-2.0/server protocol.c

[Bill Stoddard <bi...@wstoddard.com>]

>
> > There are no limitations on requests per connection defined by HTTP.
> > It is a common tool to avoid denial-of-service (or, more accurately,
> > enforce fairness-of-service) at the application-layer.
>
> I am not sure what you mean here. Is "Limit" not designed for this??
> Or do you think of other limitation functionality??

Nothing in the HTTP protocol spec puts a limit on the number of HTTP request/response pairs that can
flow over a connection.  Well implemented HTTP Servers allow the sys admin to impose a limit on the
number of requests the server will server on a connection (e.g., MaxKeepAliveRequests).  Why?  To
keep a client (browser) from hogging all the resources at the server. In other words, to give all
clients 'fair' access to the server resources.

>
> > Third, I see no reason to make the Apache httpd code base generic to
> > all protocols.  If done at all, this work belongs in a different tree.
>
> Roy, but why are there now claims made Apache is capable of doing
> multiple protocols.

That's hardly an argument to support multiprotocol routing...
> > I understand why it would be nice to have a multiprotocol routing core,
> > but the current code base is nowhere near efficient enough to support
> > such a change, certainly not without some justification from real users
> > that need such a beast.  We need to concentrate on getting it that way
> > for at least SSL and HTTP.
>
> WOuld it not be possible that there are no users, since there is
> nothing (multiprotocol Apache) to use?? :-)))

Build it and they will come?  Not a good business model IMHO, but it sometimes works in movies :-)

Seriously, have you any hard requirements from any application that is 1/100th as important as the
HTTP Server?  Our primary "customers" are HTTP server users. Let's make them happy first and quite
trying to solve all the network server problems of the world, else we'll end up doing everything
half assed.

Bill

Re: cvs commit: httpd-2.0/server protocol.c

[Harrie Hazewinkel <ha...@covalent.net>]

Bill Stoddard wrote:
> >
> 
> The protocol Lotus Notes uses is keepalive (yea, it is a proprietary protocol and may not count in
> this discussion).

Yes, that may. As a protocol guru I am probably not allowed to see the
protocol definition?? :-))


>  Doesn't BXXP (is that what it is called now?) maintain persistent connections? 

BEEP as it is now called. My understanding of BEEP is that it just
keeps the connection open like FTP when it is mapped upon TCP.
That is not really keep-alive as defined in HTTP.

> I
> know of more obscure proprietary protocols that flow multiple requests/response pairs over a
> persistent connection.

OK, keep-alive could indeed be more generic. I never really thought
of proprietary protocols.

Harrie
-- 
phone: +39-3474932300
http://www.lisanza.net/

Re: cvs commit: httpd-2.0/server protocol.c

[Bill Stoddard <bi...@wstoddard.com>]

> Roy,
>
> fielding@ebuilt.com wrote:
> >
> > >   Move the keepalives field out of the conn_rec and into an HTTP specific
> > >   connection record.  This also moves some HTTP specific back out of the
> > >   core and into the HTTP module.
> >
> > -1.  First, as I said at the hackathon, these variables are not specific
> > to HTTP.  They record and control limitations on the number of requests
> > per connection.  You can change their names, if you want, but they must
> > be in the connection record for all protocols.
>
> OK, I was not at the HACKATON, but 'keepalive' is an HTTP
> specific protocol mechanism. If not, please refer me to some
> protocol that uses it?? :-))
>

The protocol Lotus Notes uses is keepalive (yea, it is a proprietary protocol and may not count in
this discussion).  Doesn't BXXP (is that what it is called now?) maintain persistent connections?  I
know of more obscure proprietary protocols that flow multiple requests/response pairs over a
persistent connection.

Bill

Re: cvs commit: httpd-2.0/server protocol.c

[Harrie Hazewinkel <ha...@covalent.net>]

Roy,

fielding@ebuilt.com wrote:
> 
> >   Move the keepalives field out of the conn_rec and into an HTTP specific
> >   connection record.  This also moves some HTTP specific back out of the
> >   core and into the HTTP module.
> 
> -1.  First, as I said at the hackathon, these variables are not specific
> to HTTP.  They record and control limitations on the number of requests
> per connection.  You can change their names, if you want, but they must
> be in the connection record for all protocols.

OK, I was not at the HACKATON, but 'keepalive' is an HTTP
specific protocol mechanism. If not, please refer me to some
protocol that uses it?? :-))

With respect to moving HTTP specific variables out of the core
I would follow my above statement. But as I understood
keepalive is maybe HTTP protocol specific it is to much spread
over Apache core code which makes the move difficult.

Although, naming is not a real issue in my opinion.
Would it not be an option to name it like 'keepconnection'??
That means other protocols (and thus their module implementing it)
that expect multiple requests over the same connection. However,
this would extends the semantics a bit. Even though, you keep
it as keepalive for HTTP.

> There are no limitations on requests per connection defined by HTTP.
> It is a common tool to avoid denial-of-service (or, more accurately,
> enforce fairness-of-service) at the application-layer.

I am not sure what you mean here. Is "Limit" not designed for this??
Or do you think of other limitation functionality??

> Third, I see no reason to make the Apache httpd code base generic to
> all protocols.  If done at all, this work belongs in a different tree.

Roy, but why are there now claims made Apache is capable of doing
multiple protocols. I envision that protocol module would only
make use of "ap_hook_process_connection" like mod_echo does.
For the rest it does whatever it wants itself.

> I understand why it would be nice to have a multiprotocol routing core,
> but the current code base is nowhere near efficient enough to support
> such a change, certainly not without some justification from real users
> that need such a beast.  We need to concentrate on getting it that way
> for at least SSL and HTTP.

WOuld it not be possible that there are no users, since there is
nothing (multiprotocol Apache) to use?? :-)))

> 
> One of the things that needs to be kept in mind when building a
> multi-protocol server is that while many protocols carry the same
> elements, the applications that they support may have extremely
> different performance profiles.  A server architecture has to be designed
> according to the application profile, not the syntax of the protocol that
> carries it.  Pools, for example, are not efficient enough to handle a
> long-lived stateful exchange -- a memory structure for that needs to
> be able to reclaim within the session.  There are many other cases where
> the core will have to change radically in order to support those
> applications.  Those changes should be proven separate from the 2.0
> server before they are inserted in a code base that doesn't even remotely
> need them.

I agree here that an implementation is in most cases design for a
perticular performance profile and protocol profile. With respect
to the multi-protocol document, Ryan and I did not envision that our
solution would fit all protocols ever existing/used. We envisioned
with a more commone framework fopr multiple protocols faster protocol
module development and more code re-use (for instance, making use of
the same authentication functions already implemented for HTTP).

> 
> Finally, is it really necessary to do this while I am in Maui?

Enjoy Maui!! (Not to be mistaken with, now you are gone we will....
:-)))))

Cheers,

Harrie
-- 
phone: +39-3474932300
http://www.lisanza.net/