Improve efficiency of network reads in TLSEngine #1898
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was working with @tpolecat on testing Postgres TLS integration in skunk (#1897). While it's working now, Rob noticed lots of buffer underrun events during unwrapping as a result of requesting a single character from the
TLSSocket
. This turned in to a call tosocket.read(1)
. Consequently, theTLSSocket#read1
implementation would read a single byte at a time from the underlying raw socket. This would continue until enough individual bytes had been read and queued that an unwrap operation could succeed.In this PR, we guard against very small
maxBytes
by requesting up tosession.getPacketBufferSize
bytes from underlying socket whenmaxBytes
is less than that value.The result of the Postgres integration now completes with no underrun: