JP2003069610A - 通信装置、その制御方法、通信システム、及び制御プログラム - Google Patents
通信装置、その制御方法、通信システム、及び制御プログラムInfo
- Publication number
- JP2003069610A JP2003069610A JP2001251763A JP2001251763A JP2003069610A JP 2003069610 A JP2003069610 A JP 2003069610A JP 2001251763 A JP2001251763 A JP 2001251763A JP 2001251763 A JP2001251763 A JP 2001251763A JP 2003069610 A JP2003069610 A JP 2003069610A
- Authority
- JP
- Japan
- Prior art keywords
- credit
- communication device
- communication
- data
- packet
- 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.)
- Pending
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
(57)【要約】
【課題】 簡単なクレジット管理で高速にパケット交換
方式のデータ通信を行えるようにする。 【解決手段】 受信バッファに少なくとも１クレジット
分以上の空きが有る場合は、受信側のクレジット数を
「１」として通知して通信を開始し、データパケットを
受信した場合は、そのデータパケット中のデータを受信
バッファに格納した後も１クレジット分以上の空きがあ
る限りは、擬似的に所定のクレジット空き情報を返信す
る。
方式のデータ通信を行えるようにする。 【解決手段】 受信バッファに少なくとも１クレジット
分以上の空きが有る場合は、受信側のクレジット数を
「１」として通知して通信を開始し、データパケットを
受信した場合は、そのデータパケット中のデータを受信
バッファに格納した後も１クレジット分以上の空きがあ
る限りは、擬似的に所定のクレジット空き情報を返信す
る。
Description
【０００１】
【発明の属する技術分野】本発明は、データ通信技術に
関し、特にパケット交換方式のデータ通信技術に関す
る。
関し、特にパケット交換方式のデータ通信技術に関す
る。
【０００２】
【従来の技術】従来、パケット交換方式を採用したデー
タ通信システムにおいて、受信バッファのオーバーフロ
ーを回避するために、受信側の通信装置は、自己の受信
バッファの空き容量を監視し、受信バッファの空き容量
をオーバーしない範囲のクレジット数（値）を送信側の
通信装置に通知し、送信側の通信装置は、データパケッ
トの連続送信数をクレジット数以下に制限する通信方式
が知られている。
タ通信システムにおいて、受信バッファのオーバーフロ
ーを回避するために、受信側の通信装置は、自己の受信
バッファの空き容量を監視し、受信バッファの空き容量
をオーバーしない範囲のクレジット数（値）を送信側の
通信装置に通知し、送信側の通信装置は、データパケッ
トの連続送信数をクレジット数以下に制限する通信方式
が知られている。
【０００３】この通信方式では、送信側は、データパケ
ットを送信する毎にその送信パケット数分のクレジット
数を減算していき、クレジット数が「０」になった場合
には、送信を停止することで、受信側の受信バッファの
空き容量を越えるデータパケットを連続送信しないよう
にしている。
ットを送信する毎にその送信パケット数分のクレジット
数を減算していき、クレジット数が「０」になった場合
には、送信を停止することで、受信側の受信バッファの
空き容量を越えるデータパケットを連続送信しないよう
にしている。
【０００４】一方、受信側では、データパケットを受信
すると、データを正しく受信したことを送信側へ報告す
るための確認応答パケットを返信している。この確認応
答パケットには、次のパケットのシーケンス番号とクレ
ジット数を含んでいる。
すると、データを正しく受信したことを送信側へ報告す
るための確認応答パケットを返信している。この確認応
答パケットには、次のパケットのシーケンス番号とクレ
ジット数を含んでいる。
【０００５】ここで、クレジット数とは、受信可能なデ
ータ量を示す値であり、具体的には、受信可能なパケッ
ト数に相当している。また、送受信可能な最大のパケッ
ト・サイズは、初期化プロセスの段階で、ネゴシエーシ
ョンによって決定され、クレジット数の上限値は、送受
信可能な最大のパケット・サイズを考慮して決定され
る。
ータ量を示す値であり、具体的には、受信可能なパケッ
ト数に相当している。また、送受信可能な最大のパケッ
ト・サイズは、初期化プロセスの段階で、ネゴシエーシ
ョンによって決定され、クレジット数の上限値は、送受
信可能な最大のパケット・サイズを考慮して決定され
る。
【０００６】さらに、一旦、クレジット数を通知した後
でも、受信バッファ内のデータを読み出して受信バッフ
ァの空き容量が増えた場合には、クレジットを追加して
発行するようにしている。
でも、受信バッファ内のデータを読み出して受信バッフ
ァの空き容量が増えた場合には、クレジットを追加して
発行するようにしている。
【０００７】このような通信方式では、データパケット
の通信速度を上げるために、通常、クレジット数を可能
な限り多くしている。
の通信速度を上げるために、通常、クレジット数を可能
な限り多くしている。
【０００８】
【発明が解決しようとする課題】しかし、クレジット数
を複数にした場合は、通信を開始する際に受信側で発行
すべきクレジット数を決定したり、通信中に受信バッフ
ァの空き状態を監視して、空き容量が増えた場合には、
その空き容量に見合ったクレジット数を算出してクレジ
ットを追加発行したりする必要があるなど、クレジット
の管理が複雑になっていた。
を複数にした場合は、通信を開始する際に受信側で発行
すべきクレジット数を決定したり、通信中に受信バッフ
ァの空き状態を監視して、空き容量が増えた場合には、
その空き容量に見合ったクレジット数を算出してクレジ
ットを追加発行したりする必要があるなど、クレジット
の管理が複雑になっていた。
【０００９】本発明は、簡単なクレジット管理で高速に
パケット交換方式のデータ通信を行えるようにすること
にある。
パケット交換方式のデータ通信を行えるようにすること
にある。
【００１０】
【課題を解決するための手段】上記課題を解決するた
め、本発明は、パケット交換方式でデータ通信を行う通
信装置において、受信メモリに少なくとも１クレジット
分の空き容量が有る場合は、通信開始時に自己のクレジ
ット数を「１」として送信側の通信装置に通知する通知
手段と、前記送信側の通信装置からデータパケットを受
信した場合に、受信に係るデータパケット中のデータを
前記受信メモリに格納した後も該受信メモリに少なくと
も１クレジット分の空き容量が有る限りは、クレジット
空き情報を含む応答パケットを返信する返信手段とを備
えている。
め、本発明は、パケット交換方式でデータ通信を行う通
信装置において、受信メモリに少なくとも１クレジット
分の空き容量が有る場合は、通信開始時に自己のクレジ
ット数を「１」として送信側の通信装置に通知する通知
手段と、前記送信側の通信装置からデータパケットを受
信した場合に、受信に係るデータパケット中のデータを
前記受信メモリに格納した後も該受信メモリに少なくと
も１クレジット分の空き容量が有る限りは、クレジット
空き情報を含む応答パケットを返信する返信手段とを備
えている。
【００１１】また、本発明は、パケット交換方式でデー
タ通信を行う通信装置の制御方法において、受信メモリ
に少なくとも１クレジット分の空き容量が有る場合は、
通信開始時に自己のクレジット数を「１」として送信側
の通信装置に通知し、前記送信側の通信装置からデータ
パケットを受信した場合に、受信に係るデータパケット
中のデータを前記受信メモリに格納した後も該受信メモ
リに少なくとも１クレジット分の空き容量が有る限り
は、クレジット空き情報を含む応答パケットを返信して
いる。
タ通信を行う通信装置の制御方法において、受信メモリ
に少なくとも１クレジット分の空き容量が有る場合は、
通信開始時に自己のクレジット数を「１」として送信側
の通信装置に通知し、前記送信側の通信装置からデータ
パケットを受信した場合に、受信に係るデータパケット
中のデータを前記受信メモリに格納した後も該受信メモ
リに少なくとも１クレジット分の空き容量が有る限り
は、クレジット空き情報を含む応答パケットを返信して
いる。
【００１２】また、本発明は、パケット交換方式でデー
タ通信を行う通信システムにおいて、受信側の通信装置
は、自己の受信メモリに少なくとも１クレジット分の空
き容量が有る場合は、通信開始時に自己のクレジット数
を「１」として送信側の通信装置に通知する通知手段
と、前記送信側の通信装置からデータパケットを受信し
た場合に、受信に係るデータパケット中のデータを前記
受信メモリに格納した後も該受信メモリに少なくとも１
クレジット分の空き容量が有る限りは、クレジット空き
情報を含む応答パケットを返信する返信手段とを備えて
いる。
タ通信を行う通信システムにおいて、受信側の通信装置
は、自己の受信メモリに少なくとも１クレジット分の空
き容量が有る場合は、通信開始時に自己のクレジット数
を「１」として送信側の通信装置に通知する通知手段
と、前記送信側の通信装置からデータパケットを受信し
た場合に、受信に係るデータパケット中のデータを前記
受信メモリに格納した後も該受信メモリに少なくとも１
クレジット分の空き容量が有る限りは、クレジット空き
情報を含む応答パケットを返信する返信手段とを備えて
いる。
【００１３】また、本発明は、パケット交換方式でデー
タ通信を行う通信装置が受信側として機能する場合に実
行される制御プログラムであって、受信側の通信装置の
受信メモリに少なくとも１クレジット分の空き容量が有
る場合は、通信開始時に自己のクレジット数を「１」と
して送信側の通信装置に通知し、前記送信側の通信装置
からデータパケットを受信した場合に、受信に係るデー
タパケット中のデータを前記受信メモリに格納した後も
該受信メモリに少なくとも１クレジット分の空き容量が
有る限りは、クレジット空き情報を含む応答パケットを
返信する内容を有している。
タ通信を行う通信装置が受信側として機能する場合に実
行される制御プログラムであって、受信側の通信装置の
受信メモリに少なくとも１クレジット分の空き容量が有
る場合は、通信開始時に自己のクレジット数を「１」と
して送信側の通信装置に通知し、前記送信側の通信装置
からデータパケットを受信した場合に、受信に係るデー
タパケット中のデータを前記受信メモリに格納した後も
該受信メモリに少なくとも１クレジット分の空き容量が
有る限りは、クレジット空き情報を含む応答パケットを
返信する内容を有している。
【００１４】
【発明の実施の形態】以下、本発明の実施の形態を図面
に基づいて詳細に説明する。
に基づいて詳細に説明する。
【００１５】図１は、本発明を適用した印刷装置の概略
構成を示すブロック図である。
構成を示すブロック図である。
【００１６】本印刷装置は、ホストコンピュータ（図示
省略）から転送されたデータを印刷する機能を有し、イ
ンタフェース部１０００、通信制御部１０１０、受信バ
ッファ１０２０、マイクロプロセッサ１０３０、印字バ
ッファ１０４０、印字制御部１０５０、記録ヘッド１０
６０、ＬＦモータ・ドライバ１０７０、ＬＦモータ１０
８０、ＣＲモータ・ドライバ１０９０、及びＣＲモータ
１１００を有している。
省略）から転送されたデータを印刷する機能を有し、イ
ンタフェース部１０００、通信制御部１０１０、受信バ
ッファ１０２０、マイクロプロセッサ１０３０、印字バ
ッファ１０４０、印字制御部１０５０、記録ヘッド１０
６０、ＬＦモータ・ドライバ１０７０、ＬＦモータ１０
８０、ＣＲモータ・ドライバ１０９０、及びＣＲモータ
１１００を有している。
【００１７】なお、通信制御部１０１０は、マイクロコ
ンピュータにより構成され、ＣＰＵ１０１０ａ、ＲＯＭ
１０１０ｂ、ＲＡＭ１０１０１ｃを有している。ＣＰＵ
１０１０ａは、ＲＡＭ１０１０１ｃをワークエリア等と
して利用しながら、ＲＯＭ１０１０ｂに格納された制御
プログラムに基づいて各種の通信制御を行う。なお、Ｒ
ＯＭ１０１０１ｂには、図１０に示したフローチャート
に対応する制御プログラムも格納されている。
ンピュータにより構成され、ＣＰＵ１０１０ａ、ＲＯＭ
１０１０ｂ、ＲＡＭ１０１０１ｃを有している。ＣＰＵ
１０１０ａは、ＲＡＭ１０１０１ｃをワークエリア等と
して利用しながら、ＲＯＭ１０１０ｂに格納された制御
プログラムに基づいて各種の通信制御を行う。なお、Ｒ
ＯＭ１０１０１ｂには、図１０に示したフローチャート
に対応する制御プログラムも格納されている。
【００１８】また、インタフェース部１０００は、所定
の赤外線通信プロトコルに準拠しているが、この赤外線
通信プロトコルについては、後述する。さらに、受信バ
ッファ１０２０は、複数の論理チャネルに対応する複数
のバッファ０〜ｎにより構成されている。
の赤外線通信プロトコルに準拠しているが、この赤外線
通信プロトコルについては、後述する。さらに、受信バ
ッファ１０２０は、複数の論理チャネルに対応する複数
のバッファ０〜ｎにより構成されている。
【００１９】ホストコンピュータから送信されてきた印
字データ、制御コマンド等を含むパケットは、インタフ
ェース部１０００を介して通信制御部１０１０に転送さ
れる。通信制御部１０１０は、受信したパケット中のヘ
ッダデータを解析して論理チャネル、パケットのサイズ
等を特定し、特定した論理チャネルに対応するバッファ
ｎに、受信したパケット中のデータ（ヘッダデータを除
く）を格納する。
字データ、制御コマンド等を含むパケットは、インタフ
ェース部１０００を介して通信制御部１０１０に転送さ
れる。通信制御部１０１０は、受信したパケット中のヘ
ッダデータを解析して論理チャネル、パケットのサイズ
等を特定し、特定した論理チャネルに対応するバッファ
ｎに、受信したパケット中のデータ（ヘッダデータを除
く）を格納する。
【００２０】マイクロプロセッサ１０３０は、受信バッ
ファ１０２０に格納されたデータを順次読み出して、印
字バッファ１０４０に格納する。印字制御部１０５０
は、マイクロプロセッサ１０３０からの印字制御信号に
基づいて、印字バッファ１０４０からデータを読み出
し、記録ヘッド１０６０に転送する。
ファ１０２０に格納されたデータを順次読み出して、印
字バッファ１０４０に格納する。印字制御部１０５０
は、マイクロプロセッサ１０３０からの印字制御信号に
基づいて、印字バッファ１０４０からデータを読み出
し、記録ヘッド１０６０に転送する。
【００２１】また、マイクロプロセッサ１０３０は、記
録ヘッド１０６０の印字動作、ＬＦモータ・ドライバ１
０７０によるＬＦモータ１０８０の回転制御動作、ＣＲ
モータ・ドライバ１０９０によるＣＲモータ１１００の
回転制御動作等を制御する。図２は、インタフェース部
１０００、及び通信制御部１０１０により通信を行う際
に使用される赤外線通信プロトコルのデータリンク層の
構成を示した図である。
録ヘッド１０６０の印字動作、ＬＦモータ・ドライバ１
０７０によるＬＦモータ１０８０の回転制御動作、ＣＲ
モータ・ドライバ１０９０によるＣＲモータ１１００の
回転制御動作等を制御する。図２は、インタフェース部
１０００、及び通信制御部１０１０により通信を行う際
に使用される赤外線通信プロトコルのデータリンク層の
構成を示した図である。
【００２２】図２に示したように、本赤外線通信プロト
コルのデータリンク層は、ＩｒＬＡＰ（Ｉｎｆｒａｒｅ
ｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）層
Ａ、ＩｒＬＭＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ｍａｎ
ａｇｅｒ Ｐｒｏｔｏｃｏｌ）層Ｂ、ＴｙｎｙＴＰ（Ｉ
ｎｆｒａｒｅｄ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏ
ｌ）層Ｃ、ＩｒＣｏｍ（Ｉｎｆｒａｒｅｄ Ｃｏｍｍｕ
ｎｉｃａｔｉｏｎ）層Ｄにより構成されている。
コルのデータリンク層は、ＩｒＬＡＰ（Ｉｎｆｒａｒｅ
ｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）層
Ａ、ＩｒＬＭＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ｍａｎ
ａｇｅｒ Ｐｒｏｔｏｃｏｌ）層Ｂ、ＴｙｎｙＴＰ（Ｉ
ｎｆｒａｒｅｄ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏ
ｌ）層Ｃ、ＩｒＣｏｍ（Ｉｎｆｒａｒｅｄ Ｃｏｍｍｕ
ｎｉｃａｔｉｏｎ）層Ｄにより構成されている。
【００２３】実際に通信を行う場合は、図３に示したよ
うに、まず、最下層のＩｒＬＡＰ層Ａで送信側、受信側
ともに通信に必要なパラメータの折衝（ネゴシエーショ
ン）を行って、通信を開始する。そして、順に上位層間
のパラメータ折衝が行われ、これら各層でのパラメータ
折衝が完了した後に、データパケット（実データを含む
パケット）の送信、そのデータパケット受信の確認応答
等が行われる。
うに、まず、最下層のＩｒＬＡＰ層Ａで送信側、受信側
ともに通信に必要なパラメータの折衝（ネゴシエーショ
ン）を行って、通信を開始する。そして、順に上位層間
のパラメータ折衝が行われ、これら各層でのパラメータ
折衝が完了した後に、データパケット（実データを含む
パケット）の送信、そのデータパケット受信の確認応答
等が行われる。
【００２４】赤外線通信プロトコルでは、ＴｉｎｙＴＰ
層Ｃにおいてクレジット管理を行っており、ＴｉｎｙＴ
Ｐ層Ｃのパラメータ折衝において、送信側、受信側のク
レジット情報を通告する。送信側は、受信側から通告さ
れたクレジット情報に基づいて、連続送信するパケット
数等を制御する。
層Ｃにおいてクレジット管理を行っており、ＴｉｎｙＴ
Ｐ層Ｃのパラメータ折衝において、送信側、受信側のク
レジット情報を通告する。送信側は、受信側から通告さ
れたクレジット情報に基づいて、連続送信するパケット
数等を制御する。
【００２５】クレジット情報は、受信側の受信メモリ
（受信バッファ）のオーバーフローを防止するためのパ
ラメータなので、送信側は、受信側から通知されたクレ
ジット数を、１つのデータパケットを送信する毎に１ず
つデクリメントし、クレジット数が「０」となっている
間は、送信を停止する。そして、受信側より空いたクレ
ジット数の告知があった時、その値を新たに設定するこ
とで、データパケットの送信を再開する。
（受信バッファ）のオーバーフローを防止するためのパ
ラメータなので、送信側は、受信側から通知されたクレ
ジット数を、１つのデータパケットを送信する毎に１ず
つデクリメントし、クレジット数が「０」となっている
間は、送信を停止する。そして、受信側より空いたクレ
ジット数の告知があった時、その値を新たに設定するこ
とで、データパケットの送信を再開する。
【００２６】次に、クレジットに基づく本実施形態に特
有な通信制御処理を説明するが、本実施形態の特徴を容
易に理解できるようにするため、クレジット数が複数、
及び「１」の場合の従来の通信制御処理を予め説明して
おく。
有な通信制御処理を説明するが、本実施形態の特徴を容
易に理解できるようにするため、クレジット数が複数、
及び「１」の場合の従来の通信制御処理を予め説明して
おく。
【００２７】まず、受信側のクレジット数が複数の場合
における従来の通信の流れを、図４に基づいて説明す
る。
における従来の通信の流れを、図４に基づいて説明す
る。
【００２８】受信側のクレジット数が複数の場合、受信
側（本実施形態では、通信制御部１０１０）は、データ
パケットを受信すると、このデータパケットを正しく受
信した旨を示す確認応答パケットを、送信側に返信す
る。
側（本実施形態では、通信制御部１０１０）は、データ
パケットを受信すると、このデータパケットを正しく受
信した旨を示す確認応答パケットを、送信側に返信す
る。
【００２９】この場合、送信側は、上記のように、受信
側から通知されたクレジット数を、１つのデータパケッ
トを送信する毎に１ずつデクリメントし、クレジット数
が「０」となっている間は、送信を停止しているので、
受信側にとっては、次のデータパケットを連続して受信
できることは明らかである。
側から通知されたクレジット数を、１つのデータパケッ
トを送信する毎に１ずつデクリメントし、クレジット数
が「０」となっている間は、送信を停止しているので、
受信側にとっては、次のデータパケットを連続して受信
できることは明らかである。
【００３０】そこで、通信制御部１０１０は、受信した
パケットの解析が終了していなくても、直ちに、図７に
示したような受信確認のみの応答パケット、すなわちク
レジット情報を含まないＲＲ（Ｒｅｃｅｉｖｅ Ｒｅａ
ｄｙ）レスポンス・パケットを返信する。
パケットの解析が終了していなくても、直ちに、図７に
示したような受信確認のみの応答パケット、すなわちク
レジット情報を含まないＲＲ（Ｒｅｃｅｉｖｅ Ｒｅａ
ｄｙ）レスポンス・パケットを返信する。
【００３１】なお、図７に示した「Ｎｒ」は、送信側に
対して次に送信を期待するパケットの番号を示すビット
であり、このパケット番号としては、最大「７」を設定
することができる。また、「Ｆ」は、この値が「１」の
場合は、本ＲＲレスポンス・パケットの送信側が受信側
に送信権を譲渡することを示し、「０」の場合は、本Ｒ
Ｒレスポンス・パケットの送信側が送信権を保持するこ
とを示すビットである。
対して次に送信を期待するパケットの番号を示すビット
であり、このパケット番号としては、最大「７」を設定
することができる。また、「Ｆ」は、この値が「１」の
場合は、本ＲＲレスポンス・パケットの送信側が受信側
に送信権を譲渡することを示し、「０」の場合は、本Ｒ
Ｒレスポンス・パケットの送信側が送信権を保持するこ
とを示すビットである。
【００３２】このようなデータパケットの送信とＲＲレ
スポンス・パケットの返信を複数回行う。そして、受信
側は、通知したクレジット数に対応する最後のデータパ
ケットを受信すると、確認応答として、図９に示したよ
うなＩ（Ｉｎｆｏｍａｔｉｏｎ）フレームレスポンス・
パケットを返信する。
スポンス・パケットの返信を複数回行う。そして、受信
側は、通知したクレジット数に対応する最後のデータパ
ケットを受信すると、確認応答として、図９に示したよ
うなＩ（Ｉｎｆｏｍａｔｉｏｎ）フレームレスポンス・
パケットを返信する。
【００３３】なお、図９に示した「Ｎｒ」は、送信側に
対して次に送信を期待するパケットの番号を示すビット
であり、このパケット番号としては、最大「７」を設定
することができる。また、「Ｆ」は、この値が「１」の
場合は、本Ｉフレームレスポンス・パケットの送信側が
受信側に送信権を譲渡することを示し、「０」の場合
は、本本Ｉフレームレスポンス・パケットの送信側が送
信権を保持することを示すビットである。
対して次に送信を期待するパケットの番号を示すビット
であり、このパケット番号としては、最大「７」を設定
することができる。また、「Ｆ」は、この値が「１」の
場合は、本Ｉフレームレスポンス・パケットの送信側が
受信側に送信権を譲渡することを示し、「０」の場合
は、本本Ｉフレームレスポンス・パケットの送信側が送
信権を保持することを示すビットである。
【００３４】また、「Ｎｓ」は、本Ｉフレームレスポン
ス・パケットの番号を示すビットである。「Ｃ」は、Ｉ
ｒＬＭＰ層Ｂの制御コマンドであるか、或いはＩｒＬＭ
Ｐ層Ｂより上位の層の制御コマンドであるかを示すビッ
トであり、このビットが「０」の場合はＩｒＬＭＰ層Ｂ
の制御コマンド、「１」の場合はＩｒＬＭＰ層Ｂより上
位の層の制御コマンドであることを示している。
ス・パケットの番号を示すビットである。「Ｃ」は、Ｉ
ｒＬＭＰ層Ｂの制御コマンドであるか、或いはＩｒＬＭ
Ｐ層Ｂより上位の層の制御コマンドであるかを示すビッ
トであり、このビットが「０」の場合はＩｒＬＭＰ層Ｂ
の制御コマンド、「１」の場合はＩｒＬＭＰ層Ｂより上
位の層の制御コマンドであることを示している。
【００３５】また、「ＤＬＳＡＰ−ＳＥＬ」は、あて先
のＬＳＡＰ（ＩｒＬＭＰ層Ｂ以上の層でのアドレス）を
示すビットである。「ｒ」は、予約ビットである。「Ｓ
ＬＳＡＰ−ＳＥＬ」は、発信元のＬＳＡＰ（ＩｒＬＭＰ
層Ｂ以上の層でのアドレス）を示すビットである。
のＬＳＡＰ（ＩｒＬＭＰ層Ｂ以上の層でのアドレス）を
示すビットである。「ｒ」は、予約ビットである。「Ｓ
ＬＳＡＰ−ＳＥＬ」は、発信元のＬＳＡＰ（ＩｒＬＭＰ
層Ｂ以上の層でのアドレス）を示すビットである。
【００３６】「Ｍ」は、データ分割の有無を示すビット
であり、「１」の場合はデータ分割有り、「０」の場合
はデータ分割無しを示している。「Ｄｅｌｔａ Ｃｒｅ
ｄｉｔ」は、受け取れるパケット数、すなわち、受信バ
ッファ（本実施形態では、厳密には、現在確立されてい
る論理チャネルに対応するバッファ）の空き容量に対応
するクレジット数を示すビットである。
であり、「１」の場合はデータ分割有り、「０」の場合
はデータ分割無しを示している。「Ｄｅｌｔａ Ｃｒｅ
ｄｉｔ」は、受け取れるパケット数、すなわち、受信バ
ッファ（本実施形態では、厳密には、現在確立されてい
る論理チャネルに対応するバッファ）の空き容量に対応
するクレジット数を示すビットである。
【００３７】次に、受信側のクレジット数が「１」の場
合における従来の通信の流れを、図５に基づいて説明す
る。
合における従来の通信の流れを、図５に基づいて説明す
る。
【００３８】受信側のクレジット数が「１」の場合、受
信したデータパケットの解析が終了しても、次の新しい
データパケットの受信の準備が出来るまでは、データパ
ケットを受信することが出来ないので、図７に示した受
信確認のみの応答パケット（ＲＲレスポンスパケット）
を返信するしかない。
信したデータパケットの解析が終了しても、次の新しい
データパケットの受信の準備が出来るまでは、データパ
ケットを受信することが出来ないので、図７に示した受
信確認のみの応答パケット（ＲＲレスポンスパケット）
を返信するしかない。
【００３９】従って、送信側は、上記Ｉフレームレスポ
ンス・パケットを受信するまでの間は、図８に示したよ
うな通信の継続を行うための通信継続パケット（ＲＲコ
マンド・パケット）を送り続けることになる。また、受
信側も、受信バッファが空くまでは、ＲＲコマンド・パ
ケットを受信する毎に、ＲＲレスポンス・パケットを返
信することになる。このように、受信側のクレジット数
が「１」の場合は、データパケット以外のパケットの交
信回数が多くなるため、データパケットの通信速度が低
下してしまう。
ンス・パケットを受信するまでの間は、図８に示したよ
うな通信の継続を行うための通信継続パケット（ＲＲコ
マンド・パケット）を送り続けることになる。また、受
信側も、受信バッファが空くまでは、ＲＲコマンド・パ
ケットを受信する毎に、ＲＲレスポンス・パケットを返
信することになる。このように、受信側のクレジット数
が「１」の場合は、データパケット以外のパケットの交
信回数が多くなるため、データパケットの通信速度が低
下してしまう。
【００４０】次に、クレジットを用いた本実施形態にお
ける通信の流れを、図６に基づいて説明する。
ける通信の流れを、図６に基づいて説明する。
【００４１】本実施形態では、少なくともと１クレジッ
ト分の空き容量が受信バッファにあれば、その空き容量
がたとえ複数クレジット分の空き容量であったとして
も、通信開始時の受信クレジット数は、常に「１」に設
定している。
ト分の空き容量が受信バッファにあれば、その空き容量
がたとえ複数クレジット分の空き容量であったとして
も、通信開始時の受信クレジット数は、常に「１」に設
定している。
【００４２】しかし、従来の受信クレジット数が「１」
の場合と異なり、受信側では、データパケットを受信し
た場合に、受信バッファに１クレジット分以上の空き容
量がある限り、その都度、所定のクレジット空き情報を
含むＩフレームレスポンス・パケットを、確認応答とし
て返信するようにしている。
の場合と異なり、受信側では、データパケットを受信し
た場合に、受信バッファに１クレジット分以上の空き容
量がある限り、その都度、所定のクレジット空き情報を
含むＩフレームレスポンス・パケットを、確認応答とし
て返信するようにしている。
【００４３】この場合、図４と図６を比較すれば明らか
なように、データパケットの送信頻度は同一になる。従
って、通信開始時の受信バッファの空き容量がクレジッ
ト数の上限値の範囲内であれば、本実施形態の場合は、
Ｉフレームレスポンス・パケットの方がＲＲレスポンス
・パケットよりサイズが大きい分だけ通信速度がわずか
に遅くなるだけで、従来の複数のクレジット数の場合と
ほぼ同等の通信速度を実現することができる。
なように、データパケットの送信頻度は同一になる。従
って、通信開始時の受信バッファの空き容量がクレジッ
ト数の上限値の範囲内であれば、本実施形態の場合は、
Ｉフレームレスポンス・パケットの方がＲＲレスポンス
・パケットよりサイズが大きい分だけ通信速度がわずか
に遅くなるだけで、従来の複数のクレジット数の場合と
ほぼ同等の通信速度を実現することができる。
【００４４】次に、本発明の実施形態におけるクレジッ
ト管理処理を、図１０のフローチャートに基づいて説明
する。なお、フローチャートは、受信側のクレジット数
として、「１」を既に送信側に通知していることを前提
としている。
ト管理処理を、図１０のフローチャートに基づいて説明
する。なお、フローチャートは、受信側のクレジット数
として、「１」を既に送信側に通知していることを前提
としている。
【００４５】通信制御部１０１０のＣＰＵ１０１０ａ
は、ＲＯＭ１０１０ｂに格納された制御プログラムに基
づいて、まず、受信したパケットが、実データを含むデ
ータパケットであるか否かを判別する（ステップＳ
１）。その結果、受信したパケットがデータパケットで
あれば、そのデータパケットを解析部へ転送する（ステ
ップＳ２）。なお、本実施形態では、解析部は、ソフト
ウェアにより構成されており、ステップＳ２では、解析
ルーチンにデータパケットを引き渡している。
は、ＲＯＭ１０１０ｂに格納された制御プログラムに基
づいて、まず、受信したパケットが、実データを含むデ
ータパケットであるか否かを判別する（ステップＳ
１）。その結果、受信したパケットがデータパケットで
あれば、そのデータパケットを解析部へ転送する（ステ
ップＳ２）。なお、本実施形態では、解析部は、ソフト
ウェアにより構成されており、ステップＳ２では、解析
ルーチンにデータパケットを引き渡している。
【００４６】次に、解析終了を待つことなく、受信バッ
ファ、すなわち、受信バッファ１０２０内のバッファ０
〜ｎのうち、現在確立されている論理チャネルに対応す
るバッファに１クレジット分以上の空き容量が有るか否
かを判別する（ステップＳ３）。この場合、実際には、
前述のネゴシエーションで決定された最大パケットサイ
ズ以上の空き容量があるか否かを判別する。また、今回
受信したデータパケット中のデータを上記バッファに格
納した後の状態で空き容量の有無を判別する。
ファ、すなわち、受信バッファ１０２０内のバッファ０
〜ｎのうち、現在確立されている論理チャネルに対応す
るバッファに１クレジット分以上の空き容量が有るか否
かを判別する（ステップＳ３）。この場合、実際には、
前述のネゴシエーションで決定された最大パケットサイ
ズ以上の空き容量があるか否かを判別する。また、今回
受信したデータパケット中のデータを上記バッファに格
納した後の状態で空き容量の有無を判別する。
【００４７】その結果、受信バッファに１クレジット分
以上の空き容量が有れば、応答パケットに所定のクレジ
ット空き情報を加えて転送して、すなわち、図９に示し
たようなＩフレームレスポンス・パケットを送信側に返
信して（ステップＳ４）、終了する。一方、受信バッフ
ァに１クレジット分以上の空き容量が無ければ、通信制
御部１０１０の内部的な処理のためにクレジット数が
「０」である旨を設定する（ステップＳ５）。そして、
図７に示したような受信確認のみの応答パケット（ＲＲ
レスポンス・パケット）を返信し（ステップＳ６）、終
了する。
以上の空き容量が有れば、応答パケットに所定のクレジ
ット空き情報を加えて転送して、すなわち、図９に示し
たようなＩフレームレスポンス・パケットを送信側に返
信して（ステップＳ４）、終了する。一方、受信バッフ
ァに１クレジット分以上の空き容量が無ければ、通信制
御部１０１０の内部的な処理のためにクレジット数が
「０」である旨を設定する（ステップＳ５）。そして、
図７に示したような受信確認のみの応答パケット（ＲＲ
レスポンス・パケット）を返信し（ステップＳ６）、終
了する。
【００４８】ステップＳ１にて、受信したパケットがデ
ータパケットでないと判別された場合は、受信バッフ
ァ、すなわち、受信バッファ１０２０内のバッファ０〜
ｎのうち、現在確立されている論理チャネルに対応する
バッファに１クレジット分以上の空き容量が有るか否か
を判別する（ステップＳ７）。
ータパケットでないと判別された場合は、受信バッフ
ァ、すなわち、受信バッファ１０２０内のバッファ０〜
ｎのうち、現在確立されている論理チャネルに対応する
バッファに１クレジット分以上の空き容量が有るか否か
を判別する（ステップＳ７）。
【００４９】この場合、実際には、前述のネゴシエーシ
ョンで決定された最大パケットサイズ以上の空き容量が
あるか否かを判別する。また、この場合は、今回受信し
たパケットは、データパケットではなく、バッファにデ
ータを格納する必要はないので、ステップＳ３の場合の
ように、今回受信したデータパケット中のデータを上記
バッファに格納した後の状態を考える必要はない。ただ
し、上記バッファのデータのうち、既に読み出されたデ
ータの量は当然のことながら考慮する必要がある。
ョンで決定された最大パケットサイズ以上の空き容量が
あるか否かを判別する。また、この場合は、今回受信し
たパケットは、データパケットではなく、バッファにデ
ータを格納する必要はないので、ステップＳ３の場合の
ように、今回受信したデータパケット中のデータを上記
バッファに格納した後の状態を考える必要はない。ただ
し、上記バッファのデータのうち、既に読み出されたデ
ータの量は当然のことながら考慮する必要がある。
【００５０】ステップＳ７にて、１クレジット分以上の
空き容量があると判別された場合は、現在、クレジット
数が「０」である旨が設定されているか否かを判別する
（ステップＳ８）。その結果、クレジット数が「０」で
ある旨が設定されていれば、現在確立されている論理チ
ャネルに対応するバッファのデータが読み出されて、当
該バッファに空きができたことを意味するので、クレジ
ット数が「０」である旨の設定を解除する（ステップＳ
９）。そして、応答パケットに所定のクレジット空き情
報を加えて転送して、すなわち、図９に示したようなＩ
フレームレスポンス・パケットを送信側に返信して（ス
テップＳ１０）、終了する。
空き容量があると判別された場合は、現在、クレジット
数が「０」である旨が設定されているか否かを判別する
（ステップＳ８）。その結果、クレジット数が「０」で
ある旨が設定されていれば、現在確立されている論理チ
ャネルに対応するバッファのデータが読み出されて、当
該バッファに空きができたことを意味するので、クレジ
ット数が「０」である旨の設定を解除する（ステップＳ
９）。そして、応答パケットに所定のクレジット空き情
報を加えて転送して、すなわち、図９に示したようなＩ
フレームレスポンス・パケットを送信側に返信して（ス
テップＳ１０）、終了する。
【００５１】一方、ステップＳ７にて、受信バッファに
空きが無いと判別された場合、及びステップＳ８にて、
クレジット数が「０」である旨が設定されていないと判
別された場合は、図７に示したような受信確認のみの応
答パケット（ＲＲレスポンス・パケット）を返信して
（ステップＳ１１）、終了する。
空きが無いと判別された場合、及びステップＳ８にて、
クレジット数が「０」である旨が設定されていないと判
別された場合は、図７に示したような受信確認のみの応
答パケット（ＲＲレスポンス・パケット）を返信して
（ステップＳ１１）、終了する。
【００５２】なお、ステップＳ４，Ｓ１０におけるクレ
ジット空き情報は、複数クレジットの場合のように、実
際の受信バッファの空き容量に対応したクレジット数で
ある必要はなく、空きが有る旨を示す一定の情報、例え
ば、クレジット数「１」を示す１ビットの情報でよい。
従って、従来の複数クレジットの場合のように、受信バ
ッファの空き容量に見合ったクレジット数を算出する必
要はなく、クレジットの管理が簡単になる。
ジット空き情報は、複数クレジットの場合のように、実
際の受信バッファの空き容量に対応したクレジット数で
ある必要はなく、空きが有る旨を示す一定の情報、例え
ば、クレジット数「１」を示す１ビットの情報でよい。
従って、従来の複数クレジットの場合のように、受信バ
ッファの空き容量に見合ったクレジット数を算出する必
要はなく、クレジットの管理が簡単になる。
【００５３】このように、本発明では、受信バッファに
少なくとも１クレジット分以上の空きが有る場合は、受
信側のクレジット数を「１」として通知して通信を開始
し、データパケットを受信した場合は、そのデータパケ
ット中のデータを受信バッファに格納した後も１クレジ
ット分以上の空きがある限りは、擬似的に所定のクレジ
ット空き情報を返信するようにしている。
少なくとも１クレジット分以上の空きが有る場合は、受
信側のクレジット数を「１」として通知して通信を開始
し、データパケットを受信した場合は、そのデータパケ
ット中のデータを受信バッファに格納した後も１クレジ
ット分以上の空きがある限りは、擬似的に所定のクレジ
ット空き情報を返信するようにしている。
【００５４】従って、複数クレジットの場合のように、
通信を開始する際に受信側で発行すべきクレジット数を
決定したり、通信中に受信バッファの空き容量が増えた
場合には、その空き容量に見合ったクレジット数を算出
してクレジットを追加発行したりするといったような複
雑なクレジット管理を行わずに、複数クレジットの場合
とほぼ同様の通信速度を実現することが可能となる。
通信を開始する際に受信側で発行すべきクレジット数を
決定したり、通信中に受信バッファの空き容量が増えた
場合には、その空き容量に見合ったクレジット数を算出
してクレジットを追加発行したりするといったような複
雑なクレジット管理を行わずに、複数クレジットの場合
とほぼ同様の通信速度を実現することが可能となる。
【００５５】また、従来の複数クレジットの場合は、た
とえ受信バッファの空き容量が非常に大きくても、複数
クレジットのクレジット数の上限値は、クレジット管理
処理で決められた範囲内に限定されてしまうため、通信
速度のアップにも限界があるが、本実施形態では、受信
バッファの非常に大きな空き容量に見合ったクレジット
数を設定した場合と同等の通信速度を実現することがで
きることとなる。
とえ受信バッファの空き容量が非常に大きくても、複数
クレジットのクレジット数の上限値は、クレジット管理
処理で決められた範囲内に限定されてしまうため、通信
速度のアップにも限界があるが、本実施形態では、受信
バッファの非常に大きな空き容量に見合ったクレジット
数を設定した場合と同等の通信速度を実現することがで
きることとなる。
【００５６】なお、本発明は、上記の実施形態に限定さ
れることなく、例えば、クレジットを用いてパケット交
換方式により通信を行う通信システムであれば、赤外線
通信以外の電磁波により無線通信を行う通信システム
や、有線による通信システムにも適用することが可能で
ある。また、クレジットを用いてパケット交換方式によ
り通信を行う機能を備えた装置であれば、印刷装置以外
の各種の装置に適用することも可能である。
れることなく、例えば、クレジットを用いてパケット交
換方式により通信を行う通信システムであれば、赤外線
通信以外の電磁波により無線通信を行う通信システム
や、有線による通信システムにも適用することが可能で
ある。また、クレジットを用いてパケット交換方式によ
り通信を行う機能を備えた装置であれば、印刷装置以外
の各種の装置に適用することも可能である。
【００５７】
【発明の効果】以上、説明したように、実施例によれ
ば、簡単なクレジット管理で高速にパケット交換方式の
データ通信を行うことが可能となる。
ば、簡単なクレジット管理で高速にパケット交換方式の
データ通信を行うことが可能となる。
【図１】本発明の適用例としての印刷装置の概略構成を
示すブロック図である。
示すブロック図である。
【図２】上記印刷装置の通信機能で使用される赤外線通
信プロトコルのデータリンク層の構成図である。
信プロトコルのデータリンク層の構成図である。
【図３】赤外線通信プロトコルを用いた場合に、実際の
データ通信を行うに先立って行われるネゴシエーション
の順序を示す図である。
データ通信を行うに先立って行われるネゴシエーション
の順序を示す図である。
【図４】従来のクレジット数が複数の場合におけるデー
タ通信の流れを示す図である。
タ通信の流れを示す図である。
【図５】従来のクレジット数が「１」の場合におけるデ
ータ通信の流れを示す図である。
ータ通信の流れを示す図である。
【図６】本発明の実施形態におけるデータ通信の流れを
示す図である。
示す図である。
【図７】受信確認応答のみの応答パケット（ＲＲレスポ
ンス・パケット）のフォーマットを示す図である。
ンス・パケット）のフォーマットを示す図である。
【図８】通信継続パケット（ＲＲコマンド・パケット）
のフォーマットを示す図である。
のフォーマットを示す図である。
【図９】クレジット空き情報を含んだ受信確認応答パケ
ット（Ｉフレームレスポンス・パケット）のフォーマッ
トを示す図である。
ット（Ｉフレームレスポンス・パケット）のフォーマッ
トを示す図である。
【図１０】本発明の実施形態におけるクレジット管理処
理を示すフローチャートである。
理を示すフローチャートである。
１０００：インタフェース部
１０１０：通信制御部
１０１０ａ：ＣＰＵ
１０１０ｂ：ＲＯＭ
１０１０ｃ：ＲＡＭ
１０２０：受信バッファ
１０３０：マイクロプロセッサ
Ｄｅｌｔａ Ｃｒｅｄｉｔ：クレジット空き情報
Claims (13)
- 【請求項１】 パケット交換方式でデータ通信を行う通
信装置において、 受信メモリに少なくとも１クレジット分の空き容量が有
る場合は、通信開始時に自己のクレジット数を「１」と
して送信側の通信装置に通知する通知手段と、 前記送信側の通信装置からデータパケットを受信した場
合に、受信に係るデータパケット中のデータを前記受信
メモリに格納した後も該受信メモリに少なくとも１クレ
ジット分の空き容量が有る限りは、クレジット空き情報
を含む応答パケットを返信する返信手段と、を備えたこ
とを特徴とする通信装置。 - 【請求項２】 前記クレジット空き情報は、一定の情報
であることを特徴とする請求項１記載の通信装置。 - 【請求項３】 前記クレジット空き情報は、前記受信メ
モリの実際の空き容量に対応するクレジット数ではな
く、クレジット数が「１」である旨を示す情報であるこ
とを特徴とする請求項１又は２記載の通信装置。 - 【請求項４】 前記通信装置は、赤外線を用いた無線通
信装置であることを特徴とする請求項１〜３の何れかに
記載の通信装置。 - 【請求項５】 パケット交換方式でデータ通信を行う通
信装置の制御方法において、 受信メモリに少なくとも１クレジット分の空き容量が有
る場合は、通信開始時に自己のクレジット数を「１」と
して送信側の通信装置に通知し、前記送信側の通信装置
からデータパケットを受信した場合に、受信に係るデー
タパケット中のデータを前記受信メモリに格納した後も
該受信メモリに少なくとも１クレジット分の空き容量が
有る限りは、クレジット空き情報を含む応答パケットを
返信することを特徴とする通信装置の制御方法。 - 【請求項６】 前記クレジット空き情報は、一定の情報
であることを特徴とする請求項５記載の通信装置の制御
方法。 - 【請求項７】 前記クレジット空き情報は、前記受信メ
モリの実際の空き容量に対応するクレジット数ではな
く、クレジット数が「１」である旨を示す情報であるこ
とを特徴とする請求項５又は６記載の通信装置の制御方
法。 - 【請求項８】 前記通信装置は、赤外線を用いた無線通
信装置であることを特徴とする請求項５〜７の何れかに
記載の通信装置の制御方法。 - 【請求項９】 パケット交換方式でデータ通信を行う通
信システムにおいて、 受信側の通信装置は、自己の受信メモリに少なくとも１
クレジット分の空き容量が有る場合は、通信開始時に自
己のクレジット数を「１」として送信側の通信装置に通
知する通知手段と、 前記送信側の通信装置からデータパケットを受信した場
合に、受信に係るデータパケット中のデータを前記受信
メモリに格納した後も該受信メモリに少なくとも１クレ
ジット分の空き容量が有る限りは、クレジット空き情報
を含む応答パケットを返信する返信手段と、を備えたこ
とを特徴とする通信システム。 - 【請求項１０】 前記クレジット空き情報は、一定の情
報であることを特徴とする請求項９記載の通信システ
ム。 - 【請求項１１】 前記クレジット空き情報は、前記受信
メモリの実際の空き容量に対応するクレジット数ではな
く、クレジット数が「１」である旨を示す情報であるこ
とを特徴とする請求項９又は１０記載の通信システム。 - 【請求項１２】 前記通信装置は、赤外線を用いた無線
通信装置であることを特徴とする請求項９〜１１の何れ
かに記載の通信システム。 - 【請求項１３】 パケット交換方式でデータ通信を行う
通信装置が受信側として機能する場合に実行される制御
プログラムであって、 受信側の通信装置の受信メモリに少なくとも１クレジッ
ト分の空き容量が有る場合は、通信開始時に自己のクレ
ジット数を「１」として送信側の通信装置に通知し、前
記送信側の通信装置からデータパケットを受信した場合
に、受信に係るデータパケット中のデータを前記受信メ
モリに格納した後も該受信メモリに少なくとも１クレジ
ット分の空き容量が有る限りは、クレジット空き情報を
含む応答パケットを返信する内容を有することを特徴と
する制御プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001251763A JP2003069610A (ja) | 2001-08-22 | 2001-08-22 | 通信装置、その制御方法、通信システム、及び制御プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001251763A JP2003069610A (ja) | 2001-08-22 | 2001-08-22 | 通信装置、その制御方法、通信システム、及び制御プログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2003069610A true JP2003069610A (ja) | 2003-03-07 |
Family
ID=19080352
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001251763A Pending JP2003069610A (ja) | 2001-08-22 | 2001-08-22 | 通信装置、その制御方法、通信システム、及び制御プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2003069610A (ja) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006080403A1 (ja) * | 2005-01-28 | 2006-08-03 | Sharp Kabushiki Kaisha | 通信機器、通信システム、通信方法、通信プログラム、通信回路 |
| JP2009231975A (ja) * | 2008-03-19 | 2009-10-08 | Sony Corp | 情報処理装置、情報処理方法、クライアント機器、情報処理システム |
| US8291273B2 (en) | 2005-01-28 | 2012-10-16 | Sharp Kabushiki Kaisha | Communication device, non-transitory computer-readable medium storing a communication program |
| US8316129B2 (en) | 2005-05-25 | 2012-11-20 | Microsoft Corporation | Data communication coordination with sequence numbers |
| US8631277B2 (en) | 2010-12-10 | 2014-01-14 | Microsoft Corporation | Providing transparent failover in a file system |
| US8788579B2 (en) | 2011-09-09 | 2014-07-22 | Microsoft Corporation | Clustered client failover |
| US8856582B2 (en) | 2011-06-30 | 2014-10-07 | Microsoft Corporation | Transparent failover |
| US9331955B2 (en) | 2011-06-29 | 2016-05-03 | Microsoft Technology Licensing, Llc | Transporting operations of arbitrary size over remote direct memory access |
| US10630781B2 (en) | 2011-09-09 | 2020-04-21 | Microsoft Technology Licensing, Llc | SMB2 scaleout |
-
2001
- 2001-08-22 JP JP2001251763A patent/JP2003069610A/ja active Pending
Cited By (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8291273B2 (en) | 2005-01-28 | 2012-10-16 | Sharp Kabushiki Kaisha | Communication device, non-transitory computer-readable medium storing a communication program |
| WO2006080403A1 (ja) * | 2005-01-28 | 2006-08-03 | Sharp Kabushiki Kaisha | 通信機器、通信システム、通信方法、通信プログラム、通信回路 |
| US8825885B2 (en) | 2005-05-25 | 2014-09-02 | Microsoft Corporation | Data communication protocol |
| US8850025B2 (en) | 2005-05-25 | 2014-09-30 | Microsoft Corporation | Data communication coordination with sequence numbers |
| US8316129B2 (en) | 2005-05-25 | 2012-11-20 | Microsoft Corporation | Data communication coordination with sequence numbers |
| US8332526B2 (en) | 2005-05-25 | 2012-12-11 | Microsoft Corporation | Data communication protocol including negotiation and command compounding |
| US9438696B2 (en) | 2005-05-25 | 2016-09-06 | Microsoft Technology Licensing, Llc | Data communication protocol |
| US9332089B2 (en) | 2005-05-25 | 2016-05-03 | Microsoft Technology Licensing, Llc | Data communication coordination with sequence numbers |
| US9071661B2 (en) | 2005-05-25 | 2015-06-30 | Microsoft Technology Licensing, Llc | Data communication coordination with sequence numbers |
| US8874756B2 (en) | 2008-03-19 | 2014-10-28 | Sony Corporation | Information processing unit, information processing method, client device and information processing system |
| JP4557028B2 (ja) * | 2008-03-19 | 2010-10-06 | ソニー株式会社 | 情報処理装置、情報処理方法、クライアント機器、情報処理システム |
| JP2009231975A (ja) * | 2008-03-19 | 2009-10-08 | Sony Corp | 情報処理装置、情報処理方法、クライアント機器、情報処理システム |
| US8631277B2 (en) | 2010-12-10 | 2014-01-14 | Microsoft Corporation | Providing transparent failover in a file system |
| US9331955B2 (en) | 2011-06-29 | 2016-05-03 | Microsoft Technology Licensing, Llc | Transporting operations of arbitrary size over remote direct memory access |
| US10284626B2 (en) | 2011-06-29 | 2019-05-07 | Microsoft Technology Licensing, Llc | Transporting operations of arbitrary size over remote direct memory access |
| US8856582B2 (en) | 2011-06-30 | 2014-10-07 | Microsoft Corporation | Transparent failover |
| US9462039B2 (en) | 2011-06-30 | 2016-10-04 | Microsoft Technology Licensing, Llc | Transparent failover |
| US8788579B2 (en) | 2011-09-09 | 2014-07-22 | Microsoft Corporation | Clustered client failover |
| US10630781B2 (en) | 2011-09-09 | 2020-04-21 | Microsoft Technology Licensing, Llc | SMB2 scaleout |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9414264B2 (en) | Communication apparatus, communication method, and communication system | |
| JP4391316B2 (ja) | ワイヤレスｌａｎ用のメディア・アクセス・コントロール装置 | |
| EP1161042B1 (en) | Radio communication method and radio station | |
| EP2067285B1 (en) | Transmission using a plurality of protocols by fragmenting the frames of one of the protocols | |
| US7307994B2 (en) | Controller area network (CAN) based communication system with multiple bus connected nodes | |
| US5612950A (en) | Managing communication on an unstable error-prone channel | |
| US20040266424A1 (en) | Method and apparatus for interfacing wired and wireless data | |
| US6665719B1 (en) | Communication control for multi-layer communications | |
| JP2003069610A (ja) | 通信装置、その制御方法、通信システム、及び制御プログラム | |
| US6370118B1 (en) | Simultaneous set up of PPP on AUM and a RM interface | |
| JP2005027298A (ja) | 無線ネットワークのステーションにおけるデータの伝送を管理するための方法及び装置 | |
| EP0991240B1 (en) | Multiple access prevention for datagram-based control protocols method | |
| US6463034B1 (en) | Method and apparatus for avoiding data loss during a PPP renegotiation on a Um interface | |
| US20100077105A1 (en) | Role Switching Method Performed in Dual Role Device, and the Dual Role Device | |
| JPH04839A (ja) | パケット通信方法 | |
| CN116055583A (zh) | 可兼容多协议的通信系统及其控制方法、电子设备 | |
| US20070223532A1 (en) | Method and system for data processing | |
| JPH08256149A (ja) | 無線ｌａｎシステム | |
| JPH09331370A (ja) | データ通信装置 | |
| US4792648A (en) | Telematic reception terminal | |
| US20060023703A1 (en) | Image processing apparatus | |
| AU751352B2 (en) | Data transmitting device and method in mobile communication system | |
| JPS6236940A (ja) | 自動車内デ−タ通信装置 | |
| JP2003234796A (ja) | データフロー制御装置及び方法 | |
| JPH11196097A (ja) | データ通信制御装置、及びデータ通信制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20060413 |
|
| RD05 | Notification of revocation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7425 Effective date: 20070626 |