apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PROPOSAL/PATCH] add ssl sockets
Date Sat, 17 Jun 2006 02:13:58 GMT
Jeff Trawick 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.

Only one question.  If we are back to BUFF filtering from Apache 1.3, can
we at least go back to history and look at why it was replaced by filtering?
(Or would lurkers care to speak up?)

Let's at least not add this performance hit where it isn't needed, and leave
apr_socket_read/write alone.  More that I think about it, an apr_io_XXX() API
for any application that prefers more abstraction would be a win, all around.

 > OTOH, with more and more levels of indirection for function pointers and data 
 > you start to wonder if there is a noticeable performance hit.

Isn't that why apr_sms_ was dumped?

David said this well (can't recall between here and IRC) - ssl read/write looks
'alot' like socket read write.  Almost.  An apr_io_ abstraction layer could deal
with the fact that not everything that can be read/write/poll'ed behaves quite
the same, and not incur that hit for explicit file, pipe, socket IO if the exact
IO methods are sufficient.

If all of our objects can be accessed naked, or with an apr_io_ layer, I think
any performance objections are moot.  Performance geeks will use raw apr_file_,
apr_socket_, apr_ssl_socket_, apr_whatever.  Those who want flexibility over
speed can use apr_io_.  I think it would work out well for both communities.


Mime
View raw message