應用程式之間互相通訊的幾種方法
阿新 • • 發佈：2019-02-09
應用程式之間的資料交換（互相通訊）一直是困擾廣大程式設計師的難題，儘管已經出現了各式各樣的解決方案，但迄今為止沒有哪一種方案是完美無缺的。因此，只有學習並瞭解了它們的優缺點後，才能在特定的情況下選擇最佳方案，以滿足最終的要求。
1、共享
在硬碟上建立一個檔案，一個應用程式往該檔案裡寫資料（可以不關閉檔案，但必須重新整理緩衝區），另一個應用程式以共享方式開啟這個檔案並讀取其中的內容，這便是最簡單的一種資料交換方式。對於網路使用者而言，只要兩臺終端上安裝的都是Win311 For Workgroup或Windows 95（或NT），則只要設定一下目錄共享，對映成網路驅動器，同樣可以簡單地實現資料交換
2、DDE
每個Windows程式設計師都不會對DDE（動態資料交換）感到陌生，它是最早的基於Windows的資料交換方法，有三種方式可供選擇：冷連線、溫連線和熱連線。一般都是由客戶端向伺服器端發出連線申請，並且必須指明伺服器端的名字和標題。在連線建立後，資料可以雙向流動。典型的例子如抓圖軟體SnagIt，它提供了DDE介面，能夠讓其它應用程式來控制它。DDE是完全向後相容的，從16位平臺轉到32位，原始碼幾乎不用修改。
DDE還有網路功能。使用過Win311 For Workgroup的人大概都還記得，它自帶一個非常吸引人的小程式“Chat”，能使兩臺計算機通過網路實時交談，這在當時幾乎是一項創舉。可是很少有人知道“Chat”使用的是一種特殊的DDE，即NetDDE。它的基本工作原理仍然是DDE，但它能使一臺計算機向在同一個網路中的另一臺終端發訊息，而不像普通DDE 只能侷限在同一臺機器上。與其它的
3、WM_COPYDATA
Windows訊息WM_COPYDATA功能強大，知之者卻甚少。它的確切定義是：一個應用程式向另一個應用程式傳遞資料時所發出的訊息。眾所周知，Windows 在很大程度上依賴於訊息機制，那麼我們為什麼不把資料放在訊息中一起傳送出去呢？這樣，我們只要呼叫SendMessage（），以對方窗體的控制代碼作為第一個引數，以含有指向實際資料的指標結構的地址作為第二個引數，就可以把整個資料塊當作訊息發向另一個應用程式。也許有的程式設計師會說，一個自定義的訊息同樣可以完成這樣的工作。他只說對了一半。自定義訊息的確可以傳送到其它的應用程式上去，但其原始資料所在的記憶體區只有在傳送過程中才是合法的，若在其它模組中存取該記憶體區就會導致“Access Violation”。而使用
4、NetBIOS
從80年代開始，NetBIOS就是開發Client/Server類程式的標準介面。而當時其它的解決方案几乎都是從UNIX系統上發展而來的。當然，對於今天的使用者而言，NetBIOS已不是唯一的選擇，他們可以從各種方案中擇優選取。在Windows 95和NT平臺上，可以通過API函式Netbios()來呼叫NetBIOS功能。
NetBIOS相容以下幾種低層協議：NetBEUI協議（NBF）、NWLink NetBIOS(NWNBlink)、NetBIOS over TCP/IP(NetBT)。NetBIOS的優點是速度較快，缺點是可靠性較差。
5、標準的Sockets和WinSock
Sockets是15年前在UNIX系統上提出來的，一開始主要是用於本地通訊，但很快就應用在Client/Server體系上了。它的核心很簡單：你可以將一個Socket看作是一個雙向的節點，一個應用程式可以通過它先與另一個程式建立連線（建立在一個雙方都認可的端上，以便於區分同時執行的幾個通訊執行緒），然後就可以彼此交換資料了。
微軟公司在其基礎上建立了WinSock，專門用於Windows介面，與Socket完全相容。近年來基於TCP/IP協議的網路大行其道，Socket也隨之獲得了更加廣泛的應用。
如今，Sockets已在Internet上獲得了最廣泛的應用，主要是因為它的可移植性好：
Socket應用程式無論在任何平臺間都能互相進行通訊（不管是PC機還是Macintosh,也不管是Windows平臺還是UNIX平臺）。而最新推出的WinSock 2.0，已不僅僅只基於TCP/IP協議，還可基於其它幾種傳輸協議（如IPX）。
Socket的缺陷是它工作在通訊的低層，所以實現起來較為複雜（如果是Win 95或NT平臺，則不存在這個問題，微軟公司提供了相應的控制元件）。但是，如果要在多個平臺間互相通訊，則Socket是不二之選。
6、Mailslot和Pipe
Mailslot和Pipe有很多相同點，即都是高層的、基於記憶體的通訊系統。Mailslot由Server端建立，程式碼如下：
myMailslot = CreateMailslot(pSlotName, 0, MAILSLOT_WAIT_FOREVER, NULL);然後，Client端就可以像開啟檔案一樣開啟這個Mailslot，再通過API函式WriteFile()來將資料寫入到訊息佇列中。
與此相類似，Pipe也是由Server端建立的，程式碼如下：
pipe = CreateNamedPipe(pPipeName, PIPE_ACCESS_DUPLEX, PIPE_TYPE_MESSAGE |PIPE_READMODE_MESSAGE | PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, BUFSIZE,BUFSIZE, 20000, NULL);接著，Client端就可以通過一般的檔案API讀寫資料，程式碼如下：
pipe = CreateFile(pPipeName, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING,0,NULL);
success = WriteFile(pipe, pMessage, strlen(pMessage) + 1, &bytesWritten, NULL);Pipe分兩種，即命名Pipe和匿名Pipe。匿名Pipe是以控制代碼而不是以名字來進行標識的，因而也就限制了它只能在同一臺機器上通訊，而不能應用於網路。命名Pipe則提供了以名字來進行標識，所以能在網路上的其它任何地方開啟它。需要注意的是：命名Pipe只能在 Win NT而不是Win 95上建立（即Server端），Client端則可以是任意平臺。
Pipe既可以單向通訊也可以雙向通訊，Mailslot則只能單向通訊。Client端可以傳送訊息給mailslot，但不能接收訊息；如果你想要接收訊息，則只能建立一個新的mailslot。但mailslot有一個很大的優點：它支援資料廣播。也就是說，若Client端傳送一條訊息，則整個網路中的同名物件都能收到。這是因為mailslot的名字的作用域只是在本臺機器上，所以可在不同機器上建立同名的mailslot，當Client端發來訊息時則每一臺機上的mailslot都得到了該訊息的一份拷貝，並在本機上作出相應的反應。Mailslot的最大缺陷是不可靠，因為它的資料是以資料報格式來傳送的，網路錯誤或負荷過重都會導致資料丟失。
Pipe則較為可靠，但它不能廣播。所以，如果你不需要進行廣播，則Pipe是更好的選擇。選擇Mailslot，則要對此後遇到的麻煩有充分的準備。
7、剪貼簿（Clipboard）
大家對Windows的剪貼簿應該不會感到陌生吧？它的出現就是為了實現應用程式間的互相資料交換。Windows提供了一系列的API函式來讓應用程式安全地開啟剪貼簿，讀寫其中的資料。
剪貼簿的缺陷也是顯而易見的：當有新的資料放在剪貼簿上時，則先前的資料就會被沖掉，而在Windows中用到剪貼簿的時候又實在太多了，所以這種方式用於程式間的通訊顯然不夠安全。
8、COM和DCOM
公共物件模式（COM）是一種協議，它建立了一個軟體模組同另一個軟體模組之間的連線，然後將其描述出來。當這種連線建立起來之後，則兩個模組之間就可以通過稱為“介面”的機制來進行通訊。COM可以用不同的語言（VB、VC、Delphi）進行編制，又能被其它語言編寫的程式所使用，並且不用管通訊雙方實際所處的位置（是在同一臺機上，還是在同一個網路上的不同機上）。事實上，Internet上有大量的COM控制元件可供人們下載使用，其中有相當一部分就是用於應用程式間的相互通訊（甚至是Internet程式間的通訊），硬碟上能夠看到的大量的.ocx檔案其實就是一種COM。
COM物件為外部呼叫提供了一個標準的介面，COM Client通過建立COM Server的一個例項獲得指標，轉向所需的函式定義處並執行相應的程式。講得通俗一點，也就是先正確定義好COM物件的屬性（Property），再執行相應的方法（Method）。
DCOM（分散式公共物件模式）是COM在網路上的一種擴充套件，它通過把分散式物件間的通訊變成一個實體來實現通訊。
COM如今被微軟公司大力提倡，最著名的有OLE、ActiveX、DirectX和Win95、WinNT的外殼。由於微軟公司目前在軟體業處於霸主地位，所以COM很有可能成為將來的業界標準，其前途也較為看好。但COM的龐大也會使一些經驗豐富的程式設計師望而卻步，他們寧可自己多寫一些程式碼以使整個程式更為簡潔、有效而不願使用COM。
以上介紹的只是現今流行的一些通訊方法，它們各有各的優缺點，沒有哪一種是萬能的。因此，只有在合適的場合採用合適的方案，才是最好的解決辦法。