JP2002158736A

JP2002158736A - 通信方法

Info

Publication number: JP2002158736A
Application number: JP2000355633A
Authority: JP
Inventors: Masanori Honda; 政則本田; Taro Inoue; 太郎井上; Hiroshi Yamada; 弘山田; Masaaki Oya; 雅章大矢
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2000-11-17
Filing date: 2000-11-17
Publication date: 2002-05-31

Abstract

(57)【要約】【課題】通信を行うプロセスやスレッド自身が煩雑なコ
ネクション管理を行う必要を無くし、効率よく確実なデ
ータ転送を行う。【解決手段】通信手段１０２に設けられた通信管理部１
０５により、送信しようとするデータの大きさに応じて
コネクション型通信とコネクションレス型通信のいずれ
のプロトコルを用いて通信を行うか判別する。通信手段
１０２は、通信管理部１０５での判別の結果に従ったプ
ロトコルを用いて通信先との通信を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報機器上で動作
する複数のプロセス間の通信方法及び通信装置に関す
る。

【０００２】

【従来の技術】現在、コンピュータシステムなどにおい
て、情報処理機器のプロセス間の通信では、ＴＣＰ／Ｉ
Ｐプロトコルが標準的に使われている。ＴＣＰ／ＩＰプ
ロトコルを用いて通信を行う場合、一般には、ＴＣＰプ
ロトコルを利用したコネクション型通信を行うか、ＵＤ
Ｐプロトコルを利用したコネクションレス型通信を行う
か、ユーザアプリケーションのプログラマがあらかじめ
決める必要がある。

【０００３】コネクション型通信（ＴＣＰ）は、確実に
データの送受信が行える半面、ハンドシェイクやウィン
ドウ処理等オーバーヘッドが大きく性能が悪い。一方、
コネクションレス型通信（ＵＤＰ）は、性能がよい半
面、信頼性が低い。ユーザアプリケーションのプログラ
マは、従来、このような２つのプロトコルの特徴をよく
理解した上で、状況に応じてこれらのプロトコルを使い
分ける必要があった。

【０００４】

【発明が解決しようとする課題】１対１で通信を行う場
合では問題とならないが、１つのプロセスが多くのプロ
セスと通信する場合、以下のような問題が発生する。

【０００５】例えば、１台のコンピュータ上にソフトウ
ェア管理マネージャプロセスが動作しており、このソフ
トウェア管理マネージャプロセスにより他の１０００台
のコンピュータ上のソフトウェアを管理する場合を考え
る。他のコンピュータのそれぞれでは、ソフトウェア管
理エージェントプロセスが動作しているものとする。

【０００６】ソフトウェア管理マネージャプロセスとソ
フトウェア管理エージェントプロセスとの間の通信のた
めにコネクション型通信（ＴＣＰ）を用いると、ソフト
ウェア管理マネージャプロセスは、他のコンピュータと
の間の１０００個のコネクションを管理しなければなら
なくなる。このような多数のＴＣＰコネクションを一つ
のコンピュータで取り扱うのは現実的ではない。例え１
０００個のコネクションが管理できたとしても、著しい
性能低下を招く。

【０００７】一方、コネクションレス型通信（ＵＤＰ）
を用いると、コネクション管理が不要になる上、性能の
低下も生じない。しかし、新しいバージョンのソフトウ
ェアを配布するなど、大量のデータを転送する場合に問
題が起きる。ＵＤＰでは、大きなデータは複数のパケッ
トに分割して送られるが、各パケットが送信先に確実に
届く保証がない。このため、ユーザプログラム内で全て
のパケットが順番通り確実に届くように、パケットの管
理を行わなければならない。ユーザアプリケーションの
プログラマがこのパケット管理を行うと、ユーザプログ
ラムが非常に複雑になり、性能確保も難しくなる。

【０００８】ソフトウェア管理だけに限らず、大量の情
報機器（コンピュータ等）の運用管理を行う場合、１対
多通信、多対多通信を頻繁に行う必要があり、これらの
通信を効率よく行わなければならない。

【０００９】

【課題を解決するための手段】上記課題を解決するため
に、本発明によれば、情報処理システム上で動作するプ
ロセス間で相互に通信するための通信方法において、送
信側で、送信しようとするデータに基づきコネクション
型通信プロトコルとコネクションレス型通信プロトコル
のいずれによりデータを送信するか判別し、判別の結果
に従ったプロトコルを用いてデータの送信が行われる。

【００１０】より具体的に、本発明によれば、通信管理
部、セッション管理部、モジュールリスト部を有する通
信手段がコンピュータ上に設けられる。

【００１１】第１のコンピュータ上で動作する第１のモ
ジュールが、第２のコンピュータ上で動作する第２のモ
ジュールと通信を行う場合、第１のコンピュータ上で
は、第１の通信手段が、第２のコンピュータ上では、第
２の通信手段が動作する。第１及び第２の通信手段は、
初期処理として、各モジュールの情報をモジュールリス
トに登録する。第１のモジュールは送信時、第２のモジ
ュールの名前と、第２のコンピュータのアドレスを指定
し第１の通信手段に処理を依頼する。第１の通信手段の
通信管理部は、コネクションレス型プロトコルを利用し
て第２の通信手段にデータを送信する。第２の通信手段
は、データの受信を完了した後、受信完了を伝えるデー
タを第１の通信手段に送信する。第１の通信手段の通信
管理部は、一定時間経過しても受信完了データが第２の
通信手段から来ない場合、送信データを再送する。第１
及び第２の通信手段は、受信確認を行うことにより、信
頼性を向上させる。

【００１２】また、送信データが一定値より大きい場
合、第１の通信手段の通信管理部は、第２の通信手段に
対し、ＴＣＰによるコネクション確立要求を出す。第１
の通信手段のセッション管理部と第２の通信手段のセッ
ション管理部によりＴＣＰコネクションが張られた後、
第１の通信手段は、ＴＣＰコネクションを用いて送信デ
ータを第２の通信手段に送信する。送信完了後、ＴＣＰ
コネクションは破棄される。

【００１３】

【発明の実施の形態】図１に、本発明が適用された計算
機システムの位置実施形態における基本構成を簡略に示
したブロック図である。本実施形態では、二つのプロセ
スが通信を行う場合を例に説明を行う。なお、本明細書
において、通信を行うプロセス、またはスレッドをモジ
ュールと呼ぶ。

【００１４】コンピュータＡ１００上では、モジュール
Ａ１０１、および通信手段Ａ１０２が稼動している。同
様に、コンピュータＢ２００上では、モジュールＢ２０
１と通信手段Ｂ２０２が稼動している。通信手段Ａ１０
２、通信手段Ｂ２０２は、ＴＣＰ／ＩＰプロトコル上で
動作し、通信管理部１０３、２０３、セッション管理部
１０５、２０５、モジュールリスト部１０４、２０４か
ら構成される。通信手段Ａ１０２、通信手段Ｂ２０２
は、具体的には、デーモン（またはサービス）として実
行される。つまり、モジュールとは独立したプロセスと
して実行されている。本実施形態では、ＴＣＰおよびＵ
ＤＰを利用する手段として、ソケットインターフェース
を用いるが、他のインターフェースを用いてＴＣＰやＵ
ＤＰを利用するようにしてもよい。

【００１５】図２は、通信手段Ａ１０２、通信手段Ｂ２
０２を介して通信を行うモジュールにより実施される処
理の流れを示すフローチャートである。

【００１６】他のモジュールと通信しようとするモジュ
ールは、まず、通信手段（通信手段Ａ１０２、あるい
は、通信手段Ｂ２０２）に接続する。具体的には、ＴＣ
Ｐソケット等を用いて通信手段とプロセス間通信を行う
（ステップ１００１）。通信手段との接続が完了する
と、モジュールは、モジュール特有の処理を行う。モジ
ュール特有の処理とは、各種設定、制御、データ収集、
編集等の直接的な通信以外の処理を指す（ステップ１０
０２）。次に、必要に応じて他のモジュールと送受信を
行う。具体的には、モジュールは、通信手段に対し、送
信先となるモジュールのモジュール名、そのモジュール
が存在するコンピュータのアドレス（ホスト名、ＩＰア
ドレス等）といった、モジュールを特定するための情報
と送信するデータを指定する。また、通信手段に対して
受信要求することにより、他のモジュールからデータを
受信することができる（ステップ１００３）。ステップ
１００２および１００３の処理は、必要なだけ繰り返さ
れる。図２では、便宜的にステップ１００２、１００
３、１００４の処理が連続しているように書かれている
が、ステップ１００２の処理中にモジュールの終了が指
示されるとモジュールは処理を終了する（ステップ１０
０４）。

【００１７】図３は、通信手段の通信管理部による内部
処理の流れを示すフローチャートである。

【００１８】通信手段の通信管理部は、モジュールから
の接続があると、まず、モジュール接続受付スレッド２
１００を生成する（ステップ２００１）。続いて、送信
スレッド２２００の生成（ステップ２００２）、受信ス
レッド２３００の生成（ステップ２００３）を実施す
る。これら３つのスレッドの生成順序は、入れ替えるこ
とも可能である。この後、通信管理部は、通信手段の終
了イベントが発生するまで待つ（ステップ２００３）。

【００１９】図４は、モジュール接続受付スレッド２１
００の処理を示すフローチャートである。

【００２０】モジュール接続受付スレッド２１００は、
生成されるとモジュールからの接続要求を待つ（ステッ
プ２１０１）。接続要求が来るとモジュール接続受付ス
レッド２１００は、モジュールを通信手段に接続し、モ
ジュールリスト部にエントリを１つ追加して、モジュー
ル名、接続識別子等を登録する。モジュール名として
は、文字列でもよいし、ユニークな番号等でもよい。接
続識別子としては、例えばＴＣＰソケットを利用するの
であれば、ソケットハンドルが接続識別子となる（ステ
ップ２１０２）。モジュールリスト部への登録が完了す
ると、モジュール接続受付スレッド２１００は、ステッ
プ２１０１の処理に戻り、モジュールからの接続要求を
待つ。

【００２１】図５は、送信スレッド２２００の処理を示
すフローチャートである。

【００２２】送信スレッド２２００は、既にモジュール
リスト部に登録されているモジュールからの送信要求を
待つ（ステップ２２０１）。モジュールから送信要求が
来ると、送信スレッド２２００は、モジュールからの送
信データがＵＤＰで送信不可かどうかを調べる（ステッ
プ２２０２）。ＵＤＰでの送信が不可であれば、送信ス
レッド２２００は、送信先と送信データを指定して、セ
ッション管理部にコネクション要求を出す（ステップ２
２０３）。その後、ＵＤＰを用いて、送信先コンピュー
タの通信手段に対し、コネクション要求を送信し、ステ
ップ２２０１の処理に戻る。なお、ＵＤＰは信頼性が保
証されていないため、肯定応答等を用いて確実にデータ
や要求が送信先に届いたことを確認する（受信確認）。
一定期間待っても肯定応答が戻ってこない場合、データ
や要求の再送を行う。（ステップ２２０４）。

【００２３】ステップ２２０２において、ＵＤＰで送信
可能である場合、送信スレッド２２００は、ＵＤＰによ
り送信先へデータを送信する。この場合でも、実際に送
信データを受け取るのは、送信先コンピュータ上で動作
している通信手段である。データをＵＤＰで送るか、Ｔ
ＣＰで送るかの判別は、送信データが送信途中のネット
ワーク上で複数パケットに分割されない大きさを基準と
する。データを送信した後、ステップ２２０１の処理に
もどる（ステップ２２０５）。

【００２４】図６は、受信スレッド２３００の処理を示
すフローチャートである。

【００２５】受信スレッド２３００は、生成されるとＵ
ＤＰからの受信を待つ（ステップ２３０１）。受信スレ
ッド２３００は、ＵＤＰからデータを受け取ると、それ
が他のモジュールからの送信データか、コネクション要
求かを判別する（ステップ２３０２）。送信データであ
れば、モジュールリスト部から適切なモジュールを検索
し、該当する接続識別子を用いてそのモジュールへデー
タを転送する。モジュールリストに該当するモジュール
が登録されていなければ、送信元にエラーが返される。
データを送信した後、処理は、ステップ２３０１に戻る
（ステップ２３０３）。

【００２６】ステップ２３０２において受け取ったデー
タがコネクション要求であれば、モジュールリスト部か
ら宛先となるモジュールを探す（ステップ２３０４）。
該当するモジュールがあれば、コネクション要求をセッ
ション管理部に転送する。該当するモジュールがなけれ
ば、送信元にエラーを返す。データを送信した後、処理
は、ステップ２３０１に戻る（ステップ２３０５）。

【００２７】図７は、セッション管理部の処理を示すフ
ローチャートである。

【００２８】セッション管理部は、まず、通信管理部か
らの要求を待つ（ステップ３００１）。受け取った要求
が終了要求であればセッション管理の処理を終了する
（ステップ３００２）。受け取った要求がコネクション
要求であれば、セッションスレッド３１００を生成し、
再びコネクション要求を待つ（ステップ３００３）。

【００２９】セッションスレッド３１００では、データ
を送る側のコネクション要求か、受ける側のコネクショ
ン要求かを判別する（ステップ３１０１）。送る側のコ
ネクション要求であれば、宛先となるコンピュータの通
信手段に対し、実質的なコネクション要求を出す。これ
は、ソケットインターフェースのｃｏｎｎｅｃｔに該当
する（ステップ３１０２）。コネクションが確立された
後、データが送信される（ステップ３１０３）。データ
送信完了後、コネクションは破棄される（ステップ３１
０４）。

【００３０】ステップ３１０１において、受ける側のコ
ネクション要求であれば、実質的なコネクション要求を
待つ。これは、ソケットインターフェースのｌｉｓｔｅ
ｎに該当する（ステップ３１０５）。コネクション確立
後（ソケットインターフェースａｃｃｅｐｔの後）、デ
ータが受信され、適切なモジュールへデータが転送され
る（ステップ３１０６）。データ受信完了後、セッショ
ンスレッド３１００は、コネクションを破棄する（ステ
ップ３１０７）。

【００３１】ステップ３１０４および３１０７の後、ス
レッドは消滅する。なお、ここでスレッドを消滅させ
ず、スレッドプール構成として、スレッドを再利用する
ようにしてもよい。例えば、図８で示すように、コンピ
ュータＡ１００上にモジュールＡ１０１、コンピュータ
Ｂ２００上にモジュールＢ２０１、コンピュータＣ３０
０上にモジュールＣ３０１、コンピュータＤ４００上に
モジュールＤ_１４０１とモジュールＤ_２４１１、コンピ
ュータＥ５００上にモジュールＥ_１５０１とモジュール
Ｅ_２５１１が動作しており、全てのコンピュータがネッ
トワーク１により接続されているとする。全てのコンピ
ュータ上には、それぞれ通信手段ＡからＥが動作してい
る。これは、論理的に見ると、図９で示すように、通信
手段２を一本の通信バスとし、全てのモジュールがこの
通信バスに接続されているよう捉えることができる。

【００３２】モジュールＡ１０１がモジュールＥ_２５１
１に対してデータを送信する場合、モジュールＥ_２５１
１が動作するコンピュータ名とモジュール名（ここでは
モジュールＥ_２）および送信データを、モジュールＡ１
０１が通信手段に対して指定する。各モジュールは、煩
雑なコネクション管理を行う必要がなく、小さなデータ
もＵＤＰにより迅速に転送される。さらに、通信手段
は、ＵＤＰを利用する場合、受信確認を行うためデータ
は確実に転送される。

【００３３】図９において、モジュールＡ１０１を資産
管理マネージャ、その他のモジュールは、資産管理情報
を集めるエージェントであると仮定する。この場合にお
いて、資産管理マネージャ１０１が各エージェントに対
して資産情報収集要求を出すことを考える。上述した通
信手段を用いれば、モジュールＡ１０１は各モジュール
を指定し資産情報収集要求を出し、各モジュールからの
返信を待つだけでよい。

【００３４】また、他の形態として、名前管理を行うプ
ロセスおよびデータベースを利用することが考えられ
る。各モジュールが動作しているコンピュータ名をあら
かじめ当該データベースに登録することにより、通信
時、モジュール名を指定するだけで通信が可能となる。
こうすれば、特定のモジュールと通信を行う場合、その
物理的な位置を意識する必要がなくなる。

【００３５】

【発明の効果】本発明によれば、通信を行いたいプロセ
スやスレッド自身が煩雑なコネクション管理を行う必要
が無く、効率よく確実なデータ転送が行える。このた
め、大規模分散アプリケーションを開発するユーザアプ
リケーションプログラマは短い期間でプログラミングで
き、しかも、効率のよい通信手段を手に入れることがで
きる。

【図面の簡単な説明】

【図１】本発明が適用された計算機システムの位置実施
形態における基本構成を簡略に示したブロック図であ
る。

【図２】モジュールにより実施される処理の流れを示す
フローチャートである。

【図３】通信手段の通信管理部による内部処理の流れを
示すフローチャートである。

【図４】通信管理部のモジュール接続受付スレッドの処
理を示すフローチャートである。

【図５】通信管理部の送信スレッドの処理を示すフロー
チャートである。

【図６】通信管理部の受信スレッド２３００の処理を示
すフローチャートである。

【図７】セッション管理部の処理を示すフローチャート
である。

【図８】本発明の他の形態を示す計算機システムの構成
を簡略に示すブロック図である。

【図９】図８に示す計算機システムの論理的な構成を示
すブロック図である。

【符号の説明】

１００、２００・・・コンピュータ１０１、２０１・・・モジュール１０２、２０２・・・通信手段１０３、２０３・・・通信管理部１０４、２０４・・・モジュールリスト部１０５、２０５・・・セッション管理部

───────────────────────────────────────────────────── フロントページの続き (72)発明者山田弘神奈川県川崎市麻生区王禅寺1099番地株式会社日立製作所システム開発研究所内 (72)発明者大矢雅章神奈川県横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウェア事業部内Ｆターム(参考） 5K034 AA01 BB06 DD01 EE05 FF01 HH01 HH02 HH06 HH63 KK29 LL01

Claims

【特許請求の範囲】

【請求項１】情報処理システム上で動作するプロセス間
で相互に通信するための通信方法において、送信側で、
送信しようとするデータに基づきコネクション型通信プ
ロトコルとコネクションレス型通信プロトコルのいずれ
により前記送信しようとするデータを送信するか判別
し、該判別の結果に従ったプロトコルを用いて前記送信
しようとするデータを送信することを特徴とする通信方
法。
【請求項２】前記判別は、前記送信しようとするデータ
の大きさに基づいて行われることを特徴とする請求項１
記載の通信方法。
【請求項３】前記転送しようとするデータの大きさが一
定の大きさ以下であればコネクションレス型通信プロト
コル用い、前記転送しようとするデータの大きさが前記
一定の大きさ以上であればコネクション型通信プロトコ
ルを用いることを特徴とする請求項２記載の通信方法。
【請求項４】前記判別の結果コネクション型通信プロト
コルを用いると判別されたとき、通信先に対するコネク
ションの確立の要求を、コネクションレス型通信プロト
コルを用いて行うことを特徴とする請求項１の通信方
式。