JPH06125365A - 通信制御装置 - Google Patents

Abstract

(57)【要約】 【目的】本発明は通信制御装置に関し、特に、データ送
受信処理を高速に行う方法を提供することにある。 【構成】通信プロトコルプログラム２２とそれが管理す
るプロトコルバッファと、伝送路３を制御する通信コン
トローラ４とそれが管理するネットワークバッファを備
え、プロトコルバッファと通信バッファを共有させ、伝
送路３からのフレームデータを共有させた通信バッファ
に直接書き込み、読みだしができるように構成する。 【効果】伝送路とプロトコルの間でバッファを共有する
ため、余分なデータ移動が発生せず、通信システム全体
のスループットが向上するという効果がある。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

【従来の技術】従来、ＬＡＮ等の高速な伝送路をパーソ
ナルコンピュータやワークステーションなどの情報処理
装置に接続するための通信コントローラは、その構造の
違いから、インテリジェントタイプとノンインテリジェ
ントタイプに分けられている。インテリジェントタイプ
の通信コントローラは、システムプロセッサやシステム
メモリが接続されているバスに通信コントローラを接続
するためのバスコントローラと、伝送路を直接制御しな
がらフレームデータの送受信を行うネットワークコント
ローラと、下位層のプロトコル処理を行うローカルプロ
セッサ、そして通信データを格納するためのローカルメ
モリで構成される。通信コントローラは、必要に応じて
例えばＯＳＩ参照モデルの２層以下に関する処理を行
い、３層以上はシステムプロセッサの方に任せる。伝送
路とシステムメモリとは通信コントローラを介して接続
され、フレームデータは、一旦、ローカルメモリに蓄積
された後、システムプロセッサがシステムメモリにコピ
−することになる。したがって、例えばＦＤＤＩ（Fibe
r Distributed Data Interface）のように伝送能力が１
００Ｍｂｐｓもある高速ＬＡＮ（Local Area Network）
の場合、フレームデータをバスを通して直接システムメ
モリに転送するノンインテリジェントタイプに比べる
と、バスにかかる集中負荷を緩和することができ、その
ために生じるアンダーラン、オーバランエラーを防ぐこ
ともできる。この構成例としては、例えば特開平２−３
２６５０号公報に記載されている。

【０００３】ノンインテリジェントタイプの通信コント
ローラは、ロ−カルプロセッサを持たないタイプであ
り、伝送路を直接制御しながらフレ−ムデ−タの送受信
を行なうネットワークコントローラと、通信デ−タを格
納するためのロ−カルメモリで構成される。ネットワー
クコントローラは例えばＯＳＩ参照モデルの１層（物理
層）と１．５層（メディアアクセス制御）に関する処理
を伝送路の伝送速度に合わせてリアルタイムで行う。デ
−タフレ−ムは、ネットワークコントローラにより、一
旦、ロ−カルメモリに蓄積された後、システムプロセッ
サがシステムメモリにコピ−することになる。そのた
め、ロ−カルプロセッサで下位層を処理する分、インテ
リジェントタイプに比べると性能が上がる。又、ロ−カ
ルプロセッサを持たない分安価になる。これについて
は、例えば、電子情報通信学会秋季大会論文誌（１９９
２年、Ｂ−４３３，北村他、ワ−クステ−ションに於け
る高速プロトコル処理を目指した性能評価）やＩＥＥＥ
Communication Magazine(June,1989,David D.Clark他、
An Analysis of TCP Processing Overhead)に記載され
ている。

【０００４】

【発明が解決しようとする課題】しかしながら上記従来
技術では、システムメモリとロ−カルメモリの間でデ−
タコピ−が生じてしまうため、その分性能が劣化してし
まう。又、システムプロセッサを用いてデ−タを移動す
るためシステムプロセッサの負荷も重くなる。

【０００５】システムメモリとロ−カルメモリの間のデ
−タコピ−を、システムプロセッサを使わずに通信コン
トロ−ラで行なう場合にも問題がある。例えば、通信コ
ントローラが扱うバッファとプロトコルプログラムが扱
うバッファのフォーマットがそれぞれ異なる場合にデー
タを移し変える必要が生じる。受信を例にあげると、ま
ず、通信コントローラがシステムメモリ上に用意したバ
ッファに自分のフォーマットでデータを転送する。その
後、プロトコルプログラムが取り扱うバッファに移し変
える。通信コントローラが取り扱うバッファとは、例え
ば固定アドレスに一定サイズを割り当てた通信コントロ
ーラハードウェア専用のバッファであり、プロトコルプ
ログラムが取り扱うバッファとは、例えば小サイズのエ
リアを複数個チェインで接続し、フレーム長に応じてエ
リアの個数を変えてメモリを有効に使うようにしたバッ
ファである。このためバッファ間でデータを移動するの
に時間がかかり、その分性能が劣化してしまう。

【０００６】これらの問題は、複数の通信プロトコルを
処理するマルチプロトコル処理装置や、複数のネットワ
−クをサポ−トするマルチネットワ−ク制御装置でも存
在する。

【０００７】本発明は、上記通信制御システムにおい
て、伝送路を制御する通信ハードウェアと通信プロトコ
ルを処理するソフトウェア間で直接データ転送が可能な
高速通信制御装置を提供することを目的とする。

【０００８】

【課題を解決するための手段】上記目的を達成するため
に、本発明の通信制御装置は、通信プロトコルを処理す
るプロトコルプログラムとそのプロトコルプログラムが
管理するプロトコルバッファと、伝送路を制御しデータ
の送受信を行う通信コントローラとその通信コントロー
ラが管理する通信バッファを備える。そして、システム
メモリ上にプロトコルバッファと通信バッファを共有さ
せた共有バッファを設け、通信プロトコルと通信コント
ローラの間で無駄なコピーを行うことなく伝送路からの
フレームデータを授受できるようにした。

【０００９】さらに、共有バッファは複数のエリアで構
成した。

【００１０】また、通信コントローラを、伝送路を直接
制御するネットワークコントローラとバスを制御するバ
スコントローラだけで構成し、伝送路からのフレームデ
ータを途中でバッファリングすることなくシステムメモ
リ上の共有バッファに転送する。

【００１１】また、通信コントローラを、伝送路を直接
制御するネットワークコントローラとバスを制御するバ
スコントローラの他に、ローカルプロセッサとローカル
メモリで構成し、伝送路からのフレームデータを通信コ
ントローラ内部のローカルメモリに一旦バッファリング
した後、通信コントローラがシステムメモリ上の共有バ
ッファに転送を行う。

【００１２】また、上記共有バッファを、データを格納
するデータバッファと通信プロトコルプログラムがデー
タバッファを管理するためのプロトコルバッファ記述子
と通信コントローラがデータバッファを管理するための
通信バッファ記述子で構成した。

【００１３】また、上記共有バッファにプロトコルを選
択する手段を追加して、複数の通信プロトコルを処理で
きるようにした。

【００１４】また、上記伝送路と上記共有バッファを複
数個設けるとともに、通信プロトコルプログラムに伝送
路を選択する手段を追加して、送信デ−タを該当する伝
送路に送出できるようにした。

【００１５】また、上記伝送路選択手段により、伝送路
からの受信フレ−ムデ−タを通信プロトコルプログラム
が受け取り、処理または加工した後、バッファ間でデ−
タ移動を行なうことなく別の伝送路に送出できるように
した。

【００１６】また、非同期で独立に動いている二つの処
理部Ａ，Ｂを有する装置において、二つの処理部の間に
処理部Ａが管理するバッファと処理部Ｂが管理するバッ
ファの二つを共有させた共有バッファを設け、二つの処
理部で無駄なコピ−を行なうことなく、高速にデ−タ通
信をできるようにした。

【００１７】

【作用】上記手段により本発明は、プロトコルバッファ
と通信バッファを共有させるため余分なデータ移動が発
生せず高速にデータを通信する。

【００１８】また、上記手段により本発明は、フレーム
データを連続して送受信したり、一つのフレームデータ
を複数に分割して格納する。

【００１９】また、上記手段により本発明は、伝送路と
通信プロトコルでフレームデータを直接授受する。

【００２０】また、上記手段により本発明は、フレーム
データをバスを通して直接システムメモリに転送する上
記の場合と違い、バスにかかる集中負荷を緩和すること
ができ、そのために生じるアンダーラン、オーバランエ
ラーを防ぐこともでき、さらに通信コントローラと通信
プロトコル間でフレームデータを直接授受することがで
きる。

【００２１】また、上記手段により本発明は、上記した
プロトコルバッファ記述子と通信バッファ記述子をそれ
ぞれキュー構造にして使用する。

【００２２】また、上記手段により本発明は、複数の通
信プロトコルにたいしても伝送路との間でフレ−ムデ−
タを直接授受する。

【００２３】また、上記手段により本発明は、複数の伝
送路にたいしても通信プロトコルとフレ−ムデ−タを直
接授受する。

【００２４】また、上記手段により本発明は、バッファ
間での無駄なデ−タの移動を行なうことなく、一方の伝
送路から別の伝送路にフレ−ムデ−タを通すことがで
き、高速なブリッジ、ル−タやゲ−トウェイが実現でき
る。

【００２５】また、上記手段により本発明は、二つの独
立した処理部間でバッファを共有させるため、余分なデ
ータ移動が発生せず高速にデータを通信する。

【００２６】

【実施例】以下、本発明の実施例を構成図、フローチャ
ート図を用いて説明する。

【００２７】図１は、本発明の一実施例における通信制
御システムの構成を示すブロック図である。通信制御シ
ステムは、通信プロトコルを実行するシステムプロセッ
サ１とシステムメモリ２、伝送路３を制御しながらデー
タの送受信を行う通信コントローラ４から構成される。
バス８は上記構成要素を接続するためのもので、それぞ
れの情報交換に使用する。この時、制御コード、通信デ
ータ等の情報が流れる。構成の中でシステムプロセッサ
１とシステムメモリ２で通信プロトコルの処理、アプリ
ケーションプログラムの処理及び通信制御システム全体
の総合的な制御を行う。システムメモリ２はシステムプ
ロセッサ１で動く各種プログラムコードの他に通信デー
タの蓄積部としても利用する。プログラムとしては、図
１に示すように、通信コントローラ４を制御するドライ
バ２１、通信プロトコルを処理するプロトコルプログラ
ム２２、アプリケーションプログラム２３、ドライバ２
１とプロトコルプログラム２２が使うプロトコルバッフ
ァの管理を行うバッファ管理部２５がある。その他オペ
レーティングシステム等があるがここでは直接関係しな
いので省略する。

【００２８】通信コントローラ４がノンインテリジェン
トタイプの場合の内部構造とデータ受信の動作概要につ
いて説明する。

【００２９】図１２にノンインテリジェントタイプの通
信コントローラ４の内部構造を示す。ネットワークコン
トローラ４２は伝送路３を直接制御しながらデータの送
受信を行う。バスコントローラ４１は、ネットワークコ
ントローラ４２を図１に示すバス８に接続するためのも
のである。ネットワークコントローラ４２は、例えば、
ＡＭＤ社製のＡｍ７９Ｃ９００を用いるものとする。送
信の場合、バスコントローラ４１はネットワークコント
ローラ４２の指示により、図１に示すシステムメモリ２
の中のデータをバス８を介して読みだし、これをネット
ワークコントローラ４２が伝送路３に送出する。受信の
場合、まず伝送路３からのデータをネットワークコント
ローラ４２が受け取り、これをバスコントローラ４１が
ネットワークコントローラ４２の指示により、バス８を
介してシステムメモリ２に転送する。送受信が終了した
後は、ネットワークコントローラ４２からバスコントロ
ーラ４１を通してシステムプロセッサ１に送信終了割込
み信号２１６及び受信割込み信号２１７でその旨通知す
る。

【００３０】図１３にノンインテリジェントタイプの通
信コントローラ４を使ってデータ受信を行っている様子
を示す。ドライバ２１は、プロトコルプログラム２２と
通信コントローラ４で共有する共有バッファ２１５と、
受信割込み処理部２１３で構成し、プロトコルプログラ
ム２２はプロトコル受信キュー２２２と送受信処理部２
２１で構成する。受信動作を簡単に説明する。最初に共
有バッファ２１５に受信のための空きバッファを用意し
ておく。伝送路３からデータが送られて来ると、まず通
信コントローラ４が受信データを逐次ＤＭＡ(Direct Me
mory Access)機能によってバス８を介してシステムメモ
リ２の中の共有バッファ２１５に書き込む。受信が終了
すると、通信コントローラ４は受信割込み信号２１７に
よりシステムプロセッサ１に受信があったことを知らせ
る。システムプロセッサ１はこれによりドライバ２１の
受信割込み処理部２１３を起動する。受信割込み処理部
２１３は受信データが入っているバッファを共有バッフ
ァ２１５から取り出してプロトコル受信キュー２２２に
つなぎ、プロトコルプログラム２２の送受信処理部２２
１を起動する。送受信処理部２２１はプロトコル受信キ
ュー２２２から受信データを取り出し、通信プロトコル
処理を行った後、その中からアプリケーションデータだ
けをアプリケーションプログラム２３に引き渡す。共有
バッファ２１５をプロトコル受信キュー２２２に実際に
つなぐ方法としては、共有バッファ２１５の先頭位置を
示すポインタをプロトコル受信キュー２２２にセットす
ることにより行う。したがって受信データが移動するわ
けではない。

【００３１】つぎに通信コントローラ４がインテリジェ
ントタイプの場合の内部構造とデータ受信の動作概要に
ついて説明する。

【００３２】図１４にインテリジェントタイプの通信コ
ントローラ４の内部構造を示す。通信コンロトーラ４
は、伝送路３を直接制御しながらデータの送受信を行う
ネットワークコントローラ４５、通信コントローラ４を
バス８に接続するためのバスコントローラ４３、フレー
ムデータを格納するローカルデータメモリ４４、下位層
の通信プロトコルの処理及び通信コントローラ４全体の
制御を行うローカルプロセッサ４６とローカルメモリ４
７から構成される。バス４８はローカルプロセッサ４６
とローカルメモリ４７とバスコントローラ４３とネット
ワークコントローラ４５を接続するためのもの、バス４
９はローカルデータメモリ４４とバスコントローラ４３
とネットワークコントローラ４５を接続するためのもの
で、それぞれの情報交換に使用する。送信の場合、バス
コントローラ４３が、ローカルプロセッサ４６の指示に
より図１に示すシステムメモリ２の中のデータをバス８
を介して読みだし、これをローカルデータメモリ４４に
一旦蓄積する。必要に応じてローカルプロセッサ４６が
これにネットワークヘッダを付加してフレームデータに
組み立てる。続いてネットワークコントローラ４５がロ
ーカルプロセッサ４６の指示によりこのフレームデータ
を伝送路３に送出する。一方、受信の場合は送信と逆の
動きになり、まず、ネットワークコントローラ４５がロ
ーカルプロセッサ４６の指示により伝送路３からのフレ
ームデータをローカルデータメモリ４４に書き込み、必
要に応じてローカルプロセッサ４６がネットワークヘッ
ダを取り除く。続いてバスコントローラ４３がローカル
プロセッサ４６の指示によりこのデータをバス８を介し
てシステムメモリ２に転送する。送受信が完了した後
は、ローカルプロセッサ４６からバスコントローラ４３
を通してシステムプロセッサ１に送信終了割込み信号２
１６または受信割込み信号２１７でその旨通知する。図
１５にインテリジェントタイプの通信コントローラ４を
使ってデータ受信を行っている様子を示す。ドライバ２
１とプロトコルプログラム２２は図１３に示すものと同
じであり、中の構成要素に対して同一番号を付けてあ
る。受信動作を簡単に説明する。最初にローカルメモリ
４４と共有バッファ２１５に、受信のための空きバッフ
ァを用意しておく。伝送路３からデータが送られて来る
と、まずネットワークコントローラ４５が受信データを
順次ローカルデータメモリ４４に書き込む。受信が終了
すると、ローカルプロセッサ４６が受信データからネッ
トワークヘッダを取り除き、残りをバスコントローラ４
３に指示してシステムメモリ２上の共有バッファ２１５
に転送する。転送が終わると、ローカルプロセッサ４６
はバスコントローラ４３を通して受信割込み信号２１７
を使ってシステムプロセッサ１に受信があったことを通
知する。システムプロッサ１はこれによりドライバ２１
の受信割込み処理部２１３を起動する。受信割込み処理
部２１３は共有バッファ２１５の中の受信データが入っ
ているバッファをプロトコル受信キュー２２２につなぎ
プロトコルプログラム２２の送受信処理部２２１を起動
する。送受信処理部２２１はプロトコル受信キュー２２
２から受信データを取り出し、通信プロトコル処理を行
った後、その中からアプリケーションデータだけをアプ
リケーションプログラム２３に引き渡す。共有バッファ
２１５をプロトコル受信キュー２２２に実際につなぐ方
法としては、共有バッファ２１５の先頭位置を示すポイ
ンタをプロトコル受信キュー２２２にセットすることに
より行う。したがって受信データが移動するわけではな
い。

【００３３】図１３、図１５において、共有バッファ２
１５を複数のエリアで構成することもできる。この場
合、エリア単位にフレームデータを格納すれば、空きエ
リアをフレーム送受信の度に用意する必要が無くなり、
バッファ不足エラーを起こすことなくフレームデータを
連続して送受信することができる。

【００３４】プロトコルヘッダとアプリケーションデー
タを別のエリアに格納し、これをつなげて一つのフレー
ムを表現すれば、プロトコルプログラム２２でプロトコ
ルヘッダの付加や取外しが容易になる。

【００３５】また、共有バッファ２１５を、データを格
納するためのデータバッファとプロトコルプログラム２
２がこのデータバッファを管理するためのプロトコルバ
ッファ記述子と通信コントローラ４がデータバッファを
管理するための通信バッファ記述子で構成し、プロトコ
ルバッファ記述子と通信バッファ記述子をそれぞれキュ
ー構造にする。これによりプロトコルプログラム２２と
通信コントローラ４の間で通信データの授受が容易にな
る。

【００３６】つぎにドライバ２１について更に詳細に説
明する。図１３、図１５で説明したように、ドライバ２
１は通信コントローラ４の種類には関係がなく、ノンイ
ンテリジェントタイプとインテリジェントタイプの両方
で動くものである。

【００３７】ドライバ２１の内部構成を図５に示す。ド
ライバ２１には、送信終了割込み処理部２１１、送信処
理部２１２、受信割込み処理部２１３からなるプログラ
ムと、通信データを待ち行列にしてつないでおくための
送信キュー２１４、受信キュー２１５がある。送信終了
割込み処理部２１１と受信割込み処理部２１３は図１に
示す通信コントローラ４からの送信終了割込み２１６と
受信割込み２１７によって起動され、送信処理部２１２
はプロトコルプログラム２２によって起動される。送信
キュー２１４と受信キュー２１５は、ドライバ２１の中
のプログラムと通信コントローラ４の双方が共有できる
バッファを数珠繋ぎにしたものである。送信キュー２１
４と受信キュー２１５は、言い替えると、処理の遅延が
許されるプロトコルと非同期リアルタイムで動く伝送路
３をつなぐ時間緩衝バッファでもある。送信終了割込み
処理部２１１、送信処理部２１２、受信割込み処理部２
１３のフローチャートを図１１、図１０、図９にそれぞ
れ示す。

【００３８】図７、図８は、図５の送信キュー２１４、
受信キュー２１５の詳細構造を表したものである。二つ
のキューは通信バッファ記述子とプロトコルバッファで
構成する。通信バッファ記述子は図１に示す通信コント
ローラ４がデータバッファをアクセスするのに必要な情
報を記憶するためのものである。一方プロトコルバッフ
ァは図１に示すバッファ管理部２５で管理されており、
ドライバ２１及びプロトコルプログラム２２で取扱われ
るバッファである。プロトコルバッファは、バッファ記
述子とデータを格納するバッファが一体になった構造で
ある。

【００３９】まず、図７の送信キュー２１４について説
明する。図７の例では送信するフレームデータが二つ格
納されており、最初のフレームは（ＴｘＤ００＋ＴｘＤ
０１）のチェインになったデータ、２番目のフレームは
（ＴｘＤ１０）単独データである。

【００４０】送信キュー２１４の中のプロトコルバッフ
ァは、図７に示すように、ポインタ（ｉｆ−ｓｎｄ）が
先頭のバッファＴＢ００の位置を指す。バッファが存在
していなければポインタ（ｉｆ−ｓｎｄ）は０となる。
バッファＴＢ００，ＴＢ０１，ＴＢ１０は、例えば、１
１２バイトのデータ格納エリアと、各種バッファ管理情
報を持ち、全体を１２８バイトで構成する。バッファ管
理情報のうち、ポインタ（ｍ−ｎｅｘｔ）は次のチェイ
ンデータが入っているバッファの位置を、オフセット
（ｍ−ｏｆｆ）はデータが格納している相対位置を、デ
ータ長（ｍ−ｌｅｎ）は格納されているデータの長さ
を、ポインタ（ｍ−ａｃｔ）は次のフレームデータが入
っているバッファの位置を表す。バッファＴＢ０１では
オフセット（ｍ−ｏｆｆ）によりデータ格納エリアをペ
ージバッファＴＰＧ０にとる。ページバッファＴＰＧ０
は、例えば、４Ｋバイトの容量を持ち、大きなデータを
格納するときに使用する。ページバッファが使われてい
るか否かはオフセット（ｍ−ｏｆｆ）の値でわかる。オ
フセット（ｍ−ｏｆｆ）はそのバッファの先頭からデー
タが入っているところまでの相対位置を表すため、その
値がバッファの長さ、すなわち１２８を超えたとき、ペ
ージバッファが使われていることになる。

【００４１】送信キューの通信バッファ記述子は、図７
に示すように、例えば４ワードからなるディスクリプタ
ＴＤ００，ＴＤ０１，ＴＤ１０．．．の集まりで構成
し、リング状にして使われる。各ディスプリプタＴＤ０
０，ＴＤ０１，ＴＤ１０の中で、アドレス（ＡＤＲ）は
送信データが入っているバッファの先頭アドレスを、デ
ータ長（ＢＣＮＴ）は格納されているデータの長さを表
す。データ長（ＢＣＮＴ）はプロトコルバッファの中の
データ長（ｍ−ｌｅｎ）と同じ値となる。制御権フラグ
（ＤＩＲ）は、このディスクリプタが通信コントローラ
４（ＤＩＲ＝１）ないしドライバ２１又はプロトコルプ
ログラム２２（ＤＩＲ＝０）によって占有されているこ
とを示す。ドライバ２１はこのディスクリプタによって
指定したエリアにデータを満たした後で制御権フラグ
（ＤＩＲ）を１にセットする。通信コントローラ４はバ
ッファの内容を送信した後、制御権フラグ（ＤＩＲ）を
０にクリアする。先頭フラグ（ＳＴ），最終フラグ（Ｅ
Ｎ）はフレームの先頭及び最終バッファを表すのに用い
る。ＳＴ＝１の時これがそのフレームの最初のバッフ
ァ、ＥＮ＝１の時これがそのフレームの最終バッファで
あることを表す。図７ではディスクリプタＴＤ００とプ
ロトコルバッファＴＢ００，ＴＤ０１とＴＢ０１，ＴＤ
１０とＴＢ１０がそれぞれ同じ送信データのエリアを指
している。

【００４２】つぎに受信キューについて説明する。受信
キュー２１５は、図８に示すように、基本的には図７に
示す送信キュー２１４と同じ構造である。ディスクリプ
タの中のサイズ（ＬＥＮ）は用意した受信バッファエリ
アの長さを表す。本受信キューを使ってデータを受信す
る場合は予め複数のフレームが入るプロトコルバッファ
とディスクリプタを作っておく必要がある。通信コント
ローラ４はフレームを受信すると、ディスクリプタが指
すエリアに順次データを格納し、ディスクリプタに受信
したデータのデータ長（ＢＣＮＴ）及び先頭フラグ（Ｓ
Ｔ）、最終フラグ（ＥＮ）及び制御権フラグ（ＤＩＲ）
をセットする。

【００４３】以上のように構成された本実施例の通信制
御装置の動作について説明する。

【００４４】便宜上、本通信制御装置が扱う通信プロト
コルはＴＣＰ／ＩＰ(TransmissionControl Protocol/In
ternet Protocol)とＩＥＥＥ８０２．３、ＩＥＥＥ８０
２．２の下位プロトコルとする。伝送路３に流れるデー
タフレームは図２に示すフォーマットになっている。図
２において、データフレーム２００は、フレームヘッダ
２０１、プロトコルヘッダ２０２、ユーザデータ２０３
及びフレームテーラ２０４より構成されており、フレー
ムヘッダ２０１には宛先アドレス情報が、フレームテー
ラ２０４にはデータエラーを検出するためのチェックコ
ード情報が入っている。図２の構成のうち、フレームヘ
ッダ２０１は、生成を図１に示すプロトコルプログラム
２２で、解読を通信コントローラ４で行い、プロトコル
ヘッダ２０２の方は生成、解読いずれもプロトコルプロ
グラム２２で行う。また、フレームテーラ２０４は生
成、解読いずれも通信コントローラ４で行われる。ユー
ザデータ２０３はアプリケーションプログラム２３で使
われるものであり、アプリケーションプログラム２３か
らプロトコルプログラム２２に渡される。プロトコルヘ
ッダ２０２はＩＰとＴＣＰそれぞれ図３，図４のような
構成になっている。

【００４５】図１において、伝送路３から来たデータフ
レームの受信動作は次のようになる。符号化されたフレ
ームを通信コントローラ４で復号し、バイト単位に組立
てる。図８に示す受信キューには、バス８を介して図２
に示すデータフレームのうちフレームヘッダ２０１、プ
ロトコルヘッダ２０２、ユーザデータ２０３が書き込ま
れる。この時、通信コントローラ４では図２に示すフレ
ームヘッダ２０１を判定し自分あてのデータフレームだ
けを受信するようにする。このとき、フレームテーラ２
０４によりデータが正しいかどうかチェックも行う。デ
ータフレームが受信されると、通信コントローラ４から
受信割込み信号２１７でプロセッサ１に割込み、図５に
示すドライバ２１の受信割込み処理部２１３が起動され
る。

【００４６】受信割込み処理部２１３の動作フローチャ
ートを図９に示す。処理９１で、図８に示すディスクリ
プタの制御権フラグ（ＤＩＲ＝０）をサーチして受信さ
れたプロトコルバッファを捜す。バッファが見つかる
と、処理９２でこれを受信キュー２１５からはずし、図
６に示すプロトコル受信キュー２２２に接続する。キュ
ーのはずし方はプロトコルバッファのポインタ（ｍ−ｎ
ｅｘｔ），（ｍ−ａｃｔ）を操作するだけで簡単にでき
る。図６に示すプロトコル受信キュー２２２の構造も図
７又は図８のプロトコルバッファと同じである。従っ
て、この時、データが入ったバッファをそのままつなぎ
変えるためデータの移動は発生しない。つぎに、処理９
３でバッファ管理部２５から空バッファをもらい、受信
キュー２１５に接続しておく。この時、当然ディスクリ
プタも変更する。最後の処理９４で、例えばソフトウェ
ア割込みを使ってプロトコルプログラム２２を起動す
る。

【００４７】プロトコルプログラム２２はつぎのように
動作する。プロトコル受信キュー２２２からデータフレ
ームを取りだして図２に示すプロトコルヘッダ２０２に
対する処理を行った後、フレームヘッダ２０１とプロト
コルヘッダ２０２を取りはずしてユーザデータ２０３だ
けをアプリケーションプログラム２３に渡す。

【００４８】送信動作は受信と逆の動作になる。アプリ
ケーションプログラム２３からデータ送信要求がある
と、プロトコルプログラム２２はアプリケーションプロ
グラム２３からユーザデータを受け取り、これに図２に
示すプロトコルヘッダ２０２とフレームヘッダ２０１を
付加し、図５に示す送信処理部２１２に渡す。プロトコ
ルプロラム２２で使用するバッファはバッファ管理部２
５が管理するバッファである。

【００４９】送信処理部２１２の動作フローチャートを
図１０に示す。処理１０１で、プロトコルプログラム２
２から受け取ったバッファを図７に示す送信キューの最
後尾に接続する。この時当然ディスクリプタも作成す
る。続いて、処理１０２で通信コントローラ４を起動す
る。通常、通信コントローラ４は送信キューに接続され
ているデータを順番に伝送路３に送出するため、データ
フレームを連続して送信する場合は通信コントローラ４
を起動する必要がない。処理１０２は通信コントローラ
４が停止している場合を考慮したものである。

【００５０】通信コントローラ４は送信キューで送信待
ちになっているデータフレームを順次取りだしビット列
に変え符号化して伝送路３に送り出す。この時、図２に
示すフレームテータ２０４を最後に付加する。送信が終
了すると通信コントローラ４は送信終了割込み信号２１
６でプロセッサ１に割込み、図５に示すドライバ２１の
送信終了割込み処理部２１１が起動される。

【００５１】送信終了割込み処理部２１１の動作フロー
チャートを図１１に示す。処理１１１で、図９に示すデ
ィスクリプタの制御権フラグ（ＤＩＲ＝０）をサーチし
て送信が終了したプロトコルバッファを捜す。バッファ
が見つかると、処理１１２でこれをキューからはずし、
バッファ管理部２５に戻す。

【００５２】図２１は、本発明の別の実施例における通
信制御システムの構成を示すブロック図である。図１で
は、通信コントロ−ラ、通信プロトコル、アプリケ−シ
ョンプログラムがいずれも一つで構成したのに対して、
図２１は通信制御装置２１０１に二つの通信コントロ−
ラｃ１，ｃ２、二つのドライバｄ１，ｄ２、二つのプロ
トコルプログラムｐ１，ｐ２，三つのアプリケ−ション
プログラムａ１，ａ２，ａ３を持つシステムの例であ
る。本実施例では、図２１の構成の他に、図１に示すシ
ステムプロセッサ１やバス８等があるが、同じ動作をす
るのでここでは省略した。

【００５３】図２１に示す通信コントロ−ラｃ１とｃ２
はそれぞれ伝送路ｎ１，ｎ２を制御しながらデ−タの送
受信を行なう。これらの通信コントロ−ラは、図１に示
す通信コントロ−ラ４と同じものであり、図１２に示す
ノンインテリジェントタイプ、図１４に示すインテリジ
ェントタイプのいずれでも構わない。ドライバｄ１とｄ
２は、通信コントロ−ラｃ１，ｃ２をそれぞれ制御する
と共に、プロトコルプログラムｐ１，ｐ２との間でデ−
タ授受の仲介を行なう。プロトコルプログラムｐ１，ｐ
２は同じ内部構成をとり、図２４に示すように、送受信
処理部２４０１、プロトコルテ−ブル２４０３、プロト
コル受信キュ−２４０２から成る。

【００５４】まず、ドライバｄ１，ｄ２について説明す
る。ドライバｄ１，ｄ２の内部構成は、図５に示す構成
と同じであるが、受信割込み処理部２１３の動作だけが
異なる。受信割込み処理部２１３の動作フロ−チャ−ト
を図２３に示す。処理２３０２、処理２３０４以外の処
理は図９に示した動作フロ−チャ−トと同じである。処
理２３０１で、図５に示す受信キュ−２１５から、受信
したデ−タフレ−ムが入っているプロトコルバッファを
抽出する。プロトコルバッファには、図２に示すデ−タ
フレ−ムのうちフレ−ムヘッダ２０１、プロトコルヘッ
ダ２０２、ユ−ザデ−タ２０３が入っている。処理２３
０２では、このデ−タフレ−ムの中のフレ−ムヘッダ２
０１部分からプロトコルの種類を調べる。

【００５５】ＩＥＥＥ８０２．３，ＩＥＥＥ８０２．
２，ＳＮＡＰ(Sub Network AccessProtocol)のフレ−ム
ヘッダのフォ−マットを図２２に示す。フレ−ムヘッダ
の中で”ＴＹＰＥ”フィ−ルドがプロトコル識別子にな
っており、例えば、TYPE＝２０４８ではＴＣＰ／ＩＰ，
TYPE＝２０５４ではＡＲＰ(Address ResolutionProtoco
l)となる。処理２３０２では、プロトコルがわかると、
続いて、プロトコルバッファを該当するプロトコルプロ
グラムの中のプロトコル受信キュ−２４０２に接続す
る。この時、デ−タが入ったバッファをそのままつなぎ
変えるためデ−タの移動は発生しない。つぎに、処理２
３０３で空きバッファを図５に示す受信キュ−２１５に
接続し、処理２３０４で、例えばソフトウェア割込みを
使って、図２１に示すｐ１またはｐ２のうち該当するプ
ロトコルプログラムを起動する。

【００５６】プロトコルプログラムｐ１またはｐ２の受
信動作は以下のようになる。図２４に示す送受信処理部
２４０１は、プロトコル受信キュ−２４０２からデ−タ
フレ−ムを取り出して、図２に示すプロトコルヘッダ２
０２に対する処理を行なった後、フレ−ムヘッダ２０１
とプロトコルヘッダ２０２を取り外してユ−ザデ−タ２
０３だけを図２１に示すアプリケ−ションプログラムａ
１，ａ２，ａ３のいずれかに渡す。

【００５７】アプリケ−ションプログラムの選択には図
２４に示すプロトコルテ−ブル２４０３を用いる。プロ
トコルテ−ブル２４０３にはあらかじめ図２５に示すよ
うな内容を登録しておく。アドレスとは装置に付けた通
信窓口の番号である。受信の場合、相手アドレス、自ア
ドレスは、例えば図４に示すプロトコルヘッダの中の"S
ource Address"，"Destination Address"である。ポ−
ト番号とはアプリケ−ションプログラムに付けた通信窓
口の番号である。受信の場合、相手ポ−ト番号、自ポ−
ト番号は、例えば図３に示す"Source Port","Destinati
on Port"である。これらのアドレス、ポ−ト番号と、ア
プリケ−ションプログラム識別子、それに相手局がつな
がっている伝送路と１対１に対応するドライバの識別子
を、セットにして登録する。受信したデ−タフレ−ムか
ら該当するアプリケ−ションプログラムを選択するに
は、プロトコルヘッダの中から"Destination Port"を抽
出し、図２５のプロトコルテ−ブルを使ってこれに対応
するアプリケ−ションプログラム識別子を求めることに
より実現できる。

【００５８】プロトコルプログラムｐ１またはｐ２の送
信動作はつぎのようになる。図２１に示すアプリケ−シ
ョンプログラムａ１，ａ２，ａ３のいずれかからデ−タ
送信要求があると、プロトコルプログラムｐ１またはｐ
２は、図２４に示す送受信処理部２４０１において、ア
プリケ−ションプログラムからユ−ザデ−タを受け取
り、これに図２に示すプロトコルヘッダ２０２とフレ−
ムヘッダ２０１を付加して図２１に示すドライバｄ１，
ｄ２のいずれかに渡す。ドライバの選択にも図２４に示
すプロトコルテ−ブル２４０３を用いる。プロトコルテ
−ブル２４０３には、図２５に示すように、自ポ−ト番
号に対応して相手のアプリケ−ションプログラムがつな
がっている伝送路すなわちドライバの識別子が登録され
ており、このドライバ識別子で使用するドライバがわか
る。

【００５９】図２６は、図２１の通信制御システムを用
いたル−タの実施例を示す図である。通信制御装置２６
０１の中の構成要素は図２１と同じであり、同一番号を
付けてある。伝送路ｎ１にはステ−ション２６０２、伝
送路ｎ２にはステ−ション２６０３が接続されており、
図２６では、伝送路ｎ１上のステ−ション２６０２から
通信制御装置２６０１を介して異なる伝送路ｎ２上のス
テ−ション２６０３にデ−タを送信している様子を示し
ている。ステ−ション２６０２からのデ−タは伝送路ｎ
１、通信コントロ−ラｃ１を通ってドライバｄ１の中の
共有バッファに、途中でバッファリングされることなく
実時間で入る。プロトコルプログラムｐ１は、このバッ
ファの中のデ−タフレ−ムに対してプロトコルヘッダと
フレ−ムヘッダを取り替えた後、このバッファをドライ
バｄ２の中の共有バッファにつなぐ。つなぎ変えられた
共有バッファのデ−タは、ドライバｄ２，通信コントロ
−ラｃ２，伝送路ｎ２を通してステ−ション２６０３に
実時間で届けられる。ドライバｄ１，プロトコルプログ
ラムｐ１，ドライバｄ２の間では同じバッファが使われ
るため、バッファ間での無駄なデ−タの移動がない。

【００６０】つぎに、図７、図８に示す通信バッファ記
述子とプロトコルバッファの別の制御方法について説明
する。

【００６１】図１６は、図７に示す通信バッファ記述子
とプロトコルバッファの関係を定義した送信用通信−プ
ロトコルバッファ変換テーブル１６０１の構成例を示し
た図である。送信用通信−プロトコルバッファ変換テー
ブル１６０１は、図５に示す送信キュー２１４の一部に
含まれる。

【００６２】図１６に示す送信用通信−プロトコルバッ
ファ変換テーブル１６０１の各行番号は、図７に示す通
信バッファ記述子内のディスクリプタ番号ＴＤ００、Ｔ
Ｄ０１・・・に対応している。チェインフラグは、チェ
インの先頭（ＳＴ＝１）か、終り（ＥＮ＝１）かを示
す。各項目には、さらにディスクリプタに対応するプロ
トコルバッファのアドレス（仮想アドレス）、プロトコ
ルバッファ内のデータのアドレス（仮想アドレス及び実
アドレス）をそれぞれ格納する。 仮想アドレスとは、
仮想記憶方式を使ってアクセスされるアドレスで、一般
のプログラム中で使用される。

【００６３】実アドレスとは、メモリに対して物理的に
つけられるアドレスで、ＤＭＡ（ＤｉｒｅｃｔＭｅｍｏ
ｒｙＡｃｃｅｓｓ）で伝送路とシステムメモリ間のデー
タを転送する際、システムメモリのアドレスとして通信
コントローラにより使用される。

【００６４】送信時、通信コントローラ４は、システム
メモリ２上にある通信バッファ記述子内のディスクリプ
タをサーチし、そこに登録されている送信バッファのア
ドレスを基に送信データを伝送路に送出する。このと
き、通信コントローラ４の扱うアドレスは、実アドレス
なので、ディスクリプタ内に登録する送受信データのア
ドレスは、実アドレスでなければならない。これに対
し、プロトコルプログラム２２及びドライバ２１は、プ
ロトコルバッファの仮想アドレスにより、送信データを
アクセスする。このため、送信データの仮想アドレスか
ら実アドレスへの変換テーブルが必要になる。

【００６５】図１９は、図５に示す送信処理部２１２の
動作フローチャートである。処理１９０３で、プロトコ
ルプログラム２２から受け取ったバッファから、バッフ
ァの先頭アドレス（仮想アドレス）と、データの先頭ア
ドレス（仮想アドレス）を求め、送信ディスクリプタの
番号に対応する送信用通信−プロトコルバッファ変換テ
ーブル１６０１に値をセットする。これを図７及び図１
６の構成例で説明する。ディスクリプタＴＤ００、ＴＤ
０１、ＴＤ１０に対し、プロトコルバッファＴＢ００，
ＴＢ０１，ＴＢ１０より送信データの仮想アドレスＴｘ
Ｄ００、ＴＰＧ０、ＴｘＤ１０を求め、実アドレスＲ＿
ＴｘＤ００、Ｒ＿ＴＰＧ０、Ｒ＿ＴｘＤ１０に変換した
後、ディスクリプタ番号に対応する行位置に各データを
格納する（１９０４）。そして、送信用通信−プロトコ
ルバッファ変換テーブル１６０１を基にディスクリプタ
を更新し（１９０５）、通信コントローラを起動する
（１０２）。

【００６６】図１８は、図５に示す送信終了割込み部２
１１の動作フローチャートである。送信終了割込み処理
部２１１は、送信終了したバッファを、図７に示すディ
スクリプタから抽出し（１１１）、ディスクリプタの当
該番号から送信用通信−プロトコルバッファ変換テーブ
ル１６０１を用いて、プロトコルバッファのアドレス
（仮想アドレス）を求め、図１に示すバッファ管理部２
５に戻す（１８１０）。そして、送信用通信−プロトコ
ルバッファ変換テーブル１６０１及びディスクリプタを
更新して（１８１１）、処理が終了する。

【００６７】図１７は、図８に示す、通信バッファ記述
子とプロトコルバッファの関係を定義した受信用通信プ
ロトコルバッファ変換テーブル１７０１の構成例を示し
た図である。受信用通信プロトコルバッファ変換テーブ
ル１７０１は、図５に示す受信キュー２１５の一部に含
まれ、送信用通信プロトコルバッファ変換テーブル１６
０１と同様な項目を設定する。

【００６８】図２０は、図５に示す受信割込み処理部２
１３の動作フローチャートである。受信割込み２１７に
よって起動された受信割込み処理部２１３は、図８に示
すディスクリプタから受信したバッファを抽出し（９
１）、受信用通信−プロトコルバッファ変換テーブル１
７０１よりプロトコルバッファのアドレス（仮想アドレ
ス）を求める（２００３）。このプロトコルバッファを
プロトコルプログラム２２内の受信キューに登録してプ
ロトコルプログラム２２を起動する（９４）。つぎに、
新しい受信用のプロトコルバッファを図１に示すバッフ
ァ管理部２５から確保して（２００４）、受信ディスク
リプタを更新する（２００５）。このとき、受信用通信
−プロトコルバッファ変換変換テーブル１７０１にプロ
トコルバッファのアドレス（仮想アドレス）、データ部
のアドレス（仮想アドレス、実アドレス）を登録して
（２００６）、受信割込み処理は終了する。

【００６９】

【発明の効果】以上説明してきたように、本発明によれ
ば、伝送路とプロトコルの間でバッファを共有するた
め、バッファ間で余分なデータ移動が発生せず、通信シ
ステム全体のスループットが向上するばかりでなく、シ
ステムプロセッサの負荷も軽くなりその実用的効果は大
きい。

【図面の簡単な説明】

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

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

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

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

【図５】本発明のドライバの内部構成図である。

【図６】本発明のプロトコルプログラムの内部構成図で
ある。

【図７】本発明の送信キューの内部構成図である。

【図８】本発明の受信キューの内部構成図である。

【図９】本発明の受信割込み処理のフローチャート図で
ある。

【図１０】本発明の送信処理のフローチャート図であ
る。

【図１１】本発明の送信終了割込み処理のフローチャー
ト図である。

【図１２】本発明のノンインテリジェント通信コントロ
ーラの内部構成図である。

【図１３】本発明のノンインテリジェント通信コントロ
ーラを使ったデータフレーム受信動作例を示す図であ
る。

【図１４】本発明のインテリジェント通信コントローラ
の内部構成図である。

【図１５】本発明のインテリジェント通信コントローラ
を使ったデータフレーム受信動作例を示す図である。

【図１６】本発明の送信用通信−プロトコルバッファ変
換テ−ブルの構成図である。

【図１７】本発明の受信用通信−プロトコルバッファ変
換テ−ブルの構成図である。

【図１８】本発明の送信終了割込み処理のフローチャー
ト図である。

【図１９】本発明の送信処理のフローチャート図であ
る。

【図２０】本発明の受信割込み処理のフローチャート図
である。

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

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

【図２３】本発明の別の受信割込み処理のフロ−チャ−
ト図である。

【図２４】本発明の別のプロトコルプログラムの内部構
造図である。

【図２５】本発明のプロトコルテ−ブルの内部構成図で
ある。

【図２６】本発明の別の実施例を示す通信制御装置の構
成図である。

【符号の説明】

１…プロセッサ、 ２…システムメモリ、 ３…伝送路、 ４…通信コントローラ、 ２１…ドライバ、 ２２…プロトコルプログラム、 ２３…アプリケーションプログラム、 ２５…バッファ管理部。 ２１０１…通信制御装置 ２４０３…プロトコルテ−ブル ２６０１…通信制御装置 １６０１…送信用通信−プロトコルバッファ変換テ−ブ
ル １６０２…受信用通信−プロトコルバッファ変換テ−ブ
ル

───────────────────────────────────────────────────── フロントページの続き (72)発明者 堀本 徹 神奈川県横浜市戸塚区戸塚町5030番地株式 会社日立製作所ソフトウェア開発本部内 (72)発明者 島本 幸夫 神奈川県横浜市戸塚区吉田町292番地株式 会社日立製作所マイクロエレクトロニクス 機器開発研究所内

Claims (9)

【特許請求の範囲】
1. 【請求項１】システムプロセッサとシステムメモリとバ
   スで構成され、通信プロトコルをプログラムで処理する
   プロセッサシステムと、伝送路を制御しながらフレーム
   データの送受信を行う前記バスに接続された通信コント
   ローラを有する通信制御装置において、前記システムメ
   モリ上に前記通信プロトコルプログラムが管理するバッ
   ファと前記通信コントローラが管理するバッファの二つ
   を共有する共有バッファを設けるとともに、前記通信コ
   ントローラは、前記伝送路に流れる前記フレームデータ
   の書き込み及び読み出しを前記共有バッファに行うこと
   を特徴とする通信制御装置。
2. 【請求項２】請求項１記載の通信制御装置において、複
   数のエリアで前記共有バッファを構成し、前記フレーム
   データを連続して送受信し、または一つの前記フレーム
   データを複数に分割して格納することを特徴とする通信
   制御装置。
3. 【請求項３】請求項１または請求項２記載の通信制御装
   置において、前記通信コントローラを、前記伝送路を直
   接制御するネットワークコントローラと、前記バスを制
   御するバスコントローラとで構成するとともに、前記伝
   送路からの前記フレームデータを途中でバッファリング
   することなく前記共有バッファへの書き込みや読み出し
   を行い、前記伝送路と前記通信プロトコルで前記フレー
   ムデータを直接授受することを特徴とする通信制御装
   置。
4. 【請求項４】請求項１または請求項２記載の通信制御装
   置において、前記通信コントローラを、前記伝送路を直
   接制御するネットワークコントローラと、前記バスを制
   御するバスコントローラと、ローカルプロセッサ及びロ
   ーカルメモリとで構成するとともに、前記伝送路からの
   前記フレームデータを前記通信コントローラ内部の前記
   ローカルメモリに一旦バッファリングして、下位層の通
   信プロトコル処理を行った後、前記通信コントローラが
   前記共有バッファに書き込みや読みだしを行い、該通信
   コントローラと前記通信プロトコルで前記フレームデー
   タを授受することを特徴とする通信制御装置。
5. 【請求項５】請求項１乃至請求項４記載の通信制御装置
   において、前記共有バッファを、データを格納するデー
   タバッファと、前記通信プロトコルプログラムが該デー
   タバッファを管理するためのプロトコルバッファ記述子
   と、前記通信コントローラが該データバッファを管理す
   るための通信バッファ記述子とで構成するとともに、該
   プロトコルバッファ記述子と該通信バッファ記述子をそ
   れぞれキュー構造にしたことを特徴とする通信制御装
   置。
6. 【請求項６】請求項１乃至請求項５記載の通信制御装置
   において、１乃至ｎ個の通信プロトコルに対応できるよ
   うに、前記通信プロトコルプログラムを通信プロトコル
   の個数分設け、前記共有バッファに受信したフレ−ムデ
   −タから該通信プロトコルプログラムを選択するプロト
   コル選択手段を有することを特徴とする通信制御装置。
7. 【請求項７】請求項１乃至請求項５記載の通信制御装置
   において、１乃至ｍ個の伝送路に対応できるように、前
   記伝送路ごとに前記共有バッファを複数個設け、前記通
   信プロトコルプログラムに伝送路を選択するための伝送
   路選択手段を追加し、デ−タを送信する場合、該伝送路
   選択手段で伝送路及び通信コントロ−ラ、共有バッファ
   を選択するようにしたことを特徴とする通信制御装置。
8. 【請求項８】請求項１乃至請求項５記載の手段を兼ね備
   える通信制御装置において、前記通信プロトコルプログ
   ラムが前記通信コントロ−ラからの受信フレ−ムデ−タ
   を受け取り、処理または加工した後、バッファ間でデ−
   タ移動を行なうことなく、別の前記通信コントロ−ラを
   通して前記伝送路に送出することを特徴とする通信制御
   装置。
9. 【請求項９】非同期に動いている第１の処理部と第２の
   処理部とを有する制御装置において、前記二つの処理部
   の間に、第１の処理部が管理するバッファと第２の処理
   部が管理するバッファの二つを共有する共有バッファを
   設け、該共有バッファを、データを格納するデータバッ
   ファと、第１の処理部が該データバッファを管理するた
   めの第１のバッファ記述子と、第２の処理部が該データ
   バッファを管理するための第２のバッファ記述子とで構
   成するとともに、第１のバッファ記述子と第２のバッフ
   ァ記述子をそれぞれキュー構造にしたことを特徴とする
   制御装置。