> 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 List openssl-users@openssl.org Automated List Manager majord...@openssl.org
