RFR: 8328608: Multiple NewSessionTicket support for TLS

[Anthony Scarpino]

On Mon, 17 Jun 2024 16:28:16 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

>> Maybe the comment could use some rewording, but I tried to not write whole bug report in a code comment.
>> 
>> When this was first prototyped as non-threaded, the SocketException occurred because multiple NSTs were sent after the Finished.  The client sent a few messages and closed the connection immediately.  The server, sending the NSTs, runs into the WIndows SocketException when it tries to read the data sent by the client.  Failing to receive the any data or the close_notify.  The variability of the thread allowed the OS to handle the reset correctly and allow the TLS server to receive the close_notify and the data that was sent.
>> 
>> Waiting for application data to cross the wire may not work for clients that connect and immediately start multiple sessions via resumption to transfer data.  It will not have any tickets to resume from.  Additionally delaying the NST may not mean this problem will go away if the client closes during the NST creation.
>
> I experimented with the code a little, and I didn't observe any failures after inlining the thread code. On the other hand, when I moved the `hc.handshakeOutput.flush();` line inside the loop that sends NewSessionTicket messages, I immediately got a test failure. I forgot that the SSLSocket actually tries to "deplete" the socket before closing it, pretty sure that's the reason why the test didn't fail.
> 
> Are you sure the thread is still necessary?

The thread has been the best way to handle this so far, but I've tried other ways with mixed results.
As you may or may not have seen with your `hc.handshakeOutput.flush()` experiment, was all the NST writes can max out the packet buffer size, so it needs occasional flushing.
This is all about IO and not getting the Windows exception.  Writing a lot of handshake data at once is causing the problem.  Using the thread can allow the IO to breathe a bit, even with maybe a `sleep()` help spread out the load. 
I'm also examining a way to use the socket writing to distribute the NSTs with the flow of other data.  The spec doesn't require all of them be sent immediately, but making sent too slow risks no tickets for multi resume clients.
I feel the solution to this isn't going to be perfect and will take some compromises.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1643207977