我终于想通了。这是我开始提出此问题后所学到的:
背景:我们正在使用Xamarin / Monotouch和.NET SignalR 2.0.3客户端构建一个iOS应用。我们正在使用默认的SignalR协议-似乎正在使用SSE而不是Web套接字。我不确定Xamarin / Monotouch是否可以使用网络套接字。一切都使用Azure网站托管。
我们需要该应用程序快速重新连接到SignalR服务器,但是我们仍然遇到问题,即连接无法自行重新连接-或重新连接恰好花费了30秒(由于基础协议超时)。
我们最终针对以下三种情况进行了测试:
方案A-首次加载应用程序时连接。从第一天起,它就完美地工作了。即使在3G移动连接上,连接也可以在不到0.25秒的时间内完成。(假设收音机已经打开)
方案B-应用闲置/关闭30秒后重新连接到SignalR服务器。在这种情况下,SignalR客户端最终将自行连接到服务器,而无需进行任何特殊工作-但似乎恰好等待30秒才尝试重新连接。(对于我们的应用来说太慢了)
在这30秒的等待期间,我们尝试调用HubConnection.Start()无效。并调用HubConnection.Stop()也需要30秒。我在SignalR网站上发现了一个相关的错误,该错误似乎已解决,但在v2.0.3中仍然存在相同的问题。
方案C-应用闲置/关闭120秒或更长时间后,重新连接到SignalR服务器。在这种情况下,SignalR传输协议已经超时,因此客户端永远不会自动重新连接。这解释了为什么客户端有时但不总是自己重新连接的原因。好消息是,调用HubConnection.Start()几乎可以像方案A一样立即工作。
因此,我花了一段时间才意识到,根据应用程序关闭30秒与关闭120+秒的不同,重新连接条件有所不同。尽管SignalR跟踪日志阐明了底层协议的功能,但我不相信有一种方法可以处理代码中的传输级别事件。(在方案B中30秒后立即在方案C中触发Closed()事件;在这些重新连接等待期间,State属性显示为“已连接”;没有其他相关事件或方法)
解决方案:
解决方案很明显。我们不等待SignalR做其重新连接魔术。相反,当应用程序被激活或手机的网络连接恢复时,我们只是清除事件并取消引用HubConnection(无法处理它,因为它需要30秒钟,希望垃圾收集可以解决它。 )并创建一个新实例。现在一切正常。由于某些原因,我认为我们应该重用持久连接并重新连接,而不是仅仅创建一个新实例。