整體構架：
janus_transport_sup（實質為transport， supervisor， client instance supervisor）：每個tcp會話建立乙個transport程序來處理對應客戶端的請求。
janus_topman_sup（實質為topman， worker， topic manager）：通過topman（gen_server）模組建立多個pubsup模組（gen_server）程序來管理主題。
janus_sup（實質為janus_acceptor，worker，tcp server）：接收tcp請求並處理。
以上的架構僅是初步的模組劃分，接下來我會講到對於tcp網路請求更為詳細和精華的部分。如有錯誤或不足，請一定要拍我，謝謝！
啟動流程：
1.gen_accept()產生socket；
2.gen_tcp:controlling_process()將上述socket的通訊分配到新生成的transport程序去處理；
值得說的是：在janus_acceptor的gen_tcp:listen()的前後使用了proc_lib:start_link()和proc_lib:init_ack()配對處理來確保程序建立的原子性。
proc_lib:start_link()和proc_lib:init_ack()之間通過訊息傳遞機制實現了乙個小型的程序建立或相關處理的原子操作，在大家最為熟悉的gen_server, gen_fsm, gen_event中都應用了這種處理方式。說到erlang的標準庫，我個人有一些在標準庫函式的改進和擴充，接下來有時間的話我會寫乙個系列部落格，講述如何自學erlang以及使用一些好的erlang**風格去編寫更好的產品級**。
接下來在hotwheels中其它的一些模組：
flashbot.erl & barrier.erl & bot.erl & histo.erl & launcher.erl：資料統計，計算latence等。
bin.erl：利用了re模組對二進位制進行正規表示式計算（類似與perl的正則匹配規則）。
common.erl：提供了乙個產生隨機token的函式。
util.erl：對程序進行管理。
手機上的訊息推送的解決方案目前有以下幾種常用的方式：
1.定期查詢：按照指定的時間間隔連線伺服器查詢獲取最新的訊息。實現起來簡單，非實時，查詢時間過短則流量耗費多，耗電量大。
2.長輪詢（android適用）：基本上與目前很多**使用的方式一樣（web阿里旺旺、微博、人人等等）。客戶端發起乙個很長超時時間的請求，然後伺服器端在沒有訊息的時候阻塞這個請求（一直不給返回值）直到快要超時為止，有訊息到來再返回響應。客戶端收到響應或超時後立即再發起請求。
這種算是比較好的方式了，訊息能夠及時地到達客戶端。但考慮到移動網際網路的特點（網路不穩定、裝置記憶體小）這種方式不能保證重要的訊息一定能推送到客戶端，另外anroid在手機記憶體小的情況下可能會殺這個在等待push訊息不怎麼活動的程序。
5.mqtt：基於**發布/訂閱 模式的訊息傳輸協議，據說很適合無線手機應用，有時間就去看看，也有erlang的開源專案，可惜只到了0.1.0版本。。。
好想回去做c++。。。
spring security認證原始碼剖析
spring security 和shiro目前最主流的安全框架，很好的保護了系統的安全性。shiro實現的原理和spring security具有異曲同工之妙，學會乙個框架，另乙個框架也會很容易上手。1 spring security流程 usernamepasswordauthenticatio...
ReentrantLock獨佔鎖原始碼剖析
在開始分析reentrantlock 獨佔鎖之前，我們先來簡單了解幾個概念 悲觀鎖指對資料被外界修改持保守態度，認為資料很容易就會被其他執行緒修改，所以在資料被處理前先對資料進行加鎖，並在整個資料處理過程中，使資料處於鎖定狀態。例如synchronized。樂觀鎖是相對悲觀鎖來說對，它認為資料在一般...
locust對應原始碼HttpUser剖析（7）
老規矩，先貼 self.client session比較簡單，無非就是繼承了user的各個屬性，這裡把類變數client清空了，不再是noclientwarningraiser 了。其他都是繼續沿用，只是例項化的時候client變成了session。這個時候第乙個關注點就是，例項化的時候一定要有ho...