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. 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. Thanks, Prabhu. S On Thu, Feb 21, 2008 at 7:07 PM, jimmy bahuleyan <[EMAIL PROTECTED]> wrote: > Prabhu S wrote: > > > > > > On 2/20/08, *David Schwartz* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > > But, the application code tries to clear out/shutdown existing > > > SSL session with orderly bi-directional alerts. Once shutdown it > > > creates a new SSL object 'ssl' [ssl = SSL_new (ctx)] > > > for the next session in persistent connection.. > > > > This is nearly impossible to do. It's possible that you did it > > correctly, > > but very unlikely. The basic problem is this -- when you call 'read' > > to get > > the last message of the first session, how do you make sure you also > > don't > > get all or part of the first message of the second session? > > > > > > I do not think it is very difficult. The application initiates SSL > > sessions sequentially in a established socket connection.One cycle of > > SSL_connect - DataExchange-SSL_shutdown is followed by another cycle of > > SSL_connect - DataExchange-SSL_shutdown. As such there shouldn't be > > issue of session mix up.At least that is what is observed with say > > 400-500 clients connecting to server simultaneously. > > > > Isn't it possible you got lucky under just the 'right' conditions? Can > you guarantee it will always work? > > > > > > When the app simulates limited clients , say, 100, each client > makes > > > hundreds of unique SSL sessions successfully in persistent > > connection. > > > It is under stress of ~800 clients , that I run into issues. > > > Also, the bi-directional alerts do not happen always under > > > high stress..could this be the reason? a possible session data > > mix up? > > > > Either your code properly separates the sessions or it doesn't. My > > bet is > > that it doesn't because this is very hard to do right. > > > > > > Yes. I believe so..I am able to establish hundreds of cycles of new > > sessions in persistent connection. The trouble is under high stress > > sessions fail as indicated by ethereal trace.Sometimes server complains > > of Bad_MAC error on receiving Finished message from client. > > > > > > Why do you do things this way? It's just plain wrong. Either layer > > on top of > > SSL or don't, but splitting the difference and "sort of" layering > > between > > SSL and TCP is just plain crazy. > > > > > > Multiple sessions are tried in a single TCP connect to reduce the > > overhead of TCP handshake and termination if the client wishes to do > > multiple 'new' SSL connects to server. > > > > Have you quantified this overhead? What percentage of session > establishment is TCP handshake overhead? > > > > > Thanks, > > Prabhu. S > > > > Good luck! > > -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 openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] >
