以下本発明の実施の形態について、図面を参照しながら説明する。なお、実施の形態における説明においては、TCPを用いた通信を例に説明を行うが、TCP同様に、受信可能なバッファ空き容量を確認応答パケットによって通知する同種の通信プロトコルにおいても、本発明は、適用可能である。また、実施の形態の説明においては、受信専用の通信装置を受信側装置とし、送信専用の通信装置を送信側装置とし、受信側装置に本発明を適用したとして説明を行うが、受信側装置および送信側装置の双方に、送受信機能を備えてもよく、送信側装置に本発明を適用しても良い。
(実施の形態1)
図8は、本実施の形態に係る通信装置(受信側装置)の構成の一例を示す図である。受信側装置31は、ネットワーク37と有線または無線で接続する通信機能を持つ装置であり、例えば、Ethernet(登録商標)インタフェースを備える。ネットワーク37は有線または無線を含むネットワークであり、インターネットなどの公衆ネットワークなどが例として挙げられる。
受信側装置31は、システムバス32、処理部33、記憶部34、および通信部35を備える。
通信部35は、システムバス32上に接続されたハードウェアである。通信部35は、記憶部34に格納されたパケットをネットワーク37に送信する機能と、ネットワーク37からパケットを受信する機能を有する。また、通信部35は、ネットワーク37から受信したパケットを一時的に保持するための記憶領域(以下、FIFOという)36を有する。なお、実施の形態1〜10では、通信部が受信手段として構成されている。
処理部33は、システムバス32上に接続されたハードウェアである。処理部33は、記憶部34に格納されたデータをパケットとして構築する処理を行ったり、受信したパケットに対して解析処理を行ったりする。なお、処理部33は、送信パケットを記憶部34から通信部35へ転送したり、通信部35のFIFO36に格納されているパケットを記憶部34へ転送したりする機能を有する場合もある。
記憶部34は、送受信するパケットやそのデータを保持する機能を有する。
ここで、受信側装置31の受信処理を説明する。受信側装置31は、ネットワーク37からパケットを受信すると、まず通信部35のFIFO36に受信したパケットを格納する。次に、受信側装置31は、FIFO36に格納した受信パケットをFIFO36から記憶部34へシステムバス32を介して転送する。記憶部34へ転送された受信パケットの内容は、処理部33によって解析され、受信処理される。処理部33は、解析結果を得ると、アプリケーションプログラム(以下、単にアプリケーションという)に受信したデータを引き渡す。
図9は、本実施の形態の受信側装置31における処理部33の機能構成の一例を示す構成図である。なお、本実施の形態においては、TCP処理部42は、処理部33で実行されるプログラムとして構成されているが、LSI(Large Scale Integration)などで実装されたものであっても良い。また、図中の実線は、送受信パケットのデータフローを、破線は制御情報のやり取りに関するフローを示している。
処理部33は、IP処理部41、TCP処理部42およびアプリケーション処理部43を備える。
受信側装置31のTCP処理部42は、TCPパケット処理部44、受信バッファ47、ウィンドウサイズ算出部48、ウィンドウ更新タイマ部49、受信レート決定部50、および前回RWIN記憶部51から構成される。次に、これらの各構成要素の説明をする。
TCPパケット処理部44は、TCPパケットの送受信処理の機能を有する。TCPパケット処理部44は、受信したパケットのアプリケーションを特定し、そのパケットをアプリケーションへ引き渡すため、受信バッファ47に格納する。さらに、TCPパケット処理部44は、TCPパケットを構築し、IP処理部41へ渡し、TCP/IPパケットとして送信する機能を有する。また、TCPパケット処理部44には、ACK生成部45とウィンドウ更新通知生成部46が含まれる。
ACK生成部45は、受信したTCPパケットのシーケンス番号に基づいて、ACK番号を決定し、ACKパケットを生成する。ACKパケットには、ウィンドウサイズ算出部48から得た、現在受信可能な空き容量(以下、ウィンドウサイズ)も設定される。なお、実施の形態1〜9では、ACK生成部は第1のパケット生成手段として構成されて、ACKパケットは確認応答パケットに相当する。また、ACKパケットに設定されるウィンドウサイズは応答サイズに相当する。
ウィンドウ更新通知生成部46は、受信バッファ47の空き状況に増加が生じたとき、ウィンドウ更新通知パケットを生成する。さらに、ウィンドウ更新通知生成部46は、ウィンドウ更新タイマ部49からの指示により、ウィンドウ更新通知パケットを生成する機能を有する。ウィンドウ更新通知パケットには、ウィンドウサイズ算出部48から得た、ウィンドウサイズが設定される。なお、実施の形態1〜9では、ウィンドウ更新通知生成部は第2のパケット生成手段として構成されて、ウィンドウ更新通知パケットはデータ要求パケットに相当する。また、ウィンドウ更新通知パケットに設定されるウィンドウサイズは受信サイズに相当する。
受信バッファ47は、アプリケーション処理部43に渡すための受信データを一時的に保持する機能を有する。受信バッファ47は、最大RWIN_MAXのデータを格納することができ、アプリケーション処理部43の要求により、受信バッファ47に一時的に保持されているデータを順に、アプリケーション処理部43へ渡す。また、受信バッファ47は、アプリケーション処理部43へデータが渡されることによってウィンドウサイズが増加した際は、ウィンドウ更新通知生成部46へウィンドウサイズが増加したことを通知する。
ウィンドウサイズ算出部48は、送信側装置38へウィンドウサイズとして通知する値を算出する機能を有する。ウィンドウサイズ算出部48は、受信レート決定部50から指示される更新量(以下、RWIN_Update)と、前回RWIN記憶部51に格納される前回通知したウィンドウサイズ(RWIN_Prev)とに基づき、ウィンドウサイズを算出する。ウィンドウサイズは、次の式で算出される。
ウィンドウサイズ=RWIN_Prev+RWIN_Update・・・(式1)
なお、受信バッファ47が格納可能なデータの最大サイズ(RWIN_MAX)も考慮して、次の式で算出してもよい。
ウィンドウサイズ=MIN(RWIN_Prev+RWIN_Update,
RWIN_MAX)・・・(式2)
MIN(A,B)は、AとBの最小値を返すものとする。
ウィンドウ更新タイマ部49は、所定間隔で、ウィンドウ更新通知生成部46にウィンドウ更新通知パケットの送信を指示する機能を有する。また、所定間隔は、受信レート決定部50により指示される。
受信レート決定部50は、受信側装置31におけるTCPパケットの受信レートに基づき、ウィンドウサイズ算出部48の更新量と、ウィンドウ更新タイマ部49の所定間隔を決定する機能を有する。次に、更新量と所定間隔の決定方法の例を示す。
例1:
更新量と所定間隔は、FIFO36の容量とシステムバス32の転送能力に基づいて次の式で算出することができる。
更新量=FIFO36の容量・・・(式3)
所定間隔=FIFO36の容量/システムバス32の転送能力・・・(式4)
具体的には、受信側装置31のFIFO36の容量が4KBであり、システムバス32の転送能力が40Mbpsである場合、更新量は、FIFO36の容量に合わせ4KBとなり、所定間隔は、4KBをシステムバス32が転送するのに要する時間0.8ミリ秒となる。なお、所定間隔は、0.8ミリ秒以上とすることで、システムバス32の転送能力以下のデータ転送量に抑えることができるので、1ミリ秒としても良い。また、所定間隔を算出する際、システムバス32の転送能力で除算しているが、CPU(Central Processing Unit)処理能力も加味し、1パケットの処理時間とシステムバスの転送能力とから所定間隔を算出しても良い。
例2:
更新量と所定間隔は、FIFO36の容量とアプリケーションが要求するビットレートに基づいて次の式で算出することができる。
更新量=FIFO36の容量・・・(式5)
所定間隔=RTT/CEILING(((アプリケーションが必要とするビットレート
×RTT)/8)/更新量,1)・・・(式6)
CEILING(A,B)は、AをBの単位で切り上げた結果を出力する。
具体的には、受信側装置31のFIFO36のサイズが4KBであり、アプリケーションが要求するビットレート10Mbps、RTTを10ミリ秒とした場合、更新量は、FIFO36のサイズに合わせ4KBとなる。さらに、この場合、アプリケーションの要求するビットレートが10Mbpsであるため、1RTT(10ミリ秒)中に、12.5KBのデータをアプリケーションが受信する必要がある。したがって、更新量として4KBずつの増加を考慮すると、1RTTに中に3.125回、すなわち4回の更新が必要となる。よって、所定間隔は、RTT/4である2.5ミリ秒となる。
例3:
更新量と所定間隔は、受信バッファ47に格納可能なデータの最大容量RWIN_MAXとアプリケーションが要求するビットレートに基づいて次の式から算出することができる。
更新量=RWIN_MAX・・・(式7)
所定間隔=RTT/CEILING(((アプリケーションが必要とするビットレート
×RTT)/8)/RWIN_MAX,1)・・・(式8)
具体的には、受信バッファ47に格納可能なデータの最大容量RWIN_MAXを8KB、アプリケーションが必要とするビットレート10Mbps、RTTを10ミリ秒とした場合、更新量は、RWIN_MAXに合わせ8KBとなる。さらに、この場合、アプリケーションの必要とするビットレートが10Mbpsであるため、1RTT(10ミリ秒)中に、12.5KBのデータを受信する必要がある。したがって、更新量として8KBずつの増加を考慮すると、1RTT中に1.5625回、すなわち2回の更新が必要となる。よって、所定間隔は、RTT/2である5ミリ秒となる。
なお、例1〜例3で示した式を元に、更新量をMSS単位に丸めたり、所定間隔をミリ秒もしくは、数ミリ秒単位に切り上げたりしてもよい。
また、受信レート決定部50は、複数のコネクションが張られた場合や、処理部33が別の通信処理以外の処理を実施するため、処理能力が低下した場合など、受信側装置31の受信状況が変化場合に合わせて、更新量と所定間隔を動的に変更する機能を持っても良い。
前回RWIN記憶部51は、前回にウィンドウ更新通知を行った際に用いたウィンドウサイズ(以下、前回ウィンドウサイズという)を記録保持する機能を有する。前回RWIN記憶部51は、記録保持する前回ウィンドウサイズをウィンドウサイズ算出部48へ渡し、ウィンドウサイズ算出部48が算出した結果を受け取り、前回ウィンドウサイズを更新し記録保持を行う。
図10は、本実施の形態におけるデータパケットとACKパケットのやり取りを示したシーケンス図である。図10の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。また、1パケット長を1、更新量を4、更新間隔(上述の所定間隔)をTミリ秒、として説明をする。さらに、図中のP71(Ack=10,Win=4)は、ACK番号10およびウィンドウサイズ4のACKパケットであることを示し、P81(Seq=10,11,12,13)は、シーケンス番号10、11、12、13のデータパケットであることを示している。
受信側装置31は、送信側装置38とコネクションの確立などを経て、送信側装置38から送信されるデータを受信する状態となる。このとき、受信側装置31は、更新量4をACKパケット(ウィンドウ更新通知パケットでも良い)のウィンドウサイズとして設定し、そのACKパケット(ウィンドウ更新通知パケット)を送信側装置38へ通知している(P71)。ACKパケットP71を受信した送信側装置38は、受信したACKパケットP71のウィンドウサイズが4であることから、シーケンス番号10、11、12、13の4個のデータパケットP81を送信する(P81)。
次に、受信側装置31は、ACKパケットP71を送信後、所定間隔のTミリ秒が経過すると、式1に従い、前回通知したウィンドウサイズ4に、更新量4を加算し、8をウィンドウ更新通知パケットのウィンドウサイズに設定し、そのウィンドウ更新通知パケットを送信側装置38へ通知する(P72)。ACKパケットP72を受信した送信側装置38は、受信したACKパケットP72のウィンドウサイズが8であることから、既に送信済みシーケンス番号10、11、12、13を含めて8個のデータパケットを送信することが可能となる。そのため、送信側装置38は、データパケットP81の続きであるシーケンス番号14、15、16、17のデータパケットP82を送信する。
以降、ACKパケットP73、P74も上述と同様に受信側装置31から送信される。また、データパケットP83、P84も上述と同様に送信側装置38から送信される。
このとき、受信側装置31が送信するACKパケットの間隔は、Tミリ秒間隔であるため、送信側装置38がACKパケットを受信する間隔もTミリ秒間隔となる。さらに、送信側装置38が受信するACKパケット間隔がTミリ秒間隔であり、更新量ずつウィンドウサイズが増加しているため、送信側装置38は、Tミリ秒間隔で、更新量ずつのデータパケットを送信することとなる。
受信側装置31は、送信側装置38がTミリ秒間隔で、データパケットを送信するため、Tミリ秒間隔で更新量ずつのデータパケットを受信することとなる。なお、このTミリ秒は、(式4)または、(式6)などから算出した値であるため、このTミリ秒の間に、受信側装置31は、更新量分のデータを処理することが可能である。よって、受信処理が溢れることなく受信処理を行うことが可能である。
このように本実施の形態では、送信側装置38から送信される送信データの間隔とその量を、受信側装置31で制御することにより、受信側装置31の最大限の性能を引き出すことが可能となる。また、本発明により、この送信データの間隔とその量の制御を、データパケットの受信によらず任意のタイミングで開始することが可能である。さらに、更新量の単位で送信データ量を制御することで、ウィンドウ更新通知パケットの生成回数を減らし、ウィンドウ更新通知パケットのACK番号も同一のものを使用する。その結果、一連のウィンドウ更新通知パケットで変更すべきパラメータはウィンドウサイズだけであるため、処理負荷を軽減することが可能となる。例えば、RWIN_MAXを32、更新量を4、RTTを10ミリ秒としたとき、本実施の形態では、ウィンドウ更新通知パケットの送信間隔は、1.42ミリ秒となる。一方、特許文献1では、ACK分割を行い1MSSずつ受信可能な空きバッファ容量を更新する方式を使用するため、0.32ミリ秒間隔で制御する必要がある。したがって、本実施の形態では、従来と比べて処理負荷を軽減できる。さらに、送信側装置38から送信される送信データの間隔とその量を、受信側装置31のアプリケーションの受信レートにあったレートに制御することができ、受信バッファには、最大でも更新量分のデータしか滞留せず、メモリ効率も良くなる。
(実施の形態2)
本実施の形態における通信装置(受信側装置)は、実施の形態1の図8に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
図11は、本実施の形態の受信側装置31における処理部の機能構成の一例を示す構成図である。本実施の形態の受信側装置31は、実施の形態1の処理部33の代わりに処理部33aを備える。以降、各構成要素の機能に関して説明を行う。なお、本実施の形態における処理部33aは、実施の形態1の処理部33に対して付加的な機能を有するため、実施の形態1との差分のみを説明する。
処理部33aは、IP処理部61、TCP処理部62およびアプリケーション処理部63を備える。
また、本実施の形態の受信側装置31のTCP処理部62は、TCPパケット処理部64、受信バッファ67、ウィンドウサイズ算出部68、ウィンドウ更新タイマ部69、受信レート決定部70、および前回RWIN記憶部71から構成される。ここで、受信バッファ67、ウィンドウサイズ算出部68および前回RWIN記憶部71は、実施の形態1の受信バッファ47、ウィンドウサイズ算出部48および前回RWIN記憶部51と同一の機能および構成を有する。
TCPパケット処理部64は、ACK生成部65およびウィンドウ更新通知生成部66を備える。このようなTCPパケット処理部64は、実施の形態1に示したTCPパケット処理部44の機能を有するとともに、通知するウィンドウサイズを(式1)に基づき更新している最中に、送信側装置38からのパケットを受信したら、ウィンドウ更新通知機能を停止することを受信レート決定部70に通知する機能をさらに有する。なお、ウィンドウ更新通知機能とは、実施の形態1に示すように、所定間隔で、ウィンドウサイズを増加させて、その増加されたウィンドウサイズを示すウィンドウ更新通知パケットを送信側装置38に送信することをいう。
ウィンドウ更新タイマ部69は、実施の形態1に示したウィンドウ更新タイマ部49の機能を有するとともに、受信レート決定部70からの停止通知に基づきタイマ機能を停止する機能をさらに有する。
受信レート決定部70は、実施の形態1に示した受信レート決定部50の機能を有するとともに、TCPパケット処理部64からの停止通知を受けて、ウィンドウ更新タイマ部69を停止する機能と更新量を0とする機能とをさらに有する。
図12は、本実施の形態におけるデータパケットとACKパケットのやり取りを示したシーケンス図である。図12の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。また、1パケット長を1、更新量を4、更新間隔(上述の所定間隔)をTミリ秒、として説明をする。さらに、図中のP91(Ack=10,Win=4)は、ACK番号10およびウィンドウサイズ4のACKパケットであることを示し、P101(Seq=10,11,12,13)は、シーケンス番号10、11、12、13のデータパケットであることを示している。
受信側装置31がACKパケットP94を送信するまでと、送信側装置38がデータパケットP104を送信するまでは、受信側装置31および送信側装置38におけるデータ送受信処理は、実施の形態1と同様である。したがって、受信側装置31が、ACKパケットP95を送信する処理、すなわち1RTT経過後の処理から説明する。
1RTT経過後、受信側装置31は、データパケットP101を受信する。受信側装置31は、データパケットP101を受信すると、データパケットP101に対するACKパケットP95を生成し、送信側装置38へ送信する。また、データパケットP101を受信すると受信レート決定部70は、ウィンドウ更新タイマ部69のウィンドウ更新タイマを停止し、ウィンドウサイズ算出部68での更新量を0に設定する。そのため、送信するACKパケットP95のウィンドウサイズは、前回RWIN記憶部71が保持するウィンドウサイズ値である16となる。
このACKパケットP95を受信した送信側装置38は、ACK番号14およびウィンドウサイズ16から、シーケンス番号14以降のデータをウィンドウサイズ16分送信することができる。そこで、送信側装置38は、シーケンス番号14以降の未送信データであるシーケンス番号26、27、28、29のデータパケットP105を送信する。
次に、受信側装置31が、データパケットP102を受信したときの処理に関して説明する。データパケットP102受信時には、ウィンドウ更新タイマは停止しており、更新量は0となっている。そのため、データパケットP102に対するACKパケットP96のウィンドウサイズは、前回RWIN記憶部71が保持するウィンドウサイズ値である16となる。また、このACKパケットP96を受信した送信側装置38は、シーケンス番号18以降の未送信データであるシーケンス番号30、31、32、33のデータパケットP106を送信する。以降、同様に処理を繰り返す。
図13は、本実施の形態における受信側装置31の動作を示すフローチャートである。
まず、受信側装置31は、送信側装置38との間でコネクションを確立し、送信側装置38から送信されるデータを受信し得る状態になる。そして、受信側装置31は、ウィンドウ更新通知機能を開始する(ステップS400)。つまり、受信側装置31は、ACK番号=Nおよびウィンドウサイズ=更新量を示すACKパケットまたはウィンドウ更新通知パケットを生成して、送信側装置38に送信する。なお、Nは、受信側装置31が要求するデータパケットのシーケンス番号である。また、このとき受信側装置31のウィンドウ更新タイマ部49は時間計測を開始する。
次に、受信側装置31は、受信側装置38からデータパケットを受信したか否かを判別する(ステップS402)。ここで、受信側装置38からデータパケットを受信していないと判別したときには(ステップS402のN)、さらに、受信側装置31は、所定期間であるTミリ秒が経過したか否かを判別する(ステップS404)。
受信側装置31は、Tミリ秒が経過したと判別すると(ステップS404のY)、ACK番号=Nおよびウィンドウサイズ=前回のウィンドウサイズ+更新量を示すウィンドウ更新通知パケットを生成して、送信側装置38に送信する(ステップS406)。一方、Tミリ秒が経過していないと判別したとき(ステップS404のN)や、ステップS406でウィンドウ更新通知パケットの送信が終了したときには、受信側装置31は、再びステップS402からの処理を実行する。
また、受信側装置31は、ステップS402でデータパケットを受信したと判別すると(ステップS402のY)、上述のウィンドウ更新通知機能を停止する(ステップS408)。つまり、ウィンドウ更新タイマ部49は時間計測を停止し、更新量は0にリセットされる。さらに、受信側装置31は、送信側装置38から送信されて受信されたデータパケットに対する確認応答として、ACK番号=N+nおよびウィンドウサイズ=前回のウィンドウサイズを示すACKパケットを生成して、送信側装置38に送信する(ステップS410)。なお、nは、受信側装置31で受信されたデータパケットの数である。
そして、受信側装置31は、再び、送信側装置38からデータパケットを受信したか否かを判別する(ステップS412)。その結果、データパケットを受信したと判別したときには(ステップS412のY)、受信側装置31は、ステップS410からの処理を繰り返し実行し、データパケットを受信していないと判別したときには(ステップS412のN)、送信側装置38からのデータの受信処理を終了する。
このように本実施の形態では、実施の形態1と同様の効果を得ることができるとともに、1RTT経過後に受信レート決定部70が更新量を0にしてウィンドウ更新タイマを停止することで、データ受信後も送信側装置38から送信される送信データのレートを一定に保つことが可能となる。
(実施の形態3)
本実施の形態における通信装置(受信側装置)は、実施の形態1の図8に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
図14は、本実施の形態の受信側装置31における処理部の機能構成の一例を示す構成図である。本実施の形態の受信側装置31は、実施の形態1の処理部33の代わりに処理部33bを備える。以降、各構成要素の機能に関して説明を行う。なお、本実施の形態における処理部33bは、実施の形態2の処理部33aに対して付加的な機能を有するため、実施の形態2との差分のみを説明する。
処理部33bは、IP処理部81、TCP処理部82およびアプリケーション処理部83を備える。
また、本実施の形態の受信側装置31のTCP処理部82は、TCPパケット処理部84、受信バッファ87、ウィンドウサイズ算出部88、ウィンドウ更新タイマ部89、受信レート決定部90、および前回RWIN記憶部91から構成される。ここで、受信バッファ87および前回RWIN記憶部91は、実施の形態1の受信バッファ47および前回RWIN記憶部51と同一の機能および構成を有する。
TCPパケット処理部84は、ACK生成部85およびウィンドウ更新通知生成部86を備える。このようなTCPパケット処理部84は、実施の形態2に示したTCPパケット処理部64の機能を有するとともに、ウィンドウ更新通知機能が停止している最中に、送信側装置38からのパケットを受信したら、受信レート決定部90にウィンドウ更新通知機能再開を通知する機能を有する。
ウィンドウサイズ算出部88は、実施の形態1および2に示したウィンドウサイズ算出部48,68の機能を有する。さらに、ウィンドウサイズ算出部88は、1連のデータ受信における総データ量をアプリケーション処理部83から通知される機能を有する場合は、総データ量だけのデータの受信の終了に合わせてACKパケットで通知するウィンドウサイズを減少させる機能を有する。
ウィンドウ更新タイマ部89は、実施の形態2に示したウィンドウ更新タイマ部69の機能と、受信レート決定部90からのウィンドウ更新通知機能再開の通知を受け、ウィンドウ更新通知機能を再開する機能を有する。
受信レート決定部90は、実施の形態2に示した受信レート決定部70の機能と、TCPパケット処理部84からのウィンドウ更新通知機能再開の通知を受け、所定間隔と更新量の算出を行い、ウィンドウ更新タイマ部89にウィンドウ更新通知機能再開の通知を行う機能を有する。
図15は、本実施の形態におけるデータパケットとACKパケットのやり取りを示したシーケンス図である。図15の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。また、1パケット長を1、更新量を4、更新間隔(上述の所定間隔)をTミリ秒、として説明をする。さらに、図中のP111(Ack=6,Win=8)は、ACK番号6およびウィンドウサイズ8のACKパケットであることを示し、P121(Seq=2,3,4,5)は、シーケンス番号2、3、4、5のデータパケットであることを示している。
送信側装置38は、データパケットP121、P122を送信することで、一旦データ転送を終える。その後、任意の時間を空けてデータパケットP123の転送を再開する。このときのACKパケットとデータパケットのやり取りを説明する。
まず、送信側装置38がデータパケットP122で転送を一旦終了するときに関して説明する。
ウィンドウサイズ算出部88は、1連のデータ受信における総データ量をアプリケーション処理部83から通知されている。そこで、ウィンドウサイズ算出部88は、総データ量だけのデータの受信の終了に合わせて、送信するACKパケットのウィンドウサイズを減少させる。(式9)は、ウィンドウサイズ算出部88におけるウィンドウサイズ算出式を示している。
ウィンドウサイズ=MIN((総データ量−受信データ量)+更新量,
前回RWIN記憶部が保持するウィンドウサイズ)・・・(式9)
すなわち、
ウィンドウサイズ=MIN(残りの受信データ量+更新量,
前回RWIN記憶部が保持するウィンドウサイズ)・・・(式10)
となる。
なお、総データ量にあわせて、
ウィンドウサイズ=MIN(総データ量−受信データ量,
前回RWIN記憶部が保持するウィンドウサイズ)・・・(式11)
としても良い。(式11)とした場合は、送信側装置38からデータ送信が再開される際、受信側装置31の受信バッファに空きが存在するか確認するプルーブパケットからデータ送信が始まることとなる。
図15において、送信側装置38は、データパケットP121を送信する。データパケットP121を受信した受信側装置31は、データパケットP121に対応するACKパケットP111を生成し、送信する。このとき受信側装置31が送信するデータパケットは、(式9)に基づき、ウィンドウサイズ8と設定される。次に、送信側装置38は、データパケットP122を送信する。データパケットP122を受信した受信側装置31は、データパケットP122に対応するACKパケットP112を生成し、送信する。このとき受信側装置31が送信するデータパケットは、(式9)に基づき、ウィンドウサイズ4と設定される。このように、残り受信データ量に合わせてウィンドウサイズを減少させていく。
次に、送信側装置38がデータ送信を再開した以降、すなわちデータパケットP123を送信した以降で説明する。
送信側装置38は、データパケットP123を送信し、データ送信を再開する。このとき、受信側装置31が前回送信したACKパケットP112のウィンドウサイズが4であったことから、送信側装置38は、シーケンス番号10、11、12、13とウィンドウサイズ分のデータパケットを送信することになる。このように、データ送信が一旦停止する際に、ウィンドウサイズを減少させていたことで、データ送信再開の際に、バースト的に送信データが到着することを防止している。
次に、受信側装置31は、送信側装置38が送信再開をしたデータパケットP123を受信すると、受信したデータパケットP123に対応するACKパケットP113を生成し、送信する。その後、受信側装置31は、受信レート決定部90にデータ転送が再開されたことを通知する。通知を受けた受信レート決定部90は、実施の形態1と同様に、更新量と所定間隔を決定し、ウィンドウ更新タイマ部89にウィンドウ更新タイマの再開を促す。その結果、ACKパケットP113を送信後、所定間隔のTミリ秒が経過すると、受信側装置31は、(式1)に従い、前回通知したウィンドウサイズ4に、更新容量4を加算し、8をウィンドウ更新通知パケットのウィンドウサイズに設定し、そのウィンドウ更新通知パケットを送信側装置38へ通知する(P114)。さらに、受信側装置31は、所定間隔のTミリ秒間隔で、ウィンドウ更新通知パケットP115、P116を送信していく。これにより、送信側装置38では、所定間隔のTミリ秒間隔で、データパケットP124、P125、P126を送信することとなる。
このように本実施の形態では、実施の形態1および2と同様の効果を得ることができる。さらに、本実施の形態では、データ転送が一旦停止した際にも、ウィンドウサイズを減少させてウィンドウ更新通知機能を再開することで、送信側装置からの送信が一旦停止した後の再開した送信データの送信レートを制御することも可能となる。
(実施の形態4)
本実施の形態における通信装置(受信側装置)は、実施の形態1の図8に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
また、本実施の形態の受信側装置31における処理部は、実施の形態2の図11に示す処理部33aと略同様の構成を有する。したがって、本実施の形態における処理部について、図11を用い、実施の形態2との違いが明確になるように以下説明する。
本実施の形態におけるTCPパケット処理部64は、実施の形態2に示した機能を有するとともに、ウィンドウ更新通知機能が停止している最中に、パケットロスを検知し、送信側装置38からのロスしたパケットの再送を確認したら、受信レート決定部70にウィンドウ更新通知機能再開を通知する機能を有する。
本実施の形態におけるウィンドウ更新タイマ部89は、実施の形態2に示した機能を有するとともに、受信レート決定部70からのウィンドウ更新通知機能再開の通知を受け、ウィンドウ更新タイマ機能を再開する機能を有する。
受信レート決定部70は、実施の形態2に示した機能を有する。さらに、受信レート決定部70は、TCPパケット処理部64からのウィンドウ更新通知機能再開の通知を受け、所定間隔と更新量の算出を行い、ウィンドウ更新タイマ部69にウィンドウ更新通知機能再開の通知を行う機能と、前回RWIN記憶部71に記録されている前回ウィンドウサイズ値を初期値、例えば0に戻す機能とを有する。
前回RWIN記憶部71は、実施の形態2に示した機能と、受信レート決定部70の働きにより、記憶している前回ウィンドウサイズ値が初期化される機能とを有する。
図16は、本実施の形態におけるデータパケットとACKパケットのやり取りを示したシーケンス図である。図16の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。また、説明を簡略化するために、1パケット長を1、更新量を1、更新間隔(上述の所定間隔)をTミリ秒、として説明をする。さらに、図中のP131(Ack=11,Win=6)は、ACK番号11およびウィンドウサイズ6のACKパケットであることを示し、P151(Seq=10)は、シーケンス番号10のデータパケットであることを示している。
受信側装置31は、ウィンドウ更新通知機能を停止している状態で、一定間隔で、送信側装置38からの送信データパケットを受信している。このとき、データパケットP152がパケットロスしたとして説明をする。
受信側装置31は、データパケットP153の到着によりパケットロスが発生したことに気付く。そのため、受信側装置31は、ACK番号11のACKパケットP133を送信する。その後も、受信側装置31は、同様にパケットロス以降のデータパケットP154、P155、P156を受信し、パケットロスが発生しているため、ACK番号11のACKパケットP134、P135、P136を送信する。このとき、送信側装置38は、重複したACK番号のACKパケットを4連続で受信すると、ネットワーク上でパケットロスが発生したと検知し、タイムアウトを待たずに即座に、データパケットP158を再送する(TCP高速再送機能)。ここまでは、従来のTCPでも、実装されている機能である。
次に、TCP高速再送機能により、データパケットP158が再送処理された以降の説明をする。
受信側装置31では、再送されたデータパケットP158が受信されると、TCPパケット処理部64は、受信レート決定部70へ、パケットロスが発生して再送パケットを受信したことを通知する。再送パケットを受信したことを通知された受信レート決定部70は、前回RWIN記憶部71の値を初期化し、ウィンドウ更新タイマ部69にウィンドウ更新タイマの起動を促し、更新量を1とし、ウィンドウ更新通知機能を再開する。その後、受信側装置31は、ACKパケットP138を生成し、送信する。このとき生成されるACKパケットP138は、現在受信しているシーケンス番号16から、ACK番号17を設定し、前回RWIN記憶部71に記録されている値と更新量を元にウィンドウサイズ1が設定される。このACKパケットP138を受信した送信側装置31は、通知されたウィンドウサイズ1に基づき、続きのシーケンス番号17のデータパケットP159を送信する。
次に、受信側装置31は、ACKパケットP138を送信後、所定間隔のTミリ秒が経過すると、(式1)に従い、前回通知したウィンドウサイズ1に、更新容量1を加算し、2をウィンドウ更新通知パケットのウィンドウサイズに設定し、そのウィンドウ更新通知パケットを送信側装置38へ通知する(P139)。ACKパケットP139を受信した送信側装置38は、受信したACKパケットP139のウィンドウサイズが2であることから、既に送信済みシーケンス番号17を含めて2個のデータパケットを送信することが可能となる。そのため、送信側装置38は、データパケットP159の続きであるシーケンス番号18のデータパケットP160を送信する。以降、受信側装置31は、実施の形態1と同様にTミリ秒間隔で、ウィンドウ更新処理を行い、Tミリ秒間隔で、データパケットを受信することになる。
このように本実施の形態では、実施の形態1および2と同様の効果を得ることができる。さらに、本実施の形態では、パケットロス発生後も、ウィンドウ更新通知機能を再開させることによって、送信側装置の再送データに関しても送信レート制御を行うことが可能となる。また、実施の形態3と組み合わせることにより、実施の形態3で得られる効果も享受することができる。
(実施の形態5)
本実施の形態における通信装置(受信側装置)は、実施の形態1の図8に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
図17は、本実施の形態の受信側装置31における処理部の機能構成の一例を示す構成図である。本実施の形態の受信側装置31は、実施の形態1の処理部33の代わりに処理部33cを備える。以降、各構成要素の機能に関して説明を行う。なお、本実施の形態における処理部33cは、実施の形態2の処理部33aに対して付加的な機能を有するため、実施の形態2との差分のみを説明する。
処理部33cは、IP処理部101、TCP処理部102およびアプリケーション処理部103を備える。
また、本実施の形態の受信側装置31のTCP処理部102は、TCPパケット処理部104、受信バッファ107、ウィンドウサイズ算出部108、ウィンドウ更新タイマ部109、受信レート決定部110、前回RWIN記憶部111、およびACK遅延部112から構成される。ここで、受信バッファ107、ウィンドウサイズ算出部108、ウィンドウ更新タイマ部109、および前回RWIN記憶部111は、実施の形態2の受信バッファ67、ウィンドウサイズ算出部68、ウィンドウ更新タイマ部69および前回RWIN記憶部71と同一の機能および構成を有する。
TCPパケット処理部104は、ACK生成部105およびウィンドウ更新通知生成部106を備える。ウィンドウ更新通知生成部106は、実施の形態2のウィンドウ更新通知生成部66と同様の機能および構成を有する。
ACK生成部105は、実施の形態1〜4のACK生成部と同様、受信したTCPパケットのシーケンス番号に基づいて、ACK番号を決定し、ACKパケットを生成する。ACKパケットには、ウィンドウサイズ算出部108から得た、現在受信可能な空き容量であるウィンドウサイズも設定される。さらに、本実施の形態のACK生成部105は、生成したACKパケットをACK遅延部112へ渡す。渡されたACKパケットは、その後送信される。
受信レート決定部110は、実施の形態2の受信レート決定部70と同様の機能を有するとともに、ACK遅延部112にACKパケット遅延時間とそのACK量とを指定する機能を有する。ACKパケット遅延時間およびACK量は、次の式で決定される。
ACK量=更新量・・・(式12)
ACKパケット遅延時間=更新間隔(上述の所定間隔)・・・(式13)
なお、ACK量およびACKパケット遅延時間は、更新量および更新間隔を算出する式と同様に、FIFO36の容量や、システムバス32の転送能力から算出したり、アプリケーションが要求するビットレートから算出したりすることができる。
ACK遅延部112は、生成されたACKパケットを送信前に一時的に保持し、遅延させる機能を有する。ACK遅延時間は、受信レート決定部110により決定される。
図18は、本実施の形態におけるデータパケットとACKパケットのやり取りを示したシーケンス図である。図18の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。また、1パケット長を1、更新量を4、更新間隔(上述の所定間隔)をTミリ秒、として説明をする。さらに、図中のP175(Ack=14,Win=16)は、ACK番号14、ウィンドウサイズ16のACKパケットであることを示し、P183(Seq=18,19,20,21)は、シーケンス番号18、19、20、21のデータパケットであることを示している。
受信側装置31は、実施の形態2と同様に、ウィンドウ更新通知機能を開始後、1RTTが経過し、データパケットP181を受信したために、ウィンドウ更新通知機能を停止している状態である。
受信側装置31のACK生成部105は、データパケットP181が受信されるとそのACKパケットを生成し、ACK遅延部112へ渡す。ACKパケットを受け取ったACK遅延部112は、前回ACKパケット(または、ウィンドウ更新通知パケット)を送信した時刻にACKパケット遅延時間を加算したACK送信時刻を求め、現在時刻がACK遅延時刻を越えているかつ、ACK番号が前回ACKパケットに比べACK量分進んでいるのなら、即座にACKパケットを送信する。図18では、データパケットP181が受信された時点で、前回ACKパケット送信時刻からACKパケット遅延時間が経過しているので、即座にACKパケットP175は送信されている。
ここで、送信側装置38が送信したデータパケットP182がネットワーク37の状況変化により通常よりも早く受信されたとする。受信側装置31のACK生成部105は、受信したデータパケットP182に対するACKパケットを生成し、ACK遅延部112へ渡す。ACKパケットを受け取ったACK遅延部112は、前回ACKパケットP175の送信時刻にACK遅延時間を加算したACK送信時刻を求めた結果、ACK送信時刻に現在時刻が満たないので、即座にACKパケットP176の送信を行わない。その後、ACK遅延部112は、ACK送信時刻に現在時刻が達すると、ACK遅延部112で保留していたACKパケットP176を送信する。
図19は、本実施の形態におけるデータパケットとACKパケットの他のやり取りを示したシーケンス図である。図19の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。また、1パケット長を1、更新量を4、更新間隔(上述の所定間隔)をTミリ秒、として説明をする。
受信側装置31は、実施の形態2と同様に、ウィンドウ更新通知機能を開始後、1RTTが経過し、データパケットP201を受信したために、ウィンドウ更新通知機能を停止している状態である。
受信側装置31のACK生成部105は、データパケットP201が受信されるとそのACKパケットを生成し、ACK遅延部112へ渡す。ACKパケットを受け取ったACK遅延部112は、前回ACKパケット(または、ウィンドウ更新通知パケット)を送信した時刻にACKパケット遅延時間を加算したACK送信時刻を求め、現在時刻がACK遅延時刻を越えているかつ、ACK番号が前回ACKパケットに比べACK量分進んでいるのなら、即座にACKパケットを送信する。図19では、データパケットP201が受信された時点で、前回ACKパケット送信時刻からACKパケット遅延時間が経過しているので、即座にACKパケットP195は送信されている。
ここで、送信側装置38が送信したデータパケットP202がネットワーク37の状況変化により通常より遅延して受信されたとする。受信側装置31のACK生成部105は、受信したデータパケットP202に対するACKパケットを生成し、ACK遅延部112へ渡す。ACKパケットを受け取ったACK遅延部112は、前回ACKパケットP195の送信時刻にACK遅延時間を加算したACK送信時刻を求めた結果、すでに現在時刻がACK送信時刻を経過しているので、即座にACKパケット196の送信を行う。つまり、図19では、前回ACKパケットP195の送信時刻からACKパケット遅延時間を十分に経過しているので、即座にACKパケットP196は送信されている。
さらに、受信側装置31は、送信側装置38が送信したデータパケットP203を受信する。受信側装置31は、受信したデータパケットP203に対するACKパケットを生成し、ACK遅延部112へ渡す。ACKパケットを受け取ったACK遅延部112は、前回ACKパケットP196の送信時刻にACK遅延時間を加算したACK送信時刻を求めた結果、ACK送信時刻に現在時刻が満たないため、ACKパケット197の送信を行わない。その後、ACK遅延部112は、ACK送信時刻に現在時刻が達すると、ACK遅延部112で保留していたACKパケットP197を送信する。以降も、ACK遅延部112は、ACK送信時刻を確認し、ACKパケットP198、P199の送信を行う。そして、ACKパケットP200の時点で、データパケット到着間隔が所定間隔に戻ったため、即座にACKパケットが送信されるようになる。
このように本実施の形態では、実施の形態1および2と同様の効果を得ることができる。さらに、本実施の形態では、ネットワークの揺らぎによって、データパケットの到着間隔に変化が生じたとしても、ACKパケットの送信間隔を制御することによって、送信側装置の送信レート制御を行うことが可能となる。また、本実施の形態を実施の形態3または4と組み合わせることにより、実施の形態3または4で得られる効果も享受することができる。
(実施の形態6)
本実施の形態における通信装置(受信側装置)は、実施の形態1の図8に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
また、本実施の形態の受信側装置31における処理部は、実施の形態5の図17に示す処理部33cと略同様の構成を有する。したがって、本実施の形態における処理部について、図17を用い、実施の形態5との違いが明確になるように以下説明する。
図17は、本発明の受信側装置31におけるTCP処理部を中心とした処理構成例を示したものである。以降、各処理部の機能に関して説明を行う。なお、実施の形態5と構成例は、同じでありその機能に若干の差があるのみである。本実施の形態を説明する上では、実施の形態5との差分のみを説明する。
本実施の形態における受信レート決定部110は、実施の形態5に示した機能を有するとともに、受信レート変更の要求を受けて、ACK遅延時間とACK量を更新し、ACK遅延部112へ通知する機能を有する。
本実施の形態におけるACK遅延部112は、実施の形態5に示した機能を有するとともに、受信レート変更要求に基づき受信レート決定部110で決定された、ACK遅延時間とACK量とを受け取り、送信するACKパケットに反映する機能を有する。
図20は、本実施の形態におけるデータパケットとACKパケットのやり取りを示したシーケンス図である。図20の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。また、ウィンドウ更新通知の開始後の、1RTTが経過するまでの1パケット長を1、更新量を4、更新間隔(上述の所定間隔)をTミリ秒、として説明をする。さらに、図中のP211(Ack=14,Win=16)は、ACK番号14およびウィンドウサイズ16のACKパケットであることを示し、P222(Seq=18,19,20,21)は、シーケンス番号18、19、20、21のデータパケットであることを示している。
受信側装置31は、データパケットP221を受信し、ACKパケットP212を送信する。ここまでは、受信側装置31は、実施の形態5と同様のデータ送受信処理を行なう。その後、受信側装置31は、図中の「受信レート変更」の時刻に受信レートを変更したくなったとする。本実施の形態では、受信間隔(上述の所定間隔)を2倍の2Tミリ秒と変更したいとする。このレート変更要求は、受信レート決定部110に通知される。受信レートの変更要求を受け取った受信レート決定部110は、受信間隔を2倍にしたいことから、ACK遅延部112にACKパケット遅延時間を2倍とするように指示を出す。
その後、受信側装置31がデータパケットP222を受信すると、ACK生成部105はACKパケットを生成し、ACK遅延部112へ渡す。ACKパケットを受け取ったACK遅延部112は、前回のACK送信時刻にACKパケット遅延時間を加算して、ACKパケット送信時刻を求める。このとき算出されるACK送信時刻は、受信レート変更要求を受けずに算出されるACK送信時刻よりも先となっている。そのため、データパケットP222が受信された時点において、現在時刻がACK送信時刻に達していないので、受信側装置31のACK遅延部112は、即座にACK送信を行わない。
さらに、受信側装置31がデータパケットP223を受信すると、ACK生成部105はACKパケットを生成し、ACK遅延部112へ渡す。ACKパケットを受け取ったACK遅延部112は、前回のACK送信時刻にACKパケット遅延時間を加算して、ACKパケット送信時刻を求める。その結果、データパケットP223が受信された時点において、現在時刻がACK送信時刻に達しているので、ACK遅延部112は即座にACK送信を行う。また、このときACK遅延部112は、前のデータパケットP222に対するACKパケットが保留されているため、その保留分のデータ量4をウィンドウサイズから減算して、ウィンドウサイズ12としてACKパケットP213の送信を行う。以降同様に、受信側装置31はデータパケットP224、P225の受信処理を行い、ACKパケットP214の送信を行う。このようにして、送信側装置38が送信するデータパケットの送信間隔を2倍に変更することが可能である。
図21は、本実施の形態におけるデータパケットとACKパケットの他のやり取りを示したシーケンス図である。図21の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。また、ウィンドウ更新通知の開始後の、1RTTが経過するまでの1パケット長を1、更新量を4、更新間隔(上述の所定間隔)をTミリ秒、として説明をする。
受信側装置31は、データパケットP241を受信し、ACKパケットP232を送信する。ここまでは、受信側装置31は、実施の形態5と同様のデータ送受信処理を行なう。その後、受信側装置31は、図中の「受信レート変更」の時刻に受信レートを変更したくなったとする。本実施の形態では、更新量を2分の1に変更したいとする。このレート変更要求は、受信レート決定部110に通知される。受信レート変更要求を受け取った受信レート決定部110は、更新量を2分の1にしたいことから、ACK遅延部112に更新量を2分の1とするように指示を出す。すなわち、本実施の形態では、更新量が2に変更される。
その後、受信側装置31がデータパケットP242を受信すると、ACK生成部105はACKパケットを生成し、ACK遅延部112へ渡す。ACKパケットを受け取ったACK遅延部112は、前回のACK送信時刻にACKパケット遅延時間を加算して、ACKパケット送信時刻を求める。このとき算出されるACK送信時刻は、データパケットP242が受信された時点において現在時刻に達しているため、ACK遅延部112は即座にACKパケットP233を送信する。しかし、受信レート変更要求によりACK遅延部112の更新量は、2分の1となっている。そのため、現在送信しようとしているACKパケットのACK量が、シーケンス番号18、19、20、21の4つ分であり、更新量が2であるから、ACK遅延部112は、(式14)に従いウィンドウサイズを14に設定してACKパケットP233を送信する。
ウィンドウサイズ=前回RWIN記憶部111が記憶するウィンドウサイズ
−(ACK量−更新量)・・・(式14)
同様に、受信側装置31は、データパケットP243、P244、P245を受信するとウィンドウサイズを2ずつ減らしながら、ACKパケットP234、P235、P236を送信していく。
その後、受信側装置31は、送信側装置38からデータパケットP246を受信する。ここで、データパケットP246はシーケンス番号34、35の2つのデータ分であって、ACK量=2となる。したがって、受信側装置31は、(式14)に従い、前回のウィンドウサイズと同じ8のウィンドウサイズを示すACKパケットP237を送信することになる。このようにして、送信側装置38が送信するデータパケットの送信量を2分の1に変更することが可能である。
このように本実施の形態では、実施の形態1、2および5と同様の効果を得ることができる。さらに、本実施の形態では、受信側装置の受信状況の変化に応じて、ACK送信間隔やウィンドウサイズを制御することにより、送信側装置が送信するデータパケットの送信レートを動的に変更することが可能である。また、本実施の形態を実施の形態3または4と組み合わせることにより、実施の形態3または4で得られる効果も享受することができる。
(実施の形態7)
本実施の形態における通信装置(受信側装置)は、実施の形態1の図8に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
図22は、本実施の形態の受信側装置31における処理部の機能構成の一例を示す構成図である。本実施の形態の受信側装置31は、実施の形態1の処理部33の代わりに処理部33dを備える。以降、各構成要素の機能に関して説明を行う。なお、本実施の形態における処理部33dは、実施の形態1の処理部33に対して付加的な機能を有するため、実施の形態1との差分のみを説明する。
処理部33dは、IP処理部121、TCP処理部122およびアプリケーション処理部123を備える。
また、本実施の形態の受信側装置31のTCP処理部122は、TCPパケット処理部124、受信バッファ127、ウィンドウサイズ算出部128、ウィンドウ更新タイマ部129、受信レート決定部130、および前回RWIN記憶部131から構成される。ここで、受信バッファ127、ウィンドウサイズ算出部128、ウィンドウ更新タイマ部129、および前回RWIN記憶部131は、実施の形態1の受信バッファ47、ウィンドウサイズ算出部48、ウィンドウ更新タイマ部49および前回RWIN記憶部51と同一の機能および構成を有する。
TCPパケット処理部124は、ACK生成部125およびウィンドウ更新通知生成部126を備える。TCPパケット処理部124は、実施の形態1に示したTCPパケット処理部44の機能を有するとともに、受信レート決定部130から更新量が通知され、連続受信データパケットが更新量に達したとき、受信データパケットが更新量に達したことを受信レート決定部130に通知する機能をさらに有する。
受信レート決定部130は、実施の形態1に示した受信レート決定部50の機能を有する。さらに、受信レート決定部130は、TCPパケット処理部124へ更新量を通知する機能と、連続受信データパケットが更新量に達したときに、受信データパケットが更新量に達したことを通知する通知をTCPパケット処理部124から受け取る機能とを有する。さらに、受信レート決定部130は、更新量に達したことの通知を受け取ると、(式3)〜(式8)のいずれかの方法で更新量と所定間隔を算出し、ウィンドウサイズ算出部128とウィンドウ更新タイマ部129へその値を伝える。
図23は、本実施の形態におけるデータパケットとACKパケットのやり取りを示したシーケンス図である。図23の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。また、1パケット長を1、更新量を4、更新間隔(上述の所定間隔)をTミリ秒、として説明をする。さらに、図中のP251(Ack=2,Win=4)は、ACK番号2およびウィンドウサイズ4のACKパケットであることを示し、P261(Seq=1)は、シーケンス番号1のデータパケットであることを示している。
送信側装置38は、送信データ量を徐々に増加させるスロースタートという機能を有している。そのため、送信側装置38が送信する送信データパケットの数は、1RTTごとに、1パケット(P261)、2パケット(P262)、4パケット(P263)と増加している。データパケットP262が受信されるまでは、受信側装置31では、送信側装置38が連続に送信するデータパケットが更新量に達していないため、ウィンドウ更新通知機能は行われていない。
その後、受信側装置31は、データパケットP263を受信する。データパケットP263を受信した受信側装置31は、データパケットP263に対するACKパケットP253を生成し送信する。また、受信側装置31では、TCPパケット処理部124が受信レート決定部130へ、更新量に達したことを通知する。更新量に達したことを通知された受信レート決定部130は、ウィンドウサイズ算出部128へ更新量(本実施の形態では4)を通知し、ウィンドウ更新タイマ部129へウィンドウ更新タイマの起動を促し、ウィンドウ更新通知機能を開始する。ACKパケットP253を受信した送信側装置38は、受信したACKパケットP253のウィンドウサイズが4であることから、続きのシーケンス番号8、9、10、11を送信する。
次に、ウィンドウ更新通知機能を開始した受信側装置31は、ACKパケットP253を送信後、所定間隔Tミリ秒経過すると、(式1)に従い、前回通知したウィンドウサイズ4に、更新量4を加算し、8をウィンドウ更新通知パケットのウィンドウサイズに設定し、そのウィンドウ更新通知パケットを送信側装置38へ通知する(P254)。ACKパケットP254を受信した送信側装置38は、受信したACKパケットP254のウィンドウサイズが8であることから、既に送信済みシーケンス番号8、9、10、11を含めて8個のデータパケットを送信することが可能となる。そのため、送信側装置38は、データパケットP263の続きであるシーケンス番号12、13、14、15のデータパケットP264を送信する。
このように本実施の形態では、実施の形態1と同様の効果を得ることができるとともに、送信側装置がスロースタートを行う場合においても、受信側装置から送信側装置の送信レートを制御することができる。また、以下の図24に示すデータ送受信処理であっても、上述と同様の効果を得ることができる。
図24は、本実施の形態におけるデータパケットとACKパケットの他のやり取りを示したシーケンス図である。図24の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。また、1パケット長を1、更新量を4、更新間隔(上述の所定間隔)をTミリ秒、として説明をする。
このとき、受信側装置31と送信側装置38とのデータ送受信処理は、データパケットP343が受信されるまで、図23に示す処理と同様に行われる。次に、受信側装置31では、データパケットP343が受信されると、TCPパケット処理部124は、受信レート決定部130へ、更新量に達したことを通知する。更新量に達したことを通知された受信レート決定部130は、ウィンドウサイズ算出部128へ更新量(本実施の形態では4)を通知し、ウィンドウ更新タイマ部129へウィンドウ更新タイマの起動を促し、ウィンドウ更新通知機能を開始する。
次に、ウィンドウ更新通知機能を開始した受信側装置31は、次の式14に則りウィンドウ更新を行う。
ウィンドウサイズ=前回通知したウィンドウサイズ+更新量−ACK番号増加量 ・・・(式14)
なお、本実施の形態では、前回通知したウィンドウサイズを4、更新量を4、ACK番号増加量を1として説明する。
データパケットP343を受信した受信側装置31は、ウィンドウ更新通知機能により、データパケット受信後、ACKパケットP333を送信側装置へと送信する。このときの、ACKパケットP333は、ACK番号はACK番号増加量1により、5となり、ウィンドウサイズは、(式14)により、7となる。ACKパケットP333を受信した送信側装置38は、受信したACKパケットP333のウィンドウサイズが7で、ACK番号が5であることから、5以降のシーケンスで未送信シーケンスであるシーケンス番号8、9、10、11のデータパケットP344を送信する。
次に、ウィンドウ更新通知機能により受信側装置31は、ACKパケットP333を送信後、所定間隔のTミリ秒が経過すると、(式14)に従い、前回通知したウィンドウサイズ7に、更新容量4を加算し、ACK番号増加量1に基づいて、ウィンドウサイズ10を算出する。受信側装置31は、算出したウィンドウサイズ10を設定したACKパケットP334を、送信側装置38へ通知する。ACKパケットP334を受信した送信側装置38は、受信したACKパケットP334のウィンドウサイズが10で、ACK番号が6であることから、ACK番号が6以降のシーケンスで未送信シーケンスであるシーケンス番号12、13、14、15のデータパケットP345を送信する。
このように本実施の形態では、実施の形態1と同様の効果を得ることができるとともに、送信側装置がスロースタートを行う場合においても、受信側装置から送信側装置の送信レートを制御することが可能である。また、本実施の形態を実施の形態2、3、または4などと組み合わせることにより、各々の実施の形態で得られる効果も享受することができる。
なお、本実施の形態では、送信側装置38から連続的に送信されたデータパケットが更新量に達したときに、ウィンドウ更新通知機能を開始させたが、予め定められた時間が経過したときや、送信側装置38から送信された全てのデータパケットの数が予め定められた数に達したときに、ウィンドウ更新通知機能を開始させてもよい。
(実施の形態8)
本実施の形態における通信装置(受信側装置)は、実施の形態1の図8に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
図25は、本実施の形態の受信側装置31における処理部の機能構成の一例を示す構成図である。本実施の形態の受信側装置31は、実施の形態1の処理部33の代わりに処理部33eを備える。
処理部33eは、IP処理部141、TCP処理部142およびアプリケーション処理部143を備える。なお、本実施の形態においては、TCP処理部142は、処理部33eで実行されるプログラムとして説明を行うが、LSIなどに実装されたものであっても良い。また、図中の実線は、送受信パケットのデータフローを、破線は制御情報のやり取りに関するフローを示している。
受信側装置31のTCP処理部142は、TCPパケット処理部144、受信バッファ147、ウィンドウサイズ算出部148、および前回RWIN記憶部149から構成される。
TCPパケット処理部144は、TCPパケットの送受信処理の機能を有する。TCPパケット処理部144は、受信したパケットのアプリケーションを特定し、そのパケットをアプリケーションへ引き渡すため、受信バッファ147に格納する。さらに、TCPパケット処理部144は、TCPパケットを構築し、IP処理部141へ渡し、TCP/IPパケットとして送信する機能を有する。また、TCPパケット処理部144には、ACK生成部145、ウィンドウ更新通知生成部146およびパケットロス検知部150が含まれる。
ACK生成部145は、受信したTCPパケットのシーケンス番号に基づいて、ACK番号を決定し、ACKパケットを生成する。ACKパケットには、ウィンドウサイズ算出部148から得た、現在受信可能な空き容量、つまりウィンドウサイズも設定される。
ウィンドウ更新通知生成部146は、受信バッファ147の空き状況に増加が生じたとき、ウィンドウ更新通知パケットを生成する。また、ウィンドウ更新通知生成部146は、ウィンドウサイズ算出部148から得たウィンドウサイズを、そのウィンドウ更新通知パケットに設定する。
パケットロス検知部150は、TCPパケットに抜けやロスがあったことを検知する機能を持つ。また、パケットロス検知部150は、ロスが発生したことをウィンドウサイズ算出部148に通知する機能を有する。
受信バッファ147は、アプリケーション処理部143に渡すための受信データを一時的に保持する機能を有する。受信バッファ147は、最大RWIN_MAXのデータを格納することができ、アプリケーション処理部143の要求により、受信バッファ147に一時的に保持されているデータを順に、アプリケーション処理部143へと渡す。また、受信バッファ147は、アプリケーション処理部143へデータが渡されることによってウィンドウサイズが増加した際は、ウィンドウ更新通知生成部146へウィンドウサイズが増加したことを通知する。
ウィンドウサイズ算出部148は、送信側装置38へウィンドウサイズとして通知する値を算出する機能を有する。つまり、本実施の形態におけるウィンドウサイズ算出部148は、パケットロス検知部150から通知されたパケットロスに基づいて、ウィンドウサイズを算出する。ウィンドウサイズは、次の式で算出される。
ウィンドウサイズ=前回通知したウィンドウサイズ−前回通知したウィンドウサイズ中ロスしたデータ量・・・(式15)
また、所定時間Hにパケットロスが検知されていなかった場合は、次の式で算出しても良い。
ウィンドウサイズ=前回通知したウィンドウサイズ+更新量・・・(式16)
なお、更新量は、1MSSであったり、複数MSSであったりしても良い。
前回RWIN記憶部149は、前回にウィンドウ更新通知を行った際に用いたウィンドウサイズ(以下、前回ウィンドウサイズという)を記録保持する機能を有する。前回RWIN記憶部149は、記録保持する前回ウィンドウサイズをウィンドウサイズ算出部148へ渡し、ウィンドウサイズ算出部148が算出した結果を受け取り、前回ウィンドウサイズを更新し記録保持を行う。
図26は、本実施の形態におけるデータパケットとACKパケットのやり取りを示したシーケンス図である。図26の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。また、説明を簡略化するために、1パケット長を1、更新量を2、所定時間をHミリ秒、として説明をする。さらに、図中のP351(Ack=1,Win=8)は、ACK番号1およびウィンドウサイズ8のACKパケットであることを示し、P362(Seq=8)は、シーケンス番号8のデータパケットであることを示している。
受信側装置31は、送信側装置38とコネクションの確立などを経て、送信側装置38から送信されるデータを受信する状態となる。このとき、受信側装置31は、ウィンドウサイズを8として、送信側装置38へ通知している(P351)。送信側装置38は、ウィンドウサイズ8に基づいて、データパケットP361、P362を受信側装置31へ送信する。しかし、このときネットワーク37が混雑している、または、中継装置の能力不足などが原因で、データパケットP362がロスしたとする。データパケットP362が到達しなかった受信側装置31では、到着したシーケンス番号までに対するACKパケットP352を送信する。ACKパケットP352を受信した送信側装置38は、続きのシーケンス番号であるデータパケットP363を送信する。
データパケットP363を受信した受信側装置31は、シーケンス番号8がロスしたこと検知し、前回送信したACKパケットP352と同様のACKパケット(以下、重複ACKパケットという)P353を、受信したパケット(シーケンス番号9〜15のパケット)数分だけ送信する。なお、本実施の形態では、7個の重複ACKパケットP353が送信されることになる。重複ACKパケットを受信した送信側装置38は、シーケンス番号8がロスしたことを知り、高速再送機能によりシーケンス番号8のデータパケットP364を再送する。
再送されたデータパケットP364を受信した受信側装置31は、(式15)によりウィンドウサイズを減少させ、ウィンドウサイズ7としてACKパケットP354を送信する。ACKパケットP354を受信した送信側装置38は、そのACKパケットに設定されるウィンドウサイズが7であることから、7パケット分のデータパケットP365を送信する。
つまり、ACKパケットP354でウィンドウサイズが8に設定されていれば、送信側装置38は、データパケットP361、P362を送信したときと同様、再び、8個のパケットを有するデータパケットを受信側装置31に送信しようとする。その結果、再び、パケットロスが発生する可能性が高まる。
しかしながら、本実施の形態では、ACKパケットP354でウィンドウサイズが7に設定されるため、再びパケットロスが発生するのを防ぐことができる。
図27は、本実施の形態におけるデータパケットとACKパケットの他のやり取りを示したシーケンス図である。図27の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。また、説明を簡略化するために、1パケット長を1、更新量を2、所定時間をHミリ秒、として説明をする。
受信側装置31は、送信側装置38とコネクションの確立などを経て、送信側装置38から送信されるデータを受信する状態となる。このとき、受信側装置31は、ウィンドウサイズを6として、送信側装置38へ通知している(P371)。送信側装置38は、ウィンドウサイズ6に基づいて、データパケットP381を受信側装置31へ送信する。データパケットP381を受信した受信側装置31は、ACK番号7およびウィンドウサイズ6を示すACKパケットP372を送信側装置38に送信する。このような受信側装置31と送信側装置38のデータ送受信処理は、暫く継続して繰り返される。
そして、受信側装置31は、データパケットの受信を開始して所定時間Hが経過すると、(式16)によりウィンドウサイズを更新量だけ増加させ、ウィンドウサイズを8として通知する(P373)。これにより、送信側装置38は、ウィンドウサイズ8に応じたデータパケットP382を送信する。
つまり、所定時間Hの間にパケットロスが発生していなければ、送信側装置38は、パケットロスの発生を抑えた状態でより多くのパケットを送信することができる可能性が高い。 したがって、本実施の形態では、所定時間Hの間にパケットロスが発生していなければ、ウィンドウサイズが大きく設定されるため、データ転送効率を向上することができる。
このように本実施の形態では、ウィンドウサイズをパケットロス状況にあわせ動的に変化させることで、連続的なパケットロスを防止することが可能となる。また、パケットロスが発生していないことを検知し、ウィンドウサイズを増加させることで、より効率の良いデータ転送を実現することが可能となる。
(実施の形態9)
本実施の形態における通信装置(受信側装置)は、実施の形態1の図8に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
図28は、本実施の形態の受信側装置31における処理部の機能構成の一例を示す構成図である。本実施の形態の受信側装置31は、実施の形態1の処理部33の代わりに処理部33eを備える。
処理部33fは、IP処理部161、TCP処理部162およびアプリケーション処理部163を備える。なお、本実施の形態においては、TCP処理部162は、処理部33fで実行されるプログラムとして説明を行うが、LSIなどに実装されたものであっても良い。また、図中の実線は、送受信パケットのデータフローを、破線は制御情報のやり取りに関するフローを示している。
受信側装置31のTCP処理部162は、TCPパケット処理部164、受信バッファ167およびウィンドウサイズ算出部168から構成される。なお、受信バッファ167は、実施の形態1の受信バッファ47と同一の機能および構成を有する。
TCPパケット処理部164は、TCPパケットの送受信処理の機能を有する。TCPパケット処理部164は、受信したパケットのアプリケーションを特定し、そのパケットをアプリケーションへ引き渡すため、受信バッファ167に格納する。さらに、TCPパケット処理部164は、TCPパケットを構築し、IP処理部161へ渡し、TCP/IPパケットとして送信する機能を有する。また、TCPパケット処理部164には、ACK生成部165、重複ACK生成部166およびパケット抜け検知部169が含まれる。
ACK生成部165は、受信したTCPパケットのシーケンス番号に基づいて、ACK番号を決定し、ACKパケットを生成する。ACKパケットには、ウィンドウサイズ算出部168から得た、現在受信可能な空き容量、つまりウィンドウサイズも設定される。
重複ACK生成部166は、受信パケットに抜けが発生したことをパケット抜け検知部169から通知されると、重複ACKパケットを生成し、送信する機能を有する。また、重複ACKパケットには、ウィンドウサイズ算出部168から得た、ウィンドウサイズが設定される。
パケット抜け検知部169は、TCPパケットに抜けやロスがあったことを検知する機能を持つ。また、パケット抜け検知部169は、パケット抜けがあったことを重複ACK生成部166に通知する。
ウィンドウサイズ算出部168は、受信バッファ167の空き状況によりウィンドウサイズを算出し、ACK生成部165や重複ACK生成部166へ通知する機能を有する。
図29は、本実施の形態におけるデータパケットとACKパケットのやり取りを示したシーケンス図である。図29の例では、受信側装置31が送信するACKパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置38が送信するデータパケットを実線で示している。
送信側装置38は、受信側装置31からACKパケットP391を受信すると、データパケットP401,P402,P403を受信側装置P391に送信する。ここで、送信側装置38が送信したデータパケットP401、P402、P403のうち、データパケットP402が受信側装置31に受信されなかったとする。
このとき、受信側装置31は、データパケットP403の到着によりパケットの抜けを検知する。パケットの抜けを検知した受信側装置31は、即座にACKパケットP392を所定数生成し、送信側装置38へ送信する。
所定数のACKパケットP392を受信した送信側装置38は、高速再送機能により、即座にデータパケットP404を再送する。
このように本実施の形態では、パケット抜け検知後、同一のACKパケットを所定数、送信側装置へ送信することにより、送信側装置に高速再送機能を迅速に誘発させることが可能となり、パケット抜けからのすばやい復旧を行うことが可能となる。
(実施の形態10)
以下本実施の形態について、図面を参照しながら説明する。
図30は、本発明の実施の形態に係るネットワークの構成例および通信装置の構成例を示す図である。図30において、通信装置200Aが、ネットワーク3Aを経由し、通信装置100Aと通信する。通信装置100Aおよび通信装置200Aは、ネットワーク3Aと有線または無線で接続する通信機能を持つ装置であり、例えば、Ethernet(登録商標)インタフェースを備えた装置(例えばPC(Personal Computer)や、ネットワーク通信が可能な家電装置など)である。ネットワーク3Aは、有線または無線を含むネットワークであり、インターネットなどの公衆ネットワークなどが例として挙げられる。
本実施の形態では、通信装置100Aと通信装置200Aとがそれぞれの間でTCPのコネクションを確立し、通信装置200Aから通信装置100Aにデータが送信されることを想定する。このような想定上、TCPのコネクションにおけるデータ送信の関係において、データ送信元の通信装置200Aを送信側装置、データ送信先の通信装置100Aを受信側装置と呼ぶ。例えば、FTP(File Transfer Protocol)サーバである送信側装置(例えばPC)から、アプリケーションプログラムに基づく動作を行なうFTPクライアントたる受信側装置がファイルをダウンロードする場合や、POP(Post Office Protocol)サーバである送信装置から、電子メールを扱うアプリケーションプログラムに基づく動作を行なう受信側装置が電子メールを受信する場合などを想定する。
通信装置100Aは、処理部たるCPU101A、記憶部102A、システムバス103A、および通信部105Aを備える。
通信部105Aは、システムバス103A上に接続されたハードウェアである。この通信部105Aは、CPU101Aによって渡されたデータをネットワーク3Aに送信する機能と、ネットワーク3Aからデータを受信してCPU101Aに渡す機能とを有する。
また、この通信部105Aは、ネットワーク3Aから受信したデータを一時的に保持する受信用FIFOメモリ151Aと、CPU101Aから渡されたデータを一時的に保持する送信用FIFOメモリ152Aとを備える。さらに、通信部105Aは、ネットワーク3Aから受信したデータが受信用FIFOメモリ151Aに収まらず溢れてしまった場合、そのデータロスを検知するデータロス検知部150Aを備える。
なお、データロス検知部150Aは、ロスしたパケットのプロトコルおよびポート番号が、現在通信しているプロトコルおよびポート番号と一致した場合のみに、オーバーランの発生をCPU101Aに通知してもよい。さらに、受信用FIFOメモリ151Aと送信用FIFOメモリ152Aは、送信と受信で共有していても良い。
CPU101Aは、通信部105Aの受信用FIFOメモリ151Aに格納されたデータを記憶部102Aに移動する(読み出し)機能と、記憶部102Aに格納されているデータを通信部105Aの送信用FIFOメモリ152Aに移動する(書き込み)機能をもつ。また、CPU101Aは、記憶部102Aに格納さているデータに対してデータの解析や送信用データの作成処理など、TCPを含むプロトコル処理も行なう。また、CPU101Aは、通信アプリケーションプログラムや、必要に応じてその他のプログラムを、記憶部102Aを使用しながら実行する機能を持つ。
なお、記憶部102Aから通信部105Aの送信用FIFOメモリ152Aまたは通信部105Aの受信用FIFOメモリ151Aから記憶部102Aへのデータの転送において、通信装置100A,200Aは、別途DMAコントローラを具備し、CPUではなく、DMA(Direct Memory Access)コントローラによりデータの移動を行なう場合もある。さらに、各プロトコル処理は、CPU101Aにより実施されるのではなく、別途ハードウェアでそれぞれ実施されてもよい。
図31は、通信装置100AにおけるCPU101Aの機能構成を示す構成図である。
図31に示す機能構成は、図30に示すCPU101A上で動作するソフトウェアとして実現可能である。なお、図31の構成図は、受信側装置として、本発明に係るTCPデータの受信処理を中心として記載されているが、通信装置100Aは、TCPデータの送信処理を行なう機能部を具備していてもよい。また、通信装置200Aは、従来の通信装置であってもよいし、本発明が適用された受信処理の機能部を持つ通信装置であってもよい。以下、各機能部の説明を記述するにあたり、本発明に係る受信処理についてのみ詳細に記述し、送信処理に係る機能および動作の説明は省略する。また、本発明に直接関係のないTCP通信を実現するためのその他の構成についても説明を省略する。
なお、図31においては、データの流れをいくつかの種類の線を用いてあらわしている。実線はパケットまたはデータの流れを示すデータフロー、点線は制御信号(通知またはパラメータ)の流れを示す制御フローである。
図31において、通信装置100AのCPU101Aは、受信または送信するパケットを処理するパケット処理部の詳細な構成として、API部1100、TCP処理部1200、IP処理部1300、IF処理部1400、およびMAC処理部1500を有する。さらに、TCP処理部1200は、受信バッファ1240、Window制御部1250、WinUpdate生成部1260、DupAck生成部1270、Ack生成部1280、TCP送信部1220、TCP受信部1210、TCPロス検知部1215、およびDupAck管理部1230を有する。またさらに、MAC処理部1500は、ロス通知部5000、パケット複製部7000、MAC送信部1520、およびMAC受信部1510を有する。
API部1100は、TCP処理部1200と例えばFTPなどのアプリケーションプログラムとの間のデータの受け渡し、および、その処理完了の通知を行なう。API部1100は、アプリケーションプログラムからの要求に応じて、TCP処理部1200にデータの受け渡しを要求し、TCP処理部1200から渡されたデータを、アプリケーションプログラムが処理できるように必要に応じて変換やコピーを行い、その処理の完了をTCP処理部1200に通知する。
TCP処理部1200は、IP処理部1300から受け取ったTCPパケットを、API部1100に渡すデータに変換する。TCP処理部1200は、IP処理部1300から受け取った一つあるいは複数のTCPパケットに含まれるデータを、TCPパケットから抽出して保持し、API部1100からのデータの受け渡し要求に応じて、該当するデータを渡す。また、TCP処理部1200は、IP処理部1300から受け取ったTCPパケットに対するAckを作成してIP処理部1300に渡す。なお、本実施の形態では、Ackを、上記実施の形態1〜9のACKまたはACKパケットとして説明する。
IP処理部1300は、IF処理部1400から受け取ったIPパケットからTCPパケットを抽出し、TCP処理部1200に渡す。また、IP処理部1300は、TCP処理部1200から受け取ったTCPパケットにIPヘッダを追加してIPパケットを構築し、IF処理部1400に渡す。
IF処理部1400は、MAC処理部1500から受け取ったMACフレームからIPパケットを抽出し、IP処理部1300に渡す。また、IF処理部1400は、IP処理部1300から受け取ったIPパケットにMACヘッダを追加してMACフレームを構築してMAC処理部1500に渡す。
MAC処理部1500は、図30に示す通信部105Aが受け取ったデータをIF処理部1400に渡す。この処理は、図30の通信部105Aの受信用FIFOメモリ151Aから図30の記憶部102Aにデータを渡す(読み出し)処理である。また、MAC処理部1500は、IF処理部1400から受け取ったMACフレームを通信部105Aに渡す。この処理は、図30の記憶部102Aから通信部105Aの送信用FIFOメモリ152Aにデータを渡す(書き込み)処理である。
以下、上記のTCP処理部1200およびMAC処理部1500のさらに詳細な構成について図31を使用して説明する。
TCP処理部1200の受信バッファ1240は、TCP受信部1210から受け取ったデータを管理するバッファ領域である。管理するデータの実態は、図30の記憶部102Aに配置される。受信バッファ1240は、管理するデータをAPI部1100に渡し、渡し終えたデータを保持していたバッファ領域を開放する機能をもつ。また、Window制御部1250からの使用可能なバッファサイズの問い合わせに対し、使用可能なバッファサイズをWindow制御部1250に伝える機能をもつ。
Window制御部1250は、受信バッファ1240に問い合わせて得た使用可能なバッファサイズからWinを算出して保持する。なお、本実施の形態では、Winを、実施の形態1〜9のウィンドウサイズとして説明する。また、Window制御部1250は、DupAck管理部1230およびAck生成部1280からのWinの問い合わせに対し、管理しているWinをそれぞれに渡す。さらに、Window制御部1250は、API部1100からアプリケーション処理の完了の通知を受けると、受信バッファ1240に問い合わせて得た使用可能なバッファサイズからWinを算出し、算出したWinをDupAck管理部1230に渡す。
WinUpdate生成部1260は、DupAck管理部1230よりWinを受け取った場合に、WindowUpdate(受信できるWinが増加したことを送信側装置に通知するAck、以後WinUpdate)を作成してTCP送信部1220に渡す。
DupAck生成部1270は、DupAck管理部1230より受け取ったDupAck情報よりDupAck(Duplicate acknowledgement:即時応答確認)を生成してTCP送信部1220に渡す。なお、DupAck情報は、上記実施の形態1〜9のACK番号たるシーケンスナンバー(以下、Seqという)と、Winとを含む。また、DupAckまたはDupAckパケットは、上記実施の形態1〜9の重複ACKに相当する。
Ack生成部1280は、TCP受信部1210よりSeqを受け取った場合、Window制御部1250に問い合わせて得たWinと、TCP受信部1210より受け取ったSeqとに基づいてAckを作成し、TCP送信部1220に渡す。
なお、本実施の形態では、DupAck生成部1270およびAck生成部1280のそれぞれが、確認応答パケットたるDupAckまたはAckを生成する第1のパケット生成手段として構成されている。
TCP送信部1220は、DupAck管理部1230またはAck生成部1280から受け取ったTCPパケット(DupAckまたはAck)に必要なTCPヘッダ情報を設定して、そのTCPパケットをIP処理部1300に渡す。
TCP受信部1210は、TCPパケットのSeqが順序どおりであるかどうかを調査するTCPロス検知部1215を備える。TCP処理部1200は、IP処理部1300から受け取ったTCPパケットのSeqが順序どおりであった場合(TCPロス検知部1215がTCPパケットのロスを検知しなかった場合)、TCPパケットからデータを抽出する処理を実施し、受信バッファ1240に渡す。また、TCP受信部1210は、Seqが順序通りであった場合に次のSeqをAck生成部1280に渡す。なお、Ack生成部1280へ次のSeqを渡す機能は、毎回発生しなくてもよい。この場合、Ack生成部1280への通知は、複数回に1回の割合で通知されたり、Delayed Ackアルゴリズムにより、システムのタイマから所定時間経過後に行われたりする。
TCPロス検知部1215は、TCP受信部1210が受け取ったTCPパケットのSeqを調査し、Seqが順序通りでなかった場合、期待していたSeqをDupAck管理部1230に渡す。
DupAck管理部1230は、TCPロス検知部1215から受け取ったSeqと、Window制御部1250に問い合わせて得たWinとをDupAck情報として保持する。さらに、DupAck管理部1230は、DupAck情報をDupAck生成部1270に渡し、その渡した回数をDupAck送信数としてカウントする。
また、DupAck管理部1230は、Window制御部1250よりWinを受け取った場合に、ロス通知部5000からのパケットロス情報に基づいて、保持するDupAck送信数から所定数に足りないDupAck複製数を算出する。その結果が1以上の場合は、DupAck管理部1230は、Window制御部1250より受け取ったWinをWinUpdate生成部1260に渡す前に、保持するDupAck情報(SeqおよびWin)をDupAck生成部1270に渡す。そして、DupAck管理部1230は、パケット複製部7000の問い合わせに対し、算出したDupAck複製数を通知する。なお、本実施の形態においては、DupAck管理部1230が算出したDupAck複製数について、パケット単位での管理を例に説明する。
なお、DupAck複製数を、送信するパケット単位ではなく例えば、TCPのコネクション単位や通信装置全体で一つとして管理してもよい。
さらに、DupAck管理部1230は、DupAck複製数をパケット複製部7000に通知すると、パケットロス通知部5000から受け取ったパケットロス情報を消去し、さらにDupAck複製数およびDupAck送信数を初期値にリセットする。DupAck複製数の初期値としては、1を例に説明する。また、DupAck送信数の初期値としては、0を例に説明する。
MAC処理部1500は、MAC受信部1510、MAC送信部1520、およびロス通知部5000を備える。それぞれの詳細な説明を以下に示す。
MAC受信部1510は、図30の通信部105Aの受信用FIFOメモリ151Aから読み出したMACフレーム(P200)をIF処理部1400に渡す。即ち、MAC受信部1510は、図30の受信用FIFOメモリ151Aのデータを、CPU101Aを介して記憶部102Aに移動させようとする。
MAC送信部1520は、パケット複製部7000を備える。MAC送信部1520は、IF処理部1400から受け取ったMACフレームをパケット複製部7000が指示する複製数だけ、図30の通信部105Aの送信用FIFOメモリ152Aに書き込む(P100)。即ち、MAC送信部1520は、図30のCPU101Aから送信用FIFOメモリ152Aへデータを移動させようとする。したがって、MAC送信部1520は、DupAckを複製して送信用FIFOメモリ152Aに書き込む。
パケット複製部7000は、DupAck管理部1230に問い合わせ、問い合わせて得たDupAck複製数(N個)に基づいて、MAC送信部1520に対して、対象となるMACフレームのN回の送信指示を行なう。なお、図30の通信部105AがMACフレームをDupAck複製数(N個)だけ複製して送信する機能をもつ場合には、パケット複製部7000は、対象となるMACフレームのデータの移動は1回として、N回複製して送信する指示のみを行なってもよい。
なお、本実施の形態では、MAC送信部1520とパケット複製部7000とが、データ要求パケットたるDupAckを生成する第2のパケット生成手段として構成されている。
ロス通知部5000は、図30のデータロス検知部150Aからのパケットロス通知(E150)を受け取り、DupAck管理部1230にパケットロス情報を渡す。なお、パケットロス通知(E150)にIPアドレスや、プロトコル、ポート番号が含まれる場合は、ロス通知部5000は、DupAck管理部1230にパケットロス情報としてIPアドレス、プロトコル、およびポート番号も渡す。その結果、DupAck管理部1230は、ロス通知部5000から取得したIPアドレスやポート番号に基づいて、ロスしたパケットの再送を促す相手である送信側装置200Aを特定する。即ち、DupAck管理部1230は装置特定手段を備える。
以下、本実施の形態に係る通信装置間の通信シーケンスについて、通信装置100Aを受信側装置、通信装置200Aを送信側装置として動作させたときを例として図32を用いて説明する。
図32は、本実施の形態における通信装置間の通信シーケンスを示す図である。なお、受信側装置100Aの性能は低い(例えばCPU101Aの性能が133MHz)。また、説明を簡略化するために、1パケット内に格納されるデータ長である1パケット長(LEN)を1KByteにし、SeqやWinの単位や値も、これに合わせている。また、図32は、受信側装置100AのWinが少なくなっている状況を示す。さらに、図32では、送信側装置200Aと受信側装置100AとのTCP接続時のコネクション設立と、受信側装置100AのWinが多い状態から少ない状態(Win=4、図32のW11参照)にいたるまでの通信のシーケンスとを省略する。
図32に示すように、受信側装置100Aは、Seq=1のデータ(P21)の受信に対し、Ack(P12)を送信側装置200Aに送信している。このAckには、次に要求するパケットのシーケンスナンバー(Num=2)と、受信側装置100Aの受信可能なデータ量(Win=3)とがパラメータとして含まれている。Winの値が3(W12)であるのは、Seq=1のデータに対するアプリケーションプログラムでの受信処理が完了しておらず、受信可能なデータ量が減少しているためである。図32の例では、Seq=2のデータ(P22)が、受信側装置100Aの受信処理中でTCP(通信プロトコルのトランスポート層)の処理に至るまでに消失している(パケットの消失が発生している)。そのため、受信側装置100AはSeq=2(P22)に対するAckを返さない。
次に、受信側装置100Aは、Seq=3、4(P23、P24)のデータの受信に対し、Ackを送信側装置に送信する。このAck(P13、P14)は、どちらもパラメータがNum=2およびWin=3となる。これは、受信側装置100Aが、Seq=1のデータの後に、Seq=3およびSeq=4のデータを受信したため、Seq=2のデータが不足していることを検知したためである。受信側装置100Aは、Seq=2のパケットを要求するAckを、Seq=1のパケットの受信時に既に送信している。したがって、このAck(P13、P14)はSeq=2のデータが到達していないことを伝えるDupAckとなる。このとき、これらのDupAck(P13、P14)のWinは、Seq=1のパケットに対するAck(P12)のWinと同じである。これは、Seq=1のデータに対するアプリケーションプログラムの受信処理が完了していないためである。
受信側装置100AのCPU101Aが低速であるため、Seq=1のデータに対するアプリケーションプログラムの受信処理は、受信側装置100Aが2つ目のDupAckを送信した後に完了する。アプリケーションプログラムの受信処理が完了した後に、受信側装置100Aは、送信側装置200AにWinが回復したことを伝えるWinUpdate(Num=2およびWin=4)(P16)を送信する。ここで、受信側装置100Aは、このWinUpdateを送信する直前に、既に送信したDupAck(P14)をコピーして、そのコピーされたDupAck(P15)を送信側装置200Aに送信する。送信側装置200Aは、3つ目のDupAck(P15)を受信し、Seq=2の再送データ(P25)を高速再送する。
図33は、受信側装置100Aにおける処理シーケンスの例を示す図である。具体的に、図33は、受信側装置100AがSeq=1(P21)のデータを受信し、WinUpdate(P16)を送信するまでの処理シーケンスを示す。図33の処理シーケンスと、図30および図31の受信側装置100Aの構成図とを用いて、本実施の形態における受信側装置100Aでの処理を説明する。なお、図33中、点線で囲まれた“通信部”は、図30の通信部105Aを示し、点線で囲まれた“MAC”は、図31のMAC処理部1500を示し、点線で囲まれた“IF”は、図31のIF処理部1400を示し、点線で囲まれた“IP”は、図31のIP処理部1300を示す。さらに、図33中、点線で囲まれた“TCP”は、図31のTCP処理部1200を示し、点線で囲まれた“API”は、図31のAPI部1100を示し、点線で囲まれた“アプリケーション”は、図31のアプリケーションプログラムを示す。
まず、図33の処理フローに従って、受信側装置100AがSeq=1(P21)のパケットを受信してからAck(P12)を送信するまでの処理シーケンス(P21、P211、P121、およびP12)を説明する。
図33に示すように、通信装置(送信側装置)200Aから送信されたSeq=1のパケット(P21)は、ネットワーク3Aを介し通信装置(受信側装置)100Aの通信部105Aによって受信処理される。通信部105Aの受信用FIFOメモリ151Aに格納されたSeq=1のパケット(P21)は、CPU101Aにより、受信用FIFOメモリ151Aから記憶部102Aに読み出される。なお、受信用FIFOメモリ151Aから記憶部102Aへの移動において、別途受信側装置100AにDMAコントローラを具備し、CPU101Aではなく、DMAコントローラによりそのパケットが移動されてもよい。
MAC処理部1500のMAC受信部1510によって通信部105Aの受信用FIFOメモリ151Aより読み出されたSeq=1のMACフレーム(P21)は、IF処理部1400およびIP処理部1300により非パケット化されてTCP受信部1210に渡される(データフローP211)。
TCP受信部1210は、Seq=1のTCPパケットのTCPヘッダの解析処理を行い、非パケット化処理を完了する。このとき、TCPロス検知部1215において、Seq=1のパケット(P21)受信処理前にパケットロスが発生していないので、Seq=1のパケットは順序通りの受信データであると判断され、受信バッファ1240およびDupAck管理部1230に受信データとして渡される。この渡された受信データは、API部1100を通してアプリケーションプログラムに渡されることとなる。
また、TCPロス検知部1215において、順序通りのパケットであることが確認されたので、TCP受信部1210は、当該データを受信したことを送信側装置200Aに通知するため、Ack生成部1280に次のSeqであるSeq=2を渡す。TCP受信部1210からSeqを受け取ったAck生成部1280は、Window制御部1250を介して、受信バッファ1240に現在受信可能なWinを問い合わせる。Ack生成部1280は、問い合わせ結果であるWin=3とTCP受信部1210から受け取ったSeqとを基に、Seq=1のパケット(P21)に対してNum=2およびWin=3を示すTCPパケットを生成し、TCP送信部1220に渡す。
TCP送信部1220は、そのTCPパケットに対してTCPヘッダ構築処理を行い、IP処理部1300およびIF処理部1400は、そのTCPヘッダ構築処理されたTCPパケットに対してパケット構築を行なう。パケット構築されたNum=2およびWin=3を示すMACフレームは、MAC処理部1500のMAC送信部1520によって、パケットとして通信部105Aの送信用FIFOメモリ152Aに書き込まれる(データフローP121)。
このように、通信部105Aの送信用FIFOメモリに書き込まれたデータ(MACフレーム)は、Seq=1のパケット(P21)のAck(P12)としてネットワーク3Aを介して送信側装置200Aへ送信される。
次に、図33の処理フローに沿って、受信側装置100AがSeq=2(P22)を受信してからの処理シーケンス(P22およびE100)を説明する。
通信装置(送信側装置)200Aから送信されたSeq=2のパケット(P22)は、ネットワーク3Aを介し、通信装置(受信側装置)100Aの通信部105Aによって受信処理される。しかし、CPU101Aが低速であるために、通信部105Aの受信用FIFOメモリ151Aにおいて既に受信されたパケットがあふれてしまい、オーバーランが発生する。その結果、Seq=2のパケット(P22)は受信用FIFOメモリ151Aに格納されない。
Seq=2のパケットでオーバーランが発生したため、データロス検知部150AはCPU101Aに対して、オーバーランが発生したことを通知する(制御フローE100)。即ち、ロス通知部5000は、パケットロス通知を受け取り、TCP処理部1200のDupAck管理部1230にパケットロス情報を渡す。DupAck管理部1230は受け取ったパケットロス情報を保持する。
次に、図33の処理フローに沿って、受信側装置100AがSeq=3およびSeq=4のパケット(P23、P24)を受信してからAck(P13、P14)を送信するまでの処理シーケンス(P231、P131、P241、P141)を説明する。P23およびP24のデータに対する処理は、P21のデータに対する処理と同様であるため、ここではそれらの処理の説明を省略する。また、P13およびP14のデータに対する処理は、P12のデータに対する処理と同様であるため、ここではそれらの処理の説明を省略する。
MAC処理部1500のMAC受信部1510によって読み出されたSeq=3のパケット(P23)は、IF処理部1400およびIP処理部1300により非パケット化され、TCP受信部1210に渡される(データフローP231)。TCP受信部1210は、受け取ったTCPパケットのTCPヘッダの解析処理を行い、非パケット化処理を完了する。このとき、Seq=2のパケット(P22)が未だ到着していないため、Seq=3のTCPパケットは、TCPロス検知部1215において、順序通りではない受信データであると判断される。TCPロス検知部1215は順序どおりで届くはずのシーケンスナンバー(Seq=2)をDupAck管理部1230に渡す。
Seq=2を受け取ったDupAck管理部1230は、Window制御部1250を介して、受信バッファ1240に現在受信可能なWinを問い合わせ、Win=3を受け取る。DupAck管理部1230は、TCPロス検知部1215から受け取ったSeq=2と、Window制御部1250に問い合わせて得たWin=3とをDupAck情報として保持し、DupAck情報をDupAck生成部1280に渡す。さらに、DupAck管理部1230は、DupAck送信数を「1」にカウントする。DupAck生成部1280は、受け取ったDupAck情報(WinおよびSeq)より、Num=2およびWin=3を示すDupAckを生成し、生成したDupAckをTCP送信部1220に渡す。
DupAck(Num=2およびWin=3)は、TCP送信部1220からIP処理部1300およびIF処理部1400を経て、パケット構築される(データフローP131)。パケット構築されたパケット(MACフレーム)は、MAC処理部1500のパケット複製部7000に出力される。このとき、パケット複製部7000は、DupAck管理部1230に複製数を問い合わせ、その複製数が「1」であるため、MAC処理部1500に対してパケットの複製を指示しない。その結果、MAC送信部1520は、通信部105Aの送信用FIFOメモリ152Aにパケットを1つだけ書き込む。
データフローP231と同様に、MAC処理部1500のMAC受信部1510によって読み出されたSeq=4のパケット(P24)は、TCP処理部1200のDupAck管理部1230およびDupAck生成部1270にまで至る(データフローP241)。DupAck管理部1230は、現在保持しているDupAck情報のSeq=2と、TCPロス検知部1215から受け取ったSeqとが同一であることを判断し、同一の場合、DupAck管理部1230が管理するDupAckの送信数を2にカウントする。
データフローP131と同様に、DupAck(P14)は、TCP送信部1220からMAC処理部1500のパケット複製部7000に至り、MAC送信部1520によって通信部105AのFIFOメモリ152Aに書き込まれる(データフローP141)。
次に、図33の処理フローに沿って、Seq=1(P21)のデータのアプリケーションプログラムによる処理が完了し、DupAckの複製を開始するまでの処理シーケンス(P212およびP213)を説明する。
送信側装置200Aでは、受信側装置100AからのAck(P12)を受信してからWinの状態(図32に示すW12)が変化していない。W12の状態では、新たに次のパケット(Seq=5)を送信することができない。その間に、受信側装置100Aでは、アプリケーションプログラムからの受信要求により、受信バッファ1240およびDupAck管理部1230がAPI部1100を介してアプリケーションプログラムに受信データを渡す(データフローP212)。
API部1100は、受信データをアプリケーションに渡し終えるとWindow制御部1250へ受信完了したことを通知する(データフローP213)。
次に、図33の処理フローに沿って、DupAckがパケット構築され、MAC処理部1500においてDupAckが複製される処理シーケンス(P151)を説明する。
API部1100から受信完了したという通知を受けたWindow制御部1250は、受信バッファ1240にバッファの空き容量を問い合わせ、得たバッファ空き容量の情報からWin=4を算出する。算出したWinをDupAck管理部1230に渡す。
Winを受け取ったDupAck管理部1230は、制御フローE100において保持していたパケットロス情報に基づき、DupAck送信数「2」と所定の数「3」とを用いてDupAck複製数算出方法によりDupAck複製数を算出する。このときの算出結果は、「1」であり、その値はDupAck管理部1230で保持される。DupAck複製数算出方法については、後で説明する。さらに、DupAck管理部は、保持していたDupAck情報(Seq=2およびWin=3)をDupAck生成部1270に渡す。
DupAck生成部1270は、受け取ったDupAck情報により、DupAck(Num=2およびWin=3)を作成してTCP送信部1220に渡す。
TCP送信部1220に渡されたNum=2およびWin=3を示すTCPパケット(DupAck)は、IP処理部1300およびIF処理部1400を経て、パケット構築される(データフローP151)。パケット構築されたDupAckパケット(MACフレーム)は、MAC処理部1500のパケット複製部7000に出力される。このときパケット複製部7000は、DupAck管理部1230に問い合わせを行なう。パケット複製部7000は、DupAck管理部1230から問い合わせて得たDupAck複製数「1」により、MAC送信部1520に対して、通信部105Aの送信用FIFOメモリ152Aに1つパケットを書き込むように指示する。そして、MAC送信部1520は、1つのDupAckパケットを送信用FIFOメモリ152Aに書き込む。
本実施の形態においては、MAC送信部1520は、DupAck複製数が「1」のため、通信部105Aの送信用FIFOメモリ152Aに1回だけDupAckパケットの書き込みを行ったが、DupAck複製数がN(N≧2)の場合は、同一のものをN回書き込むことにより、N個のDupAckパケットの送信が行なわれる。
通信部105Aの送信用FIFOメモリ152Aに書きこまれたパケットは、通信部105Aよりネットワーク3Aを介して送信側装置200AへDupAckパケット(P15)として送信される。
次に、図33の処理フローに沿って、TCP処理部1200で作成されたWinUpdateがパケット構築され、送信される処理シーケンス(P161、P16)を説明する。
DupAck管理部1230は、Window制御部1250から受け取ったWin=4をWinUpdate生成部1260に渡す。WinUpdate生成部1260は、WinUpdateを作り、TCP送信部1220に渡す。TCP送信部1220に渡されたWinUpdateは、IP処理部1300およびIF処理部1400を経て、パケット構築される(データフローP161)。パケット構築されたWinUpdateパケット(MACフレーム)は、MAC送信部1520から通信部105Aに渡される。
そして、通信部105Aは、そのWinUpdate(P16)を、ネットワーク3Aを介して送信側装置200Aへパケット送信する。
DupAck管理部1230は、複製したDupAckパケット(P15)の送信後、制御フローE100でロス通知部5000から渡されて保持していたパケットロス情報を消去し、DupAck複製数を「1」に初期化する。
さらに、DupAck管理部1230は、パケットロスしたシーケンスのパケットを受信することで、DupAck管理部1230が記憶していたDupAck情報(SeqおよびWin)を消去し、DupAck送信数を「0」にして、DupAck複製数を「0」にする。
なお、パケットロス情報の消去については、DupAck管理部1230がDupAckを複製していない場合でもロス通知部5000からパケットロス情報を受け取ってから所定時間経過後(例えば1秒後)にそのパケットロス情報を消去してもよい。
また、ロス通知部5000からパケットロス情報を受け取ってからPPS(Packet Per
Sec)が低くなった場合に、パケットロス情報の消去を実施してもよい。即ち、DupAck管理部1230はリセット手段を備える。
さらに、ロス通知部5000からパケットロス情報を受け取ってから送信したパケット数をパケット複製部7000が管理しておき、特定のパケット数が送信された場合に、パケットロス情報の消去を実施してもよい。
ここで、本実施の形態におけるTCP処理部1200のDupAck管理部1230によるDupAck複製数算出方法のアルゴリズムについて図34を用いて説明する。
図34は、本実施の形態におけるDupAck複製数算出方法のアルゴリズムを示すフローチャートである。
DupAck管理部1230は、Window制御部1250からWin更新の通知を受けると、保持しているDupAck送信数が1以上でかつN未満かどうかを調査する(ステップS100)。さらに、DupAck管理部1230は、ロス通知部5000によるロス通知が行われ、パケットロス情報が記録されているか否かを調査する(ステップS102)。
即ち、ステップS100において、DupAck管理部1230は、自分が管理するDupAck送信数が0以下または(N+1)以上の場合は(ステップS100のN)、DupAck複製数を「0」とする(ステップS104)。一方、保持しているDupAck送信数が1以上でかつN未満の場合は(ステップS100のY)、DupAck管理部1230はステップS102の処理を実行する。なお、Nは、送信側装置に対して再送を実行させるのに必要なDupAckの数(所定数または必要数)である。
ステップS102において、ロス通知部5000からのパケットロス情報が記録されていた場合は(ステップS102のY)、DupAck管理部1230は、DupAck複製数を式「N−DupAck送信数」で算出する(ステップS106)。一方、パケットロス情報が記録されていない場合は(ステップS102のN)、DupAck管理部1230は、DupAck複製数を「0」とする(ステップS104)。
例えば、本実施の形態では、上述のDupAck複製数算出方法のアルゴリズムの開始時において、DupAck管理部1230は、DupAck送信数「2」とロス通知部5000からパケットロス情報を受け取り保持(記録)している。したがって、ステップS100では、DupAck送信数が「2」であるため、DupAck管理部1230は、ステップS102の処理を実行する。そして、ステップS102では、DupAck管理部1230は、パケットロス情報を保持しているため、DupAck複製数をN=3およびDupAck送信数「2」より算出する。よって、「DupAck複製数=N−DupAck送信数」よりDupAck複製数は「1」になる。
なお、上記Nは送信側装置200Aが高速再送を発動する数であることが望ましい。また、本実施の形態では、Nを一例として3としているが、DupAckのネットワークでのパケットロスを回避する条件ということで、3以上としてもよい。大きい値は特に、ネットワークの品質が悪く、経路上でDupAckが消失しやすい場合に有効である。ただし、この値が大きいということは、ネットワークのトラヒックを増やすことに繋がるため、無用に大きくすることは好ましくない。望ましくは3、大きくても4が好ましい。
このように本実施の形態では、以上の処理を行なうことで、送信側装置200Aに高速再送を発動させTCPの再送によるスループット低下を押さえる効果と、受信側装置100A内でのパケットロスである場合にのみ送信側装置200Aの高速再送を発動させる効果と、ネットワークを過負荷状態にしない効果と、複製するDupAckによる無駄なトラフィックを抑える効果と、DupAck送信に要する受信側装置100AのCPUの消費を抑える効果と、誤ったDupAckを送信しない効果とがある。
(変形例1)
ここで上記実施の形態10における第1の変形例について説明する。
上記実施の形態10では、受信側装置100Aは通信部105Aにおけるデータロスを検知したが、本変形例に係る受信側装置100AはIP処理部1300におけるデータロスを検知する。
なお、本変形例について、上記実施の形態10に共通していない部分に関してのみ説明する。
図35は、上記実施の形態10における第1の変形例のネットワーク構成例および通信装置の構成例を示す図である。
通信部105Aは、システムバス103A上に接続されたハードウェアであって、上記実施の形態10の通信部105Aのようにデータロス検知部150Aを備えていない。この通信部105Aは、CPU101Aによって渡されたデータをネットワーク3Aに送信する機能と、ネットワーク3Aから受信したデータを受信する機能とを有する。また、通信部105Aは、ネットワーク3Aから受信したデータを一時的に保持する受信用FIFOメモリ151Aと、CPU101Aから渡されたデータを一時的に保持する送信用FIFOメモリ152Aとを備える。
本変形例に係るCPU101Aのプログラムによって実現される機能構成について図36を用いて説明する。
図36は、受信側装置100AにおけるCPU101Aの機能構成を示す構成図である。なお図36中、実線はデータの流れを示すデータフロー、点線は制御信号の流れを示す制御フローである。受信側装置100Aの受信または送信するパケットを処理するパケット処理部の詳細な構成として、受信側装置100AのCPU101Aは、API部1100、TCP処理部1200、IP処理部1300、およびMAC処理部1500を備える。図36の各機能部の説明を以下に示す。API部1100およびTCP処理部1200に関しては、上記実施の形態10の機能と全く同様であるため説明を省略する。
本変形例に係るMAC処理部1500は、上記実施の形態10におけるMAC処理部1500と異なりロス通知部5000を備えず、MAC受信部1510およびMAC送信部1520のみを備える。このMAC受信部1510およびMAC送信部1520は、上記実施の形態10と同様の機能を有する。
IP処理部1300は、上記実施の形態10のIP処理部1300と同様に、IF処理部1400から受け取ったIPパケットからTCPパケットを抽出し、TCP処理部1200に受け渡す。また、IP処理部1300は、TCP処理部1200から受け取ったTCPパケットにIPヘッダを追加してIPパケットを構築してIF処理部1400に渡す。このようなIP処理部1300は、上記実施の形態10のIP処理部1300と異なり、受信用FIFOキュー1310とデータロス検知部150Aとロス通知部5000とを備える。
受信用FIFOキュー1310は、IF処理部1400から渡されるデータを一時的に格納する領域である。この領域には、記憶部102Aの領域のうちの一部が割り当てられ、受信用FIFOキュー1310は、その領域に格納されるデータを管理する機能をもつ。即ち、受信用FIFOキュー1310は、IF処理部1400から受け取ったデータを受け取った順番にIP処理部1300に処理させる(First-In First-Out)ように管理している。
データロス検知部150Aは、受信用FIFOキュー1310において受信オーバーランが発生したことを検知し、ロスが発生したことをロス通知部5000にパケットロス通知(E150)を通知する。
ロス通知部5000は、データロス検知部150Aからパケットロス通知(E150)を受け取り、ロスが発生したことを通知するパケットロス情報を、TCP処理部1200のDupAck管理部1230に渡す。なお、パケットロス通知(E150)にIPアドレス、プロトコルやポート番号を含む場合は、ロス通知部5000は、IPアドレス、プロトコルおよびポート番号を含むパケットロス情報をDupAck管理部1230に渡す。
図37は、本変形例に係る受信側装置100Aにおける処理シーケンスの例を示す図である。即ち、この図37は、受信側装置100AがSeq=1(P21)のパケットを受信し、WinUpdate(P16)を送信するまでの処理シーケンスを示す。なお、図37中、点線で囲まれた“通信部”は、図35の通信部105Aを示し、点線で囲まれた“MAC”は、図36のMAC処理部1500を示し、点線で囲まれた“IF”は、図36のIF処理部1400を示し、点線で囲まれた“IP”は、図36のIP処理部1300を示す。さらに図37中、点線で囲まれた“TCP”は、図36のTCP処理部1200を示し、点線で囲まれた“API”は、図36のAPI部1100を示し、点線で囲まれた“アプリケーション”は、図36のアプリケーションプログラムを示す。
この図37に示す処理シーケンスは、図33に示す処理シーケンスと比べて、Seq=2のパケット(P22)に対する受信側装置100Aでのパケットロス検知の受信処理シーケンスのみが異なる。以下、この受信処理シーケンスに関してのみ説明する。
図37の処理フローに沿って、受信側装置100AによるSeq=2(P22)のパケットに対する処理シーケンス(P22、P221、E150)を説明する。
通信装置(送信側装置)200Aから送信されたSeq=2のパケット(P22)は、ネットワーク3Aを介し通信装置(受信側装置)100Aの通信部105Aにより受信処理される。
MAC処理部1500のMAC受信部1510は、通信部105Aの受信用FIFOメモリ151Aより読み出されたパケット(P22)を受け取る。読み出されたSeq=2のパケット(P22)は、IF処理部1400を介して、IP処理部1300の受信用FIFOキュー1310に渡される(データフローP221)。
ここで、IF処理部1400からIP処理部1300の受信用FIFOキュー1310にIPパケットを渡す処理の速度または量が、IP処理部1300においてIPパケットからTCPパケットを抽出してそのTCPパケットをTCP処理部1200に渡す処理の速度または量をこえてしまい、受信用FIFOキュー1310においてオーバーランが発生する。データロス検知部150Aは、ロス通知部5000にロスが発生したことを通知する(E150)。ロス通知部5000は、受信用FIFOキュー1310におけるオーバーランが発生したというパケットロス通知を受け、TCP処理部1200のDupAck管理部1230にパケットロス情報を渡す。
なお、本変形例では、IP処理部1300に受信用FIFOキュー1310があるとして説明を行ったが、IF処理部1400に同様の受信用FIFOキューを持つときには、IF処理部1400にデータロス検知部およびロス通知部を設けてもよい。また、ロスしたデータを調査し、特定のプロトコル(例えば、IPv4、IPv6)であった場合のみに通知しても良い。
また、データロス検知部150Aにおいて、ロスしたデータを調査し、特定のプロトコル(例えばTCP)であった場合にのみ、そのロスを通知してもよい。
さらに、データロス検知部150Aにおいて、ロスしたデータのアドレスや、ポート番号をパケットロス通知に付加してもよい。また、DupAck管理部1230において、受け取ったIPアドレスや、ポート番号に基づいて、ロスの判定をしてもよい。
このように本変形例では、以上の処理を行なうことで、送信側装置200Aに高速再送を発動させTCPの再送によるスループット低下を押さえる効果と、受信側装置100A内での特定のTCPパケットのパケットロスである場合にのみ送信側装置200Aの高速再送を発動させる効果と、ネットワークを過負荷状態にしない効果と、複製するDupAckによる無駄なトラフィックを抑える効果と、誤ったDupAckを送信しない効果とがある。
(変形例2)
ここで上記実施の形態10における第2の変形例について説明する。
上記実施の形態10では、MAC処理部1500でDupAckを複製したが、本変形例では、TCP処理部1200でDupAckを複製する。
以下、本変形例について、上記実施の形態10に共通していない部分に関してのみ説明する。
図38は、上記実施の形態10における第2の変形例に係るCPU101Aの機能構成を示す構成図である。実線はデータの流れを示すデータフロー、点線は制御信号の流れを示す制御フローである。受信側装置100Aの受信または送信するパケットを処理するパケット処理部の詳細な構成として、受信側装置100AのCPU101Aは、API部1100、TCP処理部1200、IP処理部1300、およびMAC処理部1500を備える。図38の各機能部の説明を以下に示す。なお、API部1100、IP処理部1300、およびIF処理部1400に関しては、上記実施の形態10の機能と全く同様であるため説明を省略する。
本変形例に係るTCP処理部1200は、パケット複製部7000を備えたTCP送信部1220に特徴がある。
TCP送信部1220は、Ack生成部1280、WinUpdate生成部1260、およびDupAck生成部1270から受け取ったTCPパケット(Ack、WinUpdate、およびDupAck)に、必要なTCPヘッダ情報を設定し、そのTCPヘッダ情報が設定されたTCPパケットをIP処理部1300に渡す。また、TCP送信部1220は、パケット複製部7000が複製したDupAckをIP処理部1300に渡す。
パケット複製部7000は、DupAck管理部1230に問い合わせて得たDupAck複製数に基づいて、そのDupAck複製数だけDupAckを複製し、複製したDupAckをIP処理部1300に渡すように、TCP送信部1220に対して指示する。
なお、本変形例では、このパケット複製部7000が、DupAckをデータ要求パケットとして生成する第2のパケット生成手段として構成されている。
MAC処理部1500は、上記実施の形態10におけるMAC処理部1500と異なり、パケット複製部7000を備えていない。MAC受信部1510、MAC送信部1520、およびロス通知部5000は、上記実施の形態10と同様の機能を有する。
ここで、図33に示す処理シーケンスを用いて、本変形例における受信側装置100Aでの処理を説明する。なお、本変形例では、図33中、点線で囲まれた“通信部”は、図30の通信部105Aを示し、点線で囲まれた“MAC”は、図38のMAC処理部1500を示し、点線で囲まれた“IF”は、図38のIF処理部1400を示し、点線で囲まれた“IP”は、図38のIP処理部1300を示す。さらに、図33中、点線で囲まれた“TCP”は、図38のTCP処理部1200を示し、点線で囲まれた“API”は、図38のAPI部1100を示し、点線で囲まれた“アプリケーション”は、図38のアプリケーションプログラムを示す。
本変形例では、図33に示すSeq=2のDupAckパケット(P15)の複製(データフローP151)に特徴があり、この点に関してのみ説明する。
受信完了通知を受けたWindow制御部1250は、受信バッファ1240にバッファの空き容量を問い合わせ、問い合わせ結果からWin=4を算出する。そしてWindow制御部1250は、算出したWinをDupAck管理部1230に通知する。Winを受け取ったDupAck管理部1230は、制御フローE100におけるパケットロス情報を保持しているため、DupAck送信数の「2」と所定の数である「3」からDupAck複製数を所定の方法(図34に示すDupAck複製数算出方法)により算出する。算出したDupAck複製数は「1」であるため、DupAck管理部1230は、保持していたDupAck情報(Seq=2およびWin=3)をDupAck生成部1270に渡し、算出したDupAck複製数を保持する。DupAck管理部1230は、DupAck情報をDupAck生成部に渡した後に、Window制御部1250から受け取ったWin=4をWinUpdate生成部1260に渡す。DupAck生成部1270は、受け取ったDupAck情報よりDupAck(Num=2およびWin=3)を作成してTCP送信部1220のパケット複製部7000に渡す。
パケット複製部7000は、DupAck生成部1270より受け取ったDupAckを、DupAck管理部1230より問い合わせて得たDupAck複製数だけ複製してTCP送信部1220に送信させる。上述の例では、DupAck複製数は「1」であるため、パケット複製部7000は、受け取ったDupAckを複製せずにその1つのDupAckをTCP送信部1220に送信するように指示する。ただし、DupAck複製数がN(≧2)である場合は、パケット複製部7000は、DupAckを複製してDupAckの数を合計N個にし、TCP送信部1220に対して、複製したDupAck(複製元のDupAckを含む)をすべて送信するように指示する。
TCP送信部1220は、パケット複製部7000に送信するように指示されたDupAckをIP処理部1300に渡す。そしてDupAckは、IF処理部1400を経て、パケット構築され、MAC処理部1500のMAC送信部1520により通信部105AのFIFOメモリ152Aに書き込まれる。
このように本変形例では、以上の処理を行なうことにより、パケット数などをTCPで管理している場合に複製するDupAckの数を管理しやすくなる。さらに、既存の通信モジュールにパケット複製部を導入する場合にTCP処理部内で改修をすることとなり、改修箇所を限定することができる。
(変形例3)
ここで上記実施の形態10における第3の変形例について説明する。
上記実施の形態10では、受信側装置100Aは、Windowの状態に基づくタイミングでDupAckを複製して送信したが、本変形例に係る受信側装置100Aは、Windowの状態に変わらずに1回目のDupAckの送信のタイミングでそのDupAckを複製して送信する。
以下、本変形例について、上記実施の形態10に共通していない部分に関してのみ説明する。
本変形例に係るTCP処理部1200は、DupAck管理部1230に特徴がある。
DupAck管理部1230は、TCPロス検知部1215から受け取ったSeqを受け取った場合に、その受け取ったSeqと、Window制御部1250に問い合わせて得たWinとをDupAck情報とし、そのDupAck情報からDupAck複製数を算出して保持する。さらに、DupAck管理部1230は、DupAck情報をDupAck生成部1270に渡し、その渡した回数をDupAck送信数としてカウントする。
DupAck管理部1230は、パケット複製部7000の問い合わせに対して算出したDupAck複製数を通知する。なお、本変形例においては、DupAck管理部1230が算出したDupAck複製数については、パケット単位での管理を例に説明する。
さらに、DupAck管理部1230は、DupAck複製数をパケット複製部7000に通知すると、パケットロス通知部5000から受け取ったパケットロス情報を消去し、さらにDupAck複製数を初期値する機能を持つ。DupAck複製数の初期値としては、「1」を例に説明する。また、DupAck送信数の初期値としては、「0」を例に説明する。
図39は、本変形例に係る通信装置間の通信シーケンスを示す図である。なお、上記実施の形態10と同様、この通信シーケンスは、受信側装置100Aの性能が低い(例えばCPUの性能が133MHz)場合のシーケンス例を示す。
受信側装置100Aは、Seq=3のデータの受信に対し、Ackを送信側装置200Aに送信する。このAck(P13)のパラメータは、Num=2およびWin=3を示す。これは、受信側装置100Aが、Seq=1のデータの後に、Seq=3のデータを受信したため、Seq=2のデータが不足していることを検知したためである。Seq=2を要求するAckは、Seq=1の受信時に既に送信されており、このAck(P13)はSeq=2のデータが到達していないことを伝えるDupAckとなる。このDupAck(P13)のWinは、Seq=1に対するAck(P12)のWinと同じである。これは、Seq=1のデータに対するアプリケーションプログラムでの受信処理が完了していないためである。
本変形例に係る受信側装置100Aは、1回目のDupAckを送信したとき、Seq=2のデータが到達していないと検知しているため、前回送信したDupAck(P13)を複製したDupAck(P14)を送信側装置200Aへ送信する。
そして、受信側装置100Aは、Seq=4のデータの受信に対し、Seq=3のデータを受信した場合と同様に、Seq=2を要求するDupAck(P15)を送信側装置200Aへ送信する。送信側装置200Aは、DupAckを3つ(P13、P14、P15)を受信したため、Seq=2の再送データ(P25)を高速再送する。
図40は、受信側装置100Aにおける処理シーケンスの例を示す図である。具体的に、図40は、受信側装置100AがSeq=1(P21)のデータを受信し、3つめのDupAck(P15)を送信するまでの処理シーケンスの例を示す。
以下、図40の処理フローに沿って、受信側装置100AがSeq=3のパケット(P23)を受信してからAck(P15)を送信するまでの処理シーケンス(P231、P131、P13、P14、P241、およびP141)を説明する。なお、図40中、点線で囲まれた“通信部”は、図30の通信部105Aを示し、点線で囲まれた“MAC”は、図31のMAC処理部1500を示し、点線で囲まれた“IF”は、図31のIF処理部1400を示す。さらに、図40中、点線で囲まれた“IP”は、図31のIP処理部1300を示し、点線で囲まれた“TCP”は、図31のTCP処理部1200を示し、点線で囲まれた“API”は、図31のAPI部1100を示し、点線で囲まれた“アプリケーション”は、図31のアプリケーションプログラムを示す。
MAC処理部1500のMAC受信部1510は、通信部105Aの受信用FIFOメモリ151Aより読み出されたデータ(MACフレーム)(P23)を受け取る。読み出されたSeq=3のデータ(MACフレーム)は、IF処理部1400およびIP処理部1300により非パケット化処理され、TCP受信部1210にTCPパケットとして渡される(データフローP231)。
TCP受信部1210は、Seq=3のTCPパケットのTCPヘッダの解析処理を行い、非パケット化処理を完了する。このときSeq=3のTCPパケットは、TCPロス検知部1215において、Seq=2のデータが到着していないため、順序通りではないデータであると判断される。TCP受信部1210は、Seq=3のデータを受信バッファ1240に渡し、TCPロス検知部1215は順序どおりで届くはずのシーケンスナンバー(Seq=2)をDupAck管理部1230に渡す。受信バッファ1240は、順序通りに到着しなかったデータを、その順序通りのデータが到着するまで保持するように管理する。
DupAck管理部1230は、受け取ったSeq(Seq=2)と、Window制御部1250を介して、受信バッファ1240に現在受信可能なWinを問い合わせた結果のWin(Win=3)とをDupAck情報として、DupAck生成部1270に渡し、DupAck送信数を「1」にカウントする。DupAck生成部1270は、受け取ったDupAck情報よりDupAck(Num=2およびWin=3)を作成してTCP送信部1220に渡す。
さらに、DupAck管理部1230は、制御フローE100において、ロス通知部5000から受け取ったパケットロス情報を保持しているため、このときに、DupAckの複製数をDupAck複製数算出方法により算出する。本変形例に係るDupAck複製数算出方法では、Win=3、MSS=1、および所定の数=3より、DupAck複製数は「2」として算出される(本変形例に係るDupAck複製数算出方法の詳細については後述する)。
なお、DupAck管理部1230は、1つめのDupAck作成時にSeqとWinを保持しておき、DupAck作成から再送によるTimeOutの経過前までの所定の時間が経過した後に、SeqとWinをDupAck生成部1270に渡し、DupAckの足りない分(複製数)の複製数を算出してもよい。
なお、DupAck管理部1230は、1つめのDupAck作成時にSeqとWinを保持しておき、DupAck作成から再送によるTimeOutの経過前までにCPUの使用率が所定の閾値以下になったときに、SeqとWinをDupAck生成部1270に渡し、DupAckの足りない分(複製数)の複製数を算出してもよい。
次に、TCP送信部1220はDupAckを出力し、そのDupAckは、IP処理部1300およびIF処理部1400を経て、パケット構築される(データフローP131)。MAC送信部1520のパケット複製部7000は、DupAck管理部1230から問い合わせて得たDupAck複製数の「2」により、IF処理部1400から受け取ったMACフレームをMAC送信部1520に2つ分送信するように指示する。MAC送信部1520は、受け取ったMACフレームを複製して、2つのMACフレームを通信部105Aの送信用FIFOメモリ152Aに書き込む。
通信部105Aの送信用FIFOメモリ152Aに書き込まれた2つのDupAck(MACフレームP13,P14)はネットワーク3Aを介して送信側装置200Aへ送信される。
DupAck管理部1230は、パケット(P14)を送信した直後に、ロス通知部5000から受け取ったパケットロス情報を消去する。さらに、DupAck複製数を「1」に初期化する。
次に、MAC処理部1500のMAC受信部1510は、通信部105Aの受信用FIFOメモリ151Aより読み出されたパケット(MACフレーム(P24))を受け取る。読み出されたSeq=4のパケット(MACフレーム)は、IF処理部1400およびIP処理部1300により非パケット化処理され、TCP受信部1210にTCPパケットとして渡される(データフローP241)。
TCP受信部1210は、Seq=3のTCPパケットのTCPヘッダの解析処理を行い、非パケット化処理を完了する。このときSeq=3のデータは、TCPロス検知部1215において、Seq=2データが到着していないため、順序通りではないデータであると判断される。TCP受信部1210は、Seq=3のデータを受信バッファ1240に渡し、TCPロス検知部1215は順序どおりで届くはずのシーケンスナンバー(Seq=2)をDupAck管理部1230に渡す。受信バッファ1240は、順序通りに到着しなかったデータを、その順序通りのデータが到着するまで保持するように管理する。
DupAck管理部1230は、Window制御部1250を介して、受信バッファ1240に現在受信可能なWinを問い合わせ、問い合わせて得たWinと、TCPロス検知部1215より受け取ったSeqとをDupAck情報として保持する。DupAck管理部1230は、DupAck生成部1270にDupAck情報を渡す。DupAck生成部1270は、受け取ったDupAck情報(Seq=2およびWin=3)から、Num=2およびWin=3を示すパケット(P15)を生成し、生成したDupAckをTCP送信部1220に渡す。このとき、DupAck管理部1230は、ロス通知部5000からのパケットロス情報を受け取っていないため、DupAck複製数を算出しない。DupAck複製数は「1」のままである。
次に、TCP送信部1220はDupAckを出力し、そのDupAckは、IP処理部1300およびIF処理部1400を経て、パケット構築される(データフローP141)。パケット構築されたDupAck(MACフレーム)は、MAC処理部1500のMAC送信部1520に取得される。このときパケット複製部7000は、DupAck管理部1230にDupAck複製数を問い合わせて、複製数が「1」であることを把握する。複製数が「1」であることにより、MAC送信部1520は、MACフレームを通信部105Aの送信用FIFOメモリ152Aに1つだけ書き込む。
MAC送信部1520により通信部105Aの送信用FIFOメモリ151Aに書き込まれたMACフレームは、ネットワーク3Aを介して送信側装置200Aへとパケットとして送信される。これが、3つ目のDupAckとなり、送信側装置200Aは高速再送を発動する。
図41は、本変形例におけるTCP処理部1200のDupAck管理部1230によるDupAck複製数算出方法のアルゴリズムを示すフローチャートである。
DupAck管理部1230は、TCPロス検知部1215からSeqを受けると、Window制御部1250から問い合わせて得たWinを、MSS(Max Section Size)で除算した商(Win/MSS)から「2」を減算した結果が、所定の数(高速再送に必要とされるDupAckの数「N」であって、例えばN=3)未満かどうかを調査する(ステップS200)。なお、上述のMSSは、送信側装置200Aが1回に送信可能な最大のデータ長であって、本変形例では例えば「1」である。
さらに、DupAck管理部1230は、ロス通知部5000により受け取ったパケットロス情報が記録されているか否かを調査する(ステップS202)。
即ち、ステップS200において、DupAck管理部1230は、WinをMSSで除算した商(Win/MSS)から「2」を減算した結果が、所定の数「N」以上の場合は(ステップS200のN)、DupAck複製数を「1」とする(ステップS204)。一方、WinをMSSで除算した商(Win/MSS)から「2」を減算した結果が、所定の数「N」未満の場合は(ステップS200のY)、DupAck管理部1230はステップS202の処理を実行する。
ステップS202において、ロス通知部5000からのパケットロス情報が記録されていた場合は(ステップS202のY)、DupAck管理部1230は、DupAck複製数を式「DupAck複製数=N−{(Win/MSS)−2}」により算出する。一方、パケットロス情報が記録されていない場合は(ステップS202のN)、DupAck管理部1230は、DupAck複製数を「1」とする(ステップS204)。
具体的に、本変形例では、DupAck管理部1230は、まず、Window制御部1250からWin=3を得る。また、MSSは例えば「1」であって、ロス通知部5000からのパケットロス情報が記録されている。
このような場合、DupAck管理部1230は、ステップS200において、((Win/MSS)−2=3/1−2=1)<(N=3)であるため、ステップS202の処理を行う。
そして、ステップS202において、DupAck管理部1230は、パケットロス情報が記録されていると判断して、ステップS206においてDupAck複製数=3−{(3/1)−2}=2を算出する。
なお、DupAck管理部1230は、ステップS206において、DupAck複製数を所定の数「N」として算出してもよい。
このように本変形例では、以上の処理を行なうことで、送信側装置200Aに高速再送を最も速く発動させTCPの再送によるスループット低下を押さえる効果と、受信側装置100A内でのパケットロスである場合にのみ送信側装置200Aの高速再送を発動させる効果と、ネットワークを過負荷状態にしない効果と、複製するDupAckによる無駄なトラフィックを抑える効果と、DupAckの送信に要する受信側装置100AのCPUの消費を抑える効果と、誤ったDupAckを送信しないという効果とがある。
以上のように、本発明について実施の形態1〜10およびその変形例を用いて説明したが、ブロック図(図8、図30および図35など)の各機能ブロックは典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されても良いし、一部又は全てを含むように1チップ化されても良い(例えばメモリ以外の機能ブロックが1チップ化されていても良い。)。
ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用しても良い。
さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適応等が可能性としてありえる。
また、各機能ブロックのうち、符号化または復号化の対象となるデータを格納する手段だけ1チップ化せずに別構成としても良い。