コア・クライアント: データ構造
Last modified 8:26 AM UTC, November 26 2004
コア・クライアント: データ構造 |
Last modified 8:26 AM UTC, November 26 2004 |
コア・クライアントの中心となるデータ構造は以下のとおりです。
PROJECT (プロジェクト) APP (アプリケーション) FILE_INFO (ファイル) APP_VERSION(アプリケーションの版) FILE_REF (ファイル参照) WORKUNIT (ワークユニット) RESULT (リザルト)これらはそれぞれ、 データと計算の抽象化 で述べた同じ名前のものに対応しています。 これらには、サーバ側には存在しないフィールドもいくつか含まれています。 たとえば、FILE_INFO には、そのファイルがこのホストに有るか否かを 示すフィールドを［追加で］もっています。
これらの個々のクラスには、 write(書き出し) とparse(解析) の機能があって、個々のインスタンスを XML表現との間で、双方向に変換できます。 いくつかのクラスでは、XMLの格納場所がスケジューリング・サーバで あるのか、あるいは、ローカルなファイル client_state.xml であるのかによって、これらの機能に別々の変種が用意されていることも あります。
これらの構造は、ポインタで結ばれています。 たとえば、 APP_VERSION は、対応する APPへのポインタを持っています。
PREFSこのクラスは prefs.xml ファイルを構文解析した結果です。 ですから、ホスト固有の情報は含んでいません。 含んでいるのは、ところどころ情報が埋められた PROJECT オブジェクト と、構文解析済みのuser preferences(参加者ごとの好みの設定)とです。
CLIENT_STATEこれは、このホストでのBOINCの大域変数(global variables)を カプセル化したものです。 これは、client_state.xml ファイルを構文解析した結果であり、 基本型へのベクターとして表現されています。 さらに、有限状態機械の一群のような一時変数も含んでいます。
コア・クライアントを起動する(CLIENT_STATE::init())と、 prefs ファイルを読み込んで解析し、PREFS オブジェクトを作成します。 (prefs ファイルがなければ、参加者にプロジェクトとアカウント・キーを 尋ね、prefs ファイルを作成します)。 そのあと、PROJECT オブジェクトのベクターを、CLIENT_STATE にコピー します。
その次に、client_state.xml ファイルを解析します。 このファイルにあるプロジェクトでも、prefs.xml に無いものは無視されます。 他のオブジェクトにリンクするオブジェクトを解析するに従って、 参照を受けるもの(XMLの中で名前で識別されます)を探して、 ポインターを埋めこんでいきます。
同様のアプローチが、スケジューリング・サーバRPCからの応答 を処理するとき(CLIENT_STATE::handle_scheduler_reply)にも 使われます。 このRPCが返却するものは、SCHEDULER_REPLY オブジェクトの中に表現された、 相互につながった基本オブジェクトです。 これらの基本オブジェクトのそれぞれについて、 CLIENT_STATE の構造内に対応するものがすでにあるかどうかを 調べます(例えば、lookup_app()を使って)。 もしなければ、 新しくオブジェクトを作って挿入し、すでに CLIENT_STATE の中に作られているオブジェクトと リンクします (例えば、link_app()を使う)。