花了一段時間吧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有了一些優化。
協定，虛拟機 本質上 就是個 狀态機。
資源：
nanomsg的位址;