我终于想通了 . 以下是自从开始这个问题以来我学到的东西：

Background: 我们're building an iOS app using Xamarin / Monotouch and the .NET SignalR 2.0.3 client. We'使用默认的SignalR协议 - 它似乎使用SSE而不是Web套接字 . 我可以使用带有Xamarin / Monotouch的网络套接字 . 一切都使用Azure网站托管 .

我们需要应用程序快速重新连接到我们的SignalR服务器，但是我们一直遇到连接没有自行重新连接的问题 - 或者重新连接花费了30秒(由于底层协议超时) .

我们最终测试了三种情况：

Scenario A - connecting the first time the app was loaded. 从第一天开始就完美无瑕 . 即使通过3G移动连接，连接也可在不到0.25秒的时间内完成 . (假设收音机已经开启)

Scenario B - reconnecting to the SignalR server after the app was idle/closed for 30 seconds. 在这种情况下，SignalR客户端最终将自行重新连接到服务器而无需任何特殊工作 - 但它似乎在尝试重新连接之前等待了30秒 . (我们的应用程序太慢了)

在这30秒的等待期间，我们尝试调用无效的HubConnection.Start() . 并且调用HubConnection.Stop()也需要30秒 . 我找到a related bug on the SignalR site that appears to be resolved，但我们在v2.0.3中仍然遇到同样的问题 .

Scenario C - reconnecting to the SignalR server after the app was idle/closed for 120 seconds or longer. 在这种情况下，SignalR传输协议已经超时，因此客户端永远不会自动重新连接 . 这解释了为什么客户有时但并不总是自己重新连接 . 好消息是，调用HubConnection.Start()几乎可以像方案A一样工作 .

因此我花了一段时间才意识到重新连接条件因应用程序是否关闭30秒而不是120秒而有所不同 . 虽然SignalR跟踪日志说明了底层协议正在发生的事情，但我认为没有办法处理代码中的传输级事件 . (Closed()事件在方案B中30秒后触发，在方案C中立即触发; State属性在这些重新连接等待期间显示“已连接”;没有其他相关事件或方法)

Solution: 解决方案很明显 . 我们're not waiting for SignalR to do its reconnection magic. Instead, when the app is activated or when the phone'的网络连接已恢复，我们're simply cleaning up the events and de-referencing the HubConnection (can' t处理它，因为它需要30秒，希望垃圾收集将处理它)并创建一个新实例 . 现在一切都很好 . 出于某种原因，我认为我们应该重用持久连接并重新连接，而不是仅仅创建一个新实例 .