为了理解boost asio库,我实现了一个异步回送服务器。我要求tcp::socket对少量数据执行一个async_read_some,即9个字节(选择用于测试的字节数),即socket_.async_read_some(boost::asio::buffer(buf, 9), callback)。然后,我将少量数据提供给服务器,并且read命令似乎只有在有整整9个字节要读取时才会回调,而不是像我预期的那样,在写入(例如4个字节)之后立即回调。是什么决定了回调何时发生,以及为什么在套接字上有一些数据可用时不立即进行回调?
发布于 2015-07-10 05:49:05
socket.async_read_some()操作与同步对应的socket.read_some()操作具有相同的完成条件。在以下情况下,该操作被认为是完成的:
操作完成后(成功或失败),http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/reference/ReadHandler.html将被发布到io_service中以推迟调用。此时,服务于ReadHandler的任何线程都可以调用io_service。
当少量数据被写入套接字(如问题描述中)时,通常会观察数据的行为,直到由于纳格尔算法而将后续数据写入套接字为止。简而言之,许多系统将试图通过将小的出站消息连接到单个消息中来缓解IP/TCP拥塞,然后再发送消息。若要在每个套接字基础上显式禁用此行为,请设置boost::asio::ip::tcp::no_delay选项:
boost::asio::ip::tcp::socket socket(io_service);
// ...
boost::asio::ip::tcp::no_delay option(true);
socket.set_option(option);当有疑问时,使用数据包分析器(如Wireshark或tcpdump )监视发送方和接收方的有线通信量。人们通常可以使用这些工具来快速识别问题是在发送方还是在接收方。在识别违规端时,通常需要深入了解内核、驱动程序或硬件文档,以确定可能是问题根源的配置。
https://stackoverflow.com/questions/31329440
复制相似问题