• <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>
            隨筆 - 119  文章 - 290  trackbacks - 0

            博客搬家了哦,請(qǐng)移步
            叫我abc

            常用鏈接

            留言簿(12)

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 304382
            • 排名 - 84

            最新評(píng)論

            閱讀排行榜

            近些天寫(xiě)了一些游戲邏輯,發(fā)現(xiàn)項(xiàng)目組在寫(xiě)C/S網(wǎng)絡(luò)消息包的時(shí)候,根據(jù)作用的不同,定義了很多的不同的消息格式。比如,所有的消息包都繼承自下面這個(gè)基本結(jié)構(gòu)。
            struct?SPacket
            {
            ??
            byte??bType;
            }
            然后,添加物品的消息包,設(shè)置成員狀態(tài)的消息包都分別定義了不同的結(jié)構(gòu)。
            struct?SAddItemPacket?:?public?SPacket
            {
            ??SItem?item;
            ??SAddItem()
            ??
            {
            ????bType?
            =?STC_AddItem;
            ??}

            }


            struct?SSetMemberPacket?:?public??SPacket
            {
            ??
            byte??bStatus;
            ??SSetMemberPacket()
            ??
            {
            ????bType?
            =?STC_SetMember;
            ??}

            }

            隨著項(xiàng)目填充越來(lái)越多的內(nèi)容,消息包的類型越來(lái)越多,不能避免嗎?

            晚上睡覺(jué)的時(shí)候,想著如果把網(wǎng)絡(luò)引擎引入項(xiàng)目之類的會(huì)怎樣呢?然后想到看過(guò)的ICE教程,就大概的思考類似ICE這樣的通用RPC大概是怎樣實(shí)現(xiàn)的。
            RPC由服務(wù)對(duì)象以及其客戶端的表現(xiàn)——代理對(duì)象構(gòu)成。客戶端代碼中,調(diào)用了代理對(duì)象的某個(gè)接口,就會(huì)導(dǎo)致其服務(wù)對(duì)象執(zhí)行該接口的實(shí)現(xiàn),使得客戶端看起來(lái)就像是執(zhí)行本地調(diào)用一樣。
            因此RPC的直觀概念是接口調(diào)用的網(wǎng)絡(luò)映射,核心內(nèi)容是:如何將客戶端調(diào)用(某個(gè)對(duì)象的)某個(gè)接口的這一行為進(jìn)行通用的序列化?
            對(duì)調(diào)用行為序列化和對(duì)對(duì)象序列化是不同的,而且RPC的目標(biāo)是對(duì)任何類型的接口調(diào)用行為都能有一個(gè)通用的序列化方案。
            我們要調(diào)用某個(gè)接口的時(shí)候,下達(dá)的命令通常是,“某某類型的,那個(gè)誰(shuí),把你的那個(gè)名叫什么的方法調(diào)用一下,參數(shù)是這些,a,b,c,d”。這樣我們就進(jìn)行了一次接口調(diào)用。因此,調(diào)用行為最基本的序列化方法是,類型ID+方法ID+對(duì)象ID+參數(shù)。將這些數(shù)據(jù)加成起來(lái),就能作為一個(gè)調(diào)用消息包由客戶端發(fā)向服務(wù)器,服務(wù)器處理RPC管理的對(duì)象將會(huì)根據(jù)類ID,對(duì)象ID找到服務(wù)對(duì)象,然后根據(jù)方法ID,找到方法,并能根據(jù)方法知道有幾個(gè)參數(shù),以及參數(shù)的類型,最終執(zhí)行調(diào)用。

            因此,我此時(shí)覺(jué)得,像項(xiàng)目組現(xiàn)在定義的多種大小不變,種類繁多的消息格式,其實(shí)都可以用一個(gè)能序列化調(diào)用行為的消息包來(lái)解決。該消息包的結(jié)構(gòu)是:

            class??SPacket
            {
            ??WORD??wClassID;
            ??WORD??wMemberFuncID;
            ??BYTE??bParam[PACKET_PARAM_BUFFER_SIZE];
            ??QWORD??qwBufferOffset?
            =?0;

            public:
            ??SPacket(WORD?par_wClassID,WORD?par_FuncID,?DWORD?dwObjID);
            ??SPacket(WORD?par_wClassID,WORD?par_FuncID,?QWORD?qwObjID);

            ??template
            <typename?T>
            ??
            bool??Push(T?value)
            ??
            {
            ????memcpy(bParam?
            +?qwBufferOffset,value,sizeof(T);
            ????qwBufferOffset?
            +=?sizeof(T);
            ??}


            ??
            bool??Pop(T?&value)
            ??
            {
            ????T??
            *pValue?=?static_cast<T*>(bParam?+?qwBufferOffset)
            ????value?
            =?*pValue;
            ????qwBufferOffset?
            +=?sizeof(T);
            ??}


            ??QWORD??Size()?
            const
            ??
            {
            ????
            return??sizeof(wClassID)?+?sizeof(wMemberFuncID)?+?qwBufferOffset;
            ??}

            }
            ;
            參數(shù)從左到右裝入消息包,相應(yīng)的也是從左到右從消息包取出,來(lái)配合服務(wù)器端執(zhí)行相應(yīng)的函數(shù)。
            posted on 2007-01-26 23:26 LOGOS 閱讀(2504) 評(píng)論(12)  編輯 收藏 引用

            FeedBack:
            # re: 通用網(wǎng)絡(luò)消息包 2007-01-27 09:52 李錦俊
            那把SPacket裝包之后,發(fā)送到接受端,接受端還是要靠一個(gè)類型ID來(lái)區(qū)分不同的網(wǎng)絡(luò)消息的。
            是不是這樣用?
            class SSetMemberPacket : public SPacket
            {
            public:
            SSetMemberPacket()
            {
            Push(STC_SetMember);
            }
            };  回復(fù)  更多評(píng)論
              
            # re: 通用網(wǎng)絡(luò)消息包 2007-01-27 11:12 LOGOS
            不是。我覺(jué)得不要再增加更多的消息包結(jié)構(gòu)體了,不然文件我看了會(huì)真的受不了的。
            比如我要調(diào)用服務(wù)器 SomeClass::SetMember,我會(huì)這樣
            SPacket packet(SomeClassID,FUNC_SetMember,objID);
            // push param
            packet.Push(playerID);
            packet.Push(status);
            net.Send(socket,&packet.packet.Size());  回復(fù)  更多評(píng)論
              
            # re: 通用網(wǎng)絡(luò)消息包 2007-01-27 11:17 LOGOS
            接受端區(qū)分消息類型肯定還是要ID啊。
            也只有這樣才能區(qū)分消息吧。這也是沒(méi)有辦法的事情。
            但是,消息包的類型不用增加,
            因?yàn)镾Packet::SPacket(BYTE *bBuffer, DWORD dwSize)
            可以將網(wǎng)絡(luò)字節(jié)流變成SPacket對(duì)象。  回復(fù)  更多評(píng)論
              
            # re: 通用網(wǎng)絡(luò)消息包 2007-01-29 09:15 netdigger
            不過(guò)這樣可能會(huì)對(duì)運(yùn)行速度,傳輸速度會(huì)有一定的影響  回復(fù)  更多評(píng)論
              
            # re: 通用網(wǎng)絡(luò)消息包 2007-01-29 09:37 李錦俊
            其實(shí)這就是一個(gè)序列化的過(guò)程。
            我以前用MFC的CArchive和CMemFile實(shí)現(xiàn)的也蠻好。  回復(fù)  更多評(píng)論
              
            # re: 通用網(wǎng)絡(luò)消息包 2007-01-29 09:37 李錦俊
            另外說(shuō)說(shuō),boost也有序列化的封裝  回復(fù)  更多評(píng)論
              
            # re: 通用網(wǎng)絡(luò)消息包 2007-02-01 17:37 christanxw0
            @LOGOS
            這樣你得嚴(yán)格控制push的順序啊。如果定義消息結(jié)構(gòu)顯然字段的順序編譯期就確定下來(lái)了。但是你這么做,就必須在寫(xiě)代碼的時(shí)候嚴(yán)格控制push的順序,保證和接受方pop的順序是一樣的。  回復(fù)  更多評(píng)論
              
            # re: 通用網(wǎng)絡(luò)消息包 2007-02-02 20:22 LOGOS
            @christanxw0
            嗯。確實(shí)是這樣子。
            但是有得有失吧。
            畢竟項(xiàng)目里面的消息包類型實(shí)在太龐大了,而且消息包以功能為向?qū)Фx的,如果缺少注釋其含義通常會(huì)比較含糊。
              回復(fù)  更多評(píng)論
              
            # re: 通用網(wǎng)絡(luò)消息包 2007-11-20 09:20 ulti
            可以用MQ4CCP的,感覺(jué)不錯(cuò),不過(guò)沒(méi)用過(guò)。
            http://www.sixtyfourbit.org/mq4cpp.htm
              回復(fù)  更多評(píng)論
              
            # re: 通用網(wǎng)絡(luò)消息包 2008-01-03 10:31 abc
            這么做有那些優(yōu)點(diǎn)呢?  回復(fù)  更多評(píng)論
              
            # re: 通用網(wǎng)絡(luò)消息包 2008-01-27 13:59 okmmno1
            復(fù)雜消息的序列化無(wú)法處理,變長(zhǎng)消息處理不好。
            總之,序列化是個(gè)比較復(fù)雜的問(wèn)題, 正在頭疼中。  回復(fù)  更多評(píng)論
              
            # re: 通用網(wǎng)絡(luò)消息包 2008-09-16 10:32 zuhd
            可以嘗試重載》和《哦,只要知道數(shù)據(jù)的長(zhǎng)度就可以用memcpy了,不過(guò)像vector這樣的就要把長(zhǎng)度也序列化進(jìn)去了,取出來(lái)的時(shí)候就直接放在對(duì)應(yīng)的結(jié)構(gòu)體了,非常方便,兩邊的對(duì)稱也很有美感  回復(fù)  更多評(píng)論
              

            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問(wèn)   Chat2DB   管理


            色综合久久天天综合| 国产精品久久久久9999| 久久精品二区| 伊人久久一区二区三区无码| 久久人人爽人人爽人人片av麻烦 | 色综合久久无码五十路人妻| 99久久免费国产精精品| 久久久久这里只有精品 | 亚洲精品久久久www| 奇米影视7777久久精品| 99久久亚洲综合精品成人| 久久国产AVJUST麻豆| 欧美综合天天夜夜久久| 久久久噜噜噜久久中文字幕色伊伊| 久久精品国产亚洲AV高清热| 国产成人久久久精品二区三区 | 热久久国产欧美一区二区精品 | 中文字幕乱码久久午夜| 99久久成人18免费网站| 无码国内精品久久人妻| 亚洲精品97久久中文字幕无码| 国产91久久精品一区二区| 7777久久久国产精品消防器材 | 久久亚洲精品人成综合网| 亚洲Av无码国产情品久久| 亚洲精品国产成人99久久| 亚洲综合伊人久久综合| 亚洲精品成人网久久久久久| 精品久久久久久无码国产| 久久线看观看精品香蕉国产| 国内精品伊人久久久久AV影院| 亚洲第一极品精品无码久久 | 久久国产精品一区二区| 性欧美丰满熟妇XXXX性久久久| 久久这里只有精品视频99| 久久精品国产亚洲Aⅴ香蕉 | 伊人久久大香线蕉综合Av| 久久久久亚洲av成人无码电影| 亚洲国产精品久久久久久| 精品亚洲综合久久中文字幕| 久久久精品人妻一区二区三区四 |