<div dir="ltr"><div><div><div>Hello Mark<br></div>I have been working recently on <a href="https://github.com/deleisha/evt">evt</a>, which is still in WIP, exposing a callback based async API's on top of libssl.<br><br></div>The idea was to abstract libssl with well defined APIs that can be integrated with libraries like libevent and libuv.<br><br></div>Thought It might be of interest to libevent.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 7, 2015 at 7:35 PM, Mark Ellzey <span dir="ltr"><<a href="mailto:ellzey@strcpy.net" target="_blank">ellzey@strcpy.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">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. <br><br>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.<br><br>I will spend some time with the proposed patches here, and see if I can make libevent happy, and hopefully very less complex.<br><br>Fingers crossed. Cheers!</div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 7, 2015 at 6:43 AM Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 07/10/15 14:29, Viktor Dukhovni wrote:<br>
> On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote:<br>
><br>
>> I have also added async support to s_server and s_client through the new<br>
>> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an<br>
>> effect you will obviously also need an async engine (such as dasync)<br>
>> loaded through the "-engine" flag. Note that dasync will only be loaded<br>
>> dynamically and thus OpenSSL must be built "shared" for this to work.<br>
>><br>
>> Documentation including some example code is available on all of this here:<br>
>> <a href="https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod" rel="noreferrer" target="_blank">https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod</a><br>
>> <a href="https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod" rel="noreferrer" target="_blank">https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod</a><br>
>> <a href="https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod" rel="noreferrer" target="_blank">https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod</a><br>
>> <a href="https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod" rel="noreferrer" target="_blank">https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod</a><br>
>><br>
>> I'd be interested to hear your thoughts.<br>
><br>
> Will existing applications doing non-blocking I/O with OpenSSL need<br>
> to be modified to handle SSL_ERROR_WANT_ASYNC?  Or does that happen<br>
> only if they explicitly request "async mode"?<br>
<br>
No, they should not need to be modified. You will only get<br>
SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC.<br>
<br>
><br>
> Should applications generally enable async mode because that might<br>
> be beneficial down the road?  Or is this just for exotic hardware<br>
> not likely to be seen in most environments?<br>
<br>
It will only be helpful if you have an engine capable of supporting<br>
async. I can't really answer the question because I don't know how<br>
common this will be. My hope is that this will become relatively common.<br>
I have been toying with the idea of creating a multi-threaded async<br>
engine where the engine manages a pool of threads to offload async work<br>
to which would then offer true async support even if you don't have<br>
specialist hardware.<br>
<br>
> For example, should Postfix enable "async" support?  It does timed<br>
> non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}.<br>
<br>
If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is<br>
not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I<br>
would encourage making the changes. You may want to consider making it a<br>
configurable option. There is a small overhead with creating ASYNC_JOBs<br>
and context switching into them when they start and finish.<br>
<br>
Matt<br>
<br>
_______________________________________________<br>
openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>Warm Regards<br>--Dev<br>OpenPegasus Developer<br><br>"I'm one of those people that think Thomas Edison and the light bulb 
changed the world more than Karl Marx ever did,” Steve Jobs<br></div></div></div>
</div>