[Android] Improve SslStream PAL buffer resizing#104726
[Android] Improve SslStream PAL buffer resizing#104726simonrozsival merged 4 commits intodotnet:mainfrom
Conversation
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| int32_t arraySize = length > remaining ? remaining : length; | ||
| jbyteArray data = make_java_byte_array(env, arraySize); | ||
| // data.setByteArrayRegion(0, length, buffer); | ||
| jbyteArray data = make_java_byte_array(env, length); |
There was a problem hiding this comment.
I thought about capping the size of the data buffer to the max payload size of one TLS frame and keep copying just a subset of the data as we did previously, but the SslStream is already chunking the data (StreamSizes.Default == 32,768).
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| int32_t arraySize = length > remaining ? remaining : length; | ||
| jbyteArray data = make_java_byte_array(env, arraySize); | ||
| // data.setByteArrayRegion(0, length, buffer); | ||
| jbyteArray data = make_java_byte_array(env, length); |
There was a problem hiding this comment.
Do we need to allocate a java array here or can we use NIO? appOutBuffer is a ByteBuffer. ByteBuffer has a put that accepts another ByteBuffer.
We can create a ByteBuffer over buffer with jobject bufferByteBuffer = (*env)->NewDirectByteBuffer(env, buffer, length);
Then we can put that in to appOutBuffer. That remove an allocation and a copy from a handshake.
There was a problem hiding this comment.
Just a thought, can be done as a follow up.
There was a problem hiding this comment.
Thanks for the suggestion, I'll give it a try.
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
There are failing runtime-extra-platforms tests, but they are all unrelated:
|
bartonjs
added
the
cryptographic-docs-impact
bartonjs
added
the
tracking
6 participants
Our current implementation of the
AndroidCryptoNative_SSLStreamWritedoesn't correctly handle buffer overflows when calling thewrapmethod. This isn't an issue because we always create buffers large enough to fit the wrapped data. The problem is that we are splitting data into many small chunks instead of sending fewer larger TLS frames and reducing overhead. This also affects certain protocols such as MS-TDS as reported in #95295.Closes #95295
/cc @rzikm @wfurt