receive notification from windows-service

user_1271037 0
Viewed 2918

I've built in C#, two-part software: one is a Windows-service that does some things, and the other is a Tray-Application to send commands to service but also receive messages from the service and notify the user.

For this communication, I made a WCF server (NamedPipes) in the windows-service, and the Tray-Application then connects and "subscribes" to receive messages.

In order for the Tray-Application to receive a notification from the service, the connection between them is a DuplexChannel. in DuplexChanel the client calls the server, and the server can execute a method on the client.

But now I understand that DuplexChannel is not really for that (i mean long listening from the client): by default, it is closed after a period of inactivity, and after I've set up a production mode, it closed after a long time or maybe sleep mode and so on. I gave up trying to solve the problems it creates (maybe I'm wrong).

the question:

What is the right - best way to send a message from the windows-service to a client(s) software in the same PC, A. Over long time (as long as the computer is running) B. In a way that allows multiple clients (because the Tray-Application is launched several times, once per user).

ipc windows-services wcf c#
6 Answers

You could also use MSMQ. But WCF is the way to go. Don't get scared away by the somewhat complicated concept, WCF will take care of the heavy lifting for you. The biggest challenge is the configuration, but at the end of the day WCF is just another communication channel. I recommend this and this tutorial.

user_82919490
  1. I think using WCF you can develop a Websocket serice
  2. also you can use polling technique in which clients frequently ask(call) server for any news(polling).both long-polling and short-polling may be usefull
  3. developing a tcp lisenter on server and tcp clients on client side
user_31687410

IMO this is a real nasty thing to do with WCF, even though I've encountered this issue several times. Personally I usually prefer to use TCP sockets for similar scenario's with ProtoBuf to do the (de)serialization. That will work fine for simple scenario's with a few clients, but with lots of clients, things will become pretty grim pretty fast.

https://csharphardcoreprogramming.wordpress.com/2014/01/31/protocol-buffers-part-3-advanced-tcp-networking/ has a decent example.

In complex scenario's, you probably want something that automatically handles a lot of different issues like reconnects, polling, pooling, etc. Also, if you use WPF for the UI, everything needs to be happening async and you have to handle events in the correct thread, which is a pain to get correctly... If you have such a scenario, I'd seriously consider going for https://www.asp.net/signalr .

user_10315910

you should use WCF,It will take care of the nasty bits for you. You have to do configuration only,it's simply another communication channel, instead of using HTTP.go through msdn

user_22990470

System Tray app(A) service(B) both need to act as client and server using two services in each side you can do something like this. A connect to B and mark its expect a notification by registering ip or soemthing like that B when need to notify it connect to all registered A apps services when A app service method execute you can show notifications

user_26635210

In a similar scenario where there was a service spawning and controlling multiple child processes a combination of NamedPipeClientStream/NamedPipeServerStream from System.IO.Pipes worked perfectly for me.

user_16542330
Related