特許 7427464 通信装置、通信方法およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-01-26

(45)【発行日】2024-02-05

(54)【発明の名称】通信装置、通信方法およびプログラム

(51)【国際特許分類】

   H04L 69/00 20220101AFI20240129BHJP

【ＦＩ】

H04L69/00

【請求項の数】 12

(21)【出願番号】P 2020022229

(22)【出願日】2020-02-13

(65)【公開番号】P2021129201

(43)【公開日】2021-09-02

【審査請求日】2023-01-16

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100109380

【弁理士】

【氏名又は名称】小西 恵

(74)【代理人】

【識別番号】100109036

【弁理士】

【氏名又は名称】永岡 重幸

(72)【発明者】

【氏名】木下 暁央

【審査官】和平 悠希

(56)【参考文献】

【文献】特開２０１９－１６５３８０（ＪＰ，Ａ）

【文献】特開２０１９－１６５４２３（ＪＰ，Ａ）

【文献】特開平０７－０３０６１１（ＪＰ，Ａ）

【文献】特開２００３－３０４２４８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ １２／００－１２／６６

Ｈ０４Ｌ ４１／００－１０１／６９５

(57)【特許請求の範囲】

【請求項1】

送信データを含むパケットをバッファに格納する格納手段と、
前記格納手段に格納された前記パケットを送信する送信手段と、
前記送信手段によって前記パケットが送信された場合に、前記パケットの格納に用いられた前記バッファを解放する解放手段と、
前記バッファの解放を通知させるか否かを設定する設定手段と、
前記解放手段によって前記バッファが解放された場合に、前記設定手段で通知させる設定がされている場合に前記バッファの解放を通知し、通知させない設定がされている場合に前記バッファの開放を通知しない通知手段と、
を備えることを特徴とする通信装置。

【請求項2】

前記送信データから前記パケットを生成する生成手段をさらに備えることを特徴とする請求項１に記載の通信装置。

【請求項3】

前記生成手段は、オフローダを用いて前記パケットを生成することを特徴とする請求項２に記載の通信装置。

【請求項4】

前記オフローダは、ＴＳＯ（ＴＣＰ Ｓｅｇｍｅｎｔａｔｉｏｎ Ｏｆｆｌｏａｄ）機能を用いることで、前記パケットを生成することを特徴とする請求項３に記載の通信装置。

【請求項5】

前記通知手段は、前記送信データの送信を要求したアプリケーションに対して前記バッファの解放を通知することを特徴とする請求項１から４のいずれか１項に記載の通信装置。

【請求項6】

前記アプリケーションは、前記通知手段から前記バッファの解放が通知されると、前記送信データの送信の要求を再開することを特徴とする請求項５に記載の通信装置。

【請求項7】

前記設定手段は、ソケットＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の返り値に基づいて、前記バッファの解放を通知させるか否かを設定することを特徴とする請求項１から６のいずれか１項に記載の通信装置。

【請求項8】

前記設定手段は、前記送信手段が前記パケットを送信する通信プロトコルの種類に基づいて、前記バッファの解放を通知させるか否かを設定することを特徴とする請求項１から７のいずれか１項に記載の通信装置。

【請求項9】

前記設定手段は、前記パケットを送信する通信インタフェースの種類に基づいて、前記バッファの解放を通知させるか否かを設定することを特徴とする請求項１から８のいずれか１項に記載の通信装置。

【請求項10】

前記通信インタフェースの種類は、有線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）および無線ＬＡＮを含むことを特徴とする請求項９に記載の通信装置。

【請求項11】

送信データを含むパケットをバッファに格納するステップと、
前記格納された前記パケットを送信するステップと、
前記パケットが送信された場合に、前記パケットの格納に用いられた前記バッファを解放するステップと、
前記バッファの解放を通知させるか否かを設定するステップと、
前記バッファが解放された場合に、前記設定するステップで通知させる設定がされている場合に前記バッファの解放を通知し、通知させない設定がされている場合に前記バッファの開放を通知しないステップと、
を備えることを特徴とする通信方法。

【請求項12】

コンピュータを請求項１から１０のいずれか１項に記載の通信装置として動作させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信装置、通信方法およびプログラムに関する。

【背景技術】

【0002】

ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）のプロトコル処理では、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）の処理軽減および通信の高速化が求められている。このような要求に対応するため、ハードウェアであるパケット生成オフローダを用いてパケットを生成する技術が採用されることがある。この技術では、パケット生成オフローダは、指定されたユーザデータをソケットＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）のコール毎にネットワークバッファへ転送する処理とチェックサム計算を同時に行う。そして、事前に計算したチェックサム値を用いてＭＳＳ（Ｍａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅ）以下のデータサイズを１つずつＣＰＵ処理でパケット化する。

【0003】

また、送信データのセグメントをチャンク化する処理と、チャンク化したセグメントをＩＰパケット化する処理をパケット生成オフローダが実行する技術が用いられている。この技術は、ＴＳＯ（ＴＣＰ Ｓｅｇｍｅｎｔａｔｉｏｎ Ｏｆｆｌｏａｄ）機能により実現されている。ＴＳＯ機能は、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）などのパケット生成オフローダで実施されることが一般的である。ＴＳＯ機能を用いることで、アプリケーションデータをＭＳＳ単位の送信ではなく、ＭＳＳよりも大きいデータ単位でパケット生成オフローダに送信要求を行い、ＭＳＳ単位でチャンク化させてネットワークに連続送信することが可能となる。

【0004】

ＣＰＵの高スペック化またはパケット生成オフローダの使用により、通信インタフェース（以下、ネットワークＩ／Ｆと言う）の送信処理よりもパケット生成処理が高速になることがある。この場合、ソケットＡＰＩにおいて送信されたデータが全て送信できない現象または送信エラーが発生し、アプリケーションは、ソケットＡＰＩを定期的にコールし、送信可能かどうかを確認する必要がある。

【0005】

特許文献１には、送信バッファおよびバス制御部を有する通信アダプタが開示されている。バス制御部は、バッファ管理部から送信バッファが引き渡されたことを確認した後、ＡＴＭからデータの送信が要求されると、送信バッファを使用してこれに送信データを格納する。

【先行技術文献】

【特許文献】

【0006】

【文献】特開平６－３４２４１０号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

しかしながら、ソケットＡＰＩを定期的にコールし、送信可能かどうかを確認する場合、プロトコルスタックおよびネットワークＩ／Ｆが送信可能な状態になっても、確認の時間間隔が経過しないと、送信可能な状態を検知できない。このため、パケットの送信効率が低下するおそれがある。

【0008】

また、特許文献１に開示された技術では、バス制御部は、送信バッファが引き渡されたことを確認した後、ＡＴＭからデータ送信が要求されると、送信データを送信バッファに格納し、送信データがネットワークに送出される。このため、特許文献１に開示された技術では、送信バッファが引き渡された場合においても、ＡＴＭからデータ送信が要求されないと、送信データがネットワークに送出されない。従って、ＡＴＭからのデータ送信の要求タイミングによっては、送信効率が低下するおそれがある。

【0009】

本発明は、上述の課題を鑑み、パケットの送信効率を向上させることを目的とする。

【課題を解決するための手段】

【0010】

本発明の１つの態様による通信装置は、送信データを含むパケットをバッファに格納する格納手段と、前記格納手段に格納された前記パケットを送信する送信手段と、前記送信手段によって前記パケットが送信された場合に、前記パケットの格納に用いられた前記バッファを解放する解放手段と、前記解放手段によって前記バッファが解放された場合に、前記バッファの解放を通知する通知手段と、を備える。

【発明の効果】

【0011】

本発明によれば、パケットの送信効率を向上させることができる。

【図面の簡単な説明】

【0012】

【図1】実施形態１に係る通信装置のハードウェア構成例を示すブロック図。

【図2】実施形態１に係る通信装置の機能的な構成例を示すブロック図。

【図3】実施形態１に係る通信装置のデータ送信処理を示すフローチャート。

【図4】実施形態１に係る通信装置のデータ送信完了処理を示すフローチャート。

【図5】実施形態２に係る通信装置のデータ送信処理を示すフローチャート。

【発明を実施するための形態】

【0013】

以下、添付図面を参照して本発明の実施形態を詳細に説明する。なお、以下の実施形態は本発明を限定するものではなく、また、実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。実施形態の構成は、本発明が適用される装置の仕様や各種条件（使用条件、使用環境等）によって適宜修正または変更され得る。本発明の技術的範囲は、特許請求の範囲によって確定されるのであって、以下の個別の実施形態によって限定されない。

【0014】

＜実施形態１＞
図１は、実施形態１に係る通信装置のハードウェア構成例を示すブロック図である。
図１に示す通信装置１の各機能モジュールのうち、ソフトウェアにより実現される機能については、各機能モジュールの機能を提供するためのプログラムがＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等のメモリに記憶される。そして、そのプログラムをＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）に読み出してＣＰＵが実行することにより実現される。ハードウェアにより実現される機能については、例えば、所定のコンパイラを用いることで、各機能モジュールの機能を実現するためのプログラムからＦＰＧＡ上に自動的に専用回路を生成すればよい。ＦＰＧＡとは、Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙの略である。また、ＦＰＧＡと同様にしてＧａｔｅ Ａｒｒａｙ回路を形成し、ハードウェアとして実現するようにしてもよい。また、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）により実現するようにしてもよい。なお、図１に示した機能ブロックの構成は一例であり、複数の機能ブロックが１つの機能ブロックを構成するようにしてもよいし、いずれかの機能ブロックが複数の機能を行うブロックに分かれてもよい。

【0015】

図１において、通信装置１は、ネットワーク２を介して通信相手装置３に接続されている。通信装置１は、ネットワーク２を介して通信相手装置３と通信可能である。通信装置１は、例えば、通信機能を備えるパーソナルコンピュータ、タブレット端末、スマートフォン、カメラ、プリンタまたはプロジェクタープロジェクトなどであってもよいが、これらに限定されない。

【0016】

本実施形態では、通信装置１は、通信プロトコルとしてＴＣＰ／ＩＰを使用する例を説明する。ＴＣＰ／ＩＰのプロトコル処理では、通信装置１は、送信データのパケット化および再送処理のために、ネットワークバッファ（送信バッファ）を用いる。通信装置１は、ＴＣＰ／ＩＰパケットの送信処理において、ソケットＡＰＩ ｓｅｎｄ（）によって指定された送信データ（ユーザデータ）を送信バッファに転送し、最大伝送単位ＭＴＵでチャンク化する。ＭＴＵは、Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔの略である。そして、通信装置１は、チャンク化されたデータと擬似ヘッダのチェックサムを計算し、ＴＣＰヘッダとＩＰヘッダが追加されたＴＣＰ／ＩＰパケットを生成する。伝送経路がイーサネット（登録商標）の場合、通信装置１は、これらヘッダに加えて、イーサネットヘッダが付加されたイーサネットフレームを生成し、ネットワーク２を介して通信相手装置３に送信する。

【0017】

また、パケット通信において、通信の信頼性を保証するため、送信側から送信されたパケットを受信した受信側がＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）と呼ばれる確認応答を用いる通信方式が利用されている。例えば、ＴＣＰ／ＩＰでは、送信側は、送信データをセグメントにチャンク化してパケット化して送信し、受信側は、セグメントをオクテット単位にシーケンス番号で管理し、受け取ったセグメントのシーケンス番号をＡＣＫとして応答する。

【0018】

このとき、ＴＣＰ／ＩＰのプロトコル処理では、送信側のパケット送信の度に受信側がＡＣＫを送信することによる通信速度の低下を回避するために、所定のウィンドウサイズを利用するウィンドウ制御が行われる。ＴＣＰ／ＩＰのウィンドウ制御では、受信側は、受信バッファの残りサイズをウィンドウサイズに設定したＡＣＫを送信し、送信側は、ウィンドウサイズになるまでＡＣＫを待つことなく送信データを送信することができる。さらに、ＴＣＰ／ＩＰのウィンドウ制御では、通信速度をより向上させるために、スライディングウィンドウが用いられる。スライディングウィンドウでは、受信側は、パケットを受信する度にＡＣＫを送信し、送信側は、最初のＡＣＫを受信するとウィンドウをスライドさせて、ＡＣＫを待つことなくウィンドウサイズ分のデータを連続的に送信することが可能となる。

【0019】

通信装置１は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０１、ＣＰＵ１０２、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０３、記録媒体１０５および通信部１１３を備える。また、通信装置１は、バッファ管理部１０６、データ転送部１０７、フレーム生成部１０８、パケット生成部１０９、チェックサム計算部１１０、タイマ管理部１０４、バッファ解放通知部１１１および通知設定部１１２を備える。

【0020】

ＲＡＭ１０１は、各種データを保存したり、ワークメモリ（ワークエリア）として使用される。ＲＡＭ１０１は、送受信データを格納して管理するためのメモリ領域１０１ａを有する。メモリ領域１０１ａには、送信データを含むパケットを格納するパケット格納用バッファ１０１ｂが割り当てられる。
ＣＰＵ１０２は、ＲＡＭ１０１をワークメモリとして、ＲＯＭ１０３または記録媒体１０５に格納された各種プログラムを実行することにより、通信装置１の各機能を動作させる。ＣＰＵ１０２は、シングルコアプロセッサであってもよいし、マルチコアプロセッサであってもよい。
ＲＯＭ１０３は、ＣＰＵ１０２により実行される各種プログラム等を記憶する。
記録媒体１０５は、ハードディスクまたはＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などのプログラム格納部である。

【0021】

通信部１１３は、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）モジュール１１３ａとＰＨＹ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ）モジュール１１３ｂを備え、イーサネット（商標登録）などのネットワーク２を介して通信相手装置３との通信を行う。通信装置１のデータの送受信では、ＣＰＵ１０２によりネットワークドライバが実行され、この実行に応じてＭＡＣモジュール１１３ａが制御される。なお、本実施形態では、通信部１１３は、イーサネット（登録商標）を介して通信を行う場合を例にとるが、Ｗｉ－Ｆｉなどの無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのＩＰ通信可能な媒体を介して通信を行うことも可能である。

【0022】

バッファ管理部１０６は、ヘッダまたはパケットを格納するバッファと関連付けた管理情報の取得を行う。
データ転送部１０７は、ＲＡＭ１０１に記憶されているデータを、ＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）にてフレーム生成部１０８およびパケット生成部１０９に転送する。データ転送部１０７は、例えば、ＤＭＡを行うＤＭＡコントローラである。なお、データ転送部１０７は、必ずしもＤＭＡ転送でデータを転送する必要はなく、データを転送する際にＣＰＵ１０２により制御されてもよい。

【0023】

フレーム生成部１０８は、送信する送信データのサイズを決定し、決定したサイズの送信データと、送信データに対するヘッダ情報を生成するためのヘッダ情報生成処理を行う。
パケット生成部１０９は、フレーム生成部１０８により決定されたサイズの送信データと、ヘッダ情報に基づいて、送信データのセグメント化およびヘッダの生成を行い、当該セグメントとヘッダからパケットを生成する。
チェックサム計算部１１０は、ＲＡＭ１０１に記憶されているデータに対してチェックサムを計算する。

【0024】

バッファ解放通知部１１１は、通信部１１３によるパケットの送信が完了した後、パケットの格納に用いられたパケット格納用バッファ１０１ｂの解放を通知する。例えば、ネットワークドライバの制御によって通信部１１３がネットワーク２へパケットの送信を完了した後、ネットワークドライバが、そのパケットの格納に用いられたパケット格納用バッファ１０１ｂを解放したものとする。このとき、バッファ解放通知部１１１は、ネットワークドライバによるパケット格納用バッファ１０１ｂの解放をＣＰＵ１０２に通知する。

【0025】

タイマ管理部１０４は、パケット送信に関して必要な所定時間を管理する。
通知設定部１１２は、バッッファ解放通知部１２０にパケット格納用バッファ１０１ｂの解放を通知させるか否かを設定する。通知設定部１１２は、送信アプリケーションで通知の有効と無効を切り替えることができる。例えば、ソケットＡＰＩが正常に返り値を返している場合には、通知設定部１１２は、通知を無効に設定し、バッファ解放を通知しない。一方、ソケットＡＰＩが全ての送信データを送信できていないかまたは送信エラーが発生している場合には、通知設定部１１２は、通知を有効に設定し、バッファ解放を通知する。また、ソケットＡＰＩが全ての送信データが送信できる状態に復帰した場合には、通知設定部１１２は、通知を無効に設定し、バッファ解放を通知しない。
通知設定部１１２は、プロトコルに基づいて通知の有効と無効を切り替えるようにしてもよい。例えば、ＴＣＰ／ＩＰのプロトコル処理において、再送のためのパケットを送信バッファに格納できた場合には、送信バッファからパケットを再送できるため通知を無効に設定し、バッファ解放を通知しない。
なお、以下に説明するパケットは、ＩＰ通信上で送受信されるデータの単位である。パケットの組み立て方法については、任意の方法を用いることができ、説明を省略する。

【0026】

図２は、実施形態１に係る通信装置の機能的な構成例を示すブロック図である。
図２において、通信装置１は、アプリケーション２１、プロトコルスタック２２、パケット生成部２３、通信Ｉ／Ｆ制御部２４、通信Ｉ／Ｆ２５および通知部２６を備える。プロトコルスタック２２は、ネットワークバッファ管理部２２１、セグメント処理部２２５、通信プロトコル処理部２２６、コネクション管理部２２２、ウィンドウ制御部２２３および輻輳制御部２２４を備える。パケット生成部２３は、パケット生成完了通知部２３１、データ転送部２３２、ヘッダ生成部２３３およびパケット生成部２３４を備える。通知部２６は、バッファ解放通知部２６１および通知設定部２６２を備える。

【0027】

アプリケーション２１は、ユーザアプリケーションである。アプリケーション２１により、任意のサイズの送信対象のアプリケーションデータが送信データとしてプロトコルスタック２２に入力される。

【0028】

プロトコルスタック２２は、アプリケーション２１から入力された送信データ（ＲＡＭ１０１のメモリ領域１０１ａに割り当てられている送信バッファ（不図示））を、ネットワークバッファ管理部２２１により管理する。ネットワークバッファ管理部２２１は、図１のバッファ管理部１０６に対応している。ネットワークバッファ管理部２２１は、ＲＡＭ１０１のメモリ領域１０１ａに割り当てられるバッファにヘッダまたはパケットを格納する。また、ネットワークバッファ管理部２２１は、メモリ領域１０１ａに格納されている送信データのサイズを管理する。

【0029】

コネクション管理部２２２は、通信装置１の通信コネクションを管理する。例えば、コネクション管理部２２２は、アプリケーション２１に対する通信コネクションにおけるＭＳＳ等のコネクション情報を管理する。
ウィンドウ制御部２２３は、通信Ｉ／Ｆ制御部２４を介して受信した確認応答から、ＴＣＰコネクションの送信ウィンドウサイズを取得し、管理する。

【0030】

輻輳制御部２２４は、ＴＣＰコネクションにおける輻輳制御を管理する。例えば、輻輳制御部２２４は、アプリケーション２１に対する通信コネクションにおける輻輳ウィンドウ（輻輳ウィンドウサイズ）を管理する。
セグメント処理部２２５は、ネットワークバッファ管理部２２１により管理される。セグメント処理部２２５は、送信データのサイズ、ＭＳＳ、送信ウィンドウサイズ、輻輳ウィンドウサイズ等に基づいて、送信データのサイズを決定する。このとき、送信データのサイズは、送信バッファに格納され、ＭＳＳは、コネクション管理部２２２で管理され、送信ウィンドウサイズは、ウィンドウ制御部２２３で管理され、輻輳ウィンドウサイズは、輻輳制御部２２４で管理される。
通信プロトコル処理部２２６は、ＴＣＰセグメントのＴＣＰヘッダ、ＵＤＰヘッダおよびＩＰヘッダの生成と、それに伴うチェックサム計算等の処理を行い、パケットを生成する。

【0031】

パケット生成部２３は、オフロード処理部（ハードウェア）である。オフロード処理部として、パケット処理に特化したパケット生成オフローダを用いることができる。パケット生成オフローダは、ＴＳＯ機能を用いることで、ＭＳＳよりも大きいデータ単位で送信要求されたアプリケーションデータをＭＳＳ単位でチャンク化し、ネットワークへの連続送信を可能とする。パケット生成完了通知部２３１は、データ転送部２３２とヘッダ生成部２３３とパケット生成部２３４によるパケット化処理の完了通知を、割り込みで行うかポーリングで行うかの選択をする。
データ転送部２３２は、図１のデータ転送部１０７に対応し、データのチャンク機能、チェックサム計算機能および転送機能を持つ。チャンク機能は、送信データをデータ転送する際、所定の単位（例えばＭＳＳ単位）にチャンク化する。チェックサム計算機能は、図１のチェックサム計算部１１０に対応する。チェックサム計算機能は、所定の単位にチャンク化した各データに対するチェックサム計算を行う。

【0032】

ヘッダ生成部２３３は、所定のヘッダ情報に基づいて、ネットワークバッファ管理部２２１が管理している送信バッファを用いて、ＴＣＰ／ＩＰヘッダ、ＵＤＰ／ＩＰヘッダおよびイーサネットヘッダを生成する。
パケット生成部２３４は、データ転送部２３２とヘッダ生成部２３３から出力されたデータを用いて、パケット化処理を行う。

【0033】

本実施形態では、セグメント処理部２２５により決定された送信データのサイズに応じて、通信プロトコル処理部２２６またはパケット生成部２３が、ネットワークバッファ管理部２２１が管理する送信バッファを用いてパケットを生成する。パケットの生成手法については、図３を用いて後述する。

【0034】

通信プロトコル処理部２２６またはパケット生成部２３により生成されたパケットは、通信Ｉ／Ｆ制御部２４に入力される。通信Ｉ／Ｆ制御部２４は、プロトコルスタック２２と通信Ｉ／Ｆ２５との間でデータおよび情報のやり取りを行う。通信Ｉ／Ｆ２５は、図１のＭＡＣモジュール１１３ａおよびＰＨＹモジュール１１３ｂに対応し、ネットワーク２を介した通信を行う。パケットの送信は、タイマ管理部１０４により一定時間以上経過したことが通知された場合に行われてもよい。

【0035】

バッファ解放通知部２６１は、パケットが格納されているバッファをネットワークバッファ管理部２２１が解放する際に、そのバッファの解放をアプリケーション２１に通知する。このとき、バッファ解放通知部２６１は、通信Ｉ／Ｆ制御部２４によって通信Ｉ／Ｆ２５からネットワーク２へパケットが送信された後に、パケットが格納されているバッファの解放をアプリケーション２１に通知する。バッファ解放通知部２６１は、図１のバッファ解放通知部１１１に対応する。

【0036】

通知設定部２６２は、バッファ解放通知部２６１による通知を無効か有効かに設定する。通知設定部２６２の処理をコールバック関数で実現し、アプリケーション２１により通知が有効に登録された場合にバッファ解放を通知し、通知が有効に登録されてない場合にバッファ解放を通知しないようにしてもよい。通知設定部２６２は、図１の通知設定部１１２に対応する。

【0037】

次に、図３および図４を参照し、図１の通信装置１により行われるデータ送信処理を説明する。図３では、ソケットＡＰＩ ｓｅｎｄ（）によるデータ送信処理を例にとる。なお、ｓｅｎｄｔｏ（）、ｓｅｎｄｍｓｇ（）、ｓｅｎｄｍｍｓｇ（）によるデータ送信処理の場合も、図３と同様の処理を用いることができる。図４では、ソケットＡＰＩ ｓｅｎｄ（）によるデータ送信処理が完了後、パケット格納用バッファの解放通知処理を説明する。
本実施形態では、ウィンドウサイズを使用するプロトコルのデータ送信処理において、ネットワーク２へパケットの送信完了後、アプリケーション２１へパケット格納用バッファ１０１ｂの解放通知を行う。

【0038】

なお、図３および図４の各ステップは、通信装置１の記憶部に記憶されたプログラムをＣＰＵ１０２読み出し、実行することで実現される。また、図３および図４に示すフローチャートの少なくとも一部をハードウェアにより実現してもよい。ハードウェアにより実現する場合、例えば、所定のコンパイラを用いることで、各ステップを実現するためのプログラムからＦＰＧＡ上に自動的に専用回路を生成すればよい。また、ＦＰＧＡと同様にしてＧａｔｅ Ａｒｒａｙ回路を形成し、ハードウェアとして実現するようにしてもよい。また、ＡＳＩＣにより実現するようにしてもよい。

【0039】

この場合、図３および図４に示すフローチャートにおける各ブロックは、ハードウェアブロックとみなすことができる。なお、複数のブロックをまとめて１つのハードウェアブロックとして構成してもよく、１つのブロックを複数のハードウェアブロックとして構成してもよい。

【0040】

図３のＳ１において、図１のＣＰＵ１０２は、ソケットＡＰＩの呼び出しを行う。より詳しくは、ＣＰＵ１０２は、ＲＯＭ１０３に格納されている所定のプログラムを実行することに応じて、図２のアプリケーション２１は、ｓｅｎｄ（）を呼び出す。
ＣＰＵ１０２は、ｓｅｎｄ（）を呼び出すと、Ｓ２において、ｓｅｎｄ（）に指定された値が正しいかどうかを判定する。Ｓ２の判定結果がＮｏの場合、Ｓ３に処理を進める。Ｓ２の判定結果がＹｅｓの場合、Ｓ４に処理を進める。

【0041】

Ｓ３において、ＣＰＵ１０２は、指定された値によりエラー番号へＥＡＬＲＥＡＤＹまたはＥＮＯＴＣＯＮＮまたはＥＦＡＵＬＴを設定し、－１を返り値にして、処理を終了する。
Ｓ４において、データ転送部１０７は、不図示のユーザバッファからのデータ転送先であるＲＡＭ１０１内の送信バッファへ送信データを転送し、送信データのチャンク化と、送信バッファへの送信データの格納のため、送信データ用バッファを取得する。データ転送部１０７は、ゼロコピーが指定された場合は、送信データ管理バッファを指定し、ゼロコピーが指定されない場合は、送信データ用バッファを指定し、Ｓ５に処理を進める。

【0042】

Ｓ５において、データ転送部１０７は、指定したバッファが１つでも確保できたかどうかを判定する。Ｓ５の判定結果がＮｏの場合、Ｓ６に処理を進める。Ｓ５の判定結果がＹｅｓの場合、Ｓ７に処理を進める。
Ｓ６において、データ転送部１０７は、指定したバッファが１つも確保できていない場合、エラー番号へＥＮＯＭＥＭを設定し、－１を返り値にし、Ｓ１９に処理を進める。

【0043】

Ｓ７において、データ転送部１０７は、不図示のユーザバッファからのデータ転送先であるＲＡＭ１０１内の送信バッファへ送信データを転送し、チャンク化を行い、送信バッファに格納する。なお、データ転送部１０７は、送信データの格納場所を送信バッファへ格納してもよい。ゼロコピーでｓｅｎｄ（）が呼び出された場合は、データ転送部１０７は、ユーザバッファの格納場所の情報を送信バッファへ転送する。
セグメント処理部２２５は、送信バッファに格納されている送信データのサイズが、ウィンドウ制御部２２３により管理されている送信ウィンドウサイズを超えるか確認する。セグメント処理部２２５は、超えている場合は送信バッファに格納されている送信データのサイズを、送信データのサイズとして決定し、超えていない場合は送信ウィンドウサイズを送信データのサイズとして決定し、Ｓ８に処理を進める。

【0044】

Ｓ８において、フレーム生成部１０８は、ＴＣＰ／ＩＰヘッダとイーサネットヘッダを生成するための情報としてヘッダ情報を生成し、Ｓ９に処理を進める。
Ｓ９において、パケット生成部１０９は、パケットを格納するため、パケット格納用バッファを１つでも確保できたかどうかを判定する。Ｓ９の判定結果がＮｏの場合、Ｓ１０に処理を進める。Ｓ９の判定結果がＹｅｓの場合、Ｓ１１に処理を進める。
Ｓ１０において、パケット生成部１０９は、指定したバッファが１つも確保できていない場合は、エラー番号へＥＮＯＭＥＭを設定し、－１を返り値にして、Ｓ１９に処理を進める。

【0045】

Ｓ１１において、パケット生成にパケット生成オフローダを使用する場合、プロトコルスタック２２は、パケット生成部２３にパケット生成のデータを設定し実行を行う。このとき、Ｓ１１において、データ転送部２３２は、送信データがチャンク化されていない場合にはチャンク化とチェックサム計算を行い、チャンク化されている場合にはチェックサム計算を行う。次に、Ｓ１１において、ヘッダ生成部２３３は、Ｓ８で生成されたヘッダ情報を使用し、送信データがＭＳＳ単位にチャンク化されて得られる各セグメントに対してＴＣＰ／ＩＰヘッダとイーサネットヘッダを（自動）生成する。ｓｅｎｄ（）が呼び出された際に送信データがＲＡＭ１０１内の送信バッファに転送された場合には、パケット生成によりイーサネットフレーム化される。次に、Ｓ１１において、パケット生成部２３４は、データ転送部２３２とヘッダ生成部２３３から出力されたデータを用いて、パケット化処理を行う。

【0046】

Ｓ１２において、パケット生成完了通知部２３１は、Ｓ１１で実行されたパケット生成オフローダの処理が完了したかどうかを判定する。Ｓ１２の判定結果がＮｏの場合、Ｓ１２に処理を繰り返し、処理が終了するのを待つ。Ｓ１２の判定結果がＹｅｓの場合、Ｓ１３に処理を進める。

【0047】

Ｓ１３において、ＣＰＵ１０１は、パケット生成によりイーサネットフレーム化されたパケットをネットワークドライバが送信可能かどうかを判定する。Ｓ１３の判定結果がＮｏの場合、Ｓ１４に処理を進める。Ｓ１３の判定結果がＹｅｓの場合、Ｓ１７に処理を進める。
Ｓ１４において、ＣＰＵ１０１は、ネットワークドライバが送信可能になるまで、送信キューにパケットの追加が可能かどうかを判定する。Ｓ１４の判定結果がＮｏの場合、Ｓ１５に処理を進める。Ｓ１４の判定結果がＹｅｓの場合、Ｓ１６に処理を進める。

【0048】

Ｓ１５において、ＣＰＵ１０１は、送信キューにパケットの追加が不可の場合はエラー番号へＥＮＯＳＰＣまたはＥＮＯＢＵＦＳを設定し、－１を返り値にして、Ｓ１９に処理を進める。
Ｓ１６において、ＣＰＵ１０１は、送信キューにパケットの追加が可能の場合は送信キューにパケットを追加し、Ｓ１９に処理を進める。
Ｓ１７において、通信プロトコル処理部２２６は、ネットワークドライバによりイーサネットフレームを通信Ｉ／Ｆ制御部２４に送信し、Ｓ１８に処理を進める。

【0049】

Ｓ１８において、ＣＰＵ１０１は、送信すべき全てのパケットについてパケット生成処理が完了しているか否かを判定する。送信すべき全てのパケットのパケット生成処理が全て完了していない場合は（Ｓ１８：Ｙｅｓ）、Ｓ１３に戻る。送信すべき全てのパケットのパケット生成処理が全て完了した場合は（Ｓ１８：Ｎｏ）、Ｓ１９に処理を進める。

【0050】

Ｓ１９において、ＣＰＵ１０１は、送信すべき全てのパケット（Ｓ１６の送信キューにキューイングされたパケット）が送信されたか、かつ送信エラー（Ｓ６、Ｓ１０およびＳ１５の送信エラーが該当）が発生していないかどうかを判定する。送信すべき全てのパケットが送信され、かつ送信エラーが発生していない場合は（Ｓ１９：Ｙｅｓ）、Ｓ２０に処理を進める。送信すべき全てのパケットが送信されていないまたは送信エラーが発生している場合は（Ｓ１９：Ｎｏ）、Ｓ２１に処理を進める。
Ｓ２０において、アプリケーション２１は、送信データがあるか判定する。送信データがある場合は（Ｓ２０：Ｙｅｓ）、図３のデータ送信処理の開始へ戻る。送信データがない場合は（Ｓ２０：Ｎｏ）、データ送信処理を終了する。

【0051】

Ｓ２１において、通知設定部２６２は、バッファ解放の通知を有効（ＯＮ）に設定するか否かを判定する。通知を有効にしない設定は、アプリケーション２１により、バッファ解放通知部２６１に対して、バッファ解放の通知を設定するコールバック関数が未登録とされることで実現する。通知を有効にしない設定は、アプリケーション２１により、コールバック関数で通知を無効にする処理で実現してもよい。通知を有効にしない設定では（Ｓ２１：Ｎｏ）、データ送信処理の開始へ戻る。通知を有効にする設定では（Ｓ２１：Ｙｅｓ）、Ｓ２２に処理を進める。
Ｓ２２において、バッファ解放通知部２６１は、パケットを格納しているバッファ解放の通知待ちを行う。

【0052】

ネットワークドライバがイーサネットフレームを通信Ｉ／Ｆ制御部２４に送信した後、通信部１１３は、図４の送信完了割り込み処理を開始する。
図４において、Ｓ２３１では、ネットワークドライバは、パケットを格納していたバッファを全て解放し、Ｓ２３２に処理を進める。

【0053】

Ｓ２３２において、パケットを格納していたバッファが全て解放されると、バッファ解放通知部２６１は、バッファ解放通知機能がＯＮの場合、アプリケーション２１へバッファ解放を通知し、Ｓ２３３に処理を進める。なお、バッファ解放通知部２６１は、バッファ解放通知機能がＯＦＦのときは、アプリケーション２１へバッファ解放を通知しない。
Ｓ２３３において、プロトコルスタック２２は、送信キューにキューイングされたパケットがあるか否かを判定する。送信キューに送信するパケットが存在する場合は（Ｓ２３３：Ｙｅｓ）、Ｓ２３４に処理を進める。送信キューに送信するパケットが存在しない場合は（Ｓ２３３：Ｎｏ）、Ｓ２３５に処理を進める。

【0054】

Ｓ２３４において、通信Ｉ／Ｆ制御部２４は、バッファ解放通知機能がＯＮの場合、図３のＳ２４の送信完了通知待ちに対して通信プロトコル処理部２２６へ送信完了を通知し、Ｓ２３５に処理を進める。
Ｓ２３５において、バッファ解放通知部２６１は、バッファ解放通知機能がＯＮの場合、図３のＳ２２のバッファ解放通知待ちに対してアプリケーション２１へバッファ解放を通知し、送信完了割り込み処理を終了する。

【0055】

図３のＳ２４の送信完了通知待ちでは、図４のＳ２３４からの送信完了の通知を受けると、通信プロトコル処理部２２６は、送信処理を開始し、Ｓ１３に処理を進める。
図３のＳ２２のバッファ解放通知待ちでは、図４のＳ２３５からのバッファ解放の通知を受けると、アプリケーション２１は、処理を開始し、Ｓ２３に処理を進める。
Ｓ２３において、通知設定部２６２は、バッファ解放の通知を無効（ＯＦＦ）に設定し、データ送信処理の開始へ戻る。

【0056】

以上説明したように、本実施形態によれば、送信データのセグメント化とＴＣＰ／ＩＰヘッダの生成とイーサネットフレーム化を実施するパケット生成処理を行い、ネットワークドライバがイーサネットフレームを通信Ｉ／Ｆ制御部２４に送信する。このとき、バッファ解放通知部は、アプリケーションへバッファ解放を通知することで、プロトコルスタックおよびネットワークドライバが送信可能な状態になり次第、アプリケーションが送信データの送信の要求を再開できる。このため、アプリケーションは、ソケットＡＰＩにて送信されたデータが全て送信できない現象または送信エラーが発生した場合においても、ソケットＡＰＩを定期的にコールし、送信可能かどうかを確認する必要がなくなる。この結果、アプリケーションは、送信可能かどうかの確認の時間間隔が経過する前に、送信データの送信処理を開始でき、通信装置１のパケットの送信効率を向上させることができる。
また、上述した実施形態によれば、バッファ解放の完了通知を状況に応じて有効または無効を設定し、有効の場合にアプリケーションがバッファ解放の完了通知を受けることができる。このため、パケットの正常に送信されている場合には、バッファ解放の完了通知をやり取りするためにかかる負荷を軽減することができ、送信処理の効率を改善することができる。
なお、パケット生成部２３のハードウェアによる処理をソフトウェアで実行した場合においても、本実施形態を適用することができる。

【0057】

なお、本実施形態では、通信Ｉ／Ｆ２５が１つの場合を例にとったが、通信Ｉ／Ｆが複数ある場合にも本実施形態を適用することができる。
また、上述した実施形態では、通知部２６のバッファ解放通知部２６１と通知設定部２６２の通知処理はコールバック関数を使用したが、オペレーティングシステム（ＯＳ）のシステムコール等の他の方法を使用することも可能である。

【0058】

＜実施形態２＞
以下、図１、図２、図４および図５を用いて、実施形態２の通信装置による通信処理を説明する。なお、実施形態２において、実施形態１と同様の構成および機能については、同一符号を付して、その詳細な説明は省略し、異なる点についてのみ説明する。実施形態１との相違は、実施形態２では、通信プロトコルとしてＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を使用する。このとき、図２の通信プロトコル処理部２２６は、ＵＤＰ／ＩＰヘッダおよびＵＤＰ／ＩＰパケットを生成する。

【0059】

ＵＤＰは、ＴＣＰ／ＩＰと異なり、ハンドシェイクを省いたコネクションレスのプロトコルである。ＵＤＰのデータ転送は、送受信されるデータの順序性の保証がなく、送信先からの確認応答がないため信頼性を保証されない。
しかし、ＵＤＰは、通信の処理にかかるコストが少ないため、データが途中で抜け落ちても問題が少ないストリーミングおよび通信処理のオーバーヘッドの軽減が求められるリアルタイムシステム通信で使われることがある。このとき、図２の通知設定部２６２は、パケットを送信する通信インタフェースの種類により、バッファ解放の通知を無効か有効かに設定することができる。

【0060】

図５は、実施形態２に係る通信装置のデータ送信処理を示すフローチャートである。
図５の処理では、ソケットＡＰＩによる複数データのデータ送信処理を想定している。複数データのデータ送信処理は、例えば、ｓｅｎｄｍｍｍｓｇ（）によるデータ送信である。
図５の処理では、複数の送信データを一度にソケットＡＰＩで指定するデータ送信処理において、データ送信処理が完了後、パケット格納用バッファの解放通知処理を行う場合を例にとる。

【0061】

図５の処理では、図３の処理のＳ２１およびＳ２３の代わりにＳ５１およびＳ５３を実行し、それ以外の処理は、図３の処理と同様である。
Ｓ５１において、図２の通知設定部２６２は、通信インタフェースが有線ＬＡＮの場合、通知を有効に設定するか否かを判定する。通知を有効にしない設定は、アプリケーション２１により、バッファ解放通知部２６１に対して、バッファ解放の通知を設定するコールバック関数が未登録とされることで実現する。通知を有効にしない設定は、コールバック関数で送信に使用する通信インタフェースが有線ＬＡＮではない場合に通知を無効にする処理で実現してもよい。通知を有効にしない設定では（Ｓ５１：Ｎｏ）、データ送信処理の開始へ戻る。通知を有効にする設定では（Ｓ５１：Ｙｅｓ）、Ｓ２２に処理を進める。
Ｓ５３において、通知設定部２６２は、通信インタフェースが有線ＬＡＮの場合、通知を無効に設定し、データ送信処理の開始へ戻る。

【0062】

以上説明したように、本実施形態によれば、送信データのセグメント化とＵＤＰ／ＩＰヘッダ生成とイーサネットフレーム化を実施するパケット生成処理を行い、ネットワークドライバがイーサネットフレームを通信Ｉ／Ｆ制御部２４に送信する。このとき、バッファ解放通知部は、アプリケーションへバッファ解放を通知することで、プロトコルスタックおよびネットワークドライバが送信可能な状態になり次第、アプリケーションが送信データの送信の要求を再開できる。このため、通信プロトコルとしてＵＤＰを使用した場合においても、通信装置１のパケットの送信効率を向上させることができる。
また、本実施形態によれば、バッファ解放の完了通知を状況に応じて有効または無効を設定し、有効の場合にアプリケーションが完了通知を受けることで、送信処理の効率を改善することができる。
なお、パケット生成部２３のハードウェアによる処理をソフトウェアで実行した場合においても、本実施形態を適用することができる。

【0063】

なお、本実施形態では、通信Ｉ／Ｆ２５が１つの場合を例にとったが、通信Ｉ／Ｆが複数ある場合にも本実施形態を適用することができる。
また、上述した実施形態では、通知部２６のバッファ解放通知部２６１と通知設定部２６２の通知処理はコールバック関数を使用したが、オペレーティングシステムのシステムコール等の他の方法を使用することも可能である。

【0064】

また、上述した実施形態では、Ｓ５１およびＳ５３の処理において、通信インタフェースが有線ＬＡＮの場合を例にとったが、通信インタフェースが無線ＬＡＮの場合であってもよい。
また、通信インタフェースが有線ＬＡＮまたは無線ＬＡＮに限らず、それ以外の通信インタフェースの種類に基づいて、バッファの解放を通知させるか否かを設定するようにしてもよい。さらに、ＴＣＰおよびＵＤＰなどのプロトコルの種類に基づいて、バッファの解放を通知させるか否かを設定するようにしてもよい。
また、上述した実施形態では、Ｓ５１の判定条件において、「通信インタフェースが有線ＬＡＮ」の場合を例にとった。これ以外にも、「任意のプロトコル」、「任意のポート番号」、「任意のコネクション」、「任意の宛先ＩＰアドレス」または「任意の送信元ＩＰアドレス」の場合であってもよい。

【0065】

＜その他の実施形態＞

【0066】

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワークまたは記憶媒体を介してシステムまたは装置に供給してもよい。そして、上述の実施形態の１以上の機能は、そのシステムまたは装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。

【符号の説明】

【0067】

１：通信装置、３：通信相手装、１０２：ＣＰＵ、１０７：データ転送部、１０８：フレーム生成部、２３、１０９、２３４：パケット生成部、１１３ａ：ＭＡＣモジュール置、２２：プロトコルスタック、２３１：パケット生成完了通知部、２３２：データ転送部、２６０：通知部、２６１：バッファ解放通知部、２６２：通知設定部

【図1】

【図2】

【図3】

【図4】

【図5】