Unbuffered process_tls_records does not mach usage scenario

[pascaldekloe]

The ConnectionState provided is no fit for the TLS use-case of: handshake first (possibly with early data) followed by reads and/or writes in any order until closed. Instead it makes users of the API handle both directions with newly created ReadTraffic and WriteTraffic instances on each invocation. Even the most simple request–response example boggles the mind.

Is there a way to extract a reader–writer pair from the unbuffered API? I'm happy to provide you with a pull request on agreement.

[ctz]

Instead it makes users of the API handle both directions with newly created ReadTraffic and WriteTraffic instances on each invocation.

Note that the caller is in control of providing received TLS data to the library. It therefore always has the option of providing an empty slice to obtain a WriteTraffic (which is the quiescent, state post-handshake with no data pending). This means the caller controls whether to write or read at any given time.

Is there a way to extract a reader–writer pair from the unbuffered API?

Note that a fully independent reader-writer pair continues to be very difficult. That is because reading TLS data can imply writing, so the reader needs to be able to prod the writer.

[pascaldekloe]

reading TLS data can imply writing

Thanks for clearing things up @ctz. The setup starts to make more sense now.

The documentation states “A Handshake record is ready for encoding” on ConnectionState::EncodeTlsData, and “Previously encoded handshake records need to be transmitted” on ConnectionState::TransmitTlsData. Are you saying that both states may also occur after the handshake, @ctz?

Why not use an error for the occasion, as in unbuffered::ReadError::NeedsWriteFirst(unbuffered::EncodeTlsData)?

Also, I believe the ConnectionState separation in EncodeTlsData and TransmitTlsData was ment to allow for network fail-over, because of the presence of done(). In such case there is a need keep state on how many bytes were written, which makes the whole reliance on rustls(3) to resume an extra step rather than it being of any help. That is, if my assumption is correct, then rustls(3) users may be better off with out done() and the state separation to deal with.

always has the option of providing an empty slice to obtain a WriteTraffic

So we could provide a method to get the WriteTraffic directly then? That alone would fix many of the problems already.