【问题标题】:Not getting sigpipe on first call to 'send' after client disconnected客户端断开连接后第一次调用“发送”时没有收到 sigpipe
【发布时间】:2012-09-26 23:06:15
【问题描述】:

我正在开发一个 TCP 服务器端应用程序,它将数据转发到客户端。

我面临的问题是我试图在我的服务器端应用程序上找出我的客户端是否断开连接以及发送了哪些数据,哪些没有发送。

我的研究表明,基本上有两种方法可以找出答案:

  • 1) 从套接字读取并检查 FIN 信号是否返回
  • 2) 等待发送调用中的 sigpipe 信号

第一个解决方案对我来说似乎并不可靠,因为我不能保证客户端不会发送任何随机数据,因此即使它不应该成功也会使我的测试成功。

第二种解决方案的问题是,我只在 X 之后调用 send 后才获得信号管道,因此无法保证哪些数据真正发送,哪些没有。我在 SO 和其他网站上读到这里,sigpipe 应该只在第二次调用 send 之后出现,如果我只通过 localhost 发送和接收,我可以重现这种行为,但如果我真的使用网络就不行。

我现在的问题是 X 可以变化是否正常,如果是,我可能会查看哪些参数来改变这种行为,或者由于 TCP 的性质,这是否可能不可靠。

【问题讨论】:

    标签: c tcp


    【解决方案1】:

    TCP 连接是双向的。来自客户端的 FIN 表示客户端将不再发送任何数据,但仍然可以发送另一个方向(从服务器到客户端)的数据(如果客户端没有重置与 RST 的连接)。从客户端检测 FIN 的可靠方法是从客户端套接字读取(如果您使用的是套接字接口),直到读取返回 0。

    TCP 保证,如果两端都以确认的 FIN 终止连接,则在连接中交换的所有数据都被另一端接收。如果使用 RST 终止连接,则 TCP 本身无法确定对方成功读取了哪些数据。为此,您需要一些应用程序级别的机制,例如应用程序级别的确认。但最好的方法是设计你的协议,在正常情况下,连接总是优雅地关闭(来自双方的 FIN,没有 RST)。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2018-02-09
      • 1970-01-01
      • 2016-07-26
      • 1970-01-01
      • 1970-01-01
      • 2015-05-30
      • 1970-01-01
      • 2020-07-21
      相关资源
      最近更新 更多