RFB协议对于客户端是无状态的。也就是说,如果客户端从服务器端断开,那么如果它重新连接相同的服务器,客户端的状态就会被保存。甚至,一个不同的客户端可以用来连接相同的RFB服务器。而在新的客户端已经能够获得与前一个客户端相同的用户状态。因此,用户的应用接口变得非常便捷。
只要合适的网络连接存在,用户就可以使用自己的应用程序,并且这些应用会一直保存,即使在不同的接入点也不会变化。这样无论在哪,系统都会给用户提供一个熟悉、独特的计算环境。
1.显示协议
显示协议是建立在“把像素数据放在一个由x,y定位的方框内”这个单一图形基础之上的。乍一看去,把这么多的用户接口组件绘制出来是非常低效的方法。但是,允许不同的像素数据编码方式,使得在处理不同的参数(如网络带宽、客户端的绘制速度和服务器处理速度等)时有了很大程度的灵活性。
通过矩形的序列可完成帧缓存的更新。一次更新代表从一个可用帧缓存状态转换到另一个可用帧缓冲状态,因此有点和视频的帧类似。尽管矩形的更新一般是分开的,但是并不是必须的。显示协议的更新部分是由客户端通过命令驱动的。也就是说,更新只是在服务器端响应客户端的请求时发生的。客户端/网络越慢,更新速度也就越慢。对于一些应用来说,相同区域的更新是连续不断的。如果用一个慢的客户端,那么帧缓存的缓存状态是可以被忽略的。这样也可以减少对客户端网络速度和绘制速度的要求。
2.输入协议
输入协议是基于标准工作站的键盘和鼠标等设备的连接协议。输入事件是通过把客户端的输入发送到服务器端的。这些输入事件也可以通过非标准的I/O设备来综合。例如,手写笔引擎可能产生一个键盘事件。
3.像素数据的重现
初始的交互涉及到RFB客户端和服务器之间传输像素数据格式和编码方式的协调。这种协调的设计使客户端的工作更简单。而设计的底线是:服务器必须按照客户端的要求格式来提供像素数据。如果客户端可以同样处理多种数据格式或编码格式,那么一般会选择服务器端易于生成的格式。
像素格式涉及如何通过像素值来实现不同颜色的重现。最常用的像素格式是24位或16位的“真彩色”,它通过位来直接实现像素值到红、绿、蓝亮度的转换。8位“颜色映射”可以任意映射像素值到RGB亮度的转换。
编码主要用来解决像素数据如何通过网络传输的问题。每一个矩形像素数据都带有X、Y参数,表示矩形的宽和高,编码类型确定了像素数据的编码方式。数据本身遵循特定的编码。
目前的编码方式主要有Raw、CopyRect、RRE、Hextile和ZRLE。在实际应用中,一般使用ZRLE、Hextile和CopyRect,因为它们提供了典型桌面的最好压缩。(www.xing528.com)
4.协议扩展
协议可以通过以下方式进行扩展。
(1)新的编码方式
一种新的协议可以通过与现存的客户端和服务端进行相关兼容的添加。因为现存的服务器将会忽略它们所不支持的新编码方式。所以,客户端通过新的编码方式进行请求也就不会有结果返回。
(2)伪编码方式
除了真正的编码方式,客户端也可以请求“伪编码”通告服务器,它支持某一协议的扩展。服务器如果不支持这种扩展,那么它将忽略。值得注意的是,客户端必须先假设服务器端不支持这种扩展,直到它获得服务器端支持的确认。
(3)新的安全方式
添加一个新型的安全方式会带来无限的灵活性,它通过修改协议的一些行为,但是并没有牺牲现存客户端和服务器端的兼容性。客户端和服务器端可以通过协议好的安全方式进行交流,当然并不一定与RFB协议类似。
5.协议消息
RFB协议可以进行可靠的传输,如基于字节流或基于消息的。和大多数协议一样,RFB协议也是通过TCP/IP协议簇连接的。协议由3步完成连接。首先是握手报文,目的是对协议版本和加密方式进行协商。第2步是初始化报文,主要用于客户和服务器的初始化消息。最后是正常协议的交互,客户端可以按需发送消息,然后获得服务器的回复。所有的消息都以消息类型开始,接下来是特定的消息数据。
协议消息描述的基本类型有U8、U16、U32、S8、S16和S32。U表示无符号整数,S表示有符号整数。所有的字节整数(除了像素值本身)都遵从Endian顺序。
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。