我還記得一開始在做混音案子，或者自己在做音樂的時候，總是花了非常久的時間，一方面那時候沒有現在厲害，一方面我花了很多時間在整理專案。

創建群組、創建資料夾、變更音軌的顏色，一次又一次重複做著，我感覺我很多的時間都花費在不是真正混音的事情上面。

我一直在想有沒有什麼方法，可以每次打開Cubase就把預先設置好的專案檔叫出來，然後直接開始混音。

直到，我發現了模板這個功能。

我相信如果你有在關注我的部落格就會看過，我曾經寫過一篇文章關於如何創建模板這個議題，如何有效的讓你的混音加速至少半小時～一小時的時間，讓你擺脫雜事，專注在最重要的事情上面。

事半功倍，是我混音能那麼快速的原因。
或許你也可以看看我那篇文章，花上一個多小時創建一下自己的模板。

或者，我把我的模板變成一個新的商品給你，讓你不需要這麼麻煩。你可以用我預設好的音軌、Routing、顏色資料夾分類、甚至我連EQ與Compressor都幫你裝好了。

當然，很遺憾的我是使用Cubase，如果有用別的DAW的朋友就暫時還沒辦法使用了。

如果你好奇我怎麼使用我的模板，來混音、編曲，你可以點下方的連結。特惠早鳥價只到7月底唷。

期待見到你，感謝你的支持。
https://ourdaysrecords.com/class/shop/shawns-cubase-template/

📜 [專欄新文章] libp2p — 模組化的點對點網路協議
✍️ Ken Lin
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

libp2p — 模組化的點對點網路協議

可重用的輪子

『不要重複造輪子』，是在軟體開發時，經常被引用的一句話。

這句話隱含的意義是，盡可能的去重用（reuse）其他人分享的開發成果，因為很多的經驗及知識，就是在這樣的重用過程中，逐漸的被累積及驗證。而許多被廣泛重用的輪子，往往就這樣成為某個特殊領域中共用的基石，進而加速了其他專案開發時的迭代過程。

本次CrossLink Taipei 2019的研討會中，也出現了一個這樣的輪子，那就是libp2p專案。

分佈式應用的共業

傳統的中心化網路架構當中，每一個參與的節點，其Server與Client的角色是確立的，因此封包在路由傳遞時也相對單純，對於開發者而言，大家也都非常熟稔這樣的架構。

而在分佈式的網路架構當中，每一個節點都同時肩負了Server與Client的角色(或者換一個說法，不再有Server-Client的區別)，再加上各種異質的網路環境與網路通訊協議，開發者往往要耗費許多資源來解決這些網路底層的通訊問題，例如NAT穿透、加密傳輸等等。

如果這些難題，一再的困擾著不同的開發者，那麼有沒有一種可能，可以把這些難題所需要的解決方案集合在一起，方便大家去重複使用並改進？libp2p的出現，便是這個問題的答案。藉由高度模組化的設計，開發者可以方便的取用自己所需要的部分模組，並在現有的模組上疊加自己額外的應用邏輯，以適應各種不同的應用場景。

由於其高度模組化的特性，使得libp2p受到許多知名專案的青睞，紛紛使用了libp2p作為其底層網路框架，例如Ethereum 2.0、Palkadot、Filecoin、0X等等。

libp2p原先是IPFS專案中的網路框架，後來抽出變成一個獨立的專案。

libp2p的特色

以下所提到的各種libp2p特色，很多都以模組的形式被實作，開發者可選擇適合的模組，進而開發出符合其應用場景的服務。

具有兼容性的定址方式

libp2p使用了類似檔案路徑的概念(PLAN9 Ubiquitous Filesystem)，為每一個行程(process)定義了專屬的位址。這種定址方式，可以增加行程定址的兼容性，假設某個行程改用了新的網路傳輸協議(例如從ipv4改為bluetooth)，可以很方便的以相同的定址結構去表達新的位址。

以目前常見的ipv4位址為例，假設某個節點是以ip 1.2.3.4以及port 80提供了服務，在libp2p中其位址可表示為/ip4/1.2.3.4/tcp/80。

支援多種傳輸協議

針對目前常見的傳輸協議，libp2p也實作了相對應的模組，例如：TCP、QUIC、WebSockets、WebRTC。在未來，libp2p預計還會支援Bluetooth、uTP、UDP，或者目前尚未發明的新協議(歸功其兼容性的定址方式)。

可升級的傳輸協議

在libp2p的設計當中，一個行程與另一個行程建立連線時，首先會以某個底層協議作為原始連線(raw connection，例如TCP協議)。一旦原始連線建立完畢，兩個行程可以進一步依據他們的需求進行協調，決定是否將原始協議升級(upgrade)為另一個協議連線(capable connection)，例如將單純的TCP協議升級為具有加密性質的連線。

多路複用

有時候在兩個節點之間建立一個連線，需要不少的成本(像是需要穿透NAT、經過多次的交握確認後才能建立連線)，如果能夠重複使用已經成功建立的連線，兩個節點之間就能以更有效率的方式實現異質的資料傳輸。舉例來說，兩個節點可以在同一個TCP連線上，進一步的產生不同的串流(stream)。

協議協調

由於libp2p支援多種傳輸協議，並且能夠多路複用，兩個節點在互相傳輸資料之前，便需要有一套機制去互相溝通，確定兩者要以哪種協議進行資料的傳輸，這便是協議協調。

目前的協議協調機制是multiselect 1.0，libp2p接下來會將協議協調機制升級為更有效率的multiselect 2.0。

節點發現與訊息傳播

在建立分佈式應用的時候，如何有效率的尋找節點(節點發現)是建立一切服務的起點，能夠找到節點，才能進一步和節點建立連線，接著才能建構其上的應用。libp2p提供了數種節點發現的實作(DHT、Randezvous、mDNS等等)。

除了節點發現，如何進行訊息傳播也是建立一個分佈式應用必須考慮的事情。在這邊要特別提起PubSub這個訊息傳播模式。這是一種類似MQTT的發布-訂閱(Publish-Subscribe)模式，允許訊息以M-to-N的方式在網路中傳遞，這種傳播模式是非同步(asynchronous)。和MQTT不同的是，libp2p是分散式的，並不需要一個中心化的broker來負責訊息的路由(routing)。

目前PubSub提供數種訊息路由演算法，包括floodsub、gossipsub等等。在Ethereum 2.0也將會採用PubSub作為其訊息傳播模式。

NAT穿透及中繼

現今的網路架構中，NAT無所不在，而這也是點對點連線時最大的困擾。libp2p實作了NAT穿透，而對於那些無法進行NAT穿透的節點，libp2p另外提供了中繼技術(relay)來作為補強方案。

結語及後記

以上所描述的libp2p特色，是在參與CrossLink Taipei 2019研討會時，印象較為深刻的幾點，尚有其他特色沒有節錄於本文之中。除此之外，各項特色的描述多半以重點式的形式紀錄，很多細節仍有待深入挖掘。

在撰寫本文時，筆者參考了許多前人的貢獻，其中有不少是來自於CrossLink Taipei 2019 的線上共筆，謝謝這些參與共筆的志工。除此之外，也要特別感謝Taipei Ethereum Meetup的朋友Kevin，提供了不少寶貴的建議以及實作經驗。

參考資料

https://segmentfault.com/a/1190000015410582

https://zhuanlan.zhihu.com/p/33535984

https://ethfans.org/posts/why-libp2p

https://medium.com/r/?url=https%3A%2F%2Fgithub.com%2Fmultiformats%2Fmultiaddr

libp2p — 模組化的點對點網路協議 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌