C# 中的 IPC 机制 - 用法和最佳实践答案

【问题标题】：IPC Mechanisms in C# - Usage and Best PracticesC# 中的 IPC 机制 - 用法和最佳实践
【发布时间】：2019-08-12 03:14:59
【问题描述】：

我之前在 Win32 代码中使用过 IPC - 关键部分、事件和信号量。

.NET 环境中的场景如何？是否有任何教程解释所有可用选项以及何时使用以及为什么？

【问题讨论】：

你需要做什么？如果需要同步访问某些外部资源，可以使用 Mutex 来实现跨进程同步。
+1。感谢上帝。这是具有“最佳实践”风格的问题的第一个实例，它没有被标记为非建设性/离题[我见过的]！！

标签： c# .net ipc

【解决方案1】：

Microsoft 在 IPC 中的最新资料是 Windows Communication Foundation。实际上底层并没有什么新东西（tcp、upd、命名管道等），但是 WCF 大大简化了 IPC 开发。

有用的资源：

Interprocess Communication with WCF Dobb 博士的门户网站
WCF Communication Options in the .NET Framework 3.5

当然还有MSDN on WCF

【讨论】：

嘿，第一个链接中的视频已经死了！

【解决方案2】：

除了显而易见的（WCF）之外，还有一个用于 C#/CLR 的 ZeroMQ 绑定非常好：

http://www.zeromq.org/bindings:clr

使用比 WCF 少得多的代码和配置实现面向消息的 IPC、发布/订阅和各种其他策略。

如果您需要低延迟通信，它至少比其他任何东西都快一个数量级并且延迟更少。

关于信号量、锁、互斥锁等。如果您通过交流而不是通过共享进行交流，那么您将比传统范例更轻松。

【讨论】：

“通过交流而不是通过分享来交流”这应该被任何从事并发编程的人每天背诵。
这是什么意思？
我认为它的意思是，您应该让程序通过 IPC 直接相互通信，而不是共享资源并让每个程序尝试随意声明它。在第一种情况下，您的程序通过锁定共享资源来“通信”。其次，它们通过某种协议进行通信以协调共享资源的使用。
zguide.zeromq.org/page:all#Unicast-Transports The inter-process ipc transport is disconnected, like tcp. It has one limitation: it does not yet work on Windows. Soooo 实际上并不是真的适用于 Windows 的 IPC，对吧？添加 C# 标签时，这仍然可能很常见。
您可以将本地环回适配器与 ZeroMQ 一起使用。不过，性能显然取决于适配器的实现。但是，当您的意图不是通过网络进行通信时，我不喜欢访问网络堆栈（尽管是虚拟接口）的语义。对于同一台机器上的 IPC，我个人认为使用管道是最好的解决方案。 .NET Standard 实现坚如磐石并且完全可移植。映射内存解决方案可能会提供最佳性能，但滚动您自己的解决方案很复杂，并且同步容易出错。 “通过交流分享” :)

【解决方案3】：

我倾向于使用命名管道或 Unix 套接字（取决于我的目标是 MS.NET 还是 Mono——我有一个将它抽象出来的类），因为它易于使用、可移植并且允许我轻松地进行互操作使用非托管代码。也就是说，如果您只处理托管代码，请使用 WCF 或远程处理 - 如果您需要 Mono 支持，则使用后者，因为他们的 WCF 支持根本不存在。

【讨论】：

虽然 2008 年 9 月（发表此评论时）可能就是这种情况，但现在是 2011 年，Mono 上的 WCF 现在已经相当成熟。请参阅Mono WCF Development page 并自行判断。

【解决方案4】：

如果您需要在机器域上使用而不是通过网络通信，我建议您使用内存映射文件。请参阅以下链接。

http://techmikael.blogspot.com/2010/02/blazing-fast-ipc-in-net-4-wcf-vs.html

【讨论】：

.NET 本地机器 API 列表：weblogs.asp.net/ricardoperes/…

【解决方案5】：

还有 .NET Remoting，我觉得它很酷，但我想他们现在已经过时了，因为他们有 WCF。

【讨论】：

微软真的这么说过吗？
他们有：“本主题专门针对一种遗留技术，该技术为与现有应用程序向后兼容而保留，不建议用于新开发。分布式应用程序现在应使用 Windows Communication Foundation (WCF )。”来自msdn.microsoft.com/en-us/library/kwdt6w2k.aspx
我已经使用 Remoting 多年了。对于小型应用程序（例如，传递多达 1k 个小对象），它非常直接且高效。超过这个限制，不！真的很烂。您必须在发送前压缩数据，这会增加额外的开销（CPU 使用率）。我对这个问题有一个非常令人沮丧的记忆。

【解决方案6】：

听起来您好像对同步技术而不是通信感兴趣。如果是这样，您可能想开始here，或者更多concise overview。

【讨论】：