>> Check my original post (I'm copying it below). We're unhappy
>> with OpenSSL's support for nonblocking I/O on servers; currently,
>> it either wants you to rewrite your server to let OpenSSL handle
>> the network I/O, or use BIO pairs to let OpenSSL think it's doing
>> networking still. Neither alternative is appealing.
>
> The TLS/SSL protocols are designed to run on top of a network
> connection (surprise :-), so it's a rather obvious approach to have
> the API designed accordingly.
I'm currently writing a multi-platform webserver using openSSL and I do also
experience problems with the fact that the networking code is too tighty
integrated with openSSL. On a unix system this may seem like a non-issue,
but my adventures trying to get openssl running for both NT, MacOS and
MacOSX made me curse the networking layer quite often (f.i. there's no such
thing as a BSD-style network calling convention on standard Mac (yes, there
is one but I find this a wrong way to go, besides more code = more bugs)).
If openSSL would be more of a library that runs on top af a stream (any
stream, being network/stdin/whatever...) it will gain potential on more
obscure/less known/non-unix platforms.
But I'm sounding a bit too negative here: This library is a true masterpiece
and I want to send my sincere gratitude to it's developers, who I think are
doing a hell of a great job.
nick.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
