分散式多使用者空間

看板mud (網路地下城/文字遊戲)作者happyhero (2008 Fighter!)時間17年前 (2009/01/29 23:44)推噓3(3推 0噓 1→)

留言4則, 4人參與討論串1/1

上網亂逛看到的應該是很久以前的文章吧XD 跟KK系統有關的文章 http://blog.csdn.net/mu_gong/archive/2005/02/19/293246.aspx 內文(by Onyx) 分散式多使用者空間挑戰人數上限萬王之王(The King Of Kings) 在去年12月底正式對外開放測試，到現在不到一年的時間內，屢次突破LP Mud的人數上限，到目前為止可以容納320個使用者，可以說是台灣最大的LP Mud。在傳統的Mud裡，使用者能從事的活動不外乎砍殺怪物，解謎題，完成任務以及與其他的玩家互動。在萬王之王中，除了這些事之外，萬王之王提供了一套方法讓使用者可以發揮想像力，創造自己的國家，建構自己想像中的夢幻世界即使你不會寫程式。第一次嘗試這種類型的Mud，並沒有想到會如此受歡迎。在不到一年的時間，甚至許多功能都尚未完成的時候，不停的有新人加入這個遊戲空間。原來是不希望設上限人數的，我們希望 :「想玩就可以來玩。」。但是人數一再增加，整個系統慢了下來，於是我們不停的嘗試各種方法來提高人數上限，包括改寫Mud library、更換硬體、更新MudOS版本、修改linux kernel以突破file descriptor上限256的限制等等。幾次電腦升級之後，目前萬王之王的硬體設備是Pentium 200(雖然是用O的)，96 MB RAM，4 50MB IDE硬碟。於是我們開始思考: 非得如此不可嗎？一定要不斷追求更新更快的機器才能容納更多人嗎？人數上限受限於哪些因素人數上限的定義 response time : 從使用者下達指令到收到結果的這段時間稱作response time. response time = 網路傳輸時間(來回) + 執行指令的時間影響網路傳輸時間的因素包括routing, propergation delay time, bandwidth等等因素，多半是我們無法掌握的，(經由實際測量，220人的時候所需的bandwidth約為0.2 Mbps，一般的10 Mbps Ethernet足可勝任) 因此我們將重點集中在執行指令的時間，也就是Mud serv er端的改進。執行使用者指令所花的時間跟在線上的人數有關，當人數越多，response time越長。在使用者能接受的response time內所能容納的人數定做人數上限。 LP Mud的運作情形 LP Mud整個系統包括Mud OS, Mud library兩層。Mud library以一種物件導向的語言LPC寫成，用來建構整個虛擬的世界。使用者所看到的世界，所使用的指令等等都屬於Mud librar y這一層。Mud OS則可以看作是Mud的driver，是真正讓Mud動起來的。在以下的說明中，Mud OS跟driver代表相同的意思，而Mud server則是包含了OS與library兩層。執行的時候，driver會將LPC寫成的 library轉為中間碼，執行的時候以中間碼執行，因此是一種interpreter的方式在運作。這裡要注意的是，並不是一開始就將整個library編譯為中間碼，只有一小部份必須在啟動的時候完成轉換，大部分的程式都是在用到的時候才進行編譯與執行的動作。轉成中間碼後，除非被清除掉，否則不需要重新編譯。 Mud OS可以看成是一個virtual machine，執行專屬的中間碼。在virtual machine是single thread的，也就是說一次一定會把一個指令或物件裡的一個method執行完畢，才輪到下一個。 Mud 需要處理以下三件事情 : 1. 每隔固定的間隔時間必須執行的 : 比如說每個生物的心跳。 2. call_out queue : 有些指令在執行的時候為了要造成延遲的效果，會以call_out函數指定過了幾秒後要跳到哪個函數執行，有點像sleep()。Mud OS會將call_out發出的請求依時間掛在一個queue, 每隔一陣子就去檢查是否到了執行的時間。 3. 使用者下的指令。整個過程大概可以寫成 : While (1) { process_heart_beat(); // 心跳，每兩秒一次 process_call_out(); // call out queue process_user_command(); // user command } Fig. 1 人數的限制回到前面的式子 response time = 網路傳輸時間(來回) + 執行指令的時間而執行指令的時間 = f ( 硬體的速度，virtual machine的效能，指令本身的複雜度，物件數目，使用者數目) 其中物件的數目受直接受使用者數目的影響，而小心設計可以降低指令的複雜度。從Fig 1的流程來看： 1. 使用者越多，花在process_heart_beat的時間越長，因此response time越長。 2. 使用者越多，要等前面所有的使用者指令都執行完的時間越久，response time越長。 3. 使用者越多，整個虛擬世界裡會被載入到記憶體的物件越多，因此尋找物件的時間越長。在Mud裡幾乎每個動作都必須尋找物件，直接影響到指令執行的時間長短。人數上限受限於所能忍受的response time, 而response time除了與硬體的速度、OS以及 v irtual machine的效能、library的結構有關以外，另一個主要的影響就是物件的數目了。如何提高人數上限 1. 提升硬體設備 : a. 使用更快速的CPU b. 使用高速記憶體與硬碟這是最簡單的方法了，然而硬體升級的速度比不上進入網路世界的人口成長，而且如果每次人數飽和就更新機器，將需要一筆可觀的費用。 2. 加強virtual machine的效能，小心設計library ‥ 現在TAnet上的Mud多半是拿國外的virtual machine(Mud OS, driver)來使用，使用新版本的virtual machine可以大幅提高執行速度。 ‥ 小心設計library，盡量不要設計的太複雜，將最花時間的一些動作與指令最佳化。 ‥ 最佳化library能夠收到的效果有限，往往最多只能增加10~20個使用者。 3. 降低單機的負擔這個想法很簡單，很直接 : 既然一台機器能容納的人有限，那就用兩台機器來跑吧。分兩台機器來跑Mud不但分散了使用者，分散了區域，分散了物件，分散了網路I/O，減少了單機的負擔。將來如果人數又達飽和了，舊的機器可以繼續使用，只需要再加入新的機器，一些較低階的機器也可以用來分擔部份負擔。需要考慮的是分散後，機器與機器間的communicat ion overhead會不會大於所獲得的好處。分散式多使用者空間在數台不同的機器上跑同樣的Mud，人物資料檔案、區域檔案等等複製一份放在各機器，這是最簡單的方法，但是這樣各機器中的人物資料就不一致了。這樣子最多只能稱作是兩個一模一樣的Mud。另一個方法是用NFS。人物資料檔存在同一個硬碟，各機器透過NFS來讀取人物資料檔。這樣不管使用者連線上哪台機器，他的資料是一致的。這種方法要解決的問題是：同一個使用者可以以「同一個身分」，「同時」連線上這幾台不同的機器，造成存在記憶體中的人物資料不一致的情形。其次，這個方法只有分散使用者，並沒有把虛擬世界的區域一併分散，每台機器都必須有一份完整的虛擬世界，而且在不同機器的使用者即使在走到同一個房間裡也看不到對方。設計前提雖然這是一個分散式的虛擬世界，我們希望使用者感覺不出來，也就是強調他的transparen cy。另外，為了留住所有的使用者，我們希望所有的使用者能夠以原來習慣的方法(telnet, tintin, zmud等等) 來加入這個世界而不需要改變。這兩點成了設計上最大的挑戰。架構 Mud server Mud server Agent telnet tintin/zmud 專屬 client 說明 1. 每個機器上都執行一份完整的Mud OS與Mud library ( 包括daemon、基本物件以及指令的部份 )，而將虛擬世界切割開來，每個機器上只負責一部份的區域。 2. 透過一個configuration 檔案來指定Mud server所負責的區域，當Mud server啟動的時候，必須跟agent程式報告所負責的區域。agent擁有區域機器對應關係的資料。 3. 以KK為例子，區域的切割點可以是港口、國界或者是recall、summon、teleport等指令。 4. 當使用者由區域A走到區域B的時候，可以由以下兩種方法傳送過去。 a. 使用專屬client 如果使用者使用專屬於這種Mud的client程式，在他走到切割點，想要走到另一個區域的時候，Mud server A首先發出一個請求到agent，詢問該區域是哪個server負責的區域。若age nt回覆為server B，A通知client程式與B 連接。client完成與B的連接後，切斷與A的連線。 b. 使用原有的client telnet、tinti、zmud等並沒有主動轉移connection的功能。當然我們可以發出一個訊息告訴使用者 : 你現在該連往哪個機器，但是這樣就不符合我們預期的目標了。而且對新使用者而言，他可能並不知道該怎麼做。因此這時候我們需要一個界面，也就是架構圖裡的agen t，幫使用者處理這些轉移connection的事物。由agent 當使用者欲從A地走到B地(或者說從機器A移到機器B) Mud server發出通知告訴age nt，由agent轉移connection，而使用者與agent的connection不需要切斷或是重新連接。 5. agent的功能 ‥ agent擁有區域機器對應的資料，在必要的時候甚至可以改變區域的分配，重新分布使用者(dynamic load balancing)。 ‥ agent必須要能forward使用者所輸入的指令給Mud server，將Mud server的回應過濾後傳回給使用者。 ‥ 所有連線的使用者都必須透過agent讀取部份的資料(password，上次離線時的地點) ，可以避免一個人多次登錄(login)的問題。可能遭遇的問題 1. channel廣播訊息例如chat、rumor等channel。所有的channel訊息都以同樣的方式處理。1. Server廣播給所有與自己連接的 client，2. 送到其他的server，再由各server自行將訊息廣播出去。 2. 跨server的交談例如tell、reply、finger，都是送訊息給特定使用者。 server送出交談內容到各server，由各server自行尋找該特定使用者。 3. daemon資料的consistancy 一般的Mud不會有這個問題，然而KK裡由於多了kingdom daemon，國家發展狀態的資料存在k ingdom daemon中。如果kingdom daemon只放在某台server上執行，將會有跨server的 quer y 動作，這是我們不希望發生的。跨server的 “query” 動作不但牽涉到分散式的物件管理(如何找到某特定物件)，所造成的communication overhead也會相當驚人。一旦每個serv er上都有一個kingdom daemon，勢必要付出代價來維護他的consistancy。 4. agent負擔過重在沒有專屬client的輔助的時候，可以發現所有的connection都集中到agent，人數的瓶頸也就轉移到agent。結語在現在的電腦使用者中，知道 mud 而且玩 mud 的人應該還是少數，雖然 mud 比起 pcgame 更有優勢，但是目前還有待推廣，將來使用 mud 的人相信會比現在更多，使用者增加後所帶來的機器負荷和網路負荷都是 mud 設計者所必須面對的挑戰。分散式的 mud 正可以解決這兩個挑戰，而將負荷降低到可以接受的範圍。未來在 mud 往圖形化的方向進步的路程中，各種的負荷只會越來越重，相信適當的分散處理將是未來的 mud 必需具備的能力。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.113.225.127 ※ 編輯: happyhero 來自: 59.113.225.127 (01/29 23:45) ※ 編輯: happyhero 來自: 59.113.225.127 (01/29 23:45)