C# 从windows服务接收通知

我内置了C#，由两部分组成的软件：一部分是Windows服务，可以做一些事情，另一部分是托盘应用程序，可以向服务发送命令，但也可以接收来自服务的消息，并通知用户

对于这种通信，我在windows服务中创建了一个WCF服务器（名为dpipes），然后托盘应用程序连接并“订阅”以接收消息

为了使托盘应用程序接收来自服务的通知，它们之间的连接是一个

双工通道

。在双工通道中，客户机调用服务器，服务器可以在客户机上执行方法

但现在我明白了

双工频道

并不是真的那样（我指的是从客户端长时间监听）：默认情况下，它在一段时间不活动后关闭，在我设置生产模式后，它在长时间后关闭，或者可能在睡眠模式下关闭，等等。我放弃了解决它带来的问题（也许我错了）

问题是： 什么是正确的-从windows服务向同一台PC中的客户端软件发送消息的最佳方式，a.长时间（只要计算机正在运行）B.以允许多个客户端的方式（因为托盘应用程序启动多次，每个用户一次）。

您也可以使用。但WCF是一条路要走。不要被这个复杂的概念吓跑了，WCF会帮你完成繁重的工作。 最大的挑战是配置，但归根结底，WCF只是另一个通信通道。我推荐这个

我认为使用WCF可以开发Websocket服务

此外，您还可以使用轮询技术，在这种技术中，客户端经常向服务器询问（调用）任何新闻（轮询）。长轮询和短轮询都可能有用

在服务器上开发tcp lisenter，在客户端开发tcp客户端

---

你应该使用WCF，它会帮你处理那些讨厌的东西。您只需进行配置，这只是另一个通信通道，而不是使用HTTP。

IMO使用WCF时，这是一件非常讨厌的事情，尽管我已经多次遇到这个问题。就我个人而言，我通常更喜欢在ProtoBuf的类似场景中使用TCP套接字来执行（反）序列化。对于一些客户机的简单场景来说，这很好，但是对于很多客户机，情况会变得非常糟糕

有一个很好的例子

在复杂的场景中，您可能希望自动处理许多不同的问题，如重新连接、轮询、池等。此外，如果您在UI中使用WPF，则所有事情都需要异步进行，并且您必须在正确的线程中处理事件，这是一个很难正确处理的问题。。。如果你有这样的场景，我会认真考虑。

< P>系统托盘APP（A）服务（B）都需要充当客户端和服务器，在每一方使用两个服务。 你可以这样做。 A连接到B并通过注册ip或soemthing这样的方式将其标记为expect A通知 B当需要通知时，连接到所有已注册的A应用程序服务

---

当应用程序服务方法执行时，您可以显示通知

在类似的场景中，有一个服务生成并控制多个子进程，

NamedPipeClientStream/NamedPipeServerStream

来自

System.IO.Pipes

的组合非常适合我。

您看过SignalR吗？这取决于你问谁。Microsoft正在推动WCF成为您在上面描述的场景中进程间通信的标准。然而，还有许多其他的可能性。发布/发送Windows消息、命名管道、套接字、内存映射文件等。您能否缩小空闲问题的范围？周期性的“脉搏”能“维持”你的联系吗？