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

            網絡服務器軟件開發/中間件開發,關注ACE/ICE/boost

            C++博客 首頁 新隨筆 聯系 聚合 管理
              152 Posts :: 3 Stories :: 172 Comments :: 0 Trackbacks
              由于工作需要,趁假期這兩天補充下RakNet的相關應用,RakNet的官方網站:http://www.jenkinssoftware.com/index.html ,看介紹感覺很不錯,側重于游戲方面的開發,并實現了UDP的可靠傳輸,具備RPC的功能。我主要看了RPC相關的,從源代碼可以得知,RPC的功能經過了幾次完善,從RPC-->AutoRPC-->RPC3,心想終于找到c++實現的rpc了,高興之余開始編譯“Remote Procedure Calls”,“AutoRPC”和“RPC3”,其中前兩個demo已經被標記為__DEPRECIATED,我先看的RPC3,結果沒怎么看明白,所以又回頭看了下他的發展史。RakNet的所有基于C/S模型的demo都在一個project中實現,不太適應這種風格,感覺初學者的模仿難度加大。碰到的幾個需要注意的問題:
              1.RPC3只有非阻塞的調用模式,即client調用某個函數時立刻返回,調用結果以消息包的形式在隨后的某個時刻返回。沒有同步的調用,無疑加大了應用程序的復雜度,比如用戶登錄時獲取可用服務器列表,一個同步調用會非常簡單明了。如果是同步異步都提供就好了。
              2.異步接收網絡消息,沒有超時機制。這個問題比較麻煩,循環調用Receive,直到碰到返回NULL表示沒有數據包可讀了,這時只能sleep,相信大家比較反感這種策略,在通讀manual時,注意到作者提到game tick的概念,我揣測作者認為這種策略是正常的.我運行RPC3的demo,CPU占用到50%,如果將Sleep(0),改為Sleep(30)則占用降到百分之幾,FAQ中有如下描述:http://www.jenkinssoftware.com/raknet/manual/faq.html
                       I get very high pings.
                       Use 0 for the sleep timer, and put a Sleep(0) in your main game loop. This will ensure responsive context switches.
                      I get very high CPU usage
                       Use 30 for the sleep timer. This will ensure RakNet spends most of its time waiting.
              3.要嚴格保證Receive和DeallocatePacket的順序,如果packet1 = Receive();packet2 = Receiver();則一定要保證DeallocatePacket(packet1),然后DeallocatePacket(packet2).因為他的內部是靠內存池的指針偏移來實現的。因此,如果想多線程處理似乎避免不了數據包的復制(?)
              總體來說,這個RPC還是比較簡單的那種,傳統的RPC方案一般提供IDL,然后生成對應的頭文件和源文件,比如sunrpc,ice。
              附件里上傳了自己改寫的RPC3 demo,client和server是分開的,很容易添加新的功能,需要的朋友可以參考下,接觸時間不長,不能保證沒有錯誤哦。http://m.shnenglu.com/Files/true/RPC3Demo.rar
              現在有個想法:數據庫服務器基于RPC實現,不過C++的RPC實現好像很少,誰給推薦個?
            posted on 2009-10-05 20:50 true 閱讀(5061) 評論(4)  編輯 收藏 引用 所屬分類: 網絡服務器開發CORBA 、游戲開發 、RakNet

            Feedback

            # re: 體驗RakNet的RPC3 2009-10-06 10:16 周龍亭
            gSoap,C++實現的WebService  回復  更多評論
              

            # re: 體驗RakNet的RPC3[未登錄] 2010-09-20 16:19 vincent
            您好,有一個問題
            我現在還不是很了解rpc,只知道它是基于函數的遠程調用
            而corba是針對對象的
            顯然在維護世界邏輯的時候,用corba應該會顯得更簡單一些
            但是我看到使用rpc的人還是有很多的
            我很好奇原因:)  回復  更多評論
              

            # re: 體驗RakNet的RPC3 2010-09-20 17:44 true
            @vincent
            CORBA,過于復雜了,RPC是遠程過程調用,就是調用函數,AMI:是異步方法調用,調用的是對象的成員,CORBA和ICE里面都有AMI功能,但是寫邏輯真的個人感覺不太適合直接用RPC或者AMI得方式,我一般用來處理一些很簡單的功能,比如和中心服務器的交互,像分配全局session id等,而且CORBA有自己的類型系統(int,long,short ,string等),這些類型與客戶端與服務器傳輸時常用的uint8,uint32等等,不一致,最好不要有兩種類型系統  回復  更多評論
              

            # re: 體驗RakNet的RPC3 2012-04-09 04:10 雅歌
            “異步接收網絡消息,沒有超時機制。這個問題比較麻煩,循環調用Receive,直到碰到返回NULL表示沒有數據包可讀了,這時只能sleep”

            不懂你說這話是什么意思。
            既然是異步的,你是被回調的,怎么還“循環調用Receive”?而且還要“sleep”?
            莫名其妙  回復  更多評論
              

            久久精品国产清自在天天线| 久久AAAA片一区二区| AV无码久久久久不卡蜜桃| 狠狠色丁香久久婷婷综合| 久久精品国产亚洲AV麻豆网站| 久久99精品久久久久久hb无码| 国产麻豆精品久久一二三| 久久精品国产黑森林| 久久久久久毛片免费播放| 国产激情久久久久影院| 狠狠色综合网站久久久久久久高清 | 国产精品美女久久久久| 91精品国产91久久久久久蜜臀| 亚洲国产成人精品久久久国产成人一区二区三区综| 久久午夜无码鲁丝片午夜精品| 成人国内精品久久久久一区| 色综合久久天天综线观看| 久久精品国产一区| 久久九九兔免费精品6| 久久免费观看视频| 日韩亚洲欧美久久久www综合网 | 26uuu久久五月天| 欧美熟妇另类久久久久久不卡| 久久久久国产精品嫩草影院 | 久久免费国产精品一区二区| 综合人妻久久一区二区精品| 天天综合久久一二三区| 亚洲伊人久久大香线蕉苏妲己| 午夜不卡久久精品无码免费| 亚洲国产天堂久久久久久| 精品国产乱码久久久久久浪潮| 欧美精品一本久久男人的天堂| 久久亚洲精品人成综合网| 日日躁夜夜躁狠狠久久AV| 国产精品久久久香蕉| 一本色道久久88综合日韩精品 | 久久亚洲AV成人无码软件| 久久婷婷五月综合成人D啪| 久久91这里精品国产2020| 狠狠久久综合伊人不卡| 国产精品亚洲综合专区片高清久久久 |