JP3647815B2 - 通信方法および通信装置 - Google Patents
通信方法および通信装置 Download PDFInfo
- Publication number
- JP3647815B2 JP3647815B2 JP2002066010A JP2002066010A JP3647815B2 JP 3647815 B2 JP3647815 B2 JP 3647815B2 JP 2002066010 A JP2002066010 A JP 2002066010A JP 2002066010 A JP2002066010 A JP 2002066010A JP 3647815 B2 JP3647815 B2 JP 3647815B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- node
- destination
- bus
- information
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/26—Special purpose or proprietary protocols or architectures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Description
【発明の属する技術分野】
本発明は、受け取ったパケット中の所定条件を具備するパケットのみを上位層に通知する通信方法および通信装置に関する。
【0002】
【従来の技術】
IEEE1394−1995、IEEE1394a−2000は高速シリアルバスの規格で、非同期転送(Asynchronous)と同期転送(Isochronous)の2種類の転送をサポートしている。
【0003】
バスに接続されたノード間で非同期転送が行なわれる場合、リード要求ノードからリード要求パケットが送出され、リード応答ノードからリード応答パケットが送出される。リード要求パケットのヘッダ部分およびリード応答パケットのヘッダ部分の双方にデスティネイションID(destination_ID:パケットを受け取るべきノードのID)が格納されている。
【0004】
バスに接続されている各ノードのリンク層では、バス上にパケットが存在すれば、物理層インタフェースを介してそのパケットを受け取り、そのパケットのヘッダ部分に格納されているデスティネイションIDと各ノードを識別するID(自己ノードID)とが一致するかを判定する。
【0005】
両IDが一致する場合、パケット内の情報が上位層であるトランザクション(Transaction)層に通知される。
【0006】
【発明が解決しようとする課題】
しかしながら、従来の技術には下記のような2つの問題点がある。まず、第1の問題点について説明する。IEEE1394では、ケーブルの挿抜によってノードの接続状態が変化するとバスリセットが発生し、各ノードのノードIDが変化する。各ノードの新たなノードIDは、ケーブルの挿抜によって発生するバスリセット後に続くツリー識別、自己識別の過程で決定される。また、全てのノードは機器の製造者等を特定するためにEUI−64といわれる64ビットの重複のないデータをコンフィギュレーションROM内の特定アドレス領域に格納している。
【0007】
IEEE1394をサポートしているWindows2000のようなOSでは、バスリセット、ツリー識別、自己識別が完了すると、その後にバス上の各ノードは他のノードを識別するために、自己以外の全ノードのEUI−64をリードする。特定ノードの特定アドレスへのリードトランザクションは、パケットのヘッダ部分にノードを特定するデスティネイションIDとアドレスを特定するデスティネイション・オフセットを格納して、リード要求パケットを送信することで開始する。これを受信したノードは、要求されたアドレスのデータをリード応答パケットに格納して返信する。かかるリード要求パケットの送信およびリード応答パケットの返信によって、リードトランザクションが終了する。バスリセット、ツリー識別、自己識別完了後、各ノードが、“全ノード数−1”個のリードトランザクションを送出する。
【0008】
例えば、第1ノード、第2ノードおよび第3ノードが存在する場合、(1)第2ノードをデスティネイションIDとするリード要求パケットと、第3ノードをデスティネイションIDとするリード要求パケットとが、第1ノードから送出され、(2)第3ノードをデスティネイションIDとするリード要求パケットと、第1ノードをデスティネイションIDとするリード要求パケットとが、第2ノードから送出され、(3)第1ノードをデスティネイションIDとするリード要求パケットと、第2ノードをデスティネイションIDとするリード要求パケットとが、第3ノードから送出される。つまり、合計6個のリード要求パケットが送出される。
【0009】
IEEE1394の上位プロトコル(例:AV/C(Audio-Video/Control)、SBP(Serial Bus Protocol)−2、DPP(Direct print protocol))を使用して、バスリセット前に特定の2ノード間でデータのやり取りを行っていた場合、バスリセット後にはノードIDが変化する可能性があるので、バスリセット後に各ノードのEUI−64値をリードして、バスリセット前にやり取りを行っていた相手ノードを探すことになっている。この場合も、やり取りしていた相手ノードのEUI−64値を記憶しておいて、かかるEUI−64値と同一のEUI−64値を有するノードが見つかるまでEUI−64値をリード対象とするリードトランザクションを繰り返す。該当するEUI−64値を有するノードを見つけたら、バスリセットによって中断されたトランザクションの続きを再開することができる。
【0010】
バス上に63ノード存在していて、各ノードがバスリセット後に、ノードIDを“0”から“全てのノード数−1”に変化させながら、EUI−64の格納されているアドレスを指定したリードトランザクションを全てのノードについて行うとすると、62×63回のリードトランザクションが行われることになる。
【0011】
このようにバスリセット後は、EUI−64のリードトランザクションによりバスが混雑する可能性が高い。また、多数のノードからリードトランザクションを受けるとハングアップする可能性があるノードが存在する場合、バスリセット後のEUI−64リードトランザクションの際にハングアップが発生する可能性が高い。
【0012】
次に、第2の問題点について説明する。前記の如く、従来のリンク層は自己ノードIDとバス上のパケットのヘッダに含まれるデスティネイションIDとを比較して、両IDが一致するパケットのみをTransaction層に通知する、つまり受信する。このため、例えば任意のノードaが特定のノードbの状態を知りたい場合、ノードa発ノードb宛てリード要求パケットがノードbに到達し、かつノードb発ノードa宛てリード応答パケットがノードaに到達しなければならない。ノードa以外のノード(例えば、ノードc)がノードbにリード要求パケットを送り、ノードbからノードc宛てリード応答パケットがバスに送出されたとしても、ノードaのリンク層はノードc宛てリード応答パケットを上位層へ通知しない。ノードaが必要とする情報を有するリード応答パケットがノードaのリンク層に届いても、かかるリード応答パケットがノードa宛ではないという理由によって、ノードaの上位層へは通知されない。
【0013】
この結果、例えばあるノードbに対して上位アプリケーションで接続状態を確立できるノード数が決まっており、かつ接続状態を確立できる最大数のノードが既にノードbにログインしているために、ノードaがノードbにログインできない場合、ノードbと既に接続状態を確立しているノードのいずれかがその接続状態を解消するまで、ノードaはノードbの状態を確認するためにリードトランザクションを繰り返さなければならない。
【0014】
【課題を解決するための手段】
本発明の第1の特徴は、パケットを送受信し、所定のパケットに関する情報を上位層へ通知する通信方法であって、(a)第1パケットが第1条件を満たすかを調べて、前記第1パケットの情報を記憶するか否かを判断し、(b)記憶すると判断した場合に前記第1パケットから第2条件として使用する情報を抽出し、(c)第2パケットが前記第2条件を満たすかを調べて、前記第2パケットの情報を上位層に通知するか否かを判断し、(d)通知すると判断した場合に前記第2パケットの情報を上位層に通知することにある。
【0015】
かかる第1の特徴により、第1条件を満たす第1パケットから抽出された情報を、第2パケットを上位層へ通知するか否かを判断するための第2条件の一部または全部として使用することが可能となる。
【0016】
【発明の実施の形態】
以下、図面に基づいて本発明の実施形態について説明する。なお、重複記載を避けるために、同一または類似の構成要素には、同一または類似の参照番号を付して説明を省略する。
【0017】
図1に示すように、後述する実施形態において送受信されるリード要求パケットは、デスティネイション(destination)ID、トランザクションラベル(tlabel)、リトライコード(rt)、トランザクションコード(tcode)、プライオリティ(pri)、ソース(source)ID、デスティネイション・オフセット(destination offset)およびヘッダ(header)CRCの各フィールドを有する。
【0018】
図2に示すように、後述する実施形態において送受信されるリード応答パケットは、デスティネイションID、トランザクションラベル、リトライコード、トランザクションコード、プライオリティ、ソースID、レスポンスコード(rcode)、予約(reserved)、クアドレット(quadlet data)およびヘッダCRCの各フィールドを有する。
【0019】
図3に示すように、後述する実施形態におけるプロトコル層は、物理層、リンク層、トランザクション層、シリアルバス管理層および上位プロトコル層から成る。上位プロトコルには、AV/C(Audio Video Control)、SBP (Serial Bus Protocol) −2、DPP(Direct Print Protocol)が含まれる。
【0020】
図4に示すように、後述する実施形態において、バスリセットが発生すると(S1)、ツリー構造の識別(S3)、自己識別(S5)およびEUI−64リード(S7)が行われる。バスリセットは、ケーブルの挿抜などによって発生する。ツリー構造の識別によって、全ノードの各ポートが親ポートまたは子ポートとして特定される。ツリー構造の識別プロセスが完結すると、自己識別プロセスが始まる。自己識別中、各ノードから自己IDパケットが送信され、ノードIDとバス上のノード数が確定する。そして、ノードの機器を特定するEUI−64(拡張固有識別子)をリードすることで、ノードIDと機器の関連付けをする。EUI−64は、ノードベンダーID(node_vendor_ID)、チップIDハイ(chip_id_hi)およびチップIDロー(chip_id_lo)を連結することで生成される64ビットの値である。
【0021】
図5に示すように、自己識別後、各ノードにID番号が割り当てられる。図5は、ID=10のノードの子ポートとID=5、6および9のノードの親ポートとが接続され、ID=5のノードの子ポートとID=3および4のノードの親ポートが接続され、ID=3のノードの子ポートとID=1および2のノードの親ポートが接続され、ID=1のノードの子ポートとID=0のノードの親ポートが接続され、ID=9のノードの子ポートとID=8のノードの親ポートが接続され、ID=8のノードの子ポートとID=7のノードの親ポートが接続されている例を示す。
【0022】
図6に示すように、1024個まであるバスの一つ一つに64個のノードで構成されるグループを割り当てる。各ノードは、256Tバイトのアドレス空間を持つ。各アドレス空間は、初期メモリ空間、プライベート空間および初期レジスタ空間に分割される。初期レジスタ空間は、CSR(Control and Status Register)アーキテクチャ空間、シリアルバス空間、コンフィギュレーションROM空間および初期ユニット空間に分割される。コンフィギュレーションROM空間内に、EUI−64が記憶される。
【0023】
図7に示すように、ID=5のノードからID=0のノードへリード要求パケットが送出されると、ID=0のノードからID=5のノードへリード応答パケットが送出される。同様に、ID=6のノードからID=0のノードへリード要求パケットが送出されると、ID=0のノードからID=6のノードへリード応答パケットが送出される。また、ID=9のノードからID=0のノードへリード要求パケットが送出されると、ID=0のノードからID=9のノードへリード応答パケットが送出される。さらに、ID=3のノードからID=0のノードへリード要求パケットが送出されると、ID=0のノードからID=3のノードへリード応答パケットが送出される。そして、ID=0のノードから送出される上記4つのリード応答パケットに含まれるEUI−64のデータは同一である。後述する実施形態においては、このような同一データを含む複数パケットの送出を不要にすることが可能になる。
【0024】
図8に示すように、後述する実施形態において送受信されるライト要求パケットは、デスティネイションID、トランザクションラベル、リトライコード、トランザクションコード、プライオリティ、ソースID、デスティネイション・オフセット、クアドレットデータおよびヘッダCRCの各フィールドを有する。
【0025】
<第1の実施形態>
第1の実施形態では、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、各ノードのノードIDとEUI−64の対応関係を上位層へ通知することを可能とする。
【0026】
図9は本発明の第1の実施形態におけるパケット送受信装置の構成を示すブロック図であり、図10は本発明の第1の実施形態における処理の流れを示すフローチャートであり、図11はノードIDとEUI−64とをレジスタに格納した状態を示す図である。
【0027】
図9に示すように、リンク層は、PHY(物理層)インタフェース110、抽出部120、一致判定部130、制御部140、記憶部150、受信FIFO170、ホストインタフェース180、送信FIFO190を含む。
【0028】
抽出部120は、バス上のパケットからデスティネイションID、デスティネイション・オフセット(送出先オフセット)、トランザクションコード、ソースID、トランザクションラベルを抽出する。これら用語の内容は、IEEE1394で定義されている。
【0029】
記憶部150は、自己ノードID、EUI−64のアドレス、リード要求コード、リード応答コード、デスティネイションID、デスティネイション・オフセット、ソースID、トランザクションラベル等を記憶する。記憶部150としては、スタティック・ランダム・アクセス・メモリ(SRAM)、ダイナミック・ランダム・アクセス・メモリ(DRAM)などが使用可能である。デスティネイションID、デスティネイション・オフセット等を物理的に1つのメモリに記憶させても良く、また物理的に分離した2以上のメモリに記憶させても良い。
【0030】
一致判定部130は、例えばバス上のパケットから抽出されたデスティネイションIDと記憶部150に記憶されている自己ノードIDとを比較し、両IDが一致したかどうかを示す信号を出力する。
【0031】
制御部140は、抽出部120にバス上のパケットから何を抽出させるか、記憶部150に何を記憶させるか、一致判定部130に何と何を比較させるかを制御する。制御部140が抽出部120等をどのように制御するかの具体的内容は図10のフローチャートに基づいて以下に説明する。
【0032】
自己ノードID、EUI−64アドレス、リード要求トランザクションコードおよびリード応答トランザクションコードは、記憶部150に予め記憶されている。
【0033】
図10に示すように、まずflag=0を設定する(ステップS101)。具体的には、記憶部のflagレジスタに0を書き込む。そして、バス上にパケットが存在するかを調べる(ステップS103)。
【0034】
ステップS103の結果がYESであるなら、パケットのデスティネイションIDが自己ノードIDと一致するかを調べる(ステップS105)。具体的には制御部140が、抽出部120にバス上のパケットからデスティネイションIDを抽出させ、一致判定部130に抽出されたデスティネイションIDと記憶されている自己ノードIDとを比較させる。
【0035】
ステップS105の結果がYESであるなら、パケット内の情報をTransaction層に通知する(ステップS107)。つまり、受信FIFO170に受信イネーブル(Enable)信号を送る。
【0036】
ステップS105の結果がNOであるなら、バス上のパケットのデスティネイション・オフセットがEUI−64のアドレスであり、かつバス上のパケットのトランザクションコードがリード要求か(第1条件)を調べる(ステップS109)。具体的には、制御部140が、抽出部120にバス上のパケットからデスティネイション・オフセットとトランザクションコードを抽出させ、一致判定部130に(1)抽出されたデスティネイション・オフセットと記憶されているEUI−64のアドレスとを比較させ、(2)抽出されたトランザクションコードと記憶されているリード要求コードとを比較させる。
【0037】
ステップS109の結果がYESであるなら、バス上のパケット(第1パケット)のデスティネイションID、ソースID、トランザクションラベルを記憶し、かつflagに1を設定する(ステップS111)。具体的には、制御部140が、抽出部140にバス上のパケット(第1パケット)からデスティネイションID 、ソースID、トランザクションラベルを抽出させ、記憶部150のflagレジスタに1を、デスティネイションIDレジスタに抽出されたデスティネイションIDを、sourceレジスタに抽出されたソースIDを、トランザクションラベルレジスタに抽出されたトランザクションラベルを書き込む。そして、ステップS103に戻り、ステップS105、S109が繰り返される。
【0038】
ステップS109の結果がNOであるなら、(1)flag=1であり、かつ(2)バス上のパケットが、ステップS111で記憶されたリード要求パケットに対するリード応答パケットか(第2条件)を調べる(ステップS113)。
【0039】
具体的には、
記憶部150のflagレジスタに1が書き込まれているかを調べ、
抽出部120に、バス上のパケット(第2パケット)からデスティネイションID、ソースID、トランザクションラベル、トランザクションコードを抽出させ、
一致判定部130に、(1)バス上の第2パケットのデスティネイションIDとステップS111で記憶された第1パケットのソースIDとを比較させ、(2)バス上の第2パケットのソースIDとステップS111で記憶された第1パケットのデスティネイションIDとを比較させ、(3)バス上の第2パケットのトランザクションラベルとステップS111で記憶された第1パケットのトランザクションラベルとを比較させ、(4)バス上の第2パケットのトランザクションコードと予め記憶されているリード応答コードとを比較させる。
【0040】
ステップS113の結果がNOであるなら、バス上のパケットを無視する(ステップS115)。
【0041】
ステップS113の結果がYESであるなら、バス上の第2パケット内の情報を上位層に通知し、flagの値を0に戻す(ステップS117)。具体的には、受信FIFO170に受信Enable信号を送り、記憶部150にflag=0を書き込む。
【0042】
ステップS117後に、バス上のリード応答パケット内のソースID(図11に示すノードID)とEUI―64の値が図11に示すように関連付けられて記憶部150のノードID/EUI−64対応表レジスタに記憶される。かかる処理を繰り返すことによって、バス上の全ノードのノードIDとEUI−64の値との対応表を作成することができる。
【0043】
上記の如く、第1の実施形態では、他ノード宛てリード応答パケットであっても、デスティネイション・オフセットがEUI―64のアドレスであるリード要求パケットに対するリード応答パケットについては上位層へ通知する。その結果、各ノードが他のノードの情報を取得するためにバス上で送受信されなければならないパケット数が減少する。
【0044】
例えば、第1のノードaと、第2のノードbと、第3のノードcとがバスを介してパケットを送受信することによって、各ノードが他のノードに関する情報を取得する場合を考える。従来はバスリセット後に下記の12個のパケットがバスに送出されていた。
【0045】
(1)ノードaからノードbへのリード要求パケット、
(2)ノードbからノードaへのリード応答パケット、
(3)ノードaからノードcへのリード要求パケット、
(4)ノードcからノードaへのリード応答パケット、
(5)ノードbからノードcへのリード要求パケット、
(6)ノードcからノードbへのリード応答パケット、
(7)ノードbからノードaへのリード要求パケット、
(8)ノードaからノードbへのリード応答パケット、
(9)ノードcからノードaへのリード要求パケット、
(10)ノードaからノードcへのリード応答パケット、
(11)ノードcからノードbへのリード要求パケット、
(12)ノードbからノードcへのリード応答パケット。
【0046】
しかし、第1の実施形態によれば、バスリセット後に下記の6個のパケットがバスに送出されるだけで良い。
【0047】
(1)ノードaからノードbへのリード要求パケット、
(2)ノードbからノードaへのリード応答パケット、
(3)ノードaからノードcへのリード要求パケット、
(4)ノードcからノードaへのリード応答パケット、
(5)ノードbからノードaへのリード要求パケット、
(6)ノードaからノードbへのリード応答パケット。
【0048】
なぜなら、ノードbからノードaへのリード応答パケットは、ノードbに関する情報を、ノードaに通知するのみならず、ノードcにも通知するからである。また、ノードcからノードaへのリード応答パケットは、ノードcに関する情報を、ノードaに通知するのみならず、ノードbにも通知するからである。さらに、ノードaからノードbへのリード応答パケットは、ノードaに関する情報を、ノードbに通知するのみならず、ノードcにも通知するからである。
【0049】
上記の如く、第1の実施形態によれば、バスリセット後に各ノードが他の全てのノードに関する情報を取得するためにバスに送出されるパケット総数が減少するので、バスの混雑を緩和することができる。そして、パケット総数が減少すれば、各ノードが他のノードに関する情報を取得するまでに必要とする時間が短縮される。その結果、実際のデータを転送する状態に早く移ることができる。実際のデータとは、各ノード間の接続関係等を把握するために送受信されるデータではなく、各ノード間の接続関係等が把握された後に送受信されるデータを言い、映像データや音声データなどが含まれる。また、複数のノードからリードトランザクションを受けるとハングアップしてしまうような機器に関しては、リードトランザクションが減少する結果、ハングアップの確率が減る。
【0050】
<第2の実施形態>
第2の実施形態では、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、バスリセット前にパケットを送受信していたノードのノードIDを上位層へ通知することを可能とする。具体的には、バスリセットの前後で変化しないEUI−64の値に基づいて、バスリセット前にパケットを送受信していたノードのバスリセット後のノードIDを上位層へ通知する。
【0051】
図12は本発明の第2の実施形態におけるパケット送受信装置の構成を示すブロック図であり、図13は本発明の第2の実施形態における処理の流れを示すフローチャートである。
【0052】
自己ノードID、EUI−64アドレス、リード要求トランザクションコードおよびリード応答トランザクションコードは、記憶部に予め記憶されている。
【0053】
図13に示すように、第2の実施形態では、まずEUI−64レジスタに値を設定する(ステップS201)。具体的には、バスリセット直前に受け取ったパケットを送出したノードのEUI−64の値を記憶部250のEUI−64レジスタに記憶する。前記の如く、バスリセットの前後で、各ノードのノードIDは変化しうるが、EUI−64の値は変化しない。
【0054】
次に、flagに0を設定し(ステップS203)、バス上にパケットが存在するかを調べ(ステップS205)、パケットが存在する場合はそのパケットのデスティネイションIDが自己ノードIDと一致するかを調べる(ステップS207)。
【0055】
ステップS207の結果がYESであるなら、パケット内の情報をTransaction層に通知する(ステップS209)。
【0056】
ステップS207の結果がNOであるなら、バス上のパケットのデスティネイション・オフセットがEUI−64のアドレスであり、かつバス上のパケットのトランザクションコードがリード要求であるか(第1条件)を調べる(ステップS211)。
【0057】
ステップS211の結果がYESであるなら、バス上のパケット(第1パケット)のデスティネイションID、ソースID、トランザクションラベルを記憶し、かつflagに1を設定する(ステップS213)。そして、ステップS205に戻り、ステップS207、S211が繰り返される。
【0058】
ステップS211の結果がNOであるなら、(1)flag=1であり、かつ(2)バス上のパケット(第2パケット)が、記憶されたリード要求パケットに対するリード応答パケットであり、かつ(3)バス上のパケット(第2パケット)のEUI―64の値がEUI―64レジスタに設定された値と一致するか(第2条件)を調べる(ステップS215)。
【0059】
具体的には、
記憶部250のflagレジスタに1が書き込まれているかを調べ、
抽出部120に、バス上のパケット(第2パケット)からデスティネイションID、ソースID、トランザクションラベル、トランザクションコードを抽出させ、
一致判定部130に、(1)バス上の第2パケットから抽出されたデスティネイションIDとステップS213で記憶された第1パケットのソースIDとを比較させ、(2)バス上の第2パケットから抽出されたソースIDとステップS213で記憶された第1パケットのデスティネイションIDとを比較させ、(3)バス上の第2パケットから抽出されたトランザクションラベルとステップS213で記憶された第1パケットのトランザクションラベルとを比較させ、(4)バス上の第2パケットから抽出されたトランザクションコードと予め記憶されているリード応答コードとを比較させ、(5)バス上の第2パケットのEUI―64の値とステップS201でEUI―64レジスタに設定された値とを比較させる。
【0060】
ステップS215の結果がNOであるなら、バス上のパケットを無視する(ステップS217)。
【0061】
ステップS215の結果がYESであるなら、バス上のパケットのソースIDを上位層に通知し、flagを0に戻す(ステップS219)。
【0062】
第2の実施形態によれば、他ノード宛てリード応答パケットを格納することによって、バスリセット直前にパケットをやり取りしていた相手方ノードを見つけ出すことができる。
【0063】
例えば、第1のノードaと、第2のノードbと、第3のノードcとが存在し、かつバスリセット直前にノードaとノードbとがパケットをやり取りしていたとする。そして、バスリセットによってノードIDが変化し、ノードaがノードxとなり、ノードbがノードyとなり、ノードcがノードzとなったとする。バスリセットによって中断されたパケットのやり取りを再開するためには、ノードxはバスリセット前のノードbがバスリセット後にノードyとなったたことを認識する必要がある。
【0064】
バスリセットによって各ノードのノードIDは変化しうるが、EUI−64の値は変化しないので、ノードxはノードbのEUI―64の値とノードyのEUI―64の値とを比較することによって、ノードyがバスリセット前のノードbであることを認識しうる。
【0065】
従来はノードxがノードyのEUI―64の値を知るためには、デスティネイション・オフセットがEUI―64アドレスであるノードy宛てリード要求パケットをノードxがバスに送出し、このリード要求パケットに対してノードyがノードx宛てリード応答パケットをバスに送出する必要があった。
【0066】
しかし、第2の実施形態によれば、ノードxは、(1)ノードzからバスに送出されたノードy宛てリード要求パケットのデスティネイション・オフセットがEUI―64のアドレスであること、および(2)このリード要求パケットに対してノードyからバスに送出されたノードz宛てリード応答パケットのクアドレットデータとバスリセット前に記憶しておいたノードbのEUI―64の値とが一致することを確認することによって、ノードyがバスリセット前のノードbであることを認識しうる。
【0067】
上記の如く、第2の実施形態によれば、(1)デスティネイション・オフセットがEUI―64のアドレスであることをリード要求パケットの受信条件とし、(2−1)このリード要求パケットに対するリード応答パケットであること、および(2−2)かかるリード応答パケットのクアドレットデータが特定の値(EUI―64レジスタに設定されている値と等しい値)であることをリード応答パケットの受信条件とすることによって、他ノード宛てリード応答パケットからバスリセット直前にパケットを送受信していたノードのノードIDを知ることができる。また、複数のノードからリードトランザクションを受けるとハングアップしてしまうような機器に関しては、リードトランザクションが減少する結果、ハングアップの確率が減る。
【0068】
<第3の実施形態>
第3の実施形態では、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、特定の上位プロトコルをサポートするノードのノードIDを上位層へ通知することを可能とする。
【0069】
図14は本発明の第3の実施形態におけるパケット送受信装置の構成を示すブロック図であり、図15は本発明の第3の実施形態における処理の流れを示すフローチャートであり、図16は本発明の第3の実施形態におけるコンフィギュレーションROMの構成を示す図である。
【0070】
自己ノードID、コンフィギュレーションROMアドレス、リード要求トランザクションコードおよびリード応答トランザクションコードは、記憶部350に予め記憶されている。
【0071】
図15に示すように、第3の実施形態では、まず上位プロトコルレジスタに値を設定する(ステップS301)。具体的には、キー・タイプ、キー・ヴァリュウ、使用したい上位プロトコルをプロトコルレジスタに設定する。かかるレジスタの設定内容が同じプロトコルをサポートするノードを探し出すために使用される。キー・タイプはエントリー・ヴァリュウ(entry_value)の特性を定義し、キー・ヴァリュウは各ROMディレクトリ項目の内容と名前を特定する。コンフィギュレーションROMの構成例を図16に示す。例えば”0x12”を2進数で表した”00010010”の上位2ビット”00”がキー・タイプを、下位6ビット”010010”がキー・ヴァリュウを表す。
次に、flagに0を設定し(ステップS303)、バス上にパケットが存在するかを調べ(ステップS305)、バス上にパケットが存在する場合はそのパケットのデスティネイションIDが自己ノードIDと一致するかを調べる(ステップS307)。
【0072】
ステップS307の結果がYESであるなら、パケット内の情報をTransaction層に通知する(ステップS309)。
【0073】
ステップS307の結果がNOであるなら、バス上のパケットのデスティネイション・オフセットがコンフィギュレーション ROMのアドレスであり、かつトランザクションコードがリード要求か(第1条件)を調べる(ステップS311)。
【0074】
ステップS311の結果がYESであるなら、バス上のパケット(第1パケット)のデスティネイションID、ソースID、トランザクションラベルを記憶し、かつflagに1を設定する(ステップS313)。そして、ステップS305に戻り、ステップS307、S311が繰り返される。
【0075】
ステップS311の結果がNOであるなら、(1)flag=1であり、かつ(2)バス上のパケット(第2パケット)がステップS313で記憶されたリード要求パケットに対するリード応答パケットであり、かつ(3)バス上のパケット(第2パケット)のデータがステップS301で上位プロトコルレジスタに設定された値と一致するか(第2条件)を調べる(ステップS315)。
【0076】
具体的には、
記憶部350のflagレジスタに1が書き込まれているかを調べ、
抽出部120に、バス上のパケット(第2パケット)からデスティネイションID、ソースID、トランザクションラベル、トランザクションコード、データを抽出させ、
一致判定部130に、(1)バス上の第2パケットから抽出されたデスティネイションIDとステップS313で記憶された第1パケットのソースIDとを比較させ、(2)バス上の第2パケットから抽出されたソースIDとステップS313で記憶された第1パケットのデスティネイションIDとを比較させ、(3)バス上の第2パケットから抽出されたトランザクションラベルとステップS313で記憶された第1パケットのトランザクションラベルとを比較させ、(4)バス上の第2パケットから抽出されたトランザクションコードと予め記憶されているリード応答コードとを比較させ、(5)バス上の第2パケットのデータとステップS301で設定された上位プロトコルレジスタの値とを比較させる。
【0077】
ステップS315の結果がNOであるなら、バス上のパケットを無視する(ステップS317)。
【0078】
ステップS315の結果がYESであるなら、バス上のパケットのソースIDを上位層に通知し、flagを0に戻す(ステップS319)。
【0079】
図16に示すように、コンフィギュレーションROMには、EUI−64以外にも機器の性能を示す情報が格納されている。上位プロトコル(AV/C、SBP−2、DPP等)のサポート状態などもそういった情報の1つである。
【0080】
上記の如く、第3の実施形態によれば、(1)デスティネイション・オフセットがコンフィギュレーション ROMのアドレスであることをリード要求パケットの受信条件とし、(2−1)このリード要求パケットに対するリード応答パケットであること、および(2−2)クアドレットデータに含まれるキー・タイプとキー・ヴァリュウが特定の値であることをリード応答パケットの受信条件とすることによって、他ノード宛てリード応答パケットであっても、特定の上位プロトコルをサポートするノードのノードIDをソースIDとするリード応答パケットについては上位層へ通知することができる。
【0081】
<第4の実施形態>
第4の実施形態では、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、特定のノードの状態を上位層へ通知することを可能とする。ノードの状態とは、所定の処理を実施中であるとか、所定の処理を終了したという状態を言い、例えばプリント処理が終了したという状態が含まれる。
【0082】
図17は本発明の第4の実施形態におけるパケット送受信装置の構成を示すブロック図であり、図18は本発明の第4の実施形態における処理の流れを示すフローチャートである。
【0083】
自己ノードID、リード要求トランザクションコードおよびリード応答トランザクションコードは、記憶部450に予め記憶されている。
【0084】
図18に示すように、第4の実施形態では、まずデスティネイションIDとデスティネイション・オフセットを設定する(ステップS401)。具体的には、状態を知りたいノードのノードIDを記憶部450のデスティネイションIDレジスタに記憶させ、状態を知りたいノードの状態レジスタのアドレスを記憶部450のデスティネイション・オフセットレジスタに記憶させる。
【0085】
次に、flagに0を設定し(ステップS403)、バス上にパケットが存在するかを調べ(ステップS405)、パケットが存在する場合はそのパケットのデスティネイションIDが自分のノードIDと一致するかを調べる(ステップS407)。
【0086】
ステップS407の結果がYESであるなら、パケット内の情報をTransaction層に通知する(ステップS409)。
【0087】
ステップS407の結果がNOであるなら、(1)バス上のパケットのデスティネイションID とデスティネイション・オフセットとがステップS401でレジスタに記憶されたデスティネイションID とデスティネイション・オフセットとにそれぞれ一致し、かつ(2)バス上のパケットのトランザクションコードがリード要求であるか(第1条件)を調べる(ステップS411)。
【0088】
ステップS411の結果がYESであるなら、バス上のパケット(第1パケット)のデスティネイションID、ソースID、トランザクションラベルを記憶し、かつflagに1を設定する(ステップS413)。そして、ステップS405に戻り、ステップS407、S411が繰り返される。
【0089】
ステップS411の結果がNOであるなら、(1)flag=1であり、かつ(2)バス上のパケットがステップS413で記憶されたリード要求パケットに対するリード応答パケットであるか(第2条件)を調べる(ステップS415)。
【0090】
具体的には、
記憶部450のflagレジスタに1が書き込まれているかを調べ、
抽出部120に、バス上のパケット(第2パケット)からデスティネイションID、ソースID、トランザクションラベル、トランザクションコードを抽出させ、
一致判定部130に、(1)バス上の第2パケットから抽出されたデスティネイションIDとステップS413で記憶された第1パケットのソースIDとを比較させ、(2)バス上の第2パケットから抽出されたソースIDとステップS413で記憶された第1パケットのデスティネイションIDとを比較させ、(3)バス上の第2パケットから抽出されたトランザクションラベルとステップS413で記憶された第1パケットのトランザクションラベルとを比較させ、(4)バス上の第2パケットから抽出されたトランザクションコードと予め記憶されているリード応答コードとを比較させる。
【0091】
ステップS415の結果がNOであるなら、バス上のパケットを無視する(ステップS417)。
【0092】
ステップS415の結果がYESであるなら、バス上の第2パケットの状態の情報を上位層に通知し、flagを0に戻す(ステップS419)。
【0093】
上記の如く、第4の実施形態によれば、(1)デスティネイションIDが特定のノードを示すこと、およびデスティネイション・オフセットが状態レジスタのアドレスであることとをリード要求パケットの受信条件とし、(2)このパケットに対する返答であることをリード応答パケットの受信条件とすることによって、他ノード宛てリード応答パケットであっても、特定のノードIDの状態レジスタから読み出されたクアドレットデータを包含しているリード応答パケットについては上位層へ通知することができる。
【0094】
<第5の実施形態>
第5の実施形態も、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、特定のノードの状態を上位層へ通知することを可能とする。上記第1から第4の実施形態では他ノード宛てリード応答パケットから必要な情報を取得する。しかし、第5の実施形態では、他ノード宛てライト要求パケットまたはロック要求パケットから必要な情報を取得する。
【0095】
図19は本発明の第5の実施形態におけるリンク層の構成を示すブロック図であり、図20は本発明の第5の実施形態における処理の流れを示すフローチャートである。
【0096】
第5の実施形態は、あるノード(例えば、ノードb)に対して上位アプリケーションで接続状態を確立できるノード数が決まっていて、接続状態を確立できるノード数の最大数のノードが既にログインされているので、ログインできていない他のノード(例えば、ノードa)が空きを待っている状態に関する。
【0097】
自己ノードIDおよびライト要求トランザクションコードは、記憶部550に予め記憶されている。状態を知りたいノードには、同時に接続可能な最大数のノードが既に接続をしているものとする。
【0098】
図20に示すように、第5の実施形態では、まずデスティネイションIDとデスティネイション・オフセットを設定する(ステップS501)。具体的には、状態を知りたいノードのIDをデスティネイションIDレジスタに、状態を知りたいノードのログイン/ログアウトレジスタのアドレスをデスティネイション・オフセットレジスタに記憶させる。
【0099】
次に、バス上にパケットが存在するかを調べ(ステップS503)、パケットが存在する場合はそのパケットのデスティネイションIDが自己ノードIDと一致するかを調べる(ステップS505)。
【0100】
ステップS505の結果がYESであるなら、パケット内の情報をTransaction層に通知する(ステップS507)。
【0101】
ステップS505の結果がNOであるなら、バス上のパケットのデスティネイションID とデスティネイション・オフセットとがステップS501でレジスタに記憶されたデスティネイションID とデスティネイション・オフセットとにそれぞれ一致し、かつバス上のパケットがライト要求パケットかを調べる(ステップS509)。
【0102】
ステップS509の結果がNOであるなら、バス上のパケットを無視する(ステップS511)。
【0103】
ステップS509の結果がYESであるなら、状態の情報を上位層に通知する(ステップS513)。ここで「状態の情報」とは、ライト要求パケットによって書き込まれるデータのことである。ただし、書き込まれるデータの単位が1クアドレット(32bit)であって、1クアドレット以上のデータが書き込まれる場合、1つのライト要求パケットによって書き込まれるデータは、全データの一部となる。
【0104】
上記の如く、第5の実施形態によれば、デスティネイションIDが特定のノードを示すこと、およびデスティネイション・オフセットが特定のアドレスを指定することをライト要求パケットの受信条件とすることによって、他ノード宛てライト要求パケットであっても、特定ノードの特定アドレスに対するライト要求パケットについては当パケット内のクアドレットデータを上位層へ通知することができる。これによって、ある特定のノードbに対して上位アプリケーションで接続状態を確立できるノード数が決まっていて、かつ接続状態を確立できるノード数だけ既にログインされているので、ノードaはノードbにログインしているノードのいずれかがログアウトするのを待っている状態であっても、ノードaはノードbの特定のアドレスの値を知ることができる。
【0105】
<第5の実施形態の変形例>
図21は本発明の第5の実施形態の変形例におけるパケット送受信装置の構成を示すブロック図であり、図22は本発明の第5の実施形態の変形例における処理の流れを示すフローチャートである。
【0106】
図22に示すステップS521、S525、S527、S529はそれぞれ、図20に示すステップS501、S503、S505、S507と同じであるから、説明を省略する。また、図22に示すステップS523では、flagに0を設定する。
【0107】
ステップS527の結果がNOであるなら、バス上のパケットのデスティネイションID とデスティネイション・オフセットとがステップS521でレジスタに記憶されたデスティネイションID とデスティネイション・オフセットとにそれぞれ一致し、かつバス上のパケットのトランザクションコードを抽出し、そのトランザクションコードが記憶部に記憶されているロック要求トランザクションコードと一致するか(第1条件)を調べる(ステップS531)。
【0108】
ステップS531の結果がYESであるなら、バス上のパケット(第1パケット)のデスティネイションID、ソースID、トランザクションラベルを記憶し、かつflagに1を設定する(ステップS533)そして、ステップS525に戻り、ステップS527、S531が繰り返される。
【0109】
ステップS531の結果がNOであるなら、(1)flag=1であり、かつ(2)バス上のパケット(第2パケット)がステップS533で記憶されたロック要求パケットに対するロック応答パケットであるか(第2条件)を調べる(ステップS535)。
【0110】
具体的には、
記憶部650のflagレジスタに1が書き込まれているかを調べ、
抽出部120に、バス上のパケット(第2パケット)からデスティネイションID、ソースID、トランザクションラベル、トランザクションコードを抽出させ、
一致判定部130に、(1)バス上の第2パケットから抽出されたデスティネイションIDとステップS533で記憶された第1パケットのソースIDとを比較させ 、(2)バス上の第2パケットから抽出されたソースIDとステップS533で記憶された第1パケットのデスティネイションIDとを比較させ、(3)バス上の第2パケットから抽出されたトランザクションラベルとステップS533で記憶された第1パケットのトランザクションラベルとを比較させ、(4)バス上の第2パケットから抽出されたトランザクションコードと予め記憶されているロック応答コードとを比較させる。
【0111】
ステップS535の結果がNOであるなら、バス上の第2パケットを無視する(ステップS537)。
【0112】
ステップS535の結果がYESであるなら、バス上の第2パケットの状態の情報を上位層に通知する(ステップS539)。かかる「状態の情報」は前述のステップS513における「状態の情報」と同じである。
【0113】
上記の如く、第5の実施形態の変形例によれば、(1)デスティネイションIDが特定のノードを示すこと、およびデスティネイション・オフセットが特定のアドレスを指定することをロック要求パケットの受信条件とし、(2)このロック要求パケットに対する応答パケットであることをロック応答パケットの受信条件とすることによって、他ノード宛てロック応答パケットであっても、特定ノードの特定アドレスに関するロック応答パケットについては当パケット内のクアドレットデータを上位層へ通知することができる。これによって、例えばノードaがノードbによってロックされている場合であっても、ノードcはノードa発ノードb宛てロック応答パケットから、ノードaの状態の情報を取得することができる。
【0114】
【発明の効果】
上記の如く本発明の実施形態およびその変形例によれば、各ノードは自分宛ではないパケットであっても、上位層が必要とするパケットを上位層に通知することができる。このため、バスリセット後に構築された各ノードの新たな接続関係等を把握するためにバス上でやり取りされなければならないパケットの総数が減少し、バスの混雑が緩和される。また、そのような接続関係等を把握するために必要なパケット総数が減少すれば、そのような接続関係等の把握が早期に完了するので、実際のデータ転送などの状態に早期に移行することができる。
【図面の簡単な説明】
【図1】本発明の実施形態において送受信されるリード要求パケットのフォーマットを示す図である。
【図2】本発明の実施形態において送受信されるリード応答パケットのフォーマットを示す図である。
【図3】本発明の実施形態において使用されるIEEE1394プロトコルの構成を示す図である。
【図4】バスリセットからEUI−64リードまでの処理の流れを示すフローチャートである。
【図5】自己識別後のバス構成例を示す図である。
【図6】シリアルバスのアドレス指定とEUI−64のアドレスとを示す図である。
【図7】EUI−64リードトランザクションの概念を示す図である。
【図8】本発明の実施形態において使用されるライト要求パケットのフォーマットを示す図である。
【図9】本発明の第1実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図10】本発明の第1実施形態における処理の流れを示すフローチャートである。
【図11】ノードIDとEUI−64の対応表の概念図である。
【図12】本発明の第2実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図13】本発明の第2実施形態における処理の流れを示すフローチャートである。
【図14】本発明の第3実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図15】本発明の第3実施形態における処理の流れを示すフローチャートである。
【図16】コンフィグレーションROMの構成例を示す図である。
【図17】本発明の第4実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図18】本発明の第4実施形態における処理の流れを示すフローチャートである。
【図19】本発明の第5実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図20】本発明の第5実施形態における処理の流れを示すフローチャートである。
【図21】本発明の第5実施形態の変形例にかかるパケット送受信装置の構成を示すブロック図である。
【図22】本発明の第5実施形態の変形例における処理の流れを示すフローチャートである。
【符号の説明】
110 PHYインタフェース
120 抽出部
130 一致判定部
140 制御部
150 記憶部
170 受信FIFO
180 ホストインタフェース
190 送信FIFO
Claims (8)
- パケットを送受信し、所定のパケットに関する情報を上位層へ通知する通信方法であって、
(a)第1パケットのデスティネイション・オフセットが、第1の所定のアドレスを指し示し、
前記第1パケットのトランザクションコードが、リード要求を定義している、という第1条件が満たされるかを調べて、前記第1パケットの情報を記憶するか否かを判断し、
(b)記憶すると判断した場合に前記第1パケットからデスティネイションID、ソースIDおよびトランザクションラベルを抽出し、
(c)第2パケットのデスティネイションIDが、前記第1パケットのソースIDと一致し、
前記第2パケットのソースIDが、前記第1パケットのデスティネイションIDと一致し、
前記第2パケットのトランザクションラベルが、前記第1パケットのトランザクションラベルと一致し、
前記第2パケットのトランザクションコードが、リード応答を定義している、という第2条件が満たされるかを調べて、前記第2パケットの情報を上位層に通知するか否かを判断し、
(d)通知すると判断した場合に前記第2パケットの情報を上位層に通知する、ことを特徴とする。 - 請求項1記載の通信方法であって、前記パケットの送受信がIEEE1394規格に従って行われる。
- 請求項1又は2記載の通信方法であって、前記第1の所定のアドレスが、EUI―64のアドレスである。
- 請求項3記載の通信方法であって、EUI−64の値を予め記憶し、
(c)前記第2条件に、前記第2パケットから送出先ノードに送られるデータの値が、予め記憶した前記EUI−64の値と一致することが含まれる。 - 請求項1ないし4記載の通信方法であって、前記上位層に通知される前記第2パケットの前記情報に前記第2パケットのソースIDが含まれる。
- 請求項1又は2記載の通信方法であって、キー・タイプ、キー・ヴァリュウおよび上位プロトコルを予め記憶し、
(a)前記第1の所定のアドレスが、コンフィギュレーションROMのアドレスであり、
(c)前記第2条件に、前記第2パケットから送出先ノードに送られるデータの値が、予め記憶した前記キー・タイプ、前記キー・ヴァリュウおよび前記上位プロトコルと一致することが含まれる。 - 請求項1又は2記載の通信方法であって、デスティネイションIDおよびデスティネイション・オフセットを予め記憶し、
(a)前記第1条件に、
前記第1パケットのデスティネイションIDが、予め記憶した前記デスティネイションIDと一致し、
前記第1パケットのデスティネイション・オフセットが、予め記憶した前記デスティネイション・オフセットと一致することが含まれる。 - パケットを送受信し、所定のパケットに関する情報を上位層へ通知する通信方法であって、デスティネイションIDおよびデスティネイション・オフセットを予め記憶し、
(a)第1パケットのデスティネイションIDが、予め記憶した前記デスティネイションIDと一致し、
前記第1パケットのデスティネイション・オフセットが、予め記憶した前記デスティネイション・オフセットと一致し、
前記第1パケットのトランザクションコードが、ロック要求を定義している、という第1条件が満たされるかを調べて、前記第1パケットの情報を記憶するか否かを判断し、
(b)前記第2条件として使用する情報が、前記第1パケットのデスティネイションID、ソースIDおよびトランザクションラベルであり、
(c)第2パケットのデスティネイションIDが、前記第1パケットのソースIDと一致し、
前記第2パケットのソースIDが、前記第1パケットのデスティネイションIDと一致し、
前記第2パケットのトランザクションラベルが、前記第1パケットのトランザクションラベルと一致し、
前記第2パケットのトランザクションコードが、ロック応答を定義している、という第2条件が満たされるかを調べて、前記第2パケットの情報を上位層に通知するか否かを判断し、
(d)通知すると判断した場合に前記第2パケットの情報を上位層に通知する、ことを特徴とする。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002066010A JP3647815B2 (ja) | 2002-03-11 | 2002-03-11 | 通信方法および通信装置 |
US10/383,635 US7352742B2 (en) | 2002-03-11 | 2003-03-10 | Method and apparatus for transmitting to an upper layer of information included in a packet |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002066010A JP3647815B2 (ja) | 2002-03-11 | 2002-03-11 | 通信方法および通信装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2003264560A JP2003264560A (ja) | 2003-09-19 |
JP3647815B2 true JP3647815B2 (ja) | 2005-05-18 |
Family
ID=29198038
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002066010A Expired - Fee Related JP3647815B2 (ja) | 2002-03-11 | 2002-03-11 | 通信方法および通信装置 |
Country Status (2)
Country | Link |
---|---|
US (1) | US7352742B2 (ja) |
JP (1) | JP3647815B2 (ja) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005157444A (ja) * | 2003-11-20 | 2005-06-16 | Toshiba Corp | Fifo制御回路 |
US8019779B2 (en) * | 2004-05-04 | 2011-09-13 | International Business Machines Corporation | Efficient locking protocol for sub-document concurrency control using prefix encoded node identifiers in XML databases |
KR20050114021A (ko) * | 2004-05-31 | 2005-12-05 | 엘지전자 주식회사 | 비동기 이동통신시스템의 단문메시지 착신전환방법 |
JP4784245B2 (ja) * | 2005-10-04 | 2011-10-05 | ソニー株式会社 | コンテンツ処理装置,サーバ装置,通信方法およびコンピュータプログラム |
TWI446351B (zh) * | 2010-05-27 | 2014-07-21 | Wistron Corp | 資料寫入方法與電腦系統 |
JP5618805B2 (ja) * | 2010-12-10 | 2014-11-05 | スパンションエルエルシー | 通信装置、ネットワークシステム及び通信方法 |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH07105804B2 (ja) | 1992-04-22 | 1995-11-13 | 宮崎 誠一 | アドレス設定器 |
US6219697B1 (en) | 1997-05-02 | 2001-04-17 | 3Com Corporation | Method and apparatus for operating the internet protocol over a high-speed serial bus |
KR19990044988A (ko) * | 1997-11-25 | 1999-06-25 | 이데이 노부유끼 | 접속 상황 송신 장치, 접속 상황 표시 데이터 작성 장치 및 접속 상황 표시 방법 |
JP2001103076A (ja) | 1999-09-29 | 2001-04-13 | Fujitsu Ltd | Ieee1394バス解析方法及びインタフェース回路 |
US6519544B1 (en) * | 1999-09-29 | 2003-02-11 | Fujitsu Limited | Method and apparatus for IEEE 1394 bus analysis |
JP2001168915A (ja) * | 1999-12-10 | 2001-06-22 | Nec Corp | Ipパケット転送装置 |
US20040213237A1 (en) * | 2000-06-29 | 2004-10-28 | Toshikazu Yasue | Network authentication apparatus and network authentication system |
US7164689B2 (en) * | 2000-12-05 | 2007-01-16 | Matsushita Electric Industrial Co., Ltd. | Multi-initiator control unit and method |
JP2002247094A (ja) * | 2001-02-20 | 2002-08-30 | Pioneer Electronic Corp | パケット送出装置および方法 |
JP4481518B2 (ja) * | 2001-03-19 | 2010-06-16 | 株式会社日立製作所 | 情報中継装置及び転送方法 |
-
2002
- 2002-03-11 JP JP2002066010A patent/JP3647815B2/ja not_active Expired - Fee Related
-
2003
- 2003-03-10 US US10/383,635 patent/US7352742B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US20030210709A1 (en) | 2003-11-13 |
US7352742B2 (en) | 2008-04-01 |
JP2003264560A (ja) | 2003-09-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP0930747A1 (en) | IEEE 1394 Serial bus system using a mapping table for identifying nodes having required capabilities to establish isochronous connections | |
JP4278439B2 (ja) | 情報通信装置、そのシステム、その方法、そのプログラム、および、そのプログラムを記録した記録媒体 | |
US6810452B1 (en) | Method and system for quarantine during bus topology configuration | |
EP1051000B1 (en) | Method and device for allocating at least one routing identifier to at least one bridge in a network | |
US6823408B2 (en) | Electronic equipment, and method for controlling state of physical layer circuit therefor | |
CN100359881C (zh) | 用于通过透明网桥传输分组的地址分配方法和设备 | |
WO2000057283A1 (en) | A method and system for circumscribing a topology to form ring structures | |
JP3647815B2 (ja) | 通信方法および通信装置 | |
US6647446B1 (en) | Method and system for using a new bus identifier resulting from a bus topology change | |
EP1091523B1 (en) | Speed converter for IEEE-1394 serial bus network | |
US6751697B1 (en) | Method and system for a multi-phase net refresh on a bus bridge interconnect | |
US6584539B1 (en) | Method and system for message broadcast flow control on a bus bridge interconnect | |
US6502158B1 (en) | Method and system for address spaces | |
US7580420B2 (en) | Interface circuit connecting a device with a bridge portal function to a communication bus | |
US20010028656A1 (en) | Information signal processing apparatus and method | |
JP3683227B2 (ja) | ローカルバスブリッジ | |
WO2000057263A1 (en) | A method and system for a multi-phase net refresh on a bus bridge interconnect | |
JP4502653B2 (ja) | パケット送受信装置及びそれに用いるパケット識別方法 | |
JP3749625B2 (ja) | ノード管理方法、ネットワークアダプタ、及び記録媒体 | |
JP4529231B2 (ja) | 電子機器 | |
JP4062829B2 (ja) | シリアルインタフェース回路 | |
JP2000013399A (ja) | ネットワーク機器識別方法 | |
JP3365262B2 (ja) | 通信プロトコル処理装置 | |
JP4244474B2 (ja) | 情報処理装置及び方法 | |
KR19990076150A (ko) | 아이 트리플 이 1394 망에서의 노드 아이디 관리방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040816 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040824 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041021 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041116 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050105 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050201 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050209 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080218 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090218 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100218 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100218 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110218 Year of fee payment: 6 |
|
LAPS | Cancellation because of no payment of annual fees |