On 5/24/24 03:30, Wiebe Cazemier via openssl-users wrote:
Hi Matt,
----- Original Message -----
From: "Matt Caswell" <matt@xxxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Sent: Friday, 24 May, 2024 00:26:28
Subject: Re: Blocking on a non-blocking socket?
Not quite.
When you call SSL_read() it is because you are hoping to read
application data.
OpenSSL will go ahead and attempt to read a record from the socket. If
there is no data (and you are using a non-blocking socket), or only a
partial record available then the SSL_read() call will fail and indicate
SSL_ERROR_WANT_READ.
If a full record is available it will process it. If the record contains
application data then the SSL_read() call will return successfully and
provide the application data to the application.
If the record contains non-application data (i.e. some TLS protocol
message like a key update, or new session ticket) then, with
SSL_MODE_AUTO_RETRY on it will automatically try and read another record
(and the above process repeats).
Can you show me in the code where that is? It seems the callers of BIO_read() [1] are responsible for doing the retry, because the reader functions abort when retry is set. Those are many callers, for x509, evp, b64, etc. But, the code is kind of hard to trace, because it's all calls to bio_method_st.bread function pointers.
My main concern is, if it would get an EWOULDBLOCK, there is (almost) no sense in retrying
That's correct, but if I understand Matt correctly, this isn't the case.
The idea of SSL_MODE_AUTO_RETRY is that if there's data, but it isn't
application data but some kind of handshake data, then SSL_read doesn't
return (after handling the handshake data), but immediately retries.
If this retry fails with EWOULDBLOCK (or actually BIO_read returns 0),
then SSL_read returns with 0 and SSL_WANT_READ.
Without SSL_MODE_AUTO_RETRY SSL_read would return after handling the
handshake data with 0 and SSL_WANT_READ.
I'm not sure how useful this is, but this is how I understand Matt.
Detlef
