comparison final_main/chapter4/chapter4.tex @ 8:f71206f427e3

add text and some file
author ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date Tue, 11 Feb 2020 17:44:52 +0900
parents 59f9d2488005
children a37b7bd13be9
comparison
equal deleted inserted replaced
7:59f9d2488005 8:f71206f427e3
16 \item ノードの中心(サーバー)が正しいファイル状況を保持するため,整合性を保つことが容易である. 16 \item ノードの中心(サーバー)が正しいファイル状況を保持するため,整合性を保つことが容易である.
17 \item どこかのノードの接続が切断されても, 障害の範囲をそのノードのみに抑えることができる. 17 \item どこかのノードの接続が切断されても, 障害の範囲をそのノードのみに抑えることができる.
18 \item 新しいノードが参加した, もしくはノードの再接続の際にはサーバーのファイル状況を参照するのみで参加, 復帰ができる. 18 \item 新しいノードが参加した, もしくはノードの再接続の際にはサーバーのファイル状況を参照するのみで参加, 復帰ができる.
19 \end{itemize} 19 \end{itemize}
20 と言ったことが挙げられる. 20 と言ったことが挙げられる.
21 21 TopologyManagerの接続相手にラベルをつける機能により, サーバーでは各nodeすべてをまとめて一つの名前で処理をすることができる. 反対に各ノードもラベルを利用することで, CG内に大きな工夫をつけることなくサーバーとの通信を行うことができる. \\
22 懸念点として
23 \begin{itemize}
24 \item 通信がノードのみに集中するため, それを原因に遅延が発生する可能性がある.
25 \item サーバーと他ノードとの一対複数という通信形式から発生する, 予期せぬ編集誤差の危険性.
26 \end{itemize}
27 と言った点が挙げられる. これらの発生を防ぐため,
28 \begin{itemize}
29 \item 送信するデータ量や頻度を減らす工夫などを凝らし, 通信の負荷がなるべく少ない設計を構築する.
30 \item サーバーを中心とした整合性維持のための設計をする.
31 \end{itemize}
32 と言った対策が考えられる.
22 33
23 \begin{figure}[H] 34 \begin{figure}[H]
24 \centering 35 \centering
25 \fbox{ 36 \fbox{
26 \includegraphics[scale=0.7]{./images/Star-Topology.pdf} 37 \includegraphics[scale=0.7]{./images/Star-Topology.pdf}