Many-to-many messaging on local machine without broker

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 开发者_Go百科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.

---

Maybe I am completely misunderstanding the problem, especially the "no central broker", but have you considered something based on tuple spaces?

-- After the comments exchange, please consider the following as my "definitive" answer, then:

Use a file-based solution, and host the directory tree on a Ramdisk to insure good performance.

I'd also suggest to have a look at the following StackOverflow discussion (even if it's Java based) for possible pointers to how to manage locking and transactions on the filesystem.

This one (.NET based) may be of help, too.

---

How about UDP broadcasting?

---

Couldn't you use a localhost socket ?

/Tony

---

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.