JP2005065204A - パーソナルｉｐシステム - Google Patents

Abstract

【課題】 イントラネットやＬＡＮ等のローカルネットワーク内においてローカルＩＰアドレスを使用して運営している環境では、インターネット等から前記ネットワーク上のノードに直接アクセスする手段がなかった。
この解決のためにＮＡＰＴ等の技術があるが、ＩＳＰが対応していない限り利用できないのが一般的である。
また、インターネット等からアクセス可能な前記ローカルネットワーク上のノード各々に対してひとつづつグローバルＩＰアドレスが必要であるなど、貴重な資源であるグローバルＩＰ アドレスを節約する用をなさない課題があった。
【解決手段】 前記課題の解決のために、現在充分に普及しているＩＰマスカレードを利用してグローバルＩＰアドレスを持つノードに仮想回線を構築し、該仮想回線を利用してインターネット等から前記ローカルネットワーク上のノードにアクセスし、このときの通信内容を解析することによって単一のグローバルＩＰアドレスで複数の前記ローカルネットワーク上のノードを識別する手段を提供する。
【選択図】 図１

Description

発明の詳細な説明

本発明は、ネットワーク通信を行うシステムに係わり、異なるプロトコルないしノード識別子空間の識別子が使用されている２以上のネットワーク間における通信を容易に行うことを可能にしたシステムに関する。

インターネットでは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）（非特許文献１）に基づき、ＩＰパケット（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｐａｃｋｅｔ）を送受信することで通信を行う。

ＩＰではノード識別子として、ＩＰアドレス（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ａｄｄｒｅｓｓ）と呼ばれるノード識別子をＩＰパケットを送受信する各々のコンピューターに割り当てる。ＩＰアドレスは、それぞれのコンピューターを識別する識別子としての役割を持つとともに、通信を行う通信路を特定するためにも使用される。

また、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）（非特許文献２）やＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）（非特許文献３）をＩＰとともに使う場合には、ＩＰアドレスとともに、ポート番号（Ｐｏｒｔ Ｎｕｍｂｅｒ）と呼ばれる多重化識別子を用いることで、一つのコンピューターが同時に複数の通信が行えるようになっている。

ＩＰアドレスは、ＩＡＮＡ（Ｉｎｔｅｒｎｅｔ Ａｓｓｉｇｎｅｄ Ｎｕｍｂｅｒｓ Ａｕｔｈｏｒｉｔｙ）を頂点とする複数の組織によって管理されている。ＩＡＮＡは、全ＩＰアドレスの一部を各地域の関連組織に割り当て、該関連組織は、割り当てられたＩＰアドレスの一部を下部組織やＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）に割り当て、と繰り返し、最終的にＩＰアドレスを各コンピューターに割り当てる。

このようにして、ＩＰアドレスは世界中で一意の識別子となるように管理されている。

しかし運営上の便宜のために、各ローカル・ネットワーク内でのみ自由に利用してもよいように、いかなる組織にも割り当てないようにＩＡＮＡが予約してあるＩＰアドレスがあり、ローカルＩＰアドレス（Ｌｏｃａｌ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ａｄｄｒｅｓｓ）、あるいはプライベートＩＰアドレス（Ｐｒｉｖａｔｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｃｏｔｏｌ Ａｄｄｒｅｓｓ）と呼ばれている。

なお、通常のＩＰアドレスは、ローカルＩＰアドレスでないことを特に示す場合にはグローバルＩＰアドレス（Ｇｌｏｂａｌ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ａｄｄｒｅｓｓ）と呼ばれる。

前記ローカルＩＰアドレスは、申請等の手続きを必要とせずに使用できるがわりに、ローカルＩＰアドレスを持ったコンピューターは、インターネットに存在しないかのように扱われるように定められている。（非特許文献４）

これは、ルーター（Ｒｏｕｔｅｒ）やゲートウェイ（Ｇａｔｅｗａｙ）が、ＩＰパケットの送信元ＩＰアドレスないしは送信先ＩＰアドレスがローカルＩＰアドレスであるＩＰパケットを通過させないことによって実現されている。

このことは、ローカル・ネットワーク内のあるコンピューターが重複してグローバルＩＰアドレスを割り当てられているのでない場合、インターネットなどのローカル・ネットワークの外部にあるコンピューターとＩＰパケットの送受信を行うことができないことを示している。

このため、グローバルＩＰアドレスを割り当てられていないコンピューターは、インターネットなどの、ローカル・ネットワークの外部のネットワークのコンピューターと通信を行うことができない。

これを解消するために、ＩＰマスカレード（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｍａｓｑｕｅｒａｄｅ）やＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）、ＮＡＰＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｐｏｒｔ Ｔｒａｎｓｌａｔｉｏｎ）、高機能ゲートウェイ（特許文献１）などの技術が利用されている。

なお、ＩＰマスカレードは元々プログラム名であり、それが一般に定着したものである。このため、ＩＰマスカレードのことを動的ＮＡＰＴと呼んだり、逆にＮＡＰＴを静的ＩＰマスカレードと呼ぶ場合もある。

また、ＮＡＰＴは、ＥＮＡＴ（Ｅｎｈａｎｃｅｄ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）、ＡＮＡＴ（Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）などと呼ばれることがある。

これら用語の混乱を避ける意味でも、以下にＩＰマスカレードとＮＡＰＴという従来の技術を使用した場合の説明を行う。

図２は、グローバルＩＰアドレスを持つコンピューターとローカルＩＰアドレスを持つコンピューターが通信を行う場合を示す図である。

同図において、２０１はインターネット、２０２はローカル・ネットワーク、２２１はインターネット２０１とローカル・ネットワーク２０２をつなぐ、ローカル・ネットワーク２０２のデフォルト・ゲートウェイであるゲートウェイ、２１１はローカル・ネットワーク２０２のローカルＩＰアドレスを割り当てられたコンピューター、２１６はインターネット２０２のグローバルＩＰアドレスを割り当てられたコンピューターである。

図３は、ゲートウェイ２２１にＩＰマスカレードが実施されている場合に、ＩＰマスカレードが使用する変換テーブルである。

図４は、ゲートウェイ２２１にＮＡＰＴが実施されている場合に、ＮＡＰＴが使用する変換テーブルである。

これらの図を用いて、ＩＰマスカレード、ＮＡＰＴの技術によってコンピューター２１１とコンピューター２１６が通信を行う場合を説明する。

ここで、コンピューター２１１にはローカルＩＰアドレス、１０．０．１．２が割り当てられ、コンピューター２１６にはグローバルＩＰアドレス、１９２．０．２．６が割り当てられているものとする。また、ゲートウェイ２２１にはローカルＩＰアドレス、１０．０．０．１とグローバルＩＰアドレス、１９２．０．２．１が割り当てられているものとする。

第一に、ゲートウェイ２２１にＩＰマスカレードが実施されている場合に、コンピューター２１１のポート番号５００１からコンピューター２１６のポート番号８０への通信としてＩＰパケットを送受信する場合について説明する。

このとき、ゲートウェイ２２１は図３の変換テーブルを使用し、この変換テーブルの内容は、最初は空である。

コンピューター２１１は、ＩＰパケットを作成する。

該ＩＰパケットは、送信元ＩＰアドレスが１０．０．１．２、送信元ポート番号が５００１、送信先ＩＰアドレスが１９２．０．２．６、送信先ポート番号が８０となっている。

コンピューター２１１は、デフォルト・ゲートウェイであるゲートウェイ２２１に該ＩＰパケットを送信する。

ゲートウェイ２２１は、受信したＩＰパケットの送信元ＩＰアドレスがローカルＩＰアドレスであるので、変換テーブルから、送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号がそれぞれＬＡ、ＬＰ、ＧＡ、ＧＰである行を検索する。

見つからなかった場合、該ＩＰパケットがＴＣＰパケットを含んでいて且つコネクションの確立要求パケットである場合、あるいは、該ＩＰパケットがＵＤＰパケットを含んでいる場合は、未使用のポート番号を一つ、代理ポート番号として選択し、該ＩＰパケットの送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号と、該代理ポート番号をそれぞれＬＡ，ＬＰ、ＧＡ、ＧＰ、ＰＰとして変換テーブルに追加して、見つかった場合の処理を行う。

ここで、ゲートウェイ２２１は代理ポート番号として９００１を選択したものとし、変換テーブルの内容は図３のようになる。

見つかった場合は、ＰＰの内容を代理ポート番号とし、該ＩＰパケットの送信元ＩＰアドレス、１０．０．１．２をゲートウェイ２２１のグローバルＩＰアドレス、１９２．０．２．１に置き換え、さらに、送信元ポート番号、５００１を見つかった代理ポート番号、９００１に置き換えた後、コンピューター２１６に送信する。

コンピューター２１６は、受信した内容に対して返信する場合、受信したＩＰパケットの送信元ＩＰアドレス１９２．０．２．１と送信元ポート番号９００１から、新しいＩＰパケットを作る。

該ＩＰパケットは、送信元ＩＰアドレスが１９２．０．２．６、送信元ポート番号が８０、送信先ＩＰアドレスが１９２．０．２．１、送信先ポート番号が９００１になっている。

コンピューター２１６は該ＩＰパケットを送信し、ゲートウェイ２２１がこれを受信する。

ゲートウェイ２２１は、受信したＩＰパケットの送信先ＩＰアドレスがゲートウェイ２２１のグローバルＩＰアドレス１９２．０．２．１であるかどうかを調べ、そうである場合には、該ＩＰパケットの送信元ＩＰアドレス、送信元ポート番号、送信先ポート番号がそれぞれＧＡ、ＧＰ、ＰＰである行を変換テーブルから検索する。

一致する行があるので、該ＩＰパケットの送信先ＩＰアドレス、１９２．０．２．６をＬＡである１０．０．１．２に置き換え、また、送信先ポート番号９００１をＬＰである５００１に置き換えた後、コンピューター２１１に送信する。

以降、同様にして、コンピューター２１１とコンピューター２１６はＩＰパケットを送受信することができる。

このように、ＩＰマスカレードでは、事前に登録を行わなくても通信が可能であるが、最初にローカル・ネットワークのコンピューターからインターネットのコンピューターに通信を開始する必要があるため、インターネットのコンピューターからローカル・ネットワークのコンピューターを指定して通信を行うことはできない。

第二に、ゲートウェイ２２１にＮＡＰＴが実施されている場合に、コンピューター２１６のポート番号５００１からコンピューター２１１のポート番号８０へ通信を行うためにＩＰパケットを送受信する場合について説明する。

このとき、ゲートウェイ２２１は図４の変換テーブルを使用し、この変換テーブルの内容は、図に示されたとおりである。

コンピューター２１６は、送信元ＩＰアドレスが１９２．０．２．６、送信元ポート番号が５００１、送信先ＩＰアドレスが１９２．０．２．１、送信先ポート番号が８０となっているＩＰパケットを作成し、デフォルト・ゲートウェイであるゲートウェイ２２１へ送信する。

ゲートウェイ２２１は、変換テーブルから、受信したＩＰパケットの送信先ＩＰアドレスと送信先ポート番号の組がＧＡ、ＧＰの組と一致する行を検索する。

一致する行が見つかったならば、該ＩＰパケットの送信先ＩＰアドレスと送信先ポート番号をそれぞれ、見つかった行のＬＡ、ＬＰに置き換え、コンピューター２１１に送信する。

この場合は、送信先ＩＰアドレス１９２．０．２．１は１０．０．１．２に置き換えられ、送信先ポート番号８０は８０８０に置き換えられる。

逆に、コンピューター２１１からコンピューター２１６にＩＰパケットを送信する場合には、コンピューター２１１はゲートウェイ２２１にＩＰパケットを送信する。

ゲートウェイ２２１は、受信したＩＰパケットの送信元ＩＰアドレスと送信元ポート番号の組がＬＡ、ＬＰの組と一致する行を検索する。

一致する行が見つかったならば、該ＩＰパケットの送信元ＩＰアドレスと送信元ポート番号をそれぞれ、見つかった行のＧＡ、ＧＰに置き換え、コンピューター２１６に送信する。

この場合は、送信元ＩＰアドレス１０．０．１．２は１９２．０．２．１に置き換えられ、送信元ポート番号８０８０は８０に置き換えられる。

同様にして、コンピューター２１６とコンピューター２１１はＩＰパケットを送受信する。

このように、ＮＡＰＴでは、あらかじめローカルＩＰアドレスとそのポート番号、グローバルＩＰアドレスとそのポート番号の組が登録されていれば、インターネットのコンピューターからローカル・ネットワークのコンピューターを指定して通信を行うことが可能である。

ＮＡＴはＮＡＰＴと同様の技術であるが、ポート番号を考慮せずに、グローバルＩＰアドレスとローカルＩＰアドレスを対応付ける。

また、高機能ゲートウェイは、グローバルＩＰアドレスとポート番号の組ではなく、アプリケーション層のプロトコル（例えばＨＴＴＰ）を解析し、ローカルＩＰアドレスとポート番号の組を決定するものである。

ＩＰマスカレードによって、ローカル・ネットワーク上のコンピューターからインターネット上のコンピューターに通信を開始することが可能となった。

また、ＮＡＰＴやＮＡＴ、高機能ゲートウェイによって、その逆も可能となっている。

しかしながら、ＮＡＰＴ，ＮＡＴ、高機能ゲートウェイは、いずれもインターネットとローカル・ネットワークとをつなぐゲートウェイに実施される技術であるため、これらの技術によってローカル・ネットワーク上のコンピューターをインターネットに公開する（即ち、外部のネットワークからローカル・ネットワークにコネクションの確立要求を行うなど通信を開始するようにする）ためには、該ゲートウェイにおいてこれらの技術を実施し、事前に登録する必要がある。

そして多くの場合、前記ゲートウェイにおいてＩＰマスカレードは実施されていても、ＮＡＰＴやＮＡＴ、高機能ゲートウェイへの登録はされていないというのが一般的である。

特願２００２−５３６６８

ＲＦＣ７９１ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ

ＲＦＣ７９３ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ

ＲＦＣ７６８ Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ

ＲＦＣ１５９７ Ａｄｄｒｅｓｓ Ａｌｌｏｃａｔｉｏｎ ｆｏｒ Ｐｒｉｖａｔｅ Ｉｎｔｅｒｎｅｔｓ

発明が解決しようとする課題

一般に、前記ゲートウェイはＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）が管理するものであり、ＩＳＰの顧客は該ゲートウェイに前記技術を実施したり登録を行ったりする権利は与えられていない。

またＩＰマスカレードは実施されていて、前記ＩＳＰの顧客はこの技術によってインターネットに接続できるが、ＮＡＰＴやＮＡＴ、高機能ゲートウェイへの登録はされてないというのが一般的である。

このため、顧客のコンピューターにグローバルＩＰアドレスを割り当てないＩＳＰの顧客は、ＩＳＰから特にサービスを受けることで登録をされない限り、インターネット上にコンピューターを公開することはできないのが現状である。

これらから、以下の課題が存在する。

課題１として、ＩＰマスカレード等の技術によって外部のネットワークに接続できるローカル・ネットワーク上にあるコンピューターへ向けて該外部のネットワーク上にある任意のコンピューターから通信を開始するための、該ローカル・ネットワークと該外部のネットワークとの間にあって該外部のネットワークに接続されているゲートウェイに対する変更や登録等を行う必要のない手段を提供する。

課題２として、課題１の手段における通信の開始ののち、前記外部のネットワーク上にある任意のコンピューターと前記ローカル・ネットワーク上にあるコンピューターとが通信を行う手段を提供する。

課題３として、課題１、２の手段を、可能な限り既存の手段を利用することで実施を容易とする手段を提供する。

課題４として、課題１、２、３の手段を、前記外部のネットワークにおける一つのノード識別子を複数の前記ローカル・ネットワーク上にあるコンピューターで共用できる手段を提供する。

課題５として、課題４の手段を、前記外部のネットワークにおいて使用されているプロトコルによってノード識別子以外に多重化識別子（ＴＣＰ／ＩＰやＵＤＰ／ＩＰにおけるポート番号）が必要とされる場合に該多重化識別子を共用できる手段を提供する。

課題６として、課題１、２、３、４、５を解決するにあたって、既存のハードウェアやソフトウェアへの変更が少なくて済む手段を提供する。

課題７として、課題６を解決するにあたって、ローカル・ネットワーク上のコンピューターに関する情報をローカル・ネットワークの外部に提供する必要がない手段を提供する。

課題８として、課題６、７を解決するにあたって、ローカル・ネットワーク上のコンピューターが通信相手に関する情報を取得する場合でも変更が少なくて済む手段を提供する。

本発明の目的は、課題１、２、３、４、５、６、７、８を解決するパーソナルＩＰシステムを提供することにある。

課題を解決するための手段

本発明は、上記の課題を解決するために、次のような手段を採用した。

第一の手段は、外部のネットワークにある任意のコンピューターがアクセスできるサーバーに該任意のコンピューターがコネクションの確立要求などを送信すると、ローカル・ネットワークにあるクライアントに対して通知するシステムであり、該通知がＩＰマスカレード等の技術を利用して前記サーバーに前記クライアントがアクセスすることで構築した仮想回線を使用すること、及び、該通知にともなって、あらたな通信チャネルを構築し、該通信チャネルによって通信内容を転送することを特徴とする。

第二の手段は、第一の手段における通信チャネルの構築を、前記仮想回線上に論理的な複数の通信チャネルを構築することによって行うことを特徴とする。

第三の手段は、第一の手段における通信チャネルの構築を、前記サーバーと前記クライアントの間に新たに仮想回線を構築し、該仮想回線を通信チャネルとして使用することによって行うことを特徴とする。

第四の手段は、前記サーバーが複数の前記クライアントに対して個別に第一の手段における仮想回線を構築することを特徴とする。

第五の手段は、第四の手段における複数の仮想回線の一つを特定するために、前記外部のネットワークにある任意のコンピューターから前記サーバーに送信を行う際に使用されるアプリケーション層のプロトコルに基づいてその内容を解析することを特徴とする。

第六の手段は、前記クライアントが前記通信チャネルの通信内容を前記ローカル・ネットワーク内で使用しているプロトコルに変換し、転送することを特徴とする。

第七の手段は、前記クライアントが前記通信チャネルによって通信されている内容をローカル・ネットワーク内の複数のコンピューターのいずれに送信するがを特定するために、該通信を行う際に使用されるアプリケーション層のプロトコルに基づいて内容を解析することを特徴とする。

第八の手段は、前記クライアントを、前記ローカル・ネットワークのデフォルト・ゲートウェイとすることで、実際に通信を行う前記外部のネットワークのコンピューターを識別するノード識別子や多重化識別子を該ローカル・ネットワークにおいて使用されているプロトコルにおける送信元や送信先とすることを特徴とする。

本発明の一実施形態を、図１及び図５ないし図２３を用いて説明する。

図１は、インターネットに接続されたゲートウェイによってＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）をインターネットに接続しているプロバイダーと、自宅にある三台のコンピューターを接続しているＬＡＮを該プロバイダーのＬＡＮに接続された本発明にかかるクライアントであるゲートウェイによって該プロバイダーのＬＡＮに接続している該プロバイダーの顧客と、インターネットに接続された本発明にかかるサーバーの図である。

同図において、１３３はインターネット、１３２はＩＳＰのＬＡＮ、１３１は前記ＩＳＰの顧客の家庭にあるＬＡＮ、１０１はＬＡＮ１３１に接続されているローカルＩＰアドレス１９２．１６８．１３１．１０１を割り振られたコンピューター、１０２はＬＡＮ１３１に接続されているローカルＩＰアドレス１９２．１６８．１３１．１０２を割り振られたコンピューター、１０３はＬＡＮ１３１に接続されているローカルＩＰアドレス１９２．１６８．１３１．１０３を割り振られたコンピューター、１０７はインターネット１３３に接続されたグローバルＩＰアドレス１９２．０．２．１０７を割り振られたコンピューター、１０８はインターネット１３３に接続されたグローバルＩＰアドレス１９２．０．２．１０８を割り振られたコンピューター、１１１はインターネット１３３に接続された本発明に係るサーバー、１２２はＬＡＮ１３２とインターネット１３３をつなぐインターネット１３３に対してグローバルＩＰアドレス１９２．０．２．１２２をＬＡＮ１３２に対してローカルＩＰアドレス１７２．１６．１３２．１２２を割り当てられたＩＰマスカレードを実施されたゲートウェイ、１２１はＬＡＮ１３１とＬＡＮ１３２をつなぐＬＡＮ１３２に対してローカルＩＰアドレス１７２．１６．１３２．１２１をＬＡＮ１３１に対してローカルＩＰアドレス１９２．１６８．１３１．１２１を割り当てられた本発明に係るクライアントであるＩＰマスカレードを実施されたゲートウェイでありＬＡＮ１３１におけるデフォルト・ゲートウェイである。

図５は、サーバー１１１の概念図である。

同図において、５１１はＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）用デバイダー・モジュール、５１２はＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）用デバイダー・モジュール、５２０はスイッチャー・モジュール、５２１、５２２、５２３はフォワーダー・モジュール、５３１、５３２、５３３はそれぞれフォワーダー５２１、５２２、５２３に異なったクライアントから接続されている仮想回線、５４１はフォワーダーマスター・モジュールである。１０７、１１１は図１と同じなので省略する。

図６は、クライアント１２１の概念図である。

同図において、６１１はレシーバー・モジュール、６２１はＨＴＴＰ用セレクター・モジュール、６２２はＦＴＰ用セレクター・モジュール、６２３はＳＭＴＰ用セレクター・モジュール、６３１はプレマスカレード・モジュール、１０１１はコンピューター１０１のポート番号８０において稼動しているＨＴＴＰサーバー・アプリケーション、１０１２はコンピューター１０１のポート番号２１において稼動しているＦＴＰサーバー・アプリケーション、１０１３はコンピューター１０１のポート番号２５において稼動しているＳＭＴＰサーバー・アプリケーション、１０２１はコンピューター１０２のポート番号８０において稼動しているＨＴＴＰサーバー・アプリケーション、１０２２はコンピューター１０２のポート番号２１において稼動しているＦＴＰサーバー・アプリケーション、１０２３はコンピューター１０２のポート番号２５において稼動しているＳＭＴＰサーバー・アプリケーション、１０３１はコンピューター１０３のポート番号８０において稼動しているＨＴＴＰサーバー・アプリケーション、１０３２はコンピューター１０３のポート番号２１において稼動しているＦＴＰサーバー・アプリケーション、１０３３はコンピューター１０３のポート番号２５において稼動しているＳＭＴＰサーバー・アプリケーションである。１０１、１０２、１０３、１２１は図１と、５３１は図５と同じなので省略する。

図７は、スイッチャー５２０が具備するフォワーダー一覧である。

図８は、レシーバー６１１が具備するセレクター一覧である。

図９は、セレクター６２１が具備する選択表である。セレクターは類似の選択表を具備する。

図１０は、ゲートウェイ１２１のプロトコル・スタックが受信したＩＰパケットを該ゲートウェイに実施されているＩＰマスカレードに処理させる際にプレマスカレード６３１が使用するプレマスカレード対応表である。

図１１は、仮想回線５３１、５３２、５３３において通信を行う際に使用されるチャンクのフォーマットである。

ここで、請求項１ないし８に記載の各特徴は以下のとおりである。

サーバーは、サーバー１１１である。

クライアントは、ゲートウェイ１２１である。

請求項１の（１−１）に記載のネットワークは、ＬＡＮ１３１である。また、ＬＡＮ１３１で使用されているプロトコルはＩＰであり、そのノード識別子空間は１９２．１６８．０．０〜１９２．１６８．２５５．２５５（１９２．１６８．０．０／１６）のローカルＩＰアドレスである。

請求項１の（１−２）に記載のネットワークは、インターネット１３３である。インターネット１３３で使用されているプロトコルはＩＰであり、そのノード識別子空間はグローバルＩＰアドレスである。

請求項１の（１−３）に記載の仮想回線は、仮想回線５３１、５３２、５３３である。

請求項１の（１−４）に記載の手段は、請求項２の（２−１）に記載の手段と請求項３の（３−４）に記載の手段である。

請求項１の（１−５）に記載のチャンクは、図１１のフォーマットを持つ。

請求項１の（１−６）に記載の通信は、デバイダーがＴＣＰ／ＩＰないしはＵＤＰ／ＩＰによって行う。

請求項１の（１−７）に記載の情報は、図１１における外部ＩＰアドレスと外部ポート番号である。

請求項１の（１−８）に記載の送信は、デバイダーがフォワーダーに送信後、それを該フォワーダーがレシーバーに送信することで行う。

請求項１の（１−９）に記載の情報は、図１１におけるフラグのＣビットであり、該ビットが１か否かによって識別する。

請求項１の（１−１０）に記載の転送は、ＴＣＰ／ＩＰ通信においては請求項３の（３−４）に記載の通信チャネルによってデバイダーが行い、ＵＤＰ／ＩＰ通信においてはデバイダーがフォワーダーに転送後、該フォワーダーが請求項２の（２−１）に記載の通信チャネルによって行う。

請求項１の（１−１１）に記載の転送は、請求項３の（３−４）に記載の通信チャネルによってデバイダーが受信した場合には該デバイダーがＴＣＰ／ＩＰ通信によって行い、請求項２の（２−１）に記載の通信チャネルによってフォワーダーが受信した場合には該フォワーダーがデバイダーに転送後、該デバイダーがＵＤＰ／ＩＰ通信によって行う。

請求項２の（２−１）に記載の通信チャネルは、フォワーダーとレシーバーが管理する。この通信チャネルは請求項１の（１−６）に記載の通信がＵＤＰ／ＩＰの際に使用される。

請求項２の（２−２）に記載の情報は、図１０におけるフラグのＳビットであり、該ビットが１か否かによって識別する。

請求項２の（２−３）に記載の特徴は、フォワーダーとレシーバーが具備する。

請求項２の（２−４）に記載の情報は、図１０におけるフラグのＥビットであり、該ビットが１か否かによって識別する。

請求項２の（２−５）に記載の特徴は、フォワーダーとレシーバーが具備する。

請求項３の（３−１）に記載の準備は、請求項１の（１−６）に記載の通信がＴＣＰ／ＩＰの場合にデバイダーが行う。これはＵＮＩＸ等のＯＳにおいては、デバイダーがＴＣＰ／ＩＰソケットを作成し、ｂｉｎｄ（）、ｌｉｓｔｅｎ（）、等の関数を呼ぶことである。

請求項３の（３−２）に記載の送信は、デバイダーが請求項３の（３−１）に記載の準備を行うことで取得された識別子であるＩＰアドレスとポート番号をフォワーダーに転送後、該フォワーダーが行う。ＵＮＩＸ等のＯＳにおいては、デバイダーはこの送信の後、ａｃｃｅｐｔ（）関数によってセレクターから接続されるのを待ち受ける。

請求項３の（３−３）に記載の構築は、請求項３の（３−２）に記載の送信によって受信した識別子であるＩＰアドレスとポート番号に、セレクターがＴＣＰ／ＩＰによって仮想回線を構築することで行う。これはＵＮＩＸ等のＯＳにおいては、セレクターが受信されたＩＰアドレスとポート番号に対してｃｏｎｎｅｃｔ（）関数を呼ぶことで仮想回線を構築することである。

請求項３の（３−４）に記載の通信チャネルは、請求項３の（３−３）に記載の構築によって構築された、デバイダーとセレクターとを接続するＴＣＰ／ＩＰによる仮想回線である。

請求項４の（４−１）に記載のプロトコルはＩＰであり、仮想回線の構築にはＴＣＰ／ＩＰを用いる。

請求項４の（４−２）に記載の特徴は、クライアントからの要求に対して各々一つづつに対応するフォワーダーを構築することに相当する。図５においては、三つのクライアント（内一つはゲートウェイ１２１）から要求を受けたことを示している。

請求項４の（４−３）に記載の選択手段は、デバイダーである。これは該デバイダーがフォワーダーを選択することである。

請求項４の（４−４）に記載の送信は、前記デバイダーが前記選択によって選択されたフォワーダーに対して送信を行ったものを、該フォワーダーがレシーバーへ転送する。

請求項５の（５−１）に記載の選択は、デバイダーが行う。デバイダーは、アプリケーション層のプロトコルにおけるクライアントを特定する情報、例えば、ＨＴＴＰ用のデバイダーであればＨＴＴＰにおけるサーバー名を指定する情報、ＳＭＴＰ用のデバイダーであればＳＭＴＰにおける送信先メールアドレスを指定する情報、によって特定されたクライアント、に対応する仮想回線、に対応するフォワーダーを選択する。

請求項５の（５−２）に記載の送信の保留は、デバイダーが行う。デバイダーは、選択を行うに充分な情報を受信するまではフォワーダーの選択を行わない。それまでの間にアプリケーション層のプロトコルに基づいて返答を必要とするならば仮に返答を行う。

請求項６の（６−１）に記載の記録手段は、図９の選択表である。

請求項６の（６−２）に記載の通信は、セレクターがＴＣＰ／ＩＰないしはＵＤＰ／ＩＰによって行う。

請求項６の（６−３）に記載の選択手段は、セレクターである。これは該セレクターが図９の選択表に示されるローカル・サーバー・アドレスとプロトコルを選択することで、（１−１）に記載のネットワークに存在するサーバー・アプリケーションを選択することである。

請求項６の（６−４）に記載の転送は、ＵＤＰ／ＩＰ通信であれば、レシーバーがフォワーダーから請求項２の（２−１）に記載の通信チャネルによって受信した内容をセレクターに転送し、該転送内容をセレクターが選択されたサーバー・アプリケーションに転送する。ＴＣＰ／ＩＰ通信であれば、請求項３の（３−４）に記載の通信チャネルによってデバイダーから受信した内容をセレクターが選択されたサーバー・アプリケーションに転送する。

請求項６の（６−５）に記載の選択手段は、プレマスカレードである。プレマスカレードは受信したＩＰパケットをいずれのセレクターに送信するか、あるいは送信しないでＩＰマスカレードに処理させるかを選択する。

請求項６の（６−６）に記載の転送は、プレマスカレードによって選択されたセレクターに転送されたあと、該セレクターからサーバーとの通信チャネルによって行われる。

請求項７の（７−１）に記載の選択はセレクターが行う。セレクターは、アプリケーション層のプロトコルにおけるサーバー・アプリケーションを特定する情報、例えば、ＨＴＴＰ用のデバイダーであればＨＴＴＰにおけるＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を指定する情報ないしはサーバー名を指定する情報、ＳＭＴＰ用のデバイダーであればＳＭＴＰにおける送信先メールアドレスを指定する情報、によって特定されたサーバー・アプリケーション、に対応するローカル・サーバー・アドレスとプロトコルを図９の選択表をもちいて選択する。

請求項７の（７−２）に記載の保留はセレクターが行う。セレクターは、前記サーバー・アプリケーションを特定する情報を受信するまではローカル・サーバー・アドレスとプロトコルの選択を行わない。それまでの間にアプリケーション層のプロトコルに基づいて返答を必要とするならば仮に返答を行う。

請求項８の（８−１）に記載の特徴は、ＬＡＮ１３１とインターネット１３３が共にＩＰを使用し、インターネット１３３において使用されているノード識別子空間がグローバルＩＰアドレスであることである。これによって、インターネット１３３からはＬＡＮ１３１のノード識別子では一意にノードを識別できないが、ＬＡＮ１３１からはインターネット１３３のノード識別子によって一意にノードを識別できる。

請求項８の（８−２）に記載の識別子は、図１１における外部ＩＰアドレスと外部ポート番号である。

請求項８の（８−３）に記載の特徴は、クライアント１２１がＬＡＮ１３１のデフォルト・ゲートウェイであることである。

請求項８の（８−４）に記載の転送における変換は、セレクターがサーバー・アプリケーションに送信する際に、プレマスカレードによって、送信するＴＣＰ／ＩＰパケットないしはＵＤＰ／ＩＰパケットの送信元ＩＰアドレスと送信元ポート番号を、図１０における発信アドレスの内容に変換することで行われる。

請求項８の（８−５）に記載の変換は、プレマスカレードが行う。

図１２ないし図１７は、本発明にかかるサーバー及びそのモジュールにおけるフローチャートである。

図１２は、本発明にかかるサーバーにおけるフローチャートである。

サーバーは、スイッチャー・モジュール、デバイダー・モジュール、フォワーダーマスター・モジュールをプロセスとして起動する。

ここでデバイダー・モジュールは、該サーバーがサポートするアプリケーション層のプロトコルによって通信する際に使用する下位のプロトコルがＴＣＰ／ＩＰであるかＵＤＰ／ＩＰであるかによって異なり、また、前記アプリケーション層のプロトコルによっても異なる。

図１３は、スイッチャーのフローチャートである。

スイッチャーは、他のモジュールと通信するためのＵＤＰ／ＩＰのスイッチャーポートを開設する。

また、図７に示されるフォワーダー一覧を作成し、空に初期化する。このフォワーダー一覧は、本発明に係るクライアントが接続してきたときに、該クライアントを識別するキーワードと該クライアントとの通信のためのフォワーダーポートへのアドレスが追加されていく。

こののち、スイッチャーポートに送信されたパケットを読み込み、フォワーダー一覧に追加／削除、あるいはその内容への問合せに返答を行うことを繰り返す。

読み込んだパケットがフォワーダー生成を示すパケットである場合は、該パケットに含まれるデバイダー識別子とキーワード、プロトコル、フォワーダーポートへのアドレスを含む行を、生成されたフォワーダーに対応する行としてフォワーダー一覧に追加する。

読み込んだパケットがフォワーダー消滅を示すパケットである場合は、フォワーダー一覧から対応する行を削除する。

読み込んだパケットが問合せを示すパケットである場合は、該パケットに含まれるデバイダー識別子とキーワードを含む行をフォワーダー一覧から検索し、見つかったならその行のフォワーダーポートへのアドレスを返送する。

見つからなかったならば、見つからなかったことを返送する。

図１４は、ＴＣＰ／ＩＰを使用するデバイダーのフローチャートの前半である。

ＴＣＰ／ＩＰを使用するデバイダーは、請求項１の（１−６）に記載の特徴である他のコンピューターないしはクライアント・アプリケーションからコネクションを確立することを要求されて仮想回線を構築して通信を行うために、ＴＣＰ／ＩＰのデバイダーポートを開設する。

スイッチャーポートに、デバイダー生成パケットとしてデバイダー識別子を送信する。

デバイダーポートへの接続を待ち、接続があれば子プロセスを生成することを繰り返す。

前記子プロセスのフローチャートは、図１５に示される、ＴＣＰ／ＩＰを使用するデバイダーのフローチャートの後半に記述される。

図１５は、ＴＣＰ／ＩＰを使用するデバイダーのフローチャートの後半である。

図１４において生成された子プロセスは、接続してきたポートからデーターを読み込み、キーワードを探す。キーワードが見つかるまでは順次読み込んだデーターをバッファーに保存していく。このときに返信する必要があれば、返信を行う。

見つかったキーワードとデバイダー識別子を、問合せパケットとしてスイッチャーポートに送信し、フォワーダーポートへのアドレスを取得する。

そののち、本発明に係るクライアントからコネクションを確立することを要求されるために、転送ポートを開設する。

図１１において示されるチャンクを作成し、該チャンクの内容として、転送ポートのアドレスとポート番号を与える。

前記チャンクをフォワーダーポートに送信する。

転送ポートへの接続を待つ。

転送ポートへ接続してきたら、バッファーに保存されているデバイダーポートから読み込んだ内容を転送ポートへ送信する。

デバイダーポートと転送ポートからの受信を待ち、受信した内容を他方に送信することを繰り返す。

図１６は、ＵＤＰ／ＩＰを使用するデバイダーのフローチャートである。

ＵＤＰ／ＩＰを使用するデバイダーは、請求項１の（１−６）に記載の特徴である他のコンピューターないしはクライアント・アプリケーションからコネクションレスの通信を行うために、ＵＤＰ／ＩＰのデバイダーポートを開設する。

またフォワーダーから図１１において示されるチャンクを転送されるための、ＵＤＰ／ＩＰの転送ポートを開設する。

そして、デバイダーポートと転送ポートのそれぞれから受信を待つ。

デバイダーポートから受信した場合、受信したＵＤＰパケットの内容からキーワードを探す。

見つかったキーワードとデバイダー識別子を、問合せパケットとしてスイッチャーポートに送信し、フォワーダーポートへのアドレスを取得する。

図１１において示されるチャンクを作成し、該チャンクの内容として、前記受信したＵＤＰパケットの内容を与える。

また、該ＵＤＰパケットの送信元ＩＰアドレスとポート番号を、外部ＩＰアドレスと外部ポート番号として与える。

さらに、転送ポートのＩＰアドレスとポート番号を内部ＩＰアドレスと内部ポート番号として与える。

そして前記チャンクをフォワーダーポートに送信する。

転送ポートから受信した場合、受信したＵＤＰパケットの内容を図１１において示されるチャンクであると見做して、その外部ＩＰアドレスと外部ポート番号を取得する。

そして、前記チャンクの内容を取得した外部ＩＰアドレスと外部ポート番号へ向けて送信する。

図１７は、フォワーダーマスターのフローチャートである。

フォワーダーマスターは、本発明に係るクライアントからの接続を待つためのサーバーポートを開設する。

サーバーポートへの接続を待ち、接続があれば子プロセスを作成することを繰り返す。

作成された子プロセスは、接続してきた本発明に係るクライアント用のフォワーダーとなる。以下、サーバーポートに接続してきたポートをクライアントポートとする。

フォワーダーはクライアントポートから、クライアントが要求するデバイダー識別子とキーワードを読み込む。

デバイダーから受信するために、ＵＤＰ／ＩＰのフォワーダーポートを開設する。

スイッチャーポートに、前記フォワーダーポートのＩＰアドレスとポート番号をフォワーダーポートのアドレスとして、デバイダー識別子とキーワードと共に送信する。

フォワーダーポートとクライアントポートからの受信を待ち、転送することを繰り返す。

フォワーダーポートから受信した場合、受信したＵＤＰパケットの内容を図１１において示されるチャンクと見做し、該チャンクをクライアントポートに送信する。

クライアントポートから受信した場合、受信した図１１において示されるチャンクの内部ＩＰアドレスと内部ポート番号からＩＰアドレスとポート番号を取得する。

取得したＩＰアドレスとポート番号へ、前記チャンクを送信する。

図１８ないし図２３は、本発明にかかるクライアント及びそのモジュールにおけるフローチャートである。

図１８は、本発明にかかるクライアントのフローチャートである。

クライアントは、プレマスカレード、セレクター、レシーバーを起動する。

クライアントがレシーバーを起動せずに、かわりに、セレクター起動後にレシーバーとなってレシーバーのフローチャートにそって動作しても同じ効果が得られる。

図１９は、レシーバーのフローチャートである。

レシーバーは、セレクターから受信するために、ＵＤＰ／ＩＰのレシーバーポートを開設する。

レシーバーは、本発明にかかるサーバーに開設されたサーバーポートにＴＣＰ／ＩＰによって接続する。その後、デバイダー識別子とキーワードを送信する。

レシーバーポートとサーバーポートとからの受信を待ち、転送することを繰り返す。

レシーバーポートから受信した場合は、その内容を図１１において示されるチャンクと見做し、該チャンクをサーバーポートに送信する。

サーバーポートから受信した場合は、受信した図１１において示されるチャンクのデバイダー識別子を取得する。

前記デバイダー識別子に対応するセレクターのセレクターポートに、前記受信したチャンクを送信する。

図２０は、ＴＣＰ／ＩＰを使用するセレクターのフローチャートである。

セレクターは、レシーバーから受信するために、ＵＤＰ／ＩＰのセレクターポートを開設する。

セレクターポートからの受信を待ち、子プロセスを生成することを繰り返す。

子プロセスは、受信したＵＤＰパケットの内容を図１１において示されるチャンクと見做し、該チャンクの外部ＩＰアドレスと外部ポート番号を取得し、発信アドレスのＩＰアドレスとポート番号とする。また、内部ＩＰアドレスと内部ポート番号を取得し、内部アドレスのＩＰアドレスとポート番号とする。さらに、前記チャンクの内容から、転送ポートのＩＰアドレスとポート番号を取得する。

前記転送ポートへ接続する。

転送ポートから受信した内容からキーワードを検索し、図９において示される選択表から、前記キーワードと、セレクターに対応するデバイダー識別子と、プロトコルと、が一致する行の、ローカル・サーバーのＩＰアドレスとポート番号を取得する。

図１０において示されるプレマスカレード対応表に、発信アドレスとして発信アドレスのＩＰアドレスとポート番号を、ローカルアドレスとしてローカル・サーバーのＩＰアドレスとポート番号を、外部アドレスとして内部アドレスのＩＰアドレスとポート番号を、内部アドレスとしてローカル・サーバーに接続しようとしているポートのＩＰアドレスとポート番号を、プロトコルとしてＴＣＰを、最終使用時刻に現在時刻を持った行を登録する。

ローカル・サーバーに接続する。なお、このときに発信されるＩＰパケットはプレマスカレードによって処理され、発信アドレスから接続されているように見える。

転送ポートから受信した内容をローカル・サーバーに送信する。

転送ポートとローカル・サーバーとからの受信を待ち、転送することを繰り返す。

転送ポートから受信した場合は、受信した内容をローカル・サーバーへ送信する。

ローカル・サーバーから受信した場合は、受信した内容を転送ポートへ送信する。

図２１は、ＵＤＰ／ＩＰを使用するセレクターのフローチャートの前半である。

セレクターは、レシーバーから受信するために、ＵＤＰ／ＩＰのセレクターポートを開設する。

セレクターポートからの受信を待つ。

受信したＵＤＰパケットの内容を図１１において示されるチャンクと見做し、該チャンクの外部ＩＰアドレスと外部ポート番号を取得し、発信アドレスのＩＰアドレスとポート番号とする。また、内部ＩＰアドレスと内部ポート番号を取得し、内部アドレスのＩＰアドレスとポート番号とする。

前記チャンクの内容からキーワードを検索し、図９において示される選択表から、前記キーワードと、セレクターに対応するデバイダー識別子と、プロトコルと、が一致する行の、ローカル・サーバーのＩＰアドレスとポート番号を取得する。

図１０において示されるプレマスカレード対応表から、発信アドレスとして発信アドレスのＩＰアドレスとポート番号を、ローカルアドレスとしてローカル・サーバーのＩＰアドレスとポート番号を、外部アドレスとして内部アドレスのＩＰアドレスとポート番号を、プロトコルとしてＵＤＰを持つ行を探す。

見つかった場合は、ＵＤＰ／ＩＰパケットを作成し、送信先のＩＰアドレスとポート番号に見つかった行のローカルアドレスを、送信元のＩＰアドレスとポート番号に内部アドレスを指定し、内容として前記チャンクの内容を与え、送信する。

見つかった行の最終使用時刻を現在時刻に更新する。

セレクターポートの受信を待つところから繰り返す。

見つからなかった場合は、子プロセスを生成し、セレクターポートの受信を待つところから繰り返す。

前記子プロセスのフローチャートは、図２２に示されるＵＤＰ／ＩＰを使用するセレクターのフローチャートの後半に記述される。

図２２は、ＵＤＰ／ＩＰを使用するセレクターのフローチャートの後半である。

セレクターの子プロセスは、ローカル・サーバーと通信するために、ＵＤＰ／ＩＰの新規ポートを開設する。

図１０において示されるプレマスカレード対応表に、発信アドレスとして発信アドレスのＩＰアドレスとポート番号を、ローカルアドレスとしてローカル・サーバーのＩＰアドレスとポート番号を、外部アドレスとして内部アドレスのＩＰアドレスとポート番号を、内部アドレスとして新規ポートのＩＰアドレスとポート番号を、プロトコルとしてＵＤＰを、最終使用時刻に現在時刻を持った行を登録する。

前記チャンクの内容を、ローカル・サーバーに送信する。

新規ＵＤＰポートからの受信を待つ。このとき、あらかじめ指定された時間受信がなければタイムアウトする。

受信した場合は図１１において示されるチャンクを作成し、該チャンクの内容として受信した内容を、発信ＩＰアドレスと発信ポート番号、内部ＩＰアドレスと内部ポート番号、外部ＩＰアドレスと外部ポート番号、デバイダー識別子を与え、レシーバーポートに送信する。

前記図１０において示されるプレマスカレード対応表に登録された行の最終使用時刻を現在時刻に更新する。

新規ＵＤＰポートからの受信を待つところから繰り返す。

タイムアウトした場合は、前記図１０において示されるプレマスカレード対応表に登録された行の最終使用時刻を取得する。

最終使用時刻が現在時刻から、あらかじめ指定された時間以上の差がないならば、新規ＵＤＰポートからの受信を待つところから繰り返す。

あらかじめ指定された時間以上の差があるならば、前記図１０において示されるプレマスカレード対応表に登録された行を削除し、新規ポートを閉鎖する。

子プロセスを終了する。

図２３は、プレマスカレードのフローチャートである。

図１０において示されるプレマスカレード対応表を初期化し、行数を零にすることで内容を空にする。

ＩＰパケットが受信されるのを待つ。

受信されたらＩＰマスカレードに処理させる前に、前記受信したＩＰパケットのプロトコルを取得する。

前記取得したプロトコルがＴＣＰかＵＤＰでないならば、ＩＰマスカレードに処理をさせ、ＩＰパケットが受信されるのを待つところから繰り返す。

前記取得したプロトコルがＴＣＰかＵＤＰであるならば、前記受信したＩＰパケットの送信元ＩＰアドレスと送信元ポート番号と、送信先ＩＰアドレスと送信先ポート番号と、を取得する。

図１０において示されるプレマスカレード対応表から、外部アドレスとして送信元ＩＰアドレスと送信元ポート番号を、内部アドレスとして送信先ＩＰアドレスと送信先ポート番号を、プロトコルとして前記取得したプロトコルを持つ行を探す。

見つかった場合は、前記受信したＩＰパケットの、送信元ＩＰアドレスと送信元ポート番号を発信アドレスに、送信先ＩＰアドレスと送信先ポート番号をローカル・サーバー・アドレスに、置き換え、ＩＰマスカレードに処理をさせ、ＩＰパケットが受信されるのを待つところから繰り返す。

見つからなかった場合は、 図１０において示されるプレマスカレード対応表から、発信アドレスとして送信先ＩＰアドレスと送信先ポート番号を、ローカル・サーバー・アドレスとして送信元ＩＰアドレスと送信元ポート番号を、プロトコルとして前記取得したプロトコルを持つ行を探す。

見つかった場合は、前記受信したＩＰパケットの、送信先ＩＰアドレスと送信先ポート番号を外部アドレスに、送信元ＩＰアドレスと送信元ポート番号を内部アドレスに、置き換え、ＩＰマスカレードに処理をさせ、ＩＰパケットが受信されるのを待つところから繰り返す。

見つからなかった場合は、ＩＰマスカレードに処理をさせ、ＩＰパケットが受信されるのを待つところから繰り返す。

「他の実施形態」
図１の実施形態では、ＬＡＮ１３１はＩＰをプロトコルとしローカルＩＰアドレスをノード識別子空間として使用し、グローバルＩＰアドレスをそのまま対応方法としている。他の実施形態では、ＬＡＮ１３１で使用するプロトコルをＩＰｖ６にし、ＩＰｖ４組み込みＩＰｖ６アドレスを請求項８の（８−１）に記載の対応手段としてもよい。

こうすることで、各地のＬＡＮが将来のＩＰｖ６化に対応するための事前準備を行うための環境を構築することができ、将来ＩＰｖ６に対応する際にスムーズに対応することができる。

また図１の実施形態では、本発明にかかるクライアントはゲートウェイ１２１であるが、本発明にかかるクライアントをデフォルト・ゲートウェイではなく、ＬＡＮ１３１に接続されているコンピューターとしてもよい。

こうすることで、既存のゲートウェイに対する変更無しに実施することが可能となる。

発明の効果

請求項１に記載の発明によれば、コネクションの確立要求がローカル・ネットワーク上のコンピューターから送信されるため、ＩＰマスカレードによってインターネットに接続できるコンピューターであれば利用が可能となる。

また、仮想回線が確保されているため、ローカル・ネットワーク上にあるコンピューターに対して、インターネット上にあるサーバーから随時送信が行える。

そして、複数の通信チャネルを用いることから、複数のインターネット上にあるコンピューターがサーバーに通信を行うことができる。

これによって、インターネット上にあるコンピューターから、サーバーを代理としてアクセスすることで、ローカル・ネットワーク上にあるコンピューターに対してコネクションの確立要求を送信することが可能となり、課題１が解決される。

請求項２に記載の発明によれば、一つの仮想回線上に複数の通信チャネルを作ることが可能となる。

この通信チャネルをつかって、クライアントとサーバーがインターネット上にある複数のコンピューターに対応する通信を行うことが可能となり、課題２が解決される。

請求項３に記載の発明によれば、新しく仮想回線を構築することで通信チャネルとすることができる。

これによって、通信チャネルの状態や構築、破棄の管理を既存のＯＳやプロトコル・スタックに行わせることができる。

このため、前記管理が最小限で済むようになるため、実施が容易となり、課題３が解決される。

請求項４に記載の発明によれば、一つのサーバーを複数のクライアントが共用することが可能となる。

このため、複数のクライアントが一つのノード識別子を共用することができ、課題４が解決される。

請求項５に記載の発明によれば、一つの多重化識別子で複数の仮想回線を区別することが可能となる。

このため、ウェルノウン・ポート番号など、使用可能な多重化識別子に制限がある場合でも、それを複数のクライアントが共用することができるので、課題５が解決される。

請求項６に記載の発明によれば、通信チャネルによる送受信をローカル・ネットワーク内にて使用されている通信方法によって、転送することが可能となる。

これによって、該ローカル・ネットワーク上の公開したいコンピューターやプログラムを、クライアントとしてサーバーと仮想回線を構築するように変更しなくともよくなる。すなわち、課題６が解決される。

請求項７に記載の発明によれば、クライアントは、特別にローカル・ネットワーク上のコンピューターを指定するための情報が無くとも、複数のローカル・ネットワーク上のコンピューターやプログラムのうちのいずれに転送するべきかを選択できる。

これによって、あらかじめサーバーにローカル・ネットワーク上のコンピューターやプログラムに関する情報を提供せずとも、クライアントが通信を行うべきローカル・ネットワーク上のコンピューターやプログラムを選択することができるので、課題７が解決される。

請求項８に記載の発明によれば、ローカル・ネットワークの外部への通信を取りまとめるデフォルト・ゲートウェイによって、仮想回線による送受信を該ローカル・ネットワーク内にて使用されている通信方法に変換する際に、通信相手のノード識別子や多重化識別子を実際の通信相手のノード識別子や多重化識別子とすることが可能となる。

これによって、ローカル・ネットワーク内の各コンピューターやプログラムは、通信相手として実際の通信相手のノード識別子や多重化識別子を既存の手段によって取得することが可能となる。

このことは、前記コンピューターやプログラムが、仮想回線経由で通信が行われていることを認識できないほどに透過的であるため、セキュリティーや情報収集のために接続相手に関する情報を必要とする場合であっても、コンピューターやプログラムの変更が必要なくなる。すなわち、課題８が解決される。

本発明にかかるサーバーとクライアントの接続図 従来のＩＰマスカレード、ＮＡＰＴ、高機能ゲートウェイの接続図 ＩＰマスカレードが使用する変換テーブル ＮＡＰＴが使用する変換テーブル 本発明にかかるサーバーの概念図 本発明にかかるクライアントの概念図 スイッチャーが具備するフォワーダー一覧 レシーバーが具備するセレクター一覧 セレクターが具備する選択表 プレマスカレードが具備するプレマスカレード対応表 仮想回線にて使用されるチャンクのフォーマット 本発明にかかるサーバーのフローチャート スイッチャーのフローチャート ＴＣＰ／ＩＰを使用するデバイダーのフローチャートの前半 ＴＣＰ／ＩＰを使用するデバイダーのフローチャートの後半 ＵＤＰ／ＩＰを使用するデバイダーのフローチャート フォワーダーマスターのフローチャート 本発明にかかるクライアントのフローチャート レシーバーのフローチャート ＴＣＰ／ＩＰを使用するセレクターのフローチャート ＵＤＰ／ＩＰを使用するセレクターのフローチャートの前半 ＵＤＰ／ＩＰを使用するセレクターのフローチャートの後半 プレマスカレードのフローチャート

符号の説明

１０１ ＬＡＮ１３１に接続されているコンピューター
１０２ ＬＡＮ１３１に接続されているコンピューター
１０３ ＬＡＮ１３１に接続されているコンピューター
１０７ インターネット１３３に接続されているコンピューター
１０８ インターネット１３３に接続されているコンピューター
１１１ 本発明にかかるサーバー
１２１ 本発明にかかるクライアントであり、ＩＰマスカレードを実施されたゲートウェイ
１２２ ＩＰマスカレードを実施されたゲートウェイ
１３１ ＩＳＰの顧客の家庭にあるＬＡＮ
１３２ ＩＳＰのＬＡＮ
１３３ インターネット
２０１ インターネット
２０２ ローカル・ネットワーク
２１１ ローカルＩＰアドレスを割り当てられたコンピューター
２１６ グローバルＩＰアドレスを割り当てられたコンピューター
２２１ ローカル・ネットワーク２０２のデフォルト・ゲートウェイ
５１１ ＨＴＴＰ用のデバイダー
５１２ ＳＭＴＰ用のデバイダー
５２０ スイッチャー
５２１ フォワーダー
５２２ フォワーダー
５２３ フォワーダー
５３１ 仮想回線
５３２ 仮想回線
５３３ 仮想回線
５４１ フォワーダーマスター
６１１ レシーバー
６２１ ＨＴＴＰ用セレクター
６２２ ＦＴＰ用セレクター
６２３ ＳＭＴＰ用セレクター
６３１ プレマスカレード
１０１１ ＨＴＴＰサーバー・アプリケーション
１０１２ ＦＴＰサーバー・アプリケーション
１０１３ ＳＭＴＰサーバー・アプリケーション
１０２１ ＨＴＴＰサーバー・アプリケーション
１０２２ ＦＴＰサーバー・アプリケーション
１０２３ ＳＭＴＰサーバー・アプリケーション
１０３１ ＨＴＴＰサーバー・アプリケーション
１０３２ ＦＴＰサーバー・アプリケーション
１０３３ ＳＭＴＰサーバー・アプリケーション

Claims (8)

1. 一方から他方へコネクションを確立することを要求して仮想回線を構築することが可能な、異なるプロトコルあるいはノード識別子空間の識別子が使用されている２以上のネットワークそれぞれにあるサーバーとクライアントからなるシステムであって、以下の（１−１）ないし（１−１１）の特徴を持つ。
   （１−１）クライアントは、サーバーの存在するネットワークへコネクションを確立することを要求して仮想回線を構築することが可能な方のネットワークに存在する。
   （１−２）サーバーは、クライアントの存在するネットワークとは異なる方のネットワークに存在する。
   （１−３）サーバーは、クライアントからコネクションを確立することを要求され、クライアントとの間に仮想回線を構築する。
   （１−４）サーバーとクライアントの間に、（１−３）に記載の仮想回線以外に一つ以上の通信チャネルを構築する手段を持つ。
   （１−５）サーバーおよびクライアントは、（１−３）に記載の仮想回線においてチャンク（ｃｈｕｎｋ）によって通信を行う。
   （１−６）サーバーは、該サーバーの存在するネットワークに存在する一つ以上の他のコンピューターないしはクライアント・アプリケーションと、コネクションレスの通信、あるいは該他のコンピューターないしはクライアント・アプリケーションからコネクションを確立することを要求されて仮想回線を構築して通信、あるいはその両方の通信を行う。
   （１−７）（１−５）に記載のチャンクは、（１−６）に記載の通信をサーバーが識別する情報を具備する。
   （１−８）サーバーは（１−３）に記載の仮想回線によって、（１−６）に記載のコネクションを確立することを要求されていることをクライアントに送信する。
   （１−９）（１−５）に記載のチャンクは、（１−８）に記載のコネクションを確立することを要求されていることをクライアントに送信するチャンクであるか否かを識別する情報を具備する。
   （１−１０）サーバーは、（１−６）に記載の通信の内容を（１−４）に記載の通信チャネルに、必要なら変更を行って、転送する。
   （１−１１）サーバーは、（１−４）に記載の通信チャネルから受信した内容を、必要なら変更を行って、（１−６）に記載の通信内容として転送する。
2. 請求項１に記載のシステムであって、以下の（２−１）ないし（２−５）の特徴を持つ。
   （２−１）（１−３）に記載の仮想回線によって送受信される（１−５）に記載のチャンクが具備する（１−７）に記載の情報を識別子として多重化することで、（１−４）に記載の通信チャネルとする。
   （２−２）（１−５）に記載のチャンクは、（２−１）に記載の通信チャネルが送信を開始することを送信するチャンクであるか否かを識別する情報を具備する。
   （２−３）（２−１）に記載の通信チャネルは、（２−２）に記載の情報によって該通信チャネルが送信を開始することを送信するチャンクであるチャンクを送信ないしは受信することで通信チャネルとして利用可能となる。
   （２−４）（１−５）に記載のチャンクは、（２−１）に記載の通信チャネルが送信を終了することを送信するチャンクであるか否かを識別する情報を具備する。
   （２−５）（２−１）に記載の通信チャネルは、（２−４）に記載の情報によって該通信チャネルが送信を終了することを送信するチャンクであるチャンクを送信ないしは受信することで該通信チャネルにおける送信ないしは受信が行われなくなることを識別する。
3. 請求項１ないし２に記載のシステムであって、以下の（３−１）ないし（３−４）の特徴を持つ。
   （３−１）サーバーは（１−８）に記載の送信に先立って、新たな仮想回線を構築するためにクライアントからコネクションを確立することを要求されるための準備を行う。
   （３−２）サーバーは（１−８）に記載の送信における（１−５）に記載のチャンクによって、クライアントが（３−１）に記載の準備をされたコネクションを確立することを要求するために必要な識別子をクライアントに送信する。
   （３−３）クライアントは（３−２）に記載の識別子によって、サーバーとの間に新しい仮想回線を構築する。
   （３−４）（３−３）に記載の新しい仮想回線を（１−４）に記載の通信チャネルとする。
4. 請求項１ないし２ないし３に記載のシステムであって、以下の（４−１）ないし（４−４）の特徴を持つ。
   （４−１）（１−２）に記載のネットワークは、（１−３）に記載の仮想回線を同時に複数構築できるプロトコルを使用する。
   （４−２）サーバーは、複数のクライアントからの（１−３）に記載の要求に対して、それぞれに（１−３）に記載の仮想回線を構築する。
   （４−３）サーバーは、（１−６）に記載の通信を（４−２）に記載の複数のクライアントのいずれに転送するかを選択する選択手段を持つ。
   （４−４）サーバーは、（１−８）に記載の送信を（４−３）に記載の選択手段によって選択されたクライアントの仮想回線に送信する。
5. 請求項４に記載のシステムであって、以下の（５−１）ないし（５−２）の特徴を持つ。
   （５−１）サーバーは、（１−６）に記載の通信において受信した内容を、該通信において使用されているアプリケーション層のプロトコルに基づいて解析し、その解析結果によって（４−３）に記載の選択を行う。
   （５−２）（５−１）に記載の選択を行うに充分な内容が受信されるまで、（１−８）に記載の送信を行わない。
6. 請求項１ないし２ないし３ないし４ないし５に記載のシステムであって、以下の（６−１）ないし（６−６）の特徴を持つ。
   （６−１）クライアントは、（１−１）に記載のネットワークにおいて使用されているプロトコルによって使用される通信相手を識別する情報を一つ以上記録する記録手段を持つ。
   （６−２）（１−１）に記載のネットワークにおいて、クライアントと（６−１）に記載の記録手段によって記録されている情報によって識別される通信相手が、コネクションレスの通信、あるいはクライアントからコネクションを確立することを要求することで仮想回線を構築して通信、あるいはその両方を行う。
   （６−３）クライアントは、（６−２）に記載の通信を行う通信相手を、（６−１）に記載の記録手段によって記録された情報によって識別される通信相手のいずれかから選択する選択手段を持つ。
   （６−４）クライアントは、（１−４）に記載の通信チャネルによって送信されて来た内容を、必要なら変更を行ったあとで、（６−３）に記載の選択手段で選択した（６−１）に記載の記録手段によって記録されている情報によって識別される通信相手に（１−１）に記載のネットワークで使用されているプロトコルによって転送する。
   （６−５）クライアントは、（１−１）に記載のネットワークにおいて使用されているプロトコルによって受信した内容を、（１−４）に記載の通信チャネルのいずれによってサーバーに送信するか、ないしは、送信しないかを選択する選択手段を持つ。
   （６−６）クライアントは、（１−１）に記載のネットワークにおいて使用されているプロトコルによって受信した内容を、（６−５）に記載の手段によって選択された通信チャネルに、必要なら変更を行ったあとで、該通信チャネルに転送する。
7. 請求項６に記載のシステムであって、以下の（７−１）ないし（７−２）の特徴を持つ。
   （７−１）クライアントは（６−３）に記載の選択手段として、（６−４）に記載の送信されてきた内容を（１−４）に記載の通信チャネルにおける通信ないしは（１−６）に記載の通信において使用されているアプリケーション層のプロトコルに基づいて解析し、その解析結果によって（６−１）に記載の記録手段によって記録された情報によって識別される通信相手のいずれかから選択する。
   （７−２）クライアントは、（７−１）に記載の選択を行うに充分な内容が受信されるまで（６−４）に記載の転送を行わない。
8. 請求項６ないし７に記載のシステムであって、以下の（８−１）ないし（８−５）までの特徴を持つ。
   （８−１）（１−１）に記載のネットワークにおいて、（１−２）に記載のネットワークにおけるノード識別子によって一意にノードを識別できる対応手段が存在する。
   （８−２）（１−７）に記載の情報が、（１−６）に記載の通信における通信相手を識別する（１−２）に記載のネットワークにおいて使用されているプロトコルにおける識別子を具備する。
   （８−３）クライアントは、（１−１）に記載のネットワークにおけるデフォルト・ゲートウェイ（Ｄｅｆａｕｌｔ Ｇａｔｅｗａｙ）である。
   （８−４）クライアントは、（６−４）に記載の転送を行う際に、（８−２）に記載の識別子を（８−１）に記載の対応手段によって対応する（１−１）に記載のネットワークにおいて使用されているプロトコルにおける通信相手を識別する識別子に変換し、該変換された識別子によって識別される通信相手を該転送の送信元として転送する。
   （８−５）クライアントは、（６−６）に記載の転送を行う際に、受信した内容の送信先を示す（１−１）に記載のネットワークにおいて使用されているプロトコルにおける通信相手を識別する識別子を、（８−１）に記載の対応手段によって対応する（８−２）に記載の識別子に変換する。

Images