%\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}