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]
