(57)【要約】【課題】利便性の高い通信制御技術を提供する。【解決手段】ゲーム装置１８の候補取得部４１は、通信相手のゲーム装置がネットワークを介して自装置へデータを送信する際に、送信先として設定されるべき自装置の識別子の候補を複数取得する。候補通知部が、取得した候補を通信相手のゲーム装置へ通知する。応答受信部４３は、通信相手のゲーム装置から送信された応答データを受信する。識別子決定部４４は、受信した応答データに送信先として設定された候補の中から、以降の通信で送信先として設定されるべき識別子を決定する。識別子通知部４５は、決定された識別子を通信相手のゲーム装置へ通知する。【選択図】図２
2008118599.tif 000002
【特許請求の範囲】
【請求項１】
通信相手の装置がネットワークを介して自装置へデータを送信する際に送信先として設定されるべき自装置の識別子の候補を複数取得する候補取得部と、
取得した複数の前記候補を前記通信相手の装置へ通知して応答データの送信を要求する候補通知部と、
前記通信相手の装置に通知した複数の前記候補が送信先に設定された前記応答データを、前記ネットワークを介して受信する応答受信部と、
受信した前記応答データに送信先として設定された前記候補の中から、前記送信先として設定されるべき自装置の識別子を決定する識別子決定部と、
決定した自装置の識別子を前記通信相手の装置へ通知する識別子通知部と、
前記識別子決定部により決定された自装置の識別子に対して、複数の仮想ソケットを割り当て、同一の前記識別子を用いた複数の通信を管理する仮想ソケット管理部と、
を備えることを特徴とする通信装置。
【請求項２】
前記候補が、自装置のプライベートＩＰアドレスを含む場合、前記識別子決定部は、前記自装置のプライベートＩＰアドレスを優先的に前記送信先として設定されるべき自装置の識別子に決定することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記候補通知部は、端末間の通信を管理する管理サーバを介して、前記候補を前記通信相手の装置へ通知することを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
通信相手の装置がネットワークを介して自装置へデータを送信する際に送信先として設定されるべき自装置の識別子の候補を複数取得するステップと、
取得した複数の前記候補を前記通信相手の装置へ通知して応答データの送信を要求するステップと、
前記通信相手の装置に通知した複数の前記候補が送信先に設定された前記応答データを、前記ネットワークを介して受信するステップと、
受信した前記応答データに送信先として設定された前記候補の中から、前記送信先として設定されるべき自装置の識別子を決定するステップと、
決定した自装置の識別子を前記通信相手の装置へ通知するステップと、
決定した自装置の識別子に対して、複数の仮想ソケットを割り当て、同一の前記識別子を用いた複数の通信を管理するステップと、
を含むことを特徴とする通信制御方法。
【請求項５】
通信相手の装置がネットワークを介して自装置へデータを送信する際に送信先として設定されるべき自装置の識別子の候補を複数取得する機能と、
取得した複数の前記候補を前記通信相手の装置へ通知して応答データの送信を要求する機能と、
前記通信相手の装置に通知した複数の前記候補が送信先に設定された前記応答データを、前記ネットワークを介して受信する機能と、
受信した前記応答データに送信先として設定された前記候補の中から、前記送信先として設定されるべき自装置の識別子を決定する機能と、
決定した自装置の識別子を前記通信相手の装置へ通知する機能と、
決定した自装置の識別子に対して、複数の仮想ソケットを割り当て、同一の前記識別子を用いた複数の通信を管理する機能と、
をコンピュータに実現させることを特徴とする通信制御プログラム。
【請求項６】
通信相手の装置がネットワークを介して自装置へデータを送信する際に送信先として設定されるべき自装置の識別子の候補を複数取得する機能と、
取得した複数の前記候補を前記通信相手の装置へ通知して応答データの送信を要求する機能と、
前記通信相手の装置に通知した複数の前記候補が送信先に設定された前記応答データを、前記ネットワークを介して受信する機能と、
受信した前記応答データに送信先として設定された前記候補の中から、前記送信先として設定されるべき自装置の識別子を決定する機能と、
決定した自装置の識別子を前記通信相手の装置へ通知する機能と、
決定した自装置の識別子に対して、複数の仮想ソケットを割り当て、同一の前記識別子を用いた複数の通信を管理する機能と、
をコンピュータに実現させることを特徴とする通信制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信制御技術に関し、とくに、ネットワークを介した端末間通信を制御する通信装置、通信制御方法、及び通信制御プログラムに関する。
【背景技術】
【０００２】
インターネットなどのネットワークのインフラの整備が進んでおり、ネットワークを介してゲーム端末間で対戦ゲームやチャットなどを楽しむことができるようになっている。ゲーム端末間における通信方式として、一般に、サーバを介さずに端末間で直接通信を行うピア・ツー・ピア（Peer to Peer：Ｐ２Ｐ）が用いられている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ゲーム装置は、ルータを介してインターネットに接続されることが多いが、ルータによって、ポートの使用ポリシーやパケットのフィルタリングポリシーが多種多様であるため、自装置が接続されているルータと通信相手の装置が接続されているルータとの組合せによっては、継続的にＰ２Ｐ通信を行うことが困難な場合がある。
【０００４】
本発明はこうした状況に鑑みてなされたものであり、その目的は、より利便性の高い通信制御技術を提供することにある。
【課題を解決するための手段】
【０００５】
本発明のある態様は、通信装置に関する。この通信装置は、通信相手の装置がネットワークを介して自装置へデータを送信する際に送信先として設定されるべき自装置の識別子の候補を複数取得する候補取得部と、取得した複数の前記候補を前記通信相手の装置へ通知して応答データの送信を要求する候補通知部と、前記通信相手の装置に通知した複数の前記候補が送信先に設定された前記応答データを、前記ネットワークを介して受信する応答受信部と、受信した前記応答データに送信先として設定された前記候補の中から、前記送信先として設定されるべき自装置の識別子を決定する識別子決定部と、決定した自装置の識別子を前記通信相手の装置へ通知する識別子通知部と、前記識別子決定部により決定された自装置の識別子に対して、複数の仮想ソケットを割り当て、同一の前記識別子を用いた複数の通信を管理する仮想ソケット管理部と、を備えることを特徴とする。
【０００６】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００７】
本発明によれば、より利便性の高い通信制御技術を提供することができる。
【発明を実施するための最良の形態】
【０００８】
図１は、実施の形態に係る通信システムの基本的な構成を示す。通信システム１０は、通信管理サーバ１２、ＳＴＵＮサーバ１４、ルータ１６、通信装置の一例であるゲーム装置１８、ネットワークの一例であるインターネット２０を含む。ルータ１６ａ、１６ｂ、・・・、を総称してルータ１６と呼ぶ。また、ゲーム装置１８ａ、１８ｂ、１８ｃ、・・・、を総称してゲーム装置１８と呼ぶ。
【０００９】
通信管理サーバ１２は、ゲーム装置間の通信を管理する。通信管理サーバ１２は、ゲーム装置１８から対戦ゲームやチャットなどの通信相手のマッチングや検索の要求を受け付け、通信相手を決定する。そして、端末間においてＰ２Ｐの通信路が確立されるまでの間、端末間の通信を仲介する。
【００１０】
ＳＴＵＮサーバは、ＳＴＵＮ（Simple Traversal of UDP through NATs）を実現するために設けられるサーバであり、ゲーム装置１８からの要求を受けて、ゲーム装置１８が接続されているルータ１６のＷＡＮ側のＩＰアドレスと、ゲーム装置１８の通信のために割り当てられているポート番号をゲーム装置１８に回答する。
【００１１】
ルータ１６は、下流に接続された複数のゲーム装置１８と、上流のネットワークとの間の通信を制御する。ルータ１６は、下流に接続された複数のゲーム装置１８に対して、互いに異なるプライベートＩＰアドレスを付与するＤＨＣＰ（Dynamic Host Configuration Protocol）サーバの機能や、ゲーム装置１８に割り当てられたプライベートＩＰアドレスと自装置に割り当てられたグローバルＩＰアドレスとを相互に変換し、プライベートＩＰアドレスしか割り当てられていないゲーム装置１８から透過的にインターネット２０を介した通信を行うことを可能とするＮＡＴ（Network Address Translation）機能や、ゲーム装置１８からインターネット２０へ送信されるパケットやインターネット２０からゲーム装置１８へ送信されるパケットの通過の許否を制御するパケットフィルタリング機能を実現する。
【００１２】
ゲーム装置１８は、ルータ１６を介してインターネット２０に接続し、インターネット２０を介したデータの送受信を行うことにより、他のゲーム装置１８との間で対戦ゲームやチャットなどを行う。
【００１３】
ゲーム装置１８が接続されているルータ１６におけるＮＡＴの特性は下記の３種に分類される。
（１）ゲーム装置１８のネットワークインタフェースに割り当てられたＩＰアドレスが、ルータ１６のインターネット２０側のグローバルＩＰアドレスと同一である場合。
（２）ゲーム装置１８のネットワークインタフェースに割り当てられたＩＰアドレスが、ルータ１６のインターネット２０側のグローバルＩＰアドレスと異なり、かつ、以下のいずれかの条件に合致する場合。
（ａ）ルータ１６のマッピングポリシーが通信相手のＩＰアドレス及びポート番号に依存せず、かつ、フィルタリングポリシーが通信相手のＩＰアドレス及びポート番号に依存しない。
（ｂ）ルータ１６のマッピングポリシーが通信相手のＩＰアドレス及びポート番号に依存せず、かつ、フィルタリングポリシーが通信相手のＩＰアドレスのみに依存する。
（ｃ）ルータ１６のマッピングポリシーが通信相手のＩＰアドレスのみに依存し、かつ、フィルタリングポリシーが通信相手のＩＰアドレス及びポート番号に依存しない。
（ｄ）ルータ１６のマッピングポリシーが通信相手のＩＰアドレス及びポート番号に依存し、かつ、フィルタリングポリシーが通信相手のＩＰアドレス及びポート番号に依存しない。
（３）上記（１）（２）以外の全ての場合。
【００１４】
このとき、Ｐ２Ｐ通信を行おうとしている２つのゲーム装置１８のそれぞれが接続しているルータ１６が、両方とも（３）のタイプである場合は、継続的にＰ２Ｐ通信を行うことが困難である。したがって、ゲーム装置１８は、予め自装置が接続しているルータ１６と、通信相手のゲーム装置１８が接続しているルータ１６のタイプを取得し、両方とも（３）のタイプであれば、Ｐ２Ｐ通信が行えない旨を報知してもよい。しかし、本実施の形態では、このような場合であっても、端末間のＰ２Ｐ通信を行うことができる可能性を高めるために、Ｐ２Ｐ通信に先立ってゲーム装置１８同士で自身のネットワーク上での識別子として使用可能な候補を複数通知し合い、試験的にパケットを送受信して通信が可能な候補を模索する技術を提案する。これにより、より確実にゲーム装置１８間におけるＰ２Ｐの通信路を確立することができ、端末間通信の利便性を向上させることができる。
【００１５】
図２は、通信装置の一例であるゲーム装置１８の構成を示す。ゲーム装置１８は、ネットワークインタフェース３０、通信制御部４０、ゲーム実行部６０、入力部６２、画像処理部６６、及び表示装置６８を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００１６】
入力部６２は、ゲームコントローラから入力されるユーザによる操作指示を受け付ける。ゲーム実行部６０は、入力部６２が受け付けたユーザからの操作指示に基づいてゲームプログラムを実行し、ゲームを進行させる。画像処理部６６は、ゲーム実行部６０により実行されるゲームの表示画面を生成して、表示装置６８に表示させる。
【００１７】
通信制御部４０は、候補取得部４１、候補通知部４２、応答受信部４３、識別子決定部４４、識別子通知部４５、候補受信部４６、応答送信部４７、識別子受信部４８、仮想ソケット管理部４９、パケット送信部５０、及びパケット受信部５１を含む。
【００１８】
候補取得部４１は、通信相手のゲーム装置１８が、ネットワークを介して自装置へデータを送信する際に、送信先として設定されるべき自装置の識別子の候補を複数取得する。本実施の形態では、識別子の例として、ＩＰアドレスとポート番号を組み合わせたソケットを使用する。
【００１９】
候補取得部４１は、まず、自装置のネットワークインタフェース３０に割り当てられているＩＰアドレスとポート番号を取得して、候補「local」にセットする。つづいて、候補取得部４１は、自装置が接続されているルータ１６がＵＰｎＰ（Universal Plug and Play）に対応していれば、ＵＰｎＰの「AddPortMapping」を試行し、ゲーム装置１８が他の装置と通信するときのポート番号として予め固定的に決められたポート番号を追加するようルータ１６へ依頼する。さらに、候補取得部４１は、ＳＴＵＮサーバ１４にアクセスし、自装置が接続しているルータ１６のインターネット２０側のＩＰアドレスとポート番号を取得する。取得したＩＰアドレスとポート番号が候補「local」と異なる場合、候補取得部４１は、取得したＩＰアドレスとポート番号を候補「stun」にセットする。また、候補取得部４１は、ルータ１６に追加を依頼したポート番号が外部からアクセス可能か否かをＳＴＵＮサーバ１４に問い合わせる。このポート番号が外部からアクセス可能であり、かつ、候補「stun」と異なる場合、候補取得部４１は、ルータ１６のインターネット２０側のＩＰアドレスと、ＵＰｎＰにより追加したポート番号を候補「static」にセットする。
【００２０】
候補通知部４２は、候補取得部４１が取得した複数の候補を通信相手のゲーム装置１８へ通知して、応答データの送信を要求する。候補通知部４２は、通信管理サーバ１２を介して通信相手のゲーム装置１８へ候補を通知してもよい。また、通信管理サーバ１２へ候補を通知し、通信管理サーバ１２から通信相手のゲーム装置１８へ候補を通知するよう依頼してもよい。これにより、候補通知部４２が通信相手のゲーム装置１８のＩＰアドレスやポート番号などを取得していなくても、自装置のＩＰアドレスやポート番号の候補を通信相手のゲーム装置１８へ通知することができる。
【００２１】
候補受信部４６は、通信相手のゲーム装置１８から、そのゲーム装置１８へデータを送信する際に、送信先として設定すべき識別子の候補を受信してテーブルに保持する。通信相手のゲーム装置１８との間で、互いに識別子の候補を送受信すると、それぞれのゲーム装置１８の接続状態は「PENDING」となる。つづいて、通信相手のゲーム装置１８との間で接続確認を行い、通信を確立する処理を行う。
【００２２】
応答受信部４３は、通信相手のゲーム装置１８に通知した複数の候補が送信先に設定された応答データを、ネットワークを介して受信する。応答受信部４３は、タイマなどを利用して、候補通知部４２が通信相手のゲーム装置１８へ候補を通知してから、応答データを受信するまでに要した時間を計測してもよい。これにより、通信を行うアプリケーションは、計測された時間をもとに、通信相手のゲーム装置１８との通信に要する時間を推測することができる。
【００２３】
応答送信部４７は、通信相手のゲーム装置１８から受信した識別子の候補を送信先に設定した応答データを、ネットワークを介して送信する。ここで、応答送信部４７は、応答受信部４３が通信相手のゲーム装置１８から受信した応答データの送信元の識別子として、候補受信部４６が受信した識別子の候補とは異なる識別子が設定されていた場合、識別子を候補「derived」にセットし、追加した候補「derived」を送信先に設定した応答データも送信する。
【００２４】
識別子決定部４４は、応答受信部４３が受信した応答データに送信先として設定された候補の中から、送信先として設定されるべき自装置の識別子を決定する。識別子決定部４４は、候補「local」にセットしたＩＰアドレスとポート番号が送信先として設定された応答データを受信すると、そのＩＰアドレスとポート番号を優先的に送信先として設定されるべき識別子に決定する。
【００２５】
図１において、ゲーム装置１８ａとゲーム装置１８ｃとの間でＰ２Ｐ通信を行う場合は、インターネット２０を介して通信する必要があるので、ゲーム装置１８ｃがゲーム装置１８ａに応答データを送信する際に、ゲーム装置１８ａのプライベートＩＰアドレスを送信先として設定しても、ゲーム装置１８ａには到達しない。この場合は、ゲーム装置１８ａが接続されているルータ１６ａのインターネット２０側のグローバルＩＰアドレスを送信先として設定する必要がある。したがって、候補「stun」か候補「static」でないとゲーム装置１８ａへ応答データが到達しない。
【００２６】
しかしながら、ゲーム装置１８ａとゲーム装置１８ｂとの間でＰ２Ｐ通信を行う場合は、ゲーム装置１８ａとゲーム装置１８ｂは同一のルータ１６ａに接続されており、インターネット２０を介さずに通信を行うことができるので、ゲーム装置１８ａのプライベートＩＰアドレスが送信先として設定された応答データもゲーム装置１８ａへ到達する。この場合、ルータ１６ａのインターネット２０側のグローバルＩＰアドレスがセットされた候補「stun」や候補「static」が送信先として設定された応答データもゲーム装置１８ａへ到達する可能性があるが、これらはいったんルータ１６ａからインターネット２０へ送出され、再度ルータ１６ａを介してゲーム装置１８ａへ到達するので、無駄に通信経路が長くなり、通信時間が長くなってしまう虞がある。したがって、Ｐ２Ｐ通信する２つのゲーム装置１８が同じＬＡＮ内に存在する場合、すなわち、候補「local」が送信先として設定された応答データが応答受信部により受信された場合は、それを優先的に採用する。これにより、通信に要する時間を短縮することができる。
【００２７】
ルータ１６ｂには、ゲーム装置１８ｃのみが接続されているが、この場合、ゲーム装置１８ｃのネットワークインタフェース３０に、ルータ１６ｂのインターネット２０側のグローバルＩＰアドレスが割り当てられることがある。このとき、ルータ１６ｂのＤＨＣＰサーバ機能とＮＡＴ機能は停止されている。この場合、候補「local」には、プライベートＩＰアドレスではなく、グローバルＩＰアドレスがセットされている。この場合であっても、候補「local」が送信先として設定された応答データが応答受信部４３により受信された場合、それを優先的に採用してもよい。
【００２８】
応答受信部４３が所定時間待機しても候補「local」が送信先として設定された応答データを受信しなかった場合、他の候補が送信先として設定された応答データを受信していたときは、それを採用する。他の複数の候補の応答データを受信していたときは、最初に応答データを受信した候補を優先的に採用してもよい。また、複数回試行して、平均通信時間が最小であった候補を優先的に採用してもよい。また、複数回試行して、通信エラーの発生回数が最小であった候補を優先的に採用してもよい。
【００２９】
識別子通知部４５は、識別子決定部４４が決定した自装置の識別子を通信相手のゲーム装置１８へ通知する。識別子通知部４５は、通信管理サーバ１２を介して、決定した識別子を通信相手のゲーム装置１８へ通知してもよい。
【００３０】
識別子受信部４８は、通信相手のゲーム装置１８から、送信先として設定すべきと決定された識別子を受信する。識別子受信部４８は、受信した識別子をテーブルに登録する。以降、パケット送信部５０が通信相手のゲーム装置１８へパケットを送信する際に、この識別子が送信先に設定される。通信相手のゲーム装置１８との間で、互いに識別子を送受信すると、それぞれのゲーム装置１８の接続状態は「ACTIVE」となり、通信路が確立され、以降、Ｐ２Ｐ通信が可能となる。
【００３１】
図３は、本実施の形態に係る通信制御方法の手順を示すフローチャートである。まず、ゲーム装置１８ａの候補取得部４１が、通信相手のゲーム装置１８ｂがネットワークを介して自装置へデータを送信する際に、送信先として設定されるべき自装置の識別子の候補を複数取得する（Ｓ１０）。つづいて、候補通知部４２が、取得した候補を通信相手のゲーム装置１８ｂへ通知する（Ｓ１２）。ゲーム装置１８ｂの候補受信部４６は、候補を受信するとテーブルに登録する（Ｓ１４）。そして、応答送信部４７が、受信した候補を送信先に設定した応答データを送信する（Ｓ１６）。ゲーム装置１８ａの応答受信部４３は、ゲーム装置１８ｂから送信された応答データを受信する（Ｓ１８）。応答受信部４３が、候補「local」が送信先として設定された応答データを受信すると（Ｓ２０のＹ）、識別子決定部４４は、候補「local」を送信先として設定されるべき識別子に決定する（Ｓ２２）。応答受信部４３が、候補「local」が送信先として設定された応答データを受信しなかった場合（Ｓ２０のＮ）、識別子決定部４４は、応答データを受信した候補の中から送信先として設定されるべき識別子を決定する（Ｓ２４）。識別子通知部４５は、決定された識別子をゲーム装置１８ｂへ通知する（Ｓ２６）。ゲーム装置１８ｂの識別子受信部４８は、通知された識別子をテーブルに登録し（Ｓ２８）、以降の通信では通知された識別子を送信先に設定する。
【００３２】
仮想ソケット管理部４９は、複数のアプリケーションが同一のポート番号を共有するために、複数のアプリケーションのそれぞれに対して仮想ソケットを割り当て、仮想ソケットに付与された仮想ポート番号を介した通信を管理する。ゲーム装置１８において、複数のアプリケーションが並行して他のゲーム装置１８と通信を行う場合、それぞれのアプリケーションが独自に上述した機能を用いて通信路を確立すると、状況によって異なる識別子が採用されることがあり、あるアプリケーションはＰ２Ｐで通信可能であるのに、別のアプリケーションは通信不可能であるという状態が生じうる。このような事態を避けるために、上述した機能により識別子が決定されると、その識別子を複数のアプリケーションが共有して利用できるようにする。そのために、仮想ソケット管理部４９は、通信を行うアプリケーションに対して互いに異なる仮想ソケットを割り当て、仮想ポート番号を管理テーブルに登録する。
【００３３】
図４は、仮想ソケットを用いた通信について説明するための図である。仮想ソケット管理部４９は、他の装置との間で通信を行うゲーム実行部６０やアプリケーション６４ａ及び６４ｂなど（以下、単に「アプリケーション６４」という）から、新たに他装置との通信を要求されると、そのアプリケーション６４に対して仮想ソケットを割り当てる。仮想ソケット管理部４９は、アプリケーション６４に割り当てた仮想ソケットの仮想ポート番号と、アプリケーション６４を識別するＩＤとを対応づけて管理テーブル５３に登録する。図４の例では、ゲーム実行部６０に対して仮想ポート５２ａが、アプリケーション６４ａに対して仮想ポート５２ｂが、アプリケーション６４ｂに対して仮想ポート５２ｃがそれぞれ割り当てられている。仮想ソケット管理部４９は、ゲーム装置１８のオペレーションシステムなどに割り当てる仮想ポート番号の範囲を予約しておき、アプリケーション６４に割り当てる仮想ポート番号の範囲を制限してもよい。
【００３４】
仮想ソケット管理部４９は、アプリケーション６４から送信データを受け取ると、仮想ソケットを管理するための仮想ソケットヘッダを送信データに付加して仮想ソケットパケットを生成し、パケット送信部５０へ送る。パケット送信部５０は、仮想ソケット管理部４９が生成した仮想ソケットパケットにＵＤＰヘッダやＩＰヘッダなどを付加して送信パケットを生成し、ルータ１６へ送出する。このとき、パケット送信部５０は、送信先のアドレスに、識別子受信部４８が受信した通信相手のゲーム装置１８の識別子を設定する。ここでは、ＵＤＰによりパケットを送受信する例について説明するが、ＴＣＰやその他の通信プロトコルでも同様である。
【００３５】
図５は、仮想ソケット管理部４９において生成される仮想ソケットパケットのデータ構造を示す。ＵＤＰパケット８０は、ＵＤＰヘッダ８１と、ＵＤＰパケット８０のペイロードに格納された１以上の仮想ソケットパケット８２を含む。仮想ソケットパケット８２は、仮想ソケットヘッダ８３と、可変長のデータ８９を含む。複数の仮想ソケットパケット８２を１つのＵＤＰパケット８０にパッケージしてもよい。
【００３６】
仮想ソケットヘッダ８３は、仮想ソケットヘッダ８３の開始を示す特定のデータ列である開始フラグ８４と、データ８９のデータ種別８５と、データ８９のデータ長８６と、送信元のアプリケーション６４に割り当てられた送信元仮想ポート番号８７と、送信先のアプリケーション６４に割り当てられた宛先仮想ポート番号８８とを含む。初回の送信時などに、宛先のアプリケーション６４の仮想ポート番号が不明である場合は、アプリケーション６４を特定するための情報を宛先仮想ポート番号８８に格納してもよい。データ種別８５には、例えば、通常データ、暗号化データ、署名付きデータ、暗号化署名付きデータなどがある。署名付きデータの場合は、仮想ソケットヘッダ８３に、署名を更に格納してもよい。この場合、署名の有無で仮想ソケットヘッダ８３のデータ長が異なることになるので、データ８９の開始位置を一意に特定可能とするために、データ長８６には、データ長８６以降の仮想ソケットヘッダ８３のデータ長とデータ８９のデータ長を加算した値を格納するようにしてもよい。または、仮想ソケットヘッダ８３に、仮想ソケットヘッダ８３のデータ長を格納する領域を設けてもよい。
【００３７】
パケット受信部５１は、通信相手のゲーム装置１８からパケットを受信すると、ＵＤＰパケット８０のペイロードを解析して、仮想ソケットヘッダ８３の存在を示す開始フラグ８４が格納されているか否かを確認する。仮想ソケットヘッダ８３が存在すれば、宛先仮想ポート番号８８をもとに管理テーブル５３を検索して送信先のアプリケーション６４を特定し、そのアプリケーション６４へ受信データを送る。
【００３８】
図６は、本実施の形態に係る通信制御方法の手順を示すフローチャートである。仮想ソケット管理部４９は、アプリケーション６４から送信データを受け取ると（Ｓ３０）、管理テーブル５３を検索して、アプリケーション６４に割り当てられている仮想ポート番号を取得する（Ｓ３２）。アプリケーション６４に対して仮想ソケットが割り当てられていない場合は（Ｓ３４のＮ）、そのアプリケーション６４に対して新たに仮想ソケットを割り当て、アプリケーション６４のＩＤと仮想ポート番号を管理テーブル５３に登録する（Ｓ３５）。仮想ソケット管理部４９は、仮想ソケットヘッダ８３を設定して仮想ソケットパケット８２を生成する（Ｓ３６）。パケット送信部５０は、生成された仮想ソケットパケット８２にＵＤＰヘッダやＩＰヘッダなどを付加し、他のゲーム装置１８へ送信する（Ｓ３８）。
【００３９】
仮想ソケット管理部４９は、他のゲーム装置１８から受信したＵＤＰパケット８０を受け取ると（Ｓ４０）、受け取ったＵＤＰパケット８０のペイロードの先頭に開始フラグ８４がセットされているか否かを確認する。開始フラグ８４がセットされていれば、仮想ソケットパケット８２が格納されているので、仮想ソケットヘッダ８３を解析して宛先仮想ポート番号８８を取得し（Ｓ４２）、管理テーブル５３を検索して送信先のアプリケーション６４を特定し、そのアプリケーションへ受信データを送る（Ｓ４４）。
【００４０】
このような技術により、いったん通信路が確立された識別子を用いて、複数の通信を並行して行うことが可能となるので、各アプリケーション６４は、より確実に他のゲーム装置１８との間でＰ２Ｐ通信を行うことができる。また、このような通信路の確立と、その通信路を用いた複数の通信の管理を、通信制御部４０が一括して行うので、アプリケーションの開発主体は、このような通信制御に関する問題を考慮することなく、Ｐ２Ｐ通信を利用したアプリケーション６４を開発することができる。これにより、開発の工数を低減することができる。
【００４１】
パケット送信部５０は、所定時間、例えば２０秒ごとに、通信相手のゲーム装置１８へキープアライブパケットを送信する。これにより、通信相手のゲーム装置１８へ、自装置がアライブであることを通知することができるとともに、自装置が接続されたルータ１６のＮＡＴテーブルを更新して通信路を継続的に確保することができる。
【００４２】
以上、本発明を実施例をもとに説明した。この実施例は例示であり、その各構成要素や各処理プロセスの組合せにいろいろな変形が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【図面の簡単な説明】
【００４３】
【図１】実施の形態に係る通信システムの基本的な構成を示す図である。
【図２】実施の形態に係るゲーム装置の構成を示す図である。
【図３】実施の形態に係る通信制御方法の手順を示すフローチャートである。
【図４】仮想ソケットを用いた通信について説明するための図である。
【図５】仮想ソケット管理部において生成される仮想ソケットパケットのデータ構造を示す図である。
【図６】実施の形態に係る通信制御方法の手順を示すフローチャートである。
【符号の説明】
【００４４】
１０  通信システム、１２  通信管理サーバ、１４  ＳＴＵＮサーバ、１６  ルータ、１８  ゲーム装置、２０  インターネット、３０  ネットワークインタフェース、４０  通信制御部、４１  候補取得部、４２  候補通知部、４３  応答受信部、４４  識別子決定部、４５  識別子通知部、４６  候補受信部、４７  応答送信部、４８  識別子受信部、４９  仮想ソケット管理部、５０  パケット送信部、５１  パケット受信部、６０  ゲーム実行部、６２  入力部、６６  画像処理部、６８  表示装置。
【図１】
2008118599.tif 000003
【図２】
2008118599.tif 000004
【図３】
2008118599.tif 000005
【図４】
2008118599.tif 000006
【図５】
2008118599.tif 000007
【図６】
2008118599.tif 000008