JPH07200505A - 一斉同報通信方法およびその装置 - Google Patents

Abstract

(57)【要約】 【目的】本発明の目的は、確認応答パケットの取りこぼ
しの可能性を軽減し、複数のパケットからなるデータを
効率的に、かつ、確実にブロードキャストすることにあ
る。 【構成】送信サイト上の送信ソフトウェア５で定義した
階層構造に基づいて、全サイトに対して配付した１ブロ
ック（複数パケット）のデータの確認応答を収集する。
最下位階層に属するサイトの受信ソフトウェア１０は、
確認応答を中間サイト上の中継ソフトウェア９に送り、
中継ソフトウェア９は、必要であれば再送処理を行なっ
て、サイト２以下の全てのサイト（サイト５４〜５８）
からの確認応答を受けてから、上位階層のサイト１に確
認応答を送信する。送信ソフトウェア５は、全ての下位
階層からの確認応答を受けとってから、１ブロックのブ
ロードキャスト送信処理を終える。 【効果】本発明により、複数パケットから成るデータの
ブロードキャストを、各受信サイトへの到達を保証し、
かつ、効率的に行なうことが可能となる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、分散／並列システムに
おけるデータの一斉同報通信方法およびその装置に関
し、特に、同報通信の信頼性を保証するための確認応答
の収集の改良に関する。

【０００２】

【従来の技術】コンピュータネットワークの発展にとも
なって、ネットワークに接続された全サイトに同一デー
タを転送するブロードキャスト（一斉同報）通信は重要
な機能となってきている。ここで、サイトとは、ネット
ワークに接続された計算ユニットをいう。この計算ユニ
ットは、プロセッサとプロセッサが機械語レベルでアク
セス可能なメモリ（ローカルメモリ）を備えている。

【０００３】従来のブロードキャスト通信では、ネット
ワーク上の全サイトにデータが届くことを保証する必要
はなかった。これに対し、すべてのサイトへのデータ到
着を保証するブロードキャスト機構を使用する例も存在
する。

【０００４】近年、プロセッサとローカルメモリを備え
た複数のサイトを高速通信回線で接続した超並列計算機
システムを用いて、従来のスーパコンピュータの性能を
しのぐ計算を行うことが重要になってきている。このよ
うなシステムにおいては、ＯＳ（オペレーティングシス
テム）やユーザアプリケーションを、全サイトあるいは
全サイトのサブセットを成すサイトの集合に、いかに速
く、かつ、信頼性を保ちながら分配するかが重要な技術
課題である。

【０００５】さらに、ワークステーションやパソコンが
ネットワークでつながれた分散環境においても、その上
で稼働するネームサーバやデータベース・マネッジメン
ト・システムに、更新データをいかに信頼性を保証しな
がら転送するかが、重要な技術課題である。

【０００６】このような場合、信頼性のあるブロードキ
ャスト（Ｒｅｌｉａｂｌｅ Ｂｒｏａｄｃａｓｔ）機構
を用いてデータを分配する。信頼性のあるブロードキャ
スト機能は、Ｋ．Ｐ．バーマン（Ｋ．Ｐ． Ｂｉｒｍａ
ｎ）著「障害時における信頼性のある通信」という表題
の論文（ａｒｔｉｃｌｅ ｅｎｔｉｔｌｅｄ ”Ｒｅｌ
ｉａｂｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｉｎ ｔｈ
ｅ Ｐｒｅｓｅｎｃｅｏｆ Ｆａｉｌｕｒｅｓ”，ｉｎ
ｔｈｅ ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｏｎ Ｃｏ
ｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ，Ｖｏｌ．５ Ｎｏ．
１，Ｆｅｂ．１９８７ ａｔ ｐｐ．４７−７６）で述
べられているように、プログラムの開発効率や、デバッ
グ作業の軽減にも役に立つ。

【０００７】通常、信頼性のあるブロードキャスト機能
は、次の２点を保証することを目的とする。即ち、
（１）全ての受信サイトにデータが渡ること、（２）全
てのサイトでデータの受け取る順番が同じであること、
の２点である。しかし、（２）を保証することは、ブロ
ードキャスト通信のパフォーマンスの低下を招き、プロ
グラムや一塊のデータを高速に分散する目的には制約が
強すぎる。

【０００８】（１）についての保証は、通常、送信サイ
トが受信サイトから確認応答（Ａｃｋｎｏｗｌｅｄｇｅ
ｍｅｎｔ）を受けることにより行われる。例えば、トラ
ンスポート層の１対１通信のプロトコルであるＴＣＰで
は、複数の送信パケットに１つの確認応答を対応させる
遅延確認技法（ｄｅｌａｙｅｄ Ａｃｋ）を用いて、確
認応答の数を減らし、性能向上を計っている。また、受
信データの取りこぼしのために再送が必要となるような
場合にのみ再送要求を送るネガティブ・アクノリッジメ
ント（ｎｅｇａｔｉｖｅ ａｃｋｎｏｗｌｅｄｇｅｍｅ
ｎｔ）の方法も、応答メッセージを減らす目的で利用さ
れる。ただし、送信サイトでは送信したデータを再送用
としてバッファに保持しており、確認応答を受けてその
バッファを解放する必要があるため、全く確認応答を送
らないで通信を行うことは不可能である。

【０００９】ネットワークアーキテクチャに関しては、
従来のブロードキャストプロトコルは、ハードウェアが
提供するブロードキャスト機能のないポイントツポイン
トの通信リンクを持つネットワークを前提としている。
例えば、ハイパーキューブの場合、奥川俊史著の「並列
計算機アーキテクチャ」の第６７〜６８に記載されてい
るように、木構造を作成して、その木構造に基づいてブ
ロードキャストを行う。

【００１０】もっと一般的なネットワークの場合は、
「ミニマム・ウェイト・スパニング・ツリーの分散アル
ゴリズム」という表題の論文（ａｒｔｉｃｌｅ ｅｎｔ
ｉｔｌｅｄ ”Ａ Ｄｉｓｔｒｉｔｕｔｅｄ Ａｌｇｏ
ｒｉｔｈｍ ｆｏｒ Ｍｉｎｉｍｕｍ−Ｗｅｉｇｈｔ
Ｓｐａｎｎｉｎｇ Ｔｒｅｅｓ”，ｂｙ Ｒ．Ｇ． Ｇ
ａｌｌａｇｅｒ，Ｐ．Ａ． Ｈｕｍｂｌｅｔ，ａｎｄ
Ｐ．Ｍ． Ｓｐｉｒａｉｎ ｔｈｅ ＡＣＭ Ｔｒａｎ
ｓａｃｔｉｏｎ ｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｌａ
ｎｇｕａｇｅｓ ａｎｄ Ｓｙｓｔｅｍｓ，Ｖｏｌ．
５，Ｎｏ．１，Ｊａｎ． １９８３ ａｔ ｐｐ．６６
−７７）で示されているアルゴリズムを用いて、ミニマ
ム・ウェイト・スパニング・ツリーを作成し、その木構
造に基づいて通信コストが最少になるようにブロードキ
ャストメッセージを転送する。

【００１１】ＬＡＮの持つブロードキャスト機能を生か
して高速な信頼性のあるブロードキャスト機能を実現す
るプロトコルとしては、「効率的な信頼性のあるブロー
ドキャストプロトコル」と言う表題の論文（ａｒｔｉｃ
ｌｅ ｅｎｔｉｔｌｅｄ ”Ａｎ Ｅｆｆｉｃｉｅｎｔ
Ｒｅｌｉａｂｌｅ Ｂｒｏａｄｃａｓｔ Ｐｒｏｔｏ
ｃｏｌｓ”，ｂｙ Ｍ．Ｆｒａｎｓ Ｋａａｓｈｏｅ
ｋ，Ａｎｄｒｅｗ Ｓ．Ｔａｎｅｎｂａｕｍ，ａｎｄ
ｅｔ． ｉｎ ｔｈｅ ＡＣＭ Ｏｐｅｒａｔｉｎｇ
Ｓｙｓｔｅｍ Ｒｅｖｉｅｗ，Ｖｏｌ．２３，Ｎｏ．
４，Ｏｃｔ． １９８９ ａｔ ｐｐ．５−２０）に掲
載されたものや、「信頼性のあるブロードキャストプロ
トコル」という表題の論文（ａｒｔｉｃｌｅ ｅｎｔｉ
ｔｌｅｄ ”Ｒｅｌｉａｂｌｅ Ｂｒｏａｄｃａｓｔ
Ｐｒｏｔｏｃｏｌｓ”，ｂｙ Ｊｏ−Ｍｅｉ Ｃｈａｎ
ｇ ａｎｄ Ｎ．Ｆ． Ｍａｘｅｍｃｈｕｋ ｉｎ ｔ
ｈｅＡＣＭ Ｔｒａｎｓａｃｔｉｏｎ ｏｎ Ｃｏｍｐ
ｕｔｅｒ Ｓｙｓｔｅｍｓ，Ｖｏｌ．２，Ｎｏ．３，Ａ
ｕｇ． １９８４ ａｔ ｐｐ．２５１−２７３）に掲
載されたものがある。これらのプロトコルの特徴は、信
頼性を保証するために、１つの特別なサイトがパケット
転送の確認を代行して行うことである。

【００１２】一方、特開平２−１１８７６３号では、分
散されたデータを木構造にしたがって効率的に集めるた
めに、木構造の各ノードで優先度付けや選択処理を行う
機構を開示している。また、特開平４−２７３７３６号
では、パケット再送専用のサイトを用意し、再送時の負
担を専用サイトに任せることにより、通信サイトの負荷
を下げる機能を提供している。

【００１３】さらに、特開平４−１３３１８号および特
開平３−２７７０２４号などでは、通信サイトをグルー
プ化し、グループごとに異るタイミングで確認応答を逐
次的に受けて、確認応答を収集する方法が開示されてい
る。特開平５−７６５２号および特開平１−４９３４６
号では、各サイトをノードとする階層構造を作成し、そ
の階層構造にしたがってパケットをブロードキャストし
確認応答を収集する方法が開示されている。

【００１４】上述の特許公開公報の技術は、いずれも、
基本的に1パケットのブロードキャストについてのみの
送信であり、再送について言及してあるものは特開平３
−２７７０２４号だけである。この特開平３−２７７０
２４号では、データの送信元は、再送要求が送られてき
たとき、新たにグループを構成し直して再送を行なって
いる。

【００１５】

【発明が解決しようとする課題】ブロードキャスト通信
において、すべての送信先サイトへのメッセージ到着の
保証を意味する信頼性を与えるために、従来は、送信サ
イトあるいは代行サイトが、送信したパケットに対応す
る確認応答を全てのサイトから受けていた。しかし、大
規模なネットワークで全サイト数が比較的大きい場合
は、確認応答パケットが１サイトに多数集中し、ネット
ワークの状態が通常の場合でも、即ち、特別にネットワ
ーク中の通信量が多くない場合でも、パケットを取りこ
ぼす可能性がある。

【００１６】図２６は、確認応答パケットの取りこぼし
の様子を示す図である。この図では、送信サイト５２２
からブロードキャストを行った後の確認応答パケットの
受信の様子を示している。ブロードキャストを行った送
信サイト５２２は、受信ノードから、確認応答パケット
を受信する。送信サイト５２２は、受信パケットのキュ
ー５２１を備えている。

【００１７】超並列システムのように通信回線のスピー
ドがプロセッサの処理スピードに比べて高速なアーキテ
クチャの場合でも、始めの数パケットは送信サイト５２
２のキュー５２１に挿入することで受信できる。しか
し、ブロードキャストの確認応答のように短時間に受信
するパケット数が多数の場合は、受信パケットキュー５
２１が一杯になり、プロセッサによるパケットの処理ス
ピードに律速される。すなわち、プロセッサの処理スピ
ードよりも確認応答パケットの受信スピードの方が早い
場合は、パケット５２１のように、受信パケットキュー
５２１が一杯のため受信されずに破棄されてしまうパケ
ットが出現する。これがパケットの取りこぼしである。

【００１８】確認応答用のパケットを取りこぼすと、上
述の通信手順を行なう送信サイトのプロトコルモジュー
ルは、タイムアウトによって取りこぼしたことを検出
し、同じデータを再送する必要がある。さらに、取りこ
ぼしたパケットが肯定応答（ＡＣＫ）であったとして
も、送信サイトは不要な再送を行なってしまう。このよ
うに、パケットを取りこぼすと、同じ手順をもう一度繰
り返す必要があり性能が低下し、かつ、不要な負荷を通
信回線にかけてしまう。

【００１９】従来方法のように、全サイトをグループに
分けグループ毎に異るタイミングで応答を待つか、また
は、全サイトを階層化しその階層構造に沿って応答を集
める方法が考えられる。しかし、これらの従来方法では
１つのパケットを単位として処理しており、１パケット
ごとに上記の確認応答収集方法を実行する必要がある。
上記の方法を1パケットずつ行なうと、複数パケットか
ら成るデータを高速に転送する場合は、確認応答収集に
時間がかかりすぎて問題である。

【００２０】さらに、従来方法のように再送処理を１サ
イト（パケット再送専用のサイト）のみで行うと、再送
処理の負荷が１箇所に集中し、問題である。

【００２１】さらに、階層構造を作成しその階層構造に
沿ってデータのブロードキャストおよび確認応答収集を
行う方法では、作成した階層構造が常に同じであると、
ネットワークアーキテクチャによっては効率的に動作し
ない場合があり、問題である。

【００２２】本発明の目的は、ブロードキャスト通信に
おける確認応答パケットの収集を改良することにある。
また、本発明の目的は、確認応答パケットの取りこぼし
の可能性を軽減し、複数のパケットからなるデータを効
率的に、かつ、確実にブロードキャストすることにあ
る。

【課題を解決するための手段】

【００２３】本発明では、プロセッサとローカルメモリ
からなる複数のサイトがネットワークで結合された計算
機システムにおいて、ある送信サイトが他の全てのサイ
トに複数パケットから成る同じデータを送る場合、送信
サイトは複数パケットを数パケットずつに分割してブロ
ックを構成し、各受信サイトからの確認応答を収集する
ために、送信サイトから成る階層を最上位階層とする階
層構造を作成し、作成した各ブロックに対して、階層構
造を含むデータの送信を行ない、その階層構造の各階層
について、その階層が最下位階層である場合は、その階
層中のサイトは、データ受信後、自サイトに対応する上
位階層中のサイトに、確認応答パケットを送り、階層が
最下位階層と送信サイトの中間である場合は、その階層
中のサイトは、確認応答パケットを受信したとき、下位
階層の全サイトからの確認応答パケットの到着と、自サ
イトへのデータ受信を確認してから、その上位階層中の
対応するサイトに確認応答パケットを送り、階層が最上
位階層である場合は、送信サイトは下位階層の全サイト
からの確認応答パケットを受信して、ブロードキャスト
通信を行なう。

【００２４】さらに、送信データパケットが喪失し、再
送処理が必要な場合が、送信サイト以外の複数のサイト
で発生した場合、そのサイトに対応する上位階層のサイ
トが異なるときは、並列に再送処理を行うことによって
ブロードキャスト通信を提供する。

【００２５】さらに、データ配付および確認応答用の階
層構造を計算機のネットワークアーキテクチャを考慮し
て作成し、ブロードキャスト通信を行なう。特に、送信
サイトからの送受信の遅れがより小さいサイトがより上
位になるように、階層構造を作成するとよい。

【００２６】さらに、各サイトがブロードキャスト機能
を有するネットワークで結合されている場合、送信サイ
トはブロードキャスト機能を用いて送信し、パケット到
達の確認は上述の方法を用いて、ブロードキャスト通信
を行なう。

【００２７】さらに、プロセッサとローカルメモリから
なる複数のサイトがネットワークで結合された計算機シ
ステムにおいて、ある送信サイトが他の全てのサイトに
複数のパケットから成る同じデータを送る場合、送信サ
イトは複数パケットを分割して数パケットずつのブロッ
クを構成し、各ブロックに対して全受信サイトから確認
応答を受けるために受信サイトをグループ化し、各グル
ープ中のサイトは、グループによって事なるタイミング
で送信サイトに確認応答パケットを応答することによ
り、データを分配し、ブロードキャスト通信を行なう。

【００２８】

【作用】本発明では、プロセッサとローカルメモリから
なる複数のサイトがネットワークで結合された計算機シ
ステムにおいて、ある送信サイトが他の全てのサイトに
複数パケットから成る同じデータを送る場合、送信サイ
トは、まず、全データを複数パケットから成るブロック
に分割する。次に、各ブロックに対して、各受信サイト
からの確認応答を収集するために、送信サイトをトップ
（最上位階層）とする階層構造を作成する。この階層構
造に基づいて、各ブロックごとに、以下の手順でブロー
ドキャスト通信を行なう。

【００２９】まず、作成した階層構造の各階層に対し
て、その階層が最下位階層である場合は、その階層中の
サイトは、１ブロックの全てのパケットの受信を確認し
た後、自サイトに対応する上位階層中のサイトに、確認
応答パケットを送る。その確認応答パケットを受信した
サイトが、送信サイトと最下位階層の中間階層に属する
場合は、下位階層の対応するサイト全てからの確認応答
パケットの到着と、自サイトへの１ブロックの全てのパ
ケットの受信を確認してから、上位階層中の対応するサ
イトに確認応答パケットを送る。これにより、中間階層
のサイトは自サイトの属する階層よりも下位の階層に存
在するすべてのサイトの受信と、自サイトの受信の確認
を、上位階層に伝達することができる。

【００３０】従って、すべての階層のトップの階層にあ
る送信サイトは、下位階層の全サイトからの確認応答パ
ケットを確認することができる。しかも、各階層で確認
する下位階層のサイト数は、全サイト数よりも少ないこ
とが、階層構造作成時に保証されているので、確認応答
パケットのぶつかりによる取りこぼしの可能性が軽減す
る。

【００３１】その上、複数パケットから成るデータに対
して、パケットをブロックに分割し、各ブロックに対し
てのみ確認応答の収集を行なうので、全体の処理に対す
る確認応答収集処理の割合を小さくでき、効率的な転送
が可能となる。

【００３２】さらに、送信データパケットが喪失し、再
送処理が必要な場合が、送信サイト以外の複数のサイト
で発生した場合、そのサイトに対応する上位階層のサイ
トが異なるときは、並列に再送処理を行う。この方法に
より、再送処理を１サイトで逐次的に行なう場合に比べ
て、高速な再送処理が可能となる。

【００３３】さらに、データ配付および確認応答用の階
層構造を計算機のネットワークアーキテクチャの構造を
考慮して作成し、送信サイトは階層構造にしたがってデ
ータを送信し、各中間階層のサイトは受信したデータ
を、自サイトに取り込むと共に次の階層へ転送する。こ
れにより、ネットワークの性質を利用した効率的なデー
タの配付および確認応答の収集が可能となり、全体とし
て高速な信頼性のあるブロードキャスト通信が可能とな
る。

【００３４】さらに、各サイトがブロードキャスト機能
を有するネットワークで結合されている場合、送信サイ
トはブロードキャスト機能を用いて送信し、確認応答
は、送信サイトで構成した階層構造に基づいて収集する
ことにより、ブロードキャスト用のハードウェア資源を
利用した効率的なブロードキャスト通信が可能となる。

【００３５】さらに、プロセッサとローカルメモリから
なる複数のサイトがネットワークで結合された計算機シ
ステムにおいて、ある送信サイトが他の全てのサイトに
複数のパケットから成る同じデータを大量に送る場合、
送信サイトは全データを数パケットから成るブロックへ
分割する。各ブロックに対して、全受信サイトから確認
応答を受けるために、受信サイトをグループ化し、各グ
ループによって異なるタイミングで送信サイトに確認応
答パケットを応答する。この方法により、受信の確認を
１サイトで行なった場合でも、確認応答パケットによる
ぶつかりの数を減らすことが可能となる。

【００３６】

【実施例】以下、本発明の１実施例を詳細に説明する。
ここでは、１つのサイトから他の全てのサイトへプログ
ラムをロードする場合を例にとり説明する。

【００３７】［プログラムのロードの実施例］図１は、
ネットワークトポロジーがメッシュ型で、かつ、軸方向
へのマルチキャスト機能を備えた並列計算機に、本発明
を適用してプログラムをロードする場合の構成図であ
る。図１では、注目するサイトのみをあげてあるが、実
際にはメッシュの各格子点上に各サイトが結合されてい
る。

【００３８】外部記憶装置３に格納されているプログラ
ムが、サイト１からほかの全てのサイトに、ブロードキ
ャストされロードされる。サイト１は、通信線２０を介
してサイト５０〜５３，２と接続している。これがＸ軸
方向の接続である。さらに、サイト１は、通信線２３を
介してサイト５９〜６３に接続している。これがＹ軸方
向の接続である。サイト２は、Ｙ軸方向の接続として、
通信線２１を介してサイト５４〜５８と接続している。

【００３９】各サイトには、Ｘ軸およびＹ軸方向へのブ
ロードキャスト通信ハードウェアが備えられている。１
１はサイト１のＸ軸方向のブロードキャスト通信ハード
ウェア、１２はサイト１のＹ軸方向のブロードキャスト
通信ハードウェア、１３はサイト２のＹ軸方向のブロー
ドキャスト通信ハードウェアである。

【００４０】例えば、サイト１においては、ブロードキ
ャスト通信ハードウェア１１によりＸ軸方向の全てのサ
イトへ一度にデータを転送することが可能である。ま
た、同ハードウェア１２により、Ｙ軸方向へのブロード
キャスト通信が可能である。但し、ブロードキャスト通
信ハードウェアは、同一軸上のサイトへデータを配付す
るだけで、ほかの軸上のサイトへの通信は行なわない。

【００４１】サイト１からブロードキャスト通信を行な
う場合、サイト１では送信ソフトウェア５が動作し、サ
イト５０〜５３，２では中継ソフトウェア（例えば、サ
イト２の中継ソフトウェア９）が動作し、中継ソフトウ
ェアが動作するサイトにＹ軸を介して接続するサイト
（例えば、サイト５４〜５８）では、受信ソフトウェア
（サイト５８の受信ソフトウェア１０）が動作する。ど
このサイトでどのソフトウェアが動作するかは、構成し
た階層構造に依存する。詳細は、構造定義情報の配付方
法で述べる。

【００４２】まず図１〜図４を用いて、図１の並列計算
機においてプログラムをブロードキャストして各サイト
にロードする場合の全体のおおまかな流れを説明する。
サイト１がプログラムの配付サイトで、その他のサイト
が受信サイトである。サイト１は、外部記憶装置３から
ロードするプログラムを自サイト１に読み込む。

【００４３】次に、送信ソフトウェア５のブロック構成
１１８により、読み込んだ全データをブロックに分割す
る処理を行なう。ブロックとは、送信するデータの単位
である。送信したデータは、確認応答が送られてくるま
では再送用に保持しておく必要があるが、ブロックはそ
の保持の単位である。この例では、プログラムをロード
するが、プログラムの全データ量は決まっており、か
つ、全データをメモリ上に保持することが可能であるか
ら、全データを１ブロックとする。

【００４４】次に、構造定義部１００により、サイト１
を最上位階層とする階層構造を作成する。この階層構造
に沿って、サイト１から他のサイトへとデータを配付
し、確認応答パケットを収集する。

【００４５】図２に、その階層構造を示す。階層構造は
木構造で、木構造の最上位階層のノード４５０は、送信
サイトであるサイト１に対応する。第２階層のノード４
５１〜４５４は、軸２０上のサイトに対応する。第３階
層のノード４５５〜４５８は、軸２１上のサイト（５４
〜５８）に対応する。説明の都合で、ノード４５３が図
１のサイト２に、ノード４５７が図１のサイト５８に、
それぞれ対応することとする。この様に、ある軸上のサ
イトをあるノードの子ノードとして構成することによ
り、あるノードからその子ノードへのブロードキャスト
を、ハードウェア装置を用いて高速に行なうことが可能
となる。

【００４６】図２は、階層構造と共に、送信時の各階層
中のサイトにおけるソフトウェアの動作とデータの流れ
をも示している。特に、図２では、図１に図示した送信
ソフトウェア５、中継ソフトウェア９、および受信ソフ
トウェア１０の各部のうち、ノード４５０（サイト１）
からデータを送信する際に着目すべき部分（図１の送信
ソフトウェア５のパケット送信部６、中継ソフトウェア
９のパケット受信部１６とパケット送信部１７、および
受信ソフトウェア１０のパケット受信部１９）を取り出
して図示している。

【００４７】データの送信時の処理の流れを説明する。
ノード４５０（以下、各サイトをノード４５０のように
対応する木構造のノードで言及する）の送信ソフトウェ
ア５は、階層構造定義を行なったあと、パケット送信部
６で子ノード４５１〜４５４へのデータ配付を行なう。
このデータ配布は、１ブロック中の全データの送信完了
まで、軸方向のマルチキャストハードウェア（図１の１
１）を用いて、行なわれる。

【００４８】ノード４５０の送信ソフトウェア５からデ
ータを受けたノード４５３の中継ソフトウェア９は、パ
ケット受信部１６で、受信パケット管理表（図１の１
４）中の、入力パケットに対応するエントリにそのパケ
ットの受信を記録する。受信パケット管理表１４の詳細
は、後に説明する。ノード４５３の中継ソフトウェア９
は、ローカルメモリ上に受信パケットをストアした後、
図２の木構造に従って、パケット送信部１７でＹ軸方向
のマルチキャストを行い、受信したパケットの中継を行
なう。

【００４９】中継されたパケットを受信したノード４５
７の受信ソフトウェア１０は、受け取ったパケットをロ
ーカルメモリ上にストアした後、ノード４５３と同じよ
うに、受信パケット管理表（図１の２２）中の対応する
項目に、パケットの受信を記録する。

【００５０】上述のようにして、単一送信サイトから各
受信サイトへ、１ブロック分のデータの送信が続く。１
ブロック分の全パケットの送信が終了すると、全ノード
は確認応答の受信処理に入る。

【００５１】図３は、全体の確認応答受信時のソフトウ
ェアの動作とデータの流れを示す。特に、図３では、図
１に図示した送信ソフトウェア５、中継ソフトウェア
９、および受信ソフトウェア１０の各部のうち、確認応
答の受信処理の際に着目すべき部分（図１の送信ソフト
ウェア５の応答受信部７、中継ソフトウェア９の応答受
信部２５、および受信ソフトウェア１０の再送要求部２
４）を取り出して図示している。さらに、図３では、図
１の中継ソフトウェア９では省略した再送要求部１４０
を図示している。

【００５２】確認応答の受信処理時の処理の流れを説明
する。１ブロック中の最終パケットを受信したノード４
５７の受信ソフトウェ１０は、再送要求部２４におい
て、受信パケット管理表２２を調べ、全てのパケットが
受信できていれば、肯定の確認応答（ＡＣＫ）を、親ノ
ード４５３の中継ソフトウェア９に送る。受信できてい
ないパケットを発見した場合は、親ノード４５３の受信
ソフトウェア９へ、そのパケットの再送要求を送る。

【００５３】中継ソフトウェア９は子ノードからの確認
応答を応答受信部２５で待つと共に、再送要求部１４０
により自ノードの再送要求処理を行なう。再送要求部１
４０の再送要求処理は、基本的に、子ノード４５７の再
送要求部２４の処理と同じである。但し、ＡＣＫを返す
条件が異る。中継ソフトウェア９は、当該ソフトウェア
が動作するノードに全パケットが到着し、かつ全ての子
ノードからＡＣＫを受信したときに、親ノードであるノ
ード４５０の送信ソフトウェア５にＡＣＫを応答する。
これにより、ノード４５３以下のノードでの１ブロック
分のデータ到達を確認することができる。

【００５４】子ノードから確認応答パケットを受けたノ
ード４５３の中継ソフトウェア９は、応答受信部２５で
確認応答パケットを調べる。ＡＣＫを受け取った場合
は、確認応答表（図１の１５）にＡＣＫ受理を記す。確
認応答表の詳細は、後に説明する。前記の条件を満たし
ていれば、ノード４５０に自サイトのＡＣＫを応答し、
ノード４５３における１ブロック分のプログラムのロー
ドは終了する。子ノードから再送要求を受けた場合は、
再送処理に入る。

【００５５】ノード４５０の送信ソフトウェア５は、全
てのパケットを送り終わった後に、応答受信部７で、子
ノードからの確認応答を待つ。確認応答が再送要求であ
れば、再送処理に入る。確認応答がＡＣＫであれば、対
応する確認応答表８にＡＣＫを受け取ったことを記録す
る。全ての子ノードからＡＣＫを受け取ったことを確認
したら、ノード４５０のサイト１は１ブロック分のプロ
グラムのロードを終了する。

【００５６】図４は、再送処理時のソフトウェアの動作
とデータの流れを示す図である。この図では、ノード４
５３の中継ソフトウェア９が再送処理を行なっている。
特に、図４では、図１に図示した送信ソフトウェア５、
中継ソフトウェア９、および受信ソフトウェア１０の各
部のうち、再送処理の際に着目すべき部分（図１の送信
ソフトウェア５の再送部１８、および受信ソフトウェア
１０の再送要求部２４）を取り出して図示している。さ
らに、図４では、図１の中継ソフトウェア９では省略し
た再送要求部１４０と再送部１５１を図示している。

【００５７】再送処理時の処理の流れを説明する。ノー
ド４５６から再送要求を受けた場合、ノード４５３の中
継ソフトウェア９は、要求されたデータをノード４５６
の受信ソフトウェア１０に送り返す（矢印４５９）。

【００５８】また、ノード４５３がノード４５７から再
送要求を受けた場合に、ノード４５７が要求した再送デ
ータが、ノード４５３にも未到着で、再送要求の対象と
なっていることがある。この場合、ノード４５３の中継
ソフトウェア９は、再送要求部１４０により、直ちに、
該当する再送要求をノード４５０に対して行なう（矢印
４６０）。ノード４５０から再送データが返答された
（矢印４６１）後に、ノード４５３の再送部１５１で、
ノード４５７へ、再送データを返答する（矢印４６
２）。

【００５９】再送データを受けとった中継ソフトウェア
９、および受信ソフトウェア１０は、親ノードのソフト
ウェアに、再送データが全て正しく届いた場合は、ＡＣ
Ｋを応答する。

【００６０】全てのノードで再送処理が終了して、１ブ
ロックの再送処理が終わる。

【００６１】図５（ａ）は、本実施例においてプログラ
ム配付を行なう際に用いる木構造を示す。図５（ａ）の
各ノードの番号は、図１の各サイトに付した番号に等し
い。本実施例では、この図のように、送信サイト１をル
ートとする木構造を各サイト間に対応させ、この木構造
に基づいてプログラムの配付を行う。

【００６２】木構造は、図１の構造定義部１００で作成
するが、その際、プログラムの配付と確認応答の収集が
その木構造に沿って効率的に行なえるように構成する。
本実施例では、送信ノードであるサイト１の子ノードと
して、サイト１からマルチキャスト可能なサイト５０〜
５３，２，５９を選ぶ。これにより、ルートノードから
子ノードへの送信処理を２回の通信（マルチキャスト通
信１回と、サイト５９への送信１回）で行なうことが可
能となる。サイト１の子ノードとしてサイト５９が必要
な理由は、後に構造定義の説明で述べる。同様に、サイ
ト１の孫ノードに関しても、マルチキャスト通信が有効
に利用できるように、木構造を構成する。例えば、サイ
ト２の子ノードには、図１の軸２１上のサイト５４〜５
８を対応させ、サイト２から子ノードへデータを配付す
る場合、軸方向のブロードキャストハードウェア１３が
利用できるようにする。

【００６３】図５（ｂ）は、確認応答の収集の様子を示
す。構造定義部１００で木構造を作成するに際しては、
確認応答を効率的に集めるために、子ノードの数を、親
ノードによる確認応答の取りこぼしが生じない程度に抑
えるようにする。また、子ノードと親ノードとの通信が
直接通信可能となるように、木構造を構成する。直接通
信可能とは、２点間の通信で、途中に他のノードやルー
ティング用の回路を経ずに通信できることを意味する。
例えば、図１において、サイト１からサイト５６へ通信
を行なう場合は、データが軸２０から軸２１と他の軸へ
移るために、パケットは、ルーティング用の回路を最低
１つ通過する必要がある。従って、この２サイト間の通
信は直接通信可能ではない。

【００６４】このような木構造に従ってデータを配付し
確認応答を収集するので、ルートとリーフ以外のノード
の動作は同じである。そこで、ノードを、ルートノー
ド、リーフノード、およびそれ以外のノード（中間ノー
ド）の３種類に分け、おのおのの場合について、各サイ
ト上でどのように処理が行われるかを詳細に説明する。

【００６５】図６は、ルートノードであるサイト１の動
作を示す。なお、以降の説明では、１ブロックの転送に
ついてのみ説明する。複数のブロックから成るデータの
場合は、以降で説明する処理を、分割したブロックの個
数分、繰り返せばよい。

【００６６】図６を参照して、送信元であるサイト１
は、構造定義部１００で、まず木構造を実際のアーキテ
クチャにどのようにマッピングするかを決定する。図１
のアーキテクチャでは、各軸方向にマルチキャスト通信
機能があるので、上述した図５のようにマッピングを行
う。これにより、各階層でプログラムを子ノードに配付
するのにマルチキャスト通信機能を用いることができ、
高速なプログラム配付が可能となる。構造定義について
は、後に例を挙げて詳述する。

【００６７】次に、外部記憶装置３からロードするプロ
グラムを読みだし（１０１）、全パケット量を算出する
（１０２）。プログラムの場合は、全データ量が既知で
あるため、全パケット量を計算することが可能である。
次に、全パケット量を基にブロックを構成する（１１
８）。本実施例では全データを１ブロックとする。この
１ブロックに対して、確認応答表８を作成し初期化する
（１０３）。

【００６８】図１０（ａ）は、確認応答表の１つのエン
トリ２００を示す。確認応答表は、このようなエントリ
２００を要素とする配列であり、１ブロックのデータ送
信後に、子ノードからの確認応答の受理を記録するため
の表である。この表は、リーフノード以外の全てのノー
ドが保持する。配列の大きさは、定義した木構造におい
て、この表を保持するノードの子ノードの数である。各
エントリ２００は、この表を保持するサイトの子ノード
となるサイトのサイト番号と、ＡＣＫ（確認応答の肯定
応答）受理フラグとからなる。ＡＣＫ受理フラグは、そ
のエントリに対応する子ノードからのＡＣＫを受信した
かどうかを示すフラグである。

【００６９】始めはＡＣＫは受け取っていないので、確
認応答表のエントリ２００のＡＣＫ受理フラグは、全て
ＡＣＫ未受理に初期化する。図１０（ｂ）および図１０
（ｃ）は、それぞれ、サイト１およびサイト２における
確認応答表を示した図である。図１０（ｃ）は、サイト
２が全ての子ノードに対応するサイトからＡＣＫを受信
し、親ノードにあたるサイト１へ自ノードのＡＣＫを応
答した後の状態である。サイト１ではサイト２からのＡ
ＣＫを受信したので、図１０（ｂ）のように、対応する
エントリ２０３をＡＣＫ受理と設定している。

【００７０】再び図６を参照して、確認応答表の作成と
初期化（１０３）の後、パケット作成部４の処理を行な
う。パケット作成部４では、ロードデータを１つ１つの
パケットに分解してデータを配付する。

【００７１】図１２（ａ）に、送信パケットの構造を示
す。この図のように、送信パケットは、構造定義情報４
４０、シーケンス番号４４１、ＩＤ４４２、ブロック長
４４３、フラグ４４４、およびデータ４４５からなる。
構造定義情報４４０は、構造定義部１００により決定さ
れた構造定義情報（図５のような木構造を示す情報）で
ある。シーケンス番号４４１は、１パケット送出毎に付
加され、インクリメントされる値で、ある通信処理に関
与する複数パケットの順序と識別を表す。ＩＤ４４２
は、通信処理を識別する識別子である。ＩＤ４４２によ
り、本発明のプロトコルを用いる複数のブロードキャス
ト通信を、同時に支援することが可能となる。ブロック
長４４３は、送信するブロックの長さ（全パケットの数
で表す）である。フラグ４４４は、送信パケットがデー
タの終了か、または、確認応答の要求かどうかを示す。
データ４４５は、実際に配付するデータである。

【００７２】図６において、パケット作成部４では、始
めに、図１２（ａ）のパケットの構造定義情報４４０の
領域に構造定義部１００で決定した構造定義情報を格納
する（１０４）。次に、パケットの順番を示すシーケン
ス番号を、図１２（ａ）のパケットのシーケンス番号フ
ィールド４４１に格納する。また、ステップ１０２で計
算した全パケット量をブロック長フィールド４４３に格
納する（１０６）。次に、このパケットが最終パケット
かどうかを、全パケット量と現在までに送信したパケッ
トの量から判断する（１０７）。その判断結果をパケッ
トのフラグフィールド４４４に設定する（１０８，１０
９）。以上で、送信すべき１パケットの準備が整う。

【００７３】次に、パケット送信部６でパケットを転送
する。本実施例の計算機では、軸方向のマルチキャスト
ハードウェアがあるので、それを利用して、サイト１は
子ノードに対応するサイト５０〜５３，２，５９にデー
タを送信する（１１０）。そして、送信したパケットが
１ブロック内の最終パケットかどうかを判断する（１１
１）。最終パケットでない場合は、パケット作成部４か
らの処理を繰り返し、次のパケットを作成して送信す
る。ステップ１１１で最終パケットである場合は、処理
は応答受信部７へ進む。

【００７４】応答受信部７では、子ノードからの確認応
答を受け、全ての子ノードからＡＣＫを受理したときに
処理を終了する。

【００７５】図１２（ｂ）に、確認応答パケットの構造
を示す。この図のように、確認応答パケットは、構造定
義情報４４０、シーケンス番号４４１、ＩＤ４４２、ブ
ロック長４４３、フラグ４４６、および再送要求パケッ
ト番号４４７からなる。構造定義情報４４０、シーケン
ス番号４４１、ＩＤ４４２、およびブロック長４４３の
各フィールドは、図１２（ａ）の送信パケットの対応す
るフィールドと同じ意味である。フラグ４４６は、この
パケットがＡＣＫか再送要求かを示すフラグである。再
送要求パケット番号４４７は、再送要求のときにのみ意
味をもち、再送要求が必要なパケットのシーケンス番号
が入る。

【００７６】図６の応答受信部７では、まず、確認応答
の受信待ちに入る（１１２）。受信タイムアウトの場合
（１１３）は、最終パケットが届いていないと考えられ
るから、再送部１８に進む。再送部１８では、確認応答
表（図１０）を調べて、ＡＣＫを受理していない子ノー
ドに対して最終パケットを再送する（１１６）。

【００７７】パケットを受信した場合は、そのパケット
が子ノードからのＡＣＫかどうかを調べる（１１４）。
子ノードからのＡＣＫである場合は、確認応答表（図１
０）を検索して、対応する子ノードのエントリを探し出
し、そこのＡＣＫ受理フラグをＡＣＫ受理にする（１１
５）。次に、確認応答表で、全ての子ノードからＡＣＫ
を受理したかどうかを調べ（１１７）、全ての子ノード
からのＡＣＫ受理であれば、サイト１は通信を終了し、
ロードプログラムの実行に移る。そうでない場合は、再
びステップ１１２で確認応答の受信を行う。ステップ１
１４で調べたパケットが再送要求である場合は、そのパ
ケットの再送要求パケット番号４４７（図１２（ｂ））
のフィールドを参照し、そこに指定されたシーケンス番
号のパケットを再送する（１１６）。

【００７８】以上が、送信ノードであるサイト１の動作
である。

【００７９】図７は、中間ノード（図１のサイト５０〜
５３，２，５９）の動作を示す。以下の説明では、代表
として、サイト２を例に取り説明する。

【００８０】サイト２は、始めにパケット受信部１６の
処理を行なう。パケット受信部１６では、まず、ロード
するプログラムデータのパケットの到着を待つ（１３
０）。タイムアウト（１３１）の場合は、受信パケット
管理表を調べ、再送する必要のあるパケットを選び（１
３２）、その再送要求を親ノードであるサイト１に送る
（１３４）。その後、再び受信処理１３０へ戻る。パケ
ットが到着した場合は、受信パケット管理表を検索し
（１３３）、そのパケットが既に受信されていたら（１
３５）、再び受信処理１３０へ戻る。始めて受信するパ
ケットであるならば、受信パケット管理表にそのパケッ
トの受信を記録し（１３６）、データをサイト２のロー
カルメモリ上にコピーする（１３７）。

【００８１】図１１は、受信パケット管理表の構造を示
す。受信パケット管理表は、データの受信最中にどこま
でデータを受信したかを記録するデータ構造である。そ
の構造は、図１１の２３０に示すように、シーケンス番
号と受信完了フラグの対をエントリとする表である。１
ブロック中の最初のパケットを受信したときに、そのパ
ケット中のブロック長４４３の長さ分のエントリを作成
し、各エントリの受信完了フラグを未完に初期化する。
受信完了フラグは、完了と未完の２つの値を取り、完了
は、そのシーケンス番号が示すパケットを受信したこと
を示し、未完は、未受信であることを示す。

【００８２】図７のステップ１３６の処理は、受信パケ
ットのパケットヘッダのシーケンス番号４４１と同じ番
号のエントリを受信パケット管理表から探索し、そのエ
ントリの受信完了フラグを完了に変える処理である。サ
イト２では、この処理を、パケットを受け取る度に行な
う。

【００８３】図７のパケット受信部１６の処理の後、パ
ケット送信部１７の処理を行なう。パケット送信部１７
では、サイト２の子ノード（サイト５４〜５８）へパケ
ットを配付する。サイト１における構造定義の際に、図
５のように、子ノードが同じ軸上にあるように階層構造
を作ったので、サイト２が子ノードにパケットを配付す
るときにも軸方向マルチキャスト機能が使用できる。そ
こで、サイト２は、軸方向マルチキャスト機能を用い
て、パケットを子ノードへ配付する（１３８）。次に、
送ったパケットが１ブロック中の最終パケットかどうか
を判断し（１３９）、最終パケットでなければ受信処理
１３０に戻る。最終パケットである場合は、再送要求部
１４０の処理に進む。

【００８４】図８に、再送要求部１４０の処理を示す。
再送要求部１４０では、まず、受信パケット管理表（図
１１）をチェックし（１８０）、取りこぼしたパケット
があるかどうか、すなわち再送が必要かどうかを判断す
る（１８１）。この判断は、受信パケット管理表の中
で、受信完了フラグが未完となっているエントリを全て
探し出すことにより行なう。そのエントリの存在は、パ
ケットの取りこぼしがあったことを意味し、再送要求を
する必要がある。例えば、受信パケット管理表が図１１
に例示した内容である場合は、シーケンス番号１〜９
６，９８が全て完了であり、他は未完であるから、再送
が必要なパケットのシーケンス番号は、９７，９９，１
００である。

【００８５】取りこぼしたパケットがある場合は、再送
要求を親ノードであるサイト１へ送り（１８３）、再送
データを待つために、応答受信部２５へ進む。再送が必
要でない、即ち、全てのパケットの受信を確認したら、
直ちに応答受信部２５へ進む。

【００８６】再び図７を参照して、応答受信部２５の処
理を説明する。応答受信部２５では、まず３種類のパケ
ットを待つ（１４１）。即ち、子ノードからのＡＣＫ、
親ノードからの再送パケット、または子ノードからの再
送要求パケットである。

【００８７】ステップ１４１でいずれのパケットも受け
取れずタイムアウトになった場合は（１４２）、最終パ
ケットを子ノード（サイト５４〜５８の中で、まだＡＣ
Ｋを受理していないサイト）に再送し（１４４）、ＡＣ
Ｋの送信を促す。そして、１ブロックの全てのパケット
の受信が完了しているかどうかを判断し（１５４）、完
了していたら受信処理１４１に戻り、完了していなかっ
たら再送要求部１４０に戻って再送要求する。

【００８８】受信処理１４１でパケットを受信した場合
は、そのパケットがＡＣＫであるかどうかを判断する
（１４３）。ＡＣＫであった場合は、確認応答表（図１
０）の該当するエントリにＡＣＫ受理を記録する（１４
６）。次に、確認応答表を調べ、子ノード全て（サイト
５４〜５８）からＡＣＫを受理しているかどうか判断す
る（１４７）。子ノード全てからＡＣＫを受理している
場合は、親ノード（サイト１）にＡＣＫを応答し（１４
８）、処理を終える（１４９）。ステップ１４７で未だ
ＡＣＫを受理していない子ノードが存在する場合は、ス
テップ１５４に戻る。

【００８９】受信処理１４１で受信したパケットがＡＣ
Ｋでないとき（１４３）は、そのパケットが親ノード
（サイト１）から再送された再送パケットであるかどう
かを判断する（１４５）。再送パケットである場合は、
そのパケットについてステップ１３５〜１３７と同様の
処理を行ない（図７では不図示）、ステップ１５４に戻
る。受信したパケットが再送パケットでない場合は、そ
のパケットが子ノードからの再送要求パケットであるか
どうか判断する（１５０）。子ノードからの再送要求パ
ケットであれば、再送部１５１で、要求されたパケット
を１対１の通信を用いて再送する（１５２）。その後、
ステップ１５４に戻る。受信したパケットが子ノードか
らの再送要求パケットでないときは、３種類のいずれの
パケットでもないということであるから、そのパケット
を捨てる（１５３）。

【００９０】以上が、中間ノードの動作である。

【００９１】最後に、図９を用いてリーフノードにおけ
る処理について説明する。

【００９２】始めに、パケット受信部１９でパケットを
受信する。パケット受信部１９の動作は、図７で説明し
た中間ノードのパケット受信部１６と同じであるので、
説明は省略する。

【００９３】パケット受信部１９によりパケットを受信
した後、その受信したパケットが１ブロック中の最終パ
ケットであるかどうかをチェックする（１７０）。受信
パケットが最終パケットでなければ、パケット受信部１
９に戻り、パケットの受信を続ける。受信パケットが最
終パケットである場合は、再送要求部２４の処理に入
る。

【００９４】再送要求部２４では、まず受信パケット管
理表２２をチェックし（１７１）、取りこぼしたパケッ
トがあるかどうか、すなわち再送が必要かどうかを判断
する（１７２）。取りこぼしたパケットが存在する場合
は、再送要求を行い（１７５）、パケット受信部１９の
処理により、要求したパケットを受理する。その後、再
び受信パケット管理表のチェック（１７１）からの処理
を行なう。全てのパケットの受理を確認した場合は（１
７２）、親ノードにＡＣＫを応答し（１７３）、処理を
終わる（１７４）。

【００９５】以上で、図５のような木構造に沿ってデー
タを配付し確認応答を収集する場合の、ルートノード、
中間ノード、およびリーフノードのおのおのについて、
各サイトでの処理を説明した。

【００９６】（構造定義）次に、図１および図６に示し
た構造定義部１００について詳しく説明する。構造定義
部１００では、ブロードキャスト通信を用いてデータ配
付とＡＣＫ（確認応答）収集とを高速に行なうために、
ネットワークの物理的な性質を考慮して、木構造へ各サ
イトをマッピングする。ここでは、代表的なネットワー
クトポロジーについて構造定義方法を述べる。

【００９７】基本方針は、階層的にデータを配り、階層
的に確認応答を集めることである。従って、送信サイト
から近い順番に階層化することが好ましい。ここで、近
いということは、送信受信の遅れが小さいということで
ある。例えば、送信サイトと受信サイトとの間にルータ
が介在する場合は、ルータの存在の分だけ遅れが生じ
る。従って、ある送信サイトから最も近いサイトとは、
送信サイトとの間のルータの数が最も少い経路で通信可
能なサイトである。

【００９８】この様な方針に基づいた木構造の定義方法
を、具体的なネットワークについて説明する。

【００９９】（メッシュ）図１３（ｂ）は、２次元のメ
ッシュの構造を示す。各軸方向には有限個のサイトが接
続されている。ブロードキャストを行うサイト１は、自
サイトが属する軸のどれかを選び、それを木構造の始め
のレベルとする。木構造のレベルとは、ルートノードか
ら等しい距離にあるノードの集合である。ルートノード
はレベル０に属する。サイトが属する軸とは、そのサイ
トと接続されている軸である。図１３（ｂ）の場合、サ
イト１が属する軸は、軸Ａ（２７３）と軸Ｃ（２７５）
である。この場合、サイト１は、軸Ａを木構造の始めの
レベルに選び、図１３（ａ）の様にマッピングする。

【０１００】次に、軸Ａ上のサイト１以外のサイト（例
えばサイト２）について、軸Ａとは異なる次元の軸（サ
イト２については、軸Ｂ（２７４））上の当該サイト以
外のサイトを当該サイトの子ノードとなるようにマッピ
ングする。即ち、サイト２の子ノードが軸Ｂのサイト６
〜９となるようにマッピングする。メッシュの場合、軸
方向を基にしてマッピングを行なうのは、同じ軸上にあ
るサイト間の通信は、最も低い遅延時間で行なうことが
可能であるからである。

【０１０１】サイト１の軸Ｃ方向のサイト（図１３の２
５２〜２５５）については、上述のようにマッピングを
行った場合、マッピングされない。そこで、図１３
（ａ）のように、サイト１の子ノードとしてＣ軸方向の
サイト１以外のサイトのマッピングを行う。あるいは、
図５（ａ）のように、軸Ｃ上のサイト１以外のサイトを
２階層に分けるマッピングも可能である。

【０１０２】図１３（ａ）の木構造において、送信サイ
ト（サイト１）の１階層下には８つのノードが存在する
（軸Ｃにはサイト１以外に４サイト接続されている）か
ら、送信サイト（サイト１）における確認応答待ち数は
８になる。一方、他の中間ノードにマップされたサイト
（サイト２〜５）の確認応答待ち数は４である。したが
って、送信サイト（サイト１）の確認応答待ち数が、中
間ノードのサイトの確認応答待ち数に比べて、多い。し
かし、軸Ｃ上のサイトはリーフノードとしてマッピング
されるので、サイト１の他の子ノードやサイト２〜５に
比べて、時間的に早く確認応答を返すことが可能でな
る。従って、同時にぶつかる確認応答の数が増えるわけ
ではない。

【０１０３】（トーラス）図１３（ｃ）は、２次元のト
ーラス構造を示す。トーラスは、リングの直積で、メッ
シュの各軸がリングになったと見做せる。従って、基本
的な構造定義の方法はメッシュのときと同じである。ま
ず、ブロードキャストするサイト１は、サイト１が属す
るリングからリングＡ（２７６）を選び、そのリング上
のサイト１以外のサイト（２５８〜２６１）をサイト１
の子ノードとする。次に、サイト１の子ノードであるサ
イト２については、サイト２が属するリングでリングＡ
と異なるリングＢ（２７７）を選び、そのリング上のサ
イト２以外のサイト（サイト６〜９）をサイト２の子ノ
ードと定める。サイト１の他の子ノードについても同様
である。

【０１０４】（ファットツリー）図１３（ｄ）は、ファ
ットツリーの構造を示す。ファットツリーは、この図の
ように、クラスタ分けした各サイト間と、各クラスタ間
をツリー状に接続したトポロジーである。まず、ブロー
ドキャストを行うサイト１が属するクラスタ（２８０）
と同等な各クラスタ（２７９，２８１）を代表するサイ
ト（例えばサイト２）を選び、これをサイト１の子ノー
ドとする。次に、各代表サイトについて、そのサイトが
属するクラスタ中の他のサイトを代表サイトの子ノード
とする。例えば、クラスタ２７９ならば、代表サイトで
あるサイト２の子ノードを、サイト６〜９とする。

【０１０５】（ハイパーキューブ）ハイパーキューブの
構造を持つネットワークにおけるブロードキャスト通信
は、通常、ＧＨＣ（Ｇｅｎｅｒａｌｉｚｅｄ ｈｙｐｅ
ｒｃｕｂｅ）用のブロードキャストアルゴリズムを用い
て、木構造に基づいて行われる。このアルゴリズムを、
図１４（ａ）の３次元ハイパーキューブ上で、サイト０
００からのブロードキャストに適用すると、木構造は図
１４（ｂ）のようになる。

【０１０６】別な木構造として、図１４（ｃ）を考えた
場合、この方が、信頼性のあるブロードキャストを高速
に行うことができる。なぜならば、図１４（ｂ）では、
ノード３１１は次のレベルにパケットを配送するのに２
回送信を行う必要があるのに対し、図１４（ｃ）では、
レベル２の各ノード３１７〜３１９は１回の送信のみで
よいからである。同じレベルの各ノードは並列に動作す
ることが可能であるので、レベル２の処理（サイト００
１，０１０，１００の送信処理）が終了するために、図
１４（ｂ）の木構造の場合は送信２回分の時間が必要で
あるのに対し、図１４（ｃ）の方法では送信１回分の時
間ですむ。

【０１０７】さらに、本発明を適応してＡＣＫを集める
場合、図１４（ｂ）の木構造の場合は、２つのノードか
らＡＣＫを集めるノード３１１がこのレベルのＡＣＫ収
集速度の律速段階となる。本発明の方法において、最終
的にルートノードがＡＣＫを集め終わる時間は、各レベ
ルで並列にＡＣＫ収集を行なうことができることを考慮
すると、基本的に木構造の高さ（レベル数）に依存す
る。仮に、ＡＣＫを集めるのに必要な時間をＴとする
と、図１４（ｃ）の場合は、Ｔ×（木の高さ）＝３Ｔと
なる。ところが、図１４（ｂ）のように、途中のノード
で複数のＡＣＫを待つ場合は、そのレベルのＡＣＫ収集
に要する時間はＴよりも大きい。１つのノードで待つＡ
ＣＫ数（即ち、そのノードの子ノードの数）がｋ（ｋ≧
２）のとき、その時間的な増分をＴ（ｋ）とすると、図
１４（ｂ）の場合は、３Ｔ＋Ｔ（２）の時間がかかる。

【０１０８】従って、図１４（ｃ）のように、なるべく
木がバランスするように木構造を決定することが望まし
い。

【０１０９】次に、図１４（ｃ）のようになるべくバラ
ンスするように木構造を作るアルゴリズムについて説明
する。

【０１１０】図１７は、上述のアルゴリズムを説明する
ためのフローチャートである。図１５は、４次元ハイパ
ーキューブに当該アルゴリズムを適用した場合におい
て、アルゴリズム中で使用するデータ構造を示す。図１
６は、４次元ハイパーキューブに当該アルゴリズムを適
用した結果、作成される木構造を示す。

【０１１１】図１５は、送信サイトの番号を００００
（２進数）と仮定したときの、送信サイトからのハミン
グ距離毎に全てのサイトを分類した表である。ハミング
距離とは、２つのサイト番号で決まる量で、各々のサイ
ト番号を２進数で表した場合、その２つの２進数間で異
なるビットの数である。例えば、サイト０１００とサイ
ト１０１０のハミング距離は３である。

【０１１２】図１５において、列３４０は送信サイトか
らのハミング距離を表し、列３４１は列３４０で示され
るハミング距離にあるサイトの集合の要素を示す。例え
ば、３４４はサイト００００からのハミング距離が２で
あるサイトの集合を表す。

【０１１３】図１６は、このアルゴリズムによって生成
される木構造である。３６３〜３６６は、同じレベルの
ノードを結ぶリンクを表す。このリンクをレベルリンク
と呼ぶ。

【０１１４】以下、図１５〜１７を用いて、一般的にア
ルゴリズムの説明をした後で、４次元のハイパーキュー
ブについて具体的な説明を行う。

【０１１５】図１７において、始めに、送信サイトから
のハミング距離により全サイトを分類し、図１５のテー
ブルを作成する（３７０）。次に、送信サイトを木構造
のルートノードと定める（３７１）。また、レベル０の
レベルリンク、即ち、送信サイトからなるレベルリンク
を作成する（３７２）。そして、処理するレベル数を特
定する変数ｋに初期値として１を代入する（３７３）。
レベルｋ−１のノードの子ノードをレベルｋのノードか
ら選ぶ処理を行なうことになる。

【０１１６】次に、現処理中のレベル（レベルｋ−１）
のノードがバランス状態（図１４で説明した木がバラン
スした状態）で取りうる子ノードの最大数を求めるた
め、ハミング距離ｋのサイト数を現レベルのレベルリン
クの長さ（現レベルのレベルリンク中にあるノードの
数）で割り、答えをｎに代入する（３７４）。除算時に
余りがあった場合は、ｎを１つインクリメントする（３
８３）。

【０１１７】バランスをなるべく保つために、現処理中
のレベルｋ−１が偶数か奇数かを判断し（３７５）、こ
れに基づいてレベルリンクのアクセス方向を決める。奇
数の場合は、レベルリンクを左からアクセスし（３７
６）、偶数の場合は右からアクセスする（３７７）。

【０１１８】次に、レベルリンクのアクセスする方向の
先頭からノードを一つ選び、選んだノードの表すサイト
からハミング距離１のサイトを、図１５のテーブルでル
ートからのハミング距離３４０がｋであるエントリ３４
１から、最大ｎ個選ぶ。選び終わったら、そのサイトを
テーブルから削除する。選んだサイトを親ノードの子ノ
ードとする（３７８）。

【０１１９】次に、レベルｋ−１のレベルリンクのノー
ドを全てアクセスしたかどうか検査し（３７９）、全て
アクセスしていなかったら、ステップ３７５から処理を
繰り返す。全てアクセスし終わった場合は、次のレベル
に処理を進めるため、ｋを１つインクリメントする（３
８０）。そして、ｋがハイパーキューブの次元数Ｄに達
したかどうか調べ（３８１）、達した場合は終了する
（３８２）。そうでない場合は、ステップ３７４から次
のレベルの処理を繰り返す。

【０１２０】次に、このアルゴリズムを、４次元のハイ
パーキューブの場合について具体的に説明する。

【０１２１】まず、図１７のステップ３７２までで、図
１６のルートノード３４７とレベルリンク３６６が作成
される。また、図１５のテーブルが作成される。次に、
ステップ３７３でｋ＝１とした後、ステップ３７４で、 ｎ＝（ハミング距離１のサイト数）÷（０レベルリンク
のサイト数）＝４÷１＝４ を計算し、ｎ＝４となる。

【０１２２】次に、ステップ３７５で、ｋ−１＝０は偶
数なので、ステップ３７７で０レベルリンク３６６を右
からアクセスする。そして、ステップ３７８でそのリン
クの先頭からノード３４７を取り出す。このノード（ル
ートノード）３４７が表すサイト番号００００からハミ
ング距離が１のサイト番号を、図１５のテーブルのルー
トサイトからのハミング距離が１のテーブル３４３のサ
イトの集合から最大４サイト選ぶ。この場合は、全て選
ばれて、これが次のレベルのノードになる。

【０１２３】ここまでで、全木構造の中で、ルートノー
ドとレベル１のノード（３４８〜３５１）が完成する。
次に、ステップ３８０でｋ＝２となり、ステップ３７４
に戻る。

【０１２４】ステップ３７４では、ｎ＝６÷４＝１とな
り、今度の場合は、余りがあるので、ステップ３８３で
ｎ＝２となる。ステップ３７５でｋ−１＝１は奇数と判
断されるから、ステップ３７６でｋ−１（＝１）レベル
リンク３６３を左からアクセスする。

【０１２５】ステップ３７８では、始めに、左端のノー
ド３４８にアクセスする。このノード３４８が表すサイ
ト１０００からのハミング距離が１のサイトを図１５の
テーブル３４４から最大２つ選ぶ。サイト１０００から
距離１のサイトは、テーブル３４４中には、サイト１１
００，１０１０，１００１の３つ存在する。ここでは、
サイト１１００と１０１０を選び、サイト１０００のノ
ード３４８の子ノード３５２，３５３とする。

【０１２６】次に、このレベルリンク３６３には未だア
クセスしていないノードがあるから、処理はステップ３
７９→３７５→３７６→３７８と進み、次のノード３４
９のアクセスに移る。ノード３４９の表すサイト０１０
０からのハミング距離が１のサイトは、図１５のテーブ
ル３４４から、サイト１１００，０１１０，０１０１で
ある。このうち、サイト１１００は既にノード３４８の
アクセスのときに削除されているので、サイト０１１０
と０１０１を選び、サイト０１００のノード３４９の子
ノード３５４，３５５とする。

【０１２７】同様にして、ノード３５０，３５１につい
ても子ノードを得る。ノード３５０，３５１のアクセス
の場合は、図１５のテーブル中にこのノードが表すサイ
ト００１０，０００１からのハミング距離が１のサイト
は１つしか存在しないので、それぞれ、その１つを子ノ
ード３５６，３５７とする。

【０１２８】次に、ｋ＝３の場合に進む。この場合は、
レベルリンク３６４を右からアクセスする。ｎ＝１とな
るので、ノード３５７をアクセスしたときは、図１５の
テーブル３４５から、ノード３５７の表すサイト１００
１からハミング距離が１のサイトを選ぶ。この場合は、
候補が２つ、サイト１１０１と１０１１があり、ここで
はサイト１１０１を選ぶ。以下、ノード３５２まで同様
に処理する。

【０１２９】次のｋ＝４の場合は、ノード３５８の子ノ
ードは、サイト１１１１の表すノード３６２となる。残
りのアクセスは、図１５のテーブル３４６に要素がなく
なるので、なにもせずに終わる。最後に、Ｄ（次元）は
４、ｋ＝５なので、木構造作成処理は終了する。

【０１３０】（ハイパークロスバ）通常のハイパーキュ
ーブと呼ばれるトポロジーにおいて、あるノードに接続
する辺の数（次数）は、ハイパーキューブの次元に等し
い。このような通常のハイパーキューブをＨＣ（２，
Ｄ）と表現する。Ｄはハイパーキューブの次元である。
ハイパークロスバのトポロジーはＨＣ（Ｎ，Ｍ）であ
る。ＨＣは一般化されたハイパーキューブで、各サイト
に付随する番号はＮ進数で表現される。Ｍは各サイトに
付随する番号の桁数を表す。

【０１３１】図１８に、ＨＣ（４，２）の構成を示す。
各辺の番号は２桁の４進数で表現されている。

【０１３２】ハイパークロスバの場合も、ＧＨＣのブロ
ードキャストアルゴリズムを用いると、木構造のバラン
スが悪くなる問題が生じる。この場合も、上述のバラン
スのよいアルゴリズムを基本的には適用する。

【０１３３】（構造定義情報の配付方法）上述したよう
に、送信サイトは構造定義情報を各パケットのヘッダに
付加する（図１２）。構造定義情報が全て同じであれ
ば、送り先ごとにパケットヘッダを変える必要がなくな
るので、送信サイトは、各パケットを送信するためにブ
ロードキャスト機能を用いることができる。

【０１３４】図１９に、構造定義部１００により定義さ
れた木構造の表現の一例を示す。図１９（ａ）の構造を
持つエントリの集合として、木構造を表現する。各エン
トリは、親ノードのサイトを表す情報４５０とそのサイ
トの子ノードに対応するサイトの集合を表す情報４５１
から成る。全サイトに対応するエントリが全体の木構造
を決定する。

【０１３５】図１９（ｂ）は、図５の木構造を表現した
例である。但し、子ノードを持たないリーフノードに対
応するサイトについてのエントリは省いてある。エント
リ４５２は、サイト１の子ノードがサイト５０〜５３，
２，５９であることを表す。エントリ４５３は、サイト
２の子ノードがサイト５４〜５８であることを表す。こ
のことから、サイト５４〜５８はサイト１の孫ノードを
構成することがわかる。

【０１３６】各受信サイトは、最初のパケット受信時
に、そのパケットの構造定義情報（図１２の４４０）か
ら図１９の構造を抜き出し、この構造と自サイトのサイ
ト番号から自サイトのアクションを定める。

【０１３７】例えば、本実施例において、サイト２は、
サイト１から初めてパケットを受信したとき、図１９
（ｂ）のような表を作成する。次に、この表から、サイ
ト２の下にサイト５４〜５８が子ノードとして構成さ
れ、サイト２の親ノードはサイト１として構成されてい
ると認識する。したがって、サイト２は中間ノードとし
て動作することがわかり、以降中継ソフトウェア９が動
作する。さらに、サイト２がパケットを中継するときに
は、中継ソフトウェア９は、図１９（ｂ）のエントリ４
５３を参照して、サイト５４〜５８にパケットを中継す
べきことを、判断できる。

【０１３８】上述の表現方法においては、構造定義をパ
ケットのヘッダとして送る場合、ヘッダのサイズは小さ
いほうが好ましいので、リーフノード以外のノードにつ
いての情報のみ送る。

【０１３９】全体の構造定義情報を各パケットに付加す
るには大きすぎる場合は、あらかじめ、木構造を定義し
ておくか、配付に先立って、構造定義情報を配付する必
要がある。

【０１４０】［ずらしＡＣＫの実施例］次に、ＡＣＫの
収集を時間的にずらして、ＡＣＫ収集の集中を排除する
実施例について説明する。

【０１４１】対象とするネットワークは、図１のような
構造を持ち、全サイトへのブロードキャスト機能が備わ
っていることを仮定する。はじめに、送信サイトでは構
造定義として、自サイト以外のサイトを複数のグループ
に分ける。

【０１４２】図１９（ｃ）は、グループ分けした構造定
義情報の表現の１例を示す。グループ１は図１の軸２０
上のサイトから成り、グループ２は軸２３のサイトから
成る。以降の説明は、グループ分けの仕方に依存しない
ので、図２０（ａ）のように、要素として４サイトをも
つグループを３つ（４０１，４０２，４０３）作った例
で説明する。

【０１４３】この実施例の通信方法は、複数の基本フェ
ーズからなりたっている。１つは送信フェーズである。
図２０（ａ）に、送信フェーズの動作の様子を示す。次
は、確認応答フェーズである。確認応答フェーズは、構
造定義時に定義したグループの数だけ存在する。図２０
ではグループが３つなので、確認応答フェーズは３つ
（図２０（ｂ）〜（ｄ））存在する。各確認応答フェー
ズでは確認応答は１つのグループとのみ行なう。例え
ば、図２０（ｂ）では、グループ４０１が送信サイト４
００に確認応答を行なっている。

【０１４４】各グループの要素数をＡＣＫの取りこぼし
が起こらない程度の数に設定しておけば、各確認応答フ
ェーズでＡＣＫの取りこぼしが発生することはない。

【０１４５】図２１は、各フェーズがどのように組み合
わされて全体のプロトコルを構成するかを示す図であ
る。送信サイトは、上述の実施例と同様にして構造定義
およびブロックの構成を行った後、図２１の転送部４２
０でパケットを転送し、全データの終了を検知すると直
ちに終了部４３０の処理を行なう。

【０１４６】転送部４２０では、個々のパケット毎に確
認応答を受けるのではなく、固定数のパケット毎に確認
応答を受ける。常に全データ送信後に確認応答を受ける
ことにすると、送信データ量が既知であるという制約が
生じる。任意長のデータを送ることを可能とするため
に、固定数のパケットをブロックとしてまとめ、ブロッ
ク毎に確認応答を受けることにする。

【０１４７】本実施例では、ブロードキャスト機能が備
わったネットワークを仮定しているので、転送部４２０
の送信では、構成定義で決定したグループとは関係な
く、１パケット毎にブロードキャスト通信機能を用いて
全サイトへ送信を行なう。ブロック送信４２１，４２
４，４２７では、この１パケットの送信を、１ブロック
分繰り返す。

【０１４８】送信パケットは、上記実施例と同様の図１
２（ａ）の構成である。１ブロック送信終了後、ステッ
プ４２２で、いま送ったブロックについて、グループ１
からのみ確認応答を受ける。確認応答パケットの構成
は、上記実施例と同様の図１２（ｂ）の構成である。

【０１４９】図１２（ｂ）の再送要求パケット番号４４
７を元にして、ステップ４２３で、送信サイトは１対１
通信を用いて再送を行なう。ここまでは、グループ１に
属するサイトによる１ブロック分のデータ到着のみ保証
しており、グループ２，３については保証していない。

【０１５０】次に、再送終了後、ステップ４２４で次の
ブロックを送る。その後、ステップ４２５，４２６でグ
ループ２の確認応答を受ける。ここの確認応答は、ステ
ップ４２１でグループ２のサイトに送られたパケットの
確認応答をも含む。これを、グループの数だけ繰り返
す。当該例では、３グループなので、ステップ４２８，
４２９でグループ３からの確認応答を受けとった後、ス
テップ４２１の処理に戻る。

【０１５１】転送部４２０のブロック送信（４２１，４
２４，４２７）のいずれかで送信終了が判明した場合、
直ちに終了部４３０の処理に入る。まだ確認応答がすん
でいないパケットが存在する可能性があるので、各グル
ープ毎に確認応答要求を送り（４３１，４３３，４３
５）、確認応答を待つ（４３２，４３４，４３６）。確
認応答を調べて再送が必要であれば、再送処理を行な
う。全てのグループに対する確認応答の収集が終了した
ら、プロトコル処理を終了する（４３７）。

【０１５２】この実施例によれば、ＡＣＫの収集をグル
ープごとに時間的にずらして行なっているので、時間的
にＡＣＫが集中することが排除できる。

【０１５３】［信号収集用のハードウェアを用いた実施
例］次に、信号収集用のハードウェアを用いた実施例に
ついて説明する。

【０１５４】図２２は、本実施例のハードウェア構成を
示す。１〜１６の番号を付した矩形がサイトを示し、こ
れらの各サイトおよびコントロールサイト５０２は通信
線５０３により相互に接続されている。コントロールサ
イト５０２も含む各サイトは、通信線５０３を介して通
常の通信を行なう。

【０１５５】また、当該ハードウェアでは、各サイトと
コントロールサイト５０２とを接続する事象通知用の信
号線５０１が設けられている。コントロールサイト５０
２のＣＰＵは、インタフェースアダプタ５００を介して
この信号線５０１にアクセスする。この信号線５０１を
用いて、各サイトはコントロールサイト５０２へ事象の
通知を行なう。逆にいえば、コントロールサイト５０２
上のソフトウェアは、各サイトからの信号線５０１を介
して、どのサイトがオン状態にあるかどのサイトがオフ
状態にあるかを検出することが可能となっている。さら
に、コントロールサイト５０２では、全サイトからの信
号線５０１のＡＮＤ信号を簡単に取り出すことが可能で
ある。

【０１５６】図２３は、上記のハードウェア上で、任意
のサイト（サイト１〜１６中のいずれか）からブロード
キャスト転送を行なうときの様子を示す。送信を行なう
サイト上で動作する送信ソフトウェア５１１は、上記の
実施例と同様にして構造定義とブロック構成を行なった
後に、ブロードキャスト開始５１２を、図２２の通信線
５０３を介して、コントロールサイト５０２上のコント
ロールソフトウェア５１０へ送信する。

【０１５７】その後、送信ソフトウェア５１１は、構造
定義情報に従って、通信線５０３を介してブロードキャ
ストを行なう。送信サイト以外のサイトでは受信ソフト
ウェア５１６が動作しており、送信ソフトウェア５１１
から送られたパケットを受信する。送信ソフトウェア５
１１は、１ブロック送信完了後に直ちに信号線５０１を
オン５１７にする。また、各受信サイトの受信ソフトウ
ェア５１６は、１ブロックの受信中に取りこぼしがない
場合、信号線５０１をオンにする。各受信サイトの受信
ソフトウェア５１６からの信号線５０１のオン信号がＡ
ＣＫに相当し、コントロールソフトウェア５１０はこれ
によりＡＣＫ収集５１４を行なう。

【０１５８】送信開始５１２を受けたコントロールソフ
トウェア５１０は、送信ソフトウェア５１１の存在する
サイトの信号線５０１がオンになるのを待つ。これがオ
ンになったら、送信ソフトウェア５１１から１ブロック
送信完了したということになる。次に、コントロールソ
フトウェア５１０は、送信ソフトウェア５１１からの信
号線５０１のオン検出から一定時間経過した後に、イン
タフェースアダプタ５００から信号線５０１のＡＮＤ信
号を読み出す。

【０１５９】ＡＮＤ信号がオフであれば、いずれかの受
信サイトでパケットの取りこぼしが発生したことにな
る。従って、コントロールソフトウェア５１０は、各サ
イトに対応する信号線５０１を調べ、信号線５０１がオ
フのサイトを検索する。コントロールソフトウェア５１
０は、信号線５０１がオフであるサイトは取りこぼしが
発生したサイトであるとみなし、送信ソフトウェア５１
１に、当該サイトへの再送処理の要求を発行する。

【０１６０】以上のようにして、信号収集用のハードウ
ェアを利用して複数パケットから成るデータのブロード
キャスト転送を行なう。

【０１６１】［動的な構造定義の実施例］次に、構造定
義を動的に行なう実施例を説明する。

【０１６２】図２４は、本実施例におけるソフトウェア
の構成を示す。この図は、１つのサイト５３０のソフト
ウェア構成を示し、各サイトごとにこの構成を備える。
５３１は構造定義部１００を含むブロードキャスト実行
部、５３２はネットワーク状態監視部である。ブロード
キャスト実行部５３１は、上述したプログラムのロード
の実施例やずらしＡＣＫの実施例で説明した方法などを
用いてブロードキャストを実行する部分である。ネット
ワーク状態監視部５３２は、ネットワークの状態を監視
する部分で、ネットワークの混み具合や、受信パケット
用のキューの長さなどを監視する。

【０１６３】ブロードキャスト実行時には、構造定義部
１００で、ネットワーク状態監視部５３２に問合せを行
ない、ネットワークの状態を得る。構造定義部１００
は、この状態に基づいて構造定義を行なう。

【０１６４】図２５は、このような構造定義の一例を示
す。始めに、ネットワーク状態監視部５３２へ監視情報
取得要求を出す（５４０）。次に、取得した情報から、
受信パケットキューの空きの長さの平均を求める（５４
１）。この値の８割に相当する値を求め、その値をＮと
する（５４２）。そして、Ｎを、各サイトにおける短時
間にパケットを受信しても取りこぼさない数の上限とみ
なす。次に、木構造を作成する際に、各レベルにおける
子ノードの最大数がＮ以下となるように、構造を決定す
る（５４３）。

【０１６５】なお、ずらしＡＣＫの実施例で、このよう
な動的な構造定義を行なう場合は、グループ化の際に、
グループに含まれる要素の数がＮ以下となるようにグル
ープ化を行なえばよい。

【０１６６】

【発明の効果】本発明によれば、単一のサイトから複数
のサイトへ同一データを転送する場合、データの取りこ
ぼしなく、確実に転送できる。また、複数パケットから
成るデータに対して、パケットをブロックに分割し、各
ブロックごとに確認応答の収集を行なうので、全体の処
理に対する確認応答収集処理の割合を小さくでき、効率
的な転送が可能となる。

【０１６７】さらに、再送処理が必要なサイトに対応す
る上位階層のサイトが異なるときは、並列に再送処理を
行うようにしているので、再送処理を１サイトで逐次的
に行なう場合に比べて、高速な再送処理が可能である。
計算機のネットワークアーキテクチャの構造を考慮して
階層構造を作成すれば、ネットワークの性質を利用した
効率的なデータの配付および確認応答の収集が可能とな
り、全体として高速な信頼性のあるブロードキャスト通
信が可能となる。

【０１６８】さらに、ハードウェアがブロードキャスト
やマルチキャスト機能をサポートしている場合は、当該
機能を効果的に利用した高速な通信を行なうことが可能
となる。

【０１６９】送信サイト以外のサイトをグループ化し、
各グループによって異なるタイミングで確認応答を行な
うようにすれば、確認応答パケットによるぶつかりの数
を減らすことが可能となる。

【図面の簡単な説明】

【図１】本発明の１実施例の構成を示すブロック図であ
る。

【図２】本発明の１実施例における、送信処理を示す図
である。

【図３】本発明の１実施例における、確認応答収集処理
を示す図である。

【図４】本発明の１実施例における、再送処理を示す図
である。

【図５】本発明の１実施例における、定義した階層構造
を示す図である。

【図６】本発明の１実施例における、送信サイトにおけ
るデータの送信手順を示す図である。

【図７】本発明の１実施例における、中間サイトにおけ
るデータの中継手順を示す図である。

【図８】本発明の１実施例における、中間サイトにおけ
る再送要求処理の手順を示す図である。

【図９】本発明の１実施例における、受信サイトにおけ
るデータの受信手順を示す図である。

【図１０】本発明の１実施例における、確認応答表を示
す図である。

【図１１】本発明の１実施例における、受信パケット管
理表を示す図である。

【図１２】本発明の１実施例における、パケットの構造
を示す図である。

【図１３】本発明の１実施例における、ネットワークト
ポロジーと木構造とのマッピングを示す図である。

【図１４】本発明の１実施例における、ハイパーキュー
ブと木構造とのマッピングを示す図である。

【図１５】本発明の１実施例における、ハイパーキュー
ブ上の各サイトの送信サイトからのハミング距離による
分類表を示す図である。

【図１６】本発明の１実施例における、ハイパーキュー
ブ上の各サイトの木構造へのマッピングを示す図であ
る。

【図１７】本発明の１実施例における、ハイパーキュー
ブ上の各サイトを木構造へマッピングする手順を示す図
である。

【図１８】本発明の１実施例における、ハイパークロス
バのトポロジーを示す図である。

【図１９】本発明の１実施例における、構造定義情報の
表現を示す図である。

【図２０】本発明の１実施例における、ずらしＡＣＫ処
理の各フェーズにおける動作を示す図である。

【図２１】本発明の１実施例における、ずらしＡＣＫ処
理の手順を示す図である。

【図２２】本発明の１実施例における、事象通知用の信
号線をもつネットワークの構造を示す図である。

【図２３】本発明の１実施例における、事象通知用の信
号線を利用したブロードキャスト方法を示す図である。

【図２４】本発明の１実施例における、動的な構造定義
の構成を示すブロック図である。

【図２５】本発明の１実施例における、動的な構造定義
の手順を示す図である。

【図２６】確認応答の取りこぼしの動作を示す図であ
る。

【符合の説明】

１，２，５０〜６３…サイト、２０，２１，２３…通信
線、３…外部記憶装置、５…送信ソフトウェア、９…中
継ソフトウェア、１０…受信ソフトウェア、１１８…ブ
ロック構成部、１００…構造定義部、６，１７…パケッ
ト送信部、７，１６，１９…パケット受信部、７，２５
…応答受信部、１８…再送部、２４…再送要求部、８，
１５…確認応答表、１４，２２…受信パケット管理表。

フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｈ０４Ｌ 12/18 8732−5Ｋ Ｈ０４Ｌ 11/18 (72)発明者 藤田 不二男 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア開発本部内

Claims (12)

【特許請求の範囲】
1. 【請求項１】プロセッサとローカルメモリとを備えた複
   数のサイトがネットワークで結合された計算機システム
   において、ある送信サイトから他の全てのサイトに複数
   パケットから成る同じデータを送信する一斉同報通信方
   法であって、 送信サイトにおいて、他サイトに送信すべき複数パケッ
   トを、所定数のパケットからなるブロックに分割するブ
   ロック構成ステップと、 送信サイトのみの階層を最上位階層とする階層構造を作
   成する構造定義ステップと、 前記階層構造を表す階層情報を各パケットに付加して、
   ブロックごとに、そのブロックの複数のパケットを送信
   サイトから他の全てのサイトに送信するパケット送信ス
   テップと、 前記階層構造の最下位階層に位置するサイトにおいて、
   前記パケット送信ステップにより送信された１ブロック
   の複数のパケットの受信を確認した後、自サイトに対応
   する上位階層のサイトに確認応答パケットを送信するス
   テップと、 前記階層構造中で最上位階層と最下位階層との中間の階
   層に位置するサイトにおいて、自サイトに対応する下位
   階層の全サイトからの確認応答パケットの到着と、自サ
   イトにおける前記１ブロックの複数のパケットの受信と
   を確認した後、自サイトに対応する上位階層のサイトに
   確認応答パケットを送信するステップと、 前記階層構造の最上位階層に位置する送信サイトにおい
   て、自サイトに対応する下位階層の全サイトからの確認
   応答パケットを受信して、送信を完了するステップとを
   備えたことを特徴とする一斉同報通信方法。
2. 【請求項２】請求項１に記載の一斉同報通信方法におい
   て、 前記パケット送信ステップは、前記階層構造に沿って前
   記ブロックの複数のパケットを送信することを特徴とす
   る一斉同報通信方法。
3. 【請求項３】請求項２に記載の一斉同報通信方法におい
   て、 前記階層構造の最上位階層に位置する送信サイトは、自
   サイトに対応する下位階層の全サイトに、前記ブロック
   の複数のパケットを一斉同報通信で送信し、 前記階層構造中で最上位階層と最下位階層との中間の階
   層に位置するサイトは、自サイトに対応する上位階層の
   サイトから一斉同報通信で送信された前記ブロックの複
   数のパケットを受信し、その複数のパケットを自サイト
   に対応する下位階層の全サイトに一斉同報通信で送信す
   ることを特徴とする一斉同報通信方法。
4. 【請求項４】請求項３に記載の一斉同報通信方法におい
   て、 送信サイト以外のサイトで再送処理が必要になった場合
   は、そのサイトに対応する上位階層のサイトに再送要求
   を送信し、その再送要求を受信したサイトは再送を行な
   うことを特徴とする一斉同報通信方法。
5. 【請求項５】請求項４に記載の一斉同報通信方法におい
   て、 送信サイト以外の複数のサイトで再送処理が必要になっ
   た場合、そのサイトに対応する上位階層のサイトが異な
   るときは、並列に再送処理を行なうことを特徴とする一
   斉同報通信方法。
6. 【請求項６】請求項１から５のいずれか１つに記載の一
   斉同報通信方法において、 前記構造定義ステップは、計算機システムのネットワー
   クアーキテクチャの構造に基づいて前記階層構造を作成
   することを特徴とする一斉同報通信方法。
7. 【請求項７】請求項６に記載の一斉同報通信方法におい
   て、 前記構造定義ステップは、前記送信サイトからの送受信
   の遅れがより小さいサイトがより上位になるように、前
   記階層構造を作成することを特徴とする一斉同報通信方
   法。
8. 【請求項８】プロセッサとローカルメモリとを備えた複
   数のサイトがネットワークで結合された計算機システム
   において、ある送信サイトから他の全てのサイトに複数
   パケットから成る同じデータを送信する一斉同報通信方
   法であって、 送信サイトにおいて、他サイトに送信すべき複数パケッ
   トを、所定数のパケットからなるブロックに分割するブ
   ロック構成ステップと、 送信サイト以外のサイトを複数のグループに分割する構
   造定義ステップと、 前記送信サイトから、ブロックごとに、そのブロックの
   複数のパケットを他の全てのサイトに送信するパケット
   送信ステップと、 前記各グループ中のサイトにおいて、グループによって
   異なるタイミングで送信サイトに確認応答パケットを応
   答するステップとを備えたことを特徴とする一斉同報通
   信方法。
9. 【請求項９】請求項８に記載の一斉同報通信方法におい
   て、 前記各グループの要素となるサイトの数を、前記確認応
   答パケットの取りこぼしが発生しない程度の数とするこ
   とを特徴とする一斉同報通信方法。
10. 【請求項１０】請求項１から９のいずれか１つに記載の
    一斉同報通信方法において、 前記確認応答パケットを送受するためのハードウェアを
    設けたことを特徴とする一斉同報通信方法。
11. 【請求項１１】請求項１から１０のいずれか１つに記載
    の一斉同報通信方法において、 前記構造定義ステップは、ネットワークの状態に基づい
    て構造定義を行なうことを特徴とする一斉同報通信方
    法。
12. 【請求項１２】プロセッサとローカルメモリとを備えた
    複数のサイトがネットワークで結合された計算機システ
    ムにおいて、ある送信サイトから他の全てのサイトに複
    数パケットから成る同じデータを送信するための一斉同
    報通信装置であって、 送信サイトにおいて、他サイトに送信すべき複数パケッ
    トを、所定数のパケットからなるブロックに分割するブ
    ロック構成手段と、 送信サイトのみの階層を最上位階層とする階層構造を作
    成する構造定義手段と、 前記階層構造を表す階層情報を各パケットに付加して、
    ブロックごとに、そのブロックの複数のパケットを送信
    サイトから他の全てのサイトに送信するパケット送信手
    段と、 前記階層構造の最下位階層に位置するサイトにおいて、
    前記パケット送信ステップにより送信された１ブロック
    の複数のパケットの受信を確認した後、自サイトに対応
    する上位階層のサイトに確認応答パケットを送信する手
    段と、 前記階層構造中で最上位階層と最下位階層との中間の階
    層に位置するサイトにおいて、自サイトに対応する下位
    階層の全サイトからの確認応答パケットの到着と、自サ
    イトにおける前記１ブロックの複数のパケットの受信と
    を確認した後、自サイトに対応する上位階層のサイトに
    確認応答パケットを送信する手段と、 前記階層構造の最上位階層に位置する送信サイトにおい
    て、自サイトに対応する下位階層の全サイトからの確認
    応答パケットを受信して、送信を完了する手段とを備え
    たことを特徴とする一斉同報通信装置。