專利名稱：基于管道的多進程間消息通信方法
技術領域：
本發(fā)明涉及windows進程間通信技術領域，特別涉及一種基于管道的多進程間消息通信方法。
背景技術：
進程是裝入內(nèi)存并獨立執(zhí)行的程序，每個進程都有自己的私有進程空間，對其他進程是不可見的。而這些獨立的進程間要交換數(shù)據(jù)就要用到進程間通信機制，進程通過這種進程間通信機制向其他進程傳輸控制信息，或與其他進程交換數(shù)據(jù)，但是這種通信存在單一性和不可控性，例如a進程與b進程之間有通信需求，c進程與a、b都沒有通信需求， 但是c進程需要關注a，b進程的通信狀態(tài)，以便做出相應的處理，這種情況下會想到，可以在a與b通信后或通信的同時與c通信告知a與b通信的狀態(tài)，但這種通信方式需要控制同步問題，而且當有通信和關注通信需求的進程不是三個而是數(shù)十個，這種方案在代碼實現(xiàn)上就會變得臃腫和不可控，當然最主要的是不利于新程序的添加。又如上面的例子，假如a、b、c程序都已經(jīng)寫好了，現(xiàn)在有個新的需求要添加一個新的程序d，它要關注a與b的通信，又要與c發(fā)消息，那么就需要同時改寫a、b、c程序，這顯然是不可行的。綜上，現(xiàn)有技術中各應用程序間之間直接進行通信，就要知道要和那個進程通信， 尤其是當通信的進程并不能確定時，處理上變得不可控，而且會頻繁修改代碼。當有新的進程要與原來已經(jīng)寫好的程序通信時，就要修改原有的程序代碼。以適應新的需求。

發(fā)明內(nèi)容
(一)要解決的技術問題本發(fā)明要解決的技術問題是如何使各進程間通信的實現(xiàn)變得簡單。( 二 )技術方案為解決上述技術問題，本發(fā)明提供了一種基于管道的多進程間消息通信方法，包括以下步驟Si、進程向消息中心進行注冊，即發(fā)送進程信息，所述消息中心是用于處理消息的服務程序，所述進程信息包括消息標識；S2、所述消息中心將與所述消息標識對應的消息發(fā)送給所述進程；在步驟Sl與S2的通信過程中，進程與消息中心之間使用管道進行通信。優(yōu)選地，所述消息中心與進程間以異步事件的機制實現(xiàn)通信。優(yōu)選地，步驟Sl中，在消息中心收到進程信息之后對進程信息進行保存，而在步驟Sl與S2的通信過程中，如果消息中心異常退出和被強制殺掉，消息中心在恢復之后自動根據(jù)所保存的進程信息與進程間進行重新連接。優(yōu)選地，消息中心與進程都以消息流的模式發(fā)送數(shù)據(jù)。優(yōu)選地，在步驟Sl之前還包括消息中心進行初始化的步驟。
3
(三)有益效果本發(fā)明由于引入了消息中心對消息進行統(tǒng)一處理，因此克服了現(xiàn)有技術中各進程間通信需要頻繁修改代碼的問題，從而使各進程間通信的實現(xiàn)變得簡單；消息中心(即服務器端)與進程(即客戶端)間以異步事件的機制實現(xiàn)，使得消息中心與進程間使用管道進行通信時不會產(chǎn)生阻塞，從而保障各進程間的正常消息通信；添加了災難恢復機制，在消息中心異常退出和被強制殺掉時，仍然能夠保障消息中心與進程間的正常通信，從而保障各進程間的正常消息通信；消息中心與進程都以消息流的模式發(fā)送數(shù)據(jù)(即發(fā)送的時候裝包，接收后解包)，使得在進程較多而消息中心較繁忙時也能保證接收的一端(某一進程) 可以得到與發(fā)送時等長的數(shù)據(jù)。


圖1是本發(fā)明的方法流程圖；圖2是本發(fā)明的方法的詳細流程圖。
具體實施例方式下面結合附圖和實施例，對本發(fā)明的具體實施方式
作進一步詳細說明。以下實施例用于說明本發(fā)明，但不用來限制本發(fā)明的范圍。如圖1、2所示，本發(fā)明提供了一種基于管道的多進程間消息通信方法。對于服務器端，即消息中心，首先進行如下初始化處理初始化客戶端隊列鎖，客戶端(即進程)注冊的信息會保存到并在該隊列中維護；初始化刪除隊列鎖，客戶端退出或關閉后，將其注冊信息移至該隊列中；消息中心以指針隊列的形式維護客戶端隊列和刪除客戶端隊列，每個隊列節(jié)點存儲著注冊的客戶端id(即進程標識)，和所關注的消息結構體，消息結構體包括消息id(即消息標識)、消息自定義常量、消息數(shù)據(jù)指針和消息數(shù)據(jù)長度；初始化通訊服務器，創(chuàng)建服務器端的管道，用管道的方式將序列化后的數(shù)據(jù)傳出去；啟動消息循環(huán)，處理來自客戶端的消息；啟動時間發(fā)生器回收內(nèi)存服務器端定時檢查刪除隊列中的節(jié)點，將注銷的客戶端節(jié)點釋放掉，以節(jié)省內(nèi)存空間。然后等待客戶端注冊消息中心初始化完成后，處于等待狀態(tài)，當有客戶端注冊請求發(fā)生時，將管道中傳過來的數(shù)據(jù)流進行解包，封裝成結構體后作為客戶端隊列鎖的一個節(jié)點添加到隊列中。啟動并處理消息服務端注冊成功后，便向客戶端返回注冊結果，然后等待客戶端的啟動消息通知 (即啟動命令)，當接收到啟動通知后，處理來自客戶端的消息，處理的方式由三種廣播消息，將消息廣播給所有注冊的客戶端；查詢消息，根據(jù)查詢的消息代號查找指定內(nèi)容；轉發(fā)消息，根據(jù)注冊時的信息將消息轉發(fā)給指定的客戶端；將停止消息循環(huán)的客戶端移至刪除隊列。
刪除消息注冊當客戶端不需要關注或發(fā)送消息時，或客戶端正常關閉或異常銷毀時，服務器端會將客戶端注冊在隊列中的節(jié)點刪除，并將該節(jié)點添加到刪除隊列中，待服務器端的定時器達到預設時間時會將刪除隊列中的數(shù)據(jù)清除掉。對于客戶端，進行以下處理首先向服務端注冊注冊客戶端信息，包括客戶端ID，關注的消息隊列(其中包括關注的消息結構體， 消息結構體包括消息id)，服務的消息隊列；然后向服務器端發(fā)送啟動命令啟動命令發(fā)送成功后，當服務器端接受到客戶端注冊的信息時，會將與消息ID對應的消息派送給客戶端。向服務端發(fā)送停止命令當客戶端不需要發(fā)消息，同時也不需要關注任何消息時，可以向服務端發(fā)送停止命令，這樣服務器端就會將該客戶端注冊的信息在隊列中刪除，不再處理，如果客戶端沒有關閉就退出或是異常情況下崩潰，服務端也會將該客戶端注冊的消息刪除。由以上實施例可以看出，本發(fā)明由于引入了消息中心對消息進行統(tǒng)一處理，因此克服了現(xiàn)有技術中各進程間通信需要頻繁修改代碼的問題，從而使各進程間通信的實現(xiàn)變得簡單；消息中心(即服務器端)與進程(即客戶端)間以異步事件的機制實現(xiàn)，使得消息中心與進程間使用管道進行通信時不會產(chǎn)生阻塞，從而保障各進程間的正常消息通信；添加了災難恢復機制，在消息中心異常退出和被強制殺掉時，仍然能夠保障消息中心與進程間的正常通信，從而保障各進程間的正常消息通信；消息中心與進程都以消息流的模式發(fā)送數(shù)據(jù)(即發(fā)送的時候裝包，接收后解包)，使得在進程較多而消息中心較繁忙時也能保證接收的一端(某一進程)可以得到與發(fā)送時等長的數(shù)據(jù)。以上實施方式僅用于說明本發(fā)明，而并非對本發(fā)明的限制，有關技術領域的普通技術人員，在不脫離本發(fā)明的精神和范圍的情況下，還可以做出各種變化和變型，因此所有等同的技術方案也屬于本發(fā)明的范疇，本發(fā)明的專利保護范圍應由權利要求限定。
權利要求
1.一種基于管道的多進程間消息通信方法，其特征在于，包括以下步驟51、進程向消息中心進行注冊，即發(fā)送進程信息，所述消息中心是用于處理消息的服務程序，所述進程信息包括消息標識；52、所述消息中心將與所述消息標識對應的消息發(fā)送給所述進程； 在步驟Sl與S2的通信過程中，進程與消息中心之間使用管道進行通信。
2.如權利要求1所述的方法，其特征在于，所述消息中心與進程間以異步事件的機制實現(xiàn)通信。
3.如權利要求1所述的方法，其特征在于，步驟Sl中，在消息中心收到進程信息之后對進程信息進行保存，而在步驟Sl與S2的通信過程中，如果消息中心異常退出和被強制殺掉，消息中心在恢復之后自動根據(jù)所保存的進程信息與進程間進行重新連接。
4.如權利要求1所述的方法，其特征在于，消息中心與進程都以消息流的模式發(fā)送數(shù)據(jù)。
5.如權利要求1 4中任一項所述的方法，其特征在于，在步驟Sl之前還包括消息中心進行初始化的步驟。
全文摘要
本發(fā)明涉及windows進程間通信技術領域，公開了一種基于管道的多進程間消息通信方法，包括以下步驟S1、進程向消息中心進行注冊，即發(fā)送進程信息，所述消息中心是用于處理消息的服務程序，所述進程信息包括消息標識；S2、所述消息中心將與所述消息標識對應的消息發(fā)送給所述進程；在步驟S1與S2的通信過程中，進程與消息中心之間使用管道進行通信。本發(fā)明能夠使各進程間通信的實現(xiàn)變得簡單。
文檔編號H04L12/58GK102355429SQ20111023071
公開日2012年2月15日 申請日期2011年8月12日 優(yōu)先權日2011年8月12日
發(fā)明者萬雪松, 于曉軍, 趙辰清 申請人:北京思創(chuàng)銀聯(lián)科技股份有限公司