指导教授庄裕泽教授.doc

DIS ProjectPUSHING ICE CUBE指導教授莊裕澤教授蔡益坤教授第十二組資管所碩一 R92725009 吳書福資管所碩一 R92725040 黃子龍動 機 與 目 標動機 增加專案開發時的樂趣在選擇專案的題目時，我們兩位組員經過不斷的討論，最後決定開發一款小遊戲，藉由開發好玩的遊戲，增添專案開發的樂趣，讓整個專案的開發過程不再是那麼的枯燥、乏味。 熟悉的遊戲流程我們選擇的遊戲，在任天堂遊戲中，是屬於一款人人都聽過，玩過的遊戲，遊戲的規則不複雜，一般人只要經過一兩次的訓練，就能順利的啟動遊戲，在網路上尋找喜歡玩的玩家一起來對戰。我們小組組員覺得，這樣的一款遊戲，適合三五好友平常打發時間，實用性、娛樂性都會很高。 簡單的遊戲操作玩家啟動遊戲後，只要單純的使用上、下、左、右，四個方向鍵，移動畫面中的角色，沒有複雜的操作指令，對於玩家而言，可以很快上手，對我們開發者而言，也可以用較少的時間開發遊戲，把部分的精力用於撰寫、處理網路問題，容錯、擴充性等等較進階的問題。目標 體會分散式系統程式設計之重點因為我們選擇開發的是一款小遊戲，改寫原有的單機版的遊戲，變成可以在網路上對戰的網路遊戲，藉由實際的開發出一個網路遊戲，可以讓我們小組組員在處理網路問題，各玩家之間的問題，體會到分散式系統程式設計中，需要考慮的種種問題。 學習設計遊戲類型程式的使用者介面這是我們兩位組員第一次撰寫遊戲的程式，我們也希望能從中學到遊戲的程式設計的相關技巧和能力。 增加團隊合作及專案管理之經驗我們也希望從這次的專案開發的過程，學到團隊之間如何協調、合作等等的議題，培養以後參與大型專案開發的能力和經驗，學到專案管理的學問和技巧。遊 戲 內 容遊戲方式 遊戲採取回合制 每一回合結束才能再開始下一場的比場遊戲人數 人數最少為兩人，不設上限 決定好參加的玩家人數之後即可以開始一場比賽遊戲操作 玩家利用上、下、左、右鍵來移動所操控的角色 玩家可以透過推動一塊冰塊來壓死路徑上的一位敵人 被冰塊壓到的玩家會被判定出局，喪失繼續比賽的資格遊戲終止 畫面上最後剩下的那一位玩家即為贏家 或者是全部的使用者退出比賽，比賽即宣告結束遊 戲 畫 面 開啟本程式看看是否有人開局自己開一局等別人加入加入別人開的局Server決定遊戲開始遊戲結束玩家是否已經斷線或者所操控之角色在遊戲中死亡遊戲進行Server初始遊戲地圖並傳給所有玩家YesNo遊 戲 流 程 圖【說明】1. 程式執行之後，先檢查是否已經有人已開好遊戲等待玩家加入2. 玩家可以選擇加入他人開啟的遊戲(若有存在的話)，或者自己新開一局3. 開局的人可以決定何時開始遊戲4. 遊戲過程中若有任何玩家不正常離線，並不會影響遊戲的進行，剩下可以正常運作的玩家仍可以繼續玩5. 當某一方消滅完所有的敵人之後，這一局便算是結束了6. 或者是當地圖中沒有冰塊了，遊戲也算是結束7. 玩家可以選擇繼續玩或者離開遊戲ClientClientClientServerjoin requestjoin requestjoin request遊 戲 架 構 在程式啟動的一開始，所有的電腦都可以選擇加入別人開的局或自己新開一局等待別人加入，當某位玩家按下Create鍵時，它就會成為Server，接受其他玩家的連線要求。ClientClientClientServerLAN Server 具有決定遊戲何時開始的權利(Server也有參與本局遊戲)。 當Server決定遊戲開始之後，就會隨機產生遊戲地圖，然後將此地圖以及所有玩家的資訊傳給所有參加者。ClientClientClientServerClient 在遊戲的進行過程中，因為每一位玩家都有其他玩家的資訊，所以關於遊戲操作的訊息就可以在玩家之間互相傳遞，而不必再透過Server來broadcast。ClientServer 在遊戲的進行中，Client要定期送訊息給Server，讓Server能知道Client仍然是正常運作中的。 若有某一台參加遊戲的Client未在固定的時間內傳送訊息給Server，Server會把這一台Client從參加者中移除，並告訴遊戲其他的參加者，目前剩下哪些玩家，讓它們接下來只對那些還活著的玩家送訊息。 若Client在一段時間內沒收到Server的訊息，Client會先Lock住，然後進行Leader Election的動作，選出另一台Server來負責上述的工作。 新選出來的Server，會告知其它還存活的Client它是新的Server(Leader)之後，遊戲繼續進行。容 錯 的 處 理Server Failure Server 和 Client 定期交換訊息。 若 Client 在一定期限內未收到 Server 的訊息，遊戲會先 lock 住。 然後所有存活的 Client 會依據client_list檢查在自己之前的Client是否有人還活著，若它發現在自己之前人都沒有回應，則它就跳出來成為新的Server (Leader)，並告知所有人這項改變。Client Failure Client 和 Server 定期交換訊息。 若 Server 在一定期限內未收到 Client 的回報。 Server 會通知其它的 Client 目前剩下哪些Client 還存活著。 存活著的 Client 則根據 Server 的訊息，排除已經 crash 的 Client，只和存活著的 Client 溝通並繼續遊戲。程 式 的 實 作在處理Client及Server的容錯方面，主要由五支程式負責：u TimelyReportClient.java：這一支程式是由所有的玩家定期傳送給擔任Server的玩家，訊息發送的方式是採取RMI的機制去呼叫遠端玩家的電腦，玩家定期把自己的IP傳送到Server上，Server的電腦會有另一支程式就會根據每個玩家有沒有定期來回報，判斷玩家的狀態。u TimelyReportServer.java：這一支程式是由擔任Server的電腦發給所有參加的玩家，訊息發送的方式也是採取RMI的機制去呼叫遠端玩家的電腦，Server傳給所有的玩家的訊息內容包括了Server的IP以及存活的Client List（ServerIP, ClientList），遠端的電腦收到Server的訊息之後，會依照收到的訊息內容，設定自己要回報的Server IP，以及目前存活的Client List。u MessageForClient.java：這一支程式負責把由Server傳來的ServerIP以及ClientList，設定到自己的ServerIP及ClientList上。u MessageForServer.java：這一支程式負責檢查每位玩家傳來的IP，它會根據IP來決定某位玩家是否有定期回報，以判斷玩家的狀態是否正常，倘若某一位玩家在一定的時間內（我們的設定是兩秒鐘），都沒來回報，Server就會將這一位玩家的IP從ClientList中移除，並且在下一次傳送給所有的玩家的ClientList中，就不會有此玩家的IP。u TimelyCheckServer.java：這一支程式會在每一位玩家的電腦上啟動，負責定期檢查擔任Server的這一位玩家的狀態是否正常，若一直沒收到Server應該傳送的ServerIP以及ClientList，所有的Client會移向另一台新擔任Server的玩家身上，然後再定期跟該新的Server回報。根據我們設計，新的Server的選擇條件是依照ClientList中的順序來定，所以遊戲一開始，擔任Server的玩家一定是ClientList中的第一台電腦。之後，隨著其它的玩家可能不正常的離線，ClientList中的數目可能會有所減少，但是Server的IP一定是ClientList中的第一位。每一位玩家就根據自己在ClientList中的順序，來決定自己是否在偵測到Server crash時應該跳出來接手，成為新的Server的位置。偵測的機制是：當確定Server不正常離線了（判斷的依據是定期回報給Server的訊息會產生Exception），每位玩家就會知道該啟動選擇新的Server的機制。每一位玩家會依自己在ClientList中的順序，傳送一個訊息給在自己之前的所有Client，以判斷在自己之前的玩家的狀態，這樣就能知道是否該要跳出來成為新的Server，舉一個例子來講，若在一個ClientList中有五位玩家，分別是Client1, Client2, Client3, Client4, Client5。在第一位的Client1是Server，這時，Server不正常離線了，第三位玩家會去問前兩位的玩家是否是正常運作的，這時，Client2會回答Client3，因此Client3知道他不用跳來擔任新的Server，而Client2也用同樣的機制去問在它之前的Client1，這時Client1不會回應Client2，而Client2又知道自己是ClientList中的第一位（扣除Client1不算），所以它應該跳出來成為新的Server，接著再和在ClientList中，在Client2之後的所有Clients傳送一個ServerIP = Client2, ClientList = (Client2, Client3, Client4, Client5)的訊息。其它的Client3, Client4, Client5，再根據這個訊息，設定自己新的ServerIP以及ClientList，並且改向新的Server回報。下面列出當Server不正常離線之後，程式的反應。一開始的ClientList為：u 104.112.107.6u 140.112.107.12u 140.112.107.17其 它 考 量Scalability 在進行一場遊戲前，所有的使用者都可以選擇建立新的遊戲或者加入已經開啟中等待參賽者加入的遊戲。 當遊戲進行時，未參加的使用者仍然可以成立一場新遊戲，兩場遊戲不會互相干擾。Load Balance 遊戲中訊息的傳遞方式是採用直接 multicast 的做法，而不會透過 Server 來轉送訊息。 因此在遊戲進行中 Server 除了定期確認並告知還有哪些 Client 還活著之外，訊息的處理以及流量與一般的 Client 並無不同。Tool 開發工具 開發平台 Java Virtual Machine Borland Jbuilder 9.0 開發技術 Java Programming Language Java RMI Multi-threadJob Distribution 工作分配 吳書福 Server to Client Communication Server Failure Handling Game GUI 黃子龍 Node to Node Communication Client Failure Handling Game ControlTimeline 時間表心 得 與 感 想這一次的DIS的專案，我負責寫Client及Server的容錯部分，在還沒寫專案之前，我和另一位組員子龍就一直在討論，研究所有應該考量會發生的情況，以及尋找一個課本上提過的理論架構，可以適合用在我們的專案上。經過一連串的討論，我們自己提出了自己的一套架構，用順序來決定新的Server，因為我們發現每一個Client都會透過定期的訊息溝通，知道其它Client的狀態，所以用順序來決定如何產生新的Server是非常的合理以及容易完成的事情。雖然在經過實際的Demo過程中，我們的Server轉移機制並沒有很順利的展現給老師看，這是我覺得很遺憾的事，但是事後我們再去請教實驗室的學長，學長提到一個可能是解決的方向，那就是針對RMI傳送的訊息，設定準確的Timeout機制，這樣也許可以增強我們的程式，讓Server的轉移可以每次都順利成功。這一次學DIS，在程式的設計上，難度比在寫一般的程式都還複雜，要考量的因素很多，最明顯的就是在單機上試可以，但是真正拿到多台電腦上試的時候就會有問題，所以在程式的撰寫上就要很仔細，同時也要花很多的腦筋。另外一點，因為專案一定是多人合作，所以在程式的整合上，也有一定的難度存在。不過就是因為困難度提高，所以這一個專案這樣經歷下來，我覺得被磨練得很多，也學得不少關於分散式系統程式撰寫方面的經驗，過程很痛苦，但事後回想覺得很值得。書福雖然之前沒有學過Java，也沒有用過RMI，更沒有做過分散式系統的開發，但是在這次的Project裡全部都接觸到了，而分散式系統的設計與實做更是讓我體會良多，無論是遊戲的同步(Currency)、容錯(Fault Tolerance)或Leader El