On Fri, 14 Jun 2024 18:51:02 GMT, Daniel Jeliński <djelin...@openjdk.org> wrote:
>> 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. 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1640419711
