apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david reid <da...@jetnet.co.uk>
Subject Re: [PROPOSAL/PATCH] add ssl sockets
Date Fri, 16 Jun 2006 11:23:44 GMT
Jeff Trawick wrote:
> On 6/14/06, Jeff Trawick <trawick@gmail.com> wrote:
>> On 6/13/06, david reid <david@jetnet.co.uk> wrote:
>> > The attached patch is a first pass at getting some support for using
>> > openssl directly for ssl sockets within APR. I've tried to be
>> generic in
>> > the basic configure code, but the actaul guts are basically openssl
>> related.
>>
>> What about an I/O layering system for sockets?  This is in essence the
>> set of function pointers used by the one true sockets API to call out
>> to the details, as mentioned in other posts.

I would really worry about the performance for such a system. It also
smacks of "httpd"izing APR :-(

That said, if people feel it's the way to go I'm in no position to stand
in their way...

> 
> FWLIW, I have a patch for a layering system on top of apr 0.9 (I'm
> pretty sure it has been posted here before, but I can't find it at the
> moment.)
> 
> The "push" function requires an existing socket, so it doesn't allow a
> layering system to allow access to the APR socket API for something
> that doesn't have a real APR socket.
> 
> APR_DECLARE(apr_status_t) apr_socket_iol_push(apr_socket_iol_t **newiol,
>                                              apr_socket_t *sock,
>                                              apr_socket_iol_t *iol,
>                                              const char *name);
> 
> name is some string associated with the layer, like "TRACER" or "SSLIO".
> 
> apr_socket_iol_t is the table of function pointers and chaining.  Note
> that an I/O layer shouldn't have to care how APR chains these together
> or tracks the name of the layer.  OTOH, with more and more levels of
> indirection for function pointers and data you start to wonder if
> there is a noticeable performance hit.
> 
> struct apr_socket_iol_t
> {
>    struct apr_socket_iol_t      *next;
>    const char                   *name;
>    apr_shutdown_fn_t             iol_socket_shutdown;
>    apr_socket_close_fn_t         iol_socket_close;
>    apr_bind_fn_t                 iol_socket_bind;
>    apr_listen_fn_t               iol_socket_listen;
> ... /* enumerate through the rest of the API */
>    /* in practice it hasn't been cool to have APIs like
>     * sendfile as an optional member; if you add sendfile
>     * support for a platform, the I/O layer implementations
>     * are one more piece which have to be recompiled
>     */
> #if APR_HAS_SENDFILE
>    apr_sendfile_fn_t             iol_socket_sendfile;
> #endif /* APR_HAS_SENDFILE */
>    ...
> };


Mime
View raw message