分散處理將是未來的 mud 必需具備的能力 (转载：不知道自己从那里找到的：）)

 

分散式多使用者空間

歐尼克斯

挑戰人數上限

 

萬王之王(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，450MB IDE硬碟。於是我們開始思考: 非得如此不可嗎？一定要不斷追求更新更快的機器才能容納更多人嗎？

人數上限受限於哪些因素

 

人數上限的定義

response time : 從使用者下達指令到收到結果的這段時間稱作response time.

response time = 網路傳輸時間(來回) + 執行指令的時間

影響網路傳輸時間的因素包括routing, propergation delay time, bandwidth等等因素，多半是我們無法掌握的，(經由實際測量，220人的時候所需的bandwidth約為0.2 Mbps，一般的10 Mbps Ethernet足可勝任) 因此我們將重點集中在執行指令的時間，也就是Mud server端的改進。

       執行使用者指令所花的時間跟在線上的人數有關，當人數越多，response time越長。在使用者能接受的response time內所能容納的人數定做人數上限。

 

LP Mud的 運作情形

 

LP Mud整個系統包括Mud OS, Mud library兩層。Mud library以一種物件導向的語言LPC寫成，用來建構整個虛擬的世界。使用者所看到的世界，所使用的指令等等都屬於Mud library這一層。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以及 virtual 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，減少了單機的負擔。將來如果人數又達飽和了，舊的機器可以繼續使用，只需要再加入新的機器，一些較低階的機器也可以用來分擔部份負擔。需要考慮的是分散後，機器與機器間的communication overhead會不會大於所獲得的好處。

分散式多使用者空間

在數台不同的機器上跑同樣的Mud，人物資料檔案、區域檔案等等複製一份放在各機器，這是最簡單的方法，但是這樣各機器中的人物資料就不一致了。這樣子最多只能稱作是兩個一模一樣的Mud。

 

    另一個方法是用NFS。人物資料檔存在同一個硬碟，各機器透過NFS來讀取人物資料檔。這樣不管使用者連線上哪台機器，他的資料是一致的。這種方法要解決的問題是：同一個使用者可以以「同一個身分」，「同時」連線上這幾台不同的機器，造成存在記憶體中的人物資料不一致的情形。其次，這個方法只有分散使用者，並沒有把虛擬世界的區域一併分散，每台機器都必須有一份完整的虛擬世界，而且在不同機器的使用者即使在走到同一個房間裡也看不到對方。

 

設計前提

雖然這是一個分散式的虛擬世界，我們希望使用者感覺不出來，也就是強調他的transparency。另外，為了留住所有的使用者，我們希望所有的使用者能夠以原來習慣的方法(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負責的區域。若agent回覆為server B，A通知client程式與B 連接。client完成與B的連接後，切斷與A的連線。

 

b.    使用原有的client

 telnet、tinti、zmud等並沒有主動轉移connection的功能。當然我們可以發出一個訊息告訴使用者 : 你現在該連往哪個機器，但是這樣就不符合我們預期的目標了。而且對新使用者而言，他可能並不知道該怎麼做。因此這時候我們需要一個界面，也就是架構圖裡的agent，幫使用者處理這些轉移connection的事物。

由agent 當使用者欲從A地走到B地(或者說從機器A移到機器B) Mud server發出通知告訴agent，由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，國家發展狀態的資料存在kingdom daemon中。如果kingdom daemon只放在某台server上執行，將會有跨server的 query 動作，這是我們不希望發生的。跨server的 “query” 動作不但牽涉到分散式的物件管理(如何找到某特定物件)，所造成的communication overhead也會相當驚人。一旦每個server上都有一個kingdom daemon，勢必要付出代價來維護他的consistancy。

4.    agent負擔過重

在沒有專屬client的輔助的時候，可以發現所有的connection都集中到agent，人數的瓶頸也就轉移到agent。

 

結語

        在現在的電腦使用者中，知道 mud 而且玩 mud 的人應該還是少數，雖然 mud 比起 pcgame 更有優勢，但是目前還有待推廣，將來使用 mud 的人相信會比現在更多，使用者增加後所帶來的機器負荷和網路負荷都是 mud 設計者所必須面對的挑戰。分散式的 mud 正可以解決這兩個挑戰，而將負荷降低到可以接受的範圍。未來在 mud 往圖形化的方向進步的路程中，各種的負荷只會越來越重，相信適當的分散處理將是未來的 mud 必需具備的能力。