使用 SO_RCVTIMEO
和 SO_SNDTIMEO
套接字选项与 Boost.Asio 很少会产生所需的行为。考虑使用以下两种模式之一:
使用 async_wait()
的组合操作
可以通过使用 Boost.Asio 计时器和 async_receive()
操作的 async_wait()
操作来组合异步读取操作以进行超时处理。这种方法在 Boost.Asio 超时示例 中有所展示,类似于:
boost::asio::deadline_timer timer(io_service);
timer.expires_from_now(boost::posix_time::seconds(1));
timer.async_wait(
[&socket, &timer](const boost::system::error_code& error)
{
if (error) return;
if (timer.expires_at() > boost::asio::deadline_timer::traits_type::now())
{
return;
}
boost::system::error_code ignored_ec;
socket.close(ignored_ec);
});
socket.async_receive(buffer,
[&socket, &timer](const boost::system::error_code& error,
std::size_t bytes_transferred)
{
timer.expires_at(boost::posix_time::pos_infin);
if (error) return;
});
请注意,两个异步操作在同一次迭代中完成是可能的,这将使得两个完成处理程序准备好以成功运行。因此,这就是为什么两个完成处理程序都需要更新和检查状态的原因。有关如何管理状态的更多详细信息,请参见
this答案。
使用std::future
Boost.Asio提供了
C++11 futures支持。当
boost::asio::use_future
作为异步操作的完成处理程序时,启动函数将返回一个
std::future
,该
std::future
将在操作完成后被实现。由于
std::future
支持定时等待,因此可以利用它来超时操作。请注意,由于调用线程将被阻塞等待未来,因此至少有另一个线程必须处理
io_service
以允许
async_receive()
操作进展并实现承诺:
std::future<std::size_t> read_result = socket.async_receive(
buffer, boost::asio::use_future);
if (read_result.wait_for(std::chrono::seconds(1)) ==
std::future_status::timeout)
{
socket.cancel();
}
else
{
auto bytes_transferred = read_result.get();
}
为什么SO_RCVTIMEO
不起作用
系统行为
SO_RCVTIMEO
文档指出,该选项仅影响执行套接字I/O的系统调用,例如read()
和recvmsg()
。它不影响事件多路复用器,例如select()
和poll()
,这些只是监视文件描述符以确定何时可以进行I/O而不会阻塞。此外,当超时发生时,I/O调用失败并返回-1
,并将errno
设置为EAGAIN
或EWOULDBLOCK
。
指定接收或发送超时时间,直到报告错误。[...] 如果没有传输数据并且达到了超时时间,则返回
-1
,同时将errno设置为
EAGAIN
或
EWOULDBLOCK
[...] 超时仅对执行套接字I/O的系统调用有效(例如,
read()
,
recvmsg()
等);超时对
select()
,
poll()
,
epoll_wait()
等无效。
当底层文件描述符设置为非阻塞时,执行套接字I/O的系统调用将立即返回
EAGAIN
或
EWOULDBLOCK
,如果资源不可用。对于非阻塞套接字,
SO_RCVTIMEO
没有任何影响,因为该调用将立即返回成功或失败。因此,要使
SO_RCVTIMEO
影响系统I/O调用,套接字必须是阻塞的。
Boost.Asio行为
首先,在Boost.Asio中,异步I/O操作将使用事件多路复用器,例如
select()
或
poll()
。因此,
SO_RCVTIMEO
不会影响异步操作。
其次,Boost.Asio的套接字具有两种非阻塞模式的概念(默认都为false):
native_non_blocking()
模式大致对应于文件描述符的非阻塞状态。此模式影响系统I/O调用。例如,如果调用socket.native_non_blocking(true)
,则recv(socket.native_handle(), ...)
可能会失败,并将errno
设置为EAGAIN
或EWOULDBLOCK
。每当在套接字上启动异步操作时,Boost.Asio都会启用此模式。
non_blocking()
模式影响Boost.Asio的同步套接字操作。当设置为true
时,Boost.Asio将设置底层文件描述符为非阻塞,并且同步Boost.Asio套接字操作可能会失败,并返回boost::asio::error::would_block
(或相应的系统错误)。当设置为false
时,即使底层文件描述符是非阻塞的,Boost.Asio也会阻塞,通过轮询文件描述符并重新尝试系统I/O操作来避免EAGAIN
或EWOULDBLOCK
。
non_blocking()
的行为会阻止 SO_RCVTIMEO
产生预期的效果。假设调用了 socket.receive()
,但没有可用的数据也没有接收到数据:
- 如果
non_blocking()
为 false,则系统 I/O 调用将根据 SO_RCVTIMEO
超时。然而,Boost.Asio 立即阻塞轮询文件描述符以进行读取,这不受 SO_RCVTIMEO
影响。最终结果是调用者被阻塞在 socket.receive()
中,直到接收到数据或失败,例如远程对等方关闭连接。
- 如果
non_blocking()
为 true,则底层文件描述符也是非阻塞的。因此,系统 I/O 调用将忽略 SO_RCVTIMEO
,立即返回 EAGAIN
或 EWOULDBLOCK
,导致 socket.receive()
失败并抛出 boost::asio::error::would_block
。
理想情况下,为了让
SO_RCVTIMEO
在Boost.Asio中起作用,需要将
native_non_blocking()
设置为false,以便
SO_RCVTIMEO
可以生效,但同时还需要将
non_blocking()
设置为true,以防止对描述符进行轮询。然而,Boost.Asio不支持这一点:
链接1
socket::native_non_blocking(bool mode)
如果模式为false
,但non_blocking()
的当前值为true
,则此函数将失败并显示boost::asio::error::invalid_argument
,因为这种组合是没有意义的。