On Thu, 20 Jun 2024 05:15:10 GMT, John Jiang <jji...@openjdk.org> wrote:
> This enhancement allows the server side to send multiple tickets and the > client side to store multiple ones. However, how does the client side use the > tickets in the cache? Yes > > This PR just takes the client side to find the first valid ticket from the > cache queue to try to resume the session. Since the tickets are generated by > the server in bulk, so their lifetimes are almost the same. Generally, the > first valid ticket is the first ticket in the cache queue (otherwise, no > valid ticket can be found). What about the remaining tickets? They are > unlikely to be used. The application calls `getSession()` from the same SSLContext of the original connection. The same way resumption is performed today. The remaining tickets sit on the client if they need them. Some applications may choose to resume multiple times to download data/images. This is a configurable option on the server because it's not applicable to all situations. Given this is stored on the client, the memory usage is minimal. If the client's lifetime is short, the tickets are deleted quickly. > > Furthermore, now that no public API supports the client-side applications to > access the cached tickets, so the clients cannot use all the tickets for > resuming multiple sessions in the subsequent connections. Then, could this PR > not change the cache? The client still stores the last ticket sent by the > server in a connection. That can simplify the solution and implementation. These cached entries are not for public API usage. They are just for resumption of existing sessions. This is no different than it is today where a TLS v1.3 stateless ticket or PSK cannot be accessed by the public API. Creating a public API would be a big change given there is no public object to identify a cached entry and no way to start a new session from a cached entry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2181846075
