查找或构建进程间广播通信通道
所以我们的产品有这种有点不寻常的需求。我们在本地主机上运行着许多进程，需要构建它们之间的通信方式。困难在于...
- 没有“服务器”或主进程
- 消息将广播到所有侦听节点
- 节点都是 Windows 进程，但可能是 C++ 或 C#
- 节点将同时在 32 位和 64 位中运行
- 任何节点都可以随时跳入/跳出对话
- 进程异常终止不应对其他节点产生不利影响
- 响应缓慢的进程也不应对其他节点产生不利影响
- 节点不需要“监听”来广播消息
一些更重要的细节...
我们需要发送的“消息”本质上是微不足道的。消息类型的名称和单个字符串参数就足够了。
通信不一定安全，不需要提供任何身份验证或访问控制手段；但是，我们希望通过 Windows 登录会话对通信进行分组。也许这里有趣的是，非提升进程应该能够与提升进程交互，反之亦然。
我的第一个问题：是否有现有的开源库？或者可以用来轻松实现此目的的东西。到目前为止，我还没有找到任何东西:(
如果不存在这样的库那么...您将使用什么技术来解决这个问题？套接字、命名管道、内存映射文件、事件句柄？在完全连接的图中，基于连接的传输（套接字/管道）似乎是一个坏主意，因为 n 个节点需要 n(n-1) 个连接，使用事件句柄和某种形式的共享存储似乎是最合理的解决方案。现在...
更新
它必须可靠且有保证吗？是的，或者不是...假设我正在倾听，并且我在合理的时间内做出回应，那么我应该总是收到消息。
典型的消息大小是多少，包括消息标识符和参数。
我们所说的消息速率是多少？低吞吐量是可以接受的，每秒 10 个就很多了，平均使用量约为每分钟 1 个。
涉及的进程数量是多少？我希望它能够处理 0 到 50 之间的数量，平均数量为 5 到 10 之间的数量。
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 ...
- There is no 'server' or master process
- Messages will be broadcast to all listening nodes
- Nodes are all Windows processes, but may be C++ or C#
- Nodes will be running in both 32-bit and 64-bit simultaneously
- Any node can jump in/out of the conversation at any time
- A process abnormally terminating should not adversely affect other nodes
- A process responding slowly should also not adversely affect other nodes
- 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不知道任何已经存在的东西，但是您应该能够通过以下组合来构建一些东西：
这可以以不需要“主”进程的方式构建，因为所有这些可以被创建为命名对象，然后由操作系统管理，并且直到最后一个客户端使用它们为止不会被销毁。基本思想是，第一个启动的进程创建您需要的对象，然后所有其他进程连接到这些对象。如果第一个进程关闭，只要至少有一个其他进程维护它们的句柄，这些对象就会保留下来。
内存映射文件用于在进程之间共享内存。互斥体提供同步以防止同时更新。如果您想允许多个读取器或一个写入器，您可以使用几个互斥锁和一个信号量构建类似读取器/写入器锁的东西（请参阅是否有全局命名的读取器/写入器锁？）。事件用于在发布新消息时通知每个人。
我已经就一些重要的技术细节挥手了。例如，知道何时重置事件有点困难。您可以让每个应用程序轮询更新。
但走这条路将提供一种无连接的信息共享方式。它不需要“服务器”进程始终运行。
对于实现，我建议用 C++ 实现，并让 C# 程序通过 P/Invoke 调用它。或者也许在 C# 中并让 C++ 应用程序通过 COM 互操作调用它。当然，这是假设您的 C++ 应用程序是本机应用程序而不是 C++/CLI。
I don't know of anything that already exists, but you should be able to build something with a combination of:
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.
我从未尝试过这个，但理论上它应该有效。正如我在评论中提到的，在环回设备上使用 UDP 端口。然后所有进程都可以从此套接字读取和写入。正如你所说，消息很小，所以应该适合每个数据包 - 也许你可以看看谷歌的协议缓冲区之类的东西来生成结构，或者简单地将结构复制到要发送的数据包中，然后在另一端进行强制转换。鉴于一切都在本地主机上，您无需担心任何对齐、网络顺序类型问题。为了支持不同类型的消息，请确保可以检查类型的通用标头，以便向后兼容。
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...
我认为一个更重要的考虑因素是性能，我们谈论的消息速率是多少，不是。进程？
无论哪种方式，您都依赖于一个允许通信需求的“主站”，无论是自定义服务还是提供的系统（管道、消息队列等）。
如果您不需要跟踪和查询过去的消息，我确实认为您应该考虑一个非常简单的服务，它打开一个命名管道 - 允许所有其他进程作为 PipeClient 读取或写入它。如果我没记错的话，它会检查您列表中的所有项目。
I think one more important consideration is performance, what message rate are we talking about and no. of processes?
Either way you are relying on a "master" that allows the communication needs, be it a custom service or a system provided(Pipes, Message Queue and such).
If you don't need to keep track and query for past messages, I do think you should consider a dead simple service that opens a named Pipe - allowing all other processes to either read or write to it as PipeClients. If I am not mistaken it checks on all items in your list.
您正在寻找的是邮槽！
请参阅创建邮槽：
http://msdn.microsoft。 com/en-us/library/windows/desktop/aa365147(v=vs.85).aspx
What your looking for is Mailslots!
See CreateMailslot:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365147(v=vs.85).aspx