國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
31
第四章 系統開發與實作
為達到安全且穩定的檔案同步方式，故在通訊的協定上，採用 AMQP 所實 作之 Rabbit MQ 套件。利用 Message Queue 來達到即使同步的接受端發生狀況時，
能自動的達成未執行之工作項目。
4-1 私有雲及本地端系統傳訊之方法
在檔案同步的傳輸方式上，原先以 socket 檔案傳輸為主，不過在經過實作之 後，還是以 AMQP 協定的實作為主。此章節將討論以以上兩種在處理檔案同步 時傳輸檔案的優點與缺點。
4-1.1 以 Socket 實作檔案同步
流程如下所述，實作一個自動產稱檔案及目錄之程式，時時變更由監控模組 所監控的資料夾，執行檔案及資料夾的新增、刪除及修改，每個指令中間間斷 5 秒。當每執行一個指令，監控模組即會發送通知給系統的檔案同步模組，檔案同 步模組即會改變自己的資料夾與檔案內容。而當需要監控模組上傳時，集會發送 socket 資訊給監控模組，最後再由監控模組將該檔案上傳，詳細流程如下圖。
圖 17：以 socket 實作流程圖 (1). 變更程式修改檔案或資料夾內容。
(2). 監控模組發送修改通知給同步模組。
(3). 若需由監控模組上傳檔案，同步模組發送 socket 資訊給予監控模組。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
32
(4). 監控模組接收到 socket 資訊，則開始上傳檔案。
優點：傳輸快且穩定。缺點：不可同時處理訊息的傳輸及檔案的傳輸。若斷 線要回復續傳不易，同時處理超過一個檔案的同步時，速度較慢。
4-1.2 以 AMQP 實作檔案同步
在系統傳輸訊息上用 Message Queue 的方式傳輸，其作法為發送端將訊息先 傳入 Message Queue 內，而接受端則在能處理的時間執行訊息的接收。當需要將 檔案上傳至系統時，則監控模組將檔案內容轉成訊息後傳送。實作利用 Message Queue 的作法也能解決斷線後同步的續傳及超過一個檔案同時進行同步的問題，
詳細流程如下圖。
圖 18：以 AMQP 協定實作流程圖 (1). 變更程式修改檔案或資料夾內容。
(2). 監控模組發送修改訊息給同步模組，若為檔案內容的修改，則將檔案內容 轉成訊息一併傳出。
(3). 同步模組從 Message Queue 接受修改訊息，若若為檔案內容的修改，則將 檔案內容寫入。
優點：在 Message Queue 內可同時並存檔案內容及通知的訊息；可解決斷線 後的續傳、伺服器當機等等的問題；可讓接收端處理不同的檔案同步。缺點：需 要將檔案的內容轉成訊息傳輸。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
33
4-2 系統身分認證之實作
當使用者登入系統時，系統會給予使用者某一特定身分，而在系統內部該使 用者就運用該身分使用系統。例如使用者 A 利用任一帳號登入至系統內部，系 統及給予 User A 之身分識別；在系統內部即利用 User A 識別，而不再使用該端 點的帳號認證。
身分認證之實作主要為了讓使用者能更方便的將檔案資源同步至公有雲上，
也因此將公有雲、私有雲及本地端帳號連結再一起，讓使用者能更方便的登入至 系統。
4-2.1 使用者對系統註冊並認領帳號
使用者首次使用系統時，便會向系統執行帳號認領之動作。使用者提供基本 的個人資訊並填入各端的帳號密碼，系統則利用使用者提供的資訊在私有雲及本 地端作基本的身分認證，接著透過 OpenID 與 O’Auth 讓 Google 對系統該帳號的 授權。流程圖如下圖：
圖 19：首次使用系統及修改帳號對應流程 (1). 使用者新增或刪除對應之帳號與密碼。
(2). 網站接受後給予系統認證模組。
(3). 系統認證模組與私有雲及本地端認證成功後傳回成功訊息。
4-2.2 使用者改變檔案內容之認證
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
34
使用者透過私有雲或本地端帳號修改檔案內容完成時，監控檔案模組會先將 使用者帳號與密碼傳達給認證模組，確認是合法使用者後，系統認證模組即會告 知檔案同步模組開始進行同步，流程圖如下：
圖 20：使用者修改檔案身分認證流程 (1). 使用者修改檔案或資料夾內容。
(2). 監控模組給予系統使用者帳號、密碼及欲修改檔案的路徑。
(3). 系統認證模組認證為合法使用者並告知檔案同步模組開始進行同步。
4-3 系統與私有雲(Hadoop)及本地端檔案同步之實作
系統接收到監控模組的通知時即進行檔案內容的同步，同步的過程是即時的，
也就是當使用者作一連串的改變時，系統驗證後是合法的使用者，則系統就將改 變的狀況一項一項同步至其他端。本章節將詳述私有雲檔案與本地端檔案同步方 式與詳細流程。
使用者在改變檔案/資料夾時，檔案監控模組則回發送訊息給系統的認證模 組，此訊息包含了＂修改時間＂、＂修改方式＂、＂檔案路徑＂、＂使用者帳號
＂以及＂檔案內容＂，當認證模組接收到後即進行身分認證，像使用者索取帳號 之密碼，使用者提供密碼認證為合法使用者後，系統的同步模組才執行接收的修 改訊息改變檔案內容及結構，直到系統端也修改完成後，同步模組再同步至另一 端，下圖以本地端同步至私有雲端為例：
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
35
圖 21：本地端同步至私有雲流程圖 (1). 使用者修改檔案內容。
(2). 監控模組將修改訊息及使用者帳號發送給系統。
(3). 認證為合法使用者，則檔案同步模組開始執行同步動作。
(4). 系統同步完成後，將同步訊息發送至私有雲端。
在私有雲及本地端之檔案同步為考慮使用者之便利性，故不另外執行身分認 證之工作。認證模組接收由監控模組所發送之訊息後，指經由帳號比對來確認是 否為合法系統使用者。
4-4 系統與公有雲(Google Docs)檔案同步之實作
由於在公有雲之檔案內容改變無法不透過公有雲提供商的通知而得知，故本 系統無法處理當公有雲檔案內容改變之後同步到私有雲及本地端的狀況。因此本 章節將詳述由本地端或私有雲發生系統改變時，同步到公有雲之情況。
系統接受到檔案變更之通知後，將會與 Google Docs 要求存取之權限。利用 使用者所提供之 Google 帳號進行 Google App 之認證與授權。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
36
當系統必須同步至公有雲時，系統會利用使用者所提供之 Google 帳號，向 Google Account Server 進行第一次的帳號認證，當認證成功後。Google App Server 會在給予一 token，系統再利用此 token 及 Google 帳號向特定的 Google App 要求 授權。當認證成功後，會授予系統一副存取之 token，系統即可透過此一 token 來達到檔案同步至公有雲之動作。在同步期間，Google App Server 會不定時要求 授權認證，即利用已授權之 token 交換新授權之認證。以此來達到授權之安全。
詳細流程圖如下圖：
圖 22：公有雲檔案同步之流程 (1). 使用者修改檔案內容。
(2). 監控模組將修改訊息及使用者帳號發送給系統。
(3). 系統向 Google Account Server 進行身分認證。
(4). 認證成功後送回 Google Account token。
(5). 再利用 token 取得 Google App 之授權。
(6). 得到 Google App 之授權 token。
(7). 取得授權後通知同步模組進行同步。
(8). 將檔案同步至公有雲檔案。
在同步檔案至公有雲時，使用的是 Google Docs API，其中包括資料夾及檔 案管理的 API 可供系統使用，在取得權限之後即可使用。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
37
圖 23：Google Docs 所提供之 API
4-5 權限同步之實作
檔案同步時常伴隨著權限同步。為了考量檔案在公有雲、私有雲及本地端之 授權安全性，故本系統在權限同步之實作上，採用部分權限同步之方式。使用者 在新增檔案後成為擁有者，而其他使用者均只有＂讀取＂之權限。以此種方式保 護檔案在公有雲、私有雲及本地端之安全性以避免由不同使用者修改檔案內容的 資訊混亂狀況，但又讓擁有者擁有檔案最高權利的便利性。