RFR: 8328608: Multiple NewSessionTicket support for TLS

[Daniel Jeliński]

On Fri, 14 Jun 2024 16:44:42 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> And your suggestion would be?
>
> This is a low level networking error beyond my control.  All this code can do is accept that the operating system has sent it a fatal error that has blocked the servers ability to read data from the socket on data that was by the client already.   This data is no lost, which is not a good situation to be in.  Catching the exception doesn't resolved the lost data.  A similar situation has occurred before with [JDK-8235973](https://bugs.openjdk.org/browse/JDK-8235973).  Their solution does not fit here as this is during a normal read operation, but shows working around the issue was necessary.

On the contrary, you are in control of this error. The client OS resets the connection whenever the client closes the socket without reading all available data from the buffers. When the reset is delivered to the server, any data that was not received yet is lost.

The best approach depends on the type of traffic on the connection. If the client is expected to receive data, we can send the NewSessionTicket message as before. If we don't know if the client is expected to receive data, we should delay sending the NewSessionTicket messages until the server actually writes data over the connection.

Sending the NewSessionTicket messages in a thread only adds variability to the mix... without a thread, the messages were guaranteed to be sent before user data. Now the messages can be sent any time before, in the middle, or after user data.

OpenSSL added a function to configure the number of tickets sent automatically after the finished message, and a function to request sending a ticket with the next application data. We should probably do the same.

https://www.openssl.org/docs/manmaster/man3/SSL_new_session_ticket.html

Regarding the failing test, there are 2 options to fix it:
- configure the server to send zero tickets, or
- receive at least one byte of data on the client side before closing the socket.

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

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