> We are working on a threaded solution but right now we are using some > third-party code (Webs 2.18) which is single threaded.
That's fine, but if you using blocking calls in a single-threaded application, you can really only handle one client at a time. > I'm also not sure I understand your answer "This is the way TCP works". > When we disconnect the network cable the connection never times out (we > left it for at least 30 minutes). Right. > Let me give you (and others) a more concrete example. I took the > wserver2 sample from http://www.rtfm.com/openssl-examples/ and built on > FC 6. I started the server like so > > ./wserver2 -n > > Then from another machine I telnet to the wserver2 machine > > telnet <ip address> 4433 > > I just let telnet connect and don't type anything. The connection > remains 'ESTABLISHED'. and no other client connections will work (e.g. > wclient2). This is basically the behavior we are seeing with our > application. A client connects and never sends any data, so it remains > connected, hence blocking any other client from communicating. The application elected to block until the negotiation was finished. That's a pretty dumb thing for an application to do. > This seems to me (in my very novice opinion) to be an issue with > openSSL, in the sense that if it doesn't get a handshake (or some other > data) on the connection it should close the connection after a period of > time. OpenSSL tries to make SSL connections act like regular TCP connections. This is exactly what TCP does. So your application would have this exact same problem with or without OpenSSL. As such, how can you blame it on OpenSSL? Blocking socket operations are very difficult to use. I strongly urge you to switch to non-blocking operations. > I agree it requires a time-out, but since we are in the openSSL library > (waiting for the hello message) there is nothing I can do in my > application. Is there a setting I can pass to SSL to tell it to time-out? Just don't make the call that's giving you problems. You are calling a function and asking it to block until the negotiation is completed or it is clear it cannot be. Non-blocking operations are available, so use them. > As for 'keepalive', I don't think that will help if the telnet session > is still connected (e.g. telnet will ack the keep-alive requests). If we're talking about not just a disconnected network cable but the whole universe of possible bad things a client can do, yeah. You need timeouts around everything you do. That's an advantage of non-blocking operations, they are easy to time out. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
