由于工作需要，趁假期這兩天補充下RakNet的相關(guān)應(yīng)用，RakNet的官方網(wǎng)站：http://www.jenkinssoftware.com/index.html
，看介紹感覺很不錯，側(cè)重于游戲方面的開發(fā)，并實現(xiàn)了UDP的可靠傳輸，具備RPC的功能。我主要看了RPC相關(guān)的，從源代碼可以得知，RPC的功能經(jīng)過了幾次完善，從RPC-->AutoRPC-->RPC3,心想終于找到c++實現(xiàn)的rpc了，高興之余開始編譯“Remote Procedure Calls”，“AutoRPC”和“RPC3”，其中前兩個demo已經(jīng)被標記為__DEPRECIATED，我先看的RPC3，結(jié)果沒怎么看明白，所以又回頭看了下他的發(fā)展史。RakNet的所有基于C/S模型的demo都在一個project中實現(xiàn)，不太適應(yīng)這種風(fēng)格，感覺初學(xué)者的模仿難度加大。碰到的幾個需要注意的問題：
1.RPC3只有非阻塞的調(diào)用模式，即client調(diào)用某個函數(shù)時立刻返回，調(diào)用結(jié)果以消息包的形式在隨后的某個時刻返回。沒有同步的調(diào)用，無疑加大了應(yīng)用程序的復(fù)雜度，比如用戶登錄時獲取可用服務(wù)器列表，一個同步調(diào)用會非常簡單明了。如果是同步異步都提供就好了。
2.異步接收網(wǎng)絡(luò)消息，沒有超時機制。這個問題比較麻煩，循環(huán)調(diào)用Receive，直到碰到返回NULL表示沒有數(shù)據(jù)包可讀了，這時只能sleep，相信大家比較反感這種策略，在通讀manual時，注意到作者提到game tick的概念，我揣測作者認為這種策略是正常的.我運行RPC3的demo，CPU占用到50%，如果將Sleep(0),改為Sleep（30）則占用降到百分之幾，F(xiàn)AQ中有如下描述：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).因為他的內(nèi)部是靠內(nèi)存池的指針偏移來實現(xiàn)的。因此，如果想多線程處理似乎避免不了數(shù)據(jù)包的復(fù)制(?)
總體來說，這個RPC還是比較簡單的那種，傳統(tǒng)的RPC方案一般提供IDL，然后生成對應(yīng)的頭文件和源文件，比如sunrpc，ice。
附件里上傳了自己改寫的RPC3 demo，client和server是分開的，很容易添加新的功能，需要的朋友可以參考下，接觸時間不長，不能保證沒有錯誤哦。http://m.shnenglu.com/Files/true/RPC3Demo.rar
現(xiàn)在有個想法：數(shù)據(jù)庫服務(wù)器基于RPC實現(xiàn)，不過C++的RPC實現(xiàn)好像很少，誰給推薦個？