简短版本:如果我在 ioserive 中运行了一个打开的 tcp 套接字,如果我停止服务会发生什么?数据是否应该继续在 tcp 套接字中排队(假设服务器继续发送数据并且没有断开连接)?如果是这样,我可以通过重置并重新启动 ioserive 来检索该数据吗?
长版:我试图在我的基于 asio 的 tcp 套接字 API 周围放置一个阻塞接口。
用户最初使用打开到服务器的套接字的 API 进行连接。
对于每个后续的 API 调用,ioservice 都会重置并启动,然后使用带有 boost::asio::write 的 tcp 套接字将数据发送到服务器,并等待响应。来自服务器的响应使用 async_read_until 处理。当收到响应时,处理程序被调用,ioservice 停止并且原始阻塞 API 调用释放回客户端,并带有来自服务器的数据。这适用于请求-响应类型的命令。总之:
- API 阻塞调用
- ioservice 重置并启动
- tcp 数据包发送到服务器
- 服务器响应
- 处理程序调用
- ioservice 已停止
- 释放 API 调用并将数据传递给用户
另一个命令是请求-响应,它从服务器开始广播,更新客户端的内部缓存。这个想法是用户在初始尝试使用类似于上面的 ioservice 启动-停止过程刷新它之后,使用另一个 API 函数访问这个缓存。但是,在此尝试之前,代码会使用以下选项之一检查套接字上是否有任何数据可用:
bool is_data_available() {
//boost::asio::socket_base::bytes_readable command(true);
//socket_->io_control(command);
//return command.get() > 0;
return socket_->available() > 0;
}
永远不会有任何数据,即使服务器已记录为已发送数据。
所以广播的总结:
- 成功执行上一个要点列表开始广播
- 观察服务器已经发送数据
- 调用上面的代码块,查看socket中是否有数据(注意此时服务还没有启动)
- 从来没有任何数据