Can read up to 5 bytes after every complete message

[sdroege]

https://github.com/steffengy/schannel-rs/blob/d475251df6b271156acb95d8bd94aae50d43efcb/src/tls_stream.rs#L149

The TLS chunks always start with a 5 byte header (1 byte content type, 2 bytes protocol version, 2 bytes length). At that point the length of the whole packet is known and SEC_E_INCOMPLETE_MESSAGE will be returned, usually providing the whole size in SECBUFFER_MISSING then (sometimes not, and byte by byte has to be read).

By starting with 5 bytes, performance should be improved a little bit.

[heinzelotto]

I think this bug is outdated an can be closed. Currently in read_in() at least 1024 bytes are allocated for the read even if needs_read = 1. https://github.com/steffengy/schannel-rs/blob/690a1aac71f5fa847d14a67b30505b16adac3f66/src/tls_stream.rs#L741

self.stream.read(buf) will then happily read more than needs_read bytes. The actual amount of bytes read nread is then saturating_subtracted from needs_read since we might have nread > needs_read. https://github.com/steffengy/schannel-rs/blob/690a1aac71f5fa847d14a67b30505b16adac3f66/src/tls_stream.rs#L750

And the loop continues to make sure that at least needs_read bytes are read. In practice the first read(buf) will often receive the whole message in one go or at least fill the initial 1024 bytes of the buffer.