#純靠北工程師5cy
----------
小弟公司做iot的,從設備端到資料倉儲中心到手機remote app到串ERP都有做,最近公司遇到奇葩客戶,對方自己養了一個「寫了十年web的工程師」,然後叫我們做設備跟app就好,中間的溝通server該工程師堅持要自己寫,且業主要求在一季內完成所有項目,開會跟對方解釋如果對方工程師要從頭開始寫起要處理一大堆兩邊對接的問題等等各種雞毛蒜皮的事,建議用本公司既有的系統下去改商業邏輯的部分就好,結果對方工程師不斷跳針:「啊不就是mqtt跟http兩邊資料互傳就好,就是用api資料丟來丟去而已嘛,雖然我沒寫過但我不覺得這很難啊,只要知道api要傳哪些資料我也可以啦」各種貶低iot這行的言論,
當場我就想走人跟老闆說這案不要接,他說他行那讓他自己上......
同樣是碼農,隔行如隔山啊,有必要這樣把人家的工作講的一文不值嗎?
何況我還沒講到可能還會碰到要處理跟某些設備互傳udp封包指令的事,從頭到尾我看這傢伙只懂http跟websocket,只有一季時間要從零做到完到底自信哪來的,真的好想叫老闆放生這公司讓他們自己踩雷後再來求人......
----------
💖 純靠北官方 Discord 歡迎在這找到你的同溫層!
👉 https://discord.gg/tPhnrs2
----------
💖 全平台留言、文章詳細內容
👉 https://init.engineer/cards/show/6946
mqtt server 在 開開大叔 Facebook 的最讚貼文
MQTT BROKER
#nodemcu-32s #mqtt #publish #subscribe #button #wifi #web #server
mqtt server 在 Taipei Ethereum Meetup Facebook 的最佳貼文
📜 [專欄新文章] 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.
👏 歡迎轉載分享鼓掌
mqtt server 在 Installing Mosquitto Server (MQTT) on Raspberry Pi 3 - YouTube 的美食出口停車場
... <看更多>