--- a/final_main/chapter2/chapter2.tex	Wed Feb 12 19:40:35 2020 +0900
+++ b/final_main/chapter2/chapter2.tex	Fri Feb 14 20:11:28 2020 +0900
@@ -9,14 +9,18 @@
 この章ではリモートエディタの実装の上で踏んだプロセスや, 開発の上で問題となる点と解決策について説明する。
 
 \section{document listenerによる編集オフセット番号の読み取り}
-    エディタ同士の基本通信環境の構成のため, Chrisitie と同様のjava 言語で作成したエディタのインスタンスを使い, 異なるマシン同士の同期の実現を目指した. 
+    エディタ同士の基本通信環境の構成のため, Chrisitie と同様にjava 言語で作成したエディタのインスタンスを使い, 異なるマシン同士の同期の実現を目指した. 
 自作エディタは java. swingの機能で構成されており, コードをオフセット番号で取り扱っている. 
 
 追記または削除されたオフセット位置とその内容の取得はDocumentListenrを使用した. 
 DocumentListenerのクラスはswingで実装したエディタ部分の入力と削除を検知し, 動作するメソッドであり, DocumentEvent内に入力されたオフセットとその長さや文字列が入力されるため, それをChrisitie側で検知し処理を行った. 
+
 insertUpdateメソッドではバッファに入力が行われた際に自動的に実行され, removeUpdateメソッドは同様にバッファ内の文字のいずれかが削除が行われた際に実行される. 
 他ノードから送信されてきた命令によるバッファの変更によっても実行され, 意図しないループが発生したため, 受信した命令では実行されないように記述をおこなった. 
+
 コード\ref{code:DocumentListener}はinsertUpdate, removeUpdateの記述部分である. 
+ 
+ \newpage
     
 \lstinputlisting[caption=DocumentListenerのコード部分, label=code:DocumentListener]{./src/DocumentListener.java}
 
@@ -59,8 +63,9 @@
 \end{itemize}
 
 javaのバージョンを下げたのは応急的な処置となってしまったが, これらの処置により問題なくCommandパターンでの命令実装を行うことができた. 
-javaのバージョンに左右されずリモートエディタを実装するには, シリアライズの機能について他のパッケージを使うか, 自信で作成する必要が生まれた。
+javaのバージョンに左右されずリモートエディタを実装するには, シリアライズの機能について他のパッケージを使うか, 自身で作成する必要が生まれた。
 
+\newpage
 
 \section{編集位置の相違}
 セッション中のエディタ間の通信で生じうる, 編集結果の相違について説明する. 
@@ -69,8 +74,9 @@
  例としてエディタが一対一の接続となっている時に発生しうる相違を図\ref{fig:difference} を使用して解説する.
  編集対象は各オフセット番号に同じ値の数字が入っているものとする. 
  EditorA ではオフセット番号 3 の 3 という 要素を削除 (テキストエディタ上のため削除されたオフセットにはその後ろの要素が繰り上げられる.), EditorB では オフセット番号 2 に A という要素を挿入するという編集をしたとする. 
+ 
  この編集を共通プロトコルとして互いに送信しあった際, 本来編集する予定だったオフセットの中身が異なってしまい編集結果に違いが生じてしまう. 
- これらの問題を解決することのできるエディタ同士の通信手法を作成しなければならない。
+ これらの問題を解決することのできるエディタ同士の通信手法を作成しなければならない.
 
 \begin{figure}[H]
 \centering
@@ -92,6 +98,77 @@
 
 が挙げられる. 
 
+そこで, すれ違いが発生したか否かを検知するために、ノード同士が送信し合うコマンドにそれぞれ番号を割り振る方法を考案した.
+図\ref{fig:Fix}を用いて解説する.
+
+以下の図はコマンド番号を実装し, すれ違いを検知する際の動作の想定図である.
+また, 本説明のコマンドは文字列の書き込み命令であり, バッファの指定されたオフセットにinsertされるため, それ以降のオフセット内の文字列は, 一つずつ後方オフセットへ移動する.
+
+命令コマンドはクラスのインスタンスを用いて作られており, 中には1オフセット分(文字数分)の文字列, 入力するオフセット, コマンド番号, コマンドを発行したノード名が記録されている. 
+
+二つのノードserver とnode は同じファイルのバッファを開いており, そのバッファには何も記述されていないとする.
+また, serverが送信するコマンドは他のノードから送られてきたコマンドであるとする.
+加えて各サーバー, ノードは実行したコマンドをスタック領域に保持しておいている.
+
+コマンドとコマンド番号について以下の特性が存在する.
+\begin{itemize}
+\item 各ノードは最後に実行した数値を変数(図ではserverがcNum, nodeがnodeCNum) に保持している.
+\item いずれかのノードがコマンドを発行したら, そのコマンドのコマンド番号は前に実行したコマンドの番号+1となる. そしてそれは送信されてきたコマンドか自分が発行したコマンドであるかは問わない.
+\item 送信されてきたコマンドのコマンド番号が自身が保持しているコマンド番号+1でなければ、自身が先に発進したコマンドとすれ違いが発生していることが判明できる. (保持コマンド番号より同値以下の場合)
+\end{itemize}
+
+\newpage
+
+つまり, 送信されたコマンドNo.102を実行したらそれぞれのノードは実行済みコマンド番号を102へ書き換えなければならない.
+そして続いて自らがバッファに変更を加えたとき, その変更をコマンドNo103として作成し, 送信と実行済みコマンド番号を103に書き換える処理が必要となる.
+
+以上の処理でコマンド送信のすれ違いを検知する.
+
+\begin{figure}[H]
+\centering
+  \fbox{
+   \includegraphics[scale=0.85]{./fig/FixCommand.pdf}
+  }
+\caption{コマンド番号を利用した相違の解消}
+\label{fig:Fix}
+\end{figure}
+
+\newpage
+
+コマンドのすれ違いを検知した際の処理は以下のように行う.
+\begin{itemize}
+\item 前提としてノードよりサーバーの整合性を維持したいため優先度は常にサーバーが高い.例えば同じオフセットにそれぞれのノードが別の文字列に変更した場合, サーバーノード共にサーバー側が発進したコマンドの文字列が書き込まれる.
+\item すれ違いが発生したら, 各ノードはコマンドを記録しているスタックを参照し, 受け取ったコマンドのオフセットのズレを集計しそのコマンドを修正する.
+\end{itemize}
+
+図上ではserverからのinsert B for offset:2 とnodeからのinsert Z for offset:2の命令がすれ違いを起こしている. 
+この場合, serverのバッファ状態が優先されるため, server側がnodeからの命令のoffset位置を調整してやらなければならない. 
+この処理はserverと全ての接続しているノード間で独立して行われる.
+
+コマンドのオフセットの修正は
+\begin{itemize}
+\item 受け取ったコマンドのオフセット ＞ 受信コマンドとすれ違ったコマンドのオフセット のとき, 受診したコマンドのオフセットに+1する. 
+\item 受け取ったコマンドのオフセット ＜ 受信コマンドとすれ違ったコマンドのオフセット のとき, 受診したコマンドのオフセットを変えずにそのまま実行できる. 
+\item 受け取ったコマンドのオフセット = 受信コマンドとすれ違ったコマンドのオフセット のとき, サーバー側の文字列が優先される. 
+\end{itemize}
+と言った方法で行うことができる.
+これを削除, 文字列の置き換えにもそれぞれ対応する方法を作ることによりズレの修正を行う.
+
+しかし, テストコードを書き上げる中でこの方法でも網羅できていない問題点や実装上の問題がみられた.
+\begin{itemize}
+\item 既存のエディタ(emacsやvim)のバッファ処理はオフセット単位で行われていない.
+\item コマンドのput(送信)失敗についての想定ができていない.
+\item 現在のChristieでは リスト型や Stack型がputできない.
+\item コマンドを保持し続けるとメモリ容量に無駄が発生する.
+\end{itemize}
+と言った問題点が露見した. 
+これらの問題についての対応方法を模索する必要がある.
+また実装した際に初めて判明する通信速度や複数の独立した処理による影響も対処しなければならない可能性がある.
+. 
+
+
+
+
 
 
 %%文書終了****************************