开源远程控制RealVNC源代码中的通讯协议RFB.doc

开源远程控制RealVNC源代码中的通讯协议RFB.doc:..开源远程控制ReaIVNC源代码中的通讯协议RFB(远程帧缓冲)分炎:远程控制业余研究开源软件2014-05-2718:042040人®读评论⑴,远程桌曲总是存在CPU占用率高和W面更新不及时等问题。于是想到了著名的幵源远程控制ReaIVNC它采用了远程帧缓存的协议(RemoteFramebuffer)在网上找到的一段关于RFB的描述RFB是真正意义h的“瘦客机”协议。RFB协议设汁的重点在于减少对客户端的硬件需求。这样客户端就可以运行在许多不同的硬件上,客户机的任务实现上就会尽S的简单。RFB协议对于客户端是无状态的。也就是说:如果容户端从服务器端断丌,那么如果它重新违接相同的服务器,客户端的状态会被保存。甚至,一个不同的客户端可以用来连接相同的RFB服务器。而在新的客户端己经能够获得4前一个客户端相同的用户状态。冈此,川户的应用接口变的非常便捷。只要合适的网络连接存在,那么用户就可以使川自己的应用程序,并且这些应用会一直保存,即使在不同的接入点也不会变化。这样无论在哪,系统都会给用户提供一个熟悉、独特的计算环境。显小•协议显示协议是建立在“把像素数据放在一个由x,y定位的方框内”这单一图形基础之上的。乍一看上去,把这么多的用户接口组件绘制出来是非常低效的方法。但是,允许不同的像索数据编码方式,使得我们在处理不冋的参数(如:网络带宽,客户端的绘制速度,服务器处理速度)有了很人程度的灵活性。通过矩形的序列来完成帧缓存的更新。一次更新代表着从-个可用帧缓存状态转换到刃一个可用,因此有点和视频的桢类似。尽管矩形的更新一般是分开的,但是并不是必须的。显示I办议的史新部分是由客户端通过命令驱动的。也就是说,史新只是在服务器端响应客户端的请求时发生的。这样就让协议更新质量足可变的。客户端/咧络越慢,更新速度也就越慢。对于一些应用来说,相同K域的史新是连续不断的。如果用一个慢的客户端,那么帧缓存的缓存状态是可以被忽略的。这样也可以减少对客户端网络速度和绘制速度的要求。输入I办议输入协议是基丁标准工作站的键盘和鼠标等设备的连接协议。输入事件就是通过把客户端的输入发送到服务器端。这些输入事件也叫以通过非标准的I/0设备米综合。例如,手写笔引擎可能产生一个键盘事件。像索数裾的表示初始的交互涉及到RFB客户端和服务器之间传输像索数据格式和编码方式的协调。这种协调被设计的让客户端的工作尽景简单。而设计的底线是:服务器必须按照客户端的要求格式米提供像紊数据。如果客户端讨以M]样的处理多种数裾格式或编码格式,那么一般会选择服务器端易于生成的格式。像素格式涉及如何通过像素值来劣现不同颜色的重现。最常用的一般像素格式楚24位或16位的“真彩色”,仑通过位來直接实现像素値到红、绿、蓝亮度的转换。8位“颜色映射”可以任意映射像素值到RGB亮度的转换。编码指一个矩形的像素数据如何通过M线传输。毎个像素数据的矩形都加上了一个头,给定矩形在屏幕t的X、丫坐标、矩形的宽和高,以及指定的编码类型。而后数据本身就是采用这种特定的编码方式。数据木身遵循特定的编码。口前的编码方式主要有Raw、CopyRect、RRE、、Hextile和CopyRect,冈为它们提供丫典砸桌面的敁好压缩。其他可能的编码方式还包括,川于静态图片的JPEG和川于动态图像有效传输的MPEG。协议可以通过增加新的编码方式来进行扩展。协议扩展协议可以通过以K方式进行扩展:新的编码方式一种新的协议川*以通过与现存的客户端和服务端进行相关兼容的添加。因为现存的服务器将会忽略它们所不支持的新编码方式。所以客户端通过新的编码方式进行请求也就不会柯结果返凶。仍编硏方式除了真正的编码方式,客户端也可以请求“伪编码”通告服务器,它文持某一协议的扩展。服务器如果不支持这种扩展,那么它将忽略。值得注意的是:客户端必须先假设服务器端不支持这种扩展,直到它获得服务器端支持的确认。新的安全方式添加一个新型的安全方式会带米无限的灵活性,它通过修改协议的一些行为,但是并没有牺牲现存客户端和服务器端的兼容性。客户端和服务器端可以通过I办议好的安全力式进行交流,当然并不一定与RFB协议类似。无论如何你都不应使用不同的版本号。RFB协议的版木是由ReaIVNC公司來制定的。如果你使用一个不同的协议版木可能与RFB/VNC不兼容,要保证协议的兼容性,请联系ReaIVNC公司。这样会减少在编码方式和安全类型上的冲突。I•办议消息RFB协议对以进行可靠的传输,如字节流或基丁•消息的。和大多数协议一样,它也足通过TCP/IP协议簇连接。协议由三步