Mercurial > hg > Papers > 2008 > fuchita-master
changeset 2:642ff24cf0bc
fig modify
author | fuchita |
---|---|
date | Tue, 12 Feb 2008 18:08:59 +0900 |
parents | e8d4b92f954f |
children | f3ef2f99653f |
files | paper/Makefile paper/abstract.tex paper/evaluation.tex paper/fig/pdf/visual01.bb paper/fig/pdf/visual01.pdf paper/introduction.tex paper/master_paper.tex paper/suggestion_of_flinda.tex |
diffstat | 8 files changed, 43 insertions(+), 100 deletions(-) [+] |
line wrap: on
line diff
--- a/paper/Makefile Tue Feb 12 17:25:42 2008 +0900 +++ b/paper/Makefile Tue Feb 12 18:08:59 2008 +0900 @@ -3,7 +3,7 @@ BIBTEX=jbibtex MENDEX=mendex DVIPS=dvips -DVIPDFM=dvipdfm +DVIPDFM=dvipdfmx MAIN_TARGET=master_paper @@ -31,14 +31,13 @@ @echo "\t second..." $(LATEX) $(MAIN_TARGET) > /dev/null -ps: final +ps: dvi @echo "========== GENERATE PostScript (PS) ==========" $(DVIPS) $(MAIN_TARGET) -pdf: final +pdf: dvi @echo "========== GENERATE PDF file ==========" # out2uni $(MAIN_TARGET) - $(LATEX) $(MAIN_TARGET) > /dev/null $(DVIPDFM) $(MAIN_TARGET) clean:
--- a/paper/abstract.tex Tue Feb 12 17:25:42 2008 +0900 +++ b/paper/abstract.tex Tue Feb 12 18:08:59 2008 +0900 @@ -3,8 +3,8 @@ 並列・分散環境におけるプログラミングは今後ますますその重要性を増していくと 考えられるが、フレームワークやデバッグ等を含めてスケーラビリティに優れた 分散プログラムを記述する事は非常に難しい。 -ここでいうスケーラビリティとは、サービスを受けるユーザー数が小規模でも大規模でも同じ様に -同等の能力を発揮できるという性能基準のことである。 +ここでいうスケーラビリティとは、サービスを受けるユーザー数が小規模から大規模に変化し +ても同じ様に同等の能力を発揮できるという性能基準のことである。 そこで本研究室では、自然にスケーラブルな分散プログラムを書くことができる プログラミングモデルとして``分散プログラミングモデル:Federated Linda''を
--- a/paper/evaluation.tex Tue Feb 12 17:25:42 2008 +0900 +++ b/paper/evaluation.tex Tue Feb 12 18:08:59 2008 +0900 @@ -75,7 +75,7 @@ \begin{figure}[htbp] \begin{center} -\includegraphics[width=14cm]{fig/pdf/visual01.pdf} +\includegraphics[width=10cm]{fig/pdf/visual01.pdf} \caption{通信量のグラフィカルな表示ツール} \label{visual01} \end{center}
--- a/paper/fig/pdf/visual01.bb Tue Feb 12 17:25:42 2008 +0900 +++ b/paper/fig/pdf/visual01.bb Tue Feb 12 18:08:59 2008 +0900 @@ -1,5 +1,5 @@ %%Title: ./visual01.pdf %%Creator: ebb Version 0.5.2 -%%BoundingBox: 0 0 525 364 -%%CreationDate: Fri Feb 8 15:10:39 2008 +%%BoundingBox: 0 0 664 434 +%%CreationDate: Tue Feb 12 18:37:28 2008
--- a/paper/introduction.tex Tue Feb 12 17:25:42 2008 +0900 +++ b/paper/introduction.tex Tue Feb 12 18:08:59 2008 +0900 @@ -36,13 +36,15 @@ を提供することである。 本論文では、本研究室で開発した分散プログラミングモデル Federated Linda を用いた -分散アルゴリズムの記述事例について紹介し、その開発によって得られた知見から本モデル -に必要となる機能としてJava言語によるタプルサーバーとLinda APIの開発及び、 -分散デバッグ機能の実装と評価を行う。 +分散アルゴリズムの記述事例としてCompactRoutingというルーティングテーブルの収束速度や +ネットワークのスケーラビリティに対して優位なアルゴリズムの実装例について紹介し、 +その開発によって得られた知見から本モデルに必要な機能拡張を提案する。 -%第2章では分散プログラムの特徴などを示し、分散プログラミングモデルに必 -%要なものを挙げる。そして、分散プログラムを構成する3つの重要な要素につい -%て説明する。 +本モデルへの機能拡張としてまず最初の段階で、Lindaサーバーの実装プログラミング言語を +Java言語とし、Java言語の高度な移植性やコードの再利用性を得た。 +これをもって、FederatedLindaの記述経験から必要と考える拡張機能を実装し、その評価を行う。 + + \section{論文の構成} 第2章では提案する分散プログラミングモデル Federated Linda について説明する。 @@ -53,8 +55,8 @@ を用いて紹介する。 第4章ではFederated Linda による分散アルゴリズムの実装の経験によって得られた知見を -もとにJava言語によるタプルサーバーの実装(type2からtype3への実装段階)と、 -Java言語で開発を行う事による利点について述べる。 +もとにJava言語によるタプルサーバーの実装と、 +Java言語でFederated Lindaの開発を行う事による利点について述べる。 第5章では通信量のスケーラビリティを検証するデバッグインターフェースの開発と評価を行い、 第6章でまとめと今後の課題を述べる。
--- a/paper/master_paper.tex Tue Feb 12 17:25:42 2008 +0900 +++ b/paper/master_paper.tex Tue Feb 12 18:08:59 2008 +0900 @@ -64,16 +64,7 @@ \input{evaluation.tex} %------------------------------------------------- -%%-------------------------------old------------------------------- -%分散プログラムについて -%\input{distribute_program.tex} -%Federated Linda の提案 -%\input{suggestion_of_flinda.tex} -%実装 -%\input{implementation.tex} -%Federated Lindaを用いたプログラミング -%\input{examples.tex} -%他のフレームワークとの比較 +%他のフレームワークとの比較 <<<-------- Jiniとの比較を入れる %\input{comparing.tex} %%-----------------------------------------------------------------
--- a/paper/suggestion_of_flinda.tex Tue Feb 12 17:25:42 2008 +0900 +++ b/paper/suggestion_of_flinda.tex Tue Feb 12 18:08:59 2008 +0900 @@ -1,11 +1,6 @@ \chapter{Federated Linda の提案} \section{LindaとFedarated Linda} -%分散プログラミングは比較的ネットワーク的に遠いコンピュータで -%並列的に実行されるプロセスを取り扱うプログラミングであり、実際に書くことも習得することも難しい。 -%また、単純に通信するだけでは、一ヶ所に通信が集中してしまうことが起きやすい。 - -%それに対して我々は、自然に分散プログラミングが書けるようなプログラミングモデル 本研究室では、自然に分散プログラミングが書けるようなプログラミングモデル として大域 ID を持たない連邦型タプルスペース[2][3](以下Federated Lindaと記す) を提案してきた。 @@ -53,7 +48,7 @@ トのパケット転送のように、タプルスペースからタプルスペースへとタプルを転 送していく。 -クライアントのアクセス数が増えても、タプルスペース等の数を増やし、処理を +クライアントのアクセス数が増えても、タプルスペース等の数を増やし、ネットワーク処理を 分散することにより、スケーラビリティを保つ。 \begin{figure}[htc] @@ -89,24 +84,6 @@ し、各ノードがそれにしたがって論理ネットワークを構築する。論理ネットワー クを構築するために、接続などを扱うモジュールを提供する。 -%\section{Federate} - -%Federate とは「連合の、連邦型」という意味がある。これは、タプルスペース -%を介して複数のプロトコルが緩く接続することにより、異なるシステム間のデー -%タのやり取りが可能となり、連合型の分散システムを構築することを表している -%(図\ref{Federate}参照)。この連合型の分散システムにより、より自由度の高い -%システムを構築することが期待できる。例えば、ルーティングプロトコルで指定 -%した先でブロードキャストを行う、などのようなことができるようになる。 - -%\begin{figure}[hc] -%\begin{center} -%\includegraphics[width=12cm]{fig/Federate.eps} -%\end{center} -%\caption{連邦型の分散システム} -%\label{Federate} -%\end{figure} - - \section{実装の段階分け} Federated Linda の実装には次の3つの段階がある。 @@ -190,25 +167,27 @@ Linda と Protocol Engine の接続は、ネットワークで接続される。type 2 では、 それらは手動で設定される。これらの設定の自動化は、やはりtype 3 で行われ -る。Federated Lindaは複雑なネットワーク状での接続を想定しており、クリアすべき -接続のトポロジーは例えば図\ref{fig:Tree}, 図\ref{fig:mesh} のような -TreeやMeshが考えられる。 +る。 + +%Federated Lindaは複雑なネットワーク状での接続を想定しており、クリアすべき +%接続のトポロジーは例えば図\ref{fig:Tree}, 図\ref{fig:mesh} のような +%TreeやMeshが考えられる。 -\begin{figure}[htbp] -\begin{center} -\includegraphics[width=10cm]{fig/tree.pdf} -\caption{Tree型トポロジ} -\label{fig:Tree} -\end{center} -\end{figure} +%\begin{figure}[htbp] +%\begin{center} +%\includegraphics[width=10cm]{fig/tree.pdf} +%\caption{Tree型トポロジ} +%\label{fig:Tree} +%\end{center} +%\end{figure} -\begin{figure}[htbp] -\begin{center} -\includegraphics[width=10cm]{fig/mesh.pdf} -\caption{Mesh型トポロジ} -\label{fig:mesh} -\end{center} -\end{figure} +%\begin{figure}[htbp] +%\begin{center} +%\includegraphics[width=10cm]{fig/mesh.pdf} +%\caption{Mesh型トポロジ} +%\label{fig:mesh} +%\end{center} +%\end{figure} \newpage @@ -236,9 +215,6 @@ 実装されている。タプルスペースには1から65535までのIDが割り当てられており、 タプルは指定されたIDへのキューへ格納される。 -%% タプルの図は入れる? - -%% in/rd の非同期の説明 非同期型 Linda Server の特徴として、タプルを要求するコマンド (in, read, wait\_read) などを実行する際のコマンド実行の保留が挙げられる。クライアン トからタプルを要求するコマンドを受け取ると、Linda Server は指定されたID @@ -260,7 +236,7 @@ プログラムは {\tt ldserv} という名前で提供されている。 起動方法は以下の通りである。``-p''オプションでポート番号を指定している。 -%% ldserv の起動方法など +% ldserv の起動方法 \begin{verbatim} $ ldserv -p 10000 \end{verbatim} @@ -290,7 +266,7 @@ C言語で提供している主な関数群は以下の通りである。 -%% CのAPIの説明 +% CのAPIの説明 \begin{itemize} \item {\tt open\_linda(hostname,port)}\\ Linda Server へ接続する。引数としてホスト名({\tt hostname})とポート番号 @@ -338,23 +314,20 @@ はユニークな番号を返す。この番号は {\tt psx\_reply} の引数として使用し、どの {\tt psx\_in, psx\_rd}の返答を取り出すかを指定するためのものである。通信は {\tt psx\_sync\_n}でのみ発生する。 -%まず open\_linda を用いて Linda Server へ接続する。この時返る値が Linda -% ^^^^^ こういうのは {\tt } とか \verb+...+ みたいなのを使って -% type writer font にする これらのAPIを用いた通信はポーリング型の形を取る。具体的なポーリングベー スのプログラミング例は Local Access の説明で述べる。 \subsubsection{Perl, Python, Ruby の API} -%% Perl, Python, Ruby で提供したクラスなどの説明 +% Perl, Python, Ruby で提供したクラスなどの説明 Perl, Python, Ruby は C の API を拡張して実装している。提供しているモジュー ルは{\tt FederatedLinda, Linda, Reply}というクラスで構成されている(図 \ref{LWLClass}参照)。各スクリプト言語で同じ名前を用いて実装している。 -%% FederatedLinda クラスや Reply クラスを、図を入れて説明 +% FederatedLinda クラスや Reply クラスを、図を入れて説明 \begin{figure}[htbp] \begin{center} @@ -364,10 +337,6 @@ \end{center} \end{figure} -%% 各クラスの説明。 -%% FederatedLinda.open() で Linda インスタンス生成、 -%% Linda.in(), Linda.rd() で Reply インスタンスが返るとか -%% FederatedLinda.sync() で通信 \newpage \begin{itemize} @@ -412,14 +381,8 @@ {\tt in, read}などのタプルを受け取るコマンドは、{\tt Reply}インスタンスを返す。Linda Serverからのタプルを取り出したいときは、{\tt Reply}の{\tt reply}メソッドを用いる。 -%% 次の「Federated Linda を用いたプログラミング」に入れてもいいかも? \subsection{Local Access to Protocol} -%% Client プログラムでの Linda API の使いかた -%% Protocol Engine の使い分け方(タプルIDの切り替え) -%% 非同期な Linda API の有効的な使いかた。?? -%% ポーリング型のプログラミングを強調 - ``Local Access''はプロトコルへアクセスするAPIである。APIの内容は先に説明 したので、ここではクライアントプログラムにおける Linda API を用いたプロ グラミングについて説明する。まず最初に、Linda API を使ったクライアントの @@ -515,12 +478,6 @@ を用いたプログラムを記述しやすい。 \subsection{Protocol Engine} - -%% プロトコルエンジンの書きかた -%% Replyを受け取ってから、再び同じタプルIDにin/rdするとか -%% プログラミングのパターンなどをソース(擬似?)を入れて説明 -%% 複数のタプルスペースへのアクセスをどう制御するか?とか - type 2 では Protocol Engine は Linda API を用いて実装する。よって実装の スタイル自体は Local Access to Protocol にて説明した通りである。そしてそ の API を用いて分散アルゴリズムを実装する。分散アルゴリズムは多種多様あ @@ -587,10 +544,6 @@ \subsection{Link Configuration} -%% タプルスペースとの接続について -%% コネクションをどう管理するか。 -%% トポロジ生成について。XMLによる生成。Graffle - Linda Server 間は Protocol Engine で接続される。その接続の形を規定するの が Link Configuration である。Link Configuration ではタプルスペース間を どのように接続するかを XML で記述しており、それを基にネットワークを構築 @@ -729,5 +682,3 @@ プログラムに任せる。また、{\tt LinkConfiguration} インスタンスを複数持つことに より、一つの Protocol Engine で別々のトポロジに参加することも可能である。 -%% 足りない部分(動的に接続を管理)にも触れる >> できれば作りたい -