(57)【要約】  【課題】  通信スループットの低下を抑えること等が可能なＴＣＰ／ＩＰ受信処理回路等を提供する。  【解決手段】  このＴＣＰ／ＩＰ受信処理回路５は、フレーム解析処理部２１と、解析結果データ格納部２２と、ＦＩＦＯバッファメモリ２３と、ＤＭＡ制御部２４と、ＤＭＡ処理部２５と、通信端点推定処理部２６と、通信端点推定情報格納部２７とを具備する。フレーム解析処理部２１は、フレームの解析結果を解析結果データ格納部２２に書き込み、パケットをＦＩＦＯバッファメモリ２３に書き込む。通信端点推定処理部２６は、解析結果と通信端点推定情報格納部２７内の情報とを照合し、通信端点を推定する。ＤＭＡ制御部２４は、推定された通信端点へのパケットの転送をＤＭＡ処理部２５に開始させ、その後、推定された通信端点と特定された通信端点とが一致しない場合に、特定された通信端点へのパケットの転送を開始させる。【選択図】  図１
2006332927.tif 000002
【特許請求の範囲】
【請求項１】
下位レイヤから受け取ったフレームに格納されているパケットを上位レイヤがアクセス可能なメモリに転送するＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）受信処理回路であって、
下位レイヤから受け取ったフレームに格納されているパケットの宛先である通信端点の特定と並行して当該パケットの宛先である通信端点の推定及び当該パケットの宛先であると推定された通信端点への当該パケットの転送の開始を行い、当該パケットの宛先であると特定された通信端点と当該パケットの宛先であると推定された通信端点とが一致しない場合に、当該パケットの宛先であると推定された通信端点への当該パケットの転送を中止し、当該パケットの宛先であると特定された通信端点への当該パケットの転送を開始する、ＴＣＰ／ＩＰ受信処理回路。
【請求項２】
下位レイヤから受け取ったフレームに格納されているＩＰ（Internet Protocol）パケット内のヘッダ・チェックサムを用いたＩＰパケットの検証、当該ＩＰパケット内のＴＣＰ（Transmission Control Protocol）又はＵＤＰ（User Datagram Protocol）パケット内のＴＣＰ又はＵＤＰのチェックサムを用いた当該ＴＣＰ又はＵＤＰパケットの検証、当該ＩＰパケット若しくは当該ＴＣＰ又はＵＤＰパケットのフォーマットの解析、並びに、当該ＴＣＰ又はＵＤＰパケットの宛先である通信端点の特定と並行して、当該ＴＣＰ又はＵＤＰパケットの宛先である通信端点の推定に必要な情報の当該フレームからの抽出、当該パケットの宛先である通信端点の推定、並びに、当該パケットの宛先であると推定された通信端点への当該パケットの転送の開始を行い、当該パケットの宛先であると特定された通信端点と当該パケットの宛先であると推定された通信端点とが一致しない場合に、当該パケットの宛先であると推定された通信端点への当該パケットの転送を中止し、当該パケットの宛先であると特定された通信端点への当該パケットの転送を開始する、請求項１記載のＴＣＰ／ＩＰ受信処理回路。
【請求項３】
下位レイヤから受け取ったフレームに格納されているＩＰパケット内のパケットのＴＣＰ又はＵＤＰパケットの区分、ソースＩＰアドレス、ソースポート番号、デスティネーションＩＰアドレス、並びに、デスティネーションポート番号を用いて当該ＴＣＰ又はＵＤＰパケットの宛先である通信端点の特定を行い、下位レイヤから受け取ったフレームに格納されているＩＰパケット内のパケットのＴＣＰ又はＵＤＰパケットの区分、ソースＩＰアドレスの所定部分、ソースポート番号の所定部分、デスティネーションＩＰアドレスの所定部分、並びに、デスティネーションポート番号の所定部分を用いて当該ＴＣＰ又はＵＤＰパケットの宛先である通信端点の推定を行う、請求項１又は２記載のＴＣＰ／ＩＰ受信処理回路。
【請求項４】
前記メモリが、所定の通信端点宛ての複数のパケットをそれぞれ格納するための複数のパケット格納領域と、各々が有する第１のポインタによってリンクされている複数のディスクリプタテーブルであって、前記パケット格納領域を指し示すための第２のポインタ及び前記第２のポインタによって指し示される前記パケット格納領域にパケットを書き込むことが可能であるか否かを示すパケット書込み可否情報をそれぞれ有する前記複数のディスクリプタテーブルと、を含む通信端点情報領域を有しており、
下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのパケットであると特定又は推定された場合に、前記第１のポインタ及び前記パケット書込み可否情報を利用して前記複数のディスクリプタテーブルの中からパケットを書き込むことが可能な前記パケット格納領域を指し示す１つのディスクリプタテーブルを決定し、下位レイヤから受け取ったフレームに格納されているパケットを当該ディスクリプタテーブル内の前記第２のポインタによって指し示される前記パケット格納領域内に転送する、請求項１〜３のいずれか１項記載のＴＣＰ／ＩＰ受信処理回路。
【請求項５】
前記複数のパケット格納領域の各々が、パケットのヘッダを格納するためのヘッダ格納領域と、パケットのペイロードを格納するためのペイロード格納領域と、を含んでおり、
前記第２のポインタが、前記ヘッダ格納領域を指し示す第３のポインタと、前記ペイロード格納領域を指し示す第４のポインタと、を含んでおり、
下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのパケットであると特定又は推定された場合に、前記第１のポインタ及び前記パケット書き込み可否情報を利用して前記複数のディスクリプタテーブルの中からパケットを書き込むことが可能な前記パケット格納領域を指し示す１つのディスクリプタテーブルを決定し、下位レイヤから受け取ったフレームに格納されているパケットのヘッダを当該ディスクリプタテーブル内の前記第３のポインタによって指し示される前記ヘッダ格納領域内に転送し、下位レイヤから受け取ったフレームに格納されているパケットのペイロードを当該ディスクリプタテーブル内の前記第４のポインタによって指し示される前記ペイロード格納領域内に転送する、請求項４記載のＴＣＰ／ＩＰ受信処理回路。
【請求項６】
前記複数のパケット格納領域内の前記ペイロード格納領域が、前記メモリ内の連続するアドレスに配置されている、請求項５記載のＴＣＰ／ＩＰ受信処理回路。
【請求項７】
前記複数のディスクリプタテーブルの各々が、前記ヘッダ格納領域に格納可能なヘッダのサイズを表すヘッダ格納領域サイズ情報と、前記ペイロード格納領域に格納可能なペイロードのサイズを表すペイロード格納領域サイズ情報と、を更に含んでおり、
下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのパケットであると特定又は推定された場合に、前記第１のポインタ及び前記パケット書き込み可否情報を利用して前記複数のディスクリプタテーブルの中からパケットを書き込むことが可能な前記パケット格納領域を指し示す１つのディスクリプタテーブルを決定し、当該ディスクリプタテーブル内の前記ヘッダ格納領域サイズ情報によって表されるサイズより下位レイヤから受け取ったフレームに格納されているパケットのヘッダのサイズが大きいときに、下位レイヤから受け取ったフレームに格納されているパケットのヘッダの内の当該ディスクリプタテーブル内の前記ヘッダ格納領域に格納可能な部分を当該ディスクリプタテーブル内の前記ヘッダ格納領域に転送し、当該ディスクリプタテーブル内の前記ペイロード格納領域サイズ情報によって表されるサイズより下位レイヤから受け取ったフレームに格納されているパケットのペイロードのサイズが大きいときに、下位レイヤから受け取ったフレームに格納されているパケットのペイロードの内の当該ディスクリプタテーブル内の前記ペイロード格納領域に格納可能な部分を当該ディスクリプタテーブル内の前記ペイロード格納領域に転送する、請求項５又は６記載のＴＣＰ／ＩＰ受信処理回路。
【請求項８】
前記所定の通信端点の論理的データストリームブロックの初期サイズを上位レイヤによって設定可能な減算カウンタを具備し、下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのパケットであると特定又は推定された場合に、前記減算カウンタにおいて、下位レイヤから受け取ったフレームに格納されているパケットのペイロードのサイズに相当する値の減算を行い、前記減算カウンタの値が０になったときに、その旨を通知するための制御信号を上位レイヤに出力する、請求項１〜７のいずれか１項記載のＴＣＰ／ＩＰ受信処理装置。
【請求項９】
前記所定の通信端点がＴＣＰの通信端点である場合に、
前記メモリが、前記所定の通信端点宛てのＲＳＴパケットを格納するためのＲＳＴパケット格納領域と、前記ＲＳＴパケット格納領域を指し示すためのポインタを有するＲＳＴディスクリプタテーブルと、を更に有し、
下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのＲＳＴパケットであると特定又は推定された場合に、前記ＲＳＴディスクリプタテーブル内の前記ポインタによって指し示される前記ＲＳＴパケット格納領域内に前記ＲＳＴパケットを転送する、請求項１〜８のいずれか１項記載のＴＣＰ／ＩＰ受信処理回路。
【請求項１０】
前記所定の通信端点のシーケンス番号の初期値を上位レイヤによって設定可能な加算カウンタを具備し、下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのパケットであると特定又は推定された場合に、当該パケットのＴＣＰヘッダ内のシーケンス番号と前記加算カウンタの値とが一致する場合に、下位レイヤから受け取ったフレームに格納されているパケットを前記メモリに転送するとともに、前記加算カウンタの値をインクリメントする、請求項１〜９のいずれか１項記載のＴＣＰ／ＩＰ受信処理装置。
【請求項１１】
前記複数のディスクリプタテーブルの各々が、下位レイヤから受け取ったフレーム又は下位レイヤから受け取ったフレームに格納されているパケットの解析結果を格納するための解析結果格納領域を更に含んでおり、
下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのパケットであると特定又は推定された場合に、前記第１のポインタ及び前記パケット書込み可否情報を利用して前記複数のディスクリプタテーブルの中からパケットを書き込むことが可能な前記パケット格納領域を指し示す１つのディスクリプタテーブルを決定し、下位レイヤから受け取ったフレームに格納されているパケットを当該ディスクリプタテーブル内の前記第２のポインタによって指し示される前記パケット格納領域内に転送するとともに、下位レイヤから受け取ったフレーム又は下位レイヤから受け取ったフレームに格納されているパケットの解析結果を当該ディスクリプタテーブル内の前記解析結果格納領域に書き込む、請求項１〜１０のいずれか１項記載のＴＣＰ／ＩＰ受信処理回路。
【請求項１２】
前記メモリが、複数の通信端点にそれぞれ対応する複数の前記通信端点情報領域を有しており、
下位レイヤから受け取ったフレームに格納されているパケットが前記複数の通信端点のいずれかの通信端点宛てのパケットであると特定又は推定された場合に、前記複数の通信端点情報領域の中の当該パケットの宛先であると特定又は推定された通信端点に対応する通信端点情報領域の中のディスクリプタテーブル内で指し示されるパケット格納領域に当該パケットを書き込む、請求項１〜１１のいずれか１項記載のＴＣＰ／ＩＰ受信処理回路。
【請求項１３】
前記メモリが、下位レイヤから受け取ったフレームに格納されているパケットのプロトコルが所定のプロトコルでない場合における当該フレーム又は下位レイヤから受け取ったフレームに格納されているパケットが前記複数の通信端点のいずれ宛てでもないパケットである場合における当該パケットを格納するための第２の前記通信端点情報領域を更に有しており、
下位レイヤから受け取ったフレームに格納されているパケットのプロトコルが所定のプロトコルでない場合又は下位レイヤから受け取ったフレームに格納されているパケットが前記複数の通信端点のいずれ宛てでもないパケットである場合に、下位レイヤから受け取ったフレームに格納されているパケットのプロトコルが所定のプロトコルでない場合における当該フレーム又は下位レイヤから受け取ったフレームに格納されているパケットが前記複数の通信端点のいずれ宛てでもないパケットである場合における当該パケットを前記第２の通信端点情報領域の中のディスクリプタテーブル内で指し示されるパケット格納領域に転送する、請求項１２記載のＴＣＰ／ＩＰ受信処理回路。
【請求項１４】
請求項１〜１３のいずれか１項記載のＴＣＰ／ＩＰ受信処理回路を具備する半導体集積回路。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）の受信処理を行うためのＴＣＰ／ＩＰ受信処理回路に関する。さらに、本発明は、そのようなＴＣＰ／ＩＰ受信処理回路を具備する半導体集積回路に関する。
【背景技術】
【０００２】
現在、インターネット、ＬＡＮ（Local Area Network）等において、ＴＣＰ／ＩＰと呼ばれる通信プロトコルの階層モデルが広く用いられている。図１０は、ＴＣＰ／ＩＰ階層モデルの各レイヤとＩＳＯ（International Organization for Standardization）で制定されたＯＳＩ（Open Systems Interconnection）参照モデルの各レイヤとのおおよその対応関係を示す図である。
【０００３】
ＴＣＰ／ＩＰ階層モデルのネットワークインタフェース層としてはEthernet（登録商標）が、ＴＣＰ／ＩＰ階層モデルのインターネット層としてはＩＰ（Internet Protocol）バージョン４（以下、単に「ＩＰ」という）が、ＴＣＰ／ＩＰ階層モデルのトランスポート層としてはＴＣＰ（Transmission Control Protocol）又はＵＤＰ（User Datagram Protocol）が、広く用いられている。なお、Ethernet（登録商標）は、ＩＥＥＥ８０２．３等に、ＩＰは、ＲＦＣ（Request For Comments）７９１等に、ＴＣＰは、ＲＦＣ７９３等に、ＵＤＰは、ＲＦＣ７６８等に、それぞれ規定されている。
【０００４】
また、ネットワーク管理用のプロトコルとして、ＴＣＰ／ＩＰ階層モデルのインターネット層に相当するＡＲＰ（Address Resolution Protocol）及びＲＡＲＰ（Reverse Address Resolution Protocol）、ＴＣＰ／ＩＰ階層モデルのトランスポート層に相当するＩＣＭＰ（Internet Control Message Protocol）が、広く用いられている。なお、ＡＲＰは、ＲＦＣ８２６等に、ＲＡＲＰは、ＲＦＣ９０３等に、ＩＣＭＰは、ＲＦＣ７９２等に、それぞれ規定されている。
【０００５】
図１１は、Ethernet（登録商標）フレーム（以下、単に「フレーム」という）のフォーマットを示す図である。図１１に示すように、フレームは、ヘッダと、ペイロードとを有する。なお、フレームが実際にネットワーク上に送信される際には、先頭にプリアンブルが、末尾にＣＲＣ（Cyclic Redundancy Check）を格納したフレームチェックシーケンス（Frame Check Sequence）が、それぞれ付加される。
【０００６】
図１２は、ＩＰパケットのフォーマットを示す図である。図１２に示すように、ＩＰパケットは、ＩＰヘッダと、ＩＰペイロードとを有する。ＩＰパケットは、フレームのペイロード内（図１１参照）に格納される。
【０００７】
図１３は、ＡＲＰ、ＲＡＲＰパケットのフォーマットを示す図である。ＡＲＰ、ＲＡＲＰパケットは、フレームのペイロード内（図１１参照）に格納される。
【０００８】
図１４は、ＴＣＰパケットのフォーマットを示す図である。図１４に示すように、ＴＣＰパケットは、ＴＣＰヘッダと、ＴＣＰペイロードとを有する。ＴＣＰパケットは、ＩＰパケットのペイロード内（図１２参照）に格納される。
【０００９】
図１５は、ＵＤＰパケットのフォーマットを示す図である。図１５に示すように、ＵＤＰパケットは、ＵＤＰヘッダと、ＵＤＰペイロードとを有する。ＵＤＰパケットは、ＩＰパケットのペイロード内（図１２参照）に格納される。
【００１０】
図１６は、ＩＣＭＰパケットのフォーマットを示す図である。ＩＣＭＰパケットは、ＩＰパケットのペイロード内（図１２参照）に格納される。
【００１１】
従来のコンピュータ等においては、ネットワークインタフェース層をハードウェア回路（以下、ＮＩＣ（Network Interface Card）という）で実現し、インターネット層〜アプリケーション層をＣＰＵとソフトウェア（プログラム）で実現する場合が多かった。しかしながら、インターネット層〜アプリケーション層をＣＰＵとソフトウェア（プログラム）で実現する場合、ＣＰＵの負荷が大きいという問題があった。そこで、近年においては、インターネット層及び／又はトランスポート層をハードウェア回路で実現したＴＣＰ／ＩＰ受信処理回路を用いることにより、ＣＰＵの負荷を軽減することが行われるようになってきている。
【００１２】
関連する技術として、下記の特許文献１には、ネットワークアダプタと複数の層を有するプロトコルスタックとを備えたネットワークノードにおいてデータを受信する方法であって、ネットワーク媒体からの着信データパケットを形成するパケットバイトをメモリに転送し、パケットバイトがネットワーク媒体からメモリへ転送される際に着信データパケットの一部を形成するパケットバイトからコードを計算し、該コードをプロトコルスタックに関連するコードチャネルへ転送し、プロトコルスタックの複数の層のうちの第１の層におけるデータパケットから抽出されたデータを受信し、該抽出されたデータをコードチャネルからのコードを使用して検証する、という各ステップを有することを特徴とする方法が掲載されている。
この方法は、パケットがネットワーク媒体からメモリへ転送される際にＴＣＰのチェックサム等を計算することができるものである。
【００１３】
また、下記の特許文献２には、ネットワークに接続され、主記憶装置とネットワークアダプタを有する計算機システムにおいて、ネットワークアダプタによってネットワークから受信されたネットワークパケットを主記憶装置に送る方法であって、(a)ネットワークアダプタによりネットワークパケットのヘッダを主記憶装置中の第1のメモリバッファに置くステップ；(b)ネットワークアダプタによりネットワークパケットに含まれるデータを主記憶装置中の第2のメモリバッファの最初に置くステップを備える方法が掲載されている。
この方法は、着信パケットのヘッダとデータを分離して別々のメモリバッファに入れることができるものである。
【００１４】
ところで、一般に、アプリケーション層において実行されるアプリケーションプログラム（ウェブブラウザプログラム、メールクライアントプログラム等）は、通信端点（ＯＳ（Operating System）上においてＡＰＩ（Application Programming Interface）によって提供される）からパケットを受け取る。この通信端点には、ＯＳによってパケットが供給される。ＯＳは、ＮＩＣからデバイスドライバ（プログラム）経由でパケットを受け取ると、現に存在している通信端点宛てのパケットであるか否かを判定し、現に存在している通信端点宛てのパケットである場合に、パケットを該当する通信端点に供給する。
【００１５】
なお、下記の非特許文献１には、ＩＴＲＯＮにおけるＴＣＰ／ＩＰの通信端点のＡＰＩの仕様が掲載されている。
【００１６】
図１７は、インターネット層及びトランスポート層をハードウェア回路で実現した従来のＴＣＰ／ＩＰ受信処理回路の動作の例を示すフローチャートである。
従来のＴＣＰ／ＩＰ受信処理回路は、ネットワークインタフェース層からフレームを受け取ると、まず、ＣＲＣを用いてフレームの検証を行う（ステップＳ５１）。
【００１７】
次に、従来のＴＣＰ／ＩＰ受信処理回路は、ＩＰのヘッダ・チェックサム（図１２参照）を用いてＩＰパケットの検証を行い（ステップＳ５２）、さらに、ＴＣＰ又はＵＤＰのチェックサム（図１４及び図１５参照）を用いてＴＣＰ又はＵＤＰパケットの検証を行う（ステップＳ５３）。
【００１８】
また、従来のＴＣＰ／ＩＰ受信処理回路は、ＩＰパケットの検証（ステップＳ５２）並びにパケットの検証（ステップＳ５３）と並行して、パケットのフォーマット解析を行う（ステップＳ５４）。これは、ＩＰパケットの検証並びにＴＣＰ又はＵＤＰパケットの検証を行うハードウェア回路と、パケットのフォーマット解析を行うハードウェア回路とを別個に具備することにより実現可能である。なお、このように異なる処理を並行して行うことは、ソフトウェア工学の分野における「ｆｏｒｋ」及び「ｊｏｉｎ」に相当するものと考えることができる。
【００１９】
従来のＴＣＰ／ＩＰ受信処理回路は、ＩＰパケットの検証（ステップＳ５２）、ＴＣＰ又はＵＤＰパケットの検証（ステップＳ５３）、並びに、パケットのフォーマット解析（ステップＳ５４）が終了すると、通信端点の特定を行う（ステップＳ５５）。
【００２０】
そして、従来のＴＣＰ／ＩＰ受信処理回路は、特定された通信端点へのパケットのＤＭＡ転送を行う（ステップＳ５６）。これにより、ネットワークインタフェース層から受け取ったフレーム中のパケットが、通信端点に送られる。
【００２１】
通信端点は、プロトコル（ＴＣＰ又はＵＤＰ）、ソース（自）ＩＰアドレス、ソース（自）ポート番号、デスティネーション（相手方）ＩＰアドレス、デスティネーション（相手方）ポート番号（以下、「通信端点特定情報」という）によって特定される。ここで、ＴＣＰ又はＵＤＰを区別するために１ビットが必要であり、ソース（自）ＩＰアドレス及びデスティネーション（相手方）ＩＰアドレスは、それぞれ３２ビット幅であり、ソース（自）ポート番号及びデスティネーション（相手方）ポート番号は、それぞれ１６ビット幅である。従って、上記のステップＳ５５において、通信端点を特定するためには、９７ビットの照合（パターンマッチング）が必要である。
【００２２】
９７ビット幅のコンパレータがＴＣＰ／ＩＰ受信処理回路に搭載されていれば、通信端点の特定は容易である。しかしながら、９７ビット幅のコンパレータのハードウェア量は非常に大きく、コストも高いため、このようなコンパレータをＴＣＰ／ＩＰ受信処理回路に搭載することは困難である。そのため、ＴＣＰ／ＩＰ受信処理回路においては、よりビット幅の小さいコンパレータ等を繰り返し動作させること等により通信端点の特定を行う必要があり、通信端点の特定に長い時間がかかってしまっていた。
【００２３】
上記のように通信端点の特定に長い時間がかかる一方で、近年、ネットワークインタフェース層の転送速度が向上してきており、１００ＢＡＳＥ−ＴＸ、１０００ＢＡＳＥ−Ｔ等が用いられるようになってきている。そのため、既に到着したフレームの通信端点の特定を長い時間を費やして行っている間に、ネットワークインタフェース層から次々と新たなフレームが到着するということが起こり得る。この場合、多数のフレームをバッファリングするための非常に大きなバッファメモリがＴＣＰ／ＩＰ受信処理回路に搭載されていれば問題は生じないが、非常に大きなバッファメモリのハードウェア量は非常に大きく、コストも高いため、このようなバッファメモリをＴＣＰ／ＩＰ受信処理回路に搭載することは困難である。そのため、ＴＣＰ／ＩＰ受信処理回路において、フレームのロスト（脱落）が頻発し、通信スループットが低下してしまうことがあった。
【００２４】
【特許文献１】特開平１１−１６８４５１号公報（第１頁、図１）
【特許文献２】特開平６−７８００１号公報（第１頁、図１）
【非特許文献１】Ｅｍｂｅｄｄｅｄ  ＴＣＰ／ＩＰ技術委員会（高田  広章  編）、“ＩＴＲＯＮ  ＴＣＰ／ＩＰ  ＡＰＩ仕様  Ver.1.00.01”、[online]、１９９８年５月１９日、（社）トロン協会  ＩＴＲＯＮ専門委員会、[平成１７年４月１３日検索]、インターネット＜ＵＲＬ：http://www.assoc.tron.org/spec/itron/tcpip-100j.pdf＞
【発明の開示】
【発明が解決しようとする課題】
【００２５】
そこで、上記の点に鑑み、本発明は、ハードウェア量の増加を抑えながら、通信スループットの低下を抑えること等が可能なＴＣＰ／ＩＰ受信処理回路を提供することを目的とする。また、本発明はそのようなＴＣＰ／ＩＰ受信処理回路を具備する半導体集積回路を提供することを更なる目的とする。
【課題を解決するための手段】
【００２６】
以上の課題を解決するため、本発明に係るＴＣＰ／ＩＰ受信処理回路は、下位レイヤから受け取ったフレームに格納されているパケットを上位レイヤがアクセス可能なメモリに転送するＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）受信処理回路であって、下位レイヤから受け取ったフレームに格納されているパケットの宛先である通信端点の特定と並行して当該パケットの宛先である通信端点の推定及び当該パケットの宛先であると推定された通信端点への当該パケットの転送の開始を行い、当該パケットの宛先であると特定された通信端点と当該パケットの宛先であると推定された通信端点とが一致しない場合に、当該パケットの宛先であると推定された通信端点への当該パケットの転送を中止し、当該パケットの宛先であると特定された通信端点への当該パケットの転送を開始する。
【００２７】
このＴＣＰ／ＩＰ受信処理回路において、下位レイヤから受け取ったフレームに格納されているＩＰ（Internet Protocol）パケット内のヘッダ・チェックサムを用いたＩＰパケットの検証、当該ＩＰパケット内のＴＣＰ（Transmission Control Protocol）又はＵＤＰ（User Datagram Protocol）パケット内のＴＣＰ又はＵＤＰのチェックサムを用いた当該ＴＣＰ又はＵＤＰパケットの検証、当該ＩＰパケット若しくは当該ＴＣＰ又はＵＤＰパケットのフォーマットの解析、並びに、当該ＴＣＰ又はＵＤＰパケットの宛先である通信端点の特定と並行して、当該ＴＣＰ又はＵＤＰパケットの宛先である通信端点の推定に必要な情報の当該フレームからの抽出、当該パケットの宛先である通信端点の推定、並びに、当該パケットの宛先であると推定された通信端点への当該パケットの転送の開始を行い、当該パケットの宛先であると特定された通信端点と当該パケットの宛先であると推定された通信端点とが一致しない場合に、当該パケットの宛先であると推定された通信端点への当該パケットの転送を中止し、当該パケットの宛先であると特定された通信端点への当該パケットの転送を開始するようにしても良い。
【００２８】
また、下位レイヤから受け取ったフレームに格納されているＩＰパケット内のパケットのＴＣＰ又はＵＤＰパケットの区分、ソースＩＰアドレス、ソースポート番号、デスティネーションＩＰアドレス、並びに、デスティネーションポート番号を用いて当該ＴＣＰ又はＵＤＰパケットの宛先である通信端点の特定を行い、下位レイヤから受け取ったフレームに格納されているＩＰパケット内のパケットのＴＣＰ又はＵＤＰパケットの区分、ソースＩＰアドレスの所定部分、ソースポート番号の所定部分、デスティネーションＩＰアドレスの所定部分、並びに、デスティネーションポート番号の所定部分を用いて当該ＴＣＰ又はＵＤＰパケットの宛先である通信端点の推定を行うようにしても良い。
【００２９】
また、メモリが、所定の通信端点宛ての複数のパケットをそれぞれ格納するための複数のパケット格納領域と、各々が有する第１のポインタによってリンクされている複数のディスクリプタテーブルであって、パケット格納領域を指し示すための第２のポインタ及び第２のポインタによって指し示されるパケット格納領域にパケットを書き込むことが可能であるか否かを示すパケット書込み可否情報をそれぞれ有する複数のディスクリプタテーブルと、を含む通信端点情報領域を有しており、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのパケットであると特定又は推定された場合に、第１のポインタ及びパケット書込み可否情報を利用して複数のディスクリプタテーブルの中からパケットを書き込むことが可能なパケット格納領域を指し示す１つのディスクリプタテーブルを決定し、下位レイヤから受け取ったフレームに格納されているパケットを当該ディスクリプタテーブル内の第２のポインタによって指し示されるパケット格納領域内に転送するようにしても良い。
【００３０】
また、複数のパケット格納領域の各々が、パケットのヘッダを格納するためのヘッダ格納領域と、パケットのペイロードを格納するためのペイロード格納領域と、を含んでおり、第２のポインタが、ヘッダ格納領域を指し示す第３のポインタと、ペイロード格納領域を指し示す第４のポインタと、を含んでおり、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのパケットであると特定又は推定された場合に、第１のポインタ及びパケット書き込み可否情報を利用して複数のディスクリプタテーブルの中からパケットを書き込むことが可能なパケット格納領域を指し示す１つのディスクリプタテーブルを決定し、下位レイヤから受け取ったフレームに格納されているパケットのヘッダを当該ディスクリプタテーブル内の第３のポインタによって指し示されるヘッダ格納領域内に転送し、下位レイヤから受け取ったフレームに格納されているパケットのペイロードを当該ディスクリプタテーブル内の第４のポインタによって指し示されるペイロード格納領域内に転送するようにしても良い。
【００３１】
また、複数のパケット格納領域内のペイロード格納領域が、メモリ内の連続するアドレスに配置されているようにしても良い。
【００３２】
また、複数のディスクリプタテーブルの各々が、ヘッダ格納領域に格納可能なヘッダのサイズを表すヘッダ格納領域サイズ情報と、ペイロード格納領域に格納可能なペイロードのサイズを表すペイロード格納領域サイズ情報と、を更に含んでおり、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのパケットであると特定又は推定された場合に、第１のポインタ及びパケット書き込み可否情報を利用して複数のディスクリプタテーブルの中からパケットを書き込むことが可能なパケット格納領域を指し示す１つのディスクリプタテーブルを決定し、当該ディスクリプタテーブル内のヘッダ格納領域サイズ情報によって表されるサイズより下位レイヤから受け取ったフレームに格納されているパケットのヘッダのサイズが大きいときに、下位レイヤから受け取ったフレームに格納されているパケットのヘッダの内の当該ディスクリプタテーブル内のヘッダ格納領域に格納可能な部分を当該ディスクリプタテーブル内のヘッダ格納領域に転送し、当該ディスクリプタテーブル内のペイロード格納領域サイズ情報によって表されるサイズより下位レイヤから受け取ったフレームに格納されているパケットのペイロードのサイズが大きいときに、下位レイヤから受け取ったフレームに格納されているパケットのペイロードの内の当該ディスクリプタテーブル内のペイロード格納領域に格納可能な部分を当該ディスクリプタテーブル内のペイロード格納領域に転送するようにしても良い。
【００３３】
また、所定の通信端点の論理的データストリームブロックの初期サイズを上位レイヤによって設定可能な減算カウンタを具備し、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのパケットであると特定又は推定された場合に、減算カウンタにおいて、下位レイヤから受け取ったフレームに格納されているパケットのペイロードのサイズに相当する値の減算を行い、減算カウンタの値が０になったときに、その旨を通知するための制御信号を上位レイヤに出力するようにしても良い。
【００３４】
また、所定の通信端点がＴＣＰの通信端点である場合に、メモリが、所定の通信端点宛てのＲＳＴパケットを格納するためのＲＳＴパケット格納領域と、ＲＳＴパケット格納領域を指し示すためのポインタを有するＲＳＴディスクリプタテーブルと、を更に有し、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのＲＳＴパケットであると特定又は推定された場合に、ＲＳＴディスクリプタテーブル内のポインタによって指し示されるＲＳＴパケット格納領域内にＲＳＴパケットを転送するようにしても良い。
【００３５】
また、所定の通信端点のシーケンス番号の初期値を上位レイヤによって設定可能な加算カウンタを具備し、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのパケットであると特定又は推定された場合に、当該パケットのＴＣＰヘッダ内のシーケンス番号と加算カウンタの値とが一致する場合に、下位レイヤから受け取ったフレームに格納されているパケットをメモリに転送するとともに、加算カウンタの値をインクリメントするようにしても良い。
【００３６】
また、複数のディスクリプタテーブルの各々が、下位レイヤから受け取ったフレーム又は下位レイヤから受け取ったフレームに格納されているパケットの解析結果を格納するための解析結果格納領域を更に含んでおり、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのパケットであると特定又は推定された場合に、第１のポインタ及びパケット書込み可否情報を利用して複数のディスクリプタテーブルの中からパケットを書き込むことが可能なパケット格納領域を指し示す１つのディスクリプタテーブルを決定し、下位レイヤから受け取ったフレームに格納されているパケットを当該ディスクリプタテーブル内の第２のポインタによって指し示されるパケット格納領域内に転送するとともに、下位レイヤから受け取ったフレーム又は下位レイヤから受け取ったフレームに格納されているパケットの解析結果を当該ディスクリプタテーブル内の解析結果格納領域に書き込むようにしても良い。
【００３７】
また、メモリが、複数の通信端点にそれぞれ対応する複数の通信端点情報領域を有しており、下位レイヤから受け取ったフレームに格納されているパケットが複数の通信端点のいずれかの通信端点宛てのパケットであると特定又は推定された場合に、複数の通信端点情報領域の中の当該パケットの宛先であると特定又は推定された通信端点に対応する通信端点情報領域の中のディスクリプタテーブル内で指し示されるパケット格納領域に当該パケットを書き込むようにしても良い。
【００３８】
また、メモリが、下位レイヤから受け取ったフレームに格納されているパケットのプロトコルが所定のプロトコルでない場合における当該フレーム又は下位レイヤから受け取ったフレームに格納されているパケットが複数の通信端点のいずれ宛てでもないパケットである場合における当該パケットを格納するための第２の通信端点情報領域を更に有しており、下位レイヤから受け取ったフレームに格納されているパケットのプロトコルが所定のプロトコルでない場合又は下位レイヤから受け取ったフレームに格納されているパケットが複数の通信端点のいずれ宛てでもないパケットである場合に、下位レイヤから受け取ったフレームに格納されているパケットのプロトコルが所定のプロトコルでない場合における当該フレーム又は下位レイヤから受け取ったフレームに格納されているパケットが複数の通信端点のいずれ宛てでもないパケットである場合における当該パケットを第２の通信端点情報領域の中のディスクリプタテーブル内で指し示されるパケット格納領域に転送するようにしても良い。
【００３９】
また、本発明に係る半導体集積回路は、本発明に係るＴＣＰ／ＩＰ受信処理回路を具備する。
【発明を実施するための最良の形態】
【００４０】
以下、図面を参照しながら、本発明の実施の形態について説明する。なお、同一の構成要素については、同一の参照番号で示している。
図１は、本発明の第１の実施形態としてのＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）受信処理回路を用いたコンピュータの概要を示すブロック図である。このコンピュータ１は、ネットワークＮに接続された物理層処理回路（ＰＨＹ）２と、ＭＡＣ（Media Access Control）処理回路３と、ＭＡＣブリッジ回路４と、本発明の第１の実施形態としてのＴＣＰ／ＩＰ受信処理回路５と、ＴＣＰ／ＩＰ送信処理回路６と、インタフェース回路７と、ＣＰＵ８と、メインメモリ９と、ＨＤＤ（ハードディスクドライブ）１０と、入力部１１と、表示部１２とを具備する。
【００４１】
本実施形態においては、ＴＣＰ／ＩＰ階層モデルのネットワークインタフェース層がEthernet（登録商標）であるものとし、物理層処理回路２、ＭＡＣ処理回路３、及び、ＭＡＣブリッジ回路４が、ネットワークインタフェース層を担うものとする。物理層処理回路２は、ネットワークＮに接続されており、ＭＡＣ処理回路３は、物理層処理回路２に接続されており、ＭＡＣブリッジ回路４は、ＭＡＣ処理回路３に接続されている。
【００４２】
また、ＴＣＰ／ＩＰ受信処理回路５、ＴＣＰ／ＩＰ送信処理回路６、及び、インタフェース回路７が、インターネット層及びトランスポート層の一部を担うものとする。ＴＣＰ／ＩＰ受信処理回路５及びＴＣＰ／ＩＰ送信処理回路６は、ＭＡＣブリッジ回路４とインタフェース回路７との間にそれぞれ接続されている。
【００４３】
また、ＣＰＵ８、メインメモリ９、ＨＤＤ１０、入力部１１、及び、表示部１２が、ＴＣＰ／ＩＰ階層モデルのインターネット層及びトランスポート層の一部とアプリケーション層を担うものとする。例えば、ＨＤＤ１０には、ＯＳ（オペレーティングシステム）、ＡＰＩ（Application Programming Interface）プログラム、メールクライアントプログラム、ウェブブラウザプログラム等が記録されており、ＣＰＵ８は、メインメモリ９を作業領域として使用しながら、これらのプログラムを実行する。ＣＰＵ８、メインメモリ９、ＨＤＤ１０、入力部１１、及び、表示部１２は、バスＢを介して接続されており、バスＢは、インタフェース回路７に接続されている。
【００４４】
ＴＣＰ／ＩＰ受信処理回路５は、フレーム等の解析を行うためのフレーム解析処理部２１と、フレーム解析処理部２１による解析結果を格納するための解析結果データ格納部２２と、パケット等を格納するためのＦＩＦＯ（First-In First-Out）バッファメモリ２３と、ＤＭＡ（Direct Memory Access）制御部２４と、ＤＭＡ制御部２４の制御下でＦＩＦＯバッファメモリ２３内に格納されているパケット等をメインメモリ９にＤＭＡ転送するＤＭＡ処理部２５と、パケットの宛先である通信端点を推定する通信端点推定処理部２６と、パケットの宛先である通信端点を推定するために用いる通信端点推定情報を格納する通信端点推定情報格納部２７とを具備する。ＤＭＡ制御部２４は、ＣＰＵ８のＩ／Ｏアドレス空間にマッピングされた複数のレジスタを有する。また、通信端点推定情報格納部２７は、ＣＰＵ８のＩ／Ｏアドレス空間にマッピングされている。
【００４５】
図２は、ＤＭＡ制御部２４内の複数のレジスタ及びメインメモリ９の内容の一例を示す図である。
アプリケーション層において通信端点を開設するためのＡＰＩがコールされると、開設された通信端点に対応する１群の領域が、ＡＰＩによりメインメモリ９内に形成される。図２においては、通信端点Ａ（ここでは、プロトコル  ＴＣＰ（Transmission Control Protocol）、自ＩＰアドレス  １９２．１６８．０．１、自ポート番号  ８０、相手ＩＰアドレス  １９２．１６８．０．２、相手ポート番号  ８０とする）に対応する第１群の領域と、通信端点Ｂ（ここでは、プロトコル  ＵＤＰ（User Datagram Protocol）、自ＩＰアドレス  １９２．１６８．０．１、自ポート番号  ６９、相手ＩＰアドレス  １９２．１６８．０．３、相手ポート番号  ６９とする）に対応する第２群の領域が示されている。
【００４６】
第１群の領域は、通信端点Ａ宛てのパケットをそれぞれ格納するための複数のパケット格納領域３１〜３ｍを含んでいる。パケット格納領域３１〜３ｍは、ヘッダ格納領域３１ａ〜３ｍａ及びペイロード格納領域３１ｂ〜３ｍｂをそれぞれ含んでいる。また、第１群の領域は、ヘッダ格納領域３１ａ〜３ｍａ及びペイロード格納領域３１ｂ〜３ｍｂへのポインタをそれぞれ有するディスクリプタテーブル４１〜４ｍを更に含んでいる。
【００４７】
図３は、ディスクリプタテーブル４１〜４ｍのフォーマットを示す図である。図３に示すように、ディスクリプタテーブル４１〜４ｍは、６ワード（本実施形態においては、１ワードは３２ビット幅とする）で構成されている。第１番目のワードは、当該ディスクリプタテーブルによって指し示されるパケット格納領域へのパケット書込みの可否に関する情報を格納するためのパケット書込み可否情報格納領域を含んでいる。パケット書込み可否情報格納領域は、当該ディスクリプタテーブルによって指し示されるパケット格納領域内にパケットが格納されているか否かを示す情報を格納するためのReceivedフィールド、及び当該ディスクリプタテーブルによって指し示されるパケット格納領域が使用可能か否かを示す情報を格納するためのUsableフィールドを含んでいる。
【００４８】
ディスクリプタテーブル４１〜４ｍの第１番目のワードは、当該ディスクリプタテーブルによって指し示されるパケット格納領域内に格納されているパケットの解析結果のレポートを格納するための解析レポート格納領域を更に含んでいる。解析レポート格納領域は、ＴＣＰヘッダ内のＦＩＮフラグ又はＲＳＴフラグ（図１４参照）がセットされているか否かを示す情報を格納するためのＦＩＮ，ＲＳＴフィールド、及びプロトコルの種類（ここでは、ＴＣＰ）を示す情報を格納するためのＰＲＯＴフィールドを含んでいる。
【００４９】
ディスクリプタテーブル４１〜４ｍの第２番目のワードは、当該ディスクリプタテーブルによって指し示されるヘッダ格納領域に格納可能なヘッダの最大サイズを示す情報を格納するためのＭＨＳフィールド（１３ビット幅）を含んでいる。このフィールドの値は、通信端点の開設時に設定される。また、ディスクリプタテーブル４１〜４ｍの第２番目のワードは、当該ディスクリプタテーブルによって指し示されるヘッダ格納領域に格納されているヘッダの実サイズを示す情報を格納するためのＲＨＳフィールド（１３ビット幅）を更に含んでいる。さらに、ディスクリプタテーブル４１〜４ｍの第２番目のワードは、ＲＨＳフィールドの値がＭＨＳフィールドの値より大きいというエラーが生じたことを示す情報を格納するためのＥＨＳフィールドを更に含んでいる。
【００５０】
ディスクリプタテーブル４１〜４ｍの第３番目のワードは、当該ディスクリプタテーブルによって指し示されるペイロード格納領域に格納可能なペイロードの最大サイズを示す情報を格納するためのＭＤＳフィールド（１３ビット幅）を含んでいる。このフィールドの値は、通信端点の開設時に設定される。また、ディスクリプタテーブル４１〜４ｍの第３番目のワードは、当該ディスクリプタテーブルによって指し示されるペイロード格納領域に格納されているペイロードの実サイズを示す情報を格納するためのＲＤＳフィールド（１３ビット幅）を更に含んでいる。さらに、ディスクリプタテーブル４１〜４ｍの第３番目のワードは、ＲＤＳフィールドの値がＭＤＳフィールドの値より大きいというエラーが生じたことを示す情報を格納するためのＥＤＳフィールドを更に含んでいる。
【００５１】
ディスクリプタテーブル４１〜４ｍの第４番目のワードは、次のディスクリプタテーブルを指し示すポインタ（アドレス）を格納するためのＮＰフィールド（３２ビット幅）を含んでいる。このＮＰフィールドにより、複数のディスクリプタテーブルが環状にリンクされている（図２参照）。これにより、パケット格納領域３１〜３ｍは、ＦＩＦＯバッファと同様に利用することが可能である。
【００５２】
ディスクリプタテーブル４１〜４ｍの第５番目のワードは、ヘッダ格納領域を指し示すポインタ（アドレス）を格納するためのＨＰフィールド（３２ビット幅）を含んでいる。
ディスクリプタテーブル４１〜４ｍの第６番目のワードは、ペイロード格納領域を指し示すポインタ（アドレス）を格納するためのＤＰフィールド（３２ビット幅）を含んでいる。
【００５３】
なお、通信端点を開設するためのＡＰＩは、ヘッダ格納領域３１ａ〜３ｍａ及びペイロード格納領域３１ｂ〜３ｍｂをそれぞれ異なるサイズにすることができる。ヘッダ格納領域３１ａ〜３ｍａ及びペイロード格納領域３１ｂ〜３ｍｂをそれぞれ異なるサイズとした場合であっても、ヘッダ格納領域３１ａ〜３ｍａ及びペイロード格納領域３１ｂ〜３ｍｂのサイズがディスクリプタテーブル４１〜４ｍのＭＨＳフィールド及びＭＤＳフィールドにそれぞれ設定されるため、ＴＣＰ／ＩＰ受信処理回路５は、ヘッダ格納領域３１ａ〜３ｍａ及びペイロード格納領域３１ｂ〜３ｍｂのサイズを検知することが可能である。
【００５４】
再び図２を参照すると、第１群の領域は、ＴＣＰのコネクションを切断するためのＲＳＴパケット（ＴＣＰヘッダ内のＲＳＴフラグ（図１４参照）がセットされたパケット）を格納するためのパケット格納領域５１を更に含んでいる。パケット格納領域５１は、ヘッダ格納領域５１ａ及びペイロード格納領域５１ｂを含んでいる。また、第１群の領域は、ヘッダ格納領域５１ａ及びペイロード格納領域５１ｂを指し示すディスクリプタテーブル５２を更に含んでいる。ディスクリプタテーブル５２のフォーマットは、図３に示すディスクリプタテーブル４１〜４ｍのフォーマットと同様である。このように、ＲＳＴパケットを格納するためのパケット格納領域５１をパケット格納領域３１〜３ｍと別個に設けることとしているのは、以下の理由による。すなわち、ＴＣＰにおいては、ＲＳＴパケットを受信することでセッションの切断指示を受け取ったことになる。そのため、パケット格納領域３１〜３ｍの全てにパケットが格納されているときに通信端点Ａ宛てのＲＳＴパケットを受信したような場合であっても、受信したＲＳＴパケットを確実にメインメモリ９内に転送及び格納し、アプリケーション層においてＴＣＰのコネクションの切断処理を確実に行うことができるようにし、セッションタイムアウトまで通信端点が機能せず、通信効率に多大な悪影響を及ぼすという事態が生ずる懸念を排除するためである。
【００５５】
さらに、第１群の領域は、通信端点Ａに関する情報を格納するための通信端点条件設定テーブル５３を更に含んでいる。
【００５６】
図４は、通信端点条件設定テーブル５３のフォーマットを示す図である。図４に示すように、通信端点条件設定テーブル５３は、５ワードと、１ハーフワードとで構成されている。第１番目のワードは、通信端点Ａのソース（自）ＩＰアドレスを格納するためのＳＯＵＲＣＥ＿ＩＰフィールド（３２ビット幅）を含んでいる。
【００５７】
通信端点条件設定テーブル５３の第２番目のワードは、通信端点Ａのデスティネーション（相手方）ＩＰアドレスを格納するためのＤＥＳＴ＿ＩＰフィールド（３２ビット幅）を含んでいる。
【００５８】
通信端点条件設定テーブル５３の第３番目のワードは、通信端点Ａのソース（自）ポート番号を格納するためのＳＯＵＲＣＥ＿ＰＮフィールド（１６ビット幅）と、通信端点Ａのデスティネーション（相手方）ポート番号を格納するためのＤＥＳＴ＿ＰＮフィールド（１６ビット幅）とを含んでいる。
【００５９】
通信端点条件設定テーブル５３の第４番目のワードは、通信端点Ａのシーケンス番号を格納するためのＳＥＱフィールド（３２ビット幅）を含んでいる。
【００６０】
通信端点条件設定テーブル５３の第５番目のワードは、通信端点Ａのアクノリッジ番号を格納するためのＡＣＫフィールド（３２ビット幅）を含んでいる。
【００６１】
通信端点条件設定テーブル５３の最後のハーフワードは、通信端点Ａのウィンドウサイズを格納するためのＷＩＮフィールド（１６ビット幅）を含んでいる。
【００６２】
再び図２を参照すると、通信端点Ｂに対応する第２群の領域は、通信端点Ｂ宛てのパケットをそれぞれ格納するための複数のパケット格納領域６１〜６ｎを含んでいる。パケット格納領域６１〜６ｎは、ヘッダ格納領域６１ａ〜６ｎａ及びペイロード格納領域６１ｂ〜６ｎｂをそれぞれ含んでいる。また、第２群の領域は、ヘッダ格納領域６１ａ〜６ｎａ及びペイロード格納領域６１ｂ〜６ｎｂへのポインタをそれぞれ有するディスクリプタテーブル７１〜７ｎと、通信端点Ｂに関する情報を格納するための通信端点条件設定テーブル８３とを更に含んでいる。
【００６３】
通信端点ＢのプロトコルはＵＤＰであり、通信端点Ｂ宛てのＲＳＴパケットというものは存在し得ない。そのため、第２群の領域は、先に説明した第１群の領域内のパケット格納領域５１及びディスクリプタテーブル５２のようなＲＳＴパケットを格納するための領域を含んでいない。
【００６４】
また、通信端点ＢのプロトコルはＵＤＰであり、通信端点Ｂ宛てのＦＩＮパケット、ＲＳＴパケットというものは存在し得ない。そのため、ディスクリプタテーブル７１〜７ｎは、図３に示すディスクリプタテーブル４１〜４ｍとほぼ同様であるが、第１番目のワードのＦＩＮ，ＲＳＴフィールドは不要である。
【００６５】
さらに、通信端点ＢのプロトコルはＵＤＰであり、通信端点Ｂにおいてはシーケンス番号、アクノリッジ番号、及び、ウィンドウサイズというものは存在しない。そのため、第２群の領域内の通信端点条件設定テーブル８３は、図４に示す通信端点条件設定テーブル５３の第１〜第３番目のワードの３ワード（ソースＩＰアドレス、デスティネーションＩＰアドレス、ソースポート番号、及び、デスティネーションポート番号）を有していれば足りる。
【００６６】
一方、ＤＭＡ制御部２４内のレジスタは、ＴＣＰの通信端点のための第１群のレジスタと、ＵＤＰの通信端点のための第２群のレジスタとに分けられている。これら第１及び第２群のレジスタの各々は、ソース（自）ＩＰアドレスを格納するための第１のフィールド、ソース（自）ポート番号を格納するための第２のフィールド、デスティネーション（相手方）ＩＰアドレスを格納するための第３のフィールド、デスティネーション（相手方）ポート番号を格納するための第４のフィールド、及び、第１〜第４のフィールドの値によって特定される通信端点に対応する複数のディスクリプタテーブルの中の１つを指し示すためのポインタ（アドレス）を格納するための第５のフィールドを含んでいる。
【００６７】
先に説明したように、ＤＭＡ制御部２４内のレジスタの各々は、ＣＰＵ８のＩ／Ｏアドレス空間にマッピングされており、ＣＰＵ８からＩ／Ｏとしてアクセス可能である。そして、アプリケーション層において通信端点を開設するためのＡＰＩがコールされると、開設された通信端点に対応するディスクリプタテーブル、パケット格納領域等が、ＡＰＩによりメインメモリ９内に形成されるとともに、開設された通信端点を特定するソース（自）ＩＰアドレス、ソース（自）ポート番号、デスティネーション（相手方）ＩＰアドレス、及び、デスティネーション（相手方）ポート番号、並びに、開設された通信端点に対応する複数のディスクリプタテーブルの中の１つのディスクリプタテーブル（ここでは、先頭のディスクリプタテーブル）を指し示すためのポインタ（アドレス）が、ＡＰＩによりＤＭＡ制御部２４内のレジスタに書き込まれる。
【００６８】
なお、コンピュータ１が、ＴＣＰ又はＵＤＰ以外のトランスポート層のプロトコル（例えば、ＩＣＭＰ（Internet Control Message Protocol）等）、ＩＰバージョン４以外のネットワーク層のプロトコル（例えば、ＡＲＰ（Address Resolution Protocol）、ＲＡＲＰ（Reverse Address Resolution Protocol）、ＩＰバージョン６等）のパケットを受信する場合がある。そのような場合のため、メインメモリ９内には、ＴＣＰ若しくはＵＤＰ以外のトランスポート層のプロトコル又はＩＰバージョン４以外のネットワーク層のプロトコルのパケットを格納するための１群の領域（以下、「ジャンクバッファ」という）が予め用意されている。ジャンクバッファは、ＴＣＰ若しくはＵＤＰ以外のトランスポート層のプロトコル又はＩＰバージョン４以外のネットワーク層のプロトコルのパケットを格納するための複数のパケット格納領域及びこれら複数のパケット格納領域へのポインタをそれぞれ有する複数のディスクリプタテーブルを含んでいる。
【００６９】
図５（ａ）は、メインメモリ９内のジャンクバッファを示す図である。ここでは、ジャンクバッファは、複数のパケット格納領域９１〜９ｐ及びディスクリプタテーブル１０１〜１０ｐを含んでいる。
【００７０】
図５（ｂ）は、ディスクリプタテーブル１０１〜１０ｐのフォーマットを示す図である。図５（ｂ）に示すように、ディスクリプタテーブル１０１〜１０ｐは、６ワードで構成されている。第１番目のワードは、当該ディスクリプタテーブルによって指し示されるパケット格納領域へのパケット書込みの可否に関する情報を格納するためのパケット書込み可否情報格納領域を含んでいる。ここでは、パケット書込み可否情報格納領域は、当該ディスクリプタテーブルによって指し示されるパケット格納領域内にパケットが格納されているか否かを示す情報を格納するためのReceivedフィールド、及び当該ディスクリプタテーブルによって指し示されるパケット格納領域が使用可能か否かを示す情報を格納するためのUsableフィールドを含んでいる。
【００７１】
ディスクリプタテーブル１０１〜１０ｐの第１番目のワードは、当該ディスクリプタテーブルによって指し示されるパケット格納領域内に格納されているパケットの解析結果のレポートを格納するための解析レポート格納領域を含んでいる。ここでは、解析レポート格納領域は、プロトコルの種類を示す情報を格納するためのＰＲＯＴフィールドを含んでいる。
【００７２】
ディスクリプタテーブル１０１〜１０ｐの第２番目のワードは、当該ディスクリプタテーブルによって指し示されるヘッダ格納領域に格納可能なパケットの最大サイズを示す情報を格納するためのＭＳフィールド（１３ビット幅）を含んでいる。このフィールドの値は、初期時に設定される。また、ディスクリプタテーブル１０１〜１０ｐの第２番目のワードは、当該ディスクリプタテーブルによって指し示されるパケット格納領域に格納されているパケットの実サイズを示す情報を格納するためのＲＳフィールド（１３ビット幅）を更に含んでいる。さらに、ディスクリプタテーブル１０１〜１０ｐの第２番目のワードは、ＲＳフィールドの値がＭＳフィールドの値より大きいというエラーが生じたことを示す情報を格納するためのＥＳフィールドを更に含んでいる。
【００７３】
ディスクリプタテーブル１０１〜１０ｐの第３番目のワードは、未使用となっている。  ディスクリプタテーブル１０１〜１０ｐの第４番目のワードは、次のディスクリプタテーブルを指し示すポインタ（アドレス）を格納するためのＮＰフィールド（３２ビット幅）を含んでいる。このＮＰフィールドにより、複数のディスクリプタテーブルが環状にリンクされている（図５（ａ）参照）。これにより、パケット格納領域９１〜９ｐは、ＦＩＦＯバッファと同様に利用することが可能である。
【００７４】
ディスクリプタテーブル１０１〜１０ｐの第５番目のワードは、パケット格納領域を指し示すポインタ（アドレス）を格納するためのＰＰフィールド（３２ビット幅）を含んでいる。
ディスクリプタテーブル１０１〜１０ｐの第６番目のワードは、未使用となっている。
【００７５】
図６は、通信端点推定情報格納部２７に格納される通信端点推定情報のフォーマットを示す図である。通信端点推定情報は、通信端点を推定するために用いられる情報である。
【００７６】
先に説明したように、通信端点は、プロトコル（ＴＣＰ又はＵＤＰ）、ソース（自）ＩＰアドレス、ソース（自）ポート番号、デスティネーション（相手方）ＩＰアドレス、デスティネーション（相手方）ポート番号（以下、「通信端点特定情報」という）によって特定される。ＴＣＰ又はＵＤＰを区別するために１ビットが必要であり、ソース（自）ＩＰアドレス及びデスティネーション（相手方）ＩＰアドレスは、それぞれ３２ビット幅であり、ソース（自）ポート番号及びデスティネーション（相手方）ポート番号は、それぞれ１６ビット幅である。従って、通信端点を特定するためには、９７ビット幅の照合（パターンマッチング）が必要であるが、９７ビット幅の照合（パターンマッチング）には、長い時間が必要である。
【００７７】
そこで、アプリケーション層において通信端点を開設するためのＡＰＩがコールされると、開設された通信端点を推定するための通信端点推定情報が、ＡＰＩにより通信端点推定情報格納部２７に書き込まれる。本実施形態においては、通信端点推定情報が、図６に示すように、ＴＣＰ又はＵＤＰの区分１ビット、ソース（自）ＩＰアドレスの上位（ＭＳＢ（Most Significant Bit）側）２ビット、ソース（自）ＩＰアドレスの下位（ＬＳＢ（Least Significant Bit）側）２ビット、ソース（自）ポート番号の上位（ＭＳＢ側）２ビット、ソース（自）ポート番号の下位（ＬＳＢ側）２ビット、デスティネーション（相手）ＩＰアドレスの上位（ＭＳＢ側）２ビット、デスティネーション（相手）ＩＰアドレスの下位（ＬＳＢ側）２ビット、デスティネーション（相手）ポート番号の上位（ＭＳＢ側）２ビット、デスティネーション（相手）ポート番号の下位（ＬＳＢ側）２ビットの計１７ビットを含むものとする。すなわち、通信端点を推定するためには、１７ビット幅の照合（パターンマッチング）を行えばよいこととなる。１７ビット幅の照合（パターンマッチング）は、比較的短い時間で行うことが可能である。
【００７８】
通信端点推定情報格納部２７には、通信端点推定情報によって推定される通信端点に対応する複数のディスクリプタテーブルの中の１つのディスクリプタテーブル（ここでは、先頭のディスクリプタテーブル）を指し示すためのポインタ（アドレス）が対応づけて格納されている。
【００７９】
次に、ＴＣＰ／ＩＰ受信処理回路５の動作について説明する。図７は、ＴＣＰ／ＩＰ受信処理回路５の動作を示すフローチャートである。ＴＣＰ／ＩＰ受信処理回路５は、ネットワークインタフェース層のＭＡＣブリッジ回路４からフレームを受け取ると、図７に示す処理を開始する。
【００８０】
まず、ＴＣＰ／ＩＰ受信処理回路５内のフレーム解析処理部２１が、ＭＡＣブリッジ回路４から受け取ったフレームの末尾に付加されているフレームチェックシーケンス（Frame Check Sequence）内のＣＲＣ（Cyclic Redundancy Check）を用いて、フレームの検証を行う（ステップＳ１１）。なお、ＣＲＣエラーがあった場合、フレーム解析処理部２１は、フレームを廃棄する。
【００８１】
次に、フレーム解析処理部２１は、ＩＰのヘッダ・チェックサム（図１２参照）を用いたＩＰパケットの検証（ステップＳ１２）、並びにＴＣＰ又はＵＤＰのチェックサム（図１４及び図１５参照）を用いたＴＣＰ又はＵＤＰパケットの検証（ステップＳ１３）を行うとともに、これらと並行して、フレームのペイロードに格納されているパケットのフォーマット解析を行う（ステップＳ１４）。これは、フレーム解析処理部２１がＩＰパケットの検証並びにＴＣＰ又はＵＤＰパケットの検証を行うハードウェア回路とパケットのフォーマット解析を行うハードウェア回路とを別個に具備することにより、実現可能である。なお、このように、異なる処理を並行して行うことは、ソフトウェア工学の分野における「ｆｏｒｋ」及び「ｊｏｉｎ」に相当するものと考えることができる。
【００８２】
フレーム解析処理部２１が行うパケットのフォーマット解析は、フレームのペイロードに格納されているパケットのプロトコルが所定のプロトコル（本実施形態においては、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＴＣＰ、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＵＤＰ、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＩＣＭＰ、インターネット層のプロトコルがＡＲＰ、又は、インターネット層のプロトコルがＲＡＲＰとする）であるか否かを調べることを含む。所定のプロトコルであるか否かは、パケットが図１２〜図１６に示すフォーマットに合致するか否かにより判断することが可能である。
【００８３】
フレーム解析処理部２１が解析結果データ格納部２２に書き込む解析結果には、プロトコル（本実施形態においては、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＴＣＰ、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＵＤＰ、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＩＣＭＰ、インターネット層のプロトコルがＡＲＰ、又は、インターネット層のプロトコルがＲＡＲＰ）、及びパケットのサイズが含まれる。さらに、フレームのペイロードに格納されているパケットのインターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＴＣＰ又はインターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＵＤＰである場合には、フレーム解析処理部２１が解析結果データ格納部２２に書き込む解析結果には、ＴＣＰヘッダ又はＵＤＰヘッダのサイズと、ＴＣＰペイロード又はＵＤＰペイロードのサイズと、通信端点を特定するための情報（ソース（自）ＩＰアドレス、ソース（自）ポート番号、デスティネーション（相手）ＩＰアドレス、及び、デスティネーション（相手）ポート番号）とが更に含まれる。なお、ソース（自）ＩＰアドレス及びデスティネーション（相手）ＩＰアドレスは、ＩＰヘッダ（図１２参照）に格納されており、ソース（自）ポート番号及びデスティネーション（相手）ポート番号）は、ＴＣＰヘッダ（図１４参照）又はＵＤＰヘッダ（図１５参照）に格納されている。
【００８４】
フレーム解析処理部２１は、フレームのペイロードに格納されているパケットのプロトコルが所定のプロトコルではない（例えば、フレームのペイロードに格納されているパケットのネットワーク層のプロトコルがＩＰバージョン６である場合や、フレームのペイロードに格納されているパケットのネットワーク層のプロトコルがＩＰではあるがトランスポート層のプロトコルがＴＣＰ、ＵＤＰ、又は、ＩＣＭＰ以外のプロトコルである場合等）と判断した場合には、フレームをそのままＦＩＦＯバッファメモリ２３に書き込み、ＤＭＡ制御部２４及びＤＭＡ処理部２５が、このフレームをメインメモリ９内のジャンクバッファに転送する。ジャンクバッファに転送されたフレームは、ＣＰＵとソフトウェア（プログラム）でインターネット層及びトランスポート層の処理がされる。
【００８５】
また、フレーム解析処理部２１は、フレームのペイロードに格納されているパケットのプロトコルがＡＲＰ又はＲＡＲＰである場合、ＡＲＰパケット又はＲＡＲＰパケットをＦＩＦＯバッファメモリ２３に書き込む。
【００８６】
さらに、フレームのペイロードに格納されているパケットのプロトコルがＩＰである場合、フレーム解析処理部２１が、ＩＰパケットのペイロードに格納されているパケット（本実施形態においては、ＴＣＰパケット、ＵＤＰパケット、又は、ＩＣＭＰパケット）をＦＩＦＯバッファメモリ２３に書き込む。
【００８７】
なお、フレーム解析処理部２１が、ＣＰＵ８のＩ／Ｏアドレス空間にマッピングされた複数の自動加算カウンタを具備していることとし、ＴＣＰの通信端点の開設時において、ＴＣＰの通信端点のシーケンス番号の初期値が、いずれかの自動加算カウンタにＡＰＩにより書き込まれるようにしても良い。そして、フレーム解析処理部２１が、ＴＣＰの通信端点宛てのパケットが格納されたフレームをＭＡＣブリッジ回路４から受け取った場合に、当該パケット中のシーケンス番号（図１２参照）と自動加算カウンタの値とが一致するときには当該パケットをＦＩＦＯバッファメモリ２３に書き込むとともに自動加算カウンタをインクリメントし、当該パケット中のシーケンス番号と自動加算カウンタの値とが一致しないときには当該パケットを廃棄するようにしても良い。ＴＣＰにおいては、シーケンス番号の一致性を検証することで、パケット到達の順序性と基本的な通信路の安全性を得る。一般に、１つの論理的データストリームは複数の受信パケットで構成される場合が多く、上記のように自動加算カウンタを具備することにより、パケット受信の可否をソフトウェアで行う必要をなくすことが可能となる。
【００８８】
フレーム解析処理部２１による処理（ステップＳ１２〜Ｓ１４）が終了すると、ＤＭＡ制御部２４が、通信端点の特定を行い（ステップＳ１５）、通信端点推定処理部２６が、通信端点の推定を行う（ステップＳ１６）。なお、このように、異なる処理を並行して行うことは、ソフトウェア工学の分野における「ｆｏｒｋ」及び「ｊｏｉｎ」に相当するものと考えることができる。
【００８９】
ＤＭＡ制御部２４は、解析結果データ格納部２２に格納されている解析結果の内のプロトコルを参照し、ＦＩＦＯバッファメモリ２３に格納されているパケット等（パケット又はフレーム）がＴＣＰ又はＵＤＰパケットである場合には、解析結果データ格納部２２に格納されている解析結果の内の通信端点を特定するための情報（ソース（自）ＩＰアドレス、ソース（自）ポート番号、デスティネーション（相手）ＩＰアドレス、及び、デスティネーション（相手）ポート番号）を更に参照し、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットがいずれかの通信端点宛てのものであるか否かをチェックする。具体的には、ＤＭＡ制御部２４内のレジスタには、先に説明したように、開設された通信端点を特定するための情報が格納されており（図２参照）、ＤＭＡ制御部２４は、解析結果データ格納部２２に格納されている解析結果の内の通信端点を特定するための情報とレジスタの内容とを照合（パターンマッチング）することにより、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットの宛先である通信端点を特定することが可能である。または、ＤＭＡ制御部２４は、解析結果データ格納部２２に格納されている解析結果の内の通信端点を特定するための情報と、メインメモリ９内の通信端点条件設定テーブル５３の内容とを照合することにより、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットがいずれかの通信端点宛てのものであるか否かをチェックすることができる。この照合（パターンマッチング）は、９７ビット幅の照合（パターンマッチング）であるため、長い時間を必要とする。
【００９０】
一方、通信端点推定処理部２６は、解析結果データ格納部２２に格納されている解析結果の内のＴＣＰ又はＵＤＰの区分１ビット、ソース（自）ＩＰアドレスの上位（ＭＳＢ側）２ビット、ソース（自）ＩＰアドレスの下位（ＬＳＢ側）２ビット、ソース（自）ポート番号の上位（ＭＳＢ側）２ビット、ソース（自）ポート番号の下位（ＬＳＢ側）２ビット、デスティネーション（相手）ＩＰアドレスの上位（ＭＳＢ側）２ビット、デスティネーション（相手）ＩＰアドレスの下位（ＬＳＢ側）２ビット、デスティネーション（相手）ポート番号の上位（ＭＳＢ側）２ビット、デスティネーション（相手）ポート番号の下位（ＬＳＢ側）２ビットの計１７ビットと、通信端点推定情報格納部２７に格納されている通信端点推定情報（図６参照）とを照合（パターンマッチング）することにより、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットの宛先である通信端点を推定する（ステップＳ１６）。推定結果としてのディスクリプタテーブルへのポインタ（図６参照）は、ＤＭＡ制御部２４に送られる。
【００９１】
ＤＭＡ制御部２４のハードウェアの一部分は、通信端点の特定（ステップＳ１５）を実行しており、ＤＭＡ制御部２４のハードウェアの他の一部分は、通信端点推定処理部２６から送られてきたポインタを用いて、パケットの宛先であると推定された通信端点のパケット格納可能なディスクリプタテーブル（図２参照）をメインメモリ９から読み込む（ステップＳ１７）。そして、ＤＭＡ制御部２４のハードウェアの他の一部分は、ＦＩＦＯバッファメモリ２３に格納されているパケットのステップＳ１７にて読み込んだディスクリプタテーブルによって指し示されるパケット格納領域（図２参照）へのＤＭＡ転送を開始するように、ＤＭＡ処理部２５を制御する（ステップＳ１８）。
【００９２】
具体的には、ＦＩＦＯバッファメモリ２３に格納されているパケットが通信端点Ａ宛てのＴＣＰパケットであると推定された場合、ＤＭＡ制御部２４は、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰパケットのパケット格納領域３１〜３ｍ（図２参照）への転送を開始するようにＤＭＡ処理部２５を制御する。なお、パケット格納領域３１〜３ｍのいずれをＤＭＡ転送先にするかは、通信端点推定情報（図６参照）内のポインタ（アドレス）からディスクリプタテーブル４１〜４ｍ内のパケット書込み可否情報格納領域（図３参照）を順次参照し、パケットの書込みが可能なパケット格納領域を探すことにより、決定することができる。また、ＤＭＡ転送量（ＤＭＡ転送データサイズ）は、解析結果データ格納部２２に格納されているＴＣＰヘッダサイズ及びＴＣＰペイロードサイズを参照することにより、決定することができる。なお、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰパケットのヘッダ又はペイロードのサイズが転送先のヘッダ格納領域又はペイロード格納領域のサイズ（図３中のＭＨＳフィールド又はＭＤＳフィールドにより検知可能）を超えている場合には、ＤＭＡ制御部２４が、当該パケットのヘッダ又はペイロードの内の転送先のヘッダ格納領域又はペイロード格納領域に格納可能な部分のみをＤＭＡ転送し、当該パケットのヘッダ又はペイロードの内の転送先のヘッダ格納領域又はペイロード格納領域のサイズを超えている部分をＤＭＡ転送しないようにしても良い。
【００９３】
同様に、ＦＩＦＯバッファメモリ２３に格納されているパケットが通信端点Ｂ宛てのＵＤＰパケットであると推定された場合、ＤＭＡ制御部２４は、ＦＩＦＯバッファメモリ２３に格納されているＵＤＰパケットのパケット格納領域６１〜６ｎ（図２参照）への転送を開始するようにＤＭＡ処理部２５を制御する。なお、パケット格納領域６１〜６ｎのいずれをＤＭＡ転送先にするかは、レジスタ内のポインタ（アドレス）からディスクリプタテーブル７１〜７ｎ内のパケット書込み可否情報格納領域（図３参照）を順次参照し、パケットの書込みが可能なパケット格納領域を探すことにより、決定することができる。また、ＤＭＡ転送量（ＤＭＡ転送データサイズ）は、解析結果データ格納部２２に格納されているＵＤＰヘッダサイズ及びＵＤＰペイロードサイズを参照することにより、決定することができる。なお、ＦＩＦＯバッファメモリ２３に格納されているＵＤＰパケットのヘッダ又はペイロードのサイズが転送先のヘッダ格納領域又はペイロード格納領域のサイズ（図３中のＭＨＳフィールド又はＭＤＳフィールドにより検知可能）を超えている場合には、ＤＭＡ制御部２４が、当該パケットのヘッダ又はペイロードの内の転送先のヘッダ格納領域又はペイロード格納領域に格納可能な部分のみをＤＭＡ転送し、当該パケットのヘッダ又はペイロードの内の転送先のヘッダ格納領域又はペイロード格納領域のサイズを超えている部分をＤＭＡ転送しないようにしても良い。
【００９４】
通信端点の特定（ステップＳ１５）、並びに、通信端点の推定及びディスクリプタテーブルの読み込み及びＤＭＡ転送の開始（ステップＳ１６〜ステップＳ１８）が終了すると、ＤＭＡ制御部２４は、ステップＳ１５にて特定された通信端点とステップＳ１６にて推定された通信端点とが一致するか否かをチェックする。そして、ステップＳ１５にて特定された通信端点とステップＳ１６にて推定された通信端点とが一致する場合には、ＤＭＡ制御部２４は、処理を終了し、ＤＭＡ処理部２５は、ステップＳ１８にて開始されたＤＭＡ転送を継続して行う。一方、ステップＳ１５にて特定された通信端点とステップＳ１６にて推定された通信端点とが一致しない場合には、ＤＭＡ制御部２４は、処理をステップＳ２０に移す（ステップＳ１９）。
【００９５】
ステップＳ１５にて特定された通信端点とステップＳ１６にて推定された通信端点とが一致しない場合、ＤＭＡ制御部２４は、ステップＳ１８にて開始させたＤＭＡ転送を中止するように、ＤＭＡ処理部２５を制御する（ステップＳ２０）。
【００９６】
次に、ＤＭＡ制御部２４は、パケットの宛先であると特定された通信端点のパケット格納可能なディスクリプタテーブル（図２参照）をメインメモリ９から読み込む（ステップＳ２１）。そして、ＤＭＡ制御部２４は、ＦＩＦＯバッファメモリ２３に格納されているパケットのステップＳ２１にて読み込んだディスクリプタテーブルによって指し示されるパケット格納領域（図２参照）へのＤＭＡ転送を開始するように、ＤＭＡ処理部２５を制御し（ステップＳ２２）、処理を終了する。
【００９７】
なお、ＤＭＡ制御部２４が、ＣＰＵ８のＩ／Ｏアドレス空間にマッピングされた複数の減算カウンタを具備していることとし、通信端点の開設時において、通信端点の論理的データストリームブロック（これは、ウィンドウバッファサイズであっても良い）の初期サイズが、いずれかの減算カウンタにＡＰＩにより書き込まれるようにしても良い。そして、ＤＭＡ制御部２４が、ステップＳ２３において、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットのペイロード部をＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットの宛先である通信端点のペイロード格納領域にＤＭＡ転送する都度、通信端点に対応する減算カウンタの値をＤＭＡ転送量だけ減算するようにしても良い。そして、ＤＭＡ制御部２４が、減算カウンタが０になるまでＣＰＵ８にパケット受信通知制御信号を出力せず、減算カウンタが０になったときにＣＰＵ８にパケット受信通知制御信号を出力するようにすれば、アプリケーション層は複数の受信パケットで構成される固定長論理データストリームを一括して扱うことができ、ソフトウェアオーバーヘッドの削減（タスクスイッチングや割り込み発生回数の削減等）が可能となる。また、ＤＭＡ制御部２４が、ペイロードの内の減算カウンタの値を超える部分をＤＭＡ転送しないようにしても良い。
【００９８】
以上説明したように、本実施形態によれば、ＤＭＡ制御部２４のハードウェアの一部分がパケットの宛先である通信端点を特定している間に、通信端点推定処理部２６が、パケットの宛先である通信端点を推定し、ＤＭＡ制御部２４のハードウェアの他の一部分が、推定された通信端点に対応するパケット格納領域へのパケットのＤＭＡ転送を開始させることができる。通信端点推定処理部２６は、例えば、１７ビット幅のコンパレータ等を用いて実現可能である。このように、ハードウェア量の増加を抑えながら、パケットのＤＭＡ転送の開始を早くすることができ、通信スループットの低下を抑えることが可能となる。また、パケットの宛先であると特定された通信端点とパケットの宛先であると推定された通信端点とが一致しない場合、パケットの宛先であると推定された通信端点へのパケットのＤＭＡ転送を中止し、パケットの宛先であると特定された通信端点へのパケットのＤＭＡ転送を開始することができるので、通信端点の推定に誤りがあった場合であっても、パケットを正しい宛先である通信端点に届けることが可能である。
【００９９】
なお、本実施形態においては、通信端点推定情報が、ＴＣＰ又はＵＤＰの区分１ビット、ソース（自）ＩＰアドレスの上位（ＭＳＢ側）２ビット、ソース（自）ＩＰアドレスの下位（ＬＳＢ側）２ビット、ソース（自）ポート番号の上位（ＭＳＢ側）２ビット、ソース（自）ポート番号の下位（ＬＳＢ側）２ビット、デスティネーション（相手）ＩＰアドレスの上位（ＭＳＢ側）２ビット、デスティネーション（相手）ＩＰアドレスの下位（ＬＳＢ側）２ビット、デスティネーション（相手）ポート番号の上位（ＭＳＢ側）２ビット、デスティネーション（相手）ポート番号の下位（ＬＳＢ側）２ビットの計１７ビットを含むものとしているが、より多いビットを含むこととしても良いし、より少ないビットを含むこととしても良い。通信端点推定情報がより多いビットを含むこととすれば、推定した通信端点と特定した通信端点とが一致する可能性が高くなるが、通信端点の推定処理（ステップＳ１６参照）の負荷が大きくなる。一方、通信端点推定情報がより少ないビットを含むこととすれば、通信端点の推定処理（ステップＳ１６参照）の負荷が小さくなるが、推定した通信端点と特定した通信端点とが一致する可能性が低くなる。また、通信端点推定情報が、ソース（自）ＩＰアドレスの他の部分、ソース（自）ポート番号の他の部分、デスティネーション（相手）ＩＰアドレスの他の部分、デスティネーション（相手）ポート番号の他の部分を含むようにしてもよい。
【０１００】
また、本実施形態によれば、ディスクリプタテーブルをリンクしておくことにより、ＴＣＰ／ＩＰ受信処理回路５がＴＣＰ又はＵＤＰの通信端点宛てのパケットをメインメモリ９内のパケット格納領域に転送することを簡素化でき、アプリケーション層が受信パケットの個数で定義される論理的データストリームブロックを容易に扱うことができる。
【０１０１】
また、本実施形態によれば、ＴＣＰ又はＵＤＰの通信端点宛てのパケットのヘッダ及びペイロードを、メインメモリ９内に設けられたヘッダ格納領域及びペイロード格納領域に転送することができる。これにより、アプリケーション層は、１つの通信端点宛ての複数のパケットが存在する場合に、ヘッダを参照することなく、ペイロードのみを自在に利用することができる。このとき、複数のペイロード格納領域を連続するアドレスに配置しておけば、アプリケーション層が複数のペイロードを連続してアクセスすることが容易となる。
【０１０２】
また、本実施形態においては、ＴＣＰ又はＵＤＰの通信端点宛てのパケットのヘッダ又はペイロードのサイズが転送先のヘッダ格納領域又はペイロード格納領域のサイズを超えている場合には、当該パケットのヘッダ又はペイロードの内の転送先のヘッダ格納領域又はペイロード格納領域のサイズを超えている部分はＤＭＡ転送されない。従って、仮に第三者が不正なパケットをコンピュータ１に送信し、不正なパケットがＴＣＰ又はＵＤＰの通信端点の設定条件に合致してしまった場合であっても、不正なパケットのヘッダ又はペイロードの内の転送先のヘッダ格納領域又はペイロード格納領域のサイズを超えている部分はＤＭＡ転送されず、不正なパケットによりＯＳ、ＡＰＩ、又は、アプリケーションプログラムのワークエリアが上書きされてしまうことがない。これにより、第三者によるクラッキング等を防止することが可能である。
【０１０３】
なお、本実施形態においては、ネットワークインタフェース層としてEthernet（登録商標）を用いることとしているが、他のものを用いるようにしても良い。また、アプリケーション層として、ＨＴＴＰ（Hyper Text Transfer Protocol）等、種々のものを用いることが可能である。
【０１０４】
次に、本発明の第２の実施形態について説明する。図８は、本発明の第２の実施形態としてのＴＣＰ／ＩＰ受信処理回路を用いたコンピュータの概要を示すブロック図である。このコンピュータ１３は、ネットワークＮに接続された物理層処理回路２と、ＭＡＣ処理回路３と、ＭＡＣブリッジ回路４と、ＴＣＰ／ＩＰ送信処理回路６と、インタフェース回路７と、ＣＰＵ８と、メインメモリ９と、ＨＤＤ１０と、入力部１１と、表示部１２と、本発明の第２の実施形態としてのＴＣＰ／ＩＰ受信処理回路１４とを具備する。
【０１０５】
本実施形態においては、ＴＣＰ／ＩＰ送信処理回路６、インタフェース回路７、及び、ＴＣＰ／ＩＰ受信処理回路１４が、インターネット層及びトランスポート層を担うものとする。ＴＣＰ／ＩＰ送信処理回路６及びＴＣＰ／ＩＰ受信処理回路１４は、ＭＡＣブリッジ回路４とインタフェース回路７との間にそれぞれ接続されている。
【０１０６】
ＴＣＰ／ＩＰ受信処理回路１４は、フレーム解析処理部２１と、解析結果データ格納部２２と、ＦＩＦＯバッファメモリ２３と、ＤＭＡ制御部２４と、ＤＭＡ処理部２５と、通信端点推定情報格納部２７と、パケットの宛先である通信端点を推定する通信端点推定処理部２８とを具備する。
【０１０７】
次に、ＴＣＰ／ＩＰ受信処理回路１４の動作について説明する。図９は、ＴＣＰ／ＩＰ受信処理回路１４の動作を示すフローチャートである。ＴＣＰ／ＩＰ受信処理回路１４は、ネットワークインタフェース層のＭＡＣブリッジ回路４からフレームを受け取ると、図９に示す処理を開始する。
【０１０８】
まず、ＴＣＰ／ＩＰ受信処理回路１４内のフレーム解析処理部２１が、ＭＡＣブリッジ回路４から受け取ったフレームの末尾に付加されているフレームチェックシーケンス内のＣＲＣを用いて、フレームの検証を行う（ステップＳ３１）。なお、ＣＲＣエラーがあった場合、フレーム解析処理部２１は、フレームを廃棄する。
【０１０９】
次に、フレーム解析処理部２１は、ＩＰのヘッダ・チェックサム（図１２参照）を用いたＩＰパケットの検証（ステップＳ３２）、並びにＴＣＰ又はＵＤＰのチェックサム（図１４及び図１５参照）を用いたＴＣＰ又はＵＤＰパケットの検証（ステップＳ３３）を行うとともに、これらと並行して、フレームのペイロードに格納されているパケットのフォーマット解析を行う（ステップＳ３４）。これは、フレーム解析処理部２１がＩＰパケットの検証並びにＴＣＰ又はＵＤＰパケットの検証を行うハードウェア回路とパケットのフォーマット解析を行うハードウェア回路とを別個に具備することにより、実現可能である。なお、このように、異なる処理を並行して行うことは、ソフトウェア工学の分野における「ｆｏｒｋ」及び「ｊｏｉｎ」に相当するものと考えることができる。
【０１１０】
フレーム解析処理部２１の処理（ステップＳ３２〜Ｓ３４）が終了すると、ＤＭＡ制御部２４が、通信端点の特定を行う（ステップＳ３５）。
【０１１１】
一方、ネットワークインタフェース層のＭＡＣブリッジ回路４からのフレームは通信端点推定処理部２８にも入力されており、通信端点推定処理部２８は、フレーム解析処理部２１の処理（ステップＳ３２〜Ｓ３４）及びＤＭＡ制御部２４の処理（ステップＳ３５）と並行して、通信端点の推定に必要な情報をフレームから抽出する（ステップＳ３６）。通信端点推定処理部２８がフレームから抽出する情報は、本実施形態においては、ＴＣＰ又はＵＤＰの区分（１ビット）、ソース（自）ＩＰアドレスの上位（ＭＳＢ側）２ビット、ソース（自）ＩＰアドレスの下位（ＬＳＢ側）２ビット、ソース（自）ポート番号の上位（ＭＳＢ側）２ビット、ソース（自）ポート番号の下位（ＬＳＢ側）２ビット、デスティネーション（相手）ＩＰアドレスの上位（ＭＳＢ側）２ビット、デスティネーション（相手）ＩＰアドレスの下位（ＬＳＢ側）２ビット、デスティネーション（相手）ポート番号の上位（ＭＳＢ側）２ビット、デスティネーション（相手）ポート番号の下位（ＬＳＢ側）２ビットである。なお、このように、異なる処理を並行して行うことは、ソフトウェア工学の分野における「ｆｏｒｋ」及び「ｊｏｉｎ」に相当するものと考えることができる。
【０１１２】
次に、通信端点推定処理部２８は、ステップＳ３６にてフレームから抽出した情報と、通信端点推定情報格納部２７に格納されている通信端点推定情報（図６参照）とを照合（パターンマッチング）することにより、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットの宛先である通信端点を推定する（ステップＳ３７）。推定結果としてのディスクリプタテーブルへのポインタ（図６参照）は、ＤＭＡ制御部２４に送られる。
【０１１３】
ＤＭＡ制御部２４のハードウェアの一部分は、通信端点の特定（ステップＳ３５）を実行しており、ＤＭＡ制御部２４のハードウェアの他の一部分は、通信端点推定処理部２８から送られてきたポインタを用いて、パケットの宛先であると推定された通信端点のパケット格納可能なディスクリプタテーブル（図２参照）をメインメモリ９から読み込む（ステップＳ３８）。そして、ＤＭＡ制御部２４のハードウェアの他の一部分は、ＦＩＦＯバッファメモリ２３に格納されているパケットのステップＳ３８にて読み込んだディスクリプタテーブルによって指し示されるパケット格納領域（図２参照）へのＤＭＡ転送を開始するように、ＤＭＡ処理部２５を制御する（ステップＳ３９）。
【０１１４】
ＩＰのヘッダ・チェックサムを用いたＩＰパケットの検証（ステップＳ３２）、ＴＣＰ又はＵＤＰのチェックサムを用いたＴＣＰ又はＵＤＰパケットの検証（ステップＳ３３）、パケットのフォーマット解析（ステップＳ３４）、通信端点の特定（ステップＳ３５）、通信端点の推定に必要な情報のフレームからの抽出（ステップＳ３６）、通信端点の推定（ステップＳ３７）、ディスクリプタテーブルの読み込み（ステップＳ３８）、並びに、ＤＭＡ転送の開始（ステップＳ３９）が終了すると、ＤＭＡ制御部２４は、ステップＳ３５にて特定された通信端点とステップＳ３７にて推定された通信端点とが一致するか否かをチェックする。そして、ステップＳ３５にて特定された通信端点とステップＳ３７にて推定された通信端点とが一致する場合には、ＤＭＡ制御部２４は、処理を終了し、ＤＭＡ処理部２５は、ステップＳ３９にて開始されたＤＭＡ転送を継続して行う。一方、ステップＳ３５にて特定された通信端点とステップＳ３７にて推定された通信端点とが一致しない場合には、ＤＭＡ制御部２４は、処理をステップＳ４１に移す（ステップＳ４０）。
【０１１５】
ステップＳ３５にて特定された通信端点とステップＳ３７にて推定された通信端点とが一致しない場合、ＤＭＡ制御部２４は、ステップＳ３９にて開始させたＤＭＡ転送を中止するように、ＤＭＡ処理部２５を制御する（ステップＳ４１）。
【０１１６】
次に、ＤＭＡ制御部２４は、パケットの宛先であると特定された通信端点のパケット格納可能なディスクリプタテーブル（図２参照）をメインメモリ９から読み込む（ステップＳ４２）。そして、ＤＭＡ制御部２４は、ＦＩＦＯバッファメモリ２３に格納されているパケットのステップＳ４２にて読み込んだディスクリプタテーブルによって指し示されるパケット格納領域（図２参照）へのＤＭＡ転送を開始するように、ＤＭＡ処理部２５を制御し（ステップＳ４３）、処理を終了する。
【０１１７】
以上説明したように、本実施形態によれば、フレーム解析処理部２１がＩＰのヘッダ・チェックサムを用いたＩＰパケットの検証、ＴＣＰ又はＵＤＰのチェックサムを用いたＴＣＰ又はＵＤＰパケットの検証、並びに、パケットのフォーマット解析を行い、ＤＭＡ制御部２４のハードウェアの一部分がパケットの宛先である通信端点を特定している間に、通信端点推定処理部２８が、通信端点の推定に必要な情報のフレームからの抽出及びパケットの宛先である通信端点の推定を行い、ＤＭＡ制御部２４のハードウェアの他の一部分が、推定された通信端点に対応するパケット格納領域へのパケットのＤＭＡ転送を開始させることができる。このように、ハードウェア量の増加を抑えながら、パケットのＤＭＡ転送の開始を早くすることができ、通信スループットの低下を抑えることが可能となる。また、パケットの宛先であると特定された通信端点とパケットの宛先であると推定された通信端点とが一致しない場合、パケットの宛先であると推定された通信端点へのパケットのＤＭＡ転送を中止し、パケットの宛先であると特定された通信端点へのパケットのＤＭＡ転送を開始することができるので、通信端点の推定に誤りがあった場合であっても、パケットを正しい宛先である通信端点に届けることが可能である。
【産業上の利用可能性】
【０１１８】
本発明は、ＴＣＰ／ＩＰ受信処理回路において利用可能である。このＴＣＰ／ＩＰ受信処理回路は、パーソナルコンピュータ、携帯電話装置、ＰＤＡ、家庭電気製品（テレビジョン装置、冷蔵庫等）等に利用可能である。
【図面の簡単な説明】
【０１１９】
【図１】本発明の第１の実施形態に係る回路を用いたシステムを示す図。
【図２】図１のメインメモリ９及びＤＭＡ制御部２４のレジスタの内容を示す図。
【図３】図２のディスクリプタテーブルのフォーマットを示す図。
【図４】図２の通信端点条件設定テーブルのフォーマットを示す図。
【図５】図１のメインメモリ９の内容を示す図。
【図６】図１の通信端点推定情報格納部に格納される情報のフォーマットを示す図。
【図７】図１のＴＣＰ／ＩＰ受信処理回路５の動作を示すフローチャート。
【図８】本発明の第２の実施形態に係る回路を用いたシステムを示す図。
【図９】図８のＴＣＰ／ＩＰ受信処理回路１４の動作を示すフローチャート。
【図１０】ＯＳＩ参照モデルとＴＣＰ／ＩＰ階層モデルとの対応関係を示す図。
【図１１】フレームのフォーマットを示す図。
【図１２】ＩＰパケットのフォーマットを示す図。
【図１３】ＡＲＰ、ＲＡＲＰパケットのフォーマットを示す図。
【図１４】ＴＣＰパケットのフォーマットを示す図。
【図１５】ＵＤＰパケットのフォーマットを示す図。
【図１６】ＩＣＭＰパケットのフォーマットを示す図。
【図１７】従来のＴＣＰ／ＩＰ受信処理回路の動作を示すフローチャート。
【符号の説明】
【０１２０】
１、１３  コンピュータ、  ２  物理層処理回路、  ３  ＭＡＣ処理回路、  ４  ＭＡＣブリッジ回路、  ５  ＴＣＰ／ＩＰ受信処理回路、  ６  ＴＣＰ／ＩＰ送信処理回路、  ７  インタフェース回路、  ８  ＣＰＵ、  ９  メインメモリ、  １０  ＨＤＤ、  １１  入力部、  １２  表示部、  ２１  フレーム解析処理部、  ２２  解析結果データ格納部、  ２３  ＦＩＦＯバッファメモリ、  ２４  ＤＭＡ制御部、  ２５  ＤＭＡ処理部、  ２６、２８  通信端点推定処理部、  ２７  通信端点推定情報格納部、
【図１】
2006332927.tif 000003
【図２】
2006332927.tif 000004
【図３】
2006332927.tif 000005
【図４】
2006332927.tif 000006
【図５】
2006332927.tif 000007
【図６】
2006332927.tif 000008
【図７】
2006332927.tif 000009
【図８】
2006332927.tif 000010
【図９】
2006332927.tif 000011
【図１０】
2006332927.tif 000012
【図１１】
2006332927.tif 000013
【図１２】
2006332927.tif 000014
【図１３】
2006332927.tif 000015
【図１４】
2006332927.tif 000016
【図１５】
2006332927.tif 000017
【図１６】
2006332927.tif 000018
【図１７】
2006332927.tif 000019