專利名稱：服務(wù)器控制的基于p2p網(wǎng)游同步方法
技術(shù)領(lǐng)域：
本發(fā)明涉及利用P2P，即點(diǎn)對(duì)點(diǎn)的技術(shù)來(lái)實(shí)現(xiàn)網(wǎng)游中的數(shù)據(jù)同步和傳輸，同時(shí)也對(duì) 客戶端的同步提出了管理的方法用以提高網(wǎng)絡(luò)傳輸?shù)男室约霸诳蛻舳送竭^(guò)程中服務(wù) 器起到控制同步的方法。
背景技術(shù)：
網(wǎng)絡(luò)模塊是網(wǎng)絡(luò)游戲系統(tǒng)中最重要的模塊之一，目前，CS架構(gòu)在網(wǎng)游中的應(yīng)用十 分普遍，CS架構(gòu)表示客戶端與服務(wù)端架構(gòu)，在CS架構(gòu)下，每個(gè)客戶端都會(huì)與服務(wù)端建立連 接，且不同的客戶端間相互獨(dú)立。對(duì)于實(shí)時(shí)性較高的數(shù)據(jù)，如移動(dòng)數(shù)據(jù)、動(dòng)作數(shù)據(jù)等，在CS架構(gòu)下，用戶的操作會(huì)以 數(shù)據(jù)包的形式上傳至服務(wù)器端，服務(wù)器將操作轉(zhuǎn)化為位置數(shù)據(jù)，服務(wù)器再將位置數(shù)據(jù)同步 給各個(gè)客戶端，此模式如附圖1所示。目前，在上述CS架構(gòu)下，自己客戶端也會(huì)做出一些自己的計(jì)算，來(lái)改善玩家的體 驗(yàn)，但這些改進(jìn)以及原來(lái)的方法都有如下的缺點(diǎn)1.大部分計(jì)算都在服務(wù)端進(jìn)行，服務(wù)器計(jì)算器比較大，因此對(duì)服務(wù)器要求很高2.數(shù)據(jù)先會(huì)上傳到服務(wù)器，再由服務(wù)器分發(fā)給各個(gè)客戶端，即時(shí)同步數(shù)據(jù)多，且頻 率較高的情況下，服務(wù)器的網(wǎng)絡(luò)帶寬要求高

發(fā)明內(nèi)容
在處理實(shí)時(shí)性較高，且同步頻率要求比較高的數(shù)據(jù)時(shí)，傳輸數(shù)據(jù)量很大，對(duì)帶寬要 求比較高，為了減輕服務(wù)器的負(fù)擔(dān)，能讓服務(wù)器帶更多的客戶端，也減小服務(wù)器的帶寬要 求，減少運(yùn)營(yíng)成本，客戶端之間可以互傳數(shù)據(jù)，服務(wù)端與客戶端數(shù)據(jù)同步步驟是步驟1 做好服務(wù)器的各項(xiàng)配置，啟動(dòng)游戲服務(wù)器；步驟2 用另外幾個(gè)客戶端登入服務(wù)器；步驟3 服務(wù)器初始化各個(gè)客戶端的同步列表；步驟4 每個(gè)客戶端產(chǎn)生狀態(tài)變化等數(shù)據(jù)；步驟5 各個(gè)客戶端向自己同步列表中客戶端發(fā)送產(chǎn)生的即時(shí)數(shù)據(jù)；步驟6 向服務(wù)器端發(fā)送產(chǎn)生的即時(shí)數(shù)據(jù)；步驟7 服務(wù)器根據(jù)客戶端狀態(tài)的變化判斷哪些客戶端需要改變同步列表，并向 該客戶端發(fā)送新的同步列表；步驟8:重復(fù)步驟4-7。本發(fā)明的優(yōu)越性在于1)將一部分計(jì)算量放在客戶端，服務(wù)端的計(jì)算量大大減小，這樣同一臺(tái)服務(wù)器能 帶更多的客戶端2)相比于傳統(tǒng)的模式中的每個(gè)周期服務(wù)端要傳大量數(shù)據(jù)到各個(gè)客戶端，新的傳輸 模式，會(huì)更節(jié)省服務(wù)器端的帶寬
3)同于只需要選擇性的同步，客戶端所接收的數(shù)據(jù)會(huì)更少，幫同步會(huì)更加的便捷 和快速4)服務(wù)器只負(fù)責(zé)判斷和控制更新各個(gè)客戶的同步列表，這樣服務(wù)器與客戶端分工 明確，且服務(wù)器和客戶端的負(fù)載較輕除此之外，本方法也有一些問(wèn)題，需要改進(jìn)的地方1)客戶端的負(fù)擔(dān)比原來(lái)稍重，自己會(huì)有一部分的計(jì)算量
2)由于客戶端有發(fā)送數(shù)據(jù)的權(quán)力，安全性會(huì)有更大的挑戰(zhàn)，因此對(duì)安全性的要求 更高


附圖1是三個(gè)客戶端都須同步的傳輸模型。附圖2是三個(gè)客戶端部分需要同步的傳輸模型。附圖3是服務(wù)器控制下的客戶端數(shù)據(jù)同步模式流程圖。
具體實(shí)施例方式在網(wǎng)絡(luò)游戲中，數(shù)據(jù)量最大的是由客戶端實(shí)時(shí)產(chǎn)生的數(shù)據(jù)，這些數(shù)據(jù)也會(huì)直接影 響到用戶的體驗(yàn)。如圖2所示，每個(gè)客戶端都有一個(gè)操控物體，那么這個(gè)客戶端有改變這個(gè)物體數(shù) 據(jù)的權(quán)利，如果客戶端1所控制物體的數(shù)據(jù)發(fā)生的了改變，首先它會(huì)向服務(wù)器發(fā)送同步消 息，服務(wù)器會(huì)根據(jù)各個(gè)客戶端對(duì)象的狀態(tài)來(lái)決定哪些客戶端間需要進(jìn)行數(shù)據(jù)同步，如果如 圖上的三個(gè)客戶端所示，三個(gè)客戶端都需要進(jìn)行同步，互相間有同步數(shù)據(jù)的傳輸。這樣所有 的客戶端和服務(wù)器端都進(jìn)行了同步，服務(wù)器的負(fù)載和所需的帶寬也最小。同樣，如果其它客 戶端比如客戶端2狀態(tài)發(fā)生改變，也會(huì)向客戶端1和客戶端3發(fā)送數(shù)據(jù)以及跟服務(wù)器同步。如果由于狀態(tài)的改變客戶端1和客戶端3，它們之間不需要進(jìn)行狀態(tài)的更新，當(dāng)它 們的狀態(tài)傳到服務(wù)器后，服務(wù)器做出判斷，會(huì)更新客戶端1和客戶端3的數(shù)據(jù)同步列表，新 的傳輸模型如附圖2所示；此時(shí)可以看出客戶端1和客戶端3的負(fù)擔(dān)會(huì)有所減小，客戶端1只需要跟客戶端 2進(jìn)行數(shù)據(jù)同步，而不需要跟客戶端3進(jìn)行同步，客戶端3跟客戶端1 一樣，當(dāng)客戶端較多 時(shí)，如果有300個(gè)玩家連到此服務(wù)器上，一般來(lái)說(shuō)同一個(gè)場(chǎng)景中不會(huì)同時(shí)出現(xiàn)太多的玩家， 如果A玩家在一起的玩家只有十幾個(gè)，則只有這些玩家需要跟A進(jìn)行同步，A的同步信息會(huì) 大大的減小，只有原來(lái)的1/20左右，如果在人少的地方，則需要跟A的同步列表會(huì)更少，即 需要同步的人會(huì)更少。而在A玩家移動(dòng)到有其它人的地方，由于服務(wù)器會(huì)有所有客戶端的信息，會(huì)根據(jù)A 的變化來(lái)更新A的同步列表，如圖2所示，如果客戶端1狀態(tài)發(fā)生變化時(shí)，客戶端1和客戶 端3之間便不需要同步了，因此，在這里服務(wù)器端只負(fù)責(zé)判斷和更新各個(gè)客戶端的同步更 表，起到控制的作用，服務(wù)器的負(fù)擔(dān)也減小了很多。在游戲中，除了玩家操控的物體，還有一些無(wú)法操控的物體，它們由服務(wù)器端統(tǒng)一 發(fā)送。向各個(gè)客戶端來(lái)進(jìn)行同步。如圖3所示，本發(fā)明描述了新的網(wǎng)游數(shù)據(jù)傳輸模式，在上述傳輸模型中，服務(wù)器起 到了控制器的作用，它會(huì)根據(jù)客戶端的變化而更新各個(gè)客戶端的同步列表。
在網(wǎng)游中，對(duì)即時(shí)數(shù)據(jù)，比如移動(dòng)、攻擊等信息，要在其它客戶端時(shí)實(shí)的看到當(dāng)前 客戶的信息，需要很高的同步頻率，因此同步的數(shù)據(jù)量也會(huì)比較大，因此需要盡量減少需要 同步的客戶端的數(shù)量，每個(gè)客戶端所需要同步的其它客戶端數(shù)量越少越好，因此客戶端要 做一個(gè)同步列表，同步列表存儲(chǔ)當(dāng)前需要同步的其它客戶端的聯(lián)接。
為了減少服務(wù)器端的負(fù)擔(dān)，服務(wù)器端也需要減少網(wǎng)絡(luò)傳輸，在傳統(tǒng)模式中，服務(wù)器 端在每個(gè)同步周期中即需要接收各個(gè)客戶端傳輸來(lái)的數(shù)據(jù)，也需要負(fù)責(zé)把這些數(shù)據(jù)分發(fā)給 其它客戶端，而在本模式中，服務(wù)器端只需要接收各個(gè)客戶端發(fā)送來(lái)的數(shù)據(jù)，并且根據(jù)這些 發(fā)送來(lái)更新的數(shù)據(jù)，判斷各個(gè)客戶端的同步列表是否會(huì)發(fā)生變化，如果沒有變化，則不用處 理，如果發(fā)生變化，則服務(wù)器負(fù)責(zé)把更新列表發(fā)送給這個(gè)客戶端，而這個(gè)更新同步列表的頻 率會(huì)比每個(gè)同步周期發(fā)送同步數(shù)據(jù)的頻率要小得多，并且數(shù)據(jù)量也會(huì)小得多。能大大減小 服務(wù)器端所需要的網(wǎng)絡(luò)帶寬，并且客戶端間直接傳送同步數(shù)據(jù)會(huì)比先上傳服務(wù)器，再由服 務(wù)器來(lái)分發(fā)同步數(shù)據(jù)的過(guò)程要快很多。在一個(gè)服務(wù)器中所帶的客戶端可能會(huì)很多，根據(jù)上述方法，可以判斷出，比起全部 客戶端都要同步的方法，此發(fā)明中的方法很大一部分客戶端所需要同步的客戶端數(shù)量可能 只是一個(gè)很少的部分，比如每個(gè)玩家離得比較遠(yuǎn)，需要同步的數(shù)量會(huì)很少。但在玩家比較集 中的地方，此方法的效率會(huì)有所下降，但總的來(lái)說(shuō)，會(huì)大大提高系統(tǒng)的效率，特別是各個(gè)玩 家不是很集中，并且移動(dòng)不是很頻繁時(shí)，各個(gè)客戶端同步列表不會(huì)經(jīng)常變化，因此效率會(huì)特 別高。這種傳輸模式，最大限度的減少了服務(wù)器端的負(fù)擔(dān)，充分利用了客戶端的資源，各 個(gè)客戶端間的資源形成了共享，發(fā)送即時(shí)性較高的數(shù)據(jù)，客戶端的數(shù)據(jù)更新比較快，服務(wù)器 能帶更多的客戶端，客戶端之間的數(shù)據(jù)同步會(huì)更快。
權(quán)利要求
一種服務(wù)器控制的基于P2P網(wǎng)游同步方法，其特點(diǎn)在于A.服務(wù)器端實(shí)時(shí)接收各個(gè)客戶端的狀態(tài)變化信息，并且根據(jù)狀態(tài)變化情況更新客戶端的同步列表信息。B.客戶端向同步列表中的其它客戶端更新本客戶端控制角色的狀態(tài)變化信息。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟A中所述服務(wù)器判斷客戶端的同步列 表是否改變方法為根據(jù)客戶端上傳的信息，例如玩家的位置、朝向等信息，以確定該玩家目前需要同步的 其它玩家的列表，與目前的列表做對(duì)比，如果不同則該玩家的同步列表已經(jīng)發(fā)生改變。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述更新本地角色在其它客戶端位置的 方法為首先確定該角色當(dāng)前的狀態(tài)以及由服務(wù)器決定的本地同步更新列表，再根據(jù)此更 新列表來(lái)更新該角色在其它客戶端的位置等狀態(tài)信息。
4.根據(jù)權(quán)利要求1所述的方法，在步驟A中，如果服務(wù)器端判斷本地角色的同步列表發(fā) 生改變，則更新控制該角色的客戶端的同步列表，服務(wù)器便向該客戶端發(fā)送新的同步列表； 由步驟B，該客戶端根據(jù)新的同步列表更新該角色在其它客戶端的位置等狀態(tài)信息。
全文摘要
本發(fā)明提供一種服務(wù)器控制的基于P2P網(wǎng)游同步方法，在具有多個(gè)客戶端與服務(wù)端通訊的情況下，客戶端之間能夠傳輸數(shù)據(jù)，將一部分計(jì)算量放在客戶端，服務(wù)端的計(jì)算量大大減小，這樣同一臺(tái)服務(wù)器能帶更多的客戶端，相比于傳統(tǒng)的模式中的每個(gè)周期服務(wù)端要傳大量數(shù)據(jù)到各個(gè)客戶端，新的傳輸模式，會(huì)更節(jié)省服務(wù)器端的帶寬，同于只需要選擇性的同步，客戶端所接收的數(shù)據(jù)會(huì)更少，幫同步會(huì)更加的便捷和快速，服務(wù)器只負(fù)責(zé)判斷和控制更新各個(gè)客戶的同步列表，這樣服務(wù)器與客戶端分工明確，且服務(wù)器和客戶端的負(fù)載較輕。
文檔編號(hào)H04L29/08GK101841563SQ201010149179
公開日2010年9月22日 申請(qǐng)日期2010年4月16日 優(yōu)先權(quán)日2010年4月16日
發(fā)明者朱德棟 申請(qǐng)人:上海亞圖軟件有限公司