C#/.NET: Reporting subprocess state to the parent service

Question

I currently have a service running several subprocesses (with System.Diagnostics.Process ). Each subprocess can run for hours and be in a specific, predefined state (think "starting", "working", "cleaning up", etc - completely predefined, no custom data attached to each state has to be reported). Each process cannot be an individual Windows service (there are more possible states than Windows service states). I need to somehow report this state to the parent service. All processes are running on the same Windows machine.

I need to be able to both query subprocess states from other processes (not the ones started by the service), and update the parent service about each subprocess states from those subprocesses. Each process gets a unique ID, so other processes can read the states easily without having to manage processes themselves. All processes share a configuration file in which each subprocess gets assigned a unique ID to identify itself with. I've thought about doing it like so:

• Redirect subprocesses' standard output to the service ( RedirectStandardOutput = true ), read each line in the output and catch "special" lines ( STATECHANGE:state )
• Write out all subprocesses' states to a file in a predefined location whenever that state changes, delete that file on service exit.

It looks like I'm trying to find a solution to a problem which was solved ages ago and I haven't found that solution. Is there any "nice" way to do such state reporting?

Answer 1

In general, you're delving into the realm of interprocess communications, or IPC.

Though you haven't tagged this question as being specific to Microsoft Windows, it is tagged as C# and .NET, so it's probably that you are running in a Windows environment. My answer assumes you're running this system in a MS Windows.

A common solution to a problem such as this is store state in database. Each service/process could write to the database independently, and then it could be queried by any process that was interested in that information. But this isn't real two-way communication.

Regarding how the parent could communicate with the child processes, this could be done a number of ways, but it would probably be easiest if the child process ran some kind of message pump on a thread and performed data processing on another thread. The message pump would receive and respond to messages, while the data processing thread would do its thing.

Using this scheme, messages could be exchanged in a number of different ways, including:

• Windows Communications Framework (WCF)
• Named Pipes
• .NET Remoting
• MS Message Queue (MSMQ)
• Windows Clipboard
• Dynamic Data Exchange (DDE)
• Component Object Model (COM)
• Memory-mapped Files
• Remote Procedure Calls (RPC)
• Sockets

Since all of these processes are running on the same machine, pipes are a simple straightforward choice. Check out the System.IO.Pipes namespace

WCF allows you to build a rich messaging interface that can be implemented on top of pipes, as well as on top of other IPC mechanisms.

There are lots of good resources on the I'net that discuss interprocess communications on .NET, and rather than rehash those here, you should search these out using terms such as ".NET", "interprocess communications", "IPC" and "local machine" (since you need IPC between processes on the local machine).