(57)【特許請求の範囲】
【請求項１】
複数のアドレスが割り当てられた外部装置とネットワークを介して通信可能な通信装置であって、
前記通信装置で動作しているアプリケーションから送信要求を受け付ける受付手段と、
前記受付手段が前記アプリケーションから前記送信要求を受け付けた場合に、所定の識別情報を含むパケットを前記送信要求において指定されている宛先アドレスを用いて前記外部装置に送信する送信手段と、
前記所定の識別情報を含む返信パケットを受信する受信手段とを備え、
前記送信手段は、前記送信要求において指定されている宛先アドレスではなく前記返信パケットの送信元アドレスを用いて、前記送信要求が示すデータ送信を実行することを特徴とする通信装置。
【請求項２】
前記受信手段が前記返信パケットを受信した場合に、前記送信要求において指定されている宛先アドレスと前記返信パケットの送信元アドレスが同じアドレスであるか否かを判定する第１の判定手段を更に備え、
前記第１の判定手段によって同じアドレスではないと判定された場合に、前記送信手段は、前記送信要求において指定されている宛先アドレスではなく前記返信パケットの送信元アドレスを用いて、前記送信要求が示すデータ送信を実行し、
前記第１の判定手段によって同じアドレスであると判定された場合に、前記送信手段は、前記送信要求において指定されている宛先アドレスを用いて前記送信要求が示すデータ送信を実行することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記送信手段が前記所定の識別情報を含むパケットを送信する際に用いた宛先アドレスと、前記返信パケットの送信元アドレスとを対応付けて記憶する記憶手段と、
前記受付手段が前記アプリケーションから新規の送信要求を受け付けた場合に、前記新規の送信要求において指定されている宛先アドレスが前記記憶手段に記憶されているか否かを判定する第２の判定手段とを備え、
前記新規の送信要求において指定されている宛先アドレスが前記記憶手段に記憶されていないと前記第２の判定手段によって判定された場合に、前記送信手段は、前記新規の送信要求において指定されている宛先アドレスに前記所定の識別情報を含むパケットを送信することを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記新規の送信要求において指定されている宛先アドレスが前記記憶手段に記憶されていると前記第２の判定手段によって判定された場合に、前記送信手段は、前記所定の識別情報を含むパケットを送信しないことを特徴とする請求項３に記載の通信装置。
【請求項５】
複数のアドレスが割り当てられた外部装置とネットワークを介して通信可能な通信装置の制御方法であって、
前記通信装置で動作しているアプリケーションから送信要求を受け付ける受付工程と、
前記受付工程で前記アプリケーションから前記送信要求を受け付けた場合に、所定の識別情報を含むパケットを前記送信要求において指定されている宛先アドレスを用いて前記外部装置に送信する第１の送信工程と、
前記所定の情報を含む返信パケットを受信する受信工程と、
前記送信要求において指定されている宛先アドレスではなく前記返信パケットの送信元アドレスを用いて、前記送信要求が示すデータ送信を実行する第２の送信工程と
を備えることを特徴とする通信装置の制御方法。
【請求項６】
請求項５に記載の通信装置の制御方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のアドレスが割り当てられた外部装置とネットワークを介して接続される通信装置、通信装置の制御方法、プログラムに関する。
【背景技術】
【０００２】
従来、ネットワーク（ＬＡＮ、インターネット等）に接続され、ネットワーク上の外部装置と通信する様々な通信装置が知られている。
ネットワークに接続される通信装置において広く使用されているプロトコルはインターネットプロトコルである。インターネットプロトコルでは各装置に固有のアドレス（ＩＰアドレス）を割り当て、このＩＰアドレスを用いて互いの装置を識別している。【０００３】
従来のＩＰ規約（ＩＰｖ４：ＩＰバージョン４）では、１つのネットワークインターフェースに対して１つのＩＰアドレスが割り当てられることが一般的であった。一方、近年普及しつつあるＩＰｖ６（ＩＰバージョン６）では、通信装置がルータに接続されると、ルータによってＩＰアドレスが割り当てられる。また、ルータが存在しない場合にも通信を行えるようにするために、ネットワークインターフェース毎に１つのＩＰｖ６アドレス（リンクローカルアドレス）が割り当てられる。更には、ＤＨＣＰサーバが存在する場合は、ＤＨＣＰサーバが発行したＩＰアドレスを取得することもできる。【０００４】
このように、ＩＰｖ６に対応している通信装置では、１つのネットワークインターフェースに対してＩＰｖ４アドレスや複数のＩＰｖ６アドレスといった複数のＩＰアドレスが割り当てられることになる。
１つのネットワークインターフェースに複数のＩＰアドレスが割り当てられた場合におけるＩＰアドレスの選択方法として、非特許文献１（ＲＦＣ３４８４）が知られている。非特許文献１に示される方法では、条件に合致する複数のＩＰアドレスのうちプレフィックス長がより長いＩＰアドレスを選択する。【０００５】
非特許文献１の方法を用いたＩＰアドレスの選択が行われる場合、次のような問題が発生することがある。例えば、ＩＰアドレスＡが割り当てられた装置ＡとＩＰアドレスＢ及びＣが割り当てられた装置ＢがＵＤＰ通信する場合、装置Ａが装置Ｂに送信するリクエストの宛先アドレスとしてＩＰアドレスＢを指定したとする。このとき、装置Ｂから装置Ａに対するレスポンスの宛先アドレスは、装置Ａから装置Ｂへのリクエストの送信元アドレスとして使用されたＩＰアドレスＡが設定される。また、装置Ｂから装置Ａに対するレスポンスの送信元アドレスは、非特許文献１の方法に従って装置ＢがＩＰアドレスＢ及びＣのいずれかを選択する。即ち、装置Ｂは、ＩＰアドレスＢ及びＣのうち、ＩＰアドレスＡに対するプレフィックス長がより長い方のＩＰアドレスを選択する。【０００６】
しかしながら、装置Ｂよる選択の結果、送信元アドレスとしてＩＰアドレスＣが選択されたとすると問題が生じる。なぜなら、装置ＡはＩＰアドレスＢを宛先としてリクエストを送信したため、ＩＰアドレスＢを送信元アドレスとするレスポンスのみを待ち続けており、ＩＰアドレスＣを送信元アドレスとするレスポンスが届いたとしても破棄してしまうからである。【０００７】
このような問題に対処するために、非特許文献２（ＷＳ−Ｅｖｅｎｔｉｎｇ）が知られている。非特許文献２に示される方法では、トランスポート層よりも上位の層に対応するデータにＭｅｓｓａｇｅＩＤ（ＲｅｑｕｅｓｔＩＤ）を付加し、このＩＤを参照してレスポンスを識別する。即ち、レスポンスの送信元アドレスを参照するのではなく、上位層のデータに付加されたＩＤを参照することによりリクエストとレスポンスを関連付ける。これにより、リクエストの宛先アドレスとして用いたＩＰアドレスとは異なるＩＰアドレスがレスポンスの発信元アドレスとして用いられたとしても、リクエストとレスポンスを関連付けることが可能となっている。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】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）攻撃の可能性があると判断されてしまうからである。【００５６】
Ｐ１００９では、クライアントＰＣ１００が、Ｐ１００５で送信パケットを送信した後、サーバ１１０からの返信パケットを受信しないまま所定時間が経過したことを検知する。そして、Ｐ１０１０では、Ｐ１００４で記憶したアドレスリストを参照し、Ｐ１００５の送信パケットで使用した宛先アドレス以外のＩＰアドレスを取得し、宛先アドレスを取得したＩＰアドレスに変更する。【００５７】
Ｐ１０１１では、変更後のＩＰアドレスを宛先として、ＩＤを付加した送信パケットを再度サーバ１１０に送信する。Ｐ１０１２では、サーバ１１０が返信パケットを生成する。この返信パケットには、送信パケットに含まれていたＩＤが付加される。続くＰ１０１３では、図６のＰ１００７と同様に、返信パケットをクライアントＰＣ１００に対して送信する。【００５８】
Ｐ１０１３で送信される返信パケットは、Ｐ１００７で送信される返信パケットとは異なり、ルータやファイアウォールを通過してクライアントＰＣ１００に届けられる。なぜなら、Ｐ１０１１の送信パケットの宛先アドレス（ＩＰアドレスｂ）と、Ｐ１０１３の返信パケットの送信元アドレス（ＩＰアドレスｂ）が一致しているからである。
以上の流れで、クライアントＰＣ１００は、サーバ１１０に対してＵＤＰパケットを送信するのに適したＩＰアドレス（ＩＰアドレスｂ）を知ることができる。これにより、次回以降にサーバ１１０にリクエストデータを送信する際に、ＩＰアドレスｂを宛先アドレスとして使用することにより、サーバ１１０と正常に通信することができる。【００５９】
図１１は、クライアントＰＣ１００からサーバ１１０にパケットを送信する際の、クライアントＰＣ１００側の通信制御部４０５の処理を説明するフローチャートである。図１１のフローチャートに示す各動作は、クライアントＰＣ１００のＣＰＵ２１１が制御プログラムを実行することにより実行される。
図１１に示すフローチャートは、図７のステップＳ７０２で「いいえ」と判定された場合に開始される。ステップＳ１１０１では、ＴＣＰパケットを用いてサーバ１１０にアドレスリストを要求する（図１０のＰ１００１）。【００６０】
ステップＳ１１０２では、サーバ１１０からアドレスリストを受信したか否かを判定し、アドレスリストを受信した場合はステップＳ１１０３に進む。ステップＳ１１０３では、受信したアドレスリストをＨＤＤ２１４に記憶する（図１０のＰ１００４）。
ステップＳ１１０４では、アプリケーション４０６から指定された宛先アドレスに対して、所定の識別情報（ＩＤ）を付加した送信パケットを送信する（図１０のＰ１００５）。このとき、アプリケーション４０６から指定された宛先アドレスを、図９に示すアドレス管理テーブルの要求アドレス９０３に、新規レコードとして追加する。【００６１】
ステップＳ１１０５では、クライアントＰＣ１００宛てのパケットを受信したか否かを判定する。クライアントＰＣ１００宛てのパケットを受信した場合は、ステップＳ１１０６に進み、ステップＳ１１０４で送信した送信パケットに付加したＩＤが、受信したパケットに付加されているか否かを判定する。この判定の結果、ＩＤが付加されていた場合は図７のステップＳ７０６に進む。受信したパケットにＩＤが付加されている場合は、そのパケットがステップＳ１１０４で送信した送信パケットに対する返信パケットであることが識別できる。【００６２】
一方、ステップＳ１１０５でクライアントＰＣ１００宛てのパケットを受信していないと判定した場合は、ステップＳ１１０７に進み、ステップＳ１１０４で送信パケットを送信してから所定時間が経過したかどうかを判定する。
この判定の結果、所定時間が経過していればステップＳ１１０８に進み、そうでなければステップＳ１１０５に戻る。ステップＳ１１０８では、Ｓ１１０３で記憶したアドレスリストに含まれるＩＰアドレスのうち、ステップＳ１１０４の送信パケットで使用したものと異なるものに宛先アドレスを変更する。【００６３】
なお、使用していないＩＰアドレスが存在しない（アドレスリストに含まれるＩＰアドレスが全て使用済みである）場合は、アプリケーション４０６に対して通信エラーを通知する。ステップＳ１１０８で宛先アドレスを変更した後、ステップＳ１１０４に戻り、変更後の宛先アドレスに対して、ＩＤを付加した送信パケットを送信する。
以上の通り、第２の実施形態では、リクエストデータを送信するための前準備としてＴＣＰパケットを用いてサーバ１１０のアドレスリストを取得する。そして、ルータやファイアウォールの存在により、サーバ１１０からの返信パケットを受信できなかった場合は、アドレスリストに含まれる他のＩＰアドレスを宛先としてＩＤを付加した送信パケットを再送信する。これにより、ルータやファイアウォールが存在する環境においても、サーバ１１０との通信を正常に行うことが可能となる。
【他の実施例】
【００６４】
なお、本発明の目的は、以下の処理を実行することによっても達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００６５】
本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために以下の請求項を添付する。
【図１】
0005638063.tif 000002
【図２】
0005638063.tif 000003
【図３】
0005638063.tif 000004
【図４】
0005638063.tif 000005
【図５】
0005638063.tif 000006
【図６】
0005638063.tif 000007
【図７】
0005638063.tif 000008
【図８】
0005638063.tif 000009
【図９】
0005638063.tif 000010
【図１０】
0005638063.tif 000011
【図１１】
0005638063.tif 000012