http://kbengine.org/docs/configuration/entities.html
http://kbengine.org/docs/programming/entitydef.html
疑問：定義Entity的時候
客戶端調了loginGateway以后base服務器就會創建account實體，創建完以后生成一個mailbox，然后調用客戶端的onCreatedProxies方法，通知客戶端創建account的客戶端部分
同時服務器上account.py的onEntitiesEnabled函數也會被調用，表示account的客戶端部分也創建好了，服務器邏輯層可以擼起來了
cellapp與cell關系:
cell是space（一個空間/場景）的一部分或者全部(由動態分割算法決定)。
cellapp是一個進程，所有的space-cell都創建在cellapp進程中
玩家的cell部分指的就是玩家在space-cell中對應的實體。
實體在不同cell中遷移， 有2個原因
第一個，由引擎動態負載均衡導致的遷移。
第二， 玩家移動導致跨越到另一個cell中
http://bbs.chinaunix.net/thread-2030722-1-1.html
服務端：考慮到服務端重啟或多宿，為socket設置SO_REUSEADDR基本成為一個定律 客戶端：客戶端很少有必要bind端口，不bind時內核自動為你分配可用的端口 每個客戶端都對應服務端的一個proxy， 這個proxy在進游戲后由於demo邏輯的做法他是一個account實體， 能讓玩家在客戶端選角色。 當玩家選完角色之后在服務端demo邏輯中會切換與客戶端綁定的proxy，所以在玩家進入場景中時他是avatar。 有一些游戲也不需要按照這個邏輯寫， 例如：登入游戲之后的這個account實體本身就是一個avatar， 不需要選擇角色。 這些概念你需要理解基本之后才能靈活運用。 看看文檔以及demo中的proxy是什么，如何切換控制權給另一個proxy。
self.client這個屬性是一個maibox， 只能通過這個mailbox調用在def中定義的clientMethods方法。
mailbox在底層包含了ip地址與實體的id， 當你調用某個正確的方法后， 底層會將方法參數等信息打包並帶上實體的id，在客戶端根據實體的id調用到某個方法。
Volatile
賬號登錄的時候創建了一個proxy,然后選擇角色進入游戲的時候又創建了一個proxy，不是說一個客戶端就對應一個proxy？
avatar是proxy，服務器跟任何一個客戶端之間同時只能存在一個proxy
當分布式的avatar需要存儲時， baseapp先請求從cellapp獲得數據放入base.cellData， 然后將所有持久化類型屬性數據打包到dbmgr執行寫入
引擎架構設計上baseApp, cellApp的區別 http://bbs.kbengine.org/forum.php?mod=viewthread&tid=69&highlight=baseApp
0基礎學KBEngine基礎學習筆記之一
做了一段時間U3D客戶端，總想着接觸一些服務器知識。於是搜了一下開源服務器框架，准備折騰一下KBEngine。
本人習慣接觸一樣新技術的時候就做一些筆記，很多時候做完就留着當備份，有空拿出來看看。因為寫的爛，再說這些東西你影擼幾遍代碼也肯定搞的定了。
但是這次我決定分享出來貢獻自己的一份力量。因為我發現KBEngine這個服務器引擎一個很糾結的問題。
不同於很多開源項目，KBEngine（以下簡稱KB）並沒有那些 quick start 之類的東西，官網上的很多文檔更類似與參考手冊，這也許讓很多慕名而來的人學個一兩天就望而卻步了。
當然或許從某種程度上說也算是一種考驗，畢竟開源的東西你還要求這要求那也過分了。
廢話不扯。開始正題，本人水平有限，發現問題歡迎各位噴我。
本篇只是開頭，說句實話我目前了解的也不多，頂多能擠多少算多少。不定時更新。
在讀這篇文章之前，請各位自定搭建運行好u3d demo。
了解服務器運行的一些抽象概念
首先了解一個概念，entity（實體），什么是實體，實體就是服務器所有東西的基類。
舉個例子，你玩家登陸后，如果是個RPG游戲，你的新手村是個實體，你周圍的NPC也是一個個實體，然后你自己當然也是個實體等等。
既然是實體，我們就需要交互，在交互之前，我們要了解一下誰負責我們實體數據的生命周期。
我目前淺薄的了解了一下，參考了下面這張圖：
在這上面有很多app進程，loginapp 負責登錄請求的轉發，bassapp 負責實體的 base 部分，cellapp 負責實體的 cell 部分（一般來說就是空間部分的數據）
很明顯我們實體的數據被不同的進程拆分了，舉個例子說，玩家的背包數據是baseapp的 base 部分，在baseapp這個進程上被維護。同理，玩家的空間坐標是cellapp的 cell部分，在cellapp上被維護。
很好, 目前我們大略的講了一下實體的生命維護，那么我們的交互呢？
首先，我們可以看到，一個實體上的數據雖然被拆分了，但是這些數據依舊是一個實體的，只是由不同進程維護（好像是廢話）。
KB給這些被拆分的實體每一個都配了 mailbox 用於和自己實體的其他部分 或者其他實體，或者周圍實體等等進行交互。(也就是所謂數據的作用域)
從某種程度上說隱藏了那些消息拆包，事件分發的機制。但實際上底層還是一樣的。
目前就這些，接下類就是枯燥的通信流程了。