首页 文章

Linux Socket：如何在客户端程序中检测断开的网络？

提问于
浏览 次
12

我正在调试基于c的linux套接字程序 . 正如网站上提供的所有示例一样，我应用了以下结构：

sockfd= socket(AF_INET, SOCK_STREAM, 0);

connect(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr));

send_bytes = send(sockfd, sock_buff, (size_t)buff_bytes, MSG_DONTWAIT);

当删除服务器关闭其服务器程序时，我可以检测到断开连接 . 但是如果我拔掉以太网电缆，send函数仍会返回正值而不是-1 .

假设我无法更改服务器端，如何检查客户端程序中的网络连接？

c linux sockets send disconnection

4 回答

  • 2

    但是如果我拔掉以太网电缆，send函数仍会返回正值而不是-1 .

    首先，您应该知道 send 不仅仅是内存复制功能/系统调用 . 它将数据从您的进程复制到内核 - 稍后内核将获取该数据，并在将数据打包成段和数据包后将其发送到另一端 . 因此， send 只能在以下情况下返回错误：

    • 套接字无效（例如伪造文件描述符）

    • 连接显然无效，例如它尚未 Build 或已经以某种方式终止（FIN，RST，超时 - 见下文）

    • 没有更多空间来复制数据

    重点是 send 不发送任何内容，因此 its return code doesn't tell you anything about data actually reaching the other side .

    回到你的问题，当TCP发送数据时，它需要在合理的时间内得到有效的确认 . 如果没有，则重新发送 . 它多久重发一次？每个TCP堆栈的工作方式都不同，但规范是使用指数退避 . 也就是说，首先等待1秒，然后是2，然后是4，依此类推 . 在某些堆栈上，此过程可能需要几分钟 .

    重点是，在中断的情况下，TCP将声明连接死亡 only after a seriously large period of silence （在Linux上，它执行15次重试 - 超过5分钟） .

    解决此问题的一种方法是在您的应用程序中实现一些确认机制 . 例如，您可以向服务器发送请求“在5秒内回复或我将声明此连接已死”然后 recv 超时 .

    回复于
  • 2

    要检测远程断开连接，请执行 read()

    查看此主题以获取更多信息：

    Can read() function on a connected socket return zero bytes?

    回复于
  • 1

    仅在调用write（）函数时才能检测到未插入的以太网电缆 . 这是因为tcp堆栈的tcp重传没有你的意识 . 这是解决方案 .

    即使您已经为应用程序套接字设置了keepalive选项，但是如果您的应用程序一直在套接字上写入，您无法及时检测到套接字的死连接状态 . 那是因为内核tcp堆栈的tcp重传 . tcp_retries1和tcp_retries2是用于配置tcp重传超时的内核参数 . 很难预测重传超时的精确时间，因为它是由RTT机制计算的 . 你可以在rfc793中看到这个计算 . （3.7 . 数据通信）

    https://www.rfc-editor.org/rfc/rfc793.txt

    每个平台都具有用于tcp重传的内核配置 .

    Linux : tcp_retries1, tcp_retries2 : (exist in /proc/sys/net/ipv4)

    http://linux.die.net/man/7/tcp

    HPUX : tcp_ip_notify_interval, tcp_ip_abort_interval

    http://www.hpuxtips.es/?q=node/53

    AIX : rto_low, rto_high, rto_length, rto_limit

    http://www-903.ibm.com/kr/event/download/200804_324_swma/socket.pdf

    如果要提前检测死连接，则应为tcp_retries2（默认值为15）设置较低的值，但它仅为单个套接字设置这些值 . 那些是全局内核参数 . 有一些尝试为单个套接字应用tcp重新传输套接字选项（http://patchwork.ozlabs.org/patch/55236/），但我没有在系统头文件中找到这些选项定义 .

    作为参考，您可以通过'netstat --timers'监控您的keepalive套接字选项，如下所示 . https://stackoverflow.com/questions/34914278

    netstat -c --timer | grep "192.0.0.1:43245             192.0.68.1:49742"

tcp        0      0 192.0.0.1:43245             192.0.68.1:49742            ESTABLISHED keepalive (1.92/0/0)
tcp        0      0 192.0.0.1:43245             192.0.68.1:49742            ESTABLISHED keepalive (0.71/0/0)
tcp        0      0 192.0.0.1:43245             192.0.68.1:49742            ESTABLISHED keepalive (9.46/0/1)
tcp        0      0 192.0.0.1:43245             192.0.68.1:49742            ESTABLISHED keepalive (8.30/0/1)
tcp        0      0 192.0.0.1:43245             192.0.68.1:49742            ESTABLISHED keepalive (7.14/0/1)
tcp        0      0 192.0.0.1:43245             192.0.68.1:49742            ESTABLISHED keepalive (5.98/0/1)
tcp        0      0 192.0.0.1:43245             192.0.68.1:49742            ESTABLISHED keepalive (4.82/0/1)

    此外，当keepalive超时时，您可以根据您使用的平台遇到不同的返回事件，因此您不能仅通过返回事件来确定死连接状态 . 例如，当发生keepalive超时时，HP返回POLLERR事件，AIX仅返回POLLIN事件 . 那时您将在recv（）调用中遇到ETIMEDOUT错误 .

    在最近的内核版本（自2.6.37）中，您可以使用TCP_USER_TIMEOUT选项将运行良好 . 此选项可用于单个插槽 .

    最后，您可以使用带有MSG_PEEK标志的read函数，它可以让您检查套接字是否正常 . （MSG_PEEK只是看看数据是否到达内核堆栈缓冲区并且从不将数据复制到用户缓冲区 . ）因此，您可以使用此标志仅用于检查套接字是否正常，没有任何副作用 .

    回复于
  • 35

    检查返回值，看它是否等于这个值：

    EPIPE此插座已连接但连接现已断开 . 在这种情况下，send首先生成SIGPIPE信号;如果说信号被忽略或阻塞，或者如果它的处理程序返回，则发送失败并使用EPIPE .

    还要在处理程序中添加对SIGPIPE信号的检查，以使其更易于控制 .

    回复于

相关问题