长轮询是否为每个请求创建新的SignalR集线器？

Question

从关于SignalR的教程中，我了解到集线器类的工作方式类似于ASP WebForms页面。在每个请求上创建一个新的集线器，处理请求，发送一个响应，然后销毁。然而，我不太清楚我是否正确地理解它如何与个别运输技术一起工作。如果我错了，请纠正我，但我假设如下：

由于WebSockets创建了一个双工通道，该连接将被持久化，直到客户端断开连接(或者连接因不同原因中断)，并且集线器的单个实例为发出初始请求的客户端提供服务。

但是，在长轮询中，一旦服务器发送响应，集线器实例就会被销毁。然后，SignalR客户端自动创建另一个请求(轮询的性质)。但是，此请求在服务器上创建了一个全新的集线器实例，这与为第一个请求提供服务的集线器对象完全不同。然后，第二个集线器实例处理请求，发送响应并销毁。然后，客户端发送第三个请求，整个过程再次启动。

我是对的还是错的？我在网上找不到答案。

Answer 1

集线器不是根据每个连接创建的，而是根据客户端到服务器的相关请求创建的(我没有讨论在服务器端直接创建的hub上下文)。您关于WebSocket的声明“Hub服务于发出初始请求的客户端的单个实例”是错误的。当您在客户端上启动连接并进程成功时，将创建一个集线器来触发OnConnected事件，然后删除它。当客户端调用服务器端方法时，再次创建一个新集线器，然后对每个调用删除。无论您使用什么传输，包括WebSocket，这都是正确的。集线器是为满足物理连接本身而创建的而不是，所以长时间轮询不是一个问题，因为它与WebSocket没有什么不同。每个WebSocket连接或长轮询HTTP请求并不意味着创建持久集线器。集线器是在每个逻辑连接(*)和每个方法调用上创建的瞬态实例。每次在集线器上触发连接事件或调用方法时，都会有一个新的实例应答，不管使用的传输是什么。

这可能是最好的文档，但是一旦您开始区分逻辑级别(SignalR事件和方法调用)和物理级别(HTTP请求或WebSocket，它们不一定与逻辑级别相关)，那么它就应该更加清晰。

您也可以通过添加以下内容来验证它：

private readonly Guid _id = Guid.NewGuid();

对于集线器，您将看到任何OnConnected事件以及随后的任何方法调用都有不同的值，无论您选择何种传输，因此证明连接和集线器之间从来没有1到1的关系(这并不意味着在可能的情况下，底层的物理连接不会被保留，比如使用WebSocket)。

(*)这里有一些微妙之处，使这一说法并非总是正确的，但它们与运输策略无关，因此我将略过它们。