Finding or building an inter-process broadcast communication channel

Question

So we have this somewhat unusual need in our product. We have numerous processes running on the local host and need to construct a means of communication between them. The difficulty is that ...

1. There is no 'server' or master process
2. Messages will be broadcast to all listening nodes
3. Nodes are all Windows processes, but may be C++ or C#
4. Nodes will be running in both 32-bit and 64-bit simultaneously
5. Any node can jump in/out of the conversation at any time
6. A process abnormally terminating should not adversely affect other nodes
7. A process responding slowly should also not adversely affect other nodes
8. A node does not need to be 'listening' to broadcast a message

A few more important details...

The 'messages' we need to send are trivial in nature. A name of the type of message and a single string argument would suffice.

The communications are not necessarily secure and do not need to provide any means of authentication or access control; however, we want to group communications by a Windows Log-on session. Perhaps of interest here is that a non-elevated process should be able to interact with an elevated process and vise-versa.

My first question: is there an existing open-source library?, or something that can be used to fulfill this with little effort. As of now I haven't been able to find anything :(

If a library doesn't exist for this then... What technologies would you use to solve this problem? Sockets, named-pipes, memory mapped files, event handles? It seems like connection based transports (sockets/pipes) would be a bad idea in a fully connected graph since n nodes requires n(n-1) number of connections. Using event handles and some form of shared storage seems the most plausible solution right now...

Updates

• Does it have to be reliable and guaranteed? Yes, and no... Let's say that if I'm listening, and I'm responding in a reasonable time, then I should always get the message.

• What are the typical message sizes? less than 100 bytes including the message identifier and argument(s). These are small.

• What message rate are we talking about? Low throughput is acceptable, 10 per second would be a lot, average usage would be around 1 per minute.

• What are the number of processes involved? I'd like it to handle between 0 and 50, with the average being between 5 and 10.

Answer 1

I don't know of anything that already exists, but you should be able to build something with a combination of:

• Memory mapped files
• Events
• Mutex
• Semaphore

This can be built in such a way that no "master" process is required, since all of those can be created as named objects that are then managed by the OS and not destroyed until the last client uses them. The basic idea is that the first process to start up creates the objects you need, and then all other processes connect to those. If the first process shuts down, the objects remain as long as at least one other process is maintaining a handle to them.

The memory mapped file is used to share memory among the processes. The mutex provides synchronization to prevent simultaneous updates. If you want to allow multiple readers or one writer, you can build something like a reader/writer lock using a couple of mutexes and a semaphore (see Is there a global named reader/writer lock?). And events are used to notify everybody when new messages are posted.

I've waved my hand over some significant technical detail. For example, knowing when to reset the event is kind of tough. You could instead have each app poll for updates.

But going this route will provide a connectionless way of sharing information. It doesn't require that a "server" process is always running.

For implementation, I would suggest implementing it in C++ and let the C# programs call it through P/Invoke. Or perhaps in C# and let the C++ apps call it through COM interop. That's assuming, of course, that your C++ apps are native rather than C++/CLI.

Answer 2

I've never tried this, but in theory it should work. As I mentioned in my comment, use a UDP port on the loopback device. Then all the processes can read and write from/to this socket. As you say, the messages are small, so should fit into each packet - may be you can look at something like google's protocol buffers to generate the structures, or simply mem copy the structure into the packet to send and at the other end, cast. Given it's all on the local host, you don't have any alignment, network order type issues to worry about. To support different types of messages, ensure a common header which can be checked for type so that you can be backward compatible.

2cents...