0

I am looking for advice on the best approach for doing inter-process communication.

The solution consists of 3 projects.

  1. GUI: This will only display messages to the user and get user input

  2. Windows Service: Communicates with the UI and runs the 3rd module using elevated credentials

  3. Worker: Internal DLL that will perform the actual work

I need a way to make the worker communicate with the GUI directly to send and receive updates.

I have two ways in mind to do it (will be happy to see more suggestions):

  1. Use two named pipes. One for the GUI<>Service communication. And the other for GUI<>Worker communication

  2. Raise an event from Worker to Service. And use WCF callback from service to UI

What will be the best way to implement the communication?

NOTE: The problem here is the GUI<>Worker communication. Not the UI<>Service communication.

mymo
  • 239
  • 2
  • 11
  • Search `windows ui service interprocess communication` and decide from there. Your question is quite broad. Please see http://stackoverflow.com/help for how to ask good questions. – Kory Gill Jan 28 '16 at 07:13
  • Possible duplicate of [How to communicate with a windows service?](http://stackoverflow.com/questions/4451216/how-to-communicate-with-a-windows-service) – Kory Gill Jan 28 '16 at 07:14
  • The problem is not with the communication between the windows service and the UI. The problem is how to communicate between the "worker" , which is separate from the windows service, and the UI . – mymo Jan 28 '16 at 07:28

1 Answers1

0

1) WCF is officially recommended way to implement interprocess communication (tcp or named pipes are fastest), it replaces remoting (but always use serialization/deserialization). In advanced scenarios communication can be implemented using

  • Memory mapped files;
  • Service Bus. (Service Bus allows to create loosely coupled components/communication. Google for nservicebus, rabbitmq, masstransit etc);
  • Something like Web Sockets or SignalR (consider using this if you have browser/javascript client/GUI).

2) If your Worker is just library (.net assembly) - it will work within Service process. In this case you dont need to invent something to pass data/events from Worker to GUI, all communication (duplex, I suppose, with subscribing to service events) will be perfomed between GUI and Service (Service only delegate some work to Worker via regular .net calls)

3) Sometimes we need something like dispatcher between services, client and server. You can find some information here.

SalientBrain
  • 2,431
  • 16
  • 18