Jimmy, You are right.The cryptographic negotiation of SSL takes much longer than any TCP handshake. And I do agree with you on significance of improvement. I haven't quantified yet the gain in doing connection in persistent TCP. But server as persistent TCP feature. Some client may wish to communicate like that.
Thanks, Prabhu. S On Thu, Feb 21, 2008 at 8:34 PM, jimmy bahuleyan <[EMAIL PROTECTED]> wrote: > Prabhu S wrote: > > Hi Jimmy, > > > > > > I think some details of my system would explain better. > > > > When the client connects to the server, the server opens another > > connection to a host server. The data that is sent by client is passed > > on to the host servers. The host servers responds to client requests via > > server. The connection b/w server and host is plain TCP. > > > > From what I've seen of SSL, the cryptographic negotiation of SSL takes > much longer than any TCP handshake over a sane network. Unless you're > doing session resumption in which case it would drastically come down > (but still be a bit more than TCP?). If you've really measured TCP > connection establishment dominating SSL negotiation, ...then I need to > look at my numbers again :) > > (What you've described here sounds roughly like port-forwarding in SSH.) > > > > Now there is a config in server, which determines when should server > > open connection to host server. It can do so as soon as TCP handshakes > > completes with the client or when SSL handshake is complete with server. > > In the latter case , there are no issues what so ever in persistent > > connection. All SSL handshakes are successful. In the former case I run > > in to issues I have mentioned. [ a valid question is, how can server > > config change affect client?] > > But why should client abruptly send FIN and RSTs and in correct finish > > messages? > > > > So successful SSL handshakes in persistent connection should be > > possible 'every time'. I do not think it can happen by accident. > > > > The over head becomes significant under stress test of server when we > > consider that the server is capable of taking in 500 session/sec and > > each session should not last more that 3 sec. > > > > -jb > -- > I used to think I was indecisive, but now I'm not so sure. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [email protected] > Automated List Manager [EMAIL PROTECTED] >
