0

Web 服务被配置为在接收到 USR1 信号时公开其一些数据。当 xinetd 服务器接收到来自远程客户端的请求时，该信号将由 xinetd 服务器发送，例如 nc myserver 50666。当 web 服务器收到 USR1 信号时，它会打开一个专用的 fifo 管道，将其数据写入管道，然后关闭管道。与此同时，xinetd 服务器读取管道并提供给远程客户端。

在大多数情况下，它们工作得很好，但偶尔，出于某种原因，客户端会收到重复记录。从日志来看，管道似乎没有正确关闭并且缓存是剩余的，所以下次它服务时，以前的和当前的都被发送到客户端。问题是它在尝试复制时不会经常发生，不幸的是，我无法复制一次。

以下是演示该过程的简单片段：

网络服务器：（webserver.py）

def SendStream(data, pipe):
  try:
    for i in data:
      pipe.write(i + '\n') 
      pipe.flush()
  finally:
      pipe.close()

def Serve():
  threading.Thread(target=SendStream, args=(data, pipe)).start()

xinetd.d 服务器：（spitter.py）

def Serve():
  if not os.path.exists(PIPE_FILE):
    os.mkfifo(PIPE_FILE)
  os.kill(server_pid, signal.SIGUSR1)
  for i in open(PIPE_FILE):
    print i,

那么究竟是什么导致了 dup 呢？如何触发它？当前修复我取消链接管道文件并每次重新创建它以避免任何剩余但我不知道这是否是一个正确的解决方案。

4

3 回答 3

0

如果你同时运行了两个 splitter.py 副本，就会有麻烦，而且几乎任何发生在你身上的事情都是合法的。尝试将进程 ID 值添加到 webserver.py，即：

pipe.write(str(os.getpid()) + i + '\n')

这可能很有启发性。

于 2009-03-20T19:40:18.253 回答
0

这里没有足够的调试。您没有显示服务器如何处理信号或打开管道。

如果可能的话，我建议不要使用信号。它们在 C 语言中已经够多的了，更不用说在上面添加了 python 自己的特性。

于 2009-03-30T21:13:25.717 回答
0

So the real problem is that there are multiple clients exist. The server has been queried/abused from other unknown clients which weren't initially being agreed with customers and sure it will break under the current design. A fix has been deployed to address the issue. So Andy's suspicion is right. Thanks guys!

于 2009-05-13T20:23:02.177 回答