0

我正在编写使用 posix FIFO 进行通信的客户端-服务器应用程序。客户端和服务器都是单线程和单进程应用程序。

服务器旨在处理多个客户端。每个客户端都有自己的一对命名管道，一个用于从服务器向该客户端发送消息，另一个用于从客户端向服务器发送消息。

这个想法很简单，Server 循环遍历所有 Client 到 Server 管道，并检查那里是否有要读取的内容。

我的第一个实现是这样的：

/* SERVER */
int desc = open(pipeName, O_RDONLY | O_NDELAY); //1
assert(desc > 0); //just simplyfing error handling
int read = read(desc, buffer, BUFSIZE); //2
if(read > 0)
  do_stuff();
close(desc); //3

/* CLIENT */
int desc = open(pipeName, O_WRONLY) //4
assert(desc > 0); //just simplyfing error handling
int read = write(desc, buffer, BUFSIZE) //5
close(desc); //6

据我所知，此代码无效。

存在竞争条件，例如调用顺序如下：1、2、4、3、5、6 - 可能会导致 SIGPIPE。

问题是即使 PIPE 的另一端没有写入器，非阻塞读取打开总是成功的。这意味着如果客户端将在 open() 上阻塞，则服务器执行非阻塞打开（这将解锁客户端），然后 read() 将返回 0，因为此时 PIPE 和之后的 close() 中将没有任何内容，那么当控制将回到想要在打开的 PIPE 上执行 write() 的客户端，这将导致 SIGPIPE，因为阅读器不再可用（服务器已经关闭了管道）。

现在我看到两个解决方案：

  1. 使用“tryAgain()”在客户端处理 SIGPIPE - 这看起来非常糟糕，如果我这样做，则无法保证它在任何时候都能正常工作 - 这取决于良好的命令处理顺序的可能性......
  2. 继续阅读 PIPE 在服务器中一直打开（打开一次并在连接被认为完成时关闭）——这在我的应用程序架构中很不方便，但当然可能。我想它会解决问题，但我不确定。

以下是我的问题：

  1. 这两种方法中的任何一种都是正确的方法吗？
  2. 有没有其他方法来处理这种情况？
  3. 您认为第二种解决方案会正常工作吗？
  4. 你会选择什么，为什么？

感谢您的每一个回答。

4

1 回答 1

2

我很难理解你的问题。事物

客户端将阻塞 open() <== 没有阻塞打开

使用 select 或 epoll 来确定哪些文件描述符是可读和可写的。

然后，只需调用这些即可。

您将被通知客户端关闭管道作为您需要处理的读取事件，如果它关闭则不写入。

http://linux.die.net/man/4/epoll

https://banu.com/blog/2/how-to-use-epoll-a-complete-example-in-c/

于 2013-05-26T08:27:17.043 回答