JP2018064187A

JP2018064187A - 通信装置、通信方法およびプログラム

Info

Publication number: JP2018064187A
Application number: JP2016201254A
Authority: JP
Inventors: 達彦富所; Tatsuhiko Tomisho
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2016-10-12
Filing date: 2016-10-12
Publication date: 2018-04-19
Also published as: CN107948236B; US20180102977A1; US10284481B2; CN107948236A

Abstract

【課題】通信装置が記憶可能なデータ量に応じた通信データ量で他の通信装置と通信できるようにする。
【解決手段】通信装置１０１は、通信装置１０２から受信したデータを記憶するために、受信バッファに加えて別の記憶領域を使用できるかを判定する。また通信装置１０１は、通信装置１０２からの送信を許可するデータ量を判定結果に基づいて決定し、決定された許可するデータ量に応じた通知を通信装置１０２に対して行う。そして通信装置１０１は、通知に応じて通信装置１０２から送信されたデータを受信し、受信したデータを受信バッファに記憶させ、また、受信バッファに記憶させないデータを別の記憶領域に記憶させる。
【選択図】図８

Description

本発明は、通信装置間で送受信されるデータの量を制御する技術に関する。

通信装置間での通信方式の一つに、ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）／ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）がある。ＴＣＰ／ＩＰに従った通信を行う通信装置は、通信相手となる他の通信装置との間で論理的な通信路（コネクション）を確立し、通信路ごとに受信バッファを管理する。通信装置が受信したデータは受信バッファに一時的に記憶される。受信バッファには容量が定められており、通信装置のメモリ資源が各受信バッファとして割り当てられる。

通信装置に対して受信バッファの容量を超えたデータが送信されないようにするために、ＴＣＰ／ＩＰにはウィンドウ制御の機能がある。ウィンドウ制御において、データの受信装置は、対象の通信路における送信を許可するデータ量を示すウィンドウサイズとして受信バッファの容量をデータの送信装置に通知する。送信装置は、通知されたウィンドウサイズ以下の量のデータを対象の通信路を用いて受信装置に送信する。このウィンドウ制御によって、受信装置の受信バッファの容量を超えるデータが送信装置から送信されることを防ぐことができる。

一方、特許文献１には、通信装置が受信バッファの空き容量より大きい値のウィンドウサイズを通知することが記載されている。そして、通信装置が受信バッファの空き容量より大きいサイズのデータを受信した際には、受信バッファと異なる一時バッファを使用することで受信バッファに記憶しきれないデータを記憶することが記載されている。

特開２００９−２３７７６８号公報

しかしながら、特許文献１に記載の通信方法では、通信装置が記憶可能なデータ量より大きいサイズのデータを受信することによって通信効率が低下する場合が考えられる。例えば、通信装置がメモリ資源の不足により一時バッファを使用することができない場合に、受信バッファの空き容量より大きいサイズのデータを受信すると、受信バッファに記憶しきれない受信データが破棄され通信効率が低下する虞がある。

本発明は上記課題に鑑みて成されたものであり、通信装置が記憶可能なデータ量に応じた通信データ量で他の通信装置と通信できるようにすることを目的とする。

上記の課題を解決するため、本発明に係る通信装置は、例えば以下の構成を有する。すなわち、他の通信装置から受信したデータを受信バッファに記憶させる第１記憶手段と、前記他の通信装置から受信したデータのうち前記受信バッファに記憶されないデータを、前記受信バッファとは別の記憶領域に記憶させる第２記憶手段と、前記他の通信装置から受信したデータを前記第２記憶手段が前記記憶領域に記憶させることができるかを判定する判定手段と、前記他の通信装置からの送信を許可するデータ量を前記判定手段による判定結果に基づいて決定する決定手段と、前記他の通信装置に対して、前記決定手段により決定された前記許可するデータ量に応じた通知を行う通知手段と、前記通知手段による通知に応じて前記他の通信装置から送信されるデータを受信する受信手段とを有することを特徴とする通信装置。

本発明によれば、通信装置が記憶可能なデータ量に応じた通信データ量で他の通信装置と通信できるようになる。

通信システム１０の構成を説明するための図である。通信装置１０１のハードウェア構成について説明するためのブロック図である。通信装置１０１の動作について説明するためのフローチャートである。ウィンドウスケールオプションのフォーマットについて説明するための図である。スケールファクタとスケール単位容量の対応関係について説明するための図である。スケールファクタに従ったウィンドウサイズについて説明するための図である。通信装置１０１と通信装置１０２との間の通信内容について説明するためのシーケンス図である。通信装置１０１によるウィンドウサイズを決定するための動作について説明するためのフローチャートである。ネットワークバッファの内部構造について説明するための図である。

以下、本発明の実施形態について、図面を参照して説明する。なお、以下の実施形態で説明する特徴の組み合わせの全てが本発明に必須のものとは限らない。

［システム構成］
図１に、本実施形態に係る通信システム１０の構成を示す。通信システム１０は通信装置１０１と通信装置１０２とを含み、通信装置１０１と通信装置１０２とはネットワーク１１０を介してＴＣＰ／ＩＰ通信を行う。なお、本実施形態においてネットワーク１１０はＥｔｈｅｒｎｅｔ（登録商標）規格に準拠したＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）により構成される。ただしこれに限らず、ネットワーク１１０は例えば、インターネットを含んでいてもよいし、ＩＥＥＥ８０２．１１シリーズ規格やＢｌｕｅｔｏｏｔｈ（登録商標）規格に準拠した無線ＬＡＮを含んでいてもよい。また、本実施形態では通信装置１０１と通信装置１０２の２台の装置の間での通信に注目して説明を行うが、３台以上の装置がネットワーク１１０を介して通信を行ってもよい。また、本実施形態では通信装置１０１と通信装置１０２とがＴＣＰ／ＩＰに基づいて通信を行う場合を例に説明するが、通信装置１０１と通信装置１０２は他のプロトコルに基づく通信を行ってもよい。

図２に、本実施形態に係る通信装置１０１のハードウェア構成を示す。なお、通信装置１０２も通信装置１０１と同様のハードウェア構成である。通信装置１０１は、記憶部２０１、制御部２０２、機能部２０３、入力部２０４、出力部２０５、及び通信部２０６を有する。

記憶部２０１は、ＲＯＭやＲＡＭ等のメモリを有し、通信装置１０１の後述する各種動作を行うためのプログラムや、ＴＣＰ／ＩＰ通信のための通信パラメータ等の各種情報を記憶する。また、記憶部２０１は通信装置１０１と通信装置１０２との間で送受信するデータを記憶するネットワークバッファとしても機能する。なお、記憶部２０１として、ＲＯＭやＲＡＭ等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、及びＤＶＤなどの記憶媒体を用いてもよい。

制御部２０２は、ＣＰＵやＭＰＵ等のプロセッサを有し、記憶部２０１に記憶されたプログラムを読み出して実行することで通信装置１０１全体を制御する。なお、制御部２０２は、記憶部２０１に記憶されたプログラムとＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）との協働により通信装置１０１全体を制御してもよい。また、制御部２０２がマルチコア等により複数のプロセッサを備え、複数のプロセッサにより通信装置１０１全体を制御してもよい。

機能部２０３は、通信装置１０１が所定の処理を実行するためのハードウェアである。例えば、通信装置１０１がカメラである場合、機能部２０３は撮像部を有し、撮像処理を行う。また例えば、通信装置１０１がプリンタである場合、機能部２０３は印刷部を有し、印刷処理を行う。また例えば、通信装置１０１がプロジェクタである場合、機能部２０３は投影部を有し、投影処理を行う。機能部２０３が処理するデータは、記憶部２０１に予め記憶されているデータであってもよいし、後述する通信部２０６を介した他の装置との通信により取得されたデータであってもよい。

入力部２０４は、ユーザによる各種入力操作を受け付ける。出力部２０５は、ユーザに対して各種出力を行う。ここで、出力部２０５による出力は、例えば表示部による画像出力や、スピーカーによる音声出力、及び振動出力などである。なお、タッチパネルなどによって入力部２０４と出力部２０５の両方を１つのモジュールで実現してもよい。また、入力部２０４や出力部２０５が通信装置１０１の外部に別の装置として存在していてもよい。この場合、制御部２０２が、入力部２０４を制御する入力制御部、及び出力部２０５を制御する出力制御部として動作する。

通信部２０６は、ＴＣＰ／ＩＰ通信の制御を行い、例えば画像データや文書データ、及び音声データ等のコンテンツを、通信装置１０２などの他の装置との間で送受信する。

［動作フロー］
まず、ＴＣＰ／ＩＰプロトコルに基づく通信における基本的な動作を説明する。通信の開始時に、通信装置１０１と通信装置１０２との間にはデータの送受信を行うための論理的な通信路（コネクション）が確立される。なお、通信装置１０１は複数のコネクションを確立することもできる。

ＴＣＰ／ＩＰプロトコル処理を行う通信装置１０１及び通信装置１０２には、通信データのパケット化や送受信処理のために、ネットワークバッファが用意されている。ネットワークバッファは複数のコネクションにおいて共用され、また送信処理と受信処理でも共用される。ＴＣＰ／ＩＰパケットの送信を行う通信装置１０２では、アプリケーションからのデータ送信命令に従って指定されたデータが、送信バッファとして割り当てられたネットワークバッファ内の記憶領域にコピーされる。そして、記憶領域にコピーされた送信データは、ＭＴＵ（ＭａｘｉｍｕｍＴｒａｎｓｍｉｓｓｉｏｎＵｎｉｔ、最大伝送単位）に応じて分割される。ここでＭＴＵは、送信側の通信装置から受信側の通信装置へ単一のフレームで伝送されるデータの最大サイズである。そして、分割された送信データにＴＣＰヘッダとＩＰヘッダが追加されたＴＣＰ／ＩＰパケットが生成される。伝送経路がＥｔｈｅｒｎｅｔの場合、さらに、Ｅｔｈｅｒｎｅｔヘッダが付加されたＥｔｈｅｒｎｅｔフレームが生成され通信装置１０１へ送信される。

ＴＣＰ／ＩＰパケットの受信を行う通信装置１０１では、ネットワークから受信されたパケットが通信部２０６内のメモリ等に一旦保持され、パケットのヘッダ部分とデータ部分に分割される。そしてパケットのデータ部分が、コネクションに対応する受信バッファとして割り当てられたネットワークバッファ内の記憶領域に記憶される。さらに、アプリケーションのデータ受信命令に従って受信バッファ内のデータがアプリケーションの用意したデータバッファ（アプリケーションバッファ）に移動（読み出し）され、受信したデータに対して処理が実施される。なお、受信バッファは、コネクションが確立される際に予約される所定のデータ容量を有し、データ容量を超えるデータを記憶することはできない。具体的な予約のタイミングは、コネクション確立のために行われるＴＣＰにおけるスリーウェイハンドシェイクの前であってもよいし、スリーウェイハンドシェイクの後であってもよいし、スリーウェイハンドシェイクの途中であってもよい。

また、ＴＣＰ／ＩＰはウィンドウ制御と呼ばれる機能を持つ。ＴＣＰ／ＩＰのウィンドウ制御では、データ受信側の通信装置１０１は受信バッファの空き容量に応じてウィンドウサイズを決定する。そして通信装置１０１は、決定したウィンドウサイズの値を示すＡＣＫ（確認応答，Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）パケットをデータ送信側の通信装置１０２へ送信する。そして、通信装置１０２はウィンドウサイズ以下のデータ量のデータを次のＡＣＫパケットを待つことなく通信装置１０１へ送信することができる。すなわち、ＴＣＰで規定されたウィンドウサイズは通信装置１０２からのコネクションを使用した送信を許可するデータ量を示し、ＡＣＫパケットに含まれるウィンドウサイズに関する情報は通信装置１０２の送信データ量を制御する制御情報となる。

通信装置１０１は、受信したパケットをアプリケーションが受信バッファから読み出していない場合、受信バッファが空の場合よりも小さいウィンドウサイズを示すＡＣＫパケットを通信装置１０２に通知する。受信したパケットをアプリケーションが読み出すと受信バッファの空き容量が増えるため、この後に送信されるＡＣＫパケットでは大きくなったウィンドウサイズが通信装置１０２に通知される。

また、ＴＣＰ／ＩＰでは通知できるウィンドウサイズの上限を拡大するためのオプションとしてウィンドウスケールオプションがある。ウィンドウスケールオプションは、通信装置１０２から通信装置１０１へのコネクション確立要求、およびコネクション確立要求への通信装置１０２による応答に、図４のようなウィンドウスケールオプションを示すパラメータが含まれている場合に有効となる。ウィンドウスケールオプションが有効になっている場合、通信装置１０１は、ＴＣＰのウィンドウスケールオプションに従うウィンドウサイズに関する情報を含むＡＣＫパケットを送信することで、通信装置１０２にウィンドウサイズを通知する。具体的には、ウィンドウスケールオプションのＳｈｉｆｔ．ｃｎｔフィールドの値が、ウィンドウサイズの拡大量に対応するスケールファクタを示す。通信装置１０１からＡＣＫパケットを受信した通信装置１０２は、ＴＣＰヘッダ中のウィンドウフィールド値をスケールファクタ分だけビットシフトすることで、ウィンドウサイズを算出する。

ウィンドウスケールオプションが有効であるとき、ウィンドウフィールド値が１の場合のウィンドウサイズに対応するスケール単位容量は次のように示される。

スケール単位容量＝２＾スケールファクタ（バイト）
従って、ウィンドウサイズは次のように示される。

ウィンドウサイズ＝ウィンドウフィールド値×２＾スケールファクタ（バイト）
ウィンドウスケールオプションでは、スケールファクタは「０」から「１４」の値で示される。図５はスケールファクタとスケール単位容量との対応関係を表す図である。

図６を用いて、スケールファクタに従ったウィンドウサイズについてさらに説明する。本実施形態において、ウィンドウスケールオプションが有効な場合に通知されるウィンドウサイズは、スケールファクタにより定まるスケール単位容量と受信バッファの空き容量とに応じて決定される。図６（Ａ）はスケール単位容量が２５６バイト、すなわちスケールファクタが８の場合の空きバッファ容量とウィンドウサイズの対応関係を示している。図６（Ｂ）はスケール単位容量が２０４８バイト、すなわちスケールファクタが１１の場合の空きバッファ容量とウィンドウサイズの対応関係を示している。

ウィンドウスケールオプションを使用した通信において、ウィンドウフィールド値が整数であるため、ウィンドウサイズはスケール単位容量の倍数、すなわち２のｎ乗（ｎはスケールファクタに対応する整数）の倍数となる。しかしながら、受信バッファの空き容量は必ずしも２のｎ乗の倍数となるとは限らない。そのため、受信バッファの空き容量に応じてウィンドウサイズを決定する際に、ウィンドウサイズと空き容量との間に丸め誤差が発生する場合がある。受信バッファの空き容量を下に丸めた場合（ウィンドウサイズが空き容量より小さくなるようなウィンドウフィールド値が設定された場合）のウィンドウサイズは、空き容量をスケール単位容量で除算した商に対してスケール単位容量を乗算した値となる。空き容量を上に丸めた場合（ウィンドウサイズが空き容量より大きくなるようなウィンドウフィールド値が設定された場合）のウィンドウサイズは、空き容量をスケール単位容量で除算した商に１を加算した値に対してスケール単位容量を乗算した値となる。

仮に、通信装置１０１が受信バッファの空き容量を常に下に丸めて、空き容量よりも小さいウィンドウサイズを通知すると、通信装置１０２からは受信バッファの空き容量よりも少ないデータ量しか送信されない。そのため、受信バッファを効率良く利用できない場合がある。一方、通信装置１０１が受信バッファの空き容量を常に上に丸めて、空き容量よりも大きいウィンドウサイズを通知すると、通信装置１０２は受信バッファの空き容量よりも多くのデータを送信する場合がある。そのため、通信装置１０１では受信データが受信バッファからあふれて破棄されることが考えられる。本実施形態では、通信装置１０１がウィンドウサイズを上に丸めるか下に丸めるかを状況に応じて決定することで、高い通信効率を実現する。

次に、図３を用いて、通信装置１０１と通信装置１０２が通信を行う際の通信装置１０１の動作について説明する。図３の処理は、通信装置１０１と通信装置１０２との通信を開始するための指示が入力部２０４を介してユーザにより行われたタイミングで開始される。ただし、図３の処理の開始タイミングは上記タイミングに限定されない。例えば、通信を開始するための指示がアプリケーションにより行われたタイミングや、タイマに応じたタイミングであってもよい。図３の処理は、記憶部２０１に記憶されたプログラムを制御部２０２が読み出して実行することで実現される。

なお、図３に示す処理の少なくとも一部をハードウェアにより実現してもよい。ハードウェアにより実現する場合、例えば、所定のコンパイラを用いることで、各ステップを実現するためのプログラムからＦＰＧＡ（ＦｉｅｌｄＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ）上に自動的に専用回路を生成すればよい。また、ＦＰＧＡと同様にしてＧａｔｅＡｒｒａｙ回路を形成し、ハードウェアとして実現するようにしてもよい。また、ＡＳＩＣ（ＡｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）により実現するようにしてもよい。

Ｓ３０１では、通信装置１０１は、ＴＣＰにおけるスリーウェイハンドシェイクによって通信装置１０２とコネクションを確立する。スリーウェイハンドシェイクにおいて行われる通信において、通信装置１０１はコネクション確立要求への応答（ＳＹＮ＿ＡＣＫパケット）によって通信装置１０２にウィンドウサイズを通知する。なお、ＳＹＮ＿ＡＣＫパケットにより通知されるウィンドウサイズにはウィンドウスケールオプションが適用されない。コネクション確立時の通信によりウィンドウスケールオプションが有効となった場合、コネクション確立より後のデータ受信に対する応答（ＡＣＫパケット）により通知されるウィンドウサイズにウィンドウスケールオプションが適用される。

Ｓ３０２では、通信装置１０１がコネクションを維持するか否か判断する。コネクションを維持すると判断した場合は、Ｓ３０３に進む。一方、コネクションを維持しないと判断した場合はＳ３０７に進み、通信装置１０１はコネクションを切断して処理を終了する。コネクションを維持しないと通信装置１０１が判断する場合とは、例えば、通信装置１０２から通信装置１０１へのデータ送信が所定時間行われない場合や、通信装置１０１に対して通信を終了する指示がなされた場合などである。

Ｓ３０３では、通信装置１０１が、通信装置１０２から受信したデータの少なくとも一部を、所定のデータ容量を有する受信バッファの空き領域に記憶させる。本実施形態において、受信データのうち記憶される少なくとも一部のデータは、受信バッファの空き領域に記憶可能な量のデータである。Ｓ３０４では、通信装置１０１が、Ｓ３０３で受信バッファに記憶した受信データに加えて、受信バッファの容量不足により受信バッファに記憶できない受信データがあるかを判断する。受信バッファに記憶できない受信データがなければＳ３０６に進み、記憶できないデータがある場合はＳ３０５に進む。Ｓ３０５では、通信装置１０１が、通信装置１０２から受信したデータのうち、受信バッファに記憶されないデータを、一時バッファに記憶させる。ここで一時バッファとは、ネットワークバッファ内の記憶領域のうち受信バッファとして割り当てられていない記憶領域であり、受信バッファの容量不足により受信バッファから溢れたデータを記憶するために一時的に使用される記憶領域である。

すなわち、通信装置１０１は、通信装置１０２との間のコネクションを介して受信されたデータを、該コネクションの確立に応じて該コネクションと対応付けて予約された領域である受信バッファに記憶する。そして、該コネクションを介して受信されたデータのうち、受信バッファの容量不足により受信バッファに記憶できないデータを、特定のコネクションに対応付けされていない記憶領域に記憶する。

Ｓ３０６において、通信装置１０１は、受信バッファの空き容量に基づいてウィンドウサイズを算出し、通信装置１０２に対してＡＣＫパケットを用いてウィンドウサイズを通知する。ウィンドウサイズの算出方法については後述する。Ｓ３０６の処理が終了するとＳ３０２に進み、Ｓ３０２−Ｓ３０６までのデータ受信処理を繰り返す。

図７は、通信装置１０１と通信装置１０２とが通信を行う場合の通信シーケンスの例を示す。Ｓ６０１からＳ６０３は通信装置１０１と通信装置１０２との間のコネクション確立に関するシーケンスである。Ｓ６０１において通信装置１０２は通信装置１０１に対してコネクション確立要求を送信し、Ｓ６０２において通信装置１０１は通信装置１０２に対してコネクション確立要求への応答を送信する。ここでは、Ｓ６０１及びＳ６０２においてウィンドウスケールオプションのＳｈｉｆｔ．ｃｎｔの値はいずれも「８」である。すなわち、スケール単位容量として２５６バイトが通知されている。

Ｓ６０４からＳ６０７は、通信装置１０２から通信装置１０１に対してデータが送信され、通信装置１０１から通信装置１０２に対して確認応答が送信されるシーケンスである。通信装置１０１の受信バッファの容量が４５００バイトである場合、Ｓ６０４において通信装置１０１が１５００バイトのデータを受信すると受信バッファの空き容量が３０００バイトとなる。Ｓ６０５において通信装置１０１はＡＣＫパケットを送信することで、通信装置１０２に対してウィンドウサイズを通知する。

ここで、受信バッファの空き容量が３０００バイトであり、スケール単位容量が２５６バイトであるため、ウィンドウサイズと空き容量との間の丸め誤差が発生する。受信バッファの空き容量を下に丸めた場合（ウィンドウフィールド値を１１に設定した場合）は通知されるウィンドウサイズが２８１６バイトとなり、空き容量を上に丸めた場合（ウィンドウフィールド値を１２に設定した場合）は３０７２バイトとなる。受信バッファの空き容量が３０００バイトである場合に、３０７２バイトのウィンドウサイズを通知すると、７２バイト分のバッファが不足する可能性がある。そこで通信装置１０１は、７２バイト以上の容量の一時バッファを確保可能であれば３０７２バイトのウィンドウサイズを通信装置１０２に通知し、そうでなければ２８１６バイトのウィンドウサイズを通信装置１０２に通知する。

Ｓ６０６において、通信装置１０１が１５００バイトのデータを受信すると、受信バッファの空き容量が１５００バイトとなる。Ｓ６０７において通信装置１０１はＡＣＫパケットを送信するが、Ｓ６０５と同様にウィンドウサイズの丸め誤差が発生する。受信バッファの空き容量を下に丸めた場合は通知するウィンドウサイズは１２８０バイトとなり、上に丸めた場合は１５３６バイトとなる。そこで通信装置１０１は、バッファが不足する可能性がある３６バイト以上の容量の一時バッファを確保可能であれば１５３６バイトのウィンドウサイズを通信装置１０２に通知し、そうでなければ１２８０バイトのウィンドウサイズを通信装置１０２に通知する。

すなわち、通信装置１０１は、通信装置１０２から受信したデータを一時バッファに記憶させることができるかを判定する。一時バッファを使用できるか否かは、例えば対象のデータ受信に使用されるコネクションとは別のコネクションにおけるデータ送受信のためのネットワークバッファの使用状況などによって決まる。そして通信装置１０１は、通信装置１０２からの送信を許可するデータ量を示すウィンドウサイズを、判定結果に基づいて決定する。

より具体的には、通信装置１０１は、ウィンドウサイズを受信バッファの空き容量以下の第１データ量とするか、受信バッファの空き容量より大きい第２データ量とするかを決定する。本実施形態において、第１データ量は受信バッファの空き容量をスケールファクタに従って下に丸めた値であり、第２データ量は受信バッファの空き容量をスケールファクタに従って上に丸めた値である。言い換えると、第１データ量は、スケールファクタにより定まるスケール単位容量の整数倍のデータ量であり且つ受信バッファの空き容量を超えないデータ量のうち、最大のデータ量である。また第２データ量は、スケール単位容量の整数倍のデータ量であり且つ受信バッファの空き容量より大きいデータ量のうち、最小のデータ量である。

なお、第１データ量及び第２データ量の決め方はこれに限らない。例えば、第１データ量は受信バッファの空き容量を下に丸めた値よりスケール単位容量の倍数分小さくてもよいし、第２データ量は受信バッファの空き容量を上に丸めた値よりスケール単位容量の倍数分大きくてもよい。

そして通信装置１０１は、ウィンドウサイズの候補である第２データ量（上に丸めた値）から受信バッファの空き容量を差し引いたデータ量に相当する容量の一時バッファを、通信装置１０２から受信したデータを記憶するために使用できるか否か判定する。差し引いたデータ量に相当する容量の一時バッファを使用できないと判定した場合には、ウィンドウサイズを第１データ量（下に丸めた値）とする。また、差し引いたデータ量に相当する容量の一時バッファを使用できると判定した場合には、ウィンドウサイズを第２データ量とする。

通信装置１０１は、ウィンドウサイズを決定すると、決定したウィンドウサイズに応じた制御情報をＡＣＫパケットの送信によって通信装置１０２に通知する。そして通信装置１０１は、通知に応じて通信装置１０２から送信されたデータを受信する。

このような処理により、通信装置１０１は、一時バッファの使用により受信バッファの空き容量より多くのデータを受信できる場合には、受信バッファの空き容量より多くのデータを通信装置１０２が送信できるように制御できる。また、一時バッファが使用できず受信バッファの空き容量以下のデータしか受信できない場合には、受信バッファの空き容量以下のデータを通信装置１０２が送信するように制御できる。これにより、通信装置１０１と通信装置１０２との間の通信における通信効率を向上することができる。そして例えば、Ｓ６０４からＳ６０７の処理が繰り返されることにより通信装置１０１は通信装置１０２からコンテンツデータを取得し、ユーザに対して出力部２０５を介した画像出力や音声出力を行うことができる。

なお、上記の図７の説明では省略したが、本実施形態における通信装置１０１は、受信バッファの空き容量が所定の閾値以上であるか否かを判定し、その判定結果と上述した一時バッファの使用可否の判定結果とに基づいてウィンドウサイズを決定する。本実施形態に係る通信装置１０１の動作について、図８を用いて説明する。なお、本実施形態において上記の所定の閾値はＭＴＵであるが、これに限らず、所定の閾値は例えばスケール単位容量など他の値であってもよい。また、通信装置は受信バッファの空き容量と所定の閾値との比較を行わず、一時バッファの使用可否のみに基づいてウィンドウサイズを決定してもよい。

図８の処理は図３のＳ３０６において行われる処理であり、通信装置１０１がデータを受信してバッファに記憶したタイミングで開始される。ただし図８の処理の開始タイミングはこれに限定されない。図８の処理は、記憶部２０１に記憶されたプログラムを制御部２０２が読み出して実行することで実現される。

Ｓ８０１において、通信装置１０１は、通信装置１０２からのコネクション確立要求およびそのコネクション確立要求への応答においてウィンドウスケールオプションが有効にされていたかを判定する。ウィンドウスケールオプションが有効であると判定した場合は、Ｓ８０２に進む。一方、ウィンドウスケールオプションが有効でないと判定した場合、通信装置１０１は、ウィンドウサイズとして指定可能な値の範囲内において、受信バッファの空き容量をウィンドウサイズとして通知する。すなわち通信装置１０１は、受信バッファの空き容量がウィンドウスケールオプションを使用せずに通知できるウィンドウサイズの上限以下の場合、受信バッファの空き容量をウィンドウサイズとして通知する。一方、受信バッファの空き容量がウィンドウサイズの上限より大きい場合には、通信装置１０１は、例えばその上限の値をウィンドウサイズとして通知する。

Ｓ８０２において、通信装置１０１は、受信バッファの空き容量がＭＴＵ以上であるかを判定する。受信バッファの空き容量がＭＴＵ以上であると判定された場合は、Ｓ８０３に進み、一時バッファの使用可否に基づいてウィンドウサイズが決定される。一方、受信バッファの空き容量がＭＴＵ未満であると判定された場合は、Ｓ８０７に進む。

Ｓ８０３において、通信装置１０１は、受信バッファの空き容量をウィンドウスケールオプションのスケール単位容量の倍数となるよう上に丸めた値を算出する。たとえば受信バッファの空き容量が１５００バイトであり、スケール単位容量が２５６バイトである場合、上に丸めた値は１５３６バイトとなる。Ｓ８０４において、通信装置１０１は、Ｓ８０３で算出した値から受信バッファの空き容量を減算することで、Ｓ８０３で算出した量のデータを受信した場合に受信バッファに記憶しきれないデータ量を算出する。そして、受信バッファに記憶しきれないデータを記憶できる空き容量を持つ一時バッファが使用可能であるか判定する。Ｓ８０４において一時バッファを使用可能であると判定された場合はＳ８０５に進み、使用可能でないと判断された場合はＳ８０７に進む。

なお、本実施形態における通信装置１０１は、Ｓ８０４において、受信バッファの空き容量を上に丸めた値をウィンドウサイズとする場合に必要となる容量の一時バッファを使用可能であるか否か判定する。これにより、必要な容量の一時バッファが使用可能な場合に有効に活用することができる。ただしこれに限らず、通信装置１０１はＳ８０４において、例えばスケール単位容量などの所定の容量の一時バッファが使用可能であるか否か判定してもよい。

Ｓ８０５において、通信装置１０１は、Ｓ８０４で算出したデータ量を記憶できる空き容量を持つネットワークバッファ内の記憶領域を一時バッファとして割り当てる。一時バッファは、通信装置１０１が通信装置１０２から受信したデータのうち、受信バッファの空き容量の不足により受信バッファに記憶できないデータを記憶するために使用される。なお、過去に図８の処理を行って一時バッファとして割り当てられた記憶領域がある場合、割り当て済みの記憶領域の容量とＳ８０４で算出されたデータ量とを比較する。割り当て済みの記憶領域の容量がＳ８０４で算出されたデータ量より小さい場合、その差分に相当する容量の記憶領域が新たに一時バッファとして割り当てられる。一方、割り当て済みの記憶領域の容量がＳ８０４で算出されたデータ量より大きい場合、その差分に相当する容量の記憶領域の割り当てが解除される。

Ｓ８０６において、通信装置１０１は、Ｓ８０３で算出した値をウィンドウサイズとして通信装置１０２に通知する。一方、Ｓ８０７において、通信装置１０１は、受信バッファの空き容量をウィンドウスケールオプションのスケール単位容量の倍数となるように下に丸めた値を、ウィンドウサイズとして通知する。たとえば受信バッファの空き容量が１５００バイトであり、スケール単位容量が２５６バイトである場合、下に丸めた値は１２８０バイトとなる。

図８に示した処理を行うことにより、通信装置１０１は、受信バッファがＭＴＵ以上の空き容量を有する場合には、一時バッファをできるだけ使用して空き容量を有効に活用できる。また、例えば通信装置１０１が一時バッファとして使用可能な記憶領域の容量が小さい場合、複数のコネクションに対応する複数の受信バッファそれぞれに対して十分な容量の一時バッファを割り当てることはできない。そこで通信装置１０１は、受信バッファの空き容量がＭＴＵに満たないほど小さい場合には、一時バッファの使用を抑制することで、容量が限られた記憶領域であるネットワークバッファを他の処理に使用しやすくできる。

なお、Ｓ８０２において通信装置１０１は、受信バッファの空き容量がＭＴＵ以上であるか否かに加えて、スケール単位容量がＭＴＵ未満であるか否かを判定してもよい。そして、受信バッファの空き容量がＭＴＵ以上であり、且つスケール単位容量がＭＴＵ未満である場合には、通信装置１０１は受信バッファの空き容量を下に丸めた値をウィンドウサイズとする。また、受信バッファの空き容量がＭＴＵ未満である場合も、受信バッファの空き容量を下に丸めた値をウィンドウサイズとする。一方、受信バッファの空き容量がＭＴＵ以上であり、且つスケール単位容量がＭＴＵ以上である場合には、一時バッファの使用可否に基づいてウィンドウサイズを決定する。

このような処理によれば、通信装置１０１は、スケール単位容量がＭＴＵ以上となるような丸め誤差が大きくなる可能性が高い場合に、一時バッファをできるだけ使用して、受信バッファの空き容量のうち活用されない部分が大きくなることを抑制できる。また通信装置１０１は、スケール単位容量がＭＴＵ未満となるような丸め誤差が小さくなる可能性が高い場合には、一時バッファの使用を抑制し、よりネットワークバッファを他の処理に使用しやすくできる。

また、図８の処理では受信バッファの空き容量が所定の閾値（ＭＴＵ）以上である場合に一時バッファの使用可否を判定するものとしたが、逆に、受信バッファの空き容量が所定の閾値未満である場合に一時バッファの使用可否を判定してもよい。例えば、通信装置１０１は、Ｓ８０２の処理に代えて、受信バッファの空き容量がスケール単位容量未満であるか否か判定する。そして、受信バッファの空き容量がスケール単位容量未満である場合には、Ｓ８０３に進み、一時バッファの使用可否に基づいてウィンドウサイズを決定する。一方、受信バッファの空き容量がスケール単位容量以上である場合には、Ｓ８０７に進み、空き容量を下に丸めた値をウィンドウサイズとする。

このような処理によれば、通信装置１０１は、一時バッファを使用しなければウィンドウサイズが０となりデータを受信できない場合に、一時バッファをできるだけ使用してデータの受信を継続できる。また通信装置１０１は、一時バッファを使用しなくてもデータを受信できる場合には、一時バッファの使用を抑制し、よりネットワークバッファを他の処理に使用しやすくできる。

また通信装置１０１は、受信バッファの空き容量と空き容量以下の第１データ量との差、及び受信バッファの空き容量と空き容量より大きい第２データ量との差の少なくとも何れかに基づいてウィンドウサイズを決定してもよい。第１データ量は例えば受信バッファの空き容量を下に丸めた値であり、第２データ量は例えば受信バッファの空き容量を上に丸めた値である。具体的には、通信装置１０１は、図８のＳ８０２の処理に代えて、受信バッファの空き容量と第１データ量との差が所定値以上であるか否かを判定する。そして、受信バッファの空き容量と第１データ量との差が所定値以上である場合には、Ｓ８０３へ進み、ウィンドウサイズを第１データ量とするか第２データ量とするかを一時バッファの使用可否に基づいて決定する。一方、受信バッファの空き容量と第１データ量との差が所定値未満である場合には、Ｓ８０７へ進み、第１データ量をウィンドウサイズとする。

このような処理によれば、通信装置１０１は、ウィンドウサイズとして第１データ量を通知すると受信バッファの空き容量のうち活用されない部分が大きくなってしまう場合に、第２データ量を通知することで受信バッファを有効に活用できる。一方、第１データ量を通知しても受信バッファのうち活用されない部分が小さい場合には、第１データ量を通知することで一時バッファの使用を抑制し、容量の限られたネットワークバッファを他の処理に使用しやすくできる。また、Ｓ８０２の処理に代えて、受信バッファの空き容量と第２データ量との差が所定値未満であるか否かを判定しても、上記と同様の効果が得られる。なお、図８のＳ８０４の処理では、所定の容量を有する一時バッファとして使用可能な記憶領域がネットワークバッファ内に存在するか否かを判定するが、判定の対象をネットワークバッファ全体でなくネットワークバッファ内の特定の記憶領域に限定してもよい。この場合の通信装置１０１の動作について説明するために、図９を用いて、通信装置１０１の記憶部２０１に展開されるネットワークバッファの内部構造について説明する。ネットワークバッファは、送受信パケットを管理するためのパケット管理構造体９０１、パケットのヘッダ部分を記憶するためのヘッダバッファ構造体９０２、及びパケットのデータ部分を記憶するためのデータバッファ構造体９０３を有する。データバッファ構造体９０３は、パケットのデータ部分を記憶するネットワークバッファ内の領域が所定の分割単位に分割された分割領域である。同様に、ヘッダバッファ構造体９０２は、パケットのヘッダ部分を記憶する領域が分割された分割領域である。パケット管理構造体９０１は、ヘッダバッファ構造体９０２に記憶されているヘッダ部分とデータバッファ構造体９０３に記憶されているデータ部分とを関連付けてパケットとして処理するための構造体である。

なお、本実施形態ではネットワークバッファが３種類の構造体を有する場合について説明を行うが、これに限らない。例えば、ネットワークバッファはパケット管理構造体９０１を有さず、ヘッダ部分とデータ部分の関連付けはパケット管理構造体９０１とは別の仕組みで行われてもよい。また、ネットワークバッファはヘッダバッファ構造体９０２を有さず、データバッファ構造体９０３にパケットのヘッダ部分が記憶されてもよい。

また、受信バッファに割り当てられるデータバッファ構造体９０３の総容量と受信バッファの容量とは一致しなくてもよい。例えば、受信バッファの容量が、予め定められたデータバッファ構造体９０３の容量の２倍より大きく３倍より小さい場合には、３つのデータバッファ構造体９０３が受信バッファに割り当てられる。この場合、３つのデータバッファ構造体９０３のうち少なくとも何れかにおいて、データ容量の一部が受信バッファに対応し、他の部分は受信バッファとして使用されない。また、ある受信バッファに割り当てられたデータバッファ構造体９０３の一部が別の受信バッファとして使用されることはない。

そこで通信装置１０１は、図８のＳ８０４において、データ容量の一部が受信バッファに対応するデータバッファ構造体９０３の、受信バッファに対応しない部分を、一時バッファとして使用できるか否か判定してもよい。すなわち、ネットワークバッファのうち一時バッファとしての使用可否を判定する対象となる記憶領域を、受信バッファのために一部が使用されているデータバッファ構造体９０３に限定してもよい。そして、所定の容量の一時バッファとして使用可能な部分を有するデータバッファ構造体９０３が存在する場合にはＳ８０５へ進み、そうでない場合にはＳ８０７へ進む。すなわち、受信バッファに割り当てられるデータバッファ構造体９０３の空き容量の総和が、受信バッファの空き容量を上に丸めた値以上である場合には、一時バッファが使用可能であると判定される。

このような処理によれば、通信装置１０１は、ネットワークバッファ内の記憶領域のうち他の処理に使用されない記憶領域を、できるだけ一時バッファとして使用する。その結果、通信装置１０１は、ネットワークバッファが他の処理に使用されるのを妨げずに、メモリ資源を有効に活用して多くのデータを受信できる。

なお、図８を用いた上記の説明においては、通信装置１０１が一時バッファの使用可否をウィンドウサイズ通知の度に判定するものとしたが、これに限らない。例えば、通信装置１０１は、図３のＳ３０１におけるコネクションの確立に応じて、そのコネクションを介して通信装置１０２から受信されるデータを記憶するためにスケール単位容量に相当する容量の一時バッファを使用できるか否かを判定してもよい。一時バッファを使用できると判定された場合は、通信装置１０１はネットワークバッファ内の記憶領域のうち一時バッファとして使用する記憶領域を確保し、対象のコネクションにおいて通知するウィンドウサイズは受信バッファの空き容量を上に丸めた値とする。一方、一時バッファを使用できないと判定された場合には、通信装置１０１は対象のコネクションにおいて通知するウィンドウサイズを、受信バッファの空き容量を下に丸めた値とする。

このような処理によれば、通信装置１０１は、一時バッファの使用可否判定と一時バッファの確保をコネクションの確立に応じて一度だけ行えばよく、処理負荷を軽減することができる。

以上説明したように、本実施形態に係る通信装置１０１は、通信装置１０２から受信したデータを記憶するために、所定のデータ容量を有する受信バッファに加えて別の記憶領域を使用できるかを判定する。また通信装置１０１は、通信装置１０２からの送信を許可するデータ量を判定結果に基づいて決定し、決定された許可するデータ量に応じた通知を通信装置１０２に対して行う。そして通信装置１０１は、通知に応じて通信装置１０２から送信されたデータを受信し、受信したデータを受信バッファに記憶し、また、受信したデータのうち容量不足により受信バッファに記憶できないデータを別の記憶領域に記憶する。

これにより通信装置１０１は、記憶可能なデータ量に応じた通信データ量で通信装置１０２と通信できるようになる。例えば通信装置１０１は、受信バッファとは別の記憶領域が使用できる場合には受信バッファの空き容量より多くのデータ量の送信を通信装置１０２に許可し、使用できない場合には受信バッファの空き容量以下のデータ量の送信を許可する。その結果、受信したパケットがバッファに記憶できず破棄されることを抑制しつつ、通信のスループット向上させることができる。

なお、本実施形態では通信装置１０１と通信装置１０２がウィンドウスケールオプションを使用した通信を行う場合を中心に説明したが、ウィンドウスケールオプションを使用しない通信を行う場合にも本発明を適用できる。すなわち通信装置１０１は、スケールファクタに関わらず、一時バッファが使用できる場合には受信バッファの空き容量よりも大きい値をウィンドウサイズとして通知し、使用できない場合には空き容量以下の値をウィンドウサイズとして通知してもよい。

また、本実施形態では通信装置１０１と通信装置１０２とがＴＣＰ／ＩＰに従って通信を行う場合を中心に説明したが、使用するプロトコルはこれに限らない。例えば、通信装置１０１と通信装置１０２はＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）に従った通信を行ってもよい。そして、ＨＴＴＰなどＴＣＰよりも上位の層のプロトコルにおいて作成されたメッセージによって、本実施形態で説明した通信データ量の制御などの機能を実現してもよい。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ等）によっても実現可能である。また、そのプログラムをコンピュータにより読み取り可能な記録媒体に記録して提供してもよい。

１０通信システム
１０１通信装置
１０２通信装置
１１０ネットワーク

Claims

通信装置であって、
前記通信装置と他の通信装置との間の論理的な通信路が確立される際に予約される容量の受信バッファに、前記他の通信装置から受信したデータを記憶させる第１記憶手段と、
前記他の通信装置から受信したデータのうち前記受信バッファに記憶されないデータを、前記受信バッファとは別の記憶領域に記憶させる第２記憶手段と、
前記他の通信装置から受信したデータを前記第２記憶手段が前記記憶領域に記憶させることができるかを判定する判定手段と、
前記他の通信装置からの送信を許可するデータ量を前記判定手段による判定結果に基づいて決定する決定手段と、
前記他の通信装置に対して、前記決定手段により決定された前記許可するデータ量に応じた通知を行う通知手段と、
前記通知手段による通知に応じて前記他の通信装置から送信されるデータを受信する受信手段とを有することを特徴とする通信装置。
前記受信バッファは、前記通信路が確立される際に前記通信路と対応づけて予約された領域であり、
前記記憶領域は、特定の通信路に対応付けされていない領域であることを特徴とする請求項１に記載の通信装置。
前記決定手段は、前記許可するデータ量を前記受信バッファの空き容量以下の第１データ量とするか、前記受信バッファの空き容量より大きい第２データ量とするかを決定することを特徴とする請求項１又は２に記載の通信装置。
前記判定手段は、前記他の通信装置から受信したデータを前記第２記憶手段が記憶させるための前記記憶領域として、前記許可するデータ量の候補である前記第２データ量から前記受信バッファの空き容量を差し引いたデータ量に相当する容量の記憶領域を使用できるかを判定することを特徴とする請求項３に記載の通信装置。
前記決定手段は、前記差し引いたデータ量に相当する容量の前記記憶領域を使用できないと前記判定手段により判定された場合には、前記許可するデータ量を前記第１データ量とし、前記差し引いたデータ量に相当する容量の前記記憶領域を使用できると前記判定手段により判定された場合には、前記許可するデータ量を前記第２データ量とすることを特徴とする請求項４に記載の通信装置。
前記決定手段は、前記受信バッファの空き容量が閾値よりも大きい場合には、前記許可するデータ量を前記判定手段による判定結果に基づいて決定し、前記受信バッファの空き容量が前記閾値よりも小さい場合には、前記許可するデータ量を前記第１データ量とすることを特徴とする請求項３又は４に記載の通信装置。
前記閾値は、前記通信装置と前記他の通信装置との間の通信路におけるＭＴＵ（ＭａｘｉｍｕｍＴｒａｎｓｍｉｓｓｉｏｎＵｎｉｔ）であることを特徴とする請求項６に記載の通信装置。
前記決定手段は、前記受信バッファの空き容量が前記ＭＴＵよりも大きく、且つ、ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）のウィンドウスケールオプションのスケールファクタにより定まるスケール単位容量が前記ＭＴＵよりも小さい場合には、前記許可するデータ量を前記第１データ量とすることを特徴とする請求項７に記載の通信装置。
前記決定手段は、前記受信バッファの空き容量が閾値よりも小さい場合には、前記許可するデータ量を前記判定手段による判定結果に基づいて決定し、前記受信バッファの空き容量が前記閾値よりも大きい場合には、前記許可するデータ量を前記第１データ量とすることを特徴とする請求項３又は４に記載の通信装置。
前記閾値は、ＴＣＰのウィンドウスケールオプションのスケールファクタにより定まるスケール単位容量であることを特徴とする請求項９に記載の通信装置。
前記決定手段は、前記受信バッファの空き容量と前記第１データ量との差、及び前記受信バッファの空き容量と前記第２データ量との差の少なくとも何れかに基づいて、前記許可するデータ量を前記第１データ量とするか前記第２データ量とするかを決定することを特徴とする請求項３又は４に記載の通信装置。
前記判定手段は、前記通信装置がデータを記憶する領域が所定の分割単位に分割された複数の分割領域のうち、データ容量の一部が前記受信バッファに対応する分割領域の、前記受信バッファに対応しない部分を、前記他の通信装置から受信したデータを前記第２記憶手段が記憶させるための前記記憶領域として使用できるかを判定することを特徴とする請求項１乃至１１の何れか１項に記載の通信装置。
前記判定手段は、前記他の通信装置から受信されるデータを前記第２記憶手段が記憶するための前記記憶領域として、ＴＣＰのウィンドウスケールオプションのスケールファクタにより定まるスケール単位容量に相当する容量の記憶領域を使用できるかを、前記通信路の確立に応じて判定することを特徴とする請求項１乃至３の何れか１項に記載の通信装置。
前記受信バッファは、前記通信装置と前記他の通信装置との間の論理的な通信路としてのＴＣＰにおけるコネクションに対応する受信バッファであり、
前記送信を許可するデータ量は、ＴＣＰで規定されたウィンドウサイズが示すデータ量であることを特徴とする請求項１乃至１３の何れか１項に記載の通信装置。
前記通知手段、ＴＣＰのウィンドウスケールオプションのスケールファクタに従うウィンドウサイズに関する情報を通知し、
前記第１データ量は、前記スケールファクタにより定まるスケール単位容量の整数倍のデータ量であり且つ前記受信バッファの空き容量を超えないデータ量であり、
前記第２データ量は、前記スケール単位容量の整数倍のデータ量であり且つ前記受信バッファの空き容量より大きいデータ量あることを特徴とする請求項３乃至１１の何れか１項に記載の通信装置。
通信装置が他の通信装置から受信したデータを、前記通信装置と前記他の通信装置との間の論理的な通信路が確立される際に予約される容量の受信バッファとは別の記憶領域に記憶させることができるかを判定する判定工程と、
前記他の通信装置からの送信を許可するデータ量を前記判定工程における判定結果に基づいて決定する決定工程と、
前記他の通信装置に対して、前記決定工程において決定された前記許可するデータ量に応じた通知を行う通知工程と、
前記通知工程における通知に応じて前記他の通信装置から送信されるデータを前記通信装置が受信する受信工程と、
前記受信工程において受信されたデータを前記受信バッファに記憶させる第１記憶工程と、
前記受信工程において受信されたデータのうち前記受信バッファに記憶されないデータを、前記記憶領域に記憶させる第２記憶工程とを有することを特徴とする通信方法。
前記受信バッファは、前記通信路が確立される際に前記通信路と対応づけて予約された領域であり、
前記記憶領域は、特定の通信路に対応付けされていない領域であることを特徴とする請求項１６に記載の通信方法。
前記決定工程は、前記許可するデータ量を前記受信バッファの空き容量以下の第１データ量とするか、前記受信バッファの空き容量より大きい第２データ量とするかを決定することを特徴とする請求項１６又は１７に記載の通信方法。
コンピュータを、請求項１乃至１５の何れか１項に記載の通信装置の各手段として動作させるためのプログラム。