統一進程間通信的製作方法

2023-04-26 11:34:56

專利名稱：：統一進程間通信的製作方法
技術領域：
：本發明涉及統一進程間通信，尤其涉及可以與所使用的硬體和軟體無關地用於通信的統一進程間通信系統和方法。
背景技術：
：通信系統可以配備各種類型的通信設備和模塊，譬如，異步傳輸模式(ATM)、同步數字分層結構(SDH)和網際網路協議(IP)等。在這樣的通信系統中，每種系統使用了與其它系統不同的進程間通信(IPC)方法。IPC與每種系統的各個硬體設備緊密地結合在一起，並且依賴於每種系統的各個硬體設備。例如，異步傳輸模式系統使用了與同步數字分層結構系統所使用的IPC方法不同的IPC方法。這樣的通信系統的通信方法隨著系統的各個設備和裝置的不同而彼此不同。由於缺乏可再用性和可移植性，這樣的系統在把IPC應用於系統的過程中會導致不希望有的成本和額外開銷，因此，是有缺點的。
發明內容為了解決現有技術的這些和其它問題，本發明的一個目的是提供一種可以與通信方法無關地應用在任何設備中的改進的進程間電信系統。本發明的另一個目的是提供一種通過把設備無關訪問層(DIA)引入系統中和通過把IPC與每個硬體設備鬆散地結合在一起，能夠改善IPC的可移植性的進程間通信方法。本發明的另一個目的是提供一種與用在通信設備中的作業系統無關地把消息數據從源發送到目的地的通信設備。本發明提供高度可移植性和靈活性。本發明的另一個目的是提供一種與用在通信設備中的硬體設備無關地把消息數據從源發送到目的地的通信方法。本發明的另一個目的是提供一種與設備所使用的通信方法(例如，異步傳輸模式、網際網路協議、同步數字分層結構等)無關地把消息數據從源發送到目的地的通信設備。為了達到根據本發明原理的這些和其它目的，正如具體化的和概括描述的那樣，本發明提供了把消息數據從源傳送到目的地的方法，該方法包括與通信設備的作業系統無關地發送消息數據，所述發送至少部分通過作業系統無關訪問層進行；和與設備的硬體無關地傳輸消息數據，所述傳輸至少部分通過設備無關訪問層進行。為了達到根據本發明原理的這些和其它目的，正如具體化的和概括描述的那樣，本發明提供了把消息數據從源傳送到目的地的設備，該設備包括設備的作業系統部分，用於與所述設備的作業系統無關地處理所述設備內的內部通信；和設備的硬體部分，用於與所述設備中的硬體設備無關地處理與所述設備的外部通信。為了達到根據本發明原理的這些和其它目的，正如具體化的和概括描述的那樣，本發明提供了在上面存儲著一組指令的計算機存儲介質，該組指令用於實現把消息數據從源傳送到目的地的方法，該組指令包括用於執行下列步驟的一條或多條指令與通信設備的作業系統無關地發送消息數據，所述發送至少部分通過作業系統無關訪問層進行；和與設備的硬體無關地傳輸消息數據，所述傳輸至少部分通過設備無關訪問層進行。在如下的章節中，通過參照只作為例子來用的附圖，更具體地描述本發明。從如下的說明和所附的權利要求書中可以清楚地看到本發明的其它優點和特徵。圖1顯示了根據本發明原理的軟體的邏輯排列功能塊；圖2是根據本發明原理的、用於消息交換的、在系統控制器與每個機框(shelf)之間的網絡；圖3顯示了根據本發明原理構造的共享總線布局；圖4顯示了根據本發明原理的、機框間消息的星形總線布局；圖5是根據本發明原理的、把消息發送到服務地點的客戶應用；和圖6是根據本發明原理的、核實部件功能的測試方法。具體實施例方式雖然從現在開始，參照顯示本發明優選實施例的附圖更全面地描述本發明，但是，從如下描述的開頭就應該明白，本領域的普通技術人員可以對這裡所述的發明進行修改，而仍然可以取得本發明的良好結果。因此，如下的描述應該被理解成面向本領域普通技術人員的概括性、原理性公開，而不是對本發明的限制。下面描述本發明的示範性實施例。為了清楚起見，並非實際裝置的所有特徵都加以描述。在如下的描述中，那些眾所周知的功能或結構將不作詳細描述，因為它們有可能使本發明的重點不突出。應該認識到，在任何實際實施例的開發過程中，必須作出許多裝置特有的決定，以達到開發者的特殊目的，譬如說，遵從因裝置而異的系統相關和商業相關約束。此外，還應該認識到，這樣的開發努力也許既複雜又費時，但是，仍然是從本公開中獲益的本領域普通技術人員要承擔的例行任務。進程間通信(IPC)指的是在同一臺計算機內，或者在網絡上，數據在一個進程與另一個進程之間的交換。IPC隱含著保證對請求作出響應的協議。IPC可以由程序自動執行。圖1顯示了根據本發明原理的軟體的邏輯排列功能塊。圖1顯示了增強型服務110、連接管理112、公共代理114、公共OAM(操作、管理、和維護)116、統一進程間通信(UIPC)118、設備無關訪問(DIA)層120、設備驅動器122、實時作業系統(RTOS)124、硬體126、作業系統無關訪問(OIA)層128、異步傳輸模式(ATM)130、同步數字分層結構(SDH)和準同步數字分層結構(PDH)132、分組語音通信(VoiceoverPacket(VoP))134、綜合數字環載波(IDLC)136、窄帶(NB)用戶138、寬帶(BB)用戶140、和網際網路協議(IP)142。圖1顯示了沿水平方向排列的一些項目，還顯示了沿垂直方向排列的其它項目。首先討論水平方向。設備的公共項，譬如，增強型服務、連接管理、公共代理、公共OAM(操作、管理、和維護)、統一進程間通信(UIPC)、和實時作業系統(RTOS)等被顯示成沿水平方向排列。現在討論垂直方向。其它項目，譬如，異步傳輸模式(ATM)、同步數字分層結構、準同步數字分層結構(PDH)、分組語音通信(VoP)、綜合數字環載波(IDLC)、窄帶(NB)用戶、寬帶(BB)用戶、和網際網路協議(IP)被顯示成沿垂直方向排列。沿垂直方向排列的那些項目通常依賴於所使用設備的每個特定部分的特性。取決於所使用的各種通信系統，可以去掉沿垂直方向排列的軟體模塊之一。圖1的上部，即從「增強型服務」到「公共OAM」，依賴於軟體的應用。本發明涉及與系統單元的內部部分和外部通信系統兩者通信的統一進程間通信(UIPC)。系統的內部通信是在UIPC的作業系統部分中處理的，而系統的外部通信是在包括UIPC的硬體部分的那些部分中處理的。作業系統無關訪問層(OIA)與作業系統的類型無關地處理通信功能。設備無關訪問層(DIA)包含在本發明中。UIPC包括應用程式接口(API)和如下所述的協議棧。圖2是根據本發明原理的、用於消息交換的、在系統控制器與每個機框之間的網絡。圖2顯示了支持的網絡布局，包括單元管理系統210、帶有插件213的系統控制器212、帶有插件215的機框2(214)、智能設備216、帶有插件219的機框3(218)、和帶有插件221的機框4(220)。在圖2中，為了讓機框4(220)與系統控制器212通信，儘管機框4(220)與系統212之間的通信在物理上穿過機框3(218)，但是，存在著一條根據本發明原理構成的、在機框4(220)與系統212之間的想像的直通路徑。在下文被標為「總線布局」的部分中，當把本發明與總線布局的類型無關地應用於機框間的相互通信時，本發明的靈活性就顯現出來了。換句話來說，在共享總線型的布局(圖3)和在星形總線型的布局(圖4)中，本發明都可以應用於機框間的相互通信。圖3顯示了根據本發明原理構造的共享總線布局。圖4顯示了根據本發明原理的、機框間消息的星形總線布局。在下文被標為「應用類型」的部分中，通過對第一機框的插件與不同機框的插件進行通信時的通信過程加以考慮(圖5)，本發明的其它特徵就呈現出來了。圖5是根據本發明原理的、把消息發送到服務地點的客戶機。在下文被標為「應用ID」的部分中，顯示了用於根據系統用戶刪除和添加軟體的軟體的應用ID。在下文被標為「UIPC網絡地址」的部分中，顯示了要用於讓消息到達可以路由消息的處理器或實體(entity)的網絡地址。就軟體功能和部件接口來說，這裡包含了有關統一進程間通信(UIPC)部件的功能描述。UIPC提供了藉此在同一個插件、同一個機框、或不同機框上的各種任務之間路由消息的手段。如下的八個文件提供了本申請文件的背景和附加信息開放系統互連，基本參考模型，ITU-TX.200；開放系統互連，數字連結服務定義，ITU-TX.212；開放系統互連，網絡服務定義，ITU-TX.213；開放系統互連，傳輸服務定義，ITU-TX.214；公共軟體平臺系統結構文件，Aztek分號70881；DIA部件描述，Aztek分號70891；UIPC詳細級別設計，LTITL分號SDC005-UIPC；和OIA部件DLD，LTITL分號SDC005-OIA。本申請文件自始至終都使用如下的定義和縮寫術語「API」指的是應用程式接口；術語「EMS」指的是單元管理系統；「跳段(hop)」指的是在數段相繼路徑上傳輸消息的過程中的一段路徑；術語「連結」指的是兩個物理端點之間的連接；術語「NE」指的是網絡單元；術語「網絡單元」指的是單元管理系統獨立管理的一個單位(一個網絡單元可以由一個或多個局部的或地理上分散的機框組成)；術語「節點」指的是可獨立尋址的、UIPC通信網絡的任何一個單元；和術語「智能端點」指的是可以接收消息的、附在插件上的設備(這種設備的例子有DSL數據機)。術語「UIPC」指的是統一進程間通信(UIPC也可以指通用進程間通信)；術語「OIA」指的是作業系統無關適配層；術語「DIA」指的是設備無關適配層；術語「DSL」指的是數字用戶線；術語「IAD」指的是綜合訪問設備；術語「RTOS」指的是實時作業系統；和術語「TCP/IP」指的是在傳輸控制協議/網際網路協議。部件綜述本發明的UIPC部件意在用於各種應用之間的所有處理器內和處理器間通信。這個部分包括本發明支持的網絡單元布局的描述、本發明所使用的尋址的基本描述、和本發明的UIPC支持的應用模型的描述。如下特性包含在本發明的UIPC和本發明的其它單元中。UIPC提供了網絡單元內部任何地方的任務之間的雙向消息傳送。UIPC允許異步發送消息的應用。應用程式接口(API)將沒有阻塞地直接返回。UIPC允許不會超時地發送消息和同步等待響應的應用。UIPC使基礎性物理傳輸機制抽象化。要求需要與服務通信的應用知道那個服務的位置。在下文標為「應用類型服務」的部分中描述服務應用。如下的附加特性包含在本發明的UIPC和本發明的其它單元中。UIPC提供藉此可以把消息廣播出去的機制。無需改變高層協議，就能夠改變低級UIPC協議。無需改變低層協議，就能夠改變高級UIPC協議。UIPC一條鏈路一條鏈路地檢測傳輸錯誤和重試有錯分組(這意味著，要求有管理每條鏈路的、協議的鏈路層以使那條鏈路是可靠的)。同一個UIPC應用程式接口(API)用於處理器內和處理器間通信。UIPC進行大消息的分割和組裝。UIPC允許端到端面向連接和無連接通信。UIPC提供允許調試輸出的機制。UIPC協議參數在運行期間是可以設置的。UIPC提供為每條鏈路設置最大傳輸單元的機制。UIPC使跳段與改變最大傳輸單元相適應。UIPC支持實時關鍵性消息的消息優先級。UIPC是與作業系統無關的。UIPC讓消息透明地從控制器傳送到附在插件上的設備(這些設備可以，也可以不遵從UIPC協議)。UIPC讓消息從網絡單元內的任何一個機框路由到另一個機框。UIPC提供用於報告協議錯誤和統計的應用程式接口(API)。除了本發明的上述特性之外，還為本發明考慮到實時系統設計的特性。實時系統設計的相關特性如下。在實時系統中，一些消息必須在某種時間限制下發送。這意味著，在協議棧的最低級上的分組的最大傳輸單位必須小到足以使大消息不會浪費通信流水線的帶寬。在實時系統中，處理器或通信帶寬可能是有限的。這意味著對效率的需要。消息的處理應該是最低限度的。應該使協議額外開銷達到最小。要在功能與效率之間權衡利弊。像TCP/IP那樣的協議棧是富特徵的，但是實現這些特徵需要花費許多額外開銷。從效率的角度來考慮，使協議與實時系統相適應最有可能使協議額外開銷達到最小，並且，最適合於大多數普通類型的消息傳送。這意味著特徵受到限制。需要附加特徵的少數幾種應用也許不得不參與到供應某個附加功能中去，而不依賴於協議棧來供應所需特徵。在實時系統中，實時作業系統(RTOS)一般不讓任務在多個端點上等待。其結果是，通常藉助於可以從多個源，譬如，其它任務或中斷服務例程(ISR)接收消息的一個消息隊列完成各種任務。這意味著UIPC需要支持藉助於單個消息隊列構造起來的多個任務。在實時系統中，實時作業系統(RTOS)一般提供所有任務可以訪問所有存儲器的平坦(flat)存儲模式。在這種模型中，幾個任務可以共享數據，而不會有在消息中傳送數據的額外開銷或用於實施共享存儲器的作業系統額外開銷。一些實時作業系統(RTOS)可以提供把存儲器限制在某個任務可以訪問的保護存儲模式。在這樣的模型中各種任務之間的通信依賴於消息傳送或共享存儲器的使用。存儲器模型不影響在本說明書中提到的應用程式接口(API)或協議定義。但是，它的確影響這些部分的實現。在作出實現建議的地方，本說明書假設更普通的平坦存儲模型。網絡單元布局網絡單元代表獨立管理的設備構件。網絡單元可以由一個或多個局部的或地理上分散的機框組成。網絡單元分布的方式稱為網絡單元布局。本發明的UIPC支持的布局是樹結構。可能存在一個與多個其它機框相連接的主系統控制器機框。對著其它機框的任何機框可能有，也可能沒有把通信路徑與系統控制器相連接的直接硬體。為任何機框之間的通信配備軟體路由功能。它與網絡布局無關。存在兩種類型的路由機制一種是靜態路由，另一種是動態路由。除了機框之外，每個機框包含數個插件。插件可以包含可以，也可以不通過UIPC協議進行通信的、附在它們身上的智能設備。這些插件或設備可以被當作樹結構的分支或葉片。圖2是根據本發明原理的、用於消息交換的、系統控制器與每個機框之間的網絡。圖2顯示了支持的網絡布局，它包括單元管理系統210、帶有插件213的系統控制器212、帶有插件215的機框2(214)、智能設備216、帶有插件219的機框3(218)、和帶有插件221的機框4(220)。圖2顯示了設計本發明的UIPC的網絡布局。本發明的UIPC支持在單個插件上的任務之間、在同一個機框上的不同插件上的任務之間、在任何機框上的任務之間、以及在任何機框和所附智能設備(例如，數字用戶線路數據機和綜合訪問設備)上的任務之間的消息交換。請注意，這裡假設，如果需要的話，可以認為需要在兩個機框之間流動的消息是通過系統控制器機框212路由的。這樣就可以使協議簡單化，並且降低了與管理更一般的網絡布局的、諸如網際網路協議(IP)之類的協議相聯繫的額外開銷。還請注意，單元管理系統210也可以通過UIPC進行通信。消息可以在單元管理系統210與任何機框上的任何插件之間路由。就UIPC而言，單元管理系統(EMS)210看起來正好像任何其它機框。總線布局上述網絡布局從外部的觀點定義了本發明的系統。現在來描述總線布局。總線布局從內部的觀點描述本發明的機框。總線布局的設計影響消息如何流過機框上的插件和在機框上的插件之間流動。總線布局可以是共享總線型的(圖3)，也可以是星形總線型的(圖4)。在共享總線型布局中，任何插件都可以與任何其它插件通信。但是，有些共享總線設計只讓插件與單個主機通話。在星形總線型布局中，每個插件與中央集線器連接。與布局無關，必須存在一些與外部世界的連接。從外部源到達機框的控制消息將由處在兩種總線布局之一下的單個插件來處理。因此，一個插件總有一些在外部系統與插件之間路由消息的功能。圖3顯示了根據本發明原理構成的共享總線布局。圖3描繪了含有插件1(312)、插件2(314)、插件3(316)、插件4(318)和插件5(320)的機框310。在圖3中，機框310包括與另一個機框(除了機框310之外)存在外部連接的插件1(312)。如插件4(318)發送的消息所示，與其它機框交換的消息由插件1(312)路由。對於在插件之間路由消息，圖3還顯示了兩種可能選擇。在讓任何插件與任何其它插件通話的設計中，如果插件知道彼此的地址，那麼，可以在這些插件之間直接發送消息。這是插件4(318)與5(320)之間所示的。這是一種在插件之間獲取消息的最有效手段。但是，為了簡單起見，如從插件2(314)發送到插件3(316)的消息所示，裝置可以選擇通過中央路由器312路由所有插件間消息。這種方法也可以用於要求所有消息流過主機的共享總線。請注意，如後所述的UIPC包括用於每個插件和用於可以包容直接插件到插件路由和集中路由兩者的機框的路由機制。它只依賴於每個插件的路由表是如何布居的。圖4顯示了根據本發明原理的、用於機框間消息的星形總線布局。圖4描繪了含有插件1(412)、插件2(414)、插件3(416)、插件4(418)和插件5(420)的機框410。如圖4所示，在星形總線布局中，所有消息都穿過中央路由器412。應用類型有各種類型可能存在的應用。為了便於討論，一個應用是作為一個任務實現的。所有應用可能都需要利用UIPC。一些應用通常不與其它應用交互。這些應用被稱為獨立應用。其它應用提供適合於其它應用的服務。這些應用被稱為服務。與服務交互的任何應用被稱為客戶。一些客戶應用也可以是服務本身。除了應用類型之外，對於每個任務，很有可能存在著某種父母/子女(parent/child)關係。甚至獨立任務也會存在創造它的某種任務(即，它的父母)。為了維護的目的，父母可能需要與他們的子女通信。例如，母任務可能想要它的子女作出強制回應，以確信它正在正常工作。如下所述的是三種應用類型(服務型，客戶型，和獨立型)，以及在應用之間的示範性客戶機/伺服器消息流動。第一種應用類型是服務型。服務是為其它應用(例如，客戶)完成特定任務，譬如，控制對公共資源的訪問實現的。對於客戶來說，如何或在哪個插件上，和可能哪個機框實現服務是無關緊要的。服務作為抽象概念的使用使客戶任務與服務所處的位置無關地利用服務。這種設計是易於改變的，因為它使服務、插件或機框內的工作部門可以不影響客戶應用地發生改變。只有在一些情況下，應用才需要與另一個節點上的特定插件通話。服務利用熟知應用ID，通過UIPC登記它們自己。應用ID類似於向伺服器開放插座連接時使用的傳輸控制協議(TCP)埠號。當與服務通信時，客戶機需要知道服務的應用ID。如果客戶機需要與特定單元的硬體，譬如，機框或機框上的具體插件上的服務通話，那麼，它還必須指定網絡地址。熟知服務的例子有管理OAM(操作、管理、和維護)相關請求的OAM任務，或負責接收報警信號的報警信號管理任務。第二種應用類型是客戶型。客戶是與服務通話的任何應用。與另一個服務通話的服務被認為是那個其它服務的客戶。也不是服務的客戶不含有熟知應用ID。但是，為了讓服務能夠把響應發送給客戶，UIPC將把一個應用ID指定給客戶的消息隊列，以便可以把響應路由給客戶。第三種應用類型是獨立型。獨立應用是不與其它應用通話的那些應用。與客戶一樣，獨立應用不含有熟知應用ID。現在來討論有關示範性客戶機/伺服器消息流動的信息。存在著許多種各種應用之間的消息流動的組合。理解消息流動的關鍵是UIPC包含了確定應該把消息發往何方的路由機制。系統中的每個插件都具有路由功能。每個機框也具有在插件或機框之間分配消息的路由功能。為了展示UIPC支持的最複雜路由，現在請參照圖5。圖5是根據本發明原理的、把消息發送到服務地點的客戶應用。圖5描繪了系統控制器機框510和機框516。系統控制器機框510含有機框控制器512和插件516。機框516含有機框控制器522和插件526。插件526含有可以是任何任務530的客戶應用530。插件526含有UIPC528。機框控制器522含有UIPC524。插件516含有服務X520和UIPC518。機框控制器512含有UIPC514。圖5描繪了把消息發送到服務X520的客戶應用530。客戶應用530由任何任務530來表示。在圖5中，服務X520是在系統控制器機框510上實現的，和客戶是在某個其它機框516上實現的。客戶請求UIPC528藉助於系統控制器510的網絡地址把消息發送到服務X520。在客戶機插件526上的UIPC528把消息轉發到機框路由器。機框路由器查找目的地網絡地址。如果它與我的網絡地址不符，那麼，就把消息路由到系統控制器510。系統控制器510上的機框路由器查找目的地網絡地址，並且確定是在機框510中的插件516上實現的。把消息發送給那個插件516。然後，在那個插件516上的UIPC518把消息路由到服務X520。應用ID這個部分說明如何把熟知應用ID指定給應用，供應用使用，和為應用所知。在插件中可用的應用ID的最大號碼是UIPC_MAX_APP_ID。在插件中可用的應用ID的最大號碼是得到與允許的進程間通信(IPC)隊列的最大號碼相對應的作業系統無關訪問層(OIA)允許的。熟知應用ID是由應用從UIPC_MAX_WEL_KNOWN_APP限定的一列應用ID中，即UIPC_MAX_APP_ID的值的前半部分中，選擇出來的。它像與傳輸控制協議(TCP)一起使用的熟知埠號。在這種情況下的應用被定義為除UIPC之外的任何東西。這種應用包括公共操作、管理、和維護(OAM)部分，以及其它應用。對於不是熟知應用的應用，從UIPC_MAX_APP_ID限定的那些值的其它後半部分中分配應用ID。這個範圍是從UIPC_DYN_APP_ID_START(UIPC_MAX_WEL_KNOWN_APP+1)到UIPC_MAX_APP_ID。當任務想要發送或接收消息時，指定這些應用ID，一旦任務完成了消息的發送或接收，就釋放這些應用ID。當這些應用ID被釋放時，可以重新使用它們。UIPC網絡地址網絡地址用於讓消息到達可以路由消息的處理器或實體。因此，每個插件、機框、機架(rack)、或智能端點擁有唯一的網絡地址。也可以把機框組織成也可以擁有唯一網絡地址的機架。也可以讓應用ID包含在告訴路由器哪個應用應該接收消息的消息中。更簡單地說，網絡地址讓消息到達插件，和應用ID讓消息到達插件上的任務。網絡地址必須能夠與機架、機框、插件、或附在插件上的智能端點的相聯繫。為此，定義了劃分成A、B、C、和D四個類別的32位地址。這類似於具有4個類別的網際網路協議(IP)尋址。每個類別包括8個位。類別A代表機架。類別B代表網絡單元中機框的地址。類別C地址代表插件。類別D地址代表智能端點。這種方案允許每個網絡或子網絡上擁有256個獨立的設備。地址類別的使用使路由器能夠屏蔽掉不關心的區段。這樣就簡化了路由表。例如，可能讓消息到達附在插件上的特定設備。由於所有想知道的是如何讓消息到達插件上，因此，機框路由器可以忽略地址的類別D部分。不需要有關附在插件上的設備的、在其路由表中的任何條目。同樣，由於所有想知道的是如何讓消息到達設備上，因此，插件上的路由器可以忽略地址的類別A和B部分。也可以把特殊地址定義成用於不知道或不應該使用特定地址的環境中。例如，一個插件上的應用可能需要與已知位於機框上、還不知道在什麼地方實現服務的服務通信。特殊地址也可以用在把地址動態地指定給路由器的地方。到未指定路由器(例如，一個插件)的網絡層控制消息可以包含特殊類型的地址，並且傳送使未指定路由器能夠具有新地址的信息。任何協議層也可以在通信協議控制消息的時候使用特定地址。通過特殊地址還可以支持消息的廣播。如下的特殊值可以用作地址的類別A、B、C、或D部分。路由器應該從類別A地址開始、一直到類別D地址處理它們，以確定如何路由消息。將描述的第一個特殊值是「任何位置」值。「任何位置」值是0xFF。當「任何位置」值在消息的地址當中時，把消息定向到可以在任何插件(類別C部分是這個值)或任何機框(類別B部分是這個值)上的服務。換言之，當地址的類別C部分具有值0xFF時，那麼，把消息定向到可以在任何插件上的服務，和當地址的類別B部分具有值0xFF時，那麼，把消息定向到可以在任何機框上的服務。如果路由器把這個地址看作類別值，那麼，應該把消息傳送到傳輸層。傳輸層將確定服務是否已經註冊成利用消息中的應用ID來接收消息。將描述的第二個特殊值是「這個位置」值。「這個位置」值是0xFE。如果地址的類別具有「這個位置」值，那麼，它就指示消息終止在接收消息的路由器上，或者，如果較低類別地址不包含「忽略(0xFD)」值，就終止在較低類別地址上。將描述的第三個特殊值是「忽略」值。「忽略」值是0xFD。如果類別具有「忽略」值，那麼，消息應該終止在不具有0xFD值的最高類別路由器上。「忽略」值用在把消息定向到特定機框或插件上。「忽略」值用在有關類別B和C路由器的路由器地址中。類別B路由器將具有像0xXXXXFDFD那樣的地址，和類別C路由器將具有像0xXXXXXXFD那樣的地址。還請注意，正像任何其它插件一樣，機框路由器處在上面的插件也將擁有它自己的地址。將描述的第四個特殊值是「廣播」值。「廣播」值是0xFC。接收包含「廣播」值的地址的路由器應該向它的路由表中與出現0xFC的類別匹配的所有地址廣播消息。例如，接收帶有0xXXXXFCFD的消息的機框將向插件的每一個發送消息。0xXXXXFCFC的值將使每個插件發送消息，並且將其轉發給所有類別D設備。將描述的第五個特殊值是「系統控制器」值。「系統控制器」值是0xFB。「系統控制器」值只應用於類別B地址。「系統控制器」值用在把消息特別發送給系統控制器機框的時候。現在給出有用地址的四個例子。應用把消息發送到這個機框上某處的服務0xFEFEFFFD。應用把消息發送到這個插件上的服務0xFEFEFEFD。應用把消息發送到可以在任何機框的任何插件上的服務0xFFFFFFFD。應用向系統中的所有插件廣播消息0xFCFCFCFD。部件描述本發明的UIPC劃分成兩個主要部分應用程式接口(API)和協議棧。應用程式接口為應用提供了無需知道協議的細節或如何執行協議，藉助於簡便的手段發送消息。為了清楚起見，為支持平坦存儲模式的作業系統給出推薦裝置。本發明的UIPC意在提供穿過同一機框上的插件或穿過機框的、在和不在處理器上兩者的任務間通信。本發明的UIPC負責讓消息到達它們的目的地。但是，消息的內容由應用負責。因此，UIPC不提供以機器無關格式表示用戶數據的機制。這將由表示層負責。由於UIPC意在用作實時協議，因此，不包含與表示層相聯繫的額外開銷。UIPC部件被設計成使把應用程式接口與協議處理分開。這就使不需要協議棧的有效處理器內通信，而同時可以使需要協議棧的處理器間通信。UIPC應用程式接口是作為程序庫而存在的，程序庫是從應用任務的環境(context)調用的。應用調用UIPC應用程式接口來發送和接收消息。為了進行處理器間消息傳送，UIPC應用程式接口可以與UIPC協議任務(也稱為「UIPC任務」)通信。通過把消息發送到UIPC協議任務的隊列中，就可以做到這一點。應用程式接口(API)是可以由任何任務使用的共享程序庫。應用程式接口把接口提供給UIPC提供的所有外部功能。應用程式接口無需通過UIPC任務，就可以處理處理器內操作。通過檢查接受的端點處理，看一看它們是代表在處理器上的端點，還是代表不在處理器上的端點，就可以做到這一點。如果在處理器上，那麼，通過調用作業系統無關訪問層(OIA)消息傳送應用程式接口，把消息直接發送到由端點所指消息隊列中。如果不在處理器上，那麼，把消息發送到UIPC協議任務的消息隊列中。調入Uipc_InitCardContext初始化本發明的UIPC。UIPC內部表全局表UIPC全局表全局表包含有關具體插件中的所有任務的信息。在全局中的每個條目是一個任務控制塊(TCB)。每個任務控制塊含有任務專用信息。任務控制塊的第一欄是任務ID。任務控制塊中的第二欄是應用ID。這是任務的主隊列的應用ID。每個任務含有動態消息管理表(handlertable)、靜態消息管理表、和動態消息類別表。每當任務調用Uipc_RegisterOneTimeApi時，就在任務的動態消息管理表中形成一個條目。在動態消息管理表中的條目不是永久的。一次性應用程式接口的響應一到達，就刪除這個條目。動態消息管理表是利用平衡二叉樹(binarytree)實現的。每當任務調用Uipc_RegisterMsgHandler時，就在靜態消息管理表中形成一個條目。靜態消息管理表專用於觀察應用程式接口。與動態消息管理表不同，靜態消息管理表中的條目是永久的。靜態消息管理表是利用陣列實現的。每當任務調用Uipc_GenerateTempMsgClass時，把消息類別返回到任務，並且在動態消息類別表中進行必要的更新，以便特定的消息類別變成被使用的。每當任務調用Uipc_FreeTempMsgClass時，UIPC就在動態消息類別表中作必要的修改，以便將來可以使用特定的消息類別。動態消息類別表也被當作陣列來實現。全局表包含到上述所有表格的指針。除此之外，全局表還包含到任務的空閒消息管理函數的指針。全局表還包含對於每個任務來說，必須用在Uipc_RcvLoop內的等待時間。每當在Uipc_RcvLoop應用程式接口內時，就在等待時間內查詢全局表。由於全局表被所有任務訪問，因此，旗語(semaphore)將保護全局表。這個旗語是在Uipc_InitCardContext期間建立起來的。每當調入Uipc_InitTaskContext時，藉助於為那個任務的tidandwaitTime輸入的有效值，在全局表中形成一個條目，並且為靜態消息管理表和動態消息類別表分配存儲器。把appId、到空閒消息管理表的指針、和到動態消息管理表的指針設置成NULL.在Uipc_SetMainQueue期間，填充appId，和在Uipc_RegisterIdleHandler期間，填充到空閒消息管理程序的指針。動態消息管理表每個任務必須完成這個動態消息管理表。這個表專用於一次性應用程式接口(API)。UIPC動態消息管理表動態消息管理表在其中含有三欄。第一欄是消息類別，第二欄是回調函數指針，和第三欄是定時器管理。每當任務調用Uipc_RegisterOneTimeApi時，就在任務的動態消息管理表中形成一個條目。每當消息藉助於像UIPC_MSG_RSP那樣的消息方向到達時，就利用消息類別查找該表格，以找出相應的回調函數。在調用回調函數之後，從任務的動態消息處理表中刪除該條目。動態消息處理表中的條目不是永久的。為了從動態消息處理表中刪除條目，要調用UIPC專用應用程式接口Uipc_DeleteMsgHndlrTableEntry。一次性應用程式接口的響應一到達，就刪除這個條目。即使出現超時情況(如果在特定時間內響應沒有到達)，也要刪除動態消息處理表中的條目。通過UIPC控制數據把有關消息到達或超時的情況告知上層。動態消息處理表是利用平衡二叉樹實現的。UIPC靜態消息管理表每個任務必須完成靜態消息管理表。UIPC靜態消息管理表每當任務調用Uipc_RegisterMsgHandler時，在靜態消息管理表中形成一個條目。靜態消息管理表專用於觀察應用程式接口。每當消息藉助於像UIPC_MSG_REP或UIPC_MSG_REQ那樣的消息方向到達時，就利用消息類別查找該表格，以找出相應的回調函數。如果找到條目，那麼，就調用回調函數。與動態消息處理表不同，靜態消息管理表中的條目是永久的。靜態消息管理表是利用陣列實現的。因為每個表擁有它自己的靜態消息管理表，所以不需要旗語來保護這個表。UIPC動態消息類別表每個任務必須完成動態消息類別表。每當任務調用Uipc_GenerateTempMsgClass時，把靜態消息類別範圍(從UIPC_DYN_MSG_CLASS_START到UIPC_MAX_NO_DYN_MSG_CLASS)內的自由消息類別賦予任務。如果沒有自由消息類別可用，那麼，向應用程式接口用戶報告沒有可用的。在分配了自由消息類別之後，更新這個表格，以便使特定消息類別變成被使用的。每當任務調用Uipc_FreeTempMsgClass時，就釋放消息類別，以便將來可以使用特定的消息類別。因為每個表擁有它自己的動態消息類別表，所以不需要旗語來保護這個表。UIPC棧為了進行處理器間消息傳送，UIPC應用程式接口(API)可以與UIPC協議任務(也稱為「UIPC任務」)通信。通過把消息發送到UIPC協議任務的隊列中，就可以做到這一點。UIPC路由程序庫也顯示了。UIPC路由程序庫使UIPC應用程式接口或UIPC協議任務能夠確定如何路由消息。這是基於應用ID和網絡地址的。對於處理器間通信來說，難以勝任讓所有消息都經過UIPC協議任務。因此，UIPC應用程式接口首先調用路由程序庫，看一看是否可以把消息直接發送到同一處理器上的任務隊列中。如果不可以，UIPC應用程式接口就把消息轉發到UIPC協議任務。UIPC協議任務將通過協議棧傳送消息。在棧的網絡層上，路由應用程式接口將再次被調用，以確定應該在哪條物理鏈路上發送消息。請注意，UIPC任務可以由子任務組成。這取決於協議棧層的實現。但是，從UIPC應用程式接口的角度來看，只需要知道有關單個UIPC協議任務的情況，並且與單個UIPC協議任務通信。在UIPC應用程式接口把消息傳送給UIPC之後所發生的情況是隱藏的。路由程序庫上的注釋也是恰如其份的。路由是由協議的傳輸層和網絡層兩者負責的。網絡層確定應該把消息發送到哪條物理鏈路上。網絡層根據網絡地址作出這樣的確定。傳輸層確定應該把消息發送給哪個應用。傳輸層根據應用ID和網絡地址兩者作出這樣的確定。這取決於如何完成這些路由表的實現。可以讓網絡層的路由表和傳輸層的路由表彼此分離，以便去耦這兩層。但是，從在協議任務外部的功能(例如，UIPC應用程式接口)的角度來看，要求某些路由功能，而這與如何實現堆棧無關。因此，路由程序庫作為一個獨立的條目顯示出來的。實際上，可以僅把稀(thin)應用程式接口加在網絡層和傳輸層展示的功能上面。協議層開放系統互連(OSI)堆棧模式用於定義存在於通信協議中的功能層。開放系統互連(OSI)是網絡結構的模型，並且是一組實現它的協議。可以把這組協議稱為協議棧。可以在7個層之間劃分OSI結構，這7個層從最低到最高依次是(i)物理層、(ii)數字鏈路層、網絡層、(iv)傳輸層、(v)會話層、(vi)表示層、(vii)應用層。本發明的UIPC堆棧模式符合開放系統互連(OSI)定義，但是，沒有必要包括開放系統互連(OSI)規定的所有7個層。UIPC協議被修整得適合於實時系統，並且不需要開放系統互連(OSI)層的所有功能。在如下的部分中描述本發明的各個層的功能。但是，在討論每層的規定之前，先把如下的一般要求應用於每一層。這些要求被當作實現這些層的原則。每層的首標應該包含協議鑑別符。該鑑別符指示在消息中正攜帶著哪種協議或協議組合。它在首標內通常是2個或3個位。這樣，將來無需改變其它協議，就可以實現不同的協議。例如，正在被網絡層處理的輸入消息可能含有指示哪個協議模塊應該是要下一個處理消息的、在網絡層首標中的協議鑑別符。如果UIPC想要支持諸如傳輸控制協議(TCP)或用戶數據報協議(UDP)之類的傳輸層協議，協議鑑別符就告訴網絡層是否把消息傳遞給傳輸控制協議或用戶數據報協議模塊。用戶數據報協議(UDP)指的是提供數據報服務的網際網路標準網絡層、傳輸層和會話層協議。用戶數據報協議是像TCP那樣，放在網際網路協議(IP)上面的層上無連接協議。一些協議層可能依賴於其它協議層，並且，不能獨立使用。例如，作為依賴於物理高級數字鏈路控制(HDLC)層的鏈路層協議的LAPD就是這種情況。縮寫「LAPD」代表D信道上的鏈路訪問過程。每一層都保存消息優先級。高優先級消息或數據段(在需要分段的長消息的情況下)總是在其它消息或數據段之前發送。值得推薦的是，本發明只支持兩種優先級，即正常的和高的。任何更多的優先級都有可能引起混亂。但是，本發明可以支持其它的優先級。每一層都應該提供標誌，以便使那一層上擴充的協議在將來可以擴充。如何把它付諸實施的例子是為網絡層預訂提供擴充尋址的特殊標誌值。每一層可以定義在端點的同等層之間交換的特殊控制消息。這些控制消息可以讓每一方都能協商協議參數或進行流控制。如下的部分描述每個協議層的特性和責任。每個部分還包括該層應該提供的一系列原語。原語的作用是顯示向其它軟體(即，相鄰上協議層)提供的外部接口。它們不描述在兩個端點之間傳遞的實際消息。這裡不描述這樣的消息的定義和任何相關的狀態機。在進行詳細設計時再定義它們。原語是利用國際電信聯盟(ITU)專門術語命名的，並且被分類成Request(請求)、Respone(響應)、Indication(指示)和Confirm(確認)。Request這是層必須支持的函數，其作用是由在它上面的相鄰層調用去請求一些動作。Respone這是由遠端在接收到請求響應的指示時調用的。其結果是，請求者將接收到確認。Indication這是發生了某一事件的通告。意圖是讓相鄰上層或生成的代碼過一會接收這些指示。大多數指示是遠端通過請求，啟動一些動作的結果。Confirm這是已經對請求作出響應的確認。每個原語都含有與之相聯繫的原語專用數據。在層與層之間傳遞原語的機制在這裡不是特別規定的，因為它是層的詳細設計的一部分。注意到必須定義最大傳輸單位(MTU)也是很重要的。最大傳輸單位(MTU)定義最大消息尺寸。在這個尺寸以下的任何消息都以單個消息發送。因此，高優先級的時間關鍵因素的消息可以在不長於兩個長度為最大發送單位的消息所花費的時間(一個時間間隔用於發送消息，另一個時間間隔用於發送高優先級消息)的時間內得到處理。為了保證正好是這種情況，在網絡層消息、鏈路層消息、和物理層(例如，高級數據鏈路控制)幀之間存在著一一對應關係。需要在這些等級上把消息捆綁在一起，以便有助於保證實時性能。確定最大發送單位是應用設計的一部分。這樣，不將其定義成UIPC的一部分。但是，UIPC的確定義了只有UIPC部件可見的內部應用程式接口(API)，以便設置最大發送單位。最大發送單位由應用性能要求、應該獲取消息的跳段數、和正在使用的通信鏈路的速度來決定。存在著源自把消息從一個節點路由到下一個節點的網絡的複雜因素。如果最大發送單位(MTU)對於每個跳段來說，都是不同的，那麼，必須採取一些措施來解決不一致性問題。問題出在一個節點發送MTU大的消息，而在具有小MTU的跳段上通過節點轉發消息的時候。一個節點難以知道消息在上面行進的所有鏈路的所有MTU。事實上，發送節點甚至可能不知道在什麼鏈路上行進。它所知道的就是讓消息到達相鄰節點。因此，在每個節點上的協議棧應該解決與那個節點相連接的鏈路上的MTU尺寸之間的差異。如本說明書下文的「網絡層」部分所述的，網絡層具有消息分段功能。這應該被用來把較大的MTU分段成較小的MTU。如果網絡層在每個節點上沒有這樣做，那麼，另一種可選方案將建立端到端連接，並且通過所有節點協議最大MTU應該是什麼。但是，這種方式將導致額外開銷，並且對無連接消息力不從心。UIPC靜態消息管理表每個任務必須完成靜態消息管理表。UIPC靜態消息管理表每當任務調用Uipc_RegisterMsgHandler時，在靜態消息管理表中形成一個條目。靜態消息管理表專用於觀察應用程式接口。每當消息藉助於像UIPC_MSG_REP或UIPC_MSG_REQ那樣的消息方向到達時，就利用消息類別查找該表格，以找出相應的回調函數。如果找到條目，那麼，就調用回調函數。與動態消息處理表不同，靜態消息管理表中的條目是永久的。靜態消息管理表是利用陣列實現的。因為每個表擁有它自己的靜態消息管理表，所以不需要旗語來保護這個表。UIPC動態消息類別表每個任務必須完成動態消息類別表。每當任務調用Uipc_GenerateTempMsgClass時，把靜態消息類別範圍(從UIPC_DYN_MSG_CLASS_START到UIPC_MAX_NO_DYN_MSG_CLASS)內的自由消息類別賦予任務。如果沒有自由消息類別可用，那麼，向應用程式接口用戶報告沒有可用的。在分配了自由消息類別之後，更新這個表格，以便使特定消息類別變成被使用的。每當任務調用Uipc_FreeTempMsgClass時，就釋放消息類別，以便將來可以使用特定的消息類別。因為每個表擁有它自己的動態消息類別表，所以不需要旗語來保護這個表。網絡層網絡層負責獲取處理器之間的消息。網絡層具有如下特性。網絡層根據網絡地址路由消息。網絡層檢查網絡地址，以確定是否把消息指定到接收它的處理器，或者是否需要通過另一個接口轉發消息，讓它到達它的最後目的地。網絡層支持消息的分段/組裝。因為不同的鏈路可以具有尺寸不同的最大傳輸單位(MTU)，所以，與網絡層可以不讓消息通過傳輸層地路由它們的事實結合在一起來考慮，網絡層也可以處理MTU尺寸之間的轉換。這意味著在這一層上支持消息分段和組裝。網絡層對應於無狀態操作。因為網絡層不提供可靠的點到點或端到端消息傳輸，所以它是無狀態的。一旦消息被發送出去，就忘掉它。點到點的可靠性是由數據鏈路層來負責的。必要時，端到端的可靠性由傳輸層來負責。類別D路由-特殊情況網絡層還必須支持把消息路由到附在插件上的設備中。這些設備的一些可以通過UIPC通信。在這種情況中，它們將具有類別D地址，並且，把消息路由到這些地址就像把消息路由到任何其它地址一樣。如果它們不運用UIPC，網絡層必須實施藉此設備可以具有虛地址的措施。在這種情況下，代理應用將在插件和寄存器上運行，以接收有關特定類別D地址的消息。代理應用負責接收這些消息和把它們轉發到各個設備。另外，這些消息不需要利用傳輸層協議，因為，並不把它們指定給各種應用。請注意，原語只鬆散地對應於國際電信聯盟(ITU)定義。請參見上述文件「開放系統互連，網絡服務定義，ITU-TX.213」。這是因為國際電信聯盟(ITU)使用了比UIPC所需的更複雜的模型。它把網絡層模型化成兩個端點之間的連接。面向連接網絡層比網絡層要複雜得多，因為已經為它提供了鏈路層。另外把UIPC的網絡層模型化成像不需要連接的網際網路協議(IP)那樣的基於分組的協議。另外，國際電信聯盟(ITU)不定義指定網絡地址的任何機制。假設這個信息以某種方式適用於網絡層。因此，UIPC定義了附加的地址相關原語，以便網絡層具有執行地址指定功能的接口。原語與網絡層的外部接口顯示在表3的原語中。表3-網絡層原語和參數一覽表這些參數定義如下。術語「遠端網絡地址」指的是把操作對準它的節點的地址。術語「優先級」指的是用戶數據的優先級。術語「協議描述符」指的是在用戶數據中攜帶更高級協議的標識符。術語「用戶數據」指的是發送的數據。用戶數據對網絡層是透明的。請注意，原語只鬆散地對應於國際電信聯盟(ITU)定義。請參見上述文件「開放系統互連，網絡服務定義，ITU-TX.213」。這是因為國際電信聯盟(ITU)使用了比UIPC所需的更複雜的模型。它把網絡層模型化成兩個端點之間的連接。面向連接網絡層比網絡層要複雜得多，因為已經為它提供了鏈路層。另外把UIPC的網絡層模型化成像不需要連接的網際網路協議(IP)那樣的基於分組的協議。另外，國際電信聯盟(ITU)不定義指定網絡地址的任何機制。假設這個信息以某種方式適用於網絡層。因此，UIPC定義了附加的地址相關原語，以便網絡層具有執行地址指定功能的接口。根據網絡層所需的操作，如下信息應該是網絡層消息首標的組成部分目的地地址、源地址、網絡消息類型(可以是網絡層控制或用戶數據消息的某種類型)、分段信息(與分段的消息有關的)、控制(用於網絡層控制消息和指示消息的類型)。傳輸層傳輸層負責應用之間的端到端通信。它具有如下特性把消息路由到作為端點的應用或服務-傳輸層引入了應用ID的概念。應用可以登記它們自己，以接收為特定應用ID指定的消息。這支持客戶機/伺服器應用。這一層將確定是否應該把消息路由到這個處理器上的任務中。以消息為基礎-藉助於寫操作和緩衝器調用傳輸層，在單個讀操作中，在遠端上接收緩衝器中的數據。可以把緩衝器看成是一種消息。這可以與基於流方法相對照，在基於流的方法中，讀操作與在單個寫操作中還是在多個寫操作中發送字節無關地簡單接收偶爾適用的字節。提供無連接消息傳送。在這種情況中，依靠應用和低層來保證可靠的端到端傳輸。為了降低額外開銷，無連接消息傳送不追究遠端實際上是否接收到消息和消息是否是有效的。低層通過CRC(循環冗餘校驗)檢驗已經保證了消息是有效的，並且讓消息逐條鏈路地重新發送。一般來說，如果應用必須知道遠端應用接收到消息，它就期望應用級確認。由於這些其它層共同負擔保證有效端到端傳輸的工作，因此，可以使用無連接操作。但是，請注意，傳輸層的確具有捨棄掉部分消息的機制，在那裡長消息的某些段可能已經被丟棄掉了。由於這種無連接消息傳送比面向連接消息傳送更易實現，因此，建議首先實現這種無連接消息傳送。提供面向連接消息傳送。在這種情況中，為應用建立和維持端到端連接。這在功能上類似於傳輸控制協議(TCP)網絡接口。當在面向連接路徑上設置和通信時，存在著附加的額外開銷和複雜性。因此，建議只有當不指望通信那麼可靠時，或當資源或實時考慮較少時才使用這種模式。雖然在這裡沒有規定，但是支持無連接和面向連接消息傳送的低級設計可能包括兩個獨立的傳輸層模塊或實現兩種類型的消息傳送的單個模塊的使用。多路復用來自可變端點的消息-假設多個端點可以發送同一個應用，傳輸層根據源地址組裝消息。建造路由表為了把消息路由給特定的應用，傳輸層負責建造把應用ID的路由表構造成真實消息隊列ID的映射。對路由表的訪問需要通過只有UIPC部件看得見的內部應用程式接口(AP1)展示出來。這樣做是需要的，以便可以通過UIPC應用程式接口功能進行有效查詢，以確定應該在處理器上，還是不在處理器上路由消息。原語到傳輸層的外部接口顯示在表4的原語中。請注意，連接建立和釋放原語只應用於面向連接模式。表4-傳輸層原語和參數一覽表術語「應用ID」指的是應用的標識符。它用於區分可以具有給定網絡地址的處理器提供的個別服務。應用可以具有熟知ID，從而其它其它可以尋址它們。應用ID是可移植跨接處理器的限制值。應用ID和網絡地址組合在一起形成應用的唯一地址。術語「遠端網絡地址」指的是把操作指向它的節點的地址。術語「近端網絡地址」指的是指定給近端的地址。術語「始發者」指示動作是由傳輸層的用戶先發起，還是由傳輸本身先發起。術語「優先級」指示用戶數據的優先級。術語「協議描述符」指的是表示由用戶數據中攜帶著什麼樣的更高級協議的標識符。術語「隊列管理」指的是管理要接收指向特定應用ID的消息的隊列。隊列管理指向與隊列的擁有者的應用ID有關的信息。術語「理由」指的是動作的理由代碼。這是實現專用的。術語「用戶數據」指的是發送的數據。它對傳輸層是透明的。請注意，傳輸層含有不與國際電信聯盟(ITU)定義中的任何東西對應的原語。請參見上述文件「開放系統互連，傳輸服務定義，ITU-TX.214」。這是因為國際電信聯盟(ITU)不含有設置傳輸服務訪問點(TSAP)的原語。傳輸服務訪問點大體上對應於應用ID。國際電信聯盟(ITU)假定傳輸服務訪問點通過一些其它手段登記，和信息適用於傳輸層。相反，UIPC傳輸層含有登記應用ID和根據它們建造路由表的附加原語。消息首標推薦根據傳輸層所需的操作，如下的信息應該是網絡層消息首標的組成部分開始應用ID、終止應用ID、控制(用於傳輸層控制消息和指示消息的類型)。應用層本發明的UIPC不包括應用層協議。圖6是根據本發明原理的、核實部件功能的測試方法。圖6顯示了黑箱(blackbox)測試。圖6顯示了根據本發明原理的、用於測試的可能配置。它依靠作業系統無關訪問層(OIA)來抽象化作業系統調用，以便測試系統可以在工作站作業系統上運行。有兩種進程在運行進程1(610)和進程2(612)。在每種進程中的是代表實時作業系統任務的線程。因為進程在獨立的存儲空間中運行，所以每個進程可以具有與別的進程無關地運行的UIPC事例。因此，它們可以是，每一個都具有它們自己的UIPC網絡地址。任務1(614)、任務2(616)、和任務3(618)代表可以驅動UIPC應用程式接口(AIP)628和630的應用。UIPC任務620在進程1內部運行。UIPC任務622在進程2內部運行。UIPC應用程式接口在作業系統無關訪問(OIA)層632和634上運行，並且適用於各種任務。UIPC把作業系統無關訪問(OIA)層用於消息排隊功能。為了模擬處理器間通信，使用了設備無關訪問(DIA)層通信驅動器模擬器624和626。這些模擬器可以僅使用一些，如網絡接口。它們也可以把錯誤注入，以核實協議管理錯誤。由於這是UIPC部件的測試，而不是設備無關訪問(DIA)層的測試，因此，模擬器需要做的唯一事情是獲得兩個進程之間的消息。可以把圖6推廣到包括模擬不同類別路由器的其它進程。為了進行測試，可以對任務1-3編程，以運行UIPC應用程式接口的各種序列和自動核實結果。其它選擇包括利用腳本或讓用戶界面執行各種命令。與它們如何驅動UIPC無關，這是從黑箱的視角來做的。對於UIPC來說，這些任務看起來與任何其它任務一樣。雖然通過對本發明實施例的描述已經展示了本發明，並且，雖然已經相當詳細地描述了這些實施例，但是，限於這樣的細節，或者，無論以何種方式把所附權利要求的範圍限於這樣的細節都不是本申請人的意圖。對於本領域的普通技術人員來說，其它各種優點和改進是顯然的。因此，從更寬泛的方面來講，本發明不限於所示的和所述的具體細節、典型的設備和方法、以及示範性的例子。於是，偏離這樣的細節並不意味著偏離申請人一般性發明構思的精神內涵或範圍。權利要求1.一種把消息數據從源傳送到目的地的方法，該方法包括與通信設備的作業系統無關地發送消息數據，所述發送至少部分通過作業系統無關訪問層進行；和與設備的硬體無關地傳輸消息數據，所述傳輸至少部分通過設備無關訪問層進行。2.根據權利要求1所述的方法，設備形成用於機框間消息的共享總線布局。3.根據權利要求1所述的方法，設備形成用於機框間消息的星形總線布局。4.根據權利要求1所述的方法，還包括藉助於設備的作業系統部分處理設備內的內部通信；和藉助於設備的硬體部分處理與設備的外部通信。5.根據權利要求1所述的方法，還包括當源和目的地兩者都在設備的第一機框上時，和當源在第一機框上和目的地在設備的第二機框上時，以及當源在第二機框的第一插件上和目的地在第二機框的第二插件上時，和當源在第一機框上和目的地在設備的外部和不在機框的任何一個上時，進行消息數據從源到目的地的所述傳送。6.一種把消息數據從源傳輸到目的地的通信設備，該設備包括設備的作業系統部分，用於與所述設備的作業系統無關地處理所述設備內的內部通信；和設備的硬體部分，用於與所述設備中的硬體設備無關地處理與所述設備的外部通信。7.根據權利要求6所述的設備，還包括用於機框間消息的共享總線布局。8.根據權利要求6所述的設備，還包括用於機框間消息的星形總線布局。9.根據權利要求6所述的設備，還包括至少包括第一插件的第一機框；和至少包括第二插件和第三插件的第二機框；當源和目的地兩者都在設備的所述第一機框上時，和當源在所述第一機框上和目的地在所述第二機框上時，以及當源在所述第二插件上和目的地在所述第三插件上時，和當源在所述第一機框上和目的地在設備的外部和不在機框的任何一個上時，所述設備進行消息數據從源到目的地的所述傳輸。10.一種在上面存儲著一組指令的計算機存儲介質，該組指令用於實現把消息數據從源傳送到目的地的方法，該組指令包括用於執行下列步驟的一條或多條指令與通信設備的作業系統無關地發送消息數據，所述發送至少部分通過作業系統無關訪問層進行；和與設備的硬體無關地傳輸消息數據，所述傳輸至少部分通過設備無關訪問層進行。11.根據權利要求10所述的存儲介質，設備形成用於機框間消息的共享總線布局。12.根據權利要求10所述的存儲介質，設備形成用於機框間消息的星形總線布局。13.根據權利要求10所述的存儲介質，還包括藉助於設備的作業系統部分處理設備內的內部通信；和藉助於設備的硬體部分處理與設備的外部通信。14.根據權利要求10所述的存儲介質，還包括當源和目的地兩者都在設備的第一機框上時，和當源在第一機框上和目的地在設備的第二機框上時，以及當源在第二機框的第一插件上和目的地在第二機框的第二插件上時，和當源在第一機框上和目的地在設備的外部和不在機框的任何一個上時，進行消息數據從源到目的地的所述傳送。全文摘要與不同硬體和軟體兼容的統一進程間通信系統和統一進程間通信方法。統一進程間通信系統可以與使用的通信方法無關地與任何設備一起使用。統一進程間通信(UIPC)方法是高度可移植的，因為UIPC方法把設備無關訪問層(DIA)引入到系統中，並且把進程間通信與每個硬體設備鬆散地耦合起來。文檔編號H04L29/08GK1404264SQ0211618公開日2003年3月19日申請日期2002年4月23日優先權日2001年9月4日發明者尹寧鉉申請人:三星電子株式會社