JPH032950A - 受信バッファ管理方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔発明の技術分野〕 本発明はデータ受信装置における受信バッファの管理方
式に関する。

［従来技術およびその問題点〕 プリンタ等のデータ受信装置においては、受信したデー
タを装置内部で処理するため、多くの場合このデータを
適当なサイズの受信バッファに順次格納し、古いデータ
から順次読み出して処理していく。このような順次の格
納と読出を管理するため、夫々書込ポインタと読出ポイ
ンタが用いられる。

データ転送をブロック中位で行ない、ブロック中にエラ
ーが検出されたら当該ブロック全体を受信バッファから
削除してブロック全体を再送する方式を上述のようなバ
ッファ管理に適用しようとすると、以下の様な問題点が
生じる。すなわち、ブロックにエラーがあることが分か
るのは、一般にそのブロックの先頭の部分あるいはブロ
ック全体が受信バッファに書き込まれた後である。装置
内部の処理が早く進んでいる場合には、現在のブロック
にエラーがあると分かったときには受信バッファからの
読出が既にこのブロック内にまで進んでしまっている可
能性がある。

〔発明の目的〕

本発明は上述した従来技術の問題点を解消し、受信バッ
ファを用いたデータ転送において、構成の複雑化を最小
限に抑えながら受信データブロックの無効化を可能にす
る受信バッファ管理方式を提供することを目的とする。

〔発明の概要〕

本発明の一実施例によれば、受信バッファを管理するた
めに、受信バッファ中でエラーの検出等により取り消さ
れる可能性のある部分とそのような可能性のない部分と
の境界を指示するように制御されるポインタを設ける。

受信バッファからの読出がこのポインタを越えて進まな
いように制御を行うことにより、上述の目的が達成され
る。

〔発明の実施例〕

以上、図面に基づいて本発明の一実施例を説明する。こ
の実施例においては、ホストから受信装置へのデータ転
送は以下のプロトコルに従って行われる。

■ホストから受信装置へのデータ転送はブロック単位で
行われる。

■ホストは１ブロックのデータを送り終わる毎に状態確
認コマンドを受信装置に与える。

■受信装置は、直前に受信したデータのブロックにエラ
ーがあれば状態確認コマンドに応答して当該ブロックを
受信バッファから削除するとともに、ホストに対してエ
ラー状態を通知する。エラー状態の通知を受けたホスト
は当該ブロックの再送を行う。

■エラーがなければ受信装置は状態確認コマンドに対し
て正常である旨応答する。この場合には、ホストは次の
ブロックの転送が可能になり、また受信バッファ中の正
常に受信されたブロックの処理が可能になる。

第１図は本発明の一実施例が適用される受信バッファの
初期状態を示す図である。同図において、ＷＰは書込ポ
インタ、Ｒ？は読出ポインタ、ＲＦは読出ポインタがそ
れ以上先へ進まないようにするための読出フェンスポイ
ンタである。同図の状態では受信バッファ１０にはデー
タが入っていないので、３つのポインタＷＰ、ＲＰ、Ｒ
Ｆは皆同じ位置を指している。

第２図は、受信バッファ１０に１ブロック分のデータが
読み込まれたが、まだエラーチエツクが完了していない
状態を示す。このエラーチエツクは例えばＣＲＣを使用
して行われるが、エラーチエツクの方法自体は本発明の
要旨ではなくまた当業者にとっては周知の事項であるた
め、これ以上の説明は省略する。

第２図から分かるように、このような状態では書込ポイ
ンタＷＰは１ブロック分進んでいるが、読出フェンスポ
インタＲＦは第１図と同じ位置に留まっている。読出ポ
インタＲＰは読出フェンスポインタＲＦを追い越せない
ようになっているので、これも第１図と同し位置に留ま
っている。

第３図は、エラーチエツクによりエラーが発見された場
合、ホスト側からの状態確認コマンドに応答して当該ブ
ロックが削除された状態を示す。

同図から分かるように、ブロックの削除は書込ポインタ
ＷＰを１ブロック分戻すことによって行われる。第２図
に関して説明したように、エラーがあるかどうかが未確
認のブロックへ読出ポインタが入り込むこと、つまりこ
のブロック内のデータが読み出されることは阻止されて
いる。従って、エラーを含んでいるブロックのデータを
処理してしまうことはない。

受信装置はブロックの削除を行うとともに、ホストに対
してエラーがあったことを通知するので、ホストはこれ
に応答して直前のブロックを再送する。今度は正常に受
信できたならば、受信装置は状態確認コマンドに応答し
て正常である旨通知するとともに、読出フェンスポイン
タＲＦを進める。

この段階ではじめて、受信装置は直前に受信されたブロ
ック中のデータを処理できるようになる。

この後受信装置による受信バッファｌＯからの読出があ
る程度進んだ状態を第４図に示す。

第７図には、上述の動作を表すシーケンスを図式的に示
す。

第５図および第６図には、第４図に示された状態の後に
次のブロックのデータが正常に受信される場合の過程が
示されでいる。なお、第６図は、読出フェンスポインタ
ＲＦが進められた直後の状態を示す。ここで、（Ａ）は
その直前までに読出ポインタが読出フェンスポインタＲ
Ｆに追いついていた場合を、また（Ｂ）は読出ポインタ
ＲＰがまだ読出フェンスポインタＲＦに追いついていな
かった場合の状態を示すものである。

なお、実際の受信バッファはリングバッファ等の形態で
実現されるが、このような具体的な受信バッファの構成
法は当業者には周知の事項であるため、説明は省略する
。

以上一実施例に基づいた説明を行ったが、本発明はこれ
に限定されるものではなく、多様な変形を包含するもの
であることは言うまでもない。

例えば、受信バッファからのブロックの削除は、フロッ
ク全体を一旦受信バッファに入れてから行なうかわりに
、ブロックの転送途中で現在受信中のブロックが不要で
あると判明したときに（例えばパリティエラーの検出に
応答して）直ちに行ってもよい。

また、ホスト側からの状態確認を待たずにブロックの削
除を行うこともできる。

また、実施例では、エラーの検出によるブロックの削除
について説明したが、本発明の適用範囲はこれに限定さ
れるものではなく、−旦受信バノファに入ったデータが
直ちに処理できない状態であることがある場合に適用で
きる。例えば受信したデータに何らかの処理を行ったり
あるいはエラーではないが不要として捨てるか否かの判
断がなされる場合にも適用可能である。

また、本発明は上述のプロトコル以外に対しても適用で
きることは言うまでもない。

〔発明の効果〕

以ト説明したように、本発明によれば、簡単な構成で、
受信側での処理が受信バッファ中のデータの未確定部分
まで進まないようにすることができる。

【図面の簡単な説明】

第１図ないし第６図は本発明の一実施例の動作を説明す
る図、第７図は第１図ないし第６図に示された動作シー
ケンスを図式的に説明するための図である。 ＩＯ＝受信バッファ ＷＰ：書込ポインタ ＲＰ：読出ポインタ ＲＦ：読出フェンスポインタ 第１図 第２図

Claims (2)

【特許請求の範囲】
1. （１）受信データが順次書き込まれまた順次読み出され
   る受信バッファにおいて、 前記書き込まれた受信データのうち前記読出を行っても
   良い部分とそうでない部分との境界位置を示す手段を設
   けたことを特徴とする受信バッファ管理方式。
2. （２）前記受信データの末尾の位置を示す第１のポイン
   タと、 前記読出が最後に行われた位置を示す第２のポインタと
   、 前記境界位置を示す手段である第３のポインタとを設け
   、 前記第２のポインタに基づいた読出は前記第３のポイン
   タが示す前記境界を越えないようにした ことを特徴とする請求項１記載の受信バッファ管理方式
   。