On 10/8/2017 5:58 PM, Kyle Hamilton wrote:
Do you have a reference to what should be done instead?
My understanding of what happens with blocking sockets is that
SSL_read() will return SSL_ERROR_WANT_READ if it needs additional data
read from a socket that doesn't have it available (and will return
SSL_ERROR_WANT_WRITE if it needs to write for a handful of reasons,
but can't). I had thought that the appropriate response would be to
add that descriptor to the appropriate set to query on the next call
to select(), and then call the same function with the same parameters
so the library can advance its state machine.
write() and read() have the means to tell you how much data was
written or read, and that's what you're supposed to use to keep
blocking descriptors from hanging your application, I thought.
-Kyle H
With blocking sockets, you just loop back around and repeat the same
call if either of those messages are returned by SSL_get_error(). No
select() required.
Blocking operations will block (aka "hang") your application until the
operation completes. If you don't want that to happen, then that's what
non-blocking descriptors are for.
--
Thomas Hruska
Shining Light Productions
Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
