%\input{/Users/e155753/.tex/setup}

%%文書開始****************************
\begin{document} 
%%**************************************
\chapter{スター型接続によるネットワーク通信}
リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行い, リモートエディタの通信部分の障害に対する耐性を保障する. スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続であり, 図:\ref{fig:star} はスター型接続をグラフ化した物である. 図で説明すると, node0がハブノード(サーバーの役割)として他のnode1, 2, 3, 4 と接続する。ここに新しくnode5が接続に加わると仮定すると, 他のノードと同様にnode0と接続する. 


\begin{figure}[H]
\centering
  \fbox{
   \includegraphics[scale=0.7]{./images/Star-Topology.pdf}
  }
  \caption{スター型の接続をグラフ化した物}
\label{fig:star}
\end{figure}

\section{スター型の利点と比較}

先行研究においてはノードの通信をリング型, つまりノード同士を円となる形で接続することで実装を試みていた.
しかし, リング型には以下の欠点が見られた.  
\begin{itemize}
\item ノードごとのもつファイルの整合性の維持が難しい. 
\item どこかのノード同士の通信が切断された際の再接続が難しく, また障害が全体に影響してしまう. 
\item 障害からの復帰が難しい.
\end{itemize}
などの問題が見られた. リング型と比較した際のスター型の利点として, 
\begin{itemize}
\item ノードの中心(サーバー)が正しいファイル状況を保持するため,整合性を保つことが容易である.
\item どこかのノードの接続が切断されても, 障害の範囲をそのノードのみに抑えることができる.
\item 新しいノードが参加した, もしくはノードの再接続の際にはサーバーのファイル状況を参照するのみで参加, 復帰ができる.
\end{itemize}
と言ったことが挙げられる.
TopologyManagerの接続相手にラベルをつける機能により, サーバーでは各nodeすべてをまとめて一つの名前で処理をすることができる. 反対に各ノードもラベルを利用することで, CG内に大きな工夫をつけることなくサーバーとの通信を行うことができる. \\
懸念点として
\begin{itemize}
\item 通信がサーバーのみに集中するため, それを原因に遅延が発生する可能性がある.
\item サーバーと他ノードとの一対複数という通信形式から発生する, 予期せぬ編集誤差の危険性. 
\end{itemize}
と言った点が挙げられる. これらの発生を防ぐため,
\begin{itemize}
\item 送信するデータ量や頻度を減らす工夫などを凝らし, 通信の負荷がなるべく少ない設計を構築する.
\item サーバーを中心とした整合性維持のための設計をする.
\end{itemize}
と言った対策が考えられる. 


\newpage

%%文書終了****************************
\end{document}