工控机的实现方法

看一看 boost::interprocess .

共享内存通常可能是最快的,但有点容易出错,并且仅限于本地进程。

COM是完全版本化的,并自动支持远程IPC,但显然它是特定于平台的。

对于大型应用程序,您可能需要考虑 ActiveMQ 或 OpenMQ .

几年前,我们针对客户机/服务器环境研究了这个特殊的问题,在这种情况下,客户机和服务器都在同一台机器上运行。当时,即使客户机和服务器在同一台计算机上,我们也在使用套接字(udp)。对我们来说,“best”实际上是共享内存和指定的信号量来同步它。当时,我主要研究管道与原始共享内存实现。我用重叠的I/O和I/O完成端口测试了管道。

我测试了大量的数据。在客户机和服务器来回回显1字节的低端,原始共享内存的实现速度是3倍。当我来回传递10000字节时,管道实现和原始共享内存实现的速度都差不多。如果我正确地回忆起共享内存的实现,我使用的是4k缓冲区。

对于所有数据大小,共享内存测试的速度都比使用套接字快2到6倍(与tcp相比)。

在管道实现之间,当传递少量数据时,重叠的I/O版本比I/O完成端口版本快约30%。同样,对于较大的数据块,差异也很小。

管道实现对代码来说当然要简单得多。但是我们处理了很多来回传递的小数据块,因此用指定的信号量实现共享内存版本值得额外的复杂性。

当然,这是几年前提到的,你不知道我是否正确地实现了所有不同的测试。还要注意,这是一个单一的客户。我们共享内存通信的最终实现对于运行的数百个“客户机”来说可伸缩性非常好。但我不知道它是否比管道实现的规模更好。

MSDN 总结得很好。

尽管如此,我认为你应该考虑使用第三方图书馆。boost应该很好——正如另一个答案中所述——而且您的gui工具包可能也有一些抽象。

对于纯win32,匿名管道必须是最简单的方法(在这种方法中,您只需调用createpipe并使用两个生成的文件句柄;对于全双工,将所有内容都加倍),但它的缺点是,它只在两个进程在同一台计算机上运行时才起作用,而且您必须已经进程之间为了传递句柄而进行的一些通信方式。

在windows中,rpc/out-of-process-com或dcom(最终将使用rpc)是进行ipc的首选方法,除非您正在执行某些操作 真正地 很简单-我见过很多这样的例子:人们沿着命名管道的路线前进,最终基本上重新实现了DCOM为您提供的功能 免费 . 别犯同样的错误:)

通过指定管道为我传输

对于数据格式,可以自己滚动或使用本地rpc(这是msft使用的)