fork上的TCP套接字关闭行为

首先，让我描述一下我正在努力实现的目标

我有一个服务器，我正试图通过自动测试来测试。为此，在编译过程中使用forkserver例程检测服务器，该例程可被触发以中断正常控制流并进入forking循环（类似于AFL++使用的循环）。 这正如预期的那样有效

服务器使用TCP进行通信。最初，测试程序将向服务器发送一些输入，然后进入分叉模式，以便从此“快照”继续。 这是程序第一次被分叉。 分叉进程被终止或正常退出。之后，从原始流程派生出一个新流程

通过阅读close手册页，我希望tcp套接字仍然能够接收数据，因为它只在子进程中关闭，而不在父进程中关闭。 但事实并非如此，因为下一次发送到服务器失败，错误号为32

关于这一点，我现在有两个问题：

我是否误解了分叉时处理tcp套接字的方式

如果上述方法（分叉，并继续使用相同的tcp连接）不起作用，那么从特定的执行点继续使用相同的tcp连接（如前所述），有什么替代方法可以达到预期的效果

EPIPE

（errno=32）错误表明本地端已关闭。因此父套接字没有关闭。但是，TCP连接可能会关闭

我建议通过使用数组为每个进程使用一个套接字。但这个解决方案看起来有点唠叨

---

我无法更改目标的行为，因为它正在测试中。我想另一种选择是使用某种虚拟化，但这种虚拟化的开销首先可能会超过快照的好处。此外，epipe错误发生在发送端（即测试软件）。服务器（即测试中的软件）是被分叉的服务器。如果我正确理解了手册页，那么分叉子对象中的关闭不应该影响父对象中的套接字。您很理解文档。仅当套接字在所有进程中都已关闭时，操作系统才会关闭该套接字。我想你的程序肯定还有别的问题。如果在两个进程中都调用read，则分叉和继续现有TCP连接可能会导致问题。然后，很难预测哪个进程获得接收到的数据。操作系统可以选择任何正在读取中休眠的进程。