tokio-rustls: how to use buffering with TlsStream?

[david-monroe]

I have seen that internally a large read buffer is used. Therefore I do not believe that it makes sense to ever use additional read buffering with TlsStream.

However, poll_write calls the underlying poll_write every time. Would it therefore make sense to use BufWriter<TlsStream<TcpStream>> or is this BufWriter unnecessary?

[quininer]

poll_write calls the underlying poll_write every time.

I don't think this is correct, it only calls poll_write when it satisfies wants_write.

[david-monroe]

My interpretation was that wants_write returns true always if there is something to write at all.

    pub fn wants_write(&self) -> bool {
        !self.sendable_tls.is_empty()
    }

[quininer]

You seem to be right. given that rustls has a flush method, this seems to be a reserved behavior for rustls.

There are two buffer in write direction, one is sendable_plaintext before send and one is sendable_tls after send.
The sendable_plaintext is equivalent to BufWriter<TlsStream<TcpStream>>, and sendable_tls is equivalent to TlsStream<BufWriter<TcpStream>>.

Does rustls have any plan to expose write buffer? @ctz @djc

[djc]

We have a plan to have an unbuffered/write-through API, where rustls doesn't maintain any buffers for the data path. I've made some progress on this over the past year, but the next step is non-trivial to implement.