重新连接SignalR 2.0 .NET客户机到服务器中心最佳实践 [英] Best practice for reconnecting SignalR 2.0 .NET client to server hub

问题描述

我在移动应用程序中使用SignalR 2.0与.NET客户端，所以我需要处理各种类型的断开。有时SignalR客户端重新连接没有我的帮助 - 有时候我有（）再次调用HubConnection.Start重新连接。 （因为SignalR神奇地自动重新连接在某些时候，我想知道如果我失去了一个功能或配置设置）

I'm using SignalR 2.0 with the .NET client in a mobile application so I need to handle various types of disconnects. Sometimes the SignalR client reconnects without my help - and sometimes I have to reconnect by calling HubConnection.Start() again. (since SignalR magically auto-reconnects some of the time, I'm wondering if I'm missing a feature or config setting)

什么是设置的最佳方式客户端将自动重新连接？我见过处理（）关闭事件，然后一个正秒钟后连接javascript例子。有什么建议的方法？

What's the best way to set up a client that reconnects automatically? I've seen javascript examples that handle the Closed() event and then Connect after a n-seconds. Is there any recommended approach?

我读过的文档约SignalR连接的寿命几篇文章，但我仍然对如何处理客户端重新连接不清楚。

I've read the documentation and several articles about the lifetime of SignalR connections, but I'm still unclear on how to handle the client reconnect.

感谢您！

推荐答案

我终于想通了这一点。这里是开始，因为这个问题，我学​​到的东西：

I finally figured this out. Here's what I've learned since starting this question:

背景：：我们正在建设使用Xamarin / MonoTouch的和.NET iOS应用SignalR 2.0.3客户端。我们使用的是默认SignalR协议 - 它似乎是使用SSE，而不是网络插座。我不知道但如果有可能使用网络插座与Xamarin / MonoTouch的。一切都在使用Azure的网站主办。

Background: We're building an iOS app using Xamarin / Monotouch and the .NET SignalR 2.0.3 client. We're using the default SignalR protocols - and it seems to be using SSE instead of web sockets. I'm not sure yet if it's possible to use web sockets with Xamarin / Monotouch. Everything is hosted using Azure websites.

我们所需要的应用程序来迅速重新连接到我们的服务器SignalR，但我们一直有问题，其中连接并没有对自己的重新连接 - 或重新连接了准确30秒（由于底层协议超时）

We needed the app to reconnect to our SignalR server quickly, but we kept having problems where the connection didn't reconnect on its own - or the reconnect took exactly 30 seconds (due to an underlying protocol timeout).

有分别，我们结束了测试三种情形：

There were three scenarios we ended up testing for:

< STRONG>方案A - 连接第一次应用程序被加载这从一开始就完美无缺。连接在不到0.25秒甚至超过3G移动连接完成。 （假设无线功能已经打开）

Scenario A - connecting the first time the app was loaded. This worked flawlessly from day one. The connection completes in less than .25 seconds even over 3G mobile connections. (assuming the radio is already on)

方案B - 重新连接到SignalR服务器应用程序是空闲/关闭30秒后在这种情况下，SignalR客户将最终重新连接到其自身的服务器，而无需任何特殊的工作 - 但似乎尝试重新连接之前要等待整30秒。 （对于我们的应用程序太慢）

Scenario B - reconnecting to the SignalR server after the app was idle/closed for 30 seconds. In this scenario, the SignalR client will eventually reconnect to the server on its own without any special work - but it seems to wait exactly 30 seconds before attempting to reconnect. (way too slow for our app)

在这30第二等待期间，我们打过电话HubConnection.Start（），它没有效果。并调用HubConnection.Stop（）也需要30秒。我发现在出现需要解决中的SignalR网站相关的错误，但我们仍然有同样的问题在V2.0.3

During this 30 second waiting period, we tried calling HubConnection.Start() which had no effect. And calling HubConnection.Stop() also takes 30 seconds. I found a related bug on the SignalR site that appears to be resolved, but we're still having the same problem in v2.0.3.

C方案 - 重新连接到服务器SignalR应用程序是空闲/关闭120秒或更长的时间后在此。情况下，SignalR传输协议已经超时，所以客户端不会自动重新连接。这就解释了为什么在客户有时但不总是对自己重新连接。好消息是，呼吁HubConnection.Start（）的作品几乎立即像一个情况

Scenario C - reconnecting to the SignalR server after the app was idle/closed for 120 seconds or longer. In this scenario, the SignalR transport protocol has already timed out so the client never automatically reconnects. This explains why the client was sometimes but not always reconnecting on its own. The good news is, calling HubConnection.Start() works almost instantly like scenario A.

所以我花了一段时间才能认识到，根据是否重新连接条件是不同的该应用程序被关闭30秒VS 120+秒。而虽然SignalR跟踪日志照亮这是怎么回事的底层协议，我不相信有一种方法来处理代码中的传输级别的事件。 （闭合（）在方案B 30秒后​​，立即在方案C后，事件触发;国家财产说已连接在这些重新连接等待时间;没有其他的相关事件或方法）

So it took me a while to realize that the reconnect conditions were different based on whether the app was closed for 30 seconds vs 120+ seconds. And although the SignalR tracing logs illuminate what's going on with the underlying protocol, I don't believe there's a way to handle the transport level events in code. (the Closed() event fires after 30 seconds in scenario B, instantly in scenario C; the State property says "Connected" during these reconnect waiting periods; no other relevant events or methods)

解决方案：
的解决方案是显而易见的。我们不是等待SignalR尽其重新连接的魔力。相反，当应用程序被激活或恢复手机的网络连接时，我们只是清理事件和去引用HubConnection（因为它需要30秒不能处理它，希望垃圾收集将照顾它）并创建一个新的实例。现在一切是伟大的工作。出于某种原因，我认为我们应该重用一个持久连接，而是重新连接刚刚创建一个新的实例。

Solution: The solution is obvious. We're not waiting for SignalR to do its reconnection magic. Instead, when the app is activated or when the phone's network connection is restored, we're simply cleaning up the events and de-referencing the HubConnection (can't dispose it because it takes 30 seconds, hopefully garbage collection will take care of it) and creating a new instance. Now everything is working great. For some reason, I thought we should be reusing a persisted connection and reconnecting instead of just creating a new instance.

这篇关于重新连接SignalR 2.0 .NET客户机到服务器中心最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！