花了一段時間吧nanomsg的源碼給編譯了一遍，同時對裏面的主要的協議進行了調試。
由於該項目是c寫的，發現可讀性太差了，調試了很多遍仍然模模糊糊的。再加上該項目中的代碼量也不低，所以這個練習是我吸收的最差的一個。 決定不能再在上面耗着了，將目前能夠理解的，結合網友的經驗帖進行記錄一下。
注意，這裏的傳輸協議不是規範的叫法，也並非tcp/ip協議的那個傳輸層協議，而是屬於應用層的一種協議。我爲了方便記憶就暫稱之爲傳輸協議。
通信協議，我這裏指的是 通信雙方的行爲表現。
1.通信協議之bus總線通信：
1.1圖解：
1.2實現：
1.3註釋：
綁定在某一個地址(總線,bus)上的節點，可以收到其它所有連接在該總線的節點發送的信息；同時，它發送的信息也可以被所有的其它節點接收到。
只是連接在某一個地址上的兩個節點或者多個節點，彼此的消息是不可達的。 即上圖中的虛線部分是不可達的。
它內部的實現通過priolist提供消息通信的實現；
2.通信協議之pipeline單向管道推送協議：
2.1圖解：
2.2實現：
2.3註釋:
它是基於socket實現的，但是不必像socket那樣，服務端綁定後，客戶端連接。
可以客戶端先連接，然後服務端再綁定。 它是通過 狀態機+定時器+線程池事件機制自動完成的這個步驟；
內部是通過：lb負載+priolist實現；
3.通信協議之pair端對端通信模型：
3.1圖解：
3.2註釋:
它跟 socket很像，socket也是端對端的通信。但是針對同一個地址，可以有多個連接進行連接。
pair端對端通信協議，限定了一個地址的兩端，只能爲1對1的關係。
其內部是通過exel + pipe的方式完成；
4.通信協議之pub/sub消息廣播模式:
4.1圖解：
4.2實現：
4.3註釋:
它與pipeline通信模型有些相似，最大的不同在於，它是 單生產者單消費者的。
它是基於 list,priolist實現；
5.通信模型之req/rep請求響應模型：
5.1圖解：
略，與pipeline差不多，不過它有操作時序的要求。
5.2實現：
5.3註釋:
與服務器容器很像。 客戶端發起請求，服務端返回響應。
服務端不可能事先給客戶端發送響應。
6.通信協議之surveyor/respondent調查者模式：
6.1圖解：
6.2實現:
6.3註釋：
它剛好與 請求響應模式有一點對立的意思； 它的首次發送信息必須由 服務端發起；
傳輸協議我在這裏的理解是 數據所在的目的位置，或者數據傳輸的途徑。
7.傳輸協議之inproc進程間數據傳輸：
7.1實現：
在windows中，它是通過共享內存完成的。 該內存封裝在 ctx上下文中，在傳輸的過程中從上下文中拷貝至目標內存進行實現。
在linux中，系統提供該協議的支持。
8.傳輸協議之ipc線程間數據傳輸：
8.1實現：
在windows中，通過WriteFile(), ReadFile()的方式，完成數據的傳輸；
在linux中，系統提供支持；
9.傳輸協議之tcp基於ip的傳輸協議：
9.1實現：
通過套接字api實現通信過程；
10.傳輸協議之ws傳輸協議：
10.1實現:
通過socket套接字api實現通信；
由瀏覽器提供支持的socket；它能引導一個http協議升級成 websocket協議，俺認爲這是它與socket最大的不同。
總結：
由於使用的是c語言，這對我調式和理解代碼增加相當的難度，尤其是多個的結構體的使用，使我理解起來造成了極大困難；
這次練習的本意的是熟悉消息隊列，但是沒有達到效果。
很多東西用面向對象的思維，其實更容易理解。 不過據說nanomsg使用c實現使得它的效率提高了，相較於zeromq有了一些優化。
協議，虛擬機 本質上 就是個 狀態機。
資源：