Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

On 08-10-17 22:55, Thomas J. Hruska wrote: > On 10/8/2017 7:28 AM, Michel wrote: >> While I understand that using non-blocking descriptors is a better >> practice, >> I still do not see why select() should NEVER be used for blocking sockets >> (except when combined/interfered with the internal

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

[...] > From that point, the only logical conclusion that can be drawn is that > select() is for non-blocking I/O only. [...] Ouahhh, it looks to me as an over-simplistic conclusion ! select() was not designed and written with future TLS state machine implementation in mind. But maybe I

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

On 10/9/2017 7:49 AM, Jakob Bohm wrote: On 09/10/2017 16:43, Thomas J. Hruska wrote: On 10/9/2017 7:29 AM, Jakob Bohm wrote: I suggest you find a good authoritative source for your claim that select() should not be used with blocking sockets.

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

? ;-). Anyway, thanks to have shared your opinion and advices with me. Regards, Michel. -Message d'origine- De : openssl-users [mailto:openssl-users-boun...@openssl.org] De la part de Thomas J. Hruska Envoyé : lundi 9 octobre 2017 15:32 À : openssl-users@openssl.org Objet : Re: [openssl-u

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

On 09/10/2017 16:43, Thomas J. Hruska wrote: On 10/9/2017 7:29 AM, Jakob Bohm wrote: I suggest you find a good authoritative source for your claim that select() should not be used with blocking sockets. http://man7.org/linux/man-pages/man2/select.2.html Section BUGS: "Under Linux, select()

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

On 10/9/2017 7:29 AM, Jakob Bohm wrote: I suggest you find a good authoritative source for your claim that select() should not be used with blocking sockets. http://man7.org/linux/man-pages/man2/select.2.html Section BUGS: "Under Linux, select() may report a socket file descriptor as "ready

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

On 09/10/2017 15:31, Thomas J. Hruska wrote: On 10/9/2017 1:32 AM, Michel wrote: 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. Yes, you have to repeat the same call, but select() is

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

On 10/9/2017 1:32 AM, Michel wrote: 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. Yes, you have to repeat the same call, but select() is still usefull, especially with blocking

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

> 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. Yes, you have to repeat the same call, but select() is still usefull, especially with blocking sockets. Regards, Michel. --

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

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

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

Important caveat: SSL_read() and SSL_write() don't directly return SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. Those values are returned by SSL_get_error(). I apologize for the misstatement. -Kyle H On Sun, Oct 8, 2017 at 5:58 PM, Kyle Hamilton wrote: > Do you have a

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

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

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

, Michel -Message d'origine- De : openssl-users [mailto:openssl-users-boun...@openssl.org] De la part de Thomas J. Hruska Envoyé : dimanche 8 octobre 2017 22:56 À : openssl-users@openssl.org Objet : Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets On 10/8

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

On 10/8/2017 7:28 AM, Michel wrote: While I understand that using non-blocking descriptors is a better practice, I still do not see why select() should NEVER be used for blocking sockets (except when combined/interfered with the internal OpenSSL state machine or equivalent mechanism). Could you

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

While I understand that using non-blocking descriptors is a better practice, I still do not see why select() should NEVER be used for blocking sockets (except when combined/interfered with the internal OpenSSL state machine or equivalent mechanism). Could you please elaborate or give an example ?

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

On 10/8/2017 4:17 AM, Kyle Hamilton wrote: The way to handle this situation is simply to never enter SSL_read() if there isn't anything to read on the socket. select() or pselect() are your friends, here, because they'll tell you if there's data to read from the underlying file descriptor. I

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

The way to handle this situation is simply to never enter SSL_read() if there isn't anything to read on the socket. select() or pselect() are your friends, here, because they'll tell you if there's data to read from the underlying file descriptor. I hope this helps! -Kyle H On Oct 5, 2017