JP5049834B2 - データ受信装置、データ受信方法およびデータ処理プログラム - Google Patents

データ受信装置、データ受信方法およびデータ処理プログラム Download PDF

Info

Publication number
JP5049834B2
JP5049834B2 JP2008081097A JP2008081097A JP5049834B2 JP 5049834 B2 JP5049834 B2 JP 5049834B2 JP 2008081097 A JP2008081097 A JP 2008081097A JP 2008081097 A JP2008081097 A JP 2008081097A JP 5049834 B2 JP5049834 B2 JP 5049834B2
Authority
JP
Japan
Prior art keywords
data
sequence number
buffer area
destination
number range
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.)
Active
Application number
JP2008081097A
Other languages
English (en)
Other versions
JP2009237768A (ja
Inventor
中 信 吾 田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2008081097A priority Critical patent/JP5049834B2/ja
Priority to US12/404,616 priority patent/US9071525B2/en
Priority to CN2009101324365A priority patent/CN101547153B/zh
Publication of JP2009237768A publication Critical patent/JP2009237768A/ja
Application granted granted Critical
Publication of JP5049834B2 publication Critical patent/JP5049834B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9084—Reactions to storage capacity overflow
    • H04L49/9089—Reactions to storage capacity overflow replacing packets in a storage arrangement, e.g. pushout
    • H04L49/9094—Arrangements for simultaneous transmit and receive, e.g. simultaneous reading/writing from/to the storage element

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Description

本発明は、ネットワークを介して所定のプロトコルにて伝送されるデータを受信するデータ受信装置、データ受信方法およびデータ処理プログラムに関する。
インターネット通信で使われている主要なプロトコルとしてＴＣＰ／ＩＰがある。従来のＴＣＰ／ＩＰは主にソフトウェア処理によって実現されており、たとえばパソコンや組み込み機器などのＣＰＵによって動作する。このような場合、ネットワークからのデータはＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｆａｃｅ Ｃａｒｄ）を用いて受信され、受信されたフレームはＮＩＣ自身またはＣＰＵによって一旦メモリのスタックバッファに書き込まれ、その後にＣＰＵのプロトコルスタックソフトウェアによってプロトコル処理が行われる。通常ＣＰＵではプロトコル処理のほかにアプリケーション処理も実行しており、プロトコル処理が行われた後にアプリケーションが指定したアプリケーションバッファにデータがコピーされる。格納されたデータはアプリケーションなどにとって読み出される。このデータの流れを図示すると図31のようになる。
しかしながら、この方法では受信したデータがＮＩＣからアプリケーションバッファに移動するまでに途中で一旦バッファリングされることになり、データがメモリ上を合計２往復することになる。そこで、米国公開公報2004-0078462号ではプロトコル処理の一部をＮＩＣで行うことで、ＮＩＣがアプリケーションバッファにダイレクトにデータを書き込む方式が開示されている。この場合のデータの流れを図示すると図32のようになる。こうすることによりデータの流れはメモリ上を１往復するだけになるので、データのコピーによる性能面・消費電力面でのオーバーヘッドを回避することができる。
米国公開公報2004-0078462号
しかしながら、米国公開公報2004-0078462号をそのまま用いると次のような問題が発生する。
（１）アプリケーション問題
通常のアプリケーションプログラムはソケットＡＰＩを用いて行われることが多い。その場合、例えばselect()関数でデータが受信されるのを待ち、受信を確認するとrecv()関数をコールするという手法がしばしば用いられる。アプリケーションバッファのアドレスはアプリケーションが指定し、プロトコル処理部はその通知されたアドレスにデータを書き込むが、ここではアプリケーションがrecv()関数でそのアドレスを通知する。よって、このようなアプリケーションに対応する場合、アプリケーションバッファが指定されていない状態、すなわち存在しない状態でデータを受信することを強いられるので、データを途中で一旦バッファせざるを得なくなる。
（２）性能問題
recv()で受信を待つとしても、データ受信後にrecv()コールが戻り、次のrecv()コールが呼ばれるまでアプリケーションバッファがないのでデータが受信できなくなり、図33のようにデータの受信が断続的になり、性能が低下する。
（３）ウィンドウサイズ通知問題
米国公開公報2004-0078462号では受信ウィンドウサイズをアプリケーションバッファのサイズとして相手に通知する方式が述べられているが、実際は以下のようにそれより大きいサイズを通知しなければならない。
・ウィンドウスケールオプションを使用すると、通知するウィンドウサイズを2n乗（n >= 1）の倍数で指定しなければならないので、アプリケーションバッファより大きいサイズで通知せざるを得ない。
・TCPのSilly Window Syndrome回避アルゴリズムにより、送信側は受信ウィンドウサイズがMSS（Maximum Segment Size）以下になるとデータ送信を控えるため、ウィンドウサイズは少なくともMSS分大きく通知する必要がある。
ウィンドウサイズを大きめに通知すると、相手はアプリケーションバッファサイズ以上のデータを送信してくる場合がある。アプリケーションバッファからはみ出たデータはバッファリングしておかないと、次のアプリケーションバッファが指定されたときに、送信側に再送をしてもらわなければならない。TCPの送信側では再送を行うと輻輳ウィンドウサイズを小さくし、スループットを大幅に低下させてしまう。よって、この再送を防ぐには、はみ出たデータを何らかの方法でバッファしておかなければならない。
このように、米国公開公報2004-0078462号を用いると（１）〜（３）の少なくともいずれかの問題が発生する。これらの問題を回避するためにはデータのバッファリングをしたいが、米国公開公報2004-0078462号ではその方法が開示されていない。
つまり、最初に述べた従来のソフトウェア方式を適用するとバッファリングを行うため（１）〜（３）の問題は発生しないが、常にコピーによるオーバーヘッドが発生してしまう。コピーによるオーバーヘッドを回避するために米国公開公報2004-0078462号を用いると、今度は（１）〜（３）の問題が発生する。
本発明は、このような問題を鑑みたものであり、ネットワークを介したデータ受信を低消費電力かつ高スループットで行うことを可能としたデータ受信装置、データ受信方法、およびデータ処理プログラムを提供することを目的とする。
本発明の一態様としてのデータ受信装置は、
各々シーケンス番号が対応付けられた一連のデータからなる受信データ列をネットワークを介して順次受信するデータ列受信手段と、
データを記憶するデータ記憶手段と、
前記データ記憶手段において、前記受信データ列に含まれるデータを一時的に格納するための一時バッファ領域を指定する一時バッファ領域指定手段と、
前記データ記憶手段において、前記受信データ列に含まれるデータを格納するための宛先バッファ領域を複数回指定する宛先バッファ領域指定手段と、
前記宛先バッファ領域指定手段により前記宛先バッファ領域が指定されたとき、指定された宛先バッファ領域のサイズに応じた宛先シーケンス番号範囲を、前回特定した宛先シーケンス番号範囲に後続するように特定し、特定された前記宛先シーケンス番号範囲に含まれる各シーケンス番号は、前記指定された宛先バッファ領域において、前記特定された宛先シーケンス番号範囲内での相対位置に応じた領域に割り当てられる、宛先シーケンス番号範囲特定手段と、
前記データ列受信手段により前記受信データ列が受信されたとき、前記受信データ列に含まれる各データのうち、前記宛先シーケンス番号範囲特定手段により特定された各前記宛先シーケンス番号範囲のいずれかに含まれるデータは、当該データのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込み、各前記宛先シーケンス番号範囲のいずれにも含まれないデータは前記一時バッファ領域に書き込むデータ書き込み手段と、
前記宛先バッファ領域指定手段により前記宛先バッファ領域が指定されたとき、前記宛先バッファ領域の指定に応じて特定された前記宛先シーケンス番号範囲内にシーケンス番号をもつデータを前記一時バッファ領域から読み出し、読み出しデータを前記読み出しデータのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込むデータコピー手段と、
を備える。
本発明の一態様としてのデータ受信方法は、
各々シーケンス番号が対応付けられた一連のデータからなる受信データ列をネットワークを介して順次受信するデータ列受信ステップと、
データを記憶するデータ記憶装置において、前記受信データ列に含まれるデータを一時的に格納するための一時バッファ領域を指定する一時バッファ領域指定ステップと、
前記データ記憶装置において、前記受信データ列に含まれるデータを格納するための宛先バッファ領域を複数回指定する宛先バッファ領域指定ステップと、
前記宛先バッファ領域指定ステップにより前記宛先バッファ領域が指定されたとき、指定された宛先バッファ領域のサイズに応じた宛先シーケンス番号範囲を、前回特定した宛先シーケンス番号範囲に後続するように特定し、特定された前記宛先シーケンス番号範囲に含まれる各シーケンス番号は、前記指定された宛先バッファ領域において、前記特定された宛先シーケンス番号範囲内での相対位置に応じた領域に割り当てられる、宛先シーケンス番号範囲特定ステップと、
前記データ列受信ステップにより前記受信データ列が受信されたとき、前記宛先シーケンス番号範囲特定ステップにより特定された各前記宛先シーケンス番号範囲のいずれかに含まれるデータは、当該データのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込み、各前記宛先シーケンス番号範囲のいずれにも含まれないデータは前記一時バッファ領域に書き込むデータ書き込みステップと、
前記宛先バッファ領域指定ステップにより前記宛先バッファ領域が指定されたとき、前記宛先バッファ領域の指定に応じて特定された前記宛先シーケンス番号範囲内にシーケンス番号をもつデータを前記一時バッファ領域から読み出し、読み出しデータを前記読み出しデータのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込むデータコピーステップと、
を備える。
本発明の一態様としてのデータ処理プログラムは、
ネットワークを介して受信された、各々シーケンス番号が対応付けられた一連のデータからなる受信データ列を処理するためのデータ処理プログラムであって、
データを記憶するデータ記憶装置において、前記データを一時的に格納するための一時バッファ領域を指定する一時バッファ領域指定ステップと、
前記データ記憶装置において、前記データを格納するための宛先バッファ領域を複数回指定する宛先バッファ領域指定ステップと、
前記宛先バッファ領域指定ステップにより前記宛先バッファ領域が指定されたとき、指定された宛先バッファ領域のサイズに応じた宛先シーケンス番号範囲を、前回特定した宛先シーケンス番号範囲に後続するように特定し、特定された前記宛先シーケンス番号範囲に含まれる各シーケンス番号は、前記指定された宛先バッファ領域において、前記特定された宛先シーケンス番号範囲内での相対位置に応じた領域に割り当てられる、宛先シーケンス番号範囲特定ステップと、
前記受信データ列が受信されたとき、前記宛先シーケンス番号範囲特定ステップにより特定された各前記宛先シーケンス番号範囲のいずれかに含まれるデータは、当該データのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込み、各前記宛先シーケンス番号範囲のいずれにも含まれないデータは前記一時バッファ領域に書き込むデータ書き込みステップと、
前記宛先バッファ領域指定ステップにより前記宛先バッファ領域が指定されたとき、前記宛先バッファ領域の指定に応じて特定された前記宛先シーケンス番号範囲内にシーケンス番号をもつデータを前記一時バッファ領域から読み出し、読み出しデータを前記読み出しデータのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込むデータコピーステップと、
をコンピュータに実行させることを特徴とする。
本発明により、ネットワークを介したデータ受信を低消費電力かつ高スループットで行うことが可能となる。
（第一の実施の形態）
図１は、本発明の第一の実施の形態に係るデータ受信装置の構成を示す。
このデータ受信装置は、ネットワークインタフェース部１１、データ記憶部１２、フレーム解析部１３、データ書き込み部１４、データコピー部１５、一時バッファ領域指定部１６、宛先バッファ領域指定部１７、宛先シーケンス番号範囲特定部１８を備える。
ネットワークインタフェース部１１は、ネットワークからのフレームを受信する。ネットワークは例えばインターネット等のTCP/IP通信が行われるネットワークであり、ネットワークインタフェース部１１は、例えばEthernet（登録商標）や無線LANなどのフレームを受信する。
データ記憶部１２は、データを記憶するための記憶領域を有する。
フレーム解析部１３は、受信したフレームのEthernet、IP、TCPヘッダを解析して、各ヘッダを除いたTCPのデータ部分（受信データ列）を取り出す。TCPデータ（受信データ列）の各バイトにはシーケンス番号が対応づけられている。
一時バッファ領域指定部１６は、データ記憶部１２において、フレーム解析部１３により取り出されたデータ（TCPデータ）を一時的に格納する一時バッファ領域を指定する。
宛先バッファ領域指定部１７は、たとえばソフトウェアのアプリケーション（TCPを処理可能なアプリケーション）であり、データ記憶部１２において、フレーム解析部１３により取り出されたTCPデータを書き込んで欲しい宛先バッファ領域を複数回に分けて指定する。宛先バッファ領域は、例えば、領域の始端アドレスと終端アドレス、あるいは、始端アドレスと長さで表される。例えばソケットAPIの場合、recv()コールなどでそのアドレス指定を行う。宛先バッファ領域の指定は、たとえば前回指定した宛先バッファ領域へのデータ書き込みが完了するごとに行う。
宛先シーケンス番号範囲特定部１８は、宛先バッファ領域指定部１７により宛先バッファ領域が指定されたとき、指定された宛先バッファ領域に対応するシーケンス番号範囲を、前回特定したシーケンス番号範囲に後続するように特定する。特定されたシーケンス番号範囲に含まれる各シーケンス番号は、上記指定された宛先バッファ領域において、宛先シーケンス番号範囲における相対的位置に相当するオフセットを加えた領域（アドレス）に割り当てられる。オフセットの基準はたとえば指定された宛先バッファ領域の先頭アドレスである。
データ書き込み部１４は、フレーム解析部１３による解析により取り出されたTCPデータを一時バッファ領域または宛先バッファ領域に書きこむ。つまり、取り出されたデータ（受信データ列）のうち、特定された宛先シーケンス番号範囲に含まれるデータは、宛先バッファ領域においてそのデータのシーケンス番号に対応する領域（アドレス）に書き込み、特定された宛先シーケンス番号範囲に含まれないデータは一時バッファ領域に書き込む。
データコピー部１５は、一時バッファ領域に書き込まれたデータを宛先バッファ領域にコピーする。つまり、宛先バッファ領域指定部１７により宛先バッファ領域が指定されたとき、一時バッファ領域に格納されたデータのうち、宛先シーケンス番号範囲特定部１８により新たに特定されたシーケンス番号範囲に含まれるデータを読み出し、読み出しデータを宛先バッファ領域における読み出しデータのシーケンス番号に対応する領域に書き込む。
以下、具体例を用いながら、図１のデータ受信装置の動作について詳細に説明する。
図5は、図1のデータ受信装置により行われる処理の流れの一例を示すフローチャートである。
まず、ネットワークからネットワークインタフェース部１１においてフレーム（例えばEthernetフレーム）が受信されたかどうかを判定する（S11）。フレームが受信されたとき（S11のYES）、フレーム解析部１３がフレームのEthernet、IP、TCPヘッダを解析する（S12）。解析の結果、各ヘッダを除いたTCPのデータ部分をデータ書き込み部１４がデータ記憶部１２の一時バッファ領域または宛先バッファ領域に書き込む（S13〜S16）。以下、S13〜S16について詳細に説明する。
上述したようにTCPのデータの各バイトにはシーケンス番号が対応づけられている。最初のデータのシーケンス番号は、コネクション確立時に相手から送られる同期（SYN）セグメントのシーケンス番号の次のシーケンス番号として特定できる。例えば最初の同期セグメントのシーケンス番号が0の場合、次に送られる最初のデータのシーケンス番号は1となる。データ受信装置は、シーケンス番号が0の同期セグメントを受け取ると最初のデータのシーケンス番号が1と分かるので、その後に受信したフレームのシーケンス番号が1と一致する場合、最初のデータを受信したことが分かる。その次に受信するデータは、最初のフレームの先頭データのシーケンス番号＋最初のフレームのデータ長となるので、例えばデータ長が1460の場合は1461となる。IP通信はデータのパケットが途中経路で順番が変わって相手に到達する可能性があるため、このようにデータをシーケンス番号で表してやりとりすることで、受信側でデータの並び変えやデータの欠落を検知することができ、それをもって正しく並び替えたり、あるいは送信側に再送を要求したりすることができる。
宛先バッファ領域指定部１７が宛先バッファ領域を指定した場合、宛先シーケンス番号範囲特定部１８は、前述の最初のシーケンス番号からその領域の長さ分の範囲を宛先シーケンス番号範囲と特定する。つまり、最初のデータからその領域の長さ分のデータを宛先バッファ領域に書き込むべきなので、そのシーケンス番号の範囲が特定されるということになる。例えば宛先バッファ領域が0x80000000〜0x80000fffとすると、長さが4096（0x1000）なので、宛先シーケンス番号範囲は1〜4096となる。
データ書き込み部１４は、データが受信されたとき、まず、宛先バッファ領域が指定されていないときは（S13のNO）、データを全て一時バッファ領域に格納する。例えば受信データのデータ長が1460(0x05b4)で、一時バッファ領域が0x70000000〜0x7000ffffと指定されたとすると、0x70000000から0x700005b3にデータが格納される。
宛先バッファ領域が指定されているとき（S13のYES）、例えばそのアドレスが前述の通り0x80000000〜0x80000fffだとすると、宛先シーケンス番号範囲1〜4096だが、受信データのシーケンス番号1〜1460は全て範囲に含まれるので、全てのデータが宛先バッファ領域に書きこまれる（S15のYES、S16）。すなわち、0x80000000から0x800005b3にデータが格納される。
ただし、宛先バッファ領域のアドレスが例えば0x80000000〜0x800000ffとすると、宛先バッファ領域の長さが256（0x100）なので、宛先シーケンス番号範囲は1〜256となる。受信データのシーケンス番号は1〜1460なので、最初の256バイトであるシーケンス番号1〜256のデータは宛先バッファ領域0x80000000〜0x800000ffに書きこまれ、残りの1204（0x04b4）バイトは一時バッファ領域に書き込まれる（S15のYES、S16）。この場合、例えば0x70000000〜0x700004b3にシーケンス番号257〜1460のデータが書き込まれる。
次に、ステップS11においてフレームが受信されていないと判定されたとき（S11のNO）、宛先バッファ領域が指定されたかどうかを判定する（S17）。宛先バッファ領域が指定されていないときは（S17のNO）ステップS11に戻る。宛先バッファ領域が指定されたときは（S17のYES）、一時バッファ領域に、新たに特定された宛先シーケンス番号範囲に含まれるデータがあるかどうかを判定する（S18）。そのようなデータがないとき、何も行うことなく、ステップS11に戻る。
一方、既にデータを受信しており、そのようなデータが一時バッファ領域に格納されているとき、データコピー部１５は、一時バッファ領域に格納されているデータのうち、新たに特定された宛先シーケンス番号範囲に含まれるデータを読み出して宛先バッファ領域に書き込む（S19）。
例えば一時バッファ領域0x70000000から0x70000fffにシーケンス番号1〜4096のデータがバッファされているとき、新たに宛先バッファ領域が0x80000000〜0x800000ffと指定されたとき、バッファの長さは256（0x100）なので、データコピー部１５は一時バッファ領域のデータのうちシーケンス番号1〜256のデータを取り出して宛先バッファ領域にコピーする。宛先バッファ領域が0x80000000〜0x8000ffffと指定されたとき、長さは65536（0x10000）なので、宛先シーケンス番号範囲は1〜65536となり、一時バッファ領域のデータのシーケンス番号1〜4096はすべて含まれるので、全て宛先バッファ領域0x80000000〜0x80000fffにコピーされる。宛先バッファ領域の残りの領域0x80001000〜0x8000ffffには、その後にネットワークから新たに受信するシーケンス番号4097〜65536のデータが直接書き込まれることになる。
ここでIP通信では送信したデータが受信側に順番通りに届かない場合がある。そのとき、受信したデータは宛先バッファ領域に受信した順に並べて書き込むのではなく、シーケンス番号に応じたオフセットをつけて書き込むことで、シーケンス番号順に並べて書き込む。前述のように宛先バッファ領域0x80001000〜0x8000ffffがあり、その宛先シーケンス番号範囲が4097〜65536のとき、次にシーケンス番号4097から始まるデータのフレームを受信することを期待するが、実際は例えばシーケンス番号5557〜7016のデータのフレームを受信する場合がある。このとき、このデータは0x80001000から始まる領域に書きこむのではなく、0x80001000 + (5557 - 4097) = 0x800015b4から始まる領域に書き込まれる。データ長が1460（0x05b4）の場合、0x800015b4〜0x80001b67に書き込まれる。その後に遅れて到着したシーケンス番号4097〜5556のデータを受信した場合、0x80001000〜0x800015b3にそのデータが書き込まれ、結局、正しく0x80001000〜0x80001b67にシーケンス番号4097〜7016のデータが順番通りに書き込まれることになる。このようにすることでデータの並び替えを実現する。フレームが欠落して再送された場合も、遅れて到着する場合と同様である。フレームが重複して届いた場合は単純に同じデータが同じ位置に上書きされるだけなので問題ない。
宛先バッファ領域0x80000000〜0x8000ffffに宛先シーケンス番号範囲1〜65536のデータが書き込まれた後、次に宛先バッファ領域が0x90000000〜0x90000fffと指定されたとき、宛先シーケンス番号範囲は後続するように特定される。すなわち、長さは4096（0x1000）で65537 + 4096 - 1 = 69632なので、宛先シーケンス番号範囲は65537〜69632である。それ以降の動作は同様である。
なお、TCPではデータを受信した際に確認応答を行う。一時バッファ領域に書き込んだ受信データも、宛先バッファ領域に書き込んだ受信データと同様に確認応答を行う。しかしながら、一時バッファ領域も有限なので、一時バッファ領域が足りなくなりデータを受信できなくなる場合がある。その場合は例えば単純にデータを破棄して確認応答はしない（つまり再送を待つ）。ただし、TCPの場合は受信バッファのサイズをウィンドウサイズとして相手に通知することができるので、宛先バッファ領域のサイズと一時バッファ領域のサイズの合計を相手に通知すれば、一時バッファ領域が溢れるまでデータが送られることを防ぐことができる。具体的には、宛先バッファ領域が指定されたとき、指定された宛先バッファのサイズと、一時バッファ領域のうち空きのサイズとの合計サイズ（あるいは宛先バッファ領域の指定によりコピーが行われた後の宛先バッファ領域の空きサイズと、一時バッファ領域との合計サイズ）を、相手に、受信バッファのサイズとして通知する。本実施形態に係わるデータ受信装置は、当該合計サイズの通知を行う受信バッファサイズ通知手段を備えていてもよい。
以上のような動作をすることで、必要なだけ受信データの一時的なバッファリングを行い、バッファリングが必要でない場合は直接宛先バッファ領域に書きこむことができる。すなわち、一時バッファ領域を持つことで、「発明が解決しようとする課題」の欄で挙げた問題（１）〜（３）を解決することができ、さらに、宛先バッファ領域に直接書き込めるときは宛先バッファ領域に書き込む形で一時バッファ領域の利用を必要最低限にすることで、コピーを可能な限り避けることができ、高性能化、低消費電力化を実現することができる。
（第二の実施の形態）
第一の実施の形態では宛先バッファ領域にどのようにデータを書き込むかの基本的な動作を述べたが、宛先バッファ領域に全てのデータが書き込み終わったこと、すなわち、データの受信完了を検知したい場合がある。第二の実施の形態ではそれを実現する形態について述べる。
図2は、本発明の第二の実施の形態に係るデータ受信装置の構成を示す。図2において図1と同一名称の要素には同一の符号を付し、拡張された処理を除き、その説明については省略する。
図 2のデータ受信装置は、図 1の構成に加え、どのシーケンス番号の受信データを受信したかを記憶する受信シーケンス番号記憶部２１と、受信シーケンス番号記憶部２１内の受信シーケンス番号を更新する受信シーケンス番号更新部２２と、受信完了を判定する受信完了判定部２３を備える。データコピー部１５は受信シーケンス番号記憶部２１の情報を用いて、コピーするデータを特定する。
図6は、図2のデータ受信装置の動作の流れを示すフローチャートである。
まず通信相手と接続を確立し、同期セグメントのやり取りから先頭シーケンス番号が10000から始まることになったとする。また、宛先バッファ領域が指定され、宛先シーケンス番号範囲が10000〜14999になったとする。IP通信では必ずしも受信データが連続して到達しないので、受信シーケンス番号記憶部２１は、離散的な受信シーケンス番号も記憶することができる。受信シーケンス番号記憶部２１は、離散的な受信シーケンス番号を受信シーケンス番号範囲情報というリスト構造のデータ構造で管理している。この受信シーケンス番号範囲情報は、データが受信されるたびに受信シーケンス番号更新部２２により更新される。
図9は接続確立後のまだ何もデータを受信していない状態での受信シーケンス番号範囲情報を示している。受信シーケンス番号範囲情報は、始端シーケンス番号、終端シーケンス番号、次の受信シーケンス番号範囲情報のアドレス、の3つの要素で構成される。ただし、最初の受信シーケンス番号範囲情報の始端シーケンス番号に関しては特に記憶する必要がないので、図示のように省略してもよい。また、現時点ではまだ何も受信しておらず、シーケンス番号10000からのデータ受信を期待する状態であるが、これはシーケンス番号9999まで受信しているのと同じ状態といえるので、便宜的に図示のように受信シーケンス番号範囲情報を表すこととする。図示の終端シーケンス番号が9999になっているのはそういう意味である。なお、nextがnullをさしているのは、受信シーケンス番号範囲情報がこれ以上ないことを示している。
データは例えば1460バイトずつ送られ、まずシーケンス番号10000〜11459のデータを受信する(S21のYES)。すると、受信シーケンス番号更新部２２が、受信シーケンス番号記憶部２１の受信シーケンス番号範囲情報を更新する。図 10は更新後の様子であり、シーケンス番号11459までのデータを受信したことを示している（S22〜S30）。
ここで、このように受信シーケンス番号範囲情報が更新されると、受信完了判定部２３によって宛先シーケンス番号範囲が、受信シーケンス番号範囲情報のいずれかに包含されるか確認される（S31のYES、S32）。この確認は、例えば最初の受信シーケンス番号範囲情報の終端シーケンス番号が、宛先シーケンス番号範囲の終端シーケンス番号以上かどうか、を比較すればよい。この段階では最初の受信シーケンス番号範囲情報の終端シーケンス番号11459は宛先シーケンス番号範囲の終端14999以上ではないので、受信完了判定部２３は受信完了を判定しない（S32のNO）。
新たにシーケンス番号11460〜12919のデータを受信すると（S21のYES）、図 11のように受信シーケンス番号範囲情報は12919まで受信したことを示すようになる（S22〜S30）。受信完了判定部２３は、最初の受信シーケンス番号範囲情報の終端シーケンス番号12919は宛先シーケンス番号範囲の終端14999以上ではないので、やはり受信完了を判定しない（S31のYES、S32のNO）。
さらに、シーケンス番号14380〜15839のデータを受信すると（S21のYES)、図 12のように新たに二つ目の受信シーケンス番号範囲情報としてシーケンス番号14380〜15839が加わる（S22〜S30）。この段階でも、受信完了判定部２３は、最初の受信シーケンス番号範囲情報の終端12919は宛先シーケンス番号範囲の終端14999以上ではないので、やはり受信完了を判定しない（S31のYES、S32のNO）。
さらにシーケンス番号12920〜14379のデータを受信すると（S21のYES）、図 13のように一つ目の受信シーケンス番号範囲情報と二つ目の受信シーケンス番号範囲情報は結合し、受信シーケンス番号範囲情報はシーケンス番号15839まで受信したことを示すようになる（S22〜S30）。すると、受信完了判定部２３は、最初の受信シーケンス番号範囲情報の終端15839は宛先シーケンス番号範囲の終端14999以上なので、ここで受信完了を判定する（S31のYES、S32のYES）。受信完了を判定すると、受信完了判定部２３から宛先バッファ領域指定部１７に受信完了の旨が通知される。その後に宛先バッファ領域指定部１７が新たに宛先バッファ領域を指定するまでは、再び宛先バッファ領域がない状態に戻る。
なお、以上では連続したシーケンス番号範囲情報が結合される例を示したが、必ずしも結合させる必要はなく、離散的なまま保存してもよい。ただし、結合させることで受信シーケンス番号範囲情報を記憶するメモリ量を節約でき、また受信完了判定部２３における受信完了判定では最初の受信シーケンス番号範囲情報の終端シーケンス番号だけをみればよくなるので、処理が簡略化される。結合させない場合、受信完了判定では、複数の受信シーケンス番号範囲情報を見て、宛先シーケンス番号範囲のすべてのシーケンス番号が受信シーケンス番号範囲に含まれているか順次スキャンする。
また、受信シーケンス番号範囲情報のデータ構造はリスト構造である必要はなく、テーブル構造（配列構造）など他のデータ構造でもよい。ここでは離散的な範囲情報を記憶することがポイントであり、そのデータ構造はなんでもよい。
次に、図6において、接続を確立した後、宛先バッファ領域が指定される前にフレームの受信を行った場合について説明する。
宛先バッファ領域がない状態でフレームを受信した場合（S21のYES、S22、S23のNO）、その全てのデータを一時バッファ領域に記憶し（S24）、先と同様に受信シーケンス番号更新部２２は受信シーケンス番号記憶部２１の受信シーケンス番号範囲情報を更新する（S30）。ただし、宛先バッファ領域が指定されていないときは、その更新後に受信完了判定部２３は受信完了判定を行わない（S31のNO）。
その後に宛先バッファ領域が指定され（S27のYES）、宛先シーケンス番号範囲が特定されると、まず受信シーケンス番号記憶部２１の受信シーケンス番号範囲情報を確認し（S33）、一時バッファ領域にどのデータが記憶されているか確認する（S34）。そして、宛先シーケンス番号範囲に含まれるデータがある場合（S34のYES）、そのデータを宛先バッファ領域にコピーし（S35）、コピー完了後に受信完了判定部２３は受信完了判定を行う（S32）。宛先シーケンス番号範囲に含まれるデータがない場合は（S34のNO）何もせず、データの受信を待つ。例えば図 12の状態で宛先バッファ領域が指定され、その後に残りのデータを受信し、受信完了を判定する場合の動作を図 14に示す。
以上、本実施の形態のようにすることで、受信完了を適切に判定することが出来るようになる。
ここで、一時バッファ領域指定部１６による一時バッファ領域の割り当て方式について説明する。
一例としてはフレーム毎に個別に記憶領域を割り当てる方式（第一の方式）がある。すなわち、一時バッファ領域指定部１６が例えば1500バイトの領域（部分領域）を例えば32個割り当てておき、データ書き込み部１４はこの32個の領域（部分領域）に対し、受信したフレームデータを一つずつ格納していく。このとき、受信シーケンス番号範囲情報と関連してこの領域のアドレスを記憶しておく必要がある。例えば、図 10のようにシーケンス番号10000〜11459のデータを受信し、そのデータを一時バッファ領域の0x80000000に格納した場合、図 16のようにそのアドレスを関連して記憶する。さらに図 11のようにシーケンス番号11460〜12919のデータを受信し、それを一時バッファ領域の0x90000000に格納した場合、図 17のようにそのアドレスを関連して記憶する。図 17のように複数のフレームの受信シーケンス番号範囲情報が結合している場合は、関連する一時バッファ領域のアドレス情報は複数記憶する必要があるので、図 18のようにリスト形式で関連付けて記憶しても良い。なお、部分領域の数は有限なので、データを宛先バッファ領域にコピーし終わった部分領域は例えば開放して再利用する。
また、一時バッファ領域指定部１６による一時バッファ領域の割り当て方式のもう一つ（第二の方式）の例は、宛先バッファ領域と同じように一つのバッファにシーケンス番号順に並べて記憶する方法である。すなわち、宛先バッファ領域と同様に一時バッファ領域にもシーケンス番号範囲を特定し、そのシーケンス番号範囲に応じたオフセット位置に書き込むことで、一時バッファ領域上にシーケンス番号順にデータを書き込む。この場合のデータ受信装置の構成を図 3に示す。
図 3のデータ受信装置は一時バッファ領域に関して宛先バッファ領域と同様に対応するシーケンス番号範囲を求める一時シーケンス番号範囲特定部３１を備える。例えば一時バッファ領域指定部１６が一時バッファ領域を0x80000000から64KByte分、すなわち、0x80000000〜0x8000ffffを指定したとすると、シーケンス番号が10000から始まる場合、一時シーケンス番号範囲特定部31はこの一時バッファ領域に対応するシーケンス番号範囲を10000〜75535（長さ64K=65536、75535=10000+65536-1）と特定する。この情報を用いれば、例えば図 12のような場合、シーケンス番号10000〜12919のデータは0x80000000〜0x80000b67（0x0b67=2919）、シーケンス番号14380〜15839のデータは0x8000111c〜0x800016cf（0x111c=4380、0x16cf =5839）というように、シーケンス番号のオフセットからアドレス領域を特定できる。つまり、先ほどの方式で述べた図 16〜図 18のように、フレームのデータ毎に一時バッファ領域のアドレスを記憶する必要がなくなるので、メモリ領域の節約や、処理の簡略化が可能となる。
なお、この場合の一時バッファ領域は例えばリングバッファとすることが好ましい。具体的には、例えば一時バッファ領域が0x80000000〜0x8000ffffのとき、宛先バッファ領域が指定されてシーケンス番号10000〜14999の宛先シーケンス番号範囲が特定され、さらに一時バッファ領域の0x80000000〜0x80001387からデータのコピーが完了したとする。この場合、0x80000000〜0x80001387（0x1387=4999）の一時バッファ領域はもう使うことはないので開放し、0x8000ffffに続いてデータの書き込みが出来るようにする。すなわち、0x80001388〜0x8000ffff、0x80000000〜0x80001387の領域がこの順番で新たな64KByteの領域となる。ただしこのとき、一時シーケンス番号範囲も15000〜80535（80535=15000+65536-1）というように、宛先シーケンス番号範囲に後続するようにシーケンス番号範囲を更新する。
このようにすることで、例えば図 14の二段目が示すコピー完了状態ではシーケンス番号15000〜15839のデータが一時バッファ領域に残っているが、この残っているデータを移動することなく、更新前と更新後における、領域アドレスとシーケンス番号の関係の整合性をとることが出来る。この様子を図 19に示す。図 19は上が更新前、下が更新後であり、数直線の上が一時バッファ領域のアドレス、下が対応するシーケンス番号を表している。
なお、一時バッファ領域が、指定した宛先バッファ領域より小さい場合はリングバッファとする必要はない。具体的には、一時バッファ領域が0x80000000〜0x800000ff（サイズ256Byte）であった場合、同じく宛先シーケンス番号範囲が10000〜14999で特定された場合、データコピーが完了すると、一時バッファ領域はそのまま0x80000000〜0x800000ffでよい。ただし、それに対する一時シーケンス番号範囲は15000〜15255となり、やはり宛先シーケンス番号範囲に後続するように更新する。
以上のようにすることで、一時バッファ領域を適切に割り当てることができる。
（第三の実施の形態）
第二の実施の形態ではデータコピー部１５によるコピー処理の後に受信完了判定を行ったが（図6のS35→S32）、データコピー部１５がコピーを行っている最中にデータを受信する場合もある。データ記憶部１２のメモリの書き込みポートは通常一つなので、その場合は双方の書き込み処理で調停が必要となり、いずれかの書き込みを待たせる必要がある。コピーするデータは一時バッファ領域に記憶されているのでコピー処理の方を遅延させてもあまり問題にならない場合があるが、データ受信の方を遅延させると、次々とデータが送られてくる場合は途中のバッファ（特にネットワークインタフェース部１１の内部的なバッファなど）がオーバーフローしてデータを欠落させてしまう可能性がある。よって、そのような場合はデータコピーによる書き込みよりデータ受信による書き込みの方を優先させたいが、そうすると、データのコピーが完了しないうちにデータ受信を行う場合が多くなる。第三の実施の形態ではこのような場合について説明する。
図7は、第三の実施の形態に係わるデータ受信装置の動作の流れを示すフローチャートである。本第三の実施の形態に係わるデータ受信装置のブロック図は図2または図3と同様である。
データコピー部１５がコピーを行っている最中に、宛先バッファ領域が指定されたデータを受信した場合（S41のYES、S43のYES、S44のYES）、まず受信シーケンス番号更新部２２は受信シーケンス番号記憶部２１の受信シーケンス範囲情報を今までと同様に更新する。しかしながら、単純に今までと同様に宛先バッファ領域にデータを書き込んでしまうと、そのデータのシーケンス番号を、データコピー部１５のコピーのスキャンがまだ通過していない場合、受信シーケンス番号範囲情報はそのシーケンス番号のデータを受信したことを記憶しているので、データコピー部１５はその後のスキャンでその更新された受信シーケンス番号範囲情報を見て、一時バッファ領域の実際は受信データが書き込まれていない該当領域からデータを読み出して宛先バッファ領域にコピーしてしまう。つまり、そのときの一時バッファ領域にたまたま記憶されている無効なデータで、宛先バッファ領域に書き込んだ受信データを上書きしてしまう。
よって、そのような場合、つまり、データコピー部１５がコピーを行っている最中にデータを受信した場合、その受信データのシーケンス番号が、データコピー部１５のコピーのスキャンを通過していない場合は（S46のNO）、宛先バッファ領域が指定されている状態でも、受信したデータを一時バッファ領域に書き込む（S49）。そうすると、その後にデータコピー部１５がスキャンした際、そのデータは正しく一時バッファ領域から宛先バッファ領域にコピーされることになる。一方、受信データのシーケンス番号が、データコピー部１５のコピーのスキャンを通過している場合は（S46のYES）、コピーによる上書きはないため、宛先バッファ領域に受信したデータを書き込む（S47）。
また、第二の実施の形態ではフレームを受信した際、このフレームのシーケンス番号を格納する宛先バッファ領域が指定されているとき、受信完了判定部２３は受信完了判定を行ったが、本実施形態では、コピーがまだ完了していない場合は（S52のYES）、まだ受信シーケンス番号記憶部２１が示すデータが宛先バッファ上にない場合があるので、宛先バッファ領域が指定されていても、受信完了判定部２３は受信完了判定を行わない。受信完了判定部２３はその後にコピーが完了したときに受信完了判定を行う（S56、S52のNO、S53）。
以上のような動作の一例を図 15に示す。図 15は図 14と同様、図 12の状態のときに宛先バッファ領域が指定された状態である。ただし、今度はデータコピー部１５がシーケンス番号12919までコピーを行ったとき、新たにシーケンス番号12920〜14379のデータを受信した様子を示している。このとき、データコピー部１５のスキャンがまだ通過してないので、データを一時バッファ領域にコピーし、その後にデータコピー部１５がこれを後続のデータと併せて宛先バッファ領域にコピーし、受信完了判定部２３が受信完了を判定する。以上のように動作することで、データコピー部１５がデータのコピー中でも適切にデータの受信を行うことが出来る。
（第四の実施の形態）
第三の実施の形態では、データコピー部１５がデータのコピーを行っている最中にデータを受信した場合、受信したデータのシーケンス番号をスキャンが通過していないときは一時バッファ領域に書き込みを行ったが、受信したデータのシーケンス番号が宛先シーケンス番号範囲に含まれる場合、データを一時バッファ領域ではなく直接宛先バッファ領域に書く方が、そのデータのコピーが発生しないので、より効率がよい。本実施の形態ではそれを実現するデータ受信装置について説明する。
図4は、本発明の第四の実施の形態に係るデータ受信装置の構成を示すブロック図である。
図 4のデータ受信装置は、図 3と比べ、受信シーケンス番号更新部と受信シーケンス番号記憶部が第一のものと第二のものでそれぞれ二つあるところが異なる。すなわち、図4のデータ受信装置は、第一受信シーケンス番号記憶部２１ａおよび第二受信シーケンス番号記憶部２１ｂと、第一受信シーケンス番号更新部２２ａおよび第二受信シーケンス番号更新部２２ｂとを備える。第一受信シーケンス番号記憶部２１ａは一時バッファ領域に書き込んだデータに対応する受信シーケンス番号範囲情報を記憶する。第一受信シーケンス番号記憶部２１ｂは宛先バッファ領域に書き込んだデータに対応する受信シーケンス番号範囲情報を記憶する。第一および第二受信シーケンス番号更新部２２ａ、２２ｂは、第一および第二受信シーケンス番号記憶部２１ａ、２１ｂの受信シーケンス番号範囲情報を更新する。
データコピー部１５がデータのコピーを行う際、一時バッファ領域に記憶されているデータに相当する受信シーケンス番号範囲情報は第一受信シーケンス番号記憶部２１ａに記憶されているので、コピーすべきデータをこの情報をみて判断し、コピーしたデータに対応する受信シーケンス番号範囲は、第一受信シーケンス番号記憶部２１ａから第二受信シーケンス番号記憶部２１ｂに移行する。
新たにデータを受信した際は、第一の実施の形態で述べた方法でデータを一時バッファ領域に書きこむか宛先バッファ領域に書きこむかを判定し、一時バッファ領域に書きこんだデータのシーケンス番号範囲は第一受信シーケンス番号記憶部２１ａに第一受信シーケンス番号更新部２２ａにより加えられ、宛先バッファ領域に書きこんだデータのシーケンス番号範囲は第二受信シーケンス番号更新部２２ｂにより第二受信シーケンス番号記憶部２１ｂに加えられる。
そして、受信完了判定部２３は、データがコピーされたとき、あるいは、新たにデータを受信したときに第二受信シーケンス番号記憶部２１ｂの受信シーケンス番号範囲情報が更新されると、更新された受信シーケンス番号範囲情報が宛先シーケンス番号範囲に包含されるかどうかを確認し、包含されることが確認されたとき受信完了を判定する。
例えば次のような場合を考える。図 20は宛先バッファ領域の指定から受信完了までの動作の一例を示している。
まず、シーケンス番号が10000から始まる状態（一時シーケンス番号範囲の始端が10000）で、一時バッファ領域にシーケンス番号10000〜12919、シーケンス番号15840〜17299のデータがあり、宛先バッファ領域が指定されていない状態から始まるとする。宛先シーケンス番号範囲が10000〜16999の宛先バッファ領域が指定されると、まずシーケンス番号10000〜11459のデータがコピーされる。次に、コピーはそのまま継続されているが、コピーの途中でシーケンス番号12920〜15839のデータが新たに受信され、宛先バッファ領域に書き込まれる。そして最後に、継続されているコピーの残りの部分であるシーケンス番号11460〜12919、シーケンス番号15840〜16999がコピーされる。この時点で宛先シーケンス番号10000〜16999の全てが宛先バッファ領域に格納される。以下、図20に示した場合における、本実施の形態に係わるデータ受信装置の動作の詳細について説明する。
図8は、第四の実施の形態に係わるデータ受信装置の処理の流れを示すフローチャートである。以下では、説明の便宜上、第一受信シーケンス番号記憶部２１ａに記憶された受信シーケンス番号範囲情報は第一のグループに属するとし、第一受信シーケンス番号記憶部２１ｂに記憶された受信シーケンス番号範囲情報は第二のグループに属するとする。
まず、初期状態での受信シーケンス番号情報の様子を図 21に示す。この状態ではまだデータを何も受信していない状態である。この状態からシーケンス番号10000〜12919、15840〜17299のデータを受信すると（S61のYES）、図 20の最初の状態になる（S62、S63のNO、S67）。図 20に対応した受信シーケンス番号範囲情報の様子を図 22に示す。図 22の各段は図 20の各段に対応している。初期状態では第一グループにはシーケンス番号〜12919、シーケンス番号15840〜17299の受信シーケンス番号範囲情報が格納される（S68）。なお、一時シーケンス番号範囲特定部３１が特定した範囲情報の始端は10000を示していることから、データは10000から始まっていることがわかる。宛先バッファ領域はないので第二グループには受信シーケンス番号範囲情報がない。
次に、宛先バッファ領域が指定される（S61のNO、S71のYES）。ただし、その状態でも受信シーケンス番号範囲情報は変わらない。
次に、シーケンス番号10000〜11459のデータがコピーされると（S75、S76のYES、S77、S73）、第一グループからそのシーケンス番号範囲が削除され、第二グループにそのシーケンス番号範囲が加えられ、結果的に第一グループはシーケンス番号〜9999、シーケンス番号11460〜12919、シーケンス番号15840〜17299、第二グループはシーケンス番号〜11459となる（S74）。ここで、受信完了判定部２３が、宛先シーケンス番号範囲10000〜16999が第二グループの受信シーケンス番号範囲情報に包含されるか確認する（S69のYES、S70）。しかしながら、ここでは包含されないので（S70のNO）、受信完了を判定しない。
次に、新たにシーケンス番号12920〜15839のデータを受信すると（S61のYES）、その範囲が第二グループに加わり、結果的に第二グループはシーケンス番号〜11459、シーケンス番号12920〜15839となる（S62、S63のYES、S64のYES、S65、S66）。ここで、再び受信完了判定部２３が、宛先シーケンス番号範囲10000〜16999が第二グループの受信シーケンス番号範囲情報に包含されるか確認する（S69のYES、S70）。しかしながら、ここでも包含されないので（S70のNO）受信完了を判定しない。
次に、コピーの残りの部分であるシーケンス番号11460〜12919、シーケンス番号15840〜16999がコピーされると（S73）、その部分が第一グループから削除され、結果的に第一グループはシーケンス番号〜9999、シーケンス番号17000〜17299、第二グループはシーケンス番号〜16999となる（S74）。ここで、再び受信完了判定部２３が、宛先シーケンス番号範囲10000〜16999が第二グループの受信シーケンス番号範囲情報に包含されるか確認する（S69のYES、S70）。ここでは、包含されることが確認されるので（S70のYES）、受信完了を判定する。
なお、データコピーが完了した後は、例えば第二の実施の形態の最後で述べたように、コピーを行った部分の一時バッファ領域は必要なくなるので開放することが望ましいが、開放に伴い、第一グループの該当する受信シーケンス番号範囲情報も必要なくなるので、例えば図 23のようにその情報を削除しても良い。すなわち、図 23の上段では第一グループの最初の受信シーケンス番号範囲情報の終端シーケンス番号が16999になっているが、これは図 22の最後の状態からシーケンス番号範囲10000〜16999の情報を削除している様子である。さらに、これは二つ目の受信シーケンス番号範囲17000〜17299と連続しているので、これらを結合させ、下段のように受信シーケンス番号範囲〜17299とすることができる。このとき、併せて一時シーケンス番号範囲の始端が17000となるので、データが17000から始まっていることがわかる。以上のような状態にした後、新たな宛先バッファ領域の指定やデータの受信に備える。
以上のように動作することで、データコピー部１５がデータのコピーを行っている最中に新たにデータを受信した場合、それを一時バッファ領域ではなく宛先バッファ領域に直接書き込むことでそのデータのコピーを回避することができ、処理の効率が良くなる。
また、上記した実施形態と同等の効果が得られるもう一つの形態を述べる。その形態にかかるデータ受信装置の構成を図 24に示す。図 24は、図2または図3と比べ、受信シーケンス番号範囲情報を一時的に記憶する受信シーケンス番号一時記憶部３２を備える。
図24のデータ処理装置の処理のフローを図 25に示す。データを受信した場合の動作は第二の実施の形態の処理と同じだが、宛先バッファ領域が指定されてからの処理が異なる。
宛先バッファ領域が指定され宛先シーケンス範囲情報が特定されたとき（S91のYES）、受信シーケンス番号一時記憶部３２は、その時点での受信シーケンス番号範囲情報を記憶する（S93）。そして、データコピー部１５は、受信シーケンス番号記憶部２１が記憶する受信シーケンス番号範囲情報ではなく、受信シーケンス番号一時記憶部３２が記憶する受信シーケンス番号範囲情報を順次スキャンして、宛先シーケンス番号範囲に含まれるデータのコピーを行う（S93）。
データのコピー中に新たにデータを受信した場合（S81のYES）、受信シーケンス番号記憶部２１が記憶する情報にその情報が更新されるが（S87）、データコピー部１５が参照している受信シーケンス番号一時記憶部３２の情報には影響しないので、コピーには影響を与えない。
コピーが完了し（S89のNO）、かつ、受信シーケンス番号範囲情報に宛先シーケンス範囲情報が包含される場合（S90のYES）、受信完了を判定する。
図20に対応する受信シーケンス番号範囲情報の変化の様子を図26に示す。「元の情報」が受信シーケンス番号記憶部２１が記憶する情報であり、「一時情報」が受信シーケンス番号一時記憶部３２が記憶する情報である。
まず、宛先バッファ領域が指定されていない段階（一段目）では、一時情報にはデータが無い。もしこの時点で前回の処理に使用したデータが一時情報に残っている場合、次の段階のコピーでそのデータは上書きされる。
宛先バッファ領域が指定されると（二段目）、この段階で受信シーケンス番号範囲情報が一時情報に記憶され、データのコピーが開始される。コピーは一時情報を参照して順次行われ、まず一つ目の受信シーケンス番号範囲情報をスキャンし、コピーを行う（三段目）。
次に、新たにデータを受信すると（四段目）、その情報は元の情報に反映されるが、一時情報には反映されないので、コピーには影響を与えない。なお、この時点で宛先シーケンス番号範囲が受信シーケンス番号範囲情報に包含されるが、コピーが完了していないので受信完了を判定しない。
その後、コピーが進み、最後の受信シーケンス番号範囲情報をスキャンして（五段目）、コピーを完了し、受信完了を判定する。
以上のように動作することで、先と同様に、データコピー部１５がデータのコピーを行っている最中に新たにデータを受信した場合、それを一時バッファ領域ではなく宛先バッファ領域に直接書き込むことでそのデータのコピーを回避することができ、処理の効率が良くなる。
（第五の実施の形態）
第五の実施の形態では、具体的な実装の形態を述べる。図27はその一例を示す。
ネットワークインタフェース部１１はNIC（Network Interface Card）などのネットワークインタフェースデバイス５１で実現する。
フレーム解析部１３、データ書き込み部１４、データコピー部１５、第一および第二受信シーケンス番号更新部２２ａ、２２ｂ、受信完了判定部２３はASIC、ダイナミックリコンフィギュアラブルプロセッサ、FPGAなどで実装されるハードウェア（専用回路）５２で実現する。
一時バッファ領域指定部１６、一時シーケンス番号範囲特定部３１、宛先バッファ領域指定部１７、宛先シーケンス番号範囲特定部１８などはホストCPU５３などにより実行されるソフトウェアで実現する。
第一および第二受信シーケンス番号記憶部２１ａ、２１ｂ、データ記憶部１２はSDRAM、SRAMなどのメモリ５４で実現する。メモリは物理的に複数で構成されていても良いし、単一で構成されていても良い。複数の場合は、それぞれ独立したメモリでもよい。
以上の構成はほんの一例であるが、少なくともフレーム解析部１３、データ書き込み部１４、データコピー部１５、第一および第二受信シーケンス番号更新部２２ａ、２２ｂは、フレームを受信する毎に処理をする必要があるので、ハードウェアで構成することが望ましい。
またホストCPU５１、NIC５１、ハードウェア５２、メモリ５４の配置例を図28〜図30に示す。図28はハードウェア５２とNIC５１が専用のバス６１でつながれている場合、図29はシェアードバス６２でつながれている場合、図30はハードウェア５１がNIC５３の中に実装されている場合である。いずれの場合でも本発明を適用することができる。
なお、これらは異なるLSIで構成されても良いし、例えばハードウェア、ホストCPUなど複数のブロックが１つのLSIで構成されていても良い。
なお、一時バッファ領域と宛先バッファ領域を共通のメモリで構成する場合、受信データの書き込み、コピーによる読み出しと書き込みの計３つ分のアクセスが同時に必要になる場合があるので、メモリの帯域をネットワーク帯域の３倍以上にすることが望ましい。
以上のように本発明の各実施形態を用いると、必要なだけ受信データの一時的なバッファへのバッファリングを行い、バッファリングが必要でない場合は直接宛先バッファ領域に書きこむ、ということができるようになるので、「発明が解決しようとする課題」の欄で述べた（１）〜（３）の問題を解決しつつ、受信データの一時バッファ領域へのコピーを最小限に抑えることができ、ひいては高性能化、低消費電力化を実現することができる。
第一の実施の形態に係るデータ受信装置の構成を示す図。 第二の実施の形態に係るデータ受信装置の構成を示す図。 第二の実施の形態に係るデータ受信装置の他の構成を示す図。 第四の実施の形態に係るデータ受信装置の構成を示すブロック図。 第一の実施の形態に係るデータ受信装置により行われる処理の流れの一例を示すフローチャート。 第二の実施の形態に係るデータ受信装置の動作の流れを示すフローチャート。 第三の実施の形態に係わるデータ受信装置の動作の流れを示すフローチャート。 第四の形態に係わるデータ受信装置の処理の流れを示すフローチャート。 第二の実施の形態に係わるデータ受信装置の動作を説明する図。 第二の実施の形態に係わるデータ受信装置の動作を説明する図。 第二の実施の形態に係わるデータ受信装置の動作を説明する図。 第二の実施の形態に係わるデータ受信装置の動作を説明する図。 第二の実施の形態に係わるデータ受信装置の動作を説明する図。 第二の実施の形態に係わるデータ受信装置の動作を説明する図。 第三の実施の形態に係わるデータ受信装置の動作を説明する図。 一時バッファ領域の割当方式（第一の方式）を説明する図。 一時バッファ領域の割当方式（第一の方式）を説明する図。 一時バッファ領域の割当方式（第一の方式）を説明する図。 一時バッファ領域の割当方式（第二の方式）を説明する図。 第四の実施の形態に係わるデータ受信装置の動作を説明する図。 第四の実施の形態に係わるデータ受信装置の動作を説明する図。 第四の実施の形態に係わるデータ受信装置の動作を説明する図。 第四の実施の形態に係わるデータ受信装置の動作を説明する図。 第四の実施の形態に係わるデータ受信装置の他の構成例を示す図。 図２４のデータ受信装置の動作の流れを示すフローチャート。 図２４のデータ受信装置の動作を説明する図。 データ受信装置の具体的な実装の形態の一例を示す図。 ホストＣＰＵ、ＮＩＣ、ハードウェア、メモリの配置例を示す図。 ホストＣＰＵ、ＮＩＣ、ハードウェア、メモリの他の配置例を示す図。 ホストＣＰＵ、ＮＩＣ、ハードウェア、メモリのさらに他の配置例を示す図。 従来のデータ受信装置の動作を説明する図。 従来のデータ受信装置の動作を説明する図。 従来のデータ受信装置の動作を説明する図。
符号の説明
１１：ネットワークインタフェース部（データ列受信手段）
１２：データ記憶部
１３：フレーム解析部
１４：データ書き込み部
１５：データコピー部
１６：一時バッファ領域指定部
１７：宛先バッファ領域指定部
１８：宛先シーケンス番号範囲特定部
２１：受信シーケンス番号記憶部
２１ａ：第一受信シーケンス番号記憶部
２１ｂ：第二受信シーケンス番号記憶部
２２：受信シーケンス番号更新部
２２ａ：第一受信シーケンス番号更新部
２２ｂ：第二受信シーケンス番号更新部
２３：受信完了判定部
３１：一時シーケンス番号範囲特定部
３２：受信シーケンス番号一時記憶部
５１：ネットワークインタフェースデバイス
５２：ハードウェア
５３：ホストＣＰＵ
５４：メモリ

Claims (12)

  1. 各々シーケンス番号が対応付けられた一連のデータからなる受信データ列をネットワークを介して順次受信するデータ列受信手段と、
    データを記憶するデータ記憶手段と、
    前記データ記憶手段において、前記受信データ列に含まれるデータを一時的に格納するための一時バッファ領域を指定する一時バッファ領域指定手段と、
    前記データ記憶手段において、前記受信データ列に含まれるデータを格納するための宛先バッファ領域を複数回指定する宛先バッファ領域指定手段と、
    前記宛先バッファ領域指定手段により前記宛先バッファ領域が指定されたとき、指定された宛先バッファ領域のサイズに応じた宛先シーケンス番号範囲を、前回特定した宛先シーケンス番号範囲に後続するように特定し、特定された前記宛先シーケンス番号範囲に含まれる各シーケンス番号は、前記指定された宛先バッファ領域において、前記特定された宛先シーケンス番号範囲内での相対位置に応じた領域に割り当てられる、宛先シーケンス番号範囲特定手段と、
    前記データ列受信手段により前記受信データ列が受信されたとき、前記受信データ列に含まれる各データのうち、前記宛先シーケンス番号範囲特定手段により特定された各前記宛先シーケンス番号範囲のいずれかに含まれるデータは、当該データのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込み、各前記宛先シーケンス番号範囲のいずれにも含まれないデータは前記一時バッファ領域に書き込むデータ書き込み手段と、 前記宛先バッファ領域指定手段により前記宛先バッファ領域が指定されたとき、前記宛先バッファ領域の指定に応じて特定された前記宛先シーケンス番号範囲内にシーケンス番号をもつデータを前記一時バッファ領域から読み出し、読み出しデータを前記読み出しデータのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込むデータコピー手段と、
    を備えたデータ受信装置。
  2. 前記データ列受信手段により受信された各前記受信データ列のシーケンス番号範囲の集合を表す受信シーケンス番号範囲情報を記憶する受信シーケンス番号記憶手段と、
    前記データ書き込み手段が前記受信データ列の書き込みを行うとき、書き込む前記受信データ列のシーケンス番号範囲を追加することにより前記受信シーケンス番号範囲情報を更新する受信シーケンス番号更新手段と、
    前記特定された宛先シーケンス番号範囲が、前記受信シーケンス番号範囲情報に包含されるか否かの検査を行い、包含されることが検知されたとき、前記特定された宛先シーケンス番号範囲に対して受信の完了を判定する受信完了判定手段と、を備え、
    前記受信完了判定手段は、前記宛先バッファ領域の指定に応じて前記データコピー手段によるデータのコピーが行われたときは、前記検査の結果、前記特定された宛先シーケンス番号範囲が前記受信シーケンス番号範囲情報に包含されることが検知されても、前記データのコピーが終わってから受信の完了を判定し、
    前記データコピー手段は、前記受信シーケンス番号範囲情報により示されるシーケンス番号範囲と、前記特定された宛先シーケンス番号範囲との両方に共通して含まれるシーケンス番号を特定し、特定したシーケンス番号をもつデータをコピーする
    ことを特徴とする請求項１に記載のデータ受信装置。
  3. 前記データコピー手段は、前記受信シーケンス番号範囲情報を順次スキャンし、前記特定された宛先シーケンス番号範囲に含まれるデータをコピーし、
    前記データ書き込み手段は、前記データコピー手段によりデータコピーが行われている最中に、前記特定されたシーケンス番号範囲に含まれるデータが受信されたとき、当該データを、当該データのシーケンス番号のスキャンがまだ通過していないときは、前記一時バッファ領域に書き込み、通過しているときは当該データのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込む
    ことを特徴とする請求項２に記載のデータ受信装置。
  4. 前記受信シーケンス番号記憶手段は、前記データ列受信手段により受信された各前記受信データ列に含まれる各データのうち、前記一時バッファ領域に書き込まれたデータのシーケンス番号範囲を表す第１の受信シーケンス番号範囲情報と、前記宛先バッファ領域に書き込まれたデータのシーケンス番号範囲を表す第２の受信シーケンス番号範囲情報を記憶し、
    前記受信シーケンス番号更新手段は、前記宛先バッファ領域に書き込まれたデータのシーケンス番号範囲を前記第２の受信シーケンス番号範囲情報に追加し、前記一時バッファ領域に書き込まれたデータのシーケンス番号範囲を前記第１の受信シーケンス番号範囲情報に追加し、
    前記データコピー手段は、前記第１の受信シーケンス番号範囲情報が示すシーケンス番号範囲と、前記特定されたシーケンス番号範囲との両方に共通して含まれるシーケンス番号を特定し、特定したシーケンス番号をもつデータをコピーし、
    前記受信シーケンス番号更新手段は、前記データコピー手段によりデータコピーがなされたときは、コピーされたデータのシーケンス番号範囲を前記第１の受信シーケンス番号範囲情報から前記第２の受信シーケンス番号範囲情報へ移動し、
    前記受信完了判定手段は、前記特定された宛先シーケンス番号範囲が、前記第２の受信シーケンス番号範囲情報に包含されることを検知したとき、前記特定された宛先シーケンス番号範囲に対して前記受信の完了を判定する
    ことを特徴とする請求項２に記載のデータ受信装置。
  5. 前記宛先シーケンス番号範囲特定手段が宛先シーケンス番号範囲を特定したとき、その時点での前記受信シーケンス番号範囲情報を記憶する、受信シーケンス番号一時記憶手段を、さらに備え、
    前記データコピー手段は、前記一時受信シーケンス番号記憶手段が記憶した受信シーケンス番号範囲情報を順次スキャンして、前記特定された宛先シーケンス番号範囲に含まれるデータをコピーする
    ことを特徴とする請求項２に記載のデータ受信装置。
  6. 前記一時バッファ領域は、前記ネットワークを介して受信される前記受信データ列を格納可能な部分領域を複数含み、
    前記データ書き込み手段は、前記一時バッファ領域への書き込みを行うとき、前記複数の部分領域のうち空きの部分領域に書き込みを行い、
    前記受信シーケンス番号記憶手段は、前記空きの部分領域に前記データが書き込まれたとき、前記データの書き込みが行われたアドレスを、前記受信シーケンス番号範囲情報における前記データのシーケンス番号範囲に関連づけて記憶し、
    前記データコピー手段は、コピーすべきデータのシーケンス番号を特定したら、特定したシーケンス番号に対応するアドレスを前記受信シーケンス番号範囲情報から特定し、特定したアドレスに格納されたデータを前記コピーすべきデータとして読み出し、
    前記一時バッファ領域指定手段は、前記部分領域に書き込まれたすべてのデータのコピーが完了したとき、当該部分領域を開放する、
    ことを特徴とする請求項２ないし５のいずれか一項に記載のデータ受信装置。
  7. 前記宛先バッファ領域の指定に応じて前記宛先シーケンス番号範囲が特定されさらに前記コピーが完了するごとに、前記一時バッファ領域に対応する一時シーケンス番号範囲を、前記特定された宛先シーケンス番号範囲に後続するように特定する一時シーケンス番号範囲特定手段と、
    前記データ書き込み手段は、前記一時バッファ領域にデータを書き込むとき、前記一時シーケンス番号範囲における前記データの相対位置に応じた領域に書き込みを行い、
    前記データコピー手段は、前記特定したシーケンス番号の前記一時シーケンス番号範囲における相対位置に応じて定まる領域に格納されたデータを、前記コピーすべきデータとして特定する
    ことを特徴とする請求項２ないし５のいずれか一項に記載のデータ受信装置。
  8. 少なくとも前記データ書き込み手段および前記データコピー手段は、ハードウェアで構成されたことを特徴とする請求項１ないし７のいずれか一項に記載のデータ受信装置。
  9. 各前記宛先バッファ領域と前記一時バッファ領域とを併せた領域のうち空き領域のサイズを、前記受信データ列の送出元に通知する受信バッファサイズ通知手段
    をさらに備えたことを特徴とする請求項１ないし８のいずれか一項に記載のデータ受信装置。
  10. 前記データ記憶手段は単一のメモリデバイスであり、
    前記メモリデバイスの帯域は、前記ネットワークの帯域の３倍以上である
    ことを特徴とする請求項１ないし９のいずれか一項に記載のデータ受信装置。
  11. コンピュータが、
    各々シーケンス番号が対応付けられた一連のデータからなる受信データ列をネットワークを介して順次受信するデータ列受信ステップと、
    データを記憶するデータ記憶装置において、前記受信データ列に含まれるデータを一時的に格納するための一時バッファ領域を指定する一時バッファ領域指定ステップと、
    前記データ記憶装置において、前記受信データ列に含まれるデータを格納するための宛先バッファ領域を複数回指定する宛先バッファ領域指定ステップと、
    前記宛先バッファ領域指定ステップにより前記宛先バッファ領域が指定されたとき、指定された宛先バッファ領域のサイズに応じた宛先シーケンス番号範囲を、前回特定した宛先シーケンス番号範囲に後続するように特定し、特定された前記宛先シーケンス番号範囲に含まれる各シーケンス番号は、前記指定された宛先バッファ領域において、前記特定された宛先シーケンス番号範囲内での相対位置に応じた領域に割り当てられる、宛先シーケンス番号範囲特定ステップと、
    前記データ列受信ステップにより前記受信データ列が受信されたとき、前記受信データ列に含まれる各データのうち、前記宛先シーケンス番号範囲特定ステップにより特定された各前記宛先シーケンス番号範囲のいずれかに含まれるデータは、当該データのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込み、各前記宛先シーケンス番号範囲のいずれにも含まれないデータは前記一時バッファ領域に書き込むデータ書き込みステップと、
    前記宛先バッファ領域指定ステップにより前記宛先バッファ領域が指定されたとき、前記宛先バッファ領域の指定に応じて特定された前記宛先シーケンス番号範囲内にシーケンス番号をもつデータを前記一時バッファ領域から読み出し、読み出しデータを前記読み出しデータのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込むデータコピーステップと、
    を実行するデータ受信方法。
  12. ネットワークを介して受信された、各々シーケンス番号が対応付けられた一連のデータからなる受信データ列を処理するためのデータ処理プログラムであって、
    データを記憶するデータ記憶装置において、前記データを一時的に格納するための一時バッファ領域を指定する一時バッファ領域指定ステップと、
    前記データ記憶装置において、前記データを格納するための宛先バッファ領域を複数回指定する宛先バッファ領域指定ステップと、
    前記宛先バッファ領域指定ステップにより前記宛先バッファ領域が指定されたとき、指定された宛先バッファ領域のサイズに応じた宛先シーケンス番号範囲を、前回特定した宛先シーケンス番号範囲に後続するように特定し、特定された前記宛先シーケンス番号範囲に含まれる各シーケンス番号は、前記指定された宛先バッファ領域において、前記特定された宛先シーケンス番号範囲内での相対位置に応じた領域に割り当てられる、宛先シーケンス番号範囲特定ステップと、
    前記受信データ列が受信されたとき、前記受信データ列に含まれる各データのうち、前記宛先シーケンス番号範囲特定ステップにより特定された各前記宛先シーケンス番号範囲のいずれかに含まれるデータは、当該データのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込み、各前記宛先シーケンス番号範囲のいずれにも含まれないデータは前記一時バッファ領域に書き込むデータ書き込みステップと、
    前記宛先バッファ領域指定ステップにより前記宛先バッファ領域が指定されたとき、前記宛先バッファ領域の指定に応じて特定された前記宛先シーケンス番号範囲内にシーケンス番号をもつデータを前記一時バッファ領域から読み出し、読み出しデータを前記読み出しデータのシーケンス番号に対応する前記宛先バッファ領域の割当領域に書き込むデータコピーステップと、
    をコンピュータに実行させるためのデータ処理プログラム。
JP2008081097A 2008-03-26 2008-03-26 データ受信装置、データ受信方法およびデータ処理プログラム Active JP5049834B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2008081097A JP5049834B2 (ja) 2008-03-26 2008-03-26 データ受信装置、データ受信方法およびデータ処理プログラム
US12/404,616 US9071525B2 (en) 2008-03-26 2009-03-16 Data receiving apparatus, data receiving method, and program storage medium
CN2009101324365A CN101547153B (zh) 2008-03-26 2009-03-26 数据接收设备和数据接收方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008081097A JP5049834B2 (ja) 2008-03-26 2008-03-26 データ受信装置、データ受信方法およびデータ処理プログラム

Publications (2)

Publication Number Publication Date
JP2009237768A JP2009237768A (ja) 2009-10-15
JP5049834B2 true JP5049834B2 (ja) 2012-10-17

Family

ID=41118817

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008081097A Active JP5049834B2 (ja) 2008-03-26 2008-03-26 データ受信装置、データ受信方法およびデータ処理プログラム

Country Status (3)

Country Link
US (1) US9071525B2 (ja)
JP (1) JP5049834B2 (ja)
CN (1) CN101547153B (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011016087A1 (ja) 2009-08-05 2011-02-10 株式会社 東芝 通信装置
JP5481485B2 (ja) 2009-09-16 2014-04-23 株式会社東芝 通信装置とそれを用いた受信処理方法及び送信処理方法
KR101720259B1 (ko) * 2009-12-04 2017-04-10 나파테크 에이/에스 중앙 제어기에 의해 제어되는 데이터 패킷들을 수신 및 저장하는 장치 및 방법
JP5060572B2 (ja) * 2010-03-09 2012-10-31 株式会社東芝 データ通信装置及び方法
DE102010044208A1 (de) * 2010-11-22 2012-05-24 Robert Bosch Gmbh Netzknoten, insbesondere für ein Sensornetzwerk, und Betriebsverfahren für einen Netzknoten
JP5361924B2 (ja) * 2011-02-28 2013-12-04 株式会社東芝 データ送信装置、データ通信装置および通信プログラム
US9124541B2 (en) * 2011-06-30 2015-09-01 Cisco Technology, Inc. Zero copy acceleration for session oriented protocols
JP5788308B2 (ja) * 2011-12-22 2015-09-30 ルネサスエレクトロニクス株式会社 整列回路及び受信装置
JP2018064187A (ja) 2016-10-12 2018-04-19 キヤノン株式会社 通信装置、通信方法およびプログラム
WO2021097802A1 (zh) * 2019-11-22 2021-05-27 华为技术有限公司 处理非缓存写数据请求的方法、缓存器和节点
CN111953618B (zh) * 2020-08-21 2022-07-19 锐捷网络股份有限公司 一种多级并行交换架构下的解乱序方法、装置及系统

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1051491A (ja) * 1996-08-01 1998-02-20 Hitachi Ltd 通信システム、クライアント端末及びデータ送信方法
US8782199B2 (en) 1997-10-14 2014-07-15 A-Tech Llc Parsing a packet header
ATE550852T1 (de) * 2000-09-29 2012-04-15 Alacritech Inc Intelligentes netzwerkspeicherschnittstellensystem und solche einrichtungen
US6741603B2 (en) * 2001-07-09 2004-05-25 Overture Networks, Inc. Use of a circular buffer to assure in-order delivery of packets
JP4511174B2 (ja) * 2001-08-31 2010-07-28 アダプテック・インコーポレイテッド Ｔｃｐ／ｉｐを使用した高速度データ送信システムおよび方法
US7007103B2 (en) * 2002-04-30 2006-02-28 Microsoft Corporation Method to offload a network stack
US7142540B2 (en) * 2002-07-18 2006-11-28 Sun Microsystems, Inc. Method and apparatus for zero-copy receive buffer management
US7336678B2 (en) * 2002-07-31 2008-02-26 Intel Corporation State-based jitter buffer and method of operation
US7346701B2 (en) 2002-08-30 2008-03-18 Broadcom Corporation System and method for TCP offload
US20040044796A1 (en) 2002-09-03 2004-03-04 Vangal Sriram R. Tracking out-of-order packets
CN1540523A (zh) * 2003-10-30 2004-10-27 中兴通讯股份有限公司 单任务快速缓冲读写方法
KR101158912B1 (ko) * 2003-11-10 2012-06-21 엘지전자 주식회사 Ｈｓｄｐａ시스템에서 윈도우를 이용한 교착회피 방법
RU2360363C2 (ru) * 2003-11-10 2009-06-27 Эл Джи Электроникс Инк. Способ обновления данных о порядковом номере следующей ожидаемой передачи и окна получателя, чтобы избежать состояния останова
AU2004310062B2 (en) * 2003-12-31 2008-04-03 Samsung Electronics Co., Ltd. Selective combining method and apparatus in a mobile communication system
US7522606B1 (en) * 2004-11-09 2009-04-21 Network Equipment Technologies, Inc. Passive packet re-ordering and packet loss detection
US7573884B2 (en) * 2006-03-06 2009-08-11 Texas Instruments Incorporated Cable modem downstream channel bonding re-sequencing mechanism

Also Published As

Publication number Publication date
US20090248891A1 (en) 2009-10-01
US9071525B2 (en) 2015-06-30
CN101547153A (zh) 2009-09-30
JP2009237768A (ja) 2009-10-15
CN101547153B (zh) 2012-10-03

Similar Documents

Publication Publication Date Title
JP5049834B2 (ja) データ受信装置、データ受信方法およびデータ処理プログラム
TWI332150B (en) Processing data for a tcp connection using an offload unit
JP4160642B2 (ja) ネットワークデータ転送方法
US20100121995A1 (en) System and method for supporting tcp out-of-order receive data using generic buffer
JP4872952B2 (ja) Ｔｃｐバッファコピー分散並列処理装置、方法及びプログラム
CN109936510A (zh) 多路径rdma传输
US20030051076A1 (en) Methods and system for pre-fetching descriptors
JP2000132443A (ja) コンピュータ、情報共有システム、及びレプリカ同一性保持方法
JP2007202159A (ja) Ｐｐｐマルチリンクをサポートするシステムにおけるマルチキャストトラフィックフォーワーディング装置及び制御方法
EP1589424A2 (en) Vertical perimeter framework for providing application services in multi-CPU environments
US20080263171A1 (en) Peripheral device that DMAS the same data to different locations in a computer
JP2019106697A (ja) 相互接続ネットワークでのメッセージ再送遅延を動的に管理するための方法及びデバイス
JP2008205890A (ja) ルーティング方法およびノード
JP2002312262A (ja) 遠隔要求を処理する方法および装置
US11336297B2 (en) DMA transfer apparatus, method of controlling the same, communication apparatus, method of controlling the same, and non-transitory computer-readable storage medium
JP2003152787A (ja) 複数経路ファイル伝送装置
JP2007235674A (ja) 通信装置および通信方法
JP2014515195A (ja) 再送制御システム及び再送制御方法
CN110169023A (zh) 一种数据传输方法、数据接收设备及数据发送设备
US20060067311A1 (en) Method of processing packet data at a high speed
CN109688085B (zh) 传输控制协议代理方法、存储介质及服务器
JP2009199281A (ja) データ送信装置
JP6618330B2 (ja) 通信装置及びその方法、コンピュータプログラム
EP3229145A1 (en) Parallel processing apparatus and communication control method
US20170265103A1 (en) Communication device, communication method, and non-transitory computer readable medium

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20101021

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120210

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120413

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120509

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: 20120626

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120723

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150727

Year of fee payment: 3

R151 Written notification of patent or utility model registration

Ref document number: 5049834

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151