在這一小節我們將詳細說明評估工具的運作細節，以及實作後遭遇的問題，
並提出解決方法，我們開發選擇的平台是 Microsoft C#，並利用其提供的函數 User32.dll 來實作我們所需的操作，像是鍵盤滑鼠或是畫面捕捉等等動作。
首先我們對需要建立同步的動作進行動作完成的畫面的擷取，我們先藉由接 收裝置上 Citrix XenDesktop Receiver 上得到使用者畫面呈現的座標位置，再 將座標位置所包含的區域暫存，做為之後動作執行完比較之用，如圖 4 所示，此 畫面為接收裝置在開啟 Citrix XenDesktop Receiver 時的桌面畫面，右下角是 Receiver 應用程式部分，而我們只在意 Receiver 內的內容，所以藉由提取應用 程式的座標來達成。
接著我們藉由圖 5 來簡單分析在使用者在使用 Citrix XenDesktop 時伺服器 與接收裝置互動情形，來分析評估工具何時能執行正確的動作，虛線表示的是由 接收裝置送給伺服器的封包，主要是滑鼠及鍵盤的操作，細短的實線是由伺服器 發送給接收裝置的封包，也就是傳送給 Citrix XenDesktop Receiver 應用程式 的畫面更新，而粗長的實線是指確認需要建立同步之動作執行之後，XenDesktop Receiver 應用程式的畫面與先前儲存的畫面已相符，之後的動作便可接續執行。
以下將舉一個簡單實例，在 tcc 時刻之前，接收裝置已執行許多操作，伺服器端 也送回對應的畫面給接收裝置，此時都尚未有同步動作出現，而在 tcc 此刻接收
圖 3 1 畫面捕捉示意圖
圖 4、畫面捕捉示意圖
15
裝置此使是開啟 Microsoft Word 應用程式，根據實驗設計，此動作是一需建立 同步動作，所以評估工具將暫停執行下一動作，並且持續比對 XenDesktop Receiver 應用程式的畫面與先前對應此動作所儲存的畫面是否相符，在 t3 伺服 器端送出對應接收裝置開啟 Microsoft Word 應用程式的畫面，而時間 t4 才比對 成功，此時 t4 稱為同步點，同步點之後才可執行下一動作，t3 減去 tcc 的時間 便是精準由接收裝置執行動作後，畫面呈現所需的時間，但是由於我們無法正確 掌握伺服器何時將畫面回傳，因此 t4 減去 tcc 的時間便是我們量測到接收裝置 送出動作後，伺服器回傳畫面所需的時間，此時間與我們比對面畫是否相同的頻 率有很大的關係，根據我們的設計，量測的頻率約 100 毫秒一次，因此我們所測 的畫面回應時間可能約有 0 至 100 毫秒的誤差，但此誤差我們認為是非常小的，
認為算是使用者可以接受的誤差，等到後面實驗我們會做簡單的驗證，來驗證量 測從接收裝置送出滑鼠或鍵盤的動作，到接收到對應的畫面回傳時間是否準確。
圖 5、伺服器與接收裝置互動情形
16
圖 6 是評估工具的執行流程圖，我們將藉由這張流程圖來介紹評估工具的執 行過程，首先會先接受到一連串輸入，輸入會告知共有幾個輸入需要執行，還有 每個輸入所做的動作為何，動作包含鍵盤輸入的內容，以及有關滑鼠的操作左鍵 右鍵滾輪的輸入，以及根據輸入所描述的座標來指定每個動作是在螢幕上何處進 行。
首先評估工具當還有動作需要執行時，便會將這個動作根據輸入時所描述的 狀態來執行，緊接著啟動一個計時器，此計時器是之後用來計算執行動作到畫面 回傳所需要的時間之用。接著再查看此動作是否為需要建立同步的動作，如果不 是需要建立同步的動作，則直接開始下一個動作，若此動作是需要建立同步的動 作，則開始進入畫面比對的流程，評估工具將持續比對 XenDesktop Receiver 畫面內的視窗，與一開始建立此動作完成後的畫面是否相同，直到比對到畫面相 同為止，評估工具都將不會開始下一個動作，而比對畫面是否相同的動作約 100 毫秒執行一次，接著如果比對相同的話，便停止計時器，記錄下所量測的時間，
我們稱此一時間為回應時間(Respond Time)，接著判斷這是否為最後一個需建立 同步動作，如果是的話便完成了一個實驗，否則就開始下一個動作，根據這個簡 單的流程，我們就可以掌握接收裝置每個動作需花多久時間得到由伺服器回應的 畫面，讓我們可以精準的掌握接受裝置，在伺服器或網路環境惡劣下，接收裝置 感受到的延遲情形，我們就可以對伺服器的狀態做評估，也可以再進一步的做為 診斷工具的診斷依據。
17
圖 6、評估工具執行流程圖
18
根據我們介紹評估工具流程後，可以發現，比對 XenDesktop Receiver 畫面 內的視窗，與一開始建立此動作完成後的畫面是否相同這個流程，佔據了評估工 具執行流程中最長的一段時間，也因此影響了我們量測回應時間的正確性。
所以我們想了一個簡單的方法，來增加量測回應時間的正確性，以下舉一個 簡單的例子來說明，我們假設現在要執行開啟 Microsoft Word 的動作，且此動 作是一需要建立同步的動作，因為之後的動作都必須等到畫面開啟完成才能執行，
否則將導致結果不正確，圖 7 是尚未執行開啟動作前的狀態，而圖 8 是我們預期 開啟 Microsoft Word 後的畫面。在之前的做法我們將 XenDesktop Receiver 畫 面內的視窗，與一開始建立此動作完成後的畫面拿來比較，但根據不同的動作，
其實畫面並不是全部都會更動，所以在這例子中，我們只需要比對 Microsoft Word 開啟的位置如圖 8 所示，因為只要開啟位置內的畫面相同，也代表了 Microsoft Word 已順利開啟，便可繼續執行下一動作。因為需要比較畫面是否 相同的範圍縮小許多，也加快了畫面比較的時間與正確性，所以後來我們都使用 此做法，也就是根據執行每個需要建立同步動作之後，只對螢幕會產生改變的範 圍來比較，所以在開始實驗之前的準備工具，也必須記錄畫面比較的範圍，在執 行工具執行的時候，才能判斷需建立同步動作需要比對的範圍，使用此方法的優 點是加快了畫面比較的速度與正確性，會提升正確性是因為如果擷取的畫面越大，
不穩定的因素就越多，例如在鍵入文字時閃爍的游標等等…，而提升畫面比較速 度，則能夠讓評估工具能在更接近畫面回傳的時間就進行，因此能提升評估工具 在測量回應時間的準確性，以上是對評估工具的改進說明。
19
圖 8、動作執行前 XenDesktop Receiver 畫面
圖 7、動作執行後，預期畫面呈現結果
20 部分則分成，連線延遲(link delay)和封包遺失(packet loss)，這兩者都會造 成使用者在使用 VDI 服務感受不佳，但感受程度又隨著環境惡劣程度而有所不同。 器會一直進行記憶體交換(Memory Swap)，此動作牽扯到磁碟的存取，所以 VDI 使用者也會感受到效能低落。最後是磁碟資源不足造成 VDI 使用者感覺效能低落，