> 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? > 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. 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. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
