網(wǎng)絡游戲中的連接服務器

bobozhang

最近在看一些網(wǎng)絡游戲的源代碼，看到他們都喜歡用一個專門的連接服務器來管理大量的連接，這個服務器把大量(一般都是10左右)客戶端的數(shù)據(jù)轉(zhuǎn)發(fā)到內(nèi)部的其它服務器中去。這些實現(xiàn)有些是用windows的完成端口，有的用freebsd的kqueue，有的用linux的epoll。但我有個疑問，這臺服務就相當于一臺路由器，負責包的轉(zhuǎn)發(fā)，但它工作在4層以上，與真正的路由器轉(zhuǎn)發(fā)包的效率相差甚遠，這會造成延遲，再則，比如一個進程(單線程)用epoll監(jiān)管10000個連接，在最壞時可能這10000個連接都有數(shù)據(jù)可讀，那么串行讀取，那么最后一個連接的延遲豈不是更嚴重？因為程序要先read() 9999次之后才來read最后一個，然后轉(zhuǎn)發(fā)。

在這些實現(xiàn)中，我感覺windows的完成端口要比其它模型要好些

我在這個領(lǐng)域一點經(jīng)驗都沒有，希望向大家學習學習

flw

你是不是沒理清楚頭緒啊，
我做過的網(wǎng)游的連接服務器只是負責初始連接，
一旦進入某個具體的地圖的時候，客戶端會和具體的地圖服務器建立連接，初始的那個連接就斷開了。

bobozhang

原帖由 flw 于 2009-9-9 10:00 發(fā)表
你是不是沒理清楚頭緒啊，
我做過的網(wǎng)游的連接服務器只是負責初始連接，
一旦進入某個具體的地圖的時候，客戶端會和具體的地圖服務器建立連接，初始的那個連接就斷開了。

哦，可能你那個實現(xiàn)不太一樣吧。

我看得這個代碼大概是這樣的哈，首先用戶連接登陸服務器獲取sessionid和 game gate的(ip:port)，然后客戶端去連接這個game gate，之后只要不退出游戲，不管怎么換地圖都不會斷開這個連接，game gate之后還有個地圖管理服務器，所有的地圖服務器都連接到這個地圖管理服務器，所有客戶端發(fā)來的跟地圖相關(guān)的包都會由game gate轉(zhuǎn)發(fā)給地圖管理服務器，然后地圖管理服務器根據(jù)角色所在的地圖再次轉(zhuǎn)發(fā)給對應的地圖服務器。

我感覺這樣大量的轉(zhuǎn)發(fā)會造成很多延遲阿，感覺你那個實現(xiàn)要好些。

ps:如果你愿意不怕泄密，是否可以向我們講解一下mmorpg業(yè)界通用的服務器端的架構(gòu)阿，謝謝！

flw

你剛才闡述的這種架構(gòu)沒法分布式啊。只能在同一個機房里搞，
那南北互通的問題就很難解決了哦。

我說的那種架構(gòu)就稍微好一些，可以把用戶分配到合理的地圖服務器上去。
而且不限制地圖服務器的物理位置。

xhl

原帖由 bobozhang 于 2009-9-9 09:55 發(fā)表
最近在看一些網(wǎng)絡游戲的源代碼，看到他們都喜歡用一個專門的連接服務器來管理大量的連接，這個服務器把大量(一般都是10左右)客戶端的數(shù)據(jù)轉(zhuǎn)發(fā)到內(nèi)部的其它服務器中去。這些實現(xiàn)有些是用windows的完成端口，有的 ...

我給你解釋一下把， 一般如果是基于tcp應用的網(wǎng)絡游戲， 這種連接服務器其實可以看作是客戶端代理， 一個clientproxy可以代理n個client, 看性能而定。

一般這種clientproxy是多個， 由網(wǎng)絡服務的中心服務來負責分配負載均衡。 每個clientproxy跟內(nèi)部地圖或者gameserver之間建立固有的連接。

對于內(nèi)部服務來說， 他們看到的只有clientproxy, clientproxy 有一個重要作用就是做數(shù)據(jù)包的安全check,  保證進入游戲服務群組內(nèi)的消息， 都是正確的。
clientproxy 還可以分擔把邏輯server的廣播壓力。

至于說時延問題， 其實大部分mmorpg類型的游戲， 對時間要求都不是很高， 除非是fps 或者竟速或者強pk類型的， 可能要特殊處理一下。 也就是同時使用tcp and udp兩種協(xié)議。主要的時延產(chǎn)生在client - clientproxy之間， 而不是內(nèi)部server之間， （可以用網(wǎng)絡通信， 也可以用進程通信， 甚至可以單進程， 多thread）。

[ 本帖最后由 xhl 于 2009-9-9 14:14 編輯 ]

anders0913

LZ看的源代碼是很早很早以前的那套傳奇的代碼吧~~

benjiam

... 老嗎？

我們現(xiàn)在也是這么做的？

客戶端直接和map 服務器連接？ 好爛的設計。同時登陸2個服務器， 安全性， 帳號余額 都將成為問題。

這樣的服務器 可以說叫g(shù)ateway, 好處很多， 安全 穩(wěn)定。 當然 gateway 本身的壓力會很大。

bobozhang

to anders0913:  不是傳奇那套代碼哈，那個代碼是dephi的，看不懂，至于c++那套，聽人說本身寫得比較爛，沒看過

to benjiam：壓力大是否可以增加gate的個數(shù)來解決？我主要關(guān)心延遲的問題哈，這樣設計的話真的會如 xhl 所言的那樣不會造成過多的延遲嗎？

bobozhang

to flw:  南北問題應該不算大問題哈，在雙線機房里面電信布置一個gate，網(wǎng)通布置一個gate

翠羽黃衫

最近也要看網(wǎng)絡游戲服務器相關(guān)的東西，看點啥好呢？各位前輩給介紹介紹唄。。就是會涉及到的相關(guān)技術(shù)。。