No way to detect connection closure on the remote side? about rust-native-tls HOT 5 CLOSED

A single call to TlsStream::read will do an arbitrarily large number of reads and writes on the underlying socket, but won't return until it's reached EOF (either because the underlying socket is closed, or because the TLS session is closed), or until there's some amount of data ready to copy into the buffer.

from rust-native-tls.

won't return until it's reached EOF (either because the underlying socket is closed, or because the TLS session is closed), or until there's some amount of data ready to copy into the buffer

How is that even possible to implement? I'm using a non-blocking TcpStream, so TlsStream can't block until there's enough data in the socket to read and fill the buffer. What am I missing?

from rust-native-tls.

If the underlying stream reports an error (e.g. if there's no data available and the socket's in nonblocking mode), TlsStream returns that error, and the caller will call read again when there's data available.

from rust-native-tls.

Let me try to explain in different words.

Suppose I have TlsStream<SomeOtherStream>.

SomeOtherStream's read() never blocks.

Suppose that the program only uses TlsStream<SomeOtherStream>.

If there's N bytes in the SomeOtherStream buffer, TlsStream can return M bytes such that M <= N.

So it's possible that SomeOtherStream receives 10 bytes but TlsStream::read returns 5 bytes.

Am I correct so far?

Now suppose that SomeOtherStream received 5 bytes. I call TlsStream::read.

Now it should be possible that this call returns Ok(0) even though the stream is not closed.

So there should be a way to distinguish these two cases:

1. 0 bytes returned but not because the stream is closed, it's just that the received contents used to maintain TLS connection
2. 0 bytes returned because the stream is closed

from rust-native-tls.

Now it should be possible that this call returns Ok(0) even though the stream is not closed.

No, that is not possible.

from rust-native-tls.