（PS開始應用《暗時間》里提到的理論，將skynet用自己的話來總結并寫下來，這樣能充分思考并轉述為自己的記憶線索）
一、skynet設計的理解
（一）單個skynet節點
（1）愿景
充分利用多核。最初想法是多進程。像咱們nodejs里多核就只能是多進程了，因為每個nodejs進程是單線程的。
多進程是遵循unix設計哲學，工具鏈形式，分拆進程的形式來分拆模塊，減少復雜度和耦合性，方便編程及維護。
后來云風他們發現lua做為嵌入式腳本，寫邏輯時很好用的，反正如何都要用lua，而且lua提供了沙盒，這樣多進程可以變為單進程多個沙盒，這樣綜合了多進程和單進程多線程的優勢。多線程里共享資源，在同一進程地址空間，訪問更高效。
（2）核心功能（門房？）
很精簡，僅解決一個問題。
skynet里不實現具體游戲邏輯，后者些放到一個一個動態庫里（so文件）。skynet將這些so注冊到自己里邊，每個so一個永不重復的id，類似于數據庫的autoincreament。看描述這個id是skynet自己運行時當次維護的，而不是模塊配置好終身的id。模塊的永久有效唯一標示為名字，skynet提供了名字服務，可以給每個模塊取一個易讀的名字。
（3）核心不解決什么問題
skynet主張所有服務在同一OS進程協作完成。核心里就沒管跨機通訊，單個服務的崩潰和重啟也沒管，云風表示這些應該由上層處理，他有責任暴露錯誤，而不是隱藏。
這個設計的原因，游戲和操作系統不一樣，操作系統默認不信任任何進程，各進程崩潰什么的不應影響其他進程，所以某個進程掛了，他就安葬它，而其他進程美好的生活。單游戲是為玩家服務的，某個環節出錯都有可能造成玩家利益混亂，所以那里錯了就整個流程（服務器）掛掉吧。沒有必要讓出錯模塊被隔離開，而其他模塊卻繼續提供服務導出未預知行為。
上邊說的東西應該上層考慮，使用lua的沙盒就能做策略隔離。
（4）skynet運行時邏輯流
skynet負責且只負責將一個數據包從一個服務發送到同一進程的另一個服務里。發送服務直接調發送API，skynet收到數據包后，調用接受者服務的注冊的callback，即發給了接受者服務。
skynet保證在各模塊初始化時、每個獨立的callback調用時，都是相互線程安全的。這樣編寫服務的人就不需要考慮多線程的任何問題了，只需專心處理給他的一個個數據包。
PS：天龍的場景lua有點像這里的單個服務。不知天龍的跨線程切場景情況在這里也可以給簡化為單線程？（回頭看源碼再研究這個問題）
（5）消息調度
TODO
（6）gate和connection
TODO
（二）skynet集群
集群里最多支持255個skynet節點，每個skynet節點有一個id，成為harbor id。這個id是集群層面指定，可以人為分配，也可以由一個中央服務器協調分配。
（1）集群間通信
skynet核心層紙負責在往外發消息時在source字段上加上自己的harbor id。而集群間的通信，是由單獨的harbor服務來做的。skynet將是往集群其他節點發的消息，就轉發到harbor內。harbor會跟集群內跟自己結識的skynet的harbor簡歷tcp鏈接。harbor把消息發給目標harbor。
harbor間的通信為單向的tcp管道。
master服務來同步全局的名字服務。每個skynet都會知道其他節點上裝配了哪些服務，好路由過去。
（2）組播
TODO