【问题标题】:C LINUX\WINSOCK- check FIN packet in SendC LINUX\WINSOCK- 检查发送中的 FIN 包
【发布时间】:2016-01-08 11:34:29
【问题描述】:

我正在尝试了解如何避免以下情况:

  1. 客户端终止其进程。一个 FIN 消息被发送到服务器。
  2. 服务器收到客户端发来的FIN报文。
  3. 服务器收到FIN报文后的毫秒,使用send报文,向客户端发送信息。

使用C API-服务器能否知道客户端确认了哪些数据包?

如果是,Linux\Winsock 中的命令是什么?

【问题讨论】:

  • 你能告诉我们更多关于你想解决的问题吗?它可以帮助寻找替代解决方案。
  • 你描述的场景没有问题。传入的 FIN 仅表示发送方已停止发送。它仍然可以接收。只有一个或几个发送可以分辨。我看不出 ACK 与它有什么关系。不清楚你在问什么。

标签: c linux sockets winsock send


【解决方案1】:

我不能代表 Linux,但在 Windows 下,如果一个进程在已建立的连接打开的情况下被杀死,这些连接将被强制(硬)重置。对等方将收到 RST,而不是 FIN,并且无法通过该连接进行进一步通信。

【讨论】:

    【解决方案2】:

    这个问题会定期出现。简短回答:操作系统中的 TCP 层有意将“acks”(接收确认)传递给应用层。如果确实如此,那将是您用来吊死自己的绳索。虽然 TCP 被认为是“可靠的”,但它实际上并没有办法表明它上面的应用程序代码是否确实处理了接收到的字节。

    您提到了“数据包”,但这是一个非常模糊的术语。您的套接字应用程序可能具有“消息”(不是数据包)的概念,但 TCP 没有数据包甚至消息的概念。它发送源自您的应用程序代码的字节“流”。 TCP 分段、IP 分段和其他因素会将您的消息分成在线路上的多个数据包。而且 TCP 不知道哪些 IP 数据包构成了整个应用程序消息。 (常见的套接字谬误 - 许多开发人员错误地认为“发送”对应于另一端相同大小的“接收”)。

    因此,唯一可以确认成功接收消息的代码是套接字应用程序本身。换句话说,您的客户端/服务器协议应该有自己的确认系统。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2016-04-19
      • 1970-01-01
      • 1970-01-01
      • 2012-06-25
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多