1

当我从 msdn链接查看 setsockopt 时。我遇到了一个参数 SO_RCVTIMEO，它的描述是“设置超时，以毫秒为单位，用于阻止接收调用。 ”我认为套接字侦听操作是事件驱动的，这意味着当内核从 NIC 卡中耗尽帧时，它会通知我的程序套接字，所以呢阻塞是怎么回事？

4

2 回答 2

3

recv 和 WSARecv 函数是阻塞的。它们不是事件驱动的（至少不是在调用级别）。即使阻塞有超时（通过SO_RECTIMEO选项设置），就您的代码而言，它们不是事件驱动的。在这种情况下，它们只是伪阻塞（可以说是非阻塞，具体取决于超时时间有多短）。

当您调用 WSARecv 时，它会等到准备好读取数据。虽然数据尚未准备好读取，但它只是等待。这就是为什么它被认为是阻塞的。

你说得对，网络的核心是事件驱动的。在引擎盖下，计算机本质上是事件驱动的。这是硬件的工作方式。硬件中断本质上是事件。你是对的，在低级别发生的事情是你的 NIC 卡告诉操作系统它已经准备好被读取。在那个级别上，它确实是基于事件的。

问题是 WSARecv 等待该事件。

这是一个希望清楚的类比。想象一下，由于某种原因你不能离开你的房子。现在想象你的朋友 F 住在隔壁。此外，假设您的另一个朋友 G 在您家。

现在想象一下，你给 G 一张纸，上面有一个问题，让他把它拿给 F。

发送问题后，假设您发送 G 去获取 F 的回复。这就像 recv 调用。G 会等到 F 写下他的回答，然后他会把它带给你。如果 F 还没有写，G 不会立即转身回来。

这就是差距的来源。G确实知道“F写了！” 事件，但你不是。你不是直接看那张纸。

设置超时意味着你告诉 G 在放弃和回来之前最多等待一段时间。在这种情况下，G 仍在等待 F 写入，但如果 F 在几毫秒内没有写入x，G 就会转身空手而归。

基本上recv的伪代码大致如下：

1) is data available?
  1a) Yes: read it and return
  1b) No: GOTO 2
2) Wait until an event is received
  2a) GOTO 1

我知道这是一个非常复杂的解释，但我的主要观点是：recv 与事件交互，而不是你的代码。recv 阻塞，直到收到这些事件之一。如果设置了超时，它会阻塞直到收到这些事件之一，或者达到超时。

于 2013-01-10T02:02:42.197 回答
2

默认情况下，套接字不是事件驱动的。您必须编写额外的代码来启用它。相反，套接字最初是在阻塞模式下创建的。这意味着默认情况下，对send()、recv()或accept()的调用将无限期地阻塞调用线程，直到请求的操作完成。

对于recv()，这意味着调用线程被阻塞，直到至少有 1 个字节可从套接字的接收缓冲区读取，或者直到发生套接字错误，以先发生者为准。 SO_RCVTIMEO允许您在阻塞读取上设置超时，因此如果在超时过去之前没有可用的传入数据，则会recv()以WSAETIMEDOUT错误退出。

实现超时的另一种方法是将套接字设置为非阻塞模式，然后通过ioctlsocket(FIONBIO)超时select()调用，然后调用recv()或accept()仅在select()报告套接字处于可读状态时调用，并且send()仅当select()报告套接字处于可写状态。但这需要更多代码来管理套接字进入阻塞状态的情况，从而导致操作失败并WSAEWOULDBLOCK出现错误。

于 2013-01-10T02:03:08.707 回答