rschmitt commented on PR #674: URL: https://github.com/apache/httpcomponents-core/pull/674#issuecomment-4746689018
I found something interesting while debugging. `SSLEngine#wrap` will consume zero bytes and report overflow unless the `dst` buffer has at least `sslSession.getPacketBufferSize()` bytes available. You can see this by setting ```java this.outEncrypted = SSLManagedBuffer.create(sslBufferMode, netBufferSize - 1); ``` which will cause TLS requests to hang. This means that we can only perform one call to `SSLIOSession#write` per reactor loop, even if the writes are small enough in aggregate to fit in the output buffer. Evidently, `wrap` [always produces an Application Data packet](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLEngine.html), therefore the output buffer must first have enough space for the largest possible packet: > The SSLEngine produces/consumes complete SSL/TLS/DTLS packets only, and does not store application data internally between calls to wrap()/unwrap(). Thus input and output ByteBuffers must be sized appropriately to hold the maximum record that can be produced. Calls to [SSLSession.getPacketBufferSize()](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLSession.html#getPacketBufferSize()) and [SSLSession.getApplicationBufferSize()](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLSession.html#getApplicationBufferSize()) should be used to determine the appropriate buffer sizes. The size of the outbound application data buffer generally does not matter. If buffer conditions do not allow for the proper consumption/production of data, the application must determine (via [SSLEngineResult](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLEngineResult.html)) and correct the problem, and then try the cal l again. This introduces a trade-off between latency and heap allocation. We might consider whether to use a _slightly_ larger `outEncrypted` buffer so that we can get the first Application Data packet sent off immediately even if a handshake packet like ChangeCipherSpec is still sitting in the buffer; probably just a few dozen bytes would make a difference. The broader question is whether or how to support a _much_ larger output buffer so that we can batch encrypt many packets in a single event loop iteration. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
