Mangos源碼分析（13）：再談登錄服的實現

關於登錄服、大區服及遊戲世界服的結構之前已做過探討，這裏再把各自的職責和關係列一下。

        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一樣，就是保存在了數據庫中。不管是怎樣一種方式，瞭解了其過程，代碼實現都是比較簡單的，我們就不再贅述了。