專利名稱：：統(tǒng)一進(jìn)程間通信的制作方法
技術(shù)領(lǐng)域：
：本發(fā)明涉及統(tǒng)一進(jìn)程間通信，尤其涉及可以與所使用的硬件和軟件無關(guān)地用于通信的統(tǒng)一進(jìn)程間通信系統(tǒng)和方法。
背景技術(shù)：
：通信系統(tǒng)可以配備各種類型的通信設(shè)備和模塊，譬如，異步傳輸模式(ATM)、同步數(shù)字分層結(jié)構(gòu)(SDH)和因特網(wǎng)協(xié)議(IP)等。在這樣的通信系統(tǒng)中，每種系統(tǒng)使用了與其它系統(tǒng)不同的進(jìn)程間通信(IPC)方法。IPC與每種系統(tǒng)的各個(gè)硬件設(shè)備緊密地結(jié)合在一起，并且依賴于每種系統(tǒng)的各個(gè)硬件設(shè)備。例如，異步傳輸模式系統(tǒng)使用了與同步數(shù)字分層結(jié)構(gòu)系統(tǒng)所使用的IPC方法不同的IPC方法。這樣的通信系統(tǒng)的通信方法隨著系統(tǒng)的各個(gè)設(shè)備和裝置的不同而彼此不同。由于缺乏可再用性和可移植性，這樣的系統(tǒng)在把IPC應(yīng)用于系統(tǒng)的過程中會(huì)導(dǎo)致不希望有的成本和額外開銷，因此，是有缺點(diǎn)的。
發(fā)明內(nèi)容為了解決現(xiàn)有技術(shù)的這些和其它問題，本發(fā)明的一個(gè)目的是提供一種可以與通信方法無關(guān)地應(yīng)用在任何設(shè)備中的改進(jìn)的進(jìn)程間電信系統(tǒng)。本發(fā)明的另一個(gè)目的是提供一種通過把設(shè)備無關(guān)訪問層(DIA)引入系統(tǒng)中和通過把IPC與每個(gè)硬件設(shè)備松散地結(jié)合在一起，能夠改善IPC的可移植性的進(jìn)程間通信方法。本發(fā)明的另一個(gè)目的是提供一種與用在通信設(shè)備中的操作系統(tǒng)無關(guān)地把消息數(shù)據(jù)從源發(fā)送到目的地的通信設(shè)備。本發(fā)明提供高度可移植性和靈活性。本發(fā)明的另一個(gè)目的是提供一種與用在通信設(shè)備中的硬件設(shè)備無關(guān)地把消息數(shù)據(jù)從源發(fā)送到目的地的通信方法。本發(fā)明的另一個(gè)目的是提供一種與設(shè)備所使用的通信方法(例如，異步傳輸模式、因特網(wǎng)協(xié)議、同步數(shù)字分層結(jié)構(gòu)等)無關(guān)地把消息數(shù)據(jù)從源發(fā)送到目的地的通信設(shè)備。為了達(dá)到根據(jù)本發(fā)明原理的這些和其它目的，正如具體化的和概括描述的那樣，本發(fā)明提供了把消息數(shù)據(jù)從源傳送到目的地的方法，該方法包括與通信設(shè)備的操作系統(tǒng)無關(guān)地發(fā)送消息數(shù)據(jù)，所述發(fā)送至少部分通過操作系統(tǒng)無關(guān)訪問層進(jìn)行；和與設(shè)備的硬件無關(guān)地傳輸消息數(shù)據(jù)，所述傳輸至少部分通過設(shè)備無關(guān)訪問層進(jìn)行。為了達(dá)到根據(jù)本發(fā)明原理的這些和其它目的，正如具體化的和概括描述的那樣，本發(fā)明提供了把消息數(shù)據(jù)從源傳送到目的地的設(shè)備，該設(shè)備包括設(shè)備的操作系統(tǒng)部分，用于與所述設(shè)備的操作系統(tǒng)無關(guān)地處理所述設(shè)備內(nèi)的內(nèi)部通信；和設(shè)備的硬件部分，用于與所述設(shè)備中的硬件設(shè)備無關(guān)地處理與所述設(shè)備的外部通信。為了達(dá)到根據(jù)本發(fā)明原理的這些和其它目的，正如具體化的和概括描述的那樣，本發(fā)明提供了在上面存儲(chǔ)著一組指令的計(jì)算機(jī)存儲(chǔ)介質(zhì)，該組指令用于實(shí)現(xiàn)把消息數(shù)據(jù)從源傳送到目的地的方法，該組指令包括用于執(zhí)行下列步驟的一條或多條指令與通信設(shè)備的操作系統(tǒng)無關(guān)地發(fā)送消息數(shù)據(jù)，所述發(fā)送至少部分通過操作系統(tǒng)無關(guān)訪問層進(jìn)行；和與設(shè)備的硬件無關(guān)地傳輸消息數(shù)據(jù)，所述傳輸至少部分通過設(shè)備無關(guān)訪問層進(jìn)行。在如下的章節(jié)中，通過參照只作為例子來用的附圖，更具體地描述本發(fā)明。從如下的說明和所附的權(quán)利要求書中可以清楚地看到本發(fā)明的其它優(yōu)點(diǎn)和特征。圖1顯示了根據(jù)本發(fā)明原理的軟件的邏輯排列功能塊；圖2是根據(jù)本發(fā)明原理的、用于消息交換的、在系統(tǒng)控制器與每個(gè)機(jī)框(shelf)之間的網(wǎng)絡(luò)；圖3顯示了根據(jù)本發(fā)明原理構(gòu)造的共享總線布局；圖4顯示了根據(jù)本發(fā)明原理的、機(jī)框間消息的星形總線布局；圖5是根據(jù)本發(fā)明原理的、把消息發(fā)送到服務(wù)地點(diǎn)的客戶應(yīng)用；和圖6是根據(jù)本發(fā)明原理的、核實(shí)部件功能的測(cè)試方法。具體實(shí)施例方式雖然從現(xiàn)在開始，參照顯示本發(fā)明優(yōu)選實(shí)施例的附圖更全面地描述本發(fā)明，但是，從如下描述的開頭就應(yīng)該明白，本領(lǐng)域的普通技術(shù)人員可以對(duì)這里所述的發(fā)明進(jìn)行修改，而仍然可以取得本發(fā)明的良好結(jié)果。因此，如下的描述應(yīng)該被理解成面向本領(lǐng)域普通技術(shù)人員的概括性、原理性公開，而不是對(duì)本發(fā)明的限制。下面描述本發(fā)明的示范性實(shí)施例。為了清楚起見，并非實(shí)際裝置的所有特征都加以描述。在如下的描述中，那些眾所周知的功能或結(jié)構(gòu)將不作詳細(xì)描述，因?yàn)樗鼈冇锌赡苁贡景l(fā)明的重點(diǎn)不突出。應(yīng)該認(rèn)識(shí)到，在任何實(shí)際實(shí)施例的開發(fā)過程中，必須作出許多裝置特有的決定，以達(dá)到開發(fā)者的特殊目的，譬如說，遵從因裝置而異的系統(tǒng)相關(guān)和商業(yè)相關(guān)約束。此外，還應(yīng)該認(rèn)識(shí)到，這樣的開發(fā)努力也許既復(fù)雜又費(fèi)時(shí)，但是，仍然是從本公開中獲益的本領(lǐng)域普通技術(shù)人員要承擔(dān)的例行任務(wù)。進(jìn)程間通信(IPC)指的是在同一臺(tái)計(jì)算機(jī)內(nèi)，或者在網(wǎng)絡(luò)上，數(shù)據(jù)在一個(gè)進(jìn)程與另一個(gè)進(jìn)程之間的交換。IPC隱含著保證對(duì)請(qǐng)求作出響應(yīng)的協(xié)議。IPC可以由程序自動(dòng)執(zhí)行。圖1顯示了根據(jù)本發(fā)明原理的軟件的邏輯排列功能塊。圖1顯示了增強(qiáng)型服務(wù)110、連接管理112、公共代理114、公共OAM(操作、管理、和維護(hù))116、統(tǒng)一進(jìn)程間通信(UIPC)118、設(shè)備無關(guān)訪問(DIA)層120、設(shè)備驅(qū)動(dòng)器122、實(shí)時(shí)操作系統(tǒng)(RTOS)124、硬件126、操作系統(tǒng)無關(guān)訪問(OIA)層128、異步傳輸模式(ATM)130、同步數(shù)字分層結(jié)構(gòu)(SDH)和準(zhǔn)同步數(shù)字分層結(jié)構(gòu)(PDH)132、分組語音通信(VoiceoverPacket(VoP))134、綜合數(shù)字環(huán)載波(IDLC)136、窄帶(NB)用戶138、寬帶(BB)用戶140、和因特網(wǎng)協(xié)議(IP)142。圖1顯示了沿水平方向排列的一些項(xiàng)目，還顯示了沿垂直方向排列的其它項(xiàng)目。首先討論水平方向。設(shè)備的公共項(xiàng)，譬如，增強(qiáng)型服務(wù)、連接管理、公共代理、公共OAM(操作、管理、和維護(hù))、統(tǒng)一進(jìn)程間通信(UIPC)、和實(shí)時(shí)操作系統(tǒng)(RTOS)等被顯示成沿水平方向排列?，F(xiàn)在討論垂直方向。其它項(xiàng)目，譬如，異步傳輸模式(ATM)、同步數(shù)字分層結(jié)構(gòu)、準(zhǔn)同步數(shù)字分層結(jié)構(gòu)(PDH)、分組語音通信(VoP)、綜合數(shù)字環(huán)載波(IDLC)、窄帶(NB)用戶、寬帶(BB)用戶、和因特網(wǎng)協(xié)議(IP)被顯示成沿垂直方向排列。沿垂直方向排列的那些項(xiàng)目通常依賴于所使用設(shè)備的每個(gè)特定部分的特性。取決于所使用的各種通信系統(tǒng)，可以去掉沿垂直方向排列的軟件模塊之一。圖1的上部，即從“增強(qiáng)型服務(wù)”到“公共OAM”，依賴于軟件的應(yīng)用。本發(fā)明涉及與系統(tǒng)單元的內(nèi)部部分和外部通信系統(tǒng)兩者通信的統(tǒng)一進(jìn)程間通信(UIPC)。系統(tǒng)的內(nèi)部通信是在UIPC的操作系統(tǒng)部分中處理的，而系統(tǒng)的外部通信是在包括UIPC的硬件部分的那些部分中處理的。操作系統(tǒng)無關(guān)訪問層(OIA)與操作系統(tǒng)的類型無關(guān)地處理通信功能。設(shè)備無關(guān)訪問層(DIA)包含在本發(fā)明中。UIPC包括應(yīng)用程序接口(API)和如下所述的協(xié)議棧。圖2是根據(jù)本發(fā)明原理的、用于消息交換的、在系統(tǒng)控制器與每個(gè)機(jī)框之間的網(wǎng)絡(luò)。圖2顯示了支持的網(wǎng)絡(luò)布局，包括單元管理系統(tǒng)210、帶有插件213的系統(tǒng)控制器212、帶有插件215的機(jī)框2(214)、智能設(shè)備216、帶有插件219的機(jī)框3(218)、和帶有插件221的機(jī)框4(220)。在圖2中，為了讓機(jī)框4(220)與系統(tǒng)控制器212通信，盡管機(jī)框4(220)與系統(tǒng)212之間的通信在物理上穿過機(jī)框3(218)，但是，存在著一條根據(jù)本發(fā)明原理構(gòu)成的、在機(jī)框4(220)與系統(tǒng)212之間的想象的直通路徑。在下文被標(biāo)為“總線布局”的部分中，當(dāng)把本發(fā)明與總線布局的類型無關(guān)地應(yīng)用于機(jī)框間的相互通信時(shí)，本發(fā)明的靈活性就顯現(xiàn)出來了。換句話來說，在共享總線型的布局(圖3)和在星形總線型的布局(圖4)中，本發(fā)明都可以應(yīng)用于機(jī)框間的相互通信。圖3顯示了根據(jù)本發(fā)明原理構(gòu)造的共享總線布局。圖4顯示了根據(jù)本發(fā)明原理的、機(jī)框間消息的星形總線布局。在下文被標(biāo)為“應(yīng)用類型”的部分中，通過對(duì)第一機(jī)框的插件與不同機(jī)框的插件進(jìn)行通信時(shí)的通信過程加以考慮(圖5)，本發(fā)明的其它特征就呈現(xiàn)出來了。圖5是根據(jù)本發(fā)明原理的、把消息發(fā)送到服務(wù)地點(diǎn)的客戶機(jī)。在下文被標(biāo)為“應(yīng)用ID”的部分中，顯示了用于根據(jù)系統(tǒng)用戶刪除和添加軟件的軟件的應(yīng)用ID。在下文被標(biāo)為“UIPC網(wǎng)絡(luò)地址”的部分中，顯示了要用于讓消息到達(dá)可以路由消息的處理器或?qū)嶓w(entity)的網(wǎng)絡(luò)地址。就軟件功能和部件接口來說，這里包含了有關(guān)統(tǒng)一進(jìn)程間通信(UIPC)部件的功能描述。UIPC提供了借此在同一個(gè)插件、同一個(gè)機(jī)框、或不同機(jī)框上的各種任務(wù)之間路由消息的手段。如下的八個(gè)文件提供了本申請(qǐng)文件的背景和附加信息開放系統(tǒng)互連，基本參考模型，ITU-TX.200；開放系統(tǒng)互連，數(shù)字鏈接服務(wù)定義，ITU-TX.212；開放系統(tǒng)互連，網(wǎng)絡(luò)服務(wù)定義，ITU-TX.213；開放系統(tǒng)互連，傳輸服務(wù)定義，ITU-TX.214；公共軟件平臺(tái)系統(tǒng)結(jié)構(gòu)文件，Aztek分號(hào)70881；DIA部件描述，Aztek分號(hào)70891；UIPC詳細(xì)級(jí)別設(shè)計(jì)，LTITL分號(hào)SDC005-UIPC；和OIA部件DLD，LTITL分號(hào)SDC005-OIA。本申請(qǐng)文件自始至終都使用如下的定義和縮寫術(shù)語“API”指的是應(yīng)用程序接口；術(shù)語“EMS”指的是單元管理系統(tǒng)；“跳段(hop)”指的是在數(shù)段相繼路徑上傳輸消息的過程中的一段路徑；術(shù)語“鏈接”指的是兩個(gè)物理端點(diǎn)之間的連接；術(shù)語“NE”指的是網(wǎng)絡(luò)單元；術(shù)語“網(wǎng)絡(luò)單元”指的是單元管理系統(tǒng)獨(dú)立管理的一個(gè)單位(一個(gè)網(wǎng)絡(luò)單元可以由一個(gè)或多個(gè)局部的或地理上分散的機(jī)框組成)；術(shù)語“節(jié)點(diǎn)”指的是可獨(dú)立尋址的、UIPC通信網(wǎng)絡(luò)的任何一個(gè)單元；和術(shù)語“智能端點(diǎn)”指的是可以接收消息的、附在插件上的設(shè)備(這種設(shè)備的例子有DSL調(diào)制解調(diào)器)。術(shù)語“UIPC”指的是統(tǒng)一進(jìn)程間通信(UIPC也可以指通用進(jìn)程間通信)；術(shù)語“OIA”指的是操作系統(tǒng)無關(guān)適配層；術(shù)語“DIA”指的是設(shè)備無關(guān)適配層；術(shù)語“DSL”指的是數(shù)字用戶線；術(shù)語“IAD”指的是綜合訪問設(shè)備；術(shù)語“RTOS”指的是實(shí)時(shí)操作系統(tǒng)；和術(shù)語“TCP/IP”指的是在傳輸控制協(xié)議/因特網(wǎng)協(xié)議。部件綜述本發(fā)明的UIPC部件意在用于各種應(yīng)用之間的所有處理器內(nèi)和處理器間通信。這個(gè)部分包括本發(fā)明支持的網(wǎng)絡(luò)單元布局的描述、本發(fā)明所使用的尋址的基本描述、和本發(fā)明的UIPC支持的應(yīng)用模型的描述。如下特性包含在本發(fā)明的UIPC和本發(fā)明的其它單元中。UIPC提供了網(wǎng)絡(luò)單元內(nèi)部任何地方的任務(wù)之間的雙向消息傳送。UIPC允許異步發(fā)送消息的應(yīng)用。應(yīng)用程序接口(API)將沒有阻塞地直接返回。UIPC允許不會(huì)超時(shí)地發(fā)送消息和同步等待響應(yīng)的應(yīng)用。UIPC使基礎(chǔ)性物理傳輸機(jī)制抽象化。要求需要與服務(wù)通信的應(yīng)用知道那個(gè)服務(wù)的位置。在下文標(biāo)為“應(yīng)用類型服務(wù)”的部分中描述服務(wù)應(yīng)用。如下的附加特性包含在本發(fā)明的UIPC和本發(fā)明的其它單元中。UIPC提供借此可以把消息廣播出去的機(jī)制。無需改變高層協(xié)議，就能夠改變低級(jí)UIPC協(xié)議。無需改變低層協(xié)議，就能夠改變高級(jí)UIPC協(xié)議。UIPC一條鏈路一條鏈路地檢測(cè)傳輸錯(cuò)誤和重試有錯(cuò)分組(這意味著，要求有管理每條鏈路的、協(xié)議的鏈路層以使那條鏈路是可靠的)。同一個(gè)UIPC應(yīng)用程序接口(API)用于處理器內(nèi)和處理器間通信。UIPC進(jìn)行大消息的分割和組裝。UIPC允許端到端面向連接和無連接通信。UIPC提供允許調(diào)試輸出的機(jī)制。UIPC協(xié)議參數(shù)在運(yùn)行期間是可以設(shè)置的。UIPC提供為每條鏈路設(shè)置最大傳輸單元的機(jī)制。UIPC使跳段與改變最大傳輸單元相適應(yīng)。UIPC支持實(shí)時(shí)關(guān)鍵性消息的消息優(yōu)先級(jí)。UIPC是與操作系統(tǒng)無關(guān)的。UIPC讓消息透明地從控制器傳送到附在插件上的設(shè)備(這些設(shè)備可以，也可以不遵從UIPC協(xié)議)。UIPC讓消息從網(wǎng)絡(luò)單元內(nèi)的任何一個(gè)機(jī)框路由到另一個(gè)機(jī)框。UIPC提供用于報(bào)告協(xié)議錯(cuò)誤和統(tǒng)計(jì)的應(yīng)用程序接口(API)。除了本發(fā)明的上述特性之外，還為本發(fā)明考慮到實(shí)時(shí)系統(tǒng)設(shè)計(jì)的特性。實(shí)時(shí)系統(tǒng)設(shè)計(jì)的相關(guān)特性如下。在實(shí)時(shí)系統(tǒng)中，一些消息必須在某種時(shí)間限制下發(fā)送。這意味著，在協(xié)議棧的最低級(jí)上的分組的最大傳輸單位必須小到足以使大消息不會(huì)浪費(fèi)通信流水線的帶寬。在實(shí)時(shí)系統(tǒng)中，處理器或通信帶寬可能是有限的。這意味著對(duì)效率的需要。消息的處理應(yīng)該是最低限度的。應(yīng)該使協(xié)議額外開銷達(dá)到最小。要在功能與效率之間權(quán)衡利弊。像TCP/IP那樣的協(xié)議棧是富特征的，但是實(shí)現(xiàn)這些特征需要花費(fèi)許多額外開銷。從效率的角度來考慮，使協(xié)議與實(shí)時(shí)系統(tǒng)相適應(yīng)最有可能使協(xié)議額外開銷達(dá)到最小，并且，最適合于大多數(shù)普通類型的消息傳送。這意味著特征受到限制。需要附加特征的少數(shù)幾種應(yīng)用也許不得不參與到供應(yīng)某個(gè)附加功能中去，而不依賴于協(xié)議棧來供應(yīng)所需特征。在實(shí)時(shí)系統(tǒng)中，實(shí)時(shí)操作系統(tǒng)(RTOS)一般不讓任務(wù)在多個(gè)端點(diǎn)上等待。其結(jié)果是，通常借助于可以從多個(gè)源，譬如，其它任務(wù)或中斷服務(wù)例程(ISR)接收消息的一個(gè)消息隊(duì)列完成各種任務(wù)。這意味著UIPC需要支持借助于單個(gè)消息隊(duì)列構(gòu)造起來的多個(gè)任務(wù)。在實(shí)時(shí)系統(tǒng)中，實(shí)時(shí)操作系統(tǒng)(RTOS)一般提供所有任務(wù)可以訪問所有存儲(chǔ)器的平坦(flat)存儲(chǔ)模式。在這種模型中，幾個(gè)任務(wù)可以共享數(shù)據(jù)，而不會(huì)有在消息中傳送數(shù)據(jù)的額外開銷或用于實(shí)施共享存儲(chǔ)器的操作系統(tǒng)額外開銷。一些實(shí)時(shí)操作系統(tǒng)(RTOS)可以提供把存儲(chǔ)器限制在某個(gè)任務(wù)可以訪問的保護(hù)存儲(chǔ)模式。在這樣的模型中各種任務(wù)之間的通信依賴于消息傳送或共享存儲(chǔ)器的使用。存儲(chǔ)器模型不影響在本說明書中提到的應(yīng)用程序接口(API)或協(xié)議定義。但是，它的確影響這些部分的實(shí)現(xiàn)。在作出實(shí)現(xiàn)建議的地方，本說明書假設(shè)更普通的平坦存儲(chǔ)模型。網(wǎng)絡(luò)單元布局網(wǎng)絡(luò)單元代表獨(dú)立管理的設(shè)備構(gòu)件。網(wǎng)絡(luò)單元可以由一個(gè)或多個(gè)局部的或地理上分散的機(jī)框組成。網(wǎng)絡(luò)單元分布的方式稱為網(wǎng)絡(luò)單元布局。本發(fā)明的UIPC支持的布局是樹結(jié)構(gòu)?？赡艽嬖谝粋€(gè)與多個(gè)其它機(jī)框相連接的主系統(tǒng)控制器機(jī)框。對(duì)著其它機(jī)框的任何機(jī)框可能有，也可能沒有把通信路徑與系統(tǒng)控制器相連接的直接硬件。為任何機(jī)框之間的通信配備軟件路由功能。它與網(wǎng)絡(luò)布局無關(guān)。存在兩種類型的路由機(jī)制一種是靜態(tài)路由，另一種是動(dòng)態(tài)路由。除了機(jī)框之外，每個(gè)機(jī)框包含數(shù)個(gè)插件。插件可以包含可以，也可以不通過UIPC協(xié)議進(jìn)行通信的、附在它們身上的智能設(shè)備。這些插件或設(shè)備可以被當(dāng)作樹結(jié)構(gòu)的分支或葉片。圖2是根據(jù)本發(fā)明原理的、用于消息交換的、系統(tǒng)控制器與每個(gè)機(jī)框之間的網(wǎng)絡(luò)。圖2顯示了支持的網(wǎng)絡(luò)布局，它包括單元管理系統(tǒng)210、帶有插件213的系統(tǒng)控制器212、帶有插件215的機(jī)框2(214)、智能設(shè)備216、帶有插件219的機(jī)框3(218)、和帶有插件221的機(jī)框4(220)。圖2顯示了設(shè)計(jì)本發(fā)明的UIPC的網(wǎng)絡(luò)布局。本發(fā)明的UIPC支持在單個(gè)插件上的任務(wù)之間、在同一個(gè)機(jī)框上的不同插件上的任務(wù)之間、在任何機(jī)框上的任務(wù)之間、以及在任何機(jī)框和所附智能設(shè)備(例如，數(shù)字用戶線路調(diào)制解調(diào)器和綜合訪問設(shè)備)上的任務(wù)之間的消息交換。請(qǐng)注意，這里假設(shè)，如果需要的話，可以認(rèn)為需要在兩個(gè)機(jī)框之間流動(dòng)的消息是通過系統(tǒng)控制器機(jī)框212路由的。這樣就可以使協(xié)議簡(jiǎn)單化，并且降低了與管理更一般的網(wǎng)絡(luò)布局的、諸如因特網(wǎng)協(xié)議(IP)之類的協(xié)議相聯(lián)系的額外開銷。還請(qǐng)注意，單元管理系統(tǒng)210也可以通過UIPC進(jìn)行通信。消息可以在單元管理系統(tǒng)210與任何機(jī)框上的任何插件之間路由。就UIPC而言，單元管理系統(tǒng)(EMS)210看起來正好像任何其它機(jī)框?？偩€布局上述網(wǎng)絡(luò)布局從外部的觀點(diǎn)定義了本發(fā)明的系統(tǒng)?，F(xiàn)在來描述總線布局?？偩€布局從內(nèi)部的觀點(diǎn)描述本發(fā)明的機(jī)框?？偩€布局的設(shè)計(jì)影響消息如何流過機(jī)框上的插件和在機(jī)框上的插件之間流動(dòng)?？偩€布局可以是共享總線型的(圖3)，也可以是星形總線型的(圖4)。在共享總線型布局中，任何插件都可以與任何其它插件通信。但是，有些共享總線設(shè)計(jì)只讓插件與單個(gè)主機(jī)通話。在星形總線型布局中，每個(gè)插件與中央集線器連接。與布局無關(guān)，必須存在一些與外部世界的連接。從外部源到達(dá)機(jī)框的控制消息將由處在兩種總線布局之一下的單個(gè)插件來處理。因此，一個(gè)插件總有一些在外部系統(tǒng)與插件之間路由消息的功能。圖3顯示了根據(jù)本發(fā)明原理構(gòu)成的共享總線布局。圖3描繪了含有插件1(312)、插件2(314)、插件3(316)、插件4(318)和插件5(320)的機(jī)框310。在圖3中，機(jī)框310包括與另一個(gè)機(jī)框(除了機(jī)框310之外)存在外部連接的插件1(312)。如插件4(318)發(fā)送的消息所示，與其它機(jī)框交換的消息由插件1(312)路由。對(duì)于在插件之間路由消息，圖3還顯示了兩種可能選擇。在讓任何插件與任何其它插件通話的設(shè)計(jì)中，如果插件知道彼此的地址，那么，可以在這些插件之間直接發(fā)送消息。這是插件4(318)與5(320)之間所示的。這是一種在插件之間獲取消息的最有效手段。但是，為了簡(jiǎn)單起見，如從插件2(314)發(fā)送到插件3(316)的消息所示，裝置可以選擇通過中央路由器312路由所有插件間消息。這種方法也可以用于要求所有消息流過主機(jī)的共享總線。請(qǐng)注意，如后所述的UIPC包括用于每個(gè)插件和用于可以包容直接插件到插件路由和集中路由兩者的機(jī)框的路由機(jī)制。它只依賴于每個(gè)插件的路由表是如何布居的。圖4顯示了根據(jù)本發(fā)明原理的、用于機(jī)框間消息的星形總線布局。圖4描繪了含有插件1(412)、插件2(414)、插件3(416)、插件4(418)和插件5(420)的機(jī)框410。如圖4所示，在星形總線布局中，所有消息都穿過中央路由器412。應(yīng)用類型有各種類型可能存在的應(yīng)用。為了便于討論，一個(gè)應(yīng)用是作為一個(gè)任務(wù)實(shí)現(xiàn)的。所有應(yīng)用可能都需要利用UIPC。一些應(yīng)用通常不與其它應(yīng)用交互。這些應(yīng)用被稱為獨(dú)立應(yīng)用。其它應(yīng)用提供適合于其它應(yīng)用的服務(wù)。這些應(yīng)用被稱為服務(wù)。與服務(wù)交互的任何應(yīng)用被稱為客戶。一些客戶應(yīng)用也可以是服務(wù)本身。除了應(yīng)用類型之外，對(duì)于每個(gè)任務(wù)，很有可能存在著某種父母/子女(parent/child)關(guān)系。甚至獨(dú)立任務(wù)也會(huì)存在創(chuàng)造它的某種任務(wù)(即，它的父母)。為了維護(hù)的目的，父母可能需要與他們的子女通信。例如，母任務(wù)可能想要它的子女作出強(qiáng)制回應(yīng)，以確信它正在正常工作。如下所述的是三種應(yīng)用類型(服務(wù)型，客戶型，和獨(dú)立型)，以及在應(yīng)用之間的示范性客戶機(jī)/服務(wù)器消息流動(dòng)。第一種應(yīng)用類型是服務(wù)型。服務(wù)是為其它應(yīng)用(例如，客戶)完成特定任務(wù)，譬如，控制對(duì)公共資源的訪問實(shí)現(xiàn)的。對(duì)于客戶來說，如何或在哪個(gè)插件上，和可能哪個(gè)機(jī)框?qū)崿F(xiàn)服務(wù)是無關(guān)緊要的。服務(wù)作為抽象概念的使用使客戶任務(wù)與服務(wù)所處的位置無關(guān)地利用服務(wù)。這種設(shè)計(jì)是易于改變的，因?yàn)樗狗?wù)、插件或機(jī)框內(nèi)的工作部門可以不影響客戶應(yīng)用地發(fā)生改變。只有在一些情況下，應(yīng)用才需要與另一個(gè)節(jié)點(diǎn)上的特定插件通話。服務(wù)利用熟知應(yīng)用ID，通過UIPC登記它們自己。應(yīng)用ID類似于向服務(wù)器開放插座連接時(shí)使用的傳輸控制協(xié)議(TCP)端口號(hào)。當(dāng)與服務(wù)通信時(shí)，客戶機(jī)需要知道服務(wù)的應(yīng)用ID。如果客戶機(jī)需要與特定單元的硬件，譬如，機(jī)框或機(jī)框上的具體插件上的服務(wù)通話，那么，它還必須指定網(wǎng)絡(luò)地址。熟知服務(wù)的例子有管理OAM(操作、管理、和維護(hù))相關(guān)請(qǐng)求的OAM任務(wù)，或負(fù)責(zé)接收?qǐng)?bào)警信號(hào)的報(bào)警信號(hào)管理任務(wù)。第二種應(yīng)用類型是客戶型。客戶是與服務(wù)通話的任何應(yīng)用。與另一個(gè)服務(wù)通話的服務(wù)被認(rèn)為是那個(gè)其它服務(wù)的客戶。也不是服務(wù)的客戶不含有熟知應(yīng)用ID。但是，為了讓服務(wù)能夠把響應(yīng)發(fā)送給客戶，UIPC將把一個(gè)應(yīng)用ID指定給客戶的消息隊(duì)列，以便可以把響應(yīng)路由給客戶。第三種應(yīng)用類型是獨(dú)立型。獨(dú)立應(yīng)用是不與其它應(yīng)用通話的那些應(yīng)用。與客戶一樣，獨(dú)立應(yīng)用不含有熟知應(yīng)用ID。現(xiàn)在來討論有關(guān)示范性客戶機(jī)/服務(wù)器消息流動(dòng)的信息。存在著許多種各種應(yīng)用之間的消息流動(dòng)的組合。理解消息流動(dòng)的關(guān)鍵是UIPC包含了確定應(yīng)該把消息發(fā)往何方的路由機(jī)制。系統(tǒng)中的每個(gè)插件都具有路由功能。每個(gè)機(jī)框也具有在插件或機(jī)框之間分配消息的路由功能。為了展示UIPC支持的最復(fù)雜路由，現(xiàn)在請(qǐng)參照?qǐng)D5。圖5是根據(jù)本發(fā)明原理的、把消息發(fā)送到服務(wù)地點(diǎn)的客戶應(yīng)用。圖5描繪了系統(tǒng)控制器機(jī)框510和機(jī)框516。系統(tǒng)控制器機(jī)框510含有機(jī)框控制器512和插件516。機(jī)框516含有機(jī)框控制器522和插件526。插件526含有可以是任何任務(wù)530的客戶應(yīng)用530。插件526含有UIPC528。機(jī)框控制器522含有UIPC524。插件516含有服務(wù)X520和UIPC518。機(jī)框控制器512含有UIPC514。圖5描繪了把消息發(fā)送到服務(wù)X520的客戶應(yīng)用530。客戶應(yīng)用530由任何任務(wù)530來表示。在圖5中，服務(wù)X520是在系統(tǒng)控制器機(jī)框510上實(shí)現(xiàn)的，和客戶是在某個(gè)其它機(jī)框516上實(shí)現(xiàn)的。客戶請(qǐng)求UIPC528借助于系統(tǒng)控制器510的網(wǎng)絡(luò)地址把消息發(fā)送到服務(wù)X520。在客戶機(jī)插件526上的UIPC528把消息轉(zhuǎn)發(fā)到機(jī)框路由器。機(jī)框路由器查找目的地網(wǎng)絡(luò)地址。如果它與我的網(wǎng)絡(luò)地址不符，那么，就把消息路由到系統(tǒng)控制器510。系統(tǒng)控制器510上的機(jī)框路由器查找目的地網(wǎng)絡(luò)地址，并且確定是在機(jī)框510中的插件516上實(shí)現(xiàn)的。把消息發(fā)送給那個(gè)插件516。然后，在那個(gè)插件516上的UIPC518把消息路由到服務(wù)X520。應(yīng)用ID這個(gè)部分說明如何把熟知應(yīng)用ID指定給應(yīng)用，供應(yīng)用使用，和為應(yīng)用所知。在插件中可用的應(yīng)用ID的最大號(hào)碼是UIPC_MAX_APP_ID。在插件中可用的應(yīng)用ID的最大號(hào)碼是得到與允許的進(jìn)程間通信(IPC)隊(duì)列的最大號(hào)碼相對(duì)應(yīng)的操作系統(tǒng)無關(guān)訪問層(OIA)允許的。熟知應(yīng)用ID是由應(yīng)用從UIPC_MAX_WEL_KNOWN_APP限定的一列應(yīng)用ID中，即UIPC_MAX_APP_ID的值的前半部分中，選擇出來的。它像與傳輸控制協(xié)議(TCP)一起使用的熟知端口號(hào)。在這種情況下的應(yīng)用被定義為除UIPC之外的任何東西。這種應(yīng)用包括公共操作、管理、和維護(hù)(OAM)部分，以及其它應(yīng)用。對(duì)于不是熟知應(yīng)用的應(yīng)用，從UIPC_MAX_APP_ID限定的那些值的其它后半部分中分配應(yīng)用ID。這個(gè)范圍是從UIPC_DYN_APP_ID_START(UIPC_MAX_WEL_KNOWN_APP+1)到UIPC_MAX_APP_ID。當(dāng)任務(wù)想要發(fā)送或接收消息時(shí)，指定這些應(yīng)用ID，一旦任務(wù)完成了消息的發(fā)送或接收，就釋放這些應(yīng)用ID。當(dāng)這些應(yīng)用ID被釋放時(shí)，可以重新使用它們。UIPC網(wǎng)絡(luò)地址網(wǎng)絡(luò)地址用于讓消息到達(dá)可以路由消息的處理器或?qū)嶓w。因此，每個(gè)插件、機(jī)框、機(jī)架(rack)、或智能端點(diǎn)擁有唯一的網(wǎng)絡(luò)地址。也可以把機(jī)框組織成也可以擁有唯一網(wǎng)絡(luò)地址的機(jī)架。也可以讓應(yīng)用ID包含在告訴路由器哪個(gè)應(yīng)用應(yīng)該接收消息的消息中。更簡(jiǎn)單地說，網(wǎng)絡(luò)地址讓消息到達(dá)插件，和應(yīng)用ID讓消息到達(dá)插件上的任務(wù)。網(wǎng)絡(luò)地址必須能夠與機(jī)架、機(jī)框、插件、或附在插件上的智能端點(diǎn)的相聯(lián)系。為此，定義了劃分成A、B、C、和D四個(gè)類別的32位地址。這類似于具有4個(gè)類別的因特網(wǎng)協(xié)議(IP)尋址。每個(gè)類別包括8個(gè)位。類別A代表機(jī)架。類別B代表網(wǎng)絡(luò)單元中機(jī)框的地址。類別C地址代表插件。類別D地址代表智能端點(diǎn)。這種方案允許每個(gè)網(wǎng)絡(luò)或子網(wǎng)絡(luò)上擁有256個(gè)獨(dú)立的設(shè)備。地址類別的使用使路由器能夠屏蔽掉不關(guān)心的區(qū)段。這樣就簡(jiǎn)化了路由表。例如，可能讓消息到達(dá)附在插件上的特定設(shè)備。由于所有想知道的是如何讓消息到達(dá)插件上，因此，機(jī)框路由器可以忽略地址的類別D部分。不需要有關(guān)附在插件上的設(shè)備的、在其路由表中的任何條目。同樣，由于所有想知道的是如何讓消息到達(dá)設(shè)備上，因此，插件上的路由器可以忽略地址的類別A和B部分。也可以把特殊地址定義成用于不知道或不應(yīng)該使用特定地址的環(huán)境中。例如，一個(gè)插件上的應(yīng)用可能需要與已知位于機(jī)框上、還不知道在什么地方實(shí)現(xiàn)服務(wù)的服務(wù)通信。特殊地址也可以用在把地址動(dòng)態(tài)地指定給路由器的地方。到未指定路由器(例如，一個(gè)插件)的網(wǎng)絡(luò)層控制消息可以包含特殊類型的地址，并且傳送使未指定路由器能夠具有新地址的信息。任何協(xié)議層也可以在通信協(xié)議控制消息的時(shí)候使用特定地址。通過特殊地址還可以支持消息的廣播。如下的特殊值可以用作地址的類別A、B、C、或D部分。路由器應(yīng)該從類別A地址開始、一直到類別D地址處理它們，以確定如何路由消息。將描述的第一個(gè)特殊值是“任何位置”值?！叭魏挝恢谩敝凳?xFF。當(dāng)“任何位置”值在消息的地址當(dāng)中時(shí)，把消息定向到可以在任何插件(類別C部分是這個(gè)值)或任何機(jī)框(類別B部分是這個(gè)值)上的服務(wù)。換言之，當(dāng)?shù)刂返念悇eC部分具有值0xFF時(shí)，那么，把消息定向到可以在任何插件上的服務(wù)，和當(dāng)?shù)刂返念悇eB部分具有值0xFF時(shí)，那么，把消息定向到可以在任何機(jī)框上的服務(wù)。如果路由器把這個(gè)地址看作類別值，那么，應(yīng)該把消息傳送到傳輸層。傳輸層將確定服務(wù)是否已經(jīng)注冊(cè)成利用消息中的應(yīng)用ID來接收消息。將描述的第二個(gè)特殊值是“這個(gè)位置”值。“這個(gè)位置”值是0xFE。如果地址的類別具有“這個(gè)位置”值，那么，它就指示消息終止在接收消息的路由器上，或者，如果較低類別地址不包含“忽略(0xFD)”值，就終止在較低類別地址上。將描述的第三個(gè)特殊值是“忽略”值。“忽略”值是0xFD。如果類別具有“忽略”值，那么，消息應(yīng)該終止在不具有0xFD值的最高類別路由器上?！昂雎浴敝涤迷诎严⒍ㄏ虻教囟C(jī)框或插件上?！昂雎浴敝涤迷谟嘘P(guān)類別B和C路由器的路由器地址中。類別B路由器將具有像0xXXXXFDFD那樣的地址，和類別C路由器將具有像0xXXXXXXFD那樣的地址。還請(qǐng)注意，正像任何其它插件一樣，機(jī)框路由器處在上面的插件也將擁有它自己的地址。將描述的第四個(gè)特殊值是“廣播”值?！皬V播”值是0xFC。接收包含“廣播”值的地址的路由器應(yīng)該向它的路由表中與出現(xiàn)0xFC的類別匹配的所有地址廣播消息。例如，接收帶有0xXXXXFCFD的消息的機(jī)框?qū)⑾虿寮拿恳粋€(gè)發(fā)送消息。0xXXXXFCFC的值將使每個(gè)插件發(fā)送消息，并且將其轉(zhuǎn)發(fā)給所有類別D設(shè)備。將描述的第五個(gè)特殊值是“系統(tǒng)控制器”值。“系統(tǒng)控制器”值是0xFB?！跋到y(tǒng)控制器”值只應(yīng)用于類別B地址?！跋到y(tǒng)控制器”值用在把消息特別發(fā)送給系統(tǒng)控制器機(jī)框的時(shí)候?，F(xiàn)在給出有用地址的四個(gè)例子。應(yīng)用把消息發(fā)送到這個(gè)機(jī)框上某處的服務(wù)0xFEFEFFFD。應(yīng)用把消息發(fā)送到這個(gè)插件上的服務(wù)0xFEFEFEFD。應(yīng)用把消息發(fā)送到可以在任何機(jī)框的任何插件上的服務(wù)0xFFFFFFFD。應(yīng)用向系統(tǒng)中的所有插件廣播消息0xFCFCFCFD。部件描述本發(fā)明的UIPC劃分成兩個(gè)主要部分應(yīng)用程序接口(API)和協(xié)議棧。應(yīng)用程序接口為應(yīng)用提供了無需知道協(xié)議的細(xì)節(jié)或如何執(zhí)行協(xié)議，借助于簡(jiǎn)便的手段發(fā)送消息。為了清楚起見，為支持平坦存儲(chǔ)模式的操作系統(tǒng)給出推薦裝置。本發(fā)明的UIPC意在提供穿過同一機(jī)框上的插件或穿過機(jī)框的、在和不在處理器上兩者的任務(wù)間通信。本發(fā)明的UIPC負(fù)責(zé)讓消息到達(dá)它們的目的地。但是，消息的內(nèi)容由應(yīng)用負(fù)責(zé)。因此，UIPC不提供以機(jī)器無關(guān)格式表示用戶數(shù)據(jù)的機(jī)制。這將由表示層負(fù)責(zé)。由于UIPC意在用作實(shí)時(shí)協(xié)議，因此，不包含與表示層相聯(lián)系的額外開銷。UIPC部件被設(shè)計(jì)成使把應(yīng)用程序接口與協(xié)議處理分開。這就使不需要協(xié)議棧的有效處理器內(nèi)通信，而同時(shí)可以使需要協(xié)議棧的處理器間通信。UIPC應(yīng)用程序接口是作為程序庫(kù)而存在的，程序庫(kù)是從應(yīng)用任務(wù)的環(huán)境(context)調(diào)用的。應(yīng)用調(diào)用UIPC應(yīng)用程序接口來發(fā)送和接收消息。為了進(jìn)行處理器間消息傳送，UIPC應(yīng)用程序接口可以與UIPC協(xié)議任務(wù)(也稱為“UIPC任務(wù)”)通信。通過把消息發(fā)送到UIPC協(xié)議任務(wù)的隊(duì)列中，就可以做到這一點(diǎn)。應(yīng)用程序接口(API)是可以由任何任務(wù)使用的共享程序庫(kù)。應(yīng)用程序接口把接口提供給UIPC提供的所有外部功能。應(yīng)用程序接口無需通過UIPC任務(wù)，就可以處理處理器內(nèi)操作。通過檢查接受的端點(diǎn)處理，看一看它們是代表在處理器上的端點(diǎn)，還是代表不在處理器上的端點(diǎn)，就可以做到這一點(diǎn)。如果在處理器上，那么，通過調(diào)用操作系統(tǒng)無關(guān)訪問層(OIA)消息傳送應(yīng)用程序接口，把消息直接發(fā)送到由端點(diǎn)所指消息隊(duì)列中。如果不在處理器上，那么，把消息發(fā)送到UIPC協(xié)議任務(wù)的消息隊(duì)列中。調(diào)入U(xiǎn)ipc_InitCardContext()初始化本發(fā)明的UIPC。UIPC內(nèi)部表全局表UIPC全局表全局表包含有關(guān)具體插件中的所有任務(wù)的信息。在全局中的每個(gè)條目是一個(gè)任務(wù)控制塊(TCB)。每個(gè)任務(wù)控制塊含有任務(wù)專用信息。任務(wù)控制塊的第一欄是任務(wù)ID。任務(wù)控制塊中的第二欄是應(yīng)用ID。這是任務(wù)的主隊(duì)列的應(yīng)用ID。每個(gè)任務(wù)含有動(dòng)態(tài)消息管理表(handlertable)、靜態(tài)消息管理表、和動(dòng)態(tài)消息類別表。每當(dāng)任務(wù)調(diào)用Uipc_RegisterOneTimeApi()時(shí)，就在任務(wù)的動(dòng)態(tài)消息管理表中形成一個(gè)條目。在動(dòng)態(tài)消息管理表中的條目不是永久的。一次性應(yīng)用程序接口的響應(yīng)一到達(dá)，就刪除這個(gè)條目。動(dòng)態(tài)消息管理表是利用平衡二叉樹(binarytree)實(shí)現(xiàn)的。每當(dāng)任務(wù)調(diào)用Uipc_RegisterMsgHandler()時(shí)，就在靜態(tài)消息管理表中形成一個(gè)條目。靜態(tài)消息管理表專用于觀察應(yīng)用程序接口。與動(dòng)態(tài)消息管理表不同，靜態(tài)消息管理表中的條目是永久的。靜態(tài)消息管理表是利用陣列實(shí)現(xiàn)的。每當(dāng)任務(wù)調(diào)用Uipc_GenerateTempMsgClass()時(shí)，把消息類別返回到任務(wù)，并且在動(dòng)態(tài)消息類別表中進(jìn)行必要的更新，以便特定的消息類別變成被使用的。每當(dāng)任務(wù)調(diào)用Uipc_FreeTempMsgClass()時(shí)，UIPC就在動(dòng)態(tài)消息類別表中作必要的修改，以便將來可以使用特定的消息類別。動(dòng)態(tài)消息類別表也被當(dāng)作陣列來實(shí)現(xiàn)。全局表包含到上述所有表格的指針。除此之外，全局表還包含到任務(wù)的空閑消息管理函數(shù)的指針。全局表還包含對(duì)于每個(gè)任務(wù)來說，必須用在Uipc_RcvLoop()內(nèi)的等待時(shí)間。每當(dāng)在Uipc_RcvLoop()應(yīng)用程序接口內(nèi)時(shí)，就在等待時(shí)間內(nèi)查詢?nèi)直怼Ｓ捎谌直肀凰腥蝿?wù)訪問，因此，旗語(semaphore)將保護(hù)全局表。這個(gè)旗語是在Uipc_InitCardContext()期間建立起來的。每當(dāng)調(diào)入U(xiǎn)ipc_InitTaskContext()時(shí)，借助于為那個(gè)任務(wù)的tidandwaitTime輸入的有效值，在全局表中形成一個(gè)條目，并且為靜態(tài)消息管理表和動(dòng)態(tài)消息類別表分配存儲(chǔ)器。把a(bǔ)ppId、到空閑消息管理表的指針、和到動(dòng)態(tài)消息管理表的指針設(shè)置成NULL.在Uipc_SetMainQueue()期間，填充appId，和在Uipc_RegisterIdleHandler()期間，填充到空閑消息管理程序的指針。動(dòng)態(tài)消息管理表每個(gè)任務(wù)必須完成這個(gè)動(dòng)態(tài)消息管理表。這個(gè)表專用于一次性應(yīng)用程序接口(API)。UIPC動(dòng)態(tài)消息管理表動(dòng)態(tài)消息管理表在其中含有三欄。第一欄是消息類別，第二欄是回調(diào)函數(shù)指針，和第三欄是定時(shí)器管理。每當(dāng)任務(wù)調(diào)用Uipc_RegisterOneTimeApi()時(shí)，就在任務(wù)的動(dòng)態(tài)消息管理表中形成一個(gè)條目。每當(dāng)消息借助于像UIPC_MSG_RSP那樣的消息方向到達(dá)時(shí)，就利用消息類別查找該表格，以找出相應(yīng)的回調(diào)函數(shù)。在調(diào)用回調(diào)函數(shù)之后，從任務(wù)的動(dòng)態(tài)消息處理表中刪除該條目。動(dòng)態(tài)消息處理表中的條目不是永久的。為了從動(dòng)態(tài)消息處理表中刪除條目，要調(diào)用UIPC專用應(yīng)用程序接口Uipc_DeleteMsgHndlrTableEntry()。一次性應(yīng)用程序接口的響應(yīng)一到達(dá)，就刪除這個(gè)條目。即使出現(xiàn)超時(shí)情況(如果在特定時(shí)間內(nèi)響應(yīng)沒有到達(dá))，也要?jiǎng)h除動(dòng)態(tài)消息處理表中的條目。通過UIPC控制數(shù)據(jù)把有關(guān)消息到達(dá)或超時(shí)的情況告知上層。動(dòng)態(tài)消息處理表是利用平衡二叉樹實(shí)現(xiàn)的。UIPC靜態(tài)消息管理表每個(gè)任務(wù)必須完成靜態(tài)消息管理表。UIPC靜態(tài)消息管理表每當(dāng)任務(wù)調(diào)用Uipc_RegisterMsgHandler()時(shí)，在靜態(tài)消息管理表中形成一個(gè)條目。靜態(tài)消息管理表專用于觀察應(yīng)用程序接口。每當(dāng)消息借助于像UIPC_MSG_REP或UIPC_MSG_REQ那樣的消息方向到達(dá)時(shí)，就利用消息類別查找該表格，以找出相應(yīng)的回調(diào)函數(shù)。如果找到條目，那么，就調(diào)用回調(diào)函數(shù)。與動(dòng)態(tài)消息處理表不同，靜態(tài)消息管理表中的條目是永久的。靜態(tài)消息管理表是利用陣列實(shí)現(xiàn)的。因?yàn)槊總€(gè)表擁有它自己的靜態(tài)消息管理表，所以不需要旗語來保護(hù)這個(gè)表。UIPC動(dòng)態(tài)消息類別表每個(gè)任務(wù)必須完成動(dòng)態(tài)消息類別表。每當(dāng)任務(wù)調(diào)用Uipc_GenerateTempMsgClass()時(shí)，把靜態(tài)消息類別范圍(從UIPC_DYN_MSG_CLASS_START到UIPC_MAX_NO_DYN_MSG_CLASS)內(nèi)的自由消息類別賦予任務(wù)。如果沒有自由消息類別可用，那么，向應(yīng)用程序接口用戶報(bào)告沒有可用的。在分配了自由消息類別之后，更新這個(gè)表格，以便使特定消息類別變成被使用的。每當(dāng)任務(wù)調(diào)用Uipc_FreeTempMsgClass()時(shí)，就釋放消息類別，以便將來可以使用特定的消息類別。因?yàn)槊總€(gè)表擁有它自己的動(dòng)態(tài)消息類別表，所以不需要旗語來保護(hù)這個(gè)表。UIPC棧為了進(jìn)行處理器間消息傳送，UIPC應(yīng)用程序接口(API)可以與UIPC協(xié)議任務(wù)(也稱為“UIPC任務(wù)”)通信。通過把消息發(fā)送到UIPC協(xié)議任務(wù)的隊(duì)列中，就可以做到這一點(diǎn)。UIPC路由程序庫(kù)也顯示了。UIPC路由程序庫(kù)使UIPC應(yīng)用程序接口或UIPC協(xié)議任務(wù)能夠確定如何路由消息。這是基于應(yīng)用ID和網(wǎng)絡(luò)地址的。對(duì)于處理器間通信來說，難以勝任讓所有消息都經(jīng)過UIPC協(xié)議任務(wù)。因此，UIPC應(yīng)用程序接口首先調(diào)用路由程序庫(kù)，看一看是否可以把消息直接發(fā)送到同一處理器上的任務(wù)隊(duì)列中。如果不可以，UIPC應(yīng)用程序接口就把消息轉(zhuǎn)發(fā)到UIPC協(xié)議任務(wù)。UIPC協(xié)議任務(wù)將通過協(xié)議棧傳送消息。在棧的網(wǎng)絡(luò)層上，路由應(yīng)用程序接口將再次被調(diào)用，以確定應(yīng)該在哪條物理鏈路上發(fā)送消息。請(qǐng)注意，UIPC任務(wù)可以由子任務(wù)組成。這取決于協(xié)議棧層的實(shí)現(xiàn)。但是，從UIPC應(yīng)用程序接口的角度來看，只需要知道有關(guān)單個(gè)UIPC協(xié)議任務(wù)的情況，并且與單個(gè)UIPC協(xié)議任務(wù)通信。在UIPC應(yīng)用程序接口把消息傳送給UIPC之后所發(fā)生的情況是隱藏的。路由程序庫(kù)上的注釋也是恰如其份的。路由是由協(xié)議的傳輸層和網(wǎng)絡(luò)層兩者負(fù)責(zé)的。網(wǎng)絡(luò)層確定應(yīng)該把消息發(fā)送到哪條物理鏈路上。網(wǎng)絡(luò)層根據(jù)網(wǎng)絡(luò)地址作出這樣的確定。傳輸層確定應(yīng)該把消息發(fā)送給哪個(gè)應(yīng)用。傳輸層根據(jù)應(yīng)用ID和網(wǎng)絡(luò)地址兩者作出這樣的確定。這取決于如何完成這些路由表的實(shí)現(xiàn)?？梢宰尵W(wǎng)絡(luò)層的路由表和傳輸層的路由表彼此分離，以便去耦這兩層。但是，從在協(xié)議任務(wù)外部的功能(例如，UIPC應(yīng)用程序接口)的角度來看，要求某些路由功能，而這與如何實(shí)現(xiàn)堆棧無關(guān)。因此，路由程序庫(kù)作為一個(gè)獨(dú)立的條目顯示出來的。實(shí)際上，可以僅把稀(thin)應(yīng)用程序接口加在網(wǎng)絡(luò)層和傳輸層展示的功能上面。協(xié)議層開放系統(tǒng)互連(OSI)堆棧模式用于定義存在于通信協(xié)議中的功能層。開放系統(tǒng)互連(OSI)是網(wǎng)絡(luò)結(jié)構(gòu)的模型，并且是一組實(shí)現(xiàn)它的協(xié)議?？梢园堰@組協(xié)議稱為協(xié)議棧。可以在7個(gè)層之間劃分OSI結(jié)構(gòu)，這7個(gè)層從最低到最高依次是(i)物理層、(ii)數(shù)字鏈路層、網(wǎng)絡(luò)層、(iv)傳輸層、(v)會(huì)話層、(vi)表示層、(vii)應(yīng)用層。本發(fā)明的UIPC堆棧模式符合開放系統(tǒng)互連(OSI)定義，但是，沒有必要包括開放系統(tǒng)互連(OSI)規(guī)定的所有7個(gè)層。UIPC協(xié)議被修整得適合于實(shí)時(shí)系統(tǒng)，并且不需要開放系統(tǒng)互連(OSI)層的所有功能。在如下的部分中描述本發(fā)明的各個(gè)層的功能。但是，在討論每層的規(guī)定之前，先把如下的一般要求應(yīng)用于每一層。這些要求被當(dāng)作實(shí)現(xiàn)這些層的原則。每層的首標(biāo)應(yīng)該包含協(xié)議鑒別符。該鑒別符指示在消息中正攜帶著哪種協(xié)議或協(xié)議組合。它在首標(biāo)內(nèi)通常是2個(gè)或3個(gè)位。這樣，將來無需改變其它協(xié)議，就可以實(shí)現(xiàn)不同的協(xié)議。例如，正在被網(wǎng)絡(luò)層處理的輸入消息可能含有指示哪個(gè)協(xié)議模塊應(yīng)該是要下一個(gè)處理消息的、在網(wǎng)絡(luò)層首標(biāo)中的協(xié)議鑒別符。如果UIPC想要支持諸如傳輸控制協(xié)議(TCP)或用戶數(shù)據(jù)報(bào)協(xié)議(UDP)之類的傳輸層協(xié)議，協(xié)議鑒別符就告訴網(wǎng)絡(luò)層是否把消息傳遞給傳輸控制協(xié)議或用戶數(shù)據(jù)報(bào)協(xié)議模塊。用戶數(shù)據(jù)報(bào)協(xié)議(UDP)指的是提供數(shù)據(jù)報(bào)服務(wù)的因特網(wǎng)標(biāo)準(zhǔn)網(wǎng)絡(luò)層、傳輸層和會(huì)話層協(xié)議。用戶數(shù)據(jù)報(bào)協(xié)議是像TCP那樣，放在因特網(wǎng)協(xié)議(IP)上面的層上無連接協(xié)議。一些協(xié)議層可能依賴于其它協(xié)議層，并且，不能獨(dú)立使用。例如，作為依賴于物理高級(jí)數(shù)字鏈路控制(HDLC)層的鏈路層協(xié)議的LAPD就是這種情況。縮寫“LAPD”代表D信道上的鏈路訪問過程。每一層都保存消息優(yōu)先級(jí)。高優(yōu)先級(jí)消息或數(shù)據(jù)段(在需要分段的長(zhǎng)消息的情況下)總是在其它消息或數(shù)據(jù)段之前發(fā)送。值得推薦的是，本發(fā)明只支持兩種優(yōu)先級(jí)，即正常的和高的。任何更多的優(yōu)先級(jí)都有可能引起混亂。但是，本發(fā)明可以支持其它的優(yōu)先級(jí)。每一層都應(yīng)該提供標(biāo)志，以便使那一層上擴(kuò)充的協(xié)議在將來可以擴(kuò)充。如何把它付諸實(shí)施的例子是為網(wǎng)絡(luò)層預(yù)訂提供擴(kuò)充尋址的特殊標(biāo)志值。每一層可以定義在端點(diǎn)的同等層之間交換的特殊控制消息。這些控制消息可以讓每一方都能協(xié)商協(xié)議參數(shù)或進(jìn)行流控制。如下的部分描述每個(gè)協(xié)議層的特性和責(zé)任。每個(gè)部分還包括該層應(yīng)該提供的一系列原語。原語的作用是顯示向其它軟件(即，相鄰上協(xié)議層)提供的外部接口。它們不描述在兩個(gè)端點(diǎn)之間傳遞的實(shí)際消息。這里不描述這樣的消息的定義和任何相關(guān)的狀態(tài)機(jī)。在進(jìn)行詳細(xì)設(shè)計(jì)時(shí)再定義它們。原語是利用國(guó)際電信聯(lián)盟(ITU)專門術(shù)語命名的，并且被分類成Request(請(qǐng)求)、Respone(響應(yīng))、Indication(指示)和Confirm(確認(rèn))。Request這是層必須支持的函數(shù)，其作用是由在它上面的相鄰層調(diào)用去請(qǐng)求一些動(dòng)作。Respone這是由遠(yuǎn)端在接收到請(qǐng)求響應(yīng)的指示時(shí)調(diào)用的。其結(jié)果是，請(qǐng)求者將接收到確認(rèn)。Indication這是發(fā)生了某一事件的通告。意圖是讓相鄰上層或生成的代碼過一會(huì)接收這些指示。大多數(shù)指示是遠(yuǎn)端通過請(qǐng)求，啟動(dòng)一些動(dòng)作的結(jié)果。Confirm這是已經(jīng)對(duì)請(qǐng)求作出響應(yīng)的確認(rèn)。每個(gè)原語都含有與之相聯(lián)系的原語專用數(shù)據(jù)。在層與層之間傳遞原語的機(jī)制在這里不是特別規(guī)定的，因?yàn)樗菍拥脑敿?xì)設(shè)計(jì)的一部分。注意到必須定義最大傳輸單位(MTU)也是很重要的。最大傳輸單位(MTU)定義最大消息尺寸。在這個(gè)尺寸以下的任何消息都以單個(gè)消息發(fā)送。因此，高優(yōu)先級(jí)的時(shí)間關(guān)鍵因素的消息可以在不長(zhǎng)于兩個(gè)長(zhǎng)度為最大發(fā)送單位的消息所花費(fèi)的時(shí)間(一個(gè)時(shí)間間隔用于發(fā)送消息，另一個(gè)時(shí)間間隔用于發(fā)送高優(yōu)先級(jí)消息)的時(shí)間內(nèi)得到處理。為了保證正好是這種情況，在網(wǎng)絡(luò)層消息、鏈路層消息、和物理層(例如，高級(jí)數(shù)據(jù)鏈路控制)幀之間存在著一一對(duì)應(yīng)關(guān)系。需要在這些等級(jí)上把消息捆綁在一起，以便有助于保證實(shí)時(shí)性能。確定最大發(fā)送單位是應(yīng)用設(shè)計(jì)的一部分。這樣，不將其定義成UIPC的一部分。但是，UIPC的確定義了只有UIPC部件可見的內(nèi)部應(yīng)用程序接口(API)，以便設(shè)置最大發(fā)送單位。最大發(fā)送單位由應(yīng)用性能要求、應(yīng)該獲取消息的跳段數(shù)、和正在使用的通信鏈路的速度來決定。存在著源自把消息從一個(gè)節(jié)點(diǎn)路由到下一個(gè)節(jié)點(diǎn)的網(wǎng)絡(luò)的復(fù)雜因素。如果最大發(fā)送單位(MTU)對(duì)于每個(gè)跳段來說，都是不同的，那么，必須采取一些措施來解決不一致性問題。問題出在一個(gè)節(jié)點(diǎn)發(fā)送MTU大的消息，而在具有小MTU的跳段上通過節(jié)點(diǎn)轉(zhuǎn)發(fā)消息的時(shí)候。一個(gè)節(jié)點(diǎn)難以知道消息在上面行進(jìn)的所有鏈路的所有MTU。事實(shí)上，發(fā)送節(jié)點(diǎn)甚至可能不知道在什么鏈路上行進(jìn)。它所知道的就是讓消息到達(dá)相鄰節(jié)點(diǎn)。因此，在每個(gè)節(jié)點(diǎn)上的協(xié)議棧應(yīng)該解決與那個(gè)節(jié)點(diǎn)相連接的鏈路上的MTU尺寸之間的差異。如本說明書下文的“網(wǎng)絡(luò)層”部分所述的，網(wǎng)絡(luò)層具有消息分段功能。這應(yīng)該被用來把較大的MTU分段成較小的MTU。如果網(wǎng)絡(luò)層在每個(gè)節(jié)點(diǎn)上沒有這樣做，那么，另一種可選方案將建立端到端連接，并且通過所有節(jié)點(diǎn)協(xié)議最大MTU應(yīng)該是什么。但是，這種方式將導(dǎo)致額外開銷，并且對(duì)無連接消息力不從心。UIPC靜態(tài)消息管理表每個(gè)任務(wù)必須完成靜態(tài)消息管理表。UIPC靜態(tài)消息管理表每當(dāng)任務(wù)調(diào)用Uipc_RegisterMsgHandler()時(shí)，在靜態(tài)消息管理表中形成一個(gè)條目。靜態(tài)消息管理表專用于觀察應(yīng)用程序接口。每當(dāng)消息借助于像UIPC_MSG_REP或UIPC_MSG_REQ那樣的消息方向到達(dá)時(shí)，就利用消息類別查找該表格，以找出相應(yīng)的回調(diào)函數(shù)。如果找到條目，那么，就調(diào)用回調(diào)函數(shù)。與動(dòng)態(tài)消息處理表不同，靜態(tài)消息管理表中的條目是永久的。靜態(tài)消息管理表是利用陣列實(shí)現(xiàn)的。因?yàn)槊總€(gè)表擁有它自己的靜態(tài)消息管理表，所以不需要旗語來保護(hù)這個(gè)表。UIPC動(dòng)態(tài)消息類別表每個(gè)任務(wù)必須完成動(dòng)態(tài)消息類別表。每當(dāng)任務(wù)調(diào)用Uipc_GenerateTempMsgClass()時(shí)，把靜態(tài)消息類別范圍(從UIPC_DYN_MSG_CLASS_START到UIPC_MAX_NO_DYN_MSG_CLASS)內(nèi)的自由消息類別賦予任務(wù)。如果沒有自由消息類別可用，那么，向應(yīng)用程序接口用戶報(bào)告沒有可用的。在分配了自由消息類別之后，更新這個(gè)表格，以便使特定消息類別變成被使用的。每當(dāng)任務(wù)調(diào)用Uipc_FreeTempMsgClass()時(shí)，就釋放消息類別，以便將來可以使用特定的消息類別。因?yàn)槊總€(gè)表擁有它自己的動(dòng)態(tài)消息類別表，所以不需要旗語來保護(hù)這個(gè)表。網(wǎng)絡(luò)層網(wǎng)絡(luò)層負(fù)責(zé)獲取處理器之間的消息。網(wǎng)絡(luò)層具有如下特性。網(wǎng)絡(luò)層根據(jù)網(wǎng)絡(luò)地址路由消息。網(wǎng)絡(luò)層檢查網(wǎng)絡(luò)地址，以確定是否把消息指定到接收它的處理器，或者是否需要通過另一個(gè)接口轉(zhuǎn)發(fā)消息，讓它到達(dá)它的最后目的地。網(wǎng)絡(luò)層支持消息的分段/組裝。因?yàn)椴煌逆溌房梢跃哂谐叽绮煌淖畲髠鬏攩挝?MTU)，所以，與網(wǎng)絡(luò)層可以不讓消息通過傳輸層地路由它們的事實(shí)結(jié)合在一起來考慮，網(wǎng)絡(luò)層也可以處理MTU尺寸之間的轉(zhuǎn)換。這意味著在這一層上支持消息分段和組裝。網(wǎng)絡(luò)層對(duì)應(yīng)于無狀態(tài)操作。因?yàn)榫W(wǎng)絡(luò)層不提供可靠的點(diǎn)到點(diǎn)或端到端消息傳輸，所以它是無狀態(tài)的。一旦消息被發(fā)送出去，就忘掉它。點(diǎn)到點(diǎn)的可靠性是由數(shù)據(jù)鏈路層來負(fù)責(zé)的。必要時(shí)，端到端的可靠性由傳輸層來負(fù)責(zé)。類別D路由-特殊情況網(wǎng)絡(luò)層還必須支持把消息路由到附在插件上的設(shè)備中。這些設(shè)備的一些可以通過UIPC通信。在這種情況中，它們將具有類別D地址，并且，把消息路由到這些地址就像把消息路由到任何其它地址一樣。如果它們不運(yùn)用UIPC，網(wǎng)絡(luò)層必須實(shí)施借此設(shè)備可以具有虛地址的措施。在這種情況下，代理應(yīng)用將在插件和寄存器上運(yùn)行，以接收有關(guān)特定類別D地址的消息。代理應(yīng)用負(fù)責(zé)接收這些消息和把它們轉(zhuǎn)發(fā)到各個(gè)設(shè)備。另外，這些消息不需要利用傳輸層協(xié)議，因?yàn)?，并不把它們指定給各種應(yīng)用。請(qǐng)注意，原語只松散地對(duì)應(yīng)于國(guó)際電信聯(lián)盟(ITU)定義。請(qǐng)參見上述文件“開放系統(tǒng)互連，網(wǎng)絡(luò)服務(wù)定義，ITU-TX.213”。這是因?yàn)閲?guó)際電信聯(lián)盟(ITU)使用了比UIPC所需的更復(fù)雜的模型。它把網(wǎng)絡(luò)層模型化成兩個(gè)端點(diǎn)之間的連接。面向連接網(wǎng)絡(luò)層比網(wǎng)絡(luò)層要復(fù)雜得多，因?yàn)橐呀?jīng)為它提供了鏈路層。另外把UIPC的網(wǎng)絡(luò)層模型化成像不需要連接的因特網(wǎng)協(xié)議(IP)那樣的基于分組的協(xié)議。另外，國(guó)際電信聯(lián)盟(ITU)不定義指定網(wǎng)絡(luò)地址的任何機(jī)制。假設(shè)這個(gè)信息以某種方式適用于網(wǎng)絡(luò)層。因此，UIPC定義了附加的地址相關(guān)原語，以便網(wǎng)絡(luò)層具有執(zhí)行地址指定功能的接口。原語與網(wǎng)絡(luò)層的外部接口顯示在表3的原語中。表3-網(wǎng)絡(luò)層原語和參數(shù)一覽表這些參數(shù)定義如下。術(shù)語“遠(yuǎn)端網(wǎng)絡(luò)地址”指的是把操作對(duì)準(zhǔn)它的節(jié)點(diǎn)的地址。術(shù)語“優(yōu)先級(jí)”指的是用戶數(shù)據(jù)的優(yōu)先級(jí)。術(shù)語“協(xié)議描述符”指的是在用戶數(shù)據(jù)中攜帶更高級(jí)協(xié)議的標(biāo)識(shí)符。術(shù)語“用戶數(shù)據(jù)”指的是發(fā)送的數(shù)據(jù)。用戶數(shù)據(jù)對(duì)網(wǎng)絡(luò)層是透明的。請(qǐng)注意，原語只松散地對(duì)應(yīng)于國(guó)際電信聯(lián)盟(ITU)定義。請(qǐng)參見上述文件“開放系統(tǒng)互連，網(wǎng)絡(luò)服務(wù)定義，ITU-TX.213”。這是因?yàn)閲?guó)際電信聯(lián)盟(ITU)使用了比UIPC所需的更復(fù)雜的模型。它把網(wǎng)絡(luò)層模型化成兩個(gè)端點(diǎn)之間的連接。面向連接網(wǎng)絡(luò)層比網(wǎng)絡(luò)層要復(fù)雜得多，因?yàn)橐呀?jīng)為它提供了鏈路層。另外把UIPC的網(wǎng)絡(luò)層模型化成像不需要連接的因特網(wǎng)協(xié)議(IP)那樣的基于分組的協(xié)議。另外，國(guó)際電信聯(lián)盟(ITU)不定義指定網(wǎng)絡(luò)地址的任何機(jī)制。假設(shè)這個(gè)信息以某種方式適用于網(wǎng)絡(luò)層。因此，UIPC定義了附加的地址相關(guān)原語，以便網(wǎng)絡(luò)層具有執(zhí)行地址指定功能的接口。根據(jù)網(wǎng)絡(luò)層所需的操作，如下信息應(yīng)該是網(wǎng)絡(luò)層消息首標(biāo)的組成部分目的地地址、源地址、網(wǎng)絡(luò)消息類型(可以是網(wǎng)絡(luò)層控制或用戶數(shù)據(jù)消息的某種類型)、分段信息(與分段的消息有關(guān)的)、控制(用于網(wǎng)絡(luò)層控制消息和指示消息的類型)。傳輸層傳輸層負(fù)責(zé)應(yīng)用之間的端到端通信。它具有如下特性把消息路由到作為端點(diǎn)的應(yīng)用或服務(wù)-傳輸層引入了應(yīng)用ID的概念。應(yīng)用可以登記它們自己，以接收為特定應(yīng)用ID指定的消息。這支持客戶機(jī)/服務(wù)器應(yīng)用。這一層將確定是否應(yīng)該把消息路由到這個(gè)處理器上的任務(wù)中。以消息為基礎(chǔ)-借助于寫操作和緩沖器調(diào)用傳輸層，在單個(gè)讀操作中，在遠(yuǎn)端上接收緩沖器中的數(shù)據(jù)?？梢园丫彌_器看成是一種消息。這可以與基于流方法相對(duì)照，在基于流的方法中，讀操作與在單個(gè)寫操作中還是在多個(gè)寫操作中發(fā)送字節(jié)無關(guān)地簡(jiǎn)單接收偶爾適用的字節(jié)。提供無連接消息傳送。在這種情況中，依靠應(yīng)用和低層來保證可靠的端到端傳輸。為了降低額外開銷，無連接消息傳送不追究遠(yuǎn)端實(shí)際上是否接收到消息和消息是否是有效的。低層通過CRC(循環(huán)冗余校驗(yàn))檢驗(yàn)已經(jīng)保證了消息是有效的，并且讓消息逐條鏈路地重新發(fā)送。一般來說，如果應(yīng)用必須知道遠(yuǎn)端應(yīng)用接收到消息，它就期望應(yīng)用級(jí)確認(rèn)。由于這些其它層共同負(fù)擔(dān)保證有效端到端傳輸?shù)墓ぷ?，因此，可以使用無連接操作。但是，請(qǐng)注意，傳輸層的確具有舍棄掉部分消息的機(jī)制，在那里長(zhǎng)消息的某些段可能已經(jīng)被丟棄掉了。由于這種無連接消息傳送比面向連接消息傳送更易實(shí)現(xiàn)，因此，建議首先實(shí)現(xiàn)這種無連接消息傳送。提供面向連接消息傳送。在這種情況中，為應(yīng)用建立和維持端到端連接。這在功能上類似于傳輸控制協(xié)議(TCP)網(wǎng)絡(luò)接口。當(dāng)在面向連接路徑上設(shè)置和通信時(shí)，存在著附加的額外開銷和復(fù)雜性。因此，建議只有當(dāng)不指望通信那么可靠時(shí)，或當(dāng)資源或?qū)崟r(shí)考慮較少時(shí)才使用這種模式。雖然在這里沒有規(guī)定，但是支持無連接和面向連接消息傳送的低級(jí)設(shè)計(jì)可能包括兩個(gè)獨(dú)立的傳輸層模塊或?qū)崿F(xiàn)兩種類型的消息傳送的單個(gè)模塊的使用。多路復(fù)用來自可變端點(diǎn)的消息-假設(shè)多個(gè)端點(diǎn)可以發(fā)送同一個(gè)應(yīng)用，傳輸層根據(jù)源地址組裝消息。建造路由表為了把消息路由給特定的應(yīng)用，傳輸層負(fù)責(zé)建造把應(yīng)用ID的路由表構(gòu)造成真實(shí)消息隊(duì)列ID的映射。對(duì)路由表的訪問需要通過只有UIPC部件看得見的內(nèi)部應(yīng)用程序接口(AP1)展示出來。這樣做是需要的，以便可以通過UIPC應(yīng)用程序接口功能進(jìn)行有效查詢，以確定應(yīng)該在處理器上，還是不在處理器上路由消息。原語到傳輸層的外部接口顯示在表4的原語中。請(qǐng)注意，連接建立和釋放原語只應(yīng)用于面向連接模式。表4-傳輸層原語和參數(shù)一覽表術(shù)語“應(yīng)用ID”指的是應(yīng)用的標(biāo)識(shí)符。它用于區(qū)分可以具有給定網(wǎng)絡(luò)地址的處理器提供的個(gè)別服務(wù)。應(yīng)用可以具有熟知ID，從而其它其它可以尋址它們。應(yīng)用ID是可移植跨接處理器的限制值。應(yīng)用ID和網(wǎng)絡(luò)地址組合在一起形成應(yīng)用的唯一地址。術(shù)語“遠(yuǎn)端網(wǎng)絡(luò)地址”指的是把操作指向它的節(jié)點(diǎn)的地址。術(shù)語“近端網(wǎng)絡(luò)地址”指的是指定給近端的地址。術(shù)語“始發(fā)者”指示動(dòng)作是由傳輸層的用戶先發(fā)起，還是由傳輸本身先發(fā)起。術(shù)語“優(yōu)先級(jí)”指示用戶數(shù)據(jù)的優(yōu)先級(jí)。術(shù)語“協(xié)議描述符”指的是表示由用戶數(shù)據(jù)中攜帶著什么樣的更高級(jí)協(xié)議的標(biāo)識(shí)符。術(shù)語“隊(duì)列管理”指的是管理要接收指向特定應(yīng)用ID的消息的隊(duì)列。隊(duì)列管理指向與隊(duì)列的擁有者的應(yīng)用ID有關(guān)的信息。術(shù)語“理由”指的是動(dòng)作的理由代碼。這是實(shí)現(xiàn)專用的。術(shù)語“用戶數(shù)據(jù)”指的是發(fā)送的數(shù)據(jù)。它對(duì)傳輸層是透明的。請(qǐng)注意，傳輸層含有不與國(guó)際電信聯(lián)盟(ITU)定義中的任何東西對(duì)應(yīng)的原語。請(qǐng)參見上述文件“開放系統(tǒng)互連，傳輸服務(wù)定義，ITU-TX.214”。這是因?yàn)閲?guó)際電信聯(lián)盟(ITU)不含有設(shè)置傳輸服務(wù)訪問點(diǎn)(TSAP)的原語。傳輸服務(wù)訪問點(diǎn)大體上對(duì)應(yīng)于應(yīng)用ID。國(guó)際電信聯(lián)盟(ITU)假定傳輸服務(wù)訪問點(diǎn)通過一些其它手段登記，和信息適用于傳輸層。相反，UIPC傳輸層含有登記應(yīng)用ID和根據(jù)它們建造路由表的附加原語。消息首標(biāo)推薦根據(jù)傳輸層所需的操作，如下的信息應(yīng)該是網(wǎng)絡(luò)層消息首標(biāo)的組成部分開始應(yīng)用ID、終止應(yīng)用ID、控制(用于傳輸層控制消息和指示消息的類型)。應(yīng)用層本發(fā)明的UIPC不包括應(yīng)用層協(xié)議。圖6是根據(jù)本發(fā)明原理的、核實(shí)部件功能的測(cè)試方法。圖6顯示了黑箱(blackbox)測(cè)試。圖6顯示了根據(jù)本發(fā)明原理的、用于測(cè)試的可能配置。它依靠操作系統(tǒng)無關(guān)訪問層(OIA)來抽象化操作系統(tǒng)調(diào)用，以便測(cè)試系統(tǒng)可以在工作站操作系統(tǒng)上運(yùn)行。有兩種進(jìn)程在運(yùn)行進(jìn)程1(610)和進(jìn)程2(612)。在每種進(jìn)程中的是代表實(shí)時(shí)操作系統(tǒng)任務(wù)的線程。因?yàn)檫M(jìn)程在獨(dú)立的存儲(chǔ)空間中運(yùn)行，所以每個(gè)進(jìn)程可以具有與別的進(jìn)程無關(guān)地運(yùn)行的UIPC事例。因此，它們可以是，每一個(gè)都具有它們自己的UIPC網(wǎng)絡(luò)地址。任務(wù)1(614)、任務(wù)2(616)、和任務(wù)3(618)代表可以驅(qū)動(dòng)UIPC應(yīng)用程序接口(AIP)628和630的應(yīng)用。UIPC任務(wù)620在進(jìn)程1內(nèi)部運(yùn)行。UIPC任務(wù)622在進(jìn)程2內(nèi)部運(yùn)行。UIPC應(yīng)用程序接口在操作系統(tǒng)無關(guān)訪問(OIA)層632和634上運(yùn)行，并且適用于各種任務(wù)。UIPC把操作系統(tǒng)無關(guān)訪問(OIA)層用于消息排隊(duì)功能。為了模擬處理器間通信，使用了設(shè)備無關(guān)訪問(DIA)層通信驅(qū)動(dòng)器模擬器624和626。這些模擬器可以僅使用一些，如網(wǎng)絡(luò)接口。它們也可以把錯(cuò)誤注入，以核實(shí)協(xié)議管理錯(cuò)誤。由于這是UIPC部件的測(cè)試，而不是設(shè)備無關(guān)訪問(DIA)層的測(cè)試，因此，模擬器需要做的唯一事情是獲得兩個(gè)進(jìn)程之間的消息。可以把圖6推廣到包括模擬不同類別路由器的其它進(jìn)程。為了進(jìn)行測(cè)試，可以對(duì)任務(wù)1-3編程，以運(yùn)行UIPC應(yīng)用程序接口的各種序列和自動(dòng)核實(shí)結(jié)果。其它選擇包括利用腳本或讓用戶界面執(zhí)行各種命令。與它們?nèi)绾悟?qū)動(dòng)UIPC無關(guān)，這是從黑箱的視角來做的。對(duì)于UIPC來說，這些任務(wù)看起來與任何其它任務(wù)一樣。雖然通過對(duì)本發(fā)明實(shí)施例的描述已經(jīng)展示了本發(fā)明，并且，雖然已經(jīng)相當(dāng)詳細(xì)地描述了這些實(shí)施例，但是，限于這樣的細(xì)節(jié)，或者，無論以何種方式把所附權(quán)利要求的范圍限于這樣的細(xì)節(jié)都不是本申請(qǐng)人的意圖。對(duì)于本領(lǐng)域的普通技術(shù)人員來說，其它各種優(yōu)點(diǎn)和改進(jìn)是顯然的。因此，從更寬泛的方面來講，本發(fā)明不限于所示的和所述的具體細(xì)節(jié)、典型的設(shè)備和方法、以及示范性的例子。于是，偏離這樣的細(xì)節(jié)并不意味著偏離申請(qǐng)人一般性發(fā)明構(gòu)思的精神內(nèi)涵或范圍。權(quán)利要求1.一種把消息數(shù)據(jù)從源傳送到目的地的方法，該方法包括與通信設(shè)備的操作系統(tǒng)無關(guān)地發(fā)送消息數(shù)據(jù)，所述發(fā)送至少部分通過操作系統(tǒng)無關(guān)訪問層進(jìn)行；和與設(shè)備的硬件無關(guān)地傳輸消息數(shù)據(jù)，所述傳輸至少部分通過設(shè)備無關(guān)訪問層進(jìn)行。2.根據(jù)權(quán)利要求1所述的方法，設(shè)備形成用于機(jī)框間消息的共享總線布局。3.根據(jù)權(quán)利要求1所述的方法，設(shè)備形成用于機(jī)框間消息的星形總線布局。4.根據(jù)權(quán)利要求1所述的方法，還包括借助于設(shè)備的操作系統(tǒng)部分處理設(shè)備內(nèi)的內(nèi)部通信；和借助于設(shè)備的硬件部分處理與設(shè)備的外部通信。5.根據(jù)權(quán)利要求1所述的方法，還包括當(dāng)源和目的地兩者都在設(shè)備的第一機(jī)框上時(shí)，和當(dāng)源在第一機(jī)框上和目的地在設(shè)備的第二機(jī)框上時(shí)，以及當(dāng)源在第二機(jī)框的第一插件上和目的地在第二機(jī)框的第二插件上時(shí)，和當(dāng)源在第一機(jī)框上和目的地在設(shè)備的外部和不在機(jī)框的任何一個(gè)上時(shí)，進(jìn)行消息數(shù)據(jù)從源到目的地的所述傳送。6.一種把消息數(shù)據(jù)從源傳輸?shù)侥康牡氐耐ㄐ旁O(shè)備，該設(shè)備包括設(shè)備的操作系統(tǒng)部分，用于與所述設(shè)備的操作系統(tǒng)無關(guān)地處理所述設(shè)備內(nèi)的內(nèi)部通信；和設(shè)備的硬件部分，用于與所述設(shè)備中的硬件設(shè)備無關(guān)地處理與所述設(shè)備的外部通信。7.根據(jù)權(quán)利要求6所述的設(shè)備，還包括用于機(jī)框間消息的共享總線布局。8.根據(jù)權(quán)利要求6所述的設(shè)備，還包括用于機(jī)框間消息的星形總線布局。9.根據(jù)權(quán)利要求6所述的設(shè)備，還包括至少包括第一插件的第一機(jī)框；和至少包括第二插件和第三插件的第二機(jī)框；當(dāng)源和目的地兩者都在設(shè)備的所述第一機(jī)框上時(shí)，和當(dāng)源在所述第一機(jī)框上和目的地在所述第二機(jī)框上時(shí)，以及當(dāng)源在所述第二插件上和目的地在所述第三插件上時(shí)，和當(dāng)源在所述第一機(jī)框上和目的地在設(shè)備的外部和不在機(jī)框的任何一個(gè)上時(shí)，所述設(shè)備進(jìn)行消息數(shù)據(jù)從源到目的地的所述傳輸。10.一種在上面存儲(chǔ)著一組指令的計(jì)算機(jī)存儲(chǔ)介質(zhì)，該組指令用于實(shí)現(xiàn)把消息數(shù)據(jù)從源傳送到目的地的方法，該組指令包括用于執(zhí)行下列步驟的一條或多條指令與通信設(shè)備的操作系統(tǒng)無關(guān)地發(fā)送消息數(shù)據(jù)，所述發(fā)送至少部分通過操作系統(tǒng)無關(guān)訪問層進(jìn)行；和與設(shè)備的硬件無關(guān)地傳輸消息數(shù)據(jù)，所述傳輸至少部分通過設(shè)備無關(guān)訪問層進(jìn)行。11.根據(jù)權(quán)利要求10所述的存儲(chǔ)介質(zhì)，設(shè)備形成用于機(jī)框間消息的共享總線布局。12.根據(jù)權(quán)利要求10所述的存儲(chǔ)介質(zhì)，設(shè)備形成用于機(jī)框間消息的星形總線布局。13.根據(jù)權(quán)利要求10所述的存儲(chǔ)介質(zhì)，還包括借助于設(shè)備的操作系統(tǒng)部分處理設(shè)備內(nèi)的內(nèi)部通信；和借助于設(shè)備的硬件部分處理與設(shè)備的外部通信。14.根據(jù)權(quán)利要求10所述的存儲(chǔ)介質(zhì)，還包括當(dāng)源和目的地兩者都在設(shè)備的第一機(jī)框上時(shí)，和當(dāng)源在第一機(jī)框上和目的地在設(shè)備的第二機(jī)框上時(shí)，以及當(dāng)源在第二機(jī)框的第一插件上和目的地在第二機(jī)框的第二插件上時(shí)，和當(dāng)源在第一機(jī)框上和目的地在設(shè)備的外部和不在機(jī)框的任何一個(gè)上時(shí)，進(jìn)行消息數(shù)據(jù)從源到目的地的所述傳送。全文摘要與不同硬件和軟件兼容的統(tǒng)一進(jìn)程間通信系統(tǒng)和統(tǒng)一進(jìn)程間通信方法。統(tǒng)一進(jìn)程間通信系統(tǒng)可以與使用的通信方法無關(guān)地與任何設(shè)備一起使用。統(tǒng)一進(jìn)程間通信(UIPC)方法是高度可移植的，因?yàn)閁IPC方法把設(shè)備無關(guān)訪問層(DIA)引入到系統(tǒng)中，并且把進(jìn)程間通信與每個(gè)硬件設(shè)備松散地耦合起來。文檔編號(hào)H04L29/08GK1404264SQ0211618公開日2003年3月19日申請(qǐng)日期2002年4月23日優(yōu)先權(quán)日2001年9月4日發(fā)明者尹寧鉉申請(qǐng)人:三星電子株式會(huì)社