中 華 大 學 碩 士 論 文
在行動計算環境中使用版本集合放鬆互斥一致 性的資料暫存方法
A Caching Scheme with Version Sets to Relax Mutual Consistency in Mobile Computing
Environments
系 所 別：資訊管理學系碩士班 學號姓名：M09410023 劉 郁 君 指導教授：李 之 中 博士
中華民國 九十六 年 八 月
摘 摘
摘 摘 要 要 要 要
在行動計算環境中，相關的研究學者提出以資料廣播的方式將伺服端上資料 庫的內容傳送給行動客戶端以解決行動客戶端的規模性問題。同時，在此種環境 中，學者也使用資料暫存技術以減少行動客戶端執行應用時的反應時間。然而，
為了確保行動客戶端能夠正確的執行應用，相關研究多以行動客戶端使用資料庫 中最新狀態的資料，也就是以互斥一致性作為正確性標準。但在此一標準下，行 動客戶端在執行應用時必須經過繁複的驗證，以確保所使用的資料是資料庫中的 最新狀態資料，此驗證過程也導致較長執行應用的反應時間。
然而，在日常生活中，有許多應用並不需在如此嚴苛的標準下執行，像是天 氣預報。因此，我們希望將資料正確的標準從互斥一致性放鬆為滿足一致性即 可，在放鬆互斥一致性的前提下，我們設計了一個使用版本集合的資料暫存方 法，這個方法可讓行動客戶端執行應用時可以使用稍早的資料，但是，這個方法 能夠避免行動客戶端使用過於陳舊的資料，以避免應用的執行發生錯誤。我們將 行動客戶端的暫存記憶體劃分為三個區域，分別將不同狀態的資料項存放三個版 本集合中，這三個版本集合分別為新版本集合、目前版本集合、失效版本集合，
再藉由控制三個版本集合的方式達到行動客戶端查詢資料的一致性，同時將查詢 結果限制於某個一致性狀態下。我們以系統模擬的方式評估版本集合的效能，在 實驗結果後發現使用版本集合可大量減少查詢時的反應時間並允許行動客戶端 更長時間的離線，這是因為當行動客戶端在加入版本集合並放鬆一致性標準後，
使得查詢到達時不需等待驗證報告即可擷取暫存資料來回答查詢，因此可減少查 詢時等待資料項的時間並允許行動客戶端更長時間的離線。
關鍵詞：行動計算環境、資料廣播、資料暫存技術
Abstract
Data broadcast is an efficient method for disseminating data items in a mobile computing environment. With the data broadcast methods, data items are broadcasted periodically according to a predetermined schedule. And therefore, the problem for the scale of mobile clients is overcome by data broadcasting. To ensure users execute an application correctly, the criterion usually follows mutual consistency. For this reason, the mobile client spent large cost on data validation. However, many real life applications don’t need so restricted criterion. Therefore, we relax the criterion from mutual consistency to consistency, that is, the mobile client may not access the up-to-date contents of the required data items in its application.
To relax the consistency criterion, we had designed the new caching method. In the method, caching data are kept in three different version sets – current version set, new version set and invalid version set. Further, we analyze the performance of the caching method through discrete event simulation. The performance results show that the access time of the version sets caching method is shorter than that of its counterparts, even when network disconnection is common or disconnection time is long.
Keywords： Mobile computing environment、Data broadcast、Data caching method
致 致
致 致 謝 謝 謝 謝
研究所的生活在此告一個段落了，回想當初剛開始進入碩班的心情是如此的 害怕、擔心，因為我不知道大學生的生活和碩士生到底有什麼不同，也不知自己 的能力可否面臨自己未知的研究所生活，但轉眼間，我即將要畢業了，要告別研 究所的生活邁向人生下一段旅程。
在這兩年簡短而充實的生活中，最感謝的就是我的指導教授李之中博士，在 研究上老師總是用心的教導我，讓我獲得許多專業上的知識，使得我能夠完成此 論文，在生活上老師也適時表達關心並與我維持良好的互動，很謝謝老師在這兩 年的教導使我受益良多。此外，還要感謝口試委員蔡耀宏博士與徐盛軒博士，在 口試過程中提供了許多專業的意見，使得我的論文可更加嚴謹。
再來，我要感謝育銘、夏暘這兩位研究上的同伴，不僅在我研究上遭遇困難 時給予我許多寶貴的意見，讓我有繼續往前的動力，在生活中也度過許多歡笑的 日子。還要謝謝學弟妹政傑、莉婷、芃安在口試上的協助，同商業智慧實驗室的 同學兆瑜、韋綸、謹豪、冠呈、逸芸在這段時間的鼓勵，還有許多一起努力的同 學們，在這兩年中我們一起面對難關互相加油、一起微笑過日子，因為有你們大 家的存在才使得生活如此多彩多姿，真的謝謝大家。
最後，我要謝謝我的家人，因為有你們在背後的支持與打氣，我才可以盡全 力來完成此論文，因此我將此篇論文獻給我的家人，希望你們與我共同分享此次 的榮耀。
目 錄
摘摘
摘摘 要要要要... I Abstract ... II 致致
致致 謝謝謝謝...III 目
目 目
目 錄錄錄錄... IV 圖目錄圖目錄
圖目錄圖目錄... VI 表目錄
表目錄 表目錄
表目錄... VIII
第一章第一章
第一章第一章 緒論緒論緒論緒論... 1
1.1 研究背景... 1
1.2 動機與目的... 5
1.3 論文架構... 7
第二章第二章 第二章第二章 相關研究相關研究相關研究相關研究... 8
2.1 行動計算環境... 8
2.2 資料廣播... 10
2.3 暫存資料的一致性... 13
第三章第三章 第三章第三章 系統模式系統模式系統模式系統模式... 16
3.1 資料庫伺服端與廣播伺服端... 16
3.2 行動客戶端... 18
第四章 第四章 第四章 第四章 使用版本集合放鬆互斥一致性的資料暫存方法使用版本集合放鬆互斥一致性的資料暫存方法使用版本集合放鬆互斥一致性的資料暫存方法使用版本集合放鬆互斥一致性的資料暫存方法... 20
4.1 版本集合... 20
4.2 資料暫存方法... 22
4.3 實例說明... 27
第五章 第五章 第五章 第五章 實驗設計與分析實驗設計與分析實驗設計與分析實驗設計與分析... 36
5.1 實驗設計... 36
5.2 效能分析... 39
第六章第六章
第六章第六章 結論結論結論結論... 47 參考文獻
參考文獻 參考文獻
參考文獻... 49 附錄附錄
附錄附錄 VS 程式碼程式碼程式碼程式碼... 52
圖目錄
圖 1-1 行動計算環境... 2
圖 2-1 廣播磁碟的架構...11
圖 2-2 TS 架構... 13
圖 3-1 資料廣播環境的系統架構圖... 16
圖 3-2 廣播結構... 17
圖 3-3 廣播週期... 17
圖 4-1 使用版本集合的行動客戶端架構圖... 21
圖 4-2 處理查詢到達事件的演算法... 24
圖 4-3 處理驗證報告到達事件的演算法... 25
圖 4-4 處理監聽到達事件的演算法... 26
圖 4-5 CASE1 資料庫伺服端狀態 ... 28
圖 4-6 CASE1 行動客戶端狀態 ... 29
圖 4-7 CASE1 查詢到達後行動客戶端狀態 ... 29
圖 4-8 CASE1 監聽資料到達後行動客戶端端狀態 ... 30
圖 4-9 CASE2 資料庫伺服端狀態 ... 31
圖 4-10 CASE2 行動客戶端狀態 ... 32
圖 4-11 CASE2 查詢到達後行動客戶端狀態 ... 32
圖 4-12 CASE2 驗證報告到達後行動客戶端狀態 ... 33
圖 4-13 CASE2 監聽資料到達後行動客戶端狀態 ... 33
圖 4-14 CASE3 資料庫伺服端狀態 ... 34
圖 4-15 CASE3 行動客戶端狀態 ... 35
圖 4-16 CASE3 查詢到達後行動客戶端狀態 ... 35
圖 5-1 行動客戶端暫存記憶體容量... 40
圖 5-2 行動客戶端查詢的平均到達時間... 41
圖 5-3 資料庫伺服端更新的平均到達時間... 43 圖 5-4 行動客戶端離線機率... 45
表目錄
表 4-1 符號的定義... 22
表 5-1 實驗參數與預設值... 37
表 5-2 行動客戶端暫存記憶體容量... 39
表 5-3 行動客戶端查詢的平均到達時間... 41
表 5-4 資料庫伺服端更新的平均到達時間... 43
表 5-5 行動客戶端離線機率... 44
第一章 緒論
隨著無線網路技術的發展，使用者可以在任何時間、任何地點，透過可攜式 設備執行日常生活的應用，這種計算環境被稱為行動計算環境(Mobile computing environments)[2]。但是當大量的行動客戶端(Mobile client)同時查詢某些資料項 時，這可能會造成行動客戶端與資料庫伺服端間上下傳通道的不敷使用，導致行 動客戶端執行應用程式的反應時間(Response time)過長，或是因為無法競爭到通 訊通道使得應用程式無法執行。幸運的，此種規模性(Scalability)的問題已經被學 界利用資料廣播(Data broadcasting)方法來克服。在資料廣播環境下，當使用者經 常性查詢相同資料項時，行動設備便要重覆的接收同一資料項，如此一來會花費 許多等待時間在擷取相同資料項，若將查詢過的資料項儲存於行動客戶端的暫存 記憶體(Cache)中，當使用者要再次查詢相同資料項時則可直接使用暫存記憶體 中的資料項來回答此次查詢，但要如何有效的保留資料項及驗證資料項的正確 性，則是我們所關切的重點。
在本章中我們會將介紹研究背景，研究背景中包含行動計算環境的內容及特 性，接著介紹本研究的動機與目的，最後介紹本論文的架構。
1.1 研究背景
隨著科技不斷地進步，無線網路儼然已成為人們類生活中的一部份，人們可 利用行動設備，例如個人數位助理、無線電腦、無線電話等，在任何時間、任何 地點透過無線網路來執行日常生活的應用，例如，某位旅行者可以利用掌上型電 腦(Palmtops)透過無線網路來查詢他所需的地圖和天氣資訊。我們將這種結合行 動設備與無線通訊技術而成的系統稱為行動計算環境[2]。
行動計算環境如圖 1-1 所示，行動計算架構中主要是由固定式主機(Fixed Host) 和行動主機(Mobile Unit)所組成。行動主機指的是具有行動裝置(UMPC、PDA、
NoteBook 等具有行動通訊的產品)的行動客戶端，利用無線傳輸方式和固定式主 機做連結，而各個固定式主機的資料通訊或傳輸皆利用有線網路來完成，若固定
式主機若同時擁有無線通訊傳輸功能，我們又稱之行動支援工作站(Mobile Support Station, MSS)。行動支援工作站為行動主機和固定式主機的傳輸媒介，當 行動主機想執行應用時便利用無線網路連接到行動支援工作站，再透過行動支援 工作站將訊息經由有線網路傳送給固定式主機，等到固定式主機完成服務，亦透 過行動支援工作站將結果傳送給行動主機，以完成行動主機所執行之應用。
每個固定式主機只服務自己覆蓋區域中的行動主機，此覆蓋區域稱之為蜂巢 (Cell)，而每個行動主機在同一時間點，只能隸屬於一個固定式主機，以方便行 動支援工作站管理行動主機與紀錄行動主機目前所在位置。行動主機可以在接收 資訊的同時從一個區域移動到另一個區域，此動作稱為區域轉移(Handoff)[3][4]
圖 1-1 行動計算環境[2]
行動計算環境和傳統的有線網路環境相較下有許多不同的特性，其中最主要 的特性如下[5][6] ：
(1) 通訊媒體的不同
傳統的主從式架構(Client /Server)和行動計算環境最大不同點就是通訊媒體
的不同，行動主機與固定主機的傳輸媒體由傳統的有線通訊網路轉變成無線的通 訊網路，這些無線傳輸媒體包含微波、衛星、紅外線、雷射等方式。行動主機可 利用上傳通道(uplink channel)對固定式主機提出要求，而固定式主機則會透過下 傳通道(downlink channel)將執行結果傳回行動主機。
(2) 行動主機的地點不固定
當行動主機因使用者在不同位置的移動下，使得行動主機由一個區域移動到 另一個區域，此動作稱之為區域轉移(Handoff)。這種區域移轉會對行動式計算環 境產生以下兩個主要的影響：一是行動支援工作站無法迅速掌握每一台行動主機 所在的位置，二是當行動主機在移動時會降低資料傳輸的效率。根據[7]，使用 GSM 技術的行動主機每次區域移轉時會有 300 m sec 的資料遺失。
(3) 有限的電池電源
行動主機為了移動性通常使用電池來供應電力，一般電池電力供應只能維持 數小時至數十小時[5]，而行動主機在通訊與磁碟機的讀寫是消耗最多電力的動 作[8]，因此行動主機為了節省電源通常會處於離線狀態或睡眠模式(Doze mode) 以減少能源的消耗。除此，由於技術問題，在未來幾年間電池容量的成長只會有 20%的成長率[9]。
(4) 頻繁的離線
行動主機會因節省電力進入睡眠模式(Doze mode)而離線，或遭受障礙物干 擾、環境影響等原因，使得行動主機將常處於離線的狀態下，在這種經常性的離 線狀態下會增加通訊的困難度(資訊要重送)，降低資料傳輸效率。
(5) 頻寬有限
當行動支援工作站採用不同網路技術時，其傳輸的速率有很大的不同[6]，
使用大哥大技術(GSM)其速率約略為 19.2 Kbps，而使用 802.11a/g[10]的區域網路 技術，其速率約略為 2 Mbps 到 54 Mbps。大致上來說行動計算環境下的頻寬相 對於以往有限網路上的頻寬，明顯小很多。
由於行動計算環境上有以上諸多特性，因此我們希望用更有效率的方法來降
低網路流量、減少電力的使用、允許行動主機可以頻繁的離線。在原來的行動計 算環境中當行動主機(以下通稱為行動客戶端)要進行查詢交易時，必經由上傳通 道(Uplink channel)向固定主機(以下通稱為資料庫伺服端)提出服務要求，當資料 庫伺服端完成此項要求時再經由下傳通道(Down channel)將其結果傳送給行動客 戶端，在此一來一往間必會造成頻寬的損耗，且行動客戶端在傳送資料時所花費 的電力遠大於接收時[11]。當大量的行動客戶端向資料庫伺服端查詢同一資料項 時，可能會造成上下傳通道的不敷使用導致行動客戶端執行程式的反應時間 (Response time)過長，或是無法競爭到通訊通道而導致應用程式無法執行。
上述此種規模性(Scalability)的問題已被學界利用資料廣播方法來解決。在資 料廣播方法中，將由資料庫伺服端透過廣播伺服端將根據廣播結構(Broadcast structure)進行廣播，將行動客戶端感興趣的資料以廣播方式主動將資料「推」
(Push)給行動客戶端。而行動客戶端只須監聽廣播通道(Broadcast channel)中是否 有自己所需的資料項正被廣播，若發現所需資料項正在被廣播當中即可直接擷取 資料項來使用，而無須再向資料庫伺服端做要求資料的動作。而廣播伺服端根據 廣播結構進行一次資料廣播稱為廣播週期(Broadcast cycle)。利用資料廣播方法使 得資料庫伺服端在僅使用一個下傳通道的情況下將所有行動客戶端所感興趣以 週期廣播的方式廣播出，如此行動客戶端不必再競爭連接資料庫伺服的通訊通 道，這使得整個行動計算環境中執行應用時的成本與效能並不會受到行動客戶端 數量的影響，我們稱這種資料庫伺服端以資料廣播方式傳遞資料給行動客戶端的 行動計算環境為「資料廣播環境」。
在資料廣播環境中，行動客戶端為了減少再次擷取同一資料的等待時間，而 將已經擷取過的資料項保留於暫存記憶體(Cache)[12]中並共下次查詢時使用。這 樣一來資料庫伺服端與行動客戶端暫存記憶體內的資料項便有若干相同，但當資 料庫伺服端的資料產生異動時，而行動客戶端的暫存記憶體中的資料項並無同時 更改其內容，那麼將會產生資料庫伺服端的資料項與行動客戶端暫存記憶體內的 資料項有不一致的情況發生。如果此時行動客戶端提出了查詢資料項的要求，並
使用了暫存記憶體中不一致的資料項時，可能導致應用執行產生錯誤的結果。因 此如何維持暫存資料的一致性是行動客戶端使用暫存資料時的一個重要課題。
1.2 動機與目的
行動客戶端暫存記憶內資料項的一致性問題將會影響使用者執行應用的結 果，為了保持暫存資料項一致性的問題，美國 Rutgers 大學的學者 Barbara 與 Imielinski[4] 針 對 行 動 計 算 環 境 的 特 性 提 出 了 初 步 快 取 失 效 策 略 (Cache invalidation strategy)的資料驗證架構，在此驗證架構下，當資料庫伺服端執行並 完成交易後，資料庫伺服端會將此次異動資訊存放至異動佇列中，然後等到通知 行動客戶端時間到達時，便根據異動佇列中的內容產生驗證報告(Invalidation report)，以定期廣播的方式將驗證報告傳遞給所有的行動客戶端。當行動客戶端 接收到驗證報告後，會根據驗證報告的內容將暫存記憶體中的失效資料項刪除，
以維持暫存資料的一致性。
在行動計算環境中使用定期傳送驗證報告的架構具有以下優點。第一、將多 次異動資訊合併成一個驗證報告後，當異動產生時不須立即傳送異動資訊給行動 客戶端，只須在廣播時間到達時傳送一次驗證報告便可將某段時間內的異動資訊 傳遞給行動客戶端，如此ㄧ來可減少傳送訊息的次數。第二、由於行動客戶端要 進行電力的管理，在平時可進入睡眠模式(Doze mode)，當驗證報告廣播時再恢 復成活動模式(Active Mode)即可接收所有的驗證訊息，而不需擔心於斷線時錯失 伺服端的驗證訊息。這個系統架構已經由進行相關研究的學者所廣為採用 [13][14][15][16]。
本研究中的暫存資料的驗證方法也延續使用 Barbara 與 Imielinski 所提出的 系統架構[4]。在 Barbara 與 Imielinski 所提出的架構下，在行動客戶端提出查詢 要求時並不做任何處理，只將查詢儲存於查詢佇列中，等待下次驗證報告到達並 完成暫存資料驗證後，再對查詢佇列中的內容做處理。當暫存資料項經過驗證後 其一致性狀態為互斥一致性(Mutual consistency) ，行動客戶端所使用的暫存資料
項皆為資料庫伺服端的最新狀態，在此驗證架構下可確保行動客戶端不會讀到陳 舊(Stale)的資料。可是這個方法也有以下的缺點：
(1) 若行動客戶端提出查詢時，所需資料項皆在暫存記憶體中且並非陳舊資料，
但也無法回答並完成使用者的查詢(實際上，此時應該可將結果傳回給使用 者)，仍必須等到下個驗證報告到達後並完成暫存資料的驗證後，才能將查詢 結果傳回給使用者，如此ㄧ來會造成不必要的等待時間。
(2) 同樣的，假設行動客戶端所查詢的資料項皆在暫存記憶體中，且暫存資料並 非陳舊資料。若此行動客戶端因為障礙物或其他原因造成斷線而無法接收到 驗證報告，為了維持暫存資料的互斥一致性，行動客戶端必須在收到驗證報 告並完成資料驗證後才能處理這個查詢。因此，在斷線期間即便是查詢所需 的資料項皆存暫存於行動客戶端中，而行動客戶端可能處在停滯(Halt)的狀 態，無法處理任何的查詢。
為了克服上述的缺點，使行動客戶端能更有彈性的使用暫存資料來處理應 用，且在真實行動計算環境中，有許多情況下行動客戶端可接受並使用稍早的資 訊時，像是天氣預報、快遞商品追蹤等等皆在此種情況下，因此我們考慮放鬆暫 存資料的互斥一致性，讓使用者在每次提出查詢後所得的結果，只要維持在過去 某一個一致性狀態上便可，但在放鬆暫存資料的互斥一致性狀態後，代表行動客 戶端中的暫存資訊可能不是資料庫伺服端中的最新資訊，但是我們也不希望行動 客戶端使用過於陳舊或甚至錯誤的暫存資料，造成使用者執行上的錯誤。在先前 的工作[14]中，我們已經在放鬆互斥一致性的前提下，提出一個在行動客戶端使 用版本集合(Version sets)進行暫存資料管理的方法，我們將延續此方法的精神再 繼續研究其正確性並做系統的模擬來驗證此方法，這個方法不但能以較短的處理 時間完成應用的執行，同時也能根據行動客戶端與伺服端資料庫的通訊狀態，使 用不同程度的一致性暫存資料。這個方法在通訊狀態良好時幾乎可以達到互斥一 致性，當通訊狀態不好時，也能根據行動客戶端現有暫存資料提供給使用者最佳 的服務。
1.3 論文架構
本論文架構如下：第二章將會介紹行動環境中行動客戶端與資料庫伺服端不 同架構或運作方式的而產生的分類及行動計算環境下的相關研究；在第三章將說 明資料廣播環境中資料庫伺服端、廣播伺服端及行動客戶端的架構與運作方式；
第四章為資料廣播環境中的行動客戶端加入版本集合後的運作方式：第五章為實 驗設計與分析，將會介紹我們如何利用系統模擬的方式來達到效能的評估以及分 析：第六章則為我們的結論。
第二章 相關研究
在本章中我們首先介紹行動計算環境的背景知識，說明在行動客戶端、資料 庫伺服端的不同架構及運作下又有哪些分類。接著，將介紹行動計算環境下資料 廣播相關研究。最後，則是介紹當行動客戶端利用暫存記憶體中存放資料項供下 次查詢使用，為了驗證暫存記憶體中資料的正確性而產生的快取失效策略。
2.1 行動計算環境
在行動客戶端方面，我們可以依據使用者的行動設備是否具備暫存記憶體來 暫存資料項，可區分為沒有暫存記憶體和有暫存記憶體兩類[1][5]：
(1) 沒有暫存記憶體
當行動設備並無設置暫存記憶體時，若使用者要查詢資料項必定經由上傳通 道(Uplink channel)和資料庫伺服端要求服務。當大量查詢來臨時必定會造成頻寬 的浪費，特別在行動客戶端查詢相同的資料項上。
(2) 有暫存記憶體
當行動設備中含有快取記憶體時，可將查詢過的資料項儲存於暫存記憶體 中，等到下次要查詢相同資料項時，可直接擷取快取記憶體中的資料項來回答查 詢。這樣不僅可減少頻寬的浪費且可減少查詢時的等待時間，但要注意到快取記 憶體中的資料和資料庫伺服端資料的一致性問題。
在資料庫伺服端方面，由於行動客戶端會依照其所需下載資料項是否有效、
記憶體大小等原因更動其記憶體的內容，所以資料庫伺服端很難精準的掌握每一 個行動客戶端的暫存資料。而對於資料庫伺服端對於是否掌握行動客戶端中的暫 存資料可以分為有狀態伺服端(Stateful Server)和無狀態伺服端(Stateless Server) 兩類[4]：
(1) 有狀態伺服端
在此架構下，資料庫伺服端知道行動客戶端目前是否處於自己的涵蓋的蜂巢 (Cell)中，同時也掌握住每個行動客戶端的暫存資料內容 ，當行動客戶端中所擁
有的資料項在資料庫伺服端上產生異動時，資料庫伺服端透過廣播伺服端主動傳 送驗證報告(Invalidation reports)給擁有相同資料項的行動客戶端。相對的，行動 客戶端會依據驗證報告來對暫存記憶體中的資料來做相對應的動作，但是當行動 客戶端正處於離線狀態時就無法接收驗證報告，那麼就有可能造成暫存資料項和 資料庫伺服端有資料不一致的狀態發生。為了維護暫存資料項的狀態，行動客戶 端必須告知資料庫伺服端何時進入、離開蜂巢及何時離線或重新上線。
(2) 無狀態伺服器
在此架構下，資料庫伺服端不會有任何資訊關於行動客戶端的資料，包含行 動客戶端是否處於自己的涵蓋的蜂巢(Cell)中、行動客戶端中暫存記憶體相關資 訊等等。當資料庫伺服端有異動產生時，廣播伺服端將會定期或不定期的傳送驗 證報告給行動客戶端，行動客戶端再依照此驗證報告及演算法來做相對應動作。
行動客戶端也會因離線狀態而無法接收驗證報告，使得行動客戶端所擁有的暫存 資料產生不一致的情形，為了解決此問題，廣播伺服端所傳送的驗證報告通常會 包含數個區段內的異動資訊。
在無狀態伺服器底下，廣播伺服端在不同時間點上傳送驗證報告，可分為非 同步(Asynchronous)與同步(Synchronous)兩種[4]：
(1) 非同步：
非同步的方式是當資料庫伺服端資料產生異動時，廣播伺服端會立即傳送驗 證報告給所有的行動客戶端，當行動客戶端是處於上線狀態時，便可馬上利用驗 證報告來驗證快取記憶體中的暫存資料。但若行動客戶端處於離線狀態時，便無 法接收驗證報告，此時，容易造成暫存資料不一致的狀況產生。
(2) 同步：
同步的方式是當資料庫伺服端有資料產生異動時，廣播伺服端不會立即傳送 驗證報告，而是先將異動資訊儲存於異動佇列中，等到廣播週期時間到達後，廣 播伺服端再依照異動佇列的內容製作成驗證報告，並將驗證報告廣播給各個行動 客戶端，例如：廣播伺服端每隔 L 秒廣播一次驗證報告，每次驗證報告會涵蓋一
個到數個時段內所發生的異動，因此，可允許行動客戶端在短時間內離線。行動 客戶端則依照著所收到的驗證報告來驗證快取記憶體中的暫存資料，若發現資料 項失效時便至資料庫伺服端做查詢的動作。
行動計算環境中還可依是否能夠提供行動客戶端、資料庫伺服端之間的雙向 溝通，可再分類為非對稱式通訊環境(Asymmetric Communication Environments) 與對稱式通訊環境(Symmetric Communication Environments)[2]。
(1) 非對稱式通訊環境
在非對稱式網路通訊環境之下，僅允許廣播伺服端單方向向行動客戶端以廣 播方式發送訊息，而不允許行動客戶端主動向資料庫伺服端發出資料需求之請 求，行動客戶端只能被動的從廣播伺服端所廣播出來的訊息中擷取適用之資訊。
(2) 對稱式通訊環境
在對稱式通訊環境之下，行動客戶端與資料庫伺服端可以做雙向溝通。行動 客戶端可以向資料庫伺服端提出查詢資料項的要求，當伺服端完成要求後，在將 其結果傳送給行動客戶端。
2.2 資料廣播
在過去利用有線網路達成通訊的環境中，大多數採主從式(Client/Server)的網 路架構，由客戶端對資料庫伺服端提出要求，資料庫伺服端在完成服務後便將結 果傳回給客戶端，而在行動計算環境中也同時存在此種點對點(Point-to-Point)的 網路架構，由行動客戶端向資料庫伺服端提出查詢資料項的要求，當資料庫伺服 端完成查詢後便將結果傳回給行動客戶端，此時若再有行動客戶端再向資料庫伺 服端要求查詢同一資料項時，資料庫伺服端還是必須傳送相同資料項給此行動客 戶端，當有大量行動客戶端要求同一資料項，那資料庫伺服端則必須在有限的頻 寬下不斷地傳送同一資料項，如此便會造成頻寬的浪費並造成某些行動客戶端無 法競爭到通訊頻道，且單一資料庫伺服器有可能會面臨到服務大量的行動客戶端 的問題。為了改善以上問題，所以在[12]中，作者提出ㄧ個廣播磁碟的架構
(Broadcast Disk)，如圖 2-1 所示。
圖 2-1 廣播磁碟的架構
廣播磁碟架構為資料廣播的架構，資料廣播是利用一個廣播通道將行動客戶 端所感興趣的資料項以循環的方式不斷地廣播，其週而復始的廣播就如同磁碟機 上持續的運轉。由廣播伺服端在廣播通道中重複的廣播資料項，而行動客戶端自 行至廣播通道當中擷取所需的資料項。在不同的廣播通道上的資料會經由廣播伺 服端決定不同的廣播結構，較熱門的資料項將以較密集的方式撥出，就如同轉動 較快的資料磁碟機上的運作，那麼這些熱門的資料項就會被廣播較多的次數。此 種利用廣播資料讓客戶端擷取資料的方式，可大大地減少資料庫伺服端傳送相同 資料項給行動客戶端的動作，此方法應用在現實生活中，例如線上新聞、股市買 賣交易資訊等，都能有效的將熱門資料傳送給大量的客戶端。
當使用資料廣播方式時，行動客戶端只需在廣播通道中擷取所需資料項，如 此ㄧ來可減少行動客戶端向資料庫伺服端要求資料及資料庫伺服端回應要求時 所佔用的頻寬。且行動客戶端上傳資料項的電力損耗遠大於下載資料項[12]，因 此使用資料廣播方法可減少行動客戶端上傳要求資料項的動作並同時達到節省 電力的目的。除此，當利用廣播方式來傳送資料項時，可允許大量的行動客戶
端在同ㄧ時間點存取資料項，廣播伺服端的效能並不會受到行動客戶端數量多 寡的影響，而行動客戶端也無須競爭通訊通道來完成應用程式。
在資料廣播環境中，行動客戶端在的狀態可分為活動模式(Active mode)與睡 眠模式(Doze mode)，當行動客戶端在監聽資料廣播時為活動模式，但長期的監 聽資料廣播時會造成電力的損耗，因此行動客戶端不需長期監聽廣播通道中的內 容，在平時處於睡眠模式中以節省電力，等到監聽資料項來臨時再切換到活動模 式。要達到此目的最有效率的方式為使用索引技術，因此有許多研究[2][18][19]
利用樹狀的結構運用在索引的技術上，例如使用索引樹(Index tree)的架構來加以 改變廣播排程的結構，當行動客戶端要擷取某資料項時，必須進入廣播通道中取 得索引資訊，並判斷所需資料項將會在何時被廣播伺服器廣播出，當判斷結束後 便進入睡眠模式，等到所需資料項將被廣播，再恢復為活動模式擷取資料項，如 此ㄧ來便可有效的達到省電的目的。
在上述整個資料廣播環境當中，若行動客戶端本身具有暫存記憶體(Cache) 時，當行動客戶端經由廣播通道中擷取所需資料項後，可將資料項存放於暫存記 憶體中，供行動客戶端再次的使用。當行動客戶端所要求查詢的資料項皆在暫存 記憶體中搜尋到，便可減少等待廣播伺服端廣播資料項的時間，如此ㄧ來便可增 進使用資料廣播的效能[20]。行動客戶端的記憶體管理又可分為兩大部分，分別 為資料項如何進入暫存記憶體中、資料項如何自暫存記憶體離開。關於第一個部 份：資料項如何進入暫存記憶體的方式有兩種，第一種方式為當行動客戶端提出 查詢資料項要求時，發現暫存記憶體並無此資料項，便自廣播通道中擷取此次所 需的資料項，並將資料項存入暫存記憶體中，第二種方式為預先抓取方式 (Prefetch)[21]，預先抓取方式是當使用者尚未查詢資料項時，先將資料項自廣播 通道中擷取下來存放於記憶體中，供使用者在未來使用，這樣一來當使用者查詢 資料項時，不用等待廣播伺服端廣播所需資料項的時間。關於第二個部份：資料 項如何自暫存記憶體離開也有兩種方式，第一種方式為暫存記憶體中的資料項在 經過驗證報告驗證後，發現資料項已失效，便將此失效資料項自暫存記憶體中刪
除[4][11][14][15][22]，第二種方式為暫存記憶體的容量已使用完畢，當新的資料 項到達時並無空間可存放，所以必須將目前暫存記憶體中的資料項置換出去，讓 新 到 達 的 資 料 項 有 空 間 可 使 用 ， 相 關 置 換 策 略 的 方 式 有 LRU[20] 、 Gray algorithm[20]等等方法。
2.3 暫存資料的一致性
在解決行動計算中規模性問題後，各學者又針對行動客戶端如何有效地再次 使用已到達行動客戶端的資料項做探討，為達到此目的便在行動客戶端設置暫存 記憶體(Cache)供行動客戶端存放已擷取的資料項，當使用者要求查詢相同資料 項時便可直接至暫存記憶體找尋資料。但將資料存放於行動客戶端的暫存記憶體 中時便要注意暫存資料與資料庫伺服端資料的一致性問題，而我們採用驗證方式 來到達維持暫存資料一致性的問題。
在[4]中，作者提出廣播時間戳記(Broadcasting timestamps)，通常簡稱為 TS 法，而本研究的計畫也將延續此架構，因此，在此先將此方法做一番簡介。此方 法為經典的快取失效策略方法。TS 法的主要概念是將許多異動資訊壓縮成ㄧ個 驗證報告(Invalidation Report)，再將此驗證報告週期地廣播給行動客戶端做暫存 資料的驗證，如此一來便可減少頻寬的損耗，而行動客戶端只要接收驗證報告便 可達到省電的目的，TS 方法如圖 2-2 所示。
圖 2-2 TS 架構
在 TS 方法中，當資料庫伺服端有異動產生時，會先將所有異動資訊紀錄於
資料庫伺服端中的異動佇列中，而異動資訊包含異動資料項的識別碼與異動時 間，等到廣播週期將要到達時，廣播伺服端會根據異動佇列中的內容製作驗證報 告，等到廣播週期的時間到達後，廣播伺服端便廣播驗證報告(Invalidation Report) 給行動客戶端。驗證報告中所含的資料項目皆是在更新視窗(Update Windows)中 所更新的資料項，更新視窗的時間長度則是由 w 個廣播週期所組成。
當行動客戶端提出查詢時，查詢處理程式並不會對此查詢做處理，而是先將 查詢儲存於查詢佇列中並等待下一次驗證報告的來臨，當行動客戶端收到驗證報 告並驗證暫存記憶體中的暫存資料項後，才開始處理查詢。行動客戶端接收到驗 證報告時，首先判斷行動客戶端的離線時間是否超出驗證報告可驗證的範圍。若 行動客戶端的離線時間超過驗證報告可驗證範圍，就無法利用此次驗證報告來驗 證暫存資料的正確性，因此必須刪除所有的暫存資料，即使有某部分暫存資料項 為正確的也必須刪除，這樣可避免行動客戶端使用到失效的資料項。若行動客戶 端的離線時間在此驗證報告可以驗證範圍內，便可利用驗證報告對暫存記憶體做 驗證。暫存記憶體中的資料項也有自己的時間戳記，我們要驗證某個資料項時就 必須要比對驗證報告及暫存資料中資料項的時間戳記，若經驗證後發現暫存資料 已失效就必須刪除，反之則保留此資料項。當完成驗證後，發現查詢所要求的資 料項皆在暫存記憶體中便回答並結束此資料項，如果查詢所要求的資料項並不在 暫存記憶體中，行動客戶端便向廣播伺服端要求所需資料項以完成查詢。
由於 TS 法所發出的驗證報告是包含於更新視窗中所有的異動資訊，因此當 行動客戶端是屬於短暫時間的離線(離線時間尚在驗證報告可驗證範圍中)，便可 利用驗證報告來維持快取記憶體的正確性。而行動客戶端除了在提出查詢及接收 驗證報告外，絕大多數的時間都是進入睡眠模式(Doze mode)，因此可節省電力 的使用達到延長待機時間，但唯一的缺點是當行動客戶端在長時間離線時須刪除 暫存記憶體中所有的資料項，這一樣來有可能會刪除到正確的資料項，當行動客 戶端又要查詢此資料項時，則必須重新向伺服端要求資料，如此ㄧ來會造成頻寬 的損耗，並增加了行動客戶端等到資料項的時間。
除了上述的廣播時間戳記(Broadcasting timestamps)方法外，在行動計算環境 中還有許多關於暫存資料一致性問題的研究，由於在行動計算環境中，行動客戶 端受環境或其他干擾等問題，使得資料庫伺服端無法完全掌握行動客戶端的位 置、暫存資料內容與通訊狀態，所以在行目前行動計算環境中[13]的研究把並行 控制與暫存資料的一致性控制分開研究。目前的研究大多是假設異動於伺服端資 料庫確認後，如何與行動客戶端的暫存資料進行一致性控制[13][14][15][16]。在 [4]中，作者提出健忘終端機(Amnesic terminal)進行暫存資料的一致性控制。其他 同樣使用廣播驗證報告的方式進行暫存資料的一致性控制的研究有位元序列法 (Bit sequence)[14]，與序列號碼法(Serial number)[15]，此兩種方法不但利用驗證 報告來驗證暫存資料，還利用數字編碼來降低驗證報告的容量大小，降低傳送驗 證報告時頻寬的佔用。在大多數廣播驗證報告的研究中，當行動客戶端在長時間 離線又重新上線時，必須將暫存記憶體中的資料完全刪除才可為暫存資料ㄧ致 性，為了避免此種情況產生在[22]中，作者提出保留低異動集合群組(GCORE ： Grouping with cold update-set retention)的方法，在[11]中作者提出廣播基礎群組驗 證法(BGI：Broadcast-based group invalidation)。為了維持暫存資料的互斥一致性，
我們付出了比傳統環境要來的更大的代價。因此我們考慮暫存資料的互斥一致性 是否必要，實際上先前的研究就已經有學者主張在此環境中放鬆互斥一致性。在 [4]中作者討論了在行動式計算環境下使用 Quasi-copies[23]維持暫存資料一致性 的想法。在[16]中，作者延伸多版本(Multiversions)的並行控制法的精神，提出暫 存資料為伺服端資料庫的快照(Snapshot)之想法，進行暫存資料的一致性控制。
邱舉明教授在[24]中，使用 View consistency 與 Local view consistency 作為行動 計算環境中資料一致性的標準。
第三章 系統模式
在本章中將會介紹資料廣播環境中的系統架構，並描述此系統架構中的的主 要內容及運作情形。如圖 3-1 所示，在整個資料廣播環境中整個架構可分為三個 部分，這三個部份分別為資料庫伺服端、廣播伺服端以及行動客戶端。我們將依 序介紹以上三個部份的功能及運作情形。
圖 3-1 資料廣播環境的系統架構圖
3.1 資料庫伺服端與廣播伺服端
在資料廣播環境當中，所有的異動(Updates)皆只能在資料庫伺服端產生，所 以資料庫伺服端的主要功能為執行異動並進行異動時的交易管理(Transaction management)。當資料庫伺服端產生異動時，資料庫伺服端根據並行控制原則來 決定異動執行的先後順序，在異動完成並經過確認後(Commit)，異動管理程式便 將此次異動訊息暫存於異動佇列中，此異動佇列的內容是廣播伺服端產生驗證報 告的依據。
廣播伺服端最主要的功能為根據廣播結構將資料以週期(Periodic)與重複 (Repeat)的廣播方式傳送給行動客戶端。廣播伺服端根據廣播結構播完一次內容 稱為廣播週期(Broadcast cycle)。廣播結構如圖 3-2 所示，其內容包含三個部份分 別為：驗證報告、時間索引、廣播資料。其中驗證報告內容為在前 w 個廣播週
期中已經在資料庫伺服端產生異動的資料項識別碼與異動時間，如圖 3-3 所示，
假設目前時間為 Ti，L 為廣播週期的長度，也就是每 L 時間單位長做一次廣播的 動作，更新視窗(Update windows)則為驗證報告可驗證之範圍，由 w 個廣播週期 所組成，也就是從時間點 Ti-3 至 Ti。而廣播資料為本次廣播週期所要廣播的資 料項，其廣播資料的播出順序必需在廣播週期到達前由廣播伺服端決定，等廣播 資料決定後廣播伺服端再依據廣播資料的順序產生時間索引，整個廣播結構的順 序則為驗證報告、時間索引、廣播資料。
圖 3-2 廣播結構
圖 3-3 廣播週期
資料庫伺服端與廣播伺服端的協同運作如下：當異動交易在資料庫伺服端確 認後，便將此次的異動資訊存放於異動佇列中。當新的廣播週期即將要開始時，
廣播伺服端便依據異動佇列中的內容產生驗證報告，同時至資料庫中取出此次所 要廣播的資料項存放於資料廣播暫存區，當下一週期的廣播開始後，便將驗證報 告、時間索引、廣播資料利用廣播通道傳送給行動客戶端。
在上述過程中，由於廣播伺服端採用週期方式來廣播資料庫中的內容，因此 廣播伺服端也利用週期的方式向資料庫伺服端讀取所有廣播資料的內容，以維持 同一廣播週期資料項之間的一致性。由此之故，當資料庫伺服端中的資料項因進
time Ti
Ti-1
Ti-2
Ti-3
廣播週期
Ti-4
驗證報告 時間索引 廣播資料
更新視窗
行異動而產生內容的改變時，這些被異動的資料項狀態並不會馬上透過廣播伺服 端播出，而是等待由下個週期廣播伺服端準備進行新一週期的資料廣播時，才由 廣播伺服端向資料庫伺服端讀取最新狀態的資料後，資料庫中的最新狀態才會在 廣播伺服端中反應出。
3.2 行動客戶端
行動客戶端在資料廣播環境當中的主要任務為接受並完成使用者所提出的 應用。針對此一目的，我們必須考慮兩個問題。第一個問題是行動客戶端如何重 新使用已經擷取的資料項，同時確保使用這些資料項所完成的應用程式可滿足使 用者的需求，第二個問題則是行動客戶端如何有效地自廣播通道中擷取使用者所 需的資料項，關於第一個問題，我們將會再行動客戶端中設置一個暫存記憶體 (Cache)儲存行動客戶端已擷取到的資料項，供行動客戶端再次查詢相同資料項 時使用。至於第二個問題，行動客戶端將會設置監聽佇列儲放所需資料項的識別 碼，當行動客戶端執行應用時，行動客戶端會將執行應用程式時所欠缺的資料項 識別碼加入至監聽佇列中。當下一週期的廣播到達且行動客戶端完成暫存資料項 的驗證之後，監聽程式會讀取時間索引，以取得監聽佇列中各資料項的廣播時 間，接著監聽程式依據監聽佇列中各資料項的廣播時間，逐一地將資料項載入暫 存記憶體中。
行動客戶端的運作情形如下，當行動客戶端接收到使用者查詢資料項的要求 後，查詢處理程式(Query processing program)首先找出此查詢需要哪些資料項，
再到暫存記憶體中檢查此次查詢所需的資料項是否皆在暫存記憶體中，如果是的 話則回答並結束此次查詢，如果不是的話查詢處理程式將此查詢儲存於查詢佇列 (Query queue)中並把所需資料項的識別碼加入監聽佇列中(Listen queue)，等待下 次驗證報告的到來。當驗證報告到達後，行動客戶端依據驗證報告的內容對暫存 記憶體中的資料項進行驗證，當發現暫存記憶體內的資料項失效時，將此失效資 料項刪除，藉由此驗證過程可將資料項狀態更新至與資料伺服端相同的狀態下。
當暫存資料項的正確性經驗證後，廣播監聽程式便依據時間索引將監聽佇列中所 需的資料項自下傳通道載入暫存記憶體中，接著開始檢查查詢佇列中的所存放的 查詢，是否有某個查詢所需的資料項皆處於暫存記憶體中，如果資料項皆在暫存 記憶體中時則回答並結束此查詢。
在上述的執行過程中，由於行動客戶端的暫存資料都是自下傳通道擷取廣播 資料而來，因此只要行動客戶端所使用的暫存資料是來自同一廣播週期，暫存資 料便為一致性的資料。因此一個簡單維持暫存資料一致性的方法為在每個廣播週 期結束時便刪除所有行動客戶端的暫存資料，並在下個廣播週期重新擷取執行應 用所需的資料項，如此一來行動客戶端的暫存資料便能永遠保持一致性，但此方 式很有可能將暫存資料中正確的資料刪除，造成行動客戶端不斷地重新擷取這些 正確的資料，特別是使用者經常性查詢此資料項時，行動客戶端將會重覆的等待 資料項自廣播伺服端廣播資料項，造成效能的降低。因此我們採用驗證暫存資料 項的方式，僅刪除行動客戶端暫存資料中已經失效的資料，而正確的資料得以保 留，供行動客戶端執行下次應用時使用。
第四章 使用版本集合放鬆互斥一致性的資料暫存方法
在大多數的行動計算環境中，多以互斥一致性做為執行應用時的標準，像是 網路訂購系統、股市價格查詢等等，伺服端都是以資料庫中最新狀態來回應使用 者所要求的服務。然而在真實的行動計算環境中，有許多情況下使用者可以接受 較舊的資訊，例如交通資訊系每五分鐘更新一次交通資訊，當使用者提出查詢的 要求，所得到的資訊是十分鐘前的資訊，對於使用者來說尚在可接受的範圍中，
諸如快遞商品追蹤、天氣預報等等，都可接受較早期的資訊。因此，我們希望將 行動客戶端執行應用時的正確性標準由互斥一致性放鬆為只要讀到過去一致性 的資料即可。
4.1 版本集合
本研究方法是延續[17]中的成果，將行動客戶端執行應用時的正確性標準由 互斥一致性放鬆為讀到過去一致性的資料即可，為達成此目的我們將行動客戶端 的暫存記憶體劃分為三個區塊，如圖 4-1 所示，分別用來存放三個不同的版本集 合(Version sets)，分別是新版本集合(New version set)、目前版本集合(Current version set)與失效版本集合(Invalid version set)。並設計一套控制這些版本集合的 方法，透過版本集合與控制方法可將行動客戶端暫存資料的正確性放鬆為過去一 致性的狀態，但同時可避免行動客戶端使用到過於陳舊的資訊，導致行動客戶端 在執行應用時產生錯誤。在本研究的系統架構中，除了行動客戶端的暫存記憶體 加入版本集合外，其於資料廣播環境的系統架構如同前一章所描述。
行動客戶端暫存記憶體所含的新版本集合、目前版本集合與失效版本集合將 用來存放的不同狀態下時的資料項。新版集合中所存放的資料項為此次廣播週期 所接收到的資料項。目前版本集合中存放上個廣播週期所接收到的資料項，每當 新的廣播週期即將到達時，行動客戶端會將新版本集合中的所有的資料項移到目 前版本集合中。失效版本集合則是存放已失效的資料項，當行動客戶端接收驗證 報告後會對目前版本集合中的資料項做驗證，在驗證過程中若發現暫存資料項失
效時，便將已失效的資料項自目前版本集合中刪除，再加到入失效版本集合中。
圖 4-1 使用版本集合的行動客戶端架構圖
當行動客戶端提出查詢後，查詢處理程式首先會到新版本集合與目前版本集 合組成的共同集合中找尋所需的資料項，若查詢所需的資料項皆在此共同集合的 中，便回答並結束此次查詢，此時所查詢出的結果處於目前一致性的狀態下，若 在此共同集合中無法結束此次查詢，查詢處理程式再到目前版本集合與失效版本 集合組成的共同集合中尋找資料項，若查詢所需資料項皆在此共同集合中也可回 答並結束此次查詢，但必須告知使用者此次查詢結果可能不在互斥一致狀態下。
若無法在暫存記憶體中找尋到所需資料項時，便將此次查詢所欠缺的資料項識別 碼加到監聽佇列中，最後將此次查詢加入查詢佇列中等待下個廣播週期的到達。
當廣播週期到達後，行動客戶端根據驗證報告對目前版本集合中的資料項做驗 證，在完成驗證後監聽程式開始監聽所需資料項，所擷取到的資料項會存放於新 版本集合中，在結束監聽事件後，查詢處理程式開始處理查詢佇列中的查詢，當 查詢所需的資料項皆處於新版本集合與目前版本所組成的共同集合時，便回答並 結束此查詢，此時查詢結果處於互斥一致性的狀態下。
4.2 資料暫存方法
在本節中我們使用事件驅動(Event driven)的方式，說明使用版本集合的資料 暫存方法是如何運作的。使用版本集合的資料暫存方法時，在行動客戶端上共有 三個事件，分別為查詢到達(Query arrival)、驗證報告到達(Invalidation report arrival)與監聽資料到達(Listen data arrival)。我們將依序說明這三個事件的運作方 式。在此之前，我們先介紹各事件的演算法所使用到的符號，再依查詢到達、驗 證報告到達、監聽資料到達的次序依序說明。
首先我們介紹演算法中所使用到的符號。這些符號已經整理如表 4-1。
表 4-1 符號的定義
名稱 描述
VSnew 新版本集合
VScurrent 目前版本集合
VSinvalid 失效版本集合
Data_Item_Set(Query) 查詢 Query 的資料項集合
Get_a_Data_Item(Data_Item_Set(Query)) 從查詢 Query 的資料項集合中，取出一個資料項 Get_a_Data_Item_ID(REPORTinvalidation) 從驗證報告 REPORTinvalidation中，取出一個資料項識別碼
Queuequery 查詢佇列，儲存尚未執行完成的查詢
Queuelisten 監聽佇列
Queryarrival 系統中剛到達的查詢 Data_Itemarrival 系統中剛到達的資料項 ID(Data_Item) 資料項 Data_Item 的識別碼
在本方法中演算法所用到的符號如下：我們將以 VSnew代表暫存記憶體中的 新版本集合，VScurrent代表暫存記憶體中的目前本集合，VSinvalid 代表暫存記憶體 中的失效版本集合。Data_Item_Set(Query)代表所查詢 Query 的資料項集合，
Get_a_Data_Item(Data_Item_Set(Query))代表自查詢到的資料項集合中，取出一個 資 料 項 的 識 別 碼 ， Get_a_Data_Item(REPORTinvalidation) 代 表 自 驗 證 報 告 REPORTinvalidation 中取出一個資料項的識別碼，QUEUEquery 代表查詢佇列，用來 存放尚未完成的查詢，QUEUElisten代表監聽佇列，用來存放需要監聽的資料項的 識別碼，QUEUEEarrival代表系統中剛到達的查詢，Data_Itemarrival 代表系統中剛 到達的資料項，ID(Data_Item)代表資料項 Data_Item 的識別碼。
4.2.1. 查詢到達事件
處理本事件的演算法如圖 4-2，而其處理流程如下：
1. 當行動客戶端收到使用者提出查詢 Queryarrival要求時，首先會判斷暫存記憶 體中的版本集合(表示為 VSnew∪VScurrent∪VSinvalid)是否為空集合，如果為空集 合則執行步驟 4，否則進行下一個步驟。
2. 檢查新版本集合與目前版本集合共同組成的集合中(表示為 VSnew∪VScurren)是 否含有此次所需查詢的資料項(表示為 Data_Item_Set(Queryarrival))，如果是的 話則回答並結束此次查詢，否則進行下一個步驟。
3. 檢查目前版本集合與失效版本集合共同組成的集合(表示為 VScurrent∪VSinvalid) 中是否有此次所需查詢的資料項，如果是的話則回答並結束此次查詢，並告 知使用者此次查詢結果有可能不在互斥一致性下，反之則代表此次查詢所要 求的資料項並未完全暫存於暫存記憶體中，接著進行下一個步驟。
4. 將此查詢所要求的資料項卻未存在行動客戶端暫存記憶體的資料項加入監 聽佇列(表示為 Queuelisten)，也將此次查詢 Queryarrival加入查詢佇列(表示為 Queuequery)中，並結束此事件的執行。
EVENT Query_Arrival GIVEN Queryarrival
//檢查暫存記憶體是否為空集合
IF (VScurrent ∪ VSnewt ∪ VSinvalid) IS EMPTY
DO UNTIL Data_Item_Set(Queryarrival) IS EMPTY
LET Data_Item = Get_a_Data_Item(Data_Item_Set(Queryarrival));
ADD Data_Item TO Queuelisten; LOOP
ADD Queryarrival TO Queuequery
ELSE
//檢查此次查詢的資料項是否皆在 VScurrent ∪ VSnew IF Data_Item_Set(Queryarrival) ⊂ { VScurrent ∪ VSnew }
RETURN THE RESULT OF THIS QUERY;
END OF THIS ROUTINE；
ENDIF
//檢查此次查詢的資料項是否皆在 VScurrent ∪VSinvalid
IF Data_Item_Set(Queryarrival) ⊂ { VScurrent ∪ VSinvalid } RETURN THE RESULT OF THIS QUERY
AND NOTIFY USER THIS RESULT MAY BE NOT CURRENT;
END OF THIS ROUTINE；
ENDIF
//將未在暫存記憶體中的資料項加入監聽佇列並將查詢加到查詢佇列中 DO UNTIL Data_Item_Set(Queryarrival) IS EMPTY
LET Data_Item = Get_a_Data_Item(Data_Item_Set(Queryarrival));
//檢查資料項是否存在於記憶體中
IF Data_Item ∉ { VScurrent ∪ VSnew }AND Data_Item ∉ VSinvalid ADD Data_Item TO Queuelisten;
ENDIF LOOP
ADD Queryarrival TO Queuequery； ENDIF
END
圖 4-2 處理查詢到達事件的演算法
4.2.2. 驗證報告到達
處理本事件的演算法如圖 4-3，而其處理流程如下：
1. 當行動客戶端在廣播週期將要到達時，首先會將新版本集合中的資料項移至 目前版本集合中，等完成此項工作後便進行下一個步驟。
2. 行動客戶端在接收驗證報告(表示為 Reportinvalidation)後，開始並針對目前版本 集合做驗證資料項的動作，把驗證出為失效的資料項從目前版本集合中移至 失效版本集合中。
EVENT Invalidation_Report_Arrival GIVEN Reportinvalidation
DO UNTIL VSnew IS EMPTY
LET Data_Item = Get_a_Data_Item(VSnew);
REMOVE Data_Item FROM VSnew
ADD Data_Item TO VScurrent; LOOP
DO UNTIL Reportinvalidation is EMPTY
LET ID = Get_a_data_Item_ID(Reportinvalidation );
LET Data_Item = ID_To_Data_Item(ID);
IF Data_Item∈VScurrent
REMOVE Data_Item FROM VScurrent; ADD ID(Data_Item) TO Queuelisten; ENDIF
LOOP END
圖 4-3 處理驗證報告到達事件的演算法
4.2.3. 監聽資料到達
處理本事件的演算法如圖 4-4。而其處理流程如下：
1. 當行動客戶端在接收到所監聽的資料項(表示為 Data_Itemarrival)時，首先將資 料項識別碼自監聽佇列中刪除，並檢查此資料項是否為失效版本集合中的失 效資料項(檢查 Data_Itemarrival ∈ VSinvalid)，如果檢查出是的話則將失效資料 項自失效版本集合中刪除，再將剛接收到的資料項 Data_Itemarrival加入新版 本集合中，反之則直接將接收到的資料項加入新版本集合中，接著進行下一 步驟。
2. 檢查查詢佇列中 Queuequery的查詢，確認是否已有查詢所要求的資料項皆完 全存在於新版本集合與目前版本集合共同組成的集合(VSnew∪VScurren)中，如 果是的話則回答並結束此次查詢，同時將此查詢自查詢佇列中刪除。
EVENT Listen_Data_Item_Arrival GIVEN Data_Itemarrival
REMOVE Data_Itemarrival FROM Queuelisten; IF Data_Itemarrival ∈ VSinvalid
REMOVE Data_Itemarrival FROM VSinvalid; ELSE
Data_Item_Replacement_Routine();
ENDIF
ADD Data_Itemarrival TO VSnew
FOR EACH Queue ∈ Queuequery
IF Data_Item_Set(Query) ⊂ { VScurrent ∪ VSnew } RETURN THE RESULT OF THIS QUERY;
ENDIF LOOP END
圖 4-4 處理監聽到達事件的演算法
以上就是我們透過查詢到達、驗證報告到達、監聽資料到達三個事件來維持 客戶端暫存資料一致性的方式，由以上三個事件可看出資料項在三個版本集合下 的移動方式。假設行動客戶端的暫存記憶體一開始並無任何資料項，當廣播週期 到達後，監聽程式便根據監聽佇列中的內容將所需資料項透過廣播通道擷取下 來，並將所擷取資料項放置於新版本集合中，此時行動客戶端的資料便和資料庫 伺服端達到一致性狀態。當下個廣播週期到達後，行動客戶端首先會將新版本集 合中的資料項移到目前版本集合中，再驗證目前版本集合中資料的正確性，將已 失效的資料項移至失效版本集合中，等到所監聽的資料項到達時便接收並加入新 本集合中，如此ㄧ來，行動客戶端暫存記憶體中新版本集合與目前版本集合所組 成的共同集中的資料項，便與本廣播週期中的資料庫伺服端狀態為一致性狀態，
而目前版本集合與失效版本集合所組成的共同集中的資料項，便與上個廣播週期 中的資料庫伺服端狀態為一致性狀態。
在過往的研究中[4,11,15]，在行動客戶端提出查詢後，並不在暫存記憶體中 搜尋所需的資料項，直接把此次查詢要求加入查詢佇列、並將此次查詢在暫存記 憶體中所欠缺的資料項加入監聽佇列，等到驗證報告到達並驗證暫存記憶體中的 資料後，才對查詢做處理。在本研究方法中為了達到放鬆互斥一致性原則下，當 查詢到達時，允許行動客戶端直接搜尋暫存記憶體中的資料項是否符合此次查
詢，首先，查詢處理程式先至新版本集合及目前版本集合中的共同集合中做搜 尋，若此次查詢的資料項皆在此共同集合中，即代表此次查詢結果為目前一致性 的狀態，如果無法在此共同集合中結束查詢，再到目前版本集合中及失效版本集 合的共同集合中做搜尋，若此次查詢的資料項皆在此共同集合中，代表此次查詢 結果處於過去某一次一致性狀態下。若查詢到達時並無法在暫存記憶體中搜尋到 資料項，便將此次查詢存放於查詢佇列中，等待下個廣播週期驗證暫存資料項的 正確性並擷取查詢所需資料項後，再對查詢做處理，此時的查詢結果則符合互斥 一致性的狀態。
4.3 實例說明
本節中將針對資料廣播環境中的資料庫伺服端、廣播伺服端、行動客戶端的 運作情形例用實例來說明。我們將以 bucket 作為時間單位並做二個假設，第一 個假設為資料項的異動只能在資料庫伺服器端上執行，第二個假設為行動客戶端 只能提出查詢，不能執行資料項的異動。
在資料庫伺服端中資料庫共有五個資料項，分別為 D1、D2、D3、D4、D5 並設異動聽佇列用來存放被更新過的資料項的識別碼及更新的時間單位。廣播伺 服端的廣播週期為 10 個時間單位，也就是每 10 個時間單位會做一次廣播的動 作，更新視窗長度為 2，代表每次廣播的驗證報告包含 2 個廣播週期內的異動訊 息，廣播順序則為驗證報告、時間索引、資料區段，由於時間索引非本研究重點，
所以在案例中將以 index 代表廣播內容。在行動客戶端的記憶體中共有三個集 合，分別為新版本集合、目前版本集合、失效版本集合，除此，行動客戶端還設 置監聽佇列、查詢佇列。最後我們假設資料庫伺服端的異動佇列及行動客戶端的 暫存記憶體在一開始時並無任何資料項。
CASE 1
圖 4-5 為資料庫伺服端更新狀況，假設資料庫在時間單位 6 時更新資料項 D2，在確認完成更新後便將資料項 D2 的識別碼及更新時間，加入異動佇列中，
此時異動佇列的內容為(D2,6)。依此類推，資料庫在時間單位 8 更新資料項 D3 後，便將資料項 D3 的識別碼及更新時間加入異動佇列中，最後異動佇列的內容 便為(D2,6)→(D3,8)。等到廣播週期將要到達時會先刪除監聽佇列中超出更新視 窗所涵蓋時間的異動資料項，但目前監聽佇列中並無超出更新視窗可涵蓋的資料 項，因此異動佇列並不做任何變動，只根據異動佇列製作驗證報告，到達後廣播 伺 服 端 開 始 廣 播 [ 驗 證 報 告 ][ 時 間 索 引 ][ 資 料 區 段 ] ， 內 容 為 [D2,D3][index][D1,D2,D3,D4,D5]。
圖 4-5 CASE1 資料庫伺服端狀態
行動客戶端中的暫存記憶體在一開時始並無任何資料項存在，如圖 4-6 所 示，當行動客戶端在時間單位 7 時提出查詢要求，此次查詢的編號為 Q1，查詢 的資料項分別有 D1,D4,D5，查詢處理程式首先會判斷記憶體中的各版本集合是 否有資料項的存在，當發現記憶體中並無資料項存在後，將此次查詢的資料項加 入監聽佇列中，因此監聽佇列的內容為 D1,D4,D5，最後將此次查詢加入查詢佇 列中，查詢佇列中的內容為 Q1(D1,D4,D5)，查詢到達後的行動客戶端記憶體如 圖 4-7 所示。在完成上述動作後行動客戶端開始等待下次的廣播週期到達。
D3
[D1,D2,D3,D4,D5]
8 10
0 6 time
[D2,D3][index]
廣播週期 更新視窗 資料庫伺服端
時間單位 2：異動佇列→(D2,6) 時間單位 8：異動佇列→(D2,6)→(D3,8)
D2 更新 更新
圖 4-6 CASE1 行動客戶端狀態
圖 4-7 CASE1 查詢到達後行動客戶端狀態
當廣播伺服端廣播驗證報告時，由於行動客戶端的記憶體中並無資料項所以 不需驗證，行動客戶端並不做任何處理，直到資料庫開始廣播時間索引時才開始 運作，監聽處理程式首先會根據監聽佇列中的資料項識別碼，來判斷此次要擷取 哪些資料項，並根據時間索引得到所需資料項廣播的時間單位，因此，監聽佇列 會根據時間索引推算出資料項 D1 的廣播時間，等到資料項 D1 被廣播出時，將 資料項 D1 自廣播通道擷取至新版本集合中存放，在完成擷取資料項 D1 後，將 資料項 D1 的識別碼自監聽佇列中移除，此時新版本集合的內容為 D1、監聽佇 列的內容為 D4,D5。依此類推，監聽處理程式也會將監聽佇列中的資料項 D4,D5，自廣播通道中擷取下來並自監聽佇列中移除，在完成擷取監聽資料項後 新版本集合的內容為 D1,D4,D5，而監聽佇列中並無任何監聽資料項識別碼。在
7
查詢編號：Q1 查詢內容：D1,D4,D5 查詢到達
D3
[D1,D2,D3,D4,D5]
8 10
0 6 time
[D2,D3][index]
D2 更新 更新
行動客戶端於時間單位 0 時狀態：
新版本集合：
目前版本集合：
新版本集合：
監聽佇列：
查詢佇列：
查詢到達後行動客戶端狀態：
新版本集合：
目前版本集合：
新版本集合：
監聽佇列：D1,D4,D5 查詢佇列：Q1(D1,D4,D5)
結束監聽事件到達後，查詢處理程式開始檢查查詢佇列中 Q1 所需的資料項 D1,D4,D5 是否皆存在新版本集合與目前版本集合共同組成的集合中，最後發現 此共同集合擁有資料項 D1,D4,D5 可滿足 Q1 的查詢，因此回答並結束本次查詢，
最後將 Q1 自查詢佇列中移除，當執行完上述動作後行動客戶端的記憶體狀態如 圖 4-8 所示。
圖 4-8 CASE1 監聽資料到達後行動客戶端端狀態
CASE 2
本案例是接續上個案例的時間單位 10 再繼續運作，因此資料庫伺服端狀態 及行動客戶端狀態是接續上個案例再繼續延伸。圖 4-9 為資料庫伺服端更新狀 況，假設資料庫在時間單位 13 時更新資料項 D2，在確認完成更新後便將資料項 D2 的識別碼及更新時間，加入異動佇列中，但資料項 D2 已在異動佇列出現過，
代表在更新視窗中稍早的時間也更新過資料項 D2，因此，先將異動佇列中原有 的資料項 D2 更新資訊刪除，再將資料項 D2 在資時間單位 13 的更新資訊加到異 動佇列中，此時異動佇列的內容為(D3,8)→(D2,13)。依此類推，資料庫在時間單 位 19 更新資料項 D5 後，便將更新資訊加入異動佇列中，最後異動佇列的內容 便為(D3,8)→(D2,13)→(D5,19)。等到廣播週期將要到達時會先刪除監聽佇列中超 出更新視窗所涵蓋時間的異動資料項，但目前監聽佇列中並無超出更新視窗可涵 蓋的資料項，因此異動佇列並不做任何變動，只根據異動佇列製作驗證報告，到 達 後 廣 播 伺 服 端 開 始 廣 播 [ 驗 證 報 告 ][ 時 間 索 引 ][ 資 料 區 段 ] ， 內 容 為 [D2,D3,D5][index][D1,D2,D3,D4,D5]。
監聽資料到達後行動客戶端狀態：
新版本集合：D1,D4,D5 目前版本集合：
新版本集合：
監聽佇列：
查詢佇列：
圖 4-9 CASE2 資料庫伺服端狀態
在 行 動 客 戶 端 中 的 記 憶 體 如 圖 4-10 所 示 ， 新 版 本 集 合 中 有 資 料 項 D1,D4,D5，其餘目前版本集合、失效版本集合、監聽佇列、查詢佇列中並無任 何資料項。當行動客戶端在時間單位 16 時提出查詢要求，此次查詢的編號為 Q2，
查詢的資料項分別有 D2,D3，查詢處理程式首先會判斷記憶體中的各版本集合是 否有資料項的存在，當發現記憶體中有資料項的存在，便開始檢查新版本集合與 目前版本集合所組成的共同集合是否擁有此次查詢所需資料項，發現此共同集合 並不能滿足此次查詢後，查詢處理程式開始檢查目前版本集合及失效版本集合所 組成的共同集合使否有此次查詢所需的資料項，發現此共同集合也無法滿足此次 查詢，便將此次查詢的所需但未在記憶體中的資料項加入監聽佇列中，因此監聽 佇列的內容為 D2,D3，最後將此次查詢加入查詢佇列中，查詢佇列中的內容為 Q2(D2,D35)，查詢到達後的行動客戶端記憶體如圖 4-11 所示。在完成上述動作 後行動客戶端開始等待下次廣播週期的到達。
20 D5 19 D2
13 D3
8 10
0 6 time
廣播週期
更新視窗 資料庫伺服端
時間單位 13：異動佇列→(D3,8)→(D2,13)
時間單位 19：異動佇列→(D3,8)→(D2,13)→(D5,19)
D2
更新 更新 更新 更新
[D1,D2,D3,D4,D5]
[D2,D3,D5][index]
