通信プロトコルを用いた相互接続方法および装置
【課題】通信プロトコルによる通信装置間の相互接続性を向上させる相互接続方法および装置を提供する。
【解決手段】ＨＴＴＰのバージョンとヘッダの両方を制御することにより通信装置間の相互接続性を高める。ＨＴＴＰ−ＨＥＡＤ生成部１０４は、クライアント１１から受信したＨＴＴＰリクエストからサーバ１２のＨＴＴＰバージョンを取得するためのＨＴＴＰリクエストを生成し、ＨＴＴＰバージョン判定部１０６はサーバ１２の応答からそのバージョンを判定する。ＨＴＴＰリクエスト生成部１０７は、クライアント１１とサーバ１２との間でＨＴＴＰバージョンおよびヘッダ情報を整合させたＨＴＴＰリクエストを生成し、サーバ１２へ送信する。これによってクライアント１１とサーバ１２との相互接続を行う。
【解決手段】ＨＴＴＰのバージョンとヘッダの両方を制御することにより通信装置間の相互接続性を高める。ＨＴＴＰ−ＨＥＡＤ生成部１０４は、クライアント１１から受信したＨＴＴＰリクエストからサーバ１２のＨＴＴＰバージョンを取得するためのＨＴＴＰリクエストを生成し、ＨＴＴＰバージョン判定部１０６はサーバ１２の応答からそのバージョンを判定する。ＨＴＴＰリクエスト生成部１０７は、クライアント１１とサーバ１２との間でＨＴＴＰバージョンおよびヘッダ情報を整合させたＨＴＴＰリクエストを生成し、サーバ１２へ送信する。これによってクライアント１１とサーバ１２との相互接続を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ通信システムに係り、特に通信プロトコルを用いた通信装置間の相互接続方法および装置に関する。
【背景技術】
【０００２】
ＨＴＴＰ（Hyper Text Transfer Protocol）は、インターネットを利用してユーザ端末上のブラウザとウェブサーバとが相互にデータを送受信するために一般的に採用されている代表的通信プロトコルである。しかしながら、このように通信プロトコルは不変のものではなく進化するものであり、ＨＴＴＰのバージョンとしてはＨＴＴＰ／１．０（ＲＦＣ１９４５）やＨＴＴＰ／１．１（ＲＦＣ２６１６）などがある。一般に旧バージョンのコマンドは新バージョンで解釈可能であるが、新バージョンに新たに導入されたコマンドは旧バージョンのサーバには解釈できない。このために通信プロトコルには常にバージョン適合の問題があるというべきであり、異なるＨＴＴＰバージョンを適合させるシステムや方法がこれまでにも多く提案されてきた。
【０００３】
たとえば、特表２００４−５３０２３１号公報（特許文献１）には、ユーザ端末とサーバとが異なるバージョンに準拠している場合、両者の相互接続性を向上させるプロキシサーバが開示されている。このプロキシサーバはユーザ端末とサーバの両方のメッセージを分析し、相互にプロトコルバージョンを変換することで良好な接続性を維持している。たとえばＨＴＴＰバージョンをＨＴＴＰ／１．１からＨＴＴＰ／１．０へ変換し、サーバとの接続性を向上させる。
【０００４】
【特許文献１】特表２００４−５３０２３１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のように通信プロトコルのバージョンを整合させるだけでは、良好な接続性を確保することができない可能性がある。たとえば、ＨＴＴＰ／１．０に準拠したサーバにＨＴＴＰ／１．１のヘッダを含むＨＴＴＰリクエストを送信した場合、通常はＨＴＴＰ／１．１のヘッダは無視されるべきである。しかしながら、この対応はサーバ側の実装によっているために、ＨＴＴＰ／１．１のヘッダを拒否する動作がされる場合もあり得る。その場合にはクライアントはサーバへの接続自体ができないことになる。
【０００６】
また、将来新しいＨＴＴＰバージョンが追加されたり、あるいはヘッダ情報を確認する仕様が追加されたりした場合、バージョン制御機能のみでは高い接続性を確保することが出来ない可能性がある。
【０００７】
また、ＲＦＣ２１４５の第２章のＮＯＴＥにて、将来のＨＴＴＰバージョンにおいては、理解不能なヘッダを含むリクエストは、却下する仕様が追加されるかもしれない（ＭＡＹ）と記述がある。このような仕様が追加されると、従来の装置が行うバージョン変換のみではヘッダの不整合により接続不能となる可能性がある。
【０００８】
本発明の目的は、通信プロトコルによる通信装置間の相互接続性を向上させる相互接続方法および装置を提供することにある。
【０００９】
本発明の他の目的は、通信プロトコルのバージョンが将来追加された場合でも高い接続性を確保することできる相互接続方法および装置を提供することにある。
【課題を解決するための手段】
【００１０】
本発明によれば、通信プロトコルのバージョンとヘッダの両方を制御することにより通信装置間の相互接続性を高める。
【００１１】
本発明の第１の側面によれば、所定の通信プロトコルにより通信装置間の通信を可能にする相互接続方法であって、ａ）前記通信装置の各々が準拠する前記通信プロトコルのバージョンを判定し、ｂ）前記通信プロトコルのバージョンとそのヘッダとを前記通信装置間で一致させ、ｃ）前記一致させた通信プロトコルのバージョンおよびヘッダを用いて前記通信装置間を相互接続する、ことを特徴とする。
【００１２】
前記ｂ）において、前記通信プロトコルの上位バージョンを下位バージョンへ変換し、前記上位バージョンのみに関係するヘッダ情報を削除することで、前記下位バージョンに従った新たなヘッダのメッセージを生成することを特徴とする。
【００１３】
本発明の一実施例によれば、前記ａ）において、一方の通信装置から受信した第１メッセージから当該一方の通信装置が準拠する通信プロトコルの第１バージョンを判定し、前記第１バージョン以下のバージョンの第２メッセージを他方の通信装置へ送信し、前記他方の通信装置から受信した前記第２メッセージに対する応答メッセージから当該他方の通信装置が準拠する通信プロトコルの第２バージョンを判定する、ことを特徴とする。
【００１４】
本発明の他の実施例によれば、前記ａ）において、一方の通信装置から受信した第１メッセージから当該一方の通信装置が準拠する通信プロトコルの第１バージョンを判定し、予め定められた複数のバージョンの各々に従った複数の第２メッセージを他方の通信装置へそれぞれ送信し、前記他方の通信装置から前記複数の第２メッセージのそれぞれに対する応答メッセージを受信すると、これら応答メッセージから当該他方の通信装置が準拠する通信プロトコルの第２バージョンを判定する、ことを特徴とする。
【００１５】
本発明の他の側面によれば、所定の通信プロトコルにより通信装置間の通信を可能にする相互接続装置であって、一方の通信装置から受信した第１メッセージと、当該第１メッセージに基づいて他方の通信装置へ送信された第２メッセージに対する応答メッセージと、からの前記一方および他方の通信装置がそれぞれ準拠する前記通信プロトコルの第１バージョンおよび第２バージョンを判定するバージョン判定手段と、前記通信プロトコルのバージョンとそのヘッダとを前記通信装置間で一致させた第３メッセージを生成するメッセージ生成手段と、を有し、前記第３メッセージを前記他方の通信装置へ送信することで前記通信装置間を相互接続することを特徴とする。
【発明の効果】
【００１６】
以上説明したように、本発明によれば、通信プロトコルのバージョンだけでなくヘッダ情報も整合させることができるために、通信装置間、たとえばクライアントとサーバとの間で高い接続性を達成することができる。また、将来、通信プロトコルの新しいバージョンが追加され下位互換性が低いプロトコルとなった場合でも高い接続性を確保することが可能である。
【発明を実施するための最良の形態】
【００１７】
１．装置構成
図１は本発明の一実施形態による相互接続装置の機能的構成を示すブロック図である。相互接続装置１０にはデータ受信部１０１およびデータ送信部１０２が設けられ、ネットワークを介してクライアント１１およびサーバ１２の各々と通信可能である。
【００１８】
ＨＴＴＰリクエスト保存部１０３はクライアント１１から受信したＨＴＴＰリクエストを保存するためのメモリである。ＨＴＴＰ−ＨＥＡＤ生成部１０４は、サーバ１２のＨＴＴＰバージョンを取得するためのＨＴＴＰ−ＨＥＡＤリクエストを生成し、ＨＴＴＰ−ＨＥＡＤリクエストはデータ送信部１０２からサーバ１２へ送信される。
【００１９】
ＨＴＴＰ−ＨＥＡＤ解析部１０５は、サーバ１２から受信したＨＴＴＰ−ＨＥＡＤリクエストに対するレスポンスを解析し、サーバ１２のＨＴＴＰバージョンを取得する。ＨＴＴＰバージョン判定部１０６は、取得したサーバ１２のＨＴＴＰバージョンから生成するＨＴＴＰリクエストのバージョンを決定する。ＨＴＴＰリクエスト生成部１０７は、ＨＴＴＰリクエスト保存部１０３に保存しているＨＴＴＰリクエストをＨＴＴＰバージョン判定部１０６より指示されたＨＴＴＰバージョンに改造する。
【００２０】
なお、図１は相互接続装置１０の機能的な構成を示しており、全体的な動作制御は図示されていない制御部により実行される。また、ＨＴＴＰ−ＨＥＡＤ生成部１０４、ＨＴＴＰ−ＨＥＡＤ解析部１０５、ＨＴＴＰバージョン判定部１０６およびＨＴＴＰリクエスト生成部１０７はハードウェアにより回路構成されても良いし、プログラム制御プロセッサ上でプログラムを実行することにより同様の機能をソフトウェア的に実現しても良い。
【００２１】
２．動作
図２は本実施形態による相互接続装置の動作を示すフローチャートである。まず、データ受信部１０１がクライアント１１からＨＴＴＰリクエストを受信すると（ステップＳ２０１）、制御部はＨＴＴＰリクエストをＨＴＴＰリクエスト保存部１０３に保存する（ステップＳ２０２）。
【００２２】
続いて、ＨＴＴＰ−ＨＥＡＤ生成部１０４は、サーバ１２のＨＴＴＰバージョンを取得するために、クライアント１１から受信したＨＴＴＰリクエストのバージョン以下のバージョンによりＨＴＴＰ−ＨＥＡＤリクエストを生成してデータ送信部１０２を通してサーバ１２へ送信し（ステップＳ２０３）、サーバ１２からの応答を待つ。
【００２３】
サーバ１２からレスポンスを受信すると（ステップＳ２０４）、ＨＴＴＰ−ＨＥＡＤ解析部１０５はそのレスポンスを解析する。ＨＴＴＰバージョン判定部１０６は解析結果からサーバ１２のＨＴＴＰバージョンを判定し（ステップＳ２０５）、ＨＴＴＰリクエスト生成部１０７へ通知する。
【００２４】
ＨＴＴＰリクエスト生成部１０７は、サーバ１２のＨＴＴＰバージョンと、ＨＴＴＰリクエスト保存部１０３に保存しているクライアント１１のＨＴＴＰリクエストとに基づいて、両者のＨＴＴＰバージョンを比較する。サーバ１２のＨＴＴＰバージョンがクライアント１１のＨＴＴＰバージョンと同一あるいは上位でサポートできる場合には問題が生じないので、クライアント１１のＨＴＴＰリクエストをそのまま送信用のＨＴＴＰリクエストとして使用する。
【００２５】
他方、サーバ１２が下位バージョンの場合には、ＨＴＴＰリクエスト生成部１０７はクライアント１１のＨＴＴＰリクエストから上位バージョン用のヘッダを削除し、下位バージョンへバージョンおよびヘッダ情報を適合させたＨＴＴＰリクエストを生成する（ステップＳ２０６）。
【００２６】
こうしてＨＴＴＰリクエスト生成部１０７から出力されたＨＴＴＰリクエストがデータ送信部１０２からサーバ１２へ送信される（ステップＳ２０７）。これに対するレスポンスをサーバ１２から受信すると（ステップＳ２０８）、そのＨＴＴＰレスポンスをクライアント１１へ送信する（ステップＳ２０９）。
【００２７】
上述したように、クライアント１１とサーバ１２との間を接続する際に、両者のＨＴＴＰバージョンだけでなくヘッダ情報も整合させることで、接続不能の事態を回避することができ高い接続性を得ることができる。
【００２８】
なお、本実施形態ではサーバ１２のＨＴＴＰバージョン取得のためにＨＥＡＤメソッドを使用しているが、その他のＧＥＴ、ＰＯＳＴ、ＴＲＡＣＥ、ＰＵＴあるいはＤＥＬＴＥメソッドを使用する場合も、ＨＥＡＤメソッドと同様にサーバ１２のバージョンを取得することが可能である。
【実施例１】
【００２９】
以下、説明を煩雑にしないためにＨＴＴＰバージョンをＨＴＴＰ／１．０およびＨＴＴＰ／１．１の２種類とする。
【００３０】
図３は本発明の第１実施例による相互接続装置の動作を説明するためのシーケンス図である。ここでは、本実施例による相互接続装置がルータ１０に組み込まれ、クライアント１１とサーバ１２との間を中継しているものとする。
【００３１】
まず、クライアント１１はＨＴＴＰ／１．１リクエストを送信する（Ｓ１１）。クライアント１１からＨＴＴＰ／１．１ＨＴＴＰリクエストを受信すると、ルータ１０はＨＴＴＰ／１．１以下のバージョンであるＨＴＴＰ／１．０のＨＥＡＤリクエストを生成し、ＨＴＴＰリクエストで指定されたサーバ１２へ送信する（Ｓ１２）。その後、サーバ１２からＨＴＴＰレスポンスを受信すると（Ｓ１３）、そのＨＴＴＰレスポンスからサーバ１２のＨＴＴＰバージョンを取得する。
【００３２】
ルータ１０のＨＴＴＰリクエスト生成部１０７は、上述したように、取得したサーバ１２のバージョンとクライアント１１から受信したＨＴＴＰリクエストとをバージョンおよびＨＴＴＰヘッダの両方を含めて一致させたＨＴＴＰリクエストを新たに生成し、サーバ１２へ送信する（Ｓ１４）。その後サーバ１２からＨＴＴＰリクエストを受信すると（Ｓ１５）、それをクライアント１１へ透過させる（Ｓ１６）。
【００３３】
ＨＴＴＰリクエスト生成部１０７が実行するバージョン情報およびヘッダ情報の制御方法を具体的に説明する。
【００３４】
図４はＨＴＴＰリクエスト生成部１０７が実行するバージョン情報およびヘッダ情報の制御方法を説明するためのＨＴＴＰメッセージを示す模式的フォーマット図である。まず、図４（ａ）に示すように、ＨＴＴＰリクエストメッセージのフォーマットは、先頭行のリクエストラインに、メソッド、ＵＲＬのパスおよびＨＴＴＰバージョンが指定され、続く行にヘッダが１行ずつ続く。そして設定するヘッダの最後にヘッダとデータとの区切りを示す改行を挟んでデータ部分が続く。
【００３５】
図４（ｂ）に示すように、クライアント１１からＨＴＴＰ／１．１リクエスト３０１を受信すると、ルータ１０はそれをＨＴＴＰリクエスト保存部１０３に格納する。そして、サーバ１２のＨＴＴＰバージョンがＨＴＴＰ／１．０であると判定されると、ＨＴＴＰリクエスト生成部１０７は、バージョンをＨＴＴＰ／１．１からＨＴＴＰ／１．０へ変換し、さらにＨＴＴＰ／１．１リクエスト３０１のヘッダを検索してＨＴＴＰ／１．１のヘッダ情報が存在する場合はこれを削除する。ここではＨｏｓｔヘッダとＡｃｃｅｐｔ−Ｌａｎｇｕａｇｅヘッダは、ＨＴＴＰ／１．１のヘッダであるから削除される。ただし、ＡｕｔｈｏｒｉｚａｔｉｏｎヘッダとＣｏｎｔｅｎｔ−ＬｅｎｇｔｈヘッダはＨＴＴＰ／１．０とＨＴＴＰ／１．１に共通のヘッダであるから保持される。以上が図２のステップＳ２０６に対応する。こうして新たなＨＴＴＰ／１．０リクエスト３０２が生成され、サーバ１２に送信される。
【００３６】
なお、ＨＴＴＰバージョンとヘッダの対応およびリクエストメッセージのフォーマットの詳細は、以下のＲＦＣを参照のこと：
ＨＴＴＰ／１．０：ＲＦＣ１９４５の４．３章、５．２章、７．１章
ＨＴＴＰ／１．１：ＲＦＣ２６１６の４．５章、５．３章、７．１章。
【００３７】
上述したように、ルータ１０の処理は、取得したクライアント１１およびサーバ１２のバージョンによって異なる。
【００３８】
図５はサーバの下位のＨＴＴＰバージョン１．０である場合のルータの処理を示すシーケンス図である。クライアント１１からＨＴＴＰ／１．１リクエストを受信することでクライアント１１のＨＴＴＰバージョンをＨＴＴＰ／１．１であると判定し（Ｓ２１）、続いてサーバ１２のＨＴＴＰバージョンがＨＴＴＰ／１．０であると判定する（Ｓ２２，Ｓ２３）。これよりＨＴＴＰリクエスト生成部１０７は、クライアント１１から受信したＨＴＴＰ／１．１リクエストをＨＴＴＰバージョン１．０に変換し、ＨＴＴＰ／１．１リクエストからＨＴＴＰ／１．１用のヘッダを削除する。こうして作成したＨＴＴＰ／１．０リクエストをサーバ１２に送信する（Ｓ２４）。
【００３９】
その後、ルータ１０は、サーバ１２からＨＴＴＰ／１．０レスポンスを受信すると（Ｓ２５）、それをクライアント１１へ透過的に送信する（Ｓ２６）。
【００４０】
図６はサーバの同一ＨＴＴＰバージョン１．１である場合のルータの処理を示すシーケンス図である。クライアント１１からＨＴＴＰ／１．１リクエストを受信することでクライアント１１のＨＴＴＰバージョンをＨＴＴＰ／１．１であると判定し（Ｓ２３１、続いてサーバ１２のＨＴＴＰバージョンがＨＴＴＰ／１．１であると判定する（Ｓ３２，Ｓ３３）。両者は同一バージョンであるから、ＨＴＴＰリクエスト生成部１０７は、クライアント１１から受信したＨＴＴＰ／１．１リクエストをサーバ１２へ送信する（Ｓ３４）。その後、ルータ１０は、サーバ１２からＨＴＴＰ／１．１のレスポンスを受信すると（Ｓ３５）、それをクライアント１１へ透過的に送信する（Ｓ３６）。
【実施例２】
【００４１】
将来、ＨＴＴＰのバージョンが追加された場合も本発明は適用可能である。以下、ＨＴＴＰ／１．０およびＨＴＴＰ／１．１に加えてＨＴＴＰ／２．０が追加され、計３種類のバージョンが存在する場合を一例として説明する。４種類以上のバージョンが存在する場合でも同様である。
【００４２】
図７は本発明の第２実施例による相互接続装置の動作を説明するためのシーケンス図である。ここでは、本実施例による相互接続装置がルータ１０に組み込まれ、クライアント１１とサーバ１２との間を中継しているものとする。
【００４３】
まず、クライアント１１はＨＴＴＰ／１．１リクエストを送信する（Ｓ４１）。クライアント１１からＨＴＴＰリクエストを受信すると、ルータ１０のＨＴＴＰ−ＨＥＡＤ生成部１０４は、サーバ１２のＨＴＴＰバージョンを正確に取得するために、ＨＴＴＰ−ＨＥＡＤリクエストを各バージョンに分けて送信する。すなわち、可能性のある３種類のＨＥＡＤリクエスト：ＨＴＴＰ／１．０−、ＨＴＴＰ／１．１−、およびＨＴＴＰ／２．０−ＨＥＡＤリクエスト、を送信する（Ｓ４２、Ｓ４３、Ｓ４４）。
【００４４】
これらに応答してサーバ１２からレスポンスを受信するが（Ｓ４５、Ｓ４６、Ｓ４７）、ルータ１０のＨＴＴＰバージョン判定部１０６は、これらレスポンスのバージョンとステータスコードの両方を参照して、サーバ１２に送信すべきＨＴＴＰリクエストのバージョンを決定する。ここでは、ＨＴＴＰ／１．０のリクエスト（Ｓ４２）に対して、ステータスコード“５０５”（ＨＴＴＰ Ｖｅｒｓｉｏｎ Ｎｏｔ Ｓｕｐｐｏｔｅｄ：リクエストしたＨＴＴＰバージョンは未サポート）を通知しているために（Ｓ４５）、サーバ１２はＨＴＴＰ／１．０を受け付けない事がわかる。また、ＨＴＴＰ／１．１のリクエスト（Ｓ４３）に対して、ＨＴＴＰ／２．０のステータスコード“２００”（ＯＫ：リクエストを正常に受け付けた）で応答し（Ｓ４６）、ＨＴＴＰ／２．０のリクエスト（Ｓ４４）に対しても同様にＨＴＴＰ／２．０のステータスコード“２００”で応答している（Ｓ４７）。これにより、サーバ１２に送信する最適なリクエストはＨＴＴＰ／２．０と判定可能である。その判定を元に、ＨＴＴＰリクエスト生成部１０７はＨＴＴＰ／２．０のリクエストを生成してサーバ１２に送信する（Ｓ４８）。ルータ１０は、サーバ１２からＨＴＴＰ／２．０のレスポンスを受信すると（Ｓ４９）、それをクライアント１１へ透過的に送信する（Ｓ５０）。
【００４５】
このように、将来ＨＴＴＰバージョンが追加され、下位互換性が低いプロトコルとなった場合でも、本発明によれば高い接続性を確保することが可能となる。
【００４６】
なお、上記第１および第２実施例ではルータ１０に本実施例による相互接続装置を実装したが、データを送受信する機能が存在する通信装置であれば良く、パーソナルコンピュータ（ＰＣ）などを用いても実現可能である。
【産業上の利用可能性】
【００４７】
本発明は通信装置間のデータ通信を中継して両者を相互接続する中継装置一般に適用可能であり、たとえばクライアントとサーバを中継するルータ、ゲートウェイなどに適用できる。
【図面の簡単な説明】
【００４８】
【図１】本発明の一実施形態による相互接続装置の機能的構成を示すブロック図である。
【図２】本実施形態による相互接続装置の動作を示すフローチャートである。
【図３】本発明の第１実施例による相互接続装置の動作を説明するためのシーケンス図である。
【図４】ＨＴＴＰリクエスト生成部１０７が実行するバージョン情報およびヘッダ情報の制御方法を説明するためのＨＴＴＰメッセージを示す模式的フォーマット図である。
【図５】サーバの下位のＨＴＴＰバージョン１．０である場合のルータの処理を示すシーケンス図である。
【図６】サーバの同一ＨＴＴＰバージョン１．１である場合のルータの処理を示すシーケンス図である。
【図７】本発明の第２実施例による相互接続装置の動作を説明するためのシーケンス図である。
【符号の説明】
【００４９】
１０ 相互接続装置（ルータ）
１１ クライアント
１２ サーバ
１０１ データ受信部
１０２ データ送信部
１０３ ＨＴＴＰリクエスト保存部
１０４ ＨＴＴＰ−ＨＥＡＤ生成部
１０５ ＨＴＴＰ−ＨＥＡＤ解析部
１０６ ＨＴＴＰバージョン判定部
１０７ ＨＴＴＰリクエスト生成部
【技術分野】
【０００１】
本発明はデータ通信システムに係り、特に通信プロトコルを用いた通信装置間の相互接続方法および装置に関する。
【背景技術】
【０００２】
ＨＴＴＰ（Hyper Text Transfer Protocol）は、インターネットを利用してユーザ端末上のブラウザとウェブサーバとが相互にデータを送受信するために一般的に採用されている代表的通信プロトコルである。しかしながら、このように通信プロトコルは不変のものではなく進化するものであり、ＨＴＴＰのバージョンとしてはＨＴＴＰ／１．０（ＲＦＣ１９４５）やＨＴＴＰ／１．１（ＲＦＣ２６１６）などがある。一般に旧バージョンのコマンドは新バージョンで解釈可能であるが、新バージョンに新たに導入されたコマンドは旧バージョンのサーバには解釈できない。このために通信プロトコルには常にバージョン適合の問題があるというべきであり、異なるＨＴＴＰバージョンを適合させるシステムや方法がこれまでにも多く提案されてきた。
【０００３】
たとえば、特表２００４−５３０２３１号公報（特許文献１）には、ユーザ端末とサーバとが異なるバージョンに準拠している場合、両者の相互接続性を向上させるプロキシサーバが開示されている。このプロキシサーバはユーザ端末とサーバの両方のメッセージを分析し、相互にプロトコルバージョンを変換することで良好な接続性を維持している。たとえばＨＴＴＰバージョンをＨＴＴＰ／１．１からＨＴＴＰ／１．０へ変換し、サーバとの接続性を向上させる。
【０００４】
【特許文献１】特表２００４−５３０２３１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のように通信プロトコルのバージョンを整合させるだけでは、良好な接続性を確保することができない可能性がある。たとえば、ＨＴＴＰ／１．０に準拠したサーバにＨＴＴＰ／１．１のヘッダを含むＨＴＴＰリクエストを送信した場合、通常はＨＴＴＰ／１．１のヘッダは無視されるべきである。しかしながら、この対応はサーバ側の実装によっているために、ＨＴＴＰ／１．１のヘッダを拒否する動作がされる場合もあり得る。その場合にはクライアントはサーバへの接続自体ができないことになる。
【０００６】
また、将来新しいＨＴＴＰバージョンが追加されたり、あるいはヘッダ情報を確認する仕様が追加されたりした場合、バージョン制御機能のみでは高い接続性を確保することが出来ない可能性がある。
【０００７】
また、ＲＦＣ２１４５の第２章のＮＯＴＥにて、将来のＨＴＴＰバージョンにおいては、理解不能なヘッダを含むリクエストは、却下する仕様が追加されるかもしれない（ＭＡＹ）と記述がある。このような仕様が追加されると、従来の装置が行うバージョン変換のみではヘッダの不整合により接続不能となる可能性がある。
【０００８】
本発明の目的は、通信プロトコルによる通信装置間の相互接続性を向上させる相互接続方法および装置を提供することにある。
【０００９】
本発明の他の目的は、通信プロトコルのバージョンが将来追加された場合でも高い接続性を確保することできる相互接続方法および装置を提供することにある。
【課題を解決するための手段】
【００１０】
本発明によれば、通信プロトコルのバージョンとヘッダの両方を制御することにより通信装置間の相互接続性を高める。
【００１１】
本発明の第１の側面によれば、所定の通信プロトコルにより通信装置間の通信を可能にする相互接続方法であって、ａ）前記通信装置の各々が準拠する前記通信プロトコルのバージョンを判定し、ｂ）前記通信プロトコルのバージョンとそのヘッダとを前記通信装置間で一致させ、ｃ）前記一致させた通信プロトコルのバージョンおよびヘッダを用いて前記通信装置間を相互接続する、ことを特徴とする。
【００１２】
前記ｂ）において、前記通信プロトコルの上位バージョンを下位バージョンへ変換し、前記上位バージョンのみに関係するヘッダ情報を削除することで、前記下位バージョンに従った新たなヘッダのメッセージを生成することを特徴とする。
【００１３】
本発明の一実施例によれば、前記ａ）において、一方の通信装置から受信した第１メッセージから当該一方の通信装置が準拠する通信プロトコルの第１バージョンを判定し、前記第１バージョン以下のバージョンの第２メッセージを他方の通信装置へ送信し、前記他方の通信装置から受信した前記第２メッセージに対する応答メッセージから当該他方の通信装置が準拠する通信プロトコルの第２バージョンを判定する、ことを特徴とする。
【００１４】
本発明の他の実施例によれば、前記ａ）において、一方の通信装置から受信した第１メッセージから当該一方の通信装置が準拠する通信プロトコルの第１バージョンを判定し、予め定められた複数のバージョンの各々に従った複数の第２メッセージを他方の通信装置へそれぞれ送信し、前記他方の通信装置から前記複数の第２メッセージのそれぞれに対する応答メッセージを受信すると、これら応答メッセージから当該他方の通信装置が準拠する通信プロトコルの第２バージョンを判定する、ことを特徴とする。
【００１５】
本発明の他の側面によれば、所定の通信プロトコルにより通信装置間の通信を可能にする相互接続装置であって、一方の通信装置から受信した第１メッセージと、当該第１メッセージに基づいて他方の通信装置へ送信された第２メッセージに対する応答メッセージと、からの前記一方および他方の通信装置がそれぞれ準拠する前記通信プロトコルの第１バージョンおよび第２バージョンを判定するバージョン判定手段と、前記通信プロトコルのバージョンとそのヘッダとを前記通信装置間で一致させた第３メッセージを生成するメッセージ生成手段と、を有し、前記第３メッセージを前記他方の通信装置へ送信することで前記通信装置間を相互接続することを特徴とする。
【発明の効果】
【００１６】
以上説明したように、本発明によれば、通信プロトコルのバージョンだけでなくヘッダ情報も整合させることができるために、通信装置間、たとえばクライアントとサーバとの間で高い接続性を達成することができる。また、将来、通信プロトコルの新しいバージョンが追加され下位互換性が低いプロトコルとなった場合でも高い接続性を確保することが可能である。
【発明を実施するための最良の形態】
【００１７】
１．装置構成
図１は本発明の一実施形態による相互接続装置の機能的構成を示すブロック図である。相互接続装置１０にはデータ受信部１０１およびデータ送信部１０２が設けられ、ネットワークを介してクライアント１１およびサーバ１２の各々と通信可能である。
【００１８】
ＨＴＴＰリクエスト保存部１０３はクライアント１１から受信したＨＴＴＰリクエストを保存するためのメモリである。ＨＴＴＰ−ＨＥＡＤ生成部１０４は、サーバ１２のＨＴＴＰバージョンを取得するためのＨＴＴＰ−ＨＥＡＤリクエストを生成し、ＨＴＴＰ−ＨＥＡＤリクエストはデータ送信部１０２からサーバ１２へ送信される。
【００１９】
ＨＴＴＰ−ＨＥＡＤ解析部１０５は、サーバ１２から受信したＨＴＴＰ−ＨＥＡＤリクエストに対するレスポンスを解析し、サーバ１２のＨＴＴＰバージョンを取得する。ＨＴＴＰバージョン判定部１０６は、取得したサーバ１２のＨＴＴＰバージョンから生成するＨＴＴＰリクエストのバージョンを決定する。ＨＴＴＰリクエスト生成部１０７は、ＨＴＴＰリクエスト保存部１０３に保存しているＨＴＴＰリクエストをＨＴＴＰバージョン判定部１０６より指示されたＨＴＴＰバージョンに改造する。
【００２０】
なお、図１は相互接続装置１０の機能的な構成を示しており、全体的な動作制御は図示されていない制御部により実行される。また、ＨＴＴＰ−ＨＥＡＤ生成部１０４、ＨＴＴＰ−ＨＥＡＤ解析部１０５、ＨＴＴＰバージョン判定部１０６およびＨＴＴＰリクエスト生成部１０７はハードウェアにより回路構成されても良いし、プログラム制御プロセッサ上でプログラムを実行することにより同様の機能をソフトウェア的に実現しても良い。
【００２１】
２．動作
図２は本実施形態による相互接続装置の動作を示すフローチャートである。まず、データ受信部１０１がクライアント１１からＨＴＴＰリクエストを受信すると（ステップＳ２０１）、制御部はＨＴＴＰリクエストをＨＴＴＰリクエスト保存部１０３に保存する（ステップＳ２０２）。
【００２２】
続いて、ＨＴＴＰ−ＨＥＡＤ生成部１０４は、サーバ１２のＨＴＴＰバージョンを取得するために、クライアント１１から受信したＨＴＴＰリクエストのバージョン以下のバージョンによりＨＴＴＰ−ＨＥＡＤリクエストを生成してデータ送信部１０２を通してサーバ１２へ送信し（ステップＳ２０３）、サーバ１２からの応答を待つ。
【００２３】
サーバ１２からレスポンスを受信すると（ステップＳ２０４）、ＨＴＴＰ−ＨＥＡＤ解析部１０５はそのレスポンスを解析する。ＨＴＴＰバージョン判定部１０６は解析結果からサーバ１２のＨＴＴＰバージョンを判定し（ステップＳ２０５）、ＨＴＴＰリクエスト生成部１０７へ通知する。
【００２４】
ＨＴＴＰリクエスト生成部１０７は、サーバ１２のＨＴＴＰバージョンと、ＨＴＴＰリクエスト保存部１０３に保存しているクライアント１１のＨＴＴＰリクエストとに基づいて、両者のＨＴＴＰバージョンを比較する。サーバ１２のＨＴＴＰバージョンがクライアント１１のＨＴＴＰバージョンと同一あるいは上位でサポートできる場合には問題が生じないので、クライアント１１のＨＴＴＰリクエストをそのまま送信用のＨＴＴＰリクエストとして使用する。
【００２５】
他方、サーバ１２が下位バージョンの場合には、ＨＴＴＰリクエスト生成部１０７はクライアント１１のＨＴＴＰリクエストから上位バージョン用のヘッダを削除し、下位バージョンへバージョンおよびヘッダ情報を適合させたＨＴＴＰリクエストを生成する（ステップＳ２０６）。
【００２６】
こうしてＨＴＴＰリクエスト生成部１０７から出力されたＨＴＴＰリクエストがデータ送信部１０２からサーバ１２へ送信される（ステップＳ２０７）。これに対するレスポンスをサーバ１２から受信すると（ステップＳ２０８）、そのＨＴＴＰレスポンスをクライアント１１へ送信する（ステップＳ２０９）。
【００２７】
上述したように、クライアント１１とサーバ１２との間を接続する際に、両者のＨＴＴＰバージョンだけでなくヘッダ情報も整合させることで、接続不能の事態を回避することができ高い接続性を得ることができる。
【００２８】
なお、本実施形態ではサーバ１２のＨＴＴＰバージョン取得のためにＨＥＡＤメソッドを使用しているが、その他のＧＥＴ、ＰＯＳＴ、ＴＲＡＣＥ、ＰＵＴあるいはＤＥＬＴＥメソッドを使用する場合も、ＨＥＡＤメソッドと同様にサーバ１２のバージョンを取得することが可能である。
【実施例１】
【００２９】
以下、説明を煩雑にしないためにＨＴＴＰバージョンをＨＴＴＰ／１．０およびＨＴＴＰ／１．１の２種類とする。
【００３０】
図３は本発明の第１実施例による相互接続装置の動作を説明するためのシーケンス図である。ここでは、本実施例による相互接続装置がルータ１０に組み込まれ、クライアント１１とサーバ１２との間を中継しているものとする。
【００３１】
まず、クライアント１１はＨＴＴＰ／１．１リクエストを送信する（Ｓ１１）。クライアント１１からＨＴＴＰ／１．１ＨＴＴＰリクエストを受信すると、ルータ１０はＨＴＴＰ／１．１以下のバージョンであるＨＴＴＰ／１．０のＨＥＡＤリクエストを生成し、ＨＴＴＰリクエストで指定されたサーバ１２へ送信する（Ｓ１２）。その後、サーバ１２からＨＴＴＰレスポンスを受信すると（Ｓ１３）、そのＨＴＴＰレスポンスからサーバ１２のＨＴＴＰバージョンを取得する。
【００３２】
ルータ１０のＨＴＴＰリクエスト生成部１０７は、上述したように、取得したサーバ１２のバージョンとクライアント１１から受信したＨＴＴＰリクエストとをバージョンおよびＨＴＴＰヘッダの両方を含めて一致させたＨＴＴＰリクエストを新たに生成し、サーバ１２へ送信する（Ｓ１４）。その後サーバ１２からＨＴＴＰリクエストを受信すると（Ｓ１５）、それをクライアント１１へ透過させる（Ｓ１６）。
【００３３】
ＨＴＴＰリクエスト生成部１０７が実行するバージョン情報およびヘッダ情報の制御方法を具体的に説明する。
【００３４】
図４はＨＴＴＰリクエスト生成部１０７が実行するバージョン情報およびヘッダ情報の制御方法を説明するためのＨＴＴＰメッセージを示す模式的フォーマット図である。まず、図４（ａ）に示すように、ＨＴＴＰリクエストメッセージのフォーマットは、先頭行のリクエストラインに、メソッド、ＵＲＬのパスおよびＨＴＴＰバージョンが指定され、続く行にヘッダが１行ずつ続く。そして設定するヘッダの最後にヘッダとデータとの区切りを示す改行を挟んでデータ部分が続く。
【００３５】
図４（ｂ）に示すように、クライアント１１からＨＴＴＰ／１．１リクエスト３０１を受信すると、ルータ１０はそれをＨＴＴＰリクエスト保存部１０３に格納する。そして、サーバ１２のＨＴＴＰバージョンがＨＴＴＰ／１．０であると判定されると、ＨＴＴＰリクエスト生成部１０７は、バージョンをＨＴＴＰ／１．１からＨＴＴＰ／１．０へ変換し、さらにＨＴＴＰ／１．１リクエスト３０１のヘッダを検索してＨＴＴＰ／１．１のヘッダ情報が存在する場合はこれを削除する。ここではＨｏｓｔヘッダとＡｃｃｅｐｔ−Ｌａｎｇｕａｇｅヘッダは、ＨＴＴＰ／１．１のヘッダであるから削除される。ただし、ＡｕｔｈｏｒｉｚａｔｉｏｎヘッダとＣｏｎｔｅｎｔ−ＬｅｎｇｔｈヘッダはＨＴＴＰ／１．０とＨＴＴＰ／１．１に共通のヘッダであるから保持される。以上が図２のステップＳ２０６に対応する。こうして新たなＨＴＴＰ／１．０リクエスト３０２が生成され、サーバ１２に送信される。
【００３６】
なお、ＨＴＴＰバージョンとヘッダの対応およびリクエストメッセージのフォーマットの詳細は、以下のＲＦＣを参照のこと：
ＨＴＴＰ／１．０：ＲＦＣ１９４５の４．３章、５．２章、７．１章
ＨＴＴＰ／１．１：ＲＦＣ２６１６の４．５章、５．３章、７．１章。
【００３７】
上述したように、ルータ１０の処理は、取得したクライアント１１およびサーバ１２のバージョンによって異なる。
【００３８】
図５はサーバの下位のＨＴＴＰバージョン１．０である場合のルータの処理を示すシーケンス図である。クライアント１１からＨＴＴＰ／１．１リクエストを受信することでクライアント１１のＨＴＴＰバージョンをＨＴＴＰ／１．１であると判定し（Ｓ２１）、続いてサーバ１２のＨＴＴＰバージョンがＨＴＴＰ／１．０であると判定する（Ｓ２２，Ｓ２３）。これよりＨＴＴＰリクエスト生成部１０７は、クライアント１１から受信したＨＴＴＰ／１．１リクエストをＨＴＴＰバージョン１．０に変換し、ＨＴＴＰ／１．１リクエストからＨＴＴＰ／１．１用のヘッダを削除する。こうして作成したＨＴＴＰ／１．０リクエストをサーバ１２に送信する（Ｓ２４）。
【００３９】
その後、ルータ１０は、サーバ１２からＨＴＴＰ／１．０レスポンスを受信すると（Ｓ２５）、それをクライアント１１へ透過的に送信する（Ｓ２６）。
【００４０】
図６はサーバの同一ＨＴＴＰバージョン１．１である場合のルータの処理を示すシーケンス図である。クライアント１１からＨＴＴＰ／１．１リクエストを受信することでクライアント１１のＨＴＴＰバージョンをＨＴＴＰ／１．１であると判定し（Ｓ２３１、続いてサーバ１２のＨＴＴＰバージョンがＨＴＴＰ／１．１であると判定する（Ｓ３２，Ｓ３３）。両者は同一バージョンであるから、ＨＴＴＰリクエスト生成部１０７は、クライアント１１から受信したＨＴＴＰ／１．１リクエストをサーバ１２へ送信する（Ｓ３４）。その後、ルータ１０は、サーバ１２からＨＴＴＰ／１．１のレスポンスを受信すると（Ｓ３５）、それをクライアント１１へ透過的に送信する（Ｓ３６）。
【実施例２】
【００４１】
将来、ＨＴＴＰのバージョンが追加された場合も本発明は適用可能である。以下、ＨＴＴＰ／１．０およびＨＴＴＰ／１．１に加えてＨＴＴＰ／２．０が追加され、計３種類のバージョンが存在する場合を一例として説明する。４種類以上のバージョンが存在する場合でも同様である。
【００４２】
図７は本発明の第２実施例による相互接続装置の動作を説明するためのシーケンス図である。ここでは、本実施例による相互接続装置がルータ１０に組み込まれ、クライアント１１とサーバ１２との間を中継しているものとする。
【００４３】
まず、クライアント１１はＨＴＴＰ／１．１リクエストを送信する（Ｓ４１）。クライアント１１からＨＴＴＰリクエストを受信すると、ルータ１０のＨＴＴＰ−ＨＥＡＤ生成部１０４は、サーバ１２のＨＴＴＰバージョンを正確に取得するために、ＨＴＴＰ−ＨＥＡＤリクエストを各バージョンに分けて送信する。すなわち、可能性のある３種類のＨＥＡＤリクエスト：ＨＴＴＰ／１．０−、ＨＴＴＰ／１．１−、およびＨＴＴＰ／２．０−ＨＥＡＤリクエスト、を送信する（Ｓ４２、Ｓ４３、Ｓ４４）。
【００４４】
これらに応答してサーバ１２からレスポンスを受信するが（Ｓ４５、Ｓ４６、Ｓ４７）、ルータ１０のＨＴＴＰバージョン判定部１０６は、これらレスポンスのバージョンとステータスコードの両方を参照して、サーバ１２に送信すべきＨＴＴＰリクエストのバージョンを決定する。ここでは、ＨＴＴＰ／１．０のリクエスト（Ｓ４２）に対して、ステータスコード“５０５”（ＨＴＴＰ Ｖｅｒｓｉｏｎ Ｎｏｔ Ｓｕｐｐｏｔｅｄ：リクエストしたＨＴＴＰバージョンは未サポート）を通知しているために（Ｓ４５）、サーバ１２はＨＴＴＰ／１．０を受け付けない事がわかる。また、ＨＴＴＰ／１．１のリクエスト（Ｓ４３）に対して、ＨＴＴＰ／２．０のステータスコード“２００”（ＯＫ：リクエストを正常に受け付けた）で応答し（Ｓ４６）、ＨＴＴＰ／２．０のリクエスト（Ｓ４４）に対しても同様にＨＴＴＰ／２．０のステータスコード“２００”で応答している（Ｓ４７）。これにより、サーバ１２に送信する最適なリクエストはＨＴＴＰ／２．０と判定可能である。その判定を元に、ＨＴＴＰリクエスト生成部１０７はＨＴＴＰ／２．０のリクエストを生成してサーバ１２に送信する（Ｓ４８）。ルータ１０は、サーバ１２からＨＴＴＰ／２．０のレスポンスを受信すると（Ｓ４９）、それをクライアント１１へ透過的に送信する（Ｓ５０）。
【００４５】
このように、将来ＨＴＴＰバージョンが追加され、下位互換性が低いプロトコルとなった場合でも、本発明によれば高い接続性を確保することが可能となる。
【００４６】
なお、上記第１および第２実施例ではルータ１０に本実施例による相互接続装置を実装したが、データを送受信する機能が存在する通信装置であれば良く、パーソナルコンピュータ（ＰＣ）などを用いても実現可能である。
【産業上の利用可能性】
【００４７】
本発明は通信装置間のデータ通信を中継して両者を相互接続する中継装置一般に適用可能であり、たとえばクライアントとサーバを中継するルータ、ゲートウェイなどに適用できる。
【図面の簡単な説明】
【００４８】
【図１】本発明の一実施形態による相互接続装置の機能的構成を示すブロック図である。
【図２】本実施形態による相互接続装置の動作を示すフローチャートである。
【図３】本発明の第１実施例による相互接続装置の動作を説明するためのシーケンス図である。
【図４】ＨＴＴＰリクエスト生成部１０７が実行するバージョン情報およびヘッダ情報の制御方法を説明するためのＨＴＴＰメッセージを示す模式的フォーマット図である。
【図５】サーバの下位のＨＴＴＰバージョン１．０である場合のルータの処理を示すシーケンス図である。
【図６】サーバの同一ＨＴＴＰバージョン１．１である場合のルータの処理を示すシーケンス図である。
【図７】本発明の第２実施例による相互接続装置の動作を説明するためのシーケンス図である。
【符号の説明】
【００４９】
１０ 相互接続装置（ルータ）
１１ クライアント
１２ サーバ
１０１ データ受信部
１０２ データ送信部
１０３ ＨＴＴＰリクエスト保存部
１０４ ＨＴＴＰ−ＨＥＡＤ生成部
１０５ ＨＴＴＰ−ＨＥＡＤ解析部
１０６ ＨＴＴＰバージョン判定部
１０７ ＨＴＴＰリクエスト生成部
【特許請求の範囲】
【請求項１】
所定の通信プロトコルにより通信装置間の通信を可能にする相互接続方法において、
ａ）前記通信装置の各々が準拠する前記通信プロトコルのバージョンを判定し、
ｂ）前記通信プロトコルのバージョンとそのヘッダとを前記通信装置間で一致させ、
ｃ）前記一致させた通信プロトコルのバージョンおよびヘッダを用いて前記通信装置間を相互接続する、
ことを特徴とする相互接続方法。
【請求項２】
前記ｂ）において、
前記通信プロトコルの上位バージョンを下位バージョンへ変換し、前記上位バージョンのみに関係するヘッダ情報を削除することで、前記下位バージョンに従った新たなヘッダのメッセージを生成することを特徴とする請求項１に記載の相互接続方法。
【請求項３】
前記ａ）において、
一方の通信装置から受信した第１メッセージから当該一方の通信装置が準拠する通信プロトコルの第１バージョンを判定し、
前記第１バージョン以下のバージョンの第２メッセージを他方の通信装置へ送信し、
前記他方の通信装置から受信した前記第２メッセージに対する応答メッセージから当該他方の通信装置が準拠する通信プロトコルの第２バージョンを判定する、
ことを特徴とする請求項１または２に記載の相互接続方法。
【請求項４】
前記ａ）において、
一方の通信装置から受信した第１メッセージから当該一方の通信装置が準拠する通信プロトコルの第１バージョンを判定し、
予め定められた複数のバージョンの各々に従った複数の第２メッセージを他方の通信装置へそれぞれ送信し、
前記他方の通信装置から前記複数の第２メッセージのそれぞれに対する応答メッセージを受信すると、これら応答メッセージから当該他方の通信装置が準拠する通信プロトコルの第２バージョンを判定する、
ことを特徴とする請求項１または２に記載の相互接続方法。
【請求項５】
所定の通信プロトコルにより通信装置間の通信を可能にする相互接続装置において、
一方の通信装置から受信した第１メッセージと、当該第１メッセージに基づいて他方の通信装置へ送信された第２メッセージに対する応答メッセージと、からの前記一方および他方の通信装置がそれぞれ準拠する前記通信プロトコルの第１バージョンおよび第２バージョンを判定するバージョン判定手段と、
前記通信プロトコルのバージョンとそのヘッダとを前記通信装置間で一致させた第３メッセージを生成するメッセージ生成手段と、
を有し、前記第３メッセージを前記他方の通信装置へ送信することで前記通信装置間を相互接続することを特徴とする相互接続装置。
【請求項６】
前記メッセージ生成手段は、第１バージョンおよび第２バージョンのうち上位バージョンを下位バージョンへ変換し、前記上位バージョンのみに関係するヘッダ情報を下位バージョンのメッセージヘッダから削除することで、前記下位バージョンに従った新たなヘッダの前記第３メッセージを生成することを特徴とする請求項５に記載の相互接続装置。
【請求項７】
請求項５または６に記載の相互接続装置を含むルータ。
【請求項８】
所定の通信プロトコルにより通信装置間の通信を可能にする相互接続機能をコンピュータに実現するためのプログラムにおいて、
前記通信装置の各々が準拠する前記通信プロトコルのバージョンを判定する判定ステップと、
前記通信プロトコルのバージョンとそのヘッダとを前記通信装置間で一致させる整合ステップと、
前記一致させた通信プロトコルのバージョンおよびヘッダを用いて前記通信装置間を相互接続するステップと、
を有することを特徴とするプログラム。
【請求項９】
前記整合ステップは、前記通信プロトコルの上位バージョンを下位バージョンへ変換し、前記上位バージョンのみに関係するヘッダ情報を削除することで、前記下位バージョンに従った新たなヘッダのメッセージを生成することを特徴とする請求項８に記載のプログラム。
【請求項１】
所定の通信プロトコルにより通信装置間の通信を可能にする相互接続方法において、
ａ）前記通信装置の各々が準拠する前記通信プロトコルのバージョンを判定し、
ｂ）前記通信プロトコルのバージョンとそのヘッダとを前記通信装置間で一致させ、
ｃ）前記一致させた通信プロトコルのバージョンおよびヘッダを用いて前記通信装置間を相互接続する、
ことを特徴とする相互接続方法。
【請求項２】
前記ｂ）において、
前記通信プロトコルの上位バージョンを下位バージョンへ変換し、前記上位バージョンのみに関係するヘッダ情報を削除することで、前記下位バージョンに従った新たなヘッダのメッセージを生成することを特徴とする請求項１に記載の相互接続方法。
【請求項３】
前記ａ）において、
一方の通信装置から受信した第１メッセージから当該一方の通信装置が準拠する通信プロトコルの第１バージョンを判定し、
前記第１バージョン以下のバージョンの第２メッセージを他方の通信装置へ送信し、
前記他方の通信装置から受信した前記第２メッセージに対する応答メッセージから当該他方の通信装置が準拠する通信プロトコルの第２バージョンを判定する、
ことを特徴とする請求項１または２に記載の相互接続方法。
【請求項４】
前記ａ）において、
一方の通信装置から受信した第１メッセージから当該一方の通信装置が準拠する通信プロトコルの第１バージョンを判定し、
予め定められた複数のバージョンの各々に従った複数の第２メッセージを他方の通信装置へそれぞれ送信し、
前記他方の通信装置から前記複数の第２メッセージのそれぞれに対する応答メッセージを受信すると、これら応答メッセージから当該他方の通信装置が準拠する通信プロトコルの第２バージョンを判定する、
ことを特徴とする請求項１または２に記載の相互接続方法。
【請求項５】
所定の通信プロトコルにより通信装置間の通信を可能にする相互接続装置において、
一方の通信装置から受信した第１メッセージと、当該第１メッセージに基づいて他方の通信装置へ送信された第２メッセージに対する応答メッセージと、からの前記一方および他方の通信装置がそれぞれ準拠する前記通信プロトコルの第１バージョンおよび第２バージョンを判定するバージョン判定手段と、
前記通信プロトコルのバージョンとそのヘッダとを前記通信装置間で一致させた第３メッセージを生成するメッセージ生成手段と、
を有し、前記第３メッセージを前記他方の通信装置へ送信することで前記通信装置間を相互接続することを特徴とする相互接続装置。
【請求項６】
前記メッセージ生成手段は、第１バージョンおよび第２バージョンのうち上位バージョンを下位バージョンへ変換し、前記上位バージョンのみに関係するヘッダ情報を下位バージョンのメッセージヘッダから削除することで、前記下位バージョンに従った新たなヘッダの前記第３メッセージを生成することを特徴とする請求項５に記載の相互接続装置。
【請求項７】
請求項５または６に記載の相互接続装置を含むルータ。
【請求項８】
所定の通信プロトコルにより通信装置間の通信を可能にする相互接続機能をコンピュータに実現するためのプログラムにおいて、
前記通信装置の各々が準拠する前記通信プロトコルのバージョンを判定する判定ステップと、
前記通信プロトコルのバージョンとそのヘッダとを前記通信装置間で一致させる整合ステップと、
前記一致させた通信プロトコルのバージョンおよびヘッダを用いて前記通信装置間を相互接続するステップと、
を有することを特徴とするプログラム。
【請求項９】
前記整合ステップは、前記通信プロトコルの上位バージョンを下位バージョンへ変換し、前記上位バージョンのみに関係するヘッダ情報を削除することで、前記下位バージョンに従った新たなヘッダのメッセージを生成することを特徴とする請求項８に記載のプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００７−２６５３５６（Ｐ２００７−２６５３５６Ａ）
【公開日】平成１９年１０月１１日（２００７．１０．１１）
【国際特許分類】
【出願番号】特願２００６−９３２６２（Ｐ２００６−９３２６２）
【出願日】平成１８年３月３０日（２００６．３．３０）
【出願人】（０００１９７３６６）ＮＥＣアクセステクニカ株式会社 (1,236)
【Ｆターム（参考）】
【公開日】平成１９年１０月１１日（２００７．１０．１１）
【国際特許分類】
【出願日】平成１８年３月３０日（２００６．３．３０）
【出願人】（０００１９７３６６）ＮＥＣアクセステクニカ株式会社 (1,236)
【Ｆターム（参考）】
[ Back to top ]