SSL_accept blocks other SSL connections

[Big Muscle]

This bug appears when TLS encryption is enabled in ADC hub and it is easily reproducable when trying to connect to more users in hub (I'm trying to connect to all users in DCDev Public).

When TLS is on, there is a lot of users I can't connect to. The reason is that SSL_connect is waiting too long and connection timeouts during that time and is disconnected.

I have no solution for this problem, but I think it's caused by SSL_accept which is blocking operation and if it block for some time, it will block all other connections. It's only my guess, because if I put setBlocking(false) before SSL_accept (and setBlocking(true) after it), the problem disappears and I can connect to all users then. But in this case I get debug message "Connected to SSL client using (NONE)", so I'm not sure if it correct way (because normally it writes some type of encryption instead of NONE), so it would be good to find some better fix.

Maybe proper solution would be make some threadAccept (like threadConnect) in BufferedSocket.

[Big Muscle (bigmuscle)]

Also, it is connected with bug that when one side is waiting in SSL_connect and second side retry the connection, it will create new connection which will wait in SSL_connect again and this can repeat forever.

[Big Muscle (bigmuscle)]

The bug isn't fixed, because it still calls SSL_accept in same thread as it accepts all other connections.

[Big Muscle (bigmuscle)]

so, changing SSLSocket::accept to non-blocking when calling waitAccepted(0) seems to fix the problem, but it eats too much CPU until all connections are connected successfully.

void SSLSocket::accept(const Socket& listeningSocket) throw(SocketException) {
 Socket::accept(listeningSocket);

 setBlocking(false);
 waitAccepted(0);
 setBlocking(true);
}

[Big Muscle (bigmuscle)]

I did some more tests and my proposal seems to be almost correct. That 100% CPU usage has nothing to do with it, because it appears also with non-TLS transfers, so it should be different problem.
Now there's only one difference between TLS and non-TLS transfers. Non-TLS transfers connect immediately, but TLS transfers take more time to connect (but they finally connect), so 100% CPU usage appears for them for longer time.

[Big Muscle (bigmuscle)]

I would make this thread as general for reporting SSL bugs. Maybe i have another one:

OpenSSL FAQ says: "Multi-threaded applications must provide two callback functions to OpenSSL by calling CRYPTO_set_locking_callback() and CRYPTO_set_id_callback(). "

Since i have reported crashes like this: http://strongdc.sourceforge.net/crash/view_crash.php?id=15541 there could be some problem with multi-threading.

[Jacek Sieka (arnetheduck)]

I prefer separate bugs for separate issues, even if they concern the same functionality...easier to keep to track of (specially if they're fixed in a different order than reported...)

[Big Muscle (bigmuscle)]

Ok, I changed title to original reason of the bug report to be more concrete. This bug fixed.