JP2018064187A - 通信装置、通信方法およびプログラム - Google Patents
通信装置、通信方法およびプログラム Download PDFInfo
- Publication number
- JP2018064187A JP2018064187A JP2016201254A JP2016201254A JP2018064187A JP 2018064187 A JP2018064187 A JP 2018064187A JP 2016201254 A JP2016201254 A JP 2016201254A JP 2016201254 A JP2016201254 A JP 2016201254A JP 2018064187 A JP2018064187 A JP 2018064187A
- Authority
- JP
- Japan
- Prior art keywords
- data
- reception buffer
- data amount
- communication apparatus
- communication device
- 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.)
- Pending
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
- H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- 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/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
- H04L47/263—Rate modification at the source after receiving feedback
-
- 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
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/20—Control channels or signalling for resource management
- H04W72/21—Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
-
- 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/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0278—Traffic management, e.g. flow control or congestion control using buffer status reports
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/10—Flow control between communication endpoints
- H04W28/12—Flow control between communication endpoints using signalling between network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】 通信装置が記憶可能なデータ量に応じた通信データ量で他の通信装置と通信できるようにする。
【解決手段】 通信装置101は、通信装置102から受信したデータを記憶するために、受信バッファに加えて別の記憶領域を使用できるかを判定する。また通信装置101は、通信装置102からの送信を許可するデータ量を判定結果に基づいて決定し、決定された許可するデータ量に応じた通知を通信装置102に対して行う。そして通信装置101は、通知に応じて通信装置102から送信されたデータを受信し、受信したデータを受信バッファに記憶させ、また、受信バッファに記憶させないデータを別の記憶領域に記憶させる。
【選択図】 図8
【解決手段】 通信装置101は、通信装置102から受信したデータを記憶するために、受信バッファに加えて別の記憶領域を使用できるかを判定する。また通信装置101は、通信装置102からの送信を許可するデータ量を判定結果に基づいて決定し、決定された許可するデータ量に応じた通知を通信装置102に対して行う。そして通信装置101は、通知に応じて通信装置102から送信されたデータを受信し、受信したデータを受信バッファに記憶させ、また、受信バッファに記憶させないデータを別の記憶領域に記憶させる。
【選択図】 図8
Description
本発明は、通信装置間で送受信されるデータの量を制御する技術に関する。
通信装置間での通信方式の一つに、TCP(Transmission Control Protocol)/IP(Internet Protocol)がある。TCP/IPに従った通信を行う通信装置は、通信相手となる他の通信装置との間で論理的な通信路(コネクション)を確立し、通信路ごとに受信バッファを管理する。通信装置が受信したデータは受信バッファに一時的に記憶される。受信バッファには容量が定められており、通信装置のメモリ資源が各受信バッファとして割り当てられる。
通信装置に対して受信バッファの容量を超えたデータが送信されないようにするために、TCP/IPにはウィンドウ制御の機能がある。ウィンドウ制御において、データの受信装置は、対象の通信路における送信を許可するデータ量を示すウィンドウサイズとして受信バッファの容量をデータの送信装置に通知する。送信装置は、通知されたウィンドウサイズ以下の量のデータを対象の通信路を用いて受信装置に送信する。このウィンドウ制御によって、受信装置の受信バッファの容量を超えるデータが送信装置から送信されることを防ぐことができる。
一方、特許文献1には、通信装置が受信バッファの空き容量より大きい値のウィンドウサイズを通知することが記載されている。そして、通信装置が受信バッファの空き容量より大きいサイズのデータを受信した際には、受信バッファと異なる一時バッファを使用することで受信バッファに記憶しきれないデータを記憶することが記載されている。
しかしながら、特許文献1に記載の通信方法では、通信装置が記憶可能なデータ量より大きいサイズのデータを受信することによって通信効率が低下する場合が考えられる。例えば、通信装置がメモリ資源の不足により一時バッファを使用することができない場合に、受信バッファの空き容量より大きいサイズのデータを受信すると、受信バッファに記憶しきれない受信データが破棄され通信効率が低下する虞がある。
本発明は上記課題に鑑みて成されたものであり、通信装置が記憶可能なデータ量に応じた通信データ量で他の通信装置と通信できるようにすることを目的とする。
上記の課題を解決するため、本発明に係る通信装置は、例えば以下の構成を有する。すなわち、他の通信装置から受信したデータを受信バッファに記憶させる第1記憶手段と、前記他の通信装置から受信したデータのうち前記受信バッファに記憶されないデータを、前記受信バッファとは別の記憶領域に記憶させる第2記憶手段と、前記他の通信装置から受信したデータを前記第2記憶手段が前記記憶領域に記憶させることができるかを判定する判定手段と、前記他の通信装置からの送信を許可するデータ量を前記判定手段による判定結果に基づいて決定する決定手段と、前記他の通信装置に対して、前記決定手段により決定された前記許可するデータ量に応じた通知を行う通知手段と、前記通知手段による通知に応じて前記他の通信装置から送信されるデータを受信する受信手段とを有することを特徴とする通信装置。
本発明によれば、通信装置が記憶可能なデータ量に応じた通信データ量で他の通信装置と通信できるようになる。
以下、本発明の実施形態について、図面を参照して説明する。なお、以下の実施形態で説明する特徴の組み合わせの全てが本発明に必須のものとは限らない。
[システム構成]
図1に、本実施形態に係る通信システム10の構成を示す。通信システム10は通信装置101と通信装置102とを含み、通信装置101と通信装置102とはネットワーク110を介してTCP/IP通信を行う。なお、本実施形態においてネットワーク110はEthernet(登録商標)規格に準拠したLAN(Local Area Network)により構成される。ただしこれに限らず、ネットワーク110は例えば、インターネットを含んでいてもよいし、IEEE802.11シリーズ規格やBluetooth(登録商標)規格に準拠した無線LANを含んでいてもよい。また、本実施形態では通信装置101と通信装置102の2台の装置の間での通信に注目して説明を行うが、3台以上の装置がネットワーク110を介して通信を行ってもよい。また、本実施形態では通信装置101と通信装置102とがTCP/IPに基づいて通信を行う場合を例に説明するが、通信装置101と通信装置102は他のプロトコルに基づく通信を行ってもよい。
図1に、本実施形態に係る通信システム10の構成を示す。通信システム10は通信装置101と通信装置102とを含み、通信装置101と通信装置102とはネットワーク110を介してTCP/IP通信を行う。なお、本実施形態においてネットワーク110はEthernet(登録商標)規格に準拠したLAN(Local Area Network)により構成される。ただしこれに限らず、ネットワーク110は例えば、インターネットを含んでいてもよいし、IEEE802.11シリーズ規格やBluetooth(登録商標)規格に準拠した無線LANを含んでいてもよい。また、本実施形態では通信装置101と通信装置102の2台の装置の間での通信に注目して説明を行うが、3台以上の装置がネットワーク110を介して通信を行ってもよい。また、本実施形態では通信装置101と通信装置102とがTCP/IPに基づいて通信を行う場合を例に説明するが、通信装置101と通信装置102は他のプロトコルに基づく通信を行ってもよい。
図2に、本実施形態に係る通信装置101のハードウェア構成を示す。なお、通信装置102も通信装置101と同様のハードウェア構成である。通信装置101は、記憶部201、制御部202、機能部203、入力部204、出力部205、及び通信部206を有する。
記憶部201は、ROMやRAM等のメモリを有し、通信装置101の後述する各種動作を行うためのプログラムや、TCP/IP通信のための通信パラメータ等の各種情報を記憶する。また、記憶部201は通信装置101と通信装置102との間で送受信するデータを記憶するネットワークバッファとしても機能する。なお、記憶部201として、ROMやRAM等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、磁気テープ、不揮発性のメモリカード、及びDVDなどの記憶媒体を用いてもよい。
制御部202は、CPUやMPU等のプロセッサを有し、記憶部201に記憶されたプログラムを読み出して実行することで通信装置101全体を制御する。なお、制御部202は、記憶部201に記憶されたプログラムとOS(Operating System)との協働により通信装置101全体を制御してもよい。また、制御部202がマルチコア等により複数のプロセッサを備え、複数のプロセッサにより通信装置101全体を制御してもよい。
機能部203は、通信装置101が所定の処理を実行するためのハードウェアである。例えば、通信装置101がカメラである場合、機能部203は撮像部を有し、撮像処理を行う。また例えば、通信装置101がプリンタである場合、機能部203は印刷部を有し、印刷処理を行う。また例えば、通信装置101がプロジェクタである場合、機能部203は投影部を有し、投影処理を行う。機能部203が処理するデータは、記憶部201に予め記憶されているデータであってもよいし、後述する通信部206を介した他の装置との通信により取得されたデータであってもよい。
入力部204は、ユーザによる各種入力操作を受け付ける。出力部205は、ユーザに対して各種出力を行う。ここで、出力部205による出力は、例えば表示部による画像出力や、スピーカーによる音声出力、及び振動出力などである。なお、タッチパネルなどによって入力部204と出力部205の両方を1つのモジュールで実現してもよい。また、入力部204や出力部205が通信装置101の外部に別の装置として存在していてもよい。この場合、制御部202が、入力部204を制御する入力制御部、及び出力部205を制御する出力制御部として動作する。
通信部206は、TCP/IP通信の制御を行い、例えば画像データや文書データ、及び音声データ等のコンテンツを、通信装置102などの他の装置との間で送受信する。
[動作フロー]
まず、TCP/IPプロトコルに基づく通信における基本的な動作を説明する。通信の開始時に、通信装置101と通信装置102との間にはデータの送受信を行うための論理的な通信路(コネクション)が確立される。なお、通信装置101は複数のコネクションを確立することもできる。
まず、TCP/IPプロトコルに基づく通信における基本的な動作を説明する。通信の開始時に、通信装置101と通信装置102との間にはデータの送受信を行うための論理的な通信路(コネクション)が確立される。なお、通信装置101は複数のコネクションを確立することもできる。
TCP/IPプロトコル処理を行う通信装置101及び通信装置102には、通信データのパケット化や送受信処理のために、ネットワークバッファが用意されている。ネットワークバッファは複数のコネクションにおいて共用され、また送信処理と受信処理でも共用される。TCP/IPパケットの送信を行う通信装置102では、アプリケーションからのデータ送信命令に従って指定されたデータが、送信バッファとして割り当てられたネットワークバッファ内の記憶領域にコピーされる。そして、記憶領域にコピーされた送信データは、MTU(Maximum Transmission Unit、最大伝送単位)に応じて分割される。ここでMTUは、送信側の通信装置から受信側の通信装置へ単一のフレームで伝送されるデータの最大サイズである。そして、分割された送信データにTCPヘッダとIPヘッダが追加されたTCP/IPパケットが生成される。伝送経路がEthernetの場合、さらに、Ethernetヘッダが付加されたEthernetフレームが生成され通信装置101へ送信される。
TCP/IPパケットの受信を行う通信装置101では、ネットワークから受信されたパケットが通信部206内のメモリ等に一旦保持され、パケットのヘッダ部分とデータ部分に分割される。そしてパケットのデータ部分が、コネクションに対応する受信バッファとして割り当てられたネットワークバッファ内の記憶領域に記憶される。さらに、アプリケーションのデータ受信命令に従って受信バッファ内のデータがアプリケーションの用意したデータバッファ(アプリケーションバッファ)に移動(読み出し)され、受信したデータに対して処理が実施される。なお、受信バッファは、コネクションが確立される際に予約される所定のデータ容量を有し、データ容量を超えるデータを記憶することはできない。具体的な予約のタイミングは、コネクション確立のために行われるTCPにおけるスリーウェイハンドシェイクの前であってもよいし、スリーウェイハンドシェイクの後であってもよいし、スリーウェイハンドシェイクの途中であってもよい。
また、TCP/IPはウィンドウ制御と呼ばれる機能を持つ。TCP/IPのウィンドウ制御では、データ受信側の通信装置101は受信バッファの空き容量に応じてウィンドウサイズを決定する。そして通信装置101は、決定したウィンドウサイズの値を示すACK(確認応答,Acknowledgement)パケットをデータ送信側の通信装置102へ送信する。そして、通信装置102はウィンドウサイズ以下のデータ量のデータを次のACKパケットを待つことなく通信装置101へ送信することができる。すなわち、TCPで規定されたウィンドウサイズは通信装置102からのコネクションを使用した送信を許可するデータ量を示し、ACKパケットに含まれるウィンドウサイズに関する情報は通信装置102の送信データ量を制御する制御情報となる。
通信装置101は、受信したパケットをアプリケーションが受信バッファから読み出していない場合、受信バッファが空の場合よりも小さいウィンドウサイズを示すACKパケットを通信装置102に通知する。受信したパケットをアプリケーションが読み出すと受信バッファの空き容量が増えるため、この後に送信されるACKパケットでは大きくなったウィンドウサイズが通信装置102に通知される。
また、TCP/IPでは通知できるウィンドウサイズの上限を拡大するためのオプションとしてウィンドウスケールオプションがある。ウィンドウスケールオプションは、通信装置102から通信装置101へのコネクション確立要求、およびコネクション確立要求への通信装置102による応答に、図4のようなウィンドウスケールオプションを示すパラメータが含まれている場合に有効となる。ウィンドウスケールオプションが有効になっている場合、通信装置101は、TCPのウィンドウスケールオプションに従うウィンドウサイズに関する情報を含むACKパケットを送信することで、通信装置102にウィンドウサイズを通知する。具体的には、ウィンドウスケールオプションのShift.cntフィールドの値が、ウィンドウサイズの拡大量に対応するスケールファクタを示す。通信装置101からACKパケットを受信した通信装置102は、TCPヘッダ中のウィンドウフィールド値をスケールファクタ分だけビットシフトすることで、ウィンドウサイズを算出する。
ウィンドウスケールオプションが有効であるとき、ウィンドウフィールド値が1の場合のウィンドウサイズに対応するスケール単位容量は次のように示される。
スケール単位容量=2^スケールファクタ(バイト)
従って、ウィンドウサイズは次のように示される。
従って、ウィンドウサイズは次のように示される。
ウィンドウサイズ=ウィンドウフィールド値×2^スケールファクタ(バイト)
ウィンドウスケールオプションでは、スケールファクタは「0」から「14」の値で示される。図5はスケールファクタとスケール単位容量との対応関係を表す図である。
ウィンドウスケールオプションでは、スケールファクタは「0」から「14」の値で示される。図5はスケールファクタとスケール単位容量との対応関係を表す図である。
図6を用いて、スケールファクタに従ったウィンドウサイズについてさらに説明する。本実施形態において、ウィンドウスケールオプションが有効な場合に通知されるウィンドウサイズは、スケールファクタにより定まるスケール単位容量と受信バッファの空き容量とに応じて決定される。図6(A)はスケール単位容量が256バイト、すなわちスケールファクタが8の場合の空きバッファ容量とウィンドウサイズの対応関係を示している。図6(B)はスケール単位容量が2048バイト、すなわちスケールファクタが11の場合の空きバッファ容量とウィンドウサイズの対応関係を示している。
ウィンドウスケールオプションを使用した通信において、ウィンドウフィールド値が整数であるため、ウィンドウサイズはスケール単位容量の倍数、すなわち2のn乗(nはスケールファクタに対応する整数)の倍数となる。しかしながら、受信バッファの空き容量は必ずしも2のn乗の倍数となるとは限らない。そのため、受信バッファの空き容量に応じてウィンドウサイズを決定する際に、ウィンドウサイズと空き容量との間に丸め誤差が発生する場合がある。受信バッファの空き容量を下に丸めた場合(ウィンドウサイズが空き容量より小さくなるようなウィンドウフィールド値が設定された場合)のウィンドウサイズは、空き容量をスケール単位容量で除算した商に対してスケール単位容量を乗算した値となる。空き容量を上に丸めた場合(ウィンドウサイズが空き容量より大きくなるようなウィンドウフィールド値が設定された場合)のウィンドウサイズは、空き容量をスケール単位容量で除算した商に1を加算した値に対してスケール単位容量を乗算した値となる。
仮に、通信装置101が受信バッファの空き容量を常に下に丸めて、空き容量よりも小さいウィンドウサイズを通知すると、通信装置102からは受信バッファの空き容量よりも少ないデータ量しか送信されない。そのため、受信バッファを効率良く利用できない場合がある。一方、通信装置101が受信バッファの空き容量を常に上に丸めて、空き容量よりも大きいウィンドウサイズを通知すると、通信装置102は受信バッファの空き容量よりも多くのデータを送信する場合がある。そのため、通信装置101では受信データが受信バッファからあふれて破棄されることが考えられる。本実施形態では、通信装置101がウィンドウサイズを上に丸めるか下に丸めるかを状況に応じて決定することで、高い通信効率を実現する。
次に、図3を用いて、通信装置101と通信装置102が通信を行う際の通信装置101の動作について説明する。図3の処理は、通信装置101と通信装置102との通信を開始するための指示が入力部204を介してユーザにより行われたタイミングで開始される。ただし、図3の処理の開始タイミングは上記タイミングに限定されない。例えば、通信を開始するための指示がアプリケーションにより行われたタイミングや、タイマに応じたタイミングであってもよい。図3の処理は、記憶部201に記憶されたプログラムを制御部202が読み出して実行することで実現される。
なお、図3に示す処理の少なくとも一部をハードウェアにより実現してもよい。ハードウェアにより実現する場合、例えば、所定のコンパイラを用いることで、各ステップを実現するためのプログラムからFPGA(Field Programmable Gate Array)上に自動的に専用回路を生成すればよい。また、FPGAと同様にしてGate Array回路を形成し、ハードウェアとして実現するようにしてもよい。また、ASIC(Application Specific Integrated Circuit)により実現するようにしてもよい。
S301では、通信装置101は、TCPにおけるスリーウェイハンドシェイクによって通信装置102とコネクションを確立する。スリーウェイハンドシェイクにおいて行われる通信において、通信装置101はコネクション確立要求への応答(SYN_ACKパケット)によって通信装置102にウィンドウサイズを通知する。なお、SYN_ACKパケットにより通知されるウィンドウサイズにはウィンドウスケールオプションが適用されない。コネクション確立時の通信によりウィンドウスケールオプションが有効となった場合、コネクション確立より後のデータ受信に対する応答(ACKパケット)により通知されるウィンドウサイズにウィンドウスケールオプションが適用される。
S302では、通信装置101がコネクションを維持するか否か判断する。コネクションを維持すると判断した場合は、S303に進む。一方、コネクションを維持しないと判断した場合はS307に進み、通信装置101はコネクションを切断して処理を終了する。コネクションを維持しないと通信装置101が判断する場合とは、例えば、通信装置102から通信装置101へのデータ送信が所定時間行われない場合や、通信装置101に対して通信を終了する指示がなされた場合などである。
S303では、通信装置101が、通信装置102から受信したデータの少なくとも一部を、所定のデータ容量を有する受信バッファの空き領域に記憶させる。本実施形態において、受信データのうち記憶される少なくとも一部のデータは、受信バッファの空き領域に記憶可能な量のデータである。S304では、通信装置101が、S303で受信バッファに記憶した受信データに加えて、受信バッファの容量不足により受信バッファに記憶できない受信データがあるかを判断する。受信バッファに記憶できない受信データがなければS306に進み、記憶できないデータがある場合はS305に進む。S305では、通信装置101が、通信装置102から受信したデータのうち、受信バッファに記憶されないデータを、一時バッファに記憶させる。ここで一時バッファとは、ネットワークバッファ内の記憶領域のうち受信バッファとして割り当てられていない記憶領域であり、受信バッファの容量不足により受信バッファから溢れたデータを記憶するために一時的に使用される記憶領域である。
すなわち、通信装置101は、通信装置102との間のコネクションを介して受信されたデータを、該コネクションの確立に応じて該コネクションと対応付けて予約された領域である受信バッファに記憶する。そして、該コネクションを介して受信されたデータのうち、受信バッファの容量不足により受信バッファに記憶できないデータを、特定のコネクションに対応付けされていない記憶領域に記憶する。
S306において、通信装置101は、受信バッファの空き容量に基づいてウィンドウサイズを算出し、通信装置102に対してACKパケットを用いてウィンドウサイズを通知する。ウィンドウサイズの算出方法については後述する。S306の処理が終了するとS302に進み、S302−S306までのデータ受信処理を繰り返す。
図7は、通信装置101と通信装置102とが通信を行う場合の通信シーケンスの例を示す。S601からS603は通信装置101と通信装置102との間のコネクション確立に関するシーケンスである。S601において通信装置102は通信装置101に対してコネクション確立要求を送信し、S602において通信装置101は通信装置102に対してコネクション確立要求への応答を送信する。ここでは、S601及びS602においてウィンドウスケールオプションのShift.cntの値はいずれも「8」である。すなわち、スケール単位容量として256バイトが通知されている。
S604からS607は、通信装置102から通信装置101に対してデータが送信され、通信装置101から通信装置102に対して確認応答が送信されるシーケンスである。通信装置101の受信バッファの容量が4500バイトである場合、S604において通信装置101が1500バイトのデータを受信すると受信バッファの空き容量が3000バイトとなる。S605において通信装置101はACKパケットを送信することで、通信装置102に対してウィンドウサイズを通知する。
ここで、受信バッファの空き容量が3000バイトであり、スケール単位容量が256バイトであるため、ウィンドウサイズと空き容量との間の丸め誤差が発生する。受信バッファの空き容量を下に丸めた場合(ウィンドウフィールド値を11に設定した場合)は通知されるウィンドウサイズが2816バイトとなり、空き容量を上に丸めた場合(ウィンドウフィールド値を12に設定した場合)は3072バイトとなる。受信バッファの空き容量が3000バイトである場合に、3072バイトのウィンドウサイズを通知すると、72バイト分のバッファが不足する可能性がある。そこで通信装置101は、72バイト以上の容量の一時バッファを確保可能であれば3072バイトのウィンドウサイズを通信装置102に通知し、そうでなければ2816バイトのウィンドウサイズを通信装置102に通知する。
S606において、通信装置101が1500バイトのデータを受信すると、受信バッファの空き容量が1500バイトとなる。S607において通信装置101はACKパケットを送信するが、S605と同様にウィンドウサイズの丸め誤差が発生する。受信バッファの空き容量を下に丸めた場合は通知するウィンドウサイズは1280バイトとなり、上に丸めた場合は1536バイトとなる。そこで通信装置101は、バッファが不足する可能性がある36バイト以上の容量の一時バッファを確保可能であれば1536バイトのウィンドウサイズを通信装置102に通知し、そうでなければ1280バイトのウィンドウサイズを通信装置102に通知する。
すなわち、通信装置101は、通信装置102から受信したデータを一時バッファに記憶させることができるかを判定する。一時バッファを使用できるか否かは、例えば対象のデータ受信に使用されるコネクションとは別のコネクションにおけるデータ送受信のためのネットワークバッファの使用状況などによって決まる。そして通信装置101は、通信装置102からの送信を許可するデータ量を示すウィンドウサイズを、判定結果に基づいて決定する。
より具体的には、通信装置101は、ウィンドウサイズを受信バッファの空き容量以下の第1データ量とするか、受信バッファの空き容量より大きい第2データ量とするかを決定する。本実施形態において、第1データ量は受信バッファの空き容量をスケールファクタに従って下に丸めた値であり、第2データ量は受信バッファの空き容量をスケールファクタに従って上に丸めた値である。言い換えると、第1データ量は、スケールファクタにより定まるスケール単位容量の整数倍のデータ量であり且つ受信バッファの空き容量を超えないデータ量のうち、最大のデータ量である。また第2データ量は、スケール単位容量の整数倍のデータ量であり且つ受信バッファの空き容量より大きいデータ量のうち、最小のデータ量である。
なお、第1データ量及び第2データ量の決め方はこれに限らない。例えば、第1データ量は受信バッファの空き容量を下に丸めた値よりスケール単位容量の倍数分小さくてもよいし、第2データ量は受信バッファの空き容量を上に丸めた値よりスケール単位容量の倍数分大きくてもよい。
そして通信装置101は、ウィンドウサイズの候補である第2データ量(上に丸めた値)から受信バッファの空き容量を差し引いたデータ量に相当する容量の一時バッファを、通信装置102から受信したデータを記憶するために使用できるか否か判定する。差し引いたデータ量に相当する容量の一時バッファを使用できないと判定した場合には、ウィンドウサイズを第1データ量(下に丸めた値)とする。また、差し引いたデータ量に相当する容量の一時バッファを使用できると判定した場合には、ウィンドウサイズを第2データ量とする。
通信装置101は、ウィンドウサイズを決定すると、決定したウィンドウサイズに応じた制御情報をACKパケットの送信によって通信装置102に通知する。そして通信装置101は、通知に応じて通信装置102から送信されたデータを受信する。
このような処理により、通信装置101は、一時バッファの使用により受信バッファの空き容量より多くのデータを受信できる場合には、受信バッファの空き容量より多くのデータを通信装置102が送信できるように制御できる。また、一時バッファが使用できず受信バッファの空き容量以下のデータしか受信できない場合には、受信バッファの空き容量以下のデータを通信装置102が送信するように制御できる。これにより、通信装置101と通信装置102との間の通信における通信効率を向上することができる。そして例えば、S604からS607の処理が繰り返されることにより通信装置101は通信装置102からコンテンツデータを取得し、ユーザに対して出力部205を介した画像出力や音声出力を行うことができる。
なお、上記の図7の説明では省略したが、本実施形態における通信装置101は、受信バッファの空き容量が所定の閾値以上であるか否かを判定し、その判定結果と上述した一時バッファの使用可否の判定結果とに基づいてウィンドウサイズを決定する。本実施形態に係る通信装置101の動作について、図8を用いて説明する。なお、本実施形態において上記の所定の閾値はMTUであるが、これに限らず、所定の閾値は例えばスケール単位容量など他の値であってもよい。また、通信装置は受信バッファの空き容量と所定の閾値との比較を行わず、一時バッファの使用可否のみに基づいてウィンドウサイズを決定してもよい。
図8の処理は図3のS306において行われる処理であり、通信装置101がデータを受信してバッファに記憶したタイミングで開始される。ただし図8の処理の開始タイミングはこれに限定されない。図8の処理は、記憶部201に記憶されたプログラムを制御部202が読み出して実行することで実現される。
S801において、通信装置101は、通信装置102からのコネクション確立要求およびそのコネクション確立要求への応答においてウィンドウスケールオプションが有効にされていたかを判定する。ウィンドウスケールオプションが有効であると判定した場合は、S802に進む。一方、ウィンドウスケールオプションが有効でないと判定した場合、通信装置101は、ウィンドウサイズとして指定可能な値の範囲内において、受信バッファの空き容量をウィンドウサイズとして通知する。すなわち通信装置101は、受信バッファの空き容量がウィンドウスケールオプションを使用せずに通知できるウィンドウサイズの上限以下の場合、受信バッファの空き容量をウィンドウサイズとして通知する。一方、受信バッファの空き容量がウィンドウサイズの上限より大きい場合には、通信装置101は、例えばその上限の値をウィンドウサイズとして通知する。
S802において、通信装置101は、受信バッファの空き容量がMTU以上であるかを判定する。受信バッファの空き容量がMTU以上であると判定された場合は、S803に進み、一時バッファの使用可否に基づいてウィンドウサイズが決定される。一方、受信バッファの空き容量がMTU未満であると判定された場合は、S807に進む。
S803において、通信装置101は、受信バッファの空き容量をウィンドウスケールオプションのスケール単位容量の倍数となるよう上に丸めた値を算出する。たとえば受信バッファの空き容量が1500バイトであり、スケール単位容量が256バイトである場合、上に丸めた値は1536バイトとなる。S804において、通信装置101は、S803で算出した値から受信バッファの空き容量を減算することで、S803で算出した量のデータを受信した場合に受信バッファに記憶しきれないデータ量を算出する。そして、受信バッファに記憶しきれないデータを記憶できる空き容量を持つ一時バッファが使用可能であるか判定する。S804において一時バッファを使用可能であると判定された場合はS805に進み、使用可能でないと判断された場合はS807に進む。
なお、本実施形態における通信装置101は、S804において、受信バッファの空き容量を上に丸めた値をウィンドウサイズとする場合に必要となる容量の一時バッファを使用可能であるか否か判定する。これにより、必要な容量の一時バッファが使用可能な場合に有効に活用することができる。ただしこれに限らず、通信装置101はS804において、例えばスケール単位容量などの所定の容量の一時バッファが使用可能であるか否か判定してもよい。
S805において、通信装置101は、S804で算出したデータ量を記憶できる空き容量を持つネットワークバッファ内の記憶領域を一時バッファとして割り当てる。一時バッファは、通信装置101が通信装置102から受信したデータのうち、受信バッファの空き容量の不足により受信バッファに記憶できないデータを記憶するために使用される。なお、過去に図8の処理を行って一時バッファとして割り当てられた記憶領域がある場合、割り当て済みの記憶領域の容量とS804で算出されたデータ量とを比較する。割り当て済みの記憶領域の容量がS804で算出されたデータ量より小さい場合、その差分に相当する容量の記憶領域が新たに一時バッファとして割り当てられる。一方、割り当て済みの記憶領域の容量がS804で算出されたデータ量より大きい場合、その差分に相当する容量の記憶領域の割り当てが解除される。
S806において、通信装置101は、S803で算出した値をウィンドウサイズとして通信装置102に通知する。一方、S807において、通信装置101は、受信バッファの空き容量をウィンドウスケールオプションのスケール単位容量の倍数となるように下に丸めた値を、ウィンドウサイズとして通知する。たとえば受信バッファの空き容量が1500バイトであり、スケール単位容量が256バイトである場合、下に丸めた値は1280バイトとなる。
図8に示した処理を行うことにより、通信装置101は、受信バッファがMTU以上の空き容量を有する場合には、一時バッファをできるだけ使用して空き容量を有効に活用できる。また、例えば通信装置101が一時バッファとして使用可能な記憶領域の容量が小さい場合、複数のコネクションに対応する複数の受信バッファそれぞれに対して十分な容量の一時バッファを割り当てることはできない。そこで通信装置101は、受信バッファの空き容量がMTUに満たないほど小さい場合には、一時バッファの使用を抑制することで、容量が限られた記憶領域であるネットワークバッファを他の処理に使用しやすくできる。
なお、S802において通信装置101は、受信バッファの空き容量がMTU以上であるか否かに加えて、スケール単位容量がMTU未満であるか否かを判定してもよい。そして、受信バッファの空き容量がMTU以上であり、且つスケール単位容量がMTU未満である場合には、通信装置101は受信バッファの空き容量を下に丸めた値をウィンドウサイズとする。また、受信バッファの空き容量がMTU未満である場合も、受信バッファの空き容量を下に丸めた値をウィンドウサイズとする。一方、受信バッファの空き容量がMTU以上であり、且つスケール単位容量がMTU以上である場合には、一時バッファの使用可否に基づいてウィンドウサイズを決定する。
このような処理によれば、通信装置101は、スケール単位容量がMTU以上となるような丸め誤差が大きくなる可能性が高い場合に、一時バッファをできるだけ使用して、受信バッファの空き容量のうち活用されない部分が大きくなることを抑制できる。また通信装置101は、スケール単位容量がMTU未満となるような丸め誤差が小さくなる可能性が高い場合には、一時バッファの使用を抑制し、よりネットワークバッファを他の処理に使用しやすくできる。
また、図8の処理では受信バッファの空き容量が所定の閾値(MTU)以上である場合に一時バッファの使用可否を判定するものとしたが、逆に、受信バッファの空き容量が所定の閾値未満である場合に一時バッファの使用可否を判定してもよい。例えば、通信装置101は、S802の処理に代えて、受信バッファの空き容量がスケール単位容量未満であるか否か判定する。そして、受信バッファの空き容量がスケール単位容量未満である場合には、S803に進み、一時バッファの使用可否に基づいてウィンドウサイズを決定する。一方、受信バッファの空き容量がスケール単位容量以上である場合には、S807に進み、空き容量を下に丸めた値をウィンドウサイズとする。
このような処理によれば、通信装置101は、一時バッファを使用しなければウィンドウサイズが0となりデータを受信できない場合に、一時バッファをできるだけ使用してデータの受信を継続できる。また通信装置101は、一時バッファを使用しなくてもデータを受信できる場合には、一時バッファの使用を抑制し、よりネットワークバッファを他の処理に使用しやすくできる。
また通信装置101は、受信バッファの空き容量と空き容量以下の第1データ量との差、及び受信バッファの空き容量と空き容量より大きい第2データ量との差の少なくとも何れかに基づいてウィンドウサイズを決定してもよい。第1データ量は例えば受信バッファの空き容量を下に丸めた値であり、第2データ量は例えば受信バッファの空き容量を上に丸めた値である。具体的には、通信装置101は、図8のS802の処理に代えて、受信バッファの空き容量と第1データ量との差が所定値以上であるか否かを判定する。そして、受信バッファの空き容量と第1データ量との差が所定値以上である場合には、S803へ進み、ウィンドウサイズを第1データ量とするか第2データ量とするかを一時バッファの使用可否に基づいて決定する。一方、受信バッファの空き容量と第1データ量との差が所定値未満である場合には、S807へ進み、第1データ量をウィンドウサイズとする。
このような処理によれば、通信装置101は、ウィンドウサイズとして第1データ量を通知すると受信バッファの空き容量のうち活用されない部分が大きくなってしまう場合に、第2データ量を通知することで受信バッファを有効に活用できる。一方、第1データ量を通知しても受信バッファのうち活用されない部分が小さい場合には、第1データ量を通知することで一時バッファの使用を抑制し、容量の限られたネットワークバッファを他の処理に使用しやすくできる。また、S802の処理に代えて、受信バッファの空き容量と第2データ量との差が所定値未満であるか否かを判定しても、上記と同様の効果が得られる。なお、図8のS804の処理では、所定の容量を有する一時バッファとして使用可能な記憶領域がネットワークバッファ内に存在するか否かを判定するが、判定の対象をネットワークバッファ全体でなくネットワークバッファ内の特定の記憶領域に限定してもよい。この場合の通信装置101の動作について説明するために、図9を用いて、通信装置101の記憶部201に展開されるネットワークバッファの内部構造について説明する。ネットワークバッファは、送受信パケットを管理するためのパケット管理構造体901、パケットのヘッダ部分を記憶するためのヘッダバッファ構造体902、及びパケットのデータ部分を記憶するためのデータバッファ構造体903を有する。データバッファ構造体903は、パケットのデータ部分を記憶するネットワークバッファ内の領域が所定の分割単位に分割された分割領域である。同様に、ヘッダバッファ構造体902は、パケットのヘッダ部分を記憶する領域が分割された分割領域である。パケット管理構造体901は、ヘッダバッファ構造体902に記憶されているヘッダ部分とデータバッファ構造体903に記憶されているデータ部分とを関連付けてパケットとして処理するための構造体である。
なお、本実施形態ではネットワークバッファが3種類の構造体を有する場合について説明を行うが、これに限らない。例えば、ネットワークバッファはパケット管理構造体901を有さず、ヘッダ部分とデータ部分の関連付けはパケット管理構造体901とは別の仕組みで行われてもよい。また、ネットワークバッファはヘッダバッファ構造体902を有さず、データバッファ構造体903にパケットのヘッダ部分が記憶されてもよい。
また、受信バッファに割り当てられるデータバッファ構造体903の総容量と受信バッファの容量とは一致しなくてもよい。例えば、受信バッファの容量が、予め定められたデータバッファ構造体903の容量の2倍より大きく3倍より小さい場合には、3つのデータバッファ構造体903が受信バッファに割り当てられる。この場合、3つのデータバッファ構造体903のうち少なくとも何れかにおいて、データ容量の一部が受信バッファに対応し、他の部分は受信バッファとして使用されない。また、ある受信バッファに割り当てられたデータバッファ構造体903の一部が別の受信バッファとして使用されることはない。
そこで通信装置101は、図8のS804において、データ容量の一部が受信バッファに対応するデータバッファ構造体903の、受信バッファに対応しない部分を、一時バッファとして使用できるか否か判定してもよい。すなわち、ネットワークバッファのうち一時バッファとしての使用可否を判定する対象となる記憶領域を、受信バッファのために一部が使用されているデータバッファ構造体903に限定してもよい。そして、所定の容量の一時バッファとして使用可能な部分を有するデータバッファ構造体903が存在する場合にはS805へ進み、そうでない場合にはS807へ進む。すなわち、受信バッファに割り当てられるデータバッファ構造体903の空き容量の総和が、受信バッファの空き容量を上に丸めた値以上である場合には、一時バッファが使用可能であると判定される。
このような処理によれば、通信装置101は、ネットワークバッファ内の記憶領域のうち他の処理に使用されない記憶領域を、できるだけ一時バッファとして使用する。その結果、通信装置101は、ネットワークバッファが他の処理に使用されるのを妨げずに、メモリ資源を有効に活用して多くのデータを受信できる。
なお、図8を用いた上記の説明においては、通信装置101が一時バッファの使用可否をウィンドウサイズ通知の度に判定するものとしたが、これに限らない。例えば、通信装置101は、図3のS301におけるコネクションの確立に応じて、そのコネクションを介して通信装置102から受信されるデータを記憶するためにスケール単位容量に相当する容量の一時バッファを使用できるか否かを判定してもよい。一時バッファを使用できると判定された場合は、通信装置101はネットワークバッファ内の記憶領域のうち一時バッファとして使用する記憶領域を確保し、対象のコネクションにおいて通知するウィンドウサイズは受信バッファの空き容量を上に丸めた値とする。一方、一時バッファを使用できないと判定された場合には、通信装置101は対象のコネクションにおいて通知するウィンドウサイズを、受信バッファの空き容量を下に丸めた値とする。
このような処理によれば、通信装置101は、一時バッファの使用可否判定と一時バッファの確保をコネクションの確立に応じて一度だけ行えばよく、処理負荷を軽減することができる。
以上説明したように、本実施形態に係る通信装置101は、通信装置102から受信したデータを記憶するために、所定のデータ容量を有する受信バッファに加えて別の記憶領域を使用できるかを判定する。また通信装置101は、通信装置102からの送信を許可するデータ量を判定結果に基づいて決定し、決定された許可するデータ量に応じた通知を通信装置102に対して行う。そして通信装置101は、通知に応じて通信装置102から送信されたデータを受信し、受信したデータを受信バッファに記憶し、また、受信したデータのうち容量不足により受信バッファに記憶できないデータを別の記憶領域に記憶する。
これにより通信装置101は、記憶可能なデータ量に応じた通信データ量で通信装置102と通信できるようになる。例えば通信装置101は、受信バッファとは別の記憶領域が使用できる場合には受信バッファの空き容量より多くのデータ量の送信を通信装置102に許可し、使用できない場合には受信バッファの空き容量以下のデータ量の送信を許可する。その結果、受信したパケットがバッファに記憶できず破棄されることを抑制しつつ、通信のスループット向上させることができる。
なお、本実施形態では通信装置101と通信装置102がウィンドウスケールオプションを使用した通信を行う場合を中心に説明したが、ウィンドウスケールオプションを使用しない通信を行う場合にも本発明を適用できる。すなわち通信装置101は、スケールファクタに関わらず、一時バッファが使用できる場合には受信バッファの空き容量よりも大きい値をウィンドウサイズとして通知し、使用できない場合には空き容量以下の値をウィンドウサイズとして通知してもよい。
また、本実施形態では通信装置101と通信装置102とがTCP/IPに従って通信を行う場合を中心に説明したが、使用するプロトコルはこれに限らない。例えば、通信装置101と通信装置102はUDP(User Datagram Protocol)に従った通信を行ってもよい。そして、HTTPなどTCPよりも上位の層のプロトコルにおいて作成されたメッセージによって、本実施形態で説明した通信データ量の制御などの機能を実現してもよい。
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC等)によっても実現可能である。また、そのプログラムをコンピュータにより読み取り可能な記録媒体に記録して提供してもよい。
10 通信システム
101 通信装置
102 通信装置
110 ネットワーク
101 通信装置
102 通信装置
110 ネットワーク
Claims (19)
- 通信装置であって、
前記通信装置と他の通信装置との間の論理的な通信路が確立される際に予約される容量の受信バッファに、前記他の通信装置から受信したデータを記憶させる第1記憶手段と、
前記他の通信装置から受信したデータのうち前記受信バッファに記憶されないデータを、前記受信バッファとは別の記憶領域に記憶させる第2記憶手段と、
前記他の通信装置から受信したデータを前記第2記憶手段が前記記憶領域に記憶させることができるかを判定する判定手段と、
前記他の通信装置からの送信を許可するデータ量を前記判定手段による判定結果に基づいて決定する決定手段と、
前記他の通信装置に対して、前記決定手段により決定された前記許可するデータ量に応じた通知を行う通知手段と、
前記通知手段による通知に応じて前記他の通信装置から送信されるデータを受信する受信手段とを有することを特徴とする通信装置。 - 前記受信バッファは、前記通信路が確立される際に前記通信路と対応づけて予約された領域であり、
前記記憶領域は、特定の通信路に対応付けされていない領域であることを特徴とする請求項1に記載の通信装置。 - 前記決定手段は、前記許可するデータ量を前記受信バッファの空き容量以下の第1データ量とするか、前記受信バッファの空き容量より大きい第2データ量とするかを決定することを特徴とする請求項1又は2に記載の通信装置。
- 前記判定手段は、前記他の通信装置から受信したデータを前記第2記憶手段が記憶させるための前記記憶領域として、前記許可するデータ量の候補である前記第2データ量から前記受信バッファの空き容量を差し引いたデータ量に相当する容量の記憶領域を使用できるかを判定することを特徴とする請求項3に記載の通信装置。
- 前記決定手段は、前記差し引いたデータ量に相当する容量の前記記憶領域を使用できないと前記判定手段により判定された場合には、前記許可するデータ量を前記第1データ量とし、前記差し引いたデータ量に相当する容量の前記記憶領域を使用できると前記判定手段により判定された場合には、前記許可するデータ量を前記第2データ量とすることを特徴とする請求項4に記載の通信装置。
- 前記決定手段は、前記受信バッファの空き容量が閾値よりも大きい場合には、前記許可するデータ量を前記判定手段による判定結果に基づいて決定し、前記受信バッファの空き容量が前記閾値よりも小さい場合には、前記許可するデータ量を前記第1データ量とすることを特徴とする請求項3又は4に記載の通信装置。
- 前記閾値は、前記通信装置と前記他の通信装置との間の通信路におけるMTU(Maximum Transmission Unit)であることを特徴とする請求項6に記載の通信装置。
- 前記決定手段は、前記受信バッファの空き容量が前記MTUよりも大きく、且つ、TCP(Transmission Control Protocol)のウィンドウスケールオプションのスケールファクタにより定まるスケール単位容量が前記MTUよりも小さい場合には、前記許可するデータ量を前記第1データ量とすることを特徴とする請求項7に記載の通信装置。
- 前記決定手段は、前記受信バッファの空き容量が閾値よりも小さい場合には、前記許可するデータ量を前記判定手段による判定結果に基づいて決定し、前記受信バッファの空き容量が前記閾値よりも大きい場合には、前記許可するデータ量を前記第1データ量とすることを特徴とする請求項3又は4に記載の通信装置。
- 前記閾値は、TCPのウィンドウスケールオプションのスケールファクタにより定まるスケール単位容量であることを特徴とする請求項9に記載の通信装置。
- 前記決定手段は、前記受信バッファの空き容量と前記第1データ量との差、及び前記受信バッファの空き容量と前記第2データ量との差の少なくとも何れかに基づいて、前記許可するデータ量を前記第1データ量とするか前記第2データ量とするかを決定することを特徴とする請求項3又は4に記載の通信装置。
- 前記判定手段は、前記通信装置がデータを記憶する領域が所定の分割単位に分割された複数の分割領域のうち、データ容量の一部が前記受信バッファに対応する分割領域の、前記受信バッファに対応しない部分を、前記他の通信装置から受信したデータを前記第2記憶手段が記憶させるための前記記憶領域として使用できるかを判定することを特徴とする請求項1乃至11の何れか1項に記載の通信装置。
- 前記判定手段は、前記他の通信装置から受信されるデータを前記第2記憶手段が記憶するための前記記憶領域として、TCPのウィンドウスケールオプションのスケールファクタにより定まるスケール単位容量に相当する容量の記憶領域を使用できるかを、前記通信路の確立に応じて判定することを特徴とする請求項1乃至3の何れか1項に記載の通信装置。
- 前記受信バッファは、前記通信装置と前記他の通信装置との間の論理的な通信路としてのTCPにおけるコネクションに対応する受信バッファであり、
前記送信を許可するデータ量は、TCPで規定されたウィンドウサイズが示すデータ量であることを特徴とする請求項1乃至13の何れか1項に記載の通信装置。 - 前記通知手段、TCPのウィンドウスケールオプションのスケールファクタに従うウィンドウサイズに関する情報を通知し、
前記第1データ量は、前記スケールファクタにより定まるスケール単位容量の整数倍のデータ量であり且つ前記受信バッファの空き容量を超えないデータ量であり、
前記第2データ量は、前記スケール単位容量の整数倍のデータ量であり且つ前記受信バッファの空き容量より大きいデータ量あることを特徴とする請求項3乃至11の何れか1項に記載の通信装置。 - 通信装置が他の通信装置から受信したデータを、前記通信装置と前記他の通信装置との間の論理的な通信路が確立される際に予約される容量の受信バッファとは別の記憶領域に記憶させることができるかを判定する判定工程と、
前記他の通信装置からの送信を許可するデータ量を前記判定工程における判定結果に基づいて決定する決定工程と、
前記他の通信装置に対して、前記決定工程において決定された前記許可するデータ量に応じた通知を行う通知工程と、
前記通知工程における通知に応じて前記他の通信装置から送信されるデータを前記通信装置が受信する受信工程と、
前記受信工程において受信されたデータを前記受信バッファに記憶させる第1記憶工程と、
前記受信工程において受信されたデータのうち前記受信バッファに記憶されないデータを、前記記憶領域に記憶させる第2記憶工程とを有することを特徴とする通信方法。 - 前記受信バッファは、前記通信路が確立される際に前記通信路と対応づけて予約された領域であり、
前記記憶領域は、特定の通信路に対応付けされていない領域であることを特徴とする請求項16に記載の通信方法。 - 前記決定工程は、前記許可するデータ量を前記受信バッファの空き容量以下の第1データ量とするか、前記受信バッファの空き容量より大きい第2データ量とするかを決定することを特徴とする請求項16又は17に記載の通信方法。
- コンピュータを、請求項1乃至15の何れか1項に記載の通信装置の各手段として動作させるためのプログラム。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016201254A JP2018064187A (ja) | 2016-10-12 | 2016-10-12 | 通信装置、通信方法およびプログラム |
CN201710914380.3A CN107948236B (zh) | 2016-10-12 | 2017-09-30 | 通信装置、通信方法以及存储介质 |
US15/729,268 US10284481B2 (en) | 2016-10-12 | 2017-10-10 | Communication device, communication method, and storage medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016201254A JP2018064187A (ja) | 2016-10-12 | 2016-10-12 | 通信装置、通信方法およびプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2018064187A true JP2018064187A (ja) | 2018-04-19 |
Family
ID=61829201
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016201254A Pending JP2018064187A (ja) | 2016-10-12 | 2016-10-12 | 通信装置、通信方法およびプログラム |
Country Status (3)
Country | Link |
---|---|
US (1) | US10284481B2 (ja) |
JP (1) | JP2018064187A (ja) |
CN (1) | CN107948236B (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109272752A (zh) * | 2018-10-11 | 2019-01-25 | 南威软件股份有限公司 | 一种路口车辆图片采集***的传输方法及传输*** |
JP2020184673A (ja) * | 2019-05-08 | 2020-11-12 | 住友電気工業株式会社 | 車載装置、システム、制御方法、半導体集積回路及びコンピュータプログラム |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6693547B2 (ja) * | 2018-09-28 | 2020-05-13 | ダイキン工業株式会社 | 情報送信装置および機器管理システム |
CN114221905A (zh) * | 2020-09-03 | 2022-03-22 | 阿里巴巴集团控股有限公司 | 处理单元及流控制单元、以及相关方法 |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2005010766A1 (ja) * | 2003-07-24 | 2005-02-03 | Fujitsu Limited | データ格納システム |
JP4235506B2 (ja) * | 2003-08-14 | 2009-03-11 | 株式会社エヌ・ティ・ティ・ドコモ | 送信装置、中継装置およびプログラム |
EP1829266B1 (en) * | 2004-12-22 | 2008-10-29 | Telefonaktiebolaget LM Ericsson (publ) | Data flow control with duplicate acknowledgment |
CN100591050C (zh) * | 2007-03-12 | 2010-02-17 | 杭州华三通信技术有限公司 | 支持多通道数据传输的数据传输装置及方法 |
JP5049834B2 (ja) | 2008-03-26 | 2012-10-17 | 株式会社東芝 | データ受信装置、データ受信方法およびデータ処理プログラム |
US8793463B2 (en) * | 2011-09-12 | 2014-07-29 | Microsoft Corporation | Allocation strategies for storage device sets |
US9804928B2 (en) * | 2011-11-14 | 2017-10-31 | Panzura, Inc. | Restoring an archived file in a distributed filesystem |
CN103051559B (zh) * | 2012-12-28 | 2016-11-23 | 华为技术有限公司 | 数据流接收处理方法和装置 |
US9128638B2 (en) * | 2013-07-22 | 2015-09-08 | Progress Rail Services Corporation | Integrated time-stamped event recorder |
JP6369332B2 (ja) * | 2015-01-05 | 2018-08-08 | 株式会社オートネットワーク技術研究所 | 車載中継装置 |
US10545684B2 (en) * | 2015-05-13 | 2020-01-28 | Hitachi, Ltd. | Storage device |
US10417102B2 (en) * | 2016-09-30 | 2019-09-17 | Commvault Systems, Inc. | Heartbeat monitoring of virtual machines for initiating failover operations in a data storage management system, including virtual machine distribution logic |
-
2016
- 2016-10-12 JP JP2016201254A patent/JP2018064187A/ja active Pending
-
2017
- 2017-09-30 CN CN201710914380.3A patent/CN107948236B/zh active Active
- 2017-10-10 US US15/729,268 patent/US10284481B2/en active Active
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109272752A (zh) * | 2018-10-11 | 2019-01-25 | 南威软件股份有限公司 | 一种路口车辆图片采集***的传输方法及传输*** |
CN109272752B (zh) * | 2018-10-11 | 2021-03-02 | 南威软件股份有限公司 | 一种路口车辆图片采集***的传输方法及传输*** |
JP2020184673A (ja) * | 2019-05-08 | 2020-11-12 | 住友電気工業株式会社 | 車載装置、システム、制御方法、半導体集積回路及びコンピュータプログラム |
JP7283215B2 (ja) | 2019-05-08 | 2023-05-30 | 住友電気工業株式会社 | 車載装置、システム、制御方法、半導体集積回路及びコンピュータプログラム |
Also Published As
Publication number | Publication date |
---|---|
US10284481B2 (en) | 2019-05-07 |
CN107948236B (zh) | 2021-03-09 |
US20180102977A1 (en) | 2018-04-12 |
CN107948236A (zh) | 2018-04-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8478890B2 (en) | System and method for reliable virtual bi-directional data stream communications with single socket point-to-multipoint capability | |
US10284481B2 (en) | Communication device, communication method, and storage medium | |
US9906581B2 (en) | Information processing apparatus, control method, and storage medium | |
US10708816B2 (en) | Communication apparatus, communication method, and non-transitory computer-readable storage medium for performing packetization processing that does not depend on a network interface | |
US20180139255A1 (en) | Communication apparatus, communication method, and storage medium | |
WO2019224860A1 (ja) | 通信装置、通信方法及び通信プログラム | |
JP5418530B2 (ja) | 通信装置 | |
JP2014195158A (ja) | 通信装置と、当該通信装置を含む通信システム、及びその制御方法とプログラム | |
US9762511B2 (en) | Communication device | |
US11172053B2 (en) | Transfer apparatus, transfer method, and program for transporting data from a single source to sinks with different communication requirements | |
US8107451B2 (en) | Efficient deallocation of network resources based on network node location extrapolation | |
JP6758858B2 (ja) | 通信装置、通信方法及びプログラム | |
JP2019016842A (ja) | 通信装置および制御方法 | |
JP2017027196A (ja) | 通信装置、電力制御方法、及び電力制御プログラム | |
JP2017038297A (ja) | 通信装置、通信方法、及び通信システム | |
JP2016019198A (ja) | 通信装置、通信装置の制御方法、プログラム | |
US20230062831A1 (en) | Communication apparatus and control method thereof, and storage medium | |
US20080091841A1 (en) | Communication method, communication system, communication apparatus, and recording medium | |
RU2576525C1 (ru) | Способ распределения ресурсов и устройство | |
CN113498040B (zh) | 一种停止发送调度请求的方法及装置 | |
JP2017157964A (ja) | 通信装置、制御方法、および、プログラム | |
JP6800514B2 (ja) | 通信装置、その制御方法、およびプログラム | |
JP2018142850A (ja) | 通信装置、通信方法及びプログラム | |
JP5771169B2 (ja) | システム | |
JP2010154329A (ja) | Ieee1394通信lsiおよびアシンクロナス送信方法 |