> ..I mentioned overhead not in terms of data bytes, but the time. > Considering that in the system each session should not last not > more than 3-4 seconds, and client wanting to make multiple SSL > session with server, persistence can offer performance improvement.
You're just making that up, because you haven't measured. In fact, common sense would suggest the reverse. Persistence requires each SSL session to completely shut down before the next session can even begin building up. Using a new TCP connection can allow the next SSL session to start setting up as soon as the decision is made to end the previous one without having to wait until the shutdown completes. > Also each client that the application simulates would pick up a unique IP > address, [ virtual address are configured in the system]. Each thread would > have a unique socket connection with server. These threads would be working > parallel in communicating the sevrer. > Would there still be issues of TCP stream getting mixed up across threads ? It's possible to make a mistake like this and also possible that you didn't make a mistake like that. There's no way to know without looking at your design. You do know that dedicated threads for connections is one of the worst design patterns out there, giving you almost all of the disadvantages of threads (overhead of synchronization, for example) with almost none of the advantages (work can still get done even if a thread blocks for an unexpected reason, fewer context switches, and so on). DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
