1

我们的团队正在 Windows 上实现 VNC 查看器（=VNC 客户端）。该协议（称为 RFB）是有状态的，这意味着查看器必须读取 1 个字节，看看它是什么，然后再读取 3 个或 10 个字节，解析它们，等等。

我们决定使用异步套接字和单个 (UI) 线程。因此，有两种方法：

1) 状态机——如果我们在读取套接字时遇到阻塞，只需记住当前状态并退出。稍后，套接字通知将到达，中断的逻辑将从正确的阶段恢复；

2）内部消息循环——一旦我们确定从套接字读取会阻塞，我们进入一个内部消息循环并在那里旋转直到最终接收到所有必要的数据。UI 不会因此在阻塞的情况下被冻结。

经验表明，第二种方法不好，因为当我们处于内部消息循环中时，任何消息都可能出现。我不能在这里讲述完整的故事，但它根本不够可靠。崩溃和kludges。

第一个选项似乎还可以接受，但要以这种风格进行编程并不容易。必须记住算法的状态和进一步处理所需的所有局部变量的值。

这很可能使用多线程，但我们只是认为这种情况下的问题会更加困难：帧缓冲区访问的同步、多线程问题等。此外，即使在这种变体中，似乎也有必要使用异步套接字也是如此。

那么，您认为最好的方法是什么？

这个问题很笼统。这就是通过有状态协议组织异步通信的问题。

编辑 1：我们使用 C++ 和 MFC 作为 UI 框架。

4

3 回答 3

1

我已经完成了一些并行计算项目，似乎 MPI（消息传递接口）可能对您的 VNC 项目有所帮助。您可能对 MPI 提供的并行计算能力不太感兴趣，但您可能希望使用简化的类套接字接口通过网络进行异步通信。

http://www.open-mpi.org/

您可以从 google 找到 MPI 的其他实现和大量使用示例。

于 2012-07-10T01:59:30.263 回答
1

不要为 CSocket 烦恼，由于您获得了额外的控制（中断、关闭等），您最终将转向 CAsyncSocket。我还建议使用单独的线程来管理通信，它增加了复杂性，但保持 UI 响应应该是重中之重。

于 2012-07-11T15:24:29.717 回答
0

我想你会发现使用单独的线程来处理阻塞套接字会大大简化你的设计。

这样做的主要原因是您不需要旋转和等待。UI 保持响应，而网络线程在无事可做时阻塞并在它有事可做时返回。您正在有效地将大部分开销转移到操作系统上。

请记住，RFB 不需要大量的状态信息即可工作。因为客户端到服务器的消息很短；在发送下一个指针输入之前，没有什么要求您接收帧缓冲区。

我的观点是 RFB 中的消息可以混合使用；服务器将按照您的日程安排工作。

现在，Windows 提供了易于使用的同步 API，虽然并不总是最有效的，但对于您的目的来说已经绰绰有余，并且可以轻松地进行概念验证。看看Windows 同步 ，特别是关键部分

只是我的 2cents，我已经在 windows 上实现了 vnc 服务器和客户端，这些是我的印象。

于 2014-06-18T21:12:08.083 回答