C# 什么是最好的？在套接字上轮询还是等待web服务超时？

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

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

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

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

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

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

我做过测试，两人似乎都有自己的想法

任何人的任何意见都将受到感激

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

---

谢谢…

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

我建议将其改为“推送”方式，而不是投票

我的做法是：

• 任何类型的每个应用程序/服务/客户端都注册以接收来自服务器的更新
• 您的服务可以使用来检查您的文件。让.NET Framework来做脏活，不要手动轮询。：-）
• 每当新文件到达时，服务将向所有订阅者发布一条消息

或者，您可以实现一个消息分派器服务，负责客户端的消息订阅。这将使订阅管理与您的文件服务分离，这对我来说会更干净

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

在工作中，我们有类似于您的场景，为此我们使用WCF服务，这些服务支持Microsoft Message Queue（MSMQ）开箱即用，并支持框架的易用性。NServiceBus使建立这些发布者/接收者场景变得容易

---

当然，还有很多其他消息队列框架可供使用，这正是我个人获得良好体验的地方。

很有趣。我试图避免使用WCF，只是因为涉及到管道。此外，如果我使用传统的web服务进行更改，那么就很简单了。我发现我有更多的工作要做使用WCF（包括安装和摆弄端绑定）。使用WCF并没有让我烦恼，只是我喜欢XCopy解决方案。我确实通过消息队列使用调度服务，该消息队列处理从客户端到服务器的更新（作业竞争）响应。我的客户端调用[web方法]，该方法会添加到消息队列中。我最初确实使用了文件监视程序，但如果服务器端的服务器套接字代码连接中断，我的客户端将永远不会知道。通过不断地将“我在这里”客户端发送到服务器，并将“是的，我知道”发送回服务器，我可以恢复断开的连接。我只是想知道它是否提供了我的[Web方法]代码及其超时没有提供的任何内容。谢谢你的链接，顺便说一句，我们现在将查看它：）