通过 JSON RPC 与 SignalR/Node.JS 推送消息

Posted 2023-02-16

【中文标题】通过 JSON RPC 与 SignalR/Node.JS 推送消息

【英文标题】：Push Message through JSON RPC vs SignalR/Node.JS

【发布时间】：2014-03-13 15:09:50

【问题描述】：

我正在为我的 Web 服务使用拉取机制。现在我们要转向推送机制。为此，我知道 SignalR 和 NodeJS。

也有人提到 JSON RPC。我对此知之甚少，搜索谷歌并没有给我结果天气我可以将它用于推送机制。

另外，值得注意的是，我的 Web 服务客户端完全是 javascript 客户端。没有服务器端语言。

谢谢

【参考方案1】：

这取决于您所说的“推送”是什么意思。

我正在为我的 Web 服务使用拉取机制。现在我们想搬家 走向推动机制。我知道 SignalR 和 NodeJS 目的。

对于大多数人来说，“推送”只是意味着使用发布/订阅模型来设置数据在未来某个未知时间从服务器发送到客户端的预先预期。

正如您所说的在浏览器中执行 JavaScript，那么您就会受到该环境产生的所有固有限制。浏览器中异步双向通信的各种实现（例如：WebSockets、WebRTC）甚至一些类似推送的技术（Comet）已经实现。

真正的“推送”依赖于服务器通过网络向客户端发送消息的能力，但效果并不好；客户端大多不允许传入连接，许多客户端在 NAT 之后。

是否有人推动这个议程，可能不了解技术考虑？为什么要“推”？通常这种讨论集中在减少服务器上的资源（例如：打开套接字）。这就是这里发生的事情吗？背景是什么？

---

也有人提到 JSON RPC。我对此知之甚少 并且搜索谷歌并没有给我结果天气我可以使用这个 用于推送机制。

JSON-RPC 协议只是一种通过两个主机之间的双向通信通道发送 JSON 的协议（约定方式）。

JSON-RPC 协议确实描述了“notification”类型的消息，这些消息（理论上）不需要通过“请求-响应”消息进行请求。例如：

客户端可以向服务器发送“通知”消息 服务器可以向客户端发送“通知”消息

（阅读规范，它似乎专注于客户端到服务器的“通知”，但在早期的草稿/讨论中并非如此，JSON-RPC 肯定不是最面向标准的社区 :-)

---

另外，值得注意的是，我的网络服务客户端完全是 JavaScript 客户端。没有服务器端语言。

JSON-RPC 的实现受到其传输 协议的极大限制。 （例如：HTTP）。

当通过普通 HTTP（例如通过XMLHttpRequest）实现时，服务器无法在响应之前的某些请求之外联系客户端——这意味着虽然客户端-服务器“通知”消息是可能的，服务器-客户端“通知”（类似推送）消息不是。

当通过 TCP 套接字（在浏览器中不可用）实现时，服务器绝对有可能向客户端发送“通知”消息（只要套接字是打开的，并且客户端准备异步处理收到的类似 RPC 的请求-响应周期之外的消息）。

---

可能的解决方案：

(1) 如果您通过一些预先存在的基于浏览器的异步双向传输协议（WebSockets、WebRTC）而不是 AJAX 实现 JSON-RPC，那么您可以非常接近正确JSON-RPC 双向“通知”消息。在这两种情况下，都需要一些预先设置，但正如您所说的“推送”，那么无论如何都是预期的（pubsub）。

(2) 另一种方法是让客户端轮询成批的通知（标准请求/响应样式消息），这些通知可能以空数组的形式返回，或者可能是1 个或多个“通知”子消息。

这些基于浏览器的方法都不是真正的“推送”，因为它们不会消除一些底层持续的客户端到服务器到服务器（请求-响应）通信的需要。