windows進程間通訊 .

摘 要: 隨着人們對應用程序的要求愈來愈高，單進程應用在許多場合已不能知足人們的要求。編寫多進程/多線程程序成爲現代程序設計的一個重要特色，在多進程程序設計中，進程間的通訊是不可避免的。Microsoft Win32 API提供了多種進程間通訊的方法，全面地闡述了這些方法的特色，並加以比較和分析，但願能給讀者選擇通訊方法提供參考。
關鍵詞 進程 進程通訊 IPC Win32 API 

1 進程與進程通訊 

進程是裝入內存並準備執行的程序，每一個進程都有私有的虛擬地址空間，由代碼、數據以及它可利用的系統資源(如文件、管道等)組成。多進程/多線程是Windows操做系統的一個基本特徵。Microsoft Win32應用編程接口(Application Programming Interface, API)提供了大量支持應用程序間數據共享和交換的機制，這些機制行使的活動稱爲進程間通訊(InterProcess Communication, IPC)，進程通訊就是指不一樣進程間進行數據共享和數據交換。
正由於使用Win32 API進行進程通訊方式有多種，如何選擇恰當的通訊方式就成爲應用開發中的一個重要問題，下面本文將對Win32中進程通訊的幾種方法加以分析和比較。 

2 進程通訊方法 

2.1 文件映射
文件映射(Memory-Mapped Files)能使進程把文件內容看成進程地址區間一塊內存那樣來對待。所以，進程沒必要使用文件I/O操做，只需簡單的指針操做就可讀取和修改文件的內容。
Win32 API容許多個進程訪問同一文件映射對象，各個進程在它本身的地址空間裏接收內存的指針。經過使用這些指針，不一樣進程就能夠讀或修改文件的內容，實現了對文件中數據的共享。
應用程序有三種方法來使多個進程共享一個文件映射對象。
(1)繼承：第一個進程創建文件映射對象，它的子進程繼承該對象的句柄。
(2)命名文件映射：第一個進程在創建文件映射對象時能夠給該對象指定一個名字(可與文件名不一樣)。第二個進程可經過這個名字打開此文件映射對象。另外，第一個進程也能夠經過一些其它IPC機制(有名管道、郵件槽等)把名字傳給第二個進程。
(3)句柄複製：第一個進程創建文件映射對象，而後經過其它IPC機制(有名管道、郵件槽等)把對象句柄傳遞給第二個進程。第二個進程複製該句柄就取得對該文件映射對象的訪問權限。
文件映射是在多個進程間共享數據的很是有效方法，有較好的安全性。但文件映射只能用於本地機器的進程之間，不能用於網絡中，而開發者還必須控制進程間的同步。

2.2 共享內存
Win32 API中共享內存(Shared Memory)實際就是文件映射的一種特殊狀況。進程在建立文件映射對象時用0xFFFFFFFF來代替文件句柄(HANDLE)，就表示了對應的文件映射對象是從操做系統頁面文件訪問內存，其它進程打開該文件映射對象就能夠訪問該內存塊。因爲共享內存是用文件映射實現的，因此它也有較好的安全性，也只能運行於同一計算機上的進程之間。

2.3 匿名管道
管道(Pipe)是一種具備兩個端點的通訊通道：有一端句柄的進程能夠和有另外一端句柄的進程通訊。管道能夠是單向－一端是隻讀的，另外一端點是隻寫的；也能夠是雙向的－管道的兩端點既可讀也可寫。
匿名管道(Anonymous Pipe)是 在父進程和子進程之間，或同一父進程的兩個子進程之間傳輸數據的無名字的單向管道。一般由父進程建立管道，而後由要通訊的子進程繼承通道的讀端點句柄或寫 端點句柄，而後實現通訊。父進程還能夠創建兩個或更多個繼承匿名管道讀和寫句柄的子進程。這些子進程可使用管道直接通訊，不須要經過父進程。
匿名管道是單機上實現子進程標準I/O重定向的有效方法，它不能在網上使用，也不能用於兩個不相關的進程之間。

2.4 命名管道
命名管道(Named Pipe)是服務器進程和一個或多個客戶進程之間通訊的單向或雙向管道。不一樣於匿名管道的是命名管道能夠在不相關的進程之間和不一樣計算機之間使用，服務器創建命名管道時給它指定一個名字，任何進程均可以經過該名字打開管道的另外一端，根據給定的權限和服務器進程通訊。
命名管道提供了相對簡單的編程接口，使經過網絡傳輸數據並不比同一計算機上兩進程之間通訊更困難，不過若是要同時和多個進程通訊它就力不從心了。

2.5 郵件槽
郵件槽(Mailslots)提供進程間單向通訊能力，任何進程都能創建郵件槽成爲郵件槽服務器。其它進程，稱爲郵件槽客戶，能夠經過郵件槽的名字給郵件槽服務器進程發送消息。進來的消 息一直放在郵件槽中，直到服務器進程讀取它爲止。一個進程既能夠是郵件槽服務器也能夠是郵件槽客戶，所以可創建多個郵件槽實現進程間的雙向通訊。
經過郵件槽能夠給本地計算機上的郵件槽、其它計算機上的郵件槽或指定網絡區域中全部計算機上有一樣名字的郵件槽發送消息。廣播通訊的消息長度不能超過400字節，非廣播消息的長度則受郵件槽服務器指定的最大消息長度的限制。
郵件槽與命名管道類似，不過它傳輸數據是經過不可靠的數據報(如TCP/IP協議中的UDP包)完成的，一旦網絡發生錯誤則沒法保證消息正確地接收，而命名管道傳輸數據則是創建在可靠鏈接基礎上的。不過郵件槽有簡化的編程接口和給指定網絡區域內的全部計算機廣播消息的能力，因此郵件槽不失爲應用程序發送和接收消息的另外一種選擇。

2.6 剪貼板
剪貼板(Clipped Board)實質是Win32 API中一組用來傳輸數據的函數和消息，爲Windows應用程序之間進行數據共享提供了一箇中介，Windows已創建的剪切(複製)－粘貼的機制爲不一樣應用程序之間共享不一樣格式數據提供了一條捷徑。當用戶在應用程序中執行剪切或複製操做時，應用程序把選取的數據用一種或多種格式放在剪貼板上。而後任何其它應用程序均可以從剪貼板上拾取數據，從給定格式中選擇適合本身的格式。
剪貼板是一個很是鬆散的交換媒介，能夠支持任何數據格式，每一格式由一無符號整數標識，對標準(預約義)剪貼板格式，該值是Win32 API定義的常量；對非標準格式可使用Register Clipboard Format函數註冊爲新的剪貼板格式。利用剪貼板進行交換的數據只需在數據格式上一致或均可以轉化爲某種格式就行。但剪貼板只能在基於Windows的程序中使用，不能在網絡上使用。

2.7 動態數據交換
動態數據交換(DDE)是使用共享內存在應用程序之間進行數據交換的一種進程間通訊形式。應用程序可使用DDE進行一次性數據傳輸，也能夠當出現新數據時，經過發送更新值在應用程序間動態交換數據。
DDE和剪貼板同樣既支持標準數據格式(如文本、位圖等)，又能夠支持本身定義的數據格式。但它們的數據傳輸機制卻不一樣，一個明顯區別是剪貼板操做幾乎老是用做對用戶指定操做的一次性應答－如從菜單中選擇Paste命令。儘管DDE也能夠由用戶啓動，但它繼續發揮做用通常沒必要用戶進一步干預。DDE有三種數據交換方式：
(1) 冷鏈：數據交換是一次性數據傳輸，與剪貼板相同。
(2) 溫鏈：當數據交換時服務器通知客戶，而後客戶必須請求新的數據。
(3) 熱鏈：當數據交換時服務器自動給客戶發送數據。
DDE交換能夠發生在單機或網絡中不一樣計算機的應用程序之間。開發者還能夠定義定製的DDE數據格式進行應用程序之間特別目的IPC，它們有更緊密耦合的通訊要求。大多數基於Windows的應用程序都支持DDE。

2.8 對象鏈接與嵌入
應用程序利用對象鏈接與嵌入(OLE)技術管理複合文檔(由多種數據格式組成的文檔)，OLE提供使某應用程序更容易調用其它應用程序進行數據編輯的服務。例如，OLE支持的字處理器能夠嵌套電子表格，當用戶要編輯電子表格時OLE庫可自動啓動電子表格編輯器。當用戶退出電子表格編輯器時，該表格已在原始字處理器文檔中獲得更新。在這裏電子表格編輯器變成了字處理器的擴展，而若是使用DDE，用戶要顯式地啓動電子表格編輯器。
同DDE技術相同，大多數基於Windows的應用程序都支持OLE技術。

2.9 動態鏈接庫
Win32動態鏈接庫(DLL)中的全局數據能夠被調用DLL的全部進程共享，這就又給進程間通訊開闢了一條新的途徑，固然訪問時要注意同步問題。
雖然能夠經過DLL進行進程間數據共享，但從數據安全的角度考慮，咱們並不提倡這種方法，使用帶有訪問權限控制的共享內存的方法更好一些。

2.10 遠程過程調用
Win32 API提供的遠程過程調用(RPC)使應用程序可使用遠程調用函數，這使在網絡上用RPC進行進程通訊就像函數調用那樣簡單。RPC既能夠在單機不一樣進程間使用也能夠在網絡中使用。
因爲Win32 API提供的RPC服從OSF-DCE(Open Software Foundation Distributed Computing Environment)標準。因此經過Win32 API編寫的RPC應用程序能與其它操做系統上支持DEC的RPC應用程序通訊。使用RPC開發者能夠創建高性能、緊密耦合的分佈式應用程序。

2.11 NetBios函數
Win32 API提供NetBios函數用於處理低級網絡控制，這主要是爲IBM NetBios系統編寫與Windows的接口。除非那些有特殊低級網絡功能要求的應用程序，其它應用程序最好不要使用NetBios函數來進行進程間通訊。

2.12 Sockets
Windows Sockets規範是以U.C.Berkeley大學BSD UNIX中流行的Socket接口爲範例定義的一套Windows下的網絡編程接口。除了Berkeley Socket原有的庫函數之外，還擴展了一組針對Windows的函數，使程序員能夠充分利用Windows的消息機制進行編程。
如今經過Sockets實現進程通訊的網絡應用愈來愈多，這主要的緣由是Sockets的跨平臺性要比其它IPC機制好得多，另外WinSock 2.0不只支持TCP/IP協議，並且還支持其它協議(如IPX)。Sockets的惟一缺點是它支持的是底層通訊操做，這使得在單機的進程間進行簡單數據傳遞不太方便，這時使用下面將介紹的WM_COPYDATA消息將更合適些。

2.13 WM_COPYDATA消息
WM_COPYDATA是一種很是強大卻不爲人知的消息。當一個應用向另外一個應用傳送數據時，發送方只需使用調用SendMessage函數，參數是目的窗口的句柄、傳遞數據的起始地址、WM_COPYDATA消息。接收方只需像處理其它消息那樣處理WM_COPY DATA消息，這樣收發雙方就實現了數據共享。
WM_COPYDATA是一種很是簡單的方法，它在底層其實是經過文件映射來實現的。它的缺點是靈活性不高，而且它只能用於Windows平臺的單機環境下。 

3 結束語 

Win32 API爲應用程序實現進程間通訊提供瞭如此多種選擇方案，那麼開發者如何進行選擇呢？一般在決定使用哪一種IPC方法以前應考慮如下一些問題：
(1)應用程序是在網絡環境下仍是在單機環境下工做。

附:

 

在我學windows編程的時候，對進程間如何通訊老是感受很神祕，網絡上介紹的方法不少，可是不多有一個系統的介紹，五花八門的說法讓人老是一頭霧水，在這裏，我整理一下各通訊方法，梳理了一下這些方法的優缺點，但願能對各位看官起到拋磚引玉的做用。 非標準的進程間通訊技術有：Windows消息，內存映射，內存共享等等。

1. Windows消息實現進程間通訊。 消息的接受進程和發送進程都要定義相同的消息。可是，若是發送方僅僅是發送消息，那麼發送方能夠不實現消息映射，不用定義消息響應函數。接受方須要定義映射和相應函數。 自定義消息的實現進程間通訊的缺陷是，因爲消息的傳遞參數是個長整形 lparam， 所以，只能傳遞整形的數據，而不能傳遞字符串。有個能夠的思路是，傳遞字符串所在的地址，而後另外一個程序經過得到發送方的進程句柄，用函數ReadProcessMemory與WriteProcessMemory操做發送方的內存空間來讀取內容。

2. 使用MFC定義的WM_COPYDATA消息 該消息其實與普通的自定義消息通訊相似，區別是，傳送的是一個指向COPYDATASTRUCT 結構的指針，要傳遞的字符串就保存在這個結構體裏。這個結構的第一個變量 dwData能夠設置爲0便可。 這個消息與 上面的那個思路的不一樣是，得到告終構體的指針後，接受進程不須要其餘的處理就能獲取到指針的數據，就好像在同一個進程裏通訊同樣. 另外注意，該消息的接受有時並不能得到所須要的長度，有可能只接收到了一部分。 所以，該方式只適合於傳遞是少許的數據。

3.使用進程內存讀寫函數 基本上與方法一得後面猜測部分相同。關鍵是，要使用GlobalAlloc()或者VirtualAllocEx來分配內存空間存放數據。把數據寫入接收方的進程內存，而後接着就發消息告訴他數據的地址。因爲是在發送方申請的內存，那麼，最好等待sleep必定時間再VirtualFreeEx申請到得內存。 GlobalAlloc()或者VirtualAllocEx能夠實如今另外一個進程的內存空間來申請內存，這就爲何上面能進行的緣由。也就是說，發送方並不在本身的內存空間申請內存，而是在接收方進程內存空間來申請內存。而後寫入輸入數據。固然，也能夠在發送方的進程空間來申請內存，接收方經過跨進程讀寫的方式來讀。這只是處理方式不一樣而已。

4.使用內存映射文件的方法 內存映射的好處就是，能夠像對待一個文件同樣來對待一塊內存區。文件時能夠被不一樣的進程來讀寫的。既然那塊內存 區像文件同樣，那麼這塊內存區就能夠被不一樣的進程來讀寫。

5.使用DLL進行通訊 Win32 DLL 只能共享代碼不能共享數據，不一樣的進程載入同一個DLL文件，DLL的代碼都只載入了一份到內存，這隻載入一份代碼僅指同一個DLL文件，若是相同的DLL文件在不一樣的盤符下，也不是同一個DLL，而是同一DLL多個副本。 Win16 DLL 被載入了系統內存，因此調用它的進程均可以訪問到它的全局變量，所以能夠很容易的實現進程間通訊。可是對於win32 DLL , 操做系統會把該DLL映射到每一個調用它的進程的地址空間，DLL成爲該進程的一部分。 能夠用下面的方法來將DLL的數據區設置爲共享區。 

#pragma data_seg("SHARED") // 定義名爲SHARED的共享數據段 

char m_strString[256]=TEXT(""); // 共享的數據。特別要注意須要初始化，由於編譯器會把未初始化的變量保存在bss數據段。 

volatile bool bInCriticalSection=FALSE; // 同步標示 

#pragma data_seg()

 #pragma comment(linker,"/SECTION:SHARED,RWS") // 將要共享的數據段通知編譯器。 

CCriticalSection cs; // 臨界區，控制同步的 上面控制了同步問題。

6.使用操做系統提供的剪貼板實現通訊 使用剪貼板是一中開銷較小的進程通訊機制。剪貼板機制的原理是，剪貼板是系統預留的一塊全局內存，用來暫存進程間進行數據交換的數據。 提供數據的進程須要先建立一個全局內存塊，而後將要傳送的數據移到或複製到該內存塊。 接收進程須要得到此內存塊的句柄，完成數據讀取。 

下面的程序標明怎麼在剪貼板寫數據 

CString strData=m_strClipBoard; // 得到數據. 

// 打開系統剪貼板. 

if (!OpenClipboard()) return; 

// 使用以前，清空系統剪貼板. 

EmptyClipboard(); 

// 分配一內存，大小等於要拷貝的字符串的大小，返回該內存控制句柄. 

HGLOBAL hClipboardData; 

hClipboardData = GlobalAlloc(GMEM_DDESHARE, strData.GetLength()+1);

 // 內存控制句柄加鎖，返回值爲指向那內存控制句柄所在的特定數據格式的指針. 

char * pchData; pchData = (char*)GlobalLock(hClipboardData); 

// 將本地變量的值賦給全局內存. 

strcpy(pchData, LPCSTR(strData));

 // 給加鎖的全局內存控制句柄解鎖. 

GlobalUnlock(hClipboardData); 

// 經過全局內存句柄將要拷貝的數據放到剪貼板上. 

SetClipboardData(CF_TEXT,hClipboardData); 

// 使用完後關閉剪貼板. 

CloseClipboard(); 

從剪貼板讀取數據的代碼以下：

// 打開系統剪貼板. 

if (!OpenClipboard()) return; 

// 判斷剪貼板上的數據是不是指定的數據格式. 

if (IsClipboardFormatAvailable(CF_TEXT)|| IsClipboardFormatAvailable(CF_OEMTEXT)) { 

// 從剪貼板上得到數據. 

HANDLE hClipboardData = GetClipboardData(CF_TEXT); 

// 經過給內存句柄加鎖，得到指向指定格式數據的指針. 

char *pchData = (char*)GlobalLock(hClipboardData);

 // 本地變量得到數據. 

m_strClipBoard = pchData; 

// 給內存句柄解鎖. 

GlobalUnlock(hClipboardData); 

} 

else

 {

 AfxMessageBox("There is no text (ANSI) data on the Clipboard."); } 

// 使用完後關閉剪貼板. 

CloseClipboard(); 

// 更新數據.

 UpdateData(FALSE);

7.DDE （Dynamic Data Exchange）動態數據交換 目前微軟已經中止了開發這種技術，僅僅保留了支持。 高級通訊技術 前面都是幾種基本的進程通訊技術，消息管道（Message Pipes）, 郵槽（Mail slots）， 和套接字（Sockets）則是實際比較常見的方法，這幾種高級通訊除了能夠像上面的方法樣實現本地系統進程間的通訊，也能夠用於遠程不一樣系統間的通訊。

8. 消息管道 Message Pipes又分爲匿名管道(anonymous Pipes),和 命名管道（Named Pipes）, 匿名管道主要用於本地系統上父進程與他啓動的子進程間的通訊。命名管道高級些，能夠再不一樣的系統上的進程間通訊，由於UNIX, LINUX等都支持這項技術，所以，命名管道技術是比較理想的C/S結構通訊技術。 命名管道原理是，一個進程把數據放進管道中，另外一個知道管道名字的常常來把數據取走。其餘不知道管道名字的進程不可能能把數據取走。 所以，管道實際上就是一塊進程間的共享內存。 建立管道的進程叫管道服務器，連接管道的進程就是客戶機。建立管道的函數是HANDLE CreateNamedPipe(….); 鏈接管道 CallNamedPipe(); 讀入或寫入數據後腰關閉它 ConnectNamedPipe(); 服務器準備好一個鏈接到客戶進程的管道，並一直等待知道客戶鏈接上爲止。 DisconnectNamedPipe(); 服務器中斷與客戶的鏈接 GetNamedPipeHandleState(); 獲取一個命名管道的狀態信息 GetNamedPipeInfo();獲取一個命名管道的信息 PeekNamedPipe(); 從一個管道中複製數據到一個緩衝區 SetNamedPipeHandleState(); 設置一個管道的狀態信息以及管道類型 TransactNamedPipe(); 從一個消息管道讀消息或寫消息 WaitNamedPipe(); 使服務器等待來自客戶的實例鏈接。 管道通訊基本流程 

（1）鏈接創建 服務器端經過ConnectNamedPipe函數創建以個命名管道實例，而後經過ConnectNamedPipe()函數來偵聽來自客戶端得請求。這個函數能夠設置等待時間。 客戶端只需使用函數WaitNamedPipe()來鏈接服務器。

（2）通訊實現 創建鏈接後，就能夠經過獲得管道的文件句柄利用ReadFile()與WriteFile()進行彼此間的通訊。 

（3）鏈接終止 客戶端調用CloseFile(), 服務器端調用DisconnectNamedPipe()終止鏈接。且都須要CloseHandle來關閉管道。

9.郵槽通訊

10.套接字通訊 套接字通訊過程可簡單的描述爲，主要調用5個函數，socket(),bind(), Listen(), connect(), accept(). 服務器端主要調用socket(),bind(), Listen(),accept()。 客戶端主要調用socket(),connect()。 雙方的數據傳送就是經過send() 與recv()完成。 套接字類型主要有5種，SOCK_STREAM, SOCK_DGRAM, SOCK_RAW, SOCK_SEQPACKET, SOCK_RDM. 

10.1 Winsock 程序設計流程 

（1）程序編譯環境 有兩套函數進行Winsock程序設計，Socket1.1 與Socket2.0. 能夠靈活混用。Socket2.0得功能較爲強大。 包含其中一個頭文件及其對應的庫文件便可。 

// Socket2.0 

#include 

#pragma comment (lib, 「ws2_32.lib」); 

// Socket1.1 

#include 

#pragma comment (lib, 「wsock32.lib」); 

（2）選擇機制（異步？非阻塞？） 默認狀況下都是建立的阻塞套接字。能夠經過select或者WSAAsynSelect()函數將其變爲非阻塞的。特別注意，用這個函數改成非阻塞後，不能簡單的利用ioctlsocket()將它再變爲阻塞模式。也就是說這兩個函數改變阻塞模式是由區別的。ioctlsocket()是將異步模式的套接字再改回阻塞模式，但以前要調用WSAAsynSelect()取消全部的異步事件,WSAAsynSelect(s,hWnd,0,0); 

（3）啓動與終止 啓動函數WSAStartup()創建於Winsock DLL 的鏈接， 終止函數WSAClearup()終止該DLL，這兩個函數必須成對使用。 

（4）出錯處理 Winsock爲了與之後的多線程環境相兼容，提供了兩個出錯處理函數來獲取和設置當前線程的最近錯誤號，即WSAGetLastError()和WSASetLastError();