问题标签 [signalr-backplane]

我希望用户在重新连接到 Signalr 服务器时检索他们可能错过的消息。

我知道我可以独立于 Signalr 保留消息，跟踪客户端中收到的最后一条消息 id 并在重新连接时重新发送较新的消息，但我正在查看 SqlServer 背板的 Messages_0 表，它有一个 Payload 和 PayloadID 并且想知道是否有是让背板为我执行此操作或扩展背板为我执行此操作的更信号方式。

你知道我该怎么做吗？

我们正在开发一个系统，该系统使用 SignalR 推送一些业务重要指标的频繁更新。我们将有中等数量的连接客户端，从 50 个到 1000 个不等，每个客户端都需要一个唯一的有效负载。

根据 Damian Edwards 的演讲，我们的负载配置文件与特定服务器横向扩展模式最匹配，在这种模式下，我们基本上分配客户端连接到拓扑中的特定 SignalR 服务器，而不是使用背板。

关于其工作原理的粗略伪代码是客户端在我们的负载平衡 API URL 上执行 GET，无论哪个服务器被击中，都会使用其 URL 进行响应，然后客户端将 SignalR 客户端库配置为使用该 URL 进行连接。

这看起来可以很好地在本地运行，但现在我们也在计划 Azure 部署。如果没有此要求，Azure 网站非常适合。但是，这种模式要求我们能够可靠地识别 Web 站点中的各个实例，而我们看不到这样做的方法。

这只是破坏了 Azure 网站提供的抽象吗？我们是否必须使用 VM 或 Web 角色来为每个 SignalR 实例获取可靠、一致的 IP 或可寻址 URL？或者人们是否有另一种方式将具有特定服务器的 SignalR 部署到 Azure。

我正在努力让 Microsoft Orleans “Grains” 将事件放到 SignalR 总线上。有一个示例项目可以做到这一点，我已经链接到下面的 SignalR 集成。

在我看来，此示例使用来自 Azure Web 和 Worker 角色的元数据来枚举所有 Web 角色，并向每个角色显式发布消息。在我看来，如果 SignalR 的背板在 azure web 角色上正确配置，这不应该是必要的——一个 HubConnection/HubProxy 应该这样做。那正确吗？

事实上，当我仔细查看下面链接的文件并看到集线器本身的一些奇怪逻辑时，我想知道该示例是否起到了基本背板的作用。

我希望有更深入 SignalR 经验的人可以为我澄清这一点。

SignalR 集成示例：https ://orleans.codeplex.com/SourceControl/latest#src/samples/GPSTracker/GPSTracker.GrainImplementation/PushNotifierGrain.cs

我们使用 Azure 服务总线主题作为 signalR 的背板，并且我们至少有 2 个 Web 实例。我们想使用 SignalR 向特定用户发送通知。我们在 Web 实例上使用“context.Clients.User”方法。

如果用户连接到此 Web 实例并通过身份验证，他/她会收到通知。

问题是：如果用户在其他 Web 实例上进行了身份验证，这不起作用。

我们如何在另一个 Web 实例上向用户发送通知？

我们正在使用 Autofac.SignalR 和 SignalR.ServiceBus

国际奥委会配置：

contex ExchangeRate 的用法是从 Hub 派生的类：

目前我们正在使用 Windows 服务中自托管的 SignalR（也使用 SSL）。这用于将不同类型的更新推送到客户端（ASP MVC 应用程序）。这一切都很好。

然而，我们现在正在寻找提供高可用性解决方案的选项。由于 windows signalr 服务目前是单点故障，因此被认为是一个弱点。

我一直在查看 signalr 提供的横向扩展选项，但我找不到很多关于此的信息（结合自托管）。目前我有以下问题： - 是否可以在自托管 SignalR 服务中使用这些横向扩展选项？- 如果没有，我们还有其他选择吗？

是否可以使用 Javascript 客户端连接到多个SignalR服务器？

例如：

第二次尝试连接（再次）给我一个错误：

我可以创建两个实例$.connection吗？显然，我认为修改相同connection会产生很多问题。

SignalR 文档说，在服务器广播类型的负载/实现的情况下，横向扩展/背板工作得很好。但是，我怀疑在纯服务器广播的情况下，它会导致向客户端发送重复的消息。考虑以下场景：

1. 我有两个集线器实例，位于我的网络场的负载均衡器后面的两台网络服务器上。
2. 每个服务器上的集线器实现了一个用于数据库轮询的计时器，以获取一些更新并以组的形式广播给客户端，按主题 id 分组。
3. 组/主题的客户端可能在两个服务器之间划分。
4. 两个中心实例都将从数据库中获取相同或重叠的更新。
5. 现在，当每个集线器通过背板向客户端发送更新时，会不会导致向客户端发送重复更新？

请建议。

我目前在 Azure 上托管我的 redis 缓存服务器，并让 signalR 依赖它作为使用以下内容的主干......

GlobalHost.DependencyResolver.UseRedis("Server",port,"password","eventKey");

这可以在端口 6379（非 SSL）上找到，但是当我尝试连接到 Azure Redis 服务器的 SSL 端口（6380）时，我的聊天应用程序中断，并且集线器从未启动。这个问题的原因可能是什么？还是我做错了什么？

这是我的浏览器 net::ERR_CONNECTION_RESET 中 /signalr/connect 上出现的错误

我们在服务器场上为 Intranet（500 名员工）托管不同的 MVC5 Web 应用程序。我们希望将 signalR 2.2 与 SQL Server 服务代理背板一起使用，主要用于服务器广播。我们希望为不同的应用程序使用相同的背板数据库，所有应用程序都可以访问背板数据库服务器。

问题：1-在性能方面是否要避免，我没有看到任何好的实践指导，它似乎在技术上有效。2-如果将消息广播到 application1 客户端，它是否也会发送到 Application2 的客户端？3-为每个应用程序使用单独的背板 DB 有什么好处？

现在我使用服务总线主题作为信号器的背板。但是事件中心比主题便宜得多。因此，我想使用事件中心作为 SignalR 的背板。我现在可以这样做还是在附近功能中可以这样做？