Linux與Windows處理序間通訊（IPC）–總結網路中內容

原文地址：http://www.cnblogs.com/raymon/archive/2012/02/18/2357608.html

http://blog.csdn.net/kesalin/article/details/3887368

 1. Linux處理序間通訊方式

處理序間通訊就是在不同進程之間傳播或交換資訊，那麼不同進程之間存在著什麼雙方都可以訪問的介質呢？進程的使用者空間是互相獨立的，一般而言是不能互相訪問的，唯一的例外是共用記憶體區。但是，系統空間卻是“公用場所”，所以核心顯然可以提供這樣的條件。除此以外，那就是雙方都可以訪問的外設了。在這個意義上，兩個進程當然也可以通過磁碟上的普通檔案交換資訊，或者通過“註冊表”或其它資料庫中的某些表項和記錄交換資訊。廣義上這也是處理序間通訊的手段，但是一般都不把這算作“處理序間通訊”。因為那些通訊手段的效率太低了，而人們對處理序間通訊的要求是要有一定的即時性。

Linux下進程通訊的八種方法：管道(pipe)，具名管道(FIFO)，記憶體映射(mappedmemeory)，訊息佇列(message
queue)，共用記憶體(shared memory)，訊號量(semaphore)，訊號(signal)，通訊端(Socket).

(1) 管道（pipe）：管道允許一個進程和另一個與它有共同祖先的進程之間進行通訊；

(2) 具名管道（FIFO）：類似於管道，但是它可以用於任何兩個進程之間的通訊，具名管道在檔案系統中有對應的檔案名稱。有名管道克服了管道沒有名字的限制，因此，除具有管道所具有的功能外，它還允許無親緣關係進程間的通訊。具名管道通過命令mkfifo或系統調用mkfifo來建立；

管道包括三種:1)普通管道PIPE,通常有種限制,一是半雙工,只能單向傳輸;二是只能在父子進程間使用.2)流管道s_pipe:去除了第一種限制,可以雙向傳輸.
3)具名管道:name_pipe,去除了第二種限制,可以在許多並不相關的進程之間進行通訊.

(3) 訊號（signal）：訊號是比較複雜的通訊方式，用於通知接收進程有某種事情發生，除了用於處理序間通訊外，進程還可以發送訊號給進程本身；Linux除了支援UNIX早期訊號語義函數signal外，還支援語義符合POSIX.1標準的訊號函數sigaction(實際上，該函數是基於BSD的，BSD即能實現可靠訊號機制，又能夠統一對外介面，用sigaction函數重新實現了signal函數的功能);

(4) 記憶體映射（mapped memory）：記憶體映射允許任何多個處理序間通訊，每一個使用該機制的進程通過把一個共用的檔案對應到自己的進程地址空間來實現它；

(5) 訊息佇列（message queue）：訊息佇列是訊息的串連表，包括POSIX訊息對和System V訊息佇列。有足夠許可權的進程可以向隊列中添加訊息，被賦予讀許可權的進程則可以讀走隊列中的訊息。訊息佇列克服了訊號承載資訊量少，管道只能成該無格式位元組流以及緩衝區大小受限等缺點；

(6) 訊號量（semaphore）：訊號量主要作為進程間以及同進程不同線程之間的同步手段；

(7) 共用記憶體（shared memory）：它使得多個進程可以訪問同一塊記憶體空間，是最快的可用IPC形式。這是針對其他通訊機制運行效率較低而設計的。它往往與其他通訊機制，如訊號量結合使用，以達到進程間的同步及互斥；

(8) 通訊端（Socket）：它是更為通用的處理序間通訊機制，可用於不同機器之間的處理序間通訊。起初是由UNIX系統的BSD分支開發出來的，但現在一般可以移植到其他類UNIX系統上：Linux和System
V的變種都支援通訊端；

2. Windows處理序間通訊方式

2.1 檔案對應

檔案對應(Memory-MappedFiles)能使進程把檔案內容當作進程地址區間一塊記憶體那樣來對待。因此，進程不必使用檔案I/O操作，只需簡單的指標操作就可讀取和修改檔案的內容。

Win32 API允許多個進程訪問同一檔案對應物件，各個進程在它自己的地址空間裡接收記憶體的指標。通過使用這些指標，不同進程就可以讀或修改檔案的內容，實現了對檔案中資料的共用。

應用程式有三種方法來使多個進程共用一個檔案對應物件。

(1)繼承：第一個進程建立檔案對應物件，它的子進程繼承該對象的控制代碼。

(2)命名檔案對應：第一個進程在建立檔案對應物件時可以給該對象指定一個名字(可與檔案名稱不同)。第二個進程可通過這個名字開啟此檔案對應物件。另外，第一個進程也可以通過一些其它IPC機制(有名管道、郵件槽等)把名字傳給第二個進程。

(3)控制代碼複製：第一個進程建立檔案對應物件，然後通過其它IPC機制(有名管道、郵件槽等)把物件控點傳遞給第二個進程。第二個進程複製該控制代碼就取得對該檔案對應物件的存取權限。

檔案對應是在多個進程間共用資料的非常有效方法，有較好的安全性。但檔案對應只能用於本地機器的進程之間，不能用於網路中，而開發人員還必須控制進程間的同步。

2.2 共用記憶體

Win32 API中共用記憶體(SharedMemory)實際就是檔案對應的一種特殊情況。進程在建立檔案對應物件時用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(OpenSoftware Foundation Distributed Computing Environment)標準。所以通過Win32API編寫的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下的網路編程介面。除了BerkeleySocket原有的庫函數以外，還擴充了一組針對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.相關問題

【FAQ1: 管道與檔案描述符,檔案指標的關係?】

答: 其實管道的使用方法與檔案類似,都能使用read,write,open等普通IO函數.管道描述符類似於檔案描述符.
事實上,管道使用的描述符,
檔案指標和檔案描述符最終都會轉化成系統中SOCKET描述符.都受到系統核心中SOCKET描述符的限制.本質上LINUX核心源碼中管道是通過空檔案來實現.

【FAQ2: 管道的使用方法?】

答: 主要有下面幾種方法: 1)pipe,建立一個管道,返回2個管道描述符.通常用於父子進程之間通訊.
2)popen, pclose:這種方式只返回一個管道描述符,常用於通訊另一方是stdin or stdout; 3)mkpipe:具名管道,
在許多進程之間進行互動.

【FAQ3: 管道與系統IPC之間的優劣比較?】

答: 管道:優點是所有的UNIX實現都支援,並且在最後一個訪問管道的進程終止後,管道就被完全刪除;缺陷是管道只允許單向傳輸或者用於父子進程之間.

系統IPC: 優點是功能強大,能在毫不相關進程之間進行通訊;缺陷是關鍵字KEY_T使用了核心標識,佔用了核心資源,而且只能被顯式刪除,而且不能使用SOCKET的一些機制,例如select,epoll等.

【FAQ4: WINDOS處理序間通訊與LINUX處理序間通訊的關係?】

答: 事實上,WINDOS的進程通訊大部分移植於UNIX, WINDOS的剪貼簿,檔案對應等都可從UNIX進程通訊的共用儲存中找到影子.

【FAQ5: 處理序間通訊與線程間通訊之間的關係?】

答: 因為WINDOWS啟動並執行實體是線程,狹義上的處理序間通訊其實是指分屬於不同進程的線程之間的通訊.而單個進程之間的線程同步問題可歸併為一種特殊的進程通訊.它要用到核心支援的系統調用來保持線程之間同步.通常用到的一些線程同步方法包括:Event,
Mutex, 訊號量Semaphore,臨界區資源等.