How to handle SSL_ERROR_WANT_ASYNC in libevent

[luwenpeng]

I want to integrate the ASYNC ssl features of openssl into libevent so that libevent supports qat. I encountered some problems in my work and would like to ask for your help.

The implementation process is as follows：

1. SSL_CTX_set_mode(SSL_MODE_ASYNC);
2. SSL_set_mode(SSL_MODE_ASYNC);
3. after tcp connect, get clientfd
4. event_add(clientfd, EV_READ|EV_WRITE, ssl_handshake);
5. When the client is readable / writable, run ssl_handshake.

    ssl_handshake()
    {
        SSL_do_handshake();
        err = SSL_get_error();
        if (err == SSL_ERROR_WANT_ASYNC)
        {
            event_del(clientfd, EV_READ);
            event_del(clientfd, EV_WRITE);

            call SSL_get_changed_async_fds() get async_fds

            // Register a readable event on asyncfd to detect when the engine is ready
            event_add(async_fds, READ, ssl_async_handshake);
        }
    }

6. When async_fds is readable, it means that the engine is ready. Run ssl_async_handshake, re-enable the clientfd read and write events, and continue the operation（next SSL_do_handshake)

    ssl_async_handshake()
    {
        event_add(clientfd, EV_READ, ssl_handshake);
        event_add(clientfd, EV_WRITE, ssl_handshake);
    }

Q1. Is there a problem with my process?

Q2. During the test, SSL_do_handshake will continue to return SSL_ERROR_WANT_ASYNC multiple times (exactly 9 times) before it succeeds. Is this normal?

Q3. The processing flow of SSL_read / SSL_write returning SSL_ERROR_WANT_ASYNC is similar to that of SSL_do_handshark, but SSL_read / SSL_write never returns SSL_ERROR_WANT_ASYNC during the test, is this a normal result? How can I test the processing flow of SSL_read / SSL_write returning SSL_ERROR_WANT_ASYNC？

[paulturx]

Hi Sorry for the delay in responding to this. In order to answer your questions I will need to reproduce - to that end could you please give me details of OS, QAT driver, QAT engine, etc., or else can I assume that it is essentially the same versions as in your issue #123?

[luwenpeng]

Yes, it's the same version as inissue #123