JP6435002B2

JP6435002B2 - 通信装置及びその制御方法、プログラム

Info

Publication number: JP6435002B2
Application number: JP2017059611A
Authority: JP
Inventors: 哲男井戸
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2017-03-24
Filing date: 2017-03-24
Publication date: 2018-12-05
Anticipated expiration: 2033-02-08
Also published as: JP2017108470A

Description

本発明は、パケットの送信先となる端末との通信をネットワークを介して行う通信装置及びその制御方法、プログラムに関するものである。

インターネットで標準的に利用されているプロトコルの一つにＴＣＰ及びＩＰがある。ＩＰはＯＳＩ参照モデルのネットワークレイヤに対応し、ＴＣＰはトランスポートレイヤにあたる。

ＴＣＰ通信処理の実装において、ＴＣＰ通信の制御に関わる様々な情報が格納されている転送制御ブロックＴＣＢを用いることが一般的である。ＴＣＢはソフトウェア実装において構造体で実現されるようなＴＣＰコネクション毎の管理領域である。ＴＣＢには遷移状態、シーケンス番号、ＡＣＫ番号、ウインドウサイズ等のＴＣＰ通信に必要な情報が格納される。ＴＣＢに格納された情報を参照したり、情報を更新したりすることで、ＴＣＰ送受信処理が実現される。

実際に、ＴＣＰを用いてネットワーク上の相手端末と通信する場合には、ＴＣＰの他に下位レイヤのプロトコルが必要となり、それらを使用しての通信となる。具体的な一例としては、ＴＣＰの通信単位であるＴＣＰセグメントをＩＰパケット化し、さらにはそのＩＰパケットをイーサネットフレーム化することで、イーサネット（登録商標）を利用してネットワークへアクセスする。ここで、ネットワーク上の相手端末は、ＭＡＣアドレスによる識別が可能である。送信したイーサネットフレームの宛先ＭＡＣアドレスとして相手端末のＭＡＣアドレスを指定することで、相手端末でイーサネットフレームを受信することができる。相手端末では、受信したイーサネットフレームからＩＰパケットを取り出し、ＩＰパケットからＴＣＰセグメントを取り出すことができる。これにより、ＴＣＰ通信が可能となる。

同様に、イーサネットの代わりに無線ＬＡＮを使うことも可能である。

上述したように、イーサネットフレームの宛先ＭＡＣアドレスに相手端末のＭＡＣアドレスを指定することで、ネットワーク上の相手端末まで正しく通信ができる。つまり、送信元では、相手端末のＭＡＣアドレスを知っておく必要がある。これを実現する方法がＡＲＰ及びＡＲＰテーブルである。

ＡＲＰテーブルは、ＡＲＰというアドレス解決プロトコルによって作成、更新及び削除される。時には、ユーザによっても操作される。ＡＲＰテーブルは、具体的には、ネットワーク上の端末のＭＡＣアドレスとＩＰアドレスを対にして記憶した情報エントリの集合である。ＩＰパケットの送信毎に、宛先ＩＰアドレスから対応するＭＡＣアドレスを検索する処理がＡＲＰテーブルに対して行われる。これにより、宛先ＭＡＣアドレスが決定し、ネットワーク上の相手端末を識別して通信が可能となる。

しかし、ＩＰパケット送信毎に、ＡＲＰテーブルから宛先ＭＡＣアドレスを決定することは処理負荷が大きい。具体的には、ＡＲＰテーブルから宛先ＩＰアドレスに対応する情報エントリの検索を行い、対象の情報エントリが見つかると、そこから宛先ＭＡＣアドレスが決定され、それによりイーサネットフレームのヘッダを作成することができる。つまり、ネットワーク上に端末が複数ある場合、その端末数が増加するとＡＲＰテーブルで管理する情報エントリ数も増加し、ＩＰパケット送信毎に実施される情報エントリの検索処理負荷が増大する。

そこで、検索処理を高速化するためにハッシュ技術を用いる方法が提案されている（特許文献１）。この方法をＡＲＰテーブルから情報エントリを検索する処理に利用することで、検索処理の負荷を軽減することが可能である。

特許第４８８８３６９号公報

しかしながら、近年のイーサネットでは、より高速な通信が可能となる規格が出てきている。無線ＬＡＮにおいても同様に高速化が進んでいる。このような高速なネットワークにおいて通信を行う場合には、ＡＲＰテーブル参照における検索処理の更なる高速化が望まれている。

本発明は上記の課題を解決するためになされたものであり、テーブル参照処理の軽減を実現し、より高速なＴＣＰ／ＩＰ通信を提供することである。

上記の目的を達成するための本発明による通信装置は以下の構成を備える。即ち、
通信装置であって、
他の通信装置とＴＣＰコネクションを確立する際に、前記他の通信装置へ送信するパケットを中継する中継装置のＩＰアドレスを、当該中継装置のＩＰアドレスを経路情報として有するルーティングテーブルを利用して判別する判別手段と、
ＭＡＣアドレスとＩＰアドレスとを対応付けたＡＲＰテーブルを利用して、前記判別手段により判別されたＩＰアドレスに対応するＭＡＣアドレスを特定する特定手段と、
前記他の通信装置とのＴＣＰコネクションに付随する情報であるコネクション管理情報に、前記他の通信装置のＩＰアドレスと、前記特定手段により特定されたＭＡＣアドレスと、を付加して保持する保持手段と、
前記保持手段により保持された前記コネクション管理情報に含まれる前記他の通信装置のＩＰアドレスと前記特定手段により特定されたＭＡＣアドレスとを用いて、前記他の通信装置へ送信するパケットを生成する生成手段と、
を有する。

本発明によれば、ＴＣＰ送信時の処理においてＡＲＰテーブルが記憶されている主記憶へのアクセスが不要となり、またＡＲＰテーブルから対象のエントリを探す検索処理も不要になることで処理負荷が軽減され、より高速なＴＣＰ通信を実現することができる。

実施形態１の通信端末の機能構成を示すブロック図である。実施形態１の処理を示すフローチャートである。実施形態１のシステム構成を示す図である。実施形態１のルーティングテーブルの例を示す図である。実施形態１のＡＲＰテーブルの例を示す図である。実施形態１の相手端末のＮＩＣ変更時の例を占めず図である。実施形態１のパケット不達発生時のフローチャートである。実施形態１のＡＲＰテーブル更新の例を示す図である。実施形態２のシステム構成を示す図である。実施形態２のＡＲＰテーブルの例を示す図である。実施形態２のゲートウェイ変更時の例を示す図である。実施形態２のゲートウェイ変更時のフローチャートである。実施形態２のルーティングテーブル変更の例を示す図である。実施形態２のＡＲＰテーブルの例を示す図である。

以下、本発明の実施の形態について図面を用いて詳細に説明する。

＜実施形態１＞
Ｅｔｈｅｒｎｅｔ（登録商標）（イーサネット）を使って、ネットワークへＴＣＰ送信を通信端末（通信装置）から行う場合の処理を説明する。

図１は通信端末の機能構成を示すブロック図である。

ルーティングテーブル１０１は、次の送信先ＩＰアドレスを経路情報として保持する。ＡＲＰテーブル１０２は、ネットワーク上の通信端末のＩＰアドレスとＭＡＣアドレスを対応づけて管理する。コネクション管理テーブル１０３は、ＴＣＰ通信の各コネクションに付随する情報であるコネクション管理情報（ＴＣＢ）を保持する。

データメモリ１０４は、画像データ等のユーザやアプリケーションが扱うデータを記憶する。アプリケーション処理部１０５は、アプリケーションを実行し、データメモリ１０４に記録されたデータを参照したり、そのデータをＴＣＰ処理部１０６へ渡したりする。また、アプリケーション処理部１０５は、ＴＣＰ処理部１０６からデータを受け取り、それをデータメモリ１０４へ記録する。

ＴＣＰ処理部１０６は、コネクション管理テーブル１０３を使用してＴＣＰのプロトコル処理を行う。ＩＰ処理部１０７は、ＩＰのプロトコル処理を行う。ＭＡＣ処理部１０８は、Ｅｔｈｅｒｎｅｔ−ＭＡＣデバイスを制御してＭＡＣのプロトコル処理を行う。ＰＨＹ処理部１０９は、Ｅｔｈｅｒｎｅｔ−ＰＨＹデバイスを制御してＰＨＹのプロトコル処理を行う。尚、ＰＨＹは、ネットワークにおけるプロトコルの機能を表したＯＳＩ参照モデルにおいて、最も物理的な接続形式を規定している通信モデルであり、全７レイヤの内、第１レイヤ目に位置する物理レイヤを意味する。

ルート決定部１１０は、ルーティングテーブル１０１を参照して、次の送信先ＩＰアドレスを決定する。宛先ＭＡＣアドレス決定部１１１は、ＡＲＰテーブル１０２を参照して次の送信先ＩＰアドレスに対応づけられた次の送信先ＭＡＣアドレスを決定する。

制御部１１２は、通信処理全体を統制し、宛先ＩＰアドレスと次の送信先ＭＡＣアドレスをＴＣＢとしてコネクション管理テーブル１０３に保存する。また、制御部１１２は、ＡＲＰテーブル１０２の更新が発生した場合、コネクション管理テーブル１０３の更新を実施するように制御する。更に、制御部１１２は、コネクション管理テーブル１０３に保存されているＴＣＢを利用して、送信用のパケットを作成する。

以下、図２のフローチャートに従って説明する。また、システム構成を図３に示す。通信端末（図１）である自端末１と相手端末２がローカルネットワーク３上に存在する構成である。

自端末１のＩＰアドレスが１９２．１６８．１．１０、ＭＡＣアドレスがａａ：ａａ：ａａ：ａａ：ａａ：ａａであるとする。また、相手端末２のＩＰアドレスが１９２．１６８．１．１１、ＭＡＣアドレスがｂｂ：ｂｂ：ｂｂ：ｂｂ：ｂｂ：ｂｂであるとする。

まず、ステップＳ１０１として、自端末１と相手端末２の間にＴＣＰコネクションを確立するために、自端末１と相手端末２ではそれぞれＴＣＰコネクションを管理するＴＣＢ（コネクション管理情報）をコネクション毎にコネクション管理テーブル１０３に作成する。コネクション確立を要求する側の自端末１では、ＴＣＢに相手端末２のポート番号とＩＰアドレスを保持する。コネクション確立の待ち受け側の相手端末２では、ＴＣＢに待ち受けのポート番号を保持する。

次に、ステップＳ１０２として、自端末１から相手端末２に向けてＴＣＰのＳＹＮパケット送信処理を開始する。自端末１は、まず、ＳＹＮパケット送信要求を生成する。

次に、ＳＹＮパケット送信処理としては、ステップＳ１０３として、自端末１は、最初に、ルーティングテーブル１０１の参照を行う。この時のルーティングテーブル１０１は、図４のようになっているとする。

ここでは、ルーティングテーブル１０１を参照すると、ＴＣＢに保持している相手端末２のＩＰアドレスが１９２．１６８．１．１１であるので、ローカルネットワーク３に属することがわかる。ローカルネットワーク３に属するという条件はデフォルトゲートウェイの条件よりも優先されるため、このような判定となる。よって、ステップＳ１０４として、自端末１は、ルートとして、次の送信先ＩＰアドレスは相手端末２のＩＰアドレスであると確定する。

次に、ステップＳ１０５として、自端末１は、ＡＲＰテーブル１０２を参照する。ステップＳ１０６として、自端末１は、ＡＲＰテーブル１０２の参照によって、送信先のアドレス解決ができたか否かを判定する。判定の結果、アドレス解決できた場合（ステップＳ１０６でＹＥＳ）、ステップＳ１１０に進む。一方、アドレス解決できなかった場合（ステップＳ１０６でＮＯ）、ステップＳ１０７に進む。

ここでは、次の送信先ＩＰアドレス１９２．１６８．１．１１がＡＲＰテーブル１０２から見つからなかった場合（アドレス解決できなかった）について説明する。この場合、ステップＳ１０７として、自端末１は、アドレス解決のためのＡＲＰ要求パケットをローカルネットワーク３に送信する（ＡＲＰを実施する）。

次に、ステップＳ１０８として、自端末１は、ＡＲＰ要求に対するＡＲＰ応答を受信することにより、アドレス解決できたか否かを判定する。判定の結果、アドレス解決できた場合（ステップＳ１０８でＹＥＳ）、ステップＳ１１０に進む。一方、アドレス解決できなかった場合（ステップＳ１０８でＮＯ）、ステップＳ１０９に進む。

ここで、ＡＲＰ要求をローカルネットワーク３上の通信端末が受信すると、ＡＲＰ応答を返信する。ＡＲＰ応答には応答した通信端末のＩＰアドレスとＭＡＣアドレスが含まれている。このＡＲＰ応答を自端末１で受信することにより、自端末１は、今回の相手端末２のＩＰアドレスとＭＡＣアドレスを知ることができ、これらを対にしてＡＲＰテーブル１０２に新規に追加（更新）することができる。この時のＡＲＰテーブル１０２を図５に示す。

ＡＲＰテーブル１０２が更新されたことで、自端末１は、ＴＣＰレイヤにて、再度、ＡＲＰテーブル１０２を参照して、今回は次の送信先ＩＰアドレス１９２．１６８．１．１１を見つけることができる。そして、ステップＳ１１０として、自端末１は、次の送信先ＩＰアドレスに対応付けられた次の送信先ＭＡＣアドレスｂｂ：ｂｂ：ｂｂ：ｂｂ：ｂｂ：ｂｂ（宛先ＭＡＣアドレス）を確定する。

尚、ステップＳ１０８において、アドレス解決できなかった場合とは、ＡＲＰテーブル１０２の更新に失敗したり、更新しても次の送信先ＩＰアドレスが見つからない場合等である。そして、この場合は、ステップＳ１０９として、自端末１は、ＴＣＢに保存する次の送信先ＭＡＣアドレスを無効に設定し、ＭＡＣヘッダ作成時に無効を検出すると送信処理を破棄する。

ステップＳ１１１として、自端末１は、次の送信先ＭＡＣアドレス（宛先ＭＡＣアドレス）をこのコネクション用のＴＣＢに保存する。ステップＳ１１２として、自端末１は、ＴＣＰレイヤにてＳＹＮパケットを作成する。このとき、ＳＹＮパケットのＴＣＰヘッダの宛先ポート番号には、相手端末２で待ち受けしているポート番号を設定する。相手端末２のポート番号は、このコネクション用に保持しているＴＣＢを参照することで知ることができる。

次に、ステップＳ１１３として、自端末１は、ＩＰレイヤにてＳＹＮパケットをＩＰパケット化する。このとき、ＩＰヘッダの宛先ＩＰアドレスには相手端末２のＩＰアドレスを設定する。相手端末２のＩＰアドレスは、このコネクション用に保持しているＴＣＢを参照することで知ることができる。

次に、ステップＳ１１４として、自端末１は、ＭＡＣレイヤにてＩＰパケットをＭＡＣフレーム化する。ここでは、例えば、イーサネットフレーム化する。このとき、イーサネットヘッダの宛先ＭＡＣアドレスには次の送信先ＭＡＣアドレスを設定する。次の送信先ＭＡＣアドレスは、このコネクション用に保持しているＴＣＢを参照することで知ることができる。

以上のようにして、自端末１は、ＳＹＮパケットをイーサネットフレーム化し、ステップＳ１１５として、ローカルネットワーク３へ送信する。

ここで、イーサネット（Ｅｔｈｅｒｎｅｔ）はＭＡＣレイヤの一例であり、イーサネットの代わりに無線ＬＡＮを使うこともできる。無線ＬＡＮを使った場合には、ＭＡＣレイヤは８０２．１１ｇ規格や８０２．１１ｎ規格等に従うものとなるが、処理については同様のものとなる。

また、ＴＣＰコネクション確立処理としては、ステップＳ１１６として、自端末１は、相手端末２から返信されるＳＹＮ−ＡＣＫパケットに対してＡＣＫを送信することで、いわゆる３ウェイハンドシェークと呼ばれるＴＣＰコネクション確立処理が完了する。

ＴＣＰコネクションが確立すると、ステップＳ１１７として、自端末１は、その後のＴＣＰによるデータ送信やＡＣＫ送信においては、そのコネクション用のＴＣＢを参照することにより、イーサネットフレーム化して、ＴＣＰ通信を実行することができる。その後、ＴＣＰ通信が完了すると、ステップＳ１１８として、自端末１は、ＴＣＰコネクションを終了する。

次に、相手端末２において、ＮＩＣが切り替わった場合について説明する。例えば、ＮＩＣが故障してしまって交換した場合や、より高性能なＮＩＣに交換した場合や、イーサネットから無線ＬＡＮに切り替えた場合や、その逆の場合等が想定される（図６参照）。

ここでは、図７のフローチャートに従って説明する。

このような場合には、相手端末のＭＡＣアドレスが変更になる。そのため、例えば、ＴＣＰデータをイーサネットフレーム化して送信しても、宛先への到達不能（不達）となってしまう。このような場合、ネットワークから宛先への到達不能メッセージが出されたり、到達不能状態が継続されるようになる。

このような状態になると、ステップＳ２０１として、自端末１は、再度、ＡＲＰ要求パケットをローカルネットワーク３に送信する（ＡＲＰを実施する）。次に、ステップＳ２０２として、自端末１は、ＡＲＰ要求に対するＡＲＰ応答を受信することにより、アドレス解決できたか否かを判定する。判定の結果、アドレス解決できなかった場合（ステップＳ２０２でＮＯ）、ステップＳ２０３に進む。ステップＳ２０３として、自端末１は、ＴＣＢに保持する次の送信先ＭＡＣアドレスを無効に設定し、ＭＡＣヘッダ作成時に無効を検出すると送信処理を破棄する。

一方、アドレス解決できた場合（ステップ２０２でＹＥＳ）、ステップＳ２０４に進む。ステップＳ２０４として、自端末１は、相手端末２から受信したＡＲＰ応答を受信することで、相手端末２のＩＰアドレスと新しいＭＡＣアドレス（宛先ＭＡＣアドレス）を知ることができ、これをＡＲＰテーブル１０２に登録（更新）することができる。この時のＡＲＰテーブル１０２を図８に示す。

また、自端末１は、ルーティングテーブル１０１（図４）を再度参照し、宛先ＩＰアドレス１９２．１６８．１．１１がローカルネットワーク３内に属することを再度確認し、次の送信先ＩＰアドレスを確定する。そして、次の送信先ＩＰアドレス１９２．１６８．１．１１がＡＲＰテーブル１０２（図８）にあるかどうかを確認する。さきほど、ＡＲＰテーブル１０２は更新されているので、自端末１は、次の送信先ＩＰアドレス１９２．１６８．１．１１を見つけることができる。これにより、自端末１は、対応する次の送信先ＭＡＣアドレスｃｃ：ｃｃ：ｃｃ：ｃｃ：ｃｃ：ｃｃ（宛先ＭＡＣアドレス）を確定することができる。

そして、ステップＳ２０５として、自端末１は、次の送信先ＭＡＣアドレス（宛先ＭＡＣアドレス）をこのコネクション用のＴＣＢに保存する。

ここで、ＡＲＰテーブル１０２が更新された場合に、自端末１は、現在確立されている全てのコネクションに対して、同様に、ルーティングテーブル１０１の参照とＡＲＰテーブル１０２の参照を行う。また、必要がある場合には、自端末１は、各ＴＣＢの次の送信先ＭＡＣアドレスを更新（更新対象）するようにしても良い。

例えば、次の送信先ＭＡＣアドレスを用いて、送信用のパケットの作成の後、前記ＡＲＰテーブルの更新が発生した場合において、その更新時のコネクションにおける次の送信先ＭＡＣアドレスと、コネクション管理テーブルに保存されているコネクション管理情報で管理される次の送信先ＭＡＣアドレスが異なる場合には、次の送信先ＭＡＣアドレスでコネクション管理テーブルで保存されるコネクション管理情報を更新しても良い。

また、相手端末２のＩＰアドレスや次の送信先ＭＡＣアドレスがＴＣＢに保存されているので、ＩＰヘッダの一部である宛先ＩＰアドレスの設定や、ＭＡＣヘッダの一部である宛先ＭＡＣヘッダの設定をＴＣＰレイヤにて行う構成としても良い。

また、ＡＲＰテーブル１０２の更新に失敗したり、更新しても次の送信先ＩＰアドレスが見つからない場合、ＴＣＢに保存する次の送信先ＭＡＣアドレスを無効に設定し、ＭＡＣヘッダ作成時に無効を検出すると送信処理を破棄するようにしても良い。

以上のように、ＩＰパケットの送信毎にルーティングテーブル１０１の参照やＡＲＰテーブル１０２の参照等の処理を行うことなく送信を行うことができる。

以上説明したように、実施形態１によれば、コネクション管理テーブル１０３のＴＣＢに相手端末のＩＰアドレスや次の送信先ＭＡＣアドレスを保存管理し、このＴＣＢを利用して送信パケットを作成する。これにより、ＴＣＰ送信時の処理においてＡＲＰテーブルが記憶されている主記憶へのアクセスが不要となる。また、ＡＲＰテーブルから対象のエントリを探す検索処理も不要になることで処理負荷が軽減され、より高速なＴＣＰ通信を実現することができる。

＜実施形態２＞
実施形態２では、無線ＬＡＮを使ってネットワークへＴＣＰ送信を行い、途中でローミング（無線ＬＡＮゲートウェイ端末の変更）を行う場合の処理を説明する。

自端末１の構成は、実施形態１の図１の機能構成と同様である。ここで、ＭＡＣ処理部１０８とＰＨＹ処理部１０９は無線ＬＡＮに対応する。

以下、図２のフローチャートに従って説明する。また、システム構成を図９に示す。通信端末である自端末１と無線ＬＡＮゲートウェイ端末４（以下、ＧＷ１）はローカルネットワーク６（例えば、無線ＬＡＮネットワーク）で接続され、ＧＷ１と相手端末２がローカルネットワーク３（例えば、イーサネット）で接続されている。同様に、自端末１と無線ＬＡＮゲートウェイ端末５（以下、ＧＷ２）はローカルネットワーク６で接続可能であり、ＧＷ２と相手端末２がローカルネットワーク３で接続されている。また、無線ＬＡＮによるローカルネットワーク６とイーサネットによるローカルネットワーク３は別ネットワークであり、ＧＷ１とＧＷ２がゲートウェイとなっている。また、ＧＷ１がデフォルトゲートウェイ端末となっている。

ここで、自端末１のＩＰアドレスが１９２．１６８．１．１０、ＭＡＣアドレスがａａ：ａａ：ａａ：ａａ：ａａ：ａａであるとする。また、相手端末２のＩＰアドレスが１９２．１６８．２．１１、ＭＡＣアドレスがｂｂ：ｂｂ：ｂｂ：ｂｂ：ｂｂ：ｂｂであるとする。さらに、ＧＷ１の無線ＬＡＮ側のＩＰアドレスが１９２．１６８．１．１、ＭＡＣアドレスがｃｃ：ｃｃ：ｃｃ：ｃｃ：ｃｃ：１１であるとする。また、ＧＷ１のイーサネット側のＩＰアドレスが１９２．１６８．２．１、ＭＡＣアドレスがｃｃ：ｃｃ：ｃｃ：ｃｃ：ｃｃ：２２であるとする。さらに、ＧＷ２の無線ＬＡＮ側のＩＰアドレスが１９２．１６８．１．２、ＭＡＣアドレスがｄｄ：ｄｄ：ｄｄ：ｄｄ：ｄｄ：１１であるとする。また、ＧＷ２のイーサネット側のＩＰアドレスが１９２．１６８．２．２、ＭＡＣアドレスがｄｄ：ｄｄ：ｄｄ：ｄｄ：ｄｄ：２２であるとする。

まず、ステップＳ１０１として、自端末１と相手端末２の間にＴＣＰコネクションを確立するため、自端末１と相手端末２ではそれぞれＴＣＰコネクションを管理するＴＣＢをコネクション毎にコネクション管理テーブル１０３に作成する。コネクション確立を要求する側の自端末１では、ＴＣＢに相手端末２のポート番号とＩＰアドレスを保持する。コネクション確立の待ち受け側の相手端末２では、ＴＣＢに待ち受けのポート番号を保持する。

ここでは、ルーティングテーブル１０１を参照すると、ＴＣＢに保持している相手端末２のＩＰアドレス１９２．１６８．２．１１は、ローカルネットワーク６ではなく、その他どこにも属していなかったとする。つまり、ステップＳ１０４として、自端末１は、ルートとして、次の送信先ＩＰアドレスはデフォルトゲートウェイのＩＰアドレス１９２．１６８．１．１と確定する。

次に、ステップＳ１０５として、自端末１は、次の送信先ＩＰアドレスを判定するために、ＡＲＰテーブル１０２を参照する。ステップＳ１０６として、自端末１は、ＡＲＰテーブル１０２の参照によって、送信先のアドレス解決ができたか否かを判定する。判定の結果、アドレス解決できなかった場合（ステップＳ１０６でＮＯ）、実施形態１と同様に、ステップＳ１０７及びステップＳ１０８によって、次の送信先ＩＰアドレスが解決されたものとする。そして、ステップＳ１１０として、自端末１は、次の送信先ＩＰアドレスに対応付けられた次の送信先ＭＡＣアドレスを確定する。このときのＡＲＰテーブルは図１０のようであったとする。

ステップＳ１１１として、自端末１は、次の送信先ＭＡＣアドレスをこのコネクション用のＴＣＢに保存する。

この先、ＳＹＮパケットの送信処理は、実施形態１で説明した通り、ステップＳ１１２からステップＳ１１５として、ＴＣＢを参照することによりＭＡＣフレーム化してローカルネットワーク６へ送信することができる。そして、ステップＳ１１６として、自端末１は、ＴＣＰコネクション確立処理を完了する。また、ステップＳ１１７として、自端末１は、その後のＴＣＰによるデータ送信やＡＣＫ送信においては、そのコネクション用のＴＣＢを参照することにより、ＭＡＣフレーム化することができる。その後、通信が完了すると、ステップＳ１１８として、自端末１は、ＴＣＰコネクションを終了する。

次に、図１１に示すように、ゲートウェイの変更を行った場合について説明する。例えば、ＴＣＰ通信処理中に、自端末１が無線通信エリアを移動した場合や、ＧＷを交換した場合等が想定される。

ここでは、図１２のフローチャートに従って説明する。

このような場合には、デフォルトゲートウェイが変更され、それにより次の送信先ＭＡＣアドレスが変更になる。このような場合、ユーザによる設定変更や、ＤＨＣＰの機能やその他の方法等により、自端末１のルーティングテーブル１０１で保持しているデフォルトゲートウェイ情報が更新される。このときのルーティングテーブル１０１を図１３に示す。

デフォルトゲートウェイが変更になると、ステップＳ３０１として、自端末１は、ルーティングテーブル１０１（図１３）を参照する。ステップＳ３０２として、自端末１は、ルートとして、デフォルトゲートウェイのＩＰアドレスが１９２．１６８．１．２であることを確定する。次に、ステップＳ３０３として、自端末１は、デフォルトゲートウェイのＩＰアドレス１９２．１６８．１．２がＡＲＰテーブル１０２に登録があり、アドレス解決できた場合（ステップＳ３０４でＹＥＳ）、ステップＳ３０８へ進む。ＡＲＰテーブル１０２に登録がなく、アドレス解決できなかった場合（ステップＳ３０４でＮＯ）、ステップＳ３０５として、自端末１は、ＡＲＰ要求パケットを送信する（ＡＲＰを実施する）。

次に、ステップＳ３０６として、自端末１は、ＡＲＰ要求に対するＡＲＰ応答を受信することにより、アドレス解決できたか否かを判定する。判定の結果、アドレス解決できなかった場合（ステップＳ３０６でＮＯ）、例えば、ＡＲＰテーブル１０２の更新に失敗したり、更新しても次の送信先ＩＰアドレスが見つからない場合、ステップＳ３０７に進む。ステップＳ３０７として、自端末１は、ＴＣＢに保持する次の送信先ＭＡＣアドレスを無効に設定し、ＭＡＣヘッダ作成時に無効を検出すると送信処理を破棄する。

一方、アドレス解決できた場合（ステップＳ３０６でＹＥＳ）、自端末１は、ＡＲＰテーブル１０２を更新する。ここで、判定することなく、ＡＲＰ要求パケットを送信して、ＡＲＰテーブル１０２を更新しても構わない。ここでは、ＧＷ２からのＡＲＰ応答によりＡＲＰテーブル１０２が更新されたものとする（図１４参照）。その後は、ステップＳ３０８として、ＡＲＰテーブル１０２から次の送信先ＭＡＣアドレスを確定する。そして、ステップＳ３０９として、実施形態１で説明したように、自端末１は、次の送信先ＭＡＣアドレスｄｄ：ｄｄ：ｄｄ：ｄｄ：ｄｄ：１１をこのコネクション用のＴＣＢに保存する。

以上説明したように、実施形態２によれば、無線ＬＡＮ環境においても、実施形態１と同様の効果を達成することができる。

尚、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステムまたは装置に供給し、そのシステムまたは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１：通信端末、１０３：コネクション管理テーブル、１０６：ＴＣＰ処理部、１１０：ルート決定部、１１１：宛先ＭＡＣアドレス決定部、１１２：制御部

Claims

通信装置であって、
他の通信装置とＴＣＰコネクションを確立する際に、前記他の通信装置へ送信するパケットを中継する中継装置のＩＰアドレスを、当該中継装置のＩＰアドレスを経路情報として有するルーティングテーブルを利用して判別する判別手段と、
ＭＡＣアドレスとＩＰアドレスとを対応付けたＡＲＰテーブルを利用して、前記判別手段により判別されたＩＰアドレスに対応するＭＡＣアドレスを特定する特定手段と、
前記他の通信装置とのＴＣＰコネクションに付随する情報であるコネクション管理情報に、前記他の通信装置のＩＰアドレスと、前記特定手段により特定されたＭＡＣアドレスと、を付加して保持する保持手段と、
前記保持手段により保持された前記コネクション管理情報に含まれる前記他の通信装置のＩＰアドレスと前記特定手段により特定されたＭＡＣアドレスとを用いて、前記他の通信装置へ送信するパケットを生成する生成手段と、
を有することを特徴とする通信装置。
前記生成手段により生成された前記パケットを送信する第１の送信手段を更に有することを特徴とする請求項１に記載の通信装置。
前記特定手段が、前記判別手段により判別されたＩＰアドレスに対応するＭＡＣアドレスの特定に失敗した場合、ＡＲＰ要求を送信する第２の送信手段を更に有することを特徴とする請求項１又は２に記載の通信装置。
前記第２の送信手段により送信された前記ＡＲＰ要求に対する応答に基づいて、前記ＡＲＰテーブルを更新する更新手段を更に有することを特徴とする請求項３に記載の通信装置。
前記更新手段により更新された前記ＡＲＰテーブルを利用して、前記特定手段は、前記判別手段により判別されたＩＰアドレスに対応するＭＡＣアドレスを特定することを特徴とする請求項４に記載の通信装置。
前記更新手段により更新された前記ＡＲＰテーブルを利用したにも拘らず、前記特定手段が、前記判別手段により判別されたＩＰアドレスに対応するＭＡＣアドレスの特定に失敗した場合、前記保持手段は、前記コネクション管理情報に含まれる前記特定手段により特定されたＭＡＣアドレスを無効に設定することを特徴とする請求項５に記載の通信装置。
前記生成手段は、ＴＣＰレイヤにおける処理の一部として、前記他の通信装置へ送信するパケットのＩＰヘッダの一部、または、ＭＡＣヘッダの一部を生成することを特徴とする請求項１から６のいずれか１項に記載の通信装置。
通信装置の制御方法であって、
他の通信装置とＴＣＰコネクションを確立する際に、前記他の通信装置へ送信するパケットを中継する中継装置のＩＰアドレスを、当該中継装置のＩＰアドレスを経路情報として有するルーティングテーブルを利用して判別する判別工程と、
ＭＡＣアドレスとＩＰアドレスとを対応付けたＡＲＰテーブルを利用して、前記判別工程において判別されたＩＰアドレスに対応するＭＡＣアドレスを特定する特定工程と、
前記他の通信装置とのＴＣＰコネクションに付随する情報であるコネクション管理情報に、前記他の通信装置のＩＰアドレスと、前記特定工程において特定されたＭＡＣアドレスと、を付加して保持する保持工程と、
前記コネクション管理情報に含まれる前記他の通信装置のＩＰアドレスと前記特定工程において特定されたＭＡＣアドレスとを用いて、前記他の通信装置へ送信するパケットを生成する生成工程と、
を有することを特徴とする制御方法。
コンピュータを、請求項１から７のいずれか１項に記載の通信装置として動作させるためのプログラム。