Cómo manejar OpenSSL SSL_ERROR_WANT_READ / WANT_WRITE en sockets sin bloqueo

La biblioteca OpenSSL permite leer desde un socket subyacente con SSL_read y escribir con SSL_write. Estas funciones pueden regresar con SSL_ERROR_WANT_READ o SSL_ERROR_WANT_WRITE dependiendo de sus necesidades de protocolo SSL (por ejemplo, al renegociar una conexión).

Realmente no entiendo lo que la API quiere que haga con estos resultados.

La creación de imágenes de una aplicación de servidor que acepta conexiones de clientes, configura una nueva sesión SSL, hace que el socket subyacente no se bloquee y luego agrega el descriptor de archivo a un bucle select / poll / epoll.

Si un cliente envía datos, el bucle principal lo enviará a un ssl_read. ¿Qué se debe hacer aquí si se devuelve SSL_ERROR_WANT_READ o SSL_ERROR_WANT_WRITE? WANT_READ podría ser fácil, porque la siguiente iteración del bucle principal podría conducir a otro ssl_read. Pero si ssl_read devuelve WANT_WRITE, ¿con qué parámetros debería llamarse? ¿Y por qué la biblioteca no emite la llamada en sí?

Si el servidor quiere enviar algunos datos a un cliente, usará ssl_write. Nuevamente, ¿qué se debe hacer si se devuelven WANT_READ o WANT_WRITE? ¿Se puede responder el WANT_WRITE repitiendo la misma llamada que se acaba de invocar? Y si se devuelve WANT_READ, ¿debería uno volver al ciclo principal y dejar que select / poll / epoll se encargue de esto? Pero, ¿qué pasa con el mensaje que debería escribirse en primer lugar?

¿O debería hacerse la lectura justo después de la escritura fallida? Entonces, ¿qué protege contra la lectura de bytes del protocolo de la aplicación y luego tener que lidiar con él en algún lugar en las afueras de la aplicación, cuando el analizador real se encuentra en el bucle principal?

Respuestas a la pregunta(3)

Su respuesta a la pregunta