changeset 27:73dc202884d3

add compare
author Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
date Mon, 09 May 2016 21:14:42 +0900
parents fae570922aaf
children 49b9beb53b4a
files paper/sigos.tex
diffstat 1 files changed, 73 insertions(+), 19 deletions(-) [+]
line wrap: on
line diff
--- a/paper/sigos.tex	Sun May 08 19:35:01 2016 +0900
+++ b/paper/sigos.tex	Mon May 09 21:14:42 2016 +0900
@@ -33,9 +33,9 @@
 \begin{document}
 
 % 和文表題
-\title{分散システム向けのTopology Managerの設計}
+\title{分散システム向けのTopology Managerの改良}
 % 英文表題
-\etitle{Design of Topology Manager for distributed system}
+\etitle{Improvement of Topology Manager for distributed system}
 
 % 所属ラベルの定義
 \affilabel{1}{琉球大学工学部情報工学科\\Information Engineering, University of the Ryukyus.}
@@ -86,20 +86,30 @@
 そして分散環境の構築に必要な処理をMeta Computationとして提供する。
 プログラマはコアな仕様の変更を抑えつつプログラムの挙動変更ができるため、信頼性の高い分散アプリケーションの記述が可能となる。
 
-ToDo:Topologymanagerが必要な理由
-    分散アプリケーションは複数のノードを管理しないといけない。
-  1.分散アプリを見つける
-    2.ノードをトポロジーに接続する(物理ネットワークとの対応:NATの対応)
-    3.故障など問題発生時の再構成
-    4.複数アプリのセパレーション・インタラクション
-    LAN内を構成するTopMとWANをGTopMが対応することで解決
-    直接の応用がTreeVNC(いままではこう)。
-    いままではTopMだけだったがGTopMを追加する
-Meta ComputationのひとつであるTopologyManagerは、アプリケーション外部からトポロジーの構成・管理をサポートする。
-本研究では、分散アプリケーションにおける課題であるNAT越えの機能をTopologyManagerで実現するための設計を行う。
+分散アプリケーションでは複数のノードを管理する必要がある。
+接続する分散アプリケーションを見つけ、それらを接続し合ってトポロジーを構成する。
+その際にはNATなどネットワークの問題を考慮しなければならない。
+そして、ノードの障害発生時にはトポロジーの再構成などの対応を用意しなければならない。
+また、別々の分散アプリケーション同士を接続・連携させる拡張をしたい場合もある。
+このように分散アプリケーションにおいてノードのトポロジー管理は重要である。
+しかし、プログラマがそれを全て記述するのは困難である。
 
+AliceのMeta ComputationのひとつであるTopology Managerは、アプリケーション外部からトポロジーの構成・管理をサポートする。
+本研究では、分散アプリケーションにおける課題であるNAT越えなどの機能をTopologyManagerで実現するための設計を行う。
 同時にAliceVNCやAliceChatといったAlice上でのアプリケーションを連携するための設計を行うことで、
 相互干渉なく容易にアプリケーションの接続・拡張ができる環境の提供を目指す。
+今までは1つの分散アプリケーションに対して1つのTopology Managerを用いていたが、
+Topology Managerを複数用意しそれぞれにLAN内とWAN内のトポロジーを管理させることで、NAT越えや別の分散アプリケーションの連携が容易にできることが期待される。
+
+%ToDo:Topologymanagerが必要な理由
+%分散アプリケーションは複数のノードを管理しないといけない。
+%  1.分散アプリを見つける
+%    2.ノードをトポロジーに接続する(物理ネットワークとの対応:NATの対応)
+%    3.故障など問題発生時の再構成
+%    4.複数アプリのセパレーション・インタラクション
+%    LAN内を構成するTopMとWANをGTopMが対応することで解決
+%    直接の応用がTreeVNC(いままではこう)。
+%    いままではTopMだけだったがGTopMを追加する
 
 \section{分散フレームワーク Alice の概要}
 \subsection*{[Data SegmentとCode Segment]}
@@ -146,10 +156,12 @@
 このようにプログラムすることで、通常処理と例外処理を分離することができるため、仕様の変更を抑えたシンプルなプログラムを記述できる。
 
 \subsection*{[Topology Manager]}
-ToDo:動的・静的でセクションわけ
 
 Aliceでは、ノード間の接続管理やトポロジーの構成管理を、Topology ManagerというMeta Computationが提供している。
 このTopology ManagerもCS/DSを用いて実装されている。
+
+\textbf{静的トポロジー}
+
 プログラマはトポロジーファイルを用意し、Topology Managerに読み込ませるだけでトポロジーを構成することができる。
 トポロジーファイルはDOT Language\cite{dot}という言語で記述される。
 DOT Languageとは、プレーンテキストを用いてデータ構造としてのグラフを表現するためのデータ記述言語の一つである。
@@ -174,16 +186,28 @@
 トポロジーファイルでlavelとして指定した名前はRemote DSMの名前としてTopology Nodeに渡される。
 そのため、Topology NodeはTopology ManagerのIPアドレスさえ知っていれば自分の接続すべきノードのデータを受け取り、ノード間での正しい接続を実現できる。
 
-また、実際の分散アプリケーションでは参加するノードの数が予め決まっているとは限らない。
+
+\textbf{動的トポロジー}
+
+実際の分散アプリケーションでは参加するノードの数が予め決まっているとは限らない。
 そのためTopology Managerは動的トポロジーにも対応している。
 トポロジーの種類を選択してTopology Managerを立ち上げれば、あとは新しいTopology Nodeが参加表明するたびに、
 Topology ManagerからTopology Nodeに対して接続すべきTopology Nodeの情報が渡され接続処理が順次行われる。
 そしてTopology Managerが持つトポロジー情報が更新される。
 現在Topology Managerでは動的なトポロジータイプとしてBinary Tree とStarに対応している。
 
-さらに、Topology Managerではトポロジーの管理だけでなく、ノードとの接続状態を常に確認するMeta Computation(Keep Alive)や、
-切断・再接続時の処理を指定できるMeta Computationが用いられている。
-そのため、構成したノード間の接続が途切れても再構成することができる。
+\textbf{障害発生時の対応}
+
+ノード間接続が切れた場合、次の通信が行われるまで切断を発見することができない。また、接続状態ではあるが応答に時間がかかる場合もある。
+これらの問題を検知するために、KeepAliveという定期的にheart beatを送信しノードの生存確認を行うMeta Computationが用意されている。
+一定時間内にノードからの応答がない場合、そのノードのRemote DSMが切断され、再接続すべきノード情報を要求する。
+
+また、各ノードに切断・再接続時に対する処理を特別に用意したい場合がある。
+そのために、切断・再接続を検知した際に任意のCSを実行できるMeta Computationもある。
+プログラマは切断の際に実行したいCSを書き、Meta Computationに指定しておくだけで良い。
+
+これらのMeta ComputationはTopology Managerにも含まれているため、
+Topology Managerを用いることで構成したノード間の接続が途切れてもトポロジーを再構成することができる。
 
 
 \section{TreeVNCのNAT越え}
@@ -317,7 +341,37 @@
 
 Meta Meta ComputationがNAT越えをサポートするため、Topology ManagerもTopology Nodeも接続要求のあったノードがグローバルかプライベートかを気にせず扱うことができる。
 
-\section{比較}
+\section{他言語等との比較}
+\subsection*{[Erlang]}
+
+並列指向プログラミング言語Erlang\cite{Erlang}は、プロセスと呼ばれるid付きの独立したタスクに対して、データをメッセージでやりとりする。
+タスクをプロセスという細かい単位に分割して並列に動かす点や、メモリロックの仕組みを必要としない点はAliceと同様である。
+
+しかしErlangでは分散環境の構築等はプログラマ自身が記述しなければならない。
+Aliceでは分散環境の構築はTopology Managerが一括して管理するため、プログラマはトポロジーを指定するだけで良い。
+
+ErlangにはNAT越えをサポートするためのライブラリが存在する\cite{Erlang-NAT}し、
+NAT機器と通信し外側IPアドレスを取得メソッドや、NATに指定したポート番号でポートマッピングするメソッドが用意されている。
+
+Aliceでは、それらの機能もTopology Nodeの一部に含めることで、NAT越えを意識しなくともTopology Nodeを用いるだけでサポートできるようにする。
+
+
+\subsection*{[Akka]}
+
+Akka\cite{Akka}はScala・Java向けの並列分散処理フレームワークである。
+アクターモデルを採用しており、アクターと呼ばれるアドレスを持ったタスクに、データをメッセージでやりとりする点がErlangと似ている。
+Akkaの特徴として、メッセージを送りたいプロセスのアドレスを知っていればアクターがどのマシン上にあるかを意識せずにプログラミングできるという点がある。
+逆にAliceはどのRemote DSMに対してやり取りをするかを考慮するが、CSがOutputしたDSを次にどのCSに渡すかを意識する必要がない。
+この点はアクターモデルとCS/DSモデルのパラダイムの違いと言える。
+
+また、Akkaのもう一つの特徴として、アクターで親子関係を構成できる点がある。
+分散通信部分を子アクターに分離し、親アクターは子アクターのExceptionが発生した時に再起動や終了といった処理を指定できる。
+さらにRouterという子アクターへのメッセージの流れを制御するアクターや、Dispatcherというアクターへのスレッドの割当を管理する機能をAkkaが提供している。
+このように処理を階層化し複雑な処理をフレームワーク側が提供する仕組みはAliceのMeta Computationと共通している。
+
+AkkaではNATに対応するために、外側IPアドレスとポート番号を指定することができる。
+しかしNAT機器へのポートマッピングはプログラマが記述しなければならない。
+
 
  \section{まとめ}
 並列分散フレームワークAliceでは、スケーラブルかつ信頼性の高いプログラムを記述する環境を実現するため、CS/DSの計算モデルとMeta Computationによる実装の階層化を採用している。