WinForms的服务器和客户端之间的通信

Question

我有50多台自助服务终端型计算机，我希望能够从一台计算机上按需获取状态更新，而不是间隔。这些计算机在请求状态的计算机上位于LAN上。

我研究了WCF但是看起来我需要安装IIS而我宁愿不在50多个Windows XP机箱上安装IIS - 所以我认为除非可以让WinForm主机成为web服务，否则不使用web服务？

我也研究过使用System.Net.Sockets甚至得到了一个功能不多的原型，但我觉得我不够熟练，无法使它成为一个可靠而可靠的系统。鉴于此路径，我需要了解有关套接字编程和线程的更多信息。

这些框运行的是.NET 3.5 SP1，因此我在.NET版本中具有完全的灵活性，但是我想坚持使用C＃。

实现此目的的最佳方法是什么？我应该咬紧牙关并更多地学习套接字，还是.NET有更好的方法来处理它？<​​/ p>

编辑： 我打算进行双向沟通，直到我意识到我所需要的只是一种单向沟通。

编辑2： 我正在避开传统的服务器/客户端并使用逆向运行，因为我想避免消耗过多的带宽，并且不确定我在说什么样的开销。我也希望能够更好地控制个人信息亭。看了之后，我想我仍然可以使用WCF并通过IP连接（我不知道我可以通过IP连接，我以为我必须添加50个web服务或其他东西）。

Answer 1

WCF不必托管在IIS中，它可以作为控制台应用程序或Windows服务托管在Winform中。 您可以让每台计算机在winform中托管其服务，并在您自己的计算机中编写程序以调用每台计算机的服务以获取状态信息。

另一种方法是在您自己的计算机中托管一项服务，并在其状态更新后让50多台计算机调用该服务，您可以使用数据库来保存每个节点的状态数据在网络内。此选项更易于维护和扩展。

P.S。 WCF旨在取代.net远程处理，替代方案可以是net.tcp binding或net.pipe

Answer 2

除非你有计划将其扩展到数千个客户，否则我认为WCF性能甚至不会成为一个边缘问题。您可以轻松地从Windows服务或Winforms应用程序托管WCF服务，一旦获得关键概念，您就会发现使用WCF的工作非常简单。

我已经为大约100-150个客户部署了类似的东西并取得了巨大的成功。

网上有大量资源可以帮助您入门 - 这是一个让您前进的资源：

http://msdn.microsoft.com/en-us/library/aa480190.aspx

Answer 3

无论是在中央服务器上使用Web服务还是WCF，您只需要在服务器上安装和配置IIS（而不是在50多个客户端上）。

你要做的是从问题中有点不清楚，但是如果客户端需要调用服务器（例如获取服务器状态），那么他们只需要在运行的webservice上调用一个方法服务器

如果您需要让服务器不时调用客户端，那么每次客户端启动时，您都需要让每个客户端在服务器webservice上调用登录方法。登录方法将客户端的委托方法作为参数。然后，当服务器需要来自客户端的信息时，服务器将调用该委托。

使用自己的Web服务设置每个客户端将代表传统（一个服务器，多个客户端）客户端/服务器体系结构的反转，正如您已经注意到的那样，这将是不切实际的。

Answer 4

不要使用远程处理。

如果你想要健壮性和可扩展性，你最终会排除一切，除了基本上无状态的远程过程调用。由于这正是Web服务的功能，并且Web服务更简单，更容易构建，因此远程处理技术本质上是毫无意义的。

具有远程代理的回调在性能/可靠性禁止列表中，因此如果您考虑使用远程处理，请再想一想。

使用网络服务。

我知道你不想参加投票，但我认为你不需要投票。既然你说你的所有单元都在一个网段上，那么我建议UDP用于广播变更通知，主要是设置一个脏标志，并允许应用程序按需（重新）获取。它仍然不可靠，但它很容易，也很快，因为它是广播。

正如其他人所说，你不需要IIS，你可以自我托管。有关如何执行此操作的详细信息，请参阅ServiceHost class。

Answer 5

我建议使用.NET Remoting。它很容易实现，不需要任何其他内容。

Answer 6

对我来说，学习网络或者套接字通信的手动方式更好..网络服务速度慢，因为它包含元数据..

您的客户端和服务器可以转换为多线程应用程序。只是模仿请求和响应架构。实现像这样的网络应用程序非常容易..

Answer 7

如果您只需要状态更新，则可以使用更简单的解决方案，例如简单的tcp服务器/客户端消息传递或类似orrsella所说的远程处理。 WCF在这里有点矫枉过正。

但需要注意的是，如果您的所有50多个信息亭都通过互联网连接，那么您可能需要使用VPN或在每个信息亭上都有一个开放端口（这是一个安全风险），以便您的服务器可以从每个信息亭检索状态更新

我们有一个类似的情况，但状态会定期发送到我们的服务器，因此我们只有1个端口来保护/保护。更新频率可配置为容纳较慢的客户端。

Answer 8

作为与超过500多个客户实施此类目标并且不断增长的人：

消息排队是可行的方法。

我们已从内部开发的TCP服务器和客户端转到WCF轮询，最终得到消息排队。这是通过互联网从客户端和服务器获取数据的唯一保证方式。作为奖励，许多这些解决方案都有一个广泛的框架，使得实现发布 - 订阅，发送 - 单向，点对点发送，请求 - 回复变得微不足道。其中一些是可能的WCF，但它将涉及哭泣，喊叫，呜咽和长夜，更不用说加仑咖啡。

一些重要的评论：

让一个进程轮询客户端而不是相反的方式=糟糕的想法..它根本不可扩展，你很快就会遇到麻烦，因为这个过程需要很长时间才能完成..更不用说拥有了处理所有的IP地址（你有权访问所需的端口上的所有客户端吗？当ip改变等时会有什么好处。）

我们做了什么：客户端定期将状态更新发送到中央消息队列（您可以在UI中轻松实现实时更新），它还会在其自己的队列中侦听GetStatusRequest消息。如果它收到这个，它会回答（有一个超时）..这样，我们可以随时查看所有客户的总体状态，并在需要时获得特定客户的特定状态。

关于带宽：自助服务终端通常显示图像/视频等.1Kb或更少的状态消息不会是很大的开销。

我不能强调你所呈现的当前设计将具有非常密集的开发周期并且不会扩展或扩展（相信我，我们已经学到了这一课）。接下来，为这类东西构建一个好的客户端/服务器协议是一项艰巨的工作，如果你犯了设计错误（迁移协议并不容易），那么之后就完全没用了。

我们在ActiveMQ上构建了我们的解决方案（使用NMS库c＃），目前正在为我们的内部工作扩展简单服务总线。

我们只使用WCF进行winforms app和集中服务之间的通信