Wie wird mit OpenSSL SSL_ERROR_WANT_READ / WANT_WRITE auf nicht blockierenden Sockets umgegangen?

Die OpenSSL-Bibliothek ermöglicht das Lesen von einem zugrunde liegenden Socket mit SSL_read und das Schreiben mit SSL_write. Diese Funktionen werden möglicherweise mit SSL_ERROR_WANT_READ oder SSL_ERROR_WANT_WRITE zurückgegeben, je nach den Anforderungen des SSL-Protokolls (z. B. beim erneuten Aushandeln einer Verbindung).

Ich verstehe nicht wirklich, was die API von mir mit diesen Ergebnissen erwartet.

Imaging einer Server-App, die Client-Verbindungen akzeptiert, eine neue SSL-Sitzung einrichtet, den zugrunde liegenden Socket nicht blockiert und dann den Filedescriptor zu einer select / poll / epoll-Schleife hinzufügt.

Wenn ein Client Daten sendet, sendet die Hauptschleife diese an ssl_read. Was ist hier zu tun, wenn SSL_ERROR_WANT_READ oder SSL_ERROR_WANT_WRITE zurückgegeben wird? WANT_READ könnte einfach sein, da die nächste Iteration der Hauptschleife nur zu einem anderen ssl_read führen könnte. Aber wenn ssl_read WANT_WRITE zurückgibt, mit welchen Parametern sollte es aufgerufen werden? Und warum gibt die Bibliothek den Aufruf nicht selbst aus?

Wenn der Server einem Client Daten senden möchte, verwendet er ssl_write. Was ist erneut zu tun, wenn WANT_READ oder WANT_WRITE zurückgegeben werden? Kann das WANT_WRITE beantwortet werden, indem derselbe Aufruf wiederholt wird, der gerade aufgerufen wurde? Und wenn WANT_READ zurückgegeben wird, sollte man dann zur Hauptschleife zurückkehren und das select / poll / epoll dafür sorgen lassen? Aber was ist mit der Nachricht, die an erster Stelle geschrieben werden sollte?

Oder sollte das Lesen direkt nach dem fehlgeschlagenen Schreiben erfolgen? Was schützt dann davor, dass Bytes aus dem Anwendungsprotokoll gelesen werden und sich irgendwo außerhalb der App damit befassen müssen, wenn der echte Parser im Mainloop sitzt?

Antworten auf die Frage(6)

Ihre Antwort auf die Frage