使用 SignalR 与 WCF 将数据推送到客户端？答案

【问题标题】：Push data to client using SignalR vs WCF?使用 SignalR 与 WCF 将数据推送到客户端？
【发布时间】：2013-02-22 10:18:46
【问题描述】：

我有一个 WPF 客户端-服务器应用程序。现在我有这样的场景，比如客户端将连接到服务器，服务器会定期向客户端推送数据。我对我应该选择什么技术和方式来通知客户有点困惑。

SignalR 最适合我认为的 Web 应用程序，而且我有桌面应用程序。使用 WCF 服务，我们可以通过双工通道和回调实现推送通知。那么您能指导我使用 SignalR 或 WCF 服务的优缺点吗？

谢谢

【问题讨论】：

标签： wcf push-notification signalr

【解决方案1】：

SignalR 不仅仅与网络有关。 SignalR 服务器端代码不关心其客户端的技术，您只需要在客户端有实现者即可。

如果我们将推送数据隔离到客户端，我强烈推荐 SignalR，因为它在这方面比 WCF 简单得多，我对 WCF 有一些问题，我猜你自己也有一些问题。我找到了一个简单的控制台/Web 应用程序示例here。

一般来说，双工 WCF 和使用像 here 这样的回调对我来说似乎很混乱，服务器端有很多配置，这就是我认为 SignalR 更简单的原因。

此外，您不能将 duplex (AFAIK) 与 javascript 和 Objective-c 一起使用。

【讨论】：

您能否详细说明为什么 SignalR 比 WCF 更简单？
我已经编辑了答案，但本质上我发现 WCF 配置非常混乱，而 SignalR 是一个非常优雅的解决方案，但也许这只是一个品味问题。我很确定，如果您希望添加 Web 客户端或任何其他客户端，SignalR 将在未来为您提供更大的灵活性。
我也想检查性能，仅出于编码目的我们不能选择 SignalR。我有桌面应用程序，将来不会有任何 Web 应用程序。我认为 SignalR 也只能在 Http 协议上运行，SignalR 支持 Net TCP 吗？
SignalR 的主要兴趣点是它的轻便性和连接到许多不同客户端的能力。好像你没有这个要求，WCF 可能会让你更轻松地进行 winform/wpf 开发。
@UpendraChaudhari 我也面临着类似的问题。我认为我们可以将 WebSockets 与 SignalR 一起使用，以在标头大小等方面获得一些性能提升。我认为使用 Net TCP 性能可以更接近 WCF。你有什么想法？

【解决方案2】：

以下是我的经验观察：

SignalR 专业人士：

易于启动，学习曲线较低。您可以轻松运行从网络上找到的示例
异常处理（例如连接断开、超时）嵌入在 API 中

SignalR 缺点：

仅支持 HTTP 协议

双工专业人士：

除了 HTTP 之外还支持 TCP。如果您知道您的客户端类型并且您的系统在封闭网络中工作，这可能会大大提高性能。此外，通过 TCP 工作比 HTTP 增加了更多的连接稳定性

双工缺点：

更高的学习曲线 - 更难启动并且有一个稳定的解决方案。想要验证吗？从网上下载双工和 SignalR 示例，看看您将花费多少时间来成功运行彼此。
您需要处理所有异常情况（连接断开、超时等）
我知道当您想长时间使用双工服务时，我不是唯一一个面临严重超时问题的人。我们需要定期进行服务调用以保持客户端连接处于活动状态。

顺便说一句，JavaScript、桌面和 Silverlight 项目都有 API 来使用 SignalR 服务。

【讨论】：

感谢您的回复。正如我在之前的一个项目中所做的那样，我已经了解 WCF 双工通信。所以从发展的角度来看，对我来说并不难。我只想知道性能方面的知识。当应用程序需要在短时间内推送大量数据或长时间空闲时出现任何超时问题时，WCF 是否会产生任何问题？
我还没有对我的双工服务进行任何性能测试。但是对于超时问题，正如我在回复中提到的，我们在开发过程中遇到了一些不确定的超时问题。由于我们找不到记录在案的解决方案和完整的工作示例，因此我们决定手动向我们的双工服务发出定期心跳请求以使其保持活动状态（=防止连接超时）。
SignalR 支持 WebSockets（用于 IIS 8），在大多数情况下，它实际上比普通 TCP 更好，因为它更擅长通过防火墙。
关于 Aron 评论的补充说明：您需要注意您的客户资料。并非所有浏览器都支持 websocket。
@Hasan signalR 仍然不支持 TCP？

【解决方案3】：

到目前为止没有人提出的一点：

SignalR 1.0.1 在服务器和客户端上需要 .NET 4。根据您所针对的客户端和服务器的版本可能是一个需要考虑的重要因素。

如果您只想定期更新新数据，最好只使用 WCF 和客户端的轮询机制，而不是使用双工 WCF 或信号器。

【讨论】：

如果我们采用轮询机制，那么甚至不需要 WCF 服务。但是在轮询中，如果轮询时间较长，获取数据会有延迟，我们无法设置较小的轮询时间并在客户端更新 UI。同样对于轮询，我们需要跟踪更新数据，不能在每次轮询时加载所有数据。

【解决方案4】：

我认为您已经获得了关于它们每个的大量数据点。但与开发工作相比，选择 SignalR 将为您提供更多优势，在大多数情况下，开发工作是选择技术时的主要决策障碍。

您无需担心 API 开发/测试等，可以专注于您自己的项目实施。

希望对你有帮助！

【讨论】：

【解决方案5】：

SignalR 现在可以轻松地与来自 javascript、.NET 和 WinForms 和 WPF 的多个客户端一起使用，甚至可以与 C++ 客户端一起使用；使用自托管的 .NET 信号器服务器 (OWIN) 是拥有一个向多个客户端推送/接收/广播的独立服务器的好方法。唯一可能更容易的是 ZeroMQ 使用其发布订阅方法。

【讨论】：