我正在寻找一种机制来创build一个简单的多对多消息传递系统，以允许Windows应用程序在单个计算机上进行通信，但在会话和桌面上进行通信。
我有以下硬性要求：
我不需要保证传递消息。
我看了很多很多的select。 这是我对思想的最后要求。
以下因违反上述一项或多项要求而被拒绝：
ZeroMQ ：为了做到多对多的信息，一个中央经纪人是必需的。
命名pipe道 ：需要中央服务器接收消息并转发它们。
多播套接字 ：需要一个正确configuration的具有有效IP地址的网卡，即全局configuration。
共享内存队列 ：要在全局名称空间中创build共享内存，需要提升权限。
多播套接字如此接近工作。 还有什么人可以build议？ 我会考虑从预包装库到裸机Windows APIfunction的任何事情。
（ 编辑9月27日 ）更多的上下文：
“中央协调员/经纪人/服务器”是指在应用程序尝试发送消息时必须运行的单独进程。 我看到的问题是，不可能保证这个过程真的会在需要时运行。 通常会使用Windows服务，但无法保证在用户login之前始终启动某个特定的服务，或者由于某种原因保证该服务未被停止。 按需运行会在服务启动时发送第一条消息时引入延迟，并引发特权问题。
多播套接字几乎可以工作，因为它设法避免完全需要中央协调器进程，并且不需要从发送或接收多播包的应用程序提升特权。 但是你必须有一个configuration好的IP地址 – 你不能在回环接口上进行多播（即使在一个configuration好的网卡上TTL = 0的组播的行为就像人们所期望的那样） – 那就是交易断开器。
也许我完全误解了这个问题，特别是“没有中央经纪人”，但是你是否考虑过基于元组空间的东西？
– 意见交换后，请考虑以下作为我的“权威”答案，然后：
使用基于文件的解决方案，并将目录树托管在Ramdisk上以确保良好的性能。
我还建议看看下面的StackOverflow讨论 （即使它是基于Java的），以便指出如何管理文件系统上的锁定和事务。
这一个 （基于.NET）也可能有帮助。
UDP 广播怎么样？
你不能使用本地主机套接字？
/托尼
最后，我决定要有一个硬性的要求，因为这个问题不能像原来所说的那样以任何合理的方式解决。
我的最终解决方案是运行命名管道服务器的Windows服务。 任何应用程序或服务都可以连接到管道的一个实例并发送消息。 任何由服务器接收到的消息都被回显到所有管道实例。
我真的很喜欢p.marino的答案，但是最终它看起来像是一个非常基本的功能的复杂性。
另外一个吸引我的可能性就是编写一个内核驱动来管理多播。 在这种情况下可能会有几种机制，但是编写一个无bug的内核驱动程序的开销太高了。