搜尋此網誌

2009年9月24日 星期四

RFB -- VNC的基礎

RFB (Remote Framebuffer)
為一種簡單的遠端存取協定,讓使用者以圖像的方式存取遠端電腦。此協定運作於Framebuffer層級,因此能夠應用於所有的視窗介面,其包括X11、Windows及Macintosh。VNC即是RFB協定一種應用。
要求連線,並得到遠端畫面的一方稱之為Client或是Viwer,對相的另一端稱之為RFB Server。RFB實為一種「Thin-Client」的協定,此重點在於建立一個功能上需求極精簡的Client,在這方面,Client可以應用於更廣泛的硬體上,而Client的功能愈簡單愈好。  RFB協定同時使得Client成為一種「stateless」的形態,假若Client中斷連結後,隨及再度連結同個Server,Client端的畫面將會保留。此外,不同的Client允許對同樣的RFB Server做連結。在新的端點上的使用者會看到與Server主機相同的畫面,實際上,這樣的介面讓使用者更能夠任意的改變位置。不論如何,只要得到合適的網路連線,使用者就能夠任意存取個人應用軟體,這些應用軟體能夠在兩地之間做到存取的動作,不過何處,都能提供使用者熟悉的、客製化的視覺基礎。

RFB內容還包括了以下各式協定:

Display Protocol
顯示協定的基礎圍繞在原始單一圖像(single graphics primitive):
  『將某區塊的像素資料,設定至(x,y)位置上』
在最初看來,以這種方式繪出使用者介面似乎會是個無效率的方法。然而,允許多種不同的編碼方式,對於像素資料處理中,交換參數值方面得到了相當大的使用彈性,例如頻寬、Client繪圖速度、Server 處理速度等。  給定一串序列的資料可對Framebuffer做更新的動作。而每一次的更新,都會將舊有的Framebuffer更動至另一種狀態,這方面有點類似一段影片中的影格(Frame),基本上每個區塊都不會相交,但還是會有不一定的狀況出現。  更新協定為一種「需求導向」的協定,意思是說「在Client要求更新時,訊息只會由Server發送」,這方式使得此協定能有最合適的通訊品質,慢速Client會更新的較慢。一般應用程式在Framebuffer相同區段改變時,會變換的較其他區段來的快速,若是在傳輸緩慢的網路中,Framebuffer的更新可能會被乎略掉。

Input protocol
輸入以標準工作工如鍵盤、多按鈕裝置為主。Client在任意地點,按下按鍵或是點座標裝置移動時,都會對Server發送要求訊息。這些被輸入的訊息亦可由非標準輸入裝置發送,整合為可被Server接受的編碼。

Display pixel data
RFB在開始送傳資料前,Client及Server 會對將被傳送的像素資料的格式及編碼方式做協調,這部份的協調是為了讓Client端的工作愈簡單愈好,Server必需提供Client最基本的像素資料的需求,假若 Client本身能夠應付其他多種編碼方式,Server則會選擇最簡單易行的編碼方式來做傳送的動作。  像素資料包函個別顏色內容,最普遍的顏色格式如「真彩」的24-bit及16-bit,每個bit區段直接轉為RGB對應的強度色彩。  「編碼」(encoding)會影響區段內的像素資料如何傳送,每個像素資料區塊都預先被指定一個(x,y)螢幕位置,而區塊的長、寬、編碼都將被指定在像素資料的資料區塊中,而區塊資料也會依據指定的編碼方式編碼。

Extension protocol
在此有多種方法能夠擴展協定:
新增一個編碼的型態對於現有的Client及Server來說是相對上的容易做到,只不過Server會自動乎略它不支援的新編碼型態,而Client也不會去求要一個新的編碼方式,因此不會產生這種編碼方式的資料區塊。

編碼資料中對於偽編碼(Pseudo Encodings),Client可以對Server要求“pesudoencoding”,宣告其本身支援這一類型的擴充協定;假若Server不支援”pseudo-encoding”則會略乎此編碼。該注意的是Client必需假設Server不支援這類的擴充,直到Client從Server取得真正完成擴充認證。

新的安全型態
協定在新新增一個安全型態時有很大的彈性,而不必擔心Client及Server的相容性問題。當Client及Server 都這同了新的安全型態後,雙方在資料交換方面將更加有效率,並不見得每一項工作都需依照RFB協定。

在任何情況下使用不同版本的協定
RFB協定的版本主要被維護人員定訂,假若你的協定與Server使用了不正確的版本號碼,雙方將無法相容。最重要的一點在於確認RFB協定的相容性,以確保編碼及安全型態不會發生衝突。


協定訊息
RFB協定可以依任何可靠的定協傳送資料 (如TCP/IP),即使byte-streamor。正常來說RFB主要透過TCP/IP達成連線。完成一個RFB協定有三個步驟:第一步為「handshaking phase」,此階段主要是去同意協定的版本及使用的安全型態;第二步為「initialization phase」,即對Server與Client互相交換「ClientInit」及「ServerInit」的訊息。第三步為「normal protocol interaction」,Client將能夠傳送任何它想傳送的訊息,然後接受Server回傳的結果。

協定版本
「Handshaking Phase」開始前,Server會傳送ProtocolVerstion的訊息給Client,使得Client能夠知道Server端支援RFB的最高版本,隨而Client回應Server可使用的版本號碼(不一定與Server的版本號碼相同),正常來說,Client不該要求高於Server端RFB的版本。

安全
一定協定版本確認後,Client、Server在連線時,必需協議共同的安全性標準。假若Client支援的安全性協定有在Server列舉的安全性協定清單中,Client會回傳單一byte的訊息告知Server某安全性協定可被用於這次的連結。  在進行Handshaking Phase時,不論這一階段的連成是否成立,Server都會傳送一個字串通知Client,假若連線成立,RFB協定即進行下一階段──Initialization Phase.
假若安全性連線失敗,Server則傳送一則字串描述此異常,隨後終止連結。

VNC認證
連線時,隨送傳送16位元的VNC認證,而協定資料不做加密的動作。Server會隨機產生一個16 byte的要求Client回應特定的訊息。Client依據Server傳送過來的16 byte編碼為金鑰,並加密回傳此金鑰以回應Server。而此更協定依據項些安全性協定的回應持續進行下去。

訊息初始化
當Client、Server建立安全性連結後,接著會進行初始化層段(initialsation phase)
這個階段,在Client傳送一個「ClientInit」,Server隨即會傳送「ServerInit」訊息。

ClientInit:
Client回應的訊息只有一個「shared-flag」參數,若值非「0」(true),則表式Server試著去持續共享桌面而不對其他的Client端做終止連線的動作,反之,若值為「0」(false),則表示終止其他連線,僅對某Client端提供桌面分享的服務。

ServerInit:
Server 接受ClientInit訊息後,會接著發送ServerInit訊息,此訊息會告知Client端Framebuffer的長、寬、像素格式以及此桌面相關名稱。

Client給Server的訊息內容
由Client所發出的訊息形態如下:
SetPixelFormat
SetEncodings
FramebufferUpdateRequest
KeyEvent
PointerEvent
ClientCutText
此外,其他仍有需要另行定義的訊息形態,需注意的是假如一則訊息形態沒有事先定義在Client的文件中,Client需確定Server傳送此特定的訊息形態後,Client仍能夠有效的支援。

Client端訊息
SetPixelFormat
設定像素資料後,接會會被置入Framebuffer中的FramebufferUpdate,假若Client沒有送出SetPixelFormat資料,Server在送出像素資料時將會依據即定的像素格式(格式請參考文件6.3.2)。
SetEncodings
指定可被Server接受的編碼格式。而設定於送給Server訊息中的編碼格式將會是雙方做連結時,編碼格式的首選,但此編碼不一定會被Server選擇。即使沒有明確指定,像素資料都會以row的方式被傳送。此外,Client可對原始編碼資料做「偽編碼」(pseudo-encodings)的要求,以告知Server本地端支援此類型的擴充,假若Server不支援此「偽編碼」的類型則會直接乎略不使用。需注意的是,Client必需假設Server端不支援Client原始的編碼型態,直到Server認同Client端的原編碼型態後,Client才能夠使用此編碼型態。

FramebufferUpdateRequest
Client端對Server提出請求,以了解Server端寫入Framebuffer中的x-position、y-position、width、height數值。Server會以「FramebufferUpdate」對Client端做回應,但需注意的是,多個FramebufferUpdateRequest可能只會由單一一個FrameBufferUpdate回應。  Server會假設Client不斷的截取存放在Framebuffer中Client所需求的部份(x-position,y-position,width,height),因此Server僅需要對Client傳送不斷更新的部份。  但在某些狀況下,Client遺失某特別需求的部份,Client將傳送一則「FramebufferUpdateRequest」訊息,其中參數incremental幫需設為「0」(false),這會對Server請求傳送某指定的Framebuffer的全部內容。  假若Client沒有遺失Framebuffer中任何必要的部份,則傳送FramebufferUpdateRequest時incremental的內容值將會是非0值(true),假若Framebuffer的內容有所更新,Server亦會傳送一個FramebufferUpdate訊息。這裡需注意的是「雙方發某更新訊息的時間是不固定的」。  在快速網路的狀況下,Client會去範規更新傳送的速度以避免獨佔頻寬。

KeyEvent
假若鍵盤按鍵按下,Framebuffer中Down-flag參數值將會是非0值(true),反之則否。其中由X Window所定義的「keysym」值,被指定用於KeyEvent,作為所謂的按鍵「key」。一般來說,這裡的keysym的key值等同於ASCII所訂定的內容值。keysyms並不容易了解,為了提高keysyms能被廣泛的利用,需要注意以下事項:
1、「shift」的狀態(不論shift是否被按下),在keysym動作時應該被視為「背景執行」。舉例來說,要按下US鍵盤的「#」需要按住「shite + 3」,但UK鍵盤則不需按下shift。假若server端為US鍵盤,想要從使用UK鍵盤的Client接收一個「#」號,Client將不會有shift被按下的動作。在這狀況下,Server為了取得一個「#」而非數字「3」,將會內部將shift設為「已按下」。
2、在keysym中,大小寫的區別常非重要。這不同於某些鍵盤於X Window下將大小寫視為相同的狀況。例如,Server接收keysym值中的大寫「A」時,即使沒有按下shift也該認為是大寫的「A」,這代表的是此時,server內部需假定已按下了shift。
3、Server應該呼略keysyms中的「lcok」,如CapsLock和NumLock,且應該依據不同的狀況來解釋每一個接收到的keysyms字元。
4、不同於shift的其他修飾鍵如「Ctrl」、「Alt」等,一樣需要用來反應keysyms值,要注意的是在keysyms中沒有如「ctrl+a」之類的值,這些值(ctrl、alert)只能在Client按下a後跟著被傳送出去。
5、以Client端來說,當他們按下Ctrl或Alt時同樣會產生keysyms中的某些字元,而Client可能需要另外傳送「Release」事件以確保傳送的keysym值能夠正確被Server了解。例如,在German PC鍵盤上,「Ctrl+Alt+q」會產生「@」,在這狀況下,Client需要為「Ctrl」或「Alt」傳送一個假的「release Ctrl」、「release Alt」訊息給 Server以確保keysym值正確被Server解釋。
6、在X Window裡,「backword tab」並沒有通用的標準,在某些系統裡,shift+tab會產生「ISO Left Tabe」的keysym值,其他系統則可能產生「Back Tab」或僅僅產生「Tab」值,或是由應用程式從shift的狀態來判別「backword-tab」而不是「forward-tab」。在RFB協定採用最後一種方式,Client應該產生shifted Tab而不是ISO Left Tab。然而,為後符合backward-compatible的Client,Server應該懂得判別ISO Left Tab同於另一種shift Tab。
PointerEvent
標示如「點的移動」或「點按鈕的按、放」等。點的位置設定於(x-position,y-position),而目前1~8的按鈕狀態由bits0~7的按鈕遮罩所表示,0代表放開,1代表按下。以滑鼠來說,按鈕1、2、3分別對應至左鍵、中鍵、右鍵等。以有滾輪的滑鼠來說,每一個「向前滾動」的動作都代表按下、放開「按鈕4」,向後滾動則以「按鈕5」來表示。

ClientCutText

Server訊息


Server to client messages
Server傳送給Client的訊息包函在下列變數中:
FramebufferUpdate
SetColourMapEntries
Bell
ServerCutText

需注意的是在傳送一則沒有定義於Server文件中的訊息前,Server需要從Client取得「extension specific」,以確定Client在接收後能夠支援此編碼,對此,通常會對Client要求一個偽編碼(pseudo-encoding)。

FramebufferUpdate
一個FramebufferUpdate的內容主要包函一序列的像素矩陣資料(Client必需將這些像素資料填入Client端的Framebuffer),而這一則命令主要在Client發出FramebufferUpdateRequest後產生,需注意的事Update及UpdateRequest的發送時間並沒有明確的定義。

SetColourMapEntries
像素格式若使用「colour map」時,訊息將會告訴Client端其指定的像素值必需對應至指定的RGB強度。

Bell
觸發Client端的Bell物件(若Client有此物件)

ServerCutText

編碼
文件中所定義的編碼型態包括:
Raw
CopyRect
RRE
Hextile
ZRLE
Cursor pseudo-encoding
DesktopSize pseudo-encoding

各編碼內容:
Raw encoding
此為最簡單的編碼型態。此編碼主要包括width x height像素值(Server端產生的四方體,其長、寬的值),這兩項變數值表示每畫面的像素值,並由左至右做線性排列。所有的RFB Client必需能夠去處理Raw編碼中的像素資料。而RFB Server也應該只以Raw編碼為編碼方式,除非Client要求其他的編碼方式。

CopyRect encoding
CopyRect(copy rectangle)編碼屬於簡單且有效率的編碼方式,能夠於Client在Framebuffer中有相同區塊的像素資料中使用。這項編碼方式會先在填入Rect的X,Y標,這動作將使Framebuffer得到一個位置,隨後Client可以取得Rect的像素資料。這項編碼可以用於Client畫面不斷變動狀況,當使用者移動某視窗,或是捲動視窗捲軸時,更能明顯看出此編碼的效果,但若用於對視窗最佳化、重繪圖像等動作時,就不會有明顯畫面變化的效果。Server對圖像只做一次最正確的傳送是最正確的作法,接著要知道這個圖像先前於Framebuffer的位置(x,y),最後使用CopyRect編碼傳送更新的Framebuffer敘述(subsequent)。

RRE encoding
RRE指rise-and-run-length,其基礎在於模擬一段的二維編碼。RRE編碼所包函的rectangle會以能夠被簡易的繪圖engines有效率而快速繪製的形式到達Client端。  RRE編碼的缺點在於無法適用於複雜的桌面,但仍能使用於某些狀況。RRE編碼的基礎在於分割某像素資料的rectangle成多個副屬的rectangle,每一個副屬的rectangle都包括了各別區塊的像素內容,而將這些副屬的rectangle組合後,將會得到原始的rectangel,這些最適的副屬區塊相對的容易被計算出來。這項編碼包括背景像素值,



Hextile encoding
Hextile編碼為RRE的一種延伸,其將rectangle分成16 x 16的區塊,可令其大小為每邊區塊4 bit,而一個被化分出來的rectangle共16bit。每個rectangle由左上開始往右下計算,先左而右,由上至下,而編碼的內容都會依據先前的rectangel排列模式做排列。假若一個rectangle的寬度並非16的倍數,則最後一個rectangel在劃份後的寬度將會小於16。高度的原理同於寬度。  每個區塊不管以Raw編碼或是RRE編碼都會有背景像素值(background pixel),若背景像素的數值同於前一區塊,則不需特別設定至新的區塊中。另一個狀況:若傳送資料是以Raw編碼,背景像素值則不需要做任何設定。假若所有的副屬區塊(subretangle)都擁有相同的背景像素值,可當做整個區塊的前景顏色像素值,僅做一次性的設定;前景像素可同於背景像素的指定方式,其不需特別設定至區塊中,可從前一個區塊中取得。假若先前的區塊是Raw或是SubrectColored的設定,當下的區塊就不會特別前景像素設定至當下的區塊中,但會以AnySubrects從前一區塊取得前景像素(假定前一區塊已經從更前面的區塊取得前景像素值)。

ZRLE encoding
ZRLE代表的是Zlib1 Run-Length Encoding,擁有Z-lib的壓縮、劃分區塊的能力。在傳送的序列資料中,每個區塊由4 byte長的標頭開始,隨後接著由z-lib壓縮的資料。每個單z-lib序列物件主都會在RFB協定的連結中產生作用,所以編碼、解碼需定訂嚴格的順序。  Z-Lib的資料在解壓後,會產生64 x 64的區塊,其值由左至右、由上至下排列(同於Hextile),若資料的長寬bit數不是64的倍數,則最後一個區塊的長寬將會小於64 bit。  ZRLE利用CPIXEL(compressed pixel)技術,這方法同於一般的像素格式,其中所有的bit由(r,g,b)構成,不管(r,g,b)強度為何,true-colour-flag的值不會是0,bitperpixel的值是32,depth值會在24以下。ZRLE中,一個CPIXEL只會有3 byte的長度,亦可能包函最低顯著或最高顯著的(r,g,b)值。bytePerCPixel為ZRLE中CPIXEL的bytes數。  每個區塊以subbencoding type byte開始,假若區塊編碼的起始byte有做過任何設定,則代表此區塊已運行過或是已被清除等等。區塊最底部的7個位元指定著色的範圍,0代表沒有做任何著色;1代表區塊使用單一色系,2~127表示區塊共使用了多少的顏色。

Pesudo-encodings
Cursor pseudo-encoding
Client若對Server發送這一則指令,即表示Client將有能力在本地端劃出server mouse的位置,這能夠在慢速的連線中明顯提升畫面呈現的效果。Server傳送FreamebufferUpdate時,會同時在Cursor pseudo-encoding設定pesudo-rectangle的內容回應Client的更新要求。pesudo-rectangle的內容包函x-position及y-position,其指出server端Cursor的位置,而width、height分別為Cursor的像素,並依據bitmask來設定資料的內容(所謂的bitmask,其內容主要是由左向右、由上至下對像素值做線性排列。

DesktopSize pseudo-encoding
Client端對Server請求DesktopSize pseudo-encoding以告知本地端可應付Framebuffer中width、height值變動的狀況。Server通常會將這一個pseudo-rectangle設定至最後一個Framebuffer資料的DesktopSize pseudo-encoding中,而此項目中pesudo-rectangle的x-position及y-position會被乎略,width及height值會告知新的Framebuffer大小。

2009年9月17日 星期四

VNC (Virtual Network Computing)

參考文件:
http://www.cl.cam.ac.uk/research/dtg/attarchive/pub/docs/att/tr.98.1.pdf

Thin Clients
VNC追求以「Thin Client」的架構,將用戶端的各項處理程序減至「極小」,Client端可任易對server做connect或disconnect的動作,而不影響server的效能。VNC的Client可於任意地點連上Server,即使是在地球的另一面端,只需使用行動裝置就能夠搖控Server。當然,除了VNC以外,另外如使用Citrix ICA Protocol的各式Thin Cline Application(例如Winframe and Insignia Solutions’ Ntrigue)也能達到這些需求,但這些應用的共同缺點是使用了特有的Protocol,以致產生了跨平臺的問題,VNC則否。

VNC Protocol
VNC底層的技術以非常簡單的Protocol實行GUI遠端存取,以Framebuffer的層級動作,卻可以應用於所有的作業系統、視窗作業系統及應用軟體等,確保任何形式的通訊連結。這項協定可透過如TCP/IP這一類可靠的通訊協定運作,終端使用者中,UI操作者我們可稱之為「VNC Client」或是「viewer」;終端機不斷傳送改變中的Framebuffer則叫做「VNC Server」。VNC確實可稱作是「Thin-Client」的系統架構,其中讓Client端以極少量的需求讓多種裝置得以運作遠端搖控。

初始圖像
在協定中,終端顯示基於最初始的單一圖像:

  產生一個虛擬四邊型物件,並給定一個(x,y)座標

一開始總認為這不是一個很有效率的呈現方式,但以網路頻寬、Client繪圖速度、Server處理速度來說,這方式在參數傳送時卻可能提供較大的彈性。像素資料以簡單的「Left to Right」的序列方式掃摸傳送,所有的VNC用方端必需支援這樣的編碼方式,然後這編碼的使用必需依存Client及Server之間的通訊狀況。
舉例來說,server在「copy-rectangle encoding」時非常簡單而有效率,若Client的Framebuffer已存有相同的的序列時,更可以直接使用已存的內容值。這些編碼只是算單的(x,y)序列。這篇編碼通常產生於使用者改變視窗內容後。
Client必需支援「Copy-rectangle encoding」,Client-Server即可簡單被實現,更加節省頻寬,比傳送原送資料還有更加迅速。  其中有一種狀況,即Client端無法讀取(讀回)已使用過的Framebuffer,此時Client無法傳送先前的編碼。
典型的工作站桌面已固的大量資料如現在的顏色、文字等。最有效的編碼方法是將主要的顏色(背景色)與他不同的產色分開傳送。這裡有多種不同的編碼方式。也許使用JPEG做固有圖像的顯示,或是使用MPEG以影像方式呈現。暫存相同的文字資料,使得圖像在第一次產生改變時,圖像資料可以有效的編碼以快速應付多次的改變。

更新
每次傳送的圖像資料會對Framebuffer內容更新,並對有一個有效的Framebuffer狀況做出變動,換句話說,這個動作相似於影像影格的變換,但與影格不同的地方在於「更新的區域」僅僅為Framebuffer中的一小塊,每個方塊可能使用不同的編碼。Server因此可為為螢幕選擇最適合的傳送方式及適用的頻寬做傳輸。這樣的協定對Client是必要的,Client向Server提出更新的求要,Server因而發送更新後的Framebuffer,所有的視窗的資料在Client最近一次求要之後,會匯整成單一的一筆更新資料,使得協定得到最適資料:速度較慢的Client,更新速度愈慢。在一個網路速度快的環境中,使用者視窗的變化在Client端會有流暢的顯示效果;反之,若使用播接網路,Client要求更新的頻率將會減少,意思是說「慢速度Client,移動視窗的最終結果可能直接呈現出來」。

輸入
VNC協定的輸入端建立於標準的工作站模組之下,鍵盤、多按鈕裝置為主。無論何時,當Client發出按鍵訊息、移動點座標裝置,都會對Server發出訊息。輸入訊息亦可被非標準I/O裝置發送。

連結的建立與結束
建立連結前,Server會對Client使用「challenge-response」的方式請求認證;而Client端的使用者通常需要輸入密碼。接著Server與Client開始交換訊息,洽談視窗大小、像素、編碼方式等等,最後Client會要求Server視窗狀況的更新。由於Client端不需回報「狀態」,任何一方可以直接終斷連結而不會產生異常。

VNC Viewers
此處說的「Viewer」指的即是「Client」,VNC中要產生一個Client是非常容易的事情,原因在於VNC要求「Thin-Client」架構。Client只要求能夠確實做到通訊(TCP/IP),並且擁有直接「顯示畫面」的小功能即可(直接繪出Framebufeer或是透過windowin system繪製)。

VNC Servers
由於VNC架構中,為了讓Client功能愈精簡愈好,因此建立VNC Server會比建立一個VNC Client稍難一些(例如Server必需額外提供Client所需求的Pixel Data 格式)。

2009年9月13日 星期日

簡介RDP(Remote Desktop Protocol)-遠端桌面協定

RDP(Remote Desktop Protocol) Wiki :
http://zh.wikipedia.org/wiki/%E9%81%A0%E7%AB%AF%E6%A1%8C%E9%9D%A2%E5%8D%94%E5%AE%9A

RDP可譯為 Remote Desktop Protocol或Remote Display Protocol,兩者涵義相同,此協定簡單的說就是「微軟遠端桌面服務」。此協定可分為Server及Client兩部份。此外,XP 擔任 RDP Server 預設只能有一個 Client 登入,如果需要多人同時登入需要安裝其他的軟體(WinConnect XP)。Windows 2003 Server 可提供多人同時登入,連線的數量根據購買的連線版權。

以下取自Wiki內容:

使用者(用戶端或稱「本機電腦」)連上提供微軟終端機服務的電腦(伺服器端或稱「遠端電腦」)。大部份的Windows都有用戶端所需軟件。其他作業系統也有這些用戶端軟件,例如LinuxFreeBSDMac OS X。伺服端電腦方面,則聽取送到TCP 3389埠的資料。

與遠端桌面協定相容的用戶端可在多種作業系統上執行,許多Linux系統上甚至將RDP用戶端功能列為核心功能之一。此外,使用者也不一定要有寬頻網路才能連上他們的遠端電腦桌面,RDP即使在56K撥接網路下,都還可以提供每秒更新五到六個畫面的效果。

相較於VNC(Virtual Network Computing) :
藉由網路,可傳送鍵盤與滑鼠的動作及即時的螢幕畫面。VNC與作業系統無關,因此可跨平台使用,例如可用Windows連線到某Linux的電腦,反之亦同。甚至在沒有安裝用戶端程式的電腦中,只要有支援JAVA瀏覽器,也可使用。

VNC Wiki:http://zh.wikipedia.org/zh-hk/VNC