我正在阅读 Boost.Beast WebSocket。当我的应用程序得到备份时,websocket 发送者似乎很乐意延迟/缓冲它们的数据(大概在应用程序级别,因为它们会延迟 1 分钟或更长时间)。
衡量我是否得到备份的最佳方法是什么?例如,我可以查看 TCP 缓冲区的大小吗?我还可以在快速线程中将所有数据读入内存,并将其放入慢速线程的队列中(在这种情况下,备份可以通过队列的大小来衡量)。但我想知道是否有更直接的方法。
我正在阅读 Boost.Beast WebSocket。当我的应用程序得到备份时,websocket 发送者似乎很乐意延迟/缓冲它们的数据(大概在应用程序级别,因为它们会延迟 1 分钟或更长时间)。
衡量我是否得到备份的最佳方法是什么?例如,我可以查看 TCP 缓冲区的大小吗?我还可以在快速线程中将所有数据读入内存,并将其放入慢速线程的队列中(在这种情况下,备份可以通过队列的大小来衡量)。但我想知道是否有更直接的方法。
这因平台而异,但有 SO_RCVBUF 选项设置在 TCP 暂停接收更多数据之前可以排队到套接字上的数据量。
如果您有权访问套接字,请s
调用它来检查其 rcv 缓冲区大小可以容纳多少数据
net::socket_base::receive_buffer_size opt = {};
s.get_option(opt);
您可能会看到它默认为 64K 左右。
然后把它调高到像兆字节一样:
net::socket_base::receive_buffer_size optSet(1000000);
boost::system::error_code ec;
s.set_option(optSet, ec);
YMMV 关于您可以传递给 set_option 调用的值有多大以及实际有多大帮助。
请记住,这只是缓解压力的临时措施。如果你不断得到备份,你只会再次达到极限,只是稍晚一点,也许不那么频繁。
我还可以在快速线程中将所有数据读入内存,并将其放入慢速线程的队列中
是的,但是您基本上已经完全实现了 SO_RCVFROM 的功能。要么是这样,要么你在内存成本方面缓冲到无穷大(没有限制)。