--- a/final_main/chapter4/chapter4.tex	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/chapter4/chapter4.tex	Fri Feb 07 21:12:05 2020 +0900
@@ -3,134 +3,21 @@
 %%文書開始****************************
 \begin{document} 
 %%**************************************
-\chapter{Christieについて}
-
-Christieは当研究室で開発している分散フレームワークである. Christieには分散プログラムを簡潔に書くための工夫が複数ある.
-本章ではChristieについて述べる.
-\section{Christieとは}
-ChristieはJavaで書かれた分散フレームワークである. Christieは当研究室で開発している GearsOSに組み込まれる予定がある. そのため, GearsOS を構成する言語 Continuation based C と似た概念がある. Christie に存在する概念として次のようなものがある.
-
+\chapter{スター型接続によるネットワーク通信}
+リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行う. スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続である. 
+先行研究においてはノードの通信をリング型, つまりノード同士を円となる形で接続することで実装を試みたが, 
 \begin{itemize}
-\item CodeGear(以下 CG)
-\item DataGear(以下 DG)
-\item CodeGearManager(以下 CGM)
-\item DataGearManager(以下 DGM)
-\end{itemize}
-
-CGはクラス, スレッドに相当し, javaの継承を用いて記述する. DGは変数データに相当し, CG内でアノテーションを用いて変数データを取り出せる. CGM はノードであり, DGM, CG, DG を管理する. DGM は DG を管理するものであり, put という操作により変数データ, つまり DG を格納できる.
-DGMのput操作を行う際にはLocalとRemoteと2つのどちらかを選び, 変数のkeyとデータを引数に書く. Localであれば,  Local のCGMが管理しているDGMに対し, DGを格納していく. Remoteであれば接続したRemote先の CGMのDGMにDGを格納できる. put操作を行ったあとは, 対象のDGMの中にqueueとして保管される. 
-DGを取り出す際には, CG内で宣言した変数データにアノテーションをつける. DGのアノテーションにはTake, Peek, TakeFrom, PeekFromの4つがある. 
-\begin{description}
-\item[Take] 先頭のDGを読み込み, そのDGを削除する. DGが複数ある場合, この動作を用いる.
-\item[Peek] 先頭のDGを読み込むが, DGが削除されない. そのため, 特に操作をしない場合は同じデータを参照し続ける. 
-\item[TakeFrom(Remote DGM name)] Takeと似ているが, Remote DGM nameを指定することで, その接続先(Remote)のDGMからTake操作を行える.
-\item[PeekFrom(Remote DGM name)] Peekと似ているが, Remote DGM nameを指定することで, その接続先(Remote)のDGMからPeek操作を行える.
-\end{description}
-
-以上が, Christieの概要である.
-
-\section{プログラミングの例}
-ここでは, Christieで実際にプログラムを記述する例を述べる.
-CGMを作り, setup(new CodeGear)を動かすことにより, DGを待ち合わせ, DGが揃った場合にCodeGearが実行される. CGMを作る方法はStartCodeGear(以下SCG)を継承したものからcreateCGM(port) methodを実行することにより, CGMが作られる. SCGのコードの例をソースコード\ref{code:StartHelloWorld}に示す.
-
-\lstinputlisting[caption=StartHelloWorld,label=code:StartHelloWorld]{./src/HelloWorld/StartHelloWorld.java}
-
-
-\section{TopologyManagerの実装}
-Christieは当研究室で開発されたAliceを改良した分散フレームワークである. しかしAliceの機能を全て移行したわけではない. TopologyManagerは最たる例であり, 分散プログラムを簡潔に書くために必要である. そのため, ChristieにTopologyManagerを実装した.
-
-ここでは, TopologyManagerとはどのようなものかを述べる. そして, TopologyManagerを実装する際に, Christie自身のコードを変更する必要があったため, TopologyManagerでどのような問題が起こり, Christieの基本機能をどのような変更したかも述べる.
-
-TopologyManagerとは, Topologyを形成するため, 参加を表明したノード, TopologyNodeに名前を与え, 必要があればノード同士の配線も行うノードである. TopologyManagerのTopology形成方法として, 静的Topologyと動的Topologyがある. 静的Topologyはソースコード\ref{code:dot-example}のようなdotファイルを与えることで, ノードの関係を図\ref{fig:dot-example}のようにさせる. 静的Topologyはdotファイルのノード数と同等のTopologyNodeがあって初めて, CodeGearが実行される. 
-
-\lstinputlisting[caption=ring.dot,label=code:dot-example]{./src/ring.dot}
-
-\begin{figure}[H]
-\centering
-  \fbox{
-   \includegraphics[scale=1]{./images/ring.pdf}
-  }
-\caption{ソースコード\ref{code:dot-example}, ring.dotを図にしたもの}
-\label{fig:dot-example}
-\end{figure}
-
-
-
-動的Topologyは参加を表明したノードに対し, 動的にノード同士の関係を作る. 例えばTreeを構成する場合, 参加を表明したノードから順に, rootに近い位置の役割を与える. また, CodeGearはノードが参加し, parentに接続したあとに実行される.
-
-TopologyManagerを実装するに当たって, 以下の2つの問題点が出た.
-
-\begin{itemize}
-\item Take, Peek操作でSuperClassの型を持ったデータを取り出す際にNullPointerExceptionが表示される.
-\item ノード間で繋がる前にput操作を行うとデータが送られない.
+\item ノードごとのもつファイルの整合性の維持が難しい. 
+\item どこかのノード同士の通信が切断された際の再接続が難しく, また障害が全体に影響してしまう. 
+\item 障害からの復帰が難しい.
 \end{itemize}
-
-Take, Peek操作でSuperClassの型を持ったデータを取り出す際にNullPointerExceptionが表示される問題に対しては, DataGearでdataを代入する際にSuperClass, interfacesまで比較するように書き換えた. また, 型の不一致が起こった際は例外を投げるようにした. その修正後のコードをソースコード\ref{code:datagear}に示す. 
-
-\begin{lstlisting}[caption=修正後のDataGearのソースコード,label=code:datagear]
-public class DataGear<T>{
-   
-    ...
-   
-    public void setData(T data) {
-        Class dataClazz = data.getClass();
-
-        if(dataClazz == this.clazz){
-            this.data = data; return;
-        }
-
-        Class dataSuperClazz = dataClazz.getSuperclass();
-        while (dataSuperClazz != null) {
-            if(dataSuperClazz == this.clazz) {
-                this.data = data; return;
-            }
-            dataSuperClazz = dataSuperClazz.getSuperclass();
-        }
-
-        Class<?>[] interfaces = dataClazz.getInterfaces();
-        for (Class<?> interfaze : interfaces) {
-            if(interfaze == this.clazz) {
-                this.data = data; return;
-            }
-        }
-
-        throw new ClassCastException("datagear cannot set class from " + dataClazz.getName() + " to " + clazz.getName());
-
-    }
-
-}
-\end{lstlisting}
-
-setDataメソッドの中身を変更した. TopologyNodeにおいて, 実行するCodeGearをputしておき, 参加するノードがすべて揃ったら, そのCodeGearを実行する. しかし, 実際には実行するCodeGearはCodeGearを継承したものである. Christieは, putされたdataのクラスとTakeされるデータのクラスが一致したならばdataを代入し, それ以外なら無視するという処理を行っていた. SuperClass, interfacesの型までは比較をしていなかっため, 型の不一致が起こり, dataの代入をしないため, NullPointerExceptionが表示されていた. 
-
-
-ノード間で繋がる前にput操作を行うとデータが送られない問題に対しては, waitを付け加えた. そのコードをソースコード\ref{code:rdgm}に示す. 
-
-\lstinputlisting[caption=修正後のRemoteDataGearManagerのソースコード,label=code:rdgm]{./src/RemoteDataGearManager.java}
-
-具体的にはソースコード\ref{code:rdgm}の17行目から21行目にlockを付け加え, putメソッドの48行目にwaitするメソッドを置き, 54行目から63行目にwaitするメソッドを付け加えた. この問題は, ノードが繋がる前にconnection.writeを行うため, 相手のDataGearに書き込みが行われないために起きた. そのため, 相手とDataGearがつながるまでputメソッドをwaitしておき, つながってからconnection.write操作を行うように書き換えた.
-
-\section{Christieにおけるブロックチェーンの実装の利点と欠点}
-
-Christieにおいてブロック, トランザクション, Paxos, Proof of Workを実装した. 
-その際, Christieで実装した場合の便利な点を述べる.
-
+などの問題が見られた. リング型と比較した際のスター型の利点として, 
 \begin{itemize}
-\item データの取り出しが簡単. ChristieはDataGearという単位でデータを保持する. そのため, ブロックやトランザクションはDataGearに包めばいいため, どう送るかという問題を考えなくてすむ. 
-\item TopologyManagerでのテストが便利. dotファイルが有れば, TopologyManagerが任意の形でTopologyを作れる. そのため, ノードの配置については理想の環境を作れるため, 理想のテスト環境を作ることができる. 
-\item 機能ごとにファイルが実装できるため, 見通しが良い. ChristieはCbCのgotoと同じように関数が終わるとsetupによって別の関数に移動する. そのため自然に機能ごとにファイルを作るため, 見通しが良くなる.
+\item ノードの中心(サーバー)が正しいファイル状況を保持するため,整合性を保つことが容易である.
+\item どこかのノードの接続が切断されても, 障害の範囲をそのノードのみに抑えることができる.
+\item 新しいノードが参加した, もしくはノードの再接続の際にはサーバーのファイル状況を参照するのみで参加, 復帰ができる.
 \end{itemize}
-
-不便な点を以下に述べる.
-
-\begin{itemize}
-\item デバッグが難しい. cgm.setupでCodeGearが実行されるが, keyの待ち合わせで止まり, どこのCGで止まっているかわからないことが多かった. 例えば, putするkeyのスペルミスでコードの待ち合わせが起こり, CGが実行されず, エラーなども表示されずにwaitすることがある. その時に, どこで止まっているか特定するのが難しい.
-\item TakeFrom, PeekFromの使い方が難しい. TakeFrom, PeekFromは引数でDGM nameを指定する. しかし, DGMの名前を静的に与えるよりも, 動的に与えたい場合が多かった.
-\item Takeの待ち合わせでCGが実行されない. 2つのCGで同じ変数をTakeしようとすると, setupされた時点で変数がロックされる. このとき, 片方のCGはDGがすべて揃っているのに, すべての変数が揃っていないもう片方のCGに同名の変数がロックされ, 実行されない場合がある. 
-\end{itemize}
-
-
-
+と言ったことが挙げられる.
 
 \newpage