Mercurial > hg > Papers > 2020 > itsuki-thesis

Binary file final_main/.DS_Store has changed
--- a/final_main/chapter2/chapter2.tex	Tue Feb 11 17:44:52 2020 +0900
+++ b/final_main/chapter2/chapter2.tex	Tue Feb 11 21:59:14 2020 +0900
@@ -3,76 +3,70 @@
 %%文書開始****************************
 \begin{document}
 %%**************************************
-\chapter{分散フレームワークChrisiteについて}
-ここでは本研究室で開発している分散フレームワークChrisiteについて解説する. Chrisiteは複雑な分散プログラムを簡潔に書くことのできる構成となっている.
+\chapter{リモートエディタ}
+リモートエディタとは他のマシン上に存在するファイルのバッファを別デバイスから開いて編集, 保存することができる機能である. 加えてこのリモートエディタを複数人が同時に同じファイルを編集し, その上変更がリアルタイムに反映されるように設計する.
+この章ではリモートエディタの実装の上で踏んだプロセスや, 開発の上で問題となる点と解決策について説明する。
+
+\section{document listenerによる編集オフセット番号の読み取り}
+    エディタ同士の基本通信環境の構成のため, Chrisitie と同様のjava 言語で作成したエディタのインスタンスを使い, 異なるマシン同士の同期の実現を目指した.  自作エディタは java. swingの機能で構成されており, 追記または削除されたオフセット位置とその内容の取得はDocumentListenrを使用した. DocumentListenerのクラスはswingで実装したエディタ部分の入力と削除を検知し, 動作するメソッドであり, DocumentEvent内に入力されたオフセットとその長さや文字列が入力されるため, それをChrisitie側で検知し処理を行った.
+insertUpdateメソッドではバッファに入力が行われた際に自動的に実行され, removeUpdateメソッドは同様に削除が行われた際に実行される. 他ノードから送信されてきた命令によるバッファの変更によっても実行され, 意図しないループが発生したため, 受信した命令では実行されないように記述をおこなった.
+
+\lstinputlisting[caption=DocumentListenerのコード部分, label=code:DocumentListener]{./src/DocumentListener.java}


-\section{Chrisiteとは}
-ChristieはJava言語で構成された本研究室独自の分散フレームワークである。同じく本研究室で開発を行っているGearsOSのファイルシステムに組み込む予定があるため, GearsOSを構成している本研究室の独自の言語Continuation based C (以下CbC言語)とにた, Gearというプログラム概念が存在する.
+\section{Command パターンによる命令オブジェクトの作成}
+リモートエディタを実装する上において, 各エディタは自身に起きたバッファの変更を対応した他ノードに送信する必要がある. この変更の送り合いをCommand パターンとして実装した. Command パターンとは, 命令を一つのオブジェクトとして表現する方法である. コマンドパターンの利点として,
+\begin{itemize}
+\item インスタンスを利用して命令を作成するため, ChristieのGearの概念と相性が良い.
+\item 命令に必要な内容をまとめて送信するため, 相違の発生を防ぐことができる.
+\item 命令の管理が行いやすい, 行列に並ばせ命令の順番を管理したり, 命令の際実行, 取り消しが容易になる.
+\end{itemize}
+といった点が挙げられる. ソースコード:\ref{code:Command}は書き込み, 送信を行う際の命令をクラスとして作成したものである. このクラスのインスタンスを命令オブジェクトとして送信し合う.
+
+\lstinputlisting[caption=Commandパターンとして実装した命令, label=code:Command]{./src/Command.java}
+
+\section{命令オブジェクトを実装する際に起きた問題}
+インスタンス化した命令を他ノードに送信する際にエラーが発生し, 送信に失敗してしまうという問題が発生した. クラスの送信の際のシリアライズはmsgpackクラスを利用していた.
+msgpackクラスは,シリアライズしたいクラスにMessage アノテーションをつけることにより, シリアライズ化を行う. 原因を調査した結果, 以下の原因が見つかった.

 \begin{itemize}
-\item CodeGear(以下 CG)
-\item DataGear(以下 DG)
-\item CodeGearManager(以下 CGM)
-\item DataGearManager(以下 DGM)
+\item Christieのjavaバージョンは11を使用していたが, msgpackバージョン0.6.12はjava11に対して対応していなかった.
+\item msgpackの最新版0.8.20はシリアライズ機能が含まれなくなった.
 \end{itemize}

-CodeGearはクラスやスレッドに相当しする. DataGear は変数データに相当し, javaのアノテーション機能を用いて記述する. CG内に記述したKeyに全てのDGが揃った際に初めてそのCGが動作するという仕組みになっている. CodeGearManager はいわゆるノードに相当し、CG, DG ,DGM を管理する.  DataGearManager は DG を管理するもので,  put という操作により DG , 要するに変数データを格納することができる。DGM の put 操作を行う際には Local と Remote と 2 つのどちらかを選び, 変数の key とデータを引数に書く. Local であれば, Local の CGM が管理している DGM に対し, DG を格納していく. Remote であれば接続した Remote 先の CGM の DGM に DG を格納できる. put 操作を行ったあとは, 対象の DGM の中に queue として保管される. \\
-DG を取り出す際には, CG 内で宣言した変数データにアノテーションをつける. DG のアノテーションには Take, Peek, TakeFrom, PeekFrom の 4 つがある.
-
-\begin{description}
-\item[Take] 先頭のDGを読み込み, そのDGを削除する. DGが複数ある場合, この動作を用いる.
-\item[Peek] 先頭のDGを読み込むが, DGが削除されない. そのため, 特に操作をしない場合は同じデータを参照し続ける.
-\item[TakeFrom(Remote DGM name)] Takeと同様に読み込んだ後, DGを削除する. Remote DGM nameを指定することで, その接続先(Remote)のDGMからTake操作を行える.
-\item[PeekFrom(Remote DGM name)] Peekと同様に読み込み後もDGが削除されないが, Remote DGM nameを指定することで, その接続先(Remote)のDGMからPeek操作を行える.
-\end{description}
+以上の原因に対処するために以下のことを行った.

-\section{プログラムの例}
-以下のソースコード\ref{code:nStartHelloWorld} , \ref{code:HelloWorldCodeGear}のプログラムはChrisitieの基本動作となる DGM による put 操作を用いた hello world の出力プログラムである.  メソッド sreateCGM でポート番号を指定した上で CGM を作成しする. CGM にCG (クラスファイル)を指定した上でsetupすることでCGMが CGを動作させることができる. HelloWorldCodeGear()とFinishHelloWorld()がここではCGに当たる.  HelloWorldCodeGear() クラスには String型の"helloWorld" という key が用意され,  "helloWorld"に入力された DG(String型の変数データ) をprint するコードである.  "helloWorld" に hello と worldというDGをputすることで出力結果がhello world となる.
-\lstinputlisting[caption=StartHelloWorld,label=code:nStartHelloWorld]{./src/HelloWorld/StartHelloWorld.java}
+\begin{itemize}
+\item Christieのjavaバージョンを8まで下げ, msgpackバージョン0.6.12を動作できるようにした.
+\item シリアライズする命令クラスに対し, フィールドをpublic にした.
+\item javassistのバージョンを最新版へ変更した.
+\end{itemize}

-\lstinputlisting[caption=HelloWorldCodeGear,label=code:HelloWorldCodeGear]{./src/HelloWorld/HelloWorldCodeGear.java}
-
-CGM は起動し続けていると処理が自動的に終了しないという問題点がある. そこで役目がなくなったCGM を終了させるための処理を行わなければならない. CGMを終了させるためのプログラムはソースコード\ref{code:FinishHelloWorld} であり, 二つのkeyが揃ったらcgm.getLocalDGM().finish() の処理でcgmを終了させるよう記述されている.
-
-\lstinputlisting[caption=FinishHelloWorld, label=code:FinishHelloWorld]{./src/FinishHelloWorld.java}
+javaのバージョンを下げたのは応急的な処置となってしまったが, これらの処置により問題なくCommandパターンでの命令実装を行うことができた. javaのバージョンに左右されずリモートエディタを実装するには, シリアライズの機能について他のパッケージを使うか, 自信で作成する必要が生まれた。


-
-
-
-\section{TopologyManager について}
-ここではChrstie上でノード同士の接続をより簡潔にするために使われるTopologyManagerという機能について説明する.
-TopologyManagerとはTopologyを形成するために, 参加を表明したノード, TopologyNodeにlabel を与え, 必要があればノード同士の配線も自動で行う機能である.
-TopologyManagerのTopologyの形成方法として静的Topologyと動的Topologyの二つの方法がある. 静的Topologyはソースコード:  \ref{code:dotFile} のようなdotファイルを与えることでノードの接続を図 \ref{fig:dot} のように接続することができる. 例えばnode0 からはnode1 はright という名前で参照することができ, それぞれのノードが同じCG を実行してもlabel の与え方次第で想定したDG の差し合いを実現することができる. 静的Topologyはdotファイルのノード数と同等のTopologyNodeがあって初めて, CodeGear が実行され, ノード数が合わないとエラーが表示
-される.
-
-\lstinputlisting[caption=ringを構成するdotファイル, label=code:dotFile]{./src/ring.dot}
+\section{編集位置の相違}
+セッション中のエディタ間の通信で生じうる, 編集結果の相違について説明する. エディタ同士のコマンドの送信はそれぞれが独立して行うため, 編集対象の領域にエディタ間で相違が生じる場合がある. 例としてエディタが一対一の接続となっている時に発生しうる相違を図\ref{fig:difference} を使用して解説する.
+ 編集対象は各オフセット番号に同じ値の数字が入っているものとする. EditorA ではオフセット番号 3 の 3 という 要素を削除 (テキストエディタ上のため削除されたオフセットにはその後ろの要素が繰り上げられる.), EditorB では オフセット番号 2 に A という要素を挿入するという編集をしたとする. この編集を共通プロトコルとして互いに送信しあった際, 本来編集する予定だったオフセットの中身が異なってしまい編集結果に違いが生じてしまう. これらの問題を解決することのできるエディタ同士の通信手法を作成しなければならない。

 \begin{figure}[H]
 \centering
   \fbox{
-   \includegraphics[scale=1]{./images/ring.pdf}
+   \includegraphics[scale=0.6]{./images/difference_offset.pdf}
   }
-\caption{ソースコード \ref{code:dotFile} のdotファイルを図示化したもの}
-\label{fig:dot}
+\caption{通信のすれ違いによる編集位置の相違}
+\label{fig:difference}
 \end{figure}

-動的Topologyは参加を表明したノードを順番にTopologyの構成要素として接続していく物である. 現在時点で実装済みのTreeの構成を例とすると
-
-\begin{enumerate}
-\item 参加したノードを順にroot(根)に近い要素として接続する.
-\item Topologyの要素に構成されたノードはそれぞれ親, 子のノードを特定の名前(parent, child[n])で参照できる.
-\item 途中参加したノードは, 木の末端要素として接続する.
-\end{enumerate}
-以上の形でTopologyが形成される. \\
-コード:\ref{code:SRTE} はTopologyManagerを使用してTopologyを構成するコードである. String型のリスト(今回はmanagerArg)に構成したいTopologyの形状をdotファイル, もしくは実装済みの動的Topologyの構成型を設定し, TopologyManagerCondfigを起動することでTopologyManagerが起動できる. ソースコードではTreeを構成しており, for文でnodeNum 個分のノードを生成し, それぞれmanagerPortを記憶させている. これによりノードすべてがTopologyManagerによりTreeの構成要素として接続される.
-
-\lstinputlisting[caption=TopologyManagerによるTree型Topologyを構成するコード, label=code:SRTE]{./src/StartPrefixTree.java}
-
-現状では通信アルゴリズムの構成のため, dotファイルにより接続を行なっているが, 最終的にはStar型の動的Topology機能を作成し, 途中で参加してきたノードを接続が行えるようにする必要がある.
+\section{編集位置の相違解消方法}
+編集するオフセットに相違が発生する条件として, サーバーとノードがお互いにコマンドを送り合った際, その命令コマンドが相手に到着する前に相手が自身のバッファに変更を加えてしまった場合に起きる. したがって, 相違の解消に必要なことは
+\begin{itemize}
+\item サーバーとノード間のコマンド送信のすれ違いが発生したということを検知する方法
+\item すれ違いが発生した際に編集したオフセットのズレを修正する方法
+\end{itemize}
+が挙げられる.


 %%文書終了****************************
-\end{document}
\ No newline at end of file
+\end{document}
--- a/final_main/chapter3/chapter3.tex	Tue Feb 11 17:44:52 2020 +0900
+++ b/final_main/chapter3/chapter3.tex	Tue Feb 11 21:59:14 2020 +0900
@@ -3,72 +3,61 @@
 %%文書開始****************************
 \begin{document}
 %%**************************************
-\chapter{リモートエディタ}
-リモートエディタとは他のマシン上に存在するファイルのバッファを別デバイスから開いて編集, 保存することができる機能である. 加えてこのリモートエディタを複数人が同時に同じファイルを編集し, その上変更がリアルタイムに反映されるように設計する.
-この章ではリモートエディタの実装の上で踏んだプロセスや, 開発の上で問題となる点と解決策について説明する。
-
+\chapter{スター型接続によるネットワーク通信}
+リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行い, リモートエディタの通信部分の障害に対する耐性を保障する. スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続であり, 図:\ref{fig:star} はスター型接続をグラフ化した物である. 図で説明すると, node0がハブノード(サーバーの役割)として他のnode1, 2, 3, 4 と接続する。ここに新しくnode5が接続に加わると仮定すると, 他のノードと同様にnode0と接続する.


-\section{編集位置の相違}
-セッション中のエディタ間の通信で生じうる, 編集結果の相違について説明する. エディタ同士のコマンドの送信はそれぞれが独立して行うため, 編集対象の領域にエディタ間で相違が生じる場合がある. 例としてエディタが一対一の接続となっている時に発生しうる相違を図\ref{fig:difference} を使用して解説する.
- 編集対象は各オフセット番号に同じ値の数字が入っているものとする. EditorA ではオフセット番号 3 の 3 という 要素を削除 (テキストエディタ上のため削除されたオフセットにはその後ろの要素が繰り上げられる.), EditorB では オフセット番号 2 に A という要素を挿入するという編集をしたとする. この編集を共通プロトコルとして互いに送信しあった際, 本来編集する予定だったオフセットの中身が異なってしまい編集結果に違いが生じてしまう. これらの問題を解決することのできるエディタ同士の通信手法を作成しなければならない。
-
 \begin{figure}[H]
 \centering
   \fbox{
-   \includegraphics[scale=0.6]{./images/difference_offset.pdf}
+   \includegraphics[scale=0.7]{./images/Star-Topology.pdf}
   }
-\caption{通信のすれ違いによる編集位置の相違}
-\label{fig:difference}
+  \caption{スター型の接続をグラフ化した物}
+\label{fig:star}
 \end{figure}

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


-\section{document listenerによる編集オフセット番号の読み取り}
-    エディタ同士の基本通信環境の構成のため, Chrisitie と同様のjava 言語で作成したエディタのインスタンスを使い, 異なるマシン同士の同期の実現を目指した.  自作エディタは java. swingの機能で構成されており, 追記または削除されたオフセット位置とその内容の取得はDocumentListenrを使用した. DocumentListenerのクラスはswingで実装したエディタ部分の入力と削除を検知し, 動作するメソッドであり, DocumentEvent内に入力されたオフセットとその長さや文字列が入力されるため, それをChrisitie側で検知し処理を行った.
-insertUpdateメソッドではバッファに入力が行われた際に自動的に実行され, removeUpdateメソッドは同様に削除が行われた際に実行される. 他ノードから送信されてきた命令によるバッファの変更によっても実行され, 意図しないループが発生したため, 受信した命令では実行されないように記述をおこなった.
-
-\lstinputlisting[caption=DocumentListenerのコード部分, label=code:DocumentListener]{./src/DocumentListener.java}
+
+


-\section{Command パターンによる命令オブジェクトの作成}
-リモートエディタを実装する上において, 各エディタは自身に起きたバッファの変更を対応した他ノードに送信する必要がある. この変更の送り合いをCommand パターンとして実装した. Command パターンとは, 命令を一つのオブジェクトとして表現する方法である. コマンドパターンの利点として,
-\begin{itemize}
-\item インスタンスを利用して命令を作成するため, ChristieのGearの概念と相性が良い.
-\item 命令に必要な内容をまとめて送信するため, 相違の発生を防ぐことができる.
-\item 命令の管理が行いやすい, 行列に並ばせ命令の順番を管理したり, 命令の際実行, 取り消しが容易になる.
-\end{itemize}
-といった点が挙げられる. ソースコード:\ref{code:Command}は書き込み, 送信を行う際の命令をクラスとして作成したものである. このクラスのインスタンスを命令オブジェクトとして送信し合う.

-\lstinputlisting[caption=Commandパターンとして実装した命令, label=code:Command]{./src/Command.java}
-
-\section{命令オブジェクトを実装する際に起きた問題}
-インスタンス化した命令を他ノードに送信する際にエラーが発生し, 送信に失敗してしまうという問題が発生した. クラスの送信の際のシリアライズはmsgpackクラスを利用していた.
-msgpackクラスは,シリアライズしたいクラスにMessage アノテーションをつけることにより, シリアライズ化を行う. 原因を調査した結果, 以下の原因が見つかった.

-\begin{itemize}
-\item Christieのjavaバージョンは11を使用していたが, msgpackバージョン0.6.12はjava11に対して対応していなかった.
-\item msgpackの最新版0.8.20はシリアライズ機能が含まれなくなった.
-\end{itemize}

-以上の原因に対処するために以下のことを行った.
-
-\begin{itemize}
-\item Christieのjavaバージョンを8まで下げ, msgpackバージョン0.6.12を動作できるようにした.
-\item シリアライズする命令クラスに対し, フィールドをpublic にした.
-\item javassistのバージョンを最新版へ変更した.
-\end{itemize}
-
-javaのバージョンを下げたのは応急的な処置となってしまったが, これらの処置により問題なくCommandパターンでの命令実装を行うことができた. javaのバージョンに左右されずリモートエディタを実装するには, シリアライズの機能について他のパッケージを使うか, 自信で作成する必要が生まれた。
-
-%%文書終了****************************
-\end{document}
--- a/final_main/chapter4/chapter4.tex	Tue Feb 11 17:44:52 2020 +0900
+++ b/final_main/chapter4/chapter4.tex	Tue Feb 11 21:59:14 2020 +0900
@@ -3,55 +3,76 @@
 %%文書開始****************************
 \begin{document}
 %%**************************************
-\chapter{スター型接続によるネットワーク通信}
-リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行い, リモートエディタの通信部分の障害に対する耐性を保障する. スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続であり, 図:\ref{fig:star} はスター型接続をグラフ化した物である. 図で説明すると, node0がハブノード(サーバーの役割)として他のnode1, 2, 3, 4 と接続する。ここに新しくnode5が接続に加わると仮定すると, 他のノードと同様にnode0と接続する.
-先行研究においてはノードの通信をリング型, つまりノード同士を円となる形で接続することで実装を試みたが,
-\begin{itemize}
-\item ノードごとのもつファイルの整合性の維持が難しい.
-\item どこかのノード同士の通信が切断された際の再接続が難しく, また障害が全体に影響してしまう.
-\item 障害からの復帰が難しい.
-\end{itemize}
-などの問題が見られた. リング型と比較した際のスター型の利点として,
+\chapter{分散フレームワークChrisiteについて}
+ここでは本研究室で開発している分散フレームワークChrisiteについて解説する. Chrisiteは複雑な分散プログラムを簡潔に書くことのできる構成となっている.
+
+
+\section{Chrisiteとは}
+ChristieはJava言語で構成された本研究室独自の分散フレームワークである。同じく本研究室で開発を行っているGearsOSのファイルシステムに組み込む予定があるため, GearsOSを構成している本研究室の独自の言語Continuation based C (以下CbC言語)とにた, Gearというプログラム概念が存在する.
+
 \begin{itemize}
-\item ノードの中心(サーバー)が正しいファイル状況を保持するため,整合性を保つことが容易である.
-\item どこかのノードの接続が切断されても, 障害の範囲をそのノードのみに抑えることができる.
-\item 新しいノードが参加した, もしくはノードの再接続の際にはサーバーのファイル状況を参照するのみで参加, 復帰ができる.
-\end{itemize}
-と言ったことが挙げられる.
-TopologyManagerの接続相手にラベルをつける機能により, サーバーでは各nodeすべてをまとめて一つの名前で処理をすることができる. 反対に各ノードもラベルを利用することで, CG内に大きな工夫をつけることなくサーバーとの通信を行うことができる. \\
-懸念点として
-\begin{itemize}
-\item 通信がノードのみに集中するため, それを原因に遅延が発生する可能性がある.
-\item サーバーと他ノードとの一対複数という通信形式から発生する, 予期せぬ編集誤差の危険性.
+\item CodeGear(以下 CG)
+\item DataGear(以下 DG)
+\item CodeGearManager(以下 CGM)
+\item DataGearManager(以下 DGM)
 \end{itemize}
-と言った点が挙げられる. これらの発生を防ぐため,
-\begin{itemize}
-\item 送信するデータ量や頻度を減らす工夫などを凝らし, 通信の負荷がなるべく少ない設計を構築する.
-\item サーバーを中心とした整合性維持のための設計をする.
-\end{itemize}
-と言った対策が考えられる.
+
+CodeGearはクラスやスレッドに相当しする. DataGear は変数データに相当し, javaのアノテーション機能を用いて記述する. CG内に記述したKeyに全てのDGが揃った際に初めてそのCGが動作するという仕組みになっている. CodeGearManager はいわゆるノードに相当し、CG, DG ,DGM を管理する.  DataGearManager は DG を管理するもので,  put という操作により DG , 要するに変数データを格納することができる。DGM の put 操作を行う際には Local と Remote と 2 つのどちらかを選び, 変数の key とデータを引数に書く. Local であれば, Local の CGM が管理している DGM に対し, DG を格納していく. Remote であれば接続した Remote 先の CGM の DGM に DG を格納できる. put 操作を行ったあとは, 対象の DGM の中に queue として保管される. \\
+DG を取り出す際には, CG 内で宣言した変数データにアノテーションをつける. DG のアノテーションには Take, Peek, TakeFrom, PeekFrom の 4 つがある.

-\begin{figure}[H]
-\centering
-  \fbox{
-   \includegraphics[scale=0.7]{./images/Star-Topology.pdf}
-  }
-  \caption{スター型の接続をグラフ化した物}
-\label{fig:star}
-\end{figure}
+\begin{description}
+\item[Take] 先頭のDGを読み込み, そのDGを削除する. DGが複数ある場合, この動作を用いる.
+\item[Peek] 先頭のDGを読み込むが, DGが削除されない. そのため, 特に操作をしない場合は同じデータを参照し続ける.
+\item[TakeFrom(Remote DGM name)] Takeと同様に読み込んだ後, DGを削除する. Remote DGM nameを指定することで, その接続先(Remote)のDGMからTake操作を行える.
+\item[PeekFrom(Remote DGM name)] Peekと同様に読み込み後もDGが削除されないが, Remote DGM nameを指定することで, その接続先(Remote)のDGMからPeek操作を行える.
+\end{description}

-\newpage
+\section{プログラムの例}
+以下のソースコード\ref{code:nStartHelloWorld} , \ref{code:HelloWorldCodeGear}のプログラムはChrisitieの基本動作となる DGM による put 操作を用いた hello world の出力プログラムである.  メソッド sreateCGM でポート番号を指定した上で CGM を作成しする. CGM にCG (クラスファイル)を指定した上でsetupすることでCGMが CGを動作させることができる. HelloWorldCodeGear()とFinishHelloWorld()がここではCGに当たる.  HelloWorldCodeGear() クラスには String型の"helloWorld" という key が用意され,  "helloWorld"に入力された DG(String型の変数データ) をprint するコードである.  "helloWorld" に hello と worldというDGをputすることで出力結果がhello world となる.
+\lstinputlisting[caption=StartHelloWorld,label=code:nStartHelloWorld]{./src/HelloWorld/StartHelloWorld.java}

-%%文書終了****************************
-\end{document}
+\lstinputlisting[caption=HelloWorldCodeGear,label=code:HelloWorldCodeGear]{./src/HelloWorld/HelloWorldCodeGear.java}
+
+CGM は起動し続けていると処理が自動的に終了しないという問題点がある. そこで役目がなくなったCGM を終了させるための処理を行わなければならない. CGMを終了させるためのプログラムはソースコード\ref{code:FinishHelloWorld} であり, 二つのkeyが揃ったらcgm.getLocalDGM().finish() の処理でcgmを終了させるよう記述されている.
+
+\lstinputlisting[caption=FinishHelloWorld, label=code:FinishHelloWorld]{./src/FinishHelloWorld.java}


+\section{TopologyManager について}
+ここではChrstie上でノード同士の接続をより簡潔にするために使われるTopologyManagerという機能について説明する.
+TopologyManagerとはTopologyを形成するために, 参加を表明したノード, TopologyNodeにlabel を与え, 必要があればノード同士の配線も自動で行う機能である.
+TopologyManagerのTopologyの形成方法として静的Topologyと動的Topologyの二つの方法がある. 静的Topologyはソースコード:  \ref{code:dotFile} のようなdotファイルを与えることでノードの接続を図 \ref{fig:dot} のように接続することができる. 例えばnode0 からはnode1 はright という名前で参照することができ, それぞれのノードが同じCG を実行してもlabel の与え方次第で想定したDG の差し合いを実現することができる. 静的Topologyはdotファイルのノード数と同等のTopologyNodeがあって初めて, CodeGear が実行され, ノード数が合わないとエラーが表示
+される.
+
+\lstinputlisting[caption=ringを構成するdotファイル, label=code:dotFile]{./src/ring.dot}
+
+\begin{figure}[H]
+\centering
+  \fbox{
+   \includegraphics[scale=1]{./images/ring.pdf}
+  }
+\caption{ソースコード \ref{code:dotFile} のdotファイルを図示化したもの}
+\label{fig:dot}
+\end{figure}
+
+動的Topologyは参加を表明したノードを順番にTopologyの構成要素として接続していく物である. 現在時点で実装済みのTreeの構成を例とすると
+
+\begin{enumerate}
+\item 参加したノードを順にroot(根)に近い要素として接続する.
+\item Topologyの要素に構成されたノードはそれぞれ親, 子のノードを特定の名前(parent, child[n])で参照できる.
+\item 途中参加したノードは, 木の末端要素として接続する.
+\end{enumerate}
+以上の形でTopologyが形成される. \\
+コード:\ref{code:SRTE} はTopologyManagerを使用してTopologyを構成するコードである. String型のリスト(今回はmanagerArg)に構成したいTopologyの形状をdotファイル, もしくは実装済みの動的Topologyの構成型を設定し, TopologyManagerCondfigを起動することでTopologyManagerが起動できる. ソースコードではTreeを構成しており, for文でnodeNum 個分のノードを生成し, それぞれmanagerPortを記憶させている. これによりノードすべてがTopologyManagerによりTreeの構成要素として接続される.
+
+\lstinputlisting[caption=TopologyManagerによるTree型Topologyを構成するコード, label=code:SRTE]{./src/StartPrefixTree.java}
+
+現状では通信アルゴリズムの構成のため, dotファイルにより接続を行なっているが, 最終的にはStar型の動的Topology機能を作成し, 途中で参加してきたノードを接続が行えるようにする必要がある.


-
-
-
+%%文書終了****************************
+\end{document}
\ No newline at end of file
--- a/final_main/chapter5/chapter5.tex	Tue Feb 11 17:44:52 2020 +0900
+++ b/final_main/chapter5/chapter5.tex	Tue Feb 11 21:59:14 2020 +0900
@@ -1,5 +1,4 @@
 % 今後の課題
-%\input{/Users/e155753/.tex/setup}

 %%文書開始****************************
 \begin{document}
@@ -8,7 +7,7 @@
 ここではリモートエディタの実装において今後開発, 修正しなければならないことについて解説する.

 \section{既存エディターに対する編集方法}
-ユーザーが自身の好みなエディタを選択し、リモートセッションが行えるためには各種類のエディタのプロトコルをリモートエディタに対応させなければならない. まずはemacs 続いてはvimの実装を予定している. ただし, emacsやvimはバッファの構成がjavaによる自作エディタとは異なり, オフセットによる管理を行なっていないため, 対応させる方法を模索する必要がある.
+ユーザーが自身の好みなエディタを選択し、リモートセッションが行えるためには各種類のエディタのプロトコルをリモートエディタに対応させなければならない. まずはemacs 続いてはvimの実装を予定している. ただし, emacsやvimはバッファの構成がjavaによる自作エディタとは異なり, オフセットによる管理を行なっていないため, 対応させる方法を模索する必要がある.  加えて, emacsにリモートエディタを対応させる際にはemacs-lispを用いる必要があることが予測される. java言語で構成されたChristieからemacsの操作をするまでの処置の方法も模索しなければならない.


 \section{編集するファイルの共有方法}
@@ -21,6 +20,8 @@
  先述したが静的Topologyの構成では参加ノードの数が想定と一致しなければ動作しないという問題点がある.
  作成するリモートエディタは不特定数のユーザの参加を前提としているため, 動的にStar型のTopologyを構成する機能を作成する. また, リモートエディタのセッションでは,セッション開始者とは別にサーバーを立て, そのサーバーに開始者を含めた他のユーザを接続する予定である.

+\section{複数のマシンがセッションに参加した際の動作}
+現在は一つのマシン上にポートを複数立て, 実際の動作を確認している. これを実際に複数のマシンからセッションを参加した際の通信上でどのような問題や利便性の低下が起きるかが確認できていない. また, セッション参加者にも上限が存在することが予測される.

 %%文書終了****************************
 \end{document}
Binary file final_main/fig/FixCommand.graffle has changed
Binary file final_main/fig/FixCommand.pdf has changed
Binary file final_main/main.pdf has changed
--- a/final_main/src/Command.java	Tue Feb 11 17:44:52 2020 +0900
+++ b/final_main/src/Command.java	Tue Feb 11 21:59:14 2020 +0900
@@ -13,7 +13,6 @@

     public Command() {}

-//    delete用
     public Command(int fastOffset, int endOffset, String nodeName){
         this.fastOffset = fastOffset;
         this.endOffset = endOffset;