Darryl,
Thanks for your detailed suggestions, especially:
> It may also be helpful to call SSL_set_read_ahead(ssl, 0) to disable
> readahead optimization just before you issue the SSL_shutdown(ssl).
For some reason, adding that line before the shutdowns made all the
difference - it now works
Hi Viktor,
> Initially, does your client build an SSL connection over an already
> (TCP) established connection passed to it as a file descriptor?
yes.
> Initially, does your server accept an SSL connection over an already
> (TCP) established connection passed to it as a file descriptor?
yes.
Hi Victor,
> You should be able to cleanly shut-down SSL on both sides, and
> resume in a new process, provided the application protocol has
> a clean session termination phase.
> For example, implementing an application level "STOPTLS" verb that
> the initiator may request and the responder must
Hi David,
Thanks, you've saved me from tons of frustration and wasted time chasing an
unworkable solution. The proxy idea sounds very promising, I'll check it
out.
cheers
Andrew
I've got a situation where a listener on the server receives a connection
then the client sends a login packet. The server creates a new "worker"
process as the logged in user and passes it the socket ID. The worker
process takes over communication with the client (which is unaware of what's
happ
