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..
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? Thanks, Prabhu. S On Thu, Feb 21, 2008 at 12:25 AM, David Schwartz <[EMAIL PROTECTED]> wrote: > > > I have a SSL client and a server application.The client connects to a > > SSL server in a TCP socket persistence mode, i.e, it does a data > > exchange with the server through a SSL connection , tears down the SSL > > connection but again sends out a client_hello in the same TCP socket > > connection it had earlier established with the server to perform another > > cycle of data exchange. > > You are trying to do this without having any protocol that would assure > that > it works. As far as I know, there is no reason this should work, and you > haven't coded any. > > How do you determine, unambiguously, whether a particular chunk of data is > part of the first SSL session or the second? How do you make sure final > data > from the first connection isn't seen as starting data for the second? > > If you want to multiplex two SSL connections over a single TCP connection, > you need to make sure that both ends agree unambiguously on what data is > part of the first SSL connection and what data is part of the second. > Unless > you wrote code to do that, you are basically expecting it to happen by > accident. > > There is simply no way to prevent the code that receives the last bytes > from > the first SSL connection from receiving some of the first bytes for the > new > one, and it has no place to "put them back" since all the code just reads > directly from the socket. > > Theoretically, SSL could have been designed to allow this, but as far as I > know, it wasn't. Do you have any reason to believe otherwise? > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] >
