Roy,
[EMAIL PROTECTED] 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/
