Tim Regovich <[EMAIL PROTECTED]>: > Interesting. I see what you mean wrt Netscape. > So I tried two things : > 1) wrapped the SSL_accept call with a sigaction/alarm > scheme. it ends up timing out, and continuing, and > everything is fine (provied of course that I assume > the timeout means that something bad has happened) > 2) I converted the whole schebang to use non blocking > sockets. I have no problem with netscape connectiong > now, because when the SSL_accept returns WNAT_READ, I > just add it to my select and it eventually times out. > > So am I correct in assuming that Netscape has left the > soccket open and is *also* trying to read, leading to > this deadlock? Or is it because netscape has an > inherent race condition it in, preventing it from > connectiong to synchronized, single threaded servers?
My guess is that what happens is that the Netscape browser causes a deadlock by opening a second connection while the first one is still open (which is OK so far) and then waiting for a reply to its ClientHello on this second connection. It should continue to use the first connection in parallel to trying to finish the SSL handshake for the second one, not block the first connection while waiting for something to happen on the second one. -- Bodo M�ller <[EMAIL PROTECTED]> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
