(57)【特許請求の範囲】
【請求項１】
被送信データを送信するソースノードと、
前記被送信データを受信するデスティネーションノードとを有し、
前記ソースノードは、
前記被送信データが正常に受信されなかった場合において、前記被送信データの再送処理を所定時間が経過するまで禁止する機能を有し、
前記デスティネーションノードは、
前記デスティネーションノードの負荷状態が第１の負荷状態である場合においては、前記所定時間を第１の時間に変更して前記ソースノードに通知し、前記デスティネーションノードの負荷状態が前記第１の負荷状態よりも大きい第２の負荷状態である場合においては、前記所定時間を前記第１の時間よりも長い第２の時間に変更して前記ソースノードに通知する機能を有することを特徴とするデータ通信システム。
【請求項２】
前記ソースノードは、前記被送信データを、ＩＥＥＥ１３９４規格で規定されたアシンクロナス（asynchronous）転送方式を用いて送信することを特徴とする請求項１に記載のデータ通信システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、被送信データを送信するソースノードと、当該被送信データを受信するデスティネーションノードとを有するデータ通信システムに関する。
【０００２】
【従来の技術】
パソコン周辺機器の中で、最も利用頻度が高いのはハードディスクやプリンタであり、これらの周辺装置は小型コンピュータ用汎用型インターフェイスで代表的なデジタルインターフェイス（以下、デジタルI/F)であるSCSI等をもってパソコン間との接続がなされ、データ通信が行われている。
【０００３】
また、デジタルカメラやデジタルビデオカメラといった記録再生装置もパソコン（以下、PC）への入力手段として、周辺装置の１つであり、近年、デジタルカメラやビデオカメラで撮影した静止画や動画といった映像をPCへ取り込み、ハードディスクに記憶したり、またはPCで編集した後、プリンタでカラープリントするといった分野の技術が進んでおり、ユーザーも増えている。
【０００４】
取り込んだ画像データをPCからプリンタやハードディスクへ出力する際などに、上記のSCSI等を経由してデータ通信がされるものであり、そのようなとき画像データのようにデータ量の多い情報を送るためにも、こういったデジタルI/F には転送データレートの高い、かつ汎用性のあるものが必要とされる。
【０００５】
ディジタルVTR 、TV、チューナなどのAV機器や、パーソナルコンピュータ（以下、PCと称する）等をIEEE1394シリアルバス（以下、1394と称する）を用いて相互に接続し、これらの間においてディジタルビデオ信号、ディジタルオーディオ信号などを送受信する通信システムが提案されている。該システムは、IEEE1394 Standard for High Performance Serial Bus 規格として知られている。
【０００６】
上記1394規格においては、非同期データ転送と同期式データ転送とが定義されている。非同期データ転送では、明示したアドレスに、可変長のデータパケットを送信し、認識パケット（アクノリッジパケット）を返す、パケット転送プロトコルを提供している。また、同期式（以下、isochronous と称する）データ転送では、一定の時間的間隔で可変長のパケットを転送する、パケット転送プロトコルを提供している。
【０００７】
上記1394規格の非同期データ転送においては、任意のノードが、多数の処理のため、パケットへの対応が不可能な場合に、復路パケットにおいて、その旨を通知するレスポンスを返すための、リトライ手順が定義されている。
【０００８】
上記リトライ手順においては、要求パケット、または、レスポンスパケットを受け取ったことを知らせる、任意の復路パケットに、リトライのためのコードを付け加えても良いようになっている。図１０に示した状態遷移図は、1394における受信ノードが、他ノードから受信したパケットを処理する時の振舞いの一例を示している。
【０００９】
図１０のノードは、ノードコントローラから、Initialize、又は、Reset のコントロール要求を受け取った時、ISR0状態を除く他の任意の状態から、ISR0状態へ、遷移する。ISR0状態では、通信リソースの利用が許可されており、該ノードは、他ノードから、最初のパケットを受け付けるのを、待機する。ISR0状態のときに、非同期（以下、asynchronousと称する）パケットを受信すると、該ノードは、適切な値を持つ、受信を示すレスポンスデータを返す。
【００１０】
通信リソースが利用できない場合には、該ノードは、ISR 状態からISR1状態へ遷移する。この時、該ノードは、busy状態であるという。この場合、該ノードは、他のノードからの最初のパケットを、受け付けることができない状態である。ISR1状態のときにasynchronousパケットを受信すると、該ノードは、ack ＿busy＿X の受信レスポンスデータを返す。ISR1状態のときに通信リソースの利用が許可されると、該ノードは、ISR0状態に遷移して、busy状態ではなくなる。
【００１１】
図１１に示した状態遷移図は、1394における送信ノードが、他ノードに主要なパケットを送信した後に、busyを受け取った時の振舞いの一例を示している。また、図１１に示すノードは、Initialize、又は、Reset のトランザクション制御パケットを、ノードコントローラから受信した場合、他の状態からOSR0状態に遷移する。
【００１２】
このとき、該ノードは、他ノードにパケットを送信する準備ができている。OSR0状態のときに、該ノードがack ＿busy＿A 、ack ＿busy＿B 、ack ＿busy＿X 以外のパケットを受信すると、該ノードは、パケットを送信し、リトライを行なう必要はない。OSR0状態のときに、該ノードがack ＿busy＿A 、ack ＿busy＿B 、ack ＿busy＿X のパケットを受信すると、受信先のノードがbusy状態であると認識する。この場合、リトライの必要が生じるので、該ノードは、OSR1状態に遷移する。
【００１３】
OSR1状態の時、該ノードは、解決しなければならない保留中のリトライを有しており、他の任意のパケットを送信する前に、該リトライを解決しなければならない。この時、該ノードは、リトライコードをretry ＿X に指定して、リトライを行なう。OSR1状態の時に、該ノードがリトライを行なう回数の上限である、いわゆる、リトライリミットを越えておらず、かつ、保留中のリトライパケットを、リトライパケットの待ち行列である、いわゆる、リトライキューに入れていない場合、該ノードは、OSR1状態のままである。
【００１４】
OSR1状態の時に、該ノードが上述のリトライリミットを越えておらず、かつ、リトライパケットを上述のリトライキューに入れた場合、該ノードは、OSR1状態からOSR0状態に遷移する。
【００１５】
また、OSR1状態の時に、該ノードがack ＿busy＿A 、ack ＿busy＿B 、ack ＿busy＿X のいずれか以外のパケットを受け取ると、該ノードからのパケットは既に送信されており、OSR1状態からOSR0状態に遷移する。
【００１６】
さらに、OSR1状態の時に、該ノードが上述のリトライリミットを越えて、リトライを行なった場合、この通信は失敗し、該ノードは、OSR1状態からOSR0状態に遷移する。
【００１７】
上記のように、パケットを受信したノードがbusyであってパケットを受け取れない時、パケットを送信したノードに対し、受信ノードは、該受信ノードがbusyであることを知らせ、送信ノードが後にリトライを行なうようにする。リトライ時においては、パケットにリトライコードが付加されて送信される。
【００１８】
リトライには、シングルフェイズリトライと、デュアルフェイズリトライとの、２種類がある。シングルフェイズリトライは、比較的、単純な動作を行なうもので、受信が成功するか、又は、リトライリミットを越えるまでリトライが繰り返される。上記リトライの動作は、シングルフェイズリトライについて記述している。
【００１９】
デュアルフェイズリトライの場合、受信パケットをＡとＢとのグループに分けて、リトライ動作を行なう。デュアルフェイズリトライの場合、受信ノードがbusyであった時、受信ノードはack ＿busy＿A 、又は、ack ＿busy＿B のアクノリッジパケットを用いて応答する。
【００２０】
その後、送信ノードがリトライを行なった場合、送信ノードは、直前にack ＿busy＿A を受信したときにはretry ＿A を用い、直前にack ＿busy＿B を受信したときにはretry ＿B を用いる。
【００２１】
受信ノードが、retry ＿A のリトライを受信した場合、他のノードからのパケットに対しack ＿busy＿B を割り当てる。全てのretry ＿A のリトライが受け付けられた時点で、受信ノードは、retry ＿B のリトライを受け付けて、他の受信パケットにack ＿busy＿A を割り当てる。上記処理が繰り返されて、ＡグループとＢグループとの処理が交互に進んでゆく。
【００２２】
また、デュアルフェイズリトライでは、タイムアウトを用いてretry ＿A の全てのリトライが完了したかを、判断するようになっている。デュアルフェイズリトライを用いる送信ノードは、リトライタイムアウトが経過するまで、４つの(IEEE1394 規格に定められている）fairness interval 毎に、リトライを行なわなければならない。
【００２３】
受信ノードは、retry ＿A のリトライが全てbusyでない状態において、４つのfairness interval が経過する間に、retry ＿A の全てのリトライが送信されることを想定する。同様のタイムアウトがretry ＿B においても適用される。よって、送信ノードが４つのfairness interval 期間中に、リトライを行なえなかった場合には、通信が失敗することになる。
【００２４】
シングルフェイズリトライのみを実装している送信ノードが、ack ＿busy＿X 、ack ＿busy＿A 、ack ＿busy＿B のいずれかのアクノリッジコードを受け取った場合には、retry ＿X のリトライコードを用いてリトライしなければならないようになっている。
【００２５】
また、デュアルフェイズリトライを実装している受信ノードは、retry ＿X のリトライを受信した時のリトライフェイズが完了した時点で、retry ＿X のリトライを受け付けるようになっている。
【００２６】
上記のように、1394のasynchronous通信においては、リトライによって通信が確実に行なわれることが保証されている。従来、このasynchronous通信を用いて、ライトトランザクションによるデータ授受を用いたデータ転送方式が提案されている。
【００２７】
【発明が解決しようとする課題】
しかしながら、上記asynchronousライトトランザクションを用いた従来のデータ転送方式においては、ack ＿busy＿X 、ack ＿busy＿A 、ack ＿busy＿B などがが帰ってきてから、どのくらいの時間、待機すればよいかが規定されていない。
【００２８】
したがって、処理速度の遅い受信ノードと、高速な送信ノードとの組合せによって、転送を行なう場合において、バスが混雑した時には、上記高速な送信ノードのリトライが頻発してしまうと共に、上記処理速度の遅い受信ノードのバッファが常に満たされた状態になってしまうことが予想される。
【００２９】
この場合には、上記受信ノードからのack ＿busy＿X 、ack ＿busy＿A 、ack ＿busy＿B の転送が頻発することになり、送信ノードが次のパケットを送信できなくなる、いわゆる、デッドロックが発生してしまうといった問題点があった。
【００３０】
また、ブロードキャスト通信を用いたデータ転送方式の場合には、リトライが不可能で、通信が確実に行なわれることが保証されなくなるといった問題点があった。
【００３１】
本発明は、バスが混雑した場合にも、ack ＿busy＿X 、ack ＿busy＿A 、ack ＿busy＿B などの頻発を防止し、デッドロックの発生を防ぐことができるようにすることを目的とする。
【００３２】
【課題を解決するための手段】
本発明に係るデータ通信システムは、被送信データを送信するソースノードと、前記被送信データを受信するデスティネーションノードとを有し、前記ソースノードは、前記被送信データが正常に受信されなかった場合において、前記被送信データの再送処理を所定時間が経過するまで禁止する機能を有し、前記デスティネーションノードは、前記デスティネーションノードの負荷状態が第１の負荷状態である場合においては、前記所定時間を第１の時間に変更して前記ソースノードに通知し、前記デスティネーションノードの負荷状態が前記第１の負荷状態よりも大きい第２の負荷状態である場合においては、前記所定時間を前記第１の時間よりも長い第２の時間に変更して前記ソースノードに通知する機能を有することを特徴とする。
【００４１】
【発明の実施の形態】
以下、図１を用いて、本発明の実施の形態について説明する。図１において、 10 はcomputerであり、 12 は演算処理装置 (MPU)、 14 は第１の1394インターフェイス、 16 はキーボードなど第１の操作部、 18 は第１のデコーダ、 20 はCRT ディスプレイなどの表示装置、 22 はハードディスク、 24 は第１のメモリであり本発明に係るcomputer 10 の内部メモリ、 26 はPCI バスなどのコンピュータ内部バスである。
【００４２】
また、28はVCR であり、30は撮像光学系、32はアナログ- デジタル(A/D）変換器、34はビデオ処理部、36は圧縮伸長回路、38は第２のメモリ、 40 は第３のメモリ、 42 は第１のデータセレクタ、 44 は第２の1394インターフェイス、 46 は第１のメモリ制御回路、 48 は第２のメモリ制御回路、 50 はシステムコントローラ、 52 は第２の操作部、 54 はファインダ、 56 はD/A 変換器、 58 は記録部である。
【００４３】
さらに、60はプリンタであり、62は第３の1394インターフェイス、64は第２のデータセレクタ、66は第３の操作部、68はプリンタコントローラ、70は第２のデコーダ、72は第４のメモリ、 74 は画像処理部、 76 はドライバ、 78 はプリンタヘッドである。
【００４４】
computer 10と、VCR 28、及び、プリンタ 60 とは、第１から第３の1394インターフェイス 14, 44, 62 によって1394シリアルバスのノードを構成するとともに、該第１から第３の1394インターフェイス 14, 44, 62 を介して相互に接続されており、データの授受や、コマンドによるコントロール等が可能になっている。
【００４５】
本実施の形態では、例えば、computer 10 は、1394シリアルバス上における、画像信号送受信のコントローラとして動作する。本実施の形態に係るcomputer 10 においては、例えば、PCI バスなどのコンピュータ内部バス 26 によって、MPU  12 と、1394インターフェイス 14 、キーボード 16 、デコーダ 18 、CRT ディスプレイ 20 、ハードディスク 22 、内部メモリ 24 などの、内部の各デバイスとが相互に接続されている。
【００４６】
MPU 12は、ハードディスク 22 に記録されているソフトウェアを実行するとともに、様々なデータを内部メモリ 24 に移動させる。また、MPU 12は、PCI バス 26 によって接続されている各デバイスの、調停動作なども合わせて行なう。
【００４７】
1394 インターフェイス 14 は、1394シリアルバス上に転送される画像信号を受信するとともに、ハードディスク 22 に記録されている画像信号や、内部メモリ 24 に記憶される画像信号を送信する。
【００４８】
また、1394インターフェイス 14 は、1394シリアルバス上に接続された他の機器に対するコマンドデータを送信する。また、1394インターフェイス 14 は、1394シリアルバス上に転送される信号を他の1394ノードに転送する。
【００４９】
操作者は、キーボード 16 などの操作部を通じて、MPU 12に、ハードディスク 22 に記録されているソフトウェアを実行させる。該ソフトウェア等の情報は、CRT ディスプレイなどの表示装置 20 によって、操作者に提示される。デコーダ 18 は、上記のソフトウェアを通じて、1394シリアルバス上から受信した画像信号をデコードする。デコードされた画像信号も、また、CRT ディスプレイなどの表示装置 20 によって操作者に提示される。
【００５０】
本実施の形態では、例えば、VCR 28は、画像信号の入力装置として動作する。撮像光学系 30 から入力された映像の輝度信号（Ｙ) と色差信号（Ｃ）は各々A/D 変換器 32 にてディジタルデータに変換される。上記ディジタルデータは、ビデオ処理部 34 にて多重化される。その後、圧縮伸長回路 36 にて該画像情報のデータ量を圧縮する。
【００５１】
一般に、YC独立に該圧縮処理回路を備えているが、ここでは説明の簡略化の為にYC時間分割での圧縮処理の例を示す。次に、前記画像データを伝送路誤りに強くする目的でシャフリング処理を施す。この処理の目的は、連続的な符号誤りであるところのバーストエラーを修整や補間の行いやすい離散的な誤りであるところのランダムエラーに変換する事である。加えて、画像の画面内の粗密による情報量の発生の偏りを均一化する目的を重視する場合には前記圧縮処理の前に本処理工程を持ってくると、ランレングス等の可変長符号を用いた場合に都合が良い。
【００５２】
これを受けて、データ・シャフリングの復元の為のデータ識別（ID）情報を付加する。このID付加動作にて付加されたIDは、同時に記録しておいた前記システムのモード情報等と共に再生時の逆圧縮処理（情報量伸張処理）の際に補助情報として利用する。これらのデータの再生時の誤りを低減する為にエラー訂正（ECC ）情報を付加する。
【００５３】
このような冗長信号の付加までを、映像と音声等の情報毎に対応する独立の記録エリア毎に処理する。上記のように、ID情報やECC 情報が付加された画像信号は、記録部 58 により、磁気テープ等の記録媒体に記録されるとともに、後述する第２のメモリ 38 に一時的に記憶される。
【００５４】
一方、ビデオ処理部 34 にて多重化された画像データは、D/A 変換器 56 によって、ディジタル−アナログ変換され、電子ビューファインダ 54 で操作者により観察される。また、操作者は第２の操作部 52 を介して、様々な操作情報をシステムコントローラ 50 に送信し、システムコントローラ 50 は、該操作情報によって、VCR 全体を制御するようになっている。
【００５５】
また、ビデオ処理部 34 にて多重化された画像データは、第３のメモリ 40 に出力され、一時的に記憶される。前述した第２のメモリ 38 と、第３のメモリ 40 とは、それぞれ、第１のメモリ制御回路 46 と、第２のメモリ制御回路 48 とを介し、システムコントローラ 50 により動作制御されている。
【００５６】
第１のデータセレクタ 42 は、前述した第２のメモリ 38 と、第３のメモリ 40 からのデータを選択して、第２の1394インターフェイス 44 に受け渡す、あるいは、第２の1394インターフェイス 44 からのデータを選択して、第２のメモリ 38 と、第３のメモリ 40 とのどちらかに受け渡す。上記動作により、VCR 28における第２の1394インターフェイス 44 からは、圧縮された画像データと非圧縮の画像データとが、操作者により選択されて出力できるようになっている。
【００５７】
第２の1394インターフェイス 44 は、1394シリアルバスを通じて、VCR 28を制御するためのコマンドデータを受信する。受信されたコマンドデータは、第１のデータセレクタ 42 を通じて、システムコントローラ 50 に入力される。
【００５８】
システムコントローラ 50 は、上記のコマンドデータに対するレスポンスデータを作成して、第１のデータセレクタ 42 、及び、第２の1394インターフェイス 44 を通じ、1394シリアルバスに該データを送出する。
【００５９】
本実施の形態では、例えば、プリンタ 60 は、画像の印刷出力装置として動作する。第３の1394インターフェイス 62 は、1394シリアルバス上に転送される画像信号と、1394シリアルバスを通じて該プリンタ 60 を制御するためのコマンドデータとを受信する。また、第３の1394インターフェイス 62 は、該コマンドに対するレスポンスデータを送信する。
【００６０】
受信された画像データは、第２のデータセレクタ 64 を通じて、第２のデコーダ 70 に入力される。第２のデコーダ 70 は、該画像データをデコードして、画像処理部 74 に出力する。画像処理部 74 は、デコードされた画像データを第４のメモリ 72 に一時的に記憶する。
【００６１】
一方、受信されたコマンドデータは、第２のデータセレクタ 64 を通じて、プリンタコントローラ 68 に入力される。プリンタコントローラ 68 は、該コマンドデータによりドライバ 76 による紙送り制御や、プリンタヘッド 78 の位置制御など、様々な印刷に関する制御を行なう。また、プリンタコントローラ 68 は、第４のメモリ 72 に一時的に記憶された画像データを、印刷データとして、プリンタヘッド 78 に送信し、印刷動作を行わせる。
【００６２】
上述したように、本実施の形態に係る、第１から第３の1394インターフェイス 14,  44,  62 は、それぞれ、1394シリアルバスのノードを構成する。第１の1394インターフェイス 14 は、コントロールノード、または、コントローラとして動作し、第２の1394インターフェイス 44 は、画像データのソースノードとして動作し、第３の1394インターフェイス 62 は、デスティネーションノードとして動作する。
【００６３】
本実施の形態に係るコマンドパケット、あるいは、レスポンスパケットは、例えば、Asynchronousパケットによって送受信される。該Asynchronousパケットは、例えば、4 byte (32 bits 、以下クアッドレットと称する) を単位とするデータパケットである。
【００６４】
図２は、一般的なAsynchronousパケットの構造を示す図である。図２において、最初の16 bits はdestination ＿IDフィールドであり、該フィールドは受信先のノードIDを示す。次の6 bitsのフィールドは、トランザクション・ラベル(tl)フィールドであり、各トランザクション固有のタグである。
【００６５】
次の2 bitsのフィールドは、リトライ(rt)コードであり、パケットがリトライを試みるかどうかを指定する。また、該フィールドは、図２で示されるパケットの受信ノードに対して、前述したリトライプロトコルを指定する。下記の表１に、上記リトライコードの符号化の一例を示す。
【００６６】
【表１】
0004065466.tif 000002
【００６７】
該パケットを送信するノードが、前述したオプションのデュアルフェイズリトライをサポートしていない場合には、該フィールドの値には、retry ＿X を用いなければならないようになっている。
【００６８】
次の4 bitsのフィールドは、トランザクションコード(tcode) である。tcode は、パケットのフォーマットや、実行しなければならないトランザクションのタイプを指定する。本実施の形態においては、例えば、この値が00012 である、データブロックの書き込みリクエストのトランザクションを用いる。
【００６９】
次の4 bitsのフィールドは、プライオリティ(pri) フィールドであり、優先順位を指定する。本実施の形態においては、Asynchronousパケットを用いているので、このフィールドの値は00002 である。
【００７０】
次の16 bits はsource＿IDフィールドであり、送信側のノードIDを示す。次の48 bits はpacket type specific informationであり、該Asynchronousパケットの種類に固有の情報が格納されるフィールドである。
【００７１】
本実施の形態のようなデータブロックの書き込みリクエストや、読み出しリクエスト、ロックリクエストなどの、いわゆるリクエストパケットの場合、このフィールドはdestination ＿offsetフィールドであり、該パケットの受信ノードアドレスの、下位48 bits がこのフィールドによって指定される。
【００７２】
また、書き込み、読み出し、及び、ロックのリクエストに対するresponseパケットの場合には、該フィールドは、上位4 bitsのrcode フィールドと下位44 bits のreservedフィールドとに分割される。rcode フィールドには、上記リクエストに対する応答のコードが格納される。また、reservedフィールドには、例えば、0000000000016 の値が詰められる。
【００７３】
次の32 bits は、packet type specific quadlet data であり、該Asynchronousパケットの種類に固有のデータが格納されるフィールドである。該フィールドは、パケットの種類によって、存在しない場合があり得る。
【００７４】
例えば、データペイロードのないパケットの場合には、このフィールドは存在しない。また、データクアッドレットペイロードを有するパケットの場合、該フィールドは、quadlet ＿dataフィールドであり、32 bits のデータが格納される。
【００７５】
また、データブロックを有するパケットの場合、該フィールドは、上位16 bits のdata＿lengthフィールドと、下位16 bits のextended＿tcode フィールドとに分割される。上記data＿lengthフィールドには、後述するデータブロックのデータ長が格納される。
【００７６】
該data＿lengthフィールドに格納されるデータ長は、例えば、byte(8 bits)単位で示される。extended＿tcode フィールドは、ロックリクエスト、又は、ロックレスポンスのパケットの場合のみに意味を持ち、本実施の形態で用いられる書き込みリクエストパケットの場合のように、ロックリクエスト、ロックレスポンス以外のパケットの場合には、例えば、000016の値が格納される。
【００７７】
次の32 bits はheader＿CRC フィールドである。上述したdestination ＿IDフィールドからpacket type specific quadlet data までをパケットヘッダと称し、前記header＿CRC フィールドは、該パケットヘッダのエラー検出に用いられる。
【００７８】
次に、続くフィールドは、データブロックである。データブロックは、データブロッククアッドレット(data block quadlets) と、data＿CRC フィールドとから構成される。
【００７９】
データブロッククアッドレットは、データブロックペイロード(data block payload)や、データフィールド(data field)と称されることもある。該データブロッククアッドレットは、全てのデータブロックパケットに存在し、通常、可変長のデータが格納される。可変長のデータが格納される場合、前述したdata＿lengthフィールドによって、該データブロッククアッドレットのデータ長が示される。
【００８０】
本実施の形態においては、上記データクアッドレットブロックの、クアッドレットの倍数に満たないビットには、０の値が詰められるようになっている。言い替えると、前述のdata＿lengthフィールドに格納されるデータ長がbyte(8 bits)単位で示される場合において、該data＿lengthフィールドの値が４の倍数でない場合、上記データクアッドレットブロックは、クアッドレットを満たすまで0016の値のデータによって埋められる。
【００８１】
次の32ビットのフィールドはdata＿CRC フィールドであり、前述のheader＿CRC フィールドと同様に、上記データブロッククアッドレットのエラー検出に用いられる。
【００８２】
上述のようなパケットを受け取った受信ノードは、アクノリッジパケット(acknowledge packet)によって、応答を返す。該アクノリッジパケットは、長さがちょうど1 byte(8 bits)なので、他のパケットから容易に区別できるようになっている。該アクノリッジパケットは、アックパケット、ack パケットなどとも称される。図３は、上記アクノリッジパケットの構造を示す図である。
【００８３】
アクノリッジパケットの最初の4 bitsはack ＿codeフィールドである。該フィールドによって、前述したack ＿busy＿A 、ack ＿busy＿B 、ack ＿busy＿X などのコードが転送される。該ack ＿codeフィールドの符号化の一例を、表２に示す。
【００８４】
【表２】
0004065466.tif 000003
【００８５】
次の4 bitsのフィールドは、ack ＿parityフィールドであり、アクノリッジパケットのパリティチェックビットが格納される。例えば、本実施例では、前記ack ＿codeの値の１の補数が格納される。該フィールドは、アクノリッジパケットのエラー検出に用いられる。
【００８６】
図４に示した状態遷移図は、シングルフェイズリトライのみを実装した、本実施の形態における送信ノードが、他ノードにパケットを送信した後に、busyを受け取った時の振舞いの一例を示している。
【００８７】
図４に示すノードは、Initialize、又は、Reset のトランザクション制御パケットを、ノードコントローラから受信した場合、他の状態からOSR0状態に遷移する。このとき、該ノードは、他ノードにパケットを送信する準備ができている。OSR0状態のときに、該ノードがack ＿busy＿A 、ack ＿busy＿B 、ack ＿busy＿X 以外のパケットを受信すると、該ノードは、パケットを送信し、リトライを行なう必要はない。
【００８８】
OSR0状態のときに、該ノードがack ＿busy＿A 、ack ＿busy＿B 、ack ＿busy＿X のパケットを受信すると、受信先のノードがbusy状態であると認識する。この場合、リトライの必要が生じるので、該ノードは、OSR1状態に遷移する。
【００８９】
OSR1状態の時、該ノードは、解決しなければならない保留中のリトライを有しており、他の任意のパケットを送信する前に、該リトライを解決しなければならない。この時、該ノードは、リトライコードをretry ＿X に指定して、リトライを行なう。
【００９０】
OSR1状態の時に、該ノードがリトライを行なう回数の上限である、いわゆる、リトライリミットを越えておらず、かつ、保留中のリトライパケットを、リトライパケットの待ち行列である、いわゆる、リトライキューに入れていない場合、該ノードは、OSR1状態のままである。
【００９１】
また、OSR1状態の時には、最少リトライ周期(minimum retry period)が設定されている。OSR1状態の時に、上記最少リトライ周期を経過するまでの期間は、OSR0状態に遷移することはない。
【００９２】
OSR1状態の時に、該ノードが上述のリトライリミットを越えておらず、かつ、リトライパケットを上述のリトライキューに入れた場合、該ノードは、OSR1状態からOSR0状態に遷移する。また、OSR1状態の時に、該ノードがack ＿busy＿A 、ack ＿busy＿B 、ack ＿busy＿X のいずれか以外のパケットを受け取ると、該ノードからのパケットは既に送信されており、OSR1状態からOSR0状態に遷移する。
【００９３】
さらに、OSR1状態の時に、該ノードが上述のリトライリミットを越えて、リトライを行なった場合、この通信は失敗し、該ノードは、OSR1状態からOSR0状態に遷移する。
【００９４】
図５の状態遷移図は、オプションのデュアルフェイズリトライを実装した、本実施の形態における送信ノードが、他ノードにパケットを送信した後に、busyを受け取った時の振舞いの、一例を示している。
【００９５】
図５に示すノードは、Initialize、又は、Reset のトランザクション制御パケットを、ノードコントローラから受信した場合、他の状態からODR0状態に遷移する。このとき、該ノードは、他ノードにパケットを送信する準備ができており、上述のリトライコードをretry ＿1 に設定して待機する。ODR0状態の場合において、パケットを送信した後に、該ノードがack ＿busy＿A 、ack ＿busy＿B 、ack ＿busy＿X 以外のアクノリッジパケットを受信した場合、既にパケットは送信されており、該ノードが応答する必要はない。
【００９６】
ODR0 状態のとき、ack ＿busy＿A 、または、ack ＿busy＿B のアクノリッジパケットを受けとると、受信ノードはデュアルフェイズリトライノードであり、かつ、busy状態である。この時、該ノードはデュアルフェイズリトライとして、パケットをリトライする。
【００９７】
ODR0状態のとき、ack ＿busy＿A を受け取ると、リトライフェイズA であり、該ノードは、ODR1状態に遷移する。また、ODR0状態のとき、ack ＿busy＿B を受け取ると、リトライフェイズB であり、該ノードは、ODR2状態に遷移する。
【００９８】
ODR0状態のとき、ack ＿busy＿X のアクノリッジパケットを受けとると、受信ノードはシングルフェイズリトライノードであり、かつ、busy状態である。この時、該ノードはシングルフェイズリトライとして、パケットをリトライする。ODR0状態のとき、ack ＿busy＿X を受け取ると、該ノードは、ODR3状態に遷移する。
【００９９】
ODR1状態のとき、該ノードはリトライフェイズＡであり、解決しなければならない保留中のリトライを有している。また、ODR1状態の時には、最少リトライ周期(minimum retry period)が設定されている。ODR1状態の時に、上記最少リトライ周期を経過するまでの期間は、リトライを行なわないで、ODR1状態に留まっている。
【０１００】
ODR1状態のとき、該ノードは、リトライコードをretry ＿A に設定して、リトライを行なう。ODR1状態のときに、該ノードがアクノリッジパケットを受信した場合、アクノリッジコードがack ＿busy＿A で、かつ、上述した４つのfairness interval タイムアウト期間を経過していない場合には、該ノードはODR1状態に留まり、リトライを繰り返す。
【０１０１】
ODR1状態のときに、ack ＿busy＿A 、または、ack ＿busy＿B 以外のアクノリッジコードを含んだアクノリッジパケットを受信した場合、パケットは既に送信されており、該ノードは、ODR0状態に遷移する。また、上述のタイムアウト期間を経過した場合には、該ノードは、送信に失敗しており、やはりODR0状態に遷移する。
【０１０２】
ODR2状態のとき、該ノードはリトライフェイズＢであり、解決しなければならない保留中のリトライを有している。また、ODR2状態の時には、最少リトライ周期(minimum retry period)が設定されている。ODR2状態の時に、上記最少リトライ周期を経過するまでの期間は、リトライを行なわないで、ODR2状態に留まっている。
【０１０３】
ODR2状態のとき、該ノードは、リトライコードをretry ＿B に設定して、リトライを行なう。ODR2状態のときに、該ノードがアクノリッジパケットを受信した場合、アクノリッジコードがack ＿busy＿B で、かつ、上述した４つのfairness interval タイムアウト期間を経過していない場合には、該ノードはODR1状態に留まり、リトライを繰り返す。
【０１０４】
ODR2状態のときに、ack ＿busy＿A 、または、ack ＿busy＿B 以外のアクノリッジコードを含んだアクノリッジパケットを受信した場合、パケットは既に送信されており、該ノードは、ODR0状態に遷移する。また、上述のタイムアウト期間を経過した場合には、該ノードは、送信に失敗しており、やはりODR0状態に遷移する。
【０１０５】
ODR3状態のとき、該ノードはシングルフェイズリトライを行なう。ODR3状態の時には、最少リトライ周期(minimum retry period)が設定されている。ODR3状態の時に、上記最少リトライ周期を経過するまでの期間は、リトライを行なわないで、ODR3状態に留まっている。ODR3状態のとき、該ノードは、リトライコードをretry ＿に設定して、リトライを行なう。
【０１０６】
ODR3状態のときに、該ノードがアクノリッジパケットを受信した場合、アクノリッジコードがack ＿busy＿で、かつ、上述したリトライリミット越えていない場合には、該ノードはODR3状態に留まり、リトライを繰り返す。
【０１０７】
ODR3状態のときに、ack ＿busy＿X 以外のアクノリッジコードを含んだアクノリッジパケットを受信した場合、パケットは既に送信されており、該ノードは、ODR0状態に遷移する。また、上述のリトライリミットを越えた場合には、該ノードは、送信に失敗しており、やはりODR0状態に遷移する。
【０１０８】
上記のごとく所定のリトライ期間を有する構成にすることにより、本実施の形態の送信ノードは、通信が確実に行なわれることを保証するとともに、バスが混雑した場合にも、受信ノードにおけるbusy状態の頻発を防止し、デッドロックの発生を防ぐことができる。また、上記送信ノードを本実施の形態のソースノードとし、該ノードによりライトトランザクションを行なうことによって、デッドロックの発生を防ぐことができる通信システムを構成できる。
【０１０９】
図６を用いて、ブロードキャスト通信方式を用いたオブジェクトデータの通信手順を説明する。コントローラは、ユーザが選択したソースノードと、デスティネーションノードとの間の接続を行うために、ネゴシエーションを行う。ネゴシエーションには、接続を行うためのパケットを用いる。該パケットは、例えば、asynchronousブロードキャストパケットであり、パケット内のペイロードには、接続の番号を示すコネクションIDが書き込まれている。上記コネクションIDによって、それぞれのノードは、コネクションを識別する。
【０１１０】
コントローラから、上記のネゴシエーションパケットを受け取ったソースノードは、コントローラからの送信コマンドパケットを待機する。一方、上記ネゴシエーションパケットを受け取ったデスティネーションノードは、ソースノードからの、問い合わせのasynchronousブロードキャストパケットを待機する。
【０１１１】
該問い合わせのasynchronousブロードキャストパケットは、ソースノードが、デスティネーションノードに対して、受信準備が整ったかどうかを問い合わせる。上記コントロールノードに対し、ソースノード、及び、デスティネーションノードは、上記ネゴシエーションパケットがブロードキャストパケットであるので、アクノリッジパケットを送出しない。
【０１１２】
上述のネゴシエーションが終わると、コントローラは、ソースノードに、データ送信のためのコマンドパケットを送信する。ソースノードは、上記コマンドパケットがブロードキャストパケットであるので、コントロールノードに対し、アクノリッジパケットを送出しない。
【０１１３】
上記コマンドパケットを受信したソースノードは、デスティネーションノードに対して、問い合わせのasynchronousブロードキャストパケットを送信する。該問い合わせパケットには、上述のコネクションIDが書き込まれている。デスティネーションノードは、上記問い合わせパケットがブロードキャストパケットであるので、ソースノードに対し、アクノリッジパケットを送出しない。
【０１１４】
上記問い合わせパケットを受信すると、デスティネーションノードは、上記問い合わせパケットに書かれているコネクションIDと、上述のネゴシエーションによるコネクションIDとを照合して、該問い合わせパケットが同じコネクションのソースノードからのパケットであるかどうかを判別する。
【０１１５】
上記問い合わせパケットが同じコネクションの場合、デスティネーションノードは、上記問い合わせパケットと同一のコネクションIDと、データ受信用のバッファの容量と、を書き込んだacceptedレスポンスパケットを、asynchronousブロードキャストで送出する。ソースノードは、上記レスポンスパケットがブロードキャストパケットであるので、デスティネーションノードに対し、アクノリッジパケットを送出しない。
【０１１６】
データ転送の際に、ソースノードは、コントローラから指示された、デスティネーションノードのノードオフセットに対してライトトランザクションを行なう。該ライトトランザクションは、Asynchronousブロードキャストパケットを使用して行われる。本実施の形態では、デスティネーションノードは、上記ライトトランザクションごとに、ソースノードに対し、図３に示すアクノリッジパケットを送出し、デスティネーションノードがbusy状態の場合、ソースノードはリトライを行なうことで、データ転送の確実性を保証するようになっている。その際、ソースノードは、図４、または、図５で示される、リトライ動作を行なうことにより、上述のデッドロックの発生を防止する。
【０１１７】
ソースノードは、送信が行なわれるオブジェクトデータ（例えば、静止画像、動画像、テキスト等）を分割(segmentation)してデータを送信する。分割されたデータを、segment dataと称する。segment dataの送信は、１度のブロードキャストトランザクションにて行なわれる。該segment dataのデータ量は、例えば、データを受信するノードの（不図示の)FIFO メモリの容量によって定まるようになっている。
【０１１８】
ソースノードは、上記segment dataを、asynchronousブロードキャストパケットを使用して送信する。一つのsegment dataを含むasynchronousブロードキャストパケットを、segment パケットと称する。
【０１１９】
segment パケットには、上述のコネクションIDと、上記segment dataの順番を示すシークエンス番号とが書かれている。該パケットを受信したデスティネーションノードは、segment パケット内に書かれているコネクションIDと、事前にコントローラによって通知されているコネクションIDとの照合を行なう。
【０１２０】
segment パケット内に書かれているコネクションIDと、事前にコントローラによって通知されているコネクションIDとが一致した場合、デスティネーションノードは、該パケットを受け取り、該パケットと同一のコネクションIDと受信データ中のシークエンス番号とを書き込んだ不図示のレスポンスパケットを、asynchronousブロードキャストを用いて送信する。
【０１２１】
ソースノードは、受信したパケットのコネクションIDによって、自ノードへのパケットを識別する。上述のレスポンス動作は、一つのsegment dataの授受に伴い生ずることになる。
【０１２２】
上述したように、データ授受に先立って、ソースノードからデスティネーションノードへ問い合わせパケットが送信される。デスティネーションノードは、該問い合わせに対するレスポンスパケットを用いて、デスティネーションノード自身が有しているバッファのバッファサイズを通知する。
【０１２３】
上述した例では、１度のsegment dataの送信に伴って、レスポンスパケットの送信が発生しているが、デスティネーションノードが有する上述のバッファがsegment dataによって満たされた後に、デスティネーションノードがレスポンスパケットの送信を行なうように構成しても良い。このように構成した場合には、デスティネーションノードの行なうレスポンス動作の回数を削減できるので、デスティネーションノードを簡略化できる効果がある。
【０１２４】
本実施の形態のデスティネーションノードは、i 番目に受信したsegment パケットのシークエンス番号と、(i+1) 番目に受信したsegment パケットのシークエンス番号とを比較して、データの不整合を監視する。デスティネーションノードは、シークエンス番号に不整合が検出された場合には、再送要求を示すレスポンスパケットを送出することにより、ソースノードに再度segment dataを要求することができる。また、再送要求を示すレスポンスパケットは、再送要求の生じたシークエンス番号を指定できるようになっている。
【０１２５】
一方、ソースノードは、segment パケットを送信した後、デスティネーションノードからのレスポンスを待機する。上述したように、デスティネーションノードからはコネクションIDと、シークエンス番号とが書かれたレスポンスパケットが、Asynchronousブロードキャストパケットで送信される。
【０１２６】
ブロードキャストパケットで送信されるレスポンスパケットには、上記コネクションIDが書き込まれている。この値が、目的のデスティネーションノードとのコネクションを示すコネクションIDと一致した場合、該パケットはレスポンスパケットである。該レスポンスパケットを受信するとソースノードは、シークエンス番号をインクリメントし、次のsegment パケットを同様に送信する。上述の手順を繰り返すことにより、ソースノードは、データ転送を行なう。
【０１２７】
ソースノードが、デスティネーションノードからのレスポンスを待機する時間は、あらかじめ定められており、この周期をレスポンス周期と称する。i 番目のsegment パケットを送信した後、レスポンス周期を越えてもレスポンスが受信できない場合、ソースノードは、上記i 番目のsegment パケットと同一のsegment パケットを再送する。
【０１２８】
また、上述したような、デスティネーションノードからの再送要求レスポンスを受信した場合、ソースノードは、該レスポンスパケットにて指定されたシークエンス番号のsegment パケットを送信する。本実施の形態では、上記手順により、バスリセットの発生や何らかのエラーの発生により、データ転送が中断した場合にも、データ転送の復帰が容易に行なえるといった効果がある。
【０１２９】
全てのsegment パケットを送信することによって、データ転送が終了すると、ソースノードは、segment end を示すブロードキャストパケットを送出する。このパケットを受け取ったコントローラは、コネクションIDを解放して、データ転送が終了する。
【０１３０】
本実施の形態では、segment end を受信したコントローラが、明示的にコネクションIDを解放している。しかしながら、segment end を示すパケットがブロードキャストパケットであることから、該segment end パケットにより、デスティネーションノードが、データ転送の終了を検知することが可能である。このため、コネクションID、解放をデスティネーションノードが行なっても良い。
【０１３１】
確実にデータを転送するためには、バスリセットの発生や何らかのエラーの発生により、データ転送中が中断した場合にも、速やかに該データ転送が再開されることが望ましい。上述したように、本実施の形態では、再送要求の手順を設けることで該問題点を解決している。
【０１３２】
例えば、シークエンス番号がｉであった時に、データ転送が中断した場合、まず、各ノードは規格で定められた手順でバスの再構築を行う。バスの再構築が完了した後、デスティネーションノードは、destination ＿offset、コネクションID、及び、シークエンス番号ｉを書き込んだ再送要求パケット(resend request)を、ブロードキャストパケットで送信する。
【０１３３】
データ転送の再開が可能な場合には、ソースノードは、acceptedレスポンスを返す。その後、ソースノードは受信したパケットのコネクションIDを照合し、要求されたシークエンス番号の以降、すなわち、シークエンス番号(i+1) で始まるデータ列のデータを順次ブロードキャストパケットで送信する。
【０１３４】
上述の手順により、ソースノード、デスティネーションノード、コントローラノードはそれぞれノードIDを考慮することなく、データ転送が中断しても、その後のデータ転送を容易に、かつ、確実に再開することができる。また、上述のように、本実施の形態では、データ転送が中断した場合にも、コントローラの制御手順が簡略化できる効果がある。
【０１３５】
本実施の形態においては、上記のネゴシエーションパケット、コマンドパケット、問い合わせパケット、レスポンスパケットに対しては、アクノリッジパケットを送出せず、リトライを行なわないように記述しているが、上記のパケットに対し、アクノリッジパケットを送出し、リトライを行うように構成しても良いことはいうまでもない。
【０１３６】
次に、図７を用いて、上述のAsynchronousブロードキャストパケットについて説明する。本実施の形態に係るAsynchronousブロードキャストパケットは、例えば、4 byte (32 bits 、以下クアッドレットと称する) を単位とするデータパケットである。
【０１３７】
Asynchronous パケットにおいて、最初の16 bits はdestination ＿IDフィールドであり、該フィールドは受信先のノードIDを示す。本実施の形態のように、ブロードキャストを行なう場合には、このフィールドの値はFFFF16である。次の6 bitsのフィールドは、トランザクション・ラベル(tl)フィールドであり、各トランザクション固有のタグである。次の2 bitsのフィールドは、リトライ(rt)コードであり、パケットがリトライを試みるかどうかを指定する。
【０１３８】
次の4 bitsのフィールドは、トランザクションコード(tcode) である。tcode は、パケットのフォーマットや、実行しなければならないトランザクションのタイプを指定する。本実施の形態においては、例えば、この値が00012 である、データブロックの書き込みリクエストのトランザクションを用いる。
次の4 bitsのフィールドは、プライオリティ(pri) フィールドであり、優先順位を指定する。本実施の形態においては、Asynchronousパケットを用いているので、このフィールドの値は00002 である。
【０１３９】
次の16 bits はsource＿IDフィールドであり、送信側のノードIDを示す。次の48 bits はdestination ＿offsetフィールドであり、パケットの受信先ノードアドレスの、下位48 bits がこのフィールドによって指定される。本実施の形態においては、例えば、該destination ＿offsetの値は、後述するconnection＿IDフィールドの値によって定められる。
【０１４０】
次の16 bits はdata＿lengthフィールドであり、後述するデータフィールドの長さを、バイト単位で示している。次の16 bits はextended＿tcode フィールドであり、本実施の形態に用いられるデータブロックの書き込みリクエストトランザクションにおいては、この値は000016である。
【０１４１】
次の32 bits はheader＿CRC フィールドであり、上述したdestination ＿IDフィールドからextended＿tcode フィールドまでを、パケットヘッダと称し、該パケットヘッダのエラー検出に用いられる。
【０１４２】
次の16 bits は、上述したコネクションID(connection ＿ID) フィールドであり、該データによってコネクションを識別する。該コネクションIDによって、(2の 16 乗) × (ノード数) のコネクションを確立することが可能である。よって、本実施の形態では、各コネクションの使用する帯域の総量が、バスの容量に達するまで、コネクション数を増すことができる。
【０１４３】
次の8 bitsは、プロトコルタイプ(protocol ＿type) フィールドであり、該ヘッダ・インフォメーションを用いたデータ授受の手順を示す。本実施の形態の授受手順には、例えば、0116の値が用いられる。次の8 bitsは、コントールフラグ(control＿flags)フィールドであり、制御データが書かれる。コントールフラグフィールドの最上位ビットは、例えば、再送要求(resend ＿request)フラグであり、このビットの値が１の時、データの再送要求が生じていることを示す。
【０１４４】
次の16 bits は、シークエンス番号(sequence ＿number) フィールドである。上述したように、該シークエンス番号フィールドは、特定のコネクションIDにて送受信されるデータパケットに対し、連続的な値が使用される。デスティネーションノードは、該シークエンス番号フィールドによって、有意なデータの連続性を監視し、不一致が生じた場合には、ソースノードに対して再送要求を行なう。
【０１４５】
次の16 bits は、確認応答番号(reconfirmation ＿number) フィールドである。このフィールドは、上述の再送要求フラグの値が１の時のみ、意味を持つフィールドである。上述の再送要求フラグの値が1 の時、このフィールドは、再送要求が生じている開始パケットのシークエンス番号を示す。
【０１４６】
次の16 bits は、バッファサイズ(buffer ＿size) フィールドである。このフィールドには、デスティネーションノードのバッファサイズが書かれる。次の16 bits は、reservedフィールドであり、将来のために予約されている。
【０１４７】
次のフィールドは可変長のデータフィールドであり、該データフィールドをパケットのペイロードと称する。本実施の形態においては、該データフィールドがクアッドレットの倍数でない場合、クアッドレットに満たないビットには０が詰められる。
【０１４８】
次の32 bits のフィールドはdata＿CRC フィールドであり、上述のheader＿CRC フィールドと同様に、上述のヘッダインフォメーションと該データフィールドとのエラー検出に用いられる。なお、data＿CRC フィールドは、データフィールドのみに付けられても良いことはいうまでもない。
【０１４９】
上述のようなパケットを受け取ったノードは、図３に示す、上述のアクノリッジパケットによって、応答を返す。また、上述のようなパケットを受け取ったノードは、図８に示すような、アクノリッジパケットを用いて、応答を返すようにしても良い。
【０１５０】
図８に示すアクノリッジパケットにおいて、アクノリッジパケットの最初の4 bitsはack ＿codeフィールドである。該フィールドによって、上述したack ＿busy＿A 、ack ＿busy＿B 、ack ＿busy＿X などのコードが転送される。該ack ＿codeフィールドの符号化は、上述の図３に示すアクノリッジパケットと同様である。次の4 bitsのフィールドは、ack ＿parityフィールドであり、アクノリッジパケットのパリティチェックビットが格納される。例えば、本実施の形態では、上記ack ＿codeの値の１の補数が格納される。該フィールドは、上記ack ＿codeフィールドのエラー検出に用いられる。
【０１５１】
次の8 bitsのフィールドは、min ＿retry ＿periodフィールドである。該フィールドには、上述した最少リトライ周期の値が、例えば、１ミリ秒単位で格納される。例えば、該フィールドの値が0116であった時、該アクノリッジパケットを受信したノードは、上述した最少リトライ周期を、１ミリ秒に設定して、該最少リトライ周期の期間はリトライを返さないように動作する。もちろん、上記min＿retry ＿periodフィールドの設定の単位として、１ミリ秒ではない、他の時間単位を用いることができることはいうまでもない。
【０１５２】
また、該フィールドを設定してアクノリッジパケットを返すノードは、自ノードの負荷状態を監視して、負荷の大きい時には上述の最少リトライ期間の値を大きく、負荷の小さい時には上述の最少リトライ期間の値を小さく設定する。
【０１５３】
ノードの負荷状態は、該ノードに対して行なわれたリトライの数や、該ノードに対して送信されているパケットの数、該ノードのバッファの占有状態、該ノードが有している接続の数など、様々な指標を用いることが可能である。もちろん、ノードの負荷状態を検出する指標は、上記に限定されるものではなく、負荷状態が検出できれば良いことはいうまでもない。
【０１５４】
さらに、上記min ＿retry ＿periodフィールドの値を0016に設定することを、特別の意味に用いることも可能である。例えば、min ＿retry ＿periodフィールドの値が0016の時には、標準(default）として最少リトライ周期を100 ミリ秒に設定する。
【０１５５】
もちろん、標準(default) として最少リトライ周期は、100 ミリ秒に限定されるものではなく、他の値に設定されるようになっていても良いことはいうまでもない。また、他の実施の形態として、min ＿retry ＿periodフィールドの値が0016の時には、リトライを返すノードができるだけ早くリトライを返す、いわゆる、即座のリトライ(immediately retry）を行なうように設定しても良い。
【０１５６】
図９は、上記の最少リトライ周期を設定する動作を示すダイアグラムである。図９(a) は、ライトリクエストを行なうソースノードと、該リクエストに対しアクノリッジパケットを返すデスティネーションノードとの間の、パケットの授受を示す動作フローであり、図９(b) は、上記デスティネーションノードの負荷状態の時間変化を示すグラフである。図９(b) において、左から右方向は上記デスティネーションノードの負荷状態を示し、上から下方向は時間経過を示す。
【０１５７】
図９において、上記ソースノードが第一のライトリクエスト(write request #１）を行なった時点(t1)では、上記デスティネーションノードの負荷は、比較的小さい状態である(L1)とともに、busy状態である。デスティネーションノードは、例えば、上記min ＿retry ＿periodの値を3216に設定してack ＿busy＿X のアクノリッジパケットを返す。
【０１５８】
ソースノードは、該アクノリッジパケットの上記min ＿retry ＿periodの値から、最少リトライ周期を50ミリ秒に設定する。ソースノードは、最少リトライ周期の期間はリトライを行なわず、少なくとも、50ミリ秒の後にリトライを行なう(retry  #1) 。図９においては、該リトライは成功し、該ライトトランザクションが完了する。
【０１５９】
次に、上記ソースノードが第二のライトリクエスト(write request #2)を行なった時点(t2)では、上記デスティネーションノードの負荷は、比較的大きい状態である(L2)とともに、busy状態である。デスティネーションノードは、例えば、上記min ＿retry ＿periodの値をB416に設定してack ＿busy＿X のアクノリッジパケットを返す。
【０１６０】
ソースノードは、該アクノリッジパケットの上記min ＿retry ＿periodの値から、最少リトライ周期を180 ミリ秒に設定する。ソースノードは、最少リトライ周期の期間はリトライを行なわず、少なくとも、180 ミリ秒の後にリトライを行なう(retry #2)。
【０１６１】
上記のごとく動作することにより、本実施の形態では、アクノリッジパケット送出するノードが、動的に最少リトライ周期を設定することにより、通信が確実に行なわれることを保証するとともに、バスが混雑した場合にも、busy状態の頻発を防止し、デッドロックの発生を防ぐことのできる通信システムを提供できる効果がある。また、上記のごとく動作することにより、本実施の形態では、動的に上記最少リトライ周期を設定できるので、通信リソースを適切に配分でき、リトライを行なうノードが通信路を占有しないので、通信効率を向上させることができる効果がある。
【０１６２】
（本発明の他の実施形態）
本発明は複数の機器（例えば、ホストコンピュータ、インタフェース機器、リーダ、プリンタ等）から構成されるシステムに適用しても１つの機器からなる装置に適用しても良い。
【０１６３】
また、上述した実施形態の機能を実現するように各種のデバイスを動作させるように、上記各種デバイスと接続された装置あるいはシステム内のコンピュータに対し、上記実施形態の機能を実現するためのソフトウェアのプログラムコードを供給し、そのシステムあるいは装置のコンピュータ（ＣＰＵあるいはＭＰＵ）に格納されたプログラムに従って上記各種デバイスを動作させることによって実施したものも、本発明の範疇に含まれる。
【０１６４】
また、この場合、上記ソフトウェアのプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコード自体、およびそのプログラムコードをコンピュータに供給するための手段、例えばかかるプログラムコードを格納した記憶媒体は本発明を構成する。かかるプログラムコードを記憶する記憶媒体としては、例えばフロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０１６５】
また、コンピュータが供給されたプログラムコードを実行することにより、上述の実施形態の機能が実現されるだけでなく、そのプログラムコードがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等の共同して上述の実施形態の機能が実現される場合にもかかるプログラムコードは本発明の実施形態に含まれることは言うまでもない。
【０１６６】
さらに、供給されたプログラムコードがコンピュータの機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに格納された後、そのプログラムコードの指示に基づいてその機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって上述した実施形態の機能が実現される場合にも本発明に含まれることは言うまでもない。
【０１６７】
【発明の効果】
本発明によれば、バスが混雑した場合にも、busy状態の頻発を防止することができ、デッドロックの発生を防ぐことができる。
【図面の簡単な説明】
【図１】本発明の実施の形態のデータ通信システムの構成を表すブロック図である。
【図２】本発明の実施の形態で使用されるasynchronousパケットの一般的な構造を示す図である。
【図３】本発明の実施の形態で使用されるアクノリッジパケットの構造を示す図である。
【図４】本発明の実施の形態におけるシングルフェイズリトライにおける送信ノードの動作の一例を示す状態遷移図である。
【図５】本発明の実施の形態におけるデュアルフェイズリトライにおける送信ノードの動作の一例を示す状態遷移図である。
【図６】本発明の実施の形態のブロードキャスト通信を用いたデータ転送手順のダイアグラムを示す図である。
【図７】本発明の実施の形態のブロードキャスト通信に用いられるデータパケットの構造を示す図である。
【図８】本発明の実施の形態に用いられる最少リトライ周期を設定するためのアクノリッジパケットの構造を示す図である。
【図９】本発明の実施の形態における最少リトライ周期を設定する動作のダイアグラムを示す図である。
【図１０】従来のパケット受信ノードの動作を示す状態遷移図である。
【図１１】従来のパケット送信ノードの動作を示す状態遷移図である。
【符号の説明】
10  computer
12  演算処理装置 (MPU)
14  第一の1394インターフェイス
16  キーボードなど第一の操作部
18  第一のデコーダ
20   CRTディスプレイなどの表示装置
22  ハードディスク
24  第一のメモリ
26   PCIバスなどのコンピュータ内部バス
28   VCR
30  撮像光学系
32   A/D変換器
34  ビデオ処理部
36  圧縮伸長回路
38  第二のメモリ
40  第三のメモリ
42  第一のデータセレクタ
44  第二の1394インターフェイス
46  第一のメモリ制御回路
48  第二のメモリ制御回路
50  システムコントローラ
52  第二の操作部
54  電子ビューファインダ
56   D/A変換器
58  記録部
60  プリンタ
62  第三の1394インターフェイス
64  第二のデータセレクタ
66  第三の操作部
68  プリンタコントローラ
70  第二のデコーダ
72  第四のメモリ
74  画像処理部
76  ドライバ
78  プリンタヘッド
【図１】
0004065466.tif 000004
【図２】
0004065466.tif 000005
【図３】
0004065466.tif 000006
【図４】
0004065466.tif 000007
【図５】
0004065466.tif 000008
【図６】
0004065466.tif 000009
【図７】
0004065466.tif 000010
【図８】
0004065466.tif 000011
【図９】
0004065466.tif 000012
【図１０】
0004065466.tif 000013
【図１１】
0004065466.tif 000014