JP2005092582A - データ転送方法、通信システム、および通信装置 - Google Patents

Abstract

【課題】 通信を行っている途中で、一方の通信装置の通信アドレスが変更されたときでも、通信を継続する。
【解決手段】クライアント２は、サーバ１とのセッションを確立すると、確立されたセッションを識別するセッションＩＤとクライアント２の通信アドレスとを、サーバ１へ送信し、サーバ１は、クライアント２との間で確立されたセッションを識別するためのセッションＩＤと、クライアント２の通信アドレスとを対応付けて記憶するセッション情報記憶部１５を備え、クライアント２から受信した前期セッションＩＤおよび通信アドレスに基づいて、前期セッション情報記憶部１５の内容を更新し、サーバ１があるセッションについてクライアント２へデータを送信するとき、セッション情報記憶部１５からそのセッションのセッションＩＤと対応付けられている通信アドレスを取得して送信データを生成して送信する。
【選択図】 図１

Description

本発明は、データ転送をするための技術に関し、特に、通信途中で一方の通信装置のＩＰアドレスが変更になってもデータ転送を継続するための技術に関する。

ＩＰ（Internet Protocol）を使用したネットワーク通信において、互いに通信し合う通信装置をネットワーク上で識別するための通信アドレスとしてはＩＰアドレスを用いる。ＩＰ通信技術として最も普及しているＴＣＰ（Transmission Control Protocol）では、２つの通信装置間でデータ転送を開始する前に、それぞれ自装置のＩＰアドレスおよびポート番号を互いに通知するＴＣＰ接続フェーズがある。そして、このＴＣＰ接続フェーズで取得したＩＰアドレスおよびポート番号を用いて、それぞれの通信装置はそれ以降の通信を行う。

TCP: RFC793 ( http://www.faqs.org/rfcs/rfc2001.html )

ここで、ＴＣＰでは通信を行っている途中で、通信装置のＩＰアドレスは変更されないことを前提にプロトコルが規定されている。

しかし、実際の利用状況に鑑みると、通信途中でＩＰアドレスが変更されてしまうことがしばしば起きる。例えば、データ通信サービスを提供するサーバは、比較的ネットワーク環境の良い場所に設置されているが、サーバにアクセスするクライアントは、低品質の電話回線や無線網を介して接続されることがある。このような場合、ネットワーク上の信号の減衰などによりＩＰの下位レイアが通信中に切断されてしまい、再接続したときにＩＰアドレスが変更される可能性がある。

通信中にＩＰアドレスが変更されてしまうと、ＴＣＰは通信を継続することができず、最初の「ＴＣＰ接続フェーズ」からやり直さなくてはならない。

本発明の目的は、通信を行っている途中で、一方の通信装置の通信アドレスが変更されたときでも、通信を継続するための技術を提供することである。

本発明の一つの実施態様に従う通信システムは、第１の通信装置と第２の通信装置とを備える。第１の通信装置は、第２の通信装置とセッションを確立し、第２の通信装置へデータ送信をリクエストする手段と、前記リクエストに対して第２の通信装置から送信されたデータを受信する手段と、前記確立されたセッションを識別するセッション識別情報と自装置の通信アドレスとを、第２の通信装置へ繰り返し送信する手段と、を備える。そして、第２の通信装置は、第１の通信装置との間で確立されたセッションを識別するためのセッション識別情報と、第１の通信装置の通信アドレスとを対応付けて記憶するための記憶部と、第１の通信装置から送信された前記セッション識別情報および前記通信アドレスを受信する手段と、前記受信手段が受信した前記セッション識別情報および前記通信アドレスに基づいて、前記記憶部を更新する手段と、前記セッションで第１の通信装置へデータを送信するとき、前記記憶部から当該セッションのセッション識別情報と対応付けられている通信アドレスを取得し、取得した通信アドレス宛に前記データを送信するための送信データを生成して、送信する手段と、を備える。

本発明の一つの実施態様に従う通信装置は、他の通信装置との間で確立されたセッションを識別するためのセッション識別情報と、前記他の通信装置の通信アドレスとを対応付けて記憶するための記憶部と、前記他の通信装置から前記セッション識別情報および前記通信アドレスを受信する手段と、前記受信手段が受信した前記セッション識別情報および前記通信アドレスに基づいて、前記記憶部を更新する手段と、前記セッションで前記他の通信装置へデータを送信するとき、前記記憶部から当該セッションのセッション識別情報と対応付けられている通信アドレスを取得し、取得した通信アドレス宛に前記データを送信するための送信データを生成し、出力する手段と、を備える。

好適な実施形態では、前記記憶部に、前記受信手段が受信したセッション識別情報と同一のセッション識別情報に対応付けて記憶されている通信アドレスが、前記受信手段が受信した通信アドレスと同一でないとき、前記更新手段は、前記記憶部の通信アドレスを上書きして更新することができる。

好適な実施形態では、前記通信アドレスは、前記他の通信装置のＩＰアドレスと前記他の通信装置におけるポート番号としてもよい。

好適な実施形態では、前記送信データを出力する手段は、前記データを複数に分割し、分割されたデータに基づいてそれぞれ送信データを生成して出力するものであり、前記受信手段が、最後に前記セッション識別情報および通信アドレスを受信した時刻から所定時間以上経過すると、前記送信データを出力する手段は、それ以降、前記送信データの出力を行わないようにしてもよい。

好適な実施形態では、前記送信データを出力する手段が前記送信データの出力を停止した後、前記受信手段が前記セッション識別情報および通信アドレスを受信すると、
前記送信データを出力する手段は、前記送信データの出力を再開するようにしてもよい。

本発明の一つの実施態様に従う通信装置は、他の通信装置とセッションを確立し、前記他の通信装置へデータ送信をリクエストする手段と、前記リクエストに対して他の通信装置から送信されたデータを受信する手段と、前記確立されたセッションを識別するセッション識別情報と自装置の通信アドレスとを、前記他の通信装置へ繰り返し送信する手段と、を備える。

好適な実施形態では、前記受信手段は、送信をリクエストしたデータが複数に分割されて送信されてくるとき、これらを順次受信し、リクエストした全データを前記受信手段が受信するまでの間、前記送信手段は前記セッション識別情報および前記自装置の通信アドレスを繰り返し送信するようにしてもよい。

好適な実施形態では、前記送信手段は、前記セッション識別情報および前記自装置の通信アドレスを、所定の時間間隔で繰り返し送信するか、または、前記受信手段が所定数の分割されたデータを受信するごとに送信することができる。

本発明の一つの実施態様に従う通信システムは、第１の通信装置と第２の通信装置とを備える。そして、第１の通信装置は、第２の通信装置とセッションを確立する手段と、前記確立されたセッションを識別するセッション識別情報と自装置の通信アドレスと送信データとを、第２の通信装置へ繰り返し送信する手段と、を備える。第２の通信装置は、第１の通信装置との間で確立されたセッションを識別するためのセッション識別情報と、第１の通信装置の通信アドレスとを対応付けて記憶するための記憶部と、第１の通信装置から送信された前記セッション識別情報、前記通信アドレスおよび送信データを受信する手段と、前記受信手段が受信した情報に基づいて、前記記憶部を更新する手段と、を備える。

以下、本発明の一実施形態に係るデータ転送システムついて、図面を用いて説明する。

図１は、本発明の第１の実施形態に係るデータ転送システムである。本システムは、データの送受信機能を備えたサーバ１およびクライアント２が、互いにインターネットなどのネットワーク９を介して接続されている。ここではサーバ１とクライアント２とが１対１であるが、本発明は一つのサーバ１に対して複数のクライアント２が接続する場合にも適用可能である。

本実施形態では、クライアント２がサーバ１からデータをダウンロードする。つまり、クライアント２からのリクエストに応じてサーバ１がデータを提供する。従って、サーバ１がデータの送信装置であり、クライアント２がデータの受信装置である。サーバ１とクライアント２とは、プロトコルにＵＤＰ（User Datagram Protocol）／ＩＰを用いて通信を行う。ここで、クライアント２は、無線によってサーバ１と通信を行う端末であってもよい。例えば、携帯電話機、ＰＤＡ（Personal Data Assistant）、無線通信機能を備えたパーソナルコンピュータなどでもよい。

サーバ１およびクライアント２は、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明するサーバ１およびクライアント２内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。

クライアント２は、図１に示すように、通信制御部２１と、リクエストＩＤ生成部２２と、セッション要求部２３と、ハートビート送信部２４と、データ受信部２５と、アプリケーション（ＡＰ）２６とを備える。

通信制御部２１は、データの送受信制御を行う。例えば、パケットを生成してネットワーク９に対して出力したり、ネットワーク９からパケットを取り込んだりする。本実施形態では、通信プロトコルにＵＤＰ／ＩＰを用いるので、通信制御部２１がＵＤＰに関する制御およびＩＰに関する制御を行う。従って、通信制御部２１からネットワーク９へ出力される全パケットのＩＰヘッダには、クライアント２のＩＰアドレスが含まれ、ＵＤＰヘッダにはリクエストを識別するためのポート番号が含まれている。このＩＰアドレスとポート番号により、パケットの発信元が特定される。従って、以下に説明するデータ転送のリクエスト元を特定するための通信アドレスには、ＩＰアドレスとポート番号とが用いられる。

ここで、ＩＰアドレスは、クライアント２に固定的に割り当てられていてもよいし、動的に割り当てられるようにしてもよい。動的に割り当てられる場合は、クライアント２がデータ受信をしている途中でＩＰアドレスが変更になることもある。このとき、通信制御部２１は、今現在、割り当てられているＩＰアドレスに基づいてパケットの送受信を行う。

アプリケーション（ＡＰ）２６は、所定の処理を行うプログラムである。ＡＰ２６は、例えば、Ｗｅｂブラウザなどでもよい。そして、ＡＰ２６がサーバからデータをダウンロードしたいときは、リクエストＩＤ生成部２３へデータの識別情報、例えばファイル名などを通知して、データ取得要求をする。

リクエストＩＤ生成部２２は、サーバ１に対してデータ転送をリクエストするときに、リクエストＩＤを生成する。リクエストＩＤは、そのリクエストをクライアント２内で一意に識別するための識別情報である。従って、同一クライアントが同時に複数のリクエストを行うときでも、リクエストＩＤにより、それぞれのリクエストを識別することができる。リクエストＩＤ生成部２２は、例えば、ＡＰ２６からデータを取得するよう指示を受けると、リクエストＩＤを生成する。そして、生成したリクエストＩＤと、リクエストするデータの識別情報とを併せて、セッション要求部２３へ通知する。

セッション要求部２３は、サーバ１に対してセッションの確立を要求する。セッション要求部２３は、例えば、セッション要求をするための要求メッセージを、通信制御部２１を介してサーバ１へ送信する。この要求メッセージには、リクエストＩＤと、データ転送して欲しいデータの属性（ここではファイル名）などが含まれている。

このセッション要求に対してサーバ１が応じることを示す応諾メッセージを、セッション要求部２３が受信するとセッションが確立する。この応諾メッセージにはリクエストＩＤおよび後述するセッションＩＤが含まれている。そして、このセッションＩＤは、ハートビート送信部２４へ通知される。

ハートビート送信部２４は、セッションＩＤをサーバ１に対して送信する。このセッションＩＤの送信は、リクエストしたデータの受信が完了するまでの間繰り返し行われる。従って、このセッションＩＤの送信をここではハートビートと呼ぶ。ハートビート送信部２４は、一定の条件（以下、ハートビート送信条件という）が満たされるとハートビートを送信する。ハートビート送信条件としては、例えば、個々のハートビートの送信間隔が、あらかじめ定められた時間間隔となるようにしてもよいし、データ受信部２５が所定数のデータパケットを受信するごとにハートビートを送信するとしてもよい。ハートビートとして、実際に通信制御部２１がネットワーク９へ出力するパケットをハートビートパケットという。

データ受信部２５は、サーバ１から送られてくるデータを受信する。例えば、サーバ１に対してリクエストしたデータは、１パケットで送信可能なデータサイズよりも大きいときは複数のパケットに分割されて送信されてくるので、データ受信部２５は分割されたデータを順次受信する。そして、全データの受信が完了すると、ハートビート送信部２５へ受信完了を通知する。また、データ受信部２５が受信したデータは、ＡＰ２６へ渡される。

サーバ１は、図１に示すように、通信制御部１１と、セッション受付部１２と、セッションＩＤ生成部１３と、ハートビート受信部１４と、セッション情報記憶部１５と、データ送信部１６と、データ記憶部１７とを備える。

通信制御部１１は、通信制御部２１と同様の機能を有する。つまり、例えば、パケットを生成してネットワーク９に対して出力したり、ネットワーク９からパケットを取り込んだりする。本実施形態では、通信プロトコルにＵＤＰ／ＩＰを用いるので、通信制御部１１がＵＤＰに関する制御およびＩＰに関する制御を行う。

セッション情報記憶部１５は、クライアント２との間でデータ通信を行うセッションに関する情報を格納するための記憶部である。セッション情報記憶部１５には、例えば、図２に示すような情報が格納される。すなわち、セッション情報記憶部１５は、データ項目として、セッションＩＤ１５１と、クライアント識別情報１５２と、データ属性１５３と、タイムスタンプ１５４とを有する。セッション情報記憶部１５には、１セッションにつき１つのレコードが生成されて、格納される。

クライアント識別情報１５２には、例えば、リクエストＩＤ１５５と、ＩＰアドレス１５６と、ポート番号１５７とが含まれる。

データ属性１５３は、クライアントに対してデータをダウンロードする場合は、ダウンロードするデータのファイル名、クライアントからデータのアップロードを受ける場合は、アップロードするファイルのサイズなどが格納される。

タイムスタンプ１５４は、各レコードが更新された時刻を示す。

再び図１を参照すると、セッション受付部１２は、クライアント２から送信されてくるセッション要求のメッセージを受信する。そして、セッション受付部１２は、このセッション要求を受け入れて、クライアント２とセッションを確立する場合は、セッションＩＤ生成部１３に対してセッションＩＤの生成を依頼する。

セッションＩＤ生成部１３は、セッションＩＤの生成依頼を受けると、セッションを一意に識別するためのセッションＩＤを生成する。

セッションＩＤが生成されると、セッション受付部１２は、セッション情報記憶部１５にこのセッションに関する情報を格納する。例えば、セッションＩＤ１５１にはここで生成されたセッションＩＤがセットされる。リクエストＩＤ１５５には、セッション要求メッセージに含まれているリクエストＩＤがセットされる。ＩＰアドレス１５６には、セッション要求メッセージパケットのＩＰヘッダの発信元ＩＰアドレスがセットされる。ポート番号１５７には、セッション要求メッセージパケットのＵＤＰヘッダの発信元ポート番号がセットされる。

さらに、セッション受付部１２は、セッション要求の受け入れを示す応諾メッセージを、通信制御部１１を介してクライアント２へ返信する。この応諾メッセージには、セッションＩＤおよびリクエストＩＤが含まれている。

ハートビート受信部１４は、クライアント２から送られてくるハートビートを受信する。例えば、ハートビート受信部１４は、通信制御部１１が受信したハートビートパケットに基づいて、それに含まれているセッションＩＤおよびデータ属性の他、ＩＰヘッダおよびＵＤＰヘッダに含まれている発信元のＩＰアドレスおよびポート番号の通知を受ける。そして、ここで通知を受けた情報に基づいて、セッション情報記憶部１５を更新する。例えば、受信したハートビートパケットに含まれているセッションＩＤをキーにして、これと対応付けて記憶されているクライアント２のＩＰアドレス１５６およびポート番号１５７を上書き更新する。ハートビート受信部１４は、セッション情報記憶部１５に格納されているＩＰアドレス１５６およびポート番号１５７と、受信したハートビートパケットに含まれていたＩＰアドレスおよびポート番号が異なる場合のみ、上書き更新してもよい。いずれの場合でも、セッション情報が更新されたときは、タイムスタンプ１５４もその時の時刻に更新する。

データ送信部１６は、クライアント２からリクエストされたデータをデータ記憶部１７から取得し、クライアント２に対して送信する。このとき、送信対象のデータのファイル名は、セッションＩＤをキーにしてデータ属性１５３から取得する。送信先のＩＰアドレスおよびポート番号は、セッションＩＤをキーにしてセッション情報記憶部１５から取得する。

送信対象のデータが１パケットで送信可能なデータサイズよりも大きい場合は、データ送信部１６は、送信対象データを複数に分割して送信する。

ここで、データ送信部１６は、データ送信を行うときに動的に生成され、データ送信が終了すると消滅するようにしてもよい。このとき、一つのデータ送信部１６が一つのスレッドで実現される。この場合、図３に示すような手順でハートビート受信部１４がデータ送信部１６の生成、消滅等を管理する。以下、図３について説明する。

通信制御部１１がハートビートパケットを受信する（Ｓ１１）と、受信したハートビートパケットに基づいて、ハートビート受信部１４が上述の要領でセッション情報記憶部１５を更新する（Ｓ１２）。

このとき、ハートビート受信部１４は、受信したハートビートパケットに含まれているセッションＩＤに対応するデータ送受信部１６が生成されているかを確認する（Ｓ１３）。このデータ送受信部１６が未生成であるときは（Ｓ１３：Ｎｏ）、ハートビート受信部１４が、このセッションＩＤに対応するデータ送受信部１６を生成する（Ｓ１４）。ステップＳ１４でデータ送受信部１６生成した後、またはすでに生成済みであるときは（Ｓ１３：Ｙｅｓ）、送信すべき全データが送信済みであるかを判定する（Ｓ１５）。そして、全データの送信が完了しているときは（Ｓ１５：Ｙｅｓ）、ハートビート受信部１４の処理が終了する。未送信データが残っている場合には（Ｓ１５：Ｎｏ）、ステップＳ１１へ戻り、上記処理を繰り返す。

次に、データ送信部１６の処理手順について、図４を用いて説明する。

まず、データ送信部１６は、どのセッションのデータ送信を行うかがあらかじめ定められている。そこで、データ送信部１６は、セッション情報記憶部１５から、担当するセッションのセッションＩＤと対応付けられているセッション情報を取得する（Ｓ２１）。ここで、タイムスタンプ１５４を参照し、取得したセッション情報が更新されてから所定時間（以下、送信継続判定時間という）以上経過しているかどうかを判定する（Ｓ２２）。タイムスタンプ１５４が示す時刻から、送信継続判定時間以上が経過している場合（Ｓ２２：Ｙｅｓ）、つまり、送信継続判定時間以上セッション情報が更新されていない場合は、データ送信を終了し、データ送信部１６は消滅する。

一方、タイムスタンプ１５４が示す時刻から、送信継続判定時間以上が経過していない場合（Ｓ２２：Ｎｏ）、つまり、送信継続判定時間内にセッション情報が更新されている場合は、データ送信部１６は、上述の要領で、取得したセッション情報に基づいてデータ送信を行う（Ｓ２３）。そして、送信すべき全データの送信が完了するまで上記処理を繰り返し、送信が完了すれば、データ送信部１６は消滅する（Ｓ２４）。

つぎに、図５および図６のシーケンスチャートを用いて、本実施形態に係るデータ転送システムでのデータ転送の様子を示す。

まず、クライアント２がサーバ１に対して、データ転送のリクエストＲを送信することにより本システムでの処理が開始される。

サーバ１は、このリクエストを受けて、セッションＩＤをクライアント２へ通知する。この時点でサーバ１とクライアント２間にセッションが確立する。

次に、クライアント２からハートビートパケットＨ１が送信される。サーバ１では、このハートビートパケットＨ１を受信すると、上述の処理を行った後、データ送信部１６がデータ転送を開始する。転送されるデータは、複数のパケットに分割し、順次送信される（Ｄ１〜）。

クライアント２では、送信されてくるデータパケットを順次受信すると共に、ハートビート送信条件に基づいてサーバ１へハートビートパケットＨ２を送信する。

ここで、ハートビートパケットＨ２を送信した後、データパケットＤ５まで受信したところで、クライアント２のＩＰアドレスが変更になった場合を考える。ＩＰアドレスが変更になると、変更前のＩＰアドレスに対して送信されてきたデータを受信することはできない。従って、クライアント２は、データパケットＤ６以降が受信できないことになり、いわゆるパケットロスが生じる。

クライアント２がこの状態にあるとき、再びハートビート送信条件が満たされると、ハートビートパケットＨ３が生成されて、サーバ１へ送信される。このハートビートパケットＨ３に含まれているＩＰアドレスは、変更後のＩＰアドレスである。

ハートビートパケットＨ３がサーバ１に到達すると、セッション情報記憶部１５のＩＰアドレス１５６が更新される。従って、この更新後にサーバ１から送り出されるデータパケット（この場合Ｄ１１以降）は、変更後のＩＰアドレスへ宛てて送信されることになり、クライアント２はこれらのデータパケットの受信が可能となる。

本実施形態によれば、通信途中でクライアントのＩＰアドレスが変更になったとき、一定のパケットロスは生じるものの、速やかにそれに対応して、データ転送を継続することができるようになる。

つぎに、図６について説明する。同図の場合、何らかの理由でハートビートパケットの出力間隔（Ｈ１とＨ２との出力間隔）が長くなったとき、サーバ１では、ハートビートパケットＨ１受信後に、送信継続判定時間が経過してもハートビートパケットＨ２を受信してないことになる。こうなると、サーバ１では、すでに述べたように、このセッションのデータ送信を担当するデータ送信部１６が消滅し、データ送信が行われない状態（中断）になっている。

しかし、このような場合でも、クライアント２からハートビートパケットＨ２が送られ、ハートビートが再開すれば、再びデータ送信部１６が生成され、それに応じてデータ転送も再開する。

なお、ハートビートパケットがクライアントから出力されなかった場合の他、クライアント２から出力されたハートビートパケットが、何らかの理由でサーバ１へ到達しなかった場合も、上記と同様である。

次に、本発明の第２の実施形態に係るデータ転送システムの構成を図７に示す。本実施形態では、クライアント４からサーバ３へデータをアップロードする。従って、本実施形態では、クライアント４が送信装置であり、サーバ３が受信装置である。サーバ３およびクライアント４が備える構成については、第１の実施形態と相違する点を中心に説明する。従って、第１の実施形態と同様の機能ないし構成については、同一の符号を付して説明を省略する場合がある。

また、サーバ３およびクライアント４は、第１の実施形態と同様に、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明する個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。

クライアント４は、図７に示すように、通信制御部２１と、リクエストＩＤ生成部２２と、セッション要求部２３と、データ送信部４１と、アプリケーション（ＡＰ）２６とを備える。

サーバ３は、図７に示すように、通信制御部１１と、セッション受付部１２と、セッションＩＤ生成部１３と、セッション情報記憶部１５と、データ記憶部１７と、データ受信部３１とを備える。

ＡＰ２６は、データをサーバ１へ送信するために、リクエストＩＤ生成部２２へ、データ送信要求をする。リクエストＩＤ生成部２２とセッション要求部２３が行う処理は、データのダウンロードとアップロードとが相違する以外、セッションを確立するまでの処理は第１の実施形態と同じである。ただし、リクエスト要求メッセージに含まれるデータの属性は、アップロードするファイルのサイズである。

また、セッションを確立するまでにサーバ３が行う処理についても、データのダウンロードとアップロードとが相違する以外、第１の実施形態と同じである。従って、セッション受付部１２およびセッションＩＤ生成部１３は、第１の実施形態と同様の処理を行う。セッション情報記憶部１５にも、第１の実施形態と同様のセッション情報が格納される。

セッションが確立した後、ＡＰ２６からアップロード対象のファイルを取得すると、データ送信部４１はそのファイルをサーバ１へ送信する。ここでも、アップロード対象ファイルが１パケットのデータサイズを超えるときは、分割して送信する。このとき、それぞれの分割されたデータに、セッション要求部２３から通知されたセッションＩＤを付加して送信する。

通信制御部２１が生成してサーバ３に対して送り出されるデータパケットには、ＩＰヘッダの発信元ＩＰアドレスにクライアント４のＩＰアドレスが含まれ、ＵＤＰヘッダに発信元ポート番号にリクエストを示すポート番号が含まれる。さらに、このデータパケットのデータフィールドには、アップロードされるデータとセッションＩＤとが含まれている。

サーバ３では、通信制御部１１がこのデータパケットを受信すると、データフィールドの内容をデータ受信部３１へ渡すと共に、クライアント４のＩＰアドレスおよびポート番号を通知する。

データ受信部３１は、ここで取得した情報に基づいて、セッション情報記憶部１５を更新する。例えば、受信したハートビートパケットに含まれているセッションＩＤをキーにして、これと対応付けて記憶されているクライアント４のＩＰアドレス１５６およびポート番号１５７を上書き更新する。このとき、セッション情報記憶部１５に格納されているＩＰアドレス１５６およびポート番号１５７と、受信したデータパケットに含まれていたＩＰアドレスおよびポート番号とが異なる場合のみ、上書き更新してもよい。いずれの場合でも、セッション情報が更新されたときは、タイムスタンプ１５４もその時の時刻に更新する。

また、データ受信部３１は、アップロードファイルのサイズが格納されているセッション情報記憶部１５のデータ属性１５３を参照し、受信済みデータのデータ量と比較して、ファイルの全データの受信が完了したか確認する。全データの受信が完了すると、データ受信部３１は、データ記憶部３２に格納する。

次に、本実施形態におけるデータ転送は、図８に示すようなシーケンスチャートとなる。つまり、第１の実施形態と同様にリクエストＲ１に対するセッションＩＤの通知により、セッションが確立する。セッション確立後は、クライアント４から順次データパケットがサーバ３へ送信される。

このとき、途中でＩＰアドレスが変更された場合には、データパケットのＩＰヘッダ内の発信元ＩＰアドレスが自動的に切り替わり、サーバ３には常にクライアント４のその時点のＩＰアドレスが通知されることになる。

上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

本発明の第１の実施形態に係るデータ転送システムの構成図である。 セッション情報記憶部１５のデータ構造の一例を示す図である。 ハートビート受信部１４の処理手順を示すフローチャートである。 データ送信部１６の処理手順を示すフローチャートである。 第１の実施形態のシーケンスチャートである。 第１の実施形態のシーケンスチャートである。 本発明の第２の実施形態に係るデータ転送システムの構成図である。 第２の実施形態のシーケンスチャートである。

符号の説明

１、３…サーバ、２、４…クライアント、９…ネットワーク、１１、２１…通信制御部、１２…セッション受付部、１３…セッションＩＤ生成部、１４…ハートビート受信部、１５…セッション情報記憶部、１６…データ送信部、１７…データ記憶部、２２…リクエストＩＤ生成部、２３…セッション要求部、２４…ハートビート送信部、２５…データ受信部。

Claims (16)

1. 第１の通信装置と第２の通信装置との間で通信を行うためのセッションを確立し、
   第１の通信装置は、前記セッションを識別するためのセッション識別情報と第１の通信装置の通信アドレスとを第２の通信装置へ送信し、
   第２の通信装置は、前記第１の通信装置から送信された前記セッション識別情報と前記通信アドレスとを受信し、
   すでに受信済みの前記セッション識別情報と前記通信アドレスとが対応付けて記憶されている記憶部を、前記受信した前記セッション識別情報および通信アドレスに基づいて更新し、
   第２の通信装置が前記セッションでデータを送信するときは、前記記憶部から前記セッションに対応する通信アドレスを取得し、前記取得した通信アドレスに対して前記データを送信するデータ転送方法。
2. 第１の通信装置と第２の通信装置とを備えた通信システムであって、
   第１の通信装置は、
   第２の通信装置とセッションを確立し、第２の通信装置へデータ送信をリクエストする手段と、
   前記リクエストに対して第２の通信装置から送信されたデータを受信する手段と、
   前記確立されたセッションを識別するセッション識別情報と自装置の通信アドレスとを、第２の通信装置へ繰り返し送信する手段と、を備え、
   第２の通信装置は、
   第１の通信装置との間で確立されたセッションを識別するためのセッション識別情報と、第１の通信装置の通信アドレスとを対応付けて記憶するための記憶部と、
   第１の通信装置から送信された前記セッション識別情報および前記通信アドレスを受信する手段と、
   前記受信手段が受信した前記セッション識別情報および前記通信アドレスに基づいて、前記記憶部を更新する手段と、
   前記セッションで第１の通信装置へデータを送信するとき、前記記憶部から当該セッションのセッション識別情報と対応付けられている通信アドレスを取得し、取得した通信アドレス宛に前記データを送信するための送信データを生成して、送信する手段と、を備える通信システム。
3. 他の通信装置との間で確立されたセッションを識別するためのセッション識別情報と、前記他の通信装置の通信アドレスとを対応付けて記憶するための記憶部と、
   前記他の通信装置から前記セッション識別情報および前記通信アドレスを受信する手段と、
   前記受信手段が受信した前記セッション識別情報および前記通信アドレスに基づいて、前記記憶部を更新する手段と、
   前記セッションで前記他の通信装置へデータを送信するとき、前記記憶部から当該セッションのセッション識別情報と対応付けられている通信アドレスを取得し、取得した通信アドレス宛に前記データを送信するための送信データを生成し、出力する手段と、を備える通信装置。
4. 前記記憶部に、前記受信手段が受信したセッション識別情報と同一のセッション識別情報に対応付けて記憶されている通信アドレスが、前記受信手段が受信した通信アドレスと同一でないとき、前記更新手段は、前記記憶部の通信アドレスを上書きして更新する請求項３記載の通信装置。
5. 前記通信アドレスは、前記他の通信装置のＩＰアドレスと前記他の通信装置におけるポート番号である請求項３記載の通信装置。
6. 前記送信データを出力する手段は、前記データを複数に分割し、分割されたデータに基づいてそれぞれ送信データを生成して出力するものであり、
   前記受信手段が、最後に前記セッション識別情報および通信アドレスを受信した時刻から所定時間以上経過すると、
   前記送信データを出力する手段は、それ以降、前記送信データの出力を行わない請求項３記載の通信装置。
7. 前記送信データを出力する手段が前記送信データの出力を停止した後、前記受信手段が前記セッション識別情報および通信アドレスを受信すると、
   前記送信データを出力する手段は、前記送信データの出力を再開する請求項６記載の通信装置。
8. 他の通信装置とセッションを確立し、前記他の通信装置へデータ送信をリクエストする手段と、
   前記リクエストに対して他の通信装置から送信されたデータを受信する手段と、
   前記確立されたセッションを識別するセッション識別情報と自装置の通信アドレスとを、前記他の通信装置へ繰り返し送信する手段と、を備える通信装置。
9. 前記受信手段は、送信をリクエストしたデータが複数に分割されて送信されてくるとき、これらを順次受信し、
   リクエストした全データを前記受信手段が受信するまでの間、前記送信手段は前記セッション識別情報および前記自装置の通信アドレスを繰り返し送信する請求項８記載の通信装置。
10. 前記送信手段は、前記セッション識別情報および前記自装置の通信アドレスを、所定の時間間隔で繰り返し送信するか、または、前記受信手段が所定数の分割されたデータを受信するごとに送信する請求項９記載の通信装置。
11. 他の通信装置からのセッション確立要求に基づいてセッションを確立し、
    前記他の通信装置から送信された前記セッション識別情報と前記通信アドレスとを受信し、
    すでに受信済みの前記セッション識別情報と前記通信アドレスとが対応付けて記憶されている記憶部を、前記受信した前記セッション識別情報および通信アドレスに基づいて更新し、
    前記セッションでデータを送信するときは、前記記憶部から前記セッションに対応する通信アドレスを取得し、前記取得した通信アドレスに対して前記データを送信するデータ送信方法。
12. コンピュータに実行されると、
    他の通信装置からのセッション確立要求に基づいてセッションを確立し、
    前記他の通信装置から送信された前記セッション識別情報と前記通信アドレスとを受信し、
    すでに受信済みの前記セッション識別情報と前記通信アドレスとが対応付けて記憶されている記憶部を、前記受信した前記セッション識別情報および通信アドレスに基づいて更新し、
    前記セッションでデータを送信するときは、前記記憶部から前記セッションに対応する通信アドレスを取得し、前記取得した通信アドレスに対して前記データを送信するデータ送信のためのコンピュータプログラム。
13. 他の通信装置に対してセッションの確立を要求し、
    前記他の通信装置へデータ送信をリクエストし、
    前記セッションが確立されると、そのセッションを識別するセッション識別情報と自装置の通信アドレスとを、前記他の通信装置へ繰り返し送信し、
    前記リクエストに対して前記他の通信装置から送信されて来る複数の送信データを、順次受信し、
    リクエストした全データの受信が完了すると、前記セッション識別情報および前記通信アドレスの送信を停止するデータ受信方法。
14. コンピュータに実行されると、
    他の通信装置に対してセッションの確立を要求し、
    前記他の通信装置へデータ送信をリクエストし、
    前記セッションが確立されると、そのセッションを識別するセッション識別情報を、前記他の通信装置へ繰り返し送信し、
    前記リクエストに対して前記他の通信装置から送信されて来る複数の送信データを、順次受信し、
    リクエストした全データの受信が完了すると、前記セッション識別情報および前記通信アドレスの送信を停止するデータ受信のためのコンピュータプログラム。
15. 第１の通信装置と第２の通信装置との間で通信を行うためのセッションを確立し、
    第１の通信装置は、前記セッションを識別するためのセッション識別情報と第１の通信装置の通信アドレスと送信データとを第２の通信装置へ送信し、
    第２の通信装置は、前記第１の通信装置から送信された前記セッション識別情報と前記通信アドレスと前記送信データとを受信し、
    すでに受信済みの前記セッション識別情報と前記通信アドレスとが対応付けて記憶されている記憶部に、前記受信した前記セッション識別情報および通信アドレスを上書きして格納するデータ送信方法。
16. 第１の通信装置と第２の通信装置とを備えた通信システムであって、
    第１の通信装置は、
    第２の通信装置とセッションを確立する手段と、
    前記確立されたセッションを識別するセッション識別情報と自装置の通信アドレスと送信データとを、第２の通信装置へ繰り返し送信する手段と、を備え、
    第２の通信装置は、
    第１の通信装置との間で確立されたセッションを識別するためのセッション識別情報と、第１の通信装置の通信アドレスとを対応付けて記憶するための記憶部と、
    第１の通信装置から送信された前記セッション識別情報、前記通信アドレスおよび送信データを受信する手段と、
    前記受信手段が受信した情報に基づいて、前記記憶部を更新する手段と、を備える通信システム。