Secondary Order 的處理

將 RDP Server 傳送過來的圖片(bitmap)、文字(text)及色彩對應表（color table）進 行暫存，在遠端視窗桌面的連線上，文字、圖形會暫存在 cache 中，畫面中有重複出 現的畫面利用 memblt 將畫面取出，如果是文字那麼就利用 text order 將 cache 中的點 陣字型取出顯示在螢幕上。

rdesktop 中定義了 process_secondary_order 處理 secondary order 的封包，程式呼叫 流程如下圖。

圖 52. process_secondary_order 函數呼叫流程

in_uint_le 分別解析出封包的長度及 flags，flags 用在 bmpcache2 中告知 RDP Client 關於 bitmap 的資訊(例如：是否為持續型點陣圖(persistent)或是 bitmap 的形狀)，in_uint8 則是讀取出封包類型(type)，用來決定下面所呼叫的 process 函數。

4.4.1 process_bmpcache

process_bmpcache：處理 bitmap cache 命令，根據傳送過來的 bitmap 封包，資料 解壓縮後，依 cache id、cache index 將 bitmap 資料存入 bitmap cache 中，Bmpcache 在 rdesktop 分為兩種 header，關鍵在於是否為 rdp5，以下說明其封包格式。圖 53.為使用 rdp5 的格式，其中 Data 的資料量由 Buffer size 所決定。

圖 53. rdp5 process bmpcache 封包格式

如果不是 rdp5 的連線，其格式為圖 54.所示，封包中 Data 的最後大小即為 size 所 說明的大小。

圖 54. process bmpcache 封包格式

process bmpcache 不管是哪一種封包格式，最後解壓縮後，由 ui_create_bitmap() 函數將 bitmap 繪出後，依 bmpcache 所指定的 cache id 和 cache index 將點陣圖儲存於 bitmap cache 中，在實驗進行的過程中，由 rdesktop 連線至 Microsoft XP RDP5 .1 並未 使用這支函數，而是使用 process_bmpcache2()，因此接下來針對 process_bmpcache2 進行說明。

4.4.2 process_bmpcache2

process_bmpcache2(STREAM s, uint16 flags, BOOL compressed)，對 bitmap 處理可 分為壓縮和無壓縮，並依據 flags 定義 bitmp 資訊，最後將 bitmap 放入 bmpcache 中，

程式處理程序如下圖。

圖 55. process bmpcache2 程式處理流程 由 process_secondary_order 中的 flags 傳遞了以下資訊：

1. cache id

2. 決定暫存的 bitmap 是否存放在 persistent cache，如果存放 persistent cache 則另外給 予一組 bitmap id

3. bitmap 是否為正方形（例如：64x64），如果是正方形長寬一樣。如果不是正方形，

分別取出長寬資料 4. bits per pixel

接著定義出 buffer size 決定資料大小，由收到的封包中取出資料，如果沒有壓縮 就直接將資料讀出來，由 ui_create_bitmap 繪出資料；如果 bitmap 有壓縮，利用 bitmap_compress()函數將資料解壓縮後，交由 ui_create_bitmap 繪出 bitmap，完成的 bitmap 由 cache_put_bitmap 存 入 bitmap cache 中 ， 如 果 是 persistent 則 交 由 pstcache_save_bitmap 函數，將 bitmap 存入硬碟暫存。

4.4.3 process_colcache

process_colcache：處理 colormap cache 命令，根據 cache id 呼叫 ui_set_colourmap 設定對應的 coloymap。在 256 色顯示時，才會利用到 colormap，在本研究中沒有使用 到 colormap，這邊就不贅述。

4.4.4 process_fontcache

process_fontcache：處理 font cache 命令。接收點陣字型封包後，依 ui_create_glyph 將自行繪製出來，之後 cache_put_font 將點陣字型放入 font cache 中。一個 Font_Glyph 命令結構定義如下圖。

圖 56. RDP Font Glyph 結構

收到一個 Font 點陣字型封包後，依據所定義的結構解開 header 後，將收到的 data 交由 ui_create_glyph()處理，將繪制好的 1 bpp 點陣字型存入 font cache 中，在文字部 分，RDP Server 傳遞過來的資訊不經過壓縮編碼，而是一位元接著一位元依序傳送。

在一個 process fontcache 的命令中，所傳送過來的文字是以 glyph 來定義的，一個文字 就是一個 glyph，而一個 process fontcache 的 secondary order 包含的文字數目是一個或 是多個的，rdesktop 收到後利用 ui_create_glyph 將每個文字建立出來，之後每個文字 分別放入 fontcache 中。

4.4.5 process_raw_bmpcache

process_raw_bmpcache：處理 raw bitmap cache 命令。將未經處理壓縮的 bitmap 資料從封包中取出來，利用 memcpy 直接將封包資料複製到記憶體中，接著呼叫 ui_create_bitmap 將 bitmap 繪製出來，最後呼叫 cache_put_bitmap 將資料存入 cache 中。

由以上的敘述，可以得知 secondary order 的目的是處理暫存在 cache 中的資料，

透過資料的暫存可以有效降低點陣圖資料的傳送，比起 VNC 連線方式，RDP 就是應 用了大量的 cache 提升連線效益，但是在影片播放時，由於每個畫面幾乎是沒有重複 的，因此 RDP Server 會傳送大量 process_bmpcache 命令，將 bitmap 暫存到 bitmap cache 中，造成影片播放時 frame 遺失。