大漠落日

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

RFB內(nèi)容還包括了以下各式協(xié)定：

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

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

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

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

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

新的安全型態(tài)
協(xié)定在新新增一個安全型態(tài)時有很大的彈性，而不必?fù)?dān)心Client及Server的相容性問題。當(dāng)Client及Server 都這同了新的安全型態(tài)後，雙方在資料交換方面將更加有效率，並不見得每一項工作都需依照RFB協(xié)定。

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


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

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

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

VNC認(rèn)證
連線時，隨送傳送16位元的VNC認(rèn)證，而協(xié)定資料不做加密的動作。Server會隨機產(chǎn)生一個16 byte的要求Client回應(yīng)特定的訊息。Client依據(jù)Server傳送過來的16 byte編碼為金鑰，並加密回傳此金鑰以回應(yīng)Server。而此更協(xié)定依據(jù)項些安全性協(xié)定的回應(yīng)持續(xù)進行下去。

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

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

ServerInit：
Server 接受ClientInit訊息後，會接著發(fā)送ServerInit訊息，此訊息會告知Client端Framebuffer的長、寬、像素格式以及此桌面相關(guān)名稱。

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

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

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

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

ClientCutText

Server訊息


Server to client messages
Server傳送給Client的訊息包函在下列變數(shù)中：
FramebufferUpdate
SetColourMapEntries
Bell
ServerCutText

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

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

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

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

ServerCutText

編碼
文件中所定義的編碼型態(tài)包括：
Raw
CopyRect
RRE
Hextile
ZRLE
Cursor pseudo-encoding
DesktopSize pseudo-encoding

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

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

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



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

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

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

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