專利名稱：一種GIOP到RapidIO的新協(xié)議的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及嵌入式系統(tǒng)中的通信協(xié)議，具體涉及一種GIOP到RapidIO的新協(xié)議。
背景技術(shù)：
RapidIO是一種高速、分組交換、全雙工的互連體系結(jié)構(gòu)，它的提出是針對(duì)在芯片間及板間進(jìn)行數(shù)據(jù)和控制信息的傳輸，其傳輸效率高于以太網(wǎng)，在嵌入式系統(tǒng)領(lǐng)域具有明顯的優(yōu)勢(shì)。通用ORB間協(xié)議GIOP (general Inter-ORB protocol)為ORB之間的交互詳細(xì)規(guī)定了一套標(biāo)準(zhǔn)的傳輸語(yǔ)法(低層次的數(shù)據(jù)表達(dá))和一系列消息格式。GIOP是為ORB到ORB之間的交互而創(chuàng)建的，它直接工作在任何滿足規(guī)定的面向連接的傳輸協(xié)議上。GIOP使CORBA可以在不同操作系統(tǒng)和編程語(yǔ)言的環(huán)境下實(shí)現(xiàn)客戶和服務(wù)器對(duì)象的互操作。在CORBA規(guī)范中，對(duì)于GIOP自身而言，它不提供完整的交互功能，它必須被映射為具體的協(xié)議。GIOP到TCP/IP存在映射II0P，但是TCP/IP應(yīng)用在嵌入式系統(tǒng)中有明顯的局限性，因此越來(lái)越多的嵌入系統(tǒng)采用RapidIO技術(shù)，GIOP到RapidIO之間映射的研究還處于空白階段。CORBA參照模型包 括ORB內(nèi)核(ORB core)、對(duì)象適配、客戶端存根(IDL stub)和服務(wù)端框架(IDL skeleton)、動(dòng)態(tài)DII/DS1、CORBA客戶端和服務(wù)端、ORB之上的服務(wù)(包括名字服務(wù)，事件服務(wù))、底層驅(qū)動(dòng)等。從CORBA的體系中可以看出，CORBA客戶端程序與服務(wù)端程序進(jìn)行數(shù)據(jù)通信的基礎(chǔ)是建立了統(tǒng)一的GIOP協(xié)議以及統(tǒng)一的數(shù)據(jù)通信架構(gòu)?？蛻舳藢?duì)不同地址空間中的遠(yuǎn)端服務(wù)對(duì)象的使用過(guò)程，如同從本地的地址空間一樣方便。GIOP 協(xié)議內(nèi)容包括公共數(shù)據(jù)表不 CDR (common data representation)、GI0P 消息格式、GIOP消息傳輸、IIOP協(xié)議(internet ORB間協(xié)議)以及雙向GIOP (B1-DirectionalGI0P)。GIOP定義了不同ORB間互操作的協(xié)議，它提供一個(gè)抽象協(xié)議規(guī)范，能被映射為常見(jiàn)的面向連接的傳輸協(xié)議。應(yīng)用最廣泛的因特網(wǎng)ORB間協(xié)議(II0P，internet Inter-ORBprotocol)就是GIOP消息傳輸?shù)絋CP/IP連接的映射。在基于網(wǎng)線傳輸?shù)臋C(jī)制與TCP/IP協(xié)議基礎(chǔ)上，IIOP協(xié)議就是具體的GIOP實(shí)現(xiàn)。但是由于過(guò)多的編碼/解碼，數(shù)據(jù)復(fù)制以及高階的功能調(diào)用，HOP協(xié)議在高速網(wǎng)絡(luò)中表現(xiàn)出較低的性能。

發(fā)明內(nèi)容
針對(duì)上述現(xiàn)有技術(shù)，本發(fā)明要解決的技術(shù)問(wèn)題是由于過(guò)多的編碼/解碼，數(shù)據(jù)復(fù)制以及高階的功能調(diào)用，IIOP協(xié)議在高速網(wǎng)絡(luò)中表現(xiàn)出較低的性能。為了解決上述技術(shù)問(wèn)題，本發(fā)明采用如下技術(shù)方案
一種GIOP到RapidIO的新協(xié)議，其特征在于，包括硬件層、RapidIO總線層、RCS協(xié)議棧層、RI0-10P協(xié)議層、GIOP層、應(yīng)用層；在硬件層中采用RapidIO接口接入板卡上RapidIO交換芯片；在所述RapidIO總線層中，所述RapidIO交換芯片的物理鏈路再接入交換網(wǎng)絡(luò)中，網(wǎng)絡(luò)中的交換模塊負(fù)責(zé)維護(hù)點(diǎn)對(duì)點(diǎn)通信的路由信息；所述RCS協(xié)議棧層運(yùn)行在RapidIO的網(wǎng)絡(luò)中的各個(gè)非交換節(jié)點(diǎn)上，RCS協(xié)議棧為對(duì)RapidIO的第一次封裝，通過(guò)RCS協(xié)議?？梢詫?shí)現(xiàn)節(jié)點(diǎn)間的快速通信與數(shù)據(jù)交換；所述RIO-1OP協(xié)議層由對(duì)RapidIO進(jìn)行第二次封裝，即把RCS封裝成RIO-1OP協(xié)議，這樣RIO-1OP協(xié)議使得所有的GIOP消息可以通過(guò)RCS協(xié)議棧發(fā)送和接收。作為本發(fā)明進(jìn)一步的改進(jìn)，還包括ORB傳輸層服務(wù)端，ORB傳輸層服務(wù)端包含傳輸模塊初始化組件、對(duì)同一目標(biāo)地址空間的連接分組組件、遵循GIOP協(xié)議的GIOP消息機(jī)制組件、實(shí)現(xiàn)在RapidIO總線上的GIOP的映射RIO-1OP組件、線程策略組件、協(xié)議包的封裝組件⑶R和傳輸規(guī)則組件。作為本發(fā)明進(jìn)一步的改進(jìn)，還包括ORB傳輸層客戶端，所述ORB傳輸層客戶端包括傳輸模塊初始化組件，連接分組組件，GIOP消息機(jī)制組件以及RCS協(xié)議的GIOP映射RIO-1OP 組件。作為本發(fā)明進(jìn)一步的改進(jìn)，在客戶端呼叫服務(wù)對(duì)象的過(guò)程中，客戶端對(duì)象將通過(guò)CDR對(duì)象將請(qǐng)求封裝成GIOP協(xié)議格式，發(fā)送到服務(wù)端。作為本發(fā)明進(jìn)一步的改進(jìn)，傳輸層提供給的外部接口包括連接接口connect,監(jiān)控連接事件接口 acceptAndMonitor,監(jiān)控連接接口 monitor,通知可讀接口notifyReadable,發(fā)送請(qǐng)求接口 sendRequest,接收反饋接口 receiveReply,接收請(qǐng)求接口receiveReques,發(fā)送反饋接口 sendReply,數(shù)據(jù)發(fā)送接口 send,數(shù)據(jù)接收接口 recv。IOR采用IDL結(jié)構(gòu)來(lái)·定義，一個(gè)對(duì)象引用IOR中包含了多個(gè)taggedProfile對(duì)象，每一個(gè)taggedProfile對(duì)象是包含了用來(lái)聯(lián)系遠(yuǎn)程對(duì)象的多種協(xié)議方式；每一種taggedProfile對(duì)象中包含了一個(gè)ProfileId,如何對(duì)該對(duì)象的編解碼進(jìn)行解析,就依賴該標(biāo)識(shí)。CORBA客戶端通過(guò)IOR調(diào)用服務(wù)端對(duì)象服務(wù)，客戶端與服務(wù)端以IOR形式通過(guò)網(wǎng)絡(luò)連接進(jìn)行數(shù)據(jù)的通信，所述網(wǎng)絡(luò)連接方式有三種分別為單向連接上多重呼叫MultiplecallPer Connection、單向連接上的單重呼叫 onecallPer Connection、雙向連接bidirectionConnection
與現(xiàn)有技術(shù)相比，本發(fā)明具有以下有益效果
將基于高速總線RapidIO的協(xié)議棧RCS無(wú)縫銜接到CORBA的傳輸層，把抽象協(xié)議GIOP映射為具體的RapidIO，從理論和實(shí)踐上提出并實(shí)現(xiàn)了全新的RI0-10P協(xié)議，完成經(jīng)由RI0-10P協(xié)議的CORBA基本調(diào)用。


圖1為使用配置的RI0-10P連接服務(wù)端示意 圖2 RI0-10P建立到服務(wù)對(duì)象的連接過(guò)程 圖3為ORB傳輸層組件模型；
圖4為網(wǎng)絡(luò)層次模型對(duì)比圖。
具體實(shí)施例方式下面將結(jié)合附圖及具體實(shí)施方式
對(duì)本發(fā)明作進(jìn)一步的描述。
實(shí)施例一 IOR的組成
客戶端通過(guò)對(duì)象的引用與服務(wù)端建立通信聯(lián)系，服務(wù)端在創(chuàng)建服務(wù)對(duì)象的時(shí)候，根據(jù)對(duì)象創(chuàng)建時(shí)候的上下文關(guān)系，將這些信息發(fā)布出來(lái)給客戶端用于與伺服對(duì)象建立關(guān)聯(lián)。一個(gè)對(duì)象引用IOR中包含了多個(gè)taggedProfile對(duì)象，每一個(gè)taggedProfile對(duì)象是包含了用來(lái)聯(lián)系遠(yuǎn)程對(duì)象的多種協(xié)議方式。比如，在客戶端既可以通過(guò)RIO-1OP協(xié)議來(lái)與遠(yuǎn)程對(duì)象建立通信聯(lián)系，也可以通過(guò)其他協(xié)議(如II0P)與遠(yuǎn)程對(duì)象建立通信關(guān)系。每一種taggedProfile對(duì)象中包含了一個(gè)ProfileId,如何對(duì)該對(duì)象的編解碼進(jìn)行解析，就依賴該標(biāo)識(shí)。比如客戶端按照ProfileId定義的一種方式將數(shù)據(jù)包進(jìn)行編碼，月艮務(wù)端解碼的過(guò)程就需要通過(guò)該P(yáng)rofileId來(lái)解碼。在實(shí)際應(yīng)用中，很可能一個(gè)服務(wù)器端的某個(gè)對(duì)象的互操作對(duì)象引用(IOR)會(huì)被其它不同CORBA廠商的客戶端所使用。因此，IOR采用IDL結(jié)構(gòu)來(lái)定義的。根據(jù)RCS網(wǎng)絡(luò)節(jié)點(diǎn)間通信的機(jī)制，定義RIO-1OP IOR Profile IDL的結(jié)構(gòu)為 Module IOP{
typedef unsigned long ComponentId;const ProfileId TAG—RIO—IOP = 2;struct TaggedComponent{ ComponenteId tag; sequence<octet> component—data;
}；
Module RIO—IOP {struct Version {octet major;octet minor;
}；
struct RIO—IOPProfileBode—1—2{
Versionriop_version;
stringriop—host;
unsigned shot riop—port; sequence〈octet>object—key;
sequence〈I0P::TaggedComponent> components;
}；
使用RCS通信的對(duì)象，在對(duì)象IOR中提供了基于RI0-10P的聯(lián)系方式。riop_hoSt表示對(duì)象所在連接的目的地址，也就是RapidIO網(wǎng)絡(luò)地址。riop_port表示對(duì)象所在連接的目的端口。ob ject_key用來(lái)表示遠(yuǎn)程地址空間的對(duì)象。實(shí)施例二 CORBA客戶端通過(guò)IOR調(diào)用服務(wù)端服務(wù)
CORBA客戶端調(diào)用服務(wù)端對(duì)象服務(wù)，是基于RI0-10P協(xié)議通過(guò)IOR實(shí)現(xiàn)的。假設(shè)某個(gè)服務(wù)對(duì)象A的IOR提供了多種調(diào)用方式。通過(guò)RapidIO總線，目標(biāo)對(duì)象RapidIO網(wǎng)絡(luò)地址為節(jié)點(diǎn)標(biāo)識(shí)HOSTAjj^nS P0RT1，對(duì)象引用鍵值為0BJECT_KEY。通過(guò)TCP/IP協(xié)議，主機(jī)為HOST B，端口為P0RT2，對(duì)象鍵值為0BJECT_KEY。通過(guò)ATM協(xié)議，主機(jī)為HOSTA_ATM，接入點(diǎn)為SAP1，對(duì)象引用鍵值為OBJECT_KEY。使用RIO-1OP連接服務(wù)端如圖1所示。對(duì)象A 的 IOR 當(dāng)前使用的為RI0-10P: //H0STA:P0RT1/0BJECT_KEY，該對(duì)象中包含了聯(lián)系服務(wù)端上的遠(yuǎn)程對(duì)象A的具體方式。通過(guò)taggedProfile的信息可以知道，該對(duì)象位于節(jié)點(diǎn)標(biāo)識(shí)為H0STA，服務(wù)端口為PORTl的端口上，通過(guò)RIO-1OP協(xié)議與服務(wù)器聯(lián)系，在服務(wù)端使用0BJECT_KEY索引對(duì)象的實(shí)現(xiàn)。IOR中承載的目標(biāo)地址信息是用來(lái)建立或者選擇連接通道用的。服務(wù)端將創(chuàng)建好的服務(wù)對(duì)象通過(guò)IOR的方式發(fā)布出去?？蛻舳丝梢詫?shí)現(xiàn)在目標(biāo)地址不可用的情況下，自動(dòng)嘗試配置好的下一個(gè)聯(lián)系方式?？蛻舳伺c服務(wù)端以IOR形式通過(guò)網(wǎng)絡(luò)連接進(jìn)行數(shù)據(jù)的通信，在ORB中連接的方式，根據(jù)呼叫發(fā)起方的差異，以及連接復(fù)用的方式，將連接劃分以下3種
1)單向連接上多重呼叫(MultiplecallPerConnection)
2)單向連接上的單重呼叫(onecallPerConnection)
3)雙向連接(bidirectionConnection)
在RI0-10P消息機(jī)制中，客戶端通過(guò)請(qǐng)求消息(request)定位到需要訪問(wèn)的對(duì)象,然后使用已經(jīng)配置的連接。服務(wù)端在找到對(duì)應(yīng)的實(shí)現(xiàn)后，通過(guò)應(yīng)答消息(reply)將執(zhí)行結(jié)果按照應(yīng)答消息的包頭以及消息體的格式，在外層加上GIOP協(xié)議頭后傳輸給對(duì)應(yīng)的客戶端。請(qǐng)求消息與應(yīng)答消息通過(guò)請(qǐng)求的標(biāo)識(shí)ID進(jìn)行關(guān)聯(lián)。為了能夠通過(guò)RI0-1O P的方式訪問(wèn)服務(wù)對(duì)象，必須滿足2點(diǎn)前置條件識(shí)別RI0-10P協(xié)議的IOR字符串和注冊(cè)RI0-10P傳輸?shù)絆RB內(nèi)核中。對(duì)于第I點(diǎn)，需要在初始化以及IOR句柄解析的時(shí)候增加RI0-10P對(duì)應(yīng)的部分。對(duì)于第2點(diǎn)，需要新增RI0-10P相關(guān)的協(xié)議支持接口以及關(guān)聯(lián)部分的修改。RI0-10P協(xié)議是GIOP協(xié)議在RCS協(xié)議上的實(shí)現(xiàn)，需要繼承原有GIOP中關(guān)于數(shù)據(jù)傳輸?shù)乃蓄?，使得GIOP可以在RCS協(xié)議棧上運(yùn)行。另外，為了識(shí)別RI0-10P協(xié)議的IOR字符串，需要在RI0-10P設(shè)計(jì)時(shí)增加RI0_IOP對(duì)象，以及對(duì)一些ORB內(nèi)核中原有的對(duì)象進(jìn)行修改，這些修改對(duì)象包括I0R、GI0P_S、Interceptor。有了兩點(diǎn)前置條件后，就可以通過(guò)具有RI0-10P協(xié)議的IOR字符串訪問(wèn)服務(wù)對(duì)象。整個(gè)訪問(wèn)過(guò)程可以從客戶端和服務(wù)端兩個(gè)角度來(lái)看，通過(guò)8個(gè)階段建立到服務(wù)端的聯(lián)系，如圖2所示。8個(gè)階段分別為客戶端ORB初始化階段；客戶端創(chuàng)建對(duì)象引用階段；客戶準(zhǔn)備連接階段；客戶端請(qǐng)求分發(fā)階段；服務(wù)端ORB初始化階段；服務(wù)端對(duì)象適配器OA初始化階段；服務(wù)端任務(wù)調(diào)度階段；服務(wù)端請(qǐng)求分發(fā)階段。在RI0-10P協(xié)議的網(wǎng)絡(luò)中，由于連接都是預(yù)先分配，所以RzTask任務(wù)不可能會(huì)監(jiān)控到新連接產(chǎn)生的事件，每個(gè)RzTask任務(wù)最多只需要監(jiān)控一個(gè)連接句柄。一個(gè)EndPoint固定對(duì)應(yīng)著一個(gè)連接對(duì)象，沒(méi)有需要監(jiān)聽(tīng)的句柄，所以EndPoint中的句柄集合最多包含著一個(gè)連接句柄。在專職workerTask任務(wù)空閑的時(shí)候,監(jiān)控連接的職責(zé)也將由專職workerTask任務(wù)完成,RzTask任務(wù)將會(huì)無(wú)連接句柄可以監(jiān)控。當(dāng)專職任務(wù)進(jìn)行請(qǐng)求處理時(shí)，就會(huì)把連接句柄放入到連接集合中，由RzTask任務(wù)對(duì)連接句柄進(jìn)行監(jiān)控。連接集合不會(huì)發(fā)生變化，一個(gè)RzTask任務(wù)將只監(jiān)控一個(gè)連接句柄上的數(shù)據(jù)到達(dá)情況。實(shí)施例三RIO-1OP對(duì)CORBA基本服務(wù)的支持
RIO-1OP命名服務(wù)是指支持經(jīng)由RIO-1OP協(xié)議的CORBA命名服務(wù)，并且為了保證在分布式嵌入式系統(tǒng)中命名服務(wù)的高可靠性，RIO-1OP命名服務(wù)提供雙命名服務(wù)。RIO-1OP雙命名服務(wù)是指客戶端程序通過(guò)網(wǎng)絡(luò)與主備命名服務(wù)進(jìn)行連接。在默認(rèn)情況下，客戶端程序僅與主命名服務(wù)之間進(jìn)行交互通信，當(dāng)主命名服務(wù)出現(xiàn)故障時(shí)，客戶端可以自動(dòng)向備命名服務(wù)請(qǐng)求，以保障系統(tǒng)的持續(xù)穩(wěn)定運(yùn)行。同時(shí)在主備命名服務(wù)之間需要進(jìn)行名字配置數(shù)據(jù)的同步，以使在主命名服務(wù)故障的情況下，備命名服務(wù)可以對(duì)該服務(wù)進(jìn)行無(wú)縫切換并接管。標(biāo)準(zhǔn)CORBA通信模式中，客戶程序與伺服程序之間的通信是直接的，客戶程序向伺服程序發(fā)出調(diào)用請(qǐng)求，伺服程序進(jìn)行處理并返回結(jié)果，這種處理方式下，兩者之間完全是率禹合在一起的一對(duì)一的關(guān)系。事件服務(wù)則是一種異步通信松耦合的模式，由事件的提供者產(chǎn)生事件而事件的消費(fèi)者接收事件，它們之間不是一對(duì)一的緊耦合的關(guān)系也不需要關(guān)心對(duì)方的當(dāng)前的情況，而是各自連接在事件通道上。事件通道作為2者之間的紐帶，負(fù)責(zé)注冊(cè)提供者和消費(fèi)者，傳遞事件和錯(cuò)誤處理。RIO-1OP事件服務(wù)是指開(kāi)發(fā)的CORBA應(yīng)用程序能夠使用RIO-1OP協(xié)議，作為事件的消費(fèi)者，能夠向事件服務(wù)注冊(cè)自己以及感興趣的事件，在事件產(chǎn)生后，將得到通知；作為事件的提供者，能夠使用事件服務(wù)提供的推送接口，將產(chǎn)生的事件推送給注冊(cè)的消費(fèi)者應(yīng)用程序。RIO-1OP事件服務(wù)的前置條件是可以通過(guò)RapidIO總線傳輸符合CORBA的GI0P1. 2規(guī)范的協(xié)議數(shù)據(jù)包，后置條件是作為消費(fèi)者與提供者的應(yīng)用程序能夠通過(guò)事件服務(wù)通道建立關(guān)聯(lián)。

CORBA除了靜態(tài)調(diào)用外，還支持2種用于動(dòng)態(tài)調(diào)用的界面動(dòng)態(tài)調(diào)用界面(DII，dynamic invocation interface)和動(dòng)態(tài)框架界面(DSI, dynamic skeleton interface),分別用于服務(wù)端和客戶端的動(dòng)態(tài)調(diào)用。限于RapidIO的應(yīng)用場(chǎng)景的要求和制約，在基于RapidIO的RIO-RIO協(xié)議的CORBA應(yīng)用中對(duì)動(dòng)態(tài)特性沒(méi)有需求，所以對(duì)動(dòng)態(tài)屬性進(jìn)行剝離，以更好的適應(yīng)嵌入式環(huán)境并節(jié)省程序的空間消耗。上面已結(jié)合附圖對(duì)發(fā)明的具體實(shí)施方式
進(jìn)行了示例性的描述，顯然本發(fā)明不限于此，在本發(fā)明范圍內(nèi)進(jìn)行的各種改型均沒(méi)有超出本發(fā)明的保護(hù)范圍。
權(quán)利要求
1.一種GIOP到RapidIO的新協(xié)議，其特征在于，包括硬件層、RapidIO總線層、RCS協(xié)議棧層、RIO-1OP協(xié)議層、GIOP層、應(yīng)用層；在硬件層中采用RapidIO接口接入板卡上RapidIO交換芯片；在所述RapidIO總線層中,所述RapidIO交換芯片的物理鏈路再接入交換網(wǎng)絡(luò)中，網(wǎng)絡(luò)中的交換模塊負(fù)責(zé)維護(hù)點(diǎn)對(duì)點(diǎn)通信的路由信息；所述RCS協(xié)議棧層運(yùn)行在RapidIO的網(wǎng)絡(luò)中的各個(gè)非交換節(jié)點(diǎn)上，RCS協(xié)議棧為對(duì)RapidIO的第一次封裝，通過(guò)RCS協(xié)議棧實(shí)現(xiàn)節(jié)點(diǎn)間的快速通信與數(shù)據(jù)交換；所述RIO-1OP協(xié)議層由對(duì)RapidIO進(jìn)行第二次封裝，即把RCS封裝成RIO-1OP協(xié)議。
2.根據(jù)權(quán)利要求1所述的GIOP到RapidIO的新協(xié)議，其特征在于，還包括ORB傳輸層服務(wù)端，所述ORB傳輸層服務(wù)端包含傳輸模塊初始化組件、對(duì)同一目標(biāo)地址空間的連接分組組件、遵循GIOP協(xié)議的GIOP消息機(jī)制組件、實(shí)現(xiàn)在RapidIO總線上的GIOP的映射RIO-1OP組件、線程策略組件、協(xié)議包的封裝組件CDR和傳輸規(guī)則組件。
3.根據(jù)權(quán)利要求1所述的GIOP到RapidIO的新協(xié)議，其特征在于，還包括ORB傳輸層客戶端，所述ORB傳輸層客戶端包括傳輸模塊初始化組件，連接分組組件，GIOP消息機(jī)制組件以及RCS協(xié)議的GIOP映射RIO-1OP組件。
4.根據(jù)權(quán)利要求3所述的GIOP到RapidIO的RIO-1OP協(xié)議，其特征在于，在ORB傳輸層客戶端呼叫服務(wù)對(duì)象的過(guò)程中，ORB傳輸層客戶端對(duì)象將通過(guò)CDR對(duì)象將請(qǐng)求封裝成GIOP協(xié)議格式，發(fā)送到ORB傳輸層服務(wù)端。
5.根據(jù)權(quán)利要求1或3所述的GIOP到RapidIO的新協(xié)議，其特征在于，傳輸層提供給的外部接口包括連接接口 connect、監(jiān)控連接事件接口 acceptAndMonitor、監(jiān)控連接接口 monitor、通知可讀接口 notifyReadable、發(fā)送請(qǐng)求接口 sendRequest、接收反饋接口 receiveReply、接收請(qǐng)求接口 receiveReques、發(fā)送反饋接口 sendReply、數(shù)據(jù)發(fā)送接口send、數(shù)據(jù)接收接口 recv。
6.根據(jù)權(quán)利要求1所述的GIOP到RapidIO的新協(xié)議，其特征在于，所述RCS協(xié)議棧層通信的對(duì)象IOR采用IDL結(jié)構(gòu)來(lái)定義，一個(gè)對(duì)象引用IOR中包含了多個(gè)taggedProfile對(duì)象，每一個(gè)taggedProfile對(duì)象是包含了用來(lái)聯(lián)系遠(yuǎn)程對(duì)象的多種協(xié)議方式；每一種taggedProfile對(duì)象中包含了一個(gè)ProfileId,如何對(duì)該對(duì)象的編解碼進(jìn)行解析,就依賴該標(biāo)識(shí)。
7.根據(jù)權(quán)利要求6所述的GIOP到RapidIO的新協(xié)議，其特征在于，ORB傳輸層客戶端通過(guò)IOR調(diào)用服務(wù)端對(duì)象服務(wù)，客戶端與服務(wù)端以IOR形式通過(guò)網(wǎng)絡(luò)連接進(jìn)行數(shù)據(jù)的通信，所述網(wǎng)絡(luò)連接方式有三種分別為單向連接上多重呼叫MultiplecallPer Connection、單向連接上的單重呼叫 onecallPer Connection、雙向連接 bidirectionConnection。
全文摘要
本發(fā)明公開(kāi)了一種GIOP到RapidIO的RIO-IOP協(xié)議，包括硬件層、RapidIO總線層、RCS協(xié)議棧層、RIO-IOP協(xié)議層、GIOP層、應(yīng)用層；所述RCS協(xié)議棧層運(yùn)行在RapidIO的網(wǎng)絡(luò)中的各個(gè)非交換節(jié)點(diǎn)上，RCS協(xié)議棧為對(duì)RapidIO的第一次封裝，所述RIO-IOP協(xié)議層為對(duì)RapidIO進(jìn)行的第二次封裝，即把RCS封裝成RIO-IOP協(xié)議。本發(fā)明將基于高速總線RapidIO的協(xié)議棧RCS無(wú)縫銜接到CORBA的傳輸層，把抽象協(xié)議GIOP映射為具體的RapidIO，從理論和實(shí)踐上提出并實(shí)現(xiàn)了全新的RIO-IOP協(xié)議，完成經(jīng)由RIO-IOP協(xié)議的CORBA基本調(diào)用。
文檔編號(hào)H04L29/06GK103067412SQ201310031570
公開(kāi)日2013年4月24日 申請(qǐng)日期2013年1月28日 優(yōu)先權(quán)日2013年1月28日
發(fā)明者陳文宇, 曾茹, 劉貴松, 歐睿杰, 符明晟, 袁野, 朱建 申請(qǐng)人:電子科技大學(xué)