(57)【要約】【課題】クライアント数及びファイルサイズが共に大きい時でも、一度のデータ要求により、関連データを含めて配信でき、サーバ及びネットワークの負荷を軽減できるサーバクライアントシステムを提供する。【解決手段】本発明のサーバクライアントシステム１は、ブート情報及びＯＳを含む特定のＡＰシステムデータＤ１−１〜Ｄ２−ｎを供給可能なサーバ２と、サーバとネットワーク６で接続され、サーバから特定のＡＰシステムデータを取得して共通環境で使用される複数のクライアント５−１〜５−ｎから構成されるサーバクライアントシステムであって、サーバは複数のクライアントからのデータ要求を監視して、いずれかのクライアントからデータ要求がされた時に、データ要求されたデータＤ１−１及び当該データに関連してその後アクセスされる可能性のある関連データＤ１−２，Ｄ１−３を、複数のクライアントにマルチキャスト配信する。【選択図】図９
2010200206.tif 000002
【特許請求の範囲】
【請求項１】
ブート情報及びオペレーティングシステムを含む特定のアプリケーションシステムデータを供給可能なサーバと、前記サーバとネットワークで接続され、前記サーバから前記特定のアプリケーションシステムデータを取得して共通環境で使用される複数のクライアントから構成されるサーバクライアントシステムであって；
前記サーバは前記複数のクライアントからのデータ要求を監視して、いずれかのクライアントからデータ要求がされた時に、前記データ要求されたデータ及び当該データに関連してその後アクセスされる可能性のある関連データを、前記複数のクライアントにマルチキャスト配信する；
サーバクライアントシステム。
【請求項２】
前記クライアントはデータセットが異なる複数のグループに分類され、前記サーバは各グループのクライアントに対して、全グループが使用し得る共通データを前記複数のクライアントに一括してマルチキャスト配信し、各グループが使用し得る個別データをグループ別にマルチキャスト配信する；
請求項１に記載のサーバクライアントシステム。
【請求項３】
前記サーバは、データ送信開始時間を設定する配信タイマーを有し；
前記クライアントは、データ受信待機時間を設定する待受タイマーを有し；
前記サーバは、システムに属する１のクライアントからの最初のデータ要求を検出した場合、前記配信タイマーに前記データ要求に係るデータを使用し得る殆ど全てのクライアントが受信できるようにデータ送信開始時間を設定し、前記１のクライアント以外のクライアントに、前記待受タイマーに前記データ送信開始時間に対応するデータ受信待機時間を設定するように指示し、
前記１のクライアントと異なる他のクライアントから同一のデータ要求を検出した場合、前記配信タイマーに設定した前記データ送信開始時間を延長して再設定し、前記他のクライアント以外のクライアントに前記待受タイマーに設定した前記データ受信待機時間を延長して再設定するように指示し、
前記データ送信開始時間が再設定された場合は最後に再設定されたデータ送信開始時間が経過した時に、再設定されなかった場合は最初に設定されたデータ送信開始時間が経過した時に、前記データ要求されたデータ及び前記関連データを、前記複数のクライアントにマルチキャスト配信し；
前記クライアントは、前記サーバに前記データ要求を行うことができ、
前記データ要求を行なった１のクライアントは自発的に、前記１のクライアント以外のクライアントは前記サーバからのデータ受信待機時間の設定指示により、前記待受タイマーにデータ受信待機時間を設定して、データ受信の待機状態に入り、
前記サーバからデータ受信待機時間の延長指示があった場合、前記他のクライアント以外のクライアントは前記待受タイマーに設定した前記データ受信待機時間を延長して再設定して、データ受信の待機状態を継続し、
前記サーバから前記データ要求されたデータ及び前記関連データがマルチキャスト配信された時に、前記データ要求されたデータ及び前記関連データを受信する；
請求項１又は請求項２に記載のサーバクライアントシステム。
【請求項４】
前記サーバは、前記複数のクライアントにブート開始指示を送信し；
前記クライアントは、前記サーバからのブート開始指示を受信した時にブートを開始する；
請求項３に記載のサーバクライアントシステム。
【請求項５】
前記クライアントは、特定のアプリケーションシステムに係るブート情報配信完了後さらに一定時間経過後にブートを開始する；
請求項３に記載のサーバクライアントシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はサーバクライアントシステムに関する。詳しくは、クライアントはネットワークを介してサーバに保存されているデータを取得して、特定のアプリケーションシステムを起動するサーバクライアントシステムに関する。
【背景技術】
【０００２】
近年、ネットワークブートを取り入れたサーバクライアントシステムが普及してきた。ネットワークブートとは、クライアントがローカルエリアネットワーク（ＬＡＮ）等のネットワークを介してサーバに保存されているデータ（通常はファイル）を取得して、特定のアプリケーション（ＡＰ）に係るオペレーティングシステム（ＯＳ）を起動することをいう。クライアントが取得するデータには、ＡＰデータ（ＡＰ用プログラム及びデータ）だけでなく、ブート情報やＯＳを含むディスクイメージも含まれる。ディスクイメージを使用すると、クライアントは、恰もハードディスクからアプリケーションシステムを起動したと同様に、特定のＡＰを利用することができる。
【０００３】
図１３に従来のサーバクライアントシステムにおけるデータ配信の概念を示す。図１３（ａ）は１つのサーバから配信するサーバクライアントシステム５１Ａの例を示す。ブートサーバ（ブートを行なうサーバ）５２は特定のアプリケーションシステムデータ（本例ではディスクイメージ）５３を蓄積するデータベース５４を有し、複数クライアント５５−１〜５５−４がＬＡＮ５６を介してブートサーバ５２に接続されている。各クライアント５５−１〜５５−４は個別にブートサーバ５２にデータ５３を要求し、ブートサーバ５２は同一データ５３を各クライアント５５−１〜５５−４に時間を変えて個別に配信する。５７はＬＡＮ５６のスイッチである。図１３（ｂ）はサーバを分散して配信するサーバクライアントシステム５１Ｂの例を示す。サーバ５２−１，５２−２を分散することにより、各サーバ５２−１，５２−２に掛かる負荷は軽減される。複数のクライアント５５−１〜５５−２がＬＡＮ５６−１を介してブートサーバ５２−１に接続され、複数のクライアント５５−３〜５５−４がＬＡＮ５６−２を介してブートサーバ５２−２に接続されている。サーバ５２−１，５２−２はそれぞれ、特定のアプリケーションシステムデータ（本例ではディスクイメージ）５３を蓄積するデータベース５４−１，５４−２を有する。各クライアント５５−１〜５５−２は個別にブートサーバ５２−１にデータ５３を要求し、ブートサーバ５２−１は，同一データ５３を各クライアント５５−１〜５５−２に時間を変えて個別に配信する。各クライアント５５−３〜５５−４は個別にブートサーバ５２−２にデータ５３を要求し、ブートサーバ５２−２は，同一データ５３を各クライアント５５−３〜５５−４に時間を変えて個別に配信する。
【０００４】
図１４に従来のサーバクライアントシステムにおけるデータ配信手順の一例を示す。システムは例えば図１３（ａ）の構成とする。データ５３としてデータ５３−１〜５３−３を配信するものとする。クライアント５５−１，５５−２はそれぞれサーバ５２にデータ５３−１を要求し、サーバ５２は要求に応答してデータ５３−１をそれぞれクライアント５５−１，５５−２に時間を変えて個別に配信する。次に、クライアント５５−１，５５−２はそれぞれサーバ５２にデータ５３−２を要求し、サーバ５２は要求に応答してデータ５３−２をそれぞれクライアント５５−１，５５−２に時間を変えて個別に配信する。次に、クライアント５５−１，５５−２はそれぞれサーバ５２にデータ５３−３を要求し、サーバ５２は要求に応答してデータ５３−３をそれぞれクライアント５５−１，５５−２に時間を変えて個別に配信する。図ではクライアント数を２まで示しているが、クライアント数が多い場合でも、サーバ５２は各クライアントからの要求に応じて、クライアント毎に要求されたデータを時間を変えて個別に配信する。また、クライアントは自己のワークの処理を進めるために、データ５３−１が必要になったらデータ５３−１を要求し、受信後、処理を進め、さらにデータ５３−２が必要になったらデータ５３−２を要求するというように、必要なデータをその都度要求し、サーバ５２は要求の都度時間を変えて個別に配信する。
【０００５】
しかしながら、図１３（ａ），（ｂ）のサーバクライアントシステム共、個別に時間を変えて同一データ５３を配信するため、データ転送量＝クライアント台数×ファイルサイズ（ファイルが複数のときは、各ファイルのデータ量の和）となり、サーバ及びネットワーク５６，５６−１，５６−２の負荷は大きく、トラフィックは混雑する。このため、プログラムとデータを全プロセッサに共通なプログラムとデータで構成される共通ファイルとそれぞれのプロセッサに対応したプログラムとデータで構成される固有ファイルに分類し、共通ファイルを受信したプロセッサは、共通ファイルを次にロードすべきプロセッサが記述されたＩＰＬ（初期プログラム・ロード）制御情報から次にロードすべきプロセッサを認識して、当該プロセッサに共通ファイルを順次送信していく方式、ファイルサーバが複数のディスクレスコンピュータの１台からネットワークを介してブートデータの要求を受けたときに、所定時間待った後にブロードキャスト（不特定多数への同報通信）にて一斉に複数のディスクレスコンピュータに対してブートデータを供給する方式等が提案されている。（特許文献１，２参照）
【０００６】
図１５に従来のサーバクライアントシステムにおけるデータ配信手順の別の例を示す。この例では上述の従来例と同様に、サーバ５２はデータを要求したクライアント５５−１だけでなく、順次転送方式、ブロードキャスト、マルチキャスト（多数の相手を指定した同報通信）等により、ＬＡＮ５６を介して同じシステムに属する他のクライアント５５−２にも配信する例である。クライアント５５−１はサーバ５２にデータ５３−１を要求し、サーバ５２は要求に応答してデータ５３−１をクライアント５５−１及び５５−２に一斉に配信する。次に、クライアント５５−１はサーバ５２にデータ５３−２を要求し、サーバ５２は要求に応答してデータ５３−２をクライアント５５−１及び５５−２に一斉に配信する。次に、クライアント５５−１はサーバ５２にデータ５３−３を要求し、サーバ５２は要求に応答してデータ５３−３をクライアント５５−１及び５５−２に一斉に配信する。この例では、サーバはクライアントに一斉に配信可能であるが、異なるデータに関しては、データ毎に要求がされ、要求の都度、データ毎に配信する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開昭６１−２２８２４５号公報（第１図〜第４図、第３００頁右上欄第２行〜第３０１頁左上欄第９行）
【特許文献２】特開平０６−１６８１９８号公報（図１〜図４、段落００２４〜００４９）
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、サーバが個別のクライアントからのデータ要求に逐一応答する場合はもとより、サーバがデータ要求したクライアントだけでなく、ＬＡＮを介して同じシステムに属する他のクライアントにもデータを一斉に配信する場合でも、クライアントはデータが必要になる度にデータ要求を行い、サーバはその都度要求を受けて配信しなければならないという問題があった。また、多数のデータが必要な場合に、その都度要求を受けて配信すると、サーバとクライアントの間で何度もデータ要求と応答を繰り返さなければならず、特に、クライアント数が多い場合には、サーバが処理しなければならない要求数が多くなり、処理しきれなくなるという問題があった。すなわち、サーバ及びネットワークの負荷が増大するという問題があった。
【０００９】
特に、パソコン実習（授業と演習を行なう）用のコンピュータシステムにおいては、学生が一斉にコンピュータ（クライアント）を起動すると、データ要求数が多くなり、さらに、データ量が大きい時は応答に時間がかかり、ブートサーバが要求を処理しきれないという問題があった。授業では先生の指示に従って、学生が特定の操作を一斉に行なうことがしばしばあり、起動時に限らず、サーバへのアクセス集中が引き起こされる頻度が高い。このため、サーバからの応答がすぐに得られないためクライアントを起動するまでに長時間かかってしまうおそれも多い。データの転送量＝クライアント数×ファイルサイズとなるために、クライアント数及びファイルサイズが共に大きい場合には、データの転送量が膨大になり、また、アクセスされるファイル数が大量の場合にも要求数が多大になり、サーバ及びネットワークの負荷が増大するおそれも多い。すなわち、サーバ及びネットワークの負荷が増大するという問題が特に顕著であった。
【００１０】
本発明はかかる問題に鑑みてなされたものであり、クライアント数及びファイルサイズが共に大きい場合又はアクセスされるファイル数が多数の場合でも、一度のデータ要求により、関連データを含めて配信でき、これによりサーバ及びネットワークの負荷を軽減できるサーバクライアントシステムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するため、本発明の第１の態様のサーバクライアントシステム１は、例えば、図３及び図９に示すように、ブート情報及びオペレーティングシステム（ＯＳ）を含む特定のアプリケーションシステムデータＤ１−１〜Ｄ２−ｎを供給可能なサーバ２と、サーバ２とネットワーク６で接続され、サーバ２から特定のアプリケーションシステムデータＤ１−１〜Ｄ２−ｎを取得して共通環境で使用される複数のクライアント５−１〜５−ｎから構成されるサーバクライアントシステム１であって、サーバ２は複数のクライアント５−１〜５−ｎからのデータ要求を監視して、いずれかのクライアントからデータ要求がされた時に、データ要求されたデータＤ１−１及び当該データＤ１−１に関連してその後アクセスされる可能性のある関連データＤ１−２，Ｄ１−３を、複数のクライアント５−１〜５−ｎにマルチキャスト配信する。
【００１２】
ここにおいて、ブート情報とは、クライアントに電源を投入してからデスクトップ画面が表示されるまでに必要なデータをいい、ＯＳ及びシステムの起動に利用される一部のＡＰに含まれる。また、アプリケーションシステムデータは当然ＡＰデータ（ＡＰ用のプログラム及びデータ）を含む。従ってアプリケーションシステムデータは大別すると、ＯＳとＡＰデータからなり、ブート情報はこれらのＯＳ及びＡＰデータの一部に含まれる。また、共通環境で使用されるとは、例えばパソコンを利用した授業や演習のように、共通のネットワーク上で共通のプロトコルに則して情報通信を行ない、共通のＯＳ及び共通のＡＰを用いて使用されることを意味する。
【００１３】
本態様のように構成すると、クライアント数及びファイルサイズが共に大きい場合又はアクセスされるファイル数が多数の場合でも、一度のデータ要求により、関連データを含めてマルチキャスト配信で一斉に配信でき、これによりサーバ及びネットワークの負荷を軽減できるサーバクライアントシステムを提供できる。すなわち、クライアントを一斉に起動しても、データ転送量＝約１×ファイルサイズとなり、クライアントを１台起動するのとほぼ同じ時間で起動でき、さらに一度のデータ要求により、関連データを含めて一斉に配信できるので、サーバ及びネットワークに掛かる負荷を大いに軽減できる。
【００１４】
また、本発明の第２の態様のサーバクライアントシステム１は、第１の態様のサーバクライアントシステムにおいて、例えば図１２に示すように、クライアント５−１〜５−ｎはデータセットが異なる複数のグループに分類され、サーバ２は各グループのクライアントに対して、全グループが使用し得る共通データを複数のクライアントに一括してマルチキャスト配信し、各グループが使用し得る個別データをグループ別にマルチキャスト配信する。
【００１５】
ここにおいて、複数のグループとして、例えばＡ教室とＢ教室で別の授業が行なわれている場合が挙げられる。この場合、２つの教室で利用するＡＰデータ（ＡＰ用プログラム及びデータ）が異なる可能性がある。このため、クライアントをＡ教室とＢ教室にグループ分けしておくことにより、ＡＰデータを共通用、Ａ教室用、Ｂ教室用に分けて配信可能である。また、授業や演習の展開により使用されるデータが変化し得るので、使用し得るデータには実際に使用されるデータの他に使用される可能性のあるデータも含むものとする。
【００１６】
本態様のように構成すると、共通データについては、一度のデータ要求により、関連データを含めてデータを一括してマルチキャスト配信でき、サーバ及びネットワークの負荷を軽減できる。また、個別データについても、グループ毎に関連データを含めてまとめてマルチキャスト配信でき、サーバ及びネットワークの負荷を軽減できる。また、ＬＡＮ上の同一セグメントに存在する複数のグループに対して同じデータを配信したり、グループ毎に特定のデータを配信することが可能になる。また、グループ分けにより、グループの異なる必要でないデータを受け取らずにすむ。
【００１７】
特に、パソコン実習用のコンピュータシステムにおいては、授業では基本的に学生は全員同じプログラムを使用する。したがって、ある１人の学生がデータとして当該プログラムをデータ要求し当該プログラムを起動すると、他の学生達にも当該プログラムが配信される。すなわち、出席者全員からのデータ要求を待たずにマルチキャスト配信を行なうケースでは、進展の遅い学生には常にプログラムがダウンロードされた状態になり、サーバにアクセスする必要がなくなる。同時に、当該プログラムに関連するデータ、例えば当該プログラムが必要とする別のプログラム等もまとめて配信されるので、理想的には、サーバとクライアント間の通信が最初のＯＳのデータ要求とその応答だけで済む可能性がある。
【００１８】
また、本発明の第３の態様のサーバクライアントシステム１は、第１の態様又は第２の態様のサーバクライアントシステムにおいて、例えば、図３及び図９に示すように、サーバ２は、データ送信開始時間を設定する配信タイマー１３を有し、クライアント５−１〜５−ｎは、データ受信待機時間を設定する待受タイマー２３を有し、サーバ２は、システムに属する１のクライアントからのデータ要求を検出した場合、配信タイマー１３ーにデータ要求に係るデータを使用し得る殆ど全てのクライアントが受信できるようにデータ送信開始時間を設定し、１のクライアント以外のクライアントに、待受タイマー２３にデータ送信開始時間に対応するデータ受信待機時間を設定するように指示し、１のクライアントと異なる他のクライアントから同一のデータ要求を検出した場合、配信タイマー１３に設定したデータ送信開始時間を延長して再設定し、他のクライアント以外のクライアントに待受タイマー２３に設定したデータ受信待機時間を延長して再設定するように指示し、データ送信開始時間が再設定された場合は最後に再設定されたデータ送信開始時間が経過した時に、再設定されなかった場合は最初に設定されたデータ送信開始時間が経過した時に、データ要求されたデータ及び関連データを、複数のクライアントにマルチキャスト配信し、クライアント５−１〜５−ｎは、サーバ２にデータ要求を行うことができ、データ要求を行なった１のクライアントは自発的に、１のクライアント以外のクライアントはサーバ２からのデータ受信待機時間の設定指示により、待受タイマー２３にデータ受信待機時間を設定して、データ受信の待機状態に入り、サーバ２からデータ受信待機時間の延長指示があった場合、他のクライアント以外のクライアントは待受タイマー２３ーに設定したデータ受信待機時間を延長して再設定して、データ受信の待機状態を継続し、サーバ２からデータ要求されたデータ及び関連データがマルチキャスト配信された時に、データ要求されたデータ及び関連データを受信する。
【００１９】
ここにおいて、データを使用し得る殆ど全てのクライアントとは、システムに属し電源投入されたクライアント（授業や演習では全出席者）の殆ど全てであり、殆ど全てとは、全てを目標とするが、トラフィックやＰＣ等のトラブルを考慮し多少の漏れがあっても良い（例えば１０台中９台であれば９０％）ことを意味する。データ要求は、典型的にはシステムに属し電源投入された全てのクライアントから行なわれる。最初のＯＳ起動時には、クライアンントの電源投入時のばらつき等により、マルチキャスト配信を受信可能になっていない場合も生じ得るので、これら全てのクライアントからのデータ要求を受けて、配信タイマーの再設定を適宜行なう必要がある。これに対して、その後のＯＳ又はＡＰ起動時には、サーバ２からのデータ受信待機時間設定の指示により、クライアント側は一斉に受信待機状態に入り、直ぐに受信準備ができるので、サーバは、必ずしも他のクライアントからのデータ要求がある度にデータ送信開始時間の再設定とデータ受信待機時間の延長指示を繰り返し行なう必要はない。例えば所定の時間（例えば１ｍｉｎ）を決めて当該時間内にまとまって（例えば８０％）データ要求があった時、当該時間（この例では１ｍｉｎ）経過後に、又はシステムに属し電源投入されたクライアント数（出席者数）の所定の割合（例えば７０％）に達した後に、再設定を行ない、再設定されたデータ送信開始時間の経過後にマルチキャスト配信を行なっても良く、再設定を行わずに、データ送信開始時間の経過後にマルチキャスト配信を行なっても良い。また、データ要求数を計数しシステムに属し電源投入されたクライアント数になった後に、又はシステムが安定している等理想的な場合には１つのクライアントからのデータ要求を検出した後に、最初に設定されたデータ送信開始時間の経過後に、又は直ちにマルチキャスト配信を行なっても良い。さらに、データ要求されたデータに関連しないデータでもデータ要求がされることが確実なデータがある場合には、データ受信待機時間の解除をせずに、受信待機時間を継続すれば、１つのクライアントからのデータ要求を受信した時点で、データ送信開始時間の設定とデータ受信待機時間の継続設定を行ない、ことさら、データ送信開始時間の延長をしなくても良い。また、複数のクライアントから異なるデータ要求があった場合には、データの優先順位を定め、優先順位に従って順次配信することが好ましい。また、データ送信開始時間は開始時間を設定し、データ受信待機時間は終了時間を設定する。また、データ送信開始時間に対応するデータ受信待機時間とは、配信すべき殆ど全てのデータを配信した後にデータ受信待機時間が終了するようにデータ受信待機時間が設定されることを意味する。また、最後に再設定されたデータ送信開始時間とは、再設定が複数回行なわれた場合に最後に再設定されたデータ送信開始時間をいう。再設定が１回だけ行なわれた場合には、当該再設定が最後の再設定に該当する。再設定されなかった場合には、データ送信開始時間は当然、最初に設定されたデータ送信開始時間となる。
【００２０】
本態様のように構成すると、データをマルチキャスト配信するに際して、配信タイマーを用いてデータ送信開始時間を定めることにより、データを使用し得るクライアントのデータ受信を確実にでき、効率の良い配信を行なうことができる。また、他のクライアントからのデータ要求を契機にデータ送信開始時間を延長することにより、データを使用し得るクライアントのデータ受信を一層確実にできる。
【００２１】
また、本発明の第４の態様のサーバクライアントシステム１は、第３の態様のサーバクライアントシステムにおいて、サーバ２は、複数のクライアント５−１〜５―ｎにブート開始指示を送信し、クライアント５−１〜５―ｎは、サーバ２からのブート開始指示を受信した時にブートを開始する。
ここにおいて、ブートとは、特定のアプリケーションシステムに係るブート情報配信完了後、特定のアプリケーションシステムをデスクトップ画面に表示し、操作可能にするためのブート（起動）をいう。本態様のように構成すると、複数のクライアントについてブートの条件が整った時に一斉にブートを行なうことができ、ブートを確実化できる。
【００２２】
また、本発明の第５の態様のサーバクライアントシステム１は、第３の態様のサーバクライアントシステムにおいて、クライアント５−１〜５―ｎは、特定のアプリケーションシステムに係るブート情報配信完了後さらに一定時間経過後にブートを開始する。
本態様のように構成すると、サーバからのブート開始指示がなくても、一定時間マージンをとってブートを行なうので、ブートを確実化できる。
【発明の効果】
【００２３】
本発明によれば、クライアント数及びファイルサイズが共に大きい場合又はアクセスされるファイル数が多数の場合でも、一度のデータ要求により、関連データを含めて配信でき、これによりサーバ及びネットワークの負荷を軽減できるサーバクライアントシステムを提供できる。
【図面の簡単な説明】
【００２４】
【図１】実施例１のサーバクライアントシステムにおけるデータ配信の概念を示す図である。
【図２】実施例１のサーバクライアントシステム１のハード構成例を示す図である。
【図３】実施例１のサーバクライアントシステム１の機能構成例を示す図である。
【図４】プロファイル管理表の例を示す図である。
【図５】サーバの処理フロー例を示す図である。
【図６】クライアントの処理フロー例（その１）を示す図である。
【図７】クライアントの処理フロー例（その２）を示す図である。
【図８】クライアントの処理フロー例（その３）を示す図である。
【図９】実施例１におけるサーバとクライアント間の情報通信シーケンス例を示す図である。
【図１０】サーバとクライアント間の起動シーケンス例を示す図である。
【図１１】起動時間を比較した図である。
【図１２】実施例２におけるサーバとクライアント間の情報通信シーケンス例を示す図である。
【図１３】従来のサーバクライアントシステムにおけるデータ配信の概念を示す図である。
【図１４】従来のサーバクライアントシステムにおけるデータ配信手順の例を示す図である。
【図１５】従来のサーバクライアントシステムにおけるデータ配信手順の別の例を示す図である。
【発明を実施するための形態】
【００２５】
以下、図面を参照して、本発明の実施の形態について説明する。尚、各図において、互いに同一又は相当する部分には同一符号を付し，重複した説明は省略する。
【実施例１】
【００２６】
本実施例はパソコン実習室におけるサーバクライアントシステム１の例について説明する。サーバ２と多数のクライアント５がＬＡＮ６で接続されている。例えばサーバ２はサーバ室に、これらのクライアント５は１つの実習室内に設置されている。
【００２７】
図１に本実施例のサーバクライアントシステム１におけるデータ配信の概念を示す。ブートサーバ（ブートも行なうサーバ）２は特定のアプリケーションシステムデータ（本例ではディスクイメージ）３を蓄積するデータベース４を有し、複数のクライアント５−１〜５−４がＬＡＮ６を介してブートサーバ２に接続されている。アプリケーションシステムデータにはＡＰデータ（ＡＰ用プログラム及びデータ）及びＯＳが含まれる。また、ブート情報はこれらのＯＳ及びＡＰデータの一部に含まれる。システムに属する１つのクライアント、例えば５−１がブートサーバ２にデータ３を要求すると、ＬＡＮ６を介したマルチキャスト配信により同一データ３が各クライアント５−１〜５−４に配信され、さらに、データ３に関連する関連データも各クライアント５−１〜５−４に配信される。７はＬＡＮ６のスイッチである。マルチキャスト配信を行なうので同一ファイルは１回だけ送信されれば良く、さらに、その関連ファイルも１回だけ送信されれば良い。これによりサーバ及びネットワーク６の負荷を大いに軽減でき、サーバ数も削減できる。
【００２８】
［システム構成］
図２に本実施例のサーバクライアントシステム１のハード構成例を示す。サーバ（ブートサーバ）２は特定のアプリケーションシステムデータ（ディスクイメージ）３を蓄積する外部記憶装置（データベース）４を有し、複数のクライアント５−１，・・・５−ｎがＬＡＮ６を介してサーバ２に接続されている。
【００２９】
サーバ２は、外部記憶装置４、中央処理装置（ＣＰＵ）１１、メモリ１２、タイマー１３、ネットワークインターフェース１４及びこれらを接続するバス１５を有する。外部記憶装置４はクライアント５に配信する特定のアプリケーションシステムデータとして、データＤ１−１〜Ｄ１−ｎ，Ｄ２−１〜Ｄ２−ｎを有する。これらのデータには、ＯＳ及びＡＰデータが含まれる。また、ブート情報はこれらのＯＳの一部及びＡＰデータの一部に含まれる。したがって、これらのデータには、ディスクイメージも含まれる。クライアントはこれらのデータを取得することにより、恰もハードディスクからアプリケーションシステムを起動したと同様に、ＡＰを利用することができる。ＣＰＵ１１はメモリ１２に格納された制御用プログラムを読み出し、サーバ２の各部を制御して、サーバ２にブートサーバとしての機能を実行させる。メモリ１２はＲＯＭ（読み出し専用メモリ）に制御用プログラム等を格納し、ＲＡＭ（ランダムアクセスメモリ）にクライアントに配信するために外部記憶装置４から抽出したデータや制御用データ等を一時的に保存する。タイマー１３は配信タイマーとして使用され、データを使用し得る全クライアントが受信待機時にデータ３をマルチキャスト配信できるように、データ送信開始時間が設定される。なお、全クライアントは目標であり、トラフィックやＰＣ等のトラブル等により多少の漏れが生じる場合を許容する。ネットワークインターフェース１４は、例えばＴＣＰ／ＩＰプロトコルに適合するようにデータを処理してネットワーク６に入出力する。
【００３０】
クライアント５−１，・・・５−ｎは外部記憶装置２０、中央処理装置（ＣＰＵ）２１、メモリ２２、タイマー２３、ネットワークインターフェース２４及びこれらを接続するバス２５を有する。外部記憶装置２０はサーバ２から取得した特定のアプリケーションシステムデータ（ＯＳ及びＡＰデータ）を保存するために使用される。「キャッシュ」は取得されたデータが記憶されている領域を示し、「未使用」は空きスペース領域を示す。なお、外部記憶装置２０に代えてメモリ２２に特定のアプリケーションシステムデータを保存しても良い（クライアント５−ｎ参照）。クライアント５はブート情報を含む、ＯＳ、ＡＰデータ等の特定のアプリケーションシステムデータを取得することにより、ＡＰを利用可能となる。ＣＰＵ２１はサーバ２から取得されメモリ２２に格納されたＯＳ２９により、クライアント５の各部を制御して、クライアント５にコンピュータとしての機能を実行させる。メモリ２２はＲＯＭにＢＩＯＳ等を格納し、ＲＡＭにクライアント５がサーバ２から取得したＯＳやＡＰデータ等を保存する。タイマー２３は待受タイマーとして使用され、サーバ２からマルチキャスト配信されるデータ要求されたデータ（Ｄ１−１等）及び当該データに関連するデータを待ち受けるデータ受信待機時間（終了時間）が設定される。その際に、クライアント５はデータ受信可能な状態（データ受信待機状態）で待機し、その間にデータ要求がデータ要求部２６からサーバ２に行なわれるのを一時的に中止する。データ受信待機時間は、配信すべき全てのデータを配信した後にデータ受信待機時間が終了するように設定される。ネットワークインターフェース２４は、ＴＣＰ／ＩＰ等のプロトコルに適合するようにデータを処理してネットワーク６に入出力する。なお、全てのデータは目標であり、トラフィックやＰＣ等のトラブル等により多少の漏れが生じる場合を許容する。
【００３１】
図３に本実施例のサーバクライアントシステム１の機能構成例を示す。サーバ室にサーバ２が、実習室の教師及び学生の机上にシステムに属するクライアント５−１〜５−ｎが設置されている。実習の開始時にクライアント５−１〜５−ｎを一斉に立ち上げる。クライアント５−１〜５−ｎはサーバ２からパソコン実習に係るＡＰだけでなく、ブート情報やＯＳを含むディスクイメージを取得して、起動し、ＡＰを利用する。ただし、クライアント５−１〜５−ｎはデータセット（ディスクイメージを含む）で示されるデータの全てを取得する必要はなく、ＯＳの必要な部分、ＡＰを実行するために必要な部分を取得すれば良い。サーバ２は、ＨＴＴＰサーバ機能によりデータセットを公開する。また、サーバ２は、クライアント５−１〜５−ｎに対してネットワークブートを行なわせる機能（ＰＸＥ）、特定の複数のクライアント５−１〜５−ｎに対して同時に同一データを送信するマルチキャスト配信機能を有する。また、サーバ２は、クライアント５−１〜５−ｎに対してリモート操作による電源投入を行なう機能（ＷＯＬ）を有しても良く、本実施例ではこの機能を有するものとする。
【００３２】
クライアント５−１〜５−ｎはサーバ２から電源投入要求を受けると自電源を投入して起動し、最初はＰＸＥによりクライアントのハードウェア（ＰＸＥ対応ＢＩＯＳ及びネットワークインターフェース）がサーバ２から最小構成のＯＳ（ＯＳの中核になるカーネル及びブート起動に必要最小限のミニルート等）を取得する。最小構成のＯＳはメモリ２２のＯＳ領域に取得され、クライアントで実行される。メモリ２２のＯＳ領域に取得されたＯＳ２９は特定のアプリケーションシステムの実行に必要な環境の準備（デスクトップ環境の準備）を行なう。データ要求機能、待受タイマー機能及びマルチキャスト受信機能は最小構成のＯＳの中に含まれ、デスクトップの準備を始める前に動作する。これ以降はメモリ２２のＯＳ領域に取得されたＯＳ２９の管理により、環境の準備が実行される。最小構成のＯＳはＯＳの残りの部分（ディスクイメージ）のうち起動に必要なデータのデータ要求を行う。このようにして、順次ＯＳ領域にＯＳ２９が取得される。ＯＳの中でもブート情報に係る部分は早い段階で取得されることが好ましい。これらのネットブートにより、特定のアプリケーションシステムに必要なＯＳ２９がＯＳ領域に取得されると、以後はこのＯＳ２９が順次ＡＰに係るディスクイメージを要求する。ＡＰの中でもブート情報に係る部分は早い段階で取得されることが好ましい。サーバ２側でデータ送信開始時間になると、各データ（ディスクイメージ）がマルチキャスト配信される。
【００３３】
サーバ２は、クライアントからのデータ要求を監視し、要求されたデータ及びそれに関連するデータをマルチキャスト配信する。そして、タイマーで同期制御を行い、一斉に配信する。クライアント５−１〜５−ｎは、サーバ２からディスクイメージがマルチキャスト配信されると、ディスクイメージを取得して、ブートを行い、恰もハードディスクからアプリケーションシステムを起動したと同様に、ＡＰを利用することができる。ブート（起動）はＯＳ及びＡＰのブート情報が取得された段階で可能である。その他のＡＰはブート前に取得しても良く、ブート後に取得しても良い。ブートの前後共マルチキャスト配信が可能である。
【００３４】
サーバ２は、ＣＰＵ１１内にデータ要求管理部１６、配信タイマー設定部１７、配信管理部１８を有する。データ要求管理部１６はクライアントからのデータ要求を監視し、システム内の１つのクライアント（例えば５−１とする）からネットワークインターフェース１４を介してデータ要求があった場合は、配信タイマー設定部１７に配信タイマー１３にデータ送信開始時間を設定するように指示し、配信タイマー設定部１７は配信タイマー１３に予め定められたデータ送信開始時間を設定する。データ送信開始時間は、システムに属するクライアントのうち、データを使用し得る全てのクライアント（出席者５−１〜５−ｍとする）がデータを受信待機できる充分な時間に予め定められる。また、配信タイマー設定部１７はクライアント５−１〜５−ｍにネットワークインターフェース１４を介して受信待機時間（終了時間）を設定するように指示する。この指示により、クライアント５−１〜５−ｍはデータ受信可能な状態で待機し、待受タイマー２３に受信待機時間を設定する。また、データ要求管理部１６は、その後、システム内の他のクライアント（例えば５−２とする）からネットワークインターフェース１４を介してデータ要求があった場合は、配信タイマー設定部１７に配信タイマー１３にデータ送信開始時間を延長して再設定するように指示し、配信タイマー設定部１７は、配信タイマー１３にデータ送信開始時間を延長して再設定すると共に、クライアント５−１〜５−ｍ（５−２を除く）にネットワークインターフェース１４を介して受信待機時間（終了時間）を延長して再設定するように指示する。このように延長するのは、データを使用し得る全てのクライアントがデータを確実に取得できるようにするためである。
【００３５】
データ要求は、典型的にはシステムに属し電源投入された全てのクライアントから行なわれる。最初のＯＳ起動時には、クライアンントの電源投入時のばらつき等により、マルチキャスト配信を受信可能になっていない場合も生じ得るので、これら全てのクライアントからのデータ要求を受けて、配信タイマーの再設定を適宜行なう必要がある。これに対して、その後のＯＳ又はＡＰ起動時には、サーバ２からのデータ受信待機時間設定の指示により、クライアント側は一斉に受信待機状態に入り、直ぐに受信準備ができるので、サーバは、必ずしも他のクライアントからのデータ要求がある度にデータ送信開始時間の再設定とデータ受信待機時間の延長指示を繰り返し行なう必要はない。例えば所定の時間（例えば１ｍｉｎ）を決めて当該時間内にまとまって（例えば８０％）データ要求があった時、当該時間（この例では１ｍｉｎ）経過後に、又はシステムに属し電源投入されたクライアント数（出席者数）の所定の割合（例えば７０％）に達した後に、再設定を行ない、再設定されたデータ送信開始時間の経過後にマルチキャスト配信を行なっても良く、再設定を行わずに、データ送信開始時間の経過後にマルチキャスト配信を行なっても良い。また、データ要求数を計数しシステムに属し電源投入されたクライアント数になった後に、又はシステムが安定している等理想的な場合には１つのクライアントからのデータ要求を検出した後に、最初に設定されたデータ送信開始時間の経過後に、又は直ちにマルチキャスト配信を行なっても良い。さらに、データ要求されたデータに関連しないデータでもデータ要求がされることが確実なデータがある場合には、データ受信待機時間の解除をせずに、受信待機時間を継続すれば、１つのクライアントからのデータ要求を受信した時点で、データ送信開始時間の設定とデータ受信待機時間の継続設定を行ない、ことさら、データ送信開始時間の延長をしなくても良い。また、データ要求管理部１６は、配信管理部１８に要求されたデータ及び関連するデータを、外部記憶装置４からメモリ１２の配信待ちデータキュー表１９Ａに登録し、データ送信開始時間になったらネットワークインターフェース１４を介してクライアント５−１〜５−ｍに送信するように指示する。要求されたデータに関連するデータはメモリ１２内のプロファイル管理表１９Ｂに登録される。また、外部記憶装置４はデータセットＤ１（データＤ１−１〜Ｄ１−ｎ）とデータセットＤ２（データＤ２−１〜Ｄ２−ｎ）を保存し、各データがディスクイメージとしてブロック化されている。ただし、カーネル、ミニルートはブロック化の対象外である。
【００３６】
図４にプロファイル管理表１９Ｂの例を示す。左欄に要求されたデータを、右欄に当該データに関連するデータを一覧表形式で掲載している。例えばデータＤ１−１にはデータＤ１−２とＤ１−３が関連する。またデータＤ１−２にはデータＤ１−３とＤ１−６が関連する。これを辿ることによりデータＤ１−１が要求された場合には、関連データとして、データＤ１−２、Ｄ１−３、Ｄ１−６等が挙げられる。
【００３７】
配信管理部１８は、要求されたデータ及び関連するデータを、プロファイル管理表１９Ｂを参照して外部記憶装置４からメモリ１２内の配信待ちデータキュー表１９−１に抽出しておく。データ送信開始時間に達する（配信タイマーがタイムアウトする）と、配信タイマー１３はリセットされ、配信タイマー設定部１７を介して配信管理部１８にタイムアウト信号が送信される。また、配信タイマー設定部１７はクライアント５−１〜５−ｍにネットワークインターフェース１４を介して、データを使用し得る全てのクライアント（授業や演習では全出席者）が要求されたデータ及び関連するデータを受信できるように受信待機時間の終了時間を設定するように指示する。なお、全ては目標であり、トラブルを考慮し多少の漏れがあっても良い。配信管理部１８は、タイムアウト信号を受信すると、メモリ１２の配信待ちデータキュー表１９−１に抽出された要求されたデータ及び関連するデータを、ネットワークインターフェース１４を介してクライアント５−１〜５−ｍにマルチキャスト配信する。サーバ２とクライアント５−１〜５−ｍ間の同期は最初のデータ配信時だけで良く、この１回の同期により、データを使用し得る全てのクライアントがデータを確実に取得できる。マルチキャスト配信が終了すると、配信タイマー設定部１７はクライアント５−１〜５−ｍにネットワークインターフェース１４を介して受信待機時間を解除するよう指示する。
【００３８】
クライアント５−１〜５−ｎは、データ要求部２６、待受タイマー設定部２７、受信管理部２８及びＯＳ２９を有する。クライアント５−１〜５−ｎはそれ自体ＯＳを保有せず、サーバ２のＰＸＥ機能を利用して、サーバ２からＯＳやブート情報を取得する。本実施例ではＰＸＥを用いて、電源投入時にＢＩＯＳとネットワークインターフェースによりサーバ２から最小構成のＯＳ（カーネル及びミニルート等）が読み込まれる。最小構成のＯＳはデータ要求部２６を設定し、以後はＯＳがデータ要求部２６に順次ＯＳ及びＡＰデータ（ＡＰ用プログラム及びデータ）のデータ要求を指示する。まず、ＯＳのうち起動に必要な部分が順次データ要求されて取得され、その後ＡＰデータが順次データ要求されて取得される。データ要求すべきデータはサーバ２によりＯＳに取り込まれ、或いはサーバ２からＯＳに付随して供給されるので、クライアントの機器の性能がそろっていれば、ほぼ同じタイミングでデータ要求が行なわれることになる。このように、データ要求部２６はＨＴＴＰサーバに必要なデータを順次要求し、メモリ２２のＯＳ領域にダウンロードする。また、データ要求部２６は仮想ブロックデバイスドライバの機能を有する。すなわち、実際にアクセスした部分のデータしか持っていなくても、ＯＳ２９には全体のデータがクライアント５−１〜５−ｎ上にあるように見せる働きをする。例えばサーバ２のデータセットに１００個のファイルがある場合、ＯＳ２９から一覧を見ると恰もクライアント５−１〜５−ｎ上に１００個あるように見えても、実際に使っているデータ（例えば２０個）しかクライアントはダウンロードしないという機能を提供している。そして、ＯＳ２９が２１個目のファイルを要求した際に、通常であれば存在しないファイルに対するアクセスはエラーとなるが、仮想ブロックデバイスドライバが該当するファイル（が含まれた）データをサーバ２からメモリ２２に取得し、ＯＳ２９にアドレスを通知することでＯＳ２９は正常にファイルアクセスが可能となる。また、データ要求部２６は、データ要求の際に、待受タイマー設定部２７に待受タイマー２３にデータ受信待機時間（終了時間）を設定するように指示し、待受タイマー設定部２７は待受タイマー２３に予め定められたデータ受信待機時間を設定する。データ受信待機時間は、サーバ２がデータ送信開始時間経過後にデータをマルチキャスト配信する時にデータを受信できるように、予め定められる。また、待受タイマー設定部２７は、受信管理部２８にマルチキャスト配信されるデータを受信できるように、メモリ２２にデータを書き込むキャッシュ領域を確保するように指示すると共に、データ受信待機状態中は、データ要求部２６からサーバ２にデータ要求が行なわれるのを一時的に中止させる。また、待受タイマー設定部２７は、サーバ２からネットワークインターフェース２４を介してデータ受信待機時間（終了時間）の延長指示を受けた場合は、データ受信待機時間を延長するように再設定する。また、待受タイマー設定部２７は、受信待機時間が終了するまで、受信管理部２８にマルチキャスト配信されるデータを受信できるように、メモリ２２にデータを書き込むキャッシュ領域を確保するように指示すると共に、データ受信待機状態中は、データ要求部２６からサーバ２にデータ要求が行なわれるのを一時的に中止させる。
【００３９】
サーバ２からデータがマルチキャスト配信が開始され、受信管理部２８は、受信待機状態を受信待機時間中継続し、サーバ２からネットワークインターフェース２４を介してマルチキャスト配信されたデータを識別して受信し、メモリ２２のキャッシュ領域に配信されたデータを書き込む。待受タイマー設定部２７がサーバ２から受信待機時間の設定指示を受けるとデータ受信待機時間の終了時間を設定する。終了時間は配信すべき全てのデータを配信した後に終了するように設定される。なお、全ては目標であり、多少の漏れがあっても良い。サーバ２からデータ受信待機時間の解除指示があると又は待受タイマー２３がタイムアウトすると、データ受信待機時間が終了し、待受タイマー２３はリセットされ、待受タイマー設定部２７を介して受信管理部２８にタイムアウト信号が送信される。受信管理部２８はタイムアウト信号を受信すると受信待機状態を解除する。メモリ２２のキャッシュ領域に書き込まれたデータは状況に応じて適時、外部記憶装置２０のキャッシュ領域に移される。外部記憶装置２０に移された場合には次回以降の電源投入時の特定のアプリケーションシステムの起動に利用可能である。サーバから特定のアプリケーションシステムデータを取得したクライアント５−１はブートを行い、特定のＡＰの利用が可能となる。なお、ブートには必ずしも全てのＡＰデータが必要ではなく、ブートに関連するＯＳ及びＡＰのブートに関連するプログラムが取得された段階で、ブートを行なうことが可能であり、その他のＡＰ用プログラム及びデータはその後にデータ要求されても良い。
【００４０】
［処理フロー］
図５にサーバの処理フロー例を示す。データ要求管理部１６はクライアントからのデータ要求を監視する（Ｓ１０１）。システム内の１つのクライアントからのデータ要求が検出されるまで待ち、データ要求が検出されると（Ｓ１０２でＹＥＳ）、配信タイマー設定部１７でデータ送信開始時間を設定する（Ｓ１０３）。また、配信タイマー設定部１７はクライアント５−１〜５−ｍ（１つのクライアントを除く）に受信待機時間（終了時間）を設定するように指示する（Ｓ１０４）。その後、他のクライアントからのデータ要求が検出された場合には、配信タイマー設定部１７でデータ送信開始時間を延長して再設定し、配信タイマー設定部１７はクライアント５−１〜５−ｍ（他のクライアントを除く）に受信待機時間を延長して再設定するように（すなわち、受信待機時間を継続するように）指示する。データ送信開始時間が再設定された場合は最後に再設定されたデータ送信開始時間が経過した時に、再設定されなかった場合は最初に設定されたデータ送信開始時間が経過した時に、データ要求されたデータ及び関連データを、複数のクライアントにマルチキャスト配信することとなる。ここで、最後に再設定されたデータ送信開始時間とは、再設定が複数回行なわれた場合に最後に再設定されたデータ送信開始時間をいう。再設定が１回だけ行なわれた場合には、当該再設定が最後の再設定に該当する。再設定されなかった場合には、データ送信開始時間は当然、最初に設定されたデータ送信開始時間となる。このように、図示しないがデータ要求の監視（Ｓ１０１）〜受信待機の継続指示（Ｓ１０４）が繰り返される。配信タイマー設定部１７は、クライアント５−１〜５−ｍに受信待機状態を継続させながら（Ｓ１０４）データ送信開始時間まで待ち、データ送信開始時間がタイムアウトすると（Ｓ１０５でＹＥＳ）、マルチキャスト配信を開始する。また、タイムアウトすると、サーバ２はクライアント５−１〜５−ｍにマルチキャスト配信が終了した後に受信待機時間が終了するように受信待機時間（終了時間）を設定するように指示する（Ｓ１０６）。配信管理部１８は、要求されたデータ及び関連するデータを、メモリ１２の配信待ちデータキュー表１９−１に登録しておき（Ｓ１０７）、データ送信開始時間がタイムアウトすると、要求されたデータ及び関連するデータを配信待ちデータキュー表１９−１から読み出し（Ｓ１０８）、クライアント５−１〜５−ｍにマルチキャスト配信する（Ｓ１０９）。マルチキャスト配信が終了した後に、サーバ２はクライアント５−１〜５−ｍに受信待機時間を解除するように指示し、クライアント５−１〜５−ｍは受信待機時間の解除指示を受信すると、直ちに受信待機状態を終了する。また、受信待機時間の解除指示がクライアント５−１〜５−ｍに受信されない場合には、受信待機時間（終了時間）を設定した待受タイマー２３のタイムアウトにより受信待機状態を終了する。
【００４１】
図６〜図８にクライアントの処理フロー例を示す。クライアントでは以下の３つの処理、図６〜図８の処理が並行に行なわれる。図６はデータ要求に係る処理フロー例である。電源オン時には、ＰＸＥを用いてＢＩＯＳとネットワークインターフェースによりサーバ２から最小構成のＯＳ（カーネル及びミニルート等）がメモリ２２のＯＳ領域に読み込まれる。その後、最小構成のＯＳはデータ要求部２６を設定し、ＯＳ２９がデータ要求部２６に順次ＯＳ及びＡＰデータ（ＡＰ用プログラム及びデータ）のデータ要求を指示する。まず、ＯＳのうち起動に必要な部分が順次データ要求されて取得され、その後ＡＰデータが順次データ要求されて取得される。データ要求部２６はＯＳ２９からデータ読み込み要求を受ける（Ｓ２０１）。データ要求部２６は、外部記憶装置２０又はメモリ２２のキャシュ領域からのデータの読み込みが可能であれば、すなわち、既にデータを保有していれば（Ｓ２０２でＹＥＳ）、その旨及びデータのアドレスをＯＳ２９に通知し（Ｓ２０３）、次のデータ読み込み要求を受ける（Ｓ２０１）。キャシュ領域からのデータの読み込みが可能でなければ、すなわち、未だデータを保有していなければ（Ｓ２０２でＮＯ）、サーバ２にデータ要求を行なう（Ｓ２０４）。その後、受信管理部２８はサーバからマルチキャスト配信されるデータを待ち、データが配信された時に受信し（図８のＳ２２１）、その旨及び受信したデータのアドレスをＯＳ２９に通知する（Ｓ２０５）。その後、次のデータについて、データ要求部２６はＯＳ２９からデータ読み込み要求を受ける（Ｓ２０１）。
【００４２】
図７はデータ受信待機に係る処理フロー例である。待受タイマー設定部２７は待受タイマー２３のデータ受信待機時間（終了時間）を設定し、受信管理部２８にマルチキャスト配信されるデータを受信できるように、メモリ２２にデータを書き込むキャッシュ領域を確保するように指示すると共に、データ受信待機状態中は、データ要求部２６からサーバ２にデータ要求が行なわれるのを一時的に中止させる。そして、サーバ２からの待機解除指示又は待受タイマー２３のタイムアウトを待つ（Ｓ２１１）。サーバ２からの待機継続指示（延長指示）がなければ（Ｓ２１２でＮＯ）、そのまま待ち、待機継続指示（延長指示）があれば（Ｓ２１２でＹＥＳ）、データ受信待機時間（終了時間）を延長するように再設定する（Ｓ２１３）。その後、サーバ２からの待機解除指示がなければ（Ｓ２１４でＮＯ）、そのまま待ち、待機解除指示があれば（Ｓ２１４でＹＥＳ）、データ受信待機時間をすぐに解除する（Ｓ２１５）。また、データ受信待機時間は終了時間に係る待受タイマー２３のタイムアウトによってサーバからの終了指示が受信されなくても解除される。図８はデータ受信に係る処理フロー例である。受信管理部２８はサーバ２からマルチキャスト配信されるデータを待ち、データが配信された時に受信する（Ｓ２２１）。受信管理部２８は受信したデータをメモリ２２のキャッシュ領域に書き込む（Ｓ２２２）。その後、次のマルチキャスト配信されるデータを待つ（Ｓ２２１）。
【００４３】
図９にサーバとクライアント間の情報通信シーケンス例を示す。それぞれの処理フローについては図５〜図８を参照されたい。サーバ２を中心に、クライアント５−１を左側に、クライアント５−２を右側に示す。縦軸は時間を示す。クライアント５−１からサーバ２にデータＤ１−１をデータ要求する（Ｓ２０４）と共に、待受タイマー２３にデータ受信待機時間を設定し（Ｓ２１１）、データ受信待機状態で待機する（Ｓ２１３）。サーバ２は、データ要求を受信すると（Ｓ１０２）、配信タイマー１３にデータ送信開始時間を設定する（Ｓ１０３）。次に、クライアント５−２からサーバ２にデータＤ１−１をデータ要求がされると（Ｓ２０４）、クライアント５−２は待受タイマー２３にデータ受信待機時間を設定し（Ｓ２１１）、データ受信待機状態で待機する（Ｓ２１３）。サーバ２は、データ要求を受信すると（Ｓ１０２）、配信タイマー１３にデータ送信開始時間を延長して再設定する（Ｓ１０３）と共に、クライアント５−１にデータ受信待機時間を延長して再設定するよう指示する（Ｓ１０４）。データ送信開始時間が経過すると（Ｓ１０５でＹＥＳ）、サーバ２はデータＤ１−１をクライアント５−１及びクライアント５−２にマルチキャスト配信し（Ｓ１０９）、クライアント５−１及びクライアント５−２はデータＤ１−１を受信する（Ｓ２２１）。サーバ２は、データＤ１−１に続けてデータＤ１−１に関連するデータＤ１−２をクライアント５−１及びクライアント５−２にマルチキャスト配信し（Ｓ１０９）、クライアント５−１及びクライアント５−２はデータＤ１−２を受信する（Ｓ２０５）。サーバ２は、さらにデータＤ１−２に続けてデータＤ１−１に関連するデータＤ−３をクライアント５−１及びクライアント５−２にマルチキャスト配信し（Ｓ１０９）、クライアント５−１及びクライアント５−２はデータＤ１−３を受信する（Ｓ２２１）。このように、１つのデータ要求によりデータ要求されたデータ及び当該データに関連してその後アクセスされる可能性のある関連データが複数のクライアントにマルチキャスト配信される。図ではクライアント数が２までを示しているが、クライアントが多数の場合にも、１つのデータ要求によりデータ要求されたデータ及び関連データが複数のクライアントにマルチキャスト配信される。
【００４４】
図１０にサーバとクライアント間の起動シーケンス例を示す。ブートサーバ２は、ＤＨＣＰサーバ、ＴＦＴＰサーバ、ＨＴＴＰサーバの機能を有する。ＨＴＴＰサーバはＴＣＰ／ＩＰプロトコルに則してネットワーク通信を行なうサーバをいい、ＤＨＣＰサーバはＴＣＰ／ＩＰネットワーク上でサーバからクライアントに起動に必要な情報を自動的に読み込ませて起動（ブート）させ、クライアントにＩＰアドレスを提供するサーバをいい、ＴＦＴＰサーバはＯＳの中核になるカーネル、例えばＬｉｎｕｘ（ＵＮＩＸ（登録商標）ライクＯＳ）カーネル、ブート起動に必要最小限のミニルート等を提供するサーバをいう。すなわち、サーバ２は、クライアント５に対してネットワークブートを行なわせる機能（ＰＸＥ）を有する。また、サーバ２は、クライアント５に対してリモート操作による電源投入を行なう機能（ＷＯＬ）を有しても良い。
【００４５】
クライアント５に電源が投入されると、クライアント５はＰＸＥによりサーバ２から最小構成のＯＳ（カーネル及びミニルート等）の取得を行なう。クライアント５は最小構成のＯＳを実行し、順次、起動に必要なＯＳの残りの部分、関連するＯＳ及び特定のアプリケーションシステムファイル（データ）をサーバ２に対して要求する。サーバ２はクライアント５からのデータ要求を受けて、起動すべきクライアント５を検出する。しかし、パソコン実習室等では起動すべきクライアント数が多く、また、ファイル数も多いので、個別にデータ要求に対処していたのではサーバの稼動が膨大になり、ネットワークの負担も膨大になり、データを使用し得るクライアント（出席者）の全てを起動するのに膨大な時間を要してしまう。このため、サーバ２は、特定の複数のクライアント５に対して同時に同一データを送信するマルチキャスト配信機能を有することとし、また、一度の要求により、要求データだけでなく、その後に必要となる関連データを含めてマルチキャスト配信し、クライアント５に供給する。データを使用し得る全てのクライアント（出席者）が受信可能な待機状態時にデータをマルチキャスト配信できるように、サーバ２は、システムのいずれかのクライアント５からのデータ要求があると、配信タイマー１３にデータ送信開始時間（終了時間）を設定し、クライアント５は待受タイマー２３にデータ受信待機時間を設定して、同期をとり、一斉に配信を行なう。クライアント５はマルチキャスト配信されるデータを受信できるように待機する。なお、他のクライアンントからのデータ要求があった時は、データ受信の確実のため、サーバ２はデータ送信開始時間を延長して再設定し、クライアント５はデータ受信待機時間を延長して再設定して、マルチキャスト配信が行なわれる。クライアント５はこれらのデータを受信することで、システムを起動（ブート）し、特定アプリケーションシステムに係るをＯＳ及びＡＰデータの利用が可能になる。なお、ブートには必ずしも全てのＡＰデータが必要ではなく、ブートに関連するＯＳ及びＡＰのブートに関連するプログラムが取得された段階で、ブートを行なうことが可能であり、その他のＡＰ用プログラム及びデータはその後にデータ要求されても良い。
【００４６】
特定アプリケーションシステムのブート（特定のアプリケーションシステムに係るブート情報配信完了後、特定のアプリケーションシステムをデスクトップ画面に表示し、操作可能にするためのブート）については、サーバ２が複数のクライアント５にブート開始指示を送信し、クライアント５はサーバ２からのブート開始指示を受信した時にブートを開始するようにすると、複数のクライアントについてブートの条件が整った時に一斉にブートを行なうことができ、ブートを確実化できる。また、クライアント５が、特定のアプリケーションシステムに係るブート情報配信完了後さらに一定時間経過後にブートを開始するようにすると、サーバからのブート開始指示がなくても、一定時間マージンをとってブートを行なうので、ブートを確実化できる。
【００４７】
図１１は本実施例による起動時間を従来と比較した図である。横軸にクライアントの同時起動台数を、縦軸に全クライアント起動完了時間（ｓｅｃ）を示す。黒菱形◆は本実施例におけるマルチキャスト配信方式による実測データであり、黒正方形■は従来の個別要求・応答方式による実測データである。個別要求・応答方式では台数の増加に対し起動完了時間がリニアに増加するのに対して、マルチキャスト配信方式では台数が増加しても４０台まで、１台を起動するのとほぼ同じ時間で済む。このように４０台の台数ではマルチキャスト配信方式と個別要求・応答方式では起動完了時間に４倍の差が生じており、台数がさらに大きくなると、その差はさらに増大すると見込まれるので、台数が多くなるほどマルチキャスト配信方式による起動完了時間短縮の効果は大である。
【００４８】
本実施例によれば、クライアント数及びファイルサイズが共に大きい場合又はアクセスされるファイル数が多数の場合でも、一度のデータ要求により、関連データを含めて配信でき、これによりサーバ及びネットワークの負荷を軽減できるサーバクライアントシステムを提供できる。
【実施例２】
【００４９】
実施例１では、全てのクライアントに同じデータをマルチキャスト配信する例を説明したが、本実施例では、クライアントをデータセットが異なる複数のグループに分類して配信を行なう例を説明する。複数のグループとして、例えばＡ教室とＢ教室で別の授業が行なわれている場合が挙げられる。この場合、利用するＡＰプログラムやデータが異なる可能性がある。このため、クライアントをＡ教室とＢ教室にグループ分けしておくことにより、ＡＰプログラムやデータを共通用、Ａ教室用、Ｂ教室用に分けて配信可能である。すなわち、クライアント５−１〜５−ｎをデータセットが異なる複数のグループに分類し、サーバは各グループのクライアントに対して、全グループが使用し得る共通データを複数のクライアントに一括してマルチキャスト配信し、各グループが使用し得る個別データをグループ別にマルチキャスト配信する。どのグループに属するかはサーバが管理する。
【００５０】
図１２に本実施例におけるサーバとクライアント間の情報通信シーケンス例を示す。サーバ２を最も左側に、そして、第１グループに属するクライアント５−１，５−２、第２グループに属するクライアント５−３を順次左側から右側に示す。縦軸は時間を示す。クライアント５−１からサーバ２にデータＤ１−１をデータ要求する（Ｓ２０４）と共に、待受タイマー２３にデータ受信待機時間を設定し（Ｓ２１１）、データ受信待機状態で待機する（Ｓ２１３）。サーバ２は、データ要求を受信すると（Ｓ１０２）、配信タイマー１３にデータ送信開始時間を設定する（Ｓ１０３）。次に、クライアント５−２及び５−３からサーバ２にデータＤ１−１をデータ要求がされると（Ｓ２０４）、クライアント５−２及び５−３は待受タイマー２３にデータ受信待機時間を設定し（Ｓ２１１）、データ受信待機状態で待機する（Ｓ２１３）。サーバ２は、データ要求を受信すると（Ｓ１０２）、配信タイマー１３にデータ送信開始時間を延長して再設定する（Ｓ１０３）と共に、クライアント５−１にデータ受信待機時間を延長して再設定するよう指示する（Ｓ１０４）。データ送信開始時間が経過すると（Ｓ１０５でＹＥＳ）、サーバ２は共通データＤ１−１をクライアント５−１〜５−３にマルチキャスト配信し（Ｓ１０９）、クライアント５−１〜５−３はデータＤ１−１を受信する（Ｓ２２１）。サーバ２は、共通データＤ１−１に続けてデータＤ１−１に関連する共通データＤ１−２，Ｄ１−３をクライアント５−１〜５−３にマルチキャスト配信し（Ｓ１０９）、クライアント５−１〜５−３は共通データＤ１−２，Ｄ−３を受信する（Ｓ２２１）。共通データＤ１−１及び関連する共通データＤ１−２，Ｄ１−３のマルチキャスト配信が終了すると、クライアント５−１〜５−３はデータ受信待機状態を解除する（Ｓ２１５）。
【００５１】
その後、第１グループに属するクライアント５−１，５−２がデータＤ２−１をデータ要求し、サーバ２はデータ送信開始時間を設定し（Ｓ１０３）、クライアント５−１，５−２はデータ受信待機状態で待機する（Ｓ２１３）。サーバ２は個別データＤ２−１及びＤ２−１に関連する個別データＤ２−２を第１グループに属するクライアント５−１，５−２にマルチキャスト配信し（Ｓ１０９）、クライアント５−１，５−２はデータＤ２−１，Ｄ２−２を受信する（Ｓ２２１）。個別データＤ２−１及び関連する個別データＤ２−２のマルチキャスト配信が終了すると、クライアント５−１，５−２はデータ受信待機状態を解除する（Ｓ２１５）。なお、２つのクライアントからのデータ要求後にデータ送信開始時間を設定する例を説明したが、クライアントからのデータ要求毎に、データ送信開始時間を延長して、マルチキャスト配信しても良い。さらに、個別データでもデータ要求がされることが確実なデータがある場合には、共通データ配信後にデータ受信待機時間の解除をせずに、受信待機時間を継続すれば、第１グループに属する１つのクライアントからのデータ要求を受信した時点で、データ送信開始時間の設定とデータ受信待機時間の継続設定を行ない、ことさら、データ送信開始時間の延長をしなくても良い。次に、第２グループに属するクライアント５−３がデータＤ３−１をデータ要求し、サーバ２はデータ送信開始時間を設定し（Ｓ１０３）、クライアント５−３はデータ受信待機状態で待機する（Ｓ２１３）。サーバ２は個別データＤ３−１及びＤ３−１に関連する個別データＤ３−２を第２グループに属するクライアント５−３にマルチキャスト配信し（Ｓ１０９）、クライアント５−３はデータＤ３−１，Ｄ３−２を受信する（Ｓ２２１）。個別データＤ３−１及び関連する個別データＤ３−２のマルチキャスト配信が終了すると、クライアント５−３はデータ受信待機状態を解除する（Ｓ２１５）。なお、クライアントからのデータ要求毎に、データ送信開始時間を延長して、マルチキャスト配信しても良い。さらに、個別データでもデータ要求がされることが確実なデータがある場合には、共通データ配信後にデータ受信待機時間の解除をせずに、受信待機時間を継続すれば、第２グループに属する１つのクライアントからのデータ要求を受信した時点で、データ送信開始時間の設定とデータ受信待機時間の継続設定を行ない、ことさら、データ送信開始時間の延長をしなくても良い。
【００５２】
このように、サーバ２は、全グループが使用し得る共通データを複数のクライアントに一括してマルチキャスト配信し、各グループが使用し得る個別データをグループ別にマルチキャスト配信する。このように、各グループにデータセットが異なるデータが配信される。これにより、共通データについては、一度のデータ要求により、関連データを含めてデータを一括してマルチキャスト配信でき、サーバ及びネットワークの負荷を軽減できる。また、個別データについても、グループ毎に関連データを含めてまとめてマルチキャスト配信でき、サーバ及びネットワークの負荷を軽減できる。また、ＬＡＮ上の同一セグメントに存在する複数のグループに対して同じデータを配信したり、グループ毎に特定のデータを配信することが可能になる。また、グループ分けにより、必要でないデータを受け取らずにすむ。
【００５３】
以上、本発明の実施の形態について説明したが、本発明は上記の実施例に限定されるものではなく、本発明の趣旨を逸脱しない範囲で実施例に種々変更を加えられることは明白である。
【００５４】
例えば、以上の実施例では、パソコン実習室の例を説明したが、パソコンを利用した通信教育、講義、ゼミナール、講演、会議にも本発明を利用可能である。また、実施例１ではクライアントが１つの実習室に設置される例を説明したが、例えば東京と大阪の実習室等に分かれて設置されても良い。実施例２では複数の教室での授業や演習について、教室別にグループ分けして利用する例を説明したが、１つの実習室内での演習でグループ分けしても良い。また、システムに属するクライアントのうち出席者のクライアントを立ち上げる例を説明したが、遅刻する学生も参加できるように、全てのクライアントを立ち上げても良く、参加予定者数のクライアントを立ち上げても良く、故障等の事故に対処するために参加予定者数に余裕数を加えたクライアントを立ち上げても良い。また、以上の実施例では、ＯＳを配信した後にＡＰデータを配信する例を説明したが、一部のＡＰデータを一部のＯＳの前に配信しても良い。また、以上の実施例では、ＯＳがサーバにより内部に取り込まれたデータ要求を行なう例を説明したが、サーバから各クライアントに、プロファイル管理表の当該クライアントに関連する部分を配信しておき、データ要求に対して、ＯＳが参照して、データ要求できるようにしても良い。その他、クライアントの台数、データ送信開始時間、データ受信待機時間等も適宜変更可能である。また、本発明はサーバクライアントシステムやそれを構成するサーバやクライアントの発明としてだけでなく、実施の形態に記載のデータ配信方法の発明として、また、当該データ配信方法をコンピュータに実行させるためのプログラムの発明としても実現可能である。
【産業上の利用可能性】
【００５５】
本発明は、教育・講演・会議用等のサーバクライアントシステムに利用できる。
【符号の説明】
【００５６】
１    サーバクライアントシステム
２    サーバ
３    データ
４    データベース（外部記憶装置）
５，５−１〜５−ｎ  クライアント
６    ネットワーク（ＬＡＮ）
７    スイッチ
１１  ＣＰＵ
１２  メモリ
１３  配信タイマー
１４  ネットワークインターフェース
１５  バス
１６  データ要求管理部
１７  配信タイマー設定部
１８  配信管理部
１９Ａ  配信待ちデータキュー表
１９Ｂ  プロファイル管理表
２０  データベース（外部記憶装置）
２１  ＣＰＵ
２２  メモリ
２３  待受タイマー
２４  ネットワークインターフェース
２５  バス
２６  データ要求部
２７  待受タイマー設定部
２８  受信管理部
２９  ＯＳ
５１Ａ，５１Ｂ  サーバクライアントシステム
５２，５２−１，５２−２  ブートサーバ
５３，５３−１〜５３−３  データ
５４  データベース
５５，５５−１〜５５−４  クライアント
５６，５６−１，５６−２  ネットワーク（ＬＡＮ）
５７  スイッチ
Ｄ１−１〜Ｄ１−ｎ，Ｄ２−１〜Ｄ２−ｎ，Ｄ３−１〜Ｄ３−２  データ
【図１】
2010200206.tif 000003
【図２】
2010200206.tif 000004
【図３】
2010200206.tif 000005
【図４】
2010200206.tif 000006
【図５】
2010200206.tif 000007
【図６】
2010200206.tif 000008
【図７】
2010200206.tif 000009
【図８】
2010200206.tif 000010
【図９】
2010200206.tif 000011
【図１１】
2010200206.tif 000012
【図１２】
2010200206.tif 000013
【図１３】
2010200206.tif 000014
【図１４】
2010200206.tif 000015
【図１５】
2010200206.tif 000016
【図１０】
2010200206.tif 000017