實現IPC的方式

在Windows上實現IPC的首選方式是什麼？實現IPC的方式

我知道幾個像：命名管道，共享內存，信號燈？，也許COM（雖然我不知道如何）...

我想知道什麼被認爲是最健壯，最快，最不容易出錯和易於維護/理解。

2009-12-15 Idan

這是一個比較主觀的問題。總的來說，這也不是一個答案。您希望快速，健壯且易於維護（即便宜）。不是增加「好，快，便宜 - 選擇兩個？」 – Managu 2009-12-15 23:30:39

它絕對是一本可以編寫書籍的主題，根據不同的方法權衡不同的使用場景，而不是幾行可以回答的問題。 – 2009-12-15 23:39:12

我有同樣的問題......這是相當一個難題。目前我正在看openMPI。 – 2009-12-16 01:42:20

共享內存可能是最快的一般，但有點容易出錯並且侷限於本地進程。

COM完全版本化並自動支持遠程IPC，但顯然它是平臺特定的。

對於大型應用程序，您可能需要考慮諸如ActiveMQ或OpenMQ之類的內容。

2009-12-15 23:26:35

我用升壓進程內部幾次，這不是壞的。 – 2009-12-15 23:34:57

運輸命名管道，我

數據格式要麼推出自己的，或者使用本地RPC（這是什麼MSFT使用）

2009-12-15 23:26:51 pm100

MSDN有一個很好的總結。

這就是說，我認爲你應該考慮使用第三方庫。 Boost應該很好 - 正如另一個答案所述 - 而且你的GUI工具包也可能有一些抽象。

對於純粹的Win32，匿名管道必須是最簡單的方法（只需調用CreatePipe並使用兩個生成的文件句柄;對於全雙工都將雙重一切），但它的缺點是隻有在兩個進程在同一臺機器上運行，並且您必須在進程之間有一些通信手段才能通過句柄。

2009-12-15 23:41:11 aib

幾年前，我們研究了客戶端和服務器在同一臺機器上運行的客戶端/服務器情況下的這個特定問題。當時，即使客戶端和服務器在同一臺機器上，我們也使用套接字（UDP）。對我們來說，「最好」的結果是與命名信號共享內存來同步它。當時，我主要研究管道與原始共享內存實現。我測試了具有重疊I/O和I/O完成端口的管道。

我測試了各種各樣的數據大小。在客戶端和服務器來回響應1個字節的低端，原始共享內存實現最快爲3倍。當我傳遞10,000個字節時，管道實現和原始共享內存實現都是大約相同的速度。如果我正確地記得共享內存的實現，我正在使用4K緩衝區。

對於所有數據大小，共享內存測試的速度比使用套接字快2到6倍（與TCP相比）。

在管道實現之間，當傳遞少量數據時，重疊的I/O版本比I/O完成端口版本快大約30％。再次，大塊的數據，差異很小。

管道的實現對於代碼來說肯定簡單得多。但是我們處理了來回傳遞的不少小塊數據，因此使用命名信號實現共享內存版本更加複雜。

當然，這是幾年前提到的，你不知道，如果我正確地實現各種不同的測試。還要注意，這是與一個客戶端。我們的共享內存通信的最終實現並不規模非常好幾百「客戶」運行。但我不知道這是否是在那規模比一個管道實現更好的。

2009-12-15 23:59:13

任何RPC /進程外的COM或DCOM（它最終都會使用RPC）是在Windows中執行IPC的首選方法，除非你在做什麼真的是簡單 - 我見過這麼多例子的人沿着命名管道路線，並最終基本上實現了免費的DCOM給你。不要犯同樣的錯誤:)

2009-12-17 01:31:03

回答