这可能是一个很大的“不”，但我有一个当前的 3 层套接字架构。第 1 层除了设置必要的步骤以成为普通套接字服务器之外什么都不做，然后永远处于调用 accept() 的循环中。当 accept() 成功返回时，现在打开的套接字通过 sendmsg() 传递给一个 tier-2 程序池，这些程序获取套接字并开始读取内容并将内容保存在临时文件中。然后这个第 2 层程序读取初始数据并确定它应该调用哪个处理程序(第 3 层)程序来处理数据以在套接字上返回响应。目前，第 2 层通过 spawnp() 将仍然打开的套接字传递给第 3 层处理程序。 tier-3 程序(大约有 20 个不同的程序)处理数据并建立对互联网某处原始来源的响应。我正在寻找使用 GSK 使我的 vanilla 套接字系统适应 SSL，因此我需要一些方法来将 GSK session 句柄或某物传递到我的第 3 层程序，但到目前为止还没有成功。这个第 3 层程序是在发送响应后最终在套接字上执行任何最终 close() 的程序。
我可以提供某种图形绘图来向感兴趣的各方展示，但我是新来的，不知道这是否可行。
无论如何，我想在 SSL 中使用我当前的代码和鞋拔。目前我在 V7R1 机器上使用 GSK。在我目前的设计中，我传递 socket 就像它没什么大不了的，因为它不是。但是，似乎我无法使用 SSL 执行此操作，因为它在常规 TCP 之上具有自己的 API/协议(protocol)。我迷路了。如果您不使用 HTTPS，那么关于 SSL 的宝贵信息很少，当然如果您在 400 上使用 C++，则更少。
我的基本问题是如何将一个开放的 SSL 套接字从一个进程传递到另一个进程？可能吗？
AS/400 的 GSK 信息 http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fapis%2Fgsk_secure_soc_misc.htm
最佳答案
跨进程传递文件描述符很容易，因为内核负责管理文件描述符，并具有在进程之间传递文件描述符的内置机制。 SSL 和 GSKit 是位于内核之上的应用程序级库，它不知道它们的使用，因此您必须找到某种方法将该信息传递给您的进程。
看起来 session 句柄只是指向堆中某些存储的指针。由于 Single Level Store 的设计，您可以通过共享内存(memmap、shmget/shmat 等)复制它们。您只需确保打开 GSK 环境的进程不会终止，否则激活组将被清理，那些指针将变为无效。如果您要让多个线程访问共享数据结构，您可能还需要在它们周围放置一个互斥锁或其他一些锁定原语。
请注意，我还没有尝试过，所以这只是我的理论。
关于c++ - 使当前套接字服务器设计适应 SSL(C++、GSK、spawnp())，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21312436/