【发布时间】:2014-02-28 11:22:54
【问题描述】:
我了解 SignalR 用于使用注入的动脉脚本与客户端浏览器进行通信。我有一个似乎很常见的问题,即我的浏览器的网络日志中充满了如下所示的条目:
.../arterySignalR/poll?transport=longPolling&connectionToken=...
这告诉我 SignalR 已经退回到长轮询而不是使用 Web 套接字。假设我们有一个支持 Web 套接字的浏览器,并且该浏览器在 localhost 上运行,那么 SignalR 不应该默认使用 Web 套接字吗?什么可能导致它退回到长轮询?
【问题讨论】:
-
这个问题不应该被关闭为“主要基于意见”;问题不是是否 WebSockets 会是一个更好的选择,而是为什么即使浏览器和SignalR 支持它,连接也可能不使用WebSockets;这可以完全根据事实来回答(即使可能需要更多信息)
-
拉斯是对的。以我的经验,浏览器链接确实 使用 WebSockets。我想获得更多信息来帮助确定为什么会发生这种情况。
-
@Dan 你在 Windows 7 上运行 VS 吗? .NET 中的 WebSockets 支持未针对 Windows 7 实现。(不确定问题是否/何时重新打开,所以我现在把它放在这里)
-
@LarsHöppner 感谢您的回复。我们确实都在运行 Windows 7,但是您知道 .NET 是如何不支持它的吗?浏览器支持它,我认为隐藏的浏览器链接 iisexpress(8?) 进程也支持,SignalR 肯定支持。 SignalR 也支持 Windows 7。 .NET 还能如何发挥作用?
-
IIS 本身并没有实现WS,它依赖于System.Net.WebSockets 中的.NET 框架实现;正如您在 MSDN 的链接中所读到的,当您在 Windows 7 上安装 .NET 4.5 时,您根本无法获得必要类的实际实现;所以 SignalR 必须去
if (windows7) { abandonShip(); }然后使用一个后备选项
标签: websocket signalr long-polling browser-link