Mercurial > hg > Papers > 2020 > itsuki-thesis
comparison final_main/chapter3/chapter3.tex @ 10:5ddb3e41e515
remove .DS_Store
| author | ichikitakahiro <e165713@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Wed, 12 Feb 2020 19:40:35 +0900 |
| parents | a37b7bd13be9 |
| children | b8149a449b7d |
comparison
equal
deleted
inserted
replaced
| 9:a37b7bd13be9 | 10:5ddb3e41e515 |
|---|---|
| 2 | 2 |
| 3 %%文書開始**************************** | 3 %%文書開始**************************** |
| 4 \begin{document} | 4 \begin{document} |
| 5 %%************************************** | 5 %%************************************** |
| 6 \chapter{スター型接続によるネットワーク通信} | 6 \chapter{スター型接続によるネットワーク通信} |
| 7 リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行い, リモートエディタの通信部分の障害に対する耐性を保障する. スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続であり, 図:\ref{fig:star} はスター型接続をグラフ化した物である. 図で説明すると, node0がハブノード(サーバーの役割)として他のnode1, 2, 3, 4 と接続する。ここに新しくnode5が接続に加わると仮定すると, 他のノードと同様にnode0と接続する. | 7 リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行い, リモートエディタの通信部分の障害に対する耐性を保障する. |
| 8 スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続であり, 図:\ref{fig:star} はスター型接続をグラフ化した物である. | |
| 9 図で説明すると, node0がハブノード(サーバーの役割)として他のnode1, 2, 3, 4 と接続する. | |
| 10 例えばここに新しくnode5が接続に加わると仮定すると, 他のノードと同様にnode0と接続するのみでセッションに参加ができる.. | |
| 8 | 11 |
| 9 | 12 |
| 10 \begin{figure}[H] | 13 \begin{figure}[H] |
| 11 \centering | 14 \centering |
| 12 \fbox{ | 15 \fbox{ |
| 16 \label{fig:star} | 19 \label{fig:star} |
| 17 \end{figure} | 20 \end{figure} |
| 18 | 21 |
| 19 \section{スター型の利点と比較} | 22 \section{スター型の利点と比較} |
| 20 | 23 |
| 21 先行研究においてはノードの通信をリング型, つまりノード同士を円となる形で接続することで実装を試みていた. | 24 先行研究においてはノードの通信をリング型, つまりノード同士を円となる形で接続し, そこに巡回トークンを巡らせコマンドを回収することで実装を試みていた. |
| 22 しかし, リング型には以下の欠点が見られた. | 25 しかし, リング型には以下の欠点が見られた. |
| 26 | |
| 23 \begin{itemize} | 27 \begin{itemize} |
| 24 \item ノードごとのもつファイルの整合性の維持が難しい. | 28 \item ノードごとのもつファイルの整合性の維持が難しい. |
| 25 \item どこかのノード同士の通信が切断された際の再接続が難しく, また障害が全体に影響してしまう. | 29 \item どこかのノード同士の通信が切断された際の再接続が難しく, また障害が全体に影響してしまう. |
| 26 \item 障害からの復帰が難しい. | 30 \item 障害からの復帰が難しい. |
| 27 \end{itemize} | 31 \end{itemize} |
| 28 などの問題が見られた. リング型と比較した際のスター型の利点として, | 32 |
| 33 リング型と比較した際のスター型の利点として, | |
| 34 | |
| 29 \begin{itemize} | 35 \begin{itemize} |
| 30 \item ノードの中心(サーバー)が正しいファイル状況を保持するため,整合性を保つことが容易である. | 36 \item ノードの中心(サーバー)が正しいファイル状況を保持するため,整合性を保つことが容易である. |
| 31 \item どこかのノードの接続が切断されても, 障害の範囲をそのノードのみに抑えることができる. | 37 \item どこかのノードの接続が切断されても, 障害の範囲をそのノードのみに抑えることができる. |
| 32 \item 新しいノードが参加した, もしくはノードの再接続の際にはサーバーのファイル状況を参照するのみで参加, 復帰ができる. | 38 \item 新しいノードが参加した, もしくはノードの再接続の際にはサーバーのファイル状況を参照するのみで参加, 復帰ができる. |
| 33 \end{itemize} | 39 \end{itemize} |
| 40 | |
| 34 と言ったことが挙げられる. | 41 と言ったことが挙げられる. |
| 35 TopologyManagerの接続相手にラベルをつける機能により, サーバーでは各nodeすべてをまとめて一つの名前で処理をすることができる. 反対に各ノードもラベルを利用することで, CG内に大きな工夫をつけることなくサーバーとの通信を行うことができる. \\ | 42 |
| 43 TopologyManagerの接続相手にラベルをつける機能により, サーバーでは各nodeすべてをまとめて一つの名前で処理をすることができる. | |
| 44 反対に各ノードもラベルを利用することで, CG内に大きな工夫をつけることなくサーバーとの通信を行うことができる. | |
| 45 | |
| 36 懸念点として | 46 懸念点として |
| 47 | |
| 37 \begin{itemize} | 48 \begin{itemize} |
| 38 \item 通信がサーバーのみに集中するため, それを原因に遅延が発生する可能性がある. | 49 \item 通信がサーバーのみに集中するため, それを原因に遅延が発生する可能性がある. |
| 39 \item サーバーと他ノードとの一対複数という通信形式から発生する, 予期せぬ編集誤差の危険性. | 50 \item サーバーと他ノードとの一対複数という通信形式から発生する, 予期せぬ編集誤差の危険性. |
| 40 \end{itemize} | 51 \end{itemize} |
| 52 | |
| 41 と言った点が挙げられる. これらの発生を防ぐため, | 53 と言った点が挙げられる. これらの発生を防ぐため, |
| 54 | |
| 42 \begin{itemize} | 55 \begin{itemize} |
| 43 \item 送信するデータ量や頻度を減らす工夫などを凝らし, 通信の負荷がなるべく少ない設計を構築する. | 56 \item 送信するデータ量や頻度を減らす工夫などを凝らし, 通信の負荷がなるべく少ない設計を構築する. |
| 44 \item サーバーを中心とした整合性維持のための設計をする. | 57 \item サーバーを中心とした整合性維持のための設計をする. |
| 45 \end{itemize} | 58 \end{itemize} |
| 59 | |
| 46 と言った対策が考えられる. | 60 と言った対策が考えられる. |
| 47 | 61 |
| 48 | 62 |
| 49 \newpage | 63 \newpage |
| 50 | 64 |