[openssl-dev] Adding async support

[Mark Ellzey]

As a maintainer of libevent, and spending heaps of time in the ssl
abstractions, anything to remove all the insane things you must do now for
async io would be a reprieve of the horrors we've dealt with over the
years.

I do worry that these patches may take too much of the work away to the
point of no decent control mechanism. When I see poll() everywhere, it
throws up red flags.

I will spend some time with the proposed patches here, and see if I can
make libevent happy, and hopefully very less complex.

Fingers crossed. Cheers!

On Wed, Oct 7, 2015 at 6:43 AM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 07/10/15 14:29, Viktor Dukhovni wrote:
> > On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote:
> >
> >> I have also added async support to s_server and s_client through the new
> >> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an
> >> effect you will obviously also need an async engine (such as dasync)
> >> loaded through the "-engine" flag. Note that dasync will only be loaded
> >> dynamically and thus OpenSSL must be built "shared" for this to work.
> >>
> >> Documentation including some example code is available on all of this
> here:
> >>
> https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod
> >>
> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod
> >>
> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod
> >>
> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod
> >>
> >> I'd be interested to hear your thoughts.
> >
> > Will existing applications doing non-blocking I/O with OpenSSL need
> > to be modified to handle SSL_ERROR_WANT_ASYNC?  Or does that happen
> > only if they explicitly request "async mode"?
>
> No, they should not need to be modified. You will only get
> SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC.
>
> >
> > Should applications generally enable async mode because that might
> > be beneficial down the road?  Or is this just for exotic hardware
> > not likely to be seen in most environments?
>
> It will only be helpful if you have an engine capable of supporting
> async. I can't really answer the question because I don't know how
> common this will be. My hope is that this will become relatively common.
> I have been toying with the idea of creating a multi-threaded async
> engine where the engine manages a pool of threads to offload async work
> to which would then offer true async support even if you don't have
> specialist hardware.
>
> > For example, should Postfix enable "async" support?  It does timed
> > non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}.
>
> If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is
> not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I
> would encourage making the changes. You may want to consider making it a
> configurable option. There is a small overhead with creating ASYNC_JOBs
> and context switching into them when they start and finish.
>
> Matt
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151007/398cb0be/attachment-0001.html>