• <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://www.shnenglu.com/Files/true/RPC3Demo.rar
              現在有個想法:數據庫服務器基于RPC實現,不過C++的RPC實現好像很少,誰給推薦個?
            posted on 2009-10-05 20:50 true 閱讀(5049) 評論(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”?
            莫名其妙  回復  更多評論
              

            久久国产精品99精品国产987| 久久99免费视频| 久久综合给久久狠狠97色| 久久国产乱子精品免费女| 日本精品久久久久久久久免费| 国产精品欧美久久久天天影视| 一本色道久久HEZYO无码| 很黄很污的网站久久mimi色| 久久香蕉一级毛片| 欧美激情精品久久久久久久九九九| 久久免费精品一区二区| 国产精品99久久久精品无码| 久久最新免费视频| 精品久久久久久成人AV| 99久久夜色精品国产网站| 久久精品国产亚洲AV不卡| 97久久久精品综合88久久| 一本色综合网久久| 国产三级精品久久| 亚洲午夜久久久影院伊人| 久久国产AVJUST麻豆| 久久精品综合一区二区三区| 香港aa三级久久三级老师2021国产三级精品三级在| 99久久精品免费看国产一区二区三区| 国产精品成人99久久久久91gav| 国产伊人久久| 色婷婷噜噜久久国产精品12p| 亚洲人成无码www久久久 | 久久久老熟女一区二区三区| 久久婷婷五月综合色高清| 久久精品国产亚洲AV麻豆网站 | 久久久精品久久久久特色影视| 久久亚洲电影| 97精品国产97久久久久久免费| 国产产无码乱码精品久久鸭| 久久人妻少妇嫩草AV蜜桃| 免费久久人人爽人人爽av| 狠狠综合久久综合88亚洲| 国产午夜福利精品久久2021| 久久精品亚洲欧美日韩久久 | 久久久亚洲欧洲日产国码aⅴ|