Posted on 2011-01-19 19:18
點點滴滴 閱讀(1099)
評論(0) 編輯 收藏 引用 所屬分類:
10 服務器
關于登錄服、大區服及游戲世界服的結構之前已做過探討，這里再把各自的職責和關系列一下。
GateWay/WorldServer GateWay/WodlServer LoginServer LoginServer DNSServer WorldServerMgr
| | | | |
---------------------------------------------------------------------------------------------
| | |
internet
|
clients
其中DNSServer負責帶負載均衡的域名解析服務，返回LoginServer的IP地址給客戶端。WorldServerMgr維護當前大區內的世界服列表，LoginServer會從這里取世界列表發給客戶端。LoginServer處理玩家的登錄及世界服選擇請求。GateWay/WorldServer為各個獨立的世界服或者通過網關連接到后面的世界服。
在mangos的代碼中，我們注意到登錄服是從數據庫中取的世界列表，而在wow官方服務器中，我們卻會注意到，這個世界服列表并不是一開始就固定，而是動態生成的。當每周一次的維護完成之后，我們可以很明顯的看到這個列表生成的過程。剛開始時，世界列表是空的，慢慢的，世界服會一個個加入進來，而這里如果有世界服當機，他會顯示為離線，不會從列表中刪除。但是當下一次服務器再維護后，所有的世界服都不存在了，全部重新開始添加。
從上面的過程描述中，我們很容易想到利用一個臨時的列表來保存世界服信息，這也是我們增加WorldServerMgr服務器的目的所在。GateWay/WorldServer在啟動時會自動向WorldServerMgr注冊自己，這樣就把自己所代表的游戲世界添加到世界列表中了。類似的，如果DNSServer也可以讓LoginServer自己去注冊，這樣在臨時LoginServer時就不需要去改動DNSServer的配置文件了。
WorldServerMgr內部的實現很簡單，監聽一個固定的端口，接受來自WorldServer的主動連接，并檢測其狀態。這里可以用一個心跳包來實現其狀態的檢測，如果WorldServer的連接斷開或者在規定時間內未收到心跳包，則將其狀態更新為離線。另外WorldServerMgr還處理來自LoginServer的列表請求。由于世界列表并不常變化，所以LoginServer沒有必要每次發送世界列表時都到WorldServerMgr上去取，LoginServer完全可以自己維護一個列表，當WorldServerMgr上的列表發生變化時，WorldServerMgr會主動通知所有的LoginServer也更新一下自己的列表。這個或許就可以用前面描述過的事件方式，或者就是觀察者模式了。
WorldServerMgr實現所要考慮的內容就這些，我們再來看看LoginServer，這才是我們今天要重點討論的對象。
前面探討一些服務器公共組件，那我們這里也應該試用一下，不能只是停留在理論上。先從狀態機開始，前面也說過了，登錄服上的連接會有兩種狀態，一是帳號密碼驗證狀態，一是服務器列表選擇狀態，其實還有另外一個狀態我們未曾討論過，因為它與我們的登錄過程并無多大關系，這就是升級包發送狀態。三個狀態的轉換流程大致為：
LogonState -- 驗證成功 -- 版本檢查 -- 版本低于最新值 -- 轉到UpdateState
|
-- 版本等于最新值 -- 轉到WorldState
這個版本檢查的和決定下一個狀態的過程是在LogonState中進行的，下一個狀態的選擇是由當前狀態來決定。密碼驗證的過程使用了SRP6協議，具體過程就不多做描述，每個游戲使用的方式也都不大一樣。而版本檢查的過程就更無值得探討的東西，一個if-else即可。
升級狀態其實就是文件傳輸過程，文件發送完畢后通知客戶端開始執行升級文件并關閉連接。世界選擇狀態則提供了一個列表給客戶端，其中包括了所有游戲世界網關服務器的IP、PORT和當前負載情況。如果客戶端一直連接著，則該狀態會以每5秒一次的頻率不停刷新列表給客戶端，當然是否值得這樣做還是有待商榷。
整個過程似乎都沒有值得探討的內容，但是，還沒有完。當客戶端選擇了一個世界之后該怎么辦？wow的做法是，當客戶端選擇一個游戲世界時，客戶端會主動去連接該世界服的IP和PORT，然后進入這個游戲世界。與此同時，與登錄服的連接還沒有斷開，直到客戶端確實連接上了選定的世界服并且走完了排隊過程為止。這是一個很必要的設計，保證了我們在因意外情況連接不上世界服或者發現世界服正在排隊而想換另外一個試試時不會需要重新進行密碼驗證。
但是我們所要關注的還不是這些，而是客戶端去連接游戲世界的網關服時服務器該如何識別我們。打個比方，有個不自覺的玩家不遵守游戲規則，沒有去驗證帳號密碼就直接跑去連接世界服了，就如同一個不自覺的乘客沒有換登機牌就直接跑到登機口一樣。這時，乘務員會客氣地告訴你要先換登機牌，那登機牌又從哪來？檢票口換的，人家會先驗明你的身份，確認后才會發給你登機牌。一樣的處理過程，我們的登錄服在驗明客戶端身份后，也會發給客戶端一個登機牌，這個登機牌還有一個學名，叫做session key。
客戶端拿著這個session key去世界服網關處就可正確登錄了嗎？似乎還是有個疑問，他怎么知道我這個key是不是造假的？沒辦法，中國的假貨太多，我們不得不到處都考慮假貨的問題。方法很簡單，去找給他登機牌的那個檢票員問一下，這張牌是不是他發的不就得了。可是，那么多的LoginServer，要一個個問下來，這效率也太低了，后面排的長隊一定會開始叫喚了。那么，LoginServer將這個key存到數據庫中，讓網關服自己去數據庫驗證？似乎也是個可行的方案。
如果覺得這樣給數據庫帶來了太大的壓力的話，也可以考慮類似WorldServerMgr的做法，用一個臨時的列表來保存，甚至可以將這個列表就保存到WorldServerMgr上，他正好是全區唯一的。這兩種方案的本質并無差別，只是看你愿意將負載放在哪里。而不管在哪里，這個查詢的壓力都是有點大的，想想，全區所有玩家呢。所以，我們也可以試著考慮一種新的方案，一種不需要去全區唯一一個入口查詢的方案。
那我們將這些session key分開存儲不就得了。一個可行的方案是，讓任意時刻只有一個地方保存一個客戶端的session key，這個地方可能是客戶端當前正連接著的服務器，也可以是它正要去連接的服務器。讓我們來詳細描述一下這個過程，客戶端在LoginServer上驗證通過時，LoginServer為其生成了本次會話的session key，但只是保存在當前的LoginServer上，不會存數據庫，也不會發送給WorldServerMgr。如果客戶端這時想要去某個游戲世界，那么他必須先通知當前連接的LoginServer要去的服務器地址，LoginServer將session key安全轉移給目標服務器，轉移的意思是要確保目標服務器收到了session key，本地保存的要刪除掉。轉移成功后LoginServer通知客戶端再去連接目標服務器，這時目標服務器在驗證session key合法性的時候就不需要去別處查詢了，只在本地保存的session key列表中查詢即可。
當然了，為了session key的安全，所有的服務器在收到一個新的session key后都會為其設一個有效期，在有效期過后還沒來認證的，則該session key會被自動刪除。同時，所有服務器上的session key在連接關閉后一定會被刪除，保證一個session key真正只為一次連接會話服務。
但是，很顯然的，wow并沒有采用這種方案，因為客戶端在選擇世界服時并沒有向服務器發送要求確認的消息。wow中的session key應該是保存在一個類似于WorldServerMgr的地方，或者如mangos一樣，就是保存在了數據庫中。不管是怎樣一種方式，了解了其過程，代碼實現都是比較簡單的，我們就不再贅述了。