桌面訊息的變動偵測與壓縮傳送

(1)

國立交通大學

電信工程學系

碩士論文

桌面訊息的變動偵測與壓縮傳送

Detection of Change of Desktop Content and

Compress Transmission

研究生：蔡文賢

指導教授：張文鐘教授

(2)

桌面訊息的變動偵測與壓縮傳送

Detection of Change of Desktop Content and Compress

Transmission

研究生：蔡文賢 Student：Wen-Hsien Tsai

指導教授：張文鐘

Advisor：Wen-Thong Chang

國立交通大學

電信工程學系

碩士論文

A Thesis

Submitted to Department of Communication Engineering College of Electrical and Computer Engineering

National Chiao Tung University in Partial Fulfillment of the Requirements

for the Degree of Master of Science

in

Communication Engineering August 2008

Hsinchu, Taiwan, Republic of China

(3)

桌面訊息的變動偵測與壓縮傳送

學生：蔡文賢

指導教授

：

張文鐘

博士

國立交通大學電信工程學系碩士班

摘

要

遠端桌面技術提供相當便利的功能。外地的使用者只需要使用此技術，便可操控遠處電腦，不受限於在本地端操作，因此只要有權限的使用者皆可使用。遠端桌面技術最重要的部分在於取得 Server 變動畫面，並傳送給 Client，因此，本論文針對這部分進行深入探討。在 Server 端，使用了 Windows API 函數來輔助我們取得可能變動範圍，和增加額外判斷區域，以這兩個機制縮小我們需比對的可能範圍，在比對後取得真正變動區域後會進行畫面資料的壓縮傳送。論文另一部分是針對遠端桌面共有的問題：播放視訊檔案會造成網路流量大幅激增，因此，我們要加入 JPPEG 破壞性壓縮來處理畫面資料，而 JPEG 對影像部分較無影響，我們在傳送更新畫面時分為影像和非影像區兩類，當要更新的部分落入播放器區域會以 JPEG 破壞性壓縮；沒有落入播放器區域則以原定編碼方式傳壓縮資料。此論文是以 VNC 為平台，分為三部分：一、說明 Server 和 Client 間的運作流程；二、詳細探討 VNC Server 如何偵測桌面上真正變動畫面的區塊，和如何壓縮畫面資料傳送給 Client；三、針對畫面變動的視訊播放區域，加入 JPEG 壓縮，改善播放視訊時資料量爆增的問題，並提昇傳輸速度和品質。

(4)

Detection of Change of Desktop Content and

Compress Transmission

Student：Wen-Hsien Tsai

Advisors：Dr.

Wen-Thong Chang

Department of Communication Engineering

National Chiao Tung University

ABSTRACT

Remote Desktop Technology provides a very convenient function. Outside users through this technology can control remote computer without restriction of operation at local side. Therefore, anyone with authorization can remote control their computer wherever. The most important part of remote desktop technology is that how to get change of desktop of Server and transfer them to Client. Consequencely, this thesis will focus on this issue. On Server side, we use Windows API to adminicle to get probably change region and add extra region. Through this two mechanism can reduce region that we need to compare. After comparing, we can get real change part and compress them for transmitting.

The other problem of remote desktop technology, it’s playing video files will induce network flow huge increase. Therefore we add JPEG to compress image data.we divide into video and non-video part. When update part fall into video part, then we use JPEG. Otherwise we use original encoder to compress data.This thesis is based on Virtual Network Computing (VNC), it's composed of three parts: 1. Explain how VNC Server and Client work, 2. Detail discuss detects changed blocks on desktop, and how to compress these blocks to send to client. 3. We add JPEG algorithm which aimed at video playing areas to improve the problem that amount of data increased extremely when playing video files, and improve transfer speed and quality.

(5)

誌謝

在此最最最感謝的就是我的指導教授張文鐘博士，感謝他提供我完善的資源，和一切所須的設備，讓我在二年碩士生涯中，學業課程和研究無後顧之憂，並在論文的盲點上，點出許多可能的解決方向。同時也謝謝廖維國教授、黃仲陵教授、和范國清教授在口試時的指導，老師們真是我研究過程中的一盞明燈，讓我可以順利完成此論文。接著要感謝實驗室裡的同學和學弟們，blue、明山、政達、峻權、振偉、夸克、志偉、盛如、honda、秉謙、建民、小瘋，感謝他們陪我渡過修課、趕作業報告、寫論文的這兩年，沒有他們在我失落或瓶頸時的支持和鼓勵，我可能沒辦法支撐下去，因此感謝你們給我這麼美好的回憶，期許我們一起成長前進。感謝我的家人，父母親、姊姊，他們是我的支柱，在研究所兩年中，提供我一切生活所須，有如一股無形的力量支撐著我，讓我心無旁騖地研究，順利地完成論文。最後感謝我的室友們，明山、維庭、冠勳，在兩年的共同扶持和幫助，也感謝所有認識的知心好友、運動的球友、和其他實驗室的朋友，謝謝你們陪我走過這段時光。謝謝！

誌於 2008.08 風城交大

Wen-Hsien

(6)

中文摘要中文摘要中文摘要中文摘要 ... i 英文摘要英文摘要英文摘要英文摘要 ... ii 誌謝誌謝誌謝誌謝... iii 目錄目錄目錄目錄... iv 表目錄表目錄表目錄表目錄... vi 圖目錄圖目錄圖目錄圖目錄... viii 第一章第一章第一章第一章緒論緒論緒論緒論...1 1.1 動機動機動機 ... 1 動機 1.2 研究背景研究背景研究背景研究背景 ... 2 1.3 論文架構論文架構論文架構論文架構 ... 2 第二章第二章第二章第二章遠端桌面和相關背景知識遠端桌面和相關背景知識遠端桌面和相關背景知識遠端桌面和相關背景知識... 3 2.1 遠端桌面程式介紹遠端桌面程式介紹遠端桌面程式介紹遠端桌面程式介紹 ... 3 2.1.1 VNC...3 2.1.2 RDP ...4 2.1.3 X Window ...5 2.1.4 遠端桌面程式比較遠端桌面程式比較遠端桌面程式比較 ...6 遠端桌面程式比較 2.2 RFB Protocol ... 7 2.2.1 RFB Protocol 組成要素組成要素組成要素組成要素 ...8 2.3 Win32 API... 10 2.3.1 視窗程式建立流程視窗程式建立流程視窗程式建立流程視窗程式建立流程...10 2.3.2 訊息迴圈訊息迴圈訊息迴圈 ...12 訊息迴圈 2.3.3 WM_PAINT...14 2.3.4 Hook...17 第三章第三章第三章第三章 VNC Server...20 3.1 VNC Server 運作流程和架構運作流程和架構運作流程和架構運作流程和架構 ... 20 3.2 vncSockConnectThread ... 24 3.2.1 TCP/IP 連線建立連線建立連線建立連線建立...24 3.2.2 vncSockConnectThread 啟動啟動啟動啟動 ...24 3.3 vncClientThread... 25 3.3.1 vncClientThread 的的的 Initialization ...26 的 3.3.2 Client to Sever 訊息的種類和處理訊息的種類和處理訊息的種類和處理 ...29 訊息的種類和處理 3.4 vncDesktopThread... 29 3.4.1 vncDesktopThread 啟動啟動啟動啟動 ...30 3.4.2 vncDesktopThread 畫面處理流程畫面處理流程畫面處理流程畫面處理流程...35 3.4.3 變動畫面偵測變動畫面偵測變動畫面偵測變動畫面偵測...40 3.4.4 SendUpdate...47

(7)

第四章第四章第四章第四章 VNC Client ... 52 4.1 VNC Client 介紹介紹介紹介紹... 52 4.2 VNC Client 運作流程運作流程運作流程運作流程 ... 55 4.2.1 Initialization...56 4.2.2 Client 訊息處理迴圈訊息處理迴圈訊息處理迴圈訊息處理迴圈...60 4.3 VNC Viewer 細部工作原理細部工作原理細部工作原理... 61 細部工作原理 4.3.1 Viewer 畫面更新畫面更新畫面更新畫面更新...61 4.3.2 Viewer 觸發畫面更新觸發畫面更新觸發畫面更新觸發畫面更新要求要求要求 ...63 要求 4.3.3 鍵盤鍵盤鍵盤鍵盤、、、滑鼠動作訊息、滑鼠動作訊息滑鼠動作訊息...65 滑鼠動作訊息第五章第五章第五章第五章 Server 和和和和 Client 的溝通訊息的溝通訊息的溝通訊息... 67的溝通訊息 5.1 Handshaking Phase... 67 5.2 Initialization Phase... 69 5.3 Interaction Phase ... 71 5.3.1 Client 送給送給送給送給 Server 的訊息的訊息的訊息...72 的訊息 5.3.2 Server 送給送給送給送給 Client 的訊息的訊息的訊息 ...76 的訊息 5.4 VNC 內建壓縮方法和資料封包內建壓縮方法和資料封包內建壓縮方法和資料封包內建壓縮方法和資料封包... 78 第六章第六章第六章第六章實做與實驗數據分析實做與實驗數據分析實做與實驗數據分析實做與實驗數據分析 ... 84 6.1 問題論述和改善方法問題論述和改善方法問題論述和改善方法問題論述和改善方法 ... 84 6.2 實作過程和改進實作過程和改進實作過程和改進... 85 實作過程和改進 6.2.1 實作過程說明實作過程說明實作過程說明 ...86 實作過程說明 6.2.2 衍生問題研究和解決衍生問題研究和解決衍生問題研究和解決衍生問題研究和解決...91 6.3 最後數據分析比較最後數據分析比較最後數據分析比較... 96 最後數據分析比較第七章第七章第七章第七章結論結論結論結論... 98 7.1 結論結論結論... 98 結論 7.2 未來發展未來發展未來發展未來發展 ... 98 參考文獻參考文獻參考文獻參考文獻 ... 100 附錄一附錄一附錄一

(8)

表

表目錄

表 5-12.PIXEL_FORMAT ... 72 表 5-11.SetPixelFormat ... 72 表 5-13.SetEncodings... 73 表 5-14.Encoding-Type ... 73 表 5-15.FramebufferUpdateRequest ... 73 表 5-16.KeyEvent ... 74 表 5-17.一些常用的鍵 ... 75 表 5-18.PointerEvent ... 75 表 5-19. ClientCutText ... 76 表 5-20.Server 傳給 Client 的訊息種類 ... 76 表 5-21.其他有定義的訊息種類 ... 76 表 5-22.Framebufferupdate... 76 表 5-23.每個矩形標頭資料 ...77 表 5-24.SetColourMapEntries ...77 表 5-25.對應 Colour 的 RGB 值 ...77 表 5-26.Bell ...77 表 5-27.ServerCutText ... 78 表 5-28.壓縮種類... 78 表 5-29.RAW ... 79 表 5-30.CopyRect... 79 表 5-31.RRE...80 表 5-32.RRE 的子結構 ...80

(9)

表 5-33.subencoding 遮罩... 81 表 5-34.BackgroundSpecified... 82 表 5-35.ForegroundSpecified ... 82 表 5-36.AnySubrects ... 82 表 5-37.SubrectsColoured... 82 表 6-1.VNC 內部壓縮方法流量統計 ... 85 表 6-2.SetEncodings ... 86 表 6-3.改善後的流量 ...91 表 6-4.壓縮和解壓縮時間... 92 表 6-5.模擬 SetPixelV()後的流量統計 ... 96 表 6-6.所有方法的流量統計 ... 96 表 6-7.RDP 和 VNC 的流量統計比較 ... 96

(10)

圖

圖目錄

圖 3-17.Pollingcycle 狀態 ... 38 圖 3-18.初始狀態 ...41 圖 3-19.還原小算盤...41 圖 3-20.rgncache 記錄的座標大小... 42 圖 3-21.Server 初始狀況... 42 圖 3-22.mplayer 的變動訊息... 43 圖 3-23.rgncache 狀態 1 ... 43 圖 3-24.Hook 偵測到的初步變動範圍 ... 44 圖 3-25.螢幕四等分 ... 44 圖 3-26.第一、二次觸發的範圍 ... 45 圖 3-27.第三、四次觸發的範圍... 45

圖 3-28.Poll foreground window 累加範圍 ... 45

圖 3-29.原始圖... 46

圖 3-30.Poll Window Under Cursor 累加範圍 ... 46

圖 3-31.SendUpdate 流程圖... 47

圖 3-32.Region1 示意圖 ... 48

圖 3-33.使用 GetRegionData 函數後 ... 48

(11)

圖 3-35.toBeSent ... 50

圖 3-36.FramebufferUpdate 訊息...51

圖 4-1.Server and Client... 52

圖 4-2.Client Screen Update Request... 54

圖 4-3.Client 流程圖... 55 圖 4-4.Initialization ... 56 圖 4-5.CreateDisplay... 57 圖 4-6.CreateLocalFramebuffer()... 58 圖 4-7.Initial Viewer... 59 圖 4-8.Viewer 畫面更新 ... 62 圖 4-9.Copy to Screen ... 63 圖 4-10.觸發畫面更新訊息 ... 64 圖 4-11.SetDormant()函數 ... 65 圖 4-12.Mouse Event... 66 圖 4-13.KeyEvent ... 66 圖 5-1.RRE...80 圖 5-2.Hextile 編碼... 81 圖 6-1.Client 透過 SetEncodings 訊息通知... 86 圖 6-2.Server 判斷是否啟動 JPEG... 87 圖 6-3.toBeSent 示意圖... 87 圖 6-4.取得組合 toBeSent 的矩形資料 ... 87 圖 6-5.取得視訊播放區域 ...88 圖 6-6.矩形是否落入視訊播放區域 ... 89 圖 6-7.交叉可能 ... 89 圖 6-8.其他狀況...90 圖 6-9.啟動 JPEG 或原本 VNC 的壓縮 ...91 圖 6-10.vncDesktopThread... 93 圖 6-11.初步範圍... 94 圖 6-12.模擬 SetPixelV()函數... 95

(12)

第一章

第一章緒論

緒論

1.1 動機

動機

在結合網路和電腦後，產生了相當便利的應用程式—遠端桌面技術！透過遠端桌面技術，我們能看到遠端電腦的桌面，即 Client 連線時，Server 會透過網路將螢幕上的畫面，完完整整地呈現給 Client。而 Client 可使用滑鼠和鍵盤直接操控，且 Client 端的硬體需求不高，因此，通過此技術可把一台即將淘汰的 486 轉換成能運行大型科學計算軟體的超級電腦。實現此遠端桌面技術最關鍵部分在於取得 Server 的變動畫面，並將資料傳送給 Client 更新。Server 端可以定時透過 GDI 一連串程序，取得桌面完整畫面並和前一次畫面做比較，如此即可針對真正變動部分並傳送，但這種做法相當耗費 CPU 的效能和時間，從這個角度出發，本論文要先探討如何縮小比對的範圍。因桌面是由許多 process 組合而成，1. 我們透過 Windows 的 API，截取所有 Windows 送出的訊息，這些訊息會包含著通知 process 中元件需要更新畫面變化的區域；2. 接著再額外增加處理範圍，如將整個前景程式的視窗範圍皆加入判斷，目的在務必比對處理我們最關注的區域。以上機制是我們使用來取得可能的變動區域，達到縮小需要比對範圍的目的，只要我們比對前後畫面這些可能的區域範圍，即可取得真正有變動部分。取得真正變動畫面範圍後，接著我們要探討另一問題：使用遠端桌面技術播放視訊檔案，畫面劇烈變動會造成網路傳輸量大幅激增，因此我要們加入破壞性壓縮 JPEG 來改善此嚴重問題。而畫面是由文字和圖片組合而成，如果皆對他們使用破壞性壓縮，因圖片高頻部分被捨去所造成的影響不大，但文字部分則會產生難以忍受的模糊，因此本論文另部分要對這些影像和非影像做區別壓縮。在取得真正變動畫面後，要先判斷 Server 端是否有開啟播放器，接著取得播放器在桌

(13)

面上的位置區域，只要真正變動的部分落在播放器裡就以 JPEG 壓縮，沒有落入的部分則以原定編碼方式，如此便可有效區分出影像和非影像部分，對他們進行差別壓縮。

1.2 研究背景

研究背景

目前市面上有許多的遠端桌面程式，如 VNC、 Microsoft 的 RDP 、 X Window…等，這些程式各有優缺點，本論文則是以 open source 的 VNC 為架構， VNC-Virtual Network Computing，為什麼選擇它呢？因為它有能力得到桌面的畫面，偵測出多視窗中何者變動、變動的範圍，將這些區塊的 pixel 資料加以壓縮，來降低資料量並傳送給 Client，而最讓人稱道的是：跨平台，只要 VNC Server 和 Client 兩邊皆遵守 RFB Protocol，就可透過 VNC Client 和 Windows、Linux、 Unix、甚至 Mac 連線！

1.3 論文架構

論文架構

本論文以 VNC 為主要架構，詳細說明一套遠端桌面系統的形成，因此分成幾個章節來詳細闡述。第二章先介紹市面上常見的遠端桌面程式，和他們之間的一些比較，接著說明要瞭解 VNC 所需要的 Win32 API；第三章是此論文的重心，詳細剖析 VNC Server 的整個運作結構、如何偵測實際變動畫面和如何傳送更新畫面的壓縮資料，第四章則講解 Client 的運作流程、變動畫面的更新、和如何透過滑鼠、鍵盤操控 Server；第五章將 Server 和 Client 間所有溝通訊息分為三大 Phase，分別詳細介紹和說明；第六章針對目前遠端桌面系統最大問題：播放視訊資料時，造成傳輸資料量爆增，提出改進方法：針對視訊畫面部分做 JPEG 壓縮，說明實作過程和各個數據的比較；第七章則是為本篇論文作出結論。

(14)

第二章

第二章遠端桌面和相關背景知識

遠端桌面和相關背景知識

此章節一開始，先簡略介紹市面上常見的遠端桌面程式，接著說明 VNC 所遵循的 RFB Protocol，和要完全瞭解 VNC 所需的背景知識。2.1 節先簡單介紹 VNC、RDP、X Window 三個遠端桌面程式，並針對他們畫面更新的方式做綜合比較；2.2 節則是說明 VNC 所遵循的 RFB Protocol，它大略由 Display、Input、 Pixel Format、溝通訊息四大部分所組成；2.3 節會將 VNC 內常用到的背景知識加以講解，如：Win32 程式建立的流程、視窗與視窗間溝通原理、畫面重畫訊息、和 Windows 的 API-Hook。

2.1 遠端桌面程式介紹

遠端桌面程式介紹

目前市面上有許多遠端桌面程式，在此就不一一介紹，僅選出較常用的三個來介紹，並淺要地分析他們的原理，和比較各項特點

2.1.1 VNC

Virtual Network Computing（VNC）是現行的遠端桌面連線系統之一，最初發展是在 1995 年由英國劍橋的 Olivetti & Oracle 實驗室發展出來，公開且免費的通訊協定，至今已發展多種版本，為跨平台的遠端桌面連線程式。

VNC 透過 Remote Frame Buffer (RFB) Protocol[1]控制遠端的電腦，VNC 為一套跨平台的應用程式，在操作端安裝 VNC Viewer 就是我們所說的 Client，在遠端的電腦安裝 VNC Server，允許多台 Clients 在同一個時間連接同一個 Server，另外，也可透過 JAVA Applet 使用網路瀏覽器連接到安裝 VNC Server 的電腦。VNC 的架構可以分為 VNC Server 和 VNC Client（Viewer），彼此溝通的通訊協定為 RFB Protocol。

(15)

●VNC Server：負責接收 Client 傳送過來的鍵盤或是滑鼠的輸入訊號後，並提供一套桌面分享機制，透過 TCP/IP 傳送畫面改變的資料到 Client。

●VNC Client：根據收到的資料，在將 Client 端顯示 Server 的畫面，並依照接收到的資料做更新。

●RFB Protocol：一個簡單的原則，將 Server 端某塊寬(W)、高(H)點陣圖 (bitmap）的資料，放到螢幕指定的 X、Y 座標上。

2.1.2 RDP

Remote Desktop Protocol，簡稱 RDP [2]。RDP 是微軟根據 ITU T.120 協

議系列所制定的一套未公開發表的數據通訊協議。透過網路連接 RDP Server 將應用程式顯示畫面傳送到 RDP Client，RDP Client 將滑鼠、鍵盤等輸入訊息傳送給 RDP Server。在畫面傳送上，是以命令（order）為操作方式，可以分為 primary order 和 secondary order，Primary order 主要的工作在於處理線條、矩形或是出現過的點陣圖和文字，Secondary order 則是傳遞首次出現的 bitmap 和文字。在終端服務的桌面圖形傳輸上，畫面中 bitmap 的傳送，可以說是主要的資料量。

RDP 的 bitmap 傳送方式有兩種方式：

1.

RDP Server 先利用 secondary order 的 bitmap cache 將 bitmap 傳送到

RDP Client 暫存起來，隨後傳送一個 memory blt 將 cache 中 bitmap 資料，依據 cache id 和 cache index 取出指定的 bitmap，顯示在螢幕對應的位置上，主要畫面傳送都是利用這樣的方法。

(16)

2.

RDP Server 直接傳送 bitmap 資料，並給予座標位置，RDP Client 收到後，直接將資料顯示在畫面上。傳遞的 bitmap 通常為視窗的外框或是工作列表邊緣線，因此，在畫面傳送上佔很小的比例，這部份的畫面更新方式稱為 bitmap updates。

2.1.3 X Window

X Window 系統（也常稱為 X11 或 X）是一種以點陣圖方式顯示的視窗系統 [3]。最初是 1984 年麻省理工學院的研究，之後變成 UNIX、Linux 等作業系統所一致適用的標準化軟體工具套件及顯示架構的運作協定，經過二十多年的演進，現今已成為工業標準。X Window 與一般的作業系統不同，在設計時就是以 Client/Server 為理念，整個 X Window 可以分為幾個部份：X Server、X Client、 X Protocol 和 X Library。

● X Server：負責控制顯示卡將影像畫在顯示器上，並且管理鍵盤和滑鼠的事件，產生視窗、對應視窗及刪除視窗，這部份要特別說明，與一般的 Client/ Server 名詞定義有點差異，X Server 定義為 Display Server，而應用程式端稱為 X Client。

● X Client：在 X Window 下的應用程式，要求特定的 X Server 作特定的動作。主要的工作為：1、向 X Server 提出需求，2、接收來自 X Server 的事件訊息，3、接收來自 X Server 的錯誤訊息。

● X Protocol：X Client 和 X Server 的通訊協定，定義 Requests、Reply、 Error 和 Events。

● X Library：簡稱 X Lib，大部分 X window 上的應用程式以 X Library 來建立 GUI 元件，例如：按鈕（bottom）、目錄（menus）等等。

(17)

2.1.4 遠端桌面程式比較

遠端桌面程式比較

根據先前介紹的遠端桌面系統，這節將對系統特性以及更新方式做個比較。

1. 畫面更新方式

畫面更新方式

Server 和 Client 之間的畫面更新方式可以分為以下幾種： ● RAW：所有的更新圖片，不經過壓縮編碼，每個 pixel 的資料依序傳送，可以想像資料量很大，假設傳送一張 640 x 480 大小的 16 位元高彩圖片，就需要 614.4K Bytes。VNC 有支援這樣的編碼方式機制。 ●2D draw primitives：利用區塊填色的方法將圖形編碼，通常是一種非失真編碼的方式，VNC 畫面編碼主要是以這樣的方法。

●Low level graphic：除了圖形編碼的方法之外，還利用一些簡單的指令，例如：字型、多邊形、線條等等的指令呼叫 Client 繪圖，RDP 便是利用這樣的更新方式進行畫面更新。

●High level graphic：除了 2D draw primitives 和 Low level graphic，還支援視窗的建立和管理，X Window 所利用的 X Protocol 就是屬於這類。

2. Server/Client 訊息傳遞方式

訊息傳遞方式

Server 和 Client 的訊息傳遞方式主要可以分為兩種，Server Push 就是由 Server 主動決定何時傳送更新畫面到 Client；Client Pull 就是由 Client 向 Server 要求傳送更新，使用 Server Push 的系統，其畫面更新較為平順但是相對資料量較大，而 Client Pull 則是只有在使用者輸入訊息時，才會通知 Server 作畫面更新的傳送，但是其資料量較少。

瞭解了畫面編碼方式及系統更新方式，根據這些特點我們將針對這幾個系統做分析比較，說明如表 1.。[4]

(18)

表 2-1.遠端桌面系統比較系統畫面編碼方式更新方式壓縮方式 cache license VNC Compressed Pixel Data Client pull 2D draw primitives Client frame buffer GPL RDP Low level graphics Server

push 2D RLE YES proprietary

X window High level

graphics

Server

push none No GPL

2.2 RFB Protocol

VNC 的信令、溝通格式、編碼…等，完全是依照「RFB Protocol」所規定，因此，不論是任何版本的 VNC 皆須遵照此 protocol。RFB(Remote Frame Buffer) 是一個定義遠端圖形用戶終端介面的簡單協定，因為它是用在 FrameBuffer 上，所以它適用於所有視窗作業系統和視窗程式，包括：X11、Windows 和 Mac。使用者端稱為 RFB Client，另一端則是 FrameBuffer 的源頭，可以是視窗系統和程式，稱為 RFB Server，如圖 1。圖 2-1.VNC 系統架構 RFB Protocol 設計時考量的重點中，就強調 Client 端只需要相當少的需求，因此它可應用於廣泛的硬體上，目前市面上更出現相關的軟體，如 Smart VNC，讓手機也可以連上個人電腦，其方便性可見一斑。

(19)

2.2.1 RFB Protocol 組成要素

組成要素

此小節要初步介紹構成 RFB 的幾大要素。

1. Display Protocol

Display Protocol 是以一個很原始且簡單的概念為基礎：「將 server Framebuffer 中，一個矩形所有的 pixel 資料，放在所屬 client 對應的位置上」。由許多的矩形組成一張完整的 Framebuffer，直覺上可能很沒效率，但深入探討後，當畫面只有一些小區塊變動而不是整張 Framebuffer，此時只需更新那區塊的矩形，加上其允許不同的編碼格式，提供了網路頻寬、使用端畫面更新和伺服端處理速度，相互間的取捨！

FrameBuffer 的變動，會促成 Server 送出一連串矩形的更新，但這個更新的機制是由 Client 為需求導向，即 Client 送出要求更新的訊息，Server 才會將資料送出。一般在本地端，更新 Framebuffer 是很快速的一個接著一個，Client 只需要持續的接收資料、解封包、更新本地端的畫面，接著再送出更新的需求，對於較次一級的 Client 或網路，當 Client 端更新速度跟不上 Server 端 Framebuffer 變化時，一些 Framebuffer 的暫態會被忽略掉。

2. Input Protocol

Protocol 的輸入端，是由標準的一組鍵盤，和多按鍵的點選裝置所組成！輸入的事件，無論使用者何時按了按鍵或移動裝置，都只由 Client 端傳送訊息給 Server 端。輸入裝置也可以是不標準的 I/O，如手寫板，他們的辨識引擎會自動產生鍵盤的對應事件，因此 Server 還是可以正確的判斷！

(20)

3.

Pixel 資料表示

資料表示

在 pixel 資料要被傳送時，RFB Client 和 Server 溝通中會包括格式和編碼，這個溝通是為了讓 Client 的工作簡單化而設計。底線是 Server 要提供 Client 想要的 pixel 資料格式，如果 Client 有能力處理許多不同的格式和編碼，它會選一個 Server 較容易產生的。

(1) Pixel 格式：個別顏色如何用 Pixel 值來表示，最常見的格式是 24-bit 或 16-bit，這些 bit 會直接被轉譯成紅、綠、藍的顏色。而 8-bit 的”colour map”，可以通過 mapping，把 pixel 值轉成 RGB 的顏色！

(2)編碼：一個矩形的 pixel 資料如何被傳送。每一個矩形的 pixel 資料，會先用一個標頭記錄這個矩形在螢幕中 X、Y 的位置、長、寬，和編碼的種類，而編碼資料會接在標頭之後被傳送出去。常用的編碼種類有 Raw、CopyRect、 RRE、Hextile 和 ZRLE。一般都是使用 ZRLE、Hextile、CopyRect，因為他們提供最佳的壓縮效率！

4.

溝通訊息

RFB Protocol 可以應用在任何可靠的傳輸中，一般是在 TCP/IP 上。

這個 Protocol 總共會有三個階段：

(1)Handshaking Phase：用來確認 protocol 的版本和安全性的種類 (2) Initialization Phase： Client 和 Server 會互相傳送初始化的訊息

(3)Normal protocol interaction： Client 可以傳任何他想送的訊息，Server 會回傳結果！所有這些訊息都會以 message-type 為開端，接著才是訊息的資料！

(21)

Protocol 的訊息都是以以下幾種種類表示：U8、U16、U32、S8、S16、S32 各別是 unsigned 8、16、32bits 、signed 8、16、32bits，而所有多 bytes 都是以 big endian 來排序！ PIXEL 則是一個 pixel 值所需的 bytes 數，即 BytesPerPixel。

2.3 Win32 API

因為 VNC Server 和 Client 中，有許多功能需借用 Windows 的函數來完成，如取得程式視窗的大小；畫面變動偵測，會用到訊息溝再來取得 Hook 偵測到的變動範圍；透過 GDI 將桌面的 Framebuffer 存成 RGB 的記憶體陣列…等，還有許許多多要借用 Win32 的 API，因此此節要介紹較重要的 API，其他部分則會在後續的章節陸續介紹。

2.3.1 視窗程式建立流程

視窗程式建立流程

此小節要介紹和一個很重要的概念：Handle，和完整 Win32 程式建立流程。 ●Handle 概念視窗程式全都是模組化的程式--每個視窗元件，例如選單、捲軸、按鈕等，都是一個獨立的個體，每個個體或元件都有自己的資料和函數，由於一個程式有可能會有多個相同種類的元件(例如一個程式裡有很多按鈕)，那麼在眾多相同的元件中，要決定控制哪個元件，就需要設定 Handle，來指明控制哪個元件，例如視窗程式的主視窗，就需要一個 Handler，來指明使用者現在正控制該程式的視窗，而非其他，故 Handler 的概念非常重要。

(22)

●Win32 程式建立流程[5] int PASCAL WinMain(……)

{ HWND hwnd; //宣告程式的 Handle

MSG msg; //宣告 MSG 結構來存放訊息 WNDCLASS wc;//宣告類別結構

InitWindow( …) ) //創建主窗口

while (GetMessage(&msg, NULL, 0, 0)) //訊息迴圈 { TranslateMessage(&msg); //解析 msg

DispatchMessage(&msg); //呼叫訊息處理函數 }

}

每個程式都會有一個 (只此一個) 程式進入點 (Entry Point) ，而 Windows API 程式的進入點為 WinMain 。進入後會先宣告三個相當重要的參數， HWND、MSG、WNDCLASS，分別是程式最重要的 handler、溝通訊息的結構、和視窗程式的風格。這三個參數在往後程式運作過程中都佔有相當大的重要性。接著在 InitWindow(…)中，會先對類別結構 WNDCLASS 做設定，然後調用 RegisterClass()對該類別進行註冊。因為每個視窗程式都有一些基本的屬性，如視窗邊框、標題欄文字、視窗大小和位置、滑鼠圖示、背景色、處理視窗的訊息函數名稱等等。註冊的過程也就是將這些屬性告訴系統，然後再調用 CreateWindow()函數創建出此視窗。這也就象你去裁縫店訂做一件衣服，先要告訴店老闆你的身材尺寸、布料顏色、以及你想要的款式，然後他才能為你做出一件讓你滿意的衣服。以上初始化完成後，視窗建立大致上結束，接著會進入訊息迴圈，然後一直重覆截取訊息、解析、呼叫訊息處理函數，再回到截取…，直到收到使用者要結束時所發出的關閉訊息，才會離開此迴圈結束程式。

(23)

2.3.2 訊息迴圈

訊息迴圈

承接上節，此節詳細闡述訊息迴圈的過程。 Windows 應用程式可以接收以各種形式輸入的資訊，這包括鍵盤、滑鼠動作、記時器產生的訊息，也可以是其他應用程式發來的息等等。Windows 系統自動監控所有的輸入設備，並將其訊息放入該應用程式的訊息佇列中。 ●GetMessage() GetMessage()函數則是用來從應用程式的訊息佇列中按照先進先出的原則將這些訊息一個個的取出來，放進一個 MSG 結構中去。GetMessage()函數原型如下：[6] BOOL GetMessage( LPMSG lpMsg, //指向一個 MSG 結構的指標，用來保存訊息 HWND hWnd, //指定哪個視窗的訊息將被獲取 UINT wMsgFilterMin, //指定獲取的主訊息值的最小值 UINT wMsgFilterMax //指定獲取的主訊息值的最大值 ); GetMessage()將獲取的訊息複製到一個 MSG 結構中。如果佇列中沒有任何訊息，GetMessage()函數將一直空閒直到佇列中又有訊息時再返回。如果佇列中已有訊息，它將取出一個後返回。MSG 結構包含了一條 Windows 訊息的完整資訊，其定義如下：

typedef struct tagMSG {

HWND hwnd; //接收訊息的視窗控制碼 UINT message; //主訊息值 WPARAM wParam; //副訊息值，其具體含義依賴於主訊息值 LPARAM lParam; //副訊息值，其具體含義依賴於主訊息值 DWORD time; //訊息被投遞的時間 POINT pt; //滑鼠的位置 } MSG;

(24)

該結構中的主訊息表明了訊息的類型，例如是鍵盤訊息還是滑鼠訊息等，副訊息的含義則依賴於主訊息值，例如：如果主訊息是鍵盤訊息，那麼副訊息中則儲存了是鍵盤的哪個具體鍵的資訊。 GetMessage()函數還可以過濾訊息，它的第二個參數是用來指定從哪個視窗的訊息佇列中獲取訊息，其他視窗的訊息將被過濾掉。如果該參數為 NULL，則 GetMessage()從該應用程式的所有視窗的訊息佇列中獲取訊息。第三個和第四個參數是用來過濾 MSG 結構中主訊息值的，主訊息值在 wMsgFilterMin 和 wMsgFilterMax 之外的訊息將被過濾掉。如果這兩個參數為 0，則表示接收所有訊息。當 GetMessage()函數在獲取到 WM_QUIT 訊息後，將返回 0 值，程式將退出訊息迴圈。 ●訊息處理函數 TranslateMessage()函數的作用是把虛擬鍵訊息轉換到字元訊息，以滿足鍵盤輸入的需要。DispatchMessage()函數的工作是把當前的訊息，發送到該應用程式對應的訊息處理函數去。

LRESULT CALLBACK WindowProc( //訊息處理函數

HWND hwnd, //接收訊息視窗的控制碼 UINT uMsg, //主訊息值 WPARAM wParam, //副訊息值 LPARAM lParam //副訊息值 ) { switch( uMsg ){ case WM_KEYDOWN: ……. //擊鍵訊息

case VK_ESCAPE: ……… //按下 ESC

case WM_RBUTTONDOWN: …… //滑鼠訊息

case WM_PAINT:…… //視窗重畫訊息

case WM_DESTROY:…… //退出訊息

Default：DefWindowProc(hWnd, uMsg, wParam, lParam); } }

(25)

Windows 的訊息處理函數有一個確定的樣式，即這種函數的參數個數和類型以及其返回值的類型都有明確的規定。訊息處理函數的四個參數是由 GetMessage()函數從訊息佇列中獲得 MSG 結構，然後分解後得到的。第二個參數 uMsg 和 MSG 結構中的 message 值是一致的，代表了主訊息值。程式中用 switch 語句來將不同類型的訊息分配到不同的處理程式中去。值得注意的是，應用程式發送到視窗的訊息遠遠不止以上這幾條，像 WM_SIZE、WM_MINIMIZE、WM_CREATE、WM_MOVE 等這樣常常使用的訊息就有幾十條。為了減輕編寫程式的負擔， Windows 的 API 提供了 DefWindowProc()函數來處理這些最常用的訊息，調用了這個函數後，這些訊息將按照系統默認的方式得到處理。因此，在 switch_case 語句中，只須明確的處理那些有必要進行特別回應的訊息，把其餘的訊息交給 DefWindowProc()函數來處理，是一種明智的選擇,也是你必須做的一件事。 ●結束訊息迴圈當用戶按 Alt+F4 或單擊視窗右上角的退出按鈕，系統就向應用程式發送一條 WM_DESTROY 的訊息。在處理此訊息時，調用了 PostQuitMessage()函數，該函數會給視窗的訊息佇列中發送一條 WM_QUIT 的訊息。在訊息迴圈中， GetMessage()函數一旦檢索到這條訊息，就會返回 FALSE，從而結束訊息迴圈，隨後，程式也結束。

2.3.3 WM_PAINT

Windows 裡有各種功能的訊息，功能和格式各有不同，限於篇幅，這邊就不一一贅述，但遠端遠桌面系統最重要的便是得知畫面變動，進而壓縮這些區域傳送給 Client，因此此節要介紹和畫面更新最相關的訊息：“WM_PAINT“[7]。

(26)

●WM_PAINT 訊息 Windows 通過發送 WM_PAINT 訊息通知視窗訊息處理程式，視窗的部分顯示區域需要繪製。在 Windows 中，只能在視窗的顯示區域繪製文字和圖形，而且不能確保在顯示區域內顯示的內容會一直保留到程式下一次有意地改寫它時還保留在那裡。例如，使用者可能會在螢幕上移動另一個程式的視窗，這樣就可能覆蓋您的應用程式視窗的一部分。Windows 不會保存您的視窗中被其他程式覆蓋的區域，當程式移開後，Windows 會要求您的程式更新顯示區域的這個部分。視窗訊息處理程式應在任何時刻都準備好處理其他 WM_PAINT 訊息，必要的話，甚至重新繪製視窗的整個顯示區域。在發生下面幾種事件之一時，視窗訊息處理程式會接收到一個 WM_PAINT 訊息： 1. 在使用者移動視窗或顯示視窗時，視窗中先前被隱藏的區域重新可見。 2. 使用者改變視窗的大小 3. 程式使用 ScrollWindow 或 ScrollDC 函式滾動顯示區域的一部分。 4. 程式使用 InvalidateRect 或 InvalidateRgn 函式刻意產生 WM_PAINT。

在某些情況下，顯示區域的一部分被臨時覆蓋，Windows 試圖保存一個顯示區域，並在以後恢復它，在以下情況下，Windows”可能”發送 WM_PAINT 訊息： 1. Windows 擦除覆蓋了部分視窗的對話方塊或訊息方塊。 2. 功能表下拉出來，然後被釋放。 3. 顯示工具提示訊息。在某些情況下，Windows 總是保存它所覆蓋的顯示區域，然後恢復它。這些情況是： 1. 滑鼠游標穿越顯示區域。 2. 圖示拖過顯示區域。

(27)

程式應該組織成可以保留繪製顯示區域需要的所有資訊，並在 Windows 給視窗訊息函數發 WM_PAINT 訊息時才進行繪製。如果程式在其他時間需要更新其顯示區域，它可以強制 Windows 產生一個 WM_PAINT。 ●Update Region 儘管視窗訊息處理程一旦接收 WM_PAINT 訊息之後，就準備更新整個顯示區域，但它經常只需要更新一個較小的區域。顯然，當對話方塊覆蓋了部分顯示區域時，情況即是如此。在擦除對話方塊之後，需要重畫的只是先前被對話方塊遮住的矩形區域。這個區域稱為“Invalid Region“或更新區域。正是顯示區域內無效區域的存在，才提示了 Windows 將一個 WM_PAINT 訊息放在應用程式的訊息佇列中。只有在顯示區域的某一部分失效時，視窗才會接受 WM_PAINT 訊息。 Windows 內部為每個視窗保存一個“繪圖資訊結構“，這個結構包含了包圍無效區域的最小矩形的座標以及其他資訊，這個矩形就叫做“無效矩形“，有時也稱為“無效區域“。如果在視窗訊息處理函數處理 WM_PAINT 訊息之前顯示區域中的另一個區域變為無效，則 Windows 計算出一個包圍兩個區域的新的無效區域，並將這種變化後的資訊放在繪製資訊結構中。Windows 不會將多個 WM_PAINT 訊息都放在訊息佇列中。視窗訊息處理程式可以通過呼叫 InvalidateRect 使顯示區域內的矩形無效。如果訊息佇列中已經包含一個 WM_PAINT 訊息，Windows 將計算出新的無效矩形。否則，它將一個新的 WM_PAINT 訊息放入訊息佇列中。在接收到 WM_PAINT 訊息時，視窗訊息處理函數可以取得無效矩形的座標。通過呼叫 GetUpdateRect，可以在任何時候取得這些座標。

(28)

在處理 WM_PAINT 訊息處理期間，視窗訊息處理函數呼叫 BeginPaint 之後，整個顯示區域即變為有效。程式也可以通過呼叫 ValidateRect 函式使顯示區域內的任意矩形區域變為有效。如果這呼叫具有令整個無效區域變為有效，則目前佇列中的任何 WM_PAINT 訊息都將被刪除。 ●WM_PAINT 訊息處理 case WM_PAINT： hdc = BeginPaint(hwnd,&ps); 使用 GDI 函數 EndPaint(hwnd,&ps); Return ;

在處理 WM_PAINT 訊息，必須成對地呼叫 BeginPaint 和 EndPaint。在呼叫完 BeginPaint 後，就開始呼叫 GDI 函數做一些畫面的處理。如果視窗訊息處理程式不處理 WM_PAINT 訊息，則它必須將 WM_PAINT 訊息傳遞給 Windows 中 DefWindowProc(內定視窗訊息處理函數)。

Windows 將一個 WM_PAINT 訊息放到訊息佇列中，是因為顯示區域的一部分無效。如果不呼叫 BeginPaint 和 EndPaint(或者 ValidateRect)，則 Widnows 不會使該區域變為有效。相反，Windows 將發送另一個 WM_PAINT 訊息，且一直發送下去。

2.3.4 Hook

因為遠端桌面程式最在意的便是畫面變動的區塊，因此如何取得這些區塊，就是這類程式相當重要的一部分。VNC 採用的方法是，監視任何和畫面相關的訊息，並將範圍記錄下來，再進一步處理，這些在後面章節會詳細探討，現階段我們要先研究 VNC 是如何取得想要的訊息---Hook[8]。

(29)

Hook 實際上是一個處理訊息的程式，屬於 Windows 的 API，通過使用者的啟動後，它可以針對某些特定動作所產生的訊息做監視和處理，比如：OS 發送 WM_PAINT 的訊息給某個應用程式、使用者敲擊鍵盤、移動滑鼠，這些就被分類為三種動作，因為 Windows 溝通都是透過訊息，因此每當特定的動作產生時，都會伴隨著訊息，在訊息還沒送達目的應用程式之前，Hook 就會先捕獲該訊息，亦即 Hook 前處理函數先得到控制權，此時對應 idHook 的前處理函數即可對該訊息加工，也可以不作處理而繼續傳遞該訊息，還可以強制結束訊息的傳遞。前處理函數會如何運作的部分我們在 3.4.1 節中會詳細再說明。圖 2-2.Hook 示意圖

要實現 win32 的系統 Hook，必須調用 SDK 中的 API 函數 SetWindows- HookEx 來安裝這個 Hook 函數，這個函數的原型是：

HHOOK SetWindowsHookEx(

int idHook, //要安裝的 Hook 類型 (參考下面的 IdHook)

HOOKPROC lpfn, //Hook 前處理函數的指標，即攔截到指定系統訊息後

的前處理函數名稱,須定義在 DLL 中

HINSTANCE hMod, //應用程式實例的控制碼

DWORD dwThreadId; //要安裝 Hook 的 threadID ,指定被監視的 thread，如果明確指定了某個 thread 的 ID 就只監視該 thread，此時的 Hook 即為 thread hook；如果該參數被設置為 0，則表示此 Hook 為監視系統所有 thread 的全局 Hook。 );

(30)

得到控制權的 Hook 前處理函數在完成對訊息的處理後，如果想要該訊息繼續傳遞，那麼它必須調用另外一個 SDK 中的 API 函數 CallNextHookEx 將訊息傳遞下去。Hook 預處理函數也可以通過直接返回 true 來丟棄該訊息，並阻止該訊息的傳遞。每種類型的 Hook 是由系統來維護，最後安裝的 Hook 放在鏈的開始，而最早安裝的 Hook 放在最後，也就是後加入的先獲得控制權。Hook 在使用完之後需要用 UnHookWindowsHookEx()卸載，否則會造成麻煩。 Windows 總共提供了對應 13 種動作的 Hook，這裡僅列出一般較常用的 9 種，旁邊是要觸發 Hook 對應動作的說明。 ●常用 idHook 參數整理如下： WH_CALLWNDPROC //視窗 hook，當系統向目標視窗發送訊息時將觸發 WH_CALLWNDPROCRET //視窗 hook，當視窗處理完訊息後將觸發 WH_CBT //當 Windows 啟動、產生、釋放（關閉）、最小化、最大化或改變視窗時都將觸發此事件 WH_GETMESSAGE //當往訊息佇列中增加一個訊息時將觸發此 hook WH_JOURNALRECORD //記錄 Hook，可以用於記錄滑鼠和鍵盤操作，木馬程式可以使用此 Hook 竊取受控方在螢幕中敲入的密碼 WH_KEYBOARD //當敲擊鍵盤時將觸發此 hook WH_MOUSE //當有滑鼠操作時將觸發此 hook WH_MSGFILTER //訊息過濾 hook WH_SYSMSGFILTER //系統訊息過濾 hook

VNC Server 在程式中啟用了三個 Hook，分別是上面 WH_CALLWNDPROC、 WH_GETMESSAGE、WH_SYSMSGFILTER，並且在 SetWindowsHookEx() 函數中，第四個參數設為 0，代表是監視全局的執行緒，即所有的程式執行時，只要符合以上三個 idhook 監視動作，Hook 皆會搶先一步處理這些訊息。因此 VNC Server 可以由這些訊息中，得到訊息的種類，如果是和畫面變動有關的訊息，比如：WM_PAINT，便可由訊息中的參數 hwnd，得知是何視窗可能發生變動，並記錄他們的大小範圍，接著進一步做比對和處理。

(31)

第三章

第三章 VNC Server

此章要細部探究 VNC Server 的工作原理，說明一套遠端桌面程式是如何成形的。遠端桌面程式一定需要接受 Client 的要求連線，進一步透過某種機制來互相溝通，且這類程式最主要目的就是取得 Server 的畫面並操控它，因此也需要一套完整偵測變動畫面方法和處理資料並傳送的流程。因此，在 3.1 節會就 VNC Server 整個完整架構先進行初步介紹，對整個邏輯有點概念；3.2 節中說明 Server 是如何不斷接收不同 Client 的連線要求；3.3 節討論從 Server 和 Client 一開始連線成功的初始化、兩者如何互相溝通，和有哪些溝通訊息的封包格式，都會在這說明；3 .4 節就是整篇論文最精華也最重要的部分，說明 VNC Server 透過兩種方法取得可能畫面變動區域：一、先透過 Hook 取得如整個程式的最小化還原時、點選選單、播放影片時的拖曳區和時間跳動…等可能變動畫面的訊息，由這些訊息所屬的視窗基本結構取得初步變化的區域大小，二、再由 VNC 自行額外加入全螢幕、前景程式…等的視窗範圍，因視窗程式工作區的資訊變動，可能是由應用程式自行產生，Hook 無從取得這些訊息，因此 VNC 自行將這些區域範圍也加入。由以上兩種方式取得最後可能變動範圍後，在最新資料的 mainbuffer 和前一狀態的 backbuffer 中，詳細比對這些可能範圍，取得真正有變動的區域資料並壓縮，再進一步傳送給 Client。

3.1 VNC Server 運作流程和架構

運作流程和架構

此章在先以流程圖大概描述 VNC Server 整個程式的運作流程，接著再以示意圖的方式，詳細說明每個區塊的功能，和他們之間的溝通方式。至於每個區塊的細節部分會在後續章節詳細探討。

(32)

●

系統

系統運作流程

運作流程

圖 3-1. VNC Server 流程圖

上圖 3 是 VNC Server 完整的流程圖，它主要由四個區塊所組成，分別是主程式和三個獨立的 Thread，他們會在運作中依序被啟動。Server 一開始由 WinMain 進行一些選項的初始，接著建立 TCP/IP 和 Client 溝通訊息封包，如 Create Socket 、 Bind 、 Listen ，以上完成後就會啟動 Server 的第一隻 vncSockConnect Thread( 上圖紫色區塊 ) ，啟動後主程式即交由 vncSockConnectThread 做後續的處理，主程序隨即回去等待處理，使用者會對工具列上 Server 程式做的動作。vncSockConnectThread 的功能用來監聽是否有 Client 要求連線。當有 Client 傳送要求連線時，vncSockConnectThread 會將此 Client 加入，並開啟第二隻 vncClientThread(上圖黃色區塊)專責處理所有 Client 的溝通訊息，接著再回去繼續監聽。當 vncClientThread 開啟後會先和 Client 進行初始化，完成後偵測是否已有第三隻 vncDesktopThread(上圖深藍色區塊)的存在，若沒有則啟動它，之後回去處理 Client 送來的訊息。而 vncDesktopThread 則是專責處理畫面變動，當有畫面變動，且 Client 有要求更新，則將變動的畫面

(33)

資料傳送給 Client。這些 Thread 的細節在之後的每一節中有詳盡的說明。 ●

系統

系統架構

架構

架構示意圖

架構

示意圖

下圖 4 是 VNC Server 整體的架構和運作流程，主要是由三隻 thread 所建構而成的，他們各司其職，在接收到 Client 發出的訊息，做出相對應的處理，直到 Client 離開連線，或關掉 Server 程式！這裡先初步介紹它們的功能，細節會在後續的章節中完整地說明。

圖 3-2.VNC Server 系統架構

1.

1. vncSockConnectThread

：：用來接洽所有 Client 的連線，當成功連線：：後，會開啟 vncClientThread 來接續後面的事項，接著回去繼續監聽其他 Client 連線要求。

2.

2. vncClientThread：

：

處理一切 Client 傳送過來的訊息，訊息可能是要設定編碼、要求畫面更新、游標移動、或敲擊鍵盤…等，它會針對不同的要

(34)

求做出不同的動作。

3.

3. vncDesktopThread：

：

偵測 Server 端桌面 Framebuffer 的實際變動區域，壓縮這些畫面，並依照固定的標頭和資料格式傳送給 Client。這部分是整個 Server 的核心所在，也是最複雜的地方，後面花最多篇幅詳細的講解。

●

運作流程

Server 程式一開啟，要先檢查是否已有 Server 啟動，因為 VNC 不允許兩個 Server 同時存在。接著初始化一些必要的基本設定，如登入密碼、Port、 View Only…等。設定完後會啟動 vncSockConnectThread 去建立完整的 TCP/IP 連線流程，Create socket、Bind、Listen，再來就是等待 Client 送出連線要求才會有進一步的動作。當 Client 要求連線時，vncSockConnectThread 會和 Client 進行三方交握 (Three-Way-Handshaking) ， Accept 後， Server 接著啟動 vncClientThread，而 vncSockConnectThread 則回到接收前狀態，繼續等待其他 Client 的連線。 vncClientThread 方面，一開始會先和 Client 進行版本的溝通和密碼的確認，當這些都正確無誤，它才會去啟動第三隻最重要的 vncDesktopThread。啟動之後，vncClientThread 就開始負責所有從 Client 送過來的訊息，因為 VNC 互相溝通的訊息格式都規範在 RFB Protocol 中，只要傳送過來的格式正確，它都能夠做出對應的處理，以維持兩端正常的運作。 vncDesktopThread 則是負責所有畫面的部分，包括存取本地端 Framebuffer 的初始化、設定傳輸更新訊息的封包格式、啟動 Hook、偵測可能畫面變動、辨別實際變動區塊…等，並將這些資料依照 Client 要求的編碼種類，和 RFB Protocol 中規定的標頭格式編碼後，傳送給 Client，因此這隻 thread 的重要性不

(35)

言可喻。以上就是完整的運作流程。

3.2 vncSockConnectThread

此 Thread 是負責接收所有 Client 連線的要求，一開始說明基本的連線設定，後面會再說明不同 Client 要求連線時，Server 要如何應對。

3.2.1 TCP/IP 連線建立

連線建立

Server 端程式一執行，便會先進行基本的設定，如密碼、是否 disable input、和設定功能表上選項的勾選。以上處理完，為了讓 VNC Client 可以對 Server 提出連線要求，Server 端必須接著進行 TCP/IP 的設定：Create Socket、Bind 和 Listen，之後會啟動 Server 的第一隻 Thread：vncSockConnectThread，透過設定好的 port 等待 Client 的連線要求。

圖 3-3.TCP/IP 連線建立

3.2.2 vncSockConnectThread 啟動

啟動

為了讓 Server 可以和一般網路程式一樣，接收一個 Client 後還可以繼續監聽是否有新的 Client 要求連線，VNC Server 將 TCP/IP 最後一個函數：Accept()，放在此 Thread 中，當 vncSockConnectThread 啟動後，隨即會進入一無窮迴圈等待 Client。一旦成功連線，Accept()函數會回傳一 VSocket 的類別，其中會記錄著 accept_socketid，後續和此 Client 資料的封包傳送和接收，皆是透過此

(36)

accept_socketid。Accept()完成後會呼叫 AddClient(new_socket, FALSE, FALSE) 函數，去啟動另一獨立的 vncClientThread 專責和此 Client 溝通訊息，而 vncSockConnectThread 會再回到迴圈，繼續等待下一個連線要求，直到 Server 結束。以上即是 VNC Server 能夠持續接收許多 Client 連線的機制。圖 3-4.vncSockConnectThread 值得注意的是，vncSockConnectThread 在接收了不同 Client 連線要求後，會啟動對應但不完全相同的 vncClientThread，因為在 Server 和 Client 傳送和接收封包，是以 accept_socketid 當橋樑，因此每隻 vncClientThread 都要記錄著各別的 accept_socketid，Server 才有能力和所有 Client 溝通，分辨出此封包是由哪個 Client 送進來，應該傳送畫面資料封包到哪個 Client。

3.3 vncClientThread

此 Thread 是專責和 Client 做溝通，一切由 Client 送過來的訊息，如：畫面更新、敲擊鍵盤、移動或敲擊滑鼠、設定 Pixel_Format…等訊息，都是由此 Thread 負責解析，進而做相對應的處理。在第五節中會詳細說明訊息接收後的處理程序。

(37)

vncClientThread

Connected? Remove Client

Read Message Type rfbSetPixelFormat

rfbSetEncodings rfbFramebufferUpdateRequest rfbKeyEvent rfbClientCutText default rfbPointerEvent Initialization 圖 3-5.vncClientThread 流程圖

3.3.1 vncClientThread 的

的

的 Initialization

Thread 一啟動，馬上開始 RFB Protocol 中的 Handshaking Phase，進行版本和安全性種類的確定，再進一步檢查密碼和認証是否通過，一切完成後接著判斷 vncDesktopThread 是否已啟動，若沒有則啟動它，啟動後繼續設定 mainbuff 和 backbuff，這兩塊 buffer 在後續傳送資料時會用到，最後才會開始 Server 和 Client 的初始化訊息溝通。

(38)

圖 3-6.Handshaking Phase ●InitVersion()

一開始會由 Server 傳送 Protocol Version 給 Client，讓 Client 知道 Server 最高可以支援的 RFB Protocol 版本，而 Client 收到後會回傳訊息，告知實際是用哪一個 protocol！但它不能夠要求高於 Server 的 protocol version。這個機制是為了使雙方都可以向下支援。目前發布的 RFB 版本有 3.3，3.7，3.8。新增進的編碼格式不會改變 protocol 的版本，因為 Server 可以忽略它不懂得的編碼。這部分在第五章會再詳細說明。 ●InitAuthenticate() 在 Protocol Version 被決定後，雙方必須溝通連線安全性的種類，和密碼認証。這部分在第五章會再詳細說明。 ●啟動 vncDesktopThread 版本、安全性種類、密碼認證完成後，代表 Server 已和 Client 建立完整的溝通管道，兩邊可以按照 RFB Protocol 規定進行下一步的動作。vncClientThread 一開始會先接收 ClientInit 訊息，判斷是否准許其他 Client 同時和 Server 連線。接著， vncClientThread 會開啟畫面更新和傳送資料最核心的 Thread— vncDesktopThread。

(39)

圖 3-7.vncDesktopThread and SetBufffer

開啟 vncDesktopThread 之前，vncClientThread 會先判斷 Server 是否已有啟動 vncDesktopThread，因為同時間可以有很多個 vncClientThread 和 Server 溝通，但只需要一隻 Thread 來偵測畫面變動，因此若已有啟動則返回；沒有的話就去啟動它，至於啟動後 vncDesktopThread 的後續程序，我們會在下一節詳細探討。

●Frmaebuffer 設定

vncDesktopThread 啟動後，會去設定許許多子項，讓 VNC Server 透過一些變數，就可以得到目前 Framebuffer 的狀況。接著 vncClientThread 宣告 vncBuffer *buffer = new vncBuffer(m_desktop)，此類別中的 CheckBuffer()函數會依照得到的 Framebuffer 大小和屬性，建立 mainbuff 和 backbuff，並將目前桌面畫面資料存到兩個 buff 中。畫面產生變動時，只要把最新的變動範圍存入 mainbuff 中，再將這些範圍和舊資料的 backbuff 比對，即可得到真正變動區塊，這部分後面會詳細說明。

(40)

以上處理完，vncClientThread 會將 vncDesktopThread 得到的 Frmabuffer 的狀況，存放在 ServerInit 訊息中傳送給 Client，讓 Client 能夠在本地端開一個和 Server 相同大小屬性的 Viewer 視窗。接著 vncClientThread 會進入一個無窮迴圈，專責處理由 Client 送過來的訊息，並做相對應的處理。

3.3.2 Client to Sever 訊息的種類和處理

訊息的種類和處理

一切初始化流程結束後，vncClientThread 便會進入訊息處理迴圈，等待 Client 傳送訊息過來，並解析訊息和處理。在第六章會詳細介紹這些訊息，和 Server 如何處理他們。如果 Client 要傳送未定義的訊息，需確定 Server 是否有支援。下表 2 是 Protocol 中已訂定的幾個訊息。

表 3-1.Client to Server messages

以上即是 Client 可能傳送給 Server 的所有訊息種類，當一個訊息處理完， vncClientThread 會再回到迴圈啟始處，等待 Client 送過來的訊息，因此， vncClientThread 有如 Server 端的接待員，負責接洽 Client 的所有要求。

3.4 vncDesktopThread

接下來這節是整篇論文核心，說明 VNC Server 要如何獲得確切畫面變動區塊並壓縮傳送到 Client 端。在 3.4.1 節中介紹 vncDesktopThread 為了後續的工作，一開始先做了哪些初始化。3.4.2 節則是說明 Thread 如何取得初步變動範圍， Number Name 0 SetPixelFormat 2 SetEncodings 3 FramebufferUpdateRequest 4 KeyEvent 5 PointerEvent 6 ClientCutText

(41)

他們是由 Hook 處理和畫面相關訊息後送出的。3.4.3 節針對 Hook 沒辦法取得的畫面區塊進行補強，再額外加入比對的範圍。3.4.4 節一開始比對 3.4.3 節中獲得的最後範圍，將真正有變動的部分壓縮處理後傳送給 Client。

3.4.1 vncDesktopThread 啟動

啟動

vncDesktopThread 是由 vncClientThread 所啟動，啟動後馬上進行一連串的初始化，這些設定是為了設置許多參數，在後續運作中會用到，因此此節來說明這些函數細節。

圖 3-8.Initialise the Desktop object ●KillScreenSaver()

此函數會停用螢幕保護程式。 ●InitBitmap()

此函數主要功能是為了取得 Server 端桌面的狀況，供後續變數使用，如目前使用的解析度和維度大小…等，細部分為五大步驟：

(42)

圖 3-9.InitBitmap() 1. 取得整個桌面的 Device Context1 。 2. 由 Device Context 得到目前桌面的長和寬。 3. 在記憶體中建立一塊和桌面相同的 DC，因為後續會用到，接著將桌面 DC 的資料，由 CreateCompatibleBitmap()函數轉換成 Bitmap 的類別，存放在記憶體中，後續會再用到。

4. 用 GetDIBits()函數，可將此 m_membitmap 這個 Bitmap 類別中的 BITMAPINFO，全部填到 m_bminfo.bmi 中。

5. 判斷 Server 端是否有使用調色盤，若沒有，則 truecolour 為非零值。

1_{當 Windows 程式在螢幕、印表機或其他輸出設備上畫圖時，它並不是將圖直接輸出到設備上，而是將}

圖由 Device Context 表示的”邏輯意義”，映射到"顯示平面"上去。Device Context 是 Windows 內部的一種資料結構，它包含 GDI 需要的所有關於顯示平面狀況的描述欄位，包括相連的設備和各式各樣的狀態資訊。在螢幕上畫圖之前，Windows 程式從 GDI 獲取 Device Context Handle，每一次調用一個 GDI 輸出函數時，它就會把這個 Handle 傳回給 GDI。如果沒有有效的 Device Context Handle，則 GDI 不會做任何的繪圖動作。Device Context 使 GDI 擺脫設備限制的過程中發揮了重要的作用。

(43)

●ThunkBitmapInfo()

此函數會判斷 Server 端的色彩品質，若不是 16bits 或 32bits，會調整一些 m_bminfo.bmi 中的參數，但目前大部分的電腦都是 32bits，因此通常會直接跳到下個函數。

●SetPixFormat()

將剛得到的桌面資訊，如： trueColour 、 bigEndian 、 Width 、 Height、 bitsPerPixel、depth、biBitCount，複製到 m_scrinfo 這個結構中，之後需要某些參數，就統一從 m_scrinfo 讀取。 ●EnableOptimisedBlits() 圖 3-10.EnableOptimisedBlits() 此函數包含了相當深入的 Bitmap 問題，但最重要的功能是在建立一塊和桌面相同大小的記憶體區塊，它會以 m_bminfo.bmi 中的長、寬、bitsperpixel 來設定，當呼叫 CreateDIBSection()函數後，m_DIBbits 即是此記憶體區塊的指標，回傳值 tempbitmap 即為 DIBSection，接著會撤換掉先前的 m_membitmap。

建立 DIB Section 為的是能夠使用快速的 Blt 函數複製桌面 DC 上的資料，後續只要簡單的程序(請參閱 3.4.4 節的 Capture Screen)，就能將桌面上畫面像素資料迅速複製到 m_DIBbits 中，且在 vncClientThread 呼叫 CheckBuffer()函數時，就將 mainbuff 指向 m_DIBbits，以上就是記錄桌面 Framebuffer 的 mainbuff 記憶體位置。

(44)

●SetPixShifts()

用來設定 ServerInit 中的 Shift 值。

16bits：redMask = 0x7c00; greenMask = 0x03e0; blueMask = 0x001f 32bits：redMask = 0xff0000; greenMask = 0xff00; blueMask = 0x00ff ●SetPalette()

如果是 Server 端是全彩，則跳過此函數；反之，建立調色盤，供 Client 使用。 ●InitWindow()

此函數會建立一個 win32 程式，但不顯現在螢幕上，VNC Server 會用它來作為和 Hook 溝通的橋樑，因為每個 win32 程式都有 handle 來辨識，也有一個訊息佇列來和 Windows 或其他視窗程式溝通。因此，只要 Hook 截取到有用的訊息，它會處理此訊息，並再以訊息的方式存放在此隱形程式的訊息佇列，VNC Server 只要定期來檢查它的訊息佇列中是否有訊息，即可判斷畫面變動的狀況。後面會以例子做說明。 ●SetHook() 圖 3-11.SetHook 接續在第二章後半部介紹的 Hook，這邊要說明它是如何運作，和做了什麼工作。Hook 是在此函數中啟用的，VNC Server 總共會啟用三種 Hook： WH_CALLWNDPROC、WH_GETMESSAGE、WH_SYSMSGFILTER，他們對

(45)

應的前處理函數分別是 CallWndProc、GetMessageProc、DialogMessageProc，這三個函數只會在符合情況的訊息出現時被呼叫。這三個前處理函數被呼叫後，因為格式不同，都會將傳入的參數加以處理，最後，他們都會再用這些參數呼叫 Hookhandle()函數，Hookhandle()函數會依照不同種類的訊息做不同的處理。圖 3-12.Hook Procedure 假設以 WM_PAINT 訊息為例，當有一個視窗出現無效區域(如縮小、還原) 需要重畫時，Windows 會發送一 WM_PAINT 訊息給此視窗，此動作一產生後， Server 所啟用的 Hook-WH_CALLWNDPROC 就會先動作，Hook 會先呼叫它對應的前處理函數 GetMessageProc()，之後將訊息種類、所屬 hwnd、訊息的副消息當參數呼叫 HookHandle()函數。HookHandle()函數一開始由訊息種類可以判斷是 WM_PAINT，再用 Windows 的 SDK 函數 GetWindowsRect()得知此訊息所屬視窗的位置大小，將此位置大小的值用訊息的方式 Post 到，在 Server 端 Initialization 中啟用的隱形程式的訊息佇列，因此 Server 只要從訊息佇列中取出訊息就可知道某個區域可能即將發生畫面變化，接著對這個視窗的範圍做進一步

(46)

比對處理即可。

3.4.2 vncDesktopThread 畫面處理流程

畫面處理流程

vncDesktopThread 一開始的初始化完成後，就會進入處理畫面的無窮迴圈裡，總共有三大部分，一、取得 Hook 偵測可能的範圍，二、進一步增加額外判斷範圍，三、將最後可能變動範圍進行比對並傳送真正變動區塊。下圖為此 Thread 的流程圖。圖 3-13.vncDesktopThread 流程圖這個迴圈相當繁瑣，大致上是由三個部分所組成。

一

一、

、

、取得

取得

取得 Hook 偵測

偵測

偵測到

偵測

到

到可能的範圍

到

可能的範圍

1. vncDesktopThread 初始化後，剛進入迴圈時，可能尚未有如 4.3.1 節中啟用的三種 Hook 動作發生，因此，他們對應的前處理函數不會送來任何可

(47)

能變動的訊息到隱形程式的訊息佇列，因此佇列中沒有任何訊息。接著繼續判斷 region 中是否有記錄任何可能的變動區塊大小，若沒有，代表目前沒有任何需要更新的區域，隨即再回到迴圈中，等待訊息並加以處理。

2. 一切開始正常運作後，當一產生 4.3.1 節中啟用三種 Hook 對應的動作後，

對應 Hook 的前處理函數會處理可能和畫面變動相關的訊息，處理完後會再以訊息方式(RFB_SCREEN_UPDATE)， Post 到 Initialization 時啟動的隱形程式的訊息佇列。vncDesktopThread 進入迴圈後會先判斷訊息佇列中是否有新訊息，當它發現有訊息時，會取出此訊息判斷，如果訊息是 RFB_SCREEN_ UPDATE 就表示是由對應動作 Hook 的前處理函數處理過後傳過來的，接著 vncDesktopThread 由此 RFB_SCREEN_ UPDATE 消息的副消息參數，可以得到可能變動的大小，並將它記錄到 rgncache(Window 的 Region 類別)中，如下圖。接著再回到佇列中看是否有新的訊息，若有，則再取出並和剛剛記錄的做聯集，直到訊息佇列中都沒訊息為止。

圖 3-14.GetMessage and Record

3. 訊息佇列清空後，代表現階段沒有任何新的畫面變動，Thread 會趁此空

檔趕緊去做後續處理，因此再判斷 region 不為空後，會再判斷旗標 Update Flag 是否被設為 TRUE，它代表 Client 有要求畫面更新，若有要求才會進一步處理。若 Client 沒有要求，則 Flag 為 False，因此 Thread 會將剛記錄的 region 保留著，直接返回剛剛 vncDesktopThread 訊息處理迴圈，等待下次記錄完並清空訊息佇列後再一起處理。這是因為 VNC 的整個架

(48)

構是 Client Pull，Update Flag 是由 vncClientThread 所控制，在它收到 Client 的畫面更新要求後，才會將 Update Flag 設為 TRUE，因此主動權在 Client 端，只有在 Client 有要求後，Server 才能做後續的處理。

二

二、

、

、增加額外判斷範圍

增加額外判斷範圍

在 region 不為空且 Update Flag 被設為 TRUE 時，表示剛剛 vncDesktop- Thread 已發現可能有畫面變動，並記錄著這些區塊的座標大小在 region 中，而且當 Client 也要求要更新畫面時，Thread 就要接著後續的處理。為了避免一些應用程式，可能不是透過 Windows 以畫面重畫的訊息機制更新畫面，而是自行處理內部工作區域的變動，因此在 4.3.1 節中啟用的三種 Hook 無從取得可能變動範圍。VNC Server 在這部分，是以自行增加額外範圍來應對，它總共提供三種方式：Poll FullScreen、Poll Foreground Window、Poll Window Under Cursor。

(49)

圖 3-15.Add extra region 流程圖 ●Poll Full Screen

當使用者勾選了這個選項，代表為了確保整個螢幕都要更新到，不希望失去某些畫面，此時 VNC Server 會將螢幕範圍拆成四等分，每觸發一次都會額外再加入一個等分，如下圖。因此，採取這樣的方式會稍稍增加資料的處理量。VNC Server 也可以每次都加入全螢幕的大小範圍，但為了克服網路頻寬和 Computing Power 的問題，它採取的是經過四次的觸發流程，才會更新完整個畫面。

圖 3-16.Poll Full Screen

因為每一次清空訊息佇列中的訊息得到初步範圍後，再進到 Add extra region 時，只會加上螢幕的四分之一，加入的方式如下圖程式碼，用 m_pollingcycle 記住狀態，然後以 m_pollingcycle 計算這次要加入的是哪一塊範圍，並記錄在矩形結構 rect 中，再將這個座標大小與 vncDesktopThread 前端取得的初始範圍做聯集，接著送去 SendUpdate()函數處理後再回到迴圈，再等下次清空佇列裡的訊息，才有機會再進 Add extra region 加上另一塊四分之一的畫面，因此要重覆四次才能更新完成。

桌面訊息的變動偵測與壓縮傳送

國 立 交 通 大 學

電信工程學系

碩 士 論 文

桌面訊息的變動偵測與壓縮傳送

Detection of Change of Desktop Content and

Compress Transmission

研 究 生：蔡文賢

指導教授：張文鐘 教授

桌面訊息的變動偵測與壓縮傳送

Detection of Change of Desktop Content and Compress

Transmission

研 究 生：蔡文賢 Student：Wen-Hsien Tsai

指導教授：張文鐘

Advisor：Wen-Thong Chang

國 立 交 通 大 學

電信工程學系

碩 士 論 文

桌面訊息的變動偵測與壓縮傳送

桌面訊息的變動偵測與壓縮傳送

桌面訊息的變動偵測與壓縮傳送

桌面訊息的變動偵測與壓縮傳送

學生：蔡文賢

指導教授

張文鐘

博士

國立交通大學電信工程學系碩士班

摘

要

Detection of Change of Desktop Content and

Compress Transmission

Student：Wen-Hsien Tsai

Advisors：Dr.

Wen-Thong Chang

Department of Communication Engineering

National Chiao Tung University

ABSTRACT

誌謝

誌謝

誌謝

誌謝

誌於 2008.08 風城 交大

Wen-Hsien

目錄

目錄

目錄

目錄

表

表

表

表目錄

目錄

目錄

目錄

圖

圖

圖

圖目錄

目錄

目錄

目錄

第一章

第一章

第一章

第一章 緒論

緒論

緒論

緒論

1.1 動機

動機

動機

動機

1.2 研究背景

研究背景

研究背景

研究背景

1.3 論文架構

論文架構

論文架構

論文架構

國立交通大學

碩士論文

研究生：蔡文賢

指導教授：張文鐘教授

研究生：蔡文賢 Student：Wen-Hsien Tsai

國立交通大學

碩士論文

誌於 2008.08 風城交大

第一章緒論

第二章遠端桌面和相關背景知識