JPH06252955A - データ通信装置 - Google Patents

Abstract

(57)【要約】 【目的】本発明はデ−タ通信装置に関し、特に、デ−タ
送受信処理を高速に行う方法を提供することにある。 【構成】システムプロセッサ１と、アプリケ−ションプ
ログラム１１とそれが管理するアプリケ−ションバッフ
ァ１１２と、通信プロトコルプログラム１１３とそれが
管理するプロトコルバッファ１１４と、伝送路１３を制
御する通信コントロ−ラ１４とそれが管理する送受信バ
ッファ１４２を備えるデ−タ通信装置において、アプリ
ケ−ションバッファ１１２とプロトコルバッファ１１４
と送受信バッファ１４２の間を、システムプロセッサ１
が処理の単位とする基本バイト長ごとに高速にコピ−が
できるように構成する。 【効果】バッファ間を高速にデ−タ移動ができるため、
通信システム全体のスル−プットが向上するという効果
がある。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は通信システム、特にロ−
カルエリアネットワ−ク（ＬＡＮ）に好適な高速デ−タ
通信装置の通信処理の高速化に関する。

【０００２】

【従来の技術】パ−ソナルコンピュ−タやワ−クステ−
ションなどの情報処理装置がＬＡＮなどの高速な伝送路
を用いてデ−タ通信を行うための通信システムのとして
本発明者は、図２のような通信システムを発明した。な
お、本出願人は、既にこのデータ通信装置について特願
平４−２３０９１５号出願を出願している。

【０００３】図２は、このデータ通信装置における通信
デ−タとデ−タを格納するためのバッファの関係を示す
バッファ構成図である。送信装置６と受信装置７は伝送
路１３に接続され、伝送路１３を介してデ−タ通信を行
う。送信装置６は、アプリケ−ションプログラム６０、
送信処理プログラム６３、通信コントロ−ラ６８から構
成される。アプリケ−ション図２を用いて説明する。プ
ログラム６０には送信するアプリケ−ションデ−タ６２
を格納するためのアプリケ−ションバッファ６１を持
ち、送信処理プログラム６３には、送信のためにアプリ
ケ−ションデ−タの一部６５を一時格納するためのデ−
タバッファ６４と、通信プロトコルのヘッダ情報６７を
一時格納するためのヘッダバッファ６６を持ち、通信コ
ントロ−ラ６８には、ヘッダ情報とアプリケ−ションデ
−タからなるフレ−ムデ−タ６１０を一時格納するため
の送信バッファ６９を持つ。アプリケ−ションプログラ
ム６０と送信処理プログラム６３は、送信装置６のシス
テムメモリ上に置かれ、システムプロセッサで処理され
る。図２ではシステムメモリ、システムプロセッサを省
略している。受信装置７は、送信装置６と同じように、
アプリケ−ションプログラム７０、受信処理プログラム
７３、通信コントロ−ラ７６から構成される。アプリケ
−ションプログラム７０には受信したアプリケ−ション
デ−タ７２を格納するためのアプリケ−ションバッファ
７１を持ち、受信処理プログラム７３には、アプリケ−
ションデ−タの一部７５を一時格納するためのプロトコ
ルバッファ７４を持ち、通信コントロ−ラ７６には、受
信したフレ−ムデ−タ７８を一時格納するための受信バ
ッファ７７を持つ。アプリケ−ションプログラム７０と
受信処理プログラム７３は、受信装置７のシステムメモ
リ上に置かれ、システムプロセッサで処理される。図２
ではシステムメモリ、システムプロセッサを省略してい
る。図２において、送信装置６のアプリケ−ションデ−
タ６２を受信装置７のアプリケ−ションプログラム７０
に届けるために、送信装置６側では、アプリケ−ション
バッファ６１に入っているアプリケ−ションデ−タ６２
を分割しながら、デ−タバッファ６４、送信バッファ６
９の三つのバッファを渡って伝送路１３上に送出され、
一方、受信装置７側では、分割されたデ−タは、受信バ
ッファ７７、プロトコルバッファ７４を渡ってアプリケ
−ションバッファ７１で組立てられる。

【０００４】

【発明が解決しようとする課題】しかしながら上記先の
発明は、アプリケ−ションデ−タ６２の分割量を考慮し
ておらず、又、それぞれのバッファのデ−タ格納位置に
対しても考慮していない。そのため、バッファ間でデ−
タコピ−を行う際に二つのバッファのデ−タ先頭アドレ
スの境界が一致しなかった場合にはコピ−に時間がかか
り、通信性能が劣化してしまうという問題が生じる。

【０００５】図２において、送信装置６、受信装置７の
システムプロセッサはいずれも基本バイト長を４バイト
とした３２ビットプロセッサとする。又、全てのバッフ
ァの先頭アドレスが基本バイト長の整数倍になる位置に
割り付ける。この位置をワ−ド境界と呼ぶことにする。
図３にバッファ間を渡っていくデ−タの様子を示す。各
バッファは図２のバッファと同じものを表しており、同
一番号を付けた。各バッファに付けた目盛は１バイトご
とのアドレスを表し、左から右にアドレスが進む。逆三
角形の記号が付いている箇所がワ−ド境界を表してお
り、ワ−ド境界から１バイトづつ進んだ位置を１バイト
境界、２バイト境界、３バイト境界と呼ぶことにする。
３２ビットプロセッサでは、一般に、システムメモリに
対してワ−ド境界から４バイト分のデ−タを一度に読み
だしたり書き込むことはできるが、ワ−ド境界を挟んで
アクセスすることはできない。したがって、デ−タをコ
ピ−する場合、コピ−元とコピ−先とでワ−ド境界が一
致しているときは４バイト単位に読みだしと書き込みを
繰り返せばよいが、一致していないときには１バイトま
たは２バイト単位に読みだしと書き込みを繰り返すこと
になる。そのためメモリへのアクセス回数が多くなりコ
ピ−時間がかかってしまうという問題が生じる。図３
は、最初に１０バイトのアプリケ−ションデ−タ６２１
を送った後、次の１０バイトのアプリケ−ションデ−タ
６２２を送受信している状態を示している。ヘッダ情報
は５バイトとした。アプリケ−ションデ−タ６２２の先
頭アドレスが２バイト境界に格納されているため、アプ
リケ−ションバッファ６１からデ−タバッファ６４への
デ−タコピ−は、２バイト単位に分けて５回で行うこと
になる。送信バッファ６９へのコピ−は、ヘッダ情報に
ついては４バイトと１バイトの２回に分けてコピ−する
が、デ−タに関してはデ−タバッファ６４から１バイト
単位に１２回かけてコピ−することになる。フレ−ムデ
−タが伝送路１３を通して受信バッファ７７の先頭から
受信されたフレ−ムデ−タは、受信バッファ７７からプ
ロトコルバッファ７４に、４バイト単位に３回、１バイ
ト単位に３回でコピ−される。アプリケ−ションバッフ
ァ７１に対しては、プロトコルバッファ７４とバッファ
の先頭アドレス境界が一致していないため、アプリケ−
ションデ−タは１バイト単位に１０回かけてコピ−で行
うことになる。

【０００６】本発明は、バッファ間のデ−タコピ−を高
速に行う高速デ−タ通信システムを提供することを目的
とする。

【０００７】

【課題を解決するための手段】上記目的を達成するため
に、本発明においては、通信プロトコルをプログラムで
処理するシステムプロセッサが基本バイト長単位に処理
するプロセッサと、デ−タの送受信を行う通信専用のロ
−カルメモリと、プログラム及び通信デ−タを蓄積する
システムメモリを装備し、アプリケ−ションデ−タの伝
送量を調整しながらデ−タ通信を行うデ−タ通信装置に
おいて、伝送量を基本バイト長の整数倍にしてデ−タの
送受信を行うことにより、通信処理を高速化できるよう
にする。

【０００８】また、前記デ−タ通信装置が送信側に使用
される場合、ロ−カルメモリに送信用バッファを設け、
送信用バッファ上のアプリケ−ションデ−タを格納する
先頭アドレスが、ワ−ド境界と一致するようにして送信
処理を高速化できるようにする。

【０００９】また、前記デ−タ通信装置が受信側に使用
される場合、ロ−カルメモリに受信用バッファを設け、
受信用バッファ上のアプリケ−ションデ−タを格納する
先頭アドレスが、ワ−ド境界と一致するようにして受信
処理を高速化できるようにする。

【００１０】また、通信プロトコルをプログラムで処理
するシステムプロセッサが基本バイト長単位に処理する
プロセッサと、プログラム及び通信デ−タを蓄積するシ
ステムメモリを装備し、アプリケ−ションデ−タの伝送
量を調整しながらデ−タ通信を行うデ−タ通信装置にお
いて、伝送量を基本バイト長の整数倍にしてシステムメ
モリに直接デ−タの送受信を行うことにより、通信処理
を高速化できるようにする。

【００１１】また、前記デ−タ通信装置が送信側に使用
される場合、システムメモリに送信用バッファを設け、
送信用バッファ上のアプリケ−ションデ−タを格納する
先頭アドレスが、ワ−ド境界と一致するようにして送信
処理を高速化できるようにする。

【００１２】また、前記デ−タ通信装置が受信側に使用
される場合、システムメモリに受信用バッファを設け、
受信用バッファ上のアプリケ−ションデ−タを格納する
先頭アドレスが、ワ−ド境界と一致するようにして受信
処理を高速化できるようにする。

【００１３】また、６４ビットプロセッサを搭載したデ
−タ通信装置がEthernet ＬＡＮを通してデ−タ通信を
行う場合、一度に送るアプリケ−ションデ−タの長さを
１４５６バイトに押さえ、これにより上記デ−タ通信装
置内の処理を高速化できるようにする。

【００１４】また、６４ビットプロセッサを搭載したデ
−タ通信装置がＦＤＤＩ ＬＡＮを通してデ−タ通信を
行う場合、一度に送るアプリケ−ションデ−タの長さを
４４２４バイトに押さえ、これにより上記デ−タ通信装
置内の処理を高速化できるようにする。

【００１５】

【作用】本発明は、伝送量を基本バイト長の整数倍にし
てデ−タの送受信を行うので、バッファ間のデ−タコピ
−が速くなり、高速にデ−タを通信することができる。

【００１６】前記送信用バッファ上のアプリケ−ション
デ−タを格納する先頭アドレスが、ワ−ド境界と一致す
ることにより送信処理が高速化される。

【００１７】前記受信用バッファ上のアプリケ−ション
デ−タを格納する先頭アドレスが、ワ−ド境界と一致す
ることにより送信処理が高速化される。

【００１８】前記伝送量は、Ethernet ＬＡＮの場合は
１４５６バイトであり、ＦＤＤＩ ＬＡＮの場合は４４
２４バイトである。

【００１９】

【実施例】以下、本発明の実施例を、図を用いて説明す
る。

【００２０】図１は、本発明の一実施例におけるデ−タ
通信装置の構成を示すブロック図である。デ−タ通信装
置は通信プロトコルを実行するシステムプロセッサ１と
システムメモリ１１、伝送路１３を制御しながらデ−タ
の送受信を行う通信コントロ−ラ１４から構成される。
バス１５は上記構成要素を接続するためのもので、それ
ぞれの情報交換に使用する。この時、制御コ−ド、通信
デ−タ等の情報が流れる。構成の中でシステムプロセッ
サ１とシステムメモリ１１で通信プロトコルの処理、ア
プリケ−ションプログラムの処理および通信装置全体の
総合的な制御を行う。システムメモリ１１はシステムプ
ロセッサ１で動く各種プログラムコ−ドの他に通信デ−
タの蓄積部としても利用する。プログラムとしては、図
１に示すように、通信プロトコルを処理するプロトコル
プログラム１１３、アプリケ−ションプログラム１１１
があり、プロトコルプログラム１１３にはプロトコルバ
ッファ１１４、アプリケ−ションプログラム１１１には
アプリケ−ションバッファ１１２がある。通信コントロ
−ラ１４にはロ−カルメモリ１４１があり、その中の送
受信バッファ１４２はデ−タの送受信用に使用する。ロ
−カルメモリ１４１は、システムプロセッサ１から、シ
ステムメモリと同じようにアクセスできる。図１におい
て、システムプロセッサ１は、例えば基本バイト長が４
バイトの３２ビットプロセッサ、システムメモリ１１と
ロ−カルメモリ１４１はアドレスが４バイトおきにワ−
ド境界があるものとする。したがってシステムプロセッ
サ１は、システムメモリ１１やロ−カルメモリ１４１に
対してワ−ド境界から一度に４バイト分の情報を読み書
きすることができる。

【００２１】図２は、図１のデ−タ通信装置を送信装置
６、受信装置７に適用してデ−タ通信を行う場合のプロ
グラム構成図である。図２の送信装置６と受信装置７
は、それぞれ図１のデ−タ通信装置で構成されており、
図１のアプリケ−ションプログラム１１１と図２のアプ
リケ−ションプログラム６０及び７０、図１のアプリケ
−ションバッファ１１２と図２のアプリケ−ションバッ
ファ６１及び７１、図１のプロトコルプログラム１１３
と図２の送信処理プログラム６３及び受信処理プログラ
ム７３、図１のプロトコルバッファ１１４と図２のデ−
タバッファ６４、ヘッダバッファ６６及びプロトコルバ
ッファ７４、図１の通信コントロ−ラ１４と図２の通信
コントロ−ラ６８及び７６、図１のロ−カルメモリ中の
送受信バッファ１４２と図２の送信バッファ６９及び受
信バッファ７７、とは同じものである。

【００２２】伝送路１３に流れるデ−タフレ−ムは図４
に示すフォ−マットになっている。図４において、デ−
タフレ−ム３００は、フレ−ムヘッダ３０１、プロトコ
ルヘッダ３０２、アプリケ−ションデ−タ３０３及びフ
レ−ムテ−ラ３０４から構成されており、フレ−ムヘッ
ダ３０１には宛先アドレス情報が、フレ−ムテ−ラ３０
４にはデ−タエラ−を検出するためのチェックコ−ド情
報が入っている。フレ−ムヘッダ３０１の生成は、図２
に示す送信処理プログラム６３で、解読を通信コントロ
−ラ７６と受信処理プログラム７３で行い、プロトコル
ヘッダ３０２の方は、生成を送信処理プログラム６３
で、解読を受信処理プログラム７３で行う。また、フレ
−ムテ−ラ３０４は、生成、解読を通信コントロ−ラ６
８と７６でそれぞれ行う。アプリケ−ションデ−タ３０
３はアプリケ−ションプログラム６０から７０に渡され
るデ−タの一部である。伝送路１３では一度に送れるデ
−タ量に制限があるため、アプリケ−ションデ−タを分
割して転送する。

【００２３】最初に、図２に示す送信装置６の動作につ
いて説明する。アプリケ−ションプログラム６０の動作
フロ−チャ−トは図５のようになる。処理ｓ５１では、
システムメモリ上に先頭アドレスがワ−ド境界になるよ
うに送信用アプリケ−ションバッファ６１を割付け、処
理ｓ５２ではアプリケ−ションバッファ６１にアプリケ
−ションデ−タ６２を用意し、処理ｓ５３では図２に示
す送信処理プログラム６３を起動した後、処理ｓ５４で
送信処理プログラム６３からの送信終了報告を待つ。

【００２４】アプリケ−ションプログラム６０から送信
の指示があると、送信処理プログラム６３は図６に示す
フロ−チャ−トにしたがって動作する。処理ｓ６１で
は、伝送路１３の最大伝送量をもとにしてアプリケ−シ
ョンデ−タの伝送量を、基本バイト長の整数倍になるよ
うに決める。

【００２５】伝送量の決め方を図１０に示す。図１０に
示す処理ｓ１０１では、まだ転送されていないアプリケ
−ションデ−タの量と伝送路１３の最大デ−タ伝送量と
比較し、残りのデ−タが少ない場合には、処理ｓ１０２
で伝送量を残りのアプリケ−ションデ−タの量にする。
残りのデ−タ量が最大デ−タ伝送量よりも多い場合に
は、処理ｓ１０３で、最大デ−タ伝送量に押さえるが、
この時、システムプロセッサの基本バイト長の整数倍に
なるようにする。

【００２６】例えば、図２に示す伝送路１３をEthernet
（Ｘｅｒｏｘ社の登録商標）仕様、送信処理プログラム
６３、受信処理プログラム７３が扱う通信プロトコルを
ＴＣＰ／ＩＰ(Transmission Control Protocol/Interne
t Protocol)とすると、図４に示すフレ−ムフォ−マッ
トのうち、プロトコルヘッダ３０２とアプリケ−ション
デ−タ３０３の長さの合計は、最大１５００バイトに規
定される。プロトコルヘッダ３０２の標準長はＴＣＰ／
ＩＰヘッダ分４０バイトであるから、一度に送ることが
できるアプリケ−ションデ−タ３０３の最大デ−タ伝送
量は１４６０バイトになる。送信装置６、受信装置７の
システムプロセッサの基本バイト長を４バイトとする
と、図９に示す処理ｓ１０３では、最大デ−タ伝送量１
４６０バイトが４の整数倍であるから、伝送量は最大デ
−タ伝送量１４６０バイトそのものとなる。伝送量の具
体的な算出は、最大デ−タ伝送量を４で除算して端数を
切り捨てても求まるが、最大デ−タ伝送量を２進数で表
現して下位２ビットをゼロにするだけでも簡単に求ま
る。

【００２７】送信装置６、受信装置７のシステムプロセ
ッサを、例えば、基本バイト長８バイトの６４ビットプ
ロセッサを用いた場合には、伝送量が１４５６バイトに
なる。最大デ−タ伝送量よりも４バイト減るが、バッフ
ァ間でのデ−タコピ−を高速に行うことができるため、
結果的にデ−タ通信の性能が向上する。

【００２８】図６に示す処理ｓ６２では、上記方法で得
た伝送量分のデ−タバッファ６４を確保する。デ−タバ
ッファ６４の先頭アドレスはワ−ド境界に配置する。処
理ｓ６３では、アプリケ−ションバッファ６１からデ−
タバッファ６４にアプリケ−ションデ−タ６２の一部
を、基本バイト長を単位としてコピ−する。つぎに、処
理ｓ６４では、通信プロトコルのヘッダ長またはそれ以
上の長さのヘッダバッファ６６を確保して、処理ｓ６５
でヘッダ情報をヘッダバッファ６６の中に生成する。こ
の時、格納されたヘッダ情報の次のアドレスがちょうど
ワ−ド境界になるようにする。

【００２９】ヘッダ情報の先頭格納アドレス境界を求め
る方法として、例えば、図９に示すテ−ブルを用いる方
法がある。図９は、ヘッダの長さを２進数で表現したと
きの下位２ビットの値（１０進数）とアドレス境界の対
応図である。例えば、ヘッダ長が４０バイトの場合、２
進数で表すと１０１０００になり、下位２ビットの値が
０であるから、図９からアドレス境界はワ−ド境界にな
る。したがって、ヘッダ情報をワ−ド境界から格納すれ
ばよい。同様に、ヘッダが４１バイトの場合は、３バイ
ト境界からヘッダ情報を入れていけばよい。

【００３０】図６に示す処理ｓ６６では、通信コントロ
−ラ６８のロ−カルメモリ上に送信バッファ６９を確保
して、処理ｓ６７では、ヘッダバッファ６６から送信バ
ッファ６９にヘッダ情報６７を、基本バイト長を単位と
してコピ−し、処理ｓ６８では、デ−タバッファ６４か
ら送信バッファ６９に、ヘッダ情報につづいてアプリケ
−ションデ−タ６５を、基本バイト長を単位としてコピ
−する。このとき、送信バッファ６９には、アプリケ−
ションデ−タの先頭アドレスがちょうどワ−ド境界に一
致する形で格納する。ヘッダが入る先頭のアドレス境界
は、図６に示す処理ｓ６５で説明したように、図９を用
いると簡単に求まる。続いて、処理ｓ６９では通信コン
トロ−ラ６８に対して送信の指示を出して、処理ｓ６１
０では使用したデ−タバッファ６４とヘッダバッファ６
６を解放し、処理ｓ６１１では、まだ送信するデ−タが
残っていれば、処理ｓ６１に戻って上記動作を繰り返
す。デ−タが残っていなければ、処理ｓ６１２でアプリ
ケ−ションプログラム６０に送信が終了した旨を通知す
る。通信コントロ−ラ６８は通信処理プログラム６３か
らの送信指示があると、送信バッファ６９の中のフレ−
ムデ−タ６１０を伝送路１３上に送出し、送信が終了し
た時点で送信バッファ６９を解放する。

【００３１】図６の実施例では、アプリケ−ションプロ
グラム６０と送信処理プログラム６３は、通信コントロ
−ラ６８に送信指示しただけで送信が完了したように動
作するが、これを受信装置７からの確認応答を待つよう
にすることもできる。

【００３２】つぎに受信装置２の動作について説明す
る。アプリケ−ションプログラム７０の動作フロ−チャ
−トは図７のようになる。処理ｓ７１では、システムメ
モリ上に先頭アドレスがワ−ド境界になるように受信用
アプリケ−ションバッファ７１を割付け、処理ｓ７２で
は図２に示す受信処理プログラム７３を起動した後、処
理ｓ７３で受信処理プログラム７３からの受信終了報告
を待つ。

【００３３】アプリケ−ションプログラム７０から受信
指示があると、受信処理プログラム７３は、図８に示す
フロ−チャ−トにしたがって動作する。処理ｓ８１で
は、まず、通信コントロ−ラ７６のロ−カルメモリ上に
１乃至複数の受信バッファ７７を確保し、処理ｓ８２で
通信コントロ−ラ８７に対して受信を指示する。このと
き、受信フレ−ムを受信した際にアプリケ−ションデ−
タの先頭アドレスがワ−ド境界になるように指示する。
フレ−ムが受信する先頭アドレスの境界は、図６に示す
処理ｓ６５で説明したように、図９を用いると簡単に求
まる。処理ｓ８３では、通信コントロ−ラ７６からの受
信報告を待つ。通信コントロ−ラ７６が伝送路１３から
のフレ−ムデ−タを受信バッファ７７に受信すると、受
信処理プログラム７３に通知する。通信コントロ−ラ７
６から受信通知を受けると、受信処理プログラム７３
は、図８に示すフロ−チャ−トの処理ｓ８４でプロトコ
ルバッファ７４を確保して、処理ｓ８５で受信バッファ
７７からプロトコルバッファ７４にフレ−ムデ−タ７８
を、基本バイト長を単位としてコピ−する。このとき、
プロトコルバッファ７４には、アプリケ−ションデ−タ
の先頭アドレスが、ちょうどワ−ド境界に一致する形で
格納する。フレ−ムが入る先頭アドレスの境界は、図６
に示す処理ｓ６５で説明したように、図９を用いると簡
単に求まる。処理ｓ８６では使用した受信バッファ７７
を初期化して再度受信用として使用する。処理ｓ８７で
は、プロトコルバッファ７４に入っているフレ−ムデ−
タ７５のうち、ヘッダ情報を処理して、処理ｓ８８では
ヘッダ情報を除くアプリケ−ションデ−タだけ取り出し
て、アプリケ−ションバッファ７１に対し、すでに受信
したデ−タの次の場所からコピ−する。このとき、前の
デ−タの長さが基本バイト長の整数倍になっているた
め、次のデ−タを格納する先頭アドレスもワ−ド境界に
なり、したがってアプリケ−ションバッファ７１とプロ
トコルバッファ７４のデ−タアドレス境界が一致するた
め、両バッファに対して基本バイト単位にデ−タコピ−
が可能である。つぎに処理ｓ８９では使用したプロトコ
ルバッファ７４を解放し、処理ｓ８１０では受信デ−タ
が残っているときには、処理ｓ８３で次の受信を待ち、
全デ−タを受信したときは、処理ｓ８１１で受信終了を
アプリケ−ションプログラム７０に通知して終了する。

【００３４】図１１は、図２のデ−タ通信システムを図
５、図６、図７、図８のフロ−チャ−トにしたがって動
作させたときに、バッファ間をデ−タが流れる様子を示
したものである。各バッファに付けられている目盛は、
図３と同様に、１バイトごとのアドレスを表しており、
左から右にアドレスが進む。逆三角形の記号が付いてい
る箇所はワ−ド境界を表している。図１１では、伝送路
の最大デ−タ伝送量を１０バイトにした。システムプロ
セッサの基本バイト長が４バイトであるため、アプリケ
−ションデ−タの伝送量は、図６に示す処理ｓ６１か
ら、８バイトになる。図１１は、アプリケ−ションバッ
ファ６１１から最初に８バイトのアプリケ−ションデ−
タ６２３を送った後、次の８バイトのアプリケ−ション
デ−タ６２４を送受信している状態を示している。通信
プロトコルに用いるヘッダ情報のサイズは５バイトとし
た。送信装置側のデ−タバッファ６４１、ヘッダバッフ
ァ６６１、送信バッファ６９１に格納されるアプリケ−
ションデ−タ及びヘッダ情報の先頭アドレスは、図６に
示す処理ｓ６３、処理ｓ６５、処理ｓ６７によりそれぞ
れワ−ド境界、３バイト境界になる。このとき、アプリ
ケ−ションバッファ６１１からデ−タバッファ６４１へ
のコピ−は、両方のデ−タの先頭アドレス境界が一致し
ているため、基本バイト長、４バイト単位にコピ−が可
能である。また、ヘッダバッファ６６１、デ−タバッフ
ァ６４１から送信バッファ６９１のコピ−も、同様の理
由により、基本バイト長単位に高速にコピ−が可能であ
る。

【００３５】一方、受信装置側では、プロトコルバッフ
ァ７４１、受信バッファ７７１に格納されるフレ−ムデ
−タの先頭アドレスは、図８に示す処理ｓ８２、処理ｓ
８５により、３バイト境界にする。このとき、両方のデ
−タの先頭アドレス境界が一致しているため、受信フレ
−ムデ−タのコピ−は基本バイト長単位にコピ−が可能
である。また、プロトコルバッファ７４１からアプリケ
−ションバッファ７１１にアプリケ−ションデ−タをコ
ピ−するときも、同様の理由により、基本バイト長単位
に高速にコピ−が可能である。

【００３６】本発明の別の実施例を、図１２から図１６
を用いて説明する。図１に示すデ−タ通信装置は、通信
コントロ−ラにロ−カルメモリを内蔵し、伝送路上のデ
−タをロ−カルメモリに対して読み書きする実施例であ
り、本実施例は伝送路上のデ−タを直接システムメモリ
に対して読み書きするシステムメモリ直結タイプであ
る。

【００３７】図１２は、本発明の一実施例であるシステ
ムメモリ直結タイプのデ−タ通信装置の構成を示すブロ
ック図である。デ−タ通信装置は通信プロトコルを実行
するシステムプロセッサ１とシステムメモリ２１、伝送
路１３を制御しながらデ−タの送受信を行う通信コント
ロ−ラ２４から構成される。バス１５は上記構成要素を
接続するためのもので、それぞれの情報交換に使用す
る。この時、制御コ−ド、通信デ−タ等の情報が流れ
る。構成の中でシステムプロセッサ１とシステムメモリ
２１で通信プロトコルの処理、アプリケ−ションプログ
ラムの処理および通信装置全体の総合的な制御を行う。
システムメモリ２１はシステムプロセッサ１で動く各種
プログラムコ−ドの他に通信デ−タの蓄積部としても利
用する。プログラムとしては、図１２に示すように、通
信プロトコルを処理するプロトコルプログラム２１３、
アプリケ−ションプログラム２１１があり、プロトコル
プログラム２１３にはプロトコルバッファ２１４、アプ
リケ−ションプログラム２１１にはアプリケ−ションバ
ッファ２１２がある。図１２において、システムプロセ
ッサ１は、例えば基本バイト長が４バイトの３２ビット
プロセッサ、システムメモリ２１はアドレスが４バイト
おきにワ−ド境界があるものとする。したがってシステ
ムプロセッサ１は、システムメモリ２１に対してワ−ド
境界から一度に４バイト分の情報を読み書きすることが
できる。

【００３８】図１３は、図１２のデ−タ通信装置を送信
装置８、受信装置９に適用してデ−タ通信を行う場合の
プログラム構成図である。図１３の送信装置８と受信装
置９は、それぞれ図１２のデ−タ通信装置で構成されて
おり、図１２のアプリケ−ションプログラム２１１と図
１３のアプリケ−ションプログラム８０及び９０、図１
２のアプリケ−ションバッファ２１２と図１３のアプリ
ケ−ションバッファ８１及び９１、図１２のプロトコル
プログラム２１３と図１３の送信処理プログラム８３及
び受信処理プログラム９３、図１２のプロトコルバッフ
ァ２１４と図１３のデ−タバッファ８４、ヘッダバッフ
ァ８６及びプロトコルバッファ９４、図１２の通信コン
トロ−ラ２４と図１３の通信コントロ−ラ８８及び９
６、とは同じものである。

【００３９】伝送路１３に流れるデ−タフレ−ムは図４
に示すフォ−マットと同じになっている。図４におい
て、デ−タフレ−ム３００は、フレ−ムヘッダ３０１、
プロトコルヘッダ３０２、アプリケ−ションデ−タ３０
３及びフレ−ムテ−ラ３０４から構成されており、フレ
−ムヘッダ３０１には宛先アドレス情報が、フレ−ムテ
−ラ３０４にはデ−タエラ−を検出するためのチェック
コ−ド情報が入っている。フレ−ムヘッダ３０１の生成
は、図１３に示す送信処理プログラム８３で、解読を通
信コントロ−ラ９６と受信処理プログラム９３で行い、
プロトコルヘッダ３０２の方は、生成を送信処理プログ
ラム８３で、解読を受信処理プログラム９３で行う。ま
た、フレ−ムテ−ラ３０４は、生成、解読を通信コント
ロ−ラ８８と９６でそれぞれ行う。アプリケ−ションデ
−タ３０３はアプリケ−ションプログラム８０から９０
に渡されるデ−タの一部である。伝送路１３では一度に
送れるデ−タ量に制限があるため、アプリケ−ションデ
−タを分割して転送する。

【００４０】最初に、図１３に示す送信装置８の動作に
ついて説明する。アプリケ−ションプログラム８０の動
作フロ−チャ−トは図５と同じになる。処理ｓ５１で
は、システムメモリ上に先頭アドレスがワ−ド境界にな
るように送信用アプリケ−ションバッファ８１を割付
け、処理ｓ５２ではアプリケ−ションバッファ８１にア
プリケ−ションデ−タ８２を用意し、処理ｓ５３では図
１３に示す送信処理プログラム８３を起動した後、処理
ｓ５４で送信処理プログラム８３からの送信終了報告を
待つ。

【００４１】アプリケ−ションプログラム８０から送信
の指示があると、送信処理プログラム８３は図１４に示
すフロ−チャ−トにしたがって動作する。処理ｓ１４１
では、伝送路１３の最大伝送量をもとにしてアプリケ−
ションデ−タの伝送量を、基本バイト長の整数倍になる
ように決める。

【００４２】伝送量の決め方は図１０と同じであり、こ
こでは省略する。

【００４３】図１３に示す送信装置８、受信装置９のシ
ステムプロセッサに、例えば、基本バイト長８バイトの
６４ビットプロセッサ、伝送路１３にEthernet仕様、送
信処理プログラム８３、受信処理プログラム９３が扱う
通信プロトコルにＴＣＰ／ＩＰを用いた場合のフレ−ム
フォ−マットを図１７に示す。Ethernetヘッダ長が１４
バイト、ＴＣＰ／ＩＰヘッダ長が４０バイトであり、ア
プリケ−ションデ−タの伝送量は８の整数倍の１４５６
バイトになる。最大デ−タ伝送量よりも４バイト減る
が、バッファ間でのデ−タコピ−を高速に行うことがで
きるため、結果的にデ−タ通信の性能が向上する。

【００４４】同様に、図１３に示す送信装置８、受信装
置９のシステムプロセッサに基本バイト長８バイトの６
４ビットプロセッサ、伝送路１３にＦＤＤＩ(Fiber Dis
tributed Data Interface)仕様、送信処理プログラム８
３、受信処理プログラム９３が扱う通信プロトコルにＴ
ＣＰ／ＩＰを用いた場合のフレ−ムフォ−マットを図１
８に示す。ＦＤＤＩヘッダ長が１３バイト、ＬＬＣ(Log
ical Link Control)ヘッダ長が３バイト、ＳＮＡＰ(Sub
Network Access Protocol)ヘッダ長が５バイト、ＴＣ
Ｐ／ＩＰヘッダ長が４０バイトであり、アプリケ−ショ
ンデ−タの伝送量は８の整数倍の４４２４バイトにな
る。最大デ−タ伝送量４４３０バイトに対して６バイト
減るが、バッファ間でのデ−タコピ−を高速に行うこと
ができるため、結果的にデ−タ通信の性能が向上する。

【００４５】システムプロセッサのペ−ジサイズが４０
９６バイトの場合、アプリケ−ションデ−タの伝送量を
４０９６バイトにしても結果的にデ−タ通信の性能が向
上する。

【００４６】図１４に示す処理ｓ１４２では、上記方法
で得た伝送量分のデ−タバッファ８４を確保する。デ−
タバッファ８４の先頭アドレスはワ−ド境界に配置す
る。処理ｓ１４３では、アプリケ−ションバッファ８１
からデ−タバッファ８４にアプリケ−ションデ−タ８２
の一部を、基本バイト長を単位としてコピ−する。つぎ
に、処理ｓ１４４では、通信プロトコルのヘッダ長また
はそれ以上の長さのヘッダバッファ８６を確保して、処
理ｓ１４５でヘッダ情報をヘッダバッファ８６の中のワ
−ド境界から生成する。

【００４７】図１４に示す処理ｓ１４６では、通信コン
トロ−ラ８８に対して送信の指示を出す。通信コントロ
−ラ８８は通信処理プログラム８３からの送信指示があ
ると、ヘッダバッファ８６の中のヘッダ８７とデ−タバ
ッファ８４の中のアプリケ−ションデ−タ８５を続けて
伝送路１３上に送出する。送信が終了した時点でヘッダ
バッファ８７、デ−タバッファ８４は解放される。処理
ｓ１４７では、まだ送信するデ−タが残っていれば、処
理ｓ１４１に戻って上記動作を繰り返す。デ−タが残っ
ていなければ、処理ｓ１４８でアプリケ−ションプログ
ラム８０に送信が終了した旨を通知する。

【００４８】図１４の実施例では、アプリケ−ションプ
ログラム８０と送信処理プログラム８３は、通信コント
ロ−ラ８８に送信指示しただけで送信が完了したように
動作するが、これを受信装置９からの確認応答を待つよ
うにすることもできる。

【００４９】つぎに受信装置９の動作について説明す
る。アプリケ−ションプログラム９０の動作フロ−チャ
−トは図７と同じになる。処理ｓ７１では、システムメ
モリ上に先頭アドレスがワ−ド境界になるように受信用
アプリケ−ションバッファ９１を割付け、処理ｓ７２で
は図１３に示す受信処理プログラム９３を起動した後、
処理ｓ７３で受信処理プログラム９３からの受信終了報
告を待つ。

【００５０】アプリケ−ションプログラム９０から受信
指示があると、受信処理プログラム９３は、図１５に示
すフロ−チャ−トにしたがって動作する。処理ｓ１５１
では、まず、システムメモリ上に１乃至複数のプロトコ
ルバッファ９４を確保する。処理ｓ１５２では、通信コ
ントロ−ラ９６に対して、伝送路１３からのデ−タをプ
ロトコルバッファ９４に受信するように指示する。この
とき、受信フレ−ムを受信した際にアプリケ−ションデ
−タの先頭アドレスがワ−ド境界になるように指示す
る。フレ−ムが受信する先頭アドレスの境界は、図９を
用いると簡単に求まる。処理ｓ１５３では、通信コント
ロ−ラ９６からの受信報告を待つ。通信コントロ−ラ９
６が伝送路１３からのフレ−ムデ−タをプロトコルバッ
ファ９４に受信すると、受信処理プログラム９３に通知
する。通信コントロ−ラ９６から受信通知を受けると、
受信処理プログラム９３は、図１５に示すフロ−チャ−
トの処理ｓ１５４で、プロトコルバッファ９４に入って
いるフレ−ムデ−タ９５のうち、ヘッダ情報を処理し
て、処理ｓ１５５ではヘッダ情報を除くアプリケ−ショ
ンデ−タだけ取り出して、アプリケ−ションバッファ９
１に対し、すでに受信したデ−タの次の場所からコピ−
する。このとき、前のデ−タの長さが基本バイト長の整
数倍になっているため、次のデ−タを格納する先頭アド
レスもワ−ド境界になり、したがってアプリケ−ション
バッファ９１とプロトコルバッファ９４のデ−タアドレ
ス境界が一致するため、両バッファに対して基本バイト
単位にデ−タコピ−が可能である。つぎに処理ｓ１５６
では使用したプロトコルバッファ７４を初期化して再度
受信用として使用する。処理ｓ１５７では受信デ−タが
残っているときには、処理ｓ１５３で次の受信を待ち、
全デ−タを受信したときは、処理ｓ１５８で受信終了を
アプリケ−ションプログラム９０に通知して終了する。

【００５１】図１６は、図１３のデ−タ通信システムを
図５、図７、図１４、図１５のフロ−チャ−トにしたが
って動作させたときに、バッファ間をデ−タが流れる様
子を示したものである。各バッファに付けられている目
盛は、図１１と同様に、１バイトごとのアドレスを表し
ており、左から右にアドレスが進む。逆三角形の記号が
付いている箇所はワ−ド境界を表している。図１６で
は、伝送路の最大デ−タ伝送量を１０バイトにした。シ
ステムプロセッサの基本バイト長が４バイトであるた
め、アプリケ−ションデ−タの伝送量は、図１４に示す
処理ｓ１４１から、８バイトになる。図１６は、アプリ
ケ−ションバッファ８１１から最初に８バイトのアプリ
ケ−ションデ−タ８２３を送った後、次の８バイトのア
プリケ−ションデ−タ８２４を送受信している状態を示
している。通信プロトコルに用いるヘッダ情報のサイズ
は５バイトとした。送信装置側のデ−タバッファ８４
１、ヘッダバッファ８６１に格納されるアプリケ−ショ
ンデ−タ及びヘッダ情報の先頭アドレスは、図１４に示
す処理ｓ１４３、処理ｓ１４５によりワ−ド境界にな
る。このとき、アプリケ−ションバッファ８１１からデ
−タバッファ８４１へのコピ−は、両方のデ−タの先頭
アドレス境界が一致しているため、基本バイト長、４バ
イト単位にコピ−が可能である。

【００５２】一方、受信装置側では、プロトコルバッフ
ァ９４１に格納されるフレ−ムデ−タの先頭アドレス
は、図１５に示す処理ｓ１５２により、３バイト境界、
アプリケ−ションデ−タの先頭アドレスはワ−ド境界に
なる。プロトコルバッファ９４１からアプリケ−ション
バッファ９１１にアプリケ−ションデ−タをコピ−する
ときは、両方の先頭アドレス境界が一致しているため、
基本バイト長単位に高速にコピ−が可能である。

【００５３】

【発明の効果】以上説明してきたように、本発明によれ
ば、バッファ間を高速にデ−タ移動が可能になり、通信
システム全体のスル−プットが向上し、その実用的効果
は大きい。

【図面の簡単な説明】

【図１】本発明の実施例を示すデ−タ通信装置の構成図
である。

【図２】本発明のデ−タ通信装置のプログラム構成図で
ある。

【図３】本発明者の先の発明によるデ−タ通信動作例を
示す図である。

【図４】本発明の処理方法を説明するためのフレ−ムフ
ォ−マット図である。

【図５】本発明の送信側アプリケ−ションプログラムの
処理フロ−チャ−ト図である。

【図６】本発明の送信処理プログラムの処理フロ−チャ
−ト図である。

【図７】本発明の受信側アプリケ−ションプログラムの
処理フロ−チャ−ト図である。

【図８】本発明の受信処理プログラムの処理フロ−チャ
−ト図である。

【図９】本発明の処理方法を説明するためのアドレス境
界決定テ−ブル図である。

【図１０】本発明の伝送量算出の処理フロ−チャ−ト図
である。

【図１１】本発明のデ−タ通信動作例を示す図である。

【図１２】本発明の別の実施例を示すシステムメモリ直
結タイプデ−タ通信装置の構成図である。

【図１３】本発明のシステムメモリ直結タイプデ−タ通
信装置のプログラム構成図である。

【図１４】本発明のシステムメモリ直結タイプデ−タ通
信装置を使った送信処理プログラムの処理フロ−チャ−
ト図である。

【図１５】本発明のシステムメモリ直結タイプデ−タ通
信装置を使った受信処理プログラムの処理フロ−チャ−
ト図である。

【図１６】本発明のシステムメモリ直結タイプデ−タ通
信装置を使ったデ−タ通信動作例を示す図である。

【図１７】本発明のシステムメモリ直結タイプデ−タ通
信装置を使ったEthernet ＬＡＮ上のフレ−ムフォ−マ
ット例を示す図である。

【図１８】本発明のシステムメモリ直結タイプデ−タ通
信装置を使ったＦＤＤＩ ＬＡＮ上のフレ−ムフォ−マ
ット例を示す図である。

【符号の説明】

１…プロセッサ、１１、２１…システムメモリ、１３…
伝送路、１４、２４…通信コントロ−ラ、６、８…送信
装置、７、９…受信装置、１１３…プロトコルプログラ
ム、１１１、６０、７０、８０、９０…アプリケ−ショ
ンプログラム、６３、８３…送信処理プログラム、７
３、９３…受信処理プログラム。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁵ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｈ０４Ｌ 12/40 (72)発明者 堀本 徹 神奈川県横浜市戸塚区戸塚町5030番地株式 会社日立製作所ソフトウェア開発本部内 (72)発明者 島本 幸夫 神奈川県横浜市戸塚区吉田町292番地株式 会社日立製作所マイクロエレクトロニクス 機器開発研究所内 (72)発明者 宮本 貴久 神奈川県横浜市戸塚区吉田町292番地株式 会社日立製作所マイクロエレクトロニクス 機器開発研究所内

Claims (8)

【特許請求の範囲】
1. 【請求項１】基本バイト長単位に通信プロトコルをプロ
   グラムで処理するプロセッサと、通信デ−タの送受信を
   行うためのロ−カルメモリと、該プログラム及び該通信
   デ−タを蓄積するシステムメモリを装備し、アプリケ−
   ションデ−タの伝送量を調整しながらデ−タ通信を行う
   デ−タ通信装置であって、前記伝送量を該基本バイト長
   の整数倍にして該通信デ−タの送受信を行うことを特徴
   とするデ−タ通信装置。
2. 【請求項２】前記ロ−カルメモリに送信用バッファを設
   け、当該デ−タ通信装置が送信側に使用される場合、該
   送信用バッファ上のアプリケ−ションデ−タを格納する
   先頭アドレスが、前記基本バイト長を単位にして区切っ
   たときのワ−ド境界と一致することを特徴とする請求項
   １記載のデ−タ通信装置。
3. 【請求項３】前記ロ−カルメモリに受信用バッファを設
   け、前記デ−タ通信装置が受信側に使用される場合、該
   受信用バッファ上のアプリケ−ションデ−タを格納する
   先頭アドレスが、前記基本バイト長を単位にして区切っ
   たときのワ−ド境界と一致することを特徴とする請求項
   １記載のデ−タ通信装置。
4. 【請求項４】基本バイト長単位に通信プロトコルをプロ
   グラムで処理するプロセッサと、プログラム及び通信デ
   −タを蓄積するシステムメモリを装備し、アプリケ−シ
   ョンデ−タの伝送量を調整しながらデ−タ通信を行うデ
   −タ通信装置であって、前記伝送量を該基本バイト長の
   整数倍にして前記システムメモリに直接デ−タの送受信
   を行うことを特徴とするデ−タ通信装置。
5. 【請求項５】前記システムメモリに送信用バッファを設
   け、前記デ−タ通信装置が送信側に使用される場合、該
   送信用バッファ上のアプリケ−ションデ−タを格納する
   先頭アドレスが、前記基本バイト長を単位にして区切っ
   たときのワ−ド境界と一致することを特徴とする請求項
   ４記載のデ−タ通信装置。
6. 【請求項６】前記システムメモリに受信用バッファを設
   け、前記デ−タ通信装置が受信側に使用される場合、該
   受信用バッファ上のアプリケ−ションデ−タを格納する
   先頭アドレスが、前記基本バイト長を単位にして区切っ
   たときのワ−ド境界と一致することを特徴とする請求項
   ４記載のデ−タ通信装置。
7. 【請求項７】Ethernet ＬＡＮを通してデ−タ通信を行
   う６４ビットプロセッサを搭載したデ−タ通信装置であ
   って、一度に送るアプリケ−ションデ−タの長さが１４
   ５６バイトであることを特徴とするデ−タ通信システ
   ム。
8. 【請求項８】ＦＤＤＩ ＬＡＮを通してデ−タ通信を行
   う６４ビットプロセッサを搭載したデ−タ通信装置であ
   って一度に送るアプリケ−ションデ−タの長さが４４２
   ４バイトであることを特徴とするデ−タ通信システム。