JP2001345854A - ネットワーク間のパケット通信方法及びシステム並びに装置 - Google Patents

Abstract

(57)【要約】 【課題】 ゲートウエイ装置を用いるネットワーク環境
で、アプリケーション層にセッション概念が有るプロト
コルを、トランスポート層にコネクション概念が無いプ
ロトコルを用いた場合でも、アプリケーション層のコマ
ンド内容を逐一文法解析することなくセッション確立及
び解消を検出して、パケットの中継処理を効率的に行う
パケット通信方法及びシステム並びに装置を提供する。 【解決手段】 端末装置１０は、プロトコルスタック１
３中に接続を記述できる階層（擬似接続層）を設け、セ
ッション開始時には最初に発行するパケット内にｂｅｇ
ｉｎフラグをセットし、セッション終了時には最後に発
行するパケット内にｆｉｎフラグをセットして、ゲート
ウエイ装置２０へセッションの開始及び終了を通知す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク間の
パケット通信方法及びシステム並びに装置に関し、より
特定的には、２つのネットワークを有する通信環境にお
いて、一方のネットワーク上に存在する端末装置と、他
方のネットワーク上に存在するサーバ装置との間のセッ
ションを、双方のネットワーク間を中継するゲートウエ
イ装置を介して確立させるためのパケット通信方法、及
び当該方法を用いたサーバ・クライアントシステム、並
びに各装置に関する。

【０００２】

【従来の技術】（ネットワークモデルの説明）プロトコ
ルを機能毎にモジュール化したモデルの例として、ＯＳ
Ｉ(Open Systems interconnection)の参照モデルが一般
に挙げられる。このＯＳＩの参照モデルは、通信機能を
７階層に分け、階層毎に標準的な機能モジュールを定義
しているものである。図１３は、ＯＳＩの７階層モデル
を示す図である。図１３において、第１層（物理層）
は、データを通信回線に送出するための電気的な変換や
機械的な作業を受け持つ。第２層（データリンク層）
は、通信相手との物理的な通信経路を確保し、通信経路
を流れるデータのエラー検出等を行う。第３層（ネット
ワーク層）は、通信相手へデータを届けるための通信経
路の選択や、通信経路内のアドレス（住所）の管理を行
う。第４層（トランスポート層）は、通信相手へ確実に
効率よくデータを届けるためのデータ圧縮、誤り訂正及
び再送制御等を行う。第５層（セッション層）は、通信
プログラム同士がデータの送受信を行うための仮想的な
経路（コネクション）の確立や解放を行う。第６層（プ
レゼンテーション層）は、第５層から受け取ったデータ
をユーザが分かり易い形式に変換したり、第７層から送
られてくるデータを通信に適した形式に変換する。第７
層（アプリケーション層）は、データ通信を利用した様
々なサービスを人間や他のプログラムへ提供する。

【０００３】（ＴＣＰ／ＩＰの説明）上記ＯＳＩの７階
層モデルと同様、ネットワークを階層化したモデルのも
う１つに、ＴＣＰ／ＩＰ(Transmission Control Protoc
ol／Internet Protocol)インターネットの階層モデルが
ある。図１４は、ＴＣＰ／ＩＰインターネットの階層モ
デルを示す図である。また、図１５は、ＯＳＩの７階層
モデルとＴＣＰ／ＩＰインターネットの階層モデルと
を、非常に大まかに対比した図である。図１４におい
て、ＴＣＰ／ＩＰインターネットの階層モデルは、４つ
の概念層から構成されており、各階層は次のように呼ば
れている。最上位階層のアプリケーション層は、アプリ
ケーションプログラムから送受信されるメッセージ列や
バイトストリームを、次の階層であるトランスポート層
に渡す。トランスポート層は、アプリケーションプログ
ラムと他のプログラムとの通信を司り、ＯＳＩの７階層
モデルでのおおよそ第４層及び第５層に相当する（図１
５）。このトランスポート層は、データがエラー無く順
番通りに到着することを保証し、データをパケット単位
に分割してインターネット層に渡す。インターネット層
は、トランスポート層から渡されたパケットをＩＰデー
タグラムにカプセル化し、適切なネットワークインタフ
ェース層に渡す。最下位階層のネットワークインタフェ
ース層は、ＩＰデータグラムをインターネット層から受
け取り、ハードウエアに渡す。

【０００４】以上述べた２つの一般的なネットワークプ
ロトコルの階層では、それぞれの階層においてそれぞれ
の機能が提供されており、送信側のある階層が出力する
データと、受信側の同一階層が受け取るデータとが、同
じになるように設計されている。例えば、図１６に示す
ホスト間の通信において、ホストＢのアプリケーション
層は、ホストＡのアプリケーション層から送出されたメ
ッセージと全く同一のメッセージを受け取れるように設
計されている。

【０００５】トランスポート層の代表的なプロトコルで
あるＴＣＰでは、ホスト間の通信においてデータが正し
く送受信できていることを検査するため、コネクション
を確立して通信を行っている。ＴＣＰは、このコネクシ
ョンを使用してデータの再送や確認応答等を通信するこ
とで、ホスト間のデータを正しく送受信できるように設
計されている。また、インターネット層の代表的なプロ
トコルであるＩＰでは、パケット単位でデータのやり取
りが行われる。ここで、パケットは個々に独立して送信
されるため、その順序や重複はチェックされないが、Ｉ
Ｐは、パケット単位では正確なフォーマットによるホス
ト間の送受信ができるように、設計されている。

【０００６】このように、各階層のプロトコルが、それ
ぞれの機能に基づいたデータの送受信を行うことで、最
終的にホスト間の通信が実現されている。

【０００７】（リテラルなスクリプト表記のプロトコル
の説明）さて、人が読んでそのままシーケンスの意味を
理解することが可能な、いわゆるリテラルなスクリプト
表記のプロトコルの例として、ＲＴＳＰ(Real Time Str
eaming Protocol)やＨＴＴＰ(Hyper Text Transfer Pro
tocol)等が挙げられる。一例として、図１７に、ＲＴＳ
Ｐにおけるプロトコル送受信の様子を模式的に示す。こ
の図１７の例では、端末装置からサーバ装置に対するＶ
ｉｄｅｏ及びＡｕｄｉｏストリームのセットアップから
再生までの一連の手順を示している。

【０００８】ＲＴＳＰは、ＩＰネットワーク上でストリ
ーム形式のデータ送信を効果的に行うために、開発が進
められているプロトコルである。ＲＴＳＰは、ＴＣＰ／
ＩＰインターネットの階層構造でいうアプリケーション
層のプロトコルであり、１つ又は複数の時間同期がされ
た連続メディアストリームを確立し、再生や停止等の制
御を行う。このＲＴＳＰは、連続したストリームデータ
自体を運ぶものではなく、マルチメディアサーバのため
のネットワーク遠隔制御用プロトコルである。ＲＴＳＰ
自体にはコネクションの概念が無く、一般的には下位階
層のトランスポート層においてサーバ装置と端末装置と
の間のコネクションを確立しておいてから、その上に識
別子によって一意に利用者を特定できる“セッション”
という論理的な接続状態を持つ。図１８は、コネクショ
ン及びセッション確立の様子を、ＴＣＰプロトコルスタ
ックの例を用いて模式的に示したものである。なお、Ｒ
ＴＳＰのセッション確立及び解消に関する詳細なシーケ
ンスについては、本発明の実施形態において後述する。

【０００９】上記ＲＴＳＰと同様に、アプリケーション
層のプロトコルとしてＨＴＴＰがある。ＨＴＴＰは、イ
ンターネットのＷＷＷ(World Wide Web)サービスにおい
て、ＷＷＷサーバからＷＷＷクライアントに対してＨＴ
ＭＬ(Hyper Text Markup Language)で記述されたドキュ
メントを送受信するための通信プロトコルである。この
ＨＴＴＰでは、ＨＴＭＬ文書やその文書に関連付けられ
ている画像、音声及び動画等のファイルを、表現形式等
の情報を含めてやり取りできる。

【００１０】ＨＴＴＰは、リクエストとレスポンスとか
らなる非常に単純なプロトコルで、リクエスト及びレス
ポンスがそれぞれ独立した通信の単位となる。まず、Ｗ
ＷＷクライアントは、リクエストとして表示したいＷＷ
ＷページのＵＲＬ(Uniform Resource Locators) のパス
名を送信する。これに対し、ＷＷＷサーバは、自分が持
つＨＴＭＬ文書をＷＷＷクライアントへ送信する。例え
ば、あるＷＷＷサーバにアクセスし、接続が完了したと
ころで、ＷＷＷクライアントがコマンド「ＧＥＴ／」を
送信すると、 ＜ＨＥＡＤ＞ ＜ＴＩＴＬＥ＞ ．．．．． ＜／ＴＩＴＬＥ＞ ： ＜／ＢＯＤＹ＞ というように、ＷＷＷサーバからの応答として、ＨＴＭ
Ｌで記述されたデータが返ってくる。

【００１１】このように、ＨＴＴＰでも、ＲＴＳＰと同
様にデータ取得の度にＷＷＷサーバに論理接続し、デー
タの送受信が終わると論理接続を切断するというセッシ
ョンの概念で通信を行っている。

【００１２】

【発明が解決しようとする課題】ところで、サーバ装置
と端末装置とがそれぞれ異なるネットワーク上に存在す
る場合、双方の装置を中継するために一般にゲートウエ
イ装置が用いられる。ゲートウエイ装置を用いて構築さ
れたシステムの一例を、図１９に示す。図１９のシステ
ムにおいて、コネクションの概念が無くセッションとい
う論理的な接続状態を持つＲＴＳＰ等が、アプリケーシ
ョン層のプロトコルに用いられる場合、ゲートウエイ装
置は、下位階層のトランスポート層において行われる装
置間のコネクションの確立及び消滅を検出することによ
り、同時にセッションの確立及び消滅を検出（認識）す
ることができた。

【００１３】しかしながら、通信系の諸制約によって、
アプリケーション層にセッションの概念が有るＲＴＳＰ
等のプロトコルを、トランスポート層にコネクションの
概念が無いプロトコル（例えば、ＵＤＰ(User Datagram
Protocol)）を用いる場合が考えられる。この場合、装
置間のコネクションが存在しないので、図１９に示すゲ
ートウエイ装置は、セッションの確立及び消滅を知るた
めに、ＲＴＳＰ等のコマンド内容を逐一文法解析する必
要が生じる。また、上述したように、このＲＴＳＰ等の
プロトコルには、コマンドシーケンスの記述にリテラル
なスクリプト表記が用いられているため、人間が読んで
理解するには便利である。しかし、コンピュータがＲＴ
ＳＰ等のプロトコルを解釈するためには、ＬＥＸ等によ
るバイナリ化や文字列比較等のＣＰＵに大きな負荷がか
かる処理を数多く行わなければならない。このような処
理の実行は、通信効率を低下させる原因となっている。

【００１４】それ故、本発明の目的は、ゲートウエイ装
置を用いるネットワーク環境において、アプリケーショ
ン層にセッションの概念が有るプロトコルを、トランス
ポート層にコネクションの概念が無いプロトコルを用い
た場合でも、アプリケーション層のコマンド内容を逐一
文法解析することなくセッションの確立及び解消を検出
でき、パケットの中継処理を効率的に行うことができる
パケット通信方法及びシステム並びに装置を提供するこ
とである。

【００１５】

【課題を解決するための手段および発明の効果】第１の
発明は、第１のネットワークに接続された１つ以上の端
末装置と、第２のネットワークに接続された１つ以上の
サーバ装置と、当該第１及び第２のネットワークに接続
され両装置間のパケット通信を中継するゲートウエイ装
置とからなるサーバ・クライアントシステムにおける、
パケット通信方法であって、端末装置とサーバ装置との
間に、階層化された通信プロトコルにおけるメッセージ
送受信のための論理的な接続状態であるセッションを確
立させる場合、端末装置が、最初に発行する先頭パケッ
トを、当該先頭パケット中の特定部分にセッション開始
を示すｂｅｇｉｎフラグをセットして、ゲートウエイ装
置へ送信し、ゲートウエイ装置が、受信した先頭パケッ
ト中のｂｅｇｉｎフラグを検出することでセッション開
始を判断し、サーバ装置との通信経路を確立して当該先
頭パケットをサーバ装置へ転送し、端末装置とサーバ装
置との間に確立されたセッションを解消させる場合、端
末装置が、最後に発行する最終パケットを、当該最終パ
ケット中の特定部分にセッション終了を示すｆｉｎフラ
グをセットして、ゲートウエイ装置へ送信し、ゲートウ
エイ装置が、受信した最終パケット中のｆｉｎフラグを
検出することでセッション終了を判断し、サーバ装置か
ら最終パケットに対する応答を受信した後に、セッショ
ンを解消させることを特徴とする。

【００１６】上記のように、第１の発明によれば、端末
装置とサーバ装置との間にセッションを確立する場合、
端末装置から最初に発行されるパケットにｂｅｇｉｎフ
ラグを付加して、ゲートウエイ装置へセッション開始を
通知する。また、すでに確立されているセッションを終
了する場合、端末装置から最後に発行されるパケットに
ｆｉｎフラグを付加して、ゲートウエイ装置へセッショ
ン終了を通知する。これにより、ゲートウエイ装置は、
アプリケーション層にセッションの概念が有るプロトコ
ルを、トランスポート層にコネクションの概念が無いプ
ロトコルを用いた場合でも、アプリケーション層のコマ
ンド内容を逐一文法解析することなくセッションの確立
及び解消を検出でき、パケットの中継処理を効率的に行
うことができる。

【００１７】第２の発明は、第１のネットワークに接続
された１つ以上の端末装置と、第２のネットワークに接
続された１つ以上のサーバ装置と、当該第１及び第２の
ネットワークに接続され両装置間のパケット通信を中継
するゲートウエイ装置とからなるサーバ・クライアント
システムにおける、パケット通信方法であって、端末装
置とサーバ装置との間に、階層化された通信プロトコル
におけるメッセージ送受信のための論理的な接続状態で
あるセッションを確立させる場合、端末装置が、最初に
発行する先頭パケットを、当該先頭パケット中の特定部
分にセッション開始を示すｂｅｇｉｎフラグをセットし
て、ゲートウエイ装置へ送信し、ゲートウエイ装置が、
受信した先頭パケット中のｂｅｇｉｎフラグを検出する
ことでセッション開始を判断し、サーバ装置との通信経
路を確立して当該先頭パケットをサーバ装置へ転送し、
端末装置とサーバ装置との間に確立されたセッションを
解消させる場合、端末装置が最後に発行する最終パケッ
トの受信に基づいて、サーバ装置が、当該最終パケット
に対する応答パケットを、当該応答パケット中の特定部
分にセッション終了を示すｆｉｎフラグをセットして、
ゲートウエイ装置へ送信し、ゲートウエイ装置が、受信
した応答パケット中のｆｉｎフラグを検出することでセ
ッション終了を判断し、セッションを解消させることを
特徴とする。

【００１８】上記のように、第２の発明によれば、端末
装置とサーバ装置との間にセッションを確立する場合、
端末装置から最初に発行されるパケットにｂｅｇｉｎフ
ラグを付加して、ゲートウエイ装置へセッション開始を
通知する。また、すでに確立されているセッションを終
了する場合、サーバ装置から最後に発行されるパケット
にｆｉｎフラグを付加して、ゲートウエイ装置へセッシ
ョン終了を通知する。これにより、ゲートウエイ装置
は、アプリケーション層にセッションの概念が有るプロ
トコルを、トランスポート層にコネクションの概念が無
いプロトコルを用いた場合でも、アプリケーション層の
コマンド内容を逐一文法解析することなくセッションの
確立及び解消を検出でき、パケットの中継処理を効率的
に行うことができる。

【００１９】第３の発明は、第１及び第２の発明に従属
する発明であって、ゲートウエイ装置が、確立した通信
経路に関する情報を保持し、先頭パケット以降のパケッ
ト通信を当該情報に従って行うことを特徴とする。

【００２０】第４の発明は、第３の発明に従属する発明
であって、ゲートウエイ装置は、通信経路に関する情報
を削除することでセッションを解消させることを特徴と
する。

【００２１】上記のように、第３及び第４の発明によれ
ば、ゲートウエイ装置では、ｂｅｇｉｎフラグの検出に
基づいて端末装置とサーバ装置との間のセッションを確
立させると共に、そのセッションの通信経路に関する情
報を保持しておき、ｆｉｎフラグの検出に基づいてその
情報を抹消させてセッションを解消させる。これによ
り、先頭パケット以降のパケット通信を簡単かつ高速に
実行させることができる。

【００２２】第５の発明は、第１の発明に従属する発明
であって、第１のネットワーク上におけるセッション層
の通信プロトコルが、リテラルなスクリプト表記のプロ
トコルであることを特徴とする。

【００２３】第６の発明は、第２の発明に従属する発明
であって、第１及び第２のネットワーク上における双方
のセッション層の通信プロトコルが、共にリテラルなス
クリプト表記のプロトコルであることを特徴とする。

【００２４】この第５及び第６の発明のような通信プロ
トコルである場合に、第１及び第２の発明によるパケッ
ト通信方法を用いることによって、最も効果を発揮させ
ることができる。

【００２５】第７の発明は、第１のネットワークに接続
された１つ以上の端末装置と、第２のネットワークに接
続された１つ以上のサーバ装置と、当該第１及び第２の
ネットワークに接続され両装置間のパケット通信を中継
するゲートウエイ装置とからなるサーバ・クライアント
システムであって、サーバ装置との間に、階層化された
通信プロトコルにおけるメッセージ送受信のための論理
的な接続状態であるセッションを確立させる場合、最初
に発行する先頭パケット中の特定部分にセッション開始
を示すｂｅｇｉｎフラグをセットし、サーバ装置との間
に確立されたセッションを解消させる場合、最後に発行
する最終パケット中の特定部分にセッション終了を示す
ｆｉｎフラグをセットして、ゲートウエイ装置へ当該パ
ケットを送信する端末装置と、先頭パケット中のｂｅｇ
ｉｎフラグを検出することでセッション開始を判断し
て、サーバ装置との通信経路を確立して当該先頭パケッ
トをサーバ装置へ転送し、最終パケット中のｆｉｎフラ
グを検出することでセッション終了を判断して、サーバ
装置から最終パケットに対する応答を受信した後に、セ
ッションを解消させるゲートウエイ装置とを備える。

【００２６】第８の発明は、第１のネットワークに接続
された１つ以上の端末装置と、第２のネットワークに接
続された１つ以上のサーバ装置と、当該第１及び第２の
ネットワークに接続され両装置間のパケット通信を中継
するゲートウエイ装置とからなるサーバ・クライアント
システムであって、サーバ装置との間に、階層化された
通信プロトコルにおけるメッセージ送受信のための論理
的な接続状態であるセッションを確立させる場合、最初
に発行する先頭パケット中の特定部分にセッション開始
を示すｂｅｇｉｎフラグをセットして、ゲートウエイ装
置へ当該パケットを送信する端末装置と、端末装置との
間に確立されたセッションを解消させる場合、端末装置
が最後に発行する最終パケットの受信に基づいて、当該
最終パケットに対する応答パケット中の特定部分にセッ
ション終了を示すｆｉｎフラグをセットして、ゲートウ
エイ装置へ当該パケットを送信するサーバ装置と、先頭
パケット中のｂｅｇｉｎフラグを検出することでセッシ
ョン開始を判断して、サーバ装置との通信経路を確立し
て当該先頭パケットをサーバ装置へ転送し、応答パケッ
ト中のｆｉｎフラグを検出することでセッション終了を
判断して、セッションを解消させるゲートウエイ装置と
を備える。

【００２７】第９の発明は、第２のネットワークによっ
て１つ以上のサーバ装置と接続されたゲートウエイ装置
に、第１のネットワークを介して接続される端末装置で
あって、サーバ装置との間に、階層化された通信プロト
コルにおけるメッセージ送受信のための論理的な接続状
態であるセッションを確立させる場合、最初に発行する
先頭パケット中の特定部分にセッション開始を示すｂｅ
ｇｉｎフラグをセットする設定部と、ｂｅｇｉｎフラグ
をセットした先頭パケットをゲートウエイ装置へ送信す
る送信部とを備える。

【００２８】第１０の発明は、第２のネットワークによ
って１つ以上のサーバ装置と接続されたゲートウエイ装
置に、第１のネットワークを介して接続される端末装置
であって、サーバ装置との間に、階層化された通信プロ
トコルにおけるメッセージ送受信のための論理的な接続
状態であるセッションを確立させる場合、最初に発行す
る先頭パケット中の特定部分にセッション開始を示すｂ
ｅｇｉｎフラグをセットする設定部と、サーバ装置との
間に確立されたセッションを解消させる場合、最後に発
行する最終パケット中の特定部分にセッション終了を示
すｆｉｎフラグをセットする設定部と、ｂｅｇｉｎフラ
グをセットした先頭パケット又はｆｉｎフラグをセット
した最終パケットを、ゲートウエイ装置へ送信する送信
部とを備える。

【００２９】第１１の発明は、第１のネットワークによ
って１つ以上の端末装置と接続されたゲートウエイ装置
に、第２のネットワークを介して接続されるサーバ装置
であって、端末装置との間に確立されたセッションを解
消させる場合、端末装置が最後に発行する最終パケット
の受信に基づいて、当該最終パケットに対する応答パケ
ット中の特定部分にセッション終了を示すｆｉｎフラグ
をセットする設定部と、ｆｉｎフラグをセットした応答
パケットを、ゲートウエイ装置へ送信する送信部とを備
える。

【００３０】第１２の発明は、第１のネットワークを介
して１つ以上の端末装置と、第２のネットワークを介し
て１つ以上のサーバ装置とに接続されるゲートウエイ装
置であって、端末装置から送信されるパケット中のセッ
ション開始を示すフラグを検出することでセッション開
始を判断して、サーバ装置との通信経路を確立して当該
パケットをサーバ装置へ転送する送信部と、パケット以
降のパケット通信を、確立した通信経路に関する情報に
従って行うために、当該情報を保持する記憶部と、端末
装置又はサーバ装置から送信されるパケット中のセッシ
ョン終了を示すフラグを検出することでセッション終了
を判断して、対応するパケット送信を完了した後に通信
経路に関する情報を削除することでセッションを解消さ
せる処理部とを備える。

【００３１】第１３の発明は、第９及び第１０の発明に
従属する発明であって、第１のネットワーク上における
セッション層の通信プロトコルが、リテラルなスクリプ
ト表記のプロトコルであることを特徴とする。

【００３２】第１４の発明は、第１１の発明に従属する
発明であって、第２のネットワーク上におけるセッショ
ン層の通信プロトコルが、リテラルなスクリプト表記の
プロトコルであることを特徴とする。

【００３３】第１５の発明は、第１２の発明に従属する
発明であって、第１のネットワーク上における又は第１
及び第２のネットワーク上における双方のセッション層
の通信プロトコルが、共にリテラルなスクリプト表記の
プロトコルであることを特徴とする。

【００３４】上記のように、第７〜第１５の発明は、第
１〜第６の発明によるパケット通信方法をサーバ・クラ
イアントシステム、端末装置、サーバ装置及びゲートウ
エイ装置に適用させた発明である。これにより、第１〜
第６の発明で述べた本発明の有用な効果を奏するサーバ
・クライアントシステム、端末装置、サーバ装置及びゲ
ートウエイ装置を実現させることができる。

【００３５】

【発明の実施の形態】以下、本発明が提供するパケット
通信方法及びシステム並びに装置を、ゲートウエイ装置
を介して端末装置とサーバ装置との通信が行われるサー
バ・クライアントシステムにおいて、アプリケーション
層にリテラルなスクリプト表記のプロトコルであるＲＴ
ＳＰを用いた場合を一例に挙げて、説明する。なお、ア
プリケーション層には、別のリテラルなスクリプト表記
のプロトコルであるＨＴＴＰや、メール制御プロトコル
のＩＭＡＰ４等を用いてもよい。

【００３６】（第１の実施形態）図１は、本発明の第１
の実施形態に係るサーバ・クライアントシステムの構成
を示す図である。なお、図１では、システムのネットワ
ーク接続及びプロトコルスタックを模式的に示してい
る。また、図２は、図１のアドレス変換用参照テーブル
２２を用いて第１のネットワーク５１と第２のネットワ
ーク５２との間の通信経路を確立させた状態を模式的に
示す図である。

【００３７】図１において、第１の実施形態に係るサー
バ・クライアントシステムは、複数の端末装置１０と、
ゲートウエイ装置２０と、複数のサーバ装置３０と、フ
ァイルシステム４０とを備える。第１のネットワーク５
１は、ＵＤＰによるコネクションレス型ネットワークで
あり、各端末装置１０とゲートウエイ装置２０とを接続
する。この第１のネットワーク５１には、ＵＤＰ上の実
装である以外にも、携帯電話で使用される他のコネクシ
ョンレス型ネットワーク（例えば、ＷＤＰやＷＴＰ）を
用いることが可能である。第２のネットワーク５２は、
ＴＣＰによるコネクション型ネットワークであり、ゲー
トウエイ装置２０と各サーバ装置３０とを接続する。

【００３８】端末装置１０は、制御プログラムを格納し
たメモリデバイス１１と、ＣＰＵ１２と、プロトコルス
タック１３と、ソケット１４とからなる。また、プロト
コルスタック１３の擬似接続層には、セッション開始を
知らせるために通信の先頭パケットに付加するフラグ
（以下、ｂｅｇｉｎフラグという）１５及びセッション
終了を知らせるために通信の最終パケットに付加するフ
ラグ（以下、ｆｉｎフラグという）１６を、格納する領
域が確保されている。この擬似接続層とは、ｂｅｇｉｎ
フラグ１５やｆｉｎフラグ１６を配置するために、ＲＴ
ＳＰコマンド格納用のペイロードを一部拡張した領域と
もみなすことができるものである。ゲートウエイ装置２
０は、プロトコルスタック２１と、パケット中継時にＵ
ＤＰ−ＴＣＰ変換を行うためのアドレス変換用参照テー
ブル２２と、ＴＣＰコネクション確立のためのＴＣＰソ
ケット生成部２３と、第１のネットワーク５１上におけ
るポート番号を持ったソケット２４と、セッション確立
毎に第２のネットワーク５２上で生成されるソケット２
５とからなる。サーバ装置３０は、プロトコルスタック
３１と、第２のネットワーク５２上におけるポート番号
を持ったソケット３２と、コンテンツデータが格納され
たファイルシステム４０から所望のコンテンツデータを
送出するためのパケット生成用プロトコルスタック３３
とからなる。

【００３９】以下、図３〜図５を用い、第１の実施形態
に係るサーバ・クライアントシステムにおいて、複数の
端末装置１０内の１つが、複数のサーバ装置３０内の１
つとＲＴＳＰのセッションを確立し、セッションを終了
するまでの一連のシーケンスを説明する。

【００４０】図３は、端末装置１０がＳＥＴＵＰコマン
ドを発行して、サーバ装置３０とセッションを確立する
場合の一例を示すシーケンス図である。図３において、
ＳＥＴＵＰコマンド発行時の端末装置１０の内部動作と
して、ＣＰＵ１２が、プロトコルスタック１３のＲＴＳ
Ｐ層にＳＥＴＵＰのスクリプトを記入すると同時に、擬
似接続層にセッション開始を示すｂｅｇｉｎフラグ１５
をセットする。この状態で端末装置１０は、予め定めら
れたポート番号（端末装置の設計に依存する固定値）の
ソケット１４から、ゲートウエイ装置２０の予め定めら
れたポート番号（通信規約によって定まる。ＲＴＳＰの
場合は、一般的に５５４番とされている）のソケット２
４へ、ｂｅｇｉｎフラグ付きのＳＥＴＵＰコマンドのパ
ケット（先頭パケット）を転送する。なお、端末装置１
０とゲートウエイ装置２０との間は、プロトコルスタッ
ク１３及び２１の再送処理層の働きによって、第１のネ
ットワーク５１でのパケットロスを補償する仕組みが実
装されているものとする。

【００４１】ｂｅｇｉｎフラグ付きのＳＥＴＵＰコマン
ドのパケットを受理したゲートウエイ装置２０は、ＲＴ
ＳＰ層の“ＳＥＴＵＰ”というコマンドを文法解釈する
ことなく、ｂｅｇｉｎフラグによってセッションの開始
を検出し、受信したパケットをサーバ装置３０へ転送す
るための通信経路確立の動作に入る。この際、ゲートウ
エイ装置２０は、ＴＣＰソケット生成部２３を用い、サ
ーバ装置３０のＩＰアドレスの選択及び新たなＴＣＰソ
ケット２５の生成、さらに生成したＴＣＰソケット２５
とサーバ装置３０の予め定められたポート番号（ＲＴＳ
Ｐの場合は、一般的に５５４番）のソケット３２とのコ
ネクション確立を行う。そして、ゲートウエイ装置２０
は、確立したＴＣＰコネクション（ソケットのファイル
ディスクリプタ番号）と端末装置１０のＩＰアドレス
（以下、端末ＩＰアドレスと記す）とを一組として、そ
のアドレス変換パスをアドレス変換用参照テーブル２２
に登録する（図２）。この登録されたアドレス変換パス
（以下、エントリと記す）は、端末ＩＰアドレスからも
ＴＣＰソケットからも検索することが可能である。

【００４２】本実施形態では、１つの端末装置１０がサ
ーバ装置３０との間に確立するセッションが１つだけで
ある場合を想定しているので、セッションとエントリと
の対応は１対１である。なお、１つの端末装置１０が２
つ以上のセッションを確立する場合には、ゲートウエイ
装置２０のアドレス変換用参照テーブル２２にセッショ
ン毎のエントリを用意し、端末装置１０の擬似接続層に
もセッション毎にセッション識別用のフィールドを設け
ればよい。また、本実施形態では、端末ＩＰアドレスと
ＴＣＰソケットのみをエントリとして登録する例を示し
たが、それ以外の情報、例えばポート番号、端末装置１
０が電話機の場合は電話番号という付加情報も、一緒に
登録してもよい。

【００４３】以上のようにアドレス変換パスが生成され
ると、このＴＣＰコネクションを通じてサーバ装置３０
へＳＥＴＵＰコマンドのパケットが転送される。このパ
ケットを受け取ったサーバ装置３０は、ＵＲＬの取得及
びストリーム送出の準備を行った後、プロトコルスタッ
ク３１のＲＴＳＰ層にＯＫアクノリッジを記述したパケ
ット（ＯＫパケット）を端末装置１０に向けて返送す
る。このＯＫパケットは、上述のＴＣＰコネクションを
通じてゲートウエイ装置２０に送られる。ゲートウエイ
装置２０内では、アドレス変換用参照テーブル２２をＴ
ＣＰソケット２５で検索することにより、端末ＩＰアド
レスが抽出される。その後、ゲートウエイ装置２０は、
この端末ＩＰアドレス及び端末装置のポート番号を用い
て、プロトコルスタック２１に示されるアドレス変換を
行い、端末装置１０へＯＫパケットを転送する。これに
より、ＳＥＴＵＰコマンドのシーケンスが完了する。

【００４４】図４は、端末装置１０がＳＥＴＵＰや後述
のＴＥＡＲＤＯＷＮを除くコマンド、例えばＰＬＡＹ等
のコマンドを発行した場合のパケット転送の一例を示す
シーケンス図である。図４に示すように、上述したＳＥ
ＴＵＰコマンドの処理（図３）においてすでにアドレス
変換パスが決まっているので、ゲートウエイ装置２０で
は、アドレス変換用参照テーブル２２の検索（端末ＩＰ
アドレスに基づくＴＣＰソケットの検索）のみで素早く
アドレス変換され、ＰＬＡＹコマンド等のパケットが端
末装置１０からサーバ装置３０へ転送されることにな
る。

【００４５】図５は、端末装置１０がＴＥＡＲＤＯＷＮ
コマンドを発行して、サーバ装置３０との間に確立して
いるセッションを終了する場合の一例を示すシーケンス
図である。図５において、ＴＥＡＲＤＯＷＮコマンド発
行時の端末装置１０の内部動作として、ＣＰＵ１２が、
プロトコルスタック１３のＲＴＳＰ層にＴＥＡＲＤＯＷ
Ｎのスクリプトを記入すると同時に、擬似接続層にセッ
ション終了を示すｆｉｎフラグ１６をセットする。この
状態で端末装置１０は、予め定められたポート番号のソ
ケット１４からゲートウエイ装置２０のポート番号のソ
ケット２４へ、ｆｉｎフラグ付きのＴＥＡＲＤＯＷＮコ
マンドのパケット（最終パケット）を転送する。

【００４６】ｆｉｎフラグ付きのＴＥＡＲＤＯＷＮコマ
ンドのパケットを受理したゲートウエイ装置２０は、Ｒ
ＴＳＰ層の“ＴＥＡＲＤＯＷＮ”というコマンドを文法
解釈することなく、ｆｉｎフラグによってセッションの
終了を検出し、アドレス変換用参照テーブル２２に登録
されている当該セッションのエントリを抹消するため
に、終了マークを付加する（図２）。この終了マークの
付加は、フラグのＯＮ／ＯＦＦ等によって行えばよい。
その後、ＴＥＡＲＤＯＷＮコマンドのパケットは、アド
レス変換用参照テーブル２２に登録されているエントリ
に従い、本セッション用のＴＣＰコネクションを通じて
サーバ装置３０へ転送される。そして、このパケットを
受け取ったサーバ装置３０は、ストリーム送出の停止処
理を行った後、プロトコルスタック３１のＲＴＳＰ層に
ＯＫアクノリッジを記述したパケット（ＯＫパケット）
を端末装置１０に向けて返送する。

【００４７】このＯＫのパケットは、上述のＴＣＰコネ
クションを通じてゲートウエイ装置２０に送られる。ゲ
ートウエイ装置２０内では、アドレス変換用参照テーブ
ル２２をＴＣＰソケット２５で検索することにより、端
末ＩＰアドレスが抽出される。その際、アドレス変換パ
スのエントリには、終了マークが付加されているので、
この時点でアドレス変換用参照テーブル２２からこのエ
ントリのデータが抹消される。その後、ゲートウエイ装
置２０は、この端末ＩＰアドレス及び端末装置のポート
番号を用いてアドレス変換を行って、端末装置１０へＯ
Ｋパケットを転送する。これにより、ＴＥＡＲＤＯＷＮ
コマンドのシーケンスが完了すると同時に、端末装置１
０とサーバ装置３０との間のセッションが解消される。

【００４８】図６は、図３〜図５を用いてすでに説明し
たパケット通信方法を実現するための、ゲートウエイ装
置２０の動作の一例を示すフローチャートである。ま
ず、ゲートウエイ装置２０は、何らかのパケットを受信
したか否かを判断し（ステップＳ６０１）、受信した場
合には、そのパケットが端末装置１０又はサーバ装置３
０のどちらから送信されたパケットかを判断する（ステ
ップＳ６０２）。このステップＳ６０２において端末装
置１０から送信されたパケットであると判断した場合、
ゲートウエイ装置２０は、このパケットにｂｅｇｉｎフ
ラグ又はｆｉｎフラグが付加されているか否かを確認す
る（ステップＳ６０３，Ｓ６０４）。この確認の結果、
ｂｅｇｉｎフラグが付加されている場合、ゲートウエイ
装置２０は、サーバ装置３０との間に新たなＴＣＰコネ
クションを生成し（ステップＳ６０５）、この生成した
ＴＣＰコネクションと端末装置１０の端末ＩＰアドレス
とを、アドレス変換用参照テーブル２２に新たなエント
リとして登録する（ステップＳ６０６）。そして、ゲー
トウエイ装置２０は、アドレス変換用参照テーブル２２
に登録した本セッションのエントリに従ってアドレス変
換を行い、受信したパケットをサーバ装置３０へ転送す
る（ステップＳ６０８）。また、ｆｉｎフラグが付加さ
れている場合、ゲートウエイ装置２０は、アドレス変換
用参照テーブル２２にすでに登録されている本セッショ
ンのエントリに終了マークを付加すると共に（ステップ
Ｓ６０７）、当該エントリに従ってアドレス変換を行
い、受信したパケットをサーバ装置３０へ転送する（ス
テップＳ６０８）。一方、ｂｅｇｉｎフラグ又はｆｉｎ
フラグのいずれも付加されていない場合、ゲートウエイ
装置２０は、アドレス変換用参照テーブル２２にすでに
登録されている本セッションのエントリに従ってアドレ
ス変換を行い、受信したパケットをサーバ装置３０へ転
送する（ステップＳ６０８）。

【００４９】一方、上記ステップＳ６０２においてサー
バ装置３０から送信されたパケットであると判断した場
合、ゲートウエイ装置２０は、アドレス変換用参照テー
ブル２２にすでに登録されているエントリに従ってアド
レス変換を行い、受信したパケットを端末装置１０へ転
送する（ステップＳ６０９）。このとき、ゲートウエイ
装置２０は、本セッションのエントリに終了マークが付
加されているか否かを判断し（ステップＳ６１０）、終
了マークが付加されている場合には、登録されているエ
ントリを抹消して本セッションを解消させる（ステップ
Ｓ６１１）。

【００５０】なお、当業者には周知のように一般に、ゲ
ートウエイ装置２０には、確立されるセッション毎にパ
ケット転送を専任する中継スレッドが構築される。従っ
て、実際には、ゲートウエイ装置２０は、対応する中継
スレッドへ端末ＩＰアドレスの情報及び受信したバッフ
ァのポインタと共にシグナルを発行することで、端末装
置１０又はサーバ装置３０へのパケット転送処理を促す
ことを行う（ステップＳ６０８、Ｓ６０９）。また、ソ
ケットの判別及びパケットの発信元確認は、一般にｓｅ
ｌｅｃｔ関数やｓｏｃｋｏｐｔ関数等を用いて行われ
る。

【００５１】以上のように、本発明の第１の実施形態に
係るサーバ・クライアントシステムによれば、端末装置
とサーバ装置との間にセッションを確立する場合、端末
装置から最初に発行されるパケットにｂｅｇｉｎフラグ
を付加して、ゲートウエイ装置へセッション開始を通知
する。また、すでに確立されているセッションを終了す
る場合、端末装置から最後に発行されるパケットにｆｉ
ｎフラグを付加して、ゲートウエイ装置へセッション終
了を通知する。そして、ゲートウエイ装置では、ｂｅｇ
ｉｎフラグの検出に基づいて端末装置とサーバ装置との
間のセッションを確立させると共に、そのセッションに
関する転送経路情報（エントリ）を保持しておき、ｆｉ
ｎフラグの検出に基づいてエントリを抹消させてセッシ
ョンを解消させる。これにより、ゲートウエイ装置は、
アプリケーション層にセッションの概念が有るプロトコ
ルを、トランスポート層にコネクションの概念が無いプ
ロトコルを用いた場合でも、アプリケーション層のコマ
ンド内容を逐一文法解析することなくセッションの確立
及び解消を検出でき、パケットの中継処理を効率的に行
うことができる。

【００５２】（第２の実施形態）図７は、本発明の第２
の実施形態に係るサーバ・クライアントシステムの構成
を示す図である。なお、図７では、システムのネットワ
ーク接続及びプロトコルスタックを模式的に示してい
る。また、図８は、図７のアドレス変換用参照テーブル
７２を用いて第１のネットワーク１０１と第２のネット
ワーク１０２との間の通信経路を確立させた状態を模式
的に示す図である。

【００５３】図７において、第２の実施形態に係るサー
バ・クライアントシステムは、複数の端末装置６０と、
ゲートウエイ装置７０と、複数のサーバ装置８０と、フ
ァイルシステム９０とを備える。第１のネットワーク１
０１及び第２のネットワーク１０２は、共にＵＤＰによ
るコネクションレス型ネットワークであり、各端末装置
６０とゲートウエイ装置７０とを、ゲートウエイ装置７
０と各サーバ装置８０とをそれぞれ接続する。この第１
のネットワーク１０１及び第２のネットワーク１０２に
は、ＵＤＰ上の実装である以外にも、携帯電話で使用さ
れる他のコネクションレス型ネットワーク（例えば、Ｗ
ＤＰやＷＴＰ）を用いることが可能である。

【００５４】端末装置６０は、制御プログラムを格納し
たメモリデバイス６１と、ＣＰＵ６２と、プロトコルス
タック６３と、ソケット６４とからなる。また、プロト
コルスタック６３の擬似接続層には、セッション開始を
知らせるために通信の先頭パケットに付加するｂｅｇｉ
ｎフラグ６５を格納する領域が確保されている。この擬
似接続層とは、ｂｅｇｉｎフラグ６５を配置するため
に、ＲＴＳＰコマンド格納用のペイロードを一部拡張し
た領域ともみなすことができるものである。ゲートウエ
イ装置７０は、プロトコルスタック７１と、パケット中
継時にＵＤＰ−ＵＤＰ変換を行うためのアドレス変換用
参照テーブル７２と、ＵＤＰソケット生成部７３と、第
１のネットワーク１０１上におけるポート番号を持った
ソケット７４と、セッション確立毎に第２のネットワー
ク１０２上で生成されるソケット７５とからなる。サー
バ装置８０は、制御プログラムを格納したメモリデバイ
ス８４と、ＣＰＵ８５と、プロトコルスタック８１と、
第２のネットワーク１０２上におけるポート番号を持っ
たソケット８２と、コンテンツデータが格納されたファ
イルシステム９０から所望のコンテンツデータを送出す
るためのパケット生成用プロトコルスタック８３とから
なる。また、プロトコルスタック８１の擬似接続層に
は、セッション終了を知らせるために通信の最終パケッ
トに付加するｆｉｎフラグ８６を格納する領域が確保さ
れている。この擬似接続層とは、ｆｉｎフラグ８６を配
置するために、ＲＴＳＰコマンド格納用のペイロードを
一部拡張した領域ともみなすことができるものである。

【００５５】以下、図９〜図１１を用い、第２の実施形
態に係るサーバ・クライアントシステムにおいて、複数
の端末装置６０内の１つが、複数のサーバ装置８０内の
１つとＲＴＳＰのセッションを確立し、セッションを終
了するまでの一連のシーケンスを説明する。

【００５６】図９は、端末装置６０がＳＥＴＵＰコマン
ドを発行して、サーバ装置８０とセッションを確立する
場合の一例を示すシーケンス図である。図９において、
ＳＥＴＵＰコマンド発行時の端末装置６０の内部動作と
して、ＣＰＵ６２が、プロトコルスタック６３のＲＴＳ
Ｐ層にＳＥＴＵＰのスクリプトを記入すると同時に、擬
似接続層にセッション開始を示すｂｅｇｉｎフラグ６５
をセットする。この状態で端末装置６０は、予め定めら
れたポート番号（端末装置の設計に依存する固定値）の
ソケット６４から、ゲートウエイ装置７０の予め定めら
れたポート番号（ＲＴＳＰの場合は、一般的に５５４
番）のソケット７４へ、ｂｅｇｉｎフラグ付きのＳＥＴ
ＵＰコマンドのパケット（先頭パケット）を転送する。
なお、端末装置６０とゲートウエイ装置７０との間は、
プロトコルスタック６３及び７１の再送処理層の働きに
よって、第１のネットワーク１０１でのパケットロスを
補償する仕組みが実装されているものとする。

【００５７】ｂｅｇｉｎフラグ付きのＳＥＴＵＰコマン
ドのパケットを受理したゲートウエイ装置７０は、ＲＴ
ＳＰ層の“ＳＥＴＵＰ”というコマンドを文法解釈する
ことなく、ｂｅｇｉｎフラグによってセッションの開始
を検出し、受信したパケットをサーバ装置８０へ転送す
るための通信経路確立の動作に入る。この際、ゲートウ
エイ装置７０は、ＵＤＰソケット生成部７３を用い、サ
ーバ装置８０のＩＰアドレスの選択を行って新たなＵＤ
Ｐソケット７５を生成する。さらに、ゲートウエイ装置
７０は、生成したＵＤＰソケット７５のファイルディス
クリプタ番号と端末装置６０のＩＰアドレス（端末ＩＰ
アドレス）とを一組として、そのアドレス変換パスをア
ドレス変換用参照テーブル７２に登録する（図８）。こ
の登録されたアドレス変換パス（エントリ）は、端末Ｉ
ＰアドレスからもＵＤＰソケットからも検索することが
可能である。

【００５８】本実施形態では、１つの端末装置６０がサ
ーバ装置８０との間に確立するセッションが１つだけで
ある場合を想定しているので、セッションとエントリと
の対応は１対１である。なお、１つの端末装置６０が２
つ以上のセッションを確立する場合には、ゲートウエイ
装置７０のアドレス変換用参照テーブル７２にセッショ
ン毎のエントリを用意し、端末装置６０の擬似接続層に
もセッション毎にセッション識別用のフィールドを設け
ればよい。また、本実施形態では、端末ＩＰアドレスと
ＵＤＰソケットのみをエントリとして登録する例を示し
たが、それ以外の情報、例えばポート番号、端末装置６
０が電話機の場合は電話番号という付加情報も、一緒に
登録してもよい。

【００５９】以上のようにアドレス変換パスが生成され
ると、生成したＵＤＰソケットからサーバ装置８０の予
め定められたポート番号（ＲＴＳＰの場合は、一般的に
５５４番）のソケット８２へ向けて、ＳＥＴＵＰコマン
ドのパケットが転送される。なお、ゲートウエイ装置７
０とサーバ装置８０との間は、プロトコルスタック７１
及び８１の再送処理層の働きによって、第２のネットワ
ーク１０２でのパケットロスを補償する仕組みが実装さ
れているものとする。

【００６０】ゲートウエイ装置７０からパケットを受け
取ったサーバ装置８０は、ＵＲＬの取得及びストリーム
送出の準備を行った後、プロトコルスタック８１のＲＴ
ＳＰ層にＯＫアクノリッジを記述したパケット（ＯＫパ
ケット）を端末装置６０に向けて返送する。このＯＫパ
ケットは、ＳＥＴＵＰコマンドのパケットを受信した時
の通信経路を逆向きに辿ってゲートウエイ装置７０へ送
られる。ゲートウエイ装置７０内では、アドレス変換用
参照テーブル７２をＵＤＰソケット７５で検索すること
により、端末ＩＰアドレスが抽出される。その後、ゲー
トウエイ装置７０は、この端末ＩＰアドレス及び端末装
置のポート番号を用いて、プロトコルスタック７１に示
されるアドレス変換を行い、端末装置６０へＯＫパケッ
トを転送する。これにより、ＳＥＴＵＰコマンドのシー
ケンスが完了する。

【００６１】図１０は、端末装置６０がＳＥＴＵＰや後
述のＴＥＡＲＤＯＷＮを除くコマンド、例えばＰＬＡＹ
等のコマンドを発行した場合のパケット転送の一例を示
すシーケンス図である。図１０に示すように、上述した
ＳＥＴＵＰコマンドの処理（図９）においてすでにアド
レス変換パスが決まっているので、ゲートウエイ装置７
０では、アドレス変換用参照テーブル７２の検索（端末
ＩＰアドレスに基づくＵＤＰソケットの検索）のみで素
早くアドレス変換され、ＰＬＡＹコマンド等のパケット
が端末装置６０からサーバ装置８０へ転送されることに
なる。

【００６２】図１１は、端末装置６０がＴＥＡＲＤＯＷ
Ｎコマンドを発行して、サーバ装置８０との間に確立し
ているセッションを終了する場合の一例を示すシーケン
ス図である。図１１において、まず、端末装置６０から
ＴＥＡＲＤＯＷＮコマンドが発行されて、ゲートウエイ
装置７０を経由し、サーバ装置８０に到達するまでは、
図１０のＰＬＡＹコマンドの場合と全く同様の動作であ
る。

【００６３】ＴＥＡＲＤＯＷＮコマンドのパケットを受
理したサーバ装置８０は、ＣＰＵ８５が、プロトコルス
タック８１のＲＴＳＰ層にＴＥＡＲＤＯＷＮに対するＯ
Ｋアクノリッジを記入すると同時に、擬似接続層にセッ
ション終了を示すｆｉｎフラグ８６をセットする。次
に、サーバ装置８０は、ストリーム送出の停止処理を行
った後、生成したＯＫアクノリッジを記述したパケット
（ＯＫパケット）を、ＴＥＡＲＤＯＷＮコマンドのパケ
ットを受信した時の通信経路を逆向きに辿って端末装置
６０へ返送する。パケット返送の途中にｆｉｎフラグ付
きのＯＫパケットを受理したゲートウエイ装置７０は、
ＲＴＳＰ層の“ＯＫ”というアクノリッジを文法解釈す
ることなく、ｆｉｎフラグによってセッションの終了を
検出し、アドレス変換用参照テーブル７２に登録されて
いる本セッションのエントリを抹消する作業に入る。そ
の後、ゲートウエイ装置７０は、この端末ＩＰアドレス
及び端末装置のポート番号を用いてアドレス変換を行っ
て、端末装置６０へＯＫパケットを転送する。これによ
り、ＴＥＡＲＤＯＷＮコマンドのシーケンスが完了する
と同時に、端末装置６０とサーバ装置８０との間のセッ
ションが解消される。

【００６４】図１２は、図９〜図１１を用いてすでに説
明したパケット通信方法を実現するための、ゲートウエ
イ装置７０の動作の一例を示すフローチャートである。
まず、ゲートウエイ装置７０は、何らかのパケットを受
信したか否かを判断し（ステップＳ１２０１）、受信し
た場合には、そのパケットが端末装置６０又はサーバ装
置８０のどちらから送信されたパケットかを判断する
（ステップＳ１２０２）。このステップＳ１２０２にお
いて端末装置６０から送信されたパケットであると判断
した場合、ゲートウエイ装置７０は、このパケットにｂ
ｅｇｉｎフラグが付加されているか否かを確認する（ス
テップＳ１２０３）。この確認の結果、ｂｅｇｉｎフラ
グが付加されている場合、ゲートウエイ装置７０は、サ
ーバ装置８０との間に新たなＵＤＰソケットを生成し
（ステップＳ１２０４）、この生成したＵＤＰソケット
と端末装置６０の端末ＩＰアドレスとを、アドレス変換
用参照テーブル７２に新たなエントリとして登録する
（ステップＳ１２０５）。そして、ゲートウエイ装置７
０は、アドレス変換用参照テーブル７２に登録した本セ
ッションのエントリに従ってアドレス変換を行い、受信
したパケットをサーバ装置８０へ転送する（ステップＳ
１２０６）。一方、ｂｅｇｉｎフラグが付加されていな
い場合、ゲートウエイ装置７０は、アドレス変換用参照
テーブル７２にすでに登録されている本セッションのエ
ントリに従ってアドレス変換を行い、受信したパケット
をサーバ装置８０へ転送する（ステップＳ１２０６）。

【００６５】一方、上記ステップＳ１２０２においてサ
ーバ装置８０から送信されたパケットであると判断した
場合、ゲートウエイ装置７０は、アドレス変換用参照テ
ーブル７２にすでに登録されているエントリに従ってア
ドレス変換を行い、受信したパケットを端末装置６０へ
転送する（ステップＳ１２０７）。このとき、ゲートウ
エイ装置７０は、受信したパケットにｆｉｎフラグが付
加されているか否かを確認し（ステップＳ１２０８）、
ｆｉｎフラグが付加されている場合には、登録されてい
るエントリを抹消して本セッションを解消させる（ステ
ップＳ１２０９）。

【００６６】なお、当業者には周知のように一般に、ゲ
ートウエイ装置７０には、確立されるセッション毎にパ
ケット転送を専任する中継スレッドが構築される。従っ
て、実際には、ゲートウエイ装置７０は、対応する中継
スレッドへ端末ＩＰアドレスの情報及び受信したバッフ
ァのポインタと共にシグナルを発行することで、端末装
置６０又はサーバ装置８０へのパケット転送処理を促す
ことを行う（ステップＳ１２０６、Ｓ１２０７）。ま
た、ソケットの判別及びパケットの発信元確認は、一般
にｓｅｌｅｃｔ関数やｓｏｃｋｏｐｔ関数等を用いて行
われる。

【００６７】以上のように、本発明の第２の実施形態に
係るサーバ・クライアントシステムによれば、端末装置
とサーバ装置との間にセッションを確立する場合、端末
装置から最初に発行されるパケットにｂｅｇｉｎフラグ
を付加して、ゲートウエイ装置へセッション開始を通知
する。また、すでに確立されているセッションを終了す
る場合、サーバ装置から最後に発行されるパケットにｆ
ｉｎフラグを付加して、ゲートウエイ装置へセッション
終了を通知する。そして、ゲートウエイ装置では、ｂｅ
ｇｉｎフラグの検出に基づいて端末装置とサーバ装置と
の間のセッションを確立させると共に、そのセッション
に関する転送経路情報（エントリ）を保持しておき、ｆ
ｉｎフラグの検出に基づいてエントリを抹消させてセッ
ションを解消させる。これにより、ゲートウエイ装置
は、アプリケーション層にセッションの概念が有るプロ
トコルを、トランスポート層にコネクションの概念が無
いプロトコルを用いた場合でも、アプリケーション層の
コマンド内容を逐一文法解析することなくセッションの
確立及び解消を検出でき、パケットの中継処理を効率的
に行うことができる。

【図面の簡単な説明】

【図１】本発明の第１の実施形態に係るサーバ・クライ
アントシステムの構成を示す図である。

【図２】図１のアドレス変換用参照テーブル２２を模式
的に示す図である。

【図３】第１の実施形態におけるＳＥＴＵＰコマンド発
行時のシーケンス図である。

【図４】第１の実施形態におけるＰＬＡＹコマンド発行
時のシーケンス図である。

【図５】第１の実施形態におけるＴＥＡＲＤＯＷＮコマ
ンド発行時のシーケンス図である。

【図６】図１のゲートウエイ装置２０の動作の一例を示
すフローチャートである。

【図７】本発明の第２の実施形態に係るサーバ・クライ
アントシステムの構成を示す図である。

【図８】図７のアドレス変換用参照テーブル７２を模式
的に示す図である。

【図９】第２の実施形態におけるＳＥＴＵＰコマンド発
行時のシーケンス図である。

【図１０】第２の実施形態におけるＰＬＡＹコマンド発
行時のシーケンス図である。

【図１１】第２の実施形態におけるＴＥＡＲＤＯＷＮコ
マンド発行時のシーケンス図である。

【図１２】図７のゲートウエイ装置７０の動作の一例を
示すフローチャートである。

【図１３】ＯＳＩの７階層モデルを示す図である。

【図１４】ＴＣＰ／ＩＰインターネットの階層モデルを
示す図である。

【図１５】ＯＳＩの７階層モデルとＴＣＰ／ＩＰインタ
ーネットの階層モデルとを対比した図である。

【図１６】プロトコル階層化の原理を示す図である。

【図１７】ＲＴＳＰにおけるプロトコル送受信の様子を
模式的に示す図である。

【図１８】ＴＣＰ／ＩＰ上における一般的なＴＣＰコネ
クション及びＲＴＳＰセッションの確立状態を模式的に
示す図である。

【図１９】ゲートウエイ装置を用いた端末装置−サーバ
装置間のＴＣＰコネクション及びＲＴＳＰセッションの
確立状態を模式的に示す図である。

【符号の説明】

１０，６０…端末装置 １１，６１，８４…メモリデバイス １２，６２，８５…ＣＰＵ １３，２１，３１，３３，６３，７１，８１，８３…プ
ロトコルスタック １４，２４，２５，３２，６４，７４，７５，８２…ソ
ケット １５，６５…ｂｅｇｉｎフラグ １６，８６…ｆｉｎフラグ ２０，７０…ゲートウエイ装置 ２２，７２…アドレス変換用参照テーブル ２３…ＴＣＰソケット生成部 ３０，８０…サーバ装置 ４０，９０…ファイルシステム ５１，１０１…第１のネットワーク ５２，１０２…第２のネットワーク ７３…ＵＤＰソケット生成部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 大穂 雅博 大阪府門真市大字門真1006番地 松下電器 産業株式会社内 Ｆターム(参考） 5K030 HA06 HA08 HD03 HD05 HD06 HD09 KA01 KA05 LA08 5K034 BB05 EE11 FF11 HH01 HH02 KK29

Claims (15)

【特許請求の範囲】
1. 【請求項１】 第１のネットワークに接続された１つ以
   上の端末装置と、第２のネットワークに接続された１つ
   以上のサーバ装置と、当該第１及び第２のネットワーク
   に接続され両装置間のパケット通信を中継するゲートウ
   エイ装置とからなるサーバ・クライアントシステムにお
   ける、パケット通信方法であって、 前記端末装置と前記サーバ装置との間に、階層化された
   通信プロトコルにおけるメッセージ送受信のための論理
   的な接続状態であるセッションを確立させる場合、 前記端末装置が、最初に発行する先頭パケットを、当該
   先頭パケット中の特定部分にセッション開始を示すｂｅ
   ｇｉｎフラグをセットして、前記ゲートウエイ装置へ送
   信し、 前記ゲートウエイ装置が、受信した前記先頭パケット中
   の前記ｂｅｇｉｎフラグを検出することでセッション開
   始を判断し、前記サーバ装置との通信経路を確立して当
   該先頭パケットを前記サーバ装置へ転送し、 前記端末装置と前記サーバ装置との間に確立されたセッ
   ションを解消させる場合、 前記端末装置が、最後に発行する最終パケットを、当該
   最終パケット中の特定部分にセッション終了を示すｆｉ
   ｎフラグをセットして、前記ゲートウエイ装置へ送信
   し、 前記ゲートウエイ装置が、受信した前記最終パケット中
   の前記ｆｉｎフラグを検出することでセッション終了を
   判断し、前記サーバ装置から前記最終パケットに対する
   応答を受信した後に、セッションを解消させることを特
   徴とする、パケット通信方法。
2. 【請求項２】 第１のネットワークに接続された１つ以
   上の端末装置と、第２のネットワークに接続された１つ
   以上のサーバ装置と、当該第１及び第２のネットワーク
   に接続され両装置間のパケット通信を中継するゲートウ
   エイ装置とからなるサーバ・クライアントシステムにお
   ける、パケット通信方法であって、 前記端末装置と前記サーバ装置との間に、階層化された
   通信プロトコルにおけるメッセージ送受信のための論理
   的な接続状態であるセッションを確立させる場合、 前記端末装置が、最初に発行する先頭パケットを、当該
   先頭パケット中の特定部分にセッション開始を示すｂｅ
   ｇｉｎフラグをセットして、前記ゲートウエイ装置へ送
   信し、 前記ゲートウエイ装置が、受信した前記先頭パケット中
   の前記ｂｅｇｉｎフラグを検出することでセッション開
   始を判断し、前記サーバ装置との通信経路を確立して当
   該先頭パケットを前記サーバ装置へ転送し、 前記端末装置と前記サーバ装置との間に確立されたセッ
   ションを解消させる場合、 前記端末装置が最後に発行する最終パケットの受信に基
   づいて、前記サーバ装置が、当該最終パケットに対する
   応答パケットを、当該応答パケット中の特定部分にセッ
   ション終了を示すｆｉｎフラグをセットして、前記ゲー
   トウエイ装置へ送信し、 前記ゲートウエイ装置が、受信した前記応答パケット中
   の前記ｆｉｎフラグを検出することでセッション終了を
   判断し、セッションを解消させることを特徴とする、パ
   ケット通信方法。
3. 【請求項３】 前記ゲートウエイ装置が、確立した通信
   経路に関する情報を保持し、前記先頭パケット以降のパ
   ケット通信を当該情報に従って行うことを特徴とする、
   請求項１又は２に記載のパケット通信方法。
4. 【請求項４】 前記ゲートウエイ装置は、前記通信経路
   に関する情報を削除することでセッションを解消させる
   ことを特徴とする、請求項３に記載のパケット通信方
   法。
5. 【請求項５】 前記第１のネットワーク上におけるセッ
   ション層の通信プロトコルが、リテラルなスクリプト表
   記のプロトコルであることを特徴とする、請求項１に記
   載のパケット通信方法。
6. 【請求項６】 前記第１及び第２のネットワーク上にお
   ける双方のセッション層の通信プロトコルが、共にリテ
   ラルなスクリプト表記のプロトコルであることを特徴と
   する、請求項２に記載のパケット通信方法。
7. 【請求項７】 第１のネットワークに接続された１つ以
   上の端末装置と、第２のネットワークに接続された１つ
   以上のサーバ装置と、当該第１及び第２のネットワーク
   に接続され両装置間のパケット通信を中継するゲートウ
   エイ装置とからなるサーバ・クライアントシステムであ
   って、 前記サーバ装置との間に、階層化された通信プロトコル
   におけるメッセージ送受信のための論理的な接続状態で
   あるセッションを確立させる場合、最初に発行する先頭
   パケット中の特定部分にセッション開始を示すｂｅｇｉ
   ｎフラグをセットし、前記サーバ装置との間に確立され
   たセッションを解消させる場合、最後に発行する最終パ
   ケット中の特定部分にセッション終了を示すｆｉｎフラ
   グをセットして、前記ゲートウエイ装置へ当該パケット
   を送信する端末装置と、 前記先頭パケット中の前記ｂｅｇｉｎフラグを検出する
   ことでセッション開始を判断して、前記サーバ装置との
   通信経路を確立して当該先頭パケットを前記サーバ装置
   へ転送し、前記最終パケット中の前記ｆｉｎフラグを検
   出することでセッション終了を判断して、前記サーバ装
   置から前記最終パケットに対する応答を受信した後に、
   セッションを解消させるゲートウエイ装置とを備える、
   サーバ・クライアントシステム。
8. 【請求項８】 第１のネットワークに接続された１つ以
   上の端末装置と、第２のネットワークに接続された１つ
   以上のサーバ装置と、当該第１及び第２のネットワーク
   に接続され両装置間のパケット通信を中継するゲートウ
   エイ装置とからなるサーバ・クライアントシステムであ
   って、 前記サーバ装置との間に、階層化された通信プロトコル
   におけるメッセージ送受信のための論理的な接続状態で
   あるセッションを確立させる場合、最初に発行する先頭
   パケット中の特定部分にセッション開始を示すｂｅｇｉ
   ｎフラグをセットして、前記ゲートウエイ装置へ当該パ
   ケットを送信する端末装置と、 前記端末装置との間に確立されたセッションを解消させ
   る場合、前記端末装置が最後に発行する最終パケットの
   受信に基づいて、当該最終パケットに対する応答パケッ
   ト中の特定部分にセッション終了を示すｆｉｎフラグを
   セットして、前記ゲートウエイ装置へ当該パケットを送
   信するサーバ装置と、 前記先頭パケット中の前記ｂｅｇｉｎフラグを検出する
   ことでセッション開始を判断して、前記サーバ装置との
   通信経路を確立して当該先頭パケットを前記サーバ装置
   へ転送し、前記応答パケット中の前記ｆｉｎフラグを検
   出することでセッション終了を判断して、セッションを
   解消させるゲートウエイ装置とを備える、サーバ・クラ
   イアントシステム。
9. 【請求項９】 第２のネットワークによって１つ以上の
   サーバ装置と接続されたゲートウエイ装置に、第１のネ
   ットワークを介して接続される端末装置であって、 前記サーバ装置との間に、階層化された通信プロトコル
   におけるメッセージ送受信のための論理的な接続状態で
   あるセッションを確立させる場合、最初に発行する先頭
   パケット中の特定部分にセッション開始を示すｂｅｇｉ
   ｎフラグをセットする設定部と、 前記ｂｅｇｉｎフラグをセットした前記先頭パケットを
   前記ゲートウエイ装置へ送信する送信部とを備える、端
   末装置。
10. 【請求項１０】 第２のネットワークによって１つ以上
    のサーバ装置と接続されたゲートウエイ装置に、第１の
    ネットワークを介して接続される端末装置であって、 前記サーバ装置との間に、階層化された通信プロトコル
    におけるメッセージ送受信のための論理的な接続状態で
    あるセッションを確立させる場合、最初に発行する先頭
    パケット中の特定部分にセッション開始を示すｂｅｇｉ
    ｎフラグをセットする設定部と、 前記サーバ装置との間に確立されたセッションを解消さ
    せる場合、最後に発行する最終パケット中の特定部分に
    セッション終了を示すｆｉｎフラグをセットする設定部
    と、 前記ｂｅｇｉｎフラグをセットした前記先頭パケット又
    は前記ｆｉｎフラグをセットした前記最終パケットを、
    前記ゲートウエイ装置へ送信する送信部とを備える、端
    末装置。
11. 【請求項１１】 第１のネットワークによって１つ以上
    の端末装置と接続されたゲートウエイ装置に、第２のネ
    ットワークを介して接続されるサーバ装置であって、 前記端末装置との間に確立されたセッションを解消させ
    る場合、前記端末装置が最後に発行する最終パケットの
    受信に基づいて、当該最終パケットに対する応答パケッ
    ト中の特定部分にセッション終了を示すｆｉｎフラグを
    セットする設定部と、 前記ｆｉｎフラグをセットした前記応答パケットを、前
    記ゲートウエイ装置へ送信する送信部とを備える、サー
    バ装置。
12. 【請求項１２】 第１のネットワークを介して１つ以上
    の端末装置と、第２のネットワークを介して１つ以上の
    サーバ装置とに接続されるゲートウエイ装置であって、 前記端末装置から送信されるパケット中のセッション開
    始を示すフラグを検出することでセッション開始を判断
    して、前記サーバ装置との通信経路を確立して当該パケ
    ットを前記サーバ装置へ転送する送信部と、 前記パケット以降のパケット通信を、確立した前記通信
    経路に関する情報に従って行うために、当該情報を保持
    する記憶部と、 前記端末装置又は前記サーバ装置から送信されるパケッ
    ト中のセッション終了を示すフラグを検出することでセ
    ッション終了を判断して、対応するパケット送信を完了
    した後に前記通信経路に関する情報を削除することでセ
    ッションを解消させる処理部とを備える、ゲートウエイ
    装置。
13. 【請求項１３】 前記第１のネットワーク上におけるセ
    ッション層の通信プロトコルが、リテラルなスクリプト
    表記のプロトコルであることを特徴とする、請求項９又
    は１０に記載の端末装置。
14. 【請求項１４】 前記第２のネットワーク上におけるセ
    ッション層の通信プロトコルが、リテラルなスクリプト
    表記のプロトコルであることを特徴とする、請求項１１
    に記載のサーバ装置。
15. 【請求項１５】 前記第１のネットワーク上における又
    は前記第１及び第２のネットワーク上における双方のセ
    ッション層の通信プロトコルが、共にリテラルなスクリ
    プト表記のプロトコルであることを特徴とする、請求項
    １２に記載のゲートウエイ装置。