Return-Path: 
 <dev-return-4777-apmail-apr-dev-archive=apr.apache.org@apr.apache.org>
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 97736 invoked by uid 500); 8 Nov 2001 21:33:16 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:dev@apr.apache.org>
List-Help: <mailto:dev-help@apr.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@apr.apache.org>
List-Subscribe: <mailto:dev-subscribe@apr.apache.org>
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 97725 invoked from network); 8 Nov 2001 21:33:15 -0000
Message-ID: <00b501c1689d$22318770$ba271b09@sashimi>
From: "Bill Stoddard" <bill@wstoddard.com>
To: <rbb@covalent.net>, "APR Development List" <dev@apr.apache.org>
References: <01aa01c1686a$9d144d20$0d381b09@sashimi>
 <20011108193852.5B37E46DFD@koj.rkbloom.net>
 <005601c16893$f5cd7ad0$ba271b09@sashimi>
 <20011108212439.4329246DFD@koj.rkbloom.net>
Subject: Re: [PATCH] APR Socket IOL
Date: Thu, 8 Nov 2001 16:34:20 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


> On Thursday 08 November 2001 12:28 pm, Bill Stoddard wrote:
> > > On Thursday 08 November 2001 07:32 am, Bill Stoddard wrote:
> > <snip>
> >
> > > > Comments?
> > >
> > > What is this supposed to be used for?  I'm still not sure that this is
> > > necessary.
> >
> > 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.

Bill