Adapting current socket server design to SSL (C++,

This is probably a big fat 'no' but I have a current socket architecture that is 3-tiered. Tier 1 does nothing but set up the requisite steps in order to become a vanilla socket server and then sits in a loop forever calling accept(). When accept() returns successfully that now-open socket is passed via sendmsg() to a pool of tier-2 programs that grab the socket and begin reading the contents and saving the contents in a temp file. This tier-2 program then reads the initial data and determines which handler (tier-3) program it should call to process the data for a response back on the socket. Presently tier-2 pass the still-open socket to the tier-3 handler program via spawnp(). The tier-3 program (which there are approx 20 different ones or so) process the data and builds a response back to the original source somewhere on the internet. I'm looking to adapt my vanilla socket system to SSL using GSK, so I need some method to pass a GSK session handle or something to my tier-3 program but have been unsuccessful so far. This tier-3 program is the one that finally does any final close() on the socket after a response has been sent.

I can provide some kind of graphical drawing to show interested parties, but I'm new here and don't know if that will work.

Anyway, I want to use my current code and shoehorn in SSL. At the moment I'm using GSK on a V7R1 machine. With my current design I'm passing the socket around likes it's no big deal, because it isn't. However, it seems like I can't do this with SSL because it has it's own API/protocol on top of regular TCP. I'm lost. There's precious little information out there for SSL if you're not doing HTTPS and of course even less if you're doing C++ on the 400.

My basic question is how can you pass an open SSL socket around from one process to another? Possible?

GSK info for the AS/400 http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fapis%2Fgsk_secure_soc_misc.htm

It is easy to pass file descriptors across processes because the kernel handles managing file descriptors and has a built in mechanism to pass them between processes. SSL and GSKit are application level libraries that sit above the kernel and it has no knowledge about their use, so you'll have to find some way to pass that information to your processes.

It looks like the session handles are just pointers to some storage in heap. Due to the design of Single Level Store, you could copy them via shared memory (memmap, shmget/shmat, ...). You just have to ensure that the process that opened the GSK environment doesn't die or the activation group will get cleaned up and those pointers will become invalid. You also will probably need to put a mutex or some other locking primitive around them if you're going to have multiple threads accessing the shared data structure.

Note that I have not tried this, so this is all just theory on my part.