JP6469148B2 - 通信システム - Google Patents

Description

本発明は、サーバ装置とクライアント装置とがネットワークを介して通信を行う通信システムに関するものである。

従来、データの管理を行うサーバ装置に対して、インターネットなどのネットワークを介してクライアント装置が通信を行うことにより、サーバ装置とは異なる装置であるクライアント装置が、サーバ装置の管理するデータへアクセスすることが可能となる通信システムが運用されている。こうした通信システムの一例として、遠隔地に存在する監視対象（サーバ装置による管理対象）の状態（ステータス）を、ウェブブラウザを用いて（インターネットを介して）業者の営業所や個人宅などに設置されたクライアント装置（コンピュータなど）から監視するシステムが挙げられる。

こうした通信システムにおいては、クライアント装置は、サーバ装置の管理するデータのうちアクセス対象とするデータを指定する要求（リクエスト）を、ネットワークを介してサーバ装置へ送信し、サーバ装置は受信した要求によって指定されたデータをクライアント装置へ送信する。

以上のような従来の通信システムにおいては、クライアント装置が同一の要求をサーバ装置へ送信することを何度も繰り返す場合に、クライアント装置とサーバ装置との間の通信量が膨大になってしまうという問題点があった。

例えばクライアント装置が監視対象を遠隔地から監視し続ける場合には、クライアント装置は監視対象に関するステータスの全てをサーバ装置へ定期的に（例えば１秒に１度）要求する。このとき、クライアント装置がサーバ装置へ送信する要求は毎回同じであるが、その要求は複数のデータを指定している。したがって、指定するデータの数に比例した大きさの通信量となる要求が定期的に送信されることになり、例えば監視対象に関するステータスが１０種類あるならば、ネットワーク上の通信量は（１０×経過秒数）に比例して増加していくことになる。そして、クライアント装置が複数存在するならばそのクライアント装置の数にも比例して通信量は増加していく。

このように、従来の通信システムでは、クライアント装置が定期的にサーバ装置へ同一の要求を繰り返すだけでネットワーク上の通信量が膨大になってしまうという問題点があった。

また、サーバ装置は要求されたデータを全てクライアント装置へ送信するため、同一の要求が定期的に繰り返された場合、前回の要求の時点からデータが変化していなくとも大量のデータが毎度クライアント装置へ送信されてしまい、やはり通信量が大きくなってしまうという問題点もあった。

本発明は、上記問題点に鑑み、サーバ装置とクライアント装置との間の通信量、特に、クライアント装置がサーバ装置へデータを要求する際の通信量を低減することを課題とする。

本発明に係る通信システムは、複数のデータを管理する少なくとも１つのサーバ装置と、ネットワークを介して前記サーバ装置と通信することにより前記複数のデータにアクセスする少なくとも１つのクライアント装置と、を含み、前記クライアント装置は、前記複数のデータのうち必要とするデータに対応するデータ名を記した要求データ名リストを前記サーバ装置へ送信し、前記サーバ装置は、受信した前記要求データ名リストに記されているデータ名に対応するデータを、前記要求データ名リストを送信したクライアント装置へ送信する通信システムにおいて、前記サーバは、前記クライアント装置から前記要求データ名リストを受信した際に、前記要求データ名リストに記されたデータ名の組み合わせに応じて一意なリクエストＩＤを生成して前記リクエストＩＤを前記クライアント装置へ送信するとともに、前記要求データ名リストと前記リクエストＩＤとを紐付けたリクエストＩＤリストを記録し、前記クライアント装置が前記リクエストＩＤを受信した後、前記クライアント装置が前回送信したものと同一の前記要求データ名リストを前記サーバ装置へ再度送信しようとする際には、前記クライアント装置は前記要求データ名リストの代わりに前記リクエストＩＤを前記サーバ装置へ送信し、前記リクエストＩＤを受信したサーバ装置は、前記リクエストＩＤに紐付いた前記要求データ名リストに記されたデータ名に対応するデータを、前記リクエストＩＤを送信した前記クライアント装置へ送信することを特徴とする。

また、本発明に係る通信システムにおいては、前記サーバ装置は、前記クライアント装置へデータを送信する際に、送信時刻を示す送信タイムスタンプを付加して送信し、前記クライアント装置は、前記サーバ装置へ前記リクエストＩＤを送信する際に、前記サーバ装置から受信した最新の前記送信タイムスタンプを前記リクエストＩＤに付加して送信し、前記サーバ装置は、前記クライアント装置から受信した前記リクエストＩＤに紐付いたデータ名リストに記されたデータ名に対応するデータのうち、前記リクエストＩＤに付加された前記送信タイムスタンプが示す時刻における状態と現在時刻における状態とで差異があるデータのみを前記クライアント装置へ送信するようにしてもよい。

また、本発明に係る通信システムにおいては、前記クライアント装置にはアクセス可能なデータとアクセス不可能なデータが設定されており、前記クライアント装置が前記サーバ装置へ送信した前記要求データ名リストに、前記クライアント装置がアクセス不可能なデータに対応するデータ名が含まれている場合には、前記サーバ装置は、前記要求データ名リストに記されたデータ名に対応するデータのうち、前記クライアント装置がアクセス可能なデータのみを前記クライアント装置へ送信するとともに、前記要求データ名リストに記されたデータ名のうち、前記クライアント装置がアクセス可能なデータに対応するデータ名のみに基づいて生成したリクエストＩＤを前記クライアント装置へ送信するようにしてもよい。

また、本発明に係る通信システムにおいては、前記サーバ装置が前記リクエストＩＤを生成する際に、前記要求データ名リストに記されたデータ名から計算されたハッシュ値を前記リクエストＩＤとするようにしてもよい。

本発明に係る通信システムによれば、クライアント装置が以前の要求と同じ組み合わせのデータをサーバ装置へ要求する際には、複数のデータ名が含まれる要求データ名リストではなく、リクエストＩＤをサーバ装置へ送信するため、要求データ名リストに多量のデータ名が含まれていたとしても、二度目以降の通信の際にはリクエストＩＤのみが送信されるため、クライアント装置が同一の要求を繰り返す際の通信量が低減される。

また、リクエストＩＤに付加された送信タイムスタンプが示す時刻における状態と現在時刻における状態とで差異があるデータのみがサーバ装置からクライアント装置へ送信される場合は、以前にクライアント装置へ送信された時刻以降に変化のないデータは送信されないため、クライアント装置へ送信されるデータの通信量が低減される。

また、クライアント装置がアクセス可能なデータに対応するデータ名のみに基づいてリクエストＩＤが生成されるようになっていると、複数のクライアント装置に別々のアクセス権（アクセス可能なデータとアクセス不可能なデータの割り当て）が設定されている場合に、異なるアクセス権を持つ２つ以上のクライアント装置が同一の要求データ名リストをそれぞれサーバ装置に送信したとしても、アクセス権に応じて別々のリクエストＩＤが生成されることになり、各クライアント装置のアクセス権が適切に管理される。また、クライアント装置がアクセス不可能なデータは送信されないため、通信量の低減も図られる。

また、要求データ名リストに記されたデータ名から計算されたハッシュ値がリクエストＩＤとされる場合には、データ名の組み合わせに応じて一意なリクエストＩＤを容易に生成することができる。

本発明に係る通信システムの実施形態の一例におけるサーバ装置とクライアント装置との関係を概略的に示す図。 同実施形態においてクライアント装置がデータ名リストをサーバ装置へ送信した場合の通信を概略的に示す図。 同実施形態においてクライアント装置がリクエストＩＤをサーバ装置へ送信した場合の通信を概略的に示す図。 同実施形態においてサーバ装置が行う処理の手順を示すフローチャート。 同実施形態におけるアクセス権の取り扱いを示す図。

図１に、本発明に係る通信システムの実施形態の一例を概略的に示す。図１に示すように、サーバ装置２０とクライアント装置３０はネットワーク１０（インターネットや電話回線のような公共のネットワーク、あるいは専用の通信網）を介して接続されており、複数存在するクライアント装置３０はそれぞれサーバ装置２０と通信を行うことが可能である。

サーバ装置２０は複数のデータを管理するためのデータベース（メインＤＢ２２）を備えている。このメインＤＢ２２にはクライアント装置３０が監視対象とするオブジェクトに関する複数のデータが記録されており、クライアント装置３０はネットワーク１０を介してサーバ装置２０へ要求を送信することによってこのメインＤＢ２２に記録されたデータへアクセスする。なお、メインＤＢ２２に記録されるデータは、そのデータが記録された時刻に関するデータと組にして記録される。

なお、監視対象の具体例としては、山間部に設けられておりダムなどの複数の水源と水路でつながった貯水池４０が挙げられる。すなわち、本実施形態の通信システムを用いることにより、システムのユーザは、山間部から離れた都市部に居ながらにして、山間部の貯水池に蓄積されている水の現在水位、水位の変化率（流量）、その貯水池が達するべき目標水位、水門の開閉状態、などの様々なデータを、都市部に設けられたクライアント装置３０を利用して監視することが可能となる。また、目標水位や水門の開閉状態などの一部のデータについては、都市部から指令を送って変更することも可能となる。この例では貯水池に設置された各種センサ（水位を測定するセンサなど）およびマニュピレータ（水門を開閉する装置など）と接続されたサーバ装置２０が貯水池の近隣に設けられ、このサーバ装置２０は各種センサが測定する貯水池のデータを時系列に沿ってメインＤＢ２２へ記録したり、マニュピレータを制御（そしてその結果をメインＤＢ２２へ記録）したりして貯水池に関するデータを管理する。ここで例えば現在水位の測定データは時間経過と共に変動するが、測定が行われた時刻のデータと組にして記録されることにより、「この時刻においてはこの水位だった」という、時系列に沿った情報が記録される。そして、都市部に分散して存在する多数のクライアント装置３０が、ユーザの操作に応じてネットワーク１０を介してサーバ装置２０と通信を行い、現在水位のデータを閲覧したり、目標水位のデータを変更したりする。

こうした通信システムにおいてサーバ装置２０によって管理されているデータへクライアント装置３０が初めてアクセスする場合、クライアント装置３０は、図２に示すように、必要とするデータに対応するデータ名を記した（列挙した）データ名リスト５２（要求データ名リスト）を作成し、このデータ名リスト５２をサーバ装置２０に対するメッセージに含めて送信する（通信Ａ１）。データ名リスト５２に記されるデータ名は、貯水池の例でいえば「水位」、「流量」といった、データに設定された属性（アトリビュート）である。

サーバ装置２０は、データ名リスト５２をクライアント装置３０から受信した際に、そのデータ名リスト５２に記されているデータ名に対応するデータ５４をメインＤＢ２２から取得する（通信Ａ２）とともに、データ名リスト５２に記されているデータ名を基にリクエストＩＤ５５を生成する。このとき、データ名リスト５２に記されているデータ名の組み合わせに対して一意なリクエストＩＤ５５が生成されるようにする。例えば２つのデータ名リスト５２について、両方のデータ名リスト５２に記されたデータ名の組み合わせが同一ならば、両方のデータ名リスト５２に対して生成されるリクエストＩＤ５５は同一となり、データ名の組み合わせが異なっていれば、２つの異なるリクエストＩＤ５５が生成される。例えばデータ名の羅列を１つのデータとしてハッシュ関数に入力することによって得られるハッシュ値をリクエストＩＤ５５とすることができる。

サーバ装置２０はメインＤＢ２２とは別にリクエストＩＤ用データベース（ＩＤＤＢ２４）を備えている。サーバ装置２０がリクエストＩＤ５５を生成した際に、生成されたリクエストＩＤ５５と、そのリクエストＩＤ５５の基となったデータ名リスト５２に記されたデータ名とが紐付けられたリクエストＩＤリスト５６が、ＩＤＤＢ２４に記録される（通信Ａ３）。

データ５４の取得とリクエストＩＤ５５の生成が完了したら、サーバ装置２０は取得したデータ５４と、生成したリクエストＩＤ５５とをクライアント装置３０へ返信（送信）する。このとき、サーバ装置２０からクライアント装置３０への送信が行われる時刻を示す送信タイムスタンプｔ１が、データ５４およびリクエストＩＤ５５に付加されてクライアント装置３０へ送信される（通信Ａ４）。

以上のようにして、クライアント装置３０はサーバ装置２０からデータ５４を受信することができる。このときにリクエストＩＤ５５も受信するので、以降の通信においてはデータ名リスト５２の代わりにリクエストＩＤ５５を用いることができる。図３に、リクエストＩＤ５５を用いた通信の様子を示す。リクエストＩＤ５５を得たクライアント装置３０は、サーバ装置２０にデータ５４を要求する際に、リクエストＩＤ５５を送信する（通信Ｂ１）。このとき、好ましくは前回の通信でサーバ装置２０から受信した送信タイムスタンプｔ１もリクエストＩＤ５５に付加されて送信される。

リクエストＩＤ５５を受信したサーバ装置２０は、そのリクエストＩＤ５５をＩＤＤＢ２４に記録されているリクエストＩＤリスト５６と照合して、リクエストＩＤ５５と紐付いているデータ名の組み合わせを取得する（通信Ｂ２）。そして、サーバ装置２０はそのデータ名に対応するデータ５４をメインＤＢ２２から取得する（通信Ｂ３）。

データ５４を取得したサーバ装置２０は、そのデータ５４に、今回の送信時刻を示す新規タイムスタンプｔ２を付加してクライアント装置３０へ返信する（通信Ｂ４）。このとき、好ましくはクライアント装置３０から受信した前回の送信タイムスタンプｔ１が示す時刻から変更のあったデータのみを送信する。図３の例では、目標水位のデータに変更がないため、通信Ｂ４においてクライアント装置３０へ送信されるデータ５４に目標水位が含まれていない。

以上のようにして、クライアント装置３０はリクエストＩＤ５５を用いてデータ５４を取得することができる。図２においてデータ名リスト５２を用いて通信を行った場合と比較すると、通信Ａ１において送信されるデータ名リスト５２には多数のデータ名が含まれるために通信Ａ１の通信量が大きくなっているのに対し、図３の通信Ｂ１ではリクエストＩＤ５５（および前回の送信タイムスタンプｔ１）のみが送信されるため、通信Ｂ１の通信量は通信Ａ１に比べて大幅に低減される。すなわち、リクエストＩＤ５５を用いた通信ではクライアント装置３０がデータ名リスト５２を送信する場合に比べて通信量が低減される。

図４のフローチャートに、サーバ装置２０がクライアント装置３０からメッセージを受信した場合の処理の手順を示す。ステップＳ０１においてクライアント装置３０からメッセージを受信したサーバ装置２０は、まずそのメッセージにリクエストＩＤ５５が含まれているかどうかを判定する（ステップＳ０２）。メッセージにリクエストＩＤ５５が含まれていない場合（ステップＳ０２−ＮＯ）、クライアント装置３０はメッセージを詳しく解析する（ステップＳ０３）。

クライアント装置３０から送信されるデータ名リスト５２を含むメッセージには、実際には単にデータ名が列挙されているだけではなく、マークアップ言語の一種であるＸＭＬなどを用いてデータの形式（数値なのか文字列なのかなど）といったメタデータも含めた記述がなされており、具体的にどのようなデータ名が記されているかについては、サーバ装置２０においてメッセージおよびデータ名リスト５２の解析を行う必要がある。ステップＳ０３にてメッセージを解析したサーバ装置２０は、データ名リスト５２に記されている（クライアント装置３０が要求している）データ名の組み合わせを抽出し、それらのデータ名からリクエストＩＤ５５を生成する（ステップＳ０４）。そして、データ名の組み合わせとリクエストＩＤ５５とを紐付けたリクエストＩＤリスト５６をＩＤＤＢ２４へ記録する（ステップＳ０５）。

一方、ステップＳ０２においてクライアント装置３０からのメッセージにリクエストＩＤ５５が含まれていた場合（ステップＳ０２−ＹＥＳ）には、サーバ装置２０はそのリクエストＩＤ５５をＩＤＤＢ２４と照合し、リクエストＩＤ５５に紐付いている（クライアント装置３０が要求している）データ名の組み合わせを取得する（ステップＳ０６）。

ステップＳ０５においてＩＤＤＢ２４への記録が完了した後、またはステップＳ０６においてデータ名の組み合わせの取得が完了した後、サーバ装置２０は、クライアント装置３０が要求しているデータ名に対応するデータ５４をメインＤＢ２２から取得する（ステップＳ０７）。ここで、クライアント装置３０から受信したメッセージに前回の送信タイムスタンプｔ１が含まれているかどうかが判定され（ステップＳ０８）、送信タイムスタンプｔ１が含まれていた場合（ステップＳ０８−ＹＥＳ）には、前回の送信タイムスタンプｔ１が示す時刻におけるデータ（前回データ）と現在時刻におけるデータ（現在データ）との比較が行われる（ステップＳ０９）。メインＤＢ２２に記録されているデータは、そのデータが記録された時刻に関するデータと組にして記録されているため、サーバ装置２０は、前回データと現在データとを比較することができる。比較の結果、メインＤＢ２２から取得したデータ５４のうち、現在データが前回データから変化していない項目が含まれていた場合には、その変化していない項目をデータ５４から削除する。

ステップＳ０８においてメッセージに送信タイムスタンプｔ１が含まれていないと判定された後（ステップＳ０８−ＮＯ）、またはステップＳ０９における比較が完了した後、サーバ装置２０はクライアント装置３０が要求しているデータ名に対応するデータ５４をクライアント装置３０へ返信する（ステップＳ１０）。このとき、ステップＳ０９において現在データが前回データから変化していない項目がデータ５４から削除されていた場合には、クライアント装置３０が送信したリクエストＩＤ５５に付加されていた送信タイムスタンプｔ１が示す時刻における状態と現在時刻における状態とで差異があるデータのみがクライアント装置３０へ送信されることになる。なお、ステップＳ１０において送信されるデータ５４には、今回の送信時刻を示すタイムスタンプが付加される。このタイムスタンプはクライアント装置３０の側で送信タイムスタンプｔ１または新規タイムスタンプｔ２として扱われる。

以上のようにして、サーバ装置２０はクライアント装置３０から受信したメッセージを処理する。図４のフローチャートからわかるように、クライアント装置３０がリクエストＩＤ５５を送信しなかった場合（データ名リスト５２を送信した場合）には、サーバ装置２０はステップＳ０３においてメッセージの解析を行う必要があるが、リクエストＩＤ５５が送信された場合には、ステップＳ０３を実行する必要がなくなる。すなわち、リクエストＩＤ５５が通信に用いられることで、サーバ装置２０はクライアント装置３０との通信のたびに毎回データ名リスト５２の解析を行う必要がなくなり、処理速度が向上する。

次に、クライアント装置３０にアクセス権が設定されている場合の通信の様子を図５に示す。例として、メインＤＢ２２に記録されているデータは「公開データ」と「機密データ」の２種類に分かれており、クライアント装置３０は公開データにはアクセス可能であるが、機密データにはアクセス不可能であるという設定がなされているものとする。

図２に示す場合と同様に、クライアント装置３０は自身が必要とするデータに対応するデータ名を記したデータ名リスト５２を作成し、このデータ名リスト５２をサーバ装置２０に対するメッセージに含めて送信する（通信Ｚ１）。このとき、データ名リスト５２には「機密データ」に属するデータに対応するデータ名が含まれているものとする（説明をわかりやすくするため、ここではデータ名自体が「機密データ」であるとする）。

クライアント装置３０からメッセージを受信したサーバ装置２０は、クライアント装置３０からのメッセージを解析することにより、データ名リスト５２に「機密データ」のデータ名が含まれていることを発見する。するとサーバ装置２０は、データ名リスト５２に記されているデータ名のうち「機密データ」以外のデータ名に対応するデータ、すなわちクライアント装置３０がアクセス可能な「公開データ」に属するデータのみをメインＤＢ２２から取得する（通信Ｚ２）。さらに、リクエストＩＤ５５を生成するにあたっては、データ名リスト５２に記されているデータ名のうち「機密データ」のデータ名を無視し、「公開データ」のデータ名のみに基づいてリクエストＩＤ５５を生成する。

そして、サーバ装置２０によって生成されたリクエストＩＤ５５と、そのリクエストＩＤ５５の基となったデータ名の組み合わせ（「公開データ」のデータ名のみが含まれ、「機密データ」のデータ名を含まない組み合わせ）とが紐付けられたリクエストＩＤリスト５６が、ＩＤＤＢ２４に記録される（通信Ｚ３）。

データ５４の取得とリクエストＩＤ５５の生成が完了したら、サーバ装置２０は取得したデータ５４と、生成したリクエストＩＤ５５とをクライアント装置３０へ返信（送信）する。このときは図２における通信Ａ４と同様に、サーバ装置２０からクライアント装置３０への送信が行われる時刻を示す送信タイムスタンプｔ１が、データ５４およびリクエストＩＤ５５に付加されてクライアント装置３０へ送信される（通信Ｚ４）。

以上の通信Ｚ１〜通信Ｚ４によれば、クライアント装置３０が「機密データ」に属するデータをサーバ装置２０に要求しても、クライアント装置３０が最終的に受信するデータ５４には「機密データ」に属するデータが含まれないことになり、クライアント装置３０のアクセス権が適切に管理される。また、リクエストＩＤ５５は「機密データ」のデータ名を含まないデータ名の組み合わせと紐付けられるため、クライアント装置３０がリクエストＩＤ５５をサーバ装置２０へ送信した場合には、サーバ装置２０は改めてクライアント装置３０のアクセス権の判定を行う必要がなくなり、処理が高速化される。

なおここでは１つのクライアント装置３０のみについて考えたが、複数のクライアント装置３０にそれぞれ別々のアクセス権が設定されている（どのデータが「機密データ」に相当するのかがクライアント装置３０によって異なる）場合には、サーバ装置２０は、リクエストＩＤ５５の生成の際に、データ名リスト５２を送信したクライアント装置３０がどれなのかを考慮して、各クライアント装置３０にとっての「公開データ」のみに関するリクエストＩＤ５５およびデータ５４を返信するようにすれば、各クライアント装置３０のアクセス権が適切に管理される。またリクエストＩＤ５５を用いた通信を行うことにより、複数のクライアント装置３０それぞれに対してアクセス権の判定を行うのが１回ずつで済み、処理が高速化される。

以上に説明した実施形態における通信システムによれば、ネットワーク１０上での通信量が低減され、またサーバ装置２０が行う処理の負担も低減されるため、全体として通信が高速化する。

なお上記の実施形態においてはリクエストＩＤ５５を生成する方法としてハッシュ値を用いることを例示したが、リクエストＩＤ５５の生成方法はこれに限るものではなく、例えば受信したデータ名リスト５２に対して、受信順に連番となるシリアル番号を割り当ててもよい。またハッシュ値を用いる場合、異なるデータ名の組み合わせに対して同一のハッシュ値が得られる（衝突する）ことがあるので、サーバ装置２０がリクエストＩＤ５５を生成する際に、こうしたハッシュ値の衝突が起こった場合の対策がなされるとよい。例えばサーバ装置２０はハッシュ値を生成した際にリクエストＩＤリスト５６を確認し、生成したハッシュ値が既に他のデータ名の組み合わせに対して紐付けられている場合には、生成したハッシュ値に所定の数値を加算するなどして、既存のリクエストＩＤ５５と異なる値のリクエストＩＤ５５を生成するようにすればよい。

また、クライアント装置３０から送信されるデータ名リスト５２が頻繁に更新される場合には、リクエストＩＤ５５が大量に生成されることとなり、リクエストＩＤリスト５６が肥大化してしまうので、一定の期間以上使用されなかったリクエストＩＤ５５は破棄される（ＩＤＤＢ２４から削除される）ようにするとよい。

１０ ネットワーク
２０ サーバ装置
３０ クライアント装置
５２ データ名リスト
５５ リクエストＩＤ

Claims (4)

1. 複数のデータを管理する少なくとも１つのサーバ装置と、ネットワークを介して前記サーバ装置と通信することにより前記複数のデータにアクセスする少なくとも１つのクライアント装置と、を含み、
   前記クライアント装置は、前記複数のデータのうち必要とするデータに対応するデータ名を記した要求データ名リストを前記サーバ装置へ送信し、
   前記サーバ装置は、受信した前記要求データ名リストに記されているデータ名に対応するデータを、前記要求データ名リストを送信したクライアント装置へ送信する通信システムにおいて、
   前記サーバは、前記クライアント装置から前記要求データ名リストを受信した際に、前記要求データ名リストに記されたデータ名の組み合わせに応じて一意なリクエストＩＤを生成して前記リクエストＩＤを前記クライアント装置へ送信するとともに、前記要求データ名リストに記されたデータ名と前記リクエストＩＤとを紐付けたリクエストＩＤリストを記録し、
   前記クライアント装置が前記リクエストＩＤを受信した後、前記クライアント装置が前回送信したものと同一の前記要求データ名リストを前記サーバ装置へ再度送信しようとする際には、前記クライアント装置は前記要求データ名リストの代わりに前記リクエストＩＤを前記サーバ装置へ送信し、
   前記リクエストＩＤを受信したサーバ装置は、前記リクエストＩＤに紐付いたデータ名に対応するデータを、前記リクエストＩＤを送信した前記クライアント装置へ送信すること
   を特徴とする通信システム。
2. 前記サーバ装置は、前記クライアント装置へデータを送信する際に、送信時刻を示す送信タイムスタンプを付加して送信し、
   前記クライアント装置は、前記サーバ装置へ前記リクエストＩＤを送信する際に、前記サーバ装置から受信した最新の前記送信タイムスタンプを前記リクエストＩＤに付加して送信し、
   前記サーバ装置は、前記クライアント装置から受信した前記リクエストＩＤに紐付いたデータ名に対応するデータのうち、前記リクエストＩＤに付加された前記送信タイムスタンプが示す時刻における状態と現在時刻における状態とで差異があるデータのみを前記クライアント装置へ送信すること
   を特徴とする請求項１に記載の通信システム。
3. 前記クライアント装置にはアクセス可能なデータとアクセス不可能なデータが設定されており、
   前記クライアント装置が前記サーバ装置へ送信した前記要求データ名リストに、前記クライアント装置がアクセス不可能なデータに対応するデータ名が含まれている場合には、前記サーバ装置は、前記要求データ名リストに記されたデータ名に対応するデータのうち、前記クライアント装置がアクセス可能なデータのみを前記クライアント装置へ送信するとともに、前記要求データ名リストに記されたデータ名のうち、前記クライアント装置がアクセス可能なデータに対応するデータ名のみに基づいて生成したリクエストＩＤを前記クライアント装置へ送信すること
   を特徴とする請求項１または請求項２に記載の通信システム。
4. 前記サーバ装置が前記リクエストＩＤを生成する際に、前記要求データ名リストに記されたデータ名から計算されたハッシュ値を前記リクエストＩＤとすること
   を特徴とする請求項１ないし請求項３のいずれか１項に記載の通信システム。
   

Images