通過JSON RPC推送消息vs SignalR/Node.JS

Question

我正在爲我的Web服務使用pull機制。現在我們要走向推動機制。我知道爲此目的的SignalR和NodeJS。

有人還提到了JSON RPC。我對這方面的知識知之甚少，搜索谷歌並沒有讓我知道結果天氣，我可以使用這種推送機制。

此外，值得注意的是，我的網絡服務客戶端完全是JavaScript客戶端。沒有服務器端語言。

謝謝

Answer 1

這取決於你的意思是「推」。

我爲我的web服務使用了pull機制。現在我們想把 移向推送機制。我意識到SignalR和NodeJS對於這個 的目的。

對大多數人來說，「推」只是意味着一個發佈/訂閱模式來建立數據提前預期到從服務器在未來的某個未知時間（s）發送到客戶端。

正如你所說你正在瀏覽器中使用JavaScript，那麼你就有所有這些環境產生的固有限制。瀏覽器中異步雙向通信的各種實現（例如：WebSockets,WebRTC）甚至一些類似推式技術（Comet）已經實現。

真正的「推送」依賴於服務器通過網絡向客戶端發送消息的能力，這種方式效果不佳;客戶端大多不允許傳入連接，許多客戶端在NAT後面。

有沒有人推動這個議程，也許不瞭解技術上的考慮？爲什麼「推」？通常這種討論圍繞着減少服務器上的資源（例如：打開套接字）。這是怎麼回事？背景是什麼？

---

有人還提到JSON RPC。我對它的知識很少 和搜索谷歌沒有讓我的結果天氣我可以使用這個推動機制這個 。

JSON-RPC協議只是通過兩臺主機間的雙向通信通道發送JSON協議（約定的方式）。

JSON-RPC協議確實描述「notification」類型的消息，它們（理論上）不需要通過「請求 - 響應」消息傳遞請求。即G：

• 客戶端可以發送「通知」消息給服務器
• 服務器可以發送「通知」消息給客戶端

（讀取規格，似乎集中在客戶端到服務器的「通知」，但在早期草稿/討論，這是情況並非如此，JSON-RPC肯定不是最標準的面向社區在那裏:-)

---

另外，值得注意的是，我的網絡服務客戶端完全是 JavaScript客戶端。沒有服務器端語言。

JSON-RPC的實現受到它們的傳輸協議的約束。 （例如：HTTP）。

當通過普通的HTTP實現時（例如通過XMLHttpRequest），服務器無法在一些事先請求的響應之外與客戶端聯繫 - 這意味着雖然客戶端服務器「通知」消息是可能的，但服務器客戶端「通知」（推送式）消息不是。當通過TCP套接字實現（在瀏覽器中不可用）時，服務器絕對有可能向客戶端發送「通知」消息（只要套接字是打開的，並且客戶端準備異步處理收到類似RPC的請求 - 響應週期外的消息）。

---

可能的解決方案：

（1）如果實現JSON-RPC通過一些預先存在的基於瀏覽器的同步雙向傳輸協議（的WebSockets，的WebRTC），而不是AJAX，那麼你可以非常接近正確的JSON-RPC雙向「通知」消息。在這兩種情況下，都需要進行一些高級設置，但正如你所說的「推」，那麼無論如何也是這樣（pubsub）。

（2）另一種方法是讓客戶端輪詢批量通知（標準請求/響應樣式消息），這可能會返回爲空數組，或者可能是1個或更多個「通知「子消息。

這兩種基於瀏覽器的方法都不是真正的「推送」，因爲它們不會消除對服務器到服務器（請求 - 響應）通信的某些基礎正在進行的客戶端的需求。