Question

当使用Server-Sent Events时，客户端应建立多个连接以接收它感兴趣的不同事件，或者是否应该有单个连接并且客户端通过单独的通道指示它感兴趣的内容？ IMO后者似乎更为可取，尽管有些人可能会使客户端代码更复杂。规范支持命名事件（与特定主题相关的事件），对我来说，建议将Server-Sent Events连接用作所有事件的单个通道。

以下代码说明了启动多个服务器发送事件连接的第一个方案：

var EventSource eventSource1 = new EventSource("events/topic1");
eventSource1.addEventListener('topic1', topic1Listener, false);

var EventSource eventSource2 = new EventSource("events/topic2");
eventSource2.addEventListener('topic2', topic2Listener, false);

eventSource1将收到“topic1”事件，eventSource2将收到“topic2”事件。虽然这很简单，但对于您感兴趣的每个主题都会出现挂起的GET，效率也非常低。

替代方案如下：

var EventSource eventSource3 = new EventSource("/events?id=1234")
eventSource3.addEventListener('topic3', topic3Listener, false);
eventSource3.addEventListener('topic4', topic4Listener, false);

var subscription = new XMLHttpRequest();
subscription.open("PUT", "/events/topic3?id=1234", true);
subscription.send();

在此示例中，将存在单个EventSource，并且特定事件的兴趣将由具有服务器发送事件连接的单独请求指定，并且注册由id参数关联。 topic3Listener将收到“topic3”事件，而topic4Listener则不会。虽然需要稍多的代码，但好处是只建立了一个连接，但事件仍然可以被识别和处理不同。

网上有很多示例显示命名事件的使用，但似乎事先知道事件名称（或主题），因此客户端无需注册服务器的兴趣（{{ 3}}）。虽然我还没有看到显示多个EventSource对象的示例，但我还没有看到一个示例显示客户端使用单独的请求来注册对特定主题的兴趣，正如我上面所做的那样。我对规范的解释使我相信，表明对某个主题（或事件名称）的兴趣完全取决于开发人员，并且可以通过客户知道它将要接收的事件的名称来静态地完成它。动态地与客户端警告服务器它有兴趣接收特定事件。

我很想听听别人对这个话题的看法。注意：我通常是Java开发人员，请原谅我平庸的JS代码.. :)

Answer 1

我强烈建议，恕我直言，每个SSE提供服务有一个EventSource对象，然后使用不同类型发出消息。

但最终，它取决于消息类型的相似程度。例如，如果您有5种与用户相关的不同类型的消息，请让用户EventSource并区分事件类型。

如果您有一个关于用户的事件类型和另一个关于三明治的事件类型，我会说将它们保存在不同的服务中，从而EventSource s。

考虑以与宁静服务相同的方式分解EventSources是个好主意。如果你不使用AJAX从同一个服务中获得两件事，你可能不应该从同一个EventSource获取它们。

Answer 2

为了回应模糊和宽松的浏览器标准解释*，浏览器供应商对允许单个域/端口的持久连接数量的限制不一致。由于异步上下文的每个事件接收器在接收器打开时假定单个持久连接分配，因此必须严格限制EventSource侦听器的数量，以避免超出变化的，特定于供应商的限制。实际上，这限制了每个应用程序大约6个EventSource / async上下文对。降级是优雅的（例如，额外的EventSource连接请求只会等到一个插槽可用），但请记住，必须有可用于检索页面资源，响应XHR等的连接。

* W3C已经发布了包含语言的持久连接的标准“......应该限制同时连接的数量......”这种语言意味着标准不是强制性的，因此供应商合规性是可变的。 http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.4

每个应用程序应该只有一个EventSource对象吗？

2 个答案: