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 because in the 100 microseconds or so that passed, there is likely still no data. Plus, is there a limit on how often it's retried? If the connection is broken (packet loss, so nobody is aware) in the middle of rekeying, it can retry all it wants, but nothing will ever come. If it does that, then at some point, reads on the socket would fail with ETIMEDOUT, which is what I'm seeing. [1] https://github.com/openssl/openssl/blob/b9e084f139c53ce133e66aba2f523c680141c0e6/crypto/bio/bio_lib.c#L303
