特許 7562308 通信システム、サーバー装置、クライアント装置及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-09-27

(45)【発行日】2024-10-07

(54)【発明の名称】通信システム、サーバー装置、クライアント装置及びプログラム

(51)【国際特許分類】

   H04L 61/103 20220101AFI20240930BHJP

【ＦＩ】

H04L61/103

【請求項の数】 8

(21)【出願番号】P 2020109603

(22)【出願日】2020-06-25

(65)【公開番号】P2022006989

(43)【公開日】2022-01-13

【審査請求日】2023-06-13

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(73)【特許権者】

【識別番号】598076591

【氏名又は名称】東芝インフラシステムズ株式会社

(74)【代理人】

【識別番号】110003708

【氏名又は名称】弁理士法人鈴榮特許綜合事務所

(72)【発明者】

【氏名】大西 直哉

(72)【発明者】

【氏名】松山 拓紀

(72)【発明者】

【氏名】中谷 博司

【審査官】速水 雄太

(56)【参考文献】

【文献】特開２０１８－０４６３９２（ＪＰ，Ａ）

【文献】特開２０１９－０５４４９６（ＪＰ，Ａ）

【文献】特開２００４－２０６３９７（ＪＰ，Ａ）

【文献】特開２０１２－２４８０８３（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ １２／００－１２／６６

４１／００－１０１／６９５

(57)【特許請求の範囲】

【請求項1】

第１の装置及び第２の装置を含み、
前記第１の装置は、
送信先ＩＰアドレス、送信先ＭＡＣアドレス、及び送信先ポート番号を用いて第１の所定の関数により第１の送信側宛先符号を生成する第１の送信側生成部と、
前記第１の送信側宛先符号を付与した要求データを前記第２の装置に送信する第１の通信部と、を備え、
前記第２の装置は、
前記要求データを受信する第２の通信部と、
前記第２の装置のＩＰアドレス、前記第２の装置のＭＡＣアドレス、及び前記第２の装置のアプリケーションソフトウェアが使用するポート番号を用いて前記第１の所定の関数により第１の受信側宛先符号を生成する第２の受信側生成部と、
前記第１の受信側宛先符号と、前記要求データに付与された前記第１の送信側宛先符号が一致する場合、前記要求データに基づく処理を行い、一致しない場合、前記要求データに基づく処理をしない、第２の処理部と、を備える、通信システム。

【請求項2】

前記第２の処理部は、前記要求データのヘッダーの一部を入れ替えることで、前記要求データに対する応答である応答データのヘッダーを生成し、
前記第２の通信部は、前記応答データを前記第１の装置に送信する、請求項１に記載の通信システム。

【請求項3】

前記第２の処理部は、前記要求データのヘッダーの一部をＳＩＭＤ演算によって入れ替える、請求項２に記載の通信システム。

【請求項4】

前記第１の所定の関数は、ハッシュ関数である、請求項１乃至請求項３のいずれか１項に記載の通信システム。

【請求項5】

前記第１の受信側宛先符号及び前記第１の送信側宛先符号のビット長は、前記第２の装置のＯＳのアーキテクチャと同じビット長である、請求項１乃至請求項４のいずれか１項に記載の通信システム。

【請求項6】

前記第１の装置は、
前記第１の装置のＩＰアドレス、前記第１の装置のＭＡＣアドレス、及び前記第１の装置のアプリケーションソフトウェアが使用するポート番号を用いて第２の所定の関数により第２の受信側宛先符号を生成する第１の受信側生成部をさらに備え、
前記第２の装置は、
送信先ＩＰアドレス、送信先ＭＡＣアドレス、及び送信先ポート番号を用いて前記第２の所定の関数により第２の送信側宛先符号を生成する第２の送信側生成部をさらに備え、
前記第２の通信部は、前記要求データに対する応答である応答データに前記第２の送信側宛先符号を付与して前記第１の装置に送信し、
前記第１の装置は、
前記第２の受信側宛先符号と、前記要求データに付与された前記第１の送信側宛先符号が一致する場合、前記要求データに基づく処理を行い、一致しない場合、前記要求データに基づく処理をしない、第２の処理部と、を備える、請求項１乃至請求項５のいずれか１項に記載の通信システム。

【請求項7】

要求データを受信するサーバー通信部と、
サーバー装置のＩＰアドレス、前記サーバー装置のＭＡＣアドレス、及び前記サーバー装置のアプリケーションソフトウェアが使用するポート番号を用いて第１の所定の関数により第１の受信側宛先符号を生成するサーバー受信側生成部と、
前記第１の受信側宛先符号と、前記要求データに付与されたクライアント送信側宛先符号が一致する場合、前記要求データに基づく処理を行い、一致しない場合、前記要求データに基づく処理をしない、サーバー処理部と、を備えるサーバー装置。

【請求項8】

サーバー装置が備えるプロセッサーを、
サーバー装置のＩＰアドレス、前記サーバー装置のＭＡＣアドレス、及び前記サーバー装置のアプリケーションソフトウェアが使用するポート番号を用いて第１の所定の関数により第１の受信側宛先符号を生成するサーバー受信側生成部と、
前記第１の受信側宛先符号と、受信された要求データに付与されたクライアント送信側宛先符号が一致する場合、前記要求データに基づく処理を行い、一致しない場合、前記要求データに基づく処理をしない、サーバー処理部と、して機能させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、通信システム、サーバー装置、クライアント装置及びプログラムに関する。

【背景技術】

【0002】

ネットワークインタフェースの遅延を低減させるため、ＯＳ（operating system）のカーネル処理をバイパスする方法がある。一般的な計算機システムでは、ＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）及びＵＤＰ（User Datagram Protocol）／ＩＰの処理をＯＳのカーネルが処理するため、データの転送、システムコールの発行、及びコンテキストスイッチの発生などでネットワークインタフェースに遅延が発生する。当該遅延への対応として、計算機システムは、カーネル処理をバイパスすることで、データの転送、システムコールの発行、及びコンテキストスイッチの発生などを低減させ、ネットワークインタフェースの遅延を低減することができるとされている。

【0003】

クライアントサーバー型の時間制約のあるシステムにおいて、応答時間を短縮させるため、ＯＳのカーネルをバイパスしネットワークインタフェース遅延を低減させる方法を用いることができる。しかしながら、イーサネット（登録商標）などの汎用なネットワークを用いるシステムがカーネル処理のバイパスを行うと、アプリケーション層でＴＣＰ／ＩＰ及びＵＤＰ／ＩＰなどの汎用プロトコルの処理を行うこととなり、処理時間が増加してしまう。また、多数のクライアントが単一のサーバーにアクセスをする場合、サーバー側での汎用プロトコル処理の負荷が高くなり、処理時間がさらに増加する可能性がある。
また、サーバーは、クライアントにパケットを返答する際、アプリケーション層でＩＰヘッダー及びＵＤＰヘッダーなどを生成する必要があり、返答処理に時間を要してしまう。

【先行技術文献】

【特許文献】

【0004】

【文献】特許第５８６９１３５号公報

【発明の概要】

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

【0005】

本発明の実施形態が解決しようとする課題は、汎用プロトコルを用いる場合でもカーネル処理のバイパスにより遅延を低減することができる通信システム、サーバー装置、クライアント装置及びプログラムを提供することである。

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

【0006】

実施形態の通信システムは、第１の装置及び第２の装置を含む。前記第１の装置は、第１の送信側生成部及び第１の通信部を備える。第１の送信側生成部は、送信先ＩＰアドレス、送信先ＭＡＣアドレス、及び送信先ポート番号を用いて第１の所定の関数により第１の送信側宛先符号を生成する。第１の通信部は、前記第１の送信側宛先符号を付与した要求データを前記第２の装置に送信する。第２の装置は、第２の通信部、第２の受信側生成部及び第２の処理部を備える。第２の通信部は、前記要求データを受信する。第２の受信側生成部は、前記第２の装置のＩＰアドレス、前記第２の装置のＭＡＣアドレス、及び前記第２の装置のアプリケーションソフトウェアが使用するポート番号を用いて前記第１の所定の関数により第１の受信側宛先符号を生成する。第２の処理部は、前記第１の受信側宛先符号と、前記要求データに付与された前記第１の送信側宛先符号が一致する場合、前記要求データに基づく処理を行い、一致しない場合、前記要求データに基づく処理をしない。

【図面の簡単な説明】

【0007】

【図1】第１実施形態に係る通信システム及び当該通信システムに含まれる構成要素の要部構成の一例を示すブロック図。

【図2】図１中のクライアント装置のプロセッサーによる第１実施形態に係る処理の一例を示すフローチャート。

【図3】図１中のサーバー装置のプロセッサーによる第１実施形態に係る処理の一例を示すフローチャート。

【図4】第１実施形態に係る通信システムの情報の流れの一例を示すシーケンス図。

【図5】要求パケットの一例を示す図。

【図6】宛先置換処理及び応答パケットについて説明するための図。

【図7】ＳＩＭＤ演算による宛先置換処理の例を示す図。

【図8】第２実施形態に係る通信システム及び当該通信システムに含まれる構成要素の要部構成の一例を示すブロック図。

【図9】図８中のクライアント装置のプロセッサーによる第２実施形態に係る処理の一例を示すフローチャート。

【図10】図８中のサーバー装置のプロセッサーによる第２実施形態に係る処理の一例を示すフローチャート。

【図11】第２実施形態に係る通信システムの情報の流れの一例を示すシーケンス図。

【発明を実施するための形態】

【0008】

以下、いくつかの実施形態に係る通信システムについて図面を用いて説明する。なお、以下の実施形態の説明に用いる各図面は、各部の縮尺を適宜変更している場合がある。また、以下の実施形態の説明に用いる各図面は、説明のため、構成を省略して示している場合がある。また、各図面及び本明細書中において、同一の符号は同様の要素を示す。
〔第１実施形態〕
図１は、第１実施形態に係る通信システム１及び通信システム１に含まれる構成要素の要部構成の一例を示すブロック図である。通信システム１は、一例として、サーバー装置１００及びクライアント装置２００を含む。なお、図１にはクライアント装置２００を１つのみ示すが、典型的にはクライアント装置２００は、複数ある。また、サーバー装置１００は、複数あっても良い。

【0009】

サーバー装置１００及びクライアント装置２００は、ネットワークＮＷに接続する。ネットワークＮＷは、例えば、インターネットを含む通信網である。ネットワークＮＷは、例えば、ＷＡＮ（wide area network）を含む通信網である。ネットワークＮＷは、例えば、イントラネットなどのプライベートネットワークを含む通信網である。ネットワークＮＷは、例えば、ＬＡＮ（local area network）を含む通信網である。ネットワークＮＷは、例えば、専用線を含む通信網である。また、ネットワークＮＷは、無線回線でも良いし有線回線でも良く、無線回線と有線回線とが混在していても良い。また、ネットワークＮＷは、公衆携帯電話網などを含む通信網であっても良い。

【0010】

サーバー装置１００は、例えば、クライアントサーバーモデルのネットワークアーキテクチャにおけるサーバーとして動作する装置である。サーバー装置１００は、一例として、プロセッサー１１０、ＲＯＭ（read-only memory）１２０、ＲＡＭ（random-access memory）１３０、補助記憶装置１４０及び通信インターフェース１５０を含む。そして、バス１６０などが、これら各部を接続する。サーバー装置１００は、第２の装置の一例である。

【0011】

プロセッサー１１０は、サーバー装置１００の動作に必要な演算及び制御などの処理を行うコンピューターの中枢部分に相当する。プロセッサー１１０は、ＲＯＭ１２０又は補助記憶装置１４０などに記憶されたファームウェア、ＯＳなどのシステムソフトウェア及びアプリケーションソフトウェアなどのプログラムに基づいて、サーバー装置１００の各種の機能を実現するべく各部を制御する。また、プロセッサー１１０は、当該プログラムに基づいて後述する処理を実行する。なお、当該プログラムの一部又は全部は、プロセッサー１１０の回路内に組み込まれていても良い。プロセッサー１１０は、例えば、ＣＰＵ（central processing unit）、ＭＰＵ（micro processing unit）、ＳｏＣ（system on a chip）、ＤＳＰ（digital signal processor）、ＧＰＵ（graphics processing unit）、ＡＳＩＣ（application specific integrated circuit）、ＰＬＤ（programmable logic device）又はＦＰＧＡ（field-programmable gate array）などである。あるいは、プロセッサー１１０は、これらのうちの複数を組み合わせたものである。

【0012】

ＲＯＭ１２０は、プロセッサー１１０を中枢とするコンピューターの主記憶装置に相当する。ＲＯＭ１２０は、専らデータの読み出しに用いられる不揮発性メモリである。ＲＯＭ１２０は、上記のプログラムのうち、例えばファームウェアなどを記憶する。また、ＲＯＭ１２０は、プロセッサー１１０が各種の処理を行う上で使用するデータなども記憶する。

【0013】

ＲＡＭ１３０は、プロセッサー１１０を中枢とするコンピューターの主記憶装置に相当する。ＲＡＭ１３０は、データの読み書きに用いられるメモリである。ＲＡＭ１３０は、プロセッサー１１０が各種の処理を行う上で一時的に使用するデータを記憶するワークエリアなどとして利用される。ＲＡＭ１３０は、典型的には揮発性メモリである。

【0014】

補助記憶装置１４０は、プロセッサー１１０を中枢とするコンピューターの補助記憶装置に相当する。補助記憶装置１４０は、例えばＥＥＰＲＯＭ（electric erasable programmable read-only memory）、ＨＤＤ（hard disk drive）又はフラッシュメモリなどである。補助記憶装置１４０は、上記のプログラムのうち、例えば、システムソフトウェア及びアプリケーションソフトウェアなどを記憶する。また、補助記憶装置１４０は、プロセッサー１１０が各種の処理を行う上で使用するデータ、プロセッサー１１０での処理によって生成されたデータ及び各種の設定値などを記憶する。

【0015】

通信インターフェース１５０は、サーバー装置１００がネットワークＮＷなどを介して通信するためのインターフェースである。通信インターフェース１５０は、第２の通信部の一例である。通信インターフェース１５０は、サーバー通信部の一例である。

【0016】

バス１６０は、コントロールバス、アドレスバス及びデータバスなどを含み、サーバー装置１００の各部で授受される信号を伝送する。

【0017】

クライアント装置２００は、例えば、クライアントサーバーモデルのネットワークアーキテクチャにおけるクライアントとして動作する装置である。クライアント装置２００は、サーバー装置１００のクライアントとして動作する。クライアント装置２００は、例えば、ＰＣ（personal computer）、スマートホン、ＩｏＴ（internet of things）機器、自動改札機などの駅務機器、高速道路のＥＴＣ（electronic toll collection）ゲートの制御装置などの道路交通システム上の機器、プラント関連機器、製造機械、医療機器、健康器具、ゲーム機などの各種機器及び装置である。クライアント装置２００は、一例として、プロセッサー２１０、ＲＯＭ２２０、ＲＡＭ２３０、補助記憶装置２４０、通信インターフェース２５０、入力装置２６０及び表示装置２７０を含む。そして、バス２８０などが、これら各部を接続する。クライアント装置２００は、第１の装置の一例である。

【0018】

プロセッサー２１０は、クライアント装置２００の動作に必要な演算及び制御などの処理を行うコンピューターの中枢部分に相当する。プロセッサー２１０は、ＲＯＭ２２０又は補助記憶装置２４０などに記憶されたファームウェア、ＯＳなどのシステムソフトウェア及びアプリケーションソフトウェアなどのプログラムに基づいて、クライアント装置２００の各種の機能を実現するべく各部を制御する。また、プロセッサー２１０は、当該プログラムに基づいて後述する処理を実行する。なお、当該プログラムの一部又は全部は、プロセッサー２１０の回路内に組み込まれていても良い。プロセッサー２１０は、例えば、ＣＰＵ、ＭＰＵ、ＳｏＣ、ＤＳＰ、ＧＰＵ、ＡＳＩＣ、ＰＬＤ又はＦＰＧＡなどである。あるいは、プロセッサー２１０は、これらのうちの複数を組み合わせたものである。

【0019】

ＲＯＭ２２０は、プロセッサー２１０を中枢とするコンピューターの主記憶装置に相当する。ＲＯＭ２２０は、専らデータの読み出しに用いられる不揮発性メモリである。ＲＯＭ２２０は、上記のプログラムのうち、例えばファームウェアなどを記憶する。また、ＲＯＭ２２０は、プロセッサー２１０が各種の処理を行う上で使用するデータなども記憶する。

【0020】

ＲＡＭ２３０は、プロセッサー２１０を中枢とするコンピューターの主記憶装置に相当する。ＲＡＭ２３０は、データの読み書きに用いられるメモリである。ＲＡＭ２３０は、プロセッサー２１０が各種の処理を行う上で一時的に使用するデータを記憶するワークエリアなどとして利用される。ＲＡＭ２３０は、典型的には揮発性メモリである。

【0021】

補助記憶装置２４０は、プロセッサー２１０を中枢とするコンピューターの補助記憶装置に相当する。補助記憶装置２４０は、例えばＥＥＰＲＯＭ、ＨＤＤ又はフラッシュメモリなどである。補助記憶装置２４０は、上記のプログラムのうち、例えば、システムソフトウェア及びアプリケーションソフトウェアなどを記憶する。また、補助記憶装置２４０は、プロセッサー２１０が各種の処理を行う上で使用するデータ、プロセッサー２１０での処理によって生成されたデータ及び各種の設定値などを記憶する。

【0022】

通信インターフェース２５０は、クライアント装置２００がネットワークＮＷなどを介して通信するためのインターフェースである。通信インターフェース２５０は、第１の通信部の一例である。通信インターフェース２５０は、クライアント通信部の一例である。

【0023】

入力装置２６０は、クライアント装置２００の操作者による操作を受け付ける。入力装置２６０は、例えば、キーボード、キーパッド、タッチパッド又はマウスなどである。

【0024】

表示装置２７０は、クライアント装置２００の操作者に各種情報を通知するための画面を表示する。表示装置２７０は、例えば、液晶ディスプレイ又は有機ＥＬ（electro-luminescence）ディスプレイなどのディスプレイである。また、入力装置２６０及び表示装置２７０としては、タッチパネルを用いることもできる。すなわち、タッチパネルが備える表示パネルを表示装置２７０として、タッチパネルが備えるタッチパッドを入力装置２６０として用いることができる。

【0025】

バス２８０は、コントロールバス、アドレスバス及びデータバスなどを含み、クライアント装置２００の各部で授受される信号を伝送する。

【0026】

また、サーバー装置１００のプロセッサー１１０は、プログラムを実行することによりアプリケーション処理部１１１として機能する。アプリケーション処理部１１１は、補助記憶装置１４０などに記憶されたアプリケーションソフトウェアを実行する。アプリケーション処理部１１１は、一例として、ＡＲＰ（Address Resolution Protocol）処理部１１２、宛先判定部１１３及び宛先置換部１１４を含む。ＡＲＰ処理部１１２、宛先判定部１１３及び宛先置換部１１４は、いずれもアプリケーションソフトウェアによる処理を実行する。アプリケーション処理部１１１は、第２の処理部の一例である。アプリケーション処理部１１１は、サーバー処理部の一例である。

【0027】

ＡＲＰ処理部１１２は、ＡＲＰ処理などを行う。ＡＲＰ処理は、アドレス解決などのＡＲＰに関する処理である。
宛先判定部１１３は、受信パケットに含まれる第１の宛先符号から宛先を判定する。宛先判定部１１３は、第２の受信側生成部の一例である。宛先判定部１１３は、サーバー受信側生成部の一例である。
宛先置換部１１４は、受信パケットの送信元と送信先を置き換えて（入れ替えて）返答パケットを生成する。

【0028】

また、クライアント装置２００のプロセッサー１１０は、プログラムを実行することによりアプリケーション処理部２１１及びカーネル処理部２１２として機能する。

【0029】

アプリケーション処理部２１１は、アプリケーションソフトウェアを実行する。アプリケーション処理部２１１は、一例として、宛先符号付与部２１３を含む。アプリケーション処理部２１１は、第１の処理部の一例である。アプリケーション処理部２１１は、クライアント制御部の一例である。
宛先符号付与部２１３は、第１の宛先符号を生成する。また、宛先符号付与部２１３は、クライアント装置２００が送信するパケットに第１の宛先符号を付与する。第１の宛先符号については後述する。宛先符号付与部２１３は、第１の送信側生成部の一例である。宛先符号付与部２１３は、クライアント送信側生成部の一例である。

【0030】

カーネル処理部２１２は、ＯＳのカーネル処理を行う。カーネル処理部２１２は、一例として、汎用プロトコル処理部２１４を含む。
汎用プロトコル処理部２１４は、ＵＤＰ、ＩＰ及びＡＲＰなどの汎用プロトコルに関する処理を行う。

【0031】

以下、実施形態に係る通信システム１の動作を図２～図４などに基づいて説明する。なお、以下の動作説明における処理の内容は一例であって、同様な結果を得ることが可能な様々な処理を適宜に利用できる。図２は、クライアント装置２００のプロセッサー２１０による処理の一例を示すフローチャートである。プロセッサー２１０は、例えば、ＲＯＭ２２０又は補助記憶装置２４０などに記憶されたプログラムに基づいて図２の処理を実行する。図３は、サーバー装置１００のプロセッサー１１０による処理の一例を示すフローチャートである。プロセッサー１１０は、例えば、ＲＯＭ１２０又は補助記憶装置１４０などに記憶されたプログラムに基づいて図３の処理を実行する。図４は、第１実施形態に係る通信システム１の情報の流れの一例を示すシーケンス図である。なお、図４は、通信システム１における情報の流れを網羅するものではなく、図示しない情報の流れが存在しても良い。また、以下の動作説明では、１台のサーバー装置１００と１台のクライアント装置２００との間の処理を例に説明を行う。

【0032】

図２のステップＳ１１においてクライアント装置２００のプロセッサー２１０は、ターゲットＩＰアドレスに対応するターゲットＭＡＣアドレスを求めるため、ＡＲＰ要求を生成する。プロセッサー２１０は、ＡＲＰ要求を生成した後、当該ＡＲＰ要求をブロードキャスト送信するように通信インターフェース２５０に対して指示する。ＡＲＰ要求は、ターゲットＩＰアドレスを持つ装置にＭＡＣアドレスの送信を要求するパケットである。また、ＡＲＰ要求は、送信元のＭＡＣアドレス及びＩＰアドレスを通知するパケットである。ＡＲＰ要求は、送信元のＭＡＣアドレスとしてクライアント装置２００のＭＡＣアドレス、送信元のＩＰアドレスとしてクライアント装置２００のＩＰアドレス、ターゲットＩＰアドレス及び送信先のＩＰアドレスとしてサーバー装置１００のＩＰアドレスを含む。送信の指示を受けて通信インターフェース２５０は、ＡＲＰ要求をブロードキャスト送信する。送信された当該ＡＲＰ要求は、サーバー装置１００の通信インターフェース１５０によって受信される。ＡＲＰ要求を受信した装置は、ＡＲＰ要求に含まれるターゲットＩＰアドレスがサーバー装置１００自身のＩＰアドレスと同一であるかを確認する。そして、ＩＰアドレスがターゲットＩＰアドレスとは異なる装置、すなわちサーバー装置１００以外の装置は、受信した当該ＡＲＰ要求を破棄する。図４では、ＡＲＰ要求をステップＳＴ１１として示す。
なお、ステップＳ１１の処理は、例えば汎用プロトコル処理部２１４が行う。

【0033】

一方、図３のステップＳ２１においてサーバー装置１００のプロセッサー１１０は、通信インターフェース１５０によってパケットが受信されるのを待ち受けている。プロセッサー１１０は、ＡＲＰ要求又は要求パケットなどのパケットが受信されたならば、ステップＳ２１においてＹｅｓと判定してステップＳ２２へと進む。このとき、プロセッサー１１０は、当該パケットをカーネルバイパスしてアプリケーション処理部１１１に渡す。なお、要求パケットについては、後述する。

【0034】

ステップＳ２２においてプロセッサー１１０は、ステップＳ２１で受信されたパケットがＡＲＰ要求であるか否かを判定する。プロセッサー１１０は、ステップＳ２１で受信されたパケットがＡＲＰ要求でないならば、ステップＳ２２においてＮｏと判定してステップＳ２３へと進む。
なお、ステップＳ２２の処理は、例えばＡＲＰ処理部１１２が行う。

【0035】

ステップＳ２３においてプロセッサー１１０は、ステップＳ２１で受信されたパケットが要求パケットであるか否かを判定する。プロセッサー１１０は、ステップＳ２１で受信されたパケットが要求パケットでないならば、ステップＳ２３においてＮｏと判定して受信されたパケットの種類に応じた処理を行う。
なお、ステップＳ２３の処理は、例えばＡＲＰ処理部１１２が行う。

【0036】

プロセッサー１１０は、ステップＳ２１で受信されたパケットがＡＲＰ要求であるならば、ステップＳ２２においてＹｅｓと判定してステップＳ２４へと進む。
ステップＳ２４においてプロセッサー１１０は、ステップＳ２１で受信されたＡＲＰ要求のターゲットＩＰアドレスがサーバー装置１００のＩＰアドレスと同じであるか否かを判定する。プロセッサー１１０は、当該ＡＲＰ要求のターゲットＩＰアドレスがサーバー装置１００のＩＰアドレスと異なるならば、ステップＳ２４においてＮｏと判定してステップＳ２５へと進む。

【0037】

ステップＳ２５においてプロセッサー１１０は、ステップＳ２１で受信されたＡＲＰ要求を破棄する。プロセッサー１１０は、ステップＳ２５の処理の後、ステップＳ２１へと戻る。

【0038】

対して、プロセッサー１１０は、ステップＳ２１で受信されたＡＲＰ要求のターゲットＩＰアドレスがサーバー装置１００のＩＰアドレスと同じであるならば、ステップＳ２４においてＹｅｓと判定してステップＳ２６へと進む。

【0039】

ステップＳ２６においてプロセッサー１１０は、ＡＲＰ処理を行う。プロセッサー１１０は、ＡＲＰ処理として、ＡＲＰテーブルを生成する。ＡＲＰテーブルは、ＡＲＰ要求に含まれるクライアント装置２００のＭＡＣ（media access control）アドレスとクライアント装置２００のＩＰアドレスとを紐づけする。

【0040】

ステップＳ２７においてプロセッサー１１０は、ＡＲＰ応答を生成する。ＡＲＰ応答は、ＡＲＰ要求への応答として、ターゲットＭＡＣアドレスをＡＲＰ要求の送信元に通知する。ＡＲＰ応答は、送信元のＭＡＣアドレスとしてサーバー装置１００のＭＡＣアドレス、送信元のＩＰアドレス及びターゲットＩＰアドレスとしてサーバー装置１００のＩＰアドレス、送信先のＭＡＣアドレス及びターゲットＭＡＣアドレスとしてクライアント装置２００のＭＡＣアドレス、送信先のＩＰアドレスとしてクライアント装置２００のＩＰアドレスを含む。プロセッサー１１０は、ＡＲＰ応答を生成した後、当該ＡＲＰ応答をＡＲＰ要求の送信元であるクライアント装置２００に送信するように通信インターフェース１５０に対して指示する。送信の指示を受けて通信インターフェース１５０は、当該ＡＲＰ応答を当該クライアント装置２００に送信する。送信された当該ＡＲＰ応答は、クライアント装置２００の通信インターフェース２５０によって受信される。図４では、ＡＲＰ応答をステップＳＴ１２として示す。
なお、図３のステップＳ２４～ステップＳ２７の処理は、例えばＡＲＰ処理部１１２が行う。

【0041】

ステップＳ２８においてプロセッサー１１０は、第１の宛先符号を生成する。第１の宛先符号は、サーバー装置１００及びサーバー装置１００のアプリケーションソフトウェアの識別などに用いられる。プロセッサー１１０は、例えば、サーバー装置１００のＭＡＣアドレス、サーバー装置１００のＩＰアドレス、及びサーバー装置１００のアプリケーションソフトウェアで用いられるポート番号などを用いてハッシュ値又はチェックサムなどを求めることで、当該ハッシュ値又はチェックサムを用いた固定長の第１の宛先符号を生成する。第１の宛先符号生成のためにハッシュ値又はチェックサムを求める関数は、第１の所定の関数の一例である。なお、ハッシュ値を求める関数は、ハッシュ関数と呼ばれる。第１の宛先符号の長さは、処理速度の観点から短い方が好ましい。より好ましくは、第１の宛先符号のビット長は、ＯＳのアーキテクチャのｂｉｔ数と同じｂｉｔ数である。例えば、サーバー装置１００にインストールされているＯＳが６４ｂｉｔＯＳであるならば、第１の宛先符号の長さも６４ｂｉｔであることが好ましい。これは、第１の宛先符号が一致しているかどうかをサーバー装置１００が１命令で判定が可能となるためである。また、第１の宛先符号の長さが６４ｂｉｔであれば、衝突確率は１×１０^－１９以下となり、サーバー装置１００が誤ってサーバー装置１００のアプリケーションソフトウェア宛てでないパケットをサーバー側アプリケーション処理する確率が十分に低くなる。なお、サーバー装置１００によって生成される第１の宛先符号を、以下「サーバー側第１の宛先符号」というものとする。サーバー側第１の宛先符号は、第１の受信側宛先符号の一例である。プロセッサー１１０は、ステップＳ２８の処理の後、ステップＳ２１へと戻る。
なお、ステップＳ２８の処理は、例えば宛先判定部１１３が行う。

【0042】

一方、図２のステップＳ１２においてクライアント装置２００のプロセッサー２１０は、通信インターフェース２５０によってＡＲＰ応答が受信されるのを待ち受けている。プロセッサー２１０は、ＡＲＰ応答が受信されたならば、ステップＳ１２においてＹｅｓと判定してステップＳ１３へと進む。
なお、ステップＳ１２の処理は、例えば汎用プロトコル処理部２１４が行う。

【0043】

ステップＳ１３においてプロセッサー２１０は、要求パケットを送信するか否かを判定する。プロセッサー２１０は、例えば、アプリケーションソフトウェアの処理などにおいて、サーバー装置１００に何らかの要求を送信する必要がある場合に要求パケットを送信すると判定する。プロセッサー２１０は、要求パケットを送信しないならば、ステップＳ１３においてＮｏと判定してステップＳ１４へと進む。
なお、ステップＳ１３の処理は、例えばアプリケーション処理部２１１が行う。

【0044】

ステップＳ１４においてプロセッサー２１０は、通信インターフェース２５０によって応答パケットなどのパケットが受信されたか否かを判定する。プロセッサー２１０は、パケットが受信されないならば、ステップＳ１４においてＮｏと判定してステップＳ１３へと戻る。かくして、プロセッサー２１０は、要求パケットを送信すると判定するか、パケットが受信されるまでステップＳ１３及びステップＳ１４を繰り返す待受状態となる。

【0045】

プロセッサー２１０は、ステップＳ１３及びステップＳ１４の待受状態にあるときに要求パケットを送信すると判定するならば、ステップＳ１３においてＹｅｓと判定してステップＳ１５へと進む。
なお、ステップＳ１５の処理は、例えばアプリケーション処理部２１１が行う。

【0046】

ステップＳ１５においてプロセッサー２１０は、図５に示すような要求パケット４００を生成する。要求パケット４００は、サーバー装置１００に何らかの要求を行うためのパケットである。要求パケット４００は、要求データの一例である。

【0047】

図５は、要求パケット４００の一例を示す図である。
要求パケット４００は、一例として、Ｅｔｈｅｒヘッダー４１０、ＩＰヘッダー４２０、ＵＤＰヘッダー４３０及びペイロード４４０を含むイーサネットフレームである。

【0048】

Ｅｔｈｅｒヘッダー４１０は、イーサネットフレームのヘッダー部である。Ｅｔｈｅｒヘッダー４１０は、一例として、プリアンブル４１１、送信先ＭＡＣアドレス４１２、送信元ＭＡＣアドレス４１３及びタイプ／長さ４１４を含む。

【0049】

プリアンブル４１１は、イーサネットフレームの開始を示す。
送信先ＭＡＣアドレス４１２は、要求パケット４００の送信先のＭＡＣアドレスを示す。
送信元ＭＡＣアドレス４１３は、要求パケット４００の送信元のＭＡＣアドレスを示す。
タイプ／長さ４１４は、イーサネットフレームのデータ部で運んでいるプロトコルを示す。あるいは、タイプ／長さ４１４は、イーサネットフレームのデータ部の長さを示す。

【0050】

ＩＰヘッダー４２０はＩＰパケットのヘッダー部である。ＩＰパケットは、イーサネットフレームのデータ部に含まれる。ＩＰヘッダー４２０は、一例として、チェックサム４２１、送信元ＩＰアドレス４２２及び送信先ＩＰアドレス４２３を含む。

【0051】

チェックサム４２１は、ＩＰヘッダー４２０のチェックサムである。
送信元ＩＰアドレス４２２は、ＩＰパケットの送信元のＩＰアドレスを示す。
送信先ＩＰアドレス４２３は、ＩＰパケットの送信先のＩＰアドレスを示す。

【0052】

ＵＤＰヘッダー４３０は、ＵＤＰパケットのヘッダー部である。ＵＤＰパケットはＩＰパケッドのペイロードに含まれる。ＵＤＰヘッダー４３０は、一例として、送信元ポート番号４３１、送信先ポート番号４３２、パケット長４３３及びチェックサム４３４を含む。

【0053】

送信元ポート番号４３１は、ＵＤＰパケットの送信元のポート番号を示す。
送信先ポート番号４３２は、ＵＤＰパケットの送信先のポート番号を示す。
パケット長４３３は、ＵＤＰパケットの長さ、すなわちＵＤＰヘッダー４３０の長さ及びペイロード４４０の長さの合計を示す。
チェックサム４３４は、ＵＤＰヘッダー４３０及びペイロード４４０のチェックサムである。

【0054】

ペイロード４４０は、ＵＤＰパケットのペイロードであり、要求パケット４００によって送信されるデータの本体などを含む。当該本体は、サーバー装置１００に要求する内容を含む。例えば、当該本体は、ＥＴＣカードの識別情報、乗車券の識別情報、ＩｏＴ機器又は工場のセンサーなどから取得されるデータなどであっても良い。また、ペイロード４４０は、第１の宛先符号４４１を含む。ペイロード４４０中の第１の宛先符号４４１を除くデータは、既存の要求パケットのペイロード内のデータと同様のデータでも良い。

【0055】

プロセッサー２１０は、送信先ＭＡＣアドレス４１２、送信先ＩＰアドレス４２３及び送信先ポート番号４３２などを用いてハッシュ値又はチェックサムなどを求めることで、当該ハッシュ値又はチェックサムを用いた固定長の第１の宛先符号４４１を生成する。なお、第１の宛先符号４４１の生成に用いる関数は、サーバー側第１の宛先符号の生成に用いる関数と同一である。プロセッサー２１０は、生成した第１の宛先符号４４１を、ペイロード４４０に付与する。第１の宛先符号４４１は、第１の送信側宛先符号の一例である。第１の宛先符号４４１は、クライアント送信側宛先符号の一例である。

【0056】

プロセッサー２１０は、要求パケット４００を生成した後、当該要求パケット４００をサーバー装置１００に送信するように通信インターフェース２５０に対して指示する。この送信の指示を受けて通信インターフェース２５０は、当該要求パケット４００をサーバー装置１００に送信する。送信された当該要求パケット４００は、サーバー装置１００の通信インターフェース１５０によって受信される。図４では、要求パケット４００をステップＳＴ１３として示す。プロセッサー２１０は、図２のステップＳ１５の処理の後、ステップＳ１３へと戻る。

【0057】

なお、ステップＳ１３の処理は、例えばアプリケーション処理部２１１が行う。第１の宛先符号の生成及び付与については、宛先符号付与部２１３が行う。

【0058】

一方、サーバー装置１００のプロセッサー１１０は、図３のステップＳ２１で受信されたパケットが要求パケット４００であるならば、ステップＳ２３においてＹｅｓと判定してステップＳ２９へと進む。
ステップＳ２９においてサーバー装置１００のプロセッサー１１０は、ステップＳ２１で受信された要求パケット４００に含まれる第１の宛先符号４４１がステップＳ２８で生成したサーバー側第１の宛先符号と一致するか否かを判定する。プロセッサー１１０は、第１の宛先符号が一致するならば、ステップＳ２９においてＹｅｓと判定してステップＳ３０へと進む。
なお、ステップＳ２９の処理は、例えば宛先判定部１１３が行う。

【0059】

ステップＳ３０においてプロセッサー１１０は、要求パケット４００のペイロード４４０中のデータ本体によって要求された内容に基づくサーバー側アプリケーション処理を行う。
なお、ステップＳ３０の処理は、例えばアプリケーション処理部１１１が行う。

【0060】

ステップＳ３１においてプロセッサー１１０は、要求パケット４００への応答として、図６に示すような応答パケット５００を生成する。プロセッサー１１０は、宛先を置換する宛先置換処理により要求パケット４００から応答パケット５００を生成する。応答パケット５００は、応答データの一例である。
なお、ステップＳ３１の処理は、例えば宛先置換部１１４が行う。

【0061】

図６は、宛先置換処理及び応答パケット５００について説明するための図である
応答パケット５００は、一例として、Ｅｔｈｅｒヘッダー５１０、ＩＰヘッダー５２０、ＵＤＰヘッダー５３０及びペイロード５４０を含むイーサネットフレームである。

【0062】

Ｅｔｈｅｒヘッダー５１０は、イーサネットフレームのヘッダー部である。Ｅｔｈｅｒヘッダー５１０は、一例として、プリアンブル５１１、送信先ＭＡＣアドレス５１２、送信元ＭＡＣアドレス５１３及びタイプ／長さ５１４を含む。

【0063】

プリアンブル５１１は、イーサネットフレームの開始を示す。プリアンブル５１１は、プリアンブル４１１をコピーしたものである。

【0064】

送信先ＭＡＣアドレス５１２は、応答パケット５００の送信先のＭＡＣアドレスを示す。送信先ＭＡＣアドレス５１２は、送信元ＭＡＣアドレス４１３をコピーしたものである。
送信元ＭＡＣアドレス５１３は、応答パケット５００の送信元のＭＡＣアドレスを示す。送信元ＭＡＣアドレス５１３は、送信先ＭＡＣアドレス４１２をコピーしたものである。
以上より、送信先ＭＡＣアドレス５１２及び送信元ＭＡＣアドレス５１３は、送信先ＭＡＣアドレス４１２と送信元ＭＡＣアドレス４１３とを入れ替えたものに等しい。

【0065】

タイプ／長さ５１４は、イーサネットフレームのデータ部で運んでいるプロトコルを示す。あるいは、タイプ／長さ５１４は、イーサネットフレームのデータ部の長さを示す。タイプ／長さ５１４は、タイプ／長さ４１４をコピーしたものである。

【0066】

ＩＰヘッダー５２０は、ＩＰパケットのヘッダー部である。ＩＰヘッダー５２０は、一例として、チェックサム５２１、送信元ＩＰアドレス５２２及び送信先ＩＰアドレス５２３を含む。

【0067】

チェックサム５２１は、ＩＰヘッダー５２０のチェックサムである。チェックサム５２１は、チェックサム４２１をコピーしたものである。

【0068】

送信元ＩＰアドレス５２２は、ＩＰパケットの送信元のＩＰアドレスを示す。送信元ＩＰアドレス５２２は、送信先ＩＰアドレス４２３をコピーしたものである。
送信先ＩＰアドレス５２３は、ＩＰパケットの送信先のＩＰアドレスを示す。送信先ＩＰアドレス５２３は、送信元ＩＰアドレス４２２をコピーしたものである。
したがって、送信元ＩＰアドレス５２２及び送信先ＩＰアドレス５２３は、送信元ＩＰアドレスと送信先ＩＰアドレス４２３とを入れ替えたものに等しい。

【0069】

ＵＤＰヘッダー５３０は、ＵＤＰパケットのヘッダー部である。ＵＤＰヘッダー５３０は、一例として、送信元ポート番号５３１、送信先ポート番号５３２、パケット長５３３及びチェックサム５３４を含む。

【0070】

送信元ポート番号５３１は、ＵＤＰパケットの送信元のポート番号を示す。送信元ポート番号５３１は、送信先ポート番号４３２をコピーしたものである。
送信先ポート番号５３２は、ＵＤＰパケットの送信先のポート番号を示す。送信先ポート番号５３２は、送信元ポート番号４３１をコピーしたものである。
したがって、送信元ポート番号５３１及び送信先ポート番号５３２は、送信元ポート番号４３１と送信先ポート番号４３２とを入れ替えたものに等しい。

【0071】

パケット長５３３は、ＵＤＰパケットの長さ、すなわちＵＤＰヘッダー５３０の長さ及びペイロード５４０の長さの合計を示す。パケット長５３３は、パケット長４３３をコピーしたものである。ただし、ペイロード４４０の長さとペイロード５４０の長さは等しいものとする。

【0072】

チェックサム５３４は、ＵＤＰヘッダー５３０及びペイロード５４０のチェックサムである。

【0073】

ペイロード５４０は、ＵＤＰパケットのペイロードであり、応答パケット５００によって送信されるデータの本体などを含む。当該本体は、要求パケット４００によって要求された内容に基づき応答する内容を含む。当該本体は、ステップＳ３０の処理に基づくデータである。ペイロード５４０中のデータは、既存の応答パケットのペイロード内のデータと同様のデータでも良い。

【0074】

なお、プロセッサー１１０は、応答パケット５００において各部の入れ替えを、ＳＩＭＤ（single instruction, multiple data）演算を用いて行っても良い。例えば、プロセッサー１１０は、ｘ８６／ｘ６４プロセッサーの拡張命令であるＳＳＥ（Streaming SIMD Extensions）又はＡＶＸ（Advanced Vector Extensions）などを用いると、シャッフル命令（ＰＳＨＵＦＢ／ＶＰＳＨＵＦＢ）により、１２８ｂｉｔ、２５６ｂｉｔ、又は５１２ｂｉｔ分の領域をバイト毎に置換することが可能である。

【0075】

図７は、ＳＩＭＤ演算による宛先置換処理の例を示す図である。
例えば、プロセッサー１１０は、ＳＳＥの１２８ｂｉｔ領域のシャッフル命令を用いて、第一引数にＥｔｈｅｒヘッダー４１０を格納し、第２引数に入れ替えるバイト位置を格納すると、戻り値として、送信先ＭＡＣアドレス４１２と送信元ＭＡＣアドレス４１３とを入れ替えた値を１命令で得ることができる。また、プロセッサー１１０は、ＡＶＸの５１２ｂｉｔ領域のシャッフル命令を用いると、ＭＡＣアドレス、ＩＰアドレス及びポート番号を１命令で入れ替えることが可能である。

【0076】

ステップＳ３２においてプロセッサー１１０は、ステップＳ３１で生成した応答パケットを要求パケット４００の送信元であるクライアント装置２００に送信するように通信インターフェース１５０に対して指示する。この送信の指示を受けて通信インターフェース１５０は、当該応答パケットを当該クライアント装置２００に送信する。送信された当該応答パケットは、クライアント装置２００の通信インターフェース２５０によって受信される。図４では、応答パケットをステップＳＴ１４として示す。プロセッサー１１０は、図３のステップＳ３２の処理の後、ステップＳ２１へと戻る。
なお、ステップＳ３２の処理は、例えばアプリケーション処理部１１１が行う。

【0077】

一方、プロセッサー２１０は、図２のステップＳ１３及びステップＳ１４の待受状態にあるときにパケットが受信されたならば、ステップＳ１４においてＹｅｓと判定してステップＳ１６へと進む。このとき、プロセッサー２１０は、当該パケットをカーネルバイパスしてアプリケーション処理部２１１に渡す。
ステップＳ１６においてプロセッサー２１０は、ステップＳ１４で受信されたパケットが応答パケットであるか否かを判定する。プロセッサー２１０は、ステップＳ１４で受信されたパケットが応答パケットでないならば、ステップＳ１６においてＮｏと判定して受信されたパケットの種類に応じた処理を行う。対して、プロセッサー２１０は、ステップＳ１４で受信されたパケットが応答パケットであるならば、ステップＳ１６においてＹｅｓと判定してステップＳ１７へと進む。
なお、ステップＳ１６の処理は、例えば汎用プロトコル処理部２１４が行う。

【0078】

ステップＳ１７においてプロセッサー２１０は、応答パケット５００のペイロード５４０中のデータ本体の内容に基づくクライアント側アプリケーション処理を行う。プロセッサー２１０は、ステップＳ１７の処理の後、ステップＳ１３へと戻る。
なお、ステップＳ１７の処理は、例えばアプリケーション処理部２１１が行う。

【0079】

なお、サーバー装置１００のプロセッサー１１０は、第１の宛先符号が一致しないならば、ステップＳ２２で受信された要求パケット４００がサーバー装置１００のアプリケーションソフトウェア宛てのパケットではないとみなし、図３のステップＳ２９においてＮｏと判定してステップＳ３３へと進む。
ステップＳ３３においてプロセッサー１１０は、ステップＳ２２で受信された要求パケット４００を破棄する。プロセッサー１１０は、ステップＳ３３の処理の後、ステップＳ２１へと戻る。
なお、ステップＳ３３の処理は、例えばアプリケーション処理部１１１が行う。

【0080】

第１実施形態の通信システム１によれば、サーバー装置１００は、要求パケット４００中の第１の宛先符号４４１とサーバー側第１の宛先符号が一致するか否かを判定する。これにより、サーバー装置１００は、要求パケット４００のヘッダー部分の処理を行うことなく、要求パケット４００がサーバー装置１００のアプリケーションソフトウェア宛てであるか否かを判定することができる。この結果、サーバー装置１００による要求パケット４００に係る処理にかかる時間が短くなる。

【0081】

また、第１実施形態の通信システム１によれば、サーバー装置１００は、要求パケット４００の一部を入れ替えることで応答パケット５００を生成する。これにより、サーバー装置１００は、応答パケット５００の生成にかかる時間を短くすることができる。

【0082】

また、第１実施形態の通信システム１によれば、サーバー装置１００は、要求パケット４００の一部をコピーすることで応答パケット５００を生成する。これにより、サーバー装置１００は、応答パケット５００の生成にかかる時間を短くすることができる。

【0083】

また、第１実施形態の通信システム１によれば、サーバー装置１００は、ＳＩＭＤ演算を用いてヘッダーの一部を入れ替える。これにより、サーバー装置１００は、応答パケット５００の生成にかかる時間を短くすることができる。

【0084】

また、第１実施形態の通信システム１によれば、第１の宛先符号は、ハッシュ関数を用いて生成される場合がある。通信システム１は、第１の宛先符号の生成にハッシュ関数を用いることで、サーバー装置１００のＭＡＣアドレスとＩＰアドレスとポート番号が分かっても第１の宛先符号の推測が困難となり、セキュリティ性が向上する。

【0085】

〔第２実施形態〕
図８は、第２実施形態に係る通信システム１ｂ及び通信システム１ｂに含まれる構成要素の要部構成の一例を示すブロック図である。
通信システム１ｂのハードウェア構成は、第１実施形態の通信システム１と同様であるので説明を省略する。

【0086】

第２実施形態では、サーバー装置１００のアプリケーション処理部１１１は、ＡＲＰ処理部１１２、宛先判定部１１３及び宛先置換部１１４に加えて宛先符号付与部１１５を備える。
宛先符号付与部１１５は、第２の宛先符号を生成する。また、宛先符号付与部１１５は、サーバー装置１００が送信するパケットに第２の宛先符号を付与する。宛先符号付与部１１５は、第１の受信側生成部の一例である。

【0087】

また、第２実施形態では、クライアント装置２００のアプリケーション処理部２１１は、宛先符号付与部２１３に加えて、ＡＲＰ処理部２１５及び宛先判定部２１６を備える。
ＡＲＰ処理部２１５は、ＡＲＰ処理などを行う。
宛先判定部２１６は、受信パケットに含まれる第２の宛先符号から宛先を判定する。宛先判定部２１６は、第２の送信側生成部の一例である。

【0088】

以下、第２実施形態に係る通信システム１ｂの動作を図９～図１１などに基づいて説明する。なお、以下の動作説明における処理の内容は一例であって、同様な結果を得ることが可能な様々な処理を適宜に利用できる。図９は、クライアント装置２００のプロセッサー２１０による処理の一例を示すフローチャートである。プロセッサー２１０は、例えば、ＲＯＭ２２０又は補助記憶装置２４０などに記憶されたプログラムに基づいて図９の処理を実行する。図１０は、サーバー装置１００のプロセッサー１１０による処理の一例を示すフローチャートである。プロセッサー１１０は、例えば、ＲＯＭ１２０又は補助記憶装置１４０などに記憶されたプログラムに基づいて図１０の処理を実行する。図１１は、第２実施形態に係る通信システム１ｂの情報の流れの一例を示すシーケンス図である。なお、図１１は、通信システム１ｂにおける情報の流れを網羅するものではなく、図示しない情報の流れが存在しても良い。また、以下の動作説明では、１台のサーバー装置１００と１台のクライアント装置２００との間の処理を例に説明を行う。

【0089】

第２実施形態では、サーバー装置１００のプロセッサー１１０は、図１０のステップＳ２８の処理の後、ステップＳ５１へと進む。
ステップＳ５１においてプロセッサー１１０は、ＡＲＰ要求を生成する。ここで生成されるＡＲＰ要求は、クライアント装置２００が生成するＡＲＰ要求と同様である。ただし、サーバー装置１００によって生成されるＡＲＰ要求は、クライアント装置２００が生成するＡＲＰ要求とは送信先と送信元が逆である。プロセッサー１１０は、ＡＲＰ要求を生成した後、当該ＡＲＰ要求をクライアント装置２００に送信するように通信インターフェース１５０に対して指示する。この送信の指示を受けて通信インターフェース１５０は、当該ＡＲＰ要求をクライアント装置２００に送信する。送信された当該ＡＲＰ要求は、クライアント装置２００の通信インターフェース２５０によって受信される。図１１では、当該ＡＲＰ要求をステップＳＴ２１として示す。プロセッサー１１０は、図１０のステップＳ５１の処理の後、ステップＳ２１へと戻る。

【0090】

一方、第２実施形態では、クライアント装置２００のプロセッサー２１０は、図９のステップＳ１２の処理においてＹｅｓと判定したならばステップＳ４１へと進む
ステップＳ４１においてプロセッサー２１０は、通信インターフェース２５０によってＡＲＰ要求が受信されるのを待ち受けている。プロセッサー２１０は、ＡＲＰ要求が受信されたならば、ステップＳ４１においてＹｅｓと判定してステップＳ４２へと進む。

【0091】

ステップＳ４２においてプロセッサー２１０は、ＡＲＰ応答を生成する。ここで生成されるＡＲＰ応答は、サーバー装置１００が生成するＡＲＰ応答と同様である。ただし、クライアント装置２００によって生成されるＡＲＰ応答は、サーバー装置１００が生成するＡＲＰ要求とは送信先と送信元が逆である。プロセッサー２１０は、ＡＲＰ応答を生成した後、当該ＡＲＰ応答をサーバー装置１００に送信するように通信インターフェース２５０に対して指示する。この送信の指示を受けて通信インターフェース２５０は、当該ＡＲＰ応答をサーバー装置１００に送信する。送信された当該ＡＲＰ応答は、サーバー装置１００の通信インターフェース１５０によって受信される。図１１では、当該ＡＲＰ応答をステップＳＴ２２として示す。

【0092】

ステップＳ４３においてプロセッサー２１０は、第２の宛先符号を生成する。第２の宛先符号は、クライアント装置２００及びクライアント装置２００のアプリケーションソフトウェアの識別などに用いられる。プロセッサー１１０は、例えば、クライアント装置２００のＭＡＣアドレス、クライアント装置２００のＩＰアドレス、及びクライアント装置２００のアプリケーションソフトウェアで用いられるポート番号などを用いてハッシュ値又はチェックサムなどを求めることで、当該ハッシュ値又はチェックサムを用いた固定長の第２の宛先符号を生成する。第２の宛先符号生成のためにハッシュ値又はチェックサムを求める関数は、第２の所定の関数の一例である。第２の宛先符号の長さは、処理速度の観点から短い方が好ましい。より好ましくは、第２の宛先符号の長さは、ＯＳのｂｉｔ数と同じｂｉｔ数である。例えば、クライアント装置２００にインストールされているＯＳが６４ｂｉｔＯＳであるならば、第２の宛先符号の長さも６４ｂｉｔであることが好ましい。これは、第２の宛先符号が一致しているかどうかをクライアント装置２００が１命令で判定が可能となるためである。また、第２の宛先符号の長さが６４ｂｉｔであれば、衝突確率は１×１０^－１９以下となり、クライアント装置２００が誤ってクライアント装置２００のアプリケーションソフトウェア宛てでないパケットをサーバー側アプリケーション処理する確率が十分に低くなる。なお、クライアント装置２００によって生成される第２の宛先符号を、以下「クライアント側第２の宛先符号」というものとする。クライアント側第２の宛先符号は、第２の受信側宛先符号の一例である。プロセッサー２１０は、ステップＳ４３の処理の後、ステップＳ１３へと進む。

【0093】

一方、第２実施形態では、サーバー装置１００のプロセッサー１１０は、図１０のステップＳ２３においてＮｏと判定したならば、ステップＳ５２へと進む。
ステップＳ５２においてプロセッサー１１０は、ステップＳ２１で受信されたパケットがＡＲＰ応答であるか否かを判定する。プロセッサー１１０は、ステップＳ２１で受信されたパケットがＡＲＰ応答でないならば、ステップＳ５２においてＮｏと判定して受信されたパケットの種類に応じた処理を行う。一方、プロセッサー１１０は、ステップＳ２１で受信されたパケットがＡＲＰ応答であるならば、ステップＳ５２においてＹｅｓと判定してステップＳ２１へと戻る。

【0094】

また、第２実施形態では、プロセッサー１１０は、ステップＳ３１の処理の後、ステップＳ５３へと進む。
ステップＳ５３においてプロセッサー１１０は、送信先ＭＡＣアドレス５１２、送信先ＩＰアドレス５２３及び送信先ポート番号５３２などを用いてハッシュ値又はチェックサムなどを求めることで、当該ハッシュ値又はチェックサムを用いた固定長の第２の宛先符号を生成する。なお、ここでの第２の宛先符号の生成に用いる関数は、クライアント側第２の宛先符号の生成に用いる関数と同一である。プロセッサー２１０は、生成した第２の宛先符号を、ステップＳ３１で生成した応答パケット５００のペイロード５４０に付与する。ここで生成される宛先符号は、第２の送信側宛先符号の一例である。

【0095】

ステップＳ５４においてプロセッサー１１０は、ステップＳ５３で生成した応答パケットを要求パケット４００の送信元であるクライアント装置２００に送信するように通信インターフェース１５０に対して指示する。この送信の指示を受けて通信インターフェース１５０は、当該応答パケットを当該クライアント装置２００に送信する。送信された当該応答パケットは、クライアント装置２００の通信インターフェース２５０によって受信される。図４では、応答パケットをステップＳＴ１４として示す。プロセッサー１１０は、図３のステップＳ５４の処理の後、ステップＳ２１へと戻る。プロセッサー１１０は、ステップＳ５４の処理の後、ステップＳ２１へと戻る。

【0096】

一方、第２実施形態では、クライアント装置２００のプロセッサー２１０は、図９のステップＳ１６においてＹｅｓと判定したならば、ステップＳ４４へと進む。
ステップＳ４４においてプロセッサー２１０は、ステップＳ１４で受信された応答パケット５００に含まれる第２の宛先符号がステップＳ４３で生成したクライアント側第２の宛先符号と一致するか否かを判定する。プロセッサー２１０は、第２の宛先符号が一致しないならば、ステップＳ４４においてＮｏと判定してステップＳ４５へと進む。

【0097】

ステップＳ４５においてプロセッサー２１０は、ステップＳ１４で受信された応答パケット５００を破棄する。プロセッサー２１０は、ステップＳ４５の処理の後、ステップＳ１３へと戻る。

【0098】

対して、プロセッサー２１０は、第２の宛先符号が一致するならば、ステップＳ４４においてＹｅｓと判定してステップＳ１７へと進む。

【0099】

第２実施形態の通信システム１ｂによれば、第１実施形態の通信システム１と同様の効果が得られる。

【0100】

また、第２実施形態の通信システム１ｂによれば、クライアント装置２００は、応答パケット５００中の第２の宛先符号とクライアント側第２の宛先符号が一致するか否かを判定する。これにより、クライアント装置２００は、応答パケット５００のヘッダー部分の処理を行うことなく、応答パケット５００がクライアント装置２００のアプリケーションソフトウェア宛てであるか否かを判定することができる。この結果、クライアント装置２００による応答パケット５００に係る処理にかかる時間が短くなる。

【0101】

上記の実施形態は以下のような変形も可能である。

【0102】

第２実施形態の通信システム１ｂは、クライアント装置２００が先にＡＲＰ要求を送信し、その後にサーバー装置１００がＡＲＰ要求を送信している。しかしながら、サーバー装置１００がクライアント装置２００より先にＡＲＰ要求を送信しても良い。また、サーバー装置１００及びクライアント装置２００が同時にＡＲＰ要求を送信しても良い。

【0103】

第２実施形態の通信システム１ｂは、クライアント装置２００が先にＡＲＰ要求を送信し、当該ＡＲＰ要求を受信したことに応じてサーバー装置１００がＡＲＰ要求を送信している。しかしながら、サーバー装置１００は、クライアント装置２００がＡＲＰ要求を送信してきたこととは無関係にＡＲＰ要求を送信しても良い。
また、サーバー装置１００がクライアント装置２００より先にＡＲＰ要求を送信する場合においても、クライアント装置２００は、当該ＡＲＰ要求を受信したことに応じてＡＲＰ要求を送信しても良い。また、クライアント装置２００は、サーバー装置１００がＡＲＰ要求を送信してきたこととは無関係にＡＲＰ要求を送信しても良い。

【0104】

サーバー装置１００は、ＡＲＰ応答を受信したことに応じて、サーバー側第１の宛先符号を生成しても良い。クライアント装置２００は、ＡＲＰ応答を受信したことに応じて、クライアント側第２の宛先符号を生成しても良い。

【0105】

上記の実施形態では、サーバー装置とクライアント装置間の処理について説明した。しかしながら、実施形態の通信システムは、サーバー装置とクライアント装置間に限らず、２つの装置の間での通信において宛先符号を用いた同様の処理を行うものでもあっても良い。

【0106】

ＩＰｖ６を用いる通信システムでは、ＡＲＰに代えてＩＣＭＰ（Internet Control Message Protocol）ｖ６の近隣探索メッセージを用いても良い。この場合、クライアント装置２００又はサーバー装置１００は、ＡＲＰ要求に代えて近隣要請メッセージを、マルキャストアドレスを用いてマルチキャスト送信する。そして、近隣要請メッセージを受信したサーバー装置１００又はクライアント装置２００は、ＡＲＰ応答に代えて近隣告知メッセージを送信する。そして、サーバー装置１００及びクライアント装置２００は、ＡＲＰテーブルに代えて近隣キャッシュを用いることでＩＰアドレスとＭＡＣアドレスとを紐づける。

【0107】

サーバー装置１００は、ＡＲＰ及びＩＣＭＰｖ６以外のプロトコルで送信されるパケットを受信したことに応じて、サーバー側第１の宛先符号を生成しても良い。クライアント装置２００は、ＡＲＰ及びＩＣＭＰｖ６以外のプロトコルで送信されるパケットを受信したことに応じて、クライアント側第２の宛先符号を生成しても良い。

【0108】

実施形態の通信システムは、イーサネット以外のデータリンクを用いるものでも良い。
また、実施形態の通信システムは、ＴＣＰなどのＵＤＰ以外のトランスポートプロトコルを用いるものであっても良い。

【0109】

プロセッサー１１０及びプロセッサー２１０は、上記実施形態においてプログラムによって実現する処理の一部又は全部を、回路のハードウェア構成によって実現するものであっても良い。

【0110】

上記実施形態における各装置は、例えば、上記の各処理を実行するためのプログラムが記憶された状態で各装置の管理者などへと譲渡される。あるいは、当該各装置は、当該プログラムが記憶されない状態で当該管理者などに譲渡される。そして、当該プログラムが別途に当該管理者などへと譲渡され、当該管理者又はサービスマンなどによる操作に基づいて当該各装置に記憶される。このときのプログラムの譲渡は、例えば、ディスクメディア又は半導体メモリなどのようなリムーバブルな記憶媒体を用いて、あるいはインターネット又はＬＡＮなどを介したダウンロードにより実現できる。

【0111】

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【符号の説明】

【0112】

１……通信システム、１００……サーバー装置、１１０，２１０……プロセッサー、１１１，２１１……アプリケーション処理部、１１２，２１５……ＡＲＰ処理部、１１３，２１６……宛先判定部、１１４……宛先置換部、１１５，２１３……宛先符号付与部、１２０，２２０……ＲＯＭ、１３０，２３０……ＲＡＭ、１４０，２４０……補助記憶装置、１５０，２５０……通信インターフェース、１６０，２８０……バス、２００……クライアント装置、２１２……カーネル処理部、２１４……汎用プロトコル処理部、２６０……入力装置、２７０……表示装置、４００……要求パケット、４１０，５１０……Ｅｔｈｅｒヘッダー、４１１，５１１……プリアンブル、４１２，５１２……送信先ＭＡＣアドレス、４１３，５１３……送信元ＭＡＣアドレス、４１４，５１４……タイプ／長さ、４２０，５２０……ＩＰヘッダー、４２１，４３４，５２１，５３４……チェックサム、４２２，５２２……送信元ＩＰアドレス、４２３，５２３……送信先ＩＰアドレス、４３０，５３０……ＵＤＰヘッダー、４３１，５３１……送信元ポート番号、４３２，５３２……送信先ポート番号、４３３，５３３……パケット長、４４０，５４０……ペイロード、４４１……第１の宛先符号、５００……応答パケット

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】