JPWO2011117959A1 - 通信装置、通信装置の制御方法、プログラム - Google Patents

Abstract

多くの手間やコストをかけることなく、複数のアドレスが割り当てられた外部装置と通信することを可能にするための仕組みを提供することを目的とする。複数のアドレスが割り当てられた外部装置とネットワークを介して接続される通信装置において、所定の識別情報を含むパケットを第１のアドレスを宛先として外部装置に送信し（Ｓ７０３）、受信したパケットに所定の識別情報が含まれている場合に、当該受信したパケットの送信元アドレスを抽出する（Ｓ７０６）。そして、抽出した送信元アドレスが第１のアドレスとは異なる第２のアドレスである場合は、次回以降に外部装置に対してパケットを送信する際に第２のアドレスを宛先として送信する（Ｓ７０８）。

Description

本発明は、複数のアドレスが割り当てられた外部装置とネットワークを介して接続される通信装置、通信装置の制御方法、プログラムに関する。

従来、ネットワーク（ＬＡＮ、インターネット等）に接続され、ネットワーク上の外部装置と通信する様々な通信装置が知られている。
ネットワークに接続される通信装置において広く使用されているプロトコルはインターネットプロトコルである。インターネットプロトコルでは各装置に固有のアドレス（ＩＰアドレス）を割り当て、このＩＰアドレスを用いて互いの装置を識別している。

従来のＩＰ規約（ＩＰｖ４：ＩＰバージョン４）では、１つのネットワークインターフェースに対して１つのＩＰアドレスが割り当てられることが一般的であった。一方、近年普及しつつあるＩＰｖ６（ＩＰバージョン６）では、通信装置がルータに接続されると、ルータによってＩＰアドレスが割り当てられる。また、ルータが存在しない場合にも通信を行えるようにするために、ネットワークインターフェース毎に１つのＩＰｖ６アドレス（リンクローカルアドレス）が割り当てられる。更には、ＤＨＣＰサーバが存在する場合は、ＤＨＣＰサーバが発行したＩＰアドレスを取得することもできる。

このように、ＩＰｖ６に対応している通信装置では、１つのネットワークインターフェースに対してＩＰｖ４アドレスや複数のＩＰｖ６アドレスといった複数のＩＰアドレスが割り当てられることになる。
１つのネットワークインターフェースに複数のＩＰアドレスが割り当てられた場合におけるＩＰアドレスの選択方法として、非特許文献１（ＲＦＣ３４８４）が知られている。非特許文献１に示される方法では、条件に合致する複数のＩＰアドレスのうちプレフィックス長がより長いＩＰアドレスを選択する。

非特許文献１の方法を用いたＩＰアドレスの選択が行われる場合、次のような問題が発生することがある。例えば、ＩＰアドレスＡが割り当てられた装置ＡとＩＰアドレスＢ及びＣが割り当てられた装置ＢがＵＤＰ通信する場合、装置Ａが装置Ｂに送信するリクエストの宛先アドレスとしてＩＰアドレスＢを指定したとする。このとき、装置Ｂから装置Ａに対するレスポンスの宛先アドレスは、装置Ａから装置Ｂへのリクエストの送信元アドレスとして使用されたＩＰアドレスＡが設定される。また、装置Ｂから装置Ａに対するレスポンスの送信元アドレスは、非特許文献１の方法に従って装置ＢがＩＰアドレスＢ及びＣのいずれかを選択する。即ち、装置Ｂは、ＩＰアドレスＢ及びＣのうち、ＩＰアドレスＡに対するプレフィックス長がより長い方のＩＰアドレスを選択する。

しかしながら、装置Ｂよる選択の結果、送信元アドレスとしてＩＰアドレスＣが選択されたとすると問題が生じる。なぜなら、装置ＡはＩＰアドレスＢを宛先としてリクエストを送信したため、ＩＰアドレスＢを送信元アドレスとするレスポンスのみを待ち続けており、ＩＰアドレスＣを送信元アドレスとするレスポンスが届いたとしても破棄してしまうからである。

このような問題に対処するために、非特許文献２（ＷＳ−Ｅｖｅｎｔｉｎｇ）が知られている。非特許文献２に示される方法では、トランスポート層よりも上位の層に対応するデータにＭｅｓｓａｇｅＩＤ（ＲｅｑｕｅｓｔＩＤ）を付加し、このＩＤを参照してレスポンスを識別する。即ち、レスポンスの送信元アドレスを参照するのではなく、上位層のデータに付加されたＩＤを参照することによりリクエストとレスポンスを関連付ける。これにより、リクエストの宛先アドレスとして用いたＩＰアドレスとは異なるＩＰアドレスがレスポンスの発信元アドレスとして用いられたとしても、リクエストとレスポンスを関連付けることが可能となっている。

Internet Engineering Task Force RFC3484 "Default Address Selection for Internet Protocol version 6 (IPv6)"<URL: 1269306530609_0.txt> Web Services Eventing (WS-Eventing)<URL: http://www.w3.org/Submission/WS-Eventing/>

上述した非特許文献２に示される方法の場合、トランスポート層よりも上位の層に対応するデータにＩＤを付加する必要がある。
しかしながら、アプリケーションによってはトランスポート層よりも上位の層に対応するデータの内容を固定的なものとしていることがあり、非特許文献２に示されるようなＩＤを付加することが困難な場合がある。即ち、ＩＤを参照することによるレスポンスの識別を行う場合、全てのパケットにＩＤを付加するようにしなければならない。このためには、アプリケーションのプログラム内容を大幅に変更しなければならず、多くの手間やコストがかかってしまう。

本発明は、上記の問題点に鑑みなされたものであり、多くの手間やコストをかけることなく、複数のアドレスが割り当てられた外部装置と通信することを可能にするための仕組みを提供することを目的とする。

上記の目的を達成するために本発明の通信装置は、複数のアドレスが割り当てられた外部装置とネットワークを介して接続される通信装置であって、所定の識別情報を含むパケットを、前記複数のアドレスに含まれる第１のアドレスを宛先として前記外部装置に送信する送信手段と、前記外部装置から送信されたパケットを受信する受信手段と、前記受信手段が受信したパケットに前記所定の識別情報が含まれている場合に、当該受信したパケットの送信元アドレスを抽出する抽出手段と、前記抽出手段が抽出した送信元アドレスが前記第１のアドレスとは異なる第２のアドレスである場合は、次回以降に前記外部装置に対してパケットを送信する際に前記第２のアドレスを宛先として送信するよう制御する制御手段とを備えることを特徴とする。

本発明によれば、多くの手間やコストをかけることなく、複数のアドレスが割り当てられた外部装置と通信することが可能となる。

本発明の実施形態における通信システムの全体図である。 本発明の実施形態におけるクライアントＰＣ１００のハードウェア構成を示すブロック図である。 本発明の実施形態におけるサーバ１１０のハードウェア構成を示すブロック図である。 本発明の実施形態におけるクライアントＰＣ１００及びサーバ１１０のソフトウェア構成を示す図である。 本発明の実施形態におけるクライアントＰＣ１００とサーバ１１０との間のパケット通信の基本的な仕組みを説明するシーケンス図である。 本発明の実施形態におけるクライアントＰＣ１００とサーバ１１０との間のパケット通信の詳細を説明するシーケンス図である。 本発明の実施形態におけるクライアントＰＣ１００側の通信制御部４０５の処理を説明するフローチャートである。 本発明の実施形態におけるサーバ１１０側の通信制御部４０２の処理を説明するフローチャートである。 本発明の実施形態におけるアドレス管理テーブルを示す図である。 本発明の実施形態におけるクライアントＰＣ１００とサーバ１１０との間のパケット通信の詳細を説明するシーケンス図である。 本発明の実施形態におけるクライアントＰＣ１００側の通信制御部４０５の処理を説明するフローチャートである。

以下、図面を参照して本発明の実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る発明を限定するものでなく、また実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。

図１は、本発明の実施形態における通信システムの全体図である。クライアントＰＣ１００及びサーバ１１０はネットワーク１２０を介して互いに通信可能に接続されている。クライアントＰＣ１００及びサーバ１１０はいずれもＩＰｖ６に対応しており、複数のＩＰアドレスが割り当てられている。例えば、サーバ１１０に対してパケットを送信したい場合には、サーバ１１０に割り当てられている複数のＩＰアドレスのいずれかを宛先アドレスとすることにより、パケットはサーバ１１０に届けられる。
サーバ１１０は、クライアントＰＣ１００からのリクエストに応答するサービスを提供している。サーバ１１０が提供するサービスとしては、例えばＷｅｂ、ＤＮＳ、電子メール、ＳＮＭＰエージェント、ＷＳ−Ｅｖｅｎｔｉｎｇのサーバ機能が挙げられる。

図２は、クライアントＰＣ１００のハードウェア構成を示すブロック図である。ＣＰＵ２１１を含む制御部２１０は、クライアントＰＣ１００全体の動作を制御する。ＣＰＵ２１１は、ＲＯＭ２１２に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ２１４は、画像データや各種プログラムを記憶する。入出力装置Ｉ／Ｆ２１５は、キーボード２２０、マウス２３０、及びディスプレイ２４０を制御部２１０に接続する。

ネットワークＩ／Ｆ２１６は、制御部２１０（クライアントＰＣ１００）をネットワーク１２０に接続する。ネットワークＩ／Ｆ２１６は、ネットワーク１２０を経由した外部装置（例えば、サーバ１１０）との通信を制御する。
図３は、サーバ１１０のハードウェア構成を示すブロック図である。ＣＰＵ３１１を含む制御部３１０は、サーバ１１０全体の動作を制御する。ＣＰＵ３１１は、ＲＯＭ３１２に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＡＭ３１３は、ＣＰＵ３１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ３１４は、画像データや各種プログラムを記憶する。

ネットワークＩ／Ｆ３１５は、制御部３１０（サーバ１１０）をネットワーク１２０に接続する。ネットワークＩ／Ｆ３１５は、ネットワーク１２０上の他の装置（例えば、クライアントＰＣ１００）との間で各種情報を送受信する。
図４は、クライアントＰＣ１００及びサーバ１１０のソフトウェア構成を示す。図４に示す各機能部は、クライアントＰＣ１００及びサーバ１１０のそれぞれが備えるＣＰＵ２１１及びＣＰＵ３１１が制御プログラムを実行することにより実現される。

クライアントＰＣ１００にはアプリケーション４０６が備えられている。なお、ここでは１つのアプリケーションのみを示すが、複数のアプリケーションが備えられていても構わない。
アプリケーション４０６がサーバ１１０との間でデータを送受信する場合は、クライアントＰＣ１００内の通信制御部４０５に対して要求を行う。通信制御部４０５は、アプリケーション４０６からの要求を受けて、オペレーティングシステムの通信ライブラリ４０４を介してサーバ１１０と通信する。なお、通信ライブラリ４０４は、ソケット通信以外にＲＰＣ（Remote Procedure Call）やＷｅｂサービス等による通信にも対応している。

一方、サーバ１１０にはアプリケーション４０１が備えられている。なお、ここでは１つのアプリケーションのみを示すが、複数のアプリケーションが備えられていても構わない。
アプリケーション４０１がクライアントＰＣ１００との間でデータを送受信する場合は、サーバ１１０内の通信制御部４０２に対して要求を行う。通信制御部４０２は、アプリケーション４０１からの要求を受けて、オペレーティングシステムの通信ライブラリ４０３を介してクライアントＰＣ１００と通信する。なお、通信ライブラリ４０３は、通信ライブラリ４０４と同様に、ソケット通信以外にＲＰＣやＷｅｂサービス等による通信にも対応している。

図５は、クライアントＰＣ１００とサーバ１１０との間のパケット通信の基本的な仕組みを説明するシーケンス図である。クライアントＰＣ１００には後述する通り複数のＩＰアドレスが割り当てられているが、ここでは説明を簡単にするために１つのＩＰアドレスａ（2001:db8:abcd::ef）のみが割り当てられているものとする。同様に、サーバ１１０にも複数のＩＰアドレスが割り当てられているが、ここでは１つのＩＰアドレスｂ（2001:db8:aaaa::a）のみが割り当てられているものとする。

クライアントＰＣ１００からサーバ１１０に送信される送信パケット５０１には、宛先アドレス５０４、送信元アドレス５０３、及びリクエストデータ５０２が含まれる。宛先アドレス５０４及び送信元アドレス５０３は、ＯＳＩ参照モデルにおけるネットワーク層のＩＰアドレスの「Destination Address」及び「Source Address」に対応する。送信パケット５０１では、ＩＰアドレスｂが宛先アドレスとして用いられ、ＩＰアドレスａが送信元アドレスとして用いられている。送信パケット５０１に含まれるリクエストデータ５０２は、ＯＳＩ参照モデルにおけるトランスポート層に対応するデータである。

送信パケット５０１を受信したサーバ１１０は、リクエストデータ５０２を処理し、リクエストデータ５０２に対するレスポンスデータ５０５を生成する。そして、サーバ１１０は、レスポンスデータ５０５を含む返信パケット５０８をクライアントＰＣ１００に対して送信する。
返信パケット５０８には、宛先アドレス５０７、送信元アドレス５０６、及びレスポンスデータ５０５が含まれる。宛先アドレス５０７及び送信元アドレス５０６は、ＯＳＩ参照モデルにおけるネットワーク層のＩＰアドレスの「Destination Address」及び「Source Address」に対応する。返信パケット５０８では、送信パケット５０１の送信元アドレス５０３として使用されていたＩＰアドレスａが宛先アドレス５０７として用いられる。

また、返信パケットの送信元アドレス５０６には、サーバ１１０に割り当てられているＩＰアドレスｂが使用される。なお、実際には、サーバ１１０に複数のＩＰアドレスが割り当てられているので、図６のＰ６０２及びＰ６０７で説明する通り、返信パケットの送信元アドレスは、ＲＦＣ３４８４に従ってサーバ１１０が選択したものが使用される。
返信パケット５０８に含まれるレスポンスデータ５０５は、ＯＳＩ参照モデルにおけるトランスポート層に対応するデータである。

図６は、第１の実施形態におけるクライアントＰＣ１００とサーバ１１０との間のパケット通信の詳細を説明するシーケンス図である。図示する通り、クライアントＰＣ１００には、ＩＰアドレスａ（2001:db8:abcd::ef）に加えて、ＩＰアドレスｃ（2001:db8:cccc::c）が割り当てられている。また、サーバ１１０には、ＩＰアドレスｂ（2001:db8:aaaa::a）に加えてＩＰアドレスｄ（2001:db8:bbbb::b）が割り当てられている。

ここでは、クライアントＰＣ１００のアプリケーション４０６が、サーバ１１０のアプリケーション４０１に対してリクエストデータを送信しようとする場合について説明する。この場合、従来は、サーバ１１０に割り当てられているＩＰアドレスｂまたはｄのいずれかを宛先としてリクエストデータを含む送信パケットを送信していた。しかしながら、送信パケットに対するサーバ１１０からの返信パケットの送信元アドレスが、送信パケットの宛先アドレスと異なる場合があった（この理由の詳細は後述する）。この場合、クライアントＰＣは、送信パケットの宛先アドレスとして使用したものとは異なるＩＰアドレスを送信元アドレスとしたパケットが届いたとしても処理せずに破棄してしまうため、サーバ１１０からの返信パケットを受け取ることができない。

一方、従来、返信パケットの送信元アドレスに基づいて送信パケットと返信パケットの関連付けを行うのではなく、トランスポート層に対応するデータ内にＩＤを付加し、このＩＤを参照して関連付けを行うことが知られている。
しかしながら、この方法を採用する場合、サーバ１１０に送信する全てのパケットのデータ部分にＩＤを付加するように、クライアントＰＣ１００及びサーバ１１０双方のアプリケーションの内容を大幅に変更する必要がある。この場合、多くの手間とコストがかかってしまう。

そこで、第１の実施形態のクライアントＰＣ１００は、リクエストデータを送信するための前準備として、所定の識別情報（ＩＤ）を含む送信パケットを一度だけサーバ１１０に送信する。その後、パケットを受信した場合に、受信したパケット内に前述したＩＤが付加されていれば、受信したパケットの送信元アドレスを抽出する。そして、次回以降にサーバ１１０にパケットを送信する際は、抽出した送信元アドレスを宛先としてパケットを送信する。

以上説明した流れを、図６に示すシーケンス図を参照して説明する。クライアントＰＣ１００は、リクエストデータを送信するための前準備として、Ｐ６０１において、送信パケットを送信する。この送信パケットには、０ｘＡＢＣＤというＩＤが付加されている。また、この送信パケットの宛先アドレスは、サーバ１１０に割り当てられているＩＰアドレスｂ及びｄのうち、クライアントＰＣ１００が任意に選択したものを使用する。

ここでの任意の選択とは、例えば、ＤＮＳ（Domain Name System）を用いた名前解決を行って得られた複数のＩＰアドレスのうち、最も高い優先度が設定されているＩＰアドレスを選択することを意味する。図６に示す例では、ＩＰアドレスｄが選択され、宛先アドレスとして使用される。
更に、Ｐ６０１で送信される送信パケットの送信元アドレスには、クライアントＰＣ１００に割り当てられているＩＰアドレスａ及びｃのうち、ＲＦＣ３４８４に従った方法で選択されたＩＰアドレスが使用される。即ち、ＩＰアドレスａ及びｃのうち、宛先アドレスとして選択したＩＰアドレスｄに対してプレフィックス長がより長いＩＰアドレスが選択される。図６に示す例では、ＩＰアドレスａが選択され、送信元アドレスとして使用される。

Ｐ６０２では、サーバ１１０が返信パケットを生成する。この返信パケットには、送信パケットに含まれていたＩＤが付加される。続くＰ６０３において、返信パケットをクライアントＰＣ１００に対して送信する。
この返信パケットの宛先アドレスは、Ｐ６０１の送信パケットの送信元アドレスとして使用されていたＩＰアドレスａが使用される。更に、Ｐ６０３で送信される返信パケットの送信元アドレスには、サーバ１１０に割り当てられているＩＰアドレスｂ及びｄのうち、ＲＦＣ３４８４に従った方法で選択されたＩＰアドレスが使用される。即ち、ＩＰアドレスｂ及びｄのうち、宛先アドレスとして選択したＩＰアドレスａに対してプレフィックス長がより長いＩＰアドレスが選択される。図６に示す例では、ＩＰアドレスｂが選択され、送信元アドレスとして使用されるものとする。

以上の流れにより、サーバ１１０から送信される返信パケットの送信元アドレス（ＩＰアドレスｂ）は、クライアントＰＣ１００が最初に送信した送信パケットの宛先アドレス（ＩＰアドレスｄ）とは異なるものとなる。
Ｐ６０４では、サーバ１１０からのパケットを受信したクライアントＰＣ１００が、返信パケット内のＩＤ（０ｘＡＢＣＤ）を参照し、受信したパケットがＰ６０１で送信した送信パケットに対する返信パケットであることを識別する。そして、受信した返信パケットの送信元アドレスを抽出し、後述する図９に示すテーブルを更新する。

Ｐ６０５では、クライアントＰＣ１００がサーバ１１０に対して次回以降にパケットを送信する際に使用するＩＰアドレスを、Ｐ６０１での送信で使用したＩＰアドレスｄから、Ｐ６０４で抽出したＩＰアドレスｂに変更する。なお、Ｐ６０１でクライアントＰＣ１００が送信した送信パケットの宛先アドレスと、Ｐ６０３でサーバ１１０が送信した返信パケットの送信元アドレスが一致する場合は、Ｐ６０５の処理は必要ない。

Ｐ６０６では、リクエストデータを含む送信パケットをサーバ１１０に対して送信する。リクエストデータには、Ｐ６０１の送信パケットに付加されていたＩＤは付加されない。Ｐ６０６で送信される送信パケットの宛先アドレスには、Ｐ６０５で変更されたＩＰアドレスｂが使用され、送信元アドレスにはＩＰアドレスａが使用される。
Ｐ６０７では、サーバ１１０がリクエストデータを処理し、リクエストデータに対するレスポンスデータを生成する。なお、このレスポンスデータにもやはり、Ｐ６０３の返信パケットに付加されていたＩＤは付加されない。

続くＰ６０８では、レスポンスデータを含む返信パケットがクライアントＰＣ１００に対して送信される。この返信パケットの宛先アドレスは、Ｐ６０６の送信パケットの送信元アドレスとして使用されていたＩＰアドレスａが使用される。更に、Ｐ６０８で送信される返信パケットの送信元アドレスには、サーバ１１０に割り当てられているＩＰアドレスｂ及びｄのうち、ＲＦＣ３４８４に従った方法で選択されたＩＰアドレスが使用される。即ち、ＩＰアドレスｂ及びｄのうち、宛先アドレスとして選択したＩＰアドレスａに対してプレフィックス長がより長いＩＰアドレスが選択される。この結果、Ｐ６０３の返信パケットの送信元アドレスとして使用されたものと同じＩＰアドレスｂが選択される。

クライアントＰＣ１００は、Ｐ６０６で送信した送信パケットの宛先アドレスと一致するＩＰアドレスを送信元とするパケットを受信することになるため、それがＰ６０６で送信した送信パケットに対する返信パケットであることを識別することができる。
以上の通り、クライアントＰＣ１００は、リクエストデータを送信するための前準備として、所定の識別情報（ＩＤ）を付加した送信パケットを一度だけサーバ１１０に送信する。そして、それに対する返信パケットの送信元アドレスを抽出し、次回以降の宛先アドレスとして使用する。これにより、次回以降にサーバ１１０に対して送信するリクエストデータにＩＤを付加しなくとも、リクエストデータとレスポンスデータ（送信パケットと返信パケット）を関連付けることが可能となる。

図７は、クライアントＰＣ１００からサーバ１１０にパケットを送信する際の、クライアントＰＣ１００側の通信制御部４０５の処理を説明するフローチャートである。図７のフローチャートに示す各動作は、クライアントＰＣ１００のＣＰＵ２１１が制御プログラムを実行することにより実行される。
ステップＳ７０１では、アプリケーション４０６からの送信要求を受け付ける。ステップＳ７０２では、図９を用いて後述するアドレス管理テーブルを参照し、アプリケーション４０６から指定された宛先アドレスと一致するものがテーブル内の要求アドレス９０３に含まれているか否かを判定する。この判定の結果、一致するＩＰアドレスが存在する場合はステップＳ７０７に進み、そうでなければステップＳ７０３に進む。

ステップＳ７０３では、アプリケーション４０６から指定された宛先アドレスに対して、所定の識別情報（ＩＤ）を付加した送信パケットを送信する（図６のＰ６０１）。このとき、アプリケーション４０６から指定された宛先アドレスを、図９に示すアドレス管理テーブルの要求アドレス９０３に、新規レコードとして追加する。
ステップＳ７０４では、クライアントＰＣ１００宛てのパケットを受信したか否かを判定する。クライアントＰＣ１００宛てのパケットを受信した場合は、ステップＳ７０５に進み、ステップＳ７０３で送信した送信パケットに付加したＩＤと同じＩＤが、受信したパケットに付加されているか否かを判定する。この判定の結果、ＩＤが付加されていた場合はステップＳ７０６に進む。受信したパケットにＩＤが付加されている場合は、そのパケットがステップＳ７０３で送信した送信パケットに対する返信パケットであることが識別できる。

ステップＳ７０６では、受信した返信パケットの送信元アドレスを抽出し、図９に示すアドレス管理テーブルの送信元アドレス９０４に追加する（図６のＰ６０４）。続くステップＳ７０７では、アプリケーション４０６から指定された宛先アドレスと、ステップＳ７０６で抽出した送信元アドレスとが異なるものである場合は、使用する宛先アドレスをステップＳ７０６で抽出したものに変更する（図６のＰ６０５）。なお、アプリケーション４０６から指定された宛先アドレスと、ステップＳ７０６で抽出した送信元アドレスとが同じものである場合は、ここでの変更は必要ない。

ステップＳ７０８では、ステップＳ７０６で抽出した送信元アドレスを宛先アドレスとして、アプリケーションから送信要求されたデータをサーバ１１０に送信する（図６のＰ６０６）。
ステップＳ７０９では、クライアントＰＣ１００宛てのパケットを受信したか否かを判定する。クライアントＰＣ１００宛てのパケットを受信した場合は、ステップＳ７１０に進み、受信したパケットの送信元アドレスが、ステップＳ７０８で送信した送信パケットの宛先アドレスと一致するか否かを判定する。この判定の結果、アドレスが一致した場合はステップＳ７１１に進む。アドレスが一致した場合は、受信したパケットがステップＳ７０８で送信した送信パケットに対する返信パケットであることが識別できる。

ステップＳ７１１では、サーバ１１０との通信結果をアプリケーション４０６に対してコールバック（通知）する。このとき、アプリケーション４０６に対して通知するサーバ１１０のＩＰアドレスを、元々アプリケーション４０６が指定したＩＰアドレスとするか、ステップＳ７０７で変更された後のＩＰアドレスとするか、或いは、それらの両方とするかは予め設定可能である。

ステップＳ７１２では、アプリケーション４０６からのクローズ要求があったかどうかを判定し、クローズ要求があった場合はステップＳ７１３で通信を切断して処理を終了する。アプリケーション４０６からのクローズ要求がない場合は、ステップＳ７０１に戻り処理を継続する。
図８は、クライアントＰＣ１００からサーバ１１０にパケットを送信する際の、サーバ１１０側の通信制御部４０２の処理を説明するフローチャートである。図８のフローチャートに示す各動作は、サーバ１１０のＣＰＵ３１１が制御プログラムを実行することにより実行される。

ステップＳ８０１では、サーバ１１０宛てのパケットを受信する。ステップＳ８０２では、受信したパケットに所定の識別情報（ＩＤ）が付加されているか否かを判定する。この判定の結果、ＩＤが付加されている場合はステップＳ８０７に進み、そうでなければステップＳ８０３に進む。
ステップＳ８０７では、受信したパケット内のデータをアプリケーション４０１に転送することなく、通信制御部４０２が返信パケットを生成し、送信する（図６のＰ６０３）。このとき、返信パケットの宛先アドレスは、ステップＳ８０１で受信したパケットの送信元アドレスを用いる。また、返信パケットの送信元アドレスは、図６のＰ６０２で説明した通り、ＲＦＣ３４８４に従った方法で選択されたＩＰアドレスが使用される。

ステップＳ８０３では、受信したパケットがアプリケーション４０１に対する処理要求であるか否かを判定し、アプリケーション４０１に対する処理要求である場合はステップＳ８０４に進む。アプリケーション４０１に対する処理要求でない場合は、受信したパケットを破棄してステップＳ８０８に進む。
ステップＳ８０４では、受信したパケットに含まれるデータをアプリケーション４０１に転送する。続くステップＳ８０５では、アプリケーション４０１からの送信要求を受け付ける。

ステップＳ８０６では、アプリケーション４０１から送信が要求されたデータ（レスポンスデータ）を返信パケットとして送信する（図６のＰ６０８）。このとき、返信パケットの宛先アドレスは、ステップＳ８０１で受信したパケットの送信元アドレスを用いる。また、返信パケットの送信元アドレスは、図６のＰ６０７で説明した通り、ＲＦＣ３４８４に従った方法で選択されたＩＰアドレスが使用される。

ステップＳ８０８では、アプリケーション４０１が提供するサービスを終了するか否かを判定し、サービスを終了する場合はそのまま処理を終了する。サービスを終了しない場合は、ステップＳ８０１に戻り処理を継続する。
図９は、ＨＤＤ２１４に記憶されているアドレス管理テーブルを示す図である。アドレス管理テーブルには、管理番号９０１、アプリケーション識別９０２、アプリケーションからの要求アドレス９０３、及び返信パケットの送信元アドレス９０４が対応付けて管理されている。

管理番号９０１は、アドレス管理テーブルに管理されている各レコードを一意に識別ための情報である。アプリケーション識別９０２は、図７のステップＳ７０１において送信要求を行ったアプリケーションを識別するための情報である。
アプリケーションからの要求アドレス９０３は、ステップＳ７０３においてアドレス管理テーブルに追加される情報である。返信パケットの送信元アドレス９０４は、ステップＳ７０６においてアドレス管理テーブルに追加される情報である。

以上の通り、第１の実施形態では、リクエストデータを送信するための前準備としてＩＤを付加した送信パケットを一度だけ送信し、この送信パケットに対する返信パケットの送信元アドレスを抽出する。そして、次回以降のパケット送信（リクエストデータの送信）では、抽出した送信元アドレスを宛先アドレスとして使用する。これにより、ＵＤＰ通信を行う場合に、アプリケーションが扱うデータにＩＤを付加せずともリクエストとレスポンス（送信パケットと返信パケット）を関連付けることができる。即ち、アプリケーションのプログラム内容を大幅に変更せずとも、サーバ１１０側に多数のＴＣＰセッションを確立するためのリソースがない場合に、クライアントＰＣ１００とサーバ１１０がＵＤＰで通信することができる。

次に本発明の第２の実施形態について説明する。第１の実施形態では、リクエストデータを送信するための前準備としてＩＤを付加した送信パケットを一度だけ送信し、この送信パケットに対する返信パケットの送信元アドレスを抽出する処理を行った。
しかしながら、クライアントＰＣ１００とサーバ１１０との間に、ルータのような通信機器やファイアウォールのようなソフトウェアが介在する場合には、“Ingress Filtering Problem”が発生しうる。これは、送信パケットの宛先アドレスと、返信パケットの発信元アドレスが異なる場合は、ルータやファイアウォールが返信パケットを通さず、破棄してしまうという問題である。

従って、サーバ１１０が送信する返信パケットの送信元アドレスが、クライアントＰＣ１００が送信した送信パケットの宛先アドレスと異なるものである場合、クライアントＰＣ１００はパケットを受信することすらできない。このため、第１の実施形態で説明した方法では対応することができない。
そこで第２の実施形態では、サーバ１１０が送信する返信パケットの送信元アドレスが、クライアントＰＣ１００が送信した送信パケットの宛先アドレスと異なるものになることがないＴＣＰパケットを利用する。

図１０は、第２の実施形態におけるクライアントＰＣ１００とサーバ１１０との間のパケット通信の詳細を説明するシーケンス図である。図６と同様に、クライアントＰＣ１００には、ＩＰアドレスａ（2001:db8:abcd::ef）に加えて、ＩＰアドレスｃ（2001:db8:cccc::c）が割り当てられている。また、サーバ１１０には、ＩＰアドレスｂ（2001:db8:aaaa::a）に加えてＩＰアドレスｄ（2001:db8:bbbb::b）が割り当てられている。

第２の実施形態におけるクライアントＰＣ１００は、リクエストデータを送信するための前準備として、Ｐ１００１において、ＴＣＰパケットを用いてサーバ１１０に対してアドレスリストを要求する。この要求を受けたサーバ１１０は、Ｐ１００２において、自装置に割り当てられている複数のＩＰアドレスを記述したアドレスリストを生成する。そして、Ｐ１００３において、ＴＣＰパケットを用いてクライアントＰＣ１００にアドレスリストを送信する。

なお、ＴＣＰパケットを用いた通信の場合、送信パケットの宛先アドレスが返信パケットの送信元アドレスとして使用されるため、返信パケットの送信元アドレスが送信パケットの宛先アドレスと異なるものとなることはない。
Ｐ１００４では、クライアントＰＣ１００が、受信したアドレスリストをＨＤＤ２１４に記憶する。

Ｐ１００５では、図６のＰ６０１の処理と同様に、所定の識別情報（ＩＤ）を付加した送信パケットをサーバ１１０に対して送信する。なお、この送信パケットはＵＤＰパケットである。
Ｐ１００６では、図６のＰ６０２の処理と同様に、サーバ１１０が返信パケットを生成する。この返信パケットには、送信パケットに含まれていたＩＤが付加される。続くＰ１００７では、図６のＰ６０３と同様に、返信パケットをクライアントＰＣ１００に対して送信する。

Ｐ１００８では、クライアントＰＣ１００とサーバ１１０との間に存在するルータまたはファイアウォールによって、サーバ１１０からの返信パケットが破棄される。なぜなら、Ｐ１００５の送信パケットの宛先アドレス（ＩＰアドレスｄ）と、Ｐ１００７の返信パケットの送信元アドレス（ＩＰアドレスｂ）が異なっているため、ＤｏＳ（Denial of Service）攻撃の可能性があると判断されてしまうからである。

Ｐ１００９では、クライアントＰＣ１００が、Ｐ１００５で送信パケットを送信した後、サーバ１１０からの返信パケットを受信しないまま所定時間が経過したことを検知する。そして、Ｐ１０１０では、Ｐ１００４で記憶したアドレスリストを参照し、Ｐ１００５の送信パケットで使用した宛先アドレス以外のＩＰアドレスを取得し、宛先アドレスを取得したＩＰアドレスに変更する。

Ｐ１０１１では、変更後のＩＰアドレスを宛先として、ＩＤを付加した送信パケットを再度サーバ１１０に送信する。Ｐ１０１２では、サーバ１１０が返信パケットを生成する。この返信パケットには、送信パケットに含まれていたＩＤが付加される。続くＰ１０１３では、図６のＰ１００７と同様に、返信パケットをクライアントＰＣ１００に対して送信する。

Ｐ１０１３で送信される返信パケットは、Ｐ１００７で送信される返信パケットとは異なり、ルータやファイアウォールを通過してクライアントＰＣ１００に届けられる。なぜなら、Ｐ１０１１の送信パケットの宛先アドレス（ＩＰアドレスｂ）と、Ｐ１０１３の返信パケットの送信元アドレス（ＩＰアドレスｂ）が一致しているからである。
以上の流れで、クライアントＰＣ１００は、サーバ１１０に対してＵＤＰパケットを送信するのに適したＩＰアドレス（ＩＰアドレスｂ）を知ることができる。これにより、次回以降にサーバ１１０にリクエストデータを送信する際に、ＩＰアドレスｂを宛先アドレスとして使用することにより、サーバ１１０と正常に通信することができる。

図１１は、クライアントＰＣ１００からサーバ１１０にパケットを送信する際の、クライアントＰＣ１００側の通信制御部４０５の処理を説明するフローチャートである。図１１のフローチャートに示す各動作は、クライアントＰＣ１００のＣＰＵ２１１が制御プログラムを実行することにより実行される。
図１１に示すフローチャートは、図７のステップＳ７０２で「いいえ」と判定された場合に開始される。ステップＳ１１０１では、ＴＣＰパケットを用いてサーバ１１０にアドレスリストを要求する（図１０のＰ１００１）。

ステップＳ１１０２では、サーバ１１０からアドレスリストを受信したか否かを判定し、アドレスリストを受信した場合はステップＳ１１０３に進む。ステップＳ１１０３では、受信したアドレスリストをＨＤＤ２１４に記憶する（図１０のＰ１００４）。
ステップＳ１１０４では、アプリケーション４０６から指定された宛先アドレスに対して、所定の識別情報（ＩＤ）を付加した送信パケットを送信する（図１０のＰ１００５）。このとき、アプリケーション４０６から指定された宛先アドレスを、図９に示すアドレス管理テーブルの要求アドレス９０３に、新規レコードとして追加する。

ステップＳ１１０５では、クライアントＰＣ１００宛てのパケットを受信したか否かを判定する。クライアントＰＣ１００宛てのパケットを受信した場合は、ステップＳ１１０６に進み、ステップＳ１１０４で送信した送信パケットに付加したＩＤが、受信したパケットに付加されているか否かを判定する。この判定の結果、ＩＤが付加されていた場合は図７のステップＳ７０６に進む。受信したパケットにＩＤが付加されている場合は、そのパケットがステップＳ１１０４で送信した送信パケットに対する返信パケットであることが識別できる。

一方、ステップＳ１１０５でクライアントＰＣ１００宛てのパケットを受信していないと判定した場合は、ステップＳ１１０７に進み、ステップＳ１１０４で送信パケットを送信してから所定時間が経過したかどうかを判定する。
この判定の結果、所定時間が経過していればステップＳ１１０８に進み、そうでなければステップＳ１１０５に戻る。ステップＳ１１０８では、Ｓ１１０３で記憶したアドレスリストに含まれるＩＰアドレスのうち、ステップＳ１１０４の送信パケットで使用したものと異なるものに宛先アドレスを変更する。

なお、使用していないＩＰアドレスが存在しない（アドレスリストに含まれるＩＰアドレスが全て使用済みである）場合は、アプリケーション４０６に対して通信エラーを通知する。ステップＳ１１０８で宛先アドレスを変更した後、ステップＳ１１０４に戻り、変更後の宛先アドレスに対して、ＩＤを付加した送信パケットを送信する。
以上の通り、第２の実施形態では、リクエストデータを送信するための前準備としてＴＣＰパケットを用いてサーバ１１０のアドレスリストを取得する。そして、ルータやファイアウォールの存在により、サーバ１１０からの返信パケットを受信できなかった場合は、アドレスリストに含まれる他のＩＰアドレスを宛先としてＩＤを付加した送信パケットを再送信する。これにより、ルータやファイアウォールが存在する環境においても、サーバ１１０との通信を正常に行うことが可能となる。

他の実施例

なお、本発明の目的は、以下の処理を実行することによっても達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために以下の請求項を添付する。

Claims (8)

1. 複数のアドレスが割り当てられた外部装置とネットワークを介して接続される通信装置であって、
   所定の識別情報を含むパケットを、前記複数のアドレスに含まれる第１のアドレスを宛先として前記外部装置に送信する送信手段と、
   前記外部装置から送信されたパケットを受信する受信手段と、
   前記受信手段が受信したパケットに前記所定の識別情報が含まれている場合に、当該受信したパケットの送信元アドレスを抽出する抽出手段と、
   前記抽出手段が抽出した送信元アドレスが前記第１のアドレスとは異なる第２のアドレスである場合は、次回以降に前記外部装置に対してパケットを送信する際に前記第２のアドレスを宛先として送信するよう制御する制御手段と、
   を備えることを特徴とする通信装置。
2. 前記外部装置に対して次回以降に送信するパケットには、前記所定の識別情報が含まれないことを特徴とする請求項１に記載の通信装置。
3. 前記送信手段が前記所定の識別情報を含むパケットを送信する際に用いた宛先アドレスと、前記抽出手段により抽出された送信元アドレスとを対応付けて管理する管理手段と、
   所定のアドレスを宛先とする新規のパケット送信が要求された場合に、当該所定のアドレスが前記管理手段により管理されている宛先アドレスと一致するか否かを判定する判定手段と、
   前記制御手段は、前記判定手段による判定の結果、前記所定のアドレスが前記管理手段により管理されている宛先アドレスと一致すると判定された場合に、当該所定のアドレスに対応付けて前記管理手段により管理されている送信元アドレスを宛先として前記新規のパケット送信を行うよう制御することを特徴とする請求項１に記載の通信装置。
4. 前記判定手段による判定の結果、前記所定のアドレスが前記管理手段により管理されている宛先アドレスと一致しないと判定された場合に、前記送信手段は、当該所定のアドレスを宛先として前記所定の識別情報を含むパケットを送信することを特徴とする請求項３に記載の通信装置。
5. ＴＣＰパケットを送信することにより、前記外部装置に割り当てられた前記複数のアドレスを示すアドレスリストを前記外部装置に対して要求する要求手段と、
   前記要求手段による要求に応じて前記外部装置から送信されたアドレスリストを記憶する記憶手段と、を更に備え、
   前記送信手段は、前記記憶手段に記憶されているアドレスリストを参照し、当該アドレスリストに含まれているアドレスに対して、前記所定の識別情報を含むパケットを送信することを特徴とする請求項１に記載の通信装置。
6. 前記送信手段が送信するパケットは、ＵＤＰパケットであることを特徴とする請求項１に記載の通信装置。
7. 複数のアドレスが割り当てられた外部装置とネットワークを介して接続される通信装置の制御方法であって、
   所定の識別情報を含むパケットを、前記複数のアドレスに含まれる第１のアドレスを宛先として前記外部装置に送信する送信工程と、
   前記外部装置から送信されたパケットを受信する受信工程と、
   前記受信工程で受信したパケットに前記所定の識別情報が含まれている場合に、当該受信したパケットの送信元アドレスを抽出する抽出工程と、
   前記抽出工程で抽出した送信元アドレスが前記第１のアドレスとは異なる第２のアドレスである場合は、次回以降に前記外部装置に対してパケットを送信する際に前記第２のアドレスを宛先として送信するよう制御する制御工程と、
   を備えることを特徴とする通信装置の制御方法。
8. 請求項７に記載の通信装置の制御方法をコンピュータに実行させるためのプログラム。

Images