什么是在Windows上实现IPC的首选方法？
我知道有几种方法，例如：命名管道、共享内存、信号量，或者可能是COM（虽然我不确定如何使用）...
我想知道哪种方法被认为是最健壮、最快、最少出错和易于维护/理解的。
实现IPC的方法
3
- Idan
3
这是一个相当主观的问题。总的来说，它也不是一个有答案的问题。你想要快速、强大且易于维护（即便宜）。难道不是有句谚语说“好、快、便宜——选两个”吗？ - Managu
这绝对是一个可以写书的主题，需要权衡不同的使用场景和不同的方法，而不是几行文字就能回答的问题。 - Georg Fritzsche
我有同样的问题...这是一个相当棘手的难题。目前我正在研究openMPI。 - Hassan Syed
5个回答
6
几年前，我们为一个客户/服务器情况研究了这个特定的问题，其中客户端和服务器都在同一台计算机上运行。当时，即使客户端和服务器在同一台机器上，我们仍然使用套接字（UDP）。对我们来说，“最佳”的解决方案是使用具有命名信号量以进行同步的共享内存。当时，我主要研究了管道与原始共享内存实现之间的区别。我使用重叠I/O和I/O完成端口测试了管道。
我使用了各种数据大小进行测试。在客户端和服务器回显1个字节来回传输的低端，原始共享内存实现的速度是其他方法的3倍。当我来回传输10,000字节时，管道实现和原始共享内存实现的速度都差不多。如果我没记错的话，我使用4K缓冲区来实现共享内存。
对于所有数据大小，相比TCP，共享内存测试的速度范围在2倍到6倍之间。
在管道实现之间，当传输少量数据时，重叠I/O版本比I/O完成端口版本快约30%。同样，在传输更大的数据块时，差异很小。
管道实现肯定要简单得多。但是，我们处理了很多小块数据的来回传输，因此实现具有命名信号量的共享内存版本值得额外的复杂性。
当然，这是几年前的事情，你不知道我是否正确地实施了所有不同的测试。还要注意，这是针对单个客户端的。我们的共享内存通信的最终实现非常适用于数百个运行的“客户端”。但我不知道在那种规模下，它是否比管道实现更好。
- Mark Wilkins
2
请看 boost::interprocess。
共享内存通常是最快的，但有些容易出错并且仅限于本地进程。
COM 具有完全的版本控制，并自动支持远程 IPC，但显然它是特定于平台的。
对于大规模应用程序，您可能需要考虑像ActiveMQ或OpenMQ这样的东西。
共享内存通常是最快的，但有些容易出错并且仅限于本地进程。
COM 具有完全的版本控制，并自动支持远程 IPC，但显然它是特定于平台的。
对于大规模应用程序，您可能需要考虑像ActiveMQ或OpenMQ这样的东西。
- Tim Sylvester
1
我已经使用过 Boost Interprocess 几次，感觉还不错。 - Matt Joiner
1
MSDN有一个很好的摘要。
话虽如此，我认为您应该考虑使用第三方库。Boost应该不错-正如另一个答案中所述-而您的GUI工具包也可能有一些抽象层。
对于纯Win32，匿名管道应该是最简单的方法（您只需调用CreatePipe并使用得到的两个文件句柄即可；对于全双工，需要将其加倍），但它的缺点是仅在两个进程都运行在同一台机器上时才有效，并且您必须已经有某种手段来传递句柄以便进行通信。
- aib
1
在Windows中，除非你正在做一些非常简单的事情，否则RPC / out-of-process COM或DCOM（最终将使用RPC）是进行IPC的首选方式 - 我已经看到很多人走向命名管道路线，并最终基本上重新实现了DCOM免费提供给您的内容。不要犯同样的错误：）
- Ana Betts
0
为我提供命名管道传输
对于数据格式，可以自己编写或使用本地RPC（这是微软使用的方法）
- pm100
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接