On Thursday 08 November 2001 01:34 pm, Bill Stoddard wrote:
> > > Sander and I both have similar requirements. Here are mine...
> > >
> > > 1. My SSL library implements socket style secure APIs (eg, secure_read,
> > > secure_write, et. al). These APIs are semantically identical to BSD
> > > socket APIs.
> > >
> > > 2. I have this little kernel accellerator that, on windows, implements
> > > it's own BSD like socket API. It implements calls like afpa_read,
> > > afpa_write, etc. Again, this API is semantically identical to BSD
> > > sockets.
> > >
> > > The socket IOL makes implementing my SSL and AFPA modules significantly
> > > cleaner. Without iol, I am forced to modify the APR code. For every
> > > network i/o call in APR, I need to add code that looks something like
> > > this:
> > >
> > > if (sock->type == AFPA_SOCK) {
> > > code;
> > > afpa_sock_blah()
> > > } else if (sock->type == SSL_SOCK) {
> > > code;
> > > ssl_sock_blah()
> > > }
> > > else
> > > {
> > > bsd_sock_blah()
> > > }
> > >
> > > With the socket IOL, I can isolate all my modules code within my module
> > > and not touch the rest of the server or APR. I think I may need a
> > > couple of additional APIs to push and pop IOL's. For instance, my SSL
> > > code uses BSD accept() (nothing new there). In the pre_connection hook,
> > > I can detect if the server is enabled for SSL and push the appropriate
> > > IOL onto the socket for all subsequent network io calls.
> >
> > All of this can be done with a new output_filter that does the writes.
> > That output filter would replace the core_output_filter. In fact, one of
> > the reasons that filters were designed they way they were, was to allow
> > for this type of thing to work. By creating the socket_IOL, you are just
> > creating a second way to do the same thing.
>
> What you are suggesting will not work at all. There are apr_socket(and
> related) calls in places other than the core_*_filters. And it is not safe
> to make these calls (which will call BSD socket network io system calls)
> using descriptors from a different network interface.
Then I would consider the filtering logic broken. If you can't replace the
underlying network types, then we need to move all of the network calls in
the core into new hooks, that can be bypassed if a different network mechanism
is required.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
