IPC的实现方式
在 Windows 上实现 IPC 的首选方法是什么？
我知道几个类似的：命名管道，共享内存，信号量？ ，也许是 COM（虽然我不知道如何）...
我想知道什么被认为是最强大、最快、最不容易出错并且易于维护/理解的。
what is the preferred way to implement IPC over windows ?
i know of several like : named pipe, shared memory, semaphors ? , maybe COM (though i'm not sure how)...
i wanted to know what's considered the most robust,fast,least error prone and easy to maintain/understand.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
几年前，我们研究了客户端/服务器情况下的这个特定问题，其中客户端和服务器都在同一台计算机上运行。当时，即使客户端和服务器位于同一台机器上，我们也使用套接字（UDP）。对于我们来说，“最好的”结果是使用命名信号量来共享内存来同步它。当时，我主要研究管道与原始共享内存实现。我测试了具有重叠 I/O 和 I/O 完成端口的管道。
我测试了多种数据大小。在客户端和服务器来回回显 1 个字节的低端，原始共享内存实现的速度最快，是原来的 3 倍。当我来回传递 10,000 个字节时，管道实现和原始共享内存实现都是最快的。大约相同的速度。如果我没记错的话，我使用的是 4K 缓冲区和共享内存实现。
对于所有数据大小，共享内存测试的速度比使用套接字快 2 倍到 6 倍（与 TCP 相比）。
在管道实现之间，当传递少量数据时，重叠 I/O 版本比 I/O 完成端口版本快约 30%。同样，对于较大的数据块，差异很小。
管道实现的编码当然要简单得多。但是我们处理了相当多的来回传递的小数据块，因此使用命名信号量实现共享内存版本的额外复杂性是值得的。
当然，正如前面提到的，这是几年前的事，你不知道我是否正确实施了所有不同的测试。另请注意，这是针对单个客户的。我们的共享内存通信的最终实现确实可以很好地扩展数百个“客户端”的运行。但我不知道在这种规模上它是否比管道实现更好。
A few years ago, we studied this particular question for a client/server situation where both client and server were running on the same machine. At the time, we were using sockets (UDP) even when client and server were on the same machine. For us, "best" turned out to be shared memory with named semaphores to synchronize it. At the time, I mainly studied pipes versus a raw shared memory implementation. I tested pipes with overlapped I/O and with I/O completion ports.
I tested with a large variety of data sizes. At the low end where client and server were echoing 1 byte back and forth, the raw shared memory implementation was the fastest by a factor of 3. When I passed 10,000 bytes back and forth, the pipe implementations and the raw shared memory implementation were all about the same speed. I was using 4K buffers if I recall correctly with the shared memory implementation.
For all data sizes, the shared memory test ranged between 2 times and 6 times faster than using sockets (compared against TCP).
Between the pipe implementations, the overlapped I/O version was faster than the I/O completion port version by about 30% when passing small amounts of data. Again, with larger chunks of data, the difference was minimal.
The pipe implementation was certainly much less complex to code. But we dealt with quite a few small chunks of data being passed back and forth, so it was worth the extra complexity to implement the shared memory version with named semaphores.
Of course, this was several years ago as mentioned, and you have no idea if I implemented all the different tests correctly. Note too that this was with a single client. The final implementation of our shared memory communication does scale very well for hundreds of "clients" running. But I do not know if it is better at that scale than a pipe implementation.
看一下 boost::interprocess。
一般来说，共享内存可能是最快的，但有些容易出错并且仅限于本地进程。
COM 是完全版本化的，并且自动支持远程 IPC，但显然它是特定于平台的。
对于大型应用程序，您可能需要考虑类似 ActiveMQ 或 OpenMQ。
Take a look at boost::interprocess.
Shared memory is probably the fastest in general, but somewhat error-prone and limited to local processes.
COM is fully versioned and automatically supports remote IPC, but obviously it's platform-specific.
For a large-scale application you might want to consider something like ActiveMQ or OpenMQ.
MSDN 有一个很好的总结。
话虽这么说，我认为你应该考虑使用第三方库。 Boost 应该很好 - 正如另一个答案中所述 - 并且您的 GUI 工具包可能也有一些抽象。
对于纯 Win32，匿名管道肯定是最简单的方法（您只需调用 CreatePipe 并使用两个生成的文件句柄；将所有内容加倍以实现全双工），但它的缺点是它仅在两个进程都在 Windows 上运行时才有效。同一台机器，并且您必须已经在进程之间拥有某种通信方式才能传递句柄。
MSDN has a nice summary.
That being said, I think you should consider using a 3rd party library. Boost should be nice -as stated in another answer- and your GUI toolkit might have some abstractions, too.
For pure Win32, anonymous pipes must be the easiest method (where you only have to call CreatePipe and use the two resulting file handles; double everything for full-duplex) but it has the drawback that it only works when both processes are running on the same machine and that you must already have some means of communication between the processes in order to pass the handles.
RPC/进程外 COM 或 DCOM（无论如何最终都会使用 RPC）都是在 Windows 中执行 IPC 的首选方式，除非您正在做一些非常简单的事情 - 我见过很多这样的方法人们沿着命名管道路线走下去，最终基本上重新实现了 DCOM 为您免费提供的东西。不要犯同样的错误:)
Either RPC / out-of-process COM or DCOM (which will eventually use RPC anyways) are the preferred way to do IPC in Windows unless you're doing something really simple - I've seen so many cases of people going down the named pipes route, and ending up basically reimplementing what DCOM gives you for free. Don't make the same mistake :)
对于我来说，通过命名管道传输
数据格式可以是您自己的，也可以使用本地 RPC（这就是 msft 使用的）
transport over named pipes for me
for data format either roll your own or use local RPC (which is what msft uses)