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

anders0913

原帖由 bobozhang 于 2009-9-9 14:32 發(fā)表
to anders0913:  不是傳奇那套代碼哈，那個代碼是dephi的，看不懂，至于c++那套，聽人說本身寫得比較爛，沒看過

to benjiam：壓力大是否可以增加gate的個數(shù)來解決？我主要關(guān)心延遲的問題哈，這樣設(shè)計的話真的 ...

那兩套都看過~~

[ 本帖最后由 anders0913 于 2009-9-9 15:09 編輯 ]

xhl

原帖由 bobozhang 于 2009-9-9 14:32 發(fā)表
to anders0913:  不是傳奇那套代碼哈，那個代碼是dephi的，看不懂，至于c++那套，聽人說本身寫得比較爛，沒看過

to benjiam：壓力大是否可以增加gate的個數(shù)來解決？我主要關(guān)心延遲的問題哈，這樣設(shè)計的話真的 ...

延遲 問題是個比較復雜的問題， 要看你做什么類型的游戲， 什么類型的應(yīng)用。

竟速類型的游戲跟wow這種rpg類型的， 處理方法完全不一樣。 沒有通用的架夠， 要具體問題具體分析。

產(chǎn)生 延遲 有很多原因， 但最主要的影響就是外網(wǎng)帶寬，還有就是如果想高instant, 不能采用tcp stream service, 應(yīng)該采用udp, 采用關(guān)鍵frame思路。

只有關(guān)鍵frame才retransmit,  還有就是主邏輯服務(wù)的運算能力。 因為很多游戲邏輯部分， 存在大量的計算量。 按里說cpu應(yīng)該比網(wǎng)絡(luò)快的多， 但大量的

運算會改變這個事實。 至于你擔心的那點延遲， 其實根本就不是關(guān)鍵的地方。

benjiam

udp 是關(guān)鍵

tcp 因為在棧里面要重新排序這一些系列復雜的計算 所以 局域網(wǎng)網(wǎng)絡(luò)里面測試 流暢得很 出去就卡了。


我們現(xiàn)在有這個問題， 當時有個人提出要udp 被技術(shù)leader 否決， 現(xiàn)在就很卡。 很麻煩。 唉， 一場 政治謀殺

bobozhang

原帖由 xhl 于 2009-9-9 15:08 發(fā)表



延遲 問題是個比較復雜的問題， 要看你做什么類型的游戲， 什么類型的應(yīng)用。

竟速類型的游戲跟wow這種rpg類型的， 處理方法完全不一樣。 沒有通用的架夠， 要具體問題具體分析。

產(chǎn)生 延遲 有很多原 ...

哦，看來你是從實際經(jīng)驗中得出的結(jié)論，可信性比較高哈，謝謝！

[ 本帖最后由 bobozhang 于 2009-9-9 15:22 編輯 ]

bobozhang

原帖由 benjiam 于 2009-9-9 15:13 發(fā)表
udp 是關(guān)鍵

tcp 因為在棧里面要重新排序這一些系列復雜的計算 所以 局域網(wǎng)網(wǎng)絡(luò)里面測試 流暢得很 出去就卡了。


我們現(xiàn)在有這個問題， 當時有個人提出要udp 被技術(shù)leader 否決， 現(xiàn)在就很卡。 很麻煩。  ...

現(xiàn)在的網(wǎng)絡(luò)游戲不都是用的tcp嗎，rpg類型的用tcp應(yīng)該不會卡阿, 當然游戲里面要采用prediction

gz80

gateway壓力大可以寫個gateway name server，客戶端用短連接向gateway name server獲取gateway地址，name server以負載均衡為原則分配gateway IP。
當然搞這套東西還不如flw的初始連接，畢竟你gateway轉(zhuǎn)發(fā)是應(yīng)用層的，延遲比較大。

net_robber

放一臺“gateway”處理每個用戶實際鏈接到哪臺服務(wù)器不是挺好的么？？

沒有人規(guī)定這個鏈接必須一致保持

net_robber

另外，既然要做分布式的處理，為什么不把帳號驗證之類的流程也分出來到一臺/組單獨的服務(wù)器上呢？？

xhl

原帖由 gz80 于 2009-9-9 15:23 發(fā)表
gateway壓力大可以寫個gateway name server，客戶端用短連接向gateway name server獲取gateway地址，name server以負載均衡為原則分配gateway IP。
當然搞這套東西還不如flw的初始連接，畢竟你gateway轉(zhuǎn)發(fā)是應(yīng) ...

這個說法應(yīng)該結(jié)合游戲邏輯， 多人網(wǎng)絡(luò)游戲網(wǎng)絡(luò)上壓力最大的地方是什么？ 廣播壓力。

假如我周圍有50個人， 每個人的走動， 都要instant 的同步給周圍可見的其他人。 這個壓力就是 50 * 50的。

這個廣播壓力， 如果用地圖server一個去做， 那即使沒有你說的所謂應(yīng)用層轉(zhuǎn)發(fā)的延遲， 基本你的邏輯server也卡的要死了。

用gateway(我喜歡叫clientproxy)的好處是， 如果我現(xiàn)在有5個clientproxy, 沒個上面有10個人， 我邏輯server只發(fā)5條同樣的消息給每個clientproxy,

在由clientproxy分別自己每人負責的client廣播到， 是這樣效率好， 還是計較那點轉(zhuǎn)發(fā)延遲效率好呢？

benjiam

原帖由 xhl 于 2009-9-9 15:41 發(fā)表



這個說法應(yīng)該結(jié)合游戲邏輯， 多人網(wǎng)絡(luò)游戲網(wǎng)絡(luò)上壓力最大的地方是什么？ 廣播壓力。

假如我周圍有50個人， 每個人的走動， 都要instant 的同步給周圍可見的其他人。 這個壓力就是 50 * 50的。

這個 ...

的確  我開始也不明白。 后來明白了 這樣可以大量減少server 和 gateway 之間的數(shù)據(jù)

server 發(fā)少量數(shù)據(jù) 由 gateway 轉(zhuǎn)發(fā)。 gateway 壓力大很正常