On Monday 12 November 2001 11:15 pm, [EMAIL PROTECTED] wrote:
> rbb 01/11/12 23:15:36
>
> Modified: include http_connection.h
> server connection.c core.c
> server/mpm/prefork prefork.c
> Log:
> This allows modules to add socket descriptors to the pollset. I have
> only added this to the perfork MPM, and the others work without it.
> Tomorrow I will add it to the other MPMs.
This is the second to last patch of mine to abstract out the network logic.
The final patch will come tomorrow, and it will allow modules to take over
the accept call itself. The basic flow is simple for any module that wants to
use a non-socket transport layer:
add_listener Adds a listener to the poll set
accept_connection Accepts connection on socket
create_connection Create the conn_rec, and add the appropriate filters/
cleanups.
input/output filter Use the correct mechanism for reading the request
and writing the response. The underlying descriptor
(ie, socket, SSL type, etc) is not stored in any core
structures, it must be passed in to the filter when it is
added.
The core server will handle ALL Berkeley sockets TCP/IP communication.
Any other type of transport layer will need to be implemented by the
module that wants it. That could be an MPM, or a connection to a cache,
etc.
The only MPM that doesn't fit perfectly into the model described above is the
current Windows MPM. I have already designed the solution to the problem
in my head, I just need to write the code, but before I can do that, I need to
finish the Unix side. Before anybody gets scared, the Windows MPM that
uses this model will be 100% functionally equivalent to the current Windows
MPM.
I have a few small worries about this model, when it comes to platforms that I
don't know well, like OS/2. However, I just looked at the apr_portable.h
header file, and it should work like a charm, since all platforms except for
Windows use an integer for their sockets. I am assuming that any library
that implements a transport medium for Windows will use a type that can
be converted to a SOCKET.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
