How to communicate between service controller and a service/daemon?

Question

It is easy to display the status of a Windows service or to control it (start/stop) from a GUI application but the question if how about receiving/sending notifications from the service? Like: service telling to the user monitoring it that it needs attention.

Please consider that you can have several controllers started at any time in a multi-user environment.

Do you know an example(open source) for this kind of communication?

Extra points for a platform independent solution :)

Answer 1

If the "user" monitoring the service is a person, how about writing to an event log and then having your enterprise event monitoring system send alerts. Alternatively, have the service log the issue to the event log and then send an email.

If the "user" or client of the service is a separate or multiple applications here are a couple thoughts without fully understadning your problem.

1. Write to file. Have the client tell the service what file or some agreed token to create a file for that particular client instance and then have the service write to the file. The client can then monitor the file.
2. Status Ping. Have the client ping the service on a regular basis in a background thread to ask the service how it is doing. If unhealthy, then the client could ping the service for more information. Kind of like getting the LastMessage.
3. Open Sockets or End Point. Find a way to setup communication back from the service so that the service can call the client. This may be initiated by the client first telling the service where it is so it can call back. I forget the specifics, but WCF should be able to handle this out of the box for you. If you want something more generic you may need to roll your own.

Hope these ideas help.

Answer 2

As an option, use MsgConnect to send messages between services and controllers (crossplatform and open-source where applicable). Communication between services and controllers is possible both locally (via MMF or socket transport) and remotely (via socket transport).