• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            教父的告白
            一切都是紙老虎
            posts - 82,  comments - 7,  trackbacks - 0
            原文:http://hi.baidu.com/huangyunjun999/blog/item/7396b8c2378e4a3ce4dd3bda.html

            接觸了一段時間的網游封包設計,有了一些初步的思路,想借這篇文章總結一下,同時也作個記錄,以利于以后更新自己的思路。
            網絡游戲的技術研發,分為三個主要的方面:服務器設計,客戶端設計,數據庫設計。而在服務器和客戶端之間實現游戲邏輯的中介則是游戲數據包,服務器和 客戶端通過交換游戲數據包并根據分析得到的數據包來驅動游戲邏輯。網絡游戲的實質是互動,而互動的控制則由服務器和客戶端協同完成,協同就必然要依靠數據 來完成。
            當前網絡游戲中的封包,其定義形式是各種各樣的,但歸納起來,一般都具有如下要素:封包長度,封包類型,封包參數,校驗碼等。
            封包長度用于確定當前游戲數據包的長度,之所以提供這個數據,是因為在底層的TCP網絡傳輸中,出于傳輸效率的考慮,傳輸有時會把若干個小的數據包合 并成一個大的數據包發送出去,而在合并的過程中,并不是把每一個邏輯上完整的數據包全部合并到一起,有時可能因為這種合并而將一個在邏輯上具有完整意義的 游戲數據包分在了兩次發送過程中進行發送,這樣,當前一次的數據發送到接受方之后,其尾部的數據包必然造成了“斷尾”現象,為了判定這種斷尾的情況以及斷 尾的具體內容,游戲數據包在設計時一般都會提供封包長度這個信息,根據這個信息接受方就知道收到的包是否有斷尾,如果有斷尾,則把斷尾的數據包與下次發過 來的數據包進行拼接生成原本在邏輯意義上完整的數據包。
            封包類型用于標識當前封包是何種類型的封包,表示的是什么含義。
            封包參數則是對封包類型更具體的描述,它里面指定了這種類型封包說明里所必須的參數。比如說話封包,它的封包類型,可以用一個數值進行表示,而具體的說話內容和發言的人則作為封包參數。
            校驗碼的作用是對前述封包內容進行校驗,以確保封包在傳遞過程中內容不致被改變,同時根據校驗碼也可以確定這個封包在格式上是不是一個合法的封包。以 校驗碼作為提高封包安全性的方法,已經是目前網游普遍采用的方式。封包設計,一般是先確定封包的總體結構,然后再來具體細分有哪些封包,每個封包中應該含 有哪些內容,最后再詳細寫出封包中各部分內容具體占有的字節數及含義。
            數據包的具體設計,一般來說是根據游戲功能進行劃分和圈定的。比如游戲中有聊天功能,那么就得設計客戶端與服務器的聊天數據包,客戶端要有一個描述發 言內容與發言人信息的數據包,而在服務器端要有一個包含用戶發言內容及發言人信息的廣播數據包,通過它,服務器端可以向其他附近玩家廣播發送當前玩家的發 言內容。再比如游戲中要有交易功能,那么與這個功能相對應的就可能會有以下數據包:申請交易包,申請交易的信息包,允許或拒絕交易包,允許或拒絕交易的信 息包,提交交易物品包,提交交易物品的信息包,確認交易包,取消交易包,取消交易的信息包,交易成功或失敗的信息包。需要注意的是,在這些封包中,有的是 一方使用而另一方不使用的,而有的則是雙方都使用的包。比如申請交易包,只可能是一方使用,而另一方會得到一個申請交易的信息包;而確認交易包和提交交易 物品這樣的數據包,都是雙方在確定要進行交易時要同時使用的。封包的設計也遵從由上到下的設計原則,即先確定有哪些功能的封包,再確定封包中應該含有的信 息,最后確定這些信息應該占有的位置及長度。一層層的分析與定義,最終形成一個完善的封包定義方案。在實際的封包設計過程中,回溯的情況是經常出現的。由 于初期設計時的考慮不周或其它原因,可能造成封包設計方案的修改或增刪,這時候一個重要的問題是要記得及時更新你的設計文檔。在我的封包設計中,我采用的 是以下的封包描述表格進行描述:
            封包編號   功能描述  對應的類或結構體名  類型命令字  命令參數結構體及含義 
            根據游戲的功能,我們可以大致圈定封包的大致結構及所含的大致內容。但是,封包設計還包含有其它更多的內容,如何在保證封包邏輯簡潔的前提下縮短封包 的設計長度提高封包的傳輸速度和游戲的運行速度,這也是我們應該考慮的一個重要問題。一般情況下,設計封包時,應該盡量避免產生一百字節以上的封包,多數 封包的定義控制在100字節以內,甚至20-50字節以內。在我所定義的封包中,多數在20字節以內,對于諸如傳遞服務器列表和用戶列表這樣的封包可能會 大一點。總之一句話,應該用盡可能短的內容盡可能簡潔清晰地描述封包功能和含義。
            在封包結構設計方面,我有另一種可擴展的思路:對封包中各元素的位置進行動態定義。這樣,當換成其它游戲或想更換當前游戲的封包結構時,只要改變這些 元素的動態定義即可,而不需要完全重新設計封包結構。比如我們對封包編號,封包類型,封包參數,校驗碼這些信息的開始位置和長度進行定義,這樣就可以形成 一個動態定義的封包結構,對以后的封包移植將會有很大幫助,一個可能動態改變封包結構的游戲數據包,在相當程度上增加了外掛分析封包結構的難度。
            在進行封包設計時,最好根據封包客戶端和服務器端的不同來分類進行設計。比如大廳與游戲服務器的封包及游戲服務器與游戲客戶端的封包分開來進行設計,在包的編號上表示出他們的不同(以不同的開頭單詞表示),這樣在封包的總體結構上就會更清晰。

            posted on 2009-09-23 23:36 暗夜教父 閱讀(461) 評論(0)  編輯 收藏 引用 所屬分類: Game Development

            <2009年9月>
            303112345
            6789101112
            13141516171819
            20212223242526
            27282930123
            45678910

            常用鏈接

            留言簿(2)

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            久久精品国产欧美日韩| 色欲av伊人久久大香线蕉影院| 久久er99热精品一区二区| 久久亚洲精品中文字幕| 久久精品国产亚洲综合色| 久久久久99精品成人片三人毛片| 思思久久99热只有频精品66| 久久香综合精品久久伊人| 国产午夜电影久久| 久久人人爽爽爽人久久久| 91秦先生久久久久久久| 狠狠色丁香久久婷婷综合_中 | 国产成人无码精品久久久久免费| 久久精品国产亚洲Aⅴ蜜臀色欲| 亚洲欧美日韩中文久久| 久久久久亚洲AV综合波多野结衣| 久久亚洲私人国产精品| 伊人久久大香线蕉精品不卡| www.久久99| 日产精品99久久久久久| 伊人久久大香线蕉综合网站| 国产无套内射久久久国产| 久久久噜噜噜久久中文福利| 麻豆av久久av盛宴av| 亚洲&#228;v永久无码精品天堂久久| 2021少妇久久久久久久久久| 久久久久久久精品妇女99| 欧美性猛交xxxx免费看久久久| 日本三级久久网| 99久久99这里只有免费的精品| 日韩欧美亚洲综合久久| 亚洲精品tv久久久久| 久久天天躁狠狠躁夜夜不卡| 精品久久久久久99人妻| 中文精品久久久久国产网址| 精品九九久久国内精品| 久久精品国产影库免费看| 久久国产精品成人免费| 88久久精品无码一区二区毛片 | 国产日韩欧美久久| 国产精品成人久久久久久久|