[openssl-users] Graceful shutdown of TLS connection for blocking sockets
Thomas J. Hruska
shinelight at shininglightpro.com
Mon Oct 9 15:47:16 UTC 2017
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.
>> Section BUGS:
>> "Under Linux, select() may report a socket file descriptor as "ready
>> for reading", while nevertheless a subsequent read blocks. This could
>> for example happen when data has arrived but upon examination has
>> wrong checksum and is discarded. There may be other circumstances in
>> which a file descriptor is spuriously reported as ready. Thus it may
>> be safer to use O_NONBLOCK on sockets that should not block."
>> Authoritative enough for you?
> That must be a recent change then. But certainly that is a bug
> in Linux select, not in programs relying on the (long time)
> documented correct behavior.
The OpenSSL layer over TCP/IP complicates matters more across ALL
platforms: SSL_read() may need to write (and SSL_write() may need to
read). Even if the socket has data to read according to select(), if
the respective write end is full (or vice versa for SSL_write()), then
the call WILL block when using blocking sockets.
You can't resolve the above issue with select() or any other function
UNLESS you switch to non-blocking socket descriptors. From that point,
the only logical conclusion that can be drawn is that select() is for
non-blocking I/O only. Then the documented "bug" in Linux becomes a
misunderstanding of what select() is actually intended for across all
platforms: Preventing spurious CPU usage for non-blocking I/O.
select() is just a notification that MAYBE you can read or MAYBE you can
write, but there is no guarantee of either succeeding.
Shining Light Productions
Home of BMP2AVI and Win32 OpenSSL.
More information about the openssl-users