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
Once a TCP session is in the Established state, it stays that way
until a FIN or RST is received from the opposite host, or if a
packet times out. This is the purpose of keepalive. However,
the default time for keepalive is a system wide setting and is
usually very long, and may not be
What is the java error?
But in the meantime, since you didn't mention it, there are a few steps
you could verify:
1) Since you are using a local keystore, can I assume that you added the
certificate to it using the keystore command?
2) By 'mutual authentication' do you mean that the server must
)
at
com.tibco.tibjms.TibjmsQueueConnectionFactory.createQueueConnection(Tibj
msQueueConnectionFactory.java:79)
at Sender.main(Sender.java:39)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Sansing
Sent: Wednesday, April 18, 2007 8:57 AM
To: openssl-users@openssl.org
Subject: Re
I don't know if this is causing your problem, but if the session cannot
be re-established due to the timeout, you could set the socket option,
SO_REUSEPORT, on both the client and server sockets when they are
created. (NOTE: Check that it is supported on your platform, if not,
then you would have
When you say that a connection 'gets accepted normally', does
that mean you do the following:
1) accept
2) use fcntl to set the connection to non-blocking
3) gets a new SSL/BIO to use the connection
4) call SSL_accept
I found that step 2 has to come after step 4. At this point, I am
assuming
