Boost :: Beast Non Blocking Read for Websockets?

时间:2018-04-23 20:54:07

标签: c++ boost websocket boost-beast

我们有一个完全同步的应用程序,并且永远是因为它基本上是一个命令行解释器,用于向我们的硬件发送低级命令,并且您不能同时有两个命令进入硬件。我将只有一个客户端套接字用于此配置以同步方式运行,一个命令到服务器,它与硬件对话,并将值发送回客户端,但据我所知,目前async_read是唯一的方法非阻塞读取。

通过Beast获得非阻塞读/写的最佳方法是什么?例如,在Windows中的TCP和串行中,您可以查看缓冲区以查看数据是否已准备好被访问,如果有,您可以发出读取命令,因为知道它不会因为数据存在而阻塞。不确定我是否只是在Beast中错过了这个功能,虽然我会说如果可能的话会有这样的功能会很好。

无论如何基于此我有一个问题

首先,我可以使用Coroutine示例而不是使用yield来创建并传递read_handler函数吗?

我已经采用了coroutine示例,并将函数构建到我的类中,并使用了与此线程答案完全相同的read_handler。 How to pass read handler to async_read for Beast websocket?

按照他的说法进行编译,但设置断点从不会在收到数据时触发。

我真的不需要像async示例这样的完整异步功能,将它推入不同的线程,事实上这让我的生活变得更加困难,因为应用程序的其余部分并不是异步的。因为我们允许来自各种来源(键盘/ TCP /串行/文件)的输入,我们无法阻止等待数据。

2 个答案:

答案 0 :(得分:0)

  

通过Beast获得非阻塞读/写的最佳方法是什么?

由于websocket流的实现方式,不支持非阻塞套接字模式。

  

我可以使用Coroutine示例而不是使用yield来创建并传递read_handler函数吗?

如果你想使用完成处理程序,我建议你不要从coroutine示例开始,而是从一个异步示例开始,因为这些已经编写为使用完成处理程序。

答案 1 :(得分:0)

协同程序具有阻塞语义,而完成处理程序则没有。如果您尝试使用coroutine示例并使用完成处理程序替换yield表达式,则对启动函数的调用不会阻止它在使用协程时的方式。你不应该使用spawn。你说coroutine的例子要容易得多,可能这是因为它类似于同步代码。如果你想要易于编写和理解,那么你必须使用协同程序。使用完成处理程序的代码将显示通常与回调相关联的“控制反转”。这是它们如何工作所固有的,而不是只需从使用协同程序并更改完成标记的代码开始就可以更改的内容。