您將如何使用 Node.js 將“消息”推送到設備？

Question

現在這是一個非常奇怪的問題，我在互聯網上找不到答案。 以下是我計划構建項目的方式： Controller App --> Node.js Server (probably Express) --> Some IoT Device Running Node.js Who Knows Where

所以本質上，控制器應用程序想要控制物聯網設備，但它可以在任何地方。 因此，它與位於靜態 IP 上的服務器通信，該服務器將跟蹤此 IoT 設備的位置（可能位於任何網絡/IP/端口上）。 所以控制器應用程序會向服務器發送請求，服務器會告訴這個物聯網設備它在哪里做某事。

問題是，這個 Node.js 服務器如何知道設備在哪里？

建議的解決方案 A：我想到的一種方法是擁有一個服務器，並在服務器和 IoT 設備之間共享一個秘密字符串。 服務器將有一些物聯網設備可以“訂閱”的“端點（？）”。

建議的解決方案 B：物聯網設備形成 WebSocket 或 Sockets.io 連接。 雖然這可能是一個更好、更簡單的解決方案，但是當您添加許多設備時，服務器在與多個設備進行實時通信時會占用更多資源嗎？

所以是的，一個非常奇怪的問題，因為在這里，它實際上是來自 Node.js -> Node.js 的推送通知，而不是每個其他搜索結果的內容，對於 Node.js -> 一些通知服務，如 iOS 或 Google 或Web 服務工作者。

謝謝！

Answer 1

“推送”選項一般如下：

1. 客戶端每隔一段時間輪詢一次端點以檢查是否有新內容。 不是真正的推動，但實施起來非常簡單。 使用此實現的可行性取決於您需要推送的“實時”程度。

2. 客戶端創建並維護與服務器的持續連接，然后服務器可以隨時通過該連接發送數據。 這將是 webSocket 或 socket.io 選項，或者在某些情況下 SSE（服務器發送的事件）是連續 http 的一個版本。 客戶端將需要能夠檢測連接何時斷開並根據需要重新建立連接。 顯然，服務器需要能夠處理來自您支持的每個設備的同時連接（但主要是空閑連接）。 如果流量較低，自定義服務器配置可以支持數十萬個連接。 典型的共享托管解決方案在這方面受到更多限制，因為它們不允許您訪問整個服務器的資源。

3. 服務器使用一些內置於客戶端的現有“推送服務”。 這適用於將推送服務作為平台一部分的 iOS 或 Android 設備。 不適用於自定義 IoT 設備。

4. 第三方推送服務或庫。 谷歌有Firebase Cloud Messaging ，聲稱可以與物聯網設備一起使用，但我主要只是尋找物聯網設備發起事件的例子，然后將該事件推送到更經典的設備（手機、瀏覽器等...），不是從 node.js 服務器到 IoT 設備。