摘  要： VNC是一個強大的遠程桌面共享工具，能夠讓多個客戶端通過互聯(lián)網(wǎng)查看服務(wù)器端的實時桌面狀況并可以進行遠程操作，但是VNC系統(tǒng)的星形結(jié)構(gòu)使其在實際場景中的可用性大大降低。對VNC系統(tǒng)進行了改進，并在此基礎(chǔ)上提出了一種數(shù)據(jù)傳輸?shù)谋ＷC機制。應(yīng)用驗證表明，其機制在改進后的系統(tǒng)中保證了數(shù)據(jù)能夠?qū)崟r、可靠地傳輸。
關(guān)鍵詞： 數(shù)據(jù)會議；虛擬網(wǎng)絡(luò)計算；數(shù)據(jù)傳輸保證機制

1 VNC系統(tǒng)簡介
    VNC[1](Virtual Network Computing)由著名的AT&T歐洲研究實驗室研發(fā)，由于其平臺的獨立性，在數(shù)據(jù)共享中有著廣泛的應(yīng)用。
　VNC軟件主要由VNC服務(wù)器(VNCServer)和VNC查看器(VNCViewer)兩部分組成。在VNC服務(wù)器上運行欲共享的應(yīng)用，客戶端通過使用遠端幀緩沖器RFB(Remote Frame Buffer)協(xié)議[2]中的輸入?yún)f(xié)議將客戶端的輸入發(fā)送到服務(wù)器端，通過顯示協(xié)議實現(xiàn)遠程桌面的查看和控制，通過像素數(shù)據(jù)的重現(xiàn)實現(xiàn)客戶端和服務(wù)器之間傳輸像素數(shù)據(jù)格式和編碼方式的協(xié)調(diào)。像素數(shù)據(jù)如何通過網(wǎng)絡(luò)傳輸也是通過編碼解決的，數(shù)據(jù)本身遵循特定的編碼。
2 基于VNC的數(shù)據(jù)會議系統(tǒng)
　傳統(tǒng)的VNC體系結(jié)構(gòu)[3]默認采用星形直連方式，由一臺電腦作為服務(wù)器(VNCServer)，多臺電腦作為客戶端(VNCClient)與服務(wù)器相連，由服務(wù)器直接向各個客戶端發(fā)送共享數(shù)據(jù)。
多客戶單服務(wù)器構(gòu)架難以應(yīng)付大規(guī)模并發(fā)客戶，資源集中于服務(wù)器易形成瓶頸，客戶端資源利用率低。VNC是一個開放源代碼的項目，可以根據(jù)需要對VNC加以改進。
2.1 對基于VNC的數(shù)據(jù)會議系統(tǒng)的改進
　由于VNC服務(wù)器端的機器性能和帶寬等多方面原因，在傳輸過程中會造成性能瓶頸，使得以星形直連方式傳輸數(shù)據(jù)的VNC體系在實際的數(shù)據(jù)會議中應(yīng)用困難。為保證在數(shù)據(jù)會議中數(shù)據(jù)傳輸?shù)膶崟r、穩(wěn)定，可在VNC服務(wù)器和VNC客戶端之間設(shè)置一個共享轉(zhuǎn)發(fā)控制服務(wù)器。
    通過設(shè)置中間服務(wù)器，并由中間服務(wù)器擔負著內(nèi)容轉(zhuǎn)發(fā)服務(wù)器和網(wǎng)絡(luò)管理服務(wù)器的兩大功能，可以轉(zhuǎn)移源服務(wù)器性能和帶寬的壓力，同時也可實現(xiàn)統(tǒng)一管理。
2.2 系統(tǒng)數(shù)據(jù)更新機制的選擇
　顯示更新機制[4]包括更新時機及刷新模式。更新時機有客戶端拉動和服務(wù)器端推動兩種。每種技術(shù)又可采用兩種刷新模式，即懶惰更新和急切更新。
更新機制的選擇一般依據(jù)以下準則：
　(1)帶寬較高時優(yōu)先選擇服務(wù)器驅(qū)動的急切更新模式，以便獲得較好的共享效果。
　(2)在較低帶寬下為減少響應(yīng)時間，節(jié)省網(wǎng)絡(luò)帶寬，采用懶惰更新機制，通過放棄或者融合顯示更新來減少數(shù)據(jù)量的傳輸。
　顯示更新機制是數(shù)據(jù)會議質(zhì)量的重要決定因素。要在低帶寬的網(wǎng)絡(luò)條件下保證數(shù)據(jù)會議的質(zhì)量，應(yīng)該選擇客戶端拉動的懶惰更新模式，以保證共享電腦桌面的變化信息能夠?qū)崟r、準確地在客戶端顯示。
3 數(shù)據(jù)傳輸保證機制
3.1 數(shù)據(jù)傳輸過程中出現(xiàn)的問題
　VNC傳輸?shù)臄?shù)據(jù)本身遵循特定的編碼。編碼指一個矩形的像素數(shù)據(jù)如何通過網(wǎng)線傳輸。每個像素數(shù)據(jù)的矩形都加上一個頭，給定矩形在屏幕上的X、Y坐標、矩形的寬和高以及指定的編碼類型。數(shù)據(jù)本身就是采用這種特定的編碼方式。
　改進后的系統(tǒng)共享數(shù)據(jù)由VNCServer傳送到共享轉(zhuǎn)發(fā)控制服務(wù)器，再由共享轉(zhuǎn)發(fā)控制服務(wù)器轉(zhuǎn)發(fā)至每一個VNCClient，并在VNCClient端顯示。數(shù)據(jù)傳輸方式如圖1所示。

　由于數(shù)據(jù)更新模式選擇了客戶端拉動的懶惰更新模式，因此系統(tǒng)中消息的傳輸方式采用基于流的協(xié)議。對于共享轉(zhuǎn)發(fā)控制服務(wù)器來說，系統(tǒng)允許將原始消息積累在一起，形成一個較大的數(shù)據(jù)包。對于VNCClient端，數(shù)據(jù)到達網(wǎng)絡(luò)堆棧就開始讀取并進行解碼顯示。
　編碼方法[5]作為VNC協(xié)議中核心技術(shù)，對遠程圖形顯示具有重要意義，它直接決定了在網(wǎng)絡(luò)環(huán)境下圖像的更新和程序的響應(yīng)速度。通常情況下，壓縮率越高數(shù)據(jù)的網(wǎng)絡(luò)傳輸速率越快，解碼需要的時間越長。
目前的PC機足以滿足編解碼的硬件需求，可以在極短的時間內(nèi)完成編解碼工作。而限制共享效率的主要因素在于網(wǎng)絡(luò)帶寬，所以采用Tight編碼方法，它主要采用Jpeg壓縮算法，壓縮率很高。Jpeg壓縮算法雖然壓縮率高、網(wǎng)絡(luò)傳輸速率快，并可以節(jié)約帶寬，但Jpeg編碼器在進行解碼的過程中必須要保證數(shù)據(jù)的完整性，即必須從每一個數(shù)據(jù)包頭開始解析，否則無法進行解碼工作。
　由于采用被動更新機制，客戶端接收到的共享更新數(shù)據(jù)更新不完成就不會再一次向服務(wù)器發(fā)送更新請求。無法識別接收到的數(shù)據(jù)，就無法完成更新任務(wù)，服務(wù)器接收不到更新請求，不會繼續(xù)向該客戶端發(fā)送數(shù)據(jù)，這樣就會造成客戶端數(shù)據(jù)共享畫面陷入停止的情況，造成數(shù)據(jù)共享的失敗。
　為了避免上述情況的發(fā)生，可以在每一個數(shù)據(jù)包的包頭加入一個特征碼，然后在數(shù)據(jù)接收端進行特征碼解析。通過解析判斷，如果不是包頭，則將數(shù)據(jù)丟棄直至接收到一個完整的數(shù)據(jù)包為止。
3.2 數(shù)據(jù)傳輸保證機制的實現(xiàn)
　在VNCServer端發(fā)送的每一幀數(shù)據(jù)前加一個特征碼用以標識這段數(shù)據(jù)，特征碼的選取采用一個大的質(zhì)數(shù)。由于在數(shù)據(jù)流的傳輸過程中，很可能出現(xiàn)與特征碼相同的數(shù)據(jù)，為了確保標識的正確性，在選定特征碼的基礎(chǔ)上再加入一個隨機數(shù)，將這個隨機數(shù)和特征碼的AND運算作為校驗和。
在發(fā)送端(VNCServer)和接收端(VNCClient)均定義一個名為CharacterCode的結(jié)構(gòu)體。此結(jié)構(gòu)體用于設(shè)定并存儲　特征碼的相關(guān)信息，其結(jié)構(gòu)如下：
Typedef struct CharacterCode
{    char character； //用于存放32 bit特征碼
        char rand_character； //用于存放產(chǎn)生的32 bit隨機數(shù)
        char result_and；//用于存放32 bit校驗和
} Char_Code；
　發(fā)送端工作流程如圖2所示。

　發(fā)送端工作具體步驟如下：
　(1)定義特征碼：0x9e37fffffffc0001UL。
　(2)將特征碼存入Char_Code.character中。
　(3)由rand( )函數(shù)產(chǎn)生兩個隨機數(shù)：unsigned int crc_value1和unsigned int crc_value2，分別存入Char_Code.rand_character和Char_Code.rand_character+4中。
　(4)將Char_Code.character與Char_Code.rand_character逐位做AND運算，將運算結(jié)果存入Char_Code.result_and中。
　(5)發(fā)送更新數(shù)據(jù)。
　接收端工作流程如圖3所示。

　接收端工作步驟如下：
　(1)接收更新數(shù)據(jù)。
　(2)對接收到的數(shù)據(jù)調(diào)用KMP算法進行匹配。
　(3)如果KMP算法匹配失敗，說明這是一段無效數(shù)據(jù)。將接收到的數(shù)據(jù)段丟棄后接收下一幀數(shù)據(jù)。如果KMP算法匹配成功，進行下一步檢驗。
　(4)定義一個8 B的數(shù)組char tmpbuf[8]：tmpbuf[i]=Char_Code.character[i]& Char_Code.rand_character[i]
　(5)將tmpbuf中的值與Char_Code.result_and比較。如果相等則特征碼驗證成功，進行解析；否則丟棄該段數(shù)據(jù)，重新接收下一幀數(shù)據(jù)。
4 數(shù)據(jù)傳輸保證機制的驗證及分析
　該數(shù)據(jù)傳輸機制已應(yīng)用于大連浩視數(shù)字技術(shù)有限公司的網(wǎng)絡(luò)視頻會議系統(tǒng)。經(jīng)測試使用可知其性能穩(wěn)定，滿足數(shù)據(jù)會議的數(shù)據(jù)共享需要。
　實驗平臺為Windows XP操作系統(tǒng)，實驗工具為WIRESHARK、VC6.0。
實驗方法為：通過WIRESHARK捕獲網(wǎng)絡(luò)數(shù)據(jù)，用VC6.0編寫驗證程序。將隨機產(chǎn)生的特征碼與捕獲到的數(shù)據(jù)進行比對，通過對比結(jié)果統(tǒng)計捕獲到的數(shù)據(jù)中出現(xiàn)與特征碼相同的數(shù)據(jù)概率。
如果在捕獲到的數(shù)據(jù)中與特征碼相同的數(shù)據(jù)沒有出現(xiàn)或者出現(xiàn)的概率極低，說明通過該方案可以正確標識一個完整的數(shù)據(jù)包，這樣在接收端解析數(shù)據(jù)時不會受到偽特征碼的干擾，方案具有可行性。實驗結(jié)果統(tǒng)計如圖4所示。

　對圖4的實驗結(jié)果進行分析，并且綜合考慮共享轉(zhuǎn)發(fā)控制服務(wù)器的性能，可將每次發(fā)送的更新數(shù)據(jù)量大小設(shè)置為1M，這樣可以大大減少偽特征碼在數(shù)據(jù)更新過程中的出現(xiàn)幾率。
通過采用基于虛擬網(wǎng)絡(luò)計算的數(shù)據(jù)傳輸保證機制，實現(xiàn)了數(shù)據(jù)的唯一標識，保證了特征碼的唯一性和可靠性，避免了偽特征碼對數(shù)據(jù)解析的干擾。接收端可以正確識別出可解析數(shù)據(jù)，并對不可解析數(shù)據(jù)進行及時處理，滿足了數(shù)據(jù)共享的實時性與可靠性。
　本文通過對VNC傳統(tǒng)體系結(jié)構(gòu)的分析，說明了以VNC傳統(tǒng)體系結(jié)構(gòu)作為數(shù)據(jù)會議中數(shù)據(jù)共享方式的缺陷，并在此基礎(chǔ)上提出了采用共享轉(zhuǎn)發(fā)控制服務(wù)器的新方案。針對在采用共享轉(zhuǎn)發(fā)控制服務(wù)器的方案中選擇以客戶端拉動數(shù)據(jù)更新的懶惰更新模式所出現(xiàn)的問題提供了一種數(shù)據(jù)傳輸保證機制。通過該保證機制，可以使改進后的系統(tǒng)保證在接收端對更新數(shù)據(jù)的讀取和解析，從而實現(xiàn)資源共享的穩(wěn)定和流暢。
參考文獻
[1] RICHARDSON T， STAFFORD-FRASER Q， WOOD K R， et al. Virtual network computing[J]. IEEE Internet Computing： 1998，2(1)：33-38.
[2] 盧小林．基于虛擬網(wǎng)絡(luò)的網(wǎng)管系統(tǒng)集成的設(shè)計與實現(xiàn)[J]．計算機工程，2007，33(3)：82-84.
[3] 孫一波，劉菁．大規(guī)模視頻會議中的多人桌面共享系統(tǒng)的設(shè)計與實現(xiàn)[J]．微計算機信息，2005，21(8)：139-141.
[4] 梁飛碟，李錦濤．瘦客戶計算應(yīng)用協(xié)議中遠程顯示機制的比較[J]．計算機工程與應(yīng)用，2004，40(21)：135-137.
[5] 梁飛碟，李錦濤，史紅周．虛擬網(wǎng)絡(luò)計算(VNC)協(xié)議中的編碼方法[J]．計算機應(yīng)用，2004，24(6)：93-95.