# HG changeset patch # User kazz # Date 1328465993 -32400 # Node ID 0b01b77d33b4d9a4904aedf06fe8d1eae2419e3c # Parent 70f19a2daea60e4468fe9b5d2672fa9c1f1fadc9 write about Federated Linda diff -r 70f19a2daea6 -r 0b01b77d33b4 paper/chapter1.tex --- a/paper/chapter1.tex Mon Feb 06 02:10:30 2012 +0900 +++ b/paper/chapter1.tex Mon Feb 06 03:19:53 2012 +0900 @@ -133,7 +133,7 @@ \end{figure} \subsection{update API の追加} -Federated Linda の例題を書いているときに、 "in" の直後に "out" を実行することが多いことに気がついた。これは即ち、タプルを消して、新しいタプルを書き込むということである。そこで、新しく "update" API を追加することにした。(表\ref{fig:tb:additionalLindaApi}) +Federated Linda の例題を書いているときに、 "in" の直後に "out" を実行することが多いことに気がついた。これは即ち、タプルを消して、新しいタプルを書き込むということである。そこで、新しく "update" API を追加することにした。(表\ref{tb:additionalLindaApi}) \begin{table}[htbp] \caption{追加 Linda API} @@ -207,5 +207,13 @@ \end{figure} \subsection{接続しているタプルスペースリソースの管理} +Federated Linda にはタプルスペースへのコネクションを管理する機構がないため、ユーザーがそれらのコネクションを管理する必要があった。 +分散アプリケーションにおいて、どのようなグラフ構造でマシンが接続されているかという情報は重要である。 +接続時に、コネクションに把握しやすい名前をつけることで、ユーザーは接続を管理しやすくなる。 +例えば、リングトポロジーの場合、1つのマシンに着目してみると、右への接続を"right"、左への接続を"left"といったキーで呼び出すことができると嬉しい。 +また、受け取ったデータがどこから来たか、受け取るときに把握できると望ましい。 +なぜならば、ルーティングを行うときに役立つからである。ツリートポロジーの場合、親から来たデータを子に伝搬するといった処理を記述することがよくある。その時に、どこからデータが来たかという情報は重要である。 +これらの問題点を踏まえて設計した、新しい分散アプリケーションフレームワークの設計を次章では示す。 +