Question

I’m looking for a mechanism to use to create a simple many-to-many messaging system to allow Windows applications to communicate on a single machine but across sessions and desktops.

I have the following hard requirements:

1. Must work across all Windows sessions on a single machine.
2. Must work on Windows XP and later.
3. No global configuration required.
4. No central coordinator/broker/server.
5. Must not require elevated privileges from the applications.

I do not require guaranteed delivery of messages.

I have looked at many, many options. This is my last-ditch request for ideas.

The following have been rejected for violating one or more of the above requirements:

ZeroMQ: In order to do many-to-many messaging a central broker is required.
Named pipes: Requires a central server to receive messages and forward them on.
Multicast sockets: Requires a properly configured network card with a valid IP address, i.e. a global configuration.
Shared Memory Queue: To create shared memory in the global namespace requires elevated privileges.

Multicast sockets so nearly works. What else can anyone suggest? I’d consider anything from pre-packaged libraries to bare-metal Windows API functionality.

---

(Edit 27 September) A bit more context:

By ‘central coordinator/broker/server’, I mean a separate process that must be running at the time that an application tries to send a message. The problem I see with this is that it is impossible to guarantee that this process really will be running when it is needed. Typically a Windows service would be used, but there is no way to guarantee that a particular service will always be started before any user has logged in, or to guarantee that it has not been stopped for some reason. Run on demand introduces a delay when the first message is sent while the service starts, and raises issues with privileges.

Multicast sockets nearly worked because it manages to avoid completely the need for a central coordinator process and does not require elevated privileges from the applications sending or receiving multicast packets. But you have to have a configured IP address – you can’t do multicast on the loopback interface (even though multicast with TTL=0 on a configured NIC behaves as one would expect of loopback multicast) – and that is the deal-breaker.

Answer 1

In the end I decided that one of the hard requirements had to go, as the problem could not be solved in any reasonable way as originally stated.

My final solution is a Windows service running a named pipe server. Any application or service can connect to an instance of the pipe and send messages. Any message received by the server is echoed to all pipe instances.

I really liked p.marino’s answer, but in the end it looked like a lot of complexity for what is really a very basic piece of functionality.

The other possibility that appealed to me, though again it fell on the complexity hurdle, was to write a kernel driver to manage the multicasting. There would have been several mechanisms possible in this case, but the overhead of writing a bug-free kernel driver was just too high.