JP2007526544A5 - - Google Patents
Download PDFInfo
- Publication number
- JP2007526544A5 JP2007526544A5 JP2006517601A JP2006517601A JP2007526544A5 JP 2007526544 A5 JP2007526544 A5 JP 2007526544A5 JP 2006517601 A JP2006517601 A JP 2006517601A JP 2006517601 A JP2006517601 A JP 2006517601A JP 2007526544 A5 JP2007526544 A5 JP 2007526544A5
- Authority
- JP
- Japan
- Prior art keywords
- ipc
- server
- client
- network
- component
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000000737 periodic Effects 0.000 claims description 2
- 230000004044 response Effects 0.000 description 9
- 230000032258 transport Effects 0.000 description 9
- 210000004544 DC2 Anatomy 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 238000005538 encapsulation Methods 0.000 description 3
- 238000000034 method Methods 0.000 description 3
- 230000000875 corresponding Effects 0.000 description 2
- 235000010384 tocopherol Nutrition 0.000 description 2
- 235000019731 tricalcium phosphate Nutrition 0.000 description 2
- CRCPLBFLOSEABN-VBSNWNEZSA-N N-[(2S)-1-[[(2S)-1-amino-1-oxopropan-2-yl]amino]-3-naphthalen-2-yl-1-oxopropan-2-yl]-N'-hydroxy-2-(2-methylpropyl)butanediamide Chemical compound C1=CC=CC2=CC(C[C@H](NC(=O)C(CC(=O)NO)CC(C)C)C(=O)N[C@@H](C)C(N)=O)=CC=C21 CRCPLBFLOSEABN-VBSNWNEZSA-N 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000006011 modification reaction Methods 0.000 description 1
- 229920003258 poly(methylsilmethylene) Polymers 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001702 transmitter Effects 0.000 description 1
Description
本発明は一般的に電子分野に関し、特には、プロセッサ間通信(IPC)のプロトコル/ネットワークに関する。
ほとんどの電子システムは、システムを形成するハードウェアやソフトウェア等の、多くのネットワーク要素(部品)からなる。ほとんどのシステムにおいて、異なるネットワーク要素それ自身の間と同時に、ネットワーク要素を形成する異なる部品との間の通信に対応する層を有する。この層は一般的にプロセッサ間通信(IPC)と呼ばれる。
近年、プロセッサ間通信を行う幾つかのプロトコルが導入されている。IPCの一例はPCIAGPコントローラ(PAC)であって、Host‐to‐PCIブリッジ、DRAMコントローラ、およびデータ経路とAccelerated Graphics Port(AGP)インターフェイスを集積する。IPCの別例はOMAP(登録商標)プラットフォームである。これらのプラットフォームではいずれも、すべてのサポートがハードウェアレベル以上の場合は多くの設計自由度を得られず、低レベル部品やチャネルレベル(物理層)では設計自由度はほとんどない。
例えば、PACプラットフォームは閉構造で、オペレーティング・システムのTAPI層に埋め込まれており、IPCコードは開発者にはアクセスできない。従って、これらのプラットフォームは部品システムには拡張しないので、IPC源の動的割り当てをできないだけでなく、IPC源の動的割り当て、ハードウェア・サポート機能、マルチノード・ルーチングをできない。
リアルタイム処理アプリケーション等のアプリケーションにおける1つの問題は、異なるプロセッサ上のサービスの発見及びIPC要求の迅速な処理に対する要件である。これらの状況において、良好なサポートを保証する1つの側面は、無線通信装置における移動体アプリケーション(MA)等の異なるアプリケーションの仕事を埋め合わせ、対象のMAへのデータの送付に先立ち共同処理をサポートすることである。この共同処理サポートには、通常、コプロセッサにIPCデータを輸送し、そして、そのデータを対象のMAに再度ルーチングし得るスマート・ハードウェア・ポートが必要である。良好なサポートを保証するもう1つの側面は、専用リンク(ポート)を用いて、異なるMA上のソフトウェア・コンポーネントに特定のソフトウェアサービスを搬送することによる。今日、これらの方法は、動的でもなく、実行時設定可能でもない。従って、以上のことから、従来技術におけるこれら幾つかの欠点に対する解決策を提供し得るIPCプロトコルに対するニーズが、当分野に存在する。
本発明の特徴は、詳細に添付の請求項に記載されている。本発明は、添付図面を併用して行われる以下の説明を参照すると最も良く理解し得る。図面の幾つかの図では、同様な参照数字は、同様な要素を表す。
本明細書は、本発明の特徴を定める請求項で終わるが、本発明は、図面の図と共に以下の説明を考察すると、理解が深まると思われる。
IPCは、システムにおいて動作する異なるプロセッサが互いに通信を行うために必要なサポートを提供する。例えば、アプリケーションプロセッサ(AP)及びベースバンドプロセッサ(BP)が含まれる無線通信装置に用いる二重プロセッサ(又は多重プロセッサ)無線アーキテクチャにおいて、IPCは、プロセッサが互いに効率的に通信を行うために必要なサポートを提供する。IPCは、AP又はBPの設計に何らかの制約を課すことなく、このサポートを提供する。
IPCは、システムにおいて動作する異なるプロセッサが互いに通信を行うために必要なサポートを提供する。例えば、アプリケーションプロセッサ(AP)及びベースバンドプロセッサ(BP)が含まれる無線通信装置に用いる二重プロセッサ(又は多重プロセッサ)無線アーキテクチャにおいて、IPCは、プロセッサが互いに効率的に通信を行うために必要なサポートを提供する。IPCは、AP又はBPの設計に何らかの制約を課すことなく、このサポートを提供する。
IPCをそのプロセッサ間通信スタックとして採用するあらゆるプロセッサは、IPCにより、その2つが、共通のオペレーティング・システム及びメモリを共有する同じプロセッサコア上で実際に動作しているかの如く共存し動作し得る。通信装置において複数のプロセッサを用いることが標準になりつつある中で、IPCは、異なるプロセッサ間において信頼性の高い通信を提供する。
IPCハードウェアは、異なるプロセッサをIPCネットワークに接続する物理接続を提供する。本発明の一実施形態において、データパケットは、好適には、異なるホスト間において非同期的に輸送される。IPCネットワークに接続されるプロセッサは、それらの物理及び論理アドレスが、静的に又は動的に割り当てられる(例えば、IPCアドレス)。また、データパケットは、本発明の一実施形態におけるIPCネットワーク内で任意の方向に流れ得ることから、パケットは、それらが到達しようとしているプロセッサの宛先アドレスを搬送する必要がある。また、好適には、パケットは、従来の周期的冗長検査(CRC)手法を用いて、エラーが無いかチェックされる。本発明のIPCネットワークのネットワークアクティビティは、伝送制御プロトコル/インターネットプロトコル(TCP/IP)ネットワーク等のIPトランスポート層を用いるインターネット・ネットワーク上に存在するものとある程度類似し得るが、本発明のIPCは、TCP/IPネットワークのようにゲートウェイにより小規模なネットワークに分割されない。
次に、図1において、本発明の実施形態に基づくIPCネットワーク100を示す。IPCネットワーク100には、複数のIPCクライアント102−106と、幾つかの実例として、共有メモリ110、ユニバーサル非同期受信機/送信機(UART)112及びユニバーサル・シリアル・バス(USB)114等の異なるIPC物理リンクを用いて、IPCクライアント102−106に接続されたIPCサーバ108とが含まれる。本発明のIPCにより、IPCクライアント102−106は、現IPCサーバ108と折衝して役割を交替し得ることに留意されたい。IPCクライアント102−106が、IPCサーバになるように折衝して新しいIPCサーバになる場合、残りの全てのIPCクライアントは、IPCサーバの変更があった場合、サーバのIPCアドレスを変更するように指示される。
図2において、本発明の実施形態に基づくIPCサーバ108(又はIPCクライアント102−108)のIPCスタック200を示す。IPCスタック200は、オペレーティングシステム(OS)の下で一体化されるように、また、コンポーネントトラフィックのプロセッサ間通信ニーズへのサポートを提供するように設計されている。IPCスタックは、次の3つの主な層から構成される。即ち、
(1)IPCプレゼンテーション・マネージャ(202):この層は、異なるシステムコンポーネント(例えば、ソフトウェア・スレッド)間においてあるデータタイプを他の異なるデータタイプに変換するために用いられる。
(1)IPCプレゼンテーション・マネージャ(202):この層は、異なるシステムコンポーネント(例えば、ソフトウェア・スレッド)間においてあるデータタイプを他の異なるデータタイプに変換するために用いられる。
(2)IPCセッション・マネージャ(204):この層は、IPCスタックと全システムコンポーネントとの間における全着信/発信IPCトラフィック用の中央収納場所である。IPCセッション・マネージャ204は、幾つかの機能を有する。即ち、IPCコンポーネントを参加させるためのコンポーネントIDの割当て;IPCデータをカプセル化する必要があるかどうかの判断;IPCデータのルーチング、IPCトラフィックの終止;IPCプロセッサ用のプレースホルダ;IPCアドレスの提供、IPCクライアントの割当及び認証等を有する。
IPCトランスポート層(208):IPCセッション・マネージャ(層)204内に配置される。IPCトランスポート層208は、異なるプロセッサ間において、IPCデータを輸送する目的のために、極めて基本的な周期的冗長検査を行う。更に、IPCトランスポート層208は、IPCメッセージを、IPCネットワーク100上のそれらの最終宛先にルーチングする役割を担う。トランスポート層のルーチング機能は、IPCサーバ上でのみ使用可能である。
IPCルータブロック(210):宛先コンポーネント(図示せず)にIPCデータを輸送する。着信IPCメッセージは、とりわけ、発生元コンポーネントIDや、音声及びモデム等のIPCメッセージOPコードを搬送する。本発明の実施形態によれば、固有のOPコードが、IPCネットワークに接続された音声及びモデム等の各コンポーネント/ソフトウェア・スレッドに割り当てられることに留意されたい(例えば、図5の502参照)。IPCセッション・マネージャ204は、ルータブロック210に依拠して、IPCデータを正しいコンポーネント(1つ又は複数)に送る。
(3)デバイス・インターフェイス層(206):IPC物理対論理IPCチャネルを管理する役割を果たす。その主な機能は、スタックIPCがハードウェアに依存しなくなるように、IPCハードウェアを完全に抽象化することである。デバイス・インターフェイス層206は、直下のIPCリンクの物理帯域幅を管理して全IPC論理チャネルをサポートする。着信経路において、デバイス・インターフェイス層206は、異なる物理チャネル110−114からデータを受信して、そのデータを残りのIPCスタックに渡す。発信経路上では、デバイス・インターフェイス層206は、IPC論理チャネルのデータローディングを、データを適切な物理チャネル上に送ることによって管理する。また、デバイス・インターフェイス層206は、同じIPCチャネルに属するIPCパケットの連結を行い、その後、それらをIPCハードウェアに送る。チャネル要件は、IPCセッション・マネージャ204とIPCデバイス・インターフェイス層206との間で事前に折衝される。デバイス・インターフェイス層206は、ハードウェアポートを備え、これは、IPCクライアント102−106とのデバイス・インターフェイスを提供する。
図3において、IPCコンポーネントID割当てルーチンを示す。IPC通信に加わりたい新しいコンポーネントは、いずれも、(例えば、セッション・マネージャ204等の)そのIPCセッション・マネージャから、ステップ302において、IPC識別番号(ID)をまず要求する。すると、ローカル・セッション・マネージャ(例えば、コンポーネントが接続されているクライアントに配置されたセッション・マネージャ)は、新しいIPCコンポーネントのIPCサーバ・セッション・マネージャを呼出し、ステップ304において、コンポーネントID割当てを行う。本発明の実施形態によれば、コンポーネントIDは、動的であり、セッション・マネージャによって割り当てられる。主なIPCサーバ位置は、主AP上となる可能性が最も高い。各IPCノードは、好適には、固有のIPCノードIDを有し、セッション・マネージャは、そのデータベース中に、各関係IPCノード用の以下の情報を保持する。即ち、:
・IPCノードタイプ:例えば、特定のBP又はAP、無線ローカルエリアネットワーク(WLAN)AP等。
・IPCノードタイプ:例えば、特定のBP又はAP、無線ローカルエリアネットワーク(WLAN)AP等。
・IPCアドレス:IPCノードのIPCアドレス。
・データタイプ:IPCノードのデータタイプ。
・OPコードリスト:これは、コンポーネントが登録した全IPCメッセージのOPコードのリストである。
・データタイプ:IPCノードのデータタイプ。
・OPコードリスト:これは、コンポーネントが登録した全IPCメッセージのOPコードのリストである。
・コンポーネントID:全コンポーネントIDのリスト。
次に、図4において、全ての主IPCテーブルと共にIPCスタックを示す。動的ルーチングテーブル402には、ノードタイプ、IPCアドレス/ポート#情報、データタイプ及び登録リストが含まれる。コンポーネントルーチングテーブル404には、OPコード情報と各特定のOPコードを登録した全てのコンポーネントとをリンクする情報が含まれる。最後に、チャネル資源テーブル406には、物理チャネルIDのリストとの各チャネルIDのリンクが含まれる。
次に、図4において、全ての主IPCテーブルと共にIPCスタックを示す。動的ルーチングテーブル402には、ノードタイプ、IPCアドレス/ポート#情報、データタイプ及び登録リストが含まれる。コンポーネントルーチングテーブル404には、OPコード情報と各特定のOPコードを登録した全てのコンポーネントとをリンクする情報が含まれる。最後に、チャネル資源テーブル406には、物理チャネルIDのリストとの各チャネルIDのリンクが含まれる。
図5において、本発明の実施形態に基づくIPCスタックが、ソフトウェア・スレッド等(例えば、音声等)のコンポーネントにIPCチャネルを如何に提供するかのブロック図を示す。コンポーネント502は、まず、ステップ504において、IPCチャネルを要求する。図5に示すセッション・マネージャは、定義されたAPIを用いて、ステップ506において、コンポーネントの要求をデバイス層と折衝する。そして、デバイス層(デバイスインターフェイス)は、データチャネル508等のハードウェア資源を要求する。要求に応答して、図5に示すセッション・マネージャは、ステップ510において、要求側にIPCチャネルを与える。次に、コンポーネント502は、割り当てられたチャネル508上でそのデータを送る。そして、デバイス層は、IPCネットワークにデータを転送する。論理から物理チャネルIDへのマッピングは、IPCデバイス・インターフェイスの機能である。
次に、図6において、IPCクライアント初期化における第1ステップは、IPCクライアント602とIPCサーバ604との間において、登録要求(ステップ606)を送信することである。そして、IPCサーバ604は、ステップ608において、IPCクライアント602による要求を認証する。この後、IPCアドレスが、IPCクライアントに送信され、ステップ610において登録が完了する。IPCクライアントのセッション・マネージャは、ステップ612において、IPCクライアント602の動的ルーチングテーブルのコピーをIPCサーバに送る。
IPCクライアント初期化プロセス時に行われる詳細なステップを図7に示す。クライアント・セッション・マネージャ(セッション(クライアント)としてテーブルに示す)は、ステップ702において、IPCサーバのセッション・マネージャ(セッション(サーバ)としてテーブルに示す)に設定要求を送る。ステップ704において、認証は、IPCサーバのセッション・マネージャによって要求される。そして、IPCクライアントとIPCサーバとの間の認証は、ステップ706で実行される。
設定要求のパラメータには、ノードタイプ及びデータタイプが含まれる。ステップ702において、設定要求に応答して、セッションサーバは、要求側にIPCアドレスを割り当てる。また、もしなければ、要求側用の動的ルーチングテーブルを設定する。そして、ステップ708において、要求側に設定指示を送る。設定指示パラメータには、サーバのIPCアドレス及びクライアントの新規に割り当てられたIPCアドレスが含まれる。
設定指示の受信に応答して、セッションクライアントに取り付けられたコンポーネントは、クライアントのセッション・マネージャから制御/データを要求し得る。そして、セッションクライアントは、ステップ710において、セッションサーバに設定指示確認メッセージを送る。“設定指示確認”メッセージは、パラメータを有さない。ステップ710における設定指示確認メッセージの受信時、セッションサーバは、新規に設定されたセッションクライアントへのIPCストリームを開始し得る。そして、セッションサーバは、ステップ712及び714において、セッションクライアントに設定更新メッセージを送る。これによって、図7に示す両セッションクライアントは、それらのそれぞれの動的ルーチングテーブル(図示せず)を更新し、ステップ716及び718において、セッションサーバに設定更新確認メッセージを送る。設定更新確認メッセージを受信すると、セッションサーバは、参加した全IPCが、更新されたことを確認する。
パケットは、IPCセッション・マネージャによって受信される時、送信元コンポーネントID、宛先ID、チャネルID及びBP又はAPのタイプが含まれるデータの形態でやって来る。IPCセッション・マネージャは、宛先IDが挿入されていない場合、宛先コンポーネントのIDである宛先IDをパケットに挿入する。また、IPCセッション・マネージャは、IPCアドレスをパケットに挿入する。受信されたメッセージOPコードに基づき宛先コンポーネントIDを発見するのは、IPCセッション・マネージャである。宛先IDは、ルックアップテーブルに基づく。このルックアップテーブルは、コンポーネントが新しいIPCメッセージのOPコードに登録する(例えば、音声コンポーネントが、IPCセッション・マネージャに要求を送信することによって音声メッセージに登録する)度に、動的に更新される。
図8において、コンポーネントと本発明の実施形態に基づくそのIPCセッション・マネージャとの間における一般的な宛先ID発見シーケンス時の一連のイベントを示す。ステップ802において、コンポーネントは、その送信元ID(宛先IDはない)、宛先BP又はAPのタイプ、及びヘッダ及びデータが含まれるIPCデータを送る。ステップ804において、IPCセッション・マネージャは、対応する動的ルーチングテーブルを検索し、正しい宛先アドレスを見つけるために、IPCデータヘッダOPコード、及び宛先BP又はAPのタイプを見る。ステップ806において、IPCセッション・マネージャは、コンポーネントのIPCアドレスを挿入し、それをデバイス層に送る。
図9において、IPCコンポーネント初期化時に行われる代表的なステップを示す。BPが、図9に示すIPCサーバによって一旦設定されると、コンポーネント902等のコンポーネントは、異なるサービスに加入し得る。コンポーネントは、ステップ904において、音声や映像等の機能にコンポーネント自体を登録する。そして、コンポーネント登録情報は、IPCセッション・マネージャに送られ、(IDがまだ割り当てられていない場合)コンポーネントIDの生成が行われ、また、特定のIPCアドレス用動的ルーチングテーブルの生成又は更新が行われる(ステップ906)。ステップ908において、セッション・マネージャは、ステップ906からの情報でIPCサーバを更新する。ステップ908において、更新された動的ルーチングテーブルを受信すると、ステップ912において、更新の確認が、IPCサーバによってIPCクライアントに送信される。サーバが、一旦呼び出されると、新しい動的ルーチングテーブルの更新内容は、ステップ910において、関係する全プロセッサに一斉送信される。
図10において、同じコンポーネント初期化プロセスを、コンポーネント(クライアント)1002と、クライアント・セッション・マネージャ1004としても知られているセッション(クライアント)と、サーバ・セッション・マネージャ1006としても知られているセッション(サーバ)との間に示す。ステップ1008におけるコンポーネント設定要求は、コンポーネント(クライアント)1002によって送信される。要求に応答して、クライアント・セッション・マネージャ1004は、デバイス層(図示せず)と論理チャネルを取り決める。また、クライアント・セッション・マネージャ1004は、コンポーネントIDを割当て、その動的ルーチングテーブル(図示せず)に新しいOPコードリストを付加する。ステップ1010において、クライアント・セッション・マネージャ1004は、パラメータとして、コンポーネントID及びチャネルIDが含まれる設定応答を送る。設定応答に応じて、コンポーネント(クライアント)1002は、そのID及びチャネルIDをクライアントのセッション・マネージャ1004から受信する。
一旦クライアント・セッション・マネージャ1004が、ステップ1008における設定要求に対して、ステップ1010で返信すると、クライアント・セッション・マネージャ1004は、ステップ1012において、セッションサーバ(サーバ・セッション・マネージャ)1006に設定更新要求を送る。設定更新要求のパラメータは、動的ルーチングテーブル(図示せず)において行われた何らかの新しい変更である。サーバのセッション・マネージャ1006は、そのIPCアドレス用の動的ルーチングテーブルを更新する。そして、ステップ1016において、サーバのセッション・マネージャ1006は、全てのIPCクライアント(図示せず)に設定更新内容を送り、その間、ステップ1014において、クライアントのセッション・マネージャ1004に設定更新指示を送る。サーバのセッション・マネージャ1006は、サーバが、送られた変更でそのルーチングテーブルを更新したことを確認する。
パラメータ(1つ又は複数)として動的ルーチングテーブルを含むステップ1016の設定更新メッセージにおいて、セッションサーバ1006は、動的ルーチングテーブルを更新し、ステップ1018において、設定更新確認メッセージを送る。そして、サーバは、参加した全IPCが更新されたことを確認する。
IPCセッション・マネージャは、着信及び発信IPCパケットのルーチング経路を決定する。発信パケットのルートは、コンポーネントのIPCアドレスによって決定される。宛先アドレスが、ローカルプロセッサの宛先アドレスであると分かった場合、オペレーティングシステム(OS)へのIPCのマッピングは、セッション・マネージャ内で実行される。宛先アドレスが、ローカルIPCクライアント用であると分かった場合、パケットは、IPCスタックに送られ、更に処理(例えば、カプセル化)される。宛先コンポーネントが、IPCパケットを送信するコンポーネントとして、同じプロセッサ上に配置されている場合、カプセル化は不要であり、パケットは、通常のOSメッセージ呼出し(例えば、マイクロソフト・メッセージ・キュー等)を介して渡されることに留意されたい。このように、コンポーネントは、それらのメッセージ入力方式の変更について心配する必要はない。必要なことは、それらのメッセージのポスティング方法を、むしろOS特有の方法からIPC呼出しに変更することだけである。
着信パケットの場合、メッセージの宛先アドレスが、IPCサーバのものと等しくない場合、着信パケットは、妥当なIPCクライアントにルーチングされる。着信パケットのルーチングは、IPCサーバのセッション・マネージャによって処理される。そうでない場合、メッセージは、コンポーネント宛先IDが、有効なコンポーネントIDに又は0XFFに設定されているかどうかに応じて、正しいコンポーネント又は複数のコンポーネントに転送される。
IPCルータブロック(例えば、図2におけるIPCルータブロック210参照)は、宛先コンポーネントにIPCデータを輸送する。着信IPCメッセージは、とりわけ、発生元コンポーネントID、及び音声やモデム用等のIPCメッセージOPコードを搬送する。IPCセッション・マネージャは、そのコンポーネントルーチングテーブルに依拠して、正しいコンポーネント(1つ又は複数)にIPCデータを送る。動的ルーチングテーブル及びコンポーネントルーチングテーブルは、双方共、IPCサーバ/クライアントによって更新される。
起動時、各コンポーネントは、そのセッション・マネージャにそれ自体を登録して、IPCコンポーネントIDを取得しなければならない。更にまた、各コンポーネントは、音声やモデム等の着信IPCメッセージに登録しなければならない。この情報は、IPCセッション・マネージャによって用いられるために、コンポーネントルーチングテーブルに記憶される。
図11に示すように、コンポーネント(例えば、ソフトウェア・スレッド)1102が、ステップ1104において、そのデータ要求をIPCセッション・マネージャに送る場合、宛先IPCノード(例えば、BP)についてチェックが行われる。IPCノードが、IPCメッセージOPコードをサポートしない場合、エラー応答が、コンポーネント1102に返される。エラー応答に加えて、IPCセッション・マネージャは、その特定のOPコードを受信し得る全IPCノードの更新内容を返す。メッセージをIPCノード(1つ又は複数)のどれに転送するか判断するのは、コンポーネント次第である。IPCセッション・マネージャ1106は、引き続きIPCヘッダ情報によるデータのカプセル化を行い、その後、そのデータは、セッション・マネージャが、宛先コンポーネントは、ローカルプロセッサではなく、IPCネットワークに配置されていると判断した場合、IPCネットワーク上で送られる。
図12において、本発明の実施形態に基づくIPCデータヘッダ1202を示す。このヘッダには、送信元及び宛先IPCアドレス、送信元ポート、IPCルータによって提供された宛先ポート、IPCトランスポートによって提供された長さ及びチェックサム情報、並びにセッション・マネージャによって提供された送信元IPCコンポーネント及び宛先IPCコンポーネントが含まれる。メッセージOPコード、メッセージ長及びIPCデータは、コンポーネント1204によって提供される。
本発明の実施形態に基づく代表的なIPCデータ要求を図13に示す。ステップ1302において、コンポーネントは、更新要求を送る。好適には、コンポーネント更新パラメータには、ノードタイプ及びOPコードが含まれる。コンポーネントは、その宛先OPコードをサポートするノードタイプを検索する。ノードタイプが0xFFに等しい場合、セッション・マネージャ(図13において、”セッション”として示す)は、引き続き、全ての参加したIPC用の全ノードテーブルにコンポーネント情報を送信する。OPコードフィールドが、0xFFに等しい場合、図13に示すセッション・マネージャは、引き続き、規定されたノードタイプに属するOPコードリストをコンポーネントに送る。他方、OPコードが特定の値を有する場合、セッション・マネージャは、引き続き、ノードタイプが、その特定のOPコードをサポートする又はサポートしないかどうかに対応する真の又は偽の値をコンポーネントに送る。
ステップ1304において、コンポーネント更新指示は、コンポーネントに送られる。ノードタイプが0xFFに等しい場合、ノードテーブルが、コンポーネントに返される。OPコードフィールドが0xFFに等しい場合、OPコードのリストは、コンポーネントに返される。しかしながら、OPコードが特定の値である場合、真の又は偽のメッセージが返される。ステップ1306において、コンポーネントデータ要求が行われる。コンポーネントデータ要求用のパラメータには、ノードタイプ、IPCメッセージOPコード、IPCメッセージデータ、チャネルID及びコンポーネントIDが含まれる。コンポーネントデータ要求において、セッション・マネージャは、ノードタイプをチェックし、OPコードがサポートされるかどうか判断する。ノードタイプがOPコードをサポートしない場合、コンポーネント更新指示は、ステップ1308において送られる。しかしながら、ノードタイプがOPコードをサポートする場合、データ要求が、ステップ1310においてデバイス層に送られる。データ要求パラメータには、IPCメッセージ、チャネルID及びIPCヘッダが含まれる。
デバイス層は、チャネルIDに基づき、データ要求メッセージを送るようにスケジュール設定する。デバイス層は、ポート#ヘッダ情報に基づき、IPCハードウェアを選択する。一旦データが投入されると、データ確認メッセージが、1312においてセッション・マネージャに送られる。ステップ1314において、セッション・マネージャは、引き続き、コンポーネントデータ確認メッセージをコンポーネントに送る。コンポーネントは、確認を待ち、その後、更に、IPCメッセージを送信し得る。一旦データ確認が受信されると、コンポーネントは、引き続き、次のIPCメッセージを送信し得る。
ステップ1316において、デバイス層は、IPCメッセージデータ及びIPCヘッダが含まれるデータ指示メッセージを送る。セッション・マネージャは、メッセージの宛先IPCヘッダをチェックし、ローカルIPCアドレスと異なる場合、セッション・マネージャは、正しいIPCノードにメッセージを送る(ルーチングする)。ステップ1310において、セッション・マネージャは、予約チャネルIDと共にデバイス層にデータ要求を送る。セッション・マネージャは、宛先コンポーネントのIDである宛先をチェックし、それが0xFFに等しい場合、そのOPコードに登録された全コンポーネントにメッセージをルーチングする。ステップ1318において、セッション・マネージャは、コンポーネントデータ指示メッセージを送り、コンポーネントは、IPCデータを受信する。
IPCスタックは、全ての関係するIPCノード間での通信のために予約制御チャネルを用いる。起動時、IPCサーバのセッション・マネージャは、このリンクを用いて、IPCクライアントに又はその逆にメッセージを一斉送信する。通常動作時、この制御チャネルは、全てのAPとBP間において制御情報を搬送するために用いられる。
図14において、IPCスタック(IPCスタック及びIPCスタックサーバとして示す)とIPCハードウェアとの間に配置された制御チャネル1402−1406を示す。また、制御チャネル情報1408は、異なるIPCハードウェア間でデータを送信する時、データパケット1410と共に送信される。IPCクライアントは、初期的には、IPC制御チャネル上でその設定要求を一斉送信する。IPCスタックサーバは、一斉送信を受信し、そのクライアント用のIPCアドレスで応答する。このIPCアドレスは、その特定のプロセッサ(AP又はBP)用の動的ルーチングテーブルに対応付けられる。
IPCアプリケーション・プログラム・インターフェイス(API)
以下に、本発明のIPCプロトコル用APIの幾つかを列記する。
1)IPCセッション・マネージャからコンポーネントインターフェイスへ
CreateComponentInst()
IPCセッション・マネージャにコンポーネントデータベースを生成する。コンポーネントデータタイプ(ビッグ・エンディアン対リトル・エンディアン)等の情報及びメッセージOPコードの登録が、IPCアドレスに属する動的データルーチングテーブルにおいて用いられる。
以下に、本発明のIPCプロトコル用APIの幾つかを列記する。
1)IPCセッション・マネージャからコンポーネントインターフェイスへ
CreateComponentInst()
IPCセッション・マネージャにコンポーネントデータベースを生成する。コンポーネントデータタイプ(ビッグ・エンディアン対リトル・エンディアン)等の情報及びメッセージOPコードの登録が、IPCアドレスに属する動的データルーチングテーブルにおいて用いられる。
OpenChannelKeep()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。チャネルは、CloseChannel()が発行されるまで予約される。コンポーネントは、IPCセッション・マネージャにQoS要求を送る。コンポーネントIDがまだ割り当てられていない場合、IPCチャネルは、それを割り当てる(例えば、ChannelGrant())。
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。チャネルは、CloseChannel()が発行されるまで予約される。コンポーネントは、IPCセッション・マネージャにQoS要求を送る。コンポーネントIDがまだ割り当てられていない場合、IPCチャネルは、それを割り当てる(例えば、ChannelGrant())。
OpenChannel()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。パラメータは、OpenChannelKeep()基本要素に用いられるものと同じである。
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。パラメータは、OpenChannelKeep()基本要素に用いられるものと同じである。
OpenChannelWThru()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。これは、このチャネル上では、その隠蔽を止めることを意味するチャネル経由の書き込み要求である(例えば、非UDP_AT命令)。
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。これは、このチャネル上では、その隠蔽を止めることを意味するチャネル経由の書き込み要求である(例えば、非UDP_AT命令)。
CloseChanneI()
IPCチャネルを閉じよという要求。コンポーネントは、チャネルをもはや必要としない。そして、資源は、開放される。
IPCチャネルを閉じよという要求。コンポーネントは、チャネルをもはや必要としない。そして、資源は、開放される。
ChannelGrant()
チャネルが要求側に与えられる。チャネルIDは、まだ、それが割り当てられていない場合、IPCセッション・マネージャによって割り当てられる。
チャネルが要求側に与えられる。チャネルIDは、まだ、それが割り当てられていない場合、IPCセッション・マネージャによって割り当てられる。
ChannelError()
チャネルエラーが発生した。チャネルが閉じられ、要求側に通知される。
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。このメッセージは、IPCプレゼンテーション・マネージャによって対象のコンポーネントに送信される。これには、制御チャネルデータも含まれる。
チャネルエラーが発生した。チャネルが閉じられ、要求側に通知される。
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。このメッセージは、IPCプレゼンテーション・マネージャによって対象のコンポーネントに送信される。これには、制御チャネルデータも含まれる。
DataChannetRequest()
要求側が、開かれたチャネルに関するデータを送りたい。これには、制御チャネルデータも含まれる。
要求側が、開かれたチャネルに関するデータを送りたい。これには、制御チャネルデータも含まれる。
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
2)IPCセッション・マネージャとIPCデバイス・インターフェイス間
OpenChannel()
論理IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。IPCセッション・マネージャは、IPCデバイスインターフェイスマネージャにチャネル優先権要求を送る。
OpenChannel()
論理IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。IPCセッション・マネージャは、IPCデバイスインターフェイスマネージャにチャネル優先権要求を送る。
CloseChannel()
IPC論理チャネルを閉じよという要求。コンポーネントは、もはやチャネルが必要ないと判断する。
IPC論理チャネルを閉じよという要求。コンポーネントは、もはやチャネルが必要ないと判断する。
ChannelGrant()
論理チャネルが、要求側に与えられる。
ChannelError()
チャネルエラーが発生した。(例えば、着信データに関するCRC障害又は物理チャネル障害)
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。
論理チャネルが、要求側に与えられる。
ChannelError()
チャネルエラーが発生した。(例えば、着信データに関するCRC障害又は物理チャネル障害)
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。
DataChannelRequest()
要求側が、論理チャネルに関するデータを送りたい。
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
要求側が、論理チャネルに関するデータを送りたい。
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
3)IPCセッション・マネージャからIPCプレゼンテーション・マネージャへ
ChannetDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。情報は、正しいデータフォーマットで対象のコンポーネントに転送される。
ChannetDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。情報は、正しいデータフォーマットで対象のコンポーネントに転送される。
4)IPCハードウェア/IPCスタックインターフェイス
OpenChannel()
物理IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。IPCセッション・マネージャは、IPCハードウェアにチャネル優先権要求を送る。
OpenChannel()
物理IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。IPCセッション・マネージャは、IPCハードウェアにチャネル優先権要求を送る。
CloseChannel()
IPC物理チャネルを閉じよという要求。コンポーネントは、もはやチャネルを必要としない。
IPC物理チャネルを閉じよという要求。コンポーネントは、もはやチャネルを必要としない。
ChannelGrant()
物理チャネルが、要求側に与えられる。
ChannelError()
チャネルエラーが発生した(例えば、着信データに関するCRC障害又は物理チャネル障害)。
物理チャネルが、要求側に与えられる。
ChannelError()
チャネルエラーが発生した(例えば、着信データに関するCRC障害又は物理チャネル障害)。
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。
DataChannetRequest()
要求側が、物理チャネルに関するデータを送りたい。
要求側は、チャネルに関するデータを送付すべきであると警告される。
DataChannetRequest()
要求側が、物理チャネルに関するデータを送りたい。
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
図15において、IPCネットワークを用いて互いに通信を行うベースバンドプロセッサ(BP)1502及びアプリケーションプロセッサ(AP)1504を有する(例えば、携帯電話等)無線通信装置1500等の電子装置のブロック図を示す。本発明のIPCプロトコルは、通信装置1500等のシステム中の複数のプロセッサ間において、通信を提供する。IPCは、専用通信システム(PCS)アプリケーション等のMAサーバへの移動体アプリケーション(MA)クライアント(例えば、iDENTM_WLAN)の登録を可能にし、また、2つのMAが、それ自体のMA内で、どんなソフトウェア・アーキテクチャ、オペレーティング・システム、ハードウェアに各々依存するかという制限を一切伴わず自由に通信するための手段を提供する。
IPCプロトコルは、任意のIPC準拠MAをIPCリンクに動的に付加し通信を行わせる。従って、IPCネットワークは、コンパイル時間に一切依存せずに、即ち、他のいずれのソフトウェアも前提とせずに形成される。本発明のIPCは、ソフトウェア・コンポーネントがIPCスタック(図15に示さず)と通信を行うための標準的な方法を提示し、また、スタック下のハードウェアは、コンポーネントが通信を行うための異なるリンクを選択し得るように抽出される。
本発明の好適な実施形態について例示し説明したが、本発明がそれに限定されないことは明らかである。数多くの修正、変更、バリエーション、置き換え及び等価物が、添付の請求項によって定義される本発明の精神及び範囲から逸脱することなく、当業者には起こり得る。
Claims (10)
- プロセッサ間通信(IPC)用のIPCネットワーク(100)であって、前記IPCネットワーク(100)は、
IPCサーバ(108)として動作する第1のプロセッサと;
前記IPCサーバ(108)に接続され、且つIPCクライアント(102)として動作する、第2のプロセッサと
からなり、
前記IPCサーバ(108)と前記IPCクライアント(102)とはそれぞれ、IPCスタック(200)を備え、前記IPCスタック(200)は、
プレゼンテーション・マネージャ(202)と;
前記プレゼンテーション・マネージャ(202)に接続されたセッション・マネージャ(204)と;
前記セッション・マネージャ(204)に接続されたデバイス・インターフェイス(206)と
を備え、
前記IPCクライアント(102)は、前記IPCサーバ(108)に通信するために前記IPCスタック(200)を使用し、
前記IPCサーバ(108)と前記IPCクライアント(102)とが交渉により機能を交換することによって、前記IPCクライアント(102)は、新しいIPCサーバ(108)である新IPCサーバになり得て、
前記IPCネットワーク(100)は、複数の前記IPCクライアント(102)を有し、
前記IPCネットワーク(100)の中で、複数の前記IPCクライアント(102、104,108)のうちの1つが前記新IPCサーバになった場合は、前記新IPCサーバにならなかった残りの前記IPCクライアントは、前記IPCサーバ(108)のIPCアドレスを変更すべく指示され、
前記IPCネットワーク(100)は、前記IPCスタック(200)を採用するすべてのプロセッサを共存させ、
前記IPCネットワーク(100)は、2つの前記IPCスタック(200)があたかも、互いに共通のオペレーティング・システムとメモリとを共有する同一のプロセッサコア上で動作するように、前記IPCネットワーク(100)は動作する、IPCネットワーク。 - 少なくとも1つのコンポーネントは、前記IPCクライアント(102)に接続している、
請求項1記載のIPCネットワーク。 - 前記コンポーネント間において異なるデータタイプに変換するために、前記プレゼンテーション・マネージャが使用される、
請求項2記載のIPCネットワーク。 - 少なくとも1つの前記コンポーネントに、前記セッション・マネージャがコンポーネントIDを割り当てる、
請求項2記載のIPCネットワーク。 - 前記コンポーネントIDは、少なくとも1つの前記コンポーネントに動的に割当てられ、且つ再割当てが可能な、
請求項4記載のIPCネットワーク。 - 前記セッション・マネージャ(204)はさらに、コンポーネントルーチングテーブル(404)を有するIPCルータブロック(210)を備え、
前記コンポーネントルーチングテーブル(404)は、前記セッション・マネージャ(204)がIPCデータを特定のOPコードでリンクされた1以上の前記コンポーネントに送信するために使用される、
請求項2記載のIPCネットワーク。 - 少なくとも1つのIPCハードウェアは、デバイス・インターフェイス層(206)に接続され、
前記デバイス・インターフェイス層(206)は、前記IPCスタックがハードウェアに依存しないように、少なくとも1つの前記IPCハードウェアを抽象化する、
請求項1記載のIPCネットワーク。 - IPCネットワーク(100)の第1と第2のプロセッサ間でプロセッサ間通信(IPC)を行う通信方法であって、前記通信方法は、
前記第1のプロセッサがIPCサーバ(108)として働き、前記第2のプロセッサがIPCクライアント(102)として働く工程と;
前記IPCネットワーク(100)を介して、前記IPCサーバ(108)と前記IPCクライアント(102)との間で通信する工程であって、前記IPCサーバ(108)と前記IPCクライアント(102)とはそれぞれ、IPCスタック(200)を備えることと;
前記IPCサーバ(108)と前記IPCクライアント(102)とが互いに交渉し機能を交換することによって、前記IPCクライアント(102)が新しいIPCサーバである新IPCサーバになる工程と
を有し、
前記IPCネットワーク(100)は、複数の前記IPCクライアント(102,104,108)を有し、
前記IPCネットワーク(100)の中で、複数の前記IPCクライアント(102)のうちの1つが前記新IPCサーバである新IPCサーバになった場合は、前記新IPCサーバにならなかった残りの前記IPCクライアントは、前記IPCサーバ(108)のIPCアドレスを変更すべく指示され、
前記IPCスタック(200)はそれぞれ、
プレゼンテーション・マネージャ(202)と、
前記プレゼンテーション・マネージャ(202)に接続されたセッション・マネージャ(204)と、
前記セッション・マネージャ(204)に接続されたデバイス・インターフェイス(206)と
を備え
前記IPCクライアント(102)は、IPCサーバ(108)に通信するために前記IPCスタック(200)を使用し、
前記IPCネットワーク(100)は、前記IPCスタックを採用するすべてのプロセッサを共存させ、
前記IPCネットワーク(100)は、2つの前記IPCスタック(200)があたかも、互いに共通のオペレーティング・システムとメモリとを共有する同一のプロセッサコア上で動作する、通信方法。 - 前記セッション・マネージャ(204)はそれぞれ、動的ルーチングテーブル(402)を備え、
前記通信方法はさらに、前記動的ルーチングテーブル(402)それぞれを使用することによって、前記IPCクライアント(102)から前記IPCサーバ(108)に送信されるデータを適切にルーチングする工程を有する、
請求項8記載の通信方法。 - 前記IPCスタック(200)はそれぞれ、IPCトランスポート層(208)を有するセッション・マネージャ(204)を含み、
前記IPCトランスポート層(208)は、IPCデータについて周期的な冗長検査を行い、
前記通信方法は更に、前記IPCサーバ(108)上のみで前記IPCトランスポート層(208)のルーチング機能を可能にする、
請求項8記載の方法。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/610,746 | 2003-07-01 | ||
US10/610,746 US7447735B2 (en) | 2003-07-01 | 2003-07-01 | Interprocessor communication protocol |
PCT/US2004/020212 WO2005006133A2 (en) | 2003-07-01 | 2004-06-24 | Interprocessor communication protocol |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2007526544A JP2007526544A (ja) | 2007-09-13 |
JP2007526544A5 true JP2007526544A5 (ja) | 2012-04-05 |
JP4981444B2 JP4981444B2 (ja) | 2012-07-18 |
Family
ID=34062323
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006517601A Expired - Fee Related JP4981444B2 (ja) | 2003-07-01 | 2004-06-24 | プロセッサ間通信プロトコル |
Country Status (5)
Country | Link |
---|---|
US (2) | US7447735B2 (ja) |
EP (1) | EP1644838B1 (ja) |
JP (1) | JP4981444B2 (ja) |
KR (1) | KR100854262B1 (ja) |
WO (1) | WO2005006133A2 (ja) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7623894B2 (en) * | 2003-10-09 | 2009-11-24 | Freescale Semiconductor, Inc. | Cellular modem processing |
US7571222B1 (en) * | 2003-11-26 | 2009-08-04 | Sun Microsystems, Inc. | Network component identification |
FR2868638B1 (fr) * | 2004-03-30 | 2006-05-19 | Sagem | Procede d'echange d'informations entre deux reseaux fonctionnant sous des protocoles de routages differents |
GB2446199A (en) | 2006-12-01 | 2008-08-06 | David Irvine | Secure, decentralised and anonymous peer-to-peer network |
US8725874B2 (en) * | 2007-09-27 | 2014-05-13 | International Business Machines Corporation | Dynamic determination of an ideal client-server for a collaborative application network |
KR101600951B1 (ko) * | 2009-05-18 | 2016-03-08 | 삼성전자주식회사 | 고체 상태 드라이브 장치 |
US8667193B2 (en) | 2011-04-29 | 2014-03-04 | Qualcomm Incorporated | Non-ported generic device (software managed generic device) |
US9065674B2 (en) * | 2011-04-29 | 2015-06-23 | Qualcomm Incorporated | Multiple slimbus controllers for slimbus components |
US9043634B2 (en) | 2011-04-29 | 2015-05-26 | Qualcomm Incorporated | Methods, systems, apparatuses, and computer-readable media for waking a SLIMbus without toggle signal |
US9351337B2 (en) | 2011-08-31 | 2016-05-24 | Telefonaktiebolaget L M Ericsson (Publ) | Virtual inter-process communication between a radio equipment and a radio equipment controller in a base station of a wireless communication system |
CN104993969B (zh) * | 2015-07-28 | 2018-01-16 | 上海斐讯数据通信技术有限公司 | 一种异步配置onu方法、系统及olt |
CN113612671B (zh) * | 2021-08-02 | 2022-09-06 | 上海同星智能科技有限公司 | 总线适配器与通道绑定配置方法、映射管理器及连接系统 |
JP2023541740A (ja) * | 2021-08-02 | 2023-10-04 | シャンハイ トサン テクノロジー リミテッド | バスアダプタとチャネルとのバインディング及び配置方法、並びにマッピング管理装置及び接続システム |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3003418B2 (ja) * | 1992-09-25 | 2000-01-31 | 株式会社日立製作所 | プロセッサ間データ通信方法 |
JP3490473B2 (ja) * | 1993-02-17 | 2004-01-26 | 松下電器産業株式会社 | プロセッサ間通信システム |
US6510465B1 (en) * | 1994-04-19 | 2003-01-21 | Ibm | Dual communication services interface for distributed transaction processing |
US5623605A (en) * | 1994-08-29 | 1997-04-22 | Lucent Technologies Inc. | Methods and systems for interprocess communication and inter-network data transfer |
JPH0883230A (ja) * | 1994-09-14 | 1996-03-26 | Hitachi Ltd | 分散オブジェクト間メッセージ送信方法及び装置 |
US5848145A (en) * | 1996-12-20 | 1998-12-08 | Lucent Technologies Inc. | Automatic learning of network routing using random routes |
US6996823B1 (en) * | 2000-04-06 | 2006-02-07 | International Business Machines Corporation | Inter process communications in a distributed CP and NP environment |
US7263701B2 (en) * | 2001-09-04 | 2007-08-28 | Samsung Electronics Co., Ltd. | Interprocess communication method and apparatus |
US20030115358A1 (en) * | 2001-09-04 | 2003-06-19 | Yeong-Hyun Yun | Unified interprocess communication |
EP1322097A1 (en) * | 2001-12-21 | 2003-06-25 | Siemens Aktiengesellschaft | A method and computer system for client server inter process communication |
US7546365B2 (en) * | 2002-04-30 | 2009-06-09 | Canon Kabushiki Kaisha | Network device management system and method of controlling same |
-
2003
- 2003-07-01 US US10/610,746 patent/US7447735B2/en not_active Expired - Fee Related
-
2004
- 2004-06-24 WO PCT/US2004/020212 patent/WO2005006133A2/en active Application Filing
- 2004-06-24 KR KR1020057025477A patent/KR100854262B1/ko active IP Right Grant
- 2004-06-24 EP EP04755997.6A patent/EP1644838B1/en not_active Not-in-force
- 2004-06-24 JP JP2006517601A patent/JP4981444B2/ja not_active Expired - Fee Related
-
2008
- 2008-11-03 US US12/263,819 patent/US8326918B2/en not_active Expired - Fee Related
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8326918B2 (en) | Interprocessor communication protocol | |
US20050010925A1 (en) | Interprocessor communication protocol with smart streaming port | |
JP2003177930A (ja) | プロセス間通信方法及び装置 | |
JP2007526544A5 (ja) | ||
JP4820940B2 (ja) | ポート群を動的に専用化するプロセッサ間通信ネットワーク | |
US7263701B2 (en) | Interprocess communication method and apparatus | |
US7356594B2 (en) | Interprocessor communication protocol providing intelligent targeting of nodes | |
KR100812680B1 (ko) | 보장된 서비스 품질 및 선택적인 브로드캐스팅을 제공하는프로세서간 통신 프로토콜 | |
KR100787850B1 (ko) | 고레벨 서비스 구성을 갖는 인터프로세서 통신 프로토콜 | |
KR100805094B1 (ko) | 포트들의 동적 전용을 제공하는 인터프로세서 통신네트워크 | |
EP3534586B1 (en) | Techniques for interaction between network protocols | |
JP2000151739A (ja) | 情報処理装置、分散処理装置およびネットワークシステム |