JP2024052829A - 通信装置、通信方法及びプログラム - Google Patents

Abstract

【課題】データの受信又は送信時の処理の負荷を軽減する通信装置、通信方法及びプログラムを提供する。【解決手段】本実施形態に係る通信装置は、アプリケーション用のデータを送信するための接続要求を送信装置から受信し、前記接続要求を受信した後、前記データを受信する、受信部と、複数の前記データが受信されるまで、前記接続要求の受信を前記アプリケーションに通知することを待機する処理部とを備える。【選択図】図１

Description

本発明の実施形態は、通信装置、通信方法及びプログラムに関する。

パケット交換方式の通信では、一連のデータをパケット（データグラム又はセグメントなどとも称される）に分割して、送信装置から受信装置に配送する。送信装置ではデータ列からパケットへの変換の処理、及び受信装置ではパケットからデータ列への復元の処理が行われる。これらの処理は、通常、データをホストコンピュータのメモリ上で分割しながらコピーすることで行われる。このコピーによる負荷を下げるために、様々な技術が開発されてきた。

送信時のコピーを最小限にするための技術として、TCP Segmentation Offload (TSO) 、TSOを抽象化したGeneric Segmentation Offload (GSO) 又は Large Send Offload (LSO) がある。これらの技術では、周辺機器であるネットワークインターフェイスカード (NIC: Network Interface Card) にパケットよりも大きなデータを転送し、NICがパケット化及びヘッダの付与を行う。これにより、ホストコンピュータではデータの分割・コピーを省略でき、負荷を大幅に削減できる。このような技術はゼロコピーとも呼ばれる。

ゼロコピーを受信装置で実現する Large Receive Offload (LRO) と呼ばれる技術もある。LROでは、NICが受信したパケットからデータ列を復元し、ホストコンピュータに転送する。これにより、ホストコンピュータでの復元に伴うメモリコピーを省略する。

このようにホストコンピュータでのメモリコピーを省略するゼロコピー技術が開発されてきたものの、多量のセッションに対する負荷をオフロードする仕組みはなかった。例えば、受信装置においてはNICでオフロード可能なセッション数（コンテキスト数）に制限があるため、多量のセッションを扱えなかった。

また、セッションの管理については、通常、受信装置のオペレーティングシステムが行う。オペレーティングシステムでセッションを開始すると、ユーザプログラムによりファイルディスクリプタ（ソケット）を作成し、受信待ち受けするなどの、受信処理を行う。この受信処理のために、プロセス又はスレッドを作成する場合もある。また、受信待ち受けのために多量のファイルディスクリプタ、プロセス又はスレッドを作成することで、性能が著しく低下することもある。このため、規模拡張性（スケーラビリティ）が乏しかった。

Willem de Bruijn and Eric Dumazet , "Optimizing UDP for content delivery: GSO, pacing and zerocopy", [Online], ［令和2年6月10日検索］, インターネット＜ＵＲＬ：http://vger.kernel.org/lpc_net2018_talks/willemdebruijn-lpc2018-udpgso-paper-DRAFT-1.pdf＞ Aravind Menon and Willy Zwaenepoel, "Optimizing TCP Receive Performance", [Online], School of Computer and Communication Sciences［令和2年6月10日検索］, インターネット＜ＵＲＬ：https://www.usenix.org/legacy/event/usenix08/tech/full_papers/menon/menon_html/

本発明の実施形態は、データの受信又は送信時の処理の負荷を軽減する通信装置、通信方法及びプログラムを提供する。

本実施形態に係る通信装置は、アプリケーション用のデータを送信するための接続要求を送信装置から受信し、前記接続要求を受信した後、前記データを受信する、受信部と、複数の前記データが受信されるまで、前記接続要求の受信を前記アプリケーションに通知することを待機する処理部とを備える。

本実施形態に係る通信方法は、アプリケーション用のデータを送信するための接続要求を送信装置から受信し、前記接続要求を受信した後、前記データを受信し、複数の前記データが受信されるまで、前記接続要求の受信を前記アプリケーションに通知することを待機する。

本実施形態に係るプログラムは、アプリケーション用のデータを送信するための接続要求を送信装置から受信するステップと、前記接続要求を受信した後、前記データを受信するステップと、複数の前記データが受信されるまで、前記接続要求の受信を前記アプリケーションに通知することを待機するステップと、をコンピュータに実行させる。

第１実施形態に係るデータ送信システムのブロック図。 第１実施形態に係る受信装置のブロック図。 送信装置から受信装置がデータを受信する場合の動作シーケンス例を示す図。 送信装置から受信装置がデータを受信する場合の他の動作シーケンス例を示す図。 第１実施形態に係る受信装置の動作の一例を示すフローチャート。 受信処理部が受信装置の外部装置として存在する場合の概略構成を示す図。 第２実施形態に係るパケットのフォーマット例を示す図。 第３実施形態に係る送信装置のブロック図。 送信装置が受信装置にデータを送信する動作シーケンスの例を示す図。 第３実施形態に係る送信装置の動作の一例を示すフローチャート。 送信処理部が送信装置の外部装置として存在する場合の概略構成を示す図。 送信装置又は受信装置のハードウェア構成の一例を示すブロック図。

以下、図面を参照して、本開示の実施形態について説明する。図面は、本開示の実施形態を一例として模式的に示すものであり、本開示の実施形態は、図面に開示された形態に限定されるものではない。

（第１実施形態）
図１は、本実施形態に係るデータ送信システムのブロック図である。図１のデータ送信システムは、受信装置１０と、送信装置２０を搭載した複数の移動体Ｍとを備える。受信装置１０及び送信装置２０は、本実施形態に係る通信装置又無線通信装置の一例に相当する。

移動体Ｍは、自動車、ロボット、船舶、ドローン、モバイル端末（スマートフォン、タブレット端末等）、又は電車など、任意の移動体である。本実施形態では送信装置２０は移動体に搭載されているが、送信装置２０は固定設置された端末又はマシンに搭載されてもよい。本実施形態では移動体Ｍが自動車である場合を想定する。自動車は、ユーザの運転を支援する機能を有する自動車、及び自律的に判断して走行する自動運転車のいずれでもよい。

送信装置２０は、通信ネットワーク３０に接続されている。通信ネットワーク３０は、一例として、モバイルネットワーク又は無線ＬＡＮ（Local Area Network）等のネットワークである。モバイルネットワークの例として、３Ｇネットワーク，ＬＴＥネットワーク、次世代（５Ｇ）ネットワークなどがあるが、ネットワークの種類は何でもよい。また、通信ネットワーク３０は、無線ネットワークでも、有線ネットワークでもよい。通信ネットワーク３０は、複数種類のネットワークを含んでいてもよい。この場合、送信装置２０が、受信装置１０との通信に用いるネットワークを複数種類のネットワークから選択してもよい。本実施形態では送信装置２０は無線通信を行うが、有線通信を行う構成でもよい。

送信装置２０は、移動体Ｍに設けられた１つ又は複数のセンサからデータを取得する。１つ又は複数のセンサは、受信装置における１つ又は複数のアプリケーションに提供するデータを検出する。送信装置２０は、１つ又は複数のアプリケーション毎にデータを受信装置１０に送信する。より詳細には、送信装置２０は、データを含むパケットを生成し、生成したパケットを受信装置１０に送信する。複数のセンサの例は、カメラ、ＧＰＳ、ＬｉＤＡＲ（Light Detecting And Ranging）、速度センサ、加速度センサ、自動車の制御データ（エンジン回転状態、アクセルの踏み込み状態など）の検出センサ、急ブレーキの検出センサ、障害物（落下物、前方車両）の検出センサなどを含む。

受信装置１０は、通信ネットワーク３０に接続されている。受信装置１０は例えばモバイルネットワークに配置されている。受信装置１０は、モバイルネットワークのエッジコントローラでもよい。受信装置１０は、移動体Ｍから１つ又は複数のアプリケーションに対するデータを受信する。より詳細には、受信装置１０は、データを含むパケットを受信する。受信装置１０は、移動体Ｍから送信されたデータを処理する１つ又は複数のアプリケーションを備えていている。受信装置１０は移動体Ｍから取得したデータを、それぞれ対応するアプリケーションに渡す。

複数のアプリケーションの例は、高精細度地図を生成するアプリケーション、エンジン制御の最適化モデルを生成するアプリケーション、道路安全情報を生成するアプリケーションなどを含む。一例として、高精細度地図を生成するアプリケーション、及びエンジン制御の最適化モデルを生成するアプリケーションに対するデータ送信の時間制約は長い（１分、１時間、１日など）。一方、道路安全情報を生成するアプリケーションに対するデータ送信の時間制約は短い（例えば１０秒以下）。このような送信の時間制約の情報は、送信装置２０と受信装置１０間で共有されていてもよい。一例として時間制約の短いデータは優先度の高いデータに対応し、時間制約の長いデータは優先度の低いデータに対応する。

受信装置１０が中継装置として機能する場合、中継装置としての受信装置１０が、移動体Ｍの送信装置２０から受信したデータを、１つ又は複数のアプリケーションを備える別の装置（例えばサーバ）に送信してもよい。

移動体Ｍの送信装置２０及び受信装置１０は、基地局を介して、互いに通信してもよい。この場合、送信装置２０は、所定の接続プロセスを実行することにより、近傍の基地局と無線接続する。移動体Ｍの送信装置２０は、接続した基地局を介して、受信装置１０と通信する。受信装置１０は、基地局と無線又は有線で接続されている。受信装置１０は、複数の基地局と接続されていてもよいし、基地局と１対１で接続されていてもよい。送信装置２０及び受信装置１０間の伝送路には、基地局を含む１つ以上の中継装置が存在してもよい。

本実施形態では、受信装置１０が、１台又は複数台の送信装置２０からデータを受信する場合に、受信装置１０におけるアプリケーションの処理の負荷を軽減することを実現する。

図２は、本実施形態に係る受信装置１０のブロック図である。受信装置１０は送信装置２０と通信する。図２では送信装置２０が１台のみ示されているが、複数の送信装置２０が存在してよい。また受信装置１０の台数も１台に限定されない。図２に示す受信装置１０の構成は、本実施形態の説明に必要な要素のみを示したものであり、ユーザが指示又はデータを入力する入力部、ユーザに情報を提示する出力部など、他にも様々な要素が含まれてもよい。図２に示す受信装置１０は送信装置２０と無線通信を行うが、有線通信を行う構成も排除されない。

受信装置１０は、受信処理部１１０と、処理部１２０と、オフロード判定部１３０（決定部）と、一時記憶部１４０と、通信部１５０（受信部）と、少なくとも１つのアンテナ１６０とを備える。

受信処理部１１０は、１つ又は複数のアプリケーションを実行することにより、送信装置２０から送信されるデータを取得し、取得したデータに基づく処理を行うアプリケーション実行部である。アプリケーションの例として、高精細度地図の生成、エンジン制御の最適化モデルの生成、道路安全情報の生成などがあるが、これらは一例に過ぎず、他にも様々なアプリケーションがある。受信処理部１１０はＣＰＵ及びメモリを備えていてもよい。

受信処理部１１０のアプリケーションは、送信装置２０から例えばTCP（Transmission Control Protocol）の接続要求が受信されたとの通知を処理部１２０から待ち受ける動作を行う。アプリケーションは、処理部１２０を介して送信装置２０からの接続要求の受信を通知されると、送信装置２０からのデータを待ち受ける動作を開始する。アプリケーションは、アプリケーションに代わって送信装置２０からデータを受信（代理受信）する処理部１２０に対してデータの読み出し命令を発行し、処理部１２０からデータを取得する動作を行う。読み出し命令には、読み出すデータのサイズを指定する引数が含まれてもよい。あるいは、読み出し命令は一定サイズのデータを読み出すよう構成されていてもよい。

具体例として、アプリケーションは、socket()システムコールを用いて、ソケットを識別するファイルディスクリプタを生成する。アプリケーションは、bind()システムコールを用いて、ソケットに受信用に待機するポート番号（例えばTCPのポート番号）等を割り当てる。アプリケーションは、listen()システムコール等を用いて、送信装置２０からの接続要求を待つ準備を行う。アプリケーションは、accept()システムコール等を用いて接続要求を待つ動作を開始する。アプリケーションは、処理部１２０からaccept()システムコールからの正常応答を受信すると、送信装置２０からのデータを待機する。accept()システムコールからの正常応答は、送信装置２０から接続要求が受信されたことを通知する情報に対応する。送信装置２０から送信されたデータは処理部１２０で代理受信され、アプリケーションは、例えばreceive()システムコールを用いて、処理部１２０から、送信装置２０から受信されたデータを取得する処理を行う。receive()の引数で読み出すデータのサイズを指定してもよい。receive()システムコールを繰り返すことで、処理部１２０からデータを逐次取得する。アプリケーションは、処理部１２０からのデータの取得を終了した場合（例えば、送信装置２０から受信された全てのデータを取得した場合）、ソケットを切断する。

通信部１５０は、アンテナ１６０を介して無線信号を送受信することにより、送信装置２０と通信する。通信部１５０は、通信ネットワーク３０を介して、送信装置２０から通信の接続要求を受信すると、接続要求を処理部１２０に提供する。通信部１５０は、処理部１２０から接続要求に対する確認応答を取得すると、確認応答を送信装置２０に送信する。通信部１５０は、確認応答を送信した後、送信装置２０から送信されるデータ列を受信する。より詳細には、通信部１５０は、データを含むパケットを順次受信する。通信部１５０はパケットを処理部１２０に提供する。

通信部１５０は、送信装置２０からアプリケーション用のデータを送信するための接続要求を受信し、接続要求が受信された後、送信装置２０から送信されるデータを受信する受信部を含む。受信部において、接続要求を受信するハードウェア回路とデータを受信するハードウェアは同じでもよいし、接続要求を受信するハードウェア回路とデータを受信するハードウェアが異なってもよい。

処理部１２０は、送信装置２０と受信処理部１１０との間でデータの送受信に関する処理を行う。処理部１２０は、送信装置２０から接続要求を受信した後、アプリケーション宛のデータを代理受信して、アプリケーションへの通知を一時待機するオフロード処理を行う機能を有する。処理部１２０は一例としてＩＰ／ＴＣＰに関する処理を行う。データリンク層及び物理層に関する処理をさらに通信部１５０が行ってもよい。データリンク層及び物理層に関する処理を通信部１５０が行ってもよい。処理部１２０は一例として専用のハードウェア回路によって構成されてもよいし、プログラムによって構成されてもよいし、又はこれらの両方によって構成されてもよい。

処理部１２０は、一例としてカーネル又はオペレーティングシステム（ＯＳ）によって構成される。処理部１２０は、インターネット層及びトランスポート層の通信プロトコルとして、例えば、ＩＰ（Internet Protocol）／ＴＣＰ（Transmission Control Protocol）、を用いる。本実施形態ではＩＰ／ＴＣＰを用いる場合を想定する。但し、ＩＰ／ＵＤＰ（User Datagram Protocol）等、他の通信プロトコルを用いる場合も排除されない。

処理部１２０は、送信装置２０から接続要求を受信すると、接続要求先が、接続要求を待つ動作を行っているアプリケーション（例えばaccept()システムコールを行ったアプリケーション）であるか否かを判断する。接続要求先が当該アプリケーションでない場合は、接続の拒否通知を送信装置２０に送信する。処理部１２０は、接続要求先が当該アプリケーションである場合は、送信装置２０が送信するデータ列又は送信先のアプリケーションがオフロード対象か否か（すなわちオフロード処理を行うか否か）の判定をオフロード判定部１３０に要求する。オフロード対象か否かによって、送信装置２０から受信した接続要求の通知をアプリケーションに提供するタイミングを制御する。オフロード判定部１３０は、データ又はアプリケーションに関する情報に基づき、接続要求の受信をアプリケーションに通知するタイミングを決定する決定部を含む。

データ又はアプリケーションに関する情報の一例として、オフロード処理の有無を指定する指示情報（オフロード対象フラグ）がある。オフロード対象フラグが例えば送信装置２０側でパケットのヘッダに含められる。処理部１２０が受信したパケットのヘッダからオフロード対象フラグを検出する。オフロード対象フラグが第１値（例えば“１”）である場合は、オフロード処理を行うと判定し、第２値（例えば“０”）である場合は、オフロード処理を行わないと判定してもよい。オフロード対象フラグをアプリケーションから取得してもよい。

データ又はアプリケーションに関する情報はデータ又はアプリケーションの優先度でもよい。一例として、データ列が画像・音声等のストリーミングデータなど、遅延許容時間が長いデータの場合、低い優先度（例えば緊急度が低い）を設定する。非ストリーミングデータなど、遅延許容時間が短いデータの場合、高い優先度（例えば緊急度が高い）を設定する。オフロード判定部１３は、高い優先度の場合は、オフロード処理を行わないと判定し、低い優先度の場合は、オフロード処理を行うと判定してもよい。一例として、優先度が閾値以上のときは優先度が高いと判断し、オフロード処理を行わないと判定してもよい。また、優先度が閾値未満のときは優先度が低いと判断し、オフロード処理を行うと判定してもよい。優先度はパケットのヘッダに含められてもよいし、アプリケーションから取得してもよい。

また、データ又はアプリケーションに関する情報は、データを検出したセンサの種類でもよい。例えばストリーミングデータを生成するカメラの場合はオフロード処理を行うと判定し、急ブレーキを検出するセンサの場合は、オフロード処理を行わないと判定する。センサの種類はパケットのヘッダに含められてもよいし、アプリケーションから取得してもよい。

また、データ又はアプリケーションに関する情報は、データの送信先のアプリケーションの種類でもよい。例えば、アプリケーションごとに使用するポート番号が決まっている場合に、ヘッダからアプリケーションが使用するポート番号を取得し、アプリケーションの種類を識別してもよい。

データ又はアプリケーションに関する情報（オフロード対象フラグ、優先度、センサの種類、ポート番号等）をパケットのヘッダに含める場合、例えば接続要求のパケットのヘッダに当該情報を含めてもよい。既存のプロトコルのヘッダ（ＩＰ、ＴＣＰ等のヘッダ）の予約フィールドを用いてもよいし、独自に定義したプロトコルのヘッダを用いてもよい。

また、データ又はアプリケーションに関する情報を、アプリケーションから取得する場合に、アプリケーションが実行する関数に引数として当該情報を含めてもよい。例えば、socket()に引数として、最後のデータを受信してから通知（例えばaccept() return）を返すことを指示する“TAILAWARE”を追加してもよい。socket()に“TAILAWARE”が含まれている場合は、オフロード処理を行うことを決定する。“TAILAWARE”はオフロード処理の有無を指定する指示情報の一例に相当する。

オフロード判定部１３０はオフロード処理を行うか否か（送信装置２０から受信するデータ列がオフロード対象か否か）の判定結果を処理部１２０に提供する。

オフロード処理を行わないとの判定結果は、接続要求の受信を通常のタイミング（第１タイミング）でアプリケーションに通知することを意味する。通常のタイミング（第１タイミング）は、例えば接続要求を受信したタイミング、接続要求を受信した後かつ確認応答を返す前のタイミング、又は、確認応答を返した後かつデータの受信を開始する前のタイミングなどがある。オフロード処理を行うとの判定結果は、データが受信された後のタイミング（第２タイミング）で通知をアプリケーションに提供することを意味する。第２タイミングは、アプリケーションに接続要求を通知する条件（接続通知条件）が満たされたタイミングである。

処理部１２０は、オフロード処理を行わないと判定された場合は、送信装置２０からの接続要求の受信を通常のタイミングでアプリケーションに通知する。通知を提供する具体例は、accept()システムコールの正常応答をアプリケーションに返すことを含む。

処理部１２０は、オフロード処理を行うと判定された場合は、接続通知条件が満たされたタイミング（第２タイミング）で、接続要求の受信をアプリケーションに通知する。一例として、データの受信状況に基づいて接続通知条件が満たされるかを判断する。接続通知条件が満たされない場合は、送信装置２０からの接続要求の受信をアプリケーションに通知しない。接続通知条件が満たされた場合に、接続要求の受信をアプリケーションに通知する。接続通知条件が満たされる例として、データの受信が終了した場合（例えば送信装置２０から送信される複数のデータの全てを受信した場合）、又は送信装置２０から接続の終了要求を受信した場合などがある。接続通知条件の詳細については後述する。

処理部１２０は、オフロード判定部１３０でオフロード処理を行わないと判定された場合及びオフロード処理を行うと判定された場合のいずれも、接続要求に対する確認応答を生成する。処理部１２０は、通信部１５０を介して、確認応答を送信装置２０に送信する。

処理部１２０は、確認応答の送信後、通信部１５０を介して、送信装置２０から送信されるデータを順次受信する。処理部１２０は、送信装置２０から受信されるデータを一時記憶部１４０に格納していく。

一時記憶部１４０は、所定サイズの記憶領域を有する記憶部又は記憶装置である。一時記憶部１４０は、一例として、メモリ又はハードディスクなどの記録媒体により構成される。メモリは、揮発性メモリ、不揮発性メモリ、又はこれらの両方を含む。

処理部１２０は、送信装置２０からのデータ受信の開始後、送信装置２０から接続の終了要求を受信した場合は、送信装置２０からのデータ受信を終了する。終了要求は、一例として、データの送信の終了を通知する情報に相当する。終了要求を受信する以外の方法でデータ受信の終了を決定してもよい。例えば予め定めた量のデータを受信した場合、又は予め定めた個数のデータを受信した場合に、データ受信の終了を決定してもよい。

処理部１２０は、上述のオフロード処理を行わないと判定された場合は、アプリケーションに通常のタイミングで接続要求の受信を通知した後、アプリケーションからデータの読み出し命令を受信する。処理部１２０は、読み出し命令を受信するごとに、一時記憶部１４０からデータを読み出し、読み出したデータをアプリケーションに出力（提供）する。アプリケーションは、送信装置２０から受信されたデータの取得を完了すると、ソケットを切断する。

処理部１２０がアプリケーションに出力するデータは、一例としてＴＣＰより上位のレイヤのデータ（ＴＣＰのペイロード部分）である。但し、ＴＣＰ及びＩＰの少なくとも一方のヘッダ情報もアプリケーションに出力してもよい。また、ＴＣＰの上位に独自に定義したプロトコルのヘッダが付加されている場合に、当該独自のプロトコルより上位のレイヤのヘッダ及びペイロード部をアプリケーションに出力してもよい。

処理部１２０は、オフロード処理を行うと判定された場合は、送信装置２０から受信するデータを一時記憶部１４０に格納していくことと並行して、送信装置２０から受信されるデータに基づき、接続通知条件が満たされたかを判断する。

一例として、処理部１２０は、送信装置２０からデータ列の受信が終了した場合（例えば全てのデータが受信された場合）、接続通知条件が満たされたと判断する。具体的には、送信装置２０から接続の終了要求を受信した場合に、接続通知条件が満たされたと判断する。

あるいは予め定めたデータ量のデータが受信された場合に、接続通知条件が満たされたと判断してもよい。また、送信装置２０から受信するデータ量のうち受信済みのデータ量の割合に基づいて、接続通知条件が満たされたと判断してもよい。

また、送信装置２０側でデータに対してオフロード処理の終了を指示する情報（オフロード終了フラグ）を設定し、オフロード終了フラグに基づき判断してもよい。例えば、送信装置２０においてパケットのヘッダにオフロード終了フラグを含める。オフロード終了フラグがオフ（例えば“０”）である間は、接続通知条件は満たされていないと判断する。オフロード終了フラグがオン（例えば“１”）になった場合は、接続通知条件が満たされたと判断する。

上述の接続通知条件は、一例であり、その他の方法で接続通知条件を定義してもよい。

処理部１２０は、接続通知条件が満たされた場合、送信装置２０からの接続要求の受信をアプリケーションに通知する。例えばaccept()システムコールの正常応答をアプリケーションに返す。処理部１２０は、接続要求の受信をアプリケーションに通知した後、アプリケーションからデータの読み出し命令を順次受信する。処理部１２０は、読み出し命令を受信するごとに、一時記憶部１４０から読み出し命令で指定されたサイズのデータを読み出し、読み出したデータをアプリケーションに出力（提供）する。送信装置２０から受信したすべてのデータをアプリケーションに提供したら、アプリケーションはソケットを切断する。

アプリケーションは、上述のaccept()システムコールを行う際、引数として、遅延許容値を設定してもよい。この場合、アプリケーションは、遅延許容値が示す期間が経過するまでは、accept()システムコールの正常応答を待機する。遅延許容値を、他の関数を用いて設定してもよい。例えばソケットと関連したオプションを 設定するsetsockopt() 関数を用いてもよい。

処理部１２０がアプリケーションに出力するデータは、オフロード処理を行わないと判定された場合にアプリケーションに出力するデータと同様である。

図３は、オフロード処理を行わない場合の送信装置２０の動作シーケンスの例を示す。受信処理部１１０のアプリケーションは、送信装置２０から接続要求を待ち受けるため、accept()システムコールを実行する（Ｓ１１）。処理部１２０は、送信装置２０から接続要求を受信すると（Ｓ１２）、送信装置２０からこれから受信するデータ列に対してオフロード処理を行うか否かの判定をオフロード判定部１３０に要求する。オフロード判定部１３０によりオフロード処理を行わないと判断された場合に、accept()システムコールの正常応答をアプリケーションに即時に返すことにより、接続要求の受信をアプリケーションに通知する（Ｓ１３）。アプリケーションは送信装置２０からのデータを待機する動作を開始する。処理部１２０は、通信部１５０を介して、接続要求に対する確認応答を送信装置２０に送信する（Ｓ１４）。

処理部１２０は、通信部１５０を介して、送信装置２０から送信されるデータを順次受信する（Ｓ１５－１、Ｓ１５－２、Ｓ１５－３、・・・）。処理部１２０は、各データに対する確認応答を送信装置２０に送信する。処理部１２０は、送信装置２０から受信されるデータを一時記憶部１４０に順番に格納する。送信装置２０から全てのデータを受信した後、送信装置２０から接続の終了要求（データの送信の終了通知）を受信する（Ｓ１８）。

処理部１２０は、シーケンスＳ１５－１、Ｓ１５－２、Ｓ１５－３、・・・と並行して、アプリケーションからデータの読み出し命令を受ける（Ｓ１６－１、Ｓ１６－２、・・・、Ｓ１６－Ｎ）。処理部１２０は、一時記憶部１４０から、読み出し命令で指定されたサイズのデータを読み出して、読み出したデータをアプリケーションに出力（提供）する（Ｓ１７－１、Ｓ１７－２、・・・）。送信装置２０から受信したすべてのデータがアプリケーションに提供すると、処理部１２０は読み出し終了をアプリケーションに通知する（Ｓ１９）。読み出し終了の通知を受けたアプリケーションは、ソケットを切断する。

図４は、オフロード処理を行う場合の送信装置２０の動作シーケンスの例を示す。ここでは送信装置２０から全てのデータを受信した場合に、接続要求の受信をアプリケーションに通知する（接続通知条件が満たされる）場合の動作を記載する。

受信処理部１１０のアプリケーションは、送信装置２０から接続要求を待ち受けるため、accept()システムコールを実行する（Ｓ１０１）。処理部１２０は、送信装置２０から接続要求を受信すると（Ｓ１０２）、送信装置２０からこれから受信するデータ列に対してオフロード処理を行うか否かの判定をオフロード判定部１３０に要求する。オフロード判定部１３０によりオフロード処理を行うと判断された場合、処理部１２０は、この時点ではaccept()システムコールの正常応答をアプリケーションに返さない。処理部１２０は、通信部１５０を介して、接続要求に対する確認応答を送信装置２０に送信する（Ｓ１０３）。

処理部１２０は、通信部１５０を介して、送信装置２０から送信されるデータを順次受信する（Ｓ１０４－１、Ｓ１０４－２、Ｓ１０４－３、・・・）。処理部１２０は各データに対する確認応答を送信装置２０に送信する。処理部１２０は、送信装置２０から受信されるデータを一時記憶部１４０に順番に格納する。送信装置２０から全てのデータを受信した後、送信装置２０から接続の終了要求を受信する（Ｓ１０５）。

処理部１２０は、接続の終了要求を受信すると、accept()システムコールの正常応答をアプリケーションに返す（Ｓ１０６）。これにより、送信装置２０からの接続要求の受信をアプリケーションに通知する。接続要求の受信を通知されたアプリケーションは送信装置２０からのデータを待機する動作を開始する。処理部１２０は、アプリケーションからデータの読み出し命令を受けると（Ｓ１０７－１、Ｓ１０７－２、・・・、Ｓ１０７－Ｎ）。一時記憶部１４０から、読み出し命令で指定されたサイズのデータを読み出して、読み出したデータをアプリケーションに出力（提供）する（Ｓ１０８－１、Ｓ１０８－２、・・・）。送信装置２０から受信したすべてのデータをアプリケーションに提供すると、処理部１２０は読み出し終了を送信装置２０に通知する（Ｓ１０９）。読み出し終了の通知を受けたアプリケーションはソケットを切断する。

前述した図３及び図４のシーケンスにおいて、処理部１２０は、送信装置２０から受信したパケットのシーケンス番号に基づき、パケットの欠落を検出してもよい。パケットの欠落を検出した場合は、再送を待機する（送信装置２０はＡＣＫを受信しない場合は、最大回数までパケットの再送を行う）。処理部１２０は、すべてのパケットが受信できたことを確認できた後に、accept()システムコールの正常応答をアプリケーションに返してもよい。あるいは、処理部１２０は、パケットのロスを検出した時点又はその他の任意に定めた時点から一定時間内に受信できないパケットが存在する場合は、タイムアウトとして当該パケットをもはや待機しなくてもよい。この場合、処理部１２０は受信済みのパケットのデータのみをアプリケーションに提供する。

図３のシーケンスと図４のシーケンスの効果の違いを説明する。図３のシーケンスでは、接続要求が受信されたタイミングで、アプリケーションはデータの待ち動作を開始するため、送信装置２０から受信したデータをより早期にアプリケーションに渡すことができる。したがって緊急性の高いデータを高速にアプリケーションに届けることができる。一方、アプリケーションがすべてのデータが送信装置２０から届くまでデータの待ち動作を行っている必要があるため、アプリケーションの負荷（アプリケーションを実行するＣＰＵの負荷）が大きくなる。特に多くの送信装置からのデータを受信する場合、多量のファイルディスクリプタが生成されることで、性能が低下する可能性もある。受信処理でプロセス又はスレッドが生成される場合も、プロセス又はスレッドが多量に生成され、性能が低下する可能性がある。また通信ネットワーク３０の通信品質の低下によりパケットの到着が遅れたり、再送が発生したりする場合もあり、アプリケーションの待機時間が長くなる可能性がある。一方、図４のシーケンスでは、全てのデータが受信されるまで（接続通知条件が満たされるまで）アプリケーションはデータの待ち動作を開始しない。すべてのデータが揃ってからアプリケーションは待ち動作を開始する。よってアプリケーションが待ち動作を開始した後、高速にすべてのデータを取得できる。よって、アプリケーションにより待ち動作を行う時間は短くて済む。よってアプリケーションが多数の送信装置２０からデータを受信する場合でも、ファイルディスクリプタの生存期間（ソケットの生存期間）が短く、同時に動作させるディスクリプタ数（ソケット数）は低減される。よって、アプリケーションの負荷を低下できる。

図５は、本実施形態に係る受信装置１０の動作の一例を示すフローチャートである。ここでは送信装置２０から全てのデータを受信した場合に、接続通知条件が満たされる場合の動作例を記載する。アプリケーションはaccept()システムコール等を行うことで接続要求を待っている状況にあるとする。

受信装置１０の処理部１２０は、送信装置２０から接続要求を受信する（Ｓ２０１）。処理部１２０は、送信装置２０から受信するデータ列についてオフロード処理を行うかを、オフロード判定部１３０を用いて判定する（Ｓ２０２）。

処理部１２０は、オフロード処理を行わないと判定された場合は（Ｓ２０２のＮＯ）、accept()システムコールの応答等を送信することにより、接続要求の受信をアプリケーションに通知する（Ｓ２１０）。また、処理部１２０は、通知の後又は前において、送信装置２０に接続要求に対する確認応答を送信する。処理部１２０は、送信装置２０から逐次受信されるデータをアプリケーションに提供する（Ｓ２１１）。受信されるデータを一時的に一時記憶部１４０に格納し、一時記憶部１４０からデータを読み出してアプリケーションに提供してもよい。処理部１２０は、一例としてアプリケーションによるreceive()システムコールに対する応答としてデータをアプリケーションに提供する。処理部１２０は送信装置２０から全てのデータを受信し、かつ受信した全てのデータをアプリケーションに提供したかを判断する（Ｓ２１２）。まだ全てのデータを受信していない又はアプリケーションに提供していない場合（Ｓ２１２のＮＯ）、データの受信とデータの提供とを繰り返す。全てのデータの受信とデータの提供とを完了したら（Ｓ２１２のＹＥＳ）、処理を終了する。

処理部１２０は、オフロード処理を行うと判定された場合は（Ｓ２０２のＹＥＳ）、送信装置２０に接続要求に対する確認応答を送信し、その後、送信装置２０から受信する全てのデータを一時記憶部１４０に格納する（Ｓ２０４のＮＯ）。処理部１２０は、全てのデータの受信を終了した場合は（Ｓ２０４のＹＥＳ）、接続要求の受信をアプリケーションに通知する（Ｓ２０５）。処理部１２０は、一時記憶部１４０に格納されている全てのデータを順次読み出して、アプリケーションに提供する（Ｓ２０６）。処理部１２０は、例えばアプリケーションによるreceive()システムコールに対する応答としてデータをアプリケーションに提供してもよい。処理部１２０は、全てのデータをアプリケーションに提供したら、処理を終了する。

以上、本実施形態によれば、送信装置２０から接続要求を受信しても、接続要求の受信をアプリケーションにはすぐには通知せずに、送信装置２０から受信するデータを一時的に一時記憶部１４０に格納しておく（オフロード処理）。接続通知条件が満たされた場合に（例えば送信装置２０から全てのデータを受信した場合に）初めて、接続要求の受信をアプリケーションに通知する。アプリケーションは通知を受けた後、データを待つ動作を開始する。これにより、アプリケーションは、データが受信され終わった時点でデータを待つ処理を開始でき、アプリケーションに高速にデータを提供できるため。アプリケーションの負荷を軽減することができる。また多数の送信装置からのデータを取得する場合にも、同時に存在するファイルディスクリプタの数及び生存期間を低減することができる。

また本実施形態によれば、送信装置２０から受信するデータ列についてオフロード処理するか否かを判定することにより、データの優先度（例えば緊急度）等に応じて、オフロード処理するか否かを切り替えることができる。優先度が高い場合にはオフロード処理を行わないことで、アプリケーションに高速にデータを届けることが可能となる。優先度が低い場合にはオフロード処理を行うことで、アプリケーションの負荷を低減することができる。

また本実施形態ではオフロード処理の途中でオフロード処理を終了する（接続要求の受信をアプリケーションに通知する）ことも可能である。例えば予め定めたデータ量又は割合のデータが受信された時点で、accept()システムコールの正常応答を返す場合がある。あるいはオフロード終了フラグがオンになった時点で、accept()システムコールの正常応答を返す場合がある。これにより、送信装置がデータ列の送信の途中で緊急度が高くなった場合には、アプリケーションに受信済みのデータを高速に提供することができる。

［変形例］
図２の構成では、受信処理部１１０が受信装置１０に含まれていたが、受信処理部１１０が受信装置１０の外部装置として存在してもよい。

図６は、受信処理部１１０が外部装置（アプリケーション装置）として存在する場合の概略構成を示す。アプリケーション装置１１０Ａは、受信装置１０Ａとは無線又は有線の通信ネットワークを介して接続される。受信装置１０Ａには通信部１７０が設けられる。通信部１７０は通信ネットワークを介してアプリケーション装置１１０Ａと通信する。通信ネットワークは、無線ＬＡＮ、イーサネット等のローカルネットワークでもよいし、モバイルネットワーク又はインターネット等の広域ネットワークでもよいし、ＵＳＢ等のシリアル通信ケーブルでもよい。図６の構成においても、第１実施形態と同様の動作が行われる。

本変形例は以降に説明する他の実施形態においても同様に適用可能である。

（第２実施形態）
本実施形態では、送信装置２０から複数のアプリケーション用のデータを同一のデータフローとして１つのパケットにまとめて送信する。受信装置１０ではパケットに含まれるデータをアプリケーションごとに分離し、各データを対応するアプリケーションに提供する。この際、オフロード処理を行うか否かをアプリケーションごとに判定する。オフロード処理を行うと判定されたアプリケーションについては接続要求の受信を接続通知条件が満たされるまで（例えば当該アプリケーションのデータが全て受信されるまで）通知しない。一方、オフロード処理を行わないと判定されたアプリケーションについては接続要求を受信したタイミングで、接続要求の受信をアプリケーションに通知する。以下、第１実施形態との差分を中心に説明し、第１実施形態と同じ説明は適宜省略する。

本実施形態では、１つのパケットに複数のアプリケーションを含めるためにデータフローを制御するプロトコル（データフロー制御プロトコル（ＤＦＣＰ）と称する）を定義する。例えば、ＤＦＣＰヘッダをＴＣＰ等のトランスポート層の上位に設定する。これにより、１つのパケットに複数のアプリケーションのデータを含めて管理する。

図７は、本実施形態に係るパケットのフォーマット例を示す。図７のパケットはデータリンク層のパケットである。図７のパケットは、イーサーネットヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、ＤＦＣＰヘッダ、ＤＦＣＰのペイロード部、イーサネットＦＣＳ（Frame Check Sequence）を含む。ＤＦＣＰのペイロード部には、アプリケーションへ送信するデータ（例えばセンサで検出されたデータ）が格納される。ＤＦＣＰは、ＴＣＰよりも上位のプロトコルである。これらの層の全てが必須ではなく、また他の層が含まれてもよい。例えば複数のデータフローを共通に管理するデータフロー管理プロトコル（ＤＦＭＰ）を定義し、ＴＣＰヘッダとＤＦＣＰヘッダとの間に、ＤＦＭＰヘッダを追加してもよい。

ＤＦＣＰヘッダには、例えばデータフロー又はアプリケーションを識別するＩＤが格納される。またＤＦＣＰヘッダには、データフローごとのシーケンス番号（ローカルシーケンス番号）が格納されていてもよい。図の例では２つのＤＦＣＰヘッダが含まれ、それぞれのペイロード部に異なるアプリケーションのデータ（例えば異なるセンサから検出されたデータ）が格納される。ＤＦＣＰヘッダの個数は２に限定されず、１でも、３以上でもよい。図７のフォーマットのパケットを第１実施形態で用いてもよい。ＤＦＭＰヘッダを含める場合、ＤＦＭＰヘッダには、ＤＦＭＰで管理するシーケンス番号（グローバルシーケンス番号）を含めてもよい。

送信装置２０は、第１実施形態と同様にして、受信装置１０と接続した後、複数のアプリケーションのデータを含むパケットを順次生成し、受信装置１０に送信する。

本実施形態の受信装置１０のブロック図は、第１実施形態と同じ（図２参照）である。受信装置１０では、複数（例えば２つ）のアプリケーションが送信装置２０から接続要求待っている。送信装置２０から接続要求を受信すると、オフロード判定部１３０は、アプリケーションごとにオフロード処理を行うか否かを判定する。処理部１２０は、送信装置２０から複数のアプリケーションのデータを含むパケットを受信し、ＤＦＣＰヘッダに基づきパケットから各アプリケーションのデータを取り出す。処理部１２０は、オフロード処理を行うと判定されたアプリケーションのデータについては、第１実施形態で用いた図５のステップＳ２０３～Ｓ２０６と同様の処理を行う。オフロード処理を行わないと判定されたアプリケーションのデータについては、図５のステップＳ２１０～Ｓ２１２と同様の処理を行う。詳細は第１実施形態で説明したため省略する。

アプリケーションに提供するデータサイズを一定にするため、処理部１２０は、データフローごとに、複数のパケットから抽出したデータを統合してもよい。例えば、処理部１２０は、あるパケットに含まれるアプリケーション１用のデータと、次に受信されるパケットに含まれる当該アプリケーション１用のデータの全部又は一部とを結合して、データサイズを一定にする。処理部１２０は、一定サイズのデータをアプリケーションに提供する。これによりアプリケーションに効率的にデータを提供することができる。なお、複数のパケットに含まれるデータの結合は第１実施形態で行ってもよい。例えば通信ネットワーク３０の通信品質が低い（例えばパケットエラーレートが高いなど）場合に、パケット長を短くし、受信装置１０側で複数のパケットに含まれるデータを結合することが考えられる。

［変形例］
第１実施形態と第２実施形態を組み合わせてもよい。例えば、送信装置２０は、最初は第１実施形態に従って、アプリケーションごとに（例えばアプリケーション１とアプリケーション２ごとに）、別々のパケットでデータを送信する。アプリケーション１用のデータサイズが途中で小さくなったとする。アプリケーション２のデータと結合しても、１つのパケットで送信可能なサイズに収まる場合は、途中から第２実施形態に従って、１つのパケットにアプリケーション１のデータと、アプリケーション２のデータとを含める。これにより送信するパケットの個数を低減し、送信装置２０の負荷及び受信装置１０の負荷を低減できる。

（第３実施形態）
第１実施形態及び第２実施形態では受信装置１０でオフロード処理を行ったが、第３実施形態では送信装置２０でオフロード処理を行う。第１実施形態及び第２実施形態と同じ構成及び動作についての説明は適宜省略する。

図８は、第３実施形態に係る送信装置のブロック図である。送信装置５０は受信装置６０と通信する。図８では送信装置５０が１台のみ示されているが、複数の送信装置５０が存在してよい。また受信装置６０の台数も１台に限定されない。図８の送信装置５０の構成は、本実施形態の説明に必要な要素のみを示したものであり、ユーザが指示又はデータを入力する入力部、ユーザに情報を提示する出力部など、他にも様々な要素が含まれてもよい。図８に示す送信装置５０は受信装置６０と無線通信を行うが、有線通信を行う構成も排除されない。

送信装置５０は、送信処理部２１０と、処理部２２０と、一時記憶部２４０と、通信部２５０と、少なくとも１つのアンテナ２６０とを備えている。送信装置５０は、センサ２８０と結合されている。

通信部２５０は、アンテナ２６０を介して無線信号を送受信することにより、受信装置６０と通信する。通信部２５０は、一例として、符号／復号処理、変復調処理、帯域調整、ＡＤ／ＤＡ変換、信号増幅などを行う。

送信処理部２１０はセンサ２８０に結合されている。センサ２８０は、アプリケーション用のデータを検出し、検出したデータを出力する。図８の例ではセンサは１つであるが、２つ以上でもよい。この場合、センサごとにアプリケーション用のデータを検出する。

センサの例は、カメラ、ＧＰＳ、ＬｉＤＡＲ、速度センサ、加速度センサ、自動車の制御データ（エンジン回転状態、アクセルの踏み込み状態など）の検出センサ、急ブレーキの検出センサ、障害物（落下物、前方車両）の検出センサなどを含む。センサは、一例として、時系列に一定間隔でデータを出力する（例えば２４時間のストリーミングデータを出力する）。あるいは、センサは、イベントが発生したタイミングなど、特定のタイミングでデータを出力する。例えば、センサは、自動車の搭乗者等のユーザから操作部を介して入力されるデータを検出してもよい。１つのセンサの出力は、１つのデータフローに対応する。

送信処理部２１０は、センサ２８０から検出されたデータを逐次取得する。送信処理部２１０は、センサ２８０から検出されたデータを取得するデータ取得装置を含む。送信処理部２１０は取得したデータを一時的に保持するメモリ等の記憶部を内部又は送信処理部２１０からアクセス可能な外部に備えていてもよい。送信処理部２１０は、通信バスを介して処理部２２０に結合されている。通信バスは、送信処理部２１０と処理部２２０間の通信を行うための第１通信媒体に相当する。

送信処理部２１０は、センサ２８０から取得するデータを、オフロード処理を行う処理部２２０に送信する。すなわち、送信処理部２１０は、データを受信装置６０に送信するのではなく処理部２２０に送信する。データは一定サイズ分ずつ送信してもよいし、センサ２８０から取得したデータの単位で送信してもよい。

処理部２２０への送信に用いる通信プロトコルは任意でよいが、例えばＩＰ／ＴＣＰを用いることができる。ここではＩＰ／ＴＣＰを用いる場合を記載する。この場合、送信処理部２１０は、第１実施形態と同様にソケットを識別するファイルディスクリプタを生成し、ソケットにポート番号等を割り当て、ソケットを介してパケットを処理部２２０に送信してもよい。ポート番号はアプリケーションのポート番号でもよいし、任意のポート番号でもよい。送信処理部２１０は、接続要求（ＳＹＮ）を処理部２２０に送信し、処理部２２０から確認応答（ＡＣＫ）を受信すると、データの送信を開始する。データの送信を終了すると、接続の終了要求（ＦＩＮ）を送信する。送信処理部２１０が送信する接続要求は一例として、データの第１接続要求に対応する。

送信処理部２１０と処理部２２０間は通信バス（低遅延の通信媒体）で結合されているため、データは高速に処理部２２０に送信される。

処理部２２０は、送信処理部２１０と受信装置６０間におけるデータの送受信に関する処理を行うプロキシ装置である。処理部２２０は、送信処理部２１０に対してサーバとして機能する。処理部２２０は、送信処理部２１０に代わって受信装置６０にデータの送信を行うオフロード処理を行う機能を有する。また、処理部２２０は、ＩＰ／ＴＣＰに関する処理を行う。物理層及びデータリンク層に関する処理を処理部２２０でさらに行ってもよい。物理層及びデータリンク層に関する処理を通信部２５０が行ってもよい。処理部２２０は一例として専用のハードウェア回路によって構成されてもよいし、プログラムによって構成されてもよいし、又はこれらの両方によって構成されてもよい。

処理部２２０は、通信バス（第１通信媒体）を介して、送信処理部２１０からアプリケーション用のデータを送信するための接続要求（第１接続要求）を受信し、第１接続要求が受信された後、第１通信媒体を介して、送信処理部２１０からデータを受信する受信部を含む。受信部において、接続要求を受信するハードウェア回路と、データを受信するハードウェア回路とは同じであってもよいし、接続要求を受信するハードウェア回路と、データを受信するハードウェア回路とが異なってもよい。

処理部２２０は、送信処理部２１０から受信するデータを一時記憶部２４０に格納する。より詳細には、処理部２２０は、送信処理部２１０からパケットを受信し、受信したパケットに含まれるデータを一時記憶部２４０に格納する。処理部２２０と送信処理部２１０は通信バスで結合されているため、処理部２２０は、送信処理部２１０から逐次送信されるデータを高速に受信する。

処理部２２０は、送信処理部２１０から受信したデータを、送信処理部２１０に代わって受信装置６０に送信（代理送信）する。処理部２２０は、受信装置６０と通信ネットワーク３０を介して接続し、一時記憶部２４０内のデータを受信装置６０のアプリケーション宛に送信する。通信ネットワーク３０は通信部２５０と受信装置６０間の通信を行うための第２通信媒体に相当する。

受信装置６０へのデータの送信方法は、第１実施形態において送信装置２０が受信装置１０にデータを送信する方法と同様でよい。例えば、処理部２２０は、受信装置６０（例えばアプリケーションがaccept()システムコールにより接続要求を待っている状態である）に接続要求（第２接続要求）を送信する。処理部２２０は、受信装置６０から確認応答を受信すると、データ送信を開始する。データ送信を終了すると、接続の終了要求を送信する。アプリケーションのポート番号は予め指定されていてもよいし、送信処理部２１０から受信するパケットのポート番号としてアプリケーションのポート番号が用いられている場合は、当該パケットからアプリケーションのポート番号を特定してもよい。

処理部２２０は、送信処理部２１０からのデータの受信と並行して、受信装置６０へのデータの送信を行う。処理部２２０は、少なくとも送信処理部２１０からの接続要求が受信された後、送信装置５０からのデータの受信が終了する前に、受信装置６０に接続要求を送信する。

通信部２５０又は処理部２２０は、送信処理部２１０から接続要求（第１接続要求）が受信された後、データの受信が終了する前に、通信ネットワーク３０（第２通信媒体）を介して、当該データを送信するための接続要求（第２接続要求）を送信し、当該接続要求（第２接続要求）を送信した後、通信ネットワーク３０（第２通信媒体）を介して、データを送信する送信部を含む。送信部において、接続要求を送信するハードウェア回路とデータを送信するハードウェア回路とは同じであってもよいし、接続要求を送信するハードウェア回路とデータを送信するハードウェア回路とが異なってもよい。

受信装置６０の構成は、第１実施形態の受信装置１０と同じでもよいし、一般的な動作を行う受信装置でもよい。受信装置６０は、送信装置５０から受信したデータを、アプリケーションに提供する。

図９は、送信装置５０が受信装置６０にデータを送信する動作シーケンスの例を示す。

送信装置５０における送信処理部２１０は、センサ２８０からデータ列を取得する。送信処理部２１０は、データ列の取得と並行して、もしくはデータ列の取得が終了すると、処理部２２０にデータを送信する。送信処理部２１０は、接続要求（ＳＹＮ）を処理部２２０に送信する（Ｓ５１）。送信処理部２１０は、処理部２２０から確認応答（ＡＣＫ）を受信すると（Ｓ５２）、データ列の送信を開始する（Ｓ５３－１、Ｓ５３－２、Ｓ５３－３、・・・）。送信処理部２１０はデータ列の送信が終了すると、接続の終了要求（ＦＩＮ）を処理部２２０に送信する（Ｓ５４）。

処理部２２０は、送信処理部２１０に確認応答を送信後、送信処理部２１０から送信されるデータを逐次受信し、受信したデータを一時記憶部２４０に格納する。処理部２２０は各データに対する確認応答を送信装置５０に送信する。処理部２２０は、送信装置５０に接続要求（ＳＹＮ）を送信する（Ｓ１６１）。接続要求の送信は、送信処理部２１０への確認応答の送信後、データの受信開始前に行ってもよいし、送信処理部２１０からのデータの受信の開始後に行ってもよい。なお、送信処理部２１０からのデータ列の受信終了後に、接続要求を送信することも排除されない。処理部２２０は、受信装置６０から確認応答（ＡＣＫ）を受信すると（Ｓ１６２）、一時記憶部２４０からデータを順次読み出して、受信装置６０に送信する。処理部２２０は、送信処理部２１０から受信したデータのすべての送信を終了すると、接続の終了要求（ＦＩＮ）を送信する（Ｓ１６４）。なお再送タイムアウトにより一部のデータが受信装置６０に届かない場合もあり得る。

受信装置６０では送信装置５０から受信したデータをアプリケーションに提供する。

図１０は、本実施形態に係る送信装置５０の動作の一例を示すフローチャートである。送信装置５０の処理部２２０はaccept()システムコール等を行うことで接続要求を待っている状況にあるとする。

処理部２２０は、通信バスを介して送信処理部２１０から接続要求を受信する（Ｓ３０１）。処理部２２０は接続要求に対する確認応答を送信後、送信処理部２１０から通信バスを介してデータを受信する（Ｓ３０２）。処理部２２０は、受信されるデータを一時的に一時記憶部２４０に格納する。処理部２２０は、送信処理部２１０からのデータ受信が終了する前に、通信ネットワーク３０を介して受信装置６０に接続要求を送信する（Ｓ３０３）。接続要求の送信は、送信処理部２１０からのデータの受信開始前に行ってもよいし、受信開始後に行ってもよい。処理部２２０は、受信装置６０から接続要求に対する確認応答を受信する。処理部２２０は、送信処理部２１０から受信したデータを一時記憶部２４０から順番に読み出して、通信ネットワーク３０を介して受信装置６０に送信する（Ｓ３０４）。処理部２２０は全てのデータの送信を終了すると、接続の終了要求を受信装置６０に送信する。

以上、本実施形態によれば、送信処理部２１０が処理部２２０に通信バスを介してデータを送信し、処理部２２０が受信装置６０に通信ネットワークを介してデータを送信する。送信処理部２１０が、直接、受信装置にデータを送信する場合に比べて、データを高速に処理部２２０に送信でき、送信処理部２１０の負荷（例えばデータの送信処理を行うプログラムを実行するＣＰＵの負荷）を低減できる。

例えば、通信ネットワーク３０の通信品質に起因して遅延等が発生すると、送信装置５０からすべてのデータの送信が終了するまでに時間を要する。本実施形態ではこの場合も送信処理部２１０は通信バスを介してデータを処理部２２０に送信すればよいため、送信処理部２１０は遅延等の影響を受けずに、データを高速に送信することができる。よって送信処理部２１０におけるプログラムの実行負荷を低減でき、ＣＰＵの性能の低下を抑制できる。

［変形例１］
送信処理部２１０が複数のセンサに対応する複数のアプリケーション用のデータを処理部２２０に送信する場合、処理部２２０は複数のアプリケーション用のデータを１つのパケットにまとめて送信してもよい。すなわち複数のデータフローを１つのデータフローに合成する。例えば、前述したデータフロー制御プロトコル（ＤＦＣＰ）を用いて１つのパケットに複数のアプリケーションのデータを格納できる（図７参照）。この際、１パケットに含める各アプリケーション用のデータのデータ量又は割合を、各データの優先度（各アプリケーションの優先度）に応じて制御してもよい。例えば、優先度（例えば緊急度）が高いデータのデータ量又は割合を、優先度の低いデータのデータ量又は割合よりも大きくする。

［変形例２］
図８の構成では、送信処理部２１０が送信装置５０に含まれていたが、送信処理部２１０が送信装置５０の外部装置として送信装置５０とは別体の装置として存在してもよい。

図１１は、送信処理部２１０が送信処理装置２１０Ａとして存在する場合の概略構成を示す。送信処理装置２１０Ａはセンサ２８０からデータを取得するデータ取得装置を含む。送信処理装置２１０Ａは、送信装置５０Ａと通信媒体（第１通信媒体）を介して接続される。第１通信媒体は、送信装置５０Ａ及び受信装置６０間の通信媒体（第２通信媒体）である通信ネットワーク３０よりも低遅延である。送信装置５０Ａには送信処理装置２１０Ａと通信する通信部２７０が設けられる。

通信部２７０は第１通信媒体を介して送信処理装置２１０Ａと通信する。第１通信媒体は、ＵＳＢ等のシリアル通信ケーブル、無線ＬＡＮ、イーサネット等のローカルネットワークでもよいし、モバイルネットワーク又はインターネット等の広域ネットワークでもよい。通信部２７０又は処理部２２０は、第１通信媒体を介して、送信処理部２１０からアプリケーション用のデータを送信するための接続要求（第１接続要求）を受信する第１受信部と、第１接続要求が受信された後、第１通信媒体を介して、送信処理部２１０からデータを受信する第２受信部を含む。図１１の構成において、第２実施形態と同様の動作が行われる。

前述した実施形態における各装置（送信装置２０、又は受信装置１０）の一部又は全部は、ハードウェアで構成されていてもよいし、ＣＰＵ（Central Processing Unit）、又はＧＰＵ（Graphics Processing Unit）等が実行するソフトウェア（プログラム）の情報処理で構成されてもよい。ソフトウェアの情報処理で構成される場合には、前述した実施形態における各装置の少なくとも一部の機能を実現するソフトウェアを、フレキシブルディスク、ＣＤ－ＲＯＭ（Compact Disc-Read Only Memory）、又はＵＳＢ（Universal Serial Bus）メモリ等の非一時的な記憶媒体（非一時的なコンピュータ可読媒体）に収納し、コンピュータに読み込ませることにより、ソフトウェアの情報処理を実行してもよい。また、通信ネットワークを介して当該ソフトウェアがダウンロードされてもよい。さらに、ソフトウェアがＡＳＩＣ（Application Specific Integrated Circuit）、又はＦＰＧＡ（Field Programmable Gate Array）等の回路に実装されることにより、情報処理がハードウェアにより実行されてもよい。

ソフトウェアを収納する記憶媒体の種類は限定されるものではない。記憶媒体は、磁気ディスク、又は光ディスク等の着脱可能なものに限定されず、ハードディスク、又はメモリ等の固定型の記憶媒体であってもよい。また、記憶媒体は、コンピュータ内部に備えられてもよいし、コンピュータ外部に備えられてもよい。

図１２は、前述した実施形態における各装置（送信装置２０、又は受信装置１０）のハードウェア構成の一例を示すブロック図である。各装置は、一例として、プロセッサ９１と、主記憶装置９２（メモリ）と、補助記憶装置９３（メモリ）と、ネットワークインタフェース９４と、デバイスインタフェース９５と、を備え、これらがバス９６を介して接続されたコンピュータ９０として実現されてもよい。

図１２のコンピュータ９０は、各構成要素を一つ備えているが、同じ構成要素を複数備えていてもよい。また、図１２では、１台のコンピュータ９０が示されているが、ソフトウェアが複数台のコンピュータにインストールされて、当該複数台のコンピュータそれぞれがソフトウェアの同一の又は異なる一部の処理を実行してもよい。この場合、コンピュータそれぞれがネットワークインタフェース９４等を介して通信して処理を実行する分散コンピューティングの形態であってもよい。つまり、前述した実施形態における各装置（送信装置２０、又は受信装置１０）は、１又は複数の記憶装置に記憶された命令を１台又は複数台のコンピュータが実行することで機能を実現するシステムとして構成されてもよい。また、端末から送信された情報をクラウド上に設けられた１台又は複数台のコンピュータで処理し、この処理結果を端末に送信するような構成であってもよい。

前述した実施形態における各装置（送信装置２０、又は受信装置１０）の各種演算は、１又は複数のプロセッサを用いて、又は、ネットワークを介した複数台のコンピュータを用いて、並列処理で実行されてもよい。また、各種演算が、プロセッサ内に複数ある演算コアに振り分けられて、並列処理で実行されてもよい。また、本開示の処理、手段等の一部又は全部は、ネットワークを介してコンピュータ９０と通信可能なクラウド上に設けられたプロセッサ及び記憶装置の少なくとも一方により実行されてもよい。このように、前述した実施形態における各装置は、１台又は複数台のコンピュータによる並列コンピューティングの形態であってもよい。

プロセッサ９１は、コンピュータの制御装置及び演算装置を含む電子回路（処理回路、Processing circuit、Processing circuitry、ＣＰＵ、ＧＰＵ、ＦＰＧＡ、又はＡＳＩＣ等）であってもよい。また、プロセッサ９１は、専用の処理回路を含む半導体装置等であってもよい。プロセッサ９１は、電子論理素子を用いた電子回路に限定されるものではなく、光論理素子を用いた光回路により実現されてもよい。また、プロセッサ９１は、量子コンピューティングに基づく演算機能を含むものであってもよい。

プロセッサ９１は、コンピュータ９０の内部構成の各装置等から入力されたデータやソフトウェア（プログラム）に基づいて演算処理を行い、演算結果や制御信号を各装置等に出力することができる。プロセッサ９１は、コンピュータ９０のＯＳ（Operating System）や、アプリケーション等を実行することにより、コンピュータ９０を構成する各構成要素を制御してもよい。

前述した実施形態における各装置（送信装置２０、又は受信装置１０）は、１又は複数のプロセッサ９１により実現されてもよい。ここで、プロセッサ９１は、１チップ上に配置された１又は複数の電子回路を指してもよいし、２つ以上のチップあるいは２つ以上のデバイス上に配置された１又は複数の電子回路を指してもよい。複数の電子回路を用いる場合、各電子回路は有線又は無線により通信してもよい。

主記憶装置９２は、プロセッサ９１が実行する命令及び各種データ等を記憶する記憶装置であり、主記憶装置９２に記憶された情報がプロセッサ９１により読み出される。補助記憶装置９３は、主記憶装置９２以外の記憶装置である。なお、これらの記憶装置は、電子情報を格納可能な任意の電子部品を意味するものとし、半導体のメモリでもよい。半導体のメモリは、揮発性メモリ、不揮発性メモリのいずれでもよい。前述した実施形態における各装置（送信装置２０、又は受信装置１０）において各種データを保存するための記憶装置は、主記憶装置９２又は補助記憶装置９３により実現されてもよく、プロセッサ９１に内蔵される内蔵メモリにより実現されてもよい。例えば、前述した実施形態における一時記憶部１４０、２４０は、主記憶装置９２又は補助記憶装置９３により実現されてもよい。

記憶装置（メモリ）１つに対して、複数のプロセッサが接続（結合）されてもよいし、単数のプロセッサが接続されてもよい。プロセッサ１つに対して、複数の記憶装置（メモリ）が接続（結合）されてもよい。前述した実施形態における各装置（送信装置２０、又は受信装置１０）が、少なくとも１つの記憶装置（メモリ）とこの少なくとも１つの記憶装置（メモリ）に接続（結合）される複数のプロセッサで構成される場合、複数のプロセッサのうち少なくとも１つのプロセッサが、少なくとも１つの記憶装置（メモリ）に接続（結合）される構成を含んでもよい。また、複数台のコンピュータに含まれる記憶装置（メモリ））とプロセッサによって、この構成が実現されてもよい。さらに、記憶装置（メモリ）がプロセッサと一体になっている構成（例えば、Ｌ１キャッシュ、Ｌ２キャッシュを含むキャッシュメモリ）を含んでもよい。

ネットワークインタフェース９４は、無線又は有線により、通信ネットワーク９７に接続するためのインタフェースである。ネットワークインタフェース９４は、既存の通信規格に適合したもの等、適切なインタフェースを用いればよい。ネットワークインタフェース９４により、通信ネットワーク９７を介して接続された外部装置９８Ａと情報のやり取りが行われてもよい。なお、通信ネットワーク９７は、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、ＰＡＮ（Personal Area Network）等の何れか、又は、それらの組み合わせであってよく、コンピュータ９０と外部装置９８Ａとの間で情報のやり取りが行われるものであればよい。ＷＡＮの一例としてインターネット等があり、ＬＡＮの一例としてＩＥＥＥ８０２．１１やイーサネット（登録商標）等があり、ＰＡＮの一例としてＢｌｕｅｔｏｏｔｈ（登録商標）やＮＦＣ（Near Field Communication）等がある。

デバイスインタフェース９５は、外部装置９８Ｂと直接接続するＵＳＢ等のインタフェースである。

外部装置９８Ａはコンピュータ９０とネットワークを介して接続されている装置である。外部装置９８Ｂはコンピュータ９０と直接接続されている装置である。

外部装置９８Ａ又は外部装置９８Ｂは、一例として、入力装置であってもよい。入力装置は、例えば、カメラ、マイクロフォン、モーションキャプチャ、各種センサ、キーボード、マウス、又はタッチパネル等のデバイスであり、取得した情報をコンピュータ９０に与える。また、パーソナルコンピュータ、タブレット端末、又はスマートフォン等の入力部とメモリとプロセッサを備えるデバイスであってもよい。

また、外部装置９８Ａ又は外部装置９８Ｂは、一例として、出力装置でもよい。出力装置は、例えば、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、ＰＤＰ（Plasma Display Panel）、又は有機ＥＬ（Electro Luminescence）パネル等の表示装置であってもよいし、音声等を出力するスピーカ等であってもよい。また、パーソナルコンピュータ、タブレット端末、又はスマートフォン等の出力部とメモリとプロセッサを備えるデバイスであってもよい。

また、外部装置９８Ａまた外部装置９８Ｂは、記憶装置（メモリ）であってもよい。例えば、外部装置９８Ａはネットワークストレージ等であってもよく、外部装置９８ＢはＨＤＤ等のストレージであってもよい。

また、外部装置９８Ａ又は外部装置９８Ｂは、前述した実施形態における各装置（送信装置２０、又は受信装置１０）の構成要素の一部の機能を有する装置でもよい。つまり、コンピュータ９０は、外部装置９８Ａ又は外部装置９８Ｂの処理結果の一部又は全部を送信又は受信してもよい。

本明細書（請求項を含む）において、「a、b及びcの少なくとも1つ（一方）」又は「a、b又はcの少なくとも1つ（一方）」の表現（同様な表現を含む）が用いられる場合は、a、b、c、a-b、a-c、b-c、又はa-b-cのいずれかを含む。また、a-a、a-b-b、a-a-b-b-c-c等のように、いずれかの要素について複数のインスタンスを含んでもよい。さらに、a-b-c-dのようにdを有する等、列挙された要素（a、b及びc）以外の他の要素を加えることも含む。

本明細書（請求項を含む）において、「データを入力として／データに基づいて／に従って／に応じて」等の表現（同様な表現を含む）が用いられる場合は、特に断りがない場合、各種データそのものを入力として用いる場合や、各種データに何らかの処理を行ったもの（例えば、ノイズ加算したもの、正規化したもの、各種データの中間表現等）を入力として用いる場合を含む。また「データに基づいて／に従って／に応じて」何らかの結果が得られる旨が記載されている場合、当該データのみに基づいて当該結果が得られる場合を含むとともに、当該データ以外の他のデータ、要因、条件、及び／又は状態等にも影響を受けて当該結果が得られる場合をも含み得る。また、「データを出力する」旨が記載されている場合、特に断りがない場合、各種データそのものを出力として用いる場合や、各種データに何らかの処理を行ったもの（例えば、ノイズ加算したもの、正規化したもの、各種データの中間表現等）を出力とする場合も含む。

本明細書（請求項を含む）において、「接続される（connected）」及び「結合される（coupled）」との用語が用いられる場合は、直接的な接続／結合、間接的な接続／結合、電気的（electrically）な接続／結合、通信的（communicatively）な接続／結合、機能的（operatively）な接続／結合、物理的（physically）な接続／結合等のいずれをも含む非限定的な用語として意図される。当該用語は、当該用語が用いられた文脈に応じて適宜解釈されるべきであるが、意図的に或いは当然に排除されるのではない接続／結合形態は、当該用語に含まれるものして非限定的に解釈されるべきである。

本明細書（請求項を含む）において、「ＡがＢするよう構成される（A configured to B）」との表現が用いられる場合は、要素Ａの物理的構造が、動作Ｂを実行可能な構成を有するとともに、要素Ａの恒常的（permanent）又は一時的（temporary）な設定（setting/configuration）が、動作Ｂを実際に実行するように設定（configured/set）されていることを含んでよい。例えば、要素Ａが汎用プロセッサである場合、当該プロセッサが動作Ｂを実行可能なハードウェア構成を有するとともに、恒常的（permanent）又は一時的（temporary）なプログラム（命令）の設定により、動作Ｂを実際に実行するように設定（configured）されていればよい。また、要素Ａが専用プロセッサ又は専用演算回路等である場合、制御用命令及びデータが実際に付属しているか否かとは無関係に、当該プロセッサの回路的構造が動作Ｂを実際に実行するように構築（implemented）されていればよい。

本明細書（請求項を含む）において、含有又は所有を意味する用語（例えば、「含む（comprising/including）」及び有する「（having）等）」が用いられる場合は、当該用語の目的語により示される対象物以外の物を含有又は所有する場合を含む、open-endedな用語として意図される。これらの含有又は所有を意味する用語の目的語が数量を指定しない又は単数を示唆する表現（a又はanを冠詞とする表現）である場合は、当該表現は特定の数に限定されないものとして解釈されるべきである。

本明細書（請求項を含む）において、ある箇所において「１つ又は複数（one or more）」又は「少なくとも１つ（at least one）」等の表現が用いられ、他の箇所において数量を指定しない又は単数を示唆する表現（a又はanを冠詞とする表現）が用いられているとしても、後者の表現が「１つ」を意味することを意図しない。一般に、数量を指定しない又は単数を示唆する表現（a又はanを冠詞とする表現）は、必ずしも特定の数に限定されないものとして解釈されるべきである。

本明細書において、ある実施例の有する特定の構成について特定の効果（advantage/result）が得られる旨が記載されている場合、別段の理由がない限り、当該構成を有する他の１つ又は複数の実施例についても当該効果が得られると理解されるべきである。但し当該効果の有無は、一般に種々の要因、条件、及び／又は状態等に依存し、当該構成により必ず当該効果が得られるものではないと理解されるべきである。当該効果は、種々の要因、条件、及び／又は状態等が満たされたときに実施例に記載の当該構成により得られるものに過ぎず、当該構成又は類似の構成を規定したクレームに係る発明において、当該効果が必ずしも得られるものではない。

本明細書（請求項を含む）において、「最大化（maximize）」等の用語が用いられる場合は、グローバルな最大値を求めること、グローバルな最大値の近似値を求めること、ローカルな最大値を求めること、及びローカルな最大値の近似値を求めることを含み、当該用語が用いられた文脈に応じて適宜解釈されるべきである。また、これら最大値の近似値を確率的又はヒューリスティックに求めることを含む。同様に、「最小化（minimize）」等の用語が用いられる場合は、グローバルな最小値を求めること、グローバルな最小値の近似値を求めること、ローカルな最小値を求めること、及びローカルな最小値の近似値を求めることを含み、当該用語が用いられた文脈に応じて適宜解釈されるべきである。また、これら最小値の近似値を確率的又はヒューリスティックに求めることを含む。同様に、「最適化（optimize）」等の用語が用いられる場合は、グローバルな最適値を求めること、グローバルな最適値の近似値を求めること、ローカルな最適値を求めること、及びローカルな最適値の近似値を求めることを含み、当該用語が用いられた文脈に応じて適宜解釈されるべきである。また、これら最適値の近似値を確率的又はヒューリスティックに求めることを含む。

本明細書（請求項を含む）において、複数のハードウェアが所定の処理を行う場合、各ハードウェアが協働して所定の処理を行ってもよいし、一部のハードウェアが所定の処理の全てを行ってもよい。また、一部のハードウェアが所定の処理の一部を行い、別のハードウェアが所定の処理の残りを行ってもよい。本明細書（請求項を含む）において、「１又は複数のハードウェアが第１の処理を行い、前記１又は複数のハードウェアが第２の処理を行う」等の表現が用いられている場合、第１の処理を行うハードウェアと第２の処理を行うハードウェアは同じものであってもよいし、異なるものであってもよい。つまり、第１の処理を行うハードウェア及び第２の処理を行うハードウェアが、前記１又は複数のハードウェアに含まれていればよい。なお、ハードウェアは、電子回路、又は電子回路を含む装置等を含んでよい。

本明細書（請求項を含む）において、複数の記憶装置（メモリ）がデータの記憶を行う場合、複数の記憶装置（メモリ）のうち個々の記憶装置（メモリ）は、データの一部のみを記憶してもよいし、データの全体を記憶してもよい。

以上、本開示の実施形態について詳述したが、本開示は上記した個々の実施形態に限定されるものではない。特許請求の範囲に規定された内容及びその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲において種々の追加、変更、置き換え及び部分的削除等が可能である。例えば、前述した全ての実施形態において、数値又は数式を説明に用いている場合は、一例として示したものであり、これらに限られるものではない。また、実施形態における各動作の順序は、一例として示したものであり、これらに限られるものではない。

１０ 受信装置
１０Ａ 受信装置
２０ 送信装置
３０ 通信ネットワーク
５０ 送信装置
５０Ａ 送信装置
６０ 受信装置
９０ コンピュータ
９１ プロセッサ
９２ 主記憶装置
９３ 補助記憶装置
９４ ネットワークインタフェース
９５ デバイスインタフェース
９６ バス
９７ 通信ネットワーク
９８Ａ 外部装置
９８Ｂ 外部装置
１１０ 受信処理部
１１０Ａ アプリケーション装置
１２０ 処理部
１３０ オフロード判定部
１４０ 一時記憶部
１５０ 通信部
１６０ アンテナ
１７０ 通信部
２１０ 送信処理部
２１０Ａ 送信処理装置
２２０ 処理部
２４０ 一時記憶部
２５０ 通信部
２６０ アンテナ
２７０ 通信部
２８０ センサ

Claims (11)

1. アプリケーション用のデータを送信するための接続要求を送信装置から受信し、前記接続要求を受信した後、前記データを受信する、受信部と、
   複数の前記データが受信されるまで、前記接続要求の受信を前記アプリケーションに通知することを待機する処理部と、
   を備えた通信装置。
2. 前記処理部は、予め定めた量の前記データが受信されたとき又は予め定めた割合の前記データが受信されたとき、前記接続要求の受信を前記アプリケーションに通知する、
   請求項１に記載の通信装置。
3. 前記処理部は、前記受信部で受信するべきデータ量のうち受信済みのデータ量の割合に基づいて、前記アプリケーションに前記接続要求の受信を通知する、
   請求項１に記載の通信装置。
4. 前記処理部は、複数の前記アプリケーション用のデータを受信する、
   請求項１～３のいずれか一項に記載の通信装置。
5. 前記接続要求の受信を前記アプリケーションに通知することを待機するか否かを判定する判定部、
   をさらに備えた請求項１～４のいずれか一項に記載の通信装置。
6. 前記判定部は、前記接続要求の受信を前記アプリケーションに通知することを待機するか否かを、前記データに関する情報又は前記アプリケーションに関する情報に基づいて判定する、
   請求項５に記載の通信装置。
7. 前記データに関する情報又は前記アプリケーションに関する情報は、前記データの優先度及び前記データの緊急度の少なくとも1つを含む、
   請求項６に記載の通信装置。
8. 前記処理部は、前記接続要求の受信を前記アプリケーションに通知することを待機している間、所定の終了条件に基づいて、前記接続要求の受信を前記アプリケーションに通知することの待機を終了する、
   請求項７に記載の通信装置。
9. 前記所定の終了条件は、データ送信の優先度が高くなったときに満たされる、
   請求項８に記載の通信装置。
10. アプリケーション用のデータを送信するための接続要求を送信装置から受信し、
    前記接続要求を受信した後、前記データを受信し、
    複数の前記データが受信されるまで、前記接続要求の受信を前記アプリケーションに通知することを待機する、
    通信方法。
11. アプリケーション用のデータを送信するための接続要求を送信装置から受信するステップと、
    前記接続要求を受信した後、前記データを受信するステップと、
    複数の前記データが受信されるまで、前記接続要求の受信を前記アプリケーションに通知することを待機するステップと、
    をコンピュータに実行させるためのプログラム。

Images