c - 阻塞直到读取器连接到命名管道

Question

我写了一个服务器，它打开一个命名管道(阻塞，所以它一直等到客户端连接)，然后定期向管道写入一些东西。客户端打开管道，从中读取并处理数据。但是，由于我无法控制的情况，客户端经常退出并在不久后重新启动。

当没有读取器连接到管道时，当服务器想要在短时间内写一些东西时，这会导致问题:服务器收到 SIGPIPE 并退出。我可以忽略信号，但我不想丢失数据:理想情况下，服务器会等到客户端重新连接到管道后再写入数据。服务器在这个写入过程中阻塞是没有问题的。

使用 write() 我可以尝试写入 0 字节并检查 EPIPE 错误以检测是否有客户端连接。但是，在客户端连接之前我该如何阻止(除了睡一会儿，然后再次尝试写入)？

或者是否有其他更好的方法来实现这一点？

Answer 1

事实证明，与我对上述原始问题的评论相反，有一个直接的解决方案。

此解决方案假定同一 FIFO 的所有读取器和写入器共享内核缓冲区。这应该是实现 FIFO 的最合乎逻辑和最直接的方式(考虑到它们的行为)，所以我确实希望所有提供 FIFO 的系统都以这种方式运行。但是，这只是我的假设，不作任何保证。我没有在相关的 POSIX 标准中找到任何支持或反驳这一点的内容。如果您发现其他情况，请进行管道处理。

过程很简单:

当客户端意外消失时，写入器再次打开 FIFO，而不是先关闭原始描述符。此 open() 将阻塞，直到有新的读取器可用，但由于原始文件描述符仍处于打开状态，因此新读取器可以使用已缓存在 FIFO 中的数据。如果 open() 成功，编写器只需关闭原始描述符，并切换到使用新的描述符。

如果内核结构是共享的，则 FIFO 缓冲区状态在写入器描述符之间共享，新的读取器将能够读取前一个读取器未读取的内容。

(请注意，编写者不知道客户端更改之间缓冲的数据量，因此不知道数据流中发生切换的点。)

我已经验证了这个简单的策略适用于 Ubuntu x86_64 上的 Linux 3.8.0-35-generic 内核，以及 x86_64 上的 2.6.9-104.ELsmp。

---

但是，我仍然完全同意接受数据丢失或更改协议(protocol)，正如 Basile Starynkevitch 在对原始问题的评论中所建议的那样。

就我个人而言，我发现 Unix 域套接字(绑定(bind)到路径名，例如 /var/run/yourservice/unix)是一个更好的选择，因为它允许同时存在多个客户端而不会损坏数据(与 FIFO 不同)，以及更明智的协议(protocol)。

我更喜欢 Unix 数据报套接字，在每个数据报的开头都有一个序列号和数据报长度。 (长度有助于客户端验证它读取了整个数据报；我真的不希望任何操作系统截断 Unix 数据报。)

通常，编写器向每个客户端发送一些数据报，并在发送新数据报之前等待确认。处理数据报后，客户端通过将序列号发送给编写器来确认数据报。 (请记住，这些是套接字，因此通信是双向的。)这允许编写器为每个客户端保留一些正在传输的数据报，并且客户端可以按正确(序列号)顺序或乱序处理数据报, 使用多线程。

重要的一点是每个数据报仅在处理后才被确认，而不是在收到后立即确认。

(除了读者->作者“acks”(确认)，我还支持“请重新发送”响应，以防客户端使用太小的缓冲区来接收数据报。或者由于以下原因将其掉在地上一些其他原因。甚至可能对客户端不知道该怎么做的数据报“讨厌”。)

如果客户端消失，编写者知道所有未确认的数据报尚未被客户端处理，并且可以将它们重新发送给另一个连接的客户端或 future 的客户端。 p>

有问题吗？