JP2008236625A - パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法 - Google Patents
パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法 Download PDFInfo
- Publication number
- JP2008236625A JP2008236625A JP2007076602A JP2007076602A JP2008236625A JP 2008236625 A JP2008236625 A JP 2008236625A JP 2007076602 A JP2007076602 A JP 2007076602A JP 2007076602 A JP2007076602 A JP 2007076602A JP 2008236625 A JP2008236625 A JP 2008236625A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- packet transmission
- transmission
- deadline
- communication
- 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.)
- Withdrawn
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】ネットワーク全体で、パケットのデッドラインを保証した通信を行うことができる技術を提供する。
【解決手段】情報処理装置には周期的な通信タスクの送信順序を制御するパケットスケジューラが設けられる。また情報処理装置には利用可能通信帯域が与えられている。パケットスケジューラは、利用帯域が利用可能通信帯域を超えず、かつ、デッドラインモノトニック法によってデッドラインが保証できると判定された場合に、要求された通信タスクを実行する通信タスクとして登録する。この際、複数の通信タスクに係るパケットをMTUの範囲内で連結して送信する。
【選択図】図5
【解決手段】情報処理装置には周期的な通信タスクの送信順序を制御するパケットスケジューラが設けられる。また情報処理装置には利用可能通信帯域が与えられている。パケットスケジューラは、利用帯域が利用可能通信帯域を超えず、かつ、デッドラインモノトニック法によってデッドラインが保証できると判定された場合に、要求された通信タスクを実行する通信タスクとして登録する。この際、複数の通信タスクに係るパケットをMTUの範囲内で連結して送信する。
【選択図】図5
Description
本発明は、パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法に関する。
従来、リアルタイムパケット通信においてデッドラインを考慮して、EDF(Earliest
Deadline First)アルゴリズムに基づいてパケット通信を行う技術が知られている(特
許文献1,2)。EDFアルゴリズムとは、デッドラインが最も近い処理を優先して実行するアルゴリズムである。
Deadline First)アルゴリズムに基づいてパケット通信を行う技術が知られている(特
許文献1,2)。EDFアルゴリズムとは、デッドラインが最も近い処理を優先して実行するアルゴリズムである。
また、ギガビットイーサのような高速LANでは、パケット数が増大すると端末でのパケット処理能力不足により高速通信の利点を享受できない。そこで、より大きいサイズのパケット、いわゆるジャンボフレームが導入されている(特許文献3,4)。
特表2002−543520号公報
特表2003−505931号公報
特開2003−229905号公報
特開2005−57373号公報
しかしながら、デッドラインが最も近い処理を優先的に実行するEDF法では、パケットの送信要求の発生タイミングによっては、デッドラインが短く設定されたパケットが頻繁に送信されてしまい、他のパケット送信のデッドラインが保証できなくなるおそれがある。
また、ジャンボフレームを導入した場合であっても、送信する個々のデータサイズが小さい場合には、パケット数が増大してしまい効率的な通信が実現できない。
本発明は上記実情に鑑みてなされたものであって、その目的とするところは、効率的なパケット通信を実現し、かつ、ネットワークに接続されている情報処理装置におけるパケット送信のデッドラインを保証する技術を提供することにある。
上記目的を達成するために本発明では、以下の手段または処理によってデッドラインを保証した効率的なパケット通信を行う。
本発明に係るパケット送信制御プログラムは、ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御プログラムである。本発明に係るパケット送信制御プログラムは、情報処理装置を、送信要求受付手段と、スケジュール可能性判定手段と、パケット制御手段として機能させる。
送信要求受付手段は、各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける。
スケジュール可能性判定手段は、要求されたパケット送信のデッドラインを保証が可能か否か判定し、デッドライン保証可能であれば、要求されたパケット送信を、実行する通
信タスクとして登録する。
信タスクとして登録する。
パケット制御手段は、登録された通信タスクのパケットを、通信タスクのデッドラインに応じた優先度で送信する。
スケジュール可能性判定手段は、すでに登録されている通信タスク及び要求されたパケット通信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりのパケットの転送量(データ転送量)が情報処理装置に与えられた所定の最大転送量以内となる場合に、要求されたパケット送信を、実行する通信タスクとして登録する。
このように、本発明に係るパケット送信制御プログラムは、各情報処理装置内でパケット送信のデッドラインを保証できるか否か判定し、さらに、各情報処理装置のパケット転送量が割り当てられた最大転送量以内であるか判定した上で、パケット送信要求を登録するか否か決定するので、ネットワーク内の全ての情報処理装置についてパケット送信のデッドラインを保証することが可能となる。
本発明におけるパケット制御手段は、さらに、パケット送信の際に複数の通信タスクに係るパケットを連結して送信する。すなわち、1つの通信タスクに係るパケットのみでは、1回に送信できるデータの最大値に満たない場合には、他の通信タスクに係るパケットを連結して送信する。
このように、複数の通信タスクに係るパケットを連結して送信することにより、パケットヘッダの処理に係るオーバヘッドの割合を少なくでき、したがって、効率的な通信を実現することが可能となる。
本発明におけるパケット制御手段は、さらに、複数の通信タスクに係るパケットを固定長に分割して、各通信タスクのデッドラインに応じた優先度に応じて連結して送信することが好適である。
このように、固定長に分割することで、1回に送信できるデータの最大値いっぱいまで、パケットを連結して送信することが可能となる。また、優先度の高い通信タスクが後から登録された場合に、この通信タスクに係るパケットを優先的に送信することもできる。
本発明におけるスケジュール可能性判定手段は、デッドラインモノトニック(Deadline
Monotonic)法によって、すでに登録された通信タスク及び要求されたパケット送信の全てについてデッドライン保証が可能であるか判定することが好適である。
Monotonic)法によって、すでに登録された通信タスク及び要求されたパケット送信の全てについてデッドライン保証が可能であるか判定することが好適である。
より具体的には、送信要求受付手段が受け付けるパケット送信要求には、情報として、パケット送信の送信周期、1周期あたりの送信データ量及び各周期におけるデッドラインが含まれることが好ましい。ここで、各周期におけるデッドラインは送信周期と同じか送信周期よりも短い時間である。
まず、スケジュール可能性判定手段は、1周期あたりの送信データ量及びネットワークの実効通信速度から、要求されたパケット送信に要する送信所要時間を算出する。次に、スケジュール可能性判定手段は、送信周期、算出した送信所要時間、及びデッドラインを用いてデッドラインモノトニック法によって、スケジュール可能性を判定する。
なお、スケジュール可能性判定手段は、送信周期、送信所要時間、及びデッドラインが、デッドライン保証可能な必要十分条件を満たすか否かを判定する必要はなく、デッドラ
イン保証可能なための十分条件を満たすか否かのみを判定するようにしても良い。デッドラインモノトニック法では、必要十分条件の判定は複雑であり処理に時間を要するため、処理の軽い十分条件での判定を用いることも好ましい。
イン保証可能なための十分条件を満たすか否かのみを判定するようにしても良い。デッドラインモノトニック法では、必要十分条件の判定は複雑であり処理に時間を要するため、処理の軽い十分条件での判定を用いることも好ましい。
本発明に係るパケット送信制御プログラムが設けられている情報処理装置に割り当てられる所定の最大転送量は、設定情報として情報処理装置にあらかじめ与えられたり、各情報処理装置の全体送信量管理サーバから与えられたりすることが好ましい。
また、最大転送量は常に同じ値である必要はなく、パケット送信制御プログラムは、すでに登録された通信タスク及び要求されたパケット送信の全てについてデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が最大転送量を超える場合には、全体送信量管理サーバに対して最大転送量の増加を求めることが好ましい。
なお、本発明は、上記処理の少なくとも一部を有するパケット送信制御プログラムとして捉えることができる。また、本発明は、上記手段の少なくとも一部を含むパケット送信制御装置、または、上記処理の少なくとも一部を含むパケット送信制御方法として捉えることができる。上記手段及び処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
たとえば、本発明の一態様としてのパケット送信制御装置は、ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御装置であって、各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける送信要求受付手段と、前記要求されたパケット送信のデッドライン保証が可能か否か判定し、デッドライン保証可能であれば、該要求されたパケット送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、前記登録された通信タスクのパケットを、該通信タスクのデッドラインに応じた優先度で送信するパケット制御手段と、を有し、前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、前記パケット制御手段は、複数の通信タスクに係るパケットを連結して送信することを特徴とする。
また、本発明の一態様としてのパケット送信制御方法は、ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御方法であって、前記情報処理装置が、各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付け、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、前記登録された複数の通信タスクに係るパケットを、該通信タスクのデッドラインに応じた優先度で連結して送信することを特徴とする。
本発明によれば、効率的な通信が可能になるとともに、ネットワークに接続されている情報処理装置におけるパケット送信のデッドラインを保証することが可能となる。
以下に図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。
[第1の実施形態]
<システム概要>
図1は、本実施形態に係るパケットスケジューラ(パケット送信制御プログラム)を実行する情報処理装置のネットワークシステムを示す図である。複数の情報処理装置1a、1b、1cがネットワーク3を介して接続されており、各情報処理装置は互いにパケット通信を行う。ここで、情報処理装置1cは、各情報処理装置1a,1b,1cのそれぞれが単位時間あたりに送信できるパケットの最大転送量を管理する全体送信量管理サーバとしての機能も兼ねる。
<システム概要>
図1は、本実施形態に係るパケットスケジューラ(パケット送信制御プログラム)を実行する情報処理装置のネットワークシステムを示す図である。複数の情報処理装置1a、1b、1cがネットワーク3を介して接続されており、各情報処理装置は互いにパケット通信を行う。ここで、情報処理装置1cは、各情報処理装置1a,1b,1cのそれぞれが単位時間あたりに送信できるパケットの最大転送量を管理する全体送信量管理サーバとしての機能も兼ねる。
図2は、パケットスケジューラを実行する情報処理装置1の構成を示す図である。情報処理装置1は、CPU11,タイマ12,ハードディスク装置などの補助記憶装置13、読み書き可能メモリ(RAM)などのメモリ14、及びネットワーク制御部15を有する。これらの各要素は、バスを介して互いに接続されている。
タイマ12は、情報処理装置1における現在時刻(システム時刻)を刻むものである。パケットスケジューラは、このタイマ12のシステム時刻に基づいてパケット送信の制御を行う。
補助記憶装置13には、パケットスケジューラやその他アプリケーションのプログラムが格納されている。これらのソフトウェアは、補助記憶装置13からメモリ14に、必要に応じて適宜読み出され、CPU11によって実行される。なお、メモリ14には、パケットスケジューラが管理する通信タスクについての情報(周期、データ転送量、デッドライン、優先度など)や、情報処理装置1が単位時間あたりに送信(送出)できる最大転送量などが記憶される。
情報処理装置1は、ネットワーク制御部15を介してネットワーク3と接続されている。
上述したように図1の情報処理装置1cは全体送信量管理サーバとしての機能も兼ねる。全体送信量管理サーバは、ネットワーク3に接続された各情報処理装置が単位時間あたりに送信できる最大転送量を決定する機能を有する。このように、全体送信量管理サーバは、各情報処理装置の最大転送量を決定することで、ネットワーク全体で、過剰な通信が発生することを防止する。
<機能構成>
図3は、パケットスケジューラを実行する情報処理装置1の機能ブロック図である。パケットスケジューラの機能は、送信要求受付部21,最大転送量取得部22,通信速度取得部26,スケジュール可能性判定部23,及びパケット制御部25から構成される。なお、これらの各部は、パケット送信制御プログラムがCPU11によって実行されることによって、その機能が実現される。
図3は、パケットスケジューラを実行する情報処理装置1の機能ブロック図である。パケットスケジューラの機能は、送信要求受付部21,最大転送量取得部22,通信速度取得部26,スケジュール可能性判定部23,及びパケット制御部25から構成される。なお、これらの各部は、パケット送信制御プログラムがCPU11によって実行されることによって、その機能が実現される。
送信要求受付部21は、アプリケーションプログラム4からパケット送信の実行要求を受け付ける。パケットスケジューラは、IP(Internet Protocol)層上で機能するプロ
グラムであるので、アプリケーションプログラム4と送信要求受付部21の間には、TCP(Transmission Control Protocol)やUDP(User Datagram Protocol)などのトラ
ンスポート層および、さらにその上位のアプリケーション層が存在し、これらのプロトコル層を実装するプログラムが仲介するが、図3では省略している。
グラムであるので、アプリケーションプログラム4と送信要求受付部21の間には、TCP(Transmission Control Protocol)やUDP(User Datagram Protocol)などのトラ
ンスポート層および、さらにその上位のアプリケーション層が存在し、これらのプロトコル層を実装するプログラムが仲介するが、図3では省略している。
送信要求受付部21が受け付けるパケット送信の要求は、各周期ごとに所定のデータ量を送信する必要があり、送信開始から所定の時間(デッドライン)以内にパケットの送信を完了する必要がある。
図4は、周期的なパケット送信の通信タスクを説明する図である。図4(a)に示すように、一定周期Tごとに所定量のパケットを送信する必要がある。また、この送信を完了する制限時間であるデッドラインDが定められている。なお、パケットの送信はデッドライン以内に完了すれば、正しく処理されたものとみなされる。したがって、図4(b)に示すように、複数の通信タスクが存在する状況では、それぞれの通信タスクは1周期内で連続して全てのデータを送信する必要はなく、分割して送信することになってもかまわない。
最大転送量取得部22は、情報処理装置1が単位時間あたりに送信することを許可された最大量である最大転送量を、全体送信量管理サーバから取得する。上述したように、全体送信量管理サーバは、各情報処理装置の最大転送量を決定する。本実施形態では、最大転送量は全体送信量管理サーバから情報処理装置1に対して通信によって通知される。
通信速度取得部26は、ネットワーク3の実効通信速度を取得する。実効通信速度は、実測によって取得してもよく、あらかじめ定められた設定値を使用することもできる。
スケジュール可能性判定部23は、送信要求受付部21が受け付けたパケット送信の要求が、デッドラインを守って送信することができるか否か判定する。デッドライン保証可能であれば、通信タスク管理テーブル24に、実行すべき通信タスクとして登録する。スケジュール可能性判定部23の機能の詳細については後述する。
パケット制御部25は、通信タスク管理テーブル24に格納されている情報に基づいて、パケット送信を行う。パケット送信の通信タスクは、デッドラインが短いものほど優先度が高く設定され、パケット制御部25はこの優先度に基づいて送信するパケットを選択する。
なお、パケット制御部25は、1回に送信できるデータの最大値が定められている。この最大値は、MTU(Maximum Transfer Unit)と呼ばれる。本実施形態においては、M
TUの値として、イーサネット(登録商標)の標準規格である1518バイト(オクテット)よりも大きい16000バイトを使用する。なお、本発明において具体的なMTUのサイズは、これに限定されるものではない。
TUの値として、イーサネット(登録商標)の標準規格である1518バイト(オクテット)よりも大きい16000バイトを使用する。なお、本発明において具体的なMTUのサイズは、これに限定されるものではない。
パケット制御部25は、送信するパケットがMTUよりも大きい場合には、MTUサイズに分割した上で送信する。逆に、パケット制御部25は、送信するパケットがMTUサイズに満たない場合には、MTUサイズ内で連結して送信できる他のパケットがあればパケットを連結して送信する。
<処理フロー>
(スケジュール可能性判定処理)
次に図5を用いて、スケジュール可能性判定部23が行う、スケジュール可能性判定処理について説明する。
(スケジュール可能性判定処理)
次に図5を用いて、スケジュール可能性判定部23が行う、スケジュール可能性判定処理について説明する。
スケジュール可能性判定部23は、まずステップS101で、送信要求受付部21が受け付けたパケット送信と、すでに実行する通信タスクとして通信タスク管理テーブル24に格納されているタスクとを合計した場合の、単位時間あたりのデータ転送量を算出する。これは、Σ(各送信の送信データ量/周期)によって求めることができる。なお、(送信データ量)/(周期)は、MTU(Maximum Transfer Unit)単位に切り上げる。
次に、ステップS102で、算出した単位時間あたりのデータ転送量が、最大転送量取
得部22が取得した最大転送量以内であるか判定する。ここで、算出したデータ転送量が、最大転送量を超える転送量となる場合には、ステップS106に進み、受け付けたパケット送信を登録しないで、その実行を拒否する。算出したデータ転送量が、最大転送量以内である場合は、ステップS103に進む。
得部22が取得した最大転送量以内であるか判定する。ここで、算出したデータ転送量が、最大転送量を超える転送量となる場合には、ステップS106に進み、受け付けたパケット送信を登録しないで、その実行を拒否する。算出したデータ転送量が、最大転送量以内である場合は、ステップS103に進む。
ステップS103では、要求されたパケット送信の1周期の送信に要する送信所要時間を計算する。送信所要時間は、1周期あたりのデータ転送量を、通信速度取得部26が取得したネットワーク3の通信速度で割ることによって求めることができる。(送信所要時間)=(1周期あたりのデータ転送量)/(ネットワークの通信速度)。なお、1周期あたりのデータ転送量は、MTU単位で切り上げて使用する。
スケジュール可能性判定部23は、ステップS104で、デッドラインモノトニック法を利用して、すでに登録された通信タスク及び要求されたパケット送信についてデッドラインを保証できるか判定を行う。
デッドラインモノトニック法では、各パケット送信の周期、1周期あたりの送信所要時間、及びデッドラインを用いる。これらの情報に基づいてスケジュール可能性を判定する判断方法については、既知の如何なる方法を用いてもかまわない。例えば、スケジュール可能性の必要十分条件となる判定式を用いても良いし、十分条件を用いても良い。
スケジュール可能性の十分条件を表す判定式としては、例えば、以下の判定式を用いることができる。
なお、Ti,Ci,Diは、それぞれ通信タスクiの送信周期、送信所要時間、デッドラインである。また、通信タスクiは、i=1の通信タスクが最も優先度が高く、iが大きくなるにしたがって優先度が小さくなる。
この他の判定式については、例えば、以下の文献などに記載されている。
Audsley, Burns, Richardson, Wellings, "Hard Real-Time Scheduling: The Deadline-Monotonic Approach", Proceedings of the 8th IEEE Workshop on Real-Time Operating Systems and Software, 1991
このような判定式にしたがってスケジュール可能性の判定を行い、すでに登録された通
信タスクと要求された通信タスクの全てについてデッドラインを守ることができる場合には、ステップS105に進んで、要求されたパケット送信を、実行する通信タスクとして、通信タスク管理テーブル24に格納する。デッドラインを保証できない場合には、ステップS106に進み、受け付けたパケット送信を登録せず、その実行を拒否する。
信タスクと要求された通信タスクの全てについてデッドラインを守ることができる場合には、ステップS105に進んで、要求されたパケット送信を、実行する通信タスクとして、通信タスク管理テーブル24に格納する。デッドラインを保証できない場合には、ステップS106に進み、受け付けたパケット送信を登録せず、その実行を拒否する。
(パケット送信処理)
次に、図6を用いて、パケット制御部25が行うパケット送信処理について説明する。パケット制御部25は、通信タスク管理テーブル24に格納されている周期やデッドラインなどの情報に基づいてパケットの送信順序を制御する。また、パケット送信を効率的に行えるように、1つの通信タスクに係るパケットだけではMTUサイズに満たない場合には、他の通信タスクに係るパケットを連結して送信する。
次に、図6を用いて、パケット制御部25が行うパケット送信処理について説明する。パケット制御部25は、通信タスク管理テーブル24に格納されている周期やデッドラインなどの情報に基づいてパケットの送信順序を制御する。また、パケット送信を効率的に行えるように、1つの通信タスクに係るパケットだけではMTUサイズに満たない場合には、他の通信タスクに係るパケットを連結して送信する。
パケット制御部25は、ステップS201で、通信タスク管理テーブル24を参照して、最も優先度が高く、かつ、パケット送信が完了していない通信タスクを選択する。なお、上述したように、通信タスクの優先度は、デッドラインが短いものほど優先度が高く設定されている。
ここで、パケット制御部25は選択したパケットのサイズを計測する。なお、送信するパケットがMTUサイズよりも大きい場合には、MTUサイズに分割して送信する。一方、送信するパケットがMTUサイズよりも小さい場合には、他のデータを連結して1つのパケットとして送信する余地がある。
そこで、パケット制御部25は、ステップS202で、送信するパケットに空きがあるか判定する。すなわち、計測したパケットサイズがMTUサイズよりも小さいか判定する。ここで、ある閾値を設けて、次送信パケットにこの閾値以上の空きがあるか判定することが好ましい。
次送信パケットに空きがある場合(S202−YES)には、ステップS203へ進み、空き部分に入るデータが存在するか判定する。具体的には、パケット制御部25は、通信タスク管理テーブル24を参照して、優先度の高い通信タスクから順番に、送信データのサイズが空きサイズよりも小さい通信タスクが存在するか検査する。なお、パケット制御部25は、通信タスク管理テーブル24に登録されている全ての通信タスクを対象に検査を行っても良いが、優先度の高いものから所定の数の通信タスクについてのみ検査を行っても良い。連結するパケットの対象を絞ることで、優先度の逆転防止と通信の効率化のバランスを図ることができる。
空き部分に入るデータが存在する場合(S204−YES)は、ステップS205へ進み、次送信の空き部分に該当データを追加する。その後、ステップS202に戻り、再び次に送信するパケットに空きがあるかチェックする。一方、空き部分に入るデータが存在しない場合(S204−NO)は、ステップS206へ進み、パケットを送信する。
また、ステップS202において、次送信パケットに空きがないと判定された場合(S202−NO)は、ステップS206へ進み、その状態でパケットを送信する。
図7(a)に示すように4つの通信タスクに係るデータが送信待ちの場合を例にして、より具体的な説明を行う。通信タスクA〜Dは、通信タスクAが最も優先度が高く、通信タスクDが最も優先度が低いものとする。ここでは、まず通信タスクAが送信されるデータとして選択されるが、送信パケットには空きがある。そこで、空き部分に入るデータが存在するか優先度が高いものから順に調べると、通信タスクBが連結できることが分かる。通信タスクBを連結してもまだ空きがあるので、さらに追加できるデータがあるか調べ
ると、通信タスクCを連結するとMTUサイズを超えるので連結できないが、通信タスクDは連結できることが分かる。通信タスクA,B,Dを連結した後はこれ以上空きがないので、この状態でパケットが送信されることになる。
ると、通信タスクCを連結するとMTUサイズを超えるので連結できないが、通信タスクDは連結できることが分かる。通信タスクA,B,Dを連結した後はこれ以上空きがないので、この状態でパケットが送信されることになる。
(実施形態の効果)
本実施形態では、各情報処理装置が送信するデータ量は、全体送信量管理サーバによって管理される。さらに、各情報処理装置は、利用可能な転送量の範囲内で、デッドラインモノトニック法によってデッドライン以内に通信を完了することが保証された通信タスクのみを受け入れる。したがって、ネットワークシステム全体で、デッドラインを守ってパケット送信することができる。
本実施形態では、各情報処理装置が送信するデータ量は、全体送信量管理サーバによって管理される。さらに、各情報処理装置は、利用可能な転送量の範囲内で、デッドラインモノトニック法によってデッドライン以内に通信を完了することが保証された通信タスクのみを受け入れる。したがって、ネットワークシステム全体で、デッドラインを守ってパケット送信することができる。
また、通信タスクに係るデータのサイズがMTUサイズに比して小さい場合に、複数の通信タスクに係るデータを連結して送信するため、効率的な通信が実現できる。
[第2の実施形態]
第2の実施形態は、パケット制御部25の送信処理が異なるだけであり、その他については第1の実施形態と同様であるので、同様の部分については説明を省略する。
第2の実施形態は、パケット制御部25の送信処理が異なるだけであり、その他については第1の実施形態と同様であるので、同様の部分については説明を省略する。
本実施形態では、パケット制御部25は、送信予定のデータを、MTUよりも小さい固定長のサイズに分割した上で(以下、分割されたデータをセルという)、優先度にしたがってセルを連結してMTUサイズ分のパケットを生成して送信する。なお、本実施形態においてはセル長として53バイトを採用するが、その他どのようなセル長を採用しても良い。
図8(a)に示すように、4つの通信タスクに係るデータが送信待ちの場合を例にして具体的に説明を行う。通信タスクA〜Dは、通信タスクAが最も優先度が高く、通信タスクDが最も優先度が低いものとする。まず、各通信タスクに係るデータは、セルに分割される。たとえば、通信タスクAに係るデータは、A1〜A4の4つのセルに分割される。
次に、パケット制御部25は、優先度の高い通信タスクに係るセルから順番に、次に送信するパケットに連結していく。このような方法によって生成される送信パケットは、図8(b)に示すように、セルA1〜A4,B1,C1〜C4から構成される。この図は、生成されるパケットの一例であるが、以下の2つの利点がある。まず、第一に固定長のセルに分割しているので、優先度の逆転が発生しない。第二に、セルサイズを小さくすることで、送信パケットをMTUいっぱいまで有効に利用することができる。
また、パケット制御部25がパケット生成処理を行っている間に、優先度の高い新しい通信タスクが登録された場合に、その通信タスクに係るデータを優先して送信することができる。
このように、本実施形態によれば、優先度の逆転が極力起こらず、より効率的な通信が可能となる。
[第3の実施形態]
第3の実施形態は、スケジュール可能性判定部23が行う処理(図5参照)が異なるだけであり、その他については第1または第2の実施形態と同様であるので、同様の部分については説明を省略する。
第3の実施形態は、スケジュール可能性判定部23が行う処理(図5参照)が異なるだけであり、その他については第1または第2の実施形態と同様であるので、同様の部分については説明を省略する。
図9は、第3の実施形態におけるスケジュール可能性判定部23のスケジュール可能性判定処理を示すフローチャートである。図9の処理のうち、第1の実施形態と異なる部分
について詳しく説明する。
について詳しく説明する。
第1の実施形態と同様に、ステップS302で、要求されたパケット送信とすでに登録された通信タスクを合計した場合に必要となる単位時間あたりのデータ転送量が、情報処理装置1に割り当てられた最大転送量以内であるか判断する。必要となる単位時間あたりのデータ転送量が最大転送量を超える場合には、ステップS303に進む。
ステップS303では、最大転送量取得部22が、最大転送量の増加を全体送信量管理サーバに対して要求する。ここで、新たに要求する最大転送量は、ステップS302で求めた必要となる単位時間あたりのデータ転送量以上である。ステップS304で、全体送信量管理サーバへの要求が認められたか否か判定する。要求が認められた場合には、ステップS305に進んで、デッドラインモノトニック法によるスケジュール可能性判定を行う。要求が認められなかった場合には、ステップS308に進んで、要求されたパケット送信を拒否する。
全体送信量管理サーバは、ネットワーク全体での単位時間あたりに送信可能なデータ量(利用可能帯域)および、各情報処理装置が単位時間あたりに送信する最大送信データ量を管理しているため、帯域に余裕がある場合には、情報処理装置1からの最大転送量を増加する要求を受け入れることができる。
このように、第3の実施形態では、各情報処理装置が単位時間あたりに送信することのできる、データ量を必要に応じて増やすことができるので、より柔軟なスケジューリングが可能となる。
なお、このように最大転送量の増加を認める場合には、情報処理装置1が必要とする転送量が最大転送量よりも低くなった場合に、最大転送量を低下させる要求を全体送信量管理サーバに対して通知することが、ネットワーク資源の有効活用の観点から有効であることは言うまでもない。
[第4の実施形態]
第4の実施形態は、情報処理装置が、複数のネットワークに接続されている実施形態である。図10に示すように、情報処理装置6は、複数のネットワーク制御部15a,15b,15cを介して複数のネットワークに接続されている。この場合、情報処理装置6を含むネットワークシステムの全体は図11のようになる。図11において、情報処理装置6は、ネットワーク7a,7b,7cに接続されている。これら複数のネットワークとしては、例えば、イーサネット(登録商標)、携帯電話、光通信、無線通信などが挙げられる。
第4の実施形態は、情報処理装置が、複数のネットワークに接続されている実施形態である。図10に示すように、情報処理装置6は、複数のネットワーク制御部15a,15b,15cを介して複数のネットワークに接続されている。この場合、情報処理装置6を含むネットワークシステムの全体は図11のようになる。図11において、情報処理装置6は、ネットワーク7a,7b,7cに接続されている。これら複数のネットワークとしては、例えば、イーサネット(登録商標)、携帯電話、光通信、無線通信などが挙げられる。
この場合、情報処理装置6は、ネットワークごとに通信タスク管理テーブルを有する。スケジュール可能性判定部23は、送信相手先のネットワークに応じた通信タスク管理テーブルを用いて、上記実施形態と同様のスケジュール可能性判定処理を行うことで、それぞれのネットワークでデッドラインを保証した通信を行うことが可能となる。
なお、図11では複数のネットワークに接続された情報処理装置は1台だけであるが、複数あってもかまわないことは明らかである。
[変形例]
上記実施例においては、情報処理装置が単位時間あたりに送信できるデータ量の最大値は、全体送信量管理サーバから取得していた。しかし、必ずしもそのように構成する必要はなく、最大転送量は設定ファイルなどによる設定情報として、情報処理装置にあらかじ
め与えられていても良い。
上記実施例においては、情報処理装置が単位時間あたりに送信できるデータ量の最大値は、全体送信量管理サーバから取得していた。しかし、必ずしもそのように構成する必要はなく、最大転送量は設定ファイルなどによる設定情報として、情報処理装置にあらかじ
め与えられていても良い。
1 情報処理装置
2 パケットスケジューラ
3 ネットワーク
4 アプリケーションプログラム
6 情報処理装置
7 ネットワーク
11 CPU
12 タイマ
13 補助記憶装置
14 メモリ
15 ネットワーク制御部
21 送信要求受付部
22 最大転送量取得部
23 スケジュール可能性判定部
24 通信タスク管理テーブル
25 パケット制御部
26 通信速度取得部
2 パケットスケジューラ
3 ネットワーク
4 アプリケーションプログラム
6 情報処理装置
7 ネットワーク
11 CPU
12 タイマ
13 補助記憶装置
14 メモリ
15 ネットワーク制御部
21 送信要求受付部
22 最大転送量取得部
23 スケジュール可能性判定部
24 通信タスク管理テーブル
25 パケット制御部
26 通信速度取得部
Claims (5)
- ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御プログラムであって、
前記情報処理装置を、
各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける送信要求受付手段と、
前記要求されたパケット送信のデッドライン保証が可能か否か判定し、デッドライン保証可能であれば、該要求されたパケット送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、
前記登録された通信タスクのパケットを、該通信タスクのデッドラインに応じた優先度で送信するパケット制御手段
として機能させ、
前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、
前記パケット制御手段は、複数の通信タスクに係るパケットを連結して送信する
ことを特徴とするパケット送信制御プログラム。 - 前記パケット制御手段は、複数の通信タスクに係るパケットを固定長に分割して、前記優先度に応じて連結して送信する
ことを特徴とする請求項1に記載のパケット送信制御プログラム。 - 前記パケット送信の実行要求には、送信周期、1周期あたりの送信データ量、及び各周期におけるデッドラインが含まれ、
前記スケジュール可能性判定手段は、1周期あたりの送信データ量及び前記ネットワークにおける実効通信速度から、要求されたパケット送信に要する送信所要時間を算出し、前記送信周期、前記送信所要時間、及び前記デッドラインを用いて、デッドラインモノトニック法によって、前記すでに登録された通信タスク及び前記要求されたパケット送信の全てについて前記デッドライン保証が可能か否かを判定する
ことを特徴とする請求項1または2に記載のパケット送信制御プログラム。 - ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御装置であって、
各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける送信要求受付手段と、
前記要求されたパケット送信のデッドライン保証が可能か否か判定し、デッドライン保証可能であれば、該要求されたパケット送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、
前記登録された通信タスクのパケットを、該通信タスクのデッドラインに応じた優先度で送信するパケット制御手段と、
を有し、
前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、
前記パケット制御手段は、複数の通信タスクに係るパケットを連結して送信する
ことを特徴とするパケット送信制御装置。 - ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御方法であって、
前記情報処理装置が、
各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付け、
すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、
前記登録された複数の通信タスクに係るパケットを、該通信タスクのデッドラインに応じた優先度で連結して送信する
ことを特徴とするパケット送信制御方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007076602A JP2008236625A (ja) | 2007-03-23 | 2007-03-23 | パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007076602A JP2008236625A (ja) | 2007-03-23 | 2007-03-23 | パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2008236625A true JP2008236625A (ja) | 2008-10-02 |
Family
ID=39908817
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007076602A Withdrawn JP2008236625A (ja) | 2007-03-23 | 2007-03-23 | パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2008236625A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021106353A (ja) * | 2019-12-27 | 2021-07-26 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置およびプログラム |
-
2007
- 2007-03-23 JP JP2007076602A patent/JP2008236625A/ja not_active Withdrawn
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021106353A (ja) * | 2019-12-27 | 2021-07-26 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置およびプログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4916809B2 (ja) | 負荷分散制御装置および方法 | |
JP4872952B2 (ja) | Tcpバッファコピー分散並列処理装置、方法及びプログラム | |
CN101695019B (zh) | 一种报文发送方法和设备 | |
CN114374647B (zh) | 一种对时敏业务流和路由联合调度的规划方法及装置 | |
EP2755363B1 (en) | Data-fast-distribution method and device | |
CN101635678A (zh) | 一种p2p终端流量控制的方法及系统 | |
CN102811176B (zh) | 一种数据流量控制方法和装置 | |
US8838782B2 (en) | Network protocol processing system and network protocol processing method | |
CN113141321B (zh) | 一种基于边缘计算的数据传输方法及电子设备 | |
US20130044755A1 (en) | Scalable Packet Scheduling Policy for Vast Number of Sessions | |
JP6982250B2 (ja) | パケット転送装置、方法、及びプログラム | |
CN112787952B (zh) | 一种业务流量调整方法及装置 | |
CN104753813A (zh) | Dma传送报文的方法 | |
JP2007074218A (ja) | パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法 | |
US20230117851A1 (en) | Method and Apparatus for Queue Scheduling | |
JP2011128989A (ja) | データ処理装置、データ処理方法、及びプログラム | |
JP2010093370A (ja) | エッジノードおよび帯域制御方法 | |
JP2008236625A (ja) | パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法 | |
US8467401B1 (en) | Scheduling variable length packets | |
CN102594670B (zh) | 多端口多流的调度方法、装置及设备 | |
CN103986668A (zh) | 一种最大优先级队列的设计方法 | |
JP4630231B2 (ja) | パケット処理システム、パケット処理方法、およびプログラム | |
CN112399470B (zh) | LoRa通信方法、LoRa网关、LoRa系统、计算机可读存储介质 | |
JP5772132B2 (ja) | データ転送装置、データ転送方法および情報処理装置 | |
CN107332786B (zh) | 一种在服务链环境下保障数据流截止时间的调度方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20100601 |