JP2004326156A

JP2004326156A - クライアントサーバーシステム

Info

Publication number: JP2004326156A
Application number: JP2003115709A
Authority: JP
Inventors: Takeshi Ogawa; 武志小川; Katsumi Iijima; 克己飯島
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2003-04-21
Filing date: 2003-04-21
Publication date: 2004-11-18

Abstract

【課題】広域ネットワーク上でデジタルカメラから転送されるの画像を預かる画像サーバーにおいて、デジタルカメラ側の電池残量不足に応じてサービスの最適化を行い、電池残量不足による処理失敗を軽減する。
【解決手段】１）電池残量の少ないデジタルカメラに対して転送のバンド巾を優先的に割り当てる。２）バンド巾制御機能の無い伝送路において、動的にバンド巾計測を行い、全転送量の抑制を行う事で、優先的にバンド巾を割り当てることを可能とする。３）電池残量の少ないデジタルカメラに対してサーバー側のＣＰＵタイムを優先的に割り当てる。４）電池残量で転送可能なデータ量を超える転送要求を受け付けない。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
本発明は、複数の装置を接続可能な通信手段を用いてデジタルカメラの画像を転送する場合におけるプロトコル及び装置構成に関するものである。
【０００２】
【従来の技術】
近年インターネット上でユーザーのデジタル画像を預かり、印刷や閲覧等のサービスを利用できるサーバーが出現し、例えば特開２０００−２２２３２５「ホームページ作成ならびに公開システム」ではユーザーが専用のソフトウェアを使う事なく汎用のＷｅｂブラウザによってすべてのサービスが利用可能となるシステムが紹介されている。
【０００３】
上記のようなサーバーのサービスは接続経路のトラフィックやバンド巾の制約により接続時間がまちまちになるという特徴がある。一方、デジタルカメラのような小型端末は出来るだけ小さな電池搭載する事で携帯性を向上させる事ができるため、小さな電池でも安定したサービスを受けられる事が望ましい。
【０００４】
【発明が解決しようとする課題】
しかしながら、小さな電池を搭載した小型端末から画像を転送する場合に接続時間が予想以上に長くなってしまった場合に小型端末側の電池残容量不足によって画像の転送を中断せざるおえなくなるという欠点がある。
【０００５】
接続時間が長くなってしまう要因としては、▲１▼インターネットプロバイダの利用者の増加によるトラフィックの増加。▲２▼インターネットの利用者増加によるトラフィックの増加。▲３▼サーバーとインターネット間のバンド巾に対して利用者の増加。▲４▼サーバーの処理能力に対して利用者が増加。などが考えられる。サーバーとインターネット間のトラフィックとサーバーの能力に関しては、バンド巾の低い方の制約を受ける事となり、そのバンド巾は時間帯によらず一定であるが、インターネットプロバイダとインターネット上の利用者一人あたりのバンド巾は利用者の増加に比例して減少する。
【０００６】
また、ネットワークのバンド巾を動的に計測して送信するデータ量を制限するビデオデータ配信のシステムが特開平９−２７１００２で考案されている。
【０００７】
本発明が解決しようとする課題は電池を搭載した小型端末から画像を転送する際バンド巾の低下が原因で接続時間が長くなってしまい、その結果電池不足を起こして転送に失敗する頻度を低減したシステムを構築する事にある。
【０００８】
【課題を解決するための手段】
本願請求項１で示したクライアントサーバーシステムは、端末の電池残容量を管理する事によりサービスの最適化を行い、電池不足による処理の失敗頻度を低減する事を特徴とする。
【０００９】
また本願請求項２で示すクライアントサーバーシステムは端末の電池残容量の少ない端末に対して伝送路のバンド巾を優先的に割り当てる事で、電池残容量の少ない端末の接続時間を短縮し、電池不足による処理の失敗頻度を低減する。
【００１０】
本願請求項３で示すクライアントサーバーシステムはバンド巾制御機能の無い伝送路において、端末とサーバー間の伝送路のバンド巾計測手段を使って計測した結果を用いてバンド巾の分配を行い、バンド巾の分配に従って単位時間あたりの転送量を抑制するように動作する事によりバンド巾制御機能の無い伝送路においてもバンド巾の優先割り当てが可能となるように構成する。
【００１１】
本願請求項４で示すクライアントサーバーシステムは電池残容量の少ない端末に対して優先的にＣＰＵタイムを割り当てる事によって電池不足による処理の失敗頻度を低減する事を特徴とする。
【００１２】
請求項５で示すクライアントサーバーシステムは要求された処理に必要なサービス時間とクライアント側の電池残容量での稼動時間を比較し、稼働時間が不足した場合は要求された処理を受け付けないよう構成する。
【００１３】
【発明の実施の形態】
（第一の実施例）
図１は本発明第一の実施例の形態を示すものである。図１の１はネットワーク上で画像を預かるサービスを行う画像サーバー。図１の２は画像サーバーと広域ネットワークを接続する伝送路。図１の３は広域ネットワーク。図１の４はプロバイダと広域ネットワークを接続する伝送路。図１の５はプロバイダのサーバー。図１の６はプロバイダと端末を接続する伝送路。図１の７は端末機能を有するデジタルカメラを示す。
【００１４】
図１の７はデジタルカメラの機能を有し、通常用途において画像を撮影する事ができる。デジタルカメラのメモリーに蓄積された画像の中から印刷あるいはＷｅｂブラウザ等で閲覧する目的で図１の１の画像サーバーへ接続して画像をアップロードする。
【００１５】
図１の７のデジタルカメラから画像サーバーへ接続すると図１の１の画像サーバーは接続に応じて対応するサービスを実行するソフトウェアのインスタンスを生成する。マルチクライアントのシステムではクライアント毎のサービスを実現するインスタンスを生成するのが一般的である。
【００１６】
図２はバンド巾の割り当てを行うソフトウェアの構造を示したものである。図２の１はバンド巾の割り当てを行うバンド巾マネージャ図２の２はクライアント毎に生成されるインスタンス。図２の３はクライアントまでの伝送路のバンド巾を測定するバンド巾測定モジュールのインスタンスである。
【００１７】
図２の２のインスタンスはそれぞれバンド巾割り当てマネージャから割り当てられた割り当てバンド巾と図２の３のバンド巾測定によって測定されたクライアントとサーバー間のバンド巾およびクライアントのデジタルカメラの電池残容量、クライアント側が転送しようとしているデータの総容量をプロパティとして格納している。
【００１８】
図２の３のバンド巾測定はクライアントからのブロック転送に要する時間を計測して逆算するもので、本実施例の中では重要ではないため詳細な説明を省略する。
【００１９】
図２の１のバンド巾割り当てマネージャは画像サーバーから広域ネットワークまでの伝送路のバンド巾かサーバーの処理能力の上限によって制限されるバンド巾のどちらか低い方を総バンド巾として持つ。
【００２０】
図２の１のバンド巾割り当てマネージャは総バンド巾をすべてのクライアントへ分配する。
【００２１】
（バンド巾割り当て）
バンド巾割り当てマネージャがどのように総バンド巾を分配するのかを説明する。
【００２２】
図３はクライアントを管理するためのクライアントインスタンスのリストを示すインスタンス図である。
【００２３】
図３の１〜４のクライアントインスタンスは接続中のクライアントそれぞれの情報を持っており、リンクリストによって管理されている。リンクリストは常にクライアントの電池残容量順にソーティングされている。
【００２４】
図１の１のサーバーは図１の７のデジタルカメラと接続が完了すると、図１の７のデジタルカメラに対して電池の残容量を時間で正規化した値を問い合わせる。
【００２５】
以後図１の１のサーバーは定期的に図１の７のデジタルカメラの電池残容量を問い合わせ、図３のインスタンスの電池残容量プロパティを更新し、リストの順序をソーティングする。それにより図３のリストは常に電池残容量の順に並んでいる。
【００２６】
図３の１〜４のクライアントインスタンスは図２の３のバンド巾測定クラスによって測定されたクライアントとサーバー間の実質バンド巾をプロパティとして持っている。このプロパティも定期的に更新される。
【００２７】
図２の１のバンド巾割り当てマネージャがバンド巾を割り当てる処理を図４のフローチャートを使って説明する事とする。ステップ１０１でバンド巾マネージャがバンド巾割り当てを開始する。ステップ１０２では利用可能なバンド巾の変数ＡｖａｉｌａｂｌｅＢａｎｄＷｉｄｔｈに総バンド巾を代入している。総バンド巾はサーバーの転送能力とサーバーと広域ネットワーク間の伝送路のどちらかバンド巾の低い方と同じ値を保持している。ステップ１０２ではさらにｐＣｕｒｒｅｎｔＣｌｉｅｎｔへクライアントインスタンスリストの先頭の項目を代入し、ＲｅｍａｉｎＣｌｉｅｎｔＣｏｕｎｔへ総クライアント数を代入する。ステップ１０３ではｐＣｕｒｒｅｎｔＣｌｉｅｎｔがリストの最後を示しているかどうかを判断している。リストが空の場合はただちにステップ１１２へ分岐し、リストが空でなければステップ１０４へ分岐する。ステップ１０４ではｐＣｕｒｒｅｎｔＣｌｉｅｎｔの電池残容量が２０分以下かどうかを判断している。電池残容量が２０分以下ならステップ１０６へ分岐し、電池残容量が２０分以上ならステップ１０５へ分岐する。ステップ１０６ではバンド巾の割り当て上限値の変数であるＬｉｍｉｔｏｆＢａｎｄＷｉｄｔｈへ利用可能なバンド巾の変数ＡｖａｌｉｒａｂｌｅＢａｎｄＷｉｄｔｈの値を代入する。ステップ１０５ではバンド巾の割り当て上限値の変数であるＬｉｍｉｔｏｆＢａｎｄＷｉｄｔｈへ利用可能なバンド巾の変数ＡｖａｌｉｒａｂｌｅＢａｎｄＷｉｄｔｈの値を未だ割り当ての済んでいないクライアントの数を保持している変数ＲｅｍａｉｎＣｌｉｅｎｔＣｏｕｎｔの値で割った値を代入する。ステップ１０４、１０５、１０６のプログラムを要約すると電池残容量が２０分以上の場合は割り当て可能なバンド巾を残りのクライアントで均等に割った配分を実際に割り当てる上限とし、電池残容量が２０分以下の場合は割り当て可能なバンド巾のすべてを上限とするという事である。ステップ１０７ではクライアントが要求するバンド巾の一時変数であるＲｅｑｕｅｓｔＢａｎｄＷｉｄｔｈへクライアントとサーバーまでの実行的なバンド巾の変数であるＰｅｒｆｏｒｍａｎｃｅＢａｎｄＷｉｄｔｈを代入している。この値は図２の３のＥｓｔｉｍａｔｅＰｅｒｆｏｒｍａｎｃｅクラスによって計測された値であり、例えばクライアントとプロバイダの間の接続が２８ｋのモデムなのかＡＤＳＬの高速な回線なのかによって大きく異なる。２８ｋのモデムで接続している場合はそれ以上のバンド巾を要求する必要が無いため、要求値として計測値を使用する。ステップ１０８では要求値であるＲｅｑｕｅｓｔＢａｎｄＷｉｄｔｈと割り当て可能上限値であるＬｉｍｉｔｏｆＢａｎｄＷｉｄｔｈを比較して、ＬｉｍｉｔｏｆＢａｎｄＷｉｄｔｈの方が大きい場合ステップ１０９へＲｅｑｕｅｓｔＢａｎｄＷｉｄｔｈよりＬｉｍｉｔｏｆＢａｎｄＷｉｄｔｈの方が小さい場合ステップ１０９を実行せずにステップ１１０へ分岐する。ステップ１０９へ分岐した場合はＲｅｑｕｅｓｔＢａｎｄＷｉｄｔｈの値をＬｉｍｉｔｏｆＢａｎｄＷｉｄｔｈの値でリプレスしている。ステップ１０８、１０９のプログラムを要約すると、要求値が割り当て可能上限値を超えないようにしているという事である。ステップ１１０では割り当て可能バンド巾の変数であるＡｖａｉｌａｂｌｅＢａｎｄＷｉｄｔｈから要求値の変数であるＲｅｑｕｅｓｔＢａｎｄＷｉｄｔｈの値を引いて、クライアントへ割り当てたバンド巾を保持する変数であるｐＣｕｒｒｅｎｔＣｌｉｅｎｔ−＞ＡｌｌｏｃａｔｅｄＢａｎｄＷｉｄｔｈへ要求値の変数であるＲｅｑｕｅｓｔＢａｎｄＷｉｄｔｈを代入している。そしてステップ１１１で現在着目しているクライアントの変数であるｐＣｕｒｒｅｎｔＣｌｉｅｎｔへリスト上次のクライアントであるｐＣｕｒｒｅｎｔＣｌｉｅｎｔ−＞ｐＮｅｘｔを代入して、割り当てる残りのクライアント数を保持しているＲｅｍａｉｎＣｌｉｅｎｔＣｏｕｎｔの値をディクリメントしている。そしてステップ１０３へ分岐している。ステップ１０３からステップ１１１までのプログラムをｐＣｕｒｒｅｎｔＣｌｉｅｎｔがリストの最後を指し示すまで繰り返して処理する事によってすべてのクライアントへバンド巾の割り当てが行われる事になる。すべてのクライアントへバンド巾の割り当てが行われるとステップ１０３からステップ１１２へ分岐して処理が終了する。
【００２８】
図４のフローチャートのプログラムによって電池残容量が２０分以下のデジタルカメラは伝送路の限界までのバンド巾を分配し、電池残容量が２０分以上のデジタルカメラへは残ったバンド巾を均等に分配している。
【００２９】
（バンド巾制限）
上記のようにクライアントへバンド巾を分配した後、各クライアントはそのバンド巾を超えないように制限しながら転送しなければ総バンド巾を超えてしまう。
【００３０】
図１の７のデジタルカメラから画像サーバーへ接続した後、デジタルカメラ側のユーザーインターフェースを操作して画像の転送をスタートするが、プロトコル上はサーバーからのプルモデルによって画像転送が行われる。デジタルカメラ側からプッシュモデルによって画像を転送するよりもプルモデルの方がバンド巾抑制をやりやすいからである。
【００３１】
図５はそれぞれのクライアントから画像を受信するプロセスのフローチャートである。サーバーの中ではクライアント１つに対して１つのプロセスが生成されて独立に実行される。それぞれのプロセスは上記のクライアントリストのインスタンスの１つを参照して動作する。ステップ２００でプロセスがスタートしてステップ２０１で転送要求の累計データ量を保持する変数であるＴｏｔａｌＴｒａｎｓｆｅｒＲｅｑｕｅｓｔＳｉｚｅを０に初期化する。ステップ２０２では転送で使用したバンド巾の値を保持する変数ＴｒａｎｓｆｅｒＢａｎｄＷｉｄｔｈの算出を行っている。ＴｒａｎｓｆｅｒＢａｎｄＷｉｄｔｈは転送要求の累計データ量を経過時間で割った数字として計算している。したがって、経過時間が増えるとＴｒａｎｓｆｅｒＢａｎｄＷｉｄｔｈは減るが転送要求の累計であるＴｏｔａｌＴｒａｎｓｆｅｒＲｅｑｕｅｓｔＳｉｚｅが０なので、時間に関係なく最初は０が代入される事になる。その後ステップ２０３で使用したバンド巾と配分されているバンド巾を比較し、配分されているバンド巾の方が大きければステップ２０４へ配分されているより使用したバンド巾の方が大きければステップ２０２へ分岐する。ステップ２０２とステップ２０３を繰り返し実行する事で、時間の経過によってＴｒａｎｓｆｅｒＢａｎｄＷｉｄｔｈが減少するのでいずれはステップ２０４へ分岐する事になる。ステップ２０４ではデジタルカメラ側に対してブロック転送要求を送信し、その転送要求に応える受信用のスレッドを生成している。転送要求ブロックの大きさは１枚の画像のように大きな単位ではなく数キロバイトから数十キロバイト程度の小さな単位で行う。ステップ２０５では転送要求の累計を保持するＴｏｔａｌＴｒａｎｓｆｅｒＲｅｑｕｅｓｔＳｉｚｅに対してステップ２０４で送信した転送要求のサイズを加算する。ステップ２０６ではデジタルカメラ側の操作で転送を指示したデータのすべての転送が終了したらステップ２０７へ、まだ転送すべきデータがある場合はステップ２０２へ分岐する。ステップ２０２からステップ２０６は転送するデータが無くなるまで繰り返される。またステップ２０４では転送要求を送信した後で受信待ちになる替わりに受信スレッドを生成して処理を非同期に行っている。従ってステップ２０３の割り当てバンド巾に対して転送に使用するバンド巾が超えるまでの間ステップ２０２からステップ２０６の間を高速に繰り返し実行が可能となる。また、ステップ２０４で送信する転送要求のブロックサイズも数キロバイトから数十キロバイトと小さいのでステップ２０３でのオーバーランも非常に微小な程度に抑えられる。ステップ２０２からステップ２０６の間を高速に実行する事で短期間の間にたくさんの転送要求が送信される事になるが、その結果としてレスポンス待ちの無駄な時間が生じない為伝送路を有効に利用する事が出来る。ステップ２０２から２０３の繰り返しは時間経過によって再びＴｒａｎｓｆｅｒＢａｎｄＷｉｄｔｈの値が減少するまで行われ、一定期間後にまたステップ２０６までのプログラムが実行される。このしくみによってバンド巾を抑制する事が出来る。すべてのデータの転送が終了するステップ２０６からステップ２０７へ分岐し転送プロセスが終了する。
【００３２】
（失敗防止）
上記のようにバンド巾を割り当てて、全体のバンド巾を制限する事で電池残容量の少ない端末での失敗は軽減できるが、予め失敗の予測をする事によって無駄な接続料金の発生を防ぐ事が出来る。例えば図３の２のクライアントＢには２８ｋｂｐｓのバンド巾が割り当てられている。それに対して１５分の電池残容量しか無い。２８ｋｂｐｓだと１分で約１６９ｋＢｙｔｅの転送が可能である。従って、２，５３１ｋｂｙｔｅ以上の転送要求が失敗する事は予測できる。本願の第一の実施例ではこのような場合の転送要求に対して電池残量不足エラーという通知を端末へ送る。端末側のデジタルカメラは電池不足のため転送できないという趣旨のメッセージをユーザーに知らせるように動作する。これによって電池残量の不足による転送失敗を未然に防ぐ事ができ無駄な接続料金も節約できるだけでなく、無駄な転送によるバンド巾の占有も防げる。
【００３３】
（第二実施例）
サーバーで行うサービスとして画像の加工や利用者への情報提供サービスを行う場合、サーバー側のデータ検索や画像処理などの時間がかかる処理によって接続時間が長くなる事がある。サーバーはこのような処理をそれぞれのクライアント用に生成したプロセスによって行うが、プロセスはオペレーティングシステムによってスケジュールされており、ＣＰＵタイムを優先順位によって割り当てている。サーバーが電池残容量の少ないクライアントに対してＣＰＵタイムを優先的に割り当てられるようにプロセス生成を行う事によって電池残容量が少ない端末の処理が失敗に終わる可能性を下げる事が出来る。本願第二実施例ではサーバーが電池残容量の少ないクライアントに対してＣＰＵタイムを優先的に割り当てられるようにプロセス生成を行うものである。
【００３４】
（その他の実施例）
第一の実施例では、広域ネットワークを含む伝送路で接続していたために、実行バンド巾を計測する手段を用いていたが、ローカルにイーサーネット、ＦＤＤＩ、ＵＳＢなどの有限のバンド巾で複数の端末を接続した場合、バンド巾計測を行わない事を除けば第一の実施例同様の処理を適用できる。
【００３５】
ＡＴＭなどのバンド巾の管理機能を有する伝送路や、ＵＳＢのアイソクロナスモードなどのバンド巾制御機能を有する伝送路を用いた場合はそれらの機能を積極的に利用して電池残量の少ない端末へバンド巾を割り当てる事も可能である。
【００３６】
【発明の効果】
請求項１及び請求項２に示した発明によれば電池残容量の少ない端末に対して優先的にバンド巾が割り当てられる事によって電池不足による処理の中断失敗の頻度を下げる事が出来る。また、請求項３に示した発明によってバンド巾制御機能を持たない広域ネットワークを含む伝送路においても、単位時間あたりの総転送量を抑制する事で電池残容量の少ない端末に優先的に伝送路を配分する事が可能となる。また請求項４に示す発明によって電池残容量の少ない端末に対して優先的にサーバー側のＣＰＵタイムを割り当てられ電池不足で処理が中断失敗する頻度を下げる事ができる。
【００３７】
請求項５の発明によって電池残容量で処理を完了できない事を予測する事ができ、電池不足の処理が中断失敗する頻度を下げる事ができる。
【図面の簡単な説明】
【図１】本願第一の実施例の接続状態を示す図
【図２】本願第一の実施例におけるバンド巾マネージャのソフトウェア構造を示すクラス図
【図３】本願第一の実施例におけるクライアントインスタンスリストのソフトウェア構造を示すインスタンス図
【図４】本願第一の実施例におけるバンド巾マネージャのバンド巾割り当て処理のフローチャート図
【図５】本願第一の実施例におけるクライアント毎に生成される転送プロセスの処理を示すフローチャート図
【符号の説明】
１ネットワーク上で画像を預かるサービスを行う画像サーバー
２画像サーバーと広域ネットワークを接続する伝送路、
３広域ネットワーク、
４プロバイダと広域ネットワークを接続する伝送路、
５プロバイダのサーバー、
６プロバイダと端末を接続する伝送路、
７端末機能を有するデジタルカメラ

Claims

電池によって動作する端末装置と、複数の端末へサービスを提供するサーバー装置を有限のバンド巾の伝送路によって接続する場合において、端末側の電池残容量の情報を動的にサーバーで管理する事でサービスの最適化を行う事を特徴とするクライアントサーバーシステム。
電池残容量の少ない端末に対して優先的に伝送路のバンド巾を割り当てる事を特徴とする上記請求項１のクライアントサーバーシステム。
端末とサーバー間の伝送路のバンド巾を計測する手段を有し、上記端末とサーバー間の伝送路のバンド巾計測手段で計測した結果を用いてバンド巾の分配を行い、バンド巾の分配に従って単位時間あたりの転送量を抑制する事によって、バンド巾制御機能の無い伝送路においても、バンド巾の優先的割り付けを可能とした事を特徴とする上記請求項２のクライアントサーバーシステム。
電池残容量の少ない端末に対して優先的にＣＰＵタイムを割り当てる事を特徴とする上記請求項１のクライアントサーバーシステム。
端末側で要求した処理が端末側電池残容量で稼動可能な時間内に完了するかどうかを予測する手段を有し、上記予測手段の結果、処理が電池残容量で稼動可能な時間内に完了しない場合には処理要求を受け付けない事を特徴とする上記請求項１のクライアントサーバーシステム。