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? I submitted this as a bug to netscape, but I havent heard anything from them. Sorry for assuming there was bug :) Tim --- Bodo Moeller <[EMAIL PROTECTED]> wrote: > On Mon, Dec 10, 2001 at 11:23:53AM +0100, Daniel > Pettersson wrote: > > > I have seen the same problem, the server just > hangs forever when connecting with > > Netscape 6.[1|2]. > > > On Sat, 1 Dec 2001, Tim Regovich wrote: > > >> New subscriber. I checked the archives,m didnt > find > >> anything appropriate., > >> > >> run openssl -WWW > >> > >> have a file called test.html : > >> <html><body<img src="test.gif"><img > >> src="test.jpg"></body></html> > >> > >> make sure the images exist as well. > >> > >> connect using netscape 6.2 > >> > >> The stack gets really corrupt. I havent been > able to > >> identify why yet. > [...] > >> Apppears to be a memory corruption. > > Tim, can you elaborate? Does OpenSSL just hang (as > in Daniel's error > description) or does anything bad happen? > > If the problem is just that nothing at all happens, > the problem may be > caused by a well-known 'openssl -WWW' limitation in > combination with a > Netscape bug: 'openssl -WWW' does not provide for > any parallelization; > while one connection is open, no additional > connections can be > accepted. It appears that your version of Netscape > waits for > something to happen on a second connection. This is > wrong -- while it > makes sense to *try* to use an additional > connection, the client > should also continue to use the first connection, > and it should be > prepared for the second connection to be useless. > > (Obviously most servers are not as limited as > 'openssl -WWW', but the > TCP stack usually will allow more incoming > connections to pile up than > the application is actually ready to handle. Assume > that the TCP > stack accepts 256 connections and the server > software handles only 128 > of these simultaneously. Then if there are more > than 64 different > clients, not all of them will be able to get two > *working* connections > to the server even if connections complete at TCP > level.) > > > -- > 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] __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
