> Jinsong Du wrote: > > I have a simple server using blocked socket and OpenSSL, its only > > function is for user registering an account. When an user connect to > > this server, it spawns a child process to handle the request. I found > > sometime child processes got stuck. > > The problem here is that what if 2 users connects at the same moment (at > TCP level). > > But only one of them completes the SSL hello sequence ? > > If the one that didn't complete the SSL hello sequence got to be > serviced by ssl3_accept() first then you will find the other users (and > any subsequent users will be straved of CPU time to service their > connection). > > This is because your parent process is blocked expecting to process TCP > data (that never arrives). > > The problem is application design, you need to seperate the processing > of TCP level socket processing on accept from SSL level socket > processing on accept.
This is an interesting gotcha that should probably be added everyone's mental list of ways that OpenSSL connections are different from normal TCP connections. It's tempting to say to the OP "Well, duh, blocking functions block. You shouldn't call a blocking function if there's anything else you might need to do." But the OP can simply respond "Accepting SSL connections on that socket is the only thing I want to do." So the quirk is that SSL_accept, unlike a normal accept, can block indefinitely even though a new connection could be accepted without blocking. It can get 'stuck on the slow connection' even if there are fast connections. Arguably, this makes a blocking SSL_accept nearly useless. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
