C+C# 进程间通信：命名管道、内存映射文件还是其他？
我正在使用 C dll 来挂钩全局 Windows 事件，下一步是将一些事件数据（没什么大的）发送到 C# 应用程序。
由于我希望这种通信尽可能快，因此我正在分析两个选项：命名管道和内存映射文件。
我知道.NET 4以本机方式带来了MMF，但我必须瞄准.NET 2，因为Win98客户端的存在仍然是可能的。我还知道有一些方法可以通过 Windows API 使用 .NET 2 管理 MMF（有些人甚至为其构建了一些包装器）。
在这种情况下，我想知道：
- 选择命名管道而不是 MMF 有什么大的缺点（主要是性能）吗？重要的是要记住，我不会传输大量数据；
- NP 或 MMF（针对 .NET 2）是否涉及任何安全问题？
- 还有比这些更好的选择吗？
I'm playing with C dlls to hook global Windows events and the next step is sending some event data (nothing huge) to a C# application.
As I want this communication to be as fast as possible, I'm analysing two options: Named Pipes and Memory Mapped Files.
I know that .NET 4 brings MMF in a native way, but I have to target .NET 2, as the existence of Win98 clients is still possible. I also know that there are ways to manage MMF with .NET 2 via Windows API (and some folks have even built some wrappers to it).
In this context, I'd like to know:
- Are there any big disadvantages (performance mainly) in choosing Named Pipes instead of MMF? Important to remember that I'll not transfer huge amount of data;
- Are there any security issues involved in NP or MMF (targeting .NET 2)?
- Is there any better choice than those?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果目标应用程序有一个可以向其发送消息的窗口，并且发送的数据量相对较小，请考虑使用 WM_COPYDATA 消息来传递信息。
该消息是为简单的进程间通信（目标具有 GUI）而设计的，可以由本机或 .NET 应用程序以几乎零的工作量使用，除了您对系统施加的任何压力之外，不会对系统产生任何影响。通过创建要传递的数据来存储内存，并且可在 Windows 95 及以上的所有 Windows 系统上使用。
http://msdn.microsoft.com/en-us/library/ms649011(VS.85).aspx
If the target application has a window that you can send messages to, and the amount of data you are sending is relatively small, consider using the WM_COPYDATA message to pass the information.
This message was designed for simple inter-process communication (where the target has a GUI), can be used by a native or a .NET application with nearly zero effort, will have no impact on the system other than whatever pressure you put on the memory by creating the data you are passing around, and is available on all Windows systems from Windows 95.
http://msdn.microsoft.com/en-us/library/ms649011(VS.85).aspx
选项 1：在 C# 对象之一上公开 COM 接口，并从 C++ 应用程序中调用该接口。
选项 2：使用 C++/CLI - 您可以使用 Win32 API 挂钩全局 Windows 事件并在另一端公开 .Net 类以供 C# 客户端直接使用。
当然，这些选项都没有回答您关于命名管道与内存映射文件的问题，但我认为这两个选项都会更简单，除非您有特定需要将它们保留为单独的进程。
Option 1: Expose a COM interface on one of your C# objects and call that from your C++ application.
Option 2: Use C++/CLI - you can use the Win32 API to hook global windows events and expose a .Net class on the other side for your C# clients to use directly.
Of course, neither of these options answers your question on Named Pipes vs. Memory mapped Files, but I think either of these will be simpler unless you have a specific need to keep these as separate processes.
无法详细介绍 MMF，因为我没有尝试使用它，但从它的外观来看，它看起来有点太复杂，无法设置。包装 P/调用后，为了能够使用 .NET 2.0 将命名管道公开为流（我创建了与 3.5 System.Core 类类似的类），以任何一种方式发送数据包都非常容易如果您可以设置权限，以便在 Vista/7 上运行更严格的策略。
也许你最好在 C# 应用程序中拥有服务器流，并在本机代码中拥有可能的无数客户端实例（我不确定你是否能够在与所有进程你注入 dll，所以我认为你将有多个客户端）。
为此，我已经完全放弃了 Vista/7 的 DLL 挂钩。
Can't tell about MMF much as I've not tried to use it, but from the look of it, it looks like a bit too complex to set up things. After wrapping the P/invokes, to be able to expose the Named Pipes as a stream with .NET 2.0 (I've created look-alikes of the 3.5 System.Core classes), it is quite easy to send packets of data either way IF you can set the permissions right to have things working on Vista/7 more restrictive policies.
Probably you'd better have the Server stream in the C# Application, and have your possible myriad instances of clients in native code poking things up (I'm not sure you'll be able to share a single instance started before hooking with all the processes you inject the dll, so I think your are going to have multiple clients).
I've gave up DLL hooking for Vista/7 altogether for that matter.