JP2010041498A - パケット作成装置及びパケット作成方法 - Google Patents

Abstract

【課題】パケット処理時に用いられるチェックサム演算に整合性を持たせたまま、チェックサム算出の為にかかる遅延をなくす。
【解決手段】ヘッダのチェックサムフィールドに予め定められた値を入れ、ヘッダに続くペイロードの末尾にチェックサムデータを付与するパケット作成手段を有することによってパケット処理時に用いられるチェックサム演算に整合性を持たせたまま、チェックサム算出の為にかかる遅延をなくすことができる。
【選択図】図２

Description

本発明は、パケット作成装置及びパケット作成方法に関する。

インターネットで用いられる最も一般的なネットワークプロトコルであるＴＣＰ／ＩＰやＵＤＰ／ＩＰにおけるプロトコルの実装はＩＥＴＦのＲＦＣで事実上の標準（非特許文献１）が定められている。
ＴＣＰやＵＤＰ等のトランスポートプロトコルではヘッダ部（ヘッダ）とペイロード部（ペイロード）とを利用したチェックサムをヘッダに付加することでトランスポートレイヤにおける誤り検出を行っている。

ＩＰ層ではＩＰヘッダのみのチェックサム、ＭＡＣ層ではＭＡＣフレーム全体にわたりＣＲＣ−３２を算出してフレーム末尾に付加することで各レイヤでの誤り検出を行っている。
ＵＤＰは、ＲＦＣ７６８（非特許文献１）で定義されている。
ＵＤＰの構造は、送信側のアプリケーションが示す１６ｂｉｔのポート番号、受信側の１６ｂｉｔのポート番号に続き、ＵＤＰのデータ長、ＵＤＰチェックサム、そしてペイロードからなるＵＤＰデータグラムでＵＤＰパケットが構成されている。

ＵＤＰの送信時において、ＵＤＰヘッダはチェックサムを除いて既知である。
ＳｏｕｒｃｅＰｏｒｔ、ＤｅｓｔｉｎａｔｉｏｎＰｏｒｔ、ＵＤＰ Ｄａｔａ ＬｅｎｇｔｈがＵＤＰヘッダ作成部に渡され、ＵＤＰヘッダ作成部はＵＤＰチェックサムを算出するためにＵＤＰ擬似ヘッダを作成する。
チェックサムを計算する領域は、ＵＤＰではＵＤＰの領域に加えて、ｓｏｕｒｃｅ、ｄｅｓｔｉｎａｔｉｏｎのＩＰアドレス、プロトコル番号、データ長からなる擬似ヘッダを含める。
ＲＦＣ１０７１では効率的なチェックサムの算出方法について述べられており、その方法を以下に示す。
１．隣接しているオクテットから１６ｂｉｔの整数を構成し、これらの１の補数和を算出する。
２．チェックサムを生成するために、チェックサムフィールドはクリアされ、１６ｂｉｔの１の補数和が計算され、この合計の１の補数がチェックサムフィールドに挿入される。
３．チェックサムの検証には、チェックサムフィールドを含めて１の補数和が計算される。結果、全てのｂｉｔが"１"であればチェックは成功である。

チェックサムでは常に１の補数和の１の補数が用いられている。
そのため受信側、即ち検証側では擬似ヘッダを作成し、チェックサムフィールドを含めた全てのフィールドに対して１の補数和を計算し、全てのビットが立った状態になるかどうかを検出すればよい。
実際のアプリケーションにおいてＵＤＰプロトコルは基本的にコネクションレスの通信であるのでＵＤＰパケットの送信時においては相手先ポート番号と相手先ＩＰアドレストとを指定する場合が多く、この場合擬似ヘッダ作成のための情報は既に与えられている。

ＵＤＰでコネクション型の通信を行う場合、コネクションを開設したときにデータベースに登録した送信Ｐｏｒｔ番号−送信ＩＰアドレス−受信Ｐｏｒｔ番号−受信ＩＰアドレスの組を登録する。
ＵＤＰパケット送信時に送信Ｐｏｒｔ番号−受信Ｐｏｒｔ番号が知らされるので、この情報を用いてデータベースからＩＰアドレスの情報を検索して読み出し、同時に渡されたＵＤＰパケット長と共に擬似ヘッダを作成する。

ここで図７の上段にみられる擬似ヘッダの構造から中段に示すように一部フィールドの順番を入れ替えてＩＰヘッダの構造と互換性をとれる構造にしておく。図７は、従来のＵＤＰパケットフォーマット、ＩＰパケットフォーマット、チェックサム算出範囲を示した図である。
即ち、｛ＳｏｕｒｃｅＩＰ、ＤｅｓｔＩＰ、０、Ｐｒｏｔｏｃｏｌ、ＵＤＰ ｌｅｎｇｔｈ｝の順番を｛０、Ｐｒｏｔｏｃｏｌ、ＵＤＰ ｌｅｎｇｔｈ、ＳｏｕｒｃｅＩＰ、Ｄｅｓｔ ＩＰ｝の順に並べ替え、更に８Ｏｃｔｅｄ分の"０"スペースを空けておく。
このように擬似ヘッダを作成する際に同時にＩＰヘッダの一部分とすることで後の処理を簡略化することができる。

当然のことながらチェックサムの演算の妨げにならないように擬似ヘッダに関係のないフィールドは"０"で埋めておく。
チェックサム演算が終了するとＩＰヘッダ処理部に渡される。
擬似ヘッダ作成に使用したＩＰアドレスのフィールドはそのまま使用できるためＩＰヘッダ作成時にはその処理は省略することができる。
この構造は受信時のチェックサム検証にも利用することができる。
ＩＰ処理が終わりＵＤＰ処理フローに渡されたＵＤＰパケットは同時にＩＰヘッダが渡される。

ＩＰヘッダのＶｅｒフィールドからＴＴＬフィールドまでを削除してＩＰチェックサムフィールドをＵＤＰ ｌｅｎｇｔｈに変換するだけでそのまま擬似ヘッダとして利用できる。
ＵＤＰチェックサム検証においては擬似ヘッダを含めたペイロード末尾までのチェックサム演算の結果が"ＦＦＦＦ"となれば正当なＵＤＰパケットとして処理される。"ＦＦＦＦ"以外の演算結果になった場合はその受信パケットはそのまま捨てられる。
なお、図８は、従来のＵＤＰ擬似ヘッダを用いてＩＰヘッダを作成する一例を示す図である。また、図９は、従来のＵＤＰパケットが送信されるまでの処理の一例を示す図である。

ＴＣＰはＲＦＣ７９３（非特許文献２）で定義されており、ＩＰ層を含めてそのフォーマットを図１０に示す。図１０は、従来のＴＣＰパケットフォーマット、ＩＰパケットフォーマット、チェックサム算出範囲を示した図である。
ＵＤＰのヘッダ構造と比較するとフィールド数は増加しているが先頭３２ｂｉｔからなる送信ポート番号、受信ポート番号の並びは同一となっている。
更にＴＣＰ／ＩＰパケットの送受信においてもＵＤＰの処理と同様にＴＣＰ擬似ヘッダが作成され、その構造はＵＤＰ擬似ヘッダと同じであるため、チェックサムシーケンスはＵＤＰチェックサム処理と同じ処理が実行される。

［ｏｎｌｎｅ］、１９８０年８月２８日、［平成２０年７月２８日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ０７６８．ｔｘｔ＞ ［ｏｎｌｎｅ］、１９８１年９月、［平成２０年７月２８日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ０７９３．ｔｘｔ＞

しかしながら、従来のチェックサム算出方法では、ＩＰ層の一部の処理まで行いながらも、チェックサムの算出のためには６４Ｂｙｔｅ〜１５００Ｂｙｔｅからなるペイロードについても全てチェックサム算出の対象としている。
このため、全てのパケットデータを受信しきらなければ後段の処理に移行できないという問題点があった。

本発明はこのような問題点に鑑みなされたもので、パケット処理時に用いられるチェックサム演算に整合性を持たせたまま、チェックサム算出の為にかかる遅延をなくすことを目的とする。

そこで、本発明のパケット作成装置は、ヘッダのチェックサムフィールドに予め定められた値を入れ、ヘッダに続くペイロードの末尾にチェックサムデータを付与するパケット作成手段を有することを特徴とする。

係る構成とすることで、パケット処理時に用いられるチェックサム演算に整合性を持たせたまま、チェックサム算出の為にかかる遅延をなくすことができる。

また、本発明は、パケット作成方法、プログラム及び記憶媒体としてもよい。

本発明によれば、パケット処理時に用いられるチェックサム演算に整合性を持たせたまま、チェックサム算出の為にかかる遅延をなくすことができる。

以下、本発明の実施形態について図面に基づいて説明する。

＜実施形態１＞
図１は、パケット作成装置のハードウェア構成の一例を示す図である。ＣＰＵ（中央演算装置）１０００は、実施形態で説明する情報処理（情報処理方法）をプログラムに従って実行する。プログラム メモリ１０１０には、ＣＰＵ１０００により実行されるプログラムが記憶されている。ＲＡＭ１０２０は、ＣＰＵ１０００によるプログラムの実行時に、各種情報を一時的に記憶するためのメモリである。ハードディスク１０３０は、画像ファイル等を保存するための記憶媒体（記録媒体）である。なお、プログラムは、ハードディスク１０３０に記憶されていてもよい。バス１１００は、これら各部とＣＰＵ１０００とを接続している制御バス・データバスである。なお、パケット作成装置は、これ以外にもキーボードやポインティング デバイス等の入力機器や、表示デバイス等を備えていてもよい。
ＣＰＵ１０００が、プログラムに基づき処理を実行することによって、例えば後述する機能構成の全て又は一部、及び後述するフローチャート等が実現される。

＜第一の実施の形態＞
図２は、パケット作成装置の送信部の構成例を示した図である。
図２において、１０１は、バイトストリーム又はデータグラムの送受信を行っているアプリケーション（Ａｐｐｌｉｃａｔｉｏｎ）である。１０２は、アプリケーションメモリ（Ａｐｐｌｉｃａｔｉｏｎ Ｍｅｍｏｒｙ）である。
１０３はアプリケーション１０１の指示を受けて送信ＩＰパケットの制御を行う送信制御部（Ｔｘ Ｃｏｎｔｒｏｌｌｅｒ）である。
１０４は、送信制御部１０３の指示を受けて送出するパケットのペイロード長を算出する送出長算出部（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｅｎｇｔｈ）である。１０５は、各種ＤＭＡの制御を行うＤＭＡ制御部（ＤＭＡＣ）である。１０６は、送受信メモリ（Ｔｘ／Ｒｘ Ｍｅｍｏｒｙ）である。１０７は、１の補数和を計算する補数算出部（ｃｏｍｐｌｅｍｅｎｔ ｓｕｍ）である。

１０８は、ヘッダとペイロードとを合成してＩＰパケットとしてのフォーマットを作成するＩＰ送信部（ＩＰ Ｓｅｎｄ）である。
１０９は、補数算出部１０７で算出した１の補数和からＴＣＰ（ＵＤＰ）チェックサムの調整を行うチェックサムデータをＩＰパケットの最後に付加する送出パケット合成部（Ｃｋｓｕｍｄａｔａ Ｓｕｐｐｌｅｍｅｎｔ）である。
１１０は、ＭＡＣ層の制御を行うＭＡＣ部（ＭＡＣ）である。１１１は、物理層への変復調を行うＰＨＹ部（ＰＨＹ）である。１１２は、ＩＰ受信部（ＩＰ Ｒｅｃｅｉｖｅ）である。１１３は、ＩＰヘッダ送出部（ＩＰ Ｈｅａｄｅｒ Ｓｅｎｄ）である。
１１４は、ＴＣＰの特にＡｃｋフラグが立っているパケットを解析するＴＣＰ受信部（ＴＣＰ（Ａｃｋ）Ｒｅｃｅｉｖｅ）である。１１５は、ＴＣＰ（ＵＤＰ）ヘッダ送出部（ＴＣＰ（ＵＤＰ）Ｈｅａｄｅｒ Ｓｅｎｄ）である。ＴＣＰ（ＵＤＰ）ヘッダ送出部１１５は、ＴＣＰ／ＩＰヘッダ、ＵＤＰ／ＩＰヘッダを送出する。

図３は、図２のパケット作成装置の送信部に対応する受信部の構成例を示した図である。
図３において、２０３は、受信制御部（Ｒｘ Ｃｏｎｔｒｏｌｌｅｒ）である。２０４は、受信したパケット長を通知する受信長検出部（Ｒｅｃｅｉｖｅ Ｌｅｎｇｔｈ）である。２０７は、チェックサム検証部（Ｃｋｓｕｍｄａｔａ Ｖｅｒｉｆｙ ａｎｄ Ｒｅｍｏｖｅ）である。２０８は、ＩＰ受信部（ＩＰ Ｒｅｃｅｉｖｅ Ｄｅｆａｇｍｅｎｔ）である。２１２は、ＩＰ送信部（ＩＰ Ｓｅｎｄ）である。２１３は、ＩＰ制御部（ＩＰ Ｃｏｎｔｒｏｌｌｅｒ）である。
２１４は、ＴＣＰヘッダ特に受信通知を出力するためにＡｃｋフラグが立ったＴＣＰパケットを送出する部（ＴＣＰ（Ａｃｋ）Ｓｅｎｄ）である。２１５は、ＴＣＰヘッダを解析してメモリ上に再合成するための制御を行うＴＣＰヘッダ解析部（ＴＣＰ（ＵＤＰ） Ｒｅｃｅｉｖｅ）である。

次に、パケット作成装置におけるデータの送受信動作を順に追って説明する。
まず、アプリケーション１０１は、ネットワークに送出するデータがあることを送信制御部１０３に送信要求信号（Ｔｘ＿Ｒｅｑｕｅｓｔ）をアクティブして通知すると共に、ソケットタイプ、送信データ長、アドレス情報を指定する。
ここでいうソケットタイプとはＳＯＣＫ＿ＳＴＲＥＡＭ、ＳＯＣＫ＿ＤＧＲＡＭ、ＳＯＣＫ＿ＲＡＷの３種類がある。
ＳＯＣＫ＿ＳＴＲＥＡＭは、ＴＣＰを用いてデータを送ることを示し、ＳＯＣＫ＿ＤＧＲＡＭは、ＵＤＰ、ＳＯＣＫ＿ＲＡＷはＩＰパケットの状態で送信要求されたデータを処理する。
送信データ長は、アプリケーションメモリに格納された送信要求するデータの長さである。アドレス情報とは、送信先のＰｏｒｔ番号やＩＰアドレス情報等を示す。

本実施形態の説明においては１２００ＢｙｔｅのデータがＵＤＰパケットで送信先のＰｏｒｔ情報、ＩＰアドレス情報等を指定して要求されたものとして説明を続行する。
ＵＤＰパケットの送信要求を受け付けた送信制御部１０３は、送球されたデータ長とＭＴＵ（Ｍａｘｉｍｕｎ Ｔｒａｎｓｆｅｒ Ｕｎｉｔ）とを比較する。
送信制御部１０３は、最終的に生成されたパケットがＭＡＣに送信できるパケット長以下になるかを判断する。
一般的に１０ＢＡＳＥ−Ｔや１００ＢＡＳＥ−Ｔの場合には１５００ＢｙｔｅがＭＴＵとして使用されることが多いのでＭＴＵからＵＤＰヘッダ長、ＩＰヘッダ長、ＭＡＣヘッダ長を減算した値がＵＤＰのペイロードとして許される長さとなる。これ以上のペイロード長になる場合、送信制御部１０３は、ペイロードを分割して送信する。
ここではペイロード長に１２００Ｂｙｔｅが指定されているので送信制御部１０３は、まず、ＤＭＡＣ１０５にアプリケーションメモリ１０２から送信メモリ１０６への転送を依頼する。

送信メモリ１０６への転送している間、送信制御部１０３は、ＴＣＰ（ＵＤＰ）ヘッダ送出部１１５へ、ヘッダ作成指示を出力する。ＵＤＰのフォーマットは既に図７で示したとおりである。
この状態ではＵＤＰヘッダ中のチェックサムを算出することができないが、送信制御部１０３は、チェックサムフィールドには０ｘ００００以外の値を入れた状態にしておく。そして、送信制御部１０３は、その他のフィールドである送信元Ｐｏｒｔ番号、受信先Ｐｏｒｔ番号、ＵＤＰデータ長を決定する。
ＵＤＰデータ長は後にデータを４Ｂｙｔｅ追加するため、送信制御部１０３は、送信要求があったデータ長に"４"だけ加算する。

ＴＣＰ（ＵＤＰ）ヘッダ送出部１１５は、ＵＤＰヘッダの作成と同時にＵＤＰ擬似ヘッダを作成する。ＴＣＰ（ＵＤＰ）ヘッダ送出部１１５によって、送信元、送信先のＩＰアドレス情報、再度ＵＤＰデータ長、Ｐｒｏｔｏｃｏｌ（ＵＤＰを指定する場合は０ｘ１１）の情報が各フィールドに代入される。
ＵＤＰヘッダ、ＵＤＰ擬似ヘッダが作成されると擬似ヘッダ情報がＩＰ送出部１０８に送信される。
ＩＰ送出部１０８によって、残りのＶｅｒ、ヘッダ長、ＴＯＳ、ＩＰパケット長、ＩＤ、Ｆｒａｇ、フラグメント情報等が各々に代入される。なお、ＩＰパケット長はＵＤＰデータ長からＩＰヘッダ長を加算した値となる。

このようにして各レイヤのヘッダが完成すると送信制御部１０３は、１パケット分のペイロードを送出するために送出長算出部１０４がＤＭＡＣ１０５へヘッダを出力するよう制御する。実際にペイロードを出力するに先立ち、完成された各ヘッダが出力される。
ＩＰヘッダ送出部１１３は、送信制御部１０３からの要求により、ＩＰ送出部１０８にＩＰヘッダを送信し、ＴＣＰ（ＵＤＰ）ヘッダ送出部１１５では擬似ヘッダ付のＵＤＰヘッダが補数算出部１０７へ出力される。
このとき送出されるヘッダに付加されているチェックサムは先に述べたように０ｘ００００以外の任意の数値（予め定められた数値）であるのでチェックサム値に正当性はない。ＩＰヘッダは補数算出部１０７を経由してＩＰ送出部１０８に送られる。
補数算出部１０７を経由する際にはチェックサムフィールドを除いた全てのフィールドに対しての１の補数和が算出されている。

続いて、ＤＭＡＣ１０５から送出パケットのペイロード部が送信メモリ１０６からＩＰヘッダと同様に補数算出部１０７経由でＩＰ送出部１０８に送信される。
補数算出部１０７では先に送信したＵＤＰヘッダ＋ＵＤＰ擬似ヘッダのチェックサムに続いてペイロード部の１の補数和の計算が継続されている。
ＩＰ送出部１０８にはＩＰヘッダ、ＵＤＰヘッダ、ペイロードが到着した順序で送出パケット合成部１０９に出力されている。
しかし、このパケットのヘッダフォーマットは先の述べたようにＵＤＰパケット長、ＩＰ総パケット長が４Ｏｃｔｅｄ少なく、ＵＤＰチェックサムの値の任意の値を当てはめているだけなのでこの値に正当性がない状態で出力されている。

ここで、ペイロード部の送信が終了すると、補数算出部１０７は、ＵＤＰ擬似ヘッダ＋ＵＤＰヘッダ＋ペイロード全ての１６ｂｉｔ整数における１の補数和の算出が終了し、その値が送出パケット合成部１０９に送られる。
送出パケット合成部１０９においては受け取った１の補数和の１の補数をｃｋｓｕｍｄａｔａとしてパケット最後のデータ（ペイロード部の末尾）に付加して送出する。
このようにして送出パケット合成部１０９が最後にｃｋｓｕｍｄａｔａを付加することでＵＤＰチェックサムの整合を取ることができる。

また、ＴＣＰパケットを送出する場合においてもＴＣＰ擬似ヘッダの構成はＵＤＰ擬似ヘッダの構成と変わらないので同様に構成・動作しても同じ効果を得ることができる。
このようにして送出されたＴＣＰ（ＵＤＰ）／ＩＰパケットはＬ２スイッチやＬ３ルータ等を介して相手側端末に到着することができる。
上述したように、図３は相手側端末の受信部の一例を示している。受信部に到着したＩＰパケットはＩＰ受信部２０８においてＩＰヘッダの解析が行われる。
このＩＰ受信部２０８ではＩＰヘッダ中のＩＰ ＡｄｄｒｅｓｓフィールドとＰｒｏｔｏｃｏｌフィールドとを除いた各フィールドについては解析終了後に"０"で満たし、後段のチェックサム検証部２０７に送られる。

チェックサム検証部２０７では受信データをＤＭＡＣ１０５経由で受信メモリに書き込むと同時にチェックサム、つまり１の補数和の算出を行っている。
受信側では送信時と同様に擬似ヘッダを先頭に付けて１の補数和を取らなければいけない。
前段のＩＰ受信部２０８ではＳｏｕｒｃｅ ＩＰ ＡｄｄｒｅｓｓフィールドとＤｅｓｔ ＩＰ ＡｄｄｒｅｓｓフィールドとＰｒｏｔｏｃｏｌフィールドとが残された状態で送られてきている。
よって、ＴＣＰパケット長、ＵＤＰパケット長に関する１の補数和を追加すればよい。

ＵＤＰパケット長はＵＤＰヘッダフィールドの内容からＵＤＰパケット長を複写し、ＴＣＰパケット長はＩＰ総パケット長からＩＰヘッダ長を減じた長さをＴＣＰパケット長とする。
このようにして全ての１の補数和を算出した結果、１６ｂｉｔの総和が０ｘＦＦＦＦとなれば正しい検証結果としてエラー無し、と判断される。
もし、これ以外の結果となった場合、パケットは破棄される。
エラーがなかった場合、ＤＭＡＣ１０５から送られる受信済みパケットデータが受信制御部２０３に報告されたデータ長に達したら受信完了、としてアプリケーションにパケット受信のＲｘ Ａｃｋを送信する。
最終的にはアプリケーション若しくは受信制御部２０３がＤＭＡＣ１０５を起動して受信メモリからアプリケーションメモリ１０２に送信される。

ここで、図４は、ＵＤＰパケットが処理される場合のデータ処理の一例を示す図である。
また、図５は、ＵＤＰパケットフォーマット、ＩＰパケットフォーマット及びチェックサム算出範囲の一例を示した図である。

＜第二の実施の形態＞
図６は、パケット作成装置の送信部の処理の一例を示したフローチャートである。なお、以下では説明の簡略化のため、ＣＰＵ１０００が処理を実行するものとして説明を行う。
図６において、ステップＳ４０１から開始される処理は、送信要求を初期化し、ソケットタイプを判断した後、プロトコル毎の送信パケット長を選るまでの処理である。
一方、ステップＳ４３０から開始される処理は、ＴＣＰ／ＵＣＰプロトコルにおいてヘッダ送出→ペイロード送出→チェックサム送出までの処理である。
まず、ステップＳ４０１において、ＣＰＵ１０００は、送信要求フロー全体の初期化を行った後、ステップＳ４０２において、ＣＰＵ１０００は、上位層の送信要求が到来するまで待機する。

送信要求が到来した場合、ステップＳ４０３において、ＣＰＵ１０００は、インターフェース部における最大パケット長ＭＴＵ（Ｍａｘｉｍｕｍ Ｔｒａｎｓｆｅｒ Ｕｎｉｔ）を取得した後、ステップＳ４０４において、ソケットタイプを判断する。
ここにおけるソケットタイプとはデータの送信保証がある。
連続したデータストリームであるＴＣＰ／ＩＰを用いて送信するか、一回限りのデータグラムの送信で終了するＵＤＰ／ＩＰを用いて送信するか、若しくはＩＰパケットのままで送信するか、ＣＰＵ１０００は、上位層の要求どおりに選択する。
ここで、ＴＣＰ／ＩＰを選択した場合、ＣＰＵ１０００は、まずＭＳＳ（Ｍａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅ）を取得する。

通常、ＭＳＳはＬＡＮインターフェースの場合はＭＴＵ−４０の長さとなる。このＭＳＳ値を取得したことでこの処理におけるＴＣＰ／ＩＰの最大送信サイズはＭＳＳの値を用いて決定される。
次に、ステップＳ４０６において、ＣＰＵ１０００は、送信済みデータ長を初期化した後、送信処理にはいる。
まず、最初にステップＳ４０７において、ＣＰＵ１０００は、未送信データ長がＭＳＳ−２を超えているかどうかを判断する。
ＭＳＳから２を減じているのは後に説明するチェックサム値を最後に付与するためである。
未送信データ長がＭＳＳ−２以下である場合、ＣＰＵ１０００は、パケット長をＭＳＳ−２にし、未送信データ長からＭＳＳ−２減算し、ステップＳ４０９のＴＣＰチェックサム作成処理に移行する。ＴＣＰチェックサム作成処理が終了した場合、ＣＰＵ１０００は、残りのデータを送出するためにステップＳ４０７に戻る。

一方、未送信データ長がＭＳＳ−２に満たない場合、ＣＰＵ１０００は、パケット長に残データ長をいれ、未送信データ長を０としてＴＣＰチェックサム作成処理に移行する。
一方、ＵＤＰ／ＩＰの場合、ステップＳ４１３において、ＣＰＵ１０００は、未送信データ長が（ＭＴＵ−ＩＰヘッダ長−ＵＤＰヘッダ長−２）に満たなければステップＳ４１６、以上であればステップＳ４１４に移行する。
ステップＳ４１４に移行した場合、ＣＰＵ１０００は、パケット長をＭＴＵ−ＩＰヘッダ長−ＵＤＰヘッダ長−２に設定し、未送信データ長からパケット長を減じた後、ＵＤＰチェックサム作成処理に移行する。
ＵＤＰチェックサム作成処理が終了した後、ＣＰＵ１０００は、再びステップＳ４１３に戻る。
また、未送信データ長の判断によりステップＳ４１６に移行した場合、ＣＰＵ１０００は、パケット長に残データ長に２を加算、未送信データ長を０としてＵＤＰチェックサム作成処理に移行する。

次に上位層の指示によりＩＰＲａｗで送信する場合、ＣＰＵ１０００は、ペイロードのチェックサムを行う必要がないため、本実施形態の説明においては省略する。
次にＴＣＰ／ＵＤＰチェックサムの作成処理について説明する。
ステップＳ４３０から開始されるチェックサム作成処理は先の説明においてステップＳ４０９、ステップＳ４１１におけるＴＣＰチェックサムの作成及びステップＳ４１５、ステップＳ４１７におけるＵＤＰチェックサム作成処理を兼ねている。
まず、ステップＳ４３１において、ＣＰＵ１０００は、ＴＣＰ又はＵＤＰのヘッダを作成する。本来であればこのヘッダ作成には多くの処理が必要であるが、チェックサムの作成には多く関与されないために詳細は省略する。

このヘッダ作成においては０ｘ００００とした場合、検証側でチェックサムを行わないことを意味するため、ＣＰＵ１０００は、ＴＣＰチェックサム、ＵＤＰチェックサムの値を０ｘ００００以外の予め定められた値、例えば０ｘ０００１としておく。
次にステップＳ４３２において、ＣＰＵ１０００は、擬似ヘッダの作成を行う。
上述した図８において説明したように擬似ヘッダとＩＰヘッダとには多くの相間関係があり、また、ステップＳ４３３のチェックサムの算出には関係が無いように順序を入れ替えておくことで後のＩＰヘッダ作成が簡略することができる。
ＣＰＵ１０００は、ＴＣＰ又はＵＤＰヘッダに擬似ヘッダを付加したものに対してチェックサムを算出しておき、次のステップＳ４３４において、ＩＰヘッダを作成する。

ここでステップＳ４３５において、ＴＣＰ／ＩＰ、ＵＤＰ／ＩＰのヘッダ部については送出が可能な状態となり、ＣＰＵ１０００は、ヘッダ部を送信する。
送出するペイロードがある場合、ＣＰＵ１０００は、ステップＳ４３７〜ステップＳ４３９の処理によりチェックサムを算出しつつペイロードを送出する。ステップＳ４４０において、ＣＰＵ１０００は、未送信データが無くなった後にヘッダ部とペイロード部とのトータルのチェックサムを送出してパケットの送出を完了する。

＜その他の実施形態＞
また、本発明の目的は、以下のようにすることによって達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（又は記録媒体）を、システム或いは装置に供給する。そして、そのシステム或いは装置の中央演算処理手段（ＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行する。この場合、記憶媒体から読み出されたプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコードを記録した記憶媒体は本発明を構成することになる。

また、システム或いは装置の前記中央演算処理手段が読み出したプログラムコードを実行することにより、そのプログラムコードの指示に基づき、システム或いは装置上で稼働しているオペレーティングシステム（ＯＳ）等が実際の処理の一部又は全部を行う。その処理によって上述した実施形態の機能が実現される場合も含まれる。

更に、記憶媒体から読み出されたプログラムコードが、前記システム或いは装置に挿入された機能拡張カードや、接続された機能拡張ユニットに備わるメモリに書込まれたとする。その後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって上述した実施形態の機能が実現される場合も含まれる。

本発明を前記記憶媒体に適用する場合、その記憶媒体（コンピュータ読み取り可能な記憶媒体）には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

以上、上述した各実施形態によれば、パケット処理時に用いられるチェックサム演算に整合性を持たせたまま、チェックサム算出の為にかかる遅延をなくすことができる。また、上述した各実施形態によれば、ペイロードを退避させておくためのメモリに関して不要になるためコストダウンが可能となる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

パケット作成装置のハードウェア構成の一例を示す図である。 パケット作成装置の送信部の構成例を示した図である。 図２のパケット作成装置の送信部に対応する受信部の構成例を示した図である。 ＵＤＰパケットが処理される場合のデータ処理の一例を示す図である。 ＵＤＰパケットが処理される場合のデータ処理の一例を示す図である。 パケット作成装置の送信部の処理の一例を示したフローチャートである。 従来のＵＤＰパケットフォーマット、ＩＰパケットフォーマット、チェックサム算出範囲を示した図である。 従来のＵＤＰ擬似ヘッダを用いてＩＰヘッダを作成する一例を示す図である。 従来のＵＤＰパケットが送信されるまでの処理の一例を示す図である。 従来のＴＣＰパケットフォーマット、ＩＰパケットフォーマット、チェックサム算出範囲を示した図である。

符号の説明

１０００ ＣＰＵ
１０１０ プログラム メモリ
１０２０ ＲＡＭ
１０３０ ハードディスク

Claims (6)

1. ヘッダのチェックサムフィールドに予め定められた値を入れ、ヘッダに続くペイロードの末尾にチェックサムデータを付与するパケット作成手段を有することを特徴とするパケット作成装置。
2. 前記パケット作成手段は、ＴＣＰ／ＩＰ又はＵＤＰ／ＩＰのパケットを作成することを特徴とする請求項１に記載のパケット作成装置。
3. 前記ペイロードの前記チェックサムデータに基づくチェックサムの算出の前に、前記ヘッダを送信する送信手段を更に有することを特徴とする請求項１又は２に記載のパケット作成装置。
4. パケット作成装置におけるパケット作成方法であって、
   ヘッダのチェックサムフィールドに予め定められた値を入れ、ヘッダに続くペイロードの末尾にチェックサムデータを付与するパケット作成ステップを有することを特徴とするパケット作成方法。
5. コンピュータを、
   ヘッダのチェックサムフィールドに予め定められた値を入れ、ヘッダに続くペイロードの末尾にチェックサムデータを付与するパケット作成手段として機能させることを特徴とするプログラム。
6. 請求項５に記載のプログラムを記憶したコンピュータにより読み取り可能な記憶媒体。

Images