It's not yet finished, but i've done some tests and
they are sucessfull...
Thank you for this hint.
--- Richard Salz [EMAIL PROTECTED] a écrit :
There is no pre-existing way to write out all the
SSL state so that
another process can reconstruct it.
I would do it this way; when a
Hello,
parent accept() and SSL_accept() then fork(), parent
SSL_free() and close() and child to some work.
What work would that be? It should not be possible for the child
process to splice itself into the middle of an SSL session without
the required cryptographic state...
Of course,
First i want to thank you both for your quick answers.
It's quite hard to change the design as its an old
application which must be upgraded to SSL.
Maybe what i've said was not clear enough.
In fact, i don't want two processes to be able to
communicate on the socket at the same time.
I just
There is no pre-existing way to write out all the SSL state so that
another process can reconstruct it.
I would do it this way; when a connection comes in, spawn stunnel to
handle the SSL with a pipe() back to the dispatcher. Use raw read on the
pipe; when it's time to spawn a client, hand
On Fri, Jul 21, 2006 at 03:55:09PM +0200, Frederic Renault wrote:
First i want to thank you both for your quick answers.
It's quite hard to change the design as its an old
application which must be upgraded to SSL.
Maybe what i've said was not clear enough.
In fact, i don't want two
Hello,
Maybe what i've said was not clear enough.
In fact, i don't want two processes to be able to
communicate on the socket at the same time.
I just would like the process which has accepted the
connection to give the SSL object to a second process.
Then the first process doesn't need
On Sat, Jul 22, 2006 at 12:46:35AM +0200, Marek Marcola wrote:
parent accept() and SSL_accept() then fork(), parent
SSL_free() and close() and child to some work.
What work would that be? It should not be possible for the child
process to splice itself into the middle of an SSL session without
