需要帮助设计进程间通信层
我的系统中有几个需要相互通信的进程。
有些进程需要每秒连续传递 60 次数据块， 有些是零星的。
大多数流程都是用C#编写的，其中一种是C++。
全部运行在同一台 Windows 7 机器上。
现在每个进程都有自己不同的通信实现（管道、事件和套接字）。 我正在寻求统一到一个通信层。
- 你会如何实施这个？
- 也许某种以预期接收者作为标题的广播？
- 您会选择哪种流程通信方法？
谢谢，
SW
I have several process in my system that need to communicate with each other.
Some of the processes need to pass chunks of data 60 times per second continuously,
and some are very sporadic.
Most of the processes are in C#, one is C++.
All running on the same windows 7 machine.
Right now each process has it's own different comm implentation (pipes, events and sockets).
I'm looking to unify into one communication layer.
- How would you implement this?
- Maybe some kind of broadcast with the intended receiver as header?
- What method of process communication would you choose?
Thanks,
SW
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我建议使用 ICE，它支持远程对象和消息传递。满足您的速率和带宽需求不会有任何问题。它还跨平台，支持 C# 或 C++ 以外的语言，为您的其他组件提供更多语言选择。
I would suggest using ICE, which supports remote objects and message passing. It will have no problem meeting your rates and bandwidth needs. It's also cross platform and supports languages other then just C# or C++, giving you more languages choices for other components.
我正在使用 WCF 服务.Net 进程以及 .Net 和 Java 进程之间进行通信。我发现 WCF 是实现此目的的一种非常简单的方法。
I'm using a WCF service to communicate between .Net processes and .Net and Java processes. I found WCF a very easy way to achieve this purpose.
看看 MSMQ。它是基于套接字的并且速度相当快。本文介绍如何从 C++ 使用它：http://msdn.microsoft。 com/en-us/library/ms811055.aspx。
您也没有提到您的通信是同步还是异步（作者是否必须等待读者的响应？）。您有多个作者和读者吗？是恒定的 60Hz 还是成堆出现，以便读者可以跟上作家的喘息空间？
数据库表也可以用作队列，并且具有在系统崩溃时保留消息的优点。像 Sqlite 这样的低开销嵌入式引擎非常适合于此。
Take a look at MSMQ. It's socket-based and quite fast. This article describes how to use it from C++: http://msdn.microsoft.com/en-us/library/ms811055.aspx.
You also didn't mention whether your communication is synchronous or asynchronous (does the writer have to wait for a response from the reader?). Do you have multiple writers and readers? Is it a constant 60Hz or does it come in bunches with breathing room where readers can catch up to writers?
A database table can also be used as a queue, and has the advantage of persisting the messages if the system crashes. A low-overhead embedded engine like Sqlite is well-suited for this.
请注意，消息传递中间件解决方案（如 WCF 和 ICE）是强大的引擎，可为您提供可靠的消息传递、消息排序控制、分布式（多机）功能等功能。
它们也相对复杂，可能涉及一定程度的“框架”学习。
如果您的应用程序目前运行可靠，那么最好首先引入您为下一个新功能选择的任何消息传递解决方案，并首先在那里进行证明。然后，您可以在必要时改造现有流程（如果......）。
Note that messaging middleware solutions (like WCF and ICE) are powerful engines giving you features like reliable message delivery, control over message ordering, distributed (multi-machine) capability etc.
They are also relatively complex and may involve a degree of 'framework' learning.
If your application currently works reliably today, it might be an idea to introduce whatever messaging solution you select for your next new functionality initially and prove it there first. You could then retrofit to your existing processes (if...) and when necessary.