I've got a client/server pair in which the server forks for each connection. It calls fork() after the accept() returns and then does all the ssl gymnastics in the child process. Other than probably being a bit more costly than using a thread, it works fine.
Paul Allen
mclellan, dave wrote:
I have a closed ('closed' in the sense that produce the client and the server applications) client/server application which optionally uses SSL to secure the session. It's a mature propretiary client/server protocol which has been enhanced to add the SSL support.
On most platforms, the server starts a new thread to handle a new connection, but this happens after we execute the connect/accept sequence. That is, the listener thread accepts and SSL_accepts the client, and then starts a new thread to handle the client.
On a couple of platforms, we can't, because of unrelated architectural reasons, use a thread for a new session. We have to fork a new process after the accepting the client. Is there any prayer for the child process, with inherited socket and memory image of the SSL structures, to actually succeed? Do I need to re-initialize the library and everything else in the child process? What the heck else would I have to do in this architecture.
Does anyone have experience with SSL in forked environments? Thanks for your advice. I have seen some hits on fork behavior in the archives but no answers.
-- Boeing Phantom Works \ Paul L. Allen, (425) 865-3297 Math & Computing Technology \ [EMAIL PROTECTED] POB 3707 M/S 7L-40, Seattle, WA 98124-2207 \ Prototype Systems Group ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
