2

我有一个[网络方法]。它的作用是在目录中查找 *.dat 文件，其中目录路径由调用 [web 方法] 的客户端提供。

此时客户端调用 [web 方法] 并且代码进入循环检查任何文件。如果找到任何内容，它将返回列表。它显然也可能超时，当它超时时，我的客户端代码会捕获错误并重新调用 [web 方法]。

另一种做事的方法是在客户端上打开一个 TCP 套接字，它将向服务器上的接收套接字服务发送一个“我在这里”。服务器将使用客户端提供给它的标准来查找 *.dats 的存在。如果它找到 1+ 个文件，它将返回一个“1”。如果没有文件，它将返回一个“0”。如果客户端从服务器接收到“1”，那么我的客户端应用程序将调用 [web 方法] 来检索可用列表。

我知道我可以使用 WCF 进行回调，但我想首先明确查看这两个选项。

我也知道 SignalR，但我发现如果我使用的是 Windows 8 之前的操作系统，那么 SignalR 将恢复为长轮询，而不是 Web 套接字。

我可以理解，执行第一种方法会将“重点”放在服务器上，而执行第二种方法将平均分配“压力”，但会涉及重复的 TCP 调用。

我已经完成了测试，两者似乎都有自己的想法。

任何人的任何意见都将不胜感激。

我的目标是速度、低内存消耗、易于代码管理、服务器和客户端之间的松散耦合 - 基本上是显而易见的......

谢谢...

4

1 回答 1

1

如果您正在寻找松散耦合，那么消息队列的一些实现可能会有所帮助。尽管这意味着您需要更改架构的某些部分。

我建议将其更改为“推送”方法而不是轮询。

我的方法是这样的：

  • 任何类型的每个应用程序/服务/客户端都会注册以从您的服务器接收更新。
  • 您的服务可以使用FileSystemWatcher来检查您的文件。让 .NET Framework 完成繁琐的工作，不要手动轮询。:-)
  • 每当新文件到达时，服务都会向所有订阅者发布一条消息。

或者，您可以实现一个消息调度程序服务，该服务负责客户端的消息订阅。这会将订阅管理与您的文件服务分开，这对我来说会更干净。

实施细节可能因您选择的技术而异。

在工作中，我们有与您类似的场景，为此我们使用支持开箱即用的 Microsoft 消息队列 (MSMQ) 的 WCF 服务，并且为了便于使用NServiceBus框架。NServiceBus 使建立这些发布者/接收者场景变得容易设置。

当然还有很多其他的 Message Queue 框架可以使用，这只是我个人取得良好经验的地方。

于 2013-11-05T13:23:49.577 回答