RE: SSL connections in persistent TCP connection.

> ..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, b

Re: SSL connections in persistent TCP connection.

s an > SSL session. > > seems hardly worth it...IMO > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David Schwartz > Sent: Thursday, February 21, 2008 1:31 PM > To: openssl-users@openssl.org > Subject: RE: SSL connections

RE: SSL connections in persistent TCP connection.

s. Why ? because as David has pointed out TCP is a byte stream. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Schwartz Sent: Thursday, February 21, 2008 1:31 PM To: openssl-users@openssl.org Subject: RE: SSL connections in persistent TCP conn

Re: SSL connections in persistent TCP connection.

Hi. TCP Connection: (4 bytes) SYN SYN/ACK ACK TCP TearDown: (3 bytes) FIN/ACK ACK 7 bytes were considered overhead and optimized on a channel that needs an SSL session. seems hardly worth it...IMO On the other hand it might make sense in case stuff like firewalls between client and ser

RE: SSL connections in persistent TCP connection.

Sent: Thursday, February 21, 2008 1:31 PM To: openssl-users@openssl.org Subject: RE: SSL connections in persistent TCP 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 &#x

RE: SSL connections in persistent TCP 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?

Re: SSL connections in persistent TCP connection.

What you are describing is a performance issue. You are assuming that the bottleneck is OpenSSL, but do you have proof? Are your sessions autonomous or do the clients manage them? If each client searches thru a linked list, then that is a likely source of the problem. You need data. The gcc -p

Re: SSL connections in persistent TCP connection.

Jimmy, You are right.The cryptographic negotiation of SSL takes much longer than any TCP handshake. And I do agree with you on significance of improvement. I haven't quantified yet the gain in doing connection in persistent TCP. But server as persistent TCP feature. Some client may wish to communi

Re: SSL connections in persistent TCP connection.

Yes, Jurko. By callback functions I meant CRYPTO_set_locking_callback() and CRYPTO_set_id_callback(). 2008/2/21 Jurko Gospodnetić <[EMAIL PROTECTED]>: > Hi Prabhu. > > > For each client the SSL_CTX object is unique. And when the application > > starts, callback functions are set for multi thr

Re: SSL connections in persistent TCP connection.

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

Re: SSL connections in persistent TCP connection.

Hi Prabhu. For each client the SSL_CTX object is unique. And when the application starts, callback functions are set for multi threaded support. And when the app tries to do SSL_connects in non persistent connections[ a new TCP for each SSL session], all sessions are successful even under h

Re: SSL connections in persistent TCP connection.

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 connecti

Re: SSL connections in persistent TCP connection.

Prabhu S wrote: On 2/20/08, *David Schwartz* <[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_n

Re: SSL connections in persistent TCP connection.

Hi Jurko, For each client the SSL_CTX object is unique. And when the application starts, callback functions are set for multi threaded support. And when the app tries to do SSL_connects in non persistent connections[ a new TCP for each SSL session], all sessions are successful even under high str

Re: SSL connections in persistent TCP connection.

Hi Prabhu. Have you checked that your're not running into any concurrency problems? Best regards, Jurko Gospodnetić __ OpenSSL Project http://www.openssl.org User Support Mailing List

Re: SSL connections in persistent TCP connection.

On 2/20/08, David Schwartz <[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 connectio

RE: SSL connections in persistent TCP connection.

> 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

Re: SSL connections in persistent TCP connection.

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

RE: SSL connections in persistent TCP connection.

> 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