【问题标题】:Socket default timeout(s)套接字默认超时
【发布时间】:2017-05-08 22:16:40
【问题描述】:

主题。奇怪的是,我在 Windows 或 POSIX 的套接字参考文档中找不到这个。

出于问题的目的,我说的是影响套接字 API 调用的任何超时,即控制 API 调用返回错误的时间的任何值。像 TIME_WAIT 这样被排除,因为它只影响系统状态而不是程序的控制流。这个问题的灵感来自kill socket.accept() call on closed unix socket,OP 声称accept 会永远等待——我不相信。

  • AFAICS,有两个:用于接收和发送,不仅影响send/recv,还影响所有涉及接收或发送的API,如accept

更具体地说:

  • 是某些规范强制要求还是完全取决于操作系统供应商?
  • 主要操作系统的默认值是什么1?至少,数量级。
    • 如果在系统范围内可配置,它们存储在哪里(如果有很多可能性 - 来自内核/库存库的 POV)?

1例如Windows、Debian、Red Hat、FreeBSD、Mac OS X、Android。

【问题讨论】:

    标签: sockets language-agnostic timeout


    【解决方案1】:

    如果您谈论的是 BSD Sockets API 或基于它的系统或类似它的系统中的 API 操作,则接受、发送和接收默认超时是无限的。这是 BSD Sockets API 和 Winsock 都强制要求的。大多数实现甚至不允许您更改发送超时。

    【讨论】:

    • 这些陈述的任何参考链接?
    • 怎么会这样? TCP has timeouts all right,所以套接字必须 signal somehow after an appropriate time,不是吗?如果我使用keep-alive 会怎样? - 那么recv 也应该检测到连接断开。
    • @ivan_pozdeev 1. 我的参考资料是 BSD Sockets man 页面。 2.内部TCP超时与它无关:您明确询问不影响系统(实际连接)状态的事情,这就是我的回答。 TCP 超时会导致重试并最终在内部重置。读取时没有内部 TCP 超时,除非您通过 API 设置。 recv() 通过传递 ECONNRESET 检测连接断开,而不是通过接收超时机制。
    • 没有区别。唯一控制接收超时的时间是通过setsockopt() 设置的接收超时。内部发送超时可能会导致读取错误,但时间由相关发送的超时确定,而不是从输入接收时开始。考虑一下:您进行发送,几分钟后失败,一小时后您进行接收。它会立即失败。在等待已经过去的内部发送超时时间之后不会。相反,如果您在发送后立即接收,则发送超时后将失败。
    • 阻塞读取可以永远阻塞,因为它不会对网络做任何事情,所以没有什么会失败。由于网络问题,您需要已经完成了一次发送失败,读取才能解除阻塞。这个所谓的“设计缺陷”是 (a) 实际上是一个设计功能:参见讨论here,以及 (b) 可通过 SO_RCVTIMEO 修复。
    猜你喜欢
    • 2014-10-23
    • 1970-01-01
    • 2012-03-02
    • 1970-01-01
    • 1970-01-01
    • 2016-05-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多