httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harrie Hazewinkel <har...@covalent.net>
Subject Re: Apache 2.0 for multi protocol usage
Date Mon, 09 Apr 2001 11:30:37 GMT
David Williams wrote:
> 
> Hi Harrie,
> 
> I have only briefly looked through your multi protocol usage analysis.
> Thanks for driving this forward.  My main comments thus far are:
> 
> - Is the "state record" you have broken out primarily for authentication?
> There is a hint that it is for any long-lived protocol state, but that it
> must have a lifetime shorter than the connection.  It wasn't clear if a
> notes like structure would be used to extend the state record, or if it
> should be subclassed.

The split and creation of the additional state_rec was driven by
the pool lifetimes.

At the request-level:
If user information is stored at the request level, the pool
from which memory is allocated _CANNOT_ be free until all
the appropriate information from the request record is copied.
And if we don't want to do the copy, but just refence
it, the pool needs to exists during the complete connection.

At the connection level:
Since there are multiple sequential user able to login with the
FTP protocol, the connection information should each time be
changed. Even though, the pool could life longer one cannot
return/free a pool when a user does quit. The connection stays
open in the case of FTP.

The advantage of the 'state'-layer is that each level can have
its own pool lifetime.

Regarding the extension of the record in the specific layer, this
is done via an array that enables each module to store a pointer
to module specific data. RyanB and I name it 'state_config',
'request_config',.. This is similar to the 'server_config' approach.

> 
> - Apache doesn't support UDP or any non-TCP protocol very well.   This may
> have impact on the above "state record", since in the case of UDP it may
> have a lifetime longer than the connection, depending on the upper layer
> protocol and implementation.   e.g.  The concept of a complete application
> exchange over udp could involve many separate PDU exchanges, each using a
> new or different UDP connection.   UDP also impacts the design of apache, in
> that a sequence of related PDUs will be received by different child
> processes.

UDP is now supported via APR. Most protocols that use UDP put all
data in 1 packet. However, some UDP-based protocols use a sequencing
mechanism on top of UDP. This sequencing mechanism is typically
something
you should do in the state_config portion where the protocol module
which is handling the protocol. Take a look at the IMAP example. That
example
does not sequencing, but I mean the concept.

> 
> - Apache includes a shared memory library.   But apache-style pools are
> needed in shared memory, to facilitate placing things like the state record
> into shared memory when needed.  And being able use the ap_p* functions
> regardless of where the pool lives.
>



Mime
View raw message