FIFO(命名pipe道)消息传递障碍

我打算使用Unix命名pipe道(mkfifo)进行简单的多进程消息传递。 一条消息将只是一行文本。

你会劝阻我吗? 我应该期待什么障碍?

我注意到了这些限制:

  1. 收到消息之前,发件人无法继续。
  2. 一个接收器被阻塞,直到有一些数据。 当我们需要停止阅读时,需要非阻塞IO。 例如,另一个线程可以要求。
  3. 接收器可以在一次读取中获得许多消息。 这些必须在退出前处理。
  4. primefaces消息的最大长度受限于4096个字节。 这是Linux上的PIPE_BUF限制(请参阅man 7 pipe)。

我将在Python中实现消息传递。 但是障碍总的来说是成立的。

  1. 缺乏可移植性 – 它们主要是Unix的东西。 套接字更便携。
  2. 更难扩展到多个系统(另一个套接字+)
  3. 另一方面,我相信管道比同一台机器上的进程的套接字更快(通信开销更少)。

至于你的限制,

  1. 你可以在管道上“ 选择 ”,做一个无阻塞的读取。
  2. 我通常(在Perl中)打印出由“\ n”分隔的管道上的消息,并从中读取一行以获得一条消息。
  3. 请注意原子长度。

我发现perlipc是各种选项之间的一个很好的讨论,虽然它有Perl特定的代码。

发送方和接收方的阻塞都可以通过非阻塞I / O来解决。

FIFO的进一步限制:

  • 一次只有一个客户。
  • 客户端关闭FIFO后,服务器需要重新打开其端点。
  • 单向。

我会使用UNIX域套接字 ,而没有上述限制。

作为一个额外的好处,如果你想扩展到多台机器之间的通信,几乎没有任何改变。 例如,只需将套接字上的Python文档页面替换为socket.AF_UNIX ,然后用socket.AF_INET (HOST, PORT)替换为filename 即可

SOCK_STREAM会给你流类似的行为; 也就是说,两个发送可以合并成一个接收,反之亦然。 AF_UNIX也支持SOCK_DGRAM :数据报保证作为一个单元发送和读取,或根本不读取。 (类似地, AF_INET + SOCK_STREAM = TCP, AF_INET + SOCK_DGRAM = UDP。)