Hi Scott, Thanks for the useful experiment. It seems to me that if we were to implement HTTP 1.1 keep-alive then this problem would go away, right? That is, if the same TCP connection is used for a series of requests then not its not an issue, right?
I wonder how browsers do it- when I'm using my Internet banking stuff does it keep re-negotiating keys?? Or does it keep a single socket connection open for the 30 mins say that I'm using it. The latter seems extremely resource heavy on the server. Bye, Sanjiva. ----- Original Message ----- From: "Scott Nichol" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, July 06, 2002 9:45 AM Subject: Re: Reusing SSL-sessions... > Here are some results I got looking into SSL sessions. Using JDK 1.3.1_01 > with JSSE 1.0.3 on Win2k, I changed the SSLSocketClient sample to loop 10 > times. I ran the app with -Djavax.net.debug=ssl,handshake,session. The > debug output showed that a total of 6 sessions were created to perform the > 10 loops. Sometimes when the client tried to resume a session, the session > was resumed. Sometimes, the server forced a new session to start. > Sometimes, the client said "no cached client session". I removed the > startHandshake call and re-ran the test. This time a total of 5 sessions > were created to perform the 10 loops, but I would guess that the different > between the 6 result and the 5 result is pretty random (I will re-run the > tests). > > Having never written my own SSL client or analyzed the operation of one > before, I do not know if this is "normal". However, since I am seeing new > sessions created when executing this simple piece of code, I am not > surprised that new sessions are being created when running Apache SOAP over > SSL. > > Scott Nichol > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
