• <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)

            隨筆分類(lèi)

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 304568
            • 排名 - 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)型越來(lái)越多,不能避免嗎?

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

            因此,我此時(shí)覺(jué)得,像項(xiàng)目組現(xiàn)在定義的多種大小不變,種類(lèi)繁多的消息格式,其實(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 閱讀(2507) 評(píng)論(12)  編輯 收藏 引用

            FeedBack:
            # re: 通用網(wǎng)絡(luò)消息包 2007-01-27 09:52 李錦俊
            那把SPacket裝包之后,發(fā)送到接受端,接受端還是要靠一個(gè)類(lèi)型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ū)分消息類(lèi)型肯定還是要ID啊。
            也只有這樣才能區(qū)分消息吧。這也是沒(méi)有辦法的事情。
            但是,消息包的類(lè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)目里面的消息包類(lèi)型實(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ì)稱(chēng)也很有美感  回復(fù)  更多評(píng)論
              

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


            中文无码久久精品| 丰满少妇人妻久久久久久| 97久久精品人人做人人爽| 亚洲午夜精品久久久久久人妖| 精品久久久久久中文字幕| 久久se这里只有精品| 伊人久久大香线蕉无码麻豆| 2021国产精品久久精品| 久久人人爽人人爽人人AV| 99久久国产亚洲高清观看2024| 伊人色综合九久久天天蜜桃| 精品久久久久久无码专区不卡| 久久久久亚洲精品天堂久久久久久| 午夜精品久久久久久毛片| 久久久久久综合一区中文字幕| 精品国产青草久久久久福利| 国产午夜精品理论片久久| 久久综合综合久久综合| 久久天天躁狠狠躁夜夜2020一| 国产精品成人精品久久久| 浪潮AV色综合久久天堂| 亚洲国产视频久久| 国产精品无码久久久久| 99久久精品国产一区二区| 精品综合久久久久久888蜜芽| 伊人久久五月天| 青春久久| 久久久无码精品午夜| 久久99精品国产麻豆不卡| 国产精品无码久久四虎| 久久99精品国产一区二区三区| 亚洲欧美日韩久久精品第一区| 国内精品久久国产| 久久婷婷是五月综合色狠狠| 久久本道综合久久伊人| 久久久久国产视频电影| 精品人妻伦一二三区久久| 亚洲国产成人久久一区WWW| 久久久久久久91精品免费观看| 一本一本久久a久久精品综合麻豆| 婷婷国产天堂久久综合五月|