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 Op
[...]
> 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 shoud
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.
http://man7.org/linux/man-pages/man2/select.2.html
ogramming ? ;-).
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 :
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() m
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 f
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 s
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 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.
--
openssl-use
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 ret
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 reference to what should
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
t you experienced or I missed your point ?
Regards,
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 shutd
,
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
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
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 ?
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 ho
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 02:58
Hi All,
I have query regarding the SSL_read on blocking socket. How to come out of
blocking SSL_read when we have to close the connection ?
As per the documentation SSL_read will only return if there is any data or
an error occurred.
"If the underlying BIO is *blocking*, SSL_read() will only re
19 matches
Mail list logo
