From: owner-openssl-us...@openssl.org On Behalf Of kali muthu
Sent: Saturday, 11 June, 2011 11:52
I have Linux Server which has been connected with a Windows XP
client using SSL Sockets. I am able to read and write through those
sockets.
What is the server? Is it something you wrote? openssl or not?
I assume you created or at least are debugging the client.
Can you try another client program, like openssl commandline s_client?
Do you try your client on more than one machine, or can you?
Recently my calls to SSL_Connect() waits for long time. And yes
I am using in Blocking mode. snip
Does recently mean it used to be fast and changed to slow? If so,
did you make any code or configuration changes? Or do you mean you
just recently attempted this, and found it slow? Approximately
how long is long? 10 seconds? 5 minutes?
While at the start of SSL Socket programming, I let the socket
connections close abruptly without releasing them (through exceptions
and as a beginner's ignorance). [Might] those connections may not be
still cleared which makes my current SSL_Connect() call to hang?
I doubt it. Assuming you mean Windows close/exit without shutdown(),
or Unix(?) with linger=0, either of which (usually?) causes RST,
those should not leave 'leftover' control blocks at all. *Normal*
shutdown sometimes (often?) leaves TIME_WAIT entries on the server side
for a limited period of time, usually 1-5 minutes, as shown by netstat.
For a server not coded to deal with this (by REUSEADDR or similar) it
can cause listen (actually bind) to *fail* with an error, but not hang.
The server might appear to hang if it retries bind until it succeeds.
But even that wouldn't cause your client connects to hang; they would
be refused promptly until the server manages to listen, then accepted.
Or What might be reasons that make SSL_Connect to hang/wait
for long? And how can I establish a connection in such case when
I had to use blocking mode?
Some servers check the client in rDNS at connection start; does yours,
and if so is rDNS working in its environment, for your client(s)?
openssl in client, and in server if using client auth, can callback
for cert verification which could be doing something slow. Other SSL
implementations might, but I don't know. But you should know if you
coded that, or should have been told if someone else's code does so,
and it shouldn't have changed by itself.
The server could be doing an expensive crypto computation during
the handshake, such as choosing DHE or ECDHE parameters.
But this normally shouldn't have changed by itself, and
on reasonable desktop hardware shouldn't be *very* long.
Can you put wireshark on the XP machine (or another Windows machine
on the same nonswitched network link) and monitor? That will show
exactly how long the delay is and at what point in the handshake.
Or openssl s_client with -msg or -debug will also show you the
handshake in real time, but not with timestamps, so you'll have
to watch closely with a stopwatch or similar.
Blocking-mode in openssl only affects the organization of your code.
It is simpler to code, but doesn't allow other concurrent things
in the same program/proces. Nonblocking-mode requires somewhat more
complicated code, but once coded correctly it actually executes exactly
the same operations within openssl, and with the same timing modulo
a few nanoseconds for somewhat more function calls and kernel calls
and cache refills that no human will notice. Whatever is causing
your delay, use of blocking-mode should not be a factor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
