• <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>
            posts - 18,  comments - 21,  trackbacks - 0
            上一篇 說了問題。現在說說重構后的構架。
            基于freebsd6.3 boost-1.35.0(多處升級,最重要是包含了asio,升級了thread) STLport-5.1.5 消息隊列(msgget,msgsnd,msgrcv)

            構架方便借鑒了部分云風的思路。
            loginserver,gate,gamedb,postoffice,mapserver
            accountdb去掉了,整合進loginserver里,loginserver直接連oracle,取列表信息后去連gate,gate連gamedb負責發人物列表

            家里機器只有畫圖。。。忍著看吧。。。
            下面開始都是一個服為一個單位。
            一個服的gate是可以隨時開關的,gate起來的時候會給loginserver和postoffice注冊
             1 struct GateInfo
             2 {
             3     char name[25];
             4     char ip[16];
             5     short port;
             6     uint online;
             7 };
             8 
             9 typedef vector<GateInfo*> VecGateInfo;
            10 VecGateInfo _gateinfo;
            11 
            12 // 當有用戶連上或者斷開gate時
            13 sort(_gateinfo.begin(), _gateinfo.end(), GateSort)
            14 
            15 // 這樣client取gate信息的時候只需要發給每個gate_group的第一個就行。

            gamedb是所有userinfo的集結地,有緩存,只在第一次請求的時候把userinfo讀進緩存,其余時刻都是寫,一個慢線程,5分鐘輪詢寫一遍,某個user更新發給gamedb,由gamedb負責通知其他拷貝同步更新。

            mapserver實際上是一堆服務端的組合總稱,這塊來自云風的構架,分為chatserver(聊天服務端),mapserver(地圖服務端,還可以區分為只帶功能性npc地圖,或者稱為非pk地圖,和其他地圖),guildserver,dropserver。。。每個server都和postoffice連接,并且按功能和gamedb和其他服務端連接,按功能劃分具體的服務端可以很好的把邏輯分散,不會導致某個模塊的bug整個服務端的崩潰,在程序員整體調試水平不高的情況下,大大降低出錯后分析的難度。

            相比較以前來說就是gamedb后移,數據重心放在gamedb上,只讀一次的做法要嚴格保證gamedb的效率和穩定,否則會死的很抽象。

            一些細節mark下來,boost+asio在freebsd上居然不用kqueue用的是select。。。Orz,這是我在一次單步跟一個內存錯誤發現的
             1 //
             2 // kqueue_reactor_fwd.hpp
             3 // ~~~~~~~~~~~~~~~~~~~~~~
             4 //
             5 // Copyright (c) 2003-2008 Christopher M. Kohlhoff (chris at kohlhoff dot com)
             6 // Copyright (c) 2005 Stefan Arentz (stefan at soze dot com)
             7 //
             8 // Distributed under the Boost Software License, Version 1.0. (See accompanying
             9 // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
            10 //
            11 
            12 #ifndef BOOST_ASIO_DETAIL_KQUEUE_REACTOR_FWD_HPP
            13 #define BOOST_ASIO_DETAIL_KQUEUE_REACTOR_FWD_HPP
            14 
            15 #if defined(_MSC_VER) && (_MSC_VER >= 1200)
            16 # pragma once
            17 #endif // defined(_MSC_VER) && (_MSC_VER >= 1200)
            18 
            19 #include <boost/asio/detail/push_options.hpp>
            20 
            21 #if !defined(BOOST_ASIO_DISABLE_KQUEUE)
            22 #if defined(__MACH__) && defined(__APPLE__)
            23 
            24 // Define this to indicate that epoll is supported on the target platform.
            25 #define BOOST_ASIO_HAS_KQUEUE 1
            26 
            27 namespace boost {
            28 namespace asio {
            29 namespace detail {
            30 
            31 template <bool Own_Thread>
            32 class kqueue_reactor;
            33 
            34 // namespace detail
            35 // namespace asio
            36 // namespace boost
            37 
            38 #endif // defined(__MACH__) && defined(__APPLE__)
            39 #endif // !defined(BOOST_ASIO_DISABLE_KQUEUE)
            40 
            41 #include <boost/asio/detail/pop_options.hpp>
            42 
            43 #endif // BOOST_ASIO_DETAIL_KQUEUE_REACTOR_FWD_HPP
            反正我只是不負責任的把22和38行屏蔽掉而已。

            消息隊列只傳遞指針,意思就是某個消息由接收方alloc,然后msgsnd這塊內存的指針,msgrcv收到這個指針,處理完了free掉,而不是整個消息放進去。
            1 struct mymsg {
            2     long int    mtype;       /* message type */
            3     char        mtext[4];    /* message text */
            4 }
            5 
            說實話當初在msgsnd msgrcv上調試了很久
            1 char* packet;// 假設這個packet包括了傳進來的包
            2 mymsg* msg = (mymsg*)mem_alloc(sizeof(mymsg));
            3 memcpy(msg->mtext, &packet, sizeof(char*));
            4 msgsnd(msgid, msg, sizeof(char*),0)
            然后死活提示參數不正確。。。

            逐字逐句讀了man msgsnd數十遍之后發現。。。問題在msg->mtype不能等于0

            ok,公司物理斷網,usb口物理破壞。。。囧。。。當然,我要起帶頭作用,忍。。。
            posted on 2008-04-09 22:42 大日如來 閱讀(2340) 評論(2)  編輯 收藏 引用 所屬分類: 游戲-編程

            FeedBack:
            # re: 搬服務端的體會--接著來。[未登錄]
            2008-04-10 09:33 | cppexplore
            既然是傳遞指針進消息隊列,取端進行free,想必是同一進程間的通訊吧。
            為什么要用ipc的消息隊列呢,很笨重,自己寫線程消息隊列性能更高,簡直不是一個數量級的。  回復  更多評論
              
            # re: 搬服務端的體會--接著來。[未登錄]
            2008-04-10 09:35 | cppexplore
            附一個我實現的線程消息隊列:http://www.shnenglu.com/CppExplore/archive/2008/03/20/44949.html
            消息類型的申請釋放配合小對象內存池,完美的解決方案  回復  更多評論
              

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            常用鏈接

            留言簿(3)

            隨筆分類

            隨筆檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            久久无码人妻一区二区三区午夜| 色综合久久88色综合天天 | 嫩草伊人久久精品少妇AV| 伊人久久大香线焦AV综合影院| 久久综合狠狠综合久久激情 | 国内高清久久久久久| 久久精品无码专区免费青青| 久久人人爽人人爽AV片| 99久久无色码中文字幕 | 国产韩国精品一区二区三区久久| 久久久久亚洲AV无码永不| 久久久久久国产精品免费免费| 久久精品天天中文字幕人妻| 99久久99久久精品国产片果冻| 九九精品久久久久久噜噜| 日韩影院久久| 91精品国产色综久久| 久久久久99精品成人片欧美| 久久天天躁狠狠躁夜夜2020| 国产精品美女久久久久| 久久精品国产精品青草app| 久久精品九九亚洲精品天堂| 亚洲国产成人久久精品99| 亚洲一区精品伊人久久伊人| 国产精品无码久久综合| 老色鬼久久亚洲AV综合| 久久久久精品国产亚洲AV无码| 久久综合久久美利坚合众国| 99久久国产综合精品网成人影院| 久久久久久毛片免费播放| 国产毛片欧美毛片久久久| 狠狠色丁香婷婷久久综合五月| 久久99精品国产99久久6| 亚洲精品国产综合久久一线| 很黄很污的网站久久mimi色| 国产精品久久毛片完整版| 99久久国语露脸精品国产| 久久99精品国产| 精品久久久久久无码免费| 久久丝袜精品中文字幕| 久久婷婷五月综合成人D啪|