--- a/final_main/chapter3/chapter3.tex	Tue Feb 11 21:59:14 2020 +0900
+++ b/final_main/chapter3/chapter3.tex	Wed Feb 12 19:40:35 2020 +0900
@@ -4,7 +4,10 @@
 \begin{document} 
 %%**************************************
 \chapter{スター型接続によるネットワーク通信}
-リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行い, リモートエディタの通信部分の障害に対する耐性を保障する. スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続であり, 図:\ref{fig:star} はスター型接続をグラフ化した物である. 図で説明すると, node0がハブノード(サーバーの役割)として他のnode1, 2, 3, 4 と接続する。ここに新しくnode5が接続に加わると仮定すると, 他のノードと同様にnode0と接続する. 
+リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行い, リモートエディタの通信部分の障害に対する耐性を保障する.
+ スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続であり, 図:\ref{fig:star} はスター型接続をグラフ化した物である. 
+ 図で説明すると, node0がハブノード(サーバーの役割)として他のnode1, 2, 3, 4 と接続する.
+ 例えばここに新しくnode5が接続に加わると仮定すると, 他のノードと同様にnode0と接続するのみでセッションに参加ができる.. 
 
 
 \begin{figure}[H]
@@ -18,31 +21,42 @@
 
 \section{スター型の利点と比較}
 
-先行研究においてはノードの通信をリング型, つまりノード同士を円となる形で接続することで実装を試みていた.
+先行研究においてはノードの通信をリング型, つまりノード同士を円となる形で接続し, そこに巡回トークンを巡らせコマンドを回収することで実装を試みていた.
 しかし, リング型には以下の欠点が見られた.  
+
 \begin{itemize}
 \item ノードごとのもつファイルの整合性の維持が難しい. 
 \item どこかのノード同士の通信が切断された際の再接続が難しく, また障害が全体に影響してしまう. 
 \item 障害からの復帰が難しい.
 \end{itemize}
-などの問題が見られた. リング型と比較した際のスター型の利点として, 
+
+リング型と比較した際のスター型の利点として, 
+
 \begin{itemize}
 \item ノードの中心(サーバー)が正しいファイル状況を保持するため,整合性を保つことが容易である.
 \item どこかのノードの接続が切断されても, 障害の範囲をそのノードのみに抑えることができる.
 \item 新しいノードが参加した, もしくはノードの再接続の際にはサーバーのファイル状況を参照するのみで参加, 復帰ができる.
 \end{itemize}
+
 と言ったことが挙げられる.
-TopologyManagerの接続相手にラベルをつける機能により, サーバーでは各nodeすべてをまとめて一つの名前で処理をすることができる. 反対に各ノードもラベルを利用することで, CG内に大きな工夫をつけることなくサーバーとの通信を行うことができる. \\
+
+TopologyManagerの接続相手にラベルをつける機能により, サーバーでは各nodeすべてをまとめて一つの名前で処理をすることができる.
+反対に各ノードもラベルを利用することで, CG内に大きな工夫をつけることなくサーバーとの通信を行うことができる. 
+
 懸念点として
+
 \begin{itemize}
 \item 通信がサーバーのみに集中するため, それを原因に遅延が発生する可能性がある.
 \item サーバーと他ノードとの一対複数という通信形式から発生する, 予期せぬ編集誤差の危険性. 
 \end{itemize}
+
 と言った点が挙げられる. これらの発生を防ぐため,
+
 \begin{itemize}
 \item 送信するデータ量や頻度を減らす工夫などを凝らし, 通信の負荷がなるべく少ない設計を構築する.
 \item サーバーを中心とした整合性維持のための設計をする.
 \end{itemize}
+
 と言った対策が考えられる.