JP3729237B2 - ノード及びノード内のデータ処理方法 - Google Patents
ノード及びノード内のデータ処理方法 Download PDFInfo
- Publication number
- JP3729237B2 JP3729237B2 JP35170598A JP35170598A JP3729237B2 JP 3729237 B2 JP3729237 B2 JP 3729237B2 JP 35170598 A JP35170598 A JP 35170598A JP 35170598 A JP35170598 A JP 35170598A JP 3729237 B2 JP3729237 B2 JP 3729237B2
- Authority
- JP
- Japan
- Prior art keywords
- priority
- frame
- packet
- node
- 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
Landscapes
- Small-Scale Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ノード及びノード内のデータ処理方法に関するもので、より具体的には、優先度情報付きのフレームを送受信するデータ伝送システムに用いられるノード及びノード内のデータ処理方法に関する。
【０００２】
【従来の技術】
現在最も普及しているＬＡＮ（Local Area Network）システムとして、イーサネットがある。よく知られているように、このイーサネットは、ネットワークに接続される各ノード（端末）をスター型配線により物理的に接続し、パケットを送信する方式として、ＣＳＭＡ／ＣＤ（Carrier Sense Multiple Access with Collision Detection）方式を用いることが広く普及している。
【０００３】
このＣＳＭＡ/ＣＤ方式では、パケットを送信するノードは、予めネットワークの使用状態をチェックし、送信可能であればパケットを送り出し、他のノードがデータを転送中であることを確認すると、一定期間待った後再度使用状態のチェックをするようになる。従って、ネットワークに接続するノード数の増加や、ノード間で転送（送受信）されるデータ量が増加すると、帯域不足により送信待ちとなったり、データ（フレーム）の衝突が発生したりして、通信効率が低下する（伝送遅延時間が長くなる）ので、これを解消するために、通常スイッチングハブ（集線装置）を介して各ノードを接続するようにしたネットワーク構成が主流となる。
【０００４】
この集線装置は、あるポートで受信したフレームのイーサネットヘッドを解析し、そのフレームの宛先を認識したならばその宛先のノードが接続されているポートにのみ、その受信したフレームを中継するようにしている。これにより、例えば第１ノードから第２ノードにフレームを伝送中に、それとは別の第３ノードから第４ノードにフレームを伝送することが可能となる。つまり、複数のノードが同時に送信することが可能となる。
【０００５】
しかしながら、係る集線装置を用いたネットワークであっても、使用状態のチェックの結果、送信待ちとなることがある。そして、その送信待ちにともなう伝送遅延時間の大きさは、ネットワークの使用状況に応じて大きく変動し、しかも、そのように使用状況により決定されるため、実際に送信するまで伝送遅延時間の大きさは不明であり、伝送遅延時間の上限が保証できない。
【０００６】
従って、例えばＦＡ（ファクトリーオートメーション）におけるＬＡＮは、リアルタイム性が要求され、ＰＬＣ（プログラマブルロジックコントローラ）等の制御系のように生産ラインの制御に直接関係するデータを含むフレームは、伝送遅延時間の上限が保証されなければならないので、上記のように伝送遅延時間の上限が保証されない従来のイーサネットを用いてＦＡ用のＬＡＮを構築することはできなかった。
【０００７】
ところで、ＦＡのＬＡＮで伝送するデータには、ＰＬＣ等の制御系端末（ノード）の通信のように、生産ラインの制御に直接関係し、リアルタイムで迅速に伝送する必要のある制御系データと、パソコン端末（ノード）の通信のように、生産ラインの制御に直接関係せず、各種の統計情報等のリアルタイムで伝送する必要の無い情報系データがある。つまり、ネットワーク上を伝送されるフレームは、上記のように、リアルタイムで送る必要のある制御系データを含む優先度の高いフレームと、リアルタイムで送る必要の無い情報系データからなる優先度の低いフレームがある。
【０００８】
しかし、従来のイーサネットでは、フレームに優先度情報が無く、すべてのフレームが同等に扱われていたため、リアルタイムで送らなければならない制御系データを含むフレームが、情報系データのフレームの通信によって待たされることがある。係る現象は、ＦＡ用のＬＡＮに限ることはなく、各種のＬＡＮにおいても同様のことが言える。
【０００９】
そこで、近年、フレームに優先度を示すフィールドを設け、高優先度のフレームを低優先度のフレームより優先して送信する方法がＩＥＥＥ等で検討されている。これにより、低優先度のフレームによって高優先度のフレームの通信が妨げられる可能性が減少するため、制御系データを含むフレームのように高優先度のフレームの伝送遅延時間を短くし、リアルタイムでの通信が可能となる。すなわち、ＦＡ用のＬＡＮを、イーサネットを用いたＣＳＭＡ/ＣＤ方式のネットワークを構築することができる。
【００１０】
【発明が解決しようとする課題】
しかしながら、上記した優先度情報を備えたフレームの伝送システムでは、以下に示す問題がある。すなわち、実施の形態でも説明するように、集線装置は、高優先度のフレームを記憶するバッファと低優先度のフレームを記憶するバッファを備え、高優先度バッファに記憶されたフレームを優先的に送信することにより対応するようにした装置が開発されてきている。
【００１１】
一方、優先度情報を備えたフレームの伝送システムを構築するためには、フレームの送受信の基となるノード側もそれに対応する必要がある。係る場合、送受信するフレームに優先度情報が付加されることから、ＢＳＤ版ＵＮＩＸにおけるネットワークＩ／ＯのＡＰＩであるＳＯＣＫＥＴ Ｉ／Ｆ（ソケットインターフェース）を使用することができず、新たな拡張Ｉ／Ｆ（優先度対応の新たなＡＰＩ）を策定する必要がある。そして、そのように新たな拡張Ｉ／Ｆを策定すると、既存のアプリケーションをその拡張Ｉ／Ｆに対応し、優先度情報付きのフレーム（パケット）を送受できるアプリケーションに作り替えなければならず、その作業が非常に煩雑となる。
【００１２】
従って、集線装置までは対応できるものの、既存の各ノードに対して拡張Ｉ／Ｆ並びにアプリケーションをすべて作り替えることはできず、ノードは従前のものを使用することになる。すると、係るノードから送信されるフレームには優先度情報が無いので、結局集線装置内での処理は、低優先度となり、上記した本来的に優先度の高いフレームを優先的に送信できないという従来の問題が解決されない。
【００１３】
本発明は、上記した背景に鑑みてなされたもので、その目的とするところは、上記した問題を解決し、新たな通信のＡＰＩを追加すること無く、しかも、アプリケーションの作り替えをすること無く、優先度なしフレームに対応したアプリケーションやＡＰＩを使用したノードであっても、優先度付きフレームの送信及びまたは受信（通信）をすることができるノード及びノード内のデータ処理方法を提供することにある。
【００１４】
【課題を解決するための手段】
上記した目的を達成するために、本発明に係るノードでは、優先度付きフレームが伝送されるネットワークに接続取り外し可能なノードであって、送信パケットが送信予定のフレームについての優先度情報を有するパケットであるかどうかを判定する送信パケット解析処理手段と、前記送信パケットが前記送信パケット解析処理手段により優先度情報を有するパケットであると判定されたことに基づいて、送信予定のフレームを特定する情報（実施の形態では、「ポート番号」に対応）とそのフレームの優先度とを関連付けた優先度テーブル（実施の形態では、「ポート別優先度テーブル」に対応）を作成する優先度テーブル設定処理手段と、前記送信パケットが前記送信パケット解析処理手段により優先度情報を有するパケットでないと判定されたことに基づいて、前記送信パケットの優先度なしフレームに対し、前記優先度テーブルを参照して優先度を付加して優先度付きフレームを生成する送信パケット変換処理手段と、前記送信パケット変換処理手段が生成した優先度付きフレームを送信する送信手段を備えて構成した（請求項１）。
【００１５】
また、本発明に係るノード内のデータ処理方法では、ネットワークの接続対象であるノードにおけるデータ処理方法であって、送信パケットが送信予定のフレームについての優先度情報を有するパケットかどうかを判定し、上位層は送信予定のフレームについての優先度情報（実施の形態では、「優先度通知パケット」に対応）を下位層（実施の形態では、「イーサネットドライバが設置される層」）に対して送る。前記下位層は、受け取った優先度情報にしたがい送信予定のフレームを特定する情報と、そのフレームの優先度とを関連付けた優先度テーブル（実施の形態では、「ポート別優先度テーブル」に対応）を作成する。次いで送信パケット変換処理手段が上位層から受け取った優先度なしフレームに対し、前記優先度テーブルを参照して優先度を付加し、前記送信パケット変換処理手段が作成した優先度付きフレームを送信するようにした（請求項２）。
【００１６】
上記したノード及びデータ処理方法の発明では、上位層（例えばアプリケーション層等）から受け取った優先度なしフレームに対し優先度情報付加手段により優先度付きフレームに変換することができるので、その優先度情報付加手段よりも上位層は、従来の優先度なしフレーム（パケット）の状態で送信できる。よって、従来のＡＰＩなどに替えて優先度付きフレームを処理可能な拡張Ｉ／Ｆやアプリケーションを作成することなく、優先度付きフレームを伝送するネットワークに接続するノードを構成することができる。
【００１７】
また、本発明に係るノードは、好ましくは上記のノードを前提とし、外部から受け取ったパケットが優先度付きフレームか優先度なしフレームであるかどうかを判定する受信パケット解析処理手段と、前記受信パケットが前記受信パケット解析処理手段により優先度付きフレームと判定されたことに基づいて、前記優先度付きフレームから優先度情報を除去した優先度なしフレームを生成する優先度情報除去手段と、その優先度情報除去手段により生成された優先度なしフレームを上位層に送る手段を備えて構成することである（請求項３） 。
【００１８】
また、本発明に係るノード内のデータ処理方法は、好ましくは上述した処理方法の発明を前提として、外部から受け取ったパケットが優先度付きフレームか優先度なしフレームであるかどうかを判定し、受信パケット解析処理手段が優先度付きフレームを受信した際に、その受信したフレームから優先度情報を除去して優先度なしフレームを生成し、ついで、その生成した優先度なしフレームを上位層に送る（実施の形態では、一度受信通知をし、上位層からの転送要求を受けて送る）ようにすることである（請求項４）。
【００１９】
上記したノード及びデータ処理方法の発明では、外部（接続したネットワーク）から受け取ったデータが優先度付きフレームであった場合、そのフレームの中から優先度に関する情報を除去して上位層に送るので、上位層に転送する際には少なくとも係る優先度情報がなくなる、つまり、上位層は従来と同様の優先度なしフレームの状態でフレーム（パケット）の送受を行うことができる。
【００２０】
よって、従来のＡＰＩなどに替えて優先度付きフレームを処理可能な拡張Ｉ／Ｆやアプリケーションを作成することなく、優先度付きフレームを伝送するネットワークに接続するノードを構成することができる。
【００２１】
【発明の実施の形態】
図１は、本発明が適用されるＬＡＮの全体の概略構成を示している。同図に示すように、集線装置１を中心に伝送路２を介して各ノード３が接続されることによりネットワークが構築されている。このネットワークは、例えばノード３がＰＬＣ，センサ，パソコン等からなるＦＡに配置されたＬＡＮであり、ネットワーク接続された各ノード（ＰＬＣ等）が、協調動作・同期動作等しながら各種の処理を行うものに適用できる。もちろん、これ以外の各種のネットワークに適用できるのは言うまでもない。
【００２２】
また、集線装置１の内部構造としては、図２に示すようになっている。すなわち、集線装置１内には、データの送受を行う物理層１ａ及び通信コントローラ１ｂがあり、各物理層１ａは、所定のノード３に接続されている。これにより、通信コントローラ１ｂは、物理層１ａを介して受信したフレームを解析し、宛先のノードが接続された物理層１ａにそのフレームを転送するようになっている。さらに本形態では、高優先度フレームを格納する高優先度バッファ１ｃと、低優先度フレームを格納する低優先度バッファ１ｄを備えている。そして、それら高優先度バッファ１ｃ，低優先度バッファ１ｄのバッファあふれを監視するフロー制御機能部１ｅをさらに備えている。
【００２３】
係る構成からなる集線装置１では、通信コントローラ１ｂが、ノード３から送られてきたフレームの優先度を検出し、対応するバッファ１ｃ，１ｄに登録する。そして、高優先度バッファ１ｃに格納されたフレームから優先してその内容を解析し、宛先のノード３が接続されている物理層１ａにフレームを転送する機能を持つ。また、フロー制御機能部１ｅは、例えばバッファあふれを生じた場合に各ノードに対して送信の一時停止命令を発する機能などを有している。
【００２４】
また、本形態に用いられる優先度付きのフレーム（パケット）のフォーマットは、図３（ａ）に示すようになっている。すなわち、フレームの先頭にイーサネットヘッダがあり、続いて実際に送るデータ部分であるイーサネットデータがある。そして、イーサネットヘッダは、ＤＡ（宛先アドレス），ＳＡ（送信元アドレス），ＴＨ（優先度情報），Ｌ／Ｔ（データ長）の順に格納するようになっている。さらに、優先度情報は、ＵＰが「７」のときには高優先度を意味し、ＵＰが「１」のときには低優先度を意味する。よって、ＵＰフィールドでそのフレームの優先度の種別を判別することができる。また、ＴＰＩＤ，ＣＦＩ，ＶＩＤはそれぞれ上位層のプロトコルタイプを特定するタイプＩＤ（８１００固定），ルーティング情報（０固定），バーチャルＬＡＮのＩＤ番号（０固定）を意味する。
【００２５】
なお、従来の優先度なしフレームのデータフォーマットは、同図（ｂ）に示すようになっており、優先度付きのフレーム（同図（ａ））と比較すると明らかなように、ＴＨ（優先度情報）が無い。つまり、この優先度なしのフレームのＳＡエリアとＬ／Ｔエリアの間にＴＨエリアを挿入したものが優先度付きフレームとなる。
【００２６】
そして、本形態のノード３は、ノード３の内部（各層間）では、図３（ｂ）に示す優先度なしのフレームでの送受を行い、ノード３間、つまり、ノード３と集線装置１間では、優先度ありのフレームを送信するようにしている。すなわち、ノード３の内部に、外部に送出する際に優先度情報の無いフレームに対して優先度情報を付加する機能と、受け取った優先度ありのフレームから優先度情報を除去し、優先度なしのフレームに変換する機能を持たせている。そして具体的には、図４に示すようになっている。
【００２７】
すなわち、よく知られているように、イーサネット（ＰＣＴ／ＩＰのプロトコル）の階層化構造は、図４に示すように、最上位層としてのアプリケーション層５の下位側に、層間のインターフェースであるソケットと呼ばれるＡＰＩ６を介して、トランスポート層（ＴＣＰ／ＩＰ，ＵＤＰ）７，インターネット層（イーサネットドライバ）８，ＯＳ９，物理層（ハードウェア）１０の順に配置された構成となっている。
【００２８】
そして、係る構成におけるデータの流れとしては、通常ソケットと呼ばれるＡＰＩ６を利用し通信のアプリケーションを作成する。このアプリケーションからＡＰＩ６を通じてＴＣＰ／ＩＰ７に渡されたデータは、さらにイーサネットドライバ８に渡され、ドライバ８がＯＳ９を通じてハードウェア（イーサネットコントローラ）１０をアクセスし伝送路にパケットが送受信される。そして、イーサネットドライバ８にて、上記した優先度情報の付加・除去を行うようにしている。
【００２９】
すなわち、図に示すようにイーサネットドライバ８内に、図５のフローチャートを実施する機能を持った優先度情報付加処理部１１及び優先度設定テーブル１２並びに図６のフローチャートを実施する機能を持った優先度情報除去処理部１３を設ける。そして、イーサネットドライバ８のより具体的な内部構造は、図７に示すようになっている。
【００３０】
図７に示すように、上位層から初期化要求を受けると、ドライバ初期化処理部８ａ，ボード初期化処理部８ｂにより、ドライバ及びＥｔｈｅｒｎｅｔボードの初期化を行う。送信要求では、上位層から渡されたパケットを、イーサネット用のパケットに構成し、優先度順に送信する機能を実行する。
【００３１】
また、送信処理部８ｃは、受信した送信要求（上位層から通常の送信パケット（優先度通知パケットでない））にしたがい、Ｅｔｈｅｒｎｅｔボードにパケット送信を実行する。そして、本発明の優先度情報付加処理部１１が、この送信処理部８ｃと連携して配置され、後述するように上位層から優先度通知パケットを受信した場合に、その優先度情報付加処理部１１が稼動し、優先度設定テーブル１２に所定のデータを記憶する。
【００３２】
この優先度情報付加処理部１１は、本形態では上位層から渡されたパケットが、制御パケットか送信パケットであるかを解析する送信パケット解析処理部１１ａと、優先度設定テーブルに、ポートごとに優先度を保存する優先度テーブル設定処理部１１ｂと、指定されたポートの優先度をサーチしたり、優先度テーブルを操作し、優先度なしパケットを優先度付きのパケットフォーマットに変換する送信パケット変換処理１１ｃを備えている。
【００３３】
また、割り込みハンドラでは、ハードウェアからの受信部側に優先度情報除去処理部１３たる受信パケット変換処理部１３ａを設け、そこにおいて受信したパケットを、優先度付きのパケットフォーマットから、通常のパケットフォーマットに変換するようになっている。さらに、受信パケット解析処理部１３ｂでは、受信パケットの種類（優先度ありか否か）を判断し、優先度ありの場合には上記の受信パケット変換処理部１３ａを稼動させるようになっている。さらに、この受信パケット解析処理部１３ｂでは、優先度なしのパケットの受信を上位層に通知する機能も持つ。この通知機能は、従来も有するものである。但し異なるのは従来のものは受信したパケットはすべて優先度なしであるので、受信したらそれを通知すればよかったが、本形態では優先度付きとなしの両方のパケットが受信される可能性があるので、優先度なしの場合にはそのまま通知し、優先度付きの場合には優先度なしに変換後通知することになる。
【００３４】
さらに、この通知にしたがい上位層が発する受信パケット転送要求を受信すると、それにしたがい、指示された受信パケットを上位層に転送する機能や、上位層から終了要求を受けると、Ｅｔｈｅｎｅｔボードを停止し、ドライバが保有するすべてのリソースを開放する終了処理する機能などを有する。なお、優先度情報の付加／除去する機能以外は、従来からのイーサネットドライバと同様であるのでその詳細な説明を省略する。
【００３５】
ここで本発明では、データ送信用の通常のＡＰＩ６を利用してアプリケーション５がイーサネットドライバ８に設けた優先度設定テーブル６に優先度を登録できる特殊なパケットフォーマット（図８参照）を定義し、イーサネットドライバ８（優先度情報処理部５）は、パケットごとに優先度設定テーブルを参照して優先度をつける処理を行うようにしている。
【００３６】
ここでまずアプリケーションからイーサネットドライバに渡される優先度設定用のパケットフォーマットを説明すると、優先度設定用のパケットの場合には、図８に示すようにＵＤＰヘッダの中の先頭のＳｒｃ Ｐｏｒｔが９になっている。従って、９以外の場合は通常のデータパケットと判断できる。また、データ中の先頭のＲｅｑｕｅｓｔ Ｎｏは、設定を示す「１」となり、Ｐｏｒｔ Ｎｏは、アプリケーションが優先度付き通信を行おうとするポート番号を示し（ソケットＡＰＩにおいては、ポート番号を指定して通信を行っているため、そのポート番号が書き込まれている）、Ｐｒｉｏｒｉｔｙエリアには、その通信を行うデータが高優先度（７）か低優先度（１）かの情報がセットされている。
【００３７】
イーサネットドライバ８の優先度情報付加処理部１１は、上記した優先度通知パケットの受信にともない、優先度テーブル１２（図９参照）を作成し、また、通常のパケット（送信パケット）を受信したならば、優先度テーブル１２を参照して優先度情報を付加したパケットを作成し、データ送信をするようになっている。
【００３８】
そして、具体的には図５に示すように、まず、上位層から渡された送信要求を待ち（ＳＴ１）、受け付けたならばその送信要求のパケット種別を判断する（ＳＴ２）。つまり、９番ポートから送られてきたパケットか否かを判断し、９番ポートであれば優先度設定用のパケットであり、それ以外であればデータ送信用のパケットと判断できる。
【００３９】
そして、優先度設定用のパケットなら、ステップ９に飛び、優先度テーブルに優先度と対応ポートをセットする。具体的には、図８に示す優先度通知パケットのデータ部分を解析し、Ｐｏｒｔ Ｎｏエリアから優先度設定するポート番号（アプリケーションが、その設定しようとする優先度のフレームを送信する際に使用するポート番号）を取得し、Ｐｒｉｏｒｔｙエリアに格納された数値を取得する。そして、取得した２つの値（ポート番号と優先度）を関連付けて図９（ａ）に示すポート別優先度テーブルに格納する。すなわち、例えば図１０に示すような優先度通知パケットを受け付けた場合、データ部分から、ポート番号１０４８を使って送信するパケットの優先度が７（高優先度）となっているので、図５（ａ）に示すように該当するポート番号の優先度を７にセットする。係る処理をして優先度設定のための前処理（テーブル作成）を終了する。
【００４０】
一方、ステップ２の分岐判断で上位層から渡された送信要求がデータ送信用のパケットと判断された場合にはステップ３に飛びさらに、上位層で分割されたパケットなのか判定する。なお、分割されたパケットか否かは、ＩＰヘッダのフラグ（図示省略）から判断できる。
【００４１】
そして、分割されてなければ、ステップ６に飛び、優先度設定テーブル（ポート別優先度テーブル）１２をアクセスして対応するポートに関連付けられた優先度を読み出す（ＳＴ６）。つまり、例えばポート番号が先ほど登録した「１０４８」とすると、優先度は「７」という情報を読み出す。
【００４２】
次いで、受け付けたパケットのイーサネットヘッダ（図３（ｂ）に示すように優先度情報なし）のＳＡエリア（送信元アドレス）の後に、ＴＨエリア（優先度情報）を挿入したフレームを作成（優先度付きパケットフォーマットに変換）する。つまり、図３（ａ）に示したように、ＴＨエリアのうちＵＰエリアのみが可変（１／７）でそれ以外の固定であるので、テーブルから読み出した優先度（１／７）と固定の各値を適宜の順で挿入することになる。その後、そのように変換して生成した優先度付きフォーマットのデータを送信し、処理を終了する（ＳＴ８）。
【００４３】
また、受け付けたパケットが分割されたパケットの場合には、ステップ３からステップ４に飛び、さらに最初の分割パケットであるか否かを判断する。この判断も、ＩＰヘッダのフラグ（図示省略）から判断できる。つまり、実際の処理としては、ステップ３，４の判断はいっしょに行うことができる。
【００４４】
そして、最初の分割パケットの場合には、パケットの中のＩＤを読み出し、ＩＤと優先度を関連付けたテーブル：ＩＤフィールド別優先度テーブル（図９（ｂ）参照）を作成する。なお、優先度は、ポート番号よりポート別優先度テーブルを参照することにより認識できる。つまり、１度に送れる最大データ長が決まっているので、それ以上のデータを送る場合には、複数のパケットに分割して送ることになる。このとき、２つ目以降のパケットには、ＴＣＰ或いはＵＤＰの送信元ポートを特定する情報が含まれていないので、その２つ目以降の途中パケットの情報のみでは優先度を特定できない。
【００４５】
そこで、分割されたパケットのＩＤフィールド（ＩＤ番号）が同じ値になることを利用し、最初のパケットのＩＤ番号と優先度を関連付けたＩＤフィールド別優先度テーブル（図９（ｂ））を作成することにより、２番目以降のパケットは、ＩＤ番号からそのＩＤフィールド別優先度テーブルを参照することにより、そのＩＤ番号に対応する優先度（１／７）を知ることができるので、その取得した対応する優先度を、そのパケットを送信する際の優先度とすることができる。
【００４６】
そして、ステップ５を実行してテーブルを作成したならば、ステップ６に戻り上記した各処理を順に実行し、優先度付きのパケットに変換後データを送信するようになる。つまりテーブル（ポート別優先度データテーブル）を参照してそのポート番号に対応した優先度（１／７）を取得し、それに基づいて優先度付きパケットに変換する。なお、ステップ５を実行する際に優先度情報はすでにわかっているので、ステップ５をステップ７に飛び、そのわかっている優先度情報を用いて優先度付きパケットを組み立てるようにしてもよい。
【００４７】
さらに、分割された２つ目以降のパケットの場合には、ステップ４でＮｏとなるので、そのままステップ６に飛び、ＩＤフィールド別優先度テーブルより、対応するＩＤの優先度を読み出し、優先度付きパケットフォーマットに変換し（ＳＴ７）、ネットワークに送信する（ＳＴ８）。
【００４８】
そして、上記した各ステップと、図７に示す各処理部１１ａ〜１１ｃの関係は、送信パケット解析処理部１１ａはステップ１〜４の処理を行い、優先度テーブル設定処理部１１ｂがステップ５，９の処理を行い、送信パケット変換処理部１１ｃが、ステップ６，７の処理を行う。なお、ステップ８のデータ送信は、送信処理部８ｃが実行することになる。
【００４９】
上記したように、本形態では優先度テーブル１２として、「ポート別優先度テーブル」と「ＩＤフィールド別優先度テーブル」の２種類のテーブルを用意し、それらを使用することによりデータ長の長い複数のパケットに分割して送信するデータにも対応できるようにしている。但し、例えはＦＡ用のＰＬＣを制御するネットワークに適用した場合、分割しなければならないほどデータ長の長いデータを送ることはほとんどないので、ＩＤフィールド別優先度テーブル（図９（ｂ））はなくてもよい。その場合には、図５に示すステップ３から５の処理がなくなる。
【００５０】
そして、仮にＩＤフィールド別優先度テーブルを設けないイーサネットドライバを用いたノードにおいて複数に分割されたパケットを送信する場合には、２番目以降のパケットは優先度情報がないので、例えばオフセットとして設定される低優先度とすることにより対応できる。特に、ＰＬＣのＬＡＮの場合にデータ長が長いというのは、多くの場合情報系であると予測できるので、そのように低優先度に設定しても問題はない。なお、逆にデータ長が長く複数のパケットに分割して送信するものが、優先度の高いものが多い場合には、分割パケットの２つ目以後はすべて高優先度に設定するようにしてもよい。
【００５１】
一方、本形態のノード３のＡＰＩ６は、優先度付きのパケットを送受信できないため、ネットワークを介して受信した優先度付きのパケットを、イーサネットドライバ８で優先度なしのパケットに変換するようになっている。さらに、本形態では、優先度なしのパケットを送受信するネットワークにも対応できるように、優先度なしのパケットを受信した場合には、上記のような変換をすることなく上位層に送る（通常のデータ処理はもちろんする）ようになっている。そして、具体的には、図６に示すようなフローチャートを実行する機能を有している。
【００５２】
すなわち、まず、ハードウェア１０からの割り込み要求（伝送路２を介してネットワークから送られてきたパケット受信による割り込み）があったならば、その受信パケットが、優先度付きのものか優先度なしのものかを判断する（ＳＴ１１，ＳＴ１２）。この判断は、受信パケット解析処理部１３ｂが行う。
【００５３】
そして、優先度付きパケットと判断した場合には、ステップ１３に進み、優先度付きのパケットフォーマットから、通常のパケットフォーマットに変換する。すなわち、優先度付きフォーマット（図３（ａ）参照）のイーサネットヘッダのＴＨエリアを除去し、ＳＡエリアに続いてＬ／Ｔエリアを続けた１４バイトからなる優先度なしフォーマット（図３（ｂ）参照）のフレームに再構築する。そして、この処理は受信パケット変換処理部１３ａが実行する。その後、受信があったことを上位層に通知し、処理を終了する（ＳＴ１４）。この処理は、受信パケット解析処理部１３ｂが行う。
【００５４】
一方、優先度なしパケットを受信した場合、ステップ１２からステップ１４に飛び、上位層に対してパケット受信を通知し、処理を終了する。つまり、従来から行われている通常の受信処理を実行することになる。この一連の処理は、受信パケット解析処理部１３ｂが行う。
【００５５】
そして、通常であれば、この通知にしたがい上位層から受信パケット転送要求があるので、それを受けて受信パケットを上位層に転送する。また、上位層から終了要求を受けると、終了処理、つまり Ｅｔｈｅｎｅｔボードを停止し、ドライバが保有するすべてのリソースを開放する。
【００５６】
【発明の効果】
以上のように、本発明に係るノード及びノード内のデータ処理方法の第１の発明（請求項１，２）では、優先度情報付加手段により上位層から送られてきた優先度なしフレームが優先度付きフレームに変換（生成）されるので、その優先度情報付加手段よりも上位層は、優先度なしフレーム（パケット）の状態で送受信ができる。よって、新たなＡＰＩ（拡張Ｉ／Ｆ）を追加すること無く、アプリケーションを大幅に作り替えをすること無く、従来からあるアプリケーションや通常のＡＰＩや、ＵＤＰを使用して通信するノードであっても、接続したネットワークに対して優先度付きフレームを送信することができる。
【００５７】
また、第２の発明（請求項３，４）では、優先度情報除去手段により外部から受け取った優先度付きフレームを優先度なしフレームに作り変えるので、その優先度情報除去手段の設置層よりも上位層は、優先度なしフレームを受けることができる。よって、上記第１の発明と同様に、優先度付きフレームの通信を可能とする拡張Ｉ／Ｆやアプリケーションなどを製造する必要がなく、従来の優先度なしフレームを取り扱うＡＰＩやアプリケーションを備えたノードであっても、優先度付きフレームを受信し、所望の処理をすることができる。
【図面の簡単な説明】
【図１】 本発明が適用されるネットワークシステムの一例を示す図である。
【図２】 集線装置の内部構造を示す図である。
【図３】 （ａ）は、優先度付きフレームフォーマットを示す図である。
（ｂ）は、優先度なしフレームフォーマットを示す図である。
【図４】 本発明に係るノードの好適な一実施の形態を示す図である。
【図５】 主として優先度情報付加処理部の機能を示すフローチャートである。
【図６】 主として優先度情報除去処理部の機能を示すフローチャートである。
【図７】 イーサネットドライバの内部構造を示す図である。
【図８】 アプリケーションから送られる優先度設定通知パケットのフォーマットを示す図である。
【図９】 （ａ）は、ポート別優先度テーブルを示すデータ構造図である。
（ｂ）は、ＩＤフィールド別優先度テーブルを示すデータ構造図である。
【図１０】 優先度設定通知パケットの一例を示す図である。
【符号の説明】
３ ノード
８ イ−サネットドライバ（下位層）
１１ 優先度情報付加処理部
１２ 優先度テーブル
１３ 優先度情報除去処理部
【発明の属する技術分野】
本発明は、ノード及びノード内のデータ処理方法に関するもので、より具体的には、優先度情報付きのフレームを送受信するデータ伝送システムに用いられるノード及びノード内のデータ処理方法に関する。
【０００２】
【従来の技術】
現在最も普及しているＬＡＮ（Local Area Network）システムとして、イーサネットがある。よく知られているように、このイーサネットは、ネットワークに接続される各ノード（端末）をスター型配線により物理的に接続し、パケットを送信する方式として、ＣＳＭＡ／ＣＤ（Carrier Sense Multiple Access with Collision Detection）方式を用いることが広く普及している。
【０００３】
このＣＳＭＡ/ＣＤ方式では、パケットを送信するノードは、予めネットワークの使用状態をチェックし、送信可能であればパケットを送り出し、他のノードがデータを転送中であることを確認すると、一定期間待った後再度使用状態のチェックをするようになる。従って、ネットワークに接続するノード数の増加や、ノード間で転送（送受信）されるデータ量が増加すると、帯域不足により送信待ちとなったり、データ（フレーム）の衝突が発生したりして、通信効率が低下する（伝送遅延時間が長くなる）ので、これを解消するために、通常スイッチングハブ（集線装置）を介して各ノードを接続するようにしたネットワーク構成が主流となる。
【０００４】
この集線装置は、あるポートで受信したフレームのイーサネットヘッドを解析し、そのフレームの宛先を認識したならばその宛先のノードが接続されているポートにのみ、その受信したフレームを中継するようにしている。これにより、例えば第１ノードから第２ノードにフレームを伝送中に、それとは別の第３ノードから第４ノードにフレームを伝送することが可能となる。つまり、複数のノードが同時に送信することが可能となる。
【０００５】
しかしながら、係る集線装置を用いたネットワークであっても、使用状態のチェックの結果、送信待ちとなることがある。そして、その送信待ちにともなう伝送遅延時間の大きさは、ネットワークの使用状況に応じて大きく変動し、しかも、そのように使用状況により決定されるため、実際に送信するまで伝送遅延時間の大きさは不明であり、伝送遅延時間の上限が保証できない。
【０００６】
従って、例えばＦＡ（ファクトリーオートメーション）におけるＬＡＮは、リアルタイム性が要求され、ＰＬＣ（プログラマブルロジックコントローラ）等の制御系のように生産ラインの制御に直接関係するデータを含むフレームは、伝送遅延時間の上限が保証されなければならないので、上記のように伝送遅延時間の上限が保証されない従来のイーサネットを用いてＦＡ用のＬＡＮを構築することはできなかった。
【０００７】
ところで、ＦＡのＬＡＮで伝送するデータには、ＰＬＣ等の制御系端末（ノード）の通信のように、生産ラインの制御に直接関係し、リアルタイムで迅速に伝送する必要のある制御系データと、パソコン端末（ノード）の通信のように、生産ラインの制御に直接関係せず、各種の統計情報等のリアルタイムで伝送する必要の無い情報系データがある。つまり、ネットワーク上を伝送されるフレームは、上記のように、リアルタイムで送る必要のある制御系データを含む優先度の高いフレームと、リアルタイムで送る必要の無い情報系データからなる優先度の低いフレームがある。
【０００８】
しかし、従来のイーサネットでは、フレームに優先度情報が無く、すべてのフレームが同等に扱われていたため、リアルタイムで送らなければならない制御系データを含むフレームが、情報系データのフレームの通信によって待たされることがある。係る現象は、ＦＡ用のＬＡＮに限ることはなく、各種のＬＡＮにおいても同様のことが言える。
【０００９】
そこで、近年、フレームに優先度を示すフィールドを設け、高優先度のフレームを低優先度のフレームより優先して送信する方法がＩＥＥＥ等で検討されている。これにより、低優先度のフレームによって高優先度のフレームの通信が妨げられる可能性が減少するため、制御系データを含むフレームのように高優先度のフレームの伝送遅延時間を短くし、リアルタイムでの通信が可能となる。すなわち、ＦＡ用のＬＡＮを、イーサネットを用いたＣＳＭＡ/ＣＤ方式のネットワークを構築することができる。
【００１０】
【発明が解決しようとする課題】
しかしながら、上記した優先度情報を備えたフレームの伝送システムでは、以下に示す問題がある。すなわち、実施の形態でも説明するように、集線装置は、高優先度のフレームを記憶するバッファと低優先度のフレームを記憶するバッファを備え、高優先度バッファに記憶されたフレームを優先的に送信することにより対応するようにした装置が開発されてきている。
【００１１】
一方、優先度情報を備えたフレームの伝送システムを構築するためには、フレームの送受信の基となるノード側もそれに対応する必要がある。係る場合、送受信するフレームに優先度情報が付加されることから、ＢＳＤ版ＵＮＩＸにおけるネットワークＩ／ＯのＡＰＩであるＳＯＣＫＥＴ Ｉ／Ｆ（ソケットインターフェース）を使用することができず、新たな拡張Ｉ／Ｆ（優先度対応の新たなＡＰＩ）を策定する必要がある。そして、そのように新たな拡張Ｉ／Ｆを策定すると、既存のアプリケーションをその拡張Ｉ／Ｆに対応し、優先度情報付きのフレーム（パケット）を送受できるアプリケーションに作り替えなければならず、その作業が非常に煩雑となる。
【００１２】
従って、集線装置までは対応できるものの、既存の各ノードに対して拡張Ｉ／Ｆ並びにアプリケーションをすべて作り替えることはできず、ノードは従前のものを使用することになる。すると、係るノードから送信されるフレームには優先度情報が無いので、結局集線装置内での処理は、低優先度となり、上記した本来的に優先度の高いフレームを優先的に送信できないという従来の問題が解決されない。
【００１３】
本発明は、上記した背景に鑑みてなされたもので、その目的とするところは、上記した問題を解決し、新たな通信のＡＰＩを追加すること無く、しかも、アプリケーションの作り替えをすること無く、優先度なしフレームに対応したアプリケーションやＡＰＩを使用したノードであっても、優先度付きフレームの送信及びまたは受信（通信）をすることができるノード及びノード内のデータ処理方法を提供することにある。
【００１４】
【課題を解決するための手段】
上記した目的を達成するために、本発明に係るノードでは、優先度付きフレームが伝送されるネットワークに接続取り外し可能なノードであって、送信パケットが送信予定のフレームについての優先度情報を有するパケットであるかどうかを判定する送信パケット解析処理手段と、前記送信パケットが前記送信パケット解析処理手段により優先度情報を有するパケットであると判定されたことに基づいて、送信予定のフレームを特定する情報（実施の形態では、「ポート番号」に対応）とそのフレームの優先度とを関連付けた優先度テーブル（実施の形態では、「ポート別優先度テーブル」に対応）を作成する優先度テーブル設定処理手段と、前記送信パケットが前記送信パケット解析処理手段により優先度情報を有するパケットでないと判定されたことに基づいて、前記送信パケットの優先度なしフレームに対し、前記優先度テーブルを参照して優先度を付加して優先度付きフレームを生成する送信パケット変換処理手段と、前記送信パケット変換処理手段が生成した優先度付きフレームを送信する送信手段を備えて構成した（請求項１）。
【００１５】
また、本発明に係るノード内のデータ処理方法では、ネットワークの接続対象であるノードにおけるデータ処理方法であって、送信パケットが送信予定のフレームについての優先度情報を有するパケットかどうかを判定し、上位層は送信予定のフレームについての優先度情報（実施の形態では、「優先度通知パケット」に対応）を下位層（実施の形態では、「イーサネットドライバが設置される層」）に対して送る。前記下位層は、受け取った優先度情報にしたがい送信予定のフレームを特定する情報と、そのフレームの優先度とを関連付けた優先度テーブル（実施の形態では、「ポート別優先度テーブル」に対応）を作成する。次いで送信パケット変換処理手段が上位層から受け取った優先度なしフレームに対し、前記優先度テーブルを参照して優先度を付加し、前記送信パケット変換処理手段が作成した優先度付きフレームを送信するようにした（請求項２）。
【００１６】
上記したノード及びデータ処理方法の発明では、上位層（例えばアプリケーション層等）から受け取った優先度なしフレームに対し優先度情報付加手段により優先度付きフレームに変換することができるので、その優先度情報付加手段よりも上位層は、従来の優先度なしフレーム（パケット）の状態で送信できる。よって、従来のＡＰＩなどに替えて優先度付きフレームを処理可能な拡張Ｉ／Ｆやアプリケーションを作成することなく、優先度付きフレームを伝送するネットワークに接続するノードを構成することができる。
【００１７】
また、本発明に係るノードは、好ましくは上記のノードを前提とし、外部から受け取ったパケットが優先度付きフレームか優先度なしフレームであるかどうかを判定する受信パケット解析処理手段と、前記受信パケットが前記受信パケット解析処理手段により優先度付きフレームと判定されたことに基づいて、前記優先度付きフレームから優先度情報を除去した優先度なしフレームを生成する優先度情報除去手段と、その優先度情報除去手段により生成された優先度なしフレームを上位層に送る手段を備えて構成することである（請求項３） 。
【００１８】
また、本発明に係るノード内のデータ処理方法は、好ましくは上述した処理方法の発明を前提として、外部から受け取ったパケットが優先度付きフレームか優先度なしフレームであるかどうかを判定し、受信パケット解析処理手段が優先度付きフレームを受信した際に、その受信したフレームから優先度情報を除去して優先度なしフレームを生成し、ついで、その生成した優先度なしフレームを上位層に送る（実施の形態では、一度受信通知をし、上位層からの転送要求を受けて送る）ようにすることである（請求項４）。
【００１９】
上記したノード及びデータ処理方法の発明では、外部（接続したネットワーク）から受け取ったデータが優先度付きフレームであった場合、そのフレームの中から優先度に関する情報を除去して上位層に送るので、上位層に転送する際には少なくとも係る優先度情報がなくなる、つまり、上位層は従来と同様の優先度なしフレームの状態でフレーム（パケット）の送受を行うことができる。
【００２０】
よって、従来のＡＰＩなどに替えて優先度付きフレームを処理可能な拡張Ｉ／Ｆやアプリケーションを作成することなく、優先度付きフレームを伝送するネットワークに接続するノードを構成することができる。
【００２１】
【発明の実施の形態】
図１は、本発明が適用されるＬＡＮの全体の概略構成を示している。同図に示すように、集線装置１を中心に伝送路２を介して各ノード３が接続されることによりネットワークが構築されている。このネットワークは、例えばノード３がＰＬＣ，センサ，パソコン等からなるＦＡに配置されたＬＡＮであり、ネットワーク接続された各ノード（ＰＬＣ等）が、協調動作・同期動作等しながら各種の処理を行うものに適用できる。もちろん、これ以外の各種のネットワークに適用できるのは言うまでもない。
【００２２】
また、集線装置１の内部構造としては、図２に示すようになっている。すなわち、集線装置１内には、データの送受を行う物理層１ａ及び通信コントローラ１ｂがあり、各物理層１ａは、所定のノード３に接続されている。これにより、通信コントローラ１ｂは、物理層１ａを介して受信したフレームを解析し、宛先のノードが接続された物理層１ａにそのフレームを転送するようになっている。さらに本形態では、高優先度フレームを格納する高優先度バッファ１ｃと、低優先度フレームを格納する低優先度バッファ１ｄを備えている。そして、それら高優先度バッファ１ｃ，低優先度バッファ１ｄのバッファあふれを監視するフロー制御機能部１ｅをさらに備えている。
【００２３】
係る構成からなる集線装置１では、通信コントローラ１ｂが、ノード３から送られてきたフレームの優先度を検出し、対応するバッファ１ｃ，１ｄに登録する。そして、高優先度バッファ１ｃに格納されたフレームから優先してその内容を解析し、宛先のノード３が接続されている物理層１ａにフレームを転送する機能を持つ。また、フロー制御機能部１ｅは、例えばバッファあふれを生じた場合に各ノードに対して送信の一時停止命令を発する機能などを有している。
【００２４】
また、本形態に用いられる優先度付きのフレーム（パケット）のフォーマットは、図３（ａ）に示すようになっている。すなわち、フレームの先頭にイーサネットヘッダがあり、続いて実際に送るデータ部分であるイーサネットデータがある。そして、イーサネットヘッダは、ＤＡ（宛先アドレス），ＳＡ（送信元アドレス），ＴＨ（優先度情報），Ｌ／Ｔ（データ長）の順に格納するようになっている。さらに、優先度情報は、ＵＰが「７」のときには高優先度を意味し、ＵＰが「１」のときには低優先度を意味する。よって、ＵＰフィールドでそのフレームの優先度の種別を判別することができる。また、ＴＰＩＤ，ＣＦＩ，ＶＩＤはそれぞれ上位層のプロトコルタイプを特定するタイプＩＤ（８１００固定），ルーティング情報（０固定），バーチャルＬＡＮのＩＤ番号（０固定）を意味する。
【００２５】
なお、従来の優先度なしフレームのデータフォーマットは、同図（ｂ）に示すようになっており、優先度付きのフレーム（同図（ａ））と比較すると明らかなように、ＴＨ（優先度情報）が無い。つまり、この優先度なしのフレームのＳＡエリアとＬ／Ｔエリアの間にＴＨエリアを挿入したものが優先度付きフレームとなる。
【００２６】
そして、本形態のノード３は、ノード３の内部（各層間）では、図３（ｂ）に示す優先度なしのフレームでの送受を行い、ノード３間、つまり、ノード３と集線装置１間では、優先度ありのフレームを送信するようにしている。すなわち、ノード３の内部に、外部に送出する際に優先度情報の無いフレームに対して優先度情報を付加する機能と、受け取った優先度ありのフレームから優先度情報を除去し、優先度なしのフレームに変換する機能を持たせている。そして具体的には、図４に示すようになっている。
【００２７】
すなわち、よく知られているように、イーサネット（ＰＣＴ／ＩＰのプロトコル）の階層化構造は、図４に示すように、最上位層としてのアプリケーション層５の下位側に、層間のインターフェースであるソケットと呼ばれるＡＰＩ６を介して、トランスポート層（ＴＣＰ／ＩＰ，ＵＤＰ）７，インターネット層（イーサネットドライバ）８，ＯＳ９，物理層（ハードウェア）１０の順に配置された構成となっている。
【００２８】
そして、係る構成におけるデータの流れとしては、通常ソケットと呼ばれるＡＰＩ６を利用し通信のアプリケーションを作成する。このアプリケーションからＡＰＩ６を通じてＴＣＰ／ＩＰ７に渡されたデータは、さらにイーサネットドライバ８に渡され、ドライバ８がＯＳ９を通じてハードウェア（イーサネットコントローラ）１０をアクセスし伝送路にパケットが送受信される。そして、イーサネットドライバ８にて、上記した優先度情報の付加・除去を行うようにしている。
【００２９】
すなわち、図に示すようにイーサネットドライバ８内に、図５のフローチャートを実施する機能を持った優先度情報付加処理部１１及び優先度設定テーブル１２並びに図６のフローチャートを実施する機能を持った優先度情報除去処理部１３を設ける。そして、イーサネットドライバ８のより具体的な内部構造は、図７に示すようになっている。
【００３０】
図７に示すように、上位層から初期化要求を受けると、ドライバ初期化処理部８ａ，ボード初期化処理部８ｂにより、ドライバ及びＥｔｈｅｒｎｅｔボードの初期化を行う。送信要求では、上位層から渡されたパケットを、イーサネット用のパケットに構成し、優先度順に送信する機能を実行する。
【００３１】
また、送信処理部８ｃは、受信した送信要求（上位層から通常の送信パケット（優先度通知パケットでない））にしたがい、Ｅｔｈｅｒｎｅｔボードにパケット送信を実行する。そして、本発明の優先度情報付加処理部１１が、この送信処理部８ｃと連携して配置され、後述するように上位層から優先度通知パケットを受信した場合に、その優先度情報付加処理部１１が稼動し、優先度設定テーブル１２に所定のデータを記憶する。
【００３２】
この優先度情報付加処理部１１は、本形態では上位層から渡されたパケットが、制御パケットか送信パケットであるかを解析する送信パケット解析処理部１１ａと、優先度設定テーブルに、ポートごとに優先度を保存する優先度テーブル設定処理部１１ｂと、指定されたポートの優先度をサーチしたり、優先度テーブルを操作し、優先度なしパケットを優先度付きのパケットフォーマットに変換する送信パケット変換処理１１ｃを備えている。
【００３３】
また、割り込みハンドラでは、ハードウェアからの受信部側に優先度情報除去処理部１３たる受信パケット変換処理部１３ａを設け、そこにおいて受信したパケットを、優先度付きのパケットフォーマットから、通常のパケットフォーマットに変換するようになっている。さらに、受信パケット解析処理部１３ｂでは、受信パケットの種類（優先度ありか否か）を判断し、優先度ありの場合には上記の受信パケット変換処理部１３ａを稼動させるようになっている。さらに、この受信パケット解析処理部１３ｂでは、優先度なしのパケットの受信を上位層に通知する機能も持つ。この通知機能は、従来も有するものである。但し異なるのは従来のものは受信したパケットはすべて優先度なしであるので、受信したらそれを通知すればよかったが、本形態では優先度付きとなしの両方のパケットが受信される可能性があるので、優先度なしの場合にはそのまま通知し、優先度付きの場合には優先度なしに変換後通知することになる。
【００３４】
さらに、この通知にしたがい上位層が発する受信パケット転送要求を受信すると、それにしたがい、指示された受信パケットを上位層に転送する機能や、上位層から終了要求を受けると、Ｅｔｈｅｎｅｔボードを停止し、ドライバが保有するすべてのリソースを開放する終了処理する機能などを有する。なお、優先度情報の付加／除去する機能以外は、従来からのイーサネットドライバと同様であるのでその詳細な説明を省略する。
【００３５】
ここで本発明では、データ送信用の通常のＡＰＩ６を利用してアプリケーション５がイーサネットドライバ８に設けた優先度設定テーブル６に優先度を登録できる特殊なパケットフォーマット（図８参照）を定義し、イーサネットドライバ８（優先度情報処理部５）は、パケットごとに優先度設定テーブルを参照して優先度をつける処理を行うようにしている。
【００３６】
ここでまずアプリケーションからイーサネットドライバに渡される優先度設定用のパケットフォーマットを説明すると、優先度設定用のパケットの場合には、図８に示すようにＵＤＰヘッダの中の先頭のＳｒｃ Ｐｏｒｔが９になっている。従って、９以外の場合は通常のデータパケットと判断できる。また、データ中の先頭のＲｅｑｕｅｓｔ Ｎｏは、設定を示す「１」となり、Ｐｏｒｔ Ｎｏは、アプリケーションが優先度付き通信を行おうとするポート番号を示し（ソケットＡＰＩにおいては、ポート番号を指定して通信を行っているため、そのポート番号が書き込まれている）、Ｐｒｉｏｒｉｔｙエリアには、その通信を行うデータが高優先度（７）か低優先度（１）かの情報がセットされている。
【００３７】
イーサネットドライバ８の優先度情報付加処理部１１は、上記した優先度通知パケットの受信にともない、優先度テーブル１２（図９参照）を作成し、また、通常のパケット（送信パケット）を受信したならば、優先度テーブル１２を参照して優先度情報を付加したパケットを作成し、データ送信をするようになっている。
【００３８】
そして、具体的には図５に示すように、まず、上位層から渡された送信要求を待ち（ＳＴ１）、受け付けたならばその送信要求のパケット種別を判断する（ＳＴ２）。つまり、９番ポートから送られてきたパケットか否かを判断し、９番ポートであれば優先度設定用のパケットであり、それ以外であればデータ送信用のパケットと判断できる。
【００３９】
そして、優先度設定用のパケットなら、ステップ９に飛び、優先度テーブルに優先度と対応ポートをセットする。具体的には、図８に示す優先度通知パケットのデータ部分を解析し、Ｐｏｒｔ Ｎｏエリアから優先度設定するポート番号（アプリケーションが、その設定しようとする優先度のフレームを送信する際に使用するポート番号）を取得し、Ｐｒｉｏｒｔｙエリアに格納された数値を取得する。そして、取得した２つの値（ポート番号と優先度）を関連付けて図９（ａ）に示すポート別優先度テーブルに格納する。すなわち、例えば図１０に示すような優先度通知パケットを受け付けた場合、データ部分から、ポート番号１０４８を使って送信するパケットの優先度が７（高優先度）となっているので、図５（ａ）に示すように該当するポート番号の優先度を７にセットする。係る処理をして優先度設定のための前処理（テーブル作成）を終了する。
【００４０】
一方、ステップ２の分岐判断で上位層から渡された送信要求がデータ送信用のパケットと判断された場合にはステップ３に飛びさらに、上位層で分割されたパケットなのか判定する。なお、分割されたパケットか否かは、ＩＰヘッダのフラグ（図示省略）から判断できる。
【００４１】
そして、分割されてなければ、ステップ６に飛び、優先度設定テーブル（ポート別優先度テーブル）１２をアクセスして対応するポートに関連付けられた優先度を読み出す（ＳＴ６）。つまり、例えばポート番号が先ほど登録した「１０４８」とすると、優先度は「７」という情報を読み出す。
【００４２】
次いで、受け付けたパケットのイーサネットヘッダ（図３（ｂ）に示すように優先度情報なし）のＳＡエリア（送信元アドレス）の後に、ＴＨエリア（優先度情報）を挿入したフレームを作成（優先度付きパケットフォーマットに変換）する。つまり、図３（ａ）に示したように、ＴＨエリアのうちＵＰエリアのみが可変（１／７）でそれ以外の固定であるので、テーブルから読み出した優先度（１／７）と固定の各値を適宜の順で挿入することになる。その後、そのように変換して生成した優先度付きフォーマットのデータを送信し、処理を終了する（ＳＴ８）。
【００４３】
また、受け付けたパケットが分割されたパケットの場合には、ステップ３からステップ４に飛び、さらに最初の分割パケットであるか否かを判断する。この判断も、ＩＰヘッダのフラグ（図示省略）から判断できる。つまり、実際の処理としては、ステップ３，４の判断はいっしょに行うことができる。
【００４４】
そして、最初の分割パケットの場合には、パケットの中のＩＤを読み出し、ＩＤと優先度を関連付けたテーブル：ＩＤフィールド別優先度テーブル（図９（ｂ）参照）を作成する。なお、優先度は、ポート番号よりポート別優先度テーブルを参照することにより認識できる。つまり、１度に送れる最大データ長が決まっているので、それ以上のデータを送る場合には、複数のパケットに分割して送ることになる。このとき、２つ目以降のパケットには、ＴＣＰ或いはＵＤＰの送信元ポートを特定する情報が含まれていないので、その２つ目以降の途中パケットの情報のみでは優先度を特定できない。
【００４５】
そこで、分割されたパケットのＩＤフィールド（ＩＤ番号）が同じ値になることを利用し、最初のパケットのＩＤ番号と優先度を関連付けたＩＤフィールド別優先度テーブル（図９（ｂ））を作成することにより、２番目以降のパケットは、ＩＤ番号からそのＩＤフィールド別優先度テーブルを参照することにより、そのＩＤ番号に対応する優先度（１／７）を知ることができるので、その取得した対応する優先度を、そのパケットを送信する際の優先度とすることができる。
【００４６】
そして、ステップ５を実行してテーブルを作成したならば、ステップ６に戻り上記した各処理を順に実行し、優先度付きのパケットに変換後データを送信するようになる。つまりテーブル（ポート別優先度データテーブル）を参照してそのポート番号に対応した優先度（１／７）を取得し、それに基づいて優先度付きパケットに変換する。なお、ステップ５を実行する際に優先度情報はすでにわかっているので、ステップ５をステップ７に飛び、そのわかっている優先度情報を用いて優先度付きパケットを組み立てるようにしてもよい。
【００４７】
さらに、分割された２つ目以降のパケットの場合には、ステップ４でＮｏとなるので、そのままステップ６に飛び、ＩＤフィールド別優先度テーブルより、対応するＩＤの優先度を読み出し、優先度付きパケットフォーマットに変換し（ＳＴ７）、ネットワークに送信する（ＳＴ８）。
【００４８】
そして、上記した各ステップと、図７に示す各処理部１１ａ〜１１ｃの関係は、送信パケット解析処理部１１ａはステップ１〜４の処理を行い、優先度テーブル設定処理部１１ｂがステップ５，９の処理を行い、送信パケット変換処理部１１ｃが、ステップ６，７の処理を行う。なお、ステップ８のデータ送信は、送信処理部８ｃが実行することになる。
【００４９】
上記したように、本形態では優先度テーブル１２として、「ポート別優先度テーブル」と「ＩＤフィールド別優先度テーブル」の２種類のテーブルを用意し、それらを使用することによりデータ長の長い複数のパケットに分割して送信するデータにも対応できるようにしている。但し、例えはＦＡ用のＰＬＣを制御するネットワークに適用した場合、分割しなければならないほどデータ長の長いデータを送ることはほとんどないので、ＩＤフィールド別優先度テーブル（図９（ｂ））はなくてもよい。その場合には、図５に示すステップ３から５の処理がなくなる。
【００５０】
そして、仮にＩＤフィールド別優先度テーブルを設けないイーサネットドライバを用いたノードにおいて複数に分割されたパケットを送信する場合には、２番目以降のパケットは優先度情報がないので、例えばオフセットとして設定される低優先度とすることにより対応できる。特に、ＰＬＣのＬＡＮの場合にデータ長が長いというのは、多くの場合情報系であると予測できるので、そのように低優先度に設定しても問題はない。なお、逆にデータ長が長く複数のパケットに分割して送信するものが、優先度の高いものが多い場合には、分割パケットの２つ目以後はすべて高優先度に設定するようにしてもよい。
【００５１】
一方、本形態のノード３のＡＰＩ６は、優先度付きのパケットを送受信できないため、ネットワークを介して受信した優先度付きのパケットを、イーサネットドライバ８で優先度なしのパケットに変換するようになっている。さらに、本形態では、優先度なしのパケットを送受信するネットワークにも対応できるように、優先度なしのパケットを受信した場合には、上記のような変換をすることなく上位層に送る（通常のデータ処理はもちろんする）ようになっている。そして、具体的には、図６に示すようなフローチャートを実行する機能を有している。
【００５２】
すなわち、まず、ハードウェア１０からの割り込み要求（伝送路２を介してネットワークから送られてきたパケット受信による割り込み）があったならば、その受信パケットが、優先度付きのものか優先度なしのものかを判断する（ＳＴ１１，ＳＴ１２）。この判断は、受信パケット解析処理部１３ｂが行う。
【００５３】
そして、優先度付きパケットと判断した場合には、ステップ１３に進み、優先度付きのパケットフォーマットから、通常のパケットフォーマットに変換する。すなわち、優先度付きフォーマット（図３（ａ）参照）のイーサネットヘッダのＴＨエリアを除去し、ＳＡエリアに続いてＬ／Ｔエリアを続けた１４バイトからなる優先度なしフォーマット（図３（ｂ）参照）のフレームに再構築する。そして、この処理は受信パケット変換処理部１３ａが実行する。その後、受信があったことを上位層に通知し、処理を終了する（ＳＴ１４）。この処理は、受信パケット解析処理部１３ｂが行う。
【００５４】
一方、優先度なしパケットを受信した場合、ステップ１２からステップ１４に飛び、上位層に対してパケット受信を通知し、処理を終了する。つまり、従来から行われている通常の受信処理を実行することになる。この一連の処理は、受信パケット解析処理部１３ｂが行う。
【００５５】
そして、通常であれば、この通知にしたがい上位層から受信パケット転送要求があるので、それを受けて受信パケットを上位層に転送する。また、上位層から終了要求を受けると、終了処理、つまり Ｅｔｈｅｎｅｔボードを停止し、ドライバが保有するすべてのリソースを開放する。
【００５６】
【発明の効果】
以上のように、本発明に係るノード及びノード内のデータ処理方法の第１の発明（請求項１，２）では、優先度情報付加手段により上位層から送られてきた優先度なしフレームが優先度付きフレームに変換（生成）されるので、その優先度情報付加手段よりも上位層は、優先度なしフレーム（パケット）の状態で送受信ができる。よって、新たなＡＰＩ（拡張Ｉ／Ｆ）を追加すること無く、アプリケーションを大幅に作り替えをすること無く、従来からあるアプリケーションや通常のＡＰＩや、ＵＤＰを使用して通信するノードであっても、接続したネットワークに対して優先度付きフレームを送信することができる。
【００５７】
また、第２の発明（請求項３，４）では、優先度情報除去手段により外部から受け取った優先度付きフレームを優先度なしフレームに作り変えるので、その優先度情報除去手段の設置層よりも上位層は、優先度なしフレームを受けることができる。よって、上記第１の発明と同様に、優先度付きフレームの通信を可能とする拡張Ｉ／Ｆやアプリケーションなどを製造する必要がなく、従来の優先度なしフレームを取り扱うＡＰＩやアプリケーションを備えたノードであっても、優先度付きフレームを受信し、所望の処理をすることができる。
【図面の簡単な説明】
【図１】 本発明が適用されるネットワークシステムの一例を示す図である。
【図２】 集線装置の内部構造を示す図である。
【図３】 （ａ）は、優先度付きフレームフォーマットを示す図である。
（ｂ）は、優先度なしフレームフォーマットを示す図である。
【図４】 本発明に係るノードの好適な一実施の形態を示す図である。
【図５】 主として優先度情報付加処理部の機能を示すフローチャートである。
【図６】 主として優先度情報除去処理部の機能を示すフローチャートである。
【図７】 イーサネットドライバの内部構造を示す図である。
【図８】 アプリケーションから送られる優先度設定通知パケットのフォーマットを示す図である。
【図９】 （ａ）は、ポート別優先度テーブルを示すデータ構造図である。
（ｂ）は、ＩＤフィールド別優先度テーブルを示すデータ構造図である。
【図１０】 優先度設定通知パケットの一例を示す図である。
【符号の説明】
３ ノード
８ イ−サネットドライバ（下位層）
１１ 優先度情報付加処理部
１２ 優先度テーブル
１３ 優先度情報除去処理部
Claims (4)
- 優先度付きフレームが伝送されるネットワークに接続取り外し可能なノードであって、
送信パケットが送信予定のフレームについての優先度情報を有するパケットであるかどうかを判定する送信パケット解析処理手段と、
前記送信パケットが前記送信パケット解析処理手段により優先度情報を有するパケットであると判定されたことに基づいて、送信予定のフレームを特定する情報とそのフレームの優先度とを関連付けた優先度テーブルを作成する優先度テーブル設定処理手段と、
前記送信パケットが前記送信パケット解析処理手段により優先度情報を有するパケットでないと判定されたことに基づいて、前記送信パケットの優先度なしフレームに対し、前記優先度テーブルを参照して優先度を付加して優先度付きフレームを生成する送信パケット変換処理手段と、
前記送信パケット変換処理手段が生成した優先度付きフレームを送信する送信手段を備えたノード。 - ネットワークの接続対象であるノードにおけるデータ処理方法であって、
送信パケットが送信予定のフレームについての優先度情報を有するパケットかどうかを判定し、
上位層は前記送信予定のフレームについての優先度情報を下位層に対して送り、
前記下位層は、受け取った優先度情報にしたがい送信予定のフレームを特定する情報とそのフレームの優先度とを関連付けた優先度テーブルを作成し、
ついで、送信パケット変換処理手段が上位層から受け取った優先度なしフレームに対し、前記優先度テーブルを参照して優先度を付加して優先度付きフレームを生成し、前記送信パケット変換処理手段が作成した優先度付きフレームを送信するようにしたことを特徴とするノード内のデータ処理方法。 - 外部から受け取ったパケットが優先度付きフレームか優先度なしフレームであるかどうかを判定する受信パケット解析処理手段と、
前記受信パケットが前記受信パケット解析処理手段により優先度付きフレームと判定されたことに基づいて、前記優先度付きフレームから優先度情報を除去した優先度なしフレームを生成する優先度情報除去手段と、
その優先度情報除去手段により生成された優先度なしフレームを上位層に送る手段を備えた請求項１に記載のノード。 - 外部から受け取ったパケットが優先度付きフレームか優先度なしフレームであるかどうかを判定し、
受信パケット解析処理手段が優先度付きフレームを受信した際に、その受信したフレームから優先度情報を除去して優先度なしフレームを生成し、
ついで、その生成した優先度なしフレームを上位層に送るようにしたことを特徴とする請求項２に記載のノード内のデータ処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP35170598A JP3729237B2 (ja) | 1998-12-10 | 1998-12-10 | ノード及びノード内のデータ処理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP35170598A JP3729237B2 (ja) | 1998-12-10 | 1998-12-10 | ノード及びノード内のデータ処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000183935A JP2000183935A (ja) | 2000-06-30 |
| JP3729237B2 true JP3729237B2 (ja) | 2005-12-21 |
Family
ID=18419069
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP35170598A Expired - Fee Related JP3729237B2 (ja) | 1998-12-10 | 1998-12-10 | ノード及びノード内のデータ処理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3729237B2 (ja) |
Families Citing this family (51)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7509322B2 (en) | 2001-01-11 | 2009-03-24 | F5 Networks, Inc. | Aggregated lock management for locking aggregated files in a switched file system |
| JP4029804B2 (ja) | 2003-09-02 | 2008-01-09 | ブラザー工業株式会社 | ネットワーク装置、および送信出力レベル変更方法 |
| US7885970B2 (en) | 2005-01-20 | 2011-02-08 | F5 Networks, Inc. | Scalable system for partitioning and accessing metadata over multiple servers |
| US8417746B1 (en) | 2006-04-03 | 2013-04-09 | F5 Networks, Inc. | File system management with enhanced searchability |
| US20070258445A1 (en) * | 2006-05-02 | 2007-11-08 | Harris Corporation | Systems and methods for protocol filtering for quality of service |
| JP4535075B2 (ja) * | 2007-03-12 | 2010-09-01 | ブラザー工業株式会社 | ネットワーク装置、およびネットワーク装置用のプログラム |
| WO2008147973A2 (en) | 2007-05-25 | 2008-12-04 | Attune Systems, Inc. | Remote file virtualization in a switched file system |
| US8121117B1 (en) | 2007-10-01 | 2012-02-21 | F5 Networks, Inc. | Application layer network traffic prioritization |
| US8548953B2 (en) | 2007-11-12 | 2013-10-01 | F5 Networks, Inc. | File deduplication using storage tiers |
| US8549582B1 (en) | 2008-07-11 | 2013-10-01 | F5 Networks, Inc. | Methods for handling a multi-protocol content name and systems thereof |
| US10721269B1 (en) | 2009-11-06 | 2020-07-21 | F5 Networks, Inc. | Methods and system for returning requests with javascript for clients before passing a request to a server |
| US8806056B1 (en) | 2009-11-20 | 2014-08-12 | F5 Networks, Inc. | Method for optimizing remote file saves in a failsafe way |
| US9195500B1 (en) | 2010-02-09 | 2015-11-24 | F5 Networks, Inc. | Methods for seamless storage importing and devices thereof |
| US9503375B1 (en) | 2010-06-30 | 2016-11-22 | F5 Networks, Inc. | Methods for managing traffic in a multi-service environment and devices thereof |
| US9420049B1 (en) | 2010-06-30 | 2016-08-16 | F5 Networks, Inc. | Client side human user indicator |
| US8347100B1 (en) | 2010-07-14 | 2013-01-01 | F5 Networks, Inc. | Methods for DNSSEC proxying and deployment amelioration and systems thereof |
| US9286298B1 (en) | 2010-10-14 | 2016-03-15 | F5 Networks, Inc. | Methods for enhancing management of backup data sets and devices thereof |
| EP2710784B1 (en) | 2011-05-16 | 2017-12-06 | F5 Networks, Inc | A method for load balancing of requests' processing of diameter servers |
| US8396836B1 (en) | 2011-06-30 | 2013-03-12 | F5 Networks, Inc. | System for mitigating file virtualization storage import latency |
| US8463850B1 (en) | 2011-10-26 | 2013-06-11 | F5 Networks, Inc. | System and method of algorithmically generating a server side transaction identifier |
| US10230566B1 (en) | 2012-02-17 | 2019-03-12 | F5 Networks, Inc. | Methods for dynamically constructing a service principal name and devices thereof |
| US9020912B1 (en) | 2012-02-20 | 2015-04-28 | F5 Networks, Inc. | Methods for accessing data in a compressed file system and devices thereof |
| US9244843B1 (en) | 2012-02-20 | 2016-01-26 | F5 Networks, Inc. | Methods for improving flow cache bandwidth utilization and devices thereof |
| US10097616B2 (en) | 2012-04-27 | 2018-10-09 | F5 Networks, Inc. | Methods for optimizing service of content requests and devices thereof |
| US10033837B1 (en) | 2012-09-29 | 2018-07-24 | F5 Networks, Inc. | System and method for utilizing a data reducing module for dictionary compression of encoded data |
| US9519501B1 (en) | 2012-09-30 | 2016-12-13 | F5 Networks, Inc. | Hardware assisted flow acceleration and L2 SMAC management in a heterogeneous distributed multi-tenant virtualized clustered system |
| JP2014085803A (ja) * | 2012-10-23 | 2014-05-12 | Omron Corp | 通信装置 |
| US9578090B1 (en) | 2012-11-07 | 2017-02-21 | F5 Networks, Inc. | Methods for provisioning application delivery service and devices thereof |
| US9497614B1 (en) | 2013-02-28 | 2016-11-15 | F5 Networks, Inc. | National traffic steering device for a better control of a specific wireless/LTE network |
| US9554418B1 (en) | 2013-02-28 | 2017-01-24 | F5 Networks, Inc. | Device for topology hiding of a visited network |
| US10187317B1 (en) | 2013-11-15 | 2019-01-22 | F5 Networks, Inc. | Methods for traffic rate control and devices thereof |
| US11838851B1 (en) | 2014-07-15 | 2023-12-05 | F5, Inc. | Methods for managing L7 traffic classification and devices thereof |
| US10182013B1 (en) | 2014-12-01 | 2019-01-15 | F5 Networks, Inc. | Methods for managing progressive image delivery and devices thereof |
| US11895138B1 (en) | 2015-02-02 | 2024-02-06 | F5, Inc. | Methods for improving web scanner accuracy and devices thereof |
| US10834065B1 (en) | 2015-03-31 | 2020-11-10 | F5 Networks, Inc. | Methods for SSL protected NTLM re-authentication and devices thereof |
| US10505818B1 (en) | 2015-05-05 | 2019-12-10 | F5 Networks. Inc. | Methods for analyzing and load balancing based on server health and devices thereof |
| US11350254B1 (en) | 2015-05-05 | 2022-05-31 | F5, Inc. | Methods for enforcing compliance policies and devices thereof |
| US11757946B1 (en) | 2015-12-22 | 2023-09-12 | F5, Inc. | Methods for analyzing network traffic and enforcing network policies and devices thereof |
| US10404698B1 (en) | 2016-01-15 | 2019-09-03 | F5 Networks, Inc. | Methods for adaptive organization of web application access points in webtops and devices thereof |
| US10797888B1 (en) | 2016-01-20 | 2020-10-06 | F5 Networks, Inc. | Methods for secured SCEP enrollment for client devices and devices thereof |
| US11178150B1 (en) | 2016-01-20 | 2021-11-16 | F5 Networks, Inc. | Methods for enforcing access control list based on managed application and devices thereof |
| US10412198B1 (en) | 2016-10-27 | 2019-09-10 | F5 Networks, Inc. | Methods for improved transmission control protocol (TCP) performance visibility and devices thereof |
| US11063758B1 (en) | 2016-11-01 | 2021-07-13 | F5 Networks, Inc. | Methods for facilitating cipher selection and devices thereof |
| US10505792B1 (en) | 2016-11-02 | 2019-12-10 | F5 Networks, Inc. | Methods for facilitating network traffic analytics and devices thereof |
| US10812266B1 (en) | 2017-03-17 | 2020-10-20 | F5 Networks, Inc. | Methods for managing security tokens based on security violations and devices thereof |
| US10567492B1 (en) | 2017-05-11 | 2020-02-18 | F5 Networks, Inc. | Methods for load balancing in a federated identity environment and devices thereof |
| US11343237B1 (en) | 2017-05-12 | 2022-05-24 | F5, Inc. | Methods for managing a federated identity environment using security and access control data and devices thereof |
| US11122042B1 (en) | 2017-05-12 | 2021-09-14 | F5 Networks, Inc. | Methods for dynamically managing user access control and devices thereof |
| US11223689B1 (en) | 2018-01-05 | 2022-01-11 | F5 Networks, Inc. | Methods for multipath transmission control protocol (MPTCP) based session migration and devices thereof |
| US10833943B1 (en) | 2018-03-01 | 2020-11-10 | F5 Networks, Inc. | Methods for service chaining and devices thereof |
| US12003422B1 (en) | 2018-09-28 | 2024-06-04 | F5, Inc. | Methods for switching network packets based on packet data and devices |
-
1998
- 1998-12-10 JP JP35170598A patent/JP3729237B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000183935A (ja) | 2000-06-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3729237B2 (ja) | ノード及びノード内のデータ処理方法 | |
| US7519076B2 (en) | Method and node for using a communication network in parallel for real-time applications and non-real-time applications | |
| JP3746785B2 (ja) | 多重ネットワーク・アドレスを備えたネットワーク・ステーション | |
| US5247626A (en) | Fddi controller having flexible buffer management | |
| US6445711B1 (en) | Method of and apparatus for implementing and sending an asynchronous control mechanism packet used to control bridge devices within a network of IEEE STD 1394 serial buses | |
| JP3184817B2 (ja) | フロー制御方法、一時停止制御システムおよびノード | |
| US6266334B1 (en) | Method for optimizing acknowledge packet rate | |
| EP2003823B1 (en) | Autonegotiation over an interface for which no autonegotiation standard exists | |
| KR101401874B1 (ko) | 통신제어 시스템, 스위칭 노드, 통신제어 방법, 및 통신제어용 프로그램 | |
| US8660117B2 (en) | Packet switching device and local communication network with such a packet switching device | |
| JP2005522913A (ja) | マルチクラスタ・ネットワークにおける通信のための方法、クラスタのネットワークに接続するための装置、及びクラスタを接続するためのブリッジ | |
| US7328270B1 (en) | Communication protocol processor having multiple microprocessor cores connected in series and dynamically reprogrammed during operation via instructions transmitted along the same data paths used to convey communication data | |
| JPH08307442A (ja) | データ伝送方式 | |
| CN114301995B (zh) | 实时工业以太网协议的转换切换与互通融合系统及其方法 | |
| US7342883B2 (en) | Method and apparatus for managing network traffic | |
| JP3214454B2 (ja) | プログラム内蔵方式パケット処理装置 | |
| WO1998025381A1 (en) | Network adaptor driver with destination based ordering | |
| JPH0345042A (ja) | データ伝送装置 | |
| JP2000035930A (ja) | ネットワークシステム | |
| US11522762B2 (en) | Coordination device and method for providing control applications via a communication network for transmitting time-critical data | |
| JP3387464B2 (ja) | 通信制御システムとその制御方法 | |
| JP2007306221A (ja) | ネットワークスイッチ及び通信ネットワーク | |
| JP2003078536A (ja) | シリアル通信システム | |
| JPH1155297A (ja) | 伝送媒体接続装置および記憶媒体 | |
| JPH0720109B2 (ja) | トークンパッシングバス方式を用いたネットワークシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050224 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050308 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050509 |
|
| 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: 20050914 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050927 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091014 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |