• <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 閱讀(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”?
            莫名其妙  回復  更多評論
              

            久久久久亚洲国产| 久久99精品久久久久久水蜜桃| 久久久久国产精品麻豆AR影院| 久久黄视频| 久久精品国产亚洲AV麻豆网站 | 亚洲αv久久久噜噜噜噜噜| 日韩欧美亚洲国产精品字幕久久久| 久久狠狠爱亚洲综合影院| 国产精品久久午夜夜伦鲁鲁| 久久久WWW免费人成精品| 久久综合给久久狠狠97色| 国产精自产拍久久久久久蜜| 亚洲中文字幕无码一久久区| 久久精品99无色码中文字幕| 999久久久免费精品国产| 久久久久久久免费视频| 99久久婷婷国产综合精品草原 | 中文字幕久久精品| 国产精品美女久久久久网| 久久久国产精华液| 伊人热热久久原色播放www | 亚洲а∨天堂久久精品| 97久久精品午夜一区二区| 97精品依人久久久大香线蕉97| 久久久久无码专区亚洲av| 久久精品这里热有精品| 亚洲国产精品无码久久98| 亚洲精品99久久久久中文字幕 | 久久亚洲日韩看片无码| 久久精品国产72国产精福利| 久久se精品一区二区| 久久综合香蕉国产蜜臀AV| 女人高潮久久久叫人喷水| 亚洲国产成人精品女人久久久 | 久久精品黄AA片一区二区三区| 久久久噜噜噜久久中文字幕色伊伊 | 亚洲国产成人乱码精品女人久久久不卡| 久久久久四虎国产精品| 77777亚洲午夜久久多人| 亚洲女久久久噜噜噜熟女| 亚洲狠狠婷婷综合久久蜜芽|