在前邊
我提到，針對前面使用boost asio 中遇到的問題，對asio進行封裝，如下幾個目標：
1. 建立socket、acceptor不再自己構造io_service，由於asio中的物件均要儲存io_service的引用，
若要手動構造，必須保證io_service晚於所有的asio物件（如socket、acceptor）釋放，但是往往socket被邏輯層儲存在某個記憶體深處，任意乙個socket晚於 io_service釋放，將會引起崩潰。
2. 編寫分布式程式時，都是採用非同步訊息，但是asio 中對socket進行async_write不能保證執行緒安全，而且我們必須保證在單個socket上傳送資料
必須是順序的。
3. io_service必須繫結執行緒才能執行，而每個asio socket都需要io_service，所以經常要手動為io_service建立執行緒，但是經過測試表明，網路io分配的執行緒配置
2-4個效率最佳，在增加執行緒並不能增大吞吐量，這是由於asio採用全非同步模式。所以我們只需要開啟兩個專門的執行緒給asio的io_service用即可，
省了在關心執行緒的分配。
4. 在編寫分布式程式中，變的往往只是邏輯層，網路框架、訊息協議基本不怎麼變化，所以網路框架必須能夠保證邏輯層的介面足夠靈活。在基於訊息模式
通訊的框架下，每個程式需要單獨定製自己的訊息派發策略。
5. 如果新增加支援的訊息協議，必須保證無需重寫框架，而且保證原來的訊息派發策略仍然有效。
目前ff_lib已經能夠很好的支援以上幾點，當然，訊息解析並沒有來得及優化，目前仍然處於demo版本。
其類關係如圖：
其實現參見：
FF ASIO 非同步訊息網路框架
我提到，針對前面使用boost asio 中遇到的問題，對asio進行封裝，如下幾個目標 1.建立socket acceptor不再自己構造io service，由於asio中的物件均要儲存io service的引用，若要手動構造，必須保證io service晚於所有的asio物件 如socket ...
Spring訊息 非同步訊息
本文選自 spring實戰 第4版 第17章 spring訊息 從在大學課堂接觸c語言開始，我們進行的函式呼叫一般都是同步的，這樣的呼叫機制一般情況下很容易理解，即使像rmi和webservice那樣的遠端呼叫也是同步的。在同步呼叫機制中，當客戶端呼叫遠端方法時，客戶端必須等到遠端方法完成後，才能繼...
同步訊息和非同步訊息
同步訊息和非同步訊息區別 兩者使用場景不一樣，比如說a給b傳送一封電子郵件，a是不需要知道b是否收到就可以了的，把自己的資訊傳達出去，這樣的場景就是非同步訊息。因為在這個過程中a在乎的是把某件事情傳達出去就可以，而不必在乎其他人的狀態，比如張貼告示也是這樣，不需要知道每個人都是否知道這則告示的內容，...