使用gRPC作爲IoT協議而不是LWM2M/CoAP

我一直在玩弄使用gRPC作'IoT'型設備的想法;不像傳感器那樣受到很多限制;更像是像機器人，無人機等單板計算機內置設備。設備和集中控制器之間需要一個接口，因爲這些設備是由其他公司單獨開發和可能的。所以一個版本化的界面語言是必須的;它不應該只是一個文字文件;可以像頭文件或WSDL或IDL或ProtocolBuffer一樣編程。在設備和控制器之間，應該爲註冊，重新註冊等常見用例指定行爲。這可以在word文件中或在一些非技術文檔中。使用gRPC作爲IoT協議而不是LWM2M/CoAP

協議緩衝區（版本3）中的（rpc）接口規範以及通過gRPC的高效實現使我選擇了CoAP/LWM2M（樂山Java和C++實現）。

既然使用了LWM2M和grPC，我會說gRPC對開發者更友好;與OMA LWM2M進程相比，接口定義和實現速度很快。當然，在gRPC中沒有Observer-Notify，但爲此MQTT就足夠了。

嚴格地說，人們無法將LWM2M與gRPC進行比較。 LWM2M不僅僅是接口，還定義了許多物聯網案例中的行爲，如BootStrap，註冊，KeepAlive，SW升級等，其通用HTTP如GET，PUT在URL類型可尋址資源上使其非常完整。然而，大部分這些行爲可以通過一些努力來定製。

我們計劃編排的一些物聯網項目遠離像燈泡這樣的小設備，更像機器人。有沒有人使用gRPC用於類似的目的。任何成功的失敗故事分享

來源

2017-01-30 Alex Punnen

grpc社區也問過;無法在那裏得到答覆;因此張貼在這裏; https：//groups.google.com/forum/#！topic/grpc-io/H0DBwvUqIDA –

儘管看起來很完整，但我一直隱約關注gRPC，它確實是品牌嶄新的。我在內部對Node.js微服務進行了測試，但我不敢肯定地說這是經過測試和/或生產穩定的。您可能會對所知道的或只是原始原型更安全。除非你樂於參與長時間的遊戲，研發/原型設計和/或堅持可能成爲最好的基礎，而不必擔心大的重寫，因爲隨着時間的推移gRPC變得更加穩定。（也許在一年內它可以被認爲是一個堅實的圖書館） –

我已經採取了冒險，並用它在一個項目中連接'設備';這些小型電腦像Raspberry-pi。總的來說，這是很好的經驗;所使用的語言主要是C++和Java以及Node.js中的JavaScript。我們用它作爲Dockerized微服務;負載平衡是我們沒有做的;我讀到基於HTTP/2的負載平衡是棘手的;將更新該部分;計劃爲此使用Kubernetes。使用版本化界面的整體容器技術 - GRPC似乎非常適合（微）服務

來源

2017-06-01 04:31:58

我在gRPC中爲IoT所錯過的東西是MQTT MQ功能，如消息隊列，代理橋接QoS參數。或者通過SMS傳輸爲CoAP提供帶外消息。在這種情況下，gRPC只是一個RPC框架，它假定始終通過TCP連接。

來源

2017-08-24 18:54:55

使用gRPC作爲IoT協議而不是LWM2M/CoAP

回答

相關問題