JP2020136883A - 通信装置、通信装置の制御方法およびプログラム - Google Patents

通信装置、通信装置の制御方法およびプログラム Download PDF

Info

Publication number
JP2020136883A
JP2020136883A JP2019027378A JP2019027378A JP2020136883A JP 2020136883 A JP2020136883 A JP 2020136883A JP 2019027378 A JP2019027378 A JP 2019027378A JP 2019027378 A JP2019027378 A JP 2019027378A JP 2020136883 A JP2020136883 A JP 2020136883A
Authority
JP
Japan
Prior art keywords
header
tcp
packets
packet
payload
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.)
Granted
Application number
JP2019027378A
Other languages
English (en)
Other versions
JP6891201B2 (ja
Inventor
浩二 中禮
Koji Churei
浩二 中禮
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.)
Canon Inc
Original Assignee
Canon Inc
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 Canon Inc filed Critical Canon Inc
Priority to JP2019027378A priority Critical patent/JP6891201B2/ja
Publication of JP2020136883A publication Critical patent/JP2020136883A/ja
Application granted granted Critical
Publication of JP6891201B2 publication Critical patent/JP6891201B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】複数のパケットを一括して生成および送信する際に、通信スループットの低下を有効に防止してパケットをより効率的に送信する。【解決手段】通信装置は、複数のパケットのそれぞれに付加すべきTCPヘッダのヘッダ長を算出し、算出されたTCPヘッダのヘッダ長と、複数のパケットを送信すべきコネクションにおける最大セグメントサイズとに基づいて、送信バッファの複数の領域のそれぞれに格納すべきペイロードのペイロード長を決定し、送信バッファの複数の領域のいずれかにTCP/IPヘッダを格納するとともに、決定されたペイロード長で送信データを分割し、分割された送信データを送信バッファの複数の領域の他の領域にペイロードとしてそれぞれ格納し、送信バッファに格納されたTCP/IPヘッダおよび送信データを入力として、当該入力されたTCP/IPヘッダおよび送信データに基づいて複数のパケットを生成する。【選択図】図6

Description

本発明は、複数パケットを生成および送信可能な通信装置に関する。
ネットワーク通信において、TCP(Transmission Control Protocol)/IP(Internet Protocol)による通信が広く利用されている。このTCP/IPは、例えばカメラやスマートフォン等の端末から画像や動画をクラウドサーバへアップロードする等の大容量データ通信でも利用されているため、近年ではより高速で通信可能であることが要請されている。
パケットを通信対向装置へ送信するTCP/IPプロトコル処理では、まず、アプリケーションからソケットAPIのsend()コールによって指定されたユーザデータが、送信バッファ(ネットワークバッファ)に転送される。次に、送信バッファに転送され格納されたユーザデータを、典型的にはユーザデータの送信単位であるMSS(Maximum Segment Size)で切り出す。切り出されたユーザデータ(ペイロード)に対してTCPヘッダおよびIPヘッダ等を付加することでパケットが生成される。
上記のTCP/IPプロトコル処理に伴うCPU(Central Processing Unit)の負荷を軽減し、パケット送信処理を高速化する技術の1つに、TSO(TCP Segmentation Offload)処理がある。
このTSO処理では、上記のMSSに基づいたパケット単位でのTCP/IPプロトコル処理を行わない。すなわち、TSO処理では、送信バッファに転送されたユーザデータを送信単位であるMSSより大きなサイズで読み出してTCP/IPプロトコル処理を行った後にMSSに基づいてパケット単位に分割することで、複数のパケットを一度に生成する。TSO処理により複数のパケットを生成することで、パケットごとに実行していたTCP/IPプロトコル処理が、複数パケットに1回の実行に軽減されることとなり、CPUの負荷を軽減するとともにパケット送信処理を高速化することが実現できる。
また、複数パケットへの分割処理を、CPUにより実行されるソフトウエア処理から、例えばNIC(Network Interface Card)上に搭載されたハードウエアオフローダへオフロードして高速化することも可能である。
特許文献1は、TSO処理を利用するか否かを、パケットロスの有無やアプリケーションに応じて、TCPセッション(アプリケーション)単位で制御することの可能なTCP送信制御装置を開示する。
WO2010/073671号公報
ところで、TCPプロトコルでは、TCPオプションヘッダのペイロードへの付加を許容している。しかしながら、このTCPオプションヘッダをペイロードへ付加すべき場合に、単純にMSSに基づいて複数パケットへ分割すると、最大転送単位であるMTU(Maximum Transmission Unit)を超えるパケットが生成され得る。例えば、ペイロードサイズであるMSSが、最大転送単位であるMTUからTCPヘッダおよびIPヘッダのサイズを減じた値に設定されている場合、さらにTCPオプションヘッダが付加されることにより、IPパケット全体のサイズがMTUを超えてしまう。
このようにMTUのサイズを超過したIPパケットは、一度に送信することができないため、IPフラグメンテーション処理が実行される。すなわち、MTUのサイズを超過したIPパケットは、送信側で複数のIPパケットに分割した後に送信され、受信側で受信された複数のIPパケットから元のIPパケットへ再構成しなければならない。
パケットの送信側および受信側でこうしたIPフラグメンテーション処理が付加されることで、通信スループットの低下を招いてしまう。
本発明は、上述の課題に鑑みてなされたものであり、複数のパケットを一括して生成および送信する際に、通信スループットの低下を有効に防止してパケットをより効率的に送信することを目的とする。
上記課題を解決するため、本発明に係る通信装置は、複数の領域を含む送信バッファと、前記送信バッファに格納されたTCP/IPヘッダおよび送信データを入力として、当該入力されたTCP/IPヘッダおよび送信データに基づいて複数のパケットを生成する生成手段と、前記複数のパケットのそれぞれに付加すべきTCP/IPヘッダのうち、TCPヘッダのヘッダ長を算出する算出手段と、前記算出手段により算出された前記TCPヘッダの前記ヘッダ長と、前記複数のパケットを送信すべきコネクションにおける最大セグメントサイズとに基づいて、前記送信バッファの前記複数の領域のそれぞれに格納すべきペイロードのペイロード長を決定する決定手段と、前記決定手段により決定された前記ペイロード長で前記送信データを分割し、分割された送信データを前記送信バッファの前記複数の領域に前記ペイロードとしてそれぞれ格納して、前記生成手段に、前記決定手段により決定された前記ペイロード長で前記複数のパケットを生成させるよう制御する制御手段と、を備える。
本発明によれば、複数のパケットを一括して生成および送信する際に、通信スループットの低下を有効に防止してパケットをより効率的に送信することができる。
本実施形態に係る通信装置1のハードウエアおよび機能構成の一例を示すブロック図 実施形態1における通信装置1のネットワークバッファ34内におけるラージパケットの構成例を示す図 TCPオプションであるSACK(Selective ACK)が有効な場合のパケットおよびACKの送受信処理のシーケンスの一例を示す図 通信装置1におけるパケット生成および送信処理のシーケンスの一例を示す図 実施形態1における通信装置1のパケット生成および送信処理の詳細処理手順の一例を示すフローチャート 実施形態2における通信装置1のパケット生成および送信処理の詳細処理手順の一例を示すフローチャート 実施形態2における通信装置1のネットワークバッファ34におけるラージパケットの構成例を示す図
以下、添付図面を参照して、本発明を実施するための実施形態について詳細に説明する。なお、以下に説明する実施形態は、本発明の実現手段としての一例であり、本発明が適用される装置の構成や各種条件によって適宜修正又は変更されるべきものであり、本発明は以下の実施形態に必ずしも限定されるものではない。また、本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の構成については、同じ符号を付して説明する。
以下、通信装置が、送信バッファのユーザデータから複数のパケットを一括生成する処理を実行する例を説明する。当該処理は例えば、TSO(TCP Segmentation Offload)を使用してオフロード実行されてよい。
また、パケット生成の際に送信データに付加されるヘッダは、TCPヘッダ、IPヘッダおよびEther(Ethernet(登録商標))ヘッダを含んでよい。これらTCpヘッダ、IPヘッダ、およびEtherヘッダのうち1つ以上を、以下、プロトコルヘッダともいう。プロトコルヘッダとは、通信プロトコル処理において処理されるヘッダである。IPヘッダおよびTCPヘッダは、以下、TCP/IPヘッダとも総称される。
(実施形態1)
<本実施形態のハードウエアおよび機能構成>
図1は、本実施形態に係る通信装置のハードウエア構成および機能構成の一例を示す図である。
図1に示す通信装置1の各機能モジュールのうち、ソフトウエアにより実現される機能については、各機能モジュールの機能を提供するためのプログラムがROM等のメモリに記憶され、RAMに読み出してCPUが実行することにより実現される。ハードウエアにより実現される機能については、例えば、所定のコンパイラを用いることで、各機能モジュールの機能を実現するためのプログラムからFPGA上に自動的に専用回路を生成すればよい。FPGAとは、Field Programmable Gate Arrayの略である。また、FPGAと同様にしてGate Array回路を形成し、ハードウエアとして実現するようにしてもよい。また、ASIC(Application Specific Integrated Circuit)により実現するようにしてもよい。なお、図1に示した機能ブロックの構成は一例であり、複数の機能ブロックが1つの機能ブロックを構成するようにしてもよいし、いずれかの機能ブロックが複数の機能を行うブロックに分かれてもよい。
通信装置1は、主処理部2、および通信処理部3を備える。主処理部2は、各種アプリケーションを含む、通信装置1の全体の処理を実行する。通信処理部3は、例えばTCP/IP等の通信プロトコル処理を含む各種通信処理や制御を実行する。主処理部2および通信処理部3は、バスブリッジ4により相互接続されている。
主処理部2は、メインCPU21、メインメモリ22、およびメインバス23を備える。
メインCPU21は、各種プログラムの実行を行うとともに、通信装置1の全体を制御する。メインCPU21により実行されるプログラムには、OS(Operating System)や各種アプリケーションが含まれる。
メインメモリ22は、メインCPU21や通信処理部3のサブCPU31が各処理を実行する上で必要となるデータやプログラムなどを格納する。このメインメモリ22は、例えば、DRAM(Dynamic Random Access Memory)等の半導体メモリで構成されてよい。
メインメモリ22内部には、メインCPU21によりユーザバッファ24が構成され、このユーザバッファ24にユーザデータが格納される。ユーザバッファ24は、メインCPU21の他、サブCPU31からもバスブリッジ4およびメインバス23を介してアクセス可能な領域とされる。ユーザバッファ23に格納されるユーザデータは、メインCPU21が通信装置1のアプリケーションからネットワーク5を介して通信対向装置へ送出したいデータを含む。以下、ユーザデータを、送信データ、または単に、データともいう。
メインバス24は、メインCPU21からメインメモリ22および通信処理部3へのアクセスおよびデータ転送、または通信処理部3からメインメモリ22へのアクセスおよびデータ転送などに使用される。
通信処理部3は、サブCPU31、オンチップメモリ33、データ転送部35、パケット生成部36、LAN制御部37、WLAN制御部38、およびローカルバス39を備える。
サブCPU31は、各種通信処理に関するプログラムの実行を行う。サブCPU31により実行されるプログラムは、OSおよび通信プロトコル処理のための通信プロトコルスタックを含む。本実施形態では、通信プロトコル処理として、TCP/IPプロトコルスタックが実行される例を説明するが、他のプロトコルスタックであってもよい。
サブCPU31は、ペイロードサイズ決定部32を備える。
オンチップメモリ33は、例えば、ASICやFPGA内に構成される内部メモリである。オンチップメモリ33は、通信処理部3のサブCPU31、データ転送部35、パケット生成部36からアクセス可能なメモリである。このオンチップメモリ33は、例えばSRAM(Static Random Access Memory)等の半導体メモリで構成されてよく、これによりメインメモリ22より高速にアクセスされることが可能となる。また、オンチップメモリ33は、NIC(Network Interface Card)上に構成されるメモリデバイスであってもよい。
オンチップメモリ33内部には、サブCPU31により複数のネットワークバッファ34が構成される。これらのネットワークバッファ34は、サブCPU31が通信対向装置との間で送受信されるデータを処理する際に使用される送信バッファである。
ネットワークバッファ34は、送信バッファが必要になったタイミングでオンチップメモリ33に動的に獲得され、データ送信処理が終了して不要になった際に開放される。また、ネットワークバッファ34はそれぞれ、データ領域とネクストバッファ領域を持つ。 各ネットワークバッファ34内のネクストバッファ領域に、別のネットワークバッファのアドレス(ポインタ)を指定する。これにより、複数のネットワークバッファを連結して各ネットワークバッファ34のサイズより大きい送信データをパケット生成部36へ受け渡すことができる。このネットワークバッファ34の詳細は図2を参照して後述する。
データ転送部35は、メインCPU21、サブCPU31およびパケット生成部36からの指示に従って、各種データ転送を実行することが可能である。データ転送部35は、例えば、メインメモリ22に格納されているデータを、パケット生成部36またはオンチップメモリ33へ転送する。なお、データ転送部35が実行する処理の全部または一部は、DMAC(Direct Memory Access Controller)に実装してオフロード実行されてもよい。
パケット生成部36は、サブCPU31から、複数パケット生成処理を実行させるため入力されるラージパケットに基づいて、ネットワークバッファ34に格納されているユーザデータ(ペイロード)をパケット化する。ラージパケットとは、サブCPU31からパケット生成部36に入力される、複数のネットワークバッファ34を連結して格納することができる大きいサイズの送信データである。
まず、パケット生成部36は、サブCPU31から入力される、ラージパケットを構成する先頭のネットワークバッファ34に格納されるTCP/IPのヘッダ情報に基づいて、複数のパケットのための複数のヘッダを生成する。具体的には、パケット生成部36は、先頭のネットワークバッファ34に格納されるラージパケットのTCP/IPヘッダを複製し、パケットごとに値が異なるフィールドを書き換えることで、複数のヘッダを生成する。
例えば、ヘッダ内のIPアドレス情報やポート番号情報は、ラージパケットのTCP/IPヘッダ内の値が複製されるが、TCPシーケンス番号は、パケット生成部36により書き換えられる。ラージパケットに含まれるTCPシーケンス番号は先頭パケットのシーケンス番号であるため、分割されたパケットの各ペイロードサイズから次パケット以降のシーケンス番号が計算されるからである。
パケット生成部36が生成した複数のヘッダは、パケット生成部36の内蔵メモリへ格納してもよく、オンチップメモリ33上にヘッダ格納用に獲得されたネットワークバッファ34へ格納してもよい。サブCPU31は、生成されたヘッダと、各ヘッダに対応するネットワークバッファ34上の送信データ(ペイロード)とを連結することにより、パケット生成部36を介してネットワークへ送信すべき複数のパケットを生成する。
なお、パケット生成部36が実行する処理の全部または一部は、TSO(TCP Segmentation Offload)のオフローダに実装してオフロード実行することができる。このTSOは、例えばNIC上にハードウェアオフローダとして実装されてよい。
ローカルバス39は、通信処理部3の各機能ブロックを相互接続するとともに、メインバス23にバスブリッジ4を介して接続する。
LAN(Local Area Network)制御部37は、ネットワーク5へ接続する有線通信インターフェースであり、パケットの送受信を実行する。このLAN制御部37は、伝送メディアのPHYレイヤおよびMACレイヤ(伝送メディア制御)のハードウェア回路を含む。例えば、LAN制御部37のインターフェースがEthernet(登録商標)である場合、LAN制御部37は、イーサネット(登録商標)NIC(Network Interface Card)に相当する。
WLAN(Wireless LAN)制御部38は、ネットワーク5に接続する無線通信インターフェースであり、パケットの送受信を実行する。このWLAN制御部38は、IEEE802.11a/b/g/n/ac等の無線LAN制御を実行するコントローラおよびRF(Radio Frequency)回路を含む。
パケット生成部36およびサブCPU31により生成された複数のパケットは、LAN制御部37やWLAN制御部38等の通信制御部に受け渡されて、ネットワーク5へ送出される。
<ペイロードサイズ決定処理>
サブCPU31のペイロードサイズ決定部32は、これから送信すべきパケットのTCP/IPプロトコルのオプションヘッダのサイズに基づいて、ラージパケットを複数のパケットに分割する際のデータ分割サイズを決定する。
具体的には、ペイロードサイズ決定部32は、MSS(Maximum Segment Size)から、TCPオプションヘッダのサイズを除いたサイズを、データ分割サイズとして決定する。MSSは、TCPセッション等の通信セッションの確立時に設定される、ユーザデータの送信単位(セグメント)の最大値、すなわち当該TCPセッションで送信可能な最大セグメントサイズである。通常、このMSSは、通信対向装置から当該装置が受信できるセグメントの最大値として、コネクション確立時にTCPオプションで通知される。
サブCPU31は、パケット生成部36に複数パケット生成処理を実行させるための入力情報を生成する。サブCPU31はまた、パケット生成部36が複数のパケットのそれぞれに付加すべき複数のTCP/IPヘッダを複製により生成するためのTCP/IPヘッダの情報をパケット生成部36に入力する。
本実施形態では、パケット生成部36にパケット分割させるため入力される入力情報を、ラージパケットという。このラージパケットを複数のネットワークバッファ34を連結して生成し、パケット生成部36へ入力することで、パケット生成部36を介して、1つのラージパケットが分割された複数のパケットを生成することができる。
図2は、通信装置1のオンチップメモリ33のネットワークバッファ34上に、サブCPU31により構成される、ラージパケットの構成例を示す。
ラージパケットは、これから送信しようとする複数パケット分のペイロードと、このペイロードに対応する一組のTCPヘッダおよびIPヘッダとが連結されて成るTCP/IPパケットの構成を有する。
図2に示すように、ラージパケットは、複数のネットワークバッファNB1〜NB4が連結された領域に格納される。TCP/IPヘッダが格納されるネットワークバッファNB1と、各ペイロードが格納されるネットワークバッファNB2〜NB4とは、それぞれ別個のバッファである。各ネットワークバッファNB1〜NB4に設けられたネクストバッファの領域に、当該バッファに連結されるべき次のバッファのアドレスを設定することで、複数のネットワークバッファNB1〜NB4が連結される。
なお、各ネットワークバッファNB1〜NB4は、必ずしもオンチップメモリ33上の連続する領域に配置される必要はない。また、図2には4つのネットワークバッファNB1〜NB4が図示されているが、ネットワークバッファの数は4つに限定されず、送信されるべきユーザデータ長やコネクションの情報等に基づいて適宜その数が決定されてよい。
先頭のネットワークバッファNB1には、TCP/IPヘッダ(IPヘッダおよびTCPヘッダ)が格納される。先頭のネットワークバッファNB1にはまた、TCPオプションヘッダも格納される。図2では、TCP/IPヘッダに連続するTCPオプションヘッダとして、SACK(Selective ACK)ブロックのオプションヘッダが格納されている。
ラージパケットが持つTCP/IPヘッダに含まれる情報は、ラージパケットが複数のパケットに分割された際の先頭のパケットに対応した値となっている。また、ラージパケット内の複数のペイロードのそれぞれ(ペイロード1〜3)は、ペイロードサイズ決定部32により決定されたデータ分割サイズを最大値として、各ネットワークバッファNB2〜NB4に格納されている。
図2に示すラージパケットは、3パケット分のペイロードを含む。ペイロード1およびペイロード2は、ペイロードサイズ決定部32により決定されたデータ分割サイズに相当するサイズを有する。一方、ペイロード3は、ペイロードサイズ決定部32により決定されたデータ分割サイズに満たないサイズを有する。
図2にTCPオプションヘッダとして図示されるSACKブロックは、TCPのオプションであるSACK(Selective ACK)が有効である場合に、ペイロードの前に付加されるTCPオプションヘッダの1つである。データ送信に応答する通常のACKは、ACK番号までのデータがすべて受信されたことを通知するが、一方、SACKを有効にしたACK(SACK)は、部分的にデータが受信されたことを通知することができる。SACKオプションを有効にして、SACKによりデータ受信の確認応答を送信することで、データの再送効率を上げることができる。
図3は、TCPのオプションであるSACKが送信側および受信側の双方でサポートされており有効である場合の、データ受信およびACK送信のシーケンスの一例を示す。
データ送信側装置311から、5つの連続する送信データ(Seq=100、200、300、400)が対向するデータ受信側装置312に送信され、そのうち送信データ(Seq=300)がデータ受信側装置312に未達であるとする。
これに対して、データ受信側装置312が、SACKが有効である場合に、SACK(Ack=300、SLE=400、SRE=500)を送信したものとする。
この場合、データ送信側装置311は、Seq=300のデータのみを再送すればよく、データ受信側装置312にすでに受信された後続するSeq=400のデータは再送する必要がない。このため、SACKが無効である場合にSeq=300、およびSeq=400のデータのデータを再送しなければならないことと比較して、再送効率が向上する。
SACKが有効である場合、パケットに付加されるべきTCPオプションヘッダとしてのSACKブロックが付加されるが、このSACKブロックのサイズ(SACKブロック長)は、データ受信側装置312のデータ受信状況により可変である。具体的には、SACKブロック長は、4+8*n(n=1〜4)バイトで算出されるため、TCPオプションヘッダのサイズは、+12バイトから+36バイトまで変動する。
このため、TCPオプションヘッダであるSACKブロックが付加されたために、IPパケット全体のサイズがネットワーク上の最大転送単位であるMTU(Maximum Transmission Unit)を超過してしまう場合がある。
例えば、MTUのサイズが1500バイトである場合に、MSSのサイズをTCP/IPパケット長の40バイトを減算した1460バイトとしているものとする。この場合、ペイロードをMSSのサイズで区切っていると、TCP/IPパケットにSACKブロックのTCPオプションヘッダが付加されることで、IPパケット全体のサイズがMTUを超えて、IPフラグメンテーションが発生する。すなわち、MTUのサイズを超過したIPパケットは、送信側で複数のIPパケットに分割した後に送信され、受信側で受信された複数のIPパケットから元のIPパケットへ再構成しなければならなず、通信スループットの低下を招いてしまう。
本実施形態では、このようなIPフラグメンテーションが発生しないように、サブCPU31のペイロードサイズ決定部32が、ペイロードサイズを決定する。
なお、上記では、ペイロードサイズ決定部32が、TCPオプションヘッダとしてのSACKブロック長に基づいて、MSSからSACKブロック長を減算してデータ分割サイズとして決定する例を説明したが、本実施形態はこれに限定されない。例えば、ペイロードサイズ決定部32は、SACKブロック以外のTCPオプションヘッダのヘッダ長を算出して、データ分割サイズを決定してもよく、IPオプションヘッダのヘッダ長を算出して、データ分割サイズを決定してもよい。例えば、ペイロードサイズ決定部32は、IPv6オプションヘッダとしてのホップバイホップルーティングヘッダのヘッダ長に基づいてデータ分割サイズを決定することができる。
<通信装置1のパケット生成および送信処理シーケンス例>
図4は、通信装置1がネットワーク5を介して通信対向装置へパケットを生成して送信する送信処理のシーケンスの一例を示す。
S41で、メインCPU21は、メインメモリ22内のユーザバッファ24へユーザデータを格納する。
S42で、メインCPU21は、アプリケーションからのユーザデータの送信要求として、ソケットAPIであるsend()を呼び出す。
S42でsend()の呼び出しが実行されると、サブCPU31は、パケット送信のため、データ転送処理を開始するが、まず、ユーザバッファ24からネットワークバッファ34へユーザデータをコピーする。
このユーザデータのネットワークバッファ34へのコピーを実行するため、S43で、サブCPU31は、まず、オンチップメモリ33のネットワークバッファ34用の領域から、ユーザデータ送信に必要なサイズ分のネットワークバッファ34を獲得する。複数のバッファを獲得する場合、獲得された複数のバッファは、バッファ情報のネクストバッファ領域に次バッファのアドレスを設定することにより全て連結された状態となる。
S44で、サブCPU31は、獲得されたネットワークバッファ34に対して、ユーザバッファ24からユーザデータをコピー(転送)するように、データ転送部35へ要求する。
ユーザデータのコピーを要求されたデータ転送部35は、S45で、ユーザバッファ24からユーザデータを読み出し、ラージパケットを生成するため、ネットワークバッファ34内の各バッファ領域へ分割して転送する。
S45のネットワークバッファ34へのデータ転送が完了すると、S46で、データ転送部35は、ユーザデータのデータ転送完了をサブCPU31へ通知する。
ユーザデータのネットワークバッファ34へのデータ転送完了が通知されると、S47で、サブCPU31は、これから送信すべきユーザデータの送信サイズを決定する。
TCPプロトコルにおける通信では、通信を行っているアプリケーションごとにコネクションが異なり、コネクションごとにウィンドウサイズ、MSS、通信対向装置からのデータ受信状況等が管理されている。
本実施形態では、サブCPU31が各コネクションの管理を実行し、各コネクションのコネクション情報は、メインメモリ22に格納されている。
S47では、サブCPU31は、コネクション情報を参照して得られる送信ウインドウサイズ、輻輳ウィンドウサイズと、S45でネットワークバッファ34にコピーしたユーザデータのサイズを比較し、最も小さいサイズを送信サイズとして決定する。
S48で、サブCPU31は、複数パケットの生成処理を開始する。
具体的には、まず、サブCPU31内のペイロードサイズ決定部32により、ユーザデータからパケット生成部36に複数のパケットを一括生成させる際のデータ分割サイズを決定する。
ペイロードサイズ決定部32は、生成される複数のパケットが送信されるべきコネクションのコネクション情報を参照して、TCPオプションヘッダのサイズとMSSから、データ分割サイズを決定する。
ペイロードサイズ決定部32は、コネクション情報を参照し、TCPのSACKオプションが有効である場合は、通信対向装置からのデータ受信状況を確認して、SACKオプション長を算出する。
SACKオプションは、上述のとおり、通信相手からの送信データが部分的に受信できている場合に、受信できているデータ区間をAck番号等のパラメータにより通信相手に通知するTCPのオプションである。SACKを受信した通信相手は、SACKで通知されたデータ区間以外のデータのみを再送すればよいため、再送効率を上げることができる。
ペイロードサイズ決定部32は、S48で、MSSからSACKオプション長を除いたサイズをデータ分割サイズとして決定する。サブCPU31は、送信データを、ペイロードサイズ決定部32により決定されたデータ分割サイズ分ずつ分割して、パケット生成部36に入力すべき入力情報であるラージパケットを生成する。
S49で、サブCPU31は、ネットワークバッファ34から、これからパケット生成部36により生成されるヘッダを格納するためのネットワークバッファ34を獲得する。
なお、S49でヘッダを格納するために獲得するネットワークバッファ34のデータエリアは、S43で獲得されるユーザデータを格納するネットワークバッファ34のデータエリアより小さいサイズに制限してもよい。
S50で、サブCPU31は、パケット生成部36へ、複数パケット生成処理を要求する。複数パケット生成処理は、TSO処理で実行されてよい。この複数パケット生成処理の要求は、パケット生成部36へラージパケットを指定することで実行され、一方、S48で通常パケットが生成されていた場合には、パケット生成部36への複数パケット生成要求は実行されない。
サブCPU31はさらに、パケット生成部36にTCP/IPヘッダを複製により生成させるための情報として、ラージパケットに対するTCP/IPヘッダの情報を生成してパケット生成部36へ受け渡す。本実施形態において、このラージパケットに対するTCP/IPヘッダの情報は、例えば、上記のTCPオプションヘッダとしてのSACKブロックの情報を含む。
パケット生成に必要な情報を設定した後、S50で、サブCPU31は、パケット生成部36へパケット生成要求を行う。
S51で、パケット生成部36は、S50でサブCPU31から設定されたラージパケットを分割し、受け渡されたラージパケットに対するTCP/IPヘッダの情報から複数のTCP/IPヘッダを生成して、複数のパケットを生成する。
具体的には、パケット生成部36は、ヘッダ生成に必要な情報のうち、送信元、宛先IPアドレス、送信先、宛先ポート番号等、複数のパケット間で変化のないヘッダフィールドについては、全てラージパケットのヘッダを複製することでヘッダを生成する。
一方、パケット生成部36は、例えば、IPv4ヘッダにおけるチェックサム、データグラム長、TCPヘッダにおけるシーケンス番号、チェックサム等、複数のパケット間で変化するヘッダフィールドはラージパケットのヘッダから内容を変更する。なお、サブCPU31が生成する、ラージパケットに対するTCP/IPヘッダの情報は、テンプレートヘッダともいう。
本実施形態において、パケット生成部36がラージパケットのヘッダを複製して生成する複数のTCP/IPヘッダは、図2のネットワークバッファNB1に示されるラージパケットのヘッダと同様、TCPオプションヘッダ(SACKブロック)を含む。複数のパケットのすべてにTCPオプションヘッダであるSACKブロックが冗長に付加されることで、通信環境が悪い場合であってもデータ送受信の確実性が向上できる。
S52で、パケット生成部36は、生成した複数のヘッダをS49で獲得したネットワークバッファ34の領域へ格納するよう、データ転送部35に指示する。データ転送部35は、格納を指示された複数のヘッダをネットワークバッファ34へ格納する。
生成された複数のヘッダがネットワークバッファ34に格納されると、S53で、データ転送部35は、パケット生成部36へ、生成された複数のヘッダのネットワークバッファ34への格納(書き込み)完了を通知する。
複数のヘッダのネットワークバッファ34への格納完了を通知されると、パケット生成部36は、生成された各ヘッダと対応する各ペイロードとをそれぞれ連結してパケットを生成するために、バッファ情報を更新する。具体的には、パケット生成部36は、ヘッダが格納されたネットワークバッファ34の次バッファアドレスへ、ペイロードが格納されたアドレスを設定することで、1つのパケットを形成することができる。同様の処理を、パケット数分繰り返し実行する。これにより、複数のパケットが生成される。なお、複数のヘッダから複数のパケットを生成する上記処理は、パケット生成部36に替えてその全部または一部をサブCPU31により実行されてもよい。
S54で、パケット生成部36は、複数のヘッダの生成が完了したことをサブCPU31へ通知する。
S54で複数パケットの生成が完了すると、S55で、サブCPU31は、パケット送信処理を開始する。
S56で、サブCPU31は、複数のパケットを連結した送信要求をWLAN制御部38へ通知する。
複数パケットの送信要求が通知されたWLAN制御部38は、S57で、ネットワークバッファ34上に格納されている複数のパケット(パケット群)を読み出して、ネットワーク5へ送信する。
S58で、WLAN制御部38は、全てのパケットの送信を完了すると、パケット送信の完了をサブCPU31へ通知する。なお、上記ではWLAN制御部38によりパケットを送信する例を説明したが、これに替えてLAN制御部37が同様にパケット送信してもよい。
上記のS47からS58までの処理が、一連の複数のパケット生成および送信処理に相当する。ネットワークバッファ34へコピーされたユーザデータを全て送信するまで、S47からS58の処理は繰り返される。
ネットワークバッファ34へコピーされたユーザデータがすべてパケットとして送信されると、S59で、サブCPU31は、メインCPU21に対し、send()コールが成功した旨の応答を通知する。
<通信装置1のパケット送信処理フロー>
図5は、本実施形態において通信装置1のサブCPU31が実行および制御するパケット送信処理の処理手順の一例を示すフローチャートである。図5に示す処理は、図4に示すS43からS58の処理に相当する。図5のパケット送信処理は、例えば、アプリケーションからユーザデータの送信を指示されたことを契機に起動されてよいが、これに限定されない。
S501で、アプリケーションからソケットAPIのsend()の実行を介して呼び出されることにより、サブCPU31は、パケット送信処理を開始し、ユーザバッファ24からネットワークバッファ34へ、ユーザデータをコピーする(図4のS43からS46に相当)。
S502で、サブCPU31は、ネットワークバッファ34にコピーしたユーザデータにつき、これから送信する送信サイズを決定する(図4のS47に相当)。
S503で、サブCPU31は、アプリケーションからのsend()で使用されるTCPコネクションのコネクション情報を参照して、当該TCPコネクションにおいてSACKオプションが有効になっているか否かを判定する。SACKオプションの設定は、コネクション確立時に決定されており、当該コネクションのコネクション情報を参照することにより有効化されているか無効化されているかを判定することができる。
当該TCPコネクションでSACKオプションが有効になっている場合(S503:Y)、S504に進み、一方、SACKオプションが無効になっている場合(S503:N)、S504をスキップしてS505に進む。
S504で、サブCPU31は、TCPヘッダに付加されるSACKブロック長を算出する。SACKは通信対向装置から受信されたデータが不連続になっている場合に使用され、SACKブロック長は可変であって、SACKブロックはTCPヘッダに最大4つまで付加可能である。
なお、SACKオプションが有効であっても、通信対向装置から受信されたデータが連続して受信でている場合等、付加するべきSACKブロックがない場合、SACK長は0となる。
S505で、サブCPU31のペイロードサイズ決定部32は、データ分割サイズを算出する。データ分割サイズは、send()で使用されるTCPコネクションに設定されているMSSから、S504で算出されたSACKブロック長を減算することで算出することができる。なお、SACKオプションが無効であるTCPコネクションについては、当該TCPコネクションのMSSに設定された値をそのままデータ分割サイズとすればよい。
S506で、サブCPU31は、S502で決定された送信サイズとS505で算出されたデータ分割サイズとを比較する。
送信サイズがデータ分割サイズより大きい場合(S506:Y)、S507に進んでラージパケットを生成する。一方、送信サイズがデータ分割サイズ以下である場合(S506:N)、すなわち、データ分割サイズで区切られるペイロード長以下である場合、S508に分岐して通常のパケットを生成して、S510へ進む。S508では、S502で決定された送信サイズに対応するユーザデータをペイロードとし、サブCPU31が、パケット生成部36を介さずに、ペイロードに対応するTCP/IPヘッダを付加することで通常のパケットを生成する。
S506で送信サイズがデータ分割サイズより大きい場合、S507で、サブCPU31は、データ分割サイズに基づいて、ラージパケットを生成する。
具体的には、サブCPU31は、S502で決定された送信サイズに対応するユーザデータをペイロードとし、このペイロードに対応するTCP/IPヘッダを生成して付加することで、ラージパケットを生成する。なお、S506でラージパケットに付加されるTCPヘッダは、SACKオプションヘッダ(SACKブロック)を含む。
送信サイズは、ラージパケットのペイロードの全長となり、このペイロード全体を、図2に示すようにS505で算出されたデータ分割サイズ(ペイロードサイズ)によって複数のネットワークバッファ34それぞれで区切って、複数のパケットが生成される。
S509で、サブCPU31は、S507で生成されたラージパケットをパケット生成部36に入力して、複数のパケットの一括生成処理を、例えばTSO処理により実行させる。パケット生成部36は、サブCPU31がS507で生成したラージパケットに付加されるTCP/IPヘッダを生成される複数のパケットの数だけ複製する。SACKオプションを含むTCP/IPヘッダは複製されて、複数のパケットのそれぞれに付加される。
S510で、サブCPU31は、S509で生成された複数のパケット、またはS508で生成された通常のパケットのいずれかを、例えばWLAN制御部38を介して外部へ送信する。
S511で、サブCPU31は、S501でネットワークバッファ34へコピーされたユーザデータ中に未送信のユーザデータが存在するか否かを判定する。未送信であるユーザデータがネットワークバッファ34中に存在する場合(S511:Y)、S502に戻ってS502からS511のパケット送信処理が実行される。一方、S501でネットワークバッファ34へコピーされたユーザデータがすべて送信されている場合、パケット送信処理を終了する。
なお、図5のフローではパケット送信処理を開始した後、S504で、パケット生成処理を実行するごとに送信SACKブロック長を算出している。しかしながら本実施形態では、最初に生成すべきパケットに付加すべき送信SACKブロック長を一旦算出した後は、都度送信SACKブロック長を算出することなく、送信SACKブロック長を固定して使用してもよい。
具体的には、初回のパケット生成処理時のみに、MSSからSACKブロック長の最大値(例えば36バイト)を減算することで、データ分割サイズを算出し、初回に算出されたデータ分割サイズを使用してラージパケットを生成する。二回目以降のパケット生成処理では、データ分割サイズを再度算出することなく、初回で算出されたデータ分割サイズを使用すればよい。二回目以降のデータ分割サイズの算出を省略し、ラージパケット生成処理を簡易化することで、サブCPU31のパケット送信に係る負荷が軽減されるとともにパケット送信が高速化できる。
以上説明したように、本実施形態によれば、複数のパケットを一括生成する際に、TCPオプションヘッダ長が付加されても、IPフラグメンテーションの発生が有効に防止された適切なペイロードサイズのパケットを生成することができる。
(実施形態2)
以下、実施形態2を、図6および図7を参照して、上記の実施形態1と異なる点についてのみ詳細に説明する。実施形態1では、パケット生成部36が生成する複数のパケットのそれぞれについて同一のデータ分割サイズを算出した。これに対して、実施形態2では、先頭のパケットについて送信SACKブロック長を考慮してペイロードサイズを算出し、先頭のパケットに対してTCPオプションヘッダであるSACKブロックをTCP/IPヘッダに付加する。一方、2つ目以降のパケットについてはラージパケットをMSSで区切ってペイロードと生成し、TCPオプションヘッダであるSACKブロックはTCP/IPヘッダに付加されない。
実施形態2に係る通信装置1のハードウエア構成および機能構成は、図1に示される実施形態1と同様である。
実施形態2に係る通信装置1が実行するパケット生成および送信処理は、図4に示される実施形態1と同様である。
図6は、本実施形態において、通信装置1のサブCPU31が制御するパケット生成および送信処理の詳細処理手順の一例を示すフローチャートである。
S501〜S504の各処理は、図5に示す実施形態1のS501〜S504の各処理と同様である。
S504でTCPオプションヘッダとして付加されるべき送信SACK長を算出した後、S601で、通信装置1のサブCPU31は、ラージパケットの先頭のペイロードについて、データ分割サイズを算出して、S506へ進む。具体的算出方法は、実施形態1において、図5のS505でサブCPU31が算出するデータ分割サイズの算出方法と同一である。ただし、本実施形態では、S601で算出されたデータ分割サイズは、ラージパケットの先頭のペイロードにのみ適用される。
S506の処理は、図5に示す実施携帯1のS506の処理と同様である。
S506で、S502で決定された送信サイズがS601で算出されたデータ分割サイズより大きいと判定されると(S506:Y)、S602で、サブCPU31は、ラージパケットのヘッダと先頭ペイロードを生成する。
本実施形態において、サブCPU31は、ヘッダ用のネットワークバッファ34に、TCPオプションヘッダであるSACKブロックを含まないTCP/IPヘッダを生成する。
一方、サブCPU31は、先頭ペイロード用のネットワークバッファ34には、まずTCPオプションヘッダであるSACKブロックを生成する。このSACKブロックに加えて、サブCPU31は、送信するユーザデータからS601で決定した先頭ペイロードのためのデータ分割サイズ分のユーザデータを区切ってペイロードとして生成する。
ヘッダ用のネットワークバッファ34は、先頭ペイロード用のネットワークバッファ34へ、ヘッダ用のネットワークバッファ34のネクストバッファ領域に先頭ペイロード用のネットワークバッファ34のアドレス(ポインタ)を指定することにより連結される。
S603で、サブCPU31は、ラージパケットの2つ目以降のペイロードを生成する。これら2つ目以降のペイロードについて、ネットワークバッファ34ごとにユーザデータ(ラージパケット)をMSSで区切ってパケットを生成する。
先頭ペイロード用のネットワークバッファ34と、2つ目以降のペイロード用のネットワークバッファ34の間も、ネクストバッファ領域へ次のネットワークバッファ34のアドレスを指定することにより連結される。残りの送信すべきユーザデータのすべてについてMSSで区切ってパケットを生成することで、ラージパケットの生成が完了する。
図7は、S602およびS603の処理を経てネットワークバッファ34に生成されるラージパケットの構成の一例を示す。
図7を参照して、ヘッダ用のネットワークバッファNB1には、TCPオプションヘッダを含まないTCP/IPヘッダが生成されている。先頭ペイロード用のネットワークバッファNB2には、TCPオプションヘッダであるSACKブロックと、先頭ペイロード用のデータ分割サイズで区切られたペイロード1が格納されている。
一方、2つ目のネットワークバッファNB3、3つ目のネットワークバッファNB4には、MSSで区切られたペイロード2、ペイロード3がそれぞれ格納されている。
図6に戻り、S509で、サブCPU31は、S603で生成されたラージパケットをパケット生成部36へ入力し、複数パケットの一括生成処理を実行させる。
パケット生成部36は、S602でサブCPU31により生成されたヘッダ(TCP/IPヘッダ)を生成する。このため、本実施形態では、パケット生成部36は、TCPオプションヘッダであるSACKブロックを含まないTCP/IPヘッダを複製して、各パケットへ付加する。結果として、先頭のペイロードのネットワークバッファ34(図7のNB1)のみ、TCP/IPヘッダに続いて、TCPオプションヘッダであるSACKブロックが付加されることになる。一方、先頭以外のペイロードのネットワークバッファ34には、TCPオプションヘッダであるSACKブロックは付加されない。
S508〜S511までの各処理は、図5に示すS508〜S511までの処理と同様である。
以上説明したように、本実施形態によれば、複数のパケットを一括生成する際に、先頭パケットにのみSACKブロックを付加しつつ、2つ目以降のパケットについてはSACKブロック長を考慮する場合より長いMSSでユーザデータを区切ることができる。したがって、IPフラグメンテーションの発生を有効に防止しつつ、2つ目以降のパケットをより長いペイロード長で生成することができるため、パケット送信のスループットが向上する。また、パケット受信側におけるSACKの受信処理の負荷も軽減される。
また、本発明は、上述の実施形態の一部または1以上の機能を実現するプログラムによっても実現可能である。すなわち、そのプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータ(またはCPUやMPU等)における1つ以上のプロセッサがプログラムを読出し実行する処理により実現可能である。また、そのプログラムをコンピュータ可読な記録媒体に記録して提供してもよい。
また、コンピュータが読みだしたプログラムを実行することにより、実施形態の機能が実現されるものに限定されない。例えば、プログラムの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)などが実際の処理の一部または全部を行い、その処理によって上記した実施形態の機能が実現されてもよい。
1…通信装置、2…主処理部、3…通信処理部、4…バスブリッジ、5…ネットワーク、21…メインCPU、22…メインメモリ、23…メインバス、24…ユーザバッファ、31…サブCPU、32…ペイロードサイズ決定部、33…オンチップメモリ、34…ネットワークバッファ、35…データ転送部、36…パケット生成部、37…LAN制御部、38…WLAN制御部、39…ローカルバス
本発明は、上述の課題に鑑みてなされたものであり、通信スループットの低下を抑え、パケットをより効率的に送信することを目的とする。
上記課題を解決するため、本発明に係る通信装置は、前記通信装置が送信するパケットに付加されるヘッダであって、TCP(Transmission Control Protocol)に係るヘッダのヘッダ長を取得する取得手段と、前記取得手段により取得された前記ヘッダ長と、前記パケットを送信するTCPコネクションにおけるMSS(Maximum Segment Size)とに基づいて、前記パケットに含めるペイロードのペイロード長を決定する決定手段と、前記決定手段により決定された前記ペイロード長のペイロードを含むパケットを生成する第1の生成手段と、を有する。
本発明によれば、通信スループットの低下を抑え、パケットをより効率的に送信することができる。

Claims (11)

  1. 複数の領域を含む送信バッファと、
    前記送信バッファに格納されたTCP/IPヘッダおよび送信データを入力として、当該入力されたTCP/IPヘッダおよび送信データに基づいて複数のパケットを生成する生成手段と、
    前記TCP/IPヘッダのうち、前記複数のパケットのそれぞれに付加すべきTCPヘッダのヘッダ長を算出する算出手段と、
    前記算出手段により算出された前記TCPヘッダの前記ヘッダ長と、前記複数のパケットを送信すべきコネクションにおける最大セグメントサイズとに基づいて、前記送信バッファの前記複数の領域のそれぞれに格納すべきペイロードのペイロード長を決定する決定手段と、
    前記決定手段により決定された前記ペイロード長で前記送信データを分割し、分割された送信データを前記送信バッファの前記複数の領域に前記ペイロードとしてそれぞれ格納して、前記生成手段に、前記決定手段により決定された前記ペイロード長で前記複数のパケットを生成させるよう制御する制御手段と
    を備えることを特徴とする通信装置。
  2. 前記TCPヘッダは、TCPのプロトコルにおいてオプションとされるTCPオプションヘッダを含み、
    前記算出手段は、前記TCPオプションヘッダのヘッダ長を算出する
    ことを特徴とする請求項1に記載の通信装置。
  3. 前記決定手段は、前記最大セグメントサイズから前記ヘッダ長を減算することにより、前記ペイロード長を決定する
    ことを特徴とする請求項2に記載の通信装置。
  4. 前記算出手段は、通信対向装置から前記コネクションを介して送信されるデータの受信状況に基づいて、前記ヘッダ長を算出する
    ことを特徴とする請求項1から3のいずれか1項に記載の通信装置。
  5. 前記決定手段は、前記ペイロード長に前記ヘッダ長を付加したパケット長が、最大転送単位(Maximum Transmission Unit)を超えないよう、前記ペイロード長を決定する
    ことを特徴とする請求項1から4のいずれか1項に記載の通信装置。
  6. 前記制御手段は、前記送信データのデータ長が前記決定手段により決定された前記ペイロード長以下である場合、前記生成手段に前記複数のパケットを生成させることなく、前記送信データに前記TCP/IPヘッダを付加してパケットを生成する
    ことを特徴とする請求項1から5のいずれか1項に記載の通信装置。
  7. 前記制御手段は、前記決定手段により決定された前記ペイロード長を、前記生成手段により生成されるべき先頭のパケットのペイロード長に設定し、先頭以外のパケットのペイロード長には前記最大セグメントサイズを設定する
    ことを特徴とする請求項1から6のいずれか1項に記載の通信装置。
  8. 前記生成手段は、前記送信バッファに格納された前記TCP/IPヘッダを複製し、複製された複数のTCP/IPヘッダを、前記送信バッファの前記複数の領域に格納された複数のペイロードにそれぞれ付加して、前記複数のパケットを生成する
    ことを特徴とする請求項1から7のいずれか1項に記載の通信装置。
  9. 前記算出手段は、TCPのSACK(Selective ACK)のオプションヘッダのヘッダ長を算出する
    ことを特徴とする請求項1から8のいずれか1項に記載の通信装置。
  10. 複数のパケットを生成して送信する通信装置の制御方法であって、
    前記複数のパケットのそれぞれに付加すべきTCPヘッダのヘッダ長を算出するステップと、
    算出された前記TCPヘッダの前記ヘッダ長と、前記複数のパケットを送信すべきコネクションにおける最大セグメントサイズとに基づいて、送信バッファの複数の領域のそれぞれに格納すべきペイロードのペイロード長を決定するステップと、
    前記送信バッファの前記複数の領域のいずれかに前記TCPヘッダを含むTCP/IPヘッダを格納するとともに、決定された前記ペイロード長で送信データを分割し、分割された送信データを前記送信バッファの前記複数の領域の他の領域に前記ペイロードとしてそれぞれ格納するステップと、
    前記送信バッファに格納された前記TCP/IPヘッダおよび前記送信データを入力として、当該入力されたTCP/IPヘッダおよび送信データに基づいて前記複数のパケットを生成するステップと
    を含むことを特徴とする通信装置の制御方法。
  11. コンピュータを、請求項1から9のいずれか1項に記載の通信装置の各手段として機能させるためのプログラム。
JP2019027378A 2019-02-19 2019-02-19 通信装置、通信装置の制御方法およびプログラム Active JP6891201B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2019027378A JP6891201B2 (ja) 2019-02-19 2019-02-19 通信装置、通信装置の制御方法およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2019027378A JP6891201B2 (ja) 2019-02-19 2019-02-19 通信装置、通信装置の制御方法およびプログラム

Publications (2)

Publication Number Publication Date
JP2020136883A true JP2020136883A (ja) 2020-08-31
JP6891201B2 JP6891201B2 (ja) 2021-06-18

Family

ID=72263746

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019027378A Active JP6891201B2 (ja) 2019-02-19 2019-02-19 通信装置、通信装置の制御方法およびプログラム

Country Status (1)

Country Link
JP (1) JP6891201B2 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007266759A (ja) * 2006-03-27 2007-10-11 Sony Computer Entertainment Inc ネットワーク処理装置、マルチプロセッサシステムおよびネットワークプロトコル処理方法
JP2008113327A (ja) * 2006-10-31 2008-05-15 Matsushita Electric Ind Co Ltd ネットワークインターフェース装置
JP2013115576A (ja) * 2011-11-28 2013-06-10 Fujitsu Ltd 受信データ処理方法、通信装置、及びプログラム
JP2014049820A (ja) * 2012-08-29 2014-03-17 Fujitsu Ltd 監視装置,監視プログラム,監視方法
JP2018196053A (ja) * 2017-05-19 2018-12-06 キヤノン株式会社 通信装置、通信方法、およびプログラム
JP2019016842A (ja) * 2017-07-04 2019-01-31 キヤノン株式会社 通信装置および制御方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007266759A (ja) * 2006-03-27 2007-10-11 Sony Computer Entertainment Inc ネットワーク処理装置、マルチプロセッサシステムおよびネットワークプロトコル処理方法
JP2008113327A (ja) * 2006-10-31 2008-05-15 Matsushita Electric Ind Co Ltd ネットワークインターフェース装置
JP2013115576A (ja) * 2011-11-28 2013-06-10 Fujitsu Ltd 受信データ処理方法、通信装置、及びプログラム
JP2014049820A (ja) * 2012-08-29 2014-03-17 Fujitsu Ltd 監視装置,監視プログラム,監視方法
JP2018196053A (ja) * 2017-05-19 2018-12-06 キヤノン株式会社 通信装置、通信方法、およびプログラム
JP2019016842A (ja) * 2017-07-04 2019-01-31 キヤノン株式会社 通信装置および制御方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"BROAD BAND SPEED UP! 超絶! ブロードバンド高速化大全", ASCII 第27巻 第2号, JPN6020046637, 1 February 2003 (2003-02-01), JP, pages 148, ISSN: 0004402196 *

Also Published As

Publication number Publication date
JP6891201B2 (ja) 2021-06-18

Similar Documents

Publication Publication Date Title
US20190312938A1 (en) Data Transmission Method And Apparatus
JP4269176B2 (ja) セッション中継装置及び中継方法
JP6963411B2 (ja) 通信装置、通信方法、およびプログラム
JP5832335B2 (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
JP6891201B2 (ja) 通信装置、通信装置の制御方法およびプログラム
JP6234236B2 (ja) 通信装置
JP2019165423A (ja) 通信装置、通信装置の制御方法およびプログラム
JP5617838B2 (ja) パケット再送制御システム、パケット再送制御方法および再送制御プログラム
JP2018142853A (ja) 通信方法、通信装置、及びプログラム
JP2017038297A (ja) 通信装置、通信方法、及び通信システム
JP6618330B2 (ja) 通信装置及びその方法、コンピュータプログラム
JP2020178182A (ja) 通信装置、通信装置の制御方法およびプログラム
JP6279970B2 (ja) プロセッサ、通信装置、通信システム、通信方法およびコンピュータプログラム
JP6568571B2 (ja) データ転送装置、データ転送方法および通信装置
JP6873953B2 (ja) 通信装置、通信装置の制御方法およびプログラム
JP2019016842A (ja) 通信装置および制御方法
KR102184363B1 (ko) 네트워크 커넥터의 호스트 및 클라이언트와의 통신 방법, 그리고 동일 방법을 수행하는 네트워크 커넥터
US20170265103A1 (en) Communication device, communication method, and non-transitory computer readable medium
US20240171504A1 (en) Multi-path architecture for hardware offloading
JP7321913B2 (ja) 通信装置、制御方法およびプログラム
JP2019114947A (ja) 通信装置、通信装置の制御方法およびプログラム
US20230062831A1 (en) Communication apparatus and control method thereof, and storage medium
JP2022161570A (ja) 通信装置、通信方法およびプログラム
JP2019201249A (ja) 通信装置、通信装置の制御方法、およびプログラム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191219

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191219

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20201208

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210202

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210526

R151 Written notification of patent or utility model registration

Ref document number: 6891201

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151