与VMware和Teradici深入对话PCoIP

(BrianMadden.com)第一个问题是当一个硬件客户端连到到一个软件主机的过程是什么样的？软件主机怎么识别不具备GDI基元的软件客户端，这会导制软件主机怎样模拟原有硬件主机发送更多像素及基于GDI相关屏幕元素？如果是这样，怎样不影响用户体验、主机负载及带宽消耗？抑或是为各种硬件产品升级固件的软件客户端来模拟或处理GDI类的东西，使其能够接收来自远程主机的完整画面？如果是这样，有哪些有效的经验？

(Warren Ponder & Randy Groves)PCoIP协议所有像素（除了MMR发挥作用的地方）完全依赖于主机渲染。这意味着所有GDI基元和其它图形命令都是由VMware View所在台式机CPU或硬件主机工作站的GPU完成渲染。CPU可以高效的渲染GDI基元（小于大部分办公应用CPU负载的2%）。CPU渲染只适合CPU密集型视频解码或3D应用。主机端渲染的关键优势是它保证了所有当前和未来应用及视频解码器的兼容性，并且没有网络或客户端硬件仰赖性。例如：使用Windows 7 WPF和基于.Net 3.5 SP1的应用中远程调用的某些原始好处将会消失。

PCoIP协议从框架缓存中取得原始像素，分类这些像素到不同的图像类型（图像分解）并且根据图像类型使用最适合的压缩解码器压缩像素。在更高的层次，这个过程硬件和软件主机是相同的。

因为一切都是主机端处理，客户端设备只是充当一些简单的解压或解码引擎。这类似于数字电视如何处理使用MPEG压缩或H.264编码和解码的相关像素。所不同的是数字电视解码器处理MPEG和H.264这些公共桌面图形和文本效率不如计算机显卡。你的数字电视不能渲染像素；所有的像素都是由演播室生成的。同样的，主机端渲染，PCoIP客户端只解码使用PCoIP编码的压缩像素。

PCoIP零客户端（Zero Client）和PCoIP软件客户端主要区别是可维护性和安全方面没有一个独立的操作系统或浏览器需要每月打补丁和需要杀毒或清除流氓软件。虽然PCoIP零客户端可以使用自己的固件升级加入新功能，这是基于用户是否需要新功能而不是必须使用的安全补丁。Teradici和VMware致力于完全兼容任何现在已经安装的固件版本为3.0及以后的零客户端，我们未来所有的VMware View会继续支持。固件升级仅限于增加新功能，不会是VMware的新发布版本，这也为零客户端提供更有保障的体验。在客户端设备上使用软客户端保持与其他服务或软件完全相同的性能是非常具有挑战性的。

除了性能以外，在软客户端和零客户端之间还有一些其它区别。对于支持的视频类型，软件客户端能使用客户端MMR替代主机解码，而基于Tera1芯片的零客户端所有解码都需要在主机上完成。其它一些功能差别存在于零客户端固件与软客户端当前版本中。例如，软客户端中支持连接到VMware View Desktop中的虚拟打印和一些USB设备，在当前固件的零客户端中是不支持的（说明，零客户端支持所有连接到硬件主机的USB设备）。未来的版本中将会加入这些功能。

根据这些原则，软件主机发送到软件客户端与硬件客户端之间有没有区别？会怎样影响用户体验，主机负载及带宽消耗？

PCoIP协议在软客户端与零客户端在认证是一致的。然而，各种协议特点都是针对主机和客户端进行优化过的。比如，当一个硬件主机连到到零客户端，图像解析是在像素级别。不过，如果连接点是软件，图像会解析以更多像素块为主。这样做是为了缓解软件主机、客户端CPU使用率和在电气上使用相同的协议。软件主机对连接的软、零客户端使用同样的优化，而硬件主机会根据连接的软或零客户端采用不同的优化。

即使在同一经过优化的软件主机上使用两者之一，零客户端占用的主机负载要稍高于软客户端。这是因为零客户端能够处理像素要快于软客户端（在某些情况下大于30倍)。这使得软件主机大部分时间都在全速处理像素。针对软客户端，软件主机产生像素速度不能快于客户端处理能力，因此该PCoIP软件解码主机CPU负载部分表现与客户端处理能力直接相关。这种快与慢的区别明显的表现在软客户端上。事实上，RDP、RFX和ICA在性能好的客户端设备情况下主机负载也有相似的负载。当前，这种稍微的主机CPU负载增加带来客户端“迅捷”表现是值得的。不过，这种CPU影响表现在不受限制的网络中也至多是一个二阶效应。

针对软件主机和软客户端，有没有客户端缓存？相应的硬客户端是怎样的？我之所以问这个是因为在Geek Week(关于软件主机和硬客户端)，我们注意到在Word中滚动，如果你滚动的比较慢只能看到几个“新”无损的滚入页面。这些行在之前的滚动中已经出现在屏幕上了。如果你滚动的非常快，整个屏幕都是无损的，即使这些行之前已经显示在屏幕上了。为什么会是这样呢？

作为解压图片的一部分，PCoIP协议提供移动估计和补偿，在主机端也会试图检查两次屏幕移动之间的像素差别。这是一些微妙的技术原因所形成的方案，但它可能更容易理解为移动检测。检测到的任意移动细节都会将像素从原来的位置复制到新位置并发送到客户端设备。这些都是来自缓存，但是当前只用在之前在屏幕上显示过的像素。

你可以想像，如果你检查屏幕中的所有像素（如一个19×10的屏幕上所有的像素可能有2百万以上）移动检测是非常密集的CPU运算。大多数情况下相对之前的屏幕移动的范围都是很小像素范围，最常用的移动补偿算法都限制在附近区域查找而不是全屏查找。你看到的在滚动速度不够快时的情况是因为像素超越了主机移动算法所查找的范围造成的。在下一版的软件主机中将会采用一个新的算法来使用最小的CPU运算查找更大范围的移动。

重要的一点是移动补偿在客户端是没有CPU限制的，具体像素能移动范围有多大需要更多努力，不管移动一块还是一个像素事实上都改变了屏幕。因此在主机端移动检测算法的改进，在客户端设备都能够方便的利用这些改进的优势。

感谢Randy和Warren抽时间回答我们的问题。他们已经知道这里的相关评论，如果你有更多问题，请在下边提出我们或许可以解答。

原文：PC-over-IP email interview with VMware’s Warren Ponder and Teradici’s Randy Groves