StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POMany-to-many messaging on local machine without broker
text
Body
copied!<p>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.</p> <p>I have the following hard requirements:</p> <ol> <li>Must work across all Windows sessions on a single machine.</li> <li>Must work on Windows XP and later.</li> <li>No global configuration required.</li> <li>No central coordinator/broker/server.</li> <li>Must not require elevated privileges from the applications.</li> </ol> <p>I <strong>do not</strong> require guaranteed delivery of messages.</p> <p>I have looked at many, many options. This is my last-ditch request for ideas.</p> <p>The following have been rejected for violating one or more of the above requirements:</p> <p><strong>ZeroMQ</strong>: In order to do many-to-many messaging a central broker is required.<br> <strong>Named pipes</strong>: Requires a central server to receive messages and forward them on.<br> <strong>Multicast sockets</strong>: Requires a properly configured network card with a valid IP address, i.e. a global configuration.<br> <strong>Shared Memory Queue</strong>: To create shared memory in the global namespace requires elevated privileges.</p> <p>Multicast sockets <em>so nearly</em> works. What else can anyone suggest? I'd consider anything from pre-packaged libraries to bare-metal Windows API functionality.</p> <hr> <p>(<em>Edit 27 September</em>) A bit more context:</p> <p>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.</p> <p>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.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload