Mercurial > hg > Papers > 2020 > itsuki-thesis

changeset 4:c1732eac57f6

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
add some section
author ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date Fri, 07 Feb 2020 21:12:05 +0900
parents 284d030d3a85
children 169e4ee0d1a4
files final_main/.DS_Store final_main/chapter1/chapter1.aux final_main/chapter1/chapter1.log final_main/chapter1/chapter1.tex final_main/chapter2/.DS_Store final_main/chapter2/chapter2.aux final_main/chapter2/chapter2.log final_main/chapter2/chapter2.tex final_main/chapter3/chapter3.tex final_main/chapter4/chapter4.tex final_main/chapter5/chapter5.tex final_main/main.aux final_main/main.dvi final_main/main.lof final_main/main.log final_main/main.lol final_main/main.pdf final_main/main.tex final_main/main.toc final_main/src/.DS_Store final_main/src/Command.java final_main/src/DocumentListener.java final_main/src/HelloWorld/.DS_Store final_main/src/HelloWorld/FinishHelloWorld.java final_main/src/HelloWorld/HelloWorldCodeGear.java final_main/src/HelloWorld/StartHelloWorld.java
diffstat 24 files changed, 267 insertions(+), 589 deletions(-) [+]
line wrap: on
line diff
Binary file final_main/.DS_Store has changed
--- a/final_main/chapter1/chapter1.tex	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/chapter1/chapter1.tex	Fri Feb 07 21:12:05 2020 +0900
@@ -9,11 +9,11 @@
 
 % 序論の目安としては1枚半ぐらい．
 
-コンピュータにおいてデータの破損や不整合は深刻な異常を引き起こす原因となる. そのため, 破損, 不整合を検知するためにブロックチェーン技術を用いたい.  ブロックチェーンは分散ネットワーク技術であり, データの破損や不整合をハッシュ値によって比較できる. そして, 誤操作や改ざんがあった場合でも, ブロックチェーンを用いることでデータの追跡が行える. 
+複数人がリアルタイムにファイルの操作を行うことができるリモートエディタには, 既存の物としてVisual Studio Codeのremote session がある. しかし, 編集のセッションに参加するユーザ全員がVSCodeを使うことになり, またVSCodeの環境を導入する必要がある.
 
-当研究室では分散フレームワークとしてChristieを開発しており, これはGearsOSにファイルシステムとして組み込む予定がある. そのため, Christieにブロックチェーンを実装し, GearsOSに組み込むことにより, GearsOSのファイルシステムにおいてデータの破損, 不整合を検知できる. また, GearsOS同士による分散ファイルシステムを構成することができ, 非中央的にデータの分散ができるようになる. もし分散システムを構成しない場合でもデータの整合性保持は行え, 上記の目的は達成できる.
+そこで,セッションに参加するユーザー全員が各々好きなエディタを使用することができるリモートエディタアプリケーションを買いはすることにした. アプリケーションの形に作成することにより, 手軽に同時編集が行えるようにしたい. 先行研究 [1] ではネットワークをリング型で構成しトー クンを巡回させていたが, ノードごとの整合性の確立が難しい, ネットワーク全体の障害に対する脆弱性の弱さといっ た問題点が見られた. これらの反省点を踏まえ本研究では スター型ネットワークを用いることで remote editor の障害 耐性を高める. また新しく, 本研究室で開発している分散フレームワークChristieを使用することにより簡潔な実装と, Christie自体の性能と信頼性の向上を目指す. 
 
-本研究では, Christieにブロックチェーンを実装し, 実際に学科のPCクラスタ上の分散環境で動かす.
+
 
 
 
Binary file final_main/chapter2/.DS_Store has changed
--- a/final_main/chapter2/chapter2.aux	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/chapter2/chapter2.aux	Fri Feb 07 21:12:05 2020 +0900
@@ -1,1 +0,0 @@
-\relax 
--- a/final_main/chapter2/chapter2.log	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/chapter2/chapter2.log	Fri Feb 07 21:12:05 2020 +0900
@@ -1,59 +0,0 @@
-This is e-pTeX, Version 3.14159265-p3.6-141210-2.6 (utf8.euc) (TeX Live 2015) (preloaded format=platex 2016.4.7)  7 MAY 2019 21:01
-entering extended mode
- restricted \write18 enabled.
- file:line:error style messages enabled.
- %&-line parsing enabled.
-**chapter2
-(./chapter2.tex
-pLaTeX2e <2006/11/10> (based on LaTeX2e <2015/01/01> patch level 0)
-Babel <3.9l> and hyphenation patterns for 79 languages loaded.
-No file chapter2.aux.
-\openout1 = `chapter2.aux'.
-
-LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for JY1/mc/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-LaTeX Font Info:    Checking defaults for JT1/mc/m/n on input line 4.
-LaTeX Font Info:    ... okay on input line 4.
-
-./chapter2.tex:4: LaTeX Error: The font size command \normalsize is not defined
-:
-               there is probably something wrong with the class file.
-
-See the LaTeX manual or LaTeX Companion for explanation.
-Type  H <return>  for immediate help.
- ...                                              
-                                                  
-l.4 \begin{document}
-                    
-? 
-./chapter2.tex:4: Emergency stop.
- ...                                              
-                                                  
-l.4 \begin{document}
-                    
-Your command was ignored.
-Type  I <command> <return>  to replace it with another command,
-or  <return>  to continue without it.
-
- 
-Here is how much of TeX's memory you used:
- 5 strings out of 493777
- 273 string characters out of 6151335
- 53434 words of memory out of 5000000
- 3593 multiletter control sequences out of 15000+600000
- 7519 words of font info for 31 fonts, out of 8000000 for 9000
- 929 hyphenation exceptions out of 8191
- 9i,0n,6p,49b,28s stack positions out of 5000i,500n,10000p,200000b,80000s
-No pages of output.
--- a/final_main/chapter2/chapter2.tex	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/chapter2/chapter2.tex	Fri Feb 07 21:12:05 2020 +0900
@@ -3,64 +3,57 @@
 %%文書開始****************************
 \begin{document} 
 %%**************************************
-\chapter{ブロックチェーンについて}
-
-ブロックチェーンとは分散型台帳技術とも呼ばれ, 複数のトランザクションをまとめたブロック, そのブロックをハッシュによって繋げ, 前後関係を表した台帳というものを, システムに参加している複数のノードが保持する技術である. ブロックチェーンにはパブリック型とコンソーシアム型の2種類がある. パブリック型は不特定多数のノードを対象にしており, コンソーシアム型は管理者が許可したノードが参加している.
-
-\section{P2P}
-ブロックチェーンのネットワーク間はP2Pで動く. つまり, ブロックチェーンネットワークはサーバー, クライアントの区別がなく, すべてのノードが平等である. そのため, 非中央的にデータの管理を行う. 
+\chapter{分散フレームワークChrisiteについて}
+ここでは本研究室で開発している分散フレームワークChrisiteについて解説する. Chrisiteは複雑な分散プログラムを簡潔に書くことのできる構成となっている. 
 
 
-\section{ブロックとその構造}
-ブロックチェーンにおけるブロックは, 複数のトランザクションをまとめたものである. ブロックの構造は使用するコンセンサスアルゴリズムによって変わるが, 基本的な構造としては次のとおりである.
+\section{Chrisiteとは}
+ChristieはJava言語で構成された本研究室独自の分散フレームワークである。同じく本研究室で開発を行っているGearsOSのファイルシステムに組み込む予定があるため, GearsOSを構成している本研究室の独自の言語Continuation based C (以下CbC言語)とにた, Gearというプログラム概念が存在する.
 
 \begin{itemize}
-\item BlockHeader
-\begin{itemize}
-\item previous block hash
-\item merkle root hash
-\item time
-\end{itemize}
-\item TransactionList
+\item CodeGear(以下 CG)
+\item DataGear(以下 DG)
+\item CodeGearManager(以下 CGM)
+\item DataGearManager(以下 DGM)
 \end{itemize}
 
-BlockHeaderには, 前のブロックをハッシュ化したもの, トランザクションをまとめたmerkle treeのrootのhash, このブロックを生成したtimeとなっている.
+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と似ているが, Remote DGM nameを指定することで, その接続先(Remote)のDGMからTake操作を行える.
+\item[PeekFrom(Remote DGM name)] Peekと似ているが, Remote DGM nameを指定することで, その接続先(Remote)のDGMからPeek操作を行える.
+\end{description}
+
+\section{プログラムの例}
+以下のソースコード\ref{code:nStartHelloWorld} , \ref{code:HelloWorldCodeGear}のプログラムはChrisitieの基本動作となる DGM による put 操作を用いた hello world の出力プログラムである.  メソッド setCGM でポート番号を指定した上で CGM を作成しする. HelloWorldCodeGear() クラスには String型の"helloWorld" という key が用意され,  "helloWorld"に入力された DG をprint するコードである.  "helloWorld" に hello と worldというDGをputすることで出力結果がhello world となる. CGM が起動していると処理が終了しないため, FinishHelloWorld には DG が揃い次第 cgm.getLocalDGM().finish(); というメソッドを実行させcgmを終了させる処理が書かれている。
+\lstinputlisting[caption=StartHelloWorld,label=code:nStartHelloWorld]{./src/HelloWorld/StartHelloWorld.java}
 
-previous block hashは, 前のブロックのパラメータを並べて, hash化したものである. それが連なっていることで, 図\ref{fig:chain}のようなhash chainとして, ブロックがつながっている.
+\lstinputlisting[caption=HelloWorldCodeGear,label=code:HelloWorldCodeGear]{./src/HelloWorld/HelloWorldCodeGear.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=0.5]{./images/chain.pdf}
+   \includegraphics[scale=1]{./images/ring.pdf}
   }
-\caption{hash chain}
-\label{fig:chain}
+\caption{ソースコード \ref{code:dotFile} のdotファイルを図示化したもの}
+\label{fig:dot}
 \end{figure}
 
-そのため, 一つのブロックが変更されれば, その後に連なっているブロックをすべて変更しなければいけなくなる.
-
-ブロックが生成された場合, 知っているノードにそのブロックをブロードキャストする. 実際には通信量を抑えるためにブロック高を送った後にブロックをシリアライズして送る場合もある.
-
-
-ノードごとにブロックを検証し, 誤りがあればそのブロックを破棄し, 誤りがなければ更にそのノードがブロックをブロードキャストする. . そして, Transaction PoolというTransactionを貯めておく場所から, そのブロックに含まれているTransactionを削除し, 新しいブロックを生成する. 
-
-
-
-\section{トランザクションとその構造}
-トランザクションとはデータのやり取りを行った記録の最小単位である. トランザクションの構造は次のとおりである.
-\begin{description}
-\item[TransactionHash] トランザクションをハッシュ化したもの.
-\item[data] データ.
-\item[sendAddress] 送り元のアカウントのアドレス.
-\item[recieveAddress] 送り先のアカウントのアドレス.
-\item[signature] トランザクションの一部と秘密鍵をSHA256でハッシュ化したもの.  ECDSAで署名している.
-\end{description}
-
-トランザクションはノード間で伝搬され, ノードごとに検証される. そして検証を終え, 不正なトランザクションであればそのトランザクションを破棄し, 検証に通った場合はTransaction Poolに取り組まれ, また検証したノードからトランザクションがブロードキャストされる.
-
-\section{fork}
-
-ブロックの生成をしたあとにブロードキャストをすると, ブロック高の同じ, もしくは相手のブロック高のほうが高いブロックチェーンにたどり着く場合がある. もちろん, 相手のブロックチェーンはそのブロックを破棄する. しかしこの場合, 異なるブロックを持った2つのブロックチェーンができる. この状態をforkという. fork状態になると, 2つの異なるブロックチェーンができることになるため, 1つにまとめなければならない. 1つにまとめるためにコンセンサスアルゴリズムを使うが, コンセンサスアルゴリズムについては次章で説明する.
+動的Topologyは動的 Topology は参加を表明したノードに対し, 動的にノード同士の関係を作る. 例えば Tree を構成する場合, 参加を表明したノードから順に, root に近い位置の役割を与える. また, CodeGear はノードが参加し, parent に接続したあとに実行される.
 
 
 
--- a/final_main/chapter3/chapter3.tex	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/chapter3/chapter3.tex	Fri Feb 07 21:12:05 2020 +0900
@@ -3,175 +3,48 @@
 %%文書開始****************************
 \begin{document} 
 %%**************************************
-\chapter{コンセンサスアルゴリズム}
-
-ブロックチェーンでは, パブリックブロックチェーンの場合とコンソーシアムブロックチェーンによってコンセンサスアルゴリズムが変わる. この章ではパブリックブロックチェーンのBitcoin, Ethereumに使われているProof of Workについて説明し, コンソーシアムブロックチェーンに使えるPaxosを説明する.
-
-\section{Proof of Workを用いたコンセンサス}
-パブリックブロックチェーンとは, 不特定多数のノードが参加するブロックチェーンシステムのことを指す. よって, 不特定多数のノード間, 全体のノードの参加数が変わる状況でコンセンサスが取れるアルゴリズムを使用しなければならない. 
-Proof of Workは不特定多数のノードを対象としてコンセンサスが取れる. ノードの計算量によってコンセンサスを取るからである. 次のような問題があっても, Proof of Workはコンセンサスを取ることができる.
-
-\begin{enumerate}
-\item プロセス毎に処理の速度が違う. つまり, メッセージの返信が遅い可能性がある
-\item 通信にどれだけの時間がかかるかわからず, その途中でメッセージが失われる可能性がある, 
-\item プロセスは停止する可能性がある. また, 復旧する可能性もある.
-\item 悪意ある情報を他のノードが送信する可能性がある.
-\end{enumerate}
-
+\chapter{リモートエディタ}
+リモートエディタは共通プロトコルが対応するエディタが保持するバッファを開いて編集することができる. ネット ワーク上の一つのバッファが編集されると他のバッファにも 変更が反映され, お互いのバッファを編集し合うことができる. 
+この章ではリモートエディタの実装の上で踏んだプロセスや, 開発の上で問題となる点と解決策について説明する。
 
-Proof of Workに必要なパラメータは次のとおりである.
-
-\begin{itemize}
-\item nonce
-\item difficulty
-\end{itemize}
-
-nonceはブロックのパラメータに含まれる. difficultyはProof of Workの難しさ, 正確に言えば1つのブロックを生成する時間を調整している.
-
-Proof of Workはこれらのパラメータを使って次のようにブロックを作る.
-
-\begin{enumerate}
-\item ブロックとnonceを加えたものをハッシュ化する. この際, nonceによって, ブロックのハッシュは全く違うものになる.
-\item ハッシュ化したブロックの先頭から数えた0ビットの数がdifficultyより多ければ, そのブロックにnonceを埋め込み, ブロックを作る. 
-\item 2の条件に当てはまらなかった場合はnonceに1を足して, 1からやり直す.
-\end{enumerate}
-difficulty = 2でProof of Workの手順を図にしたものを図\ref{fig:proof-of-work}に示す. 
+\section{編集位置の相違}
 
-\begin{figure}[H]
-\centering
-  \fbox{
-   \includegraphics[scale=0.5]{./images/proof-of-work.pdf}
-  }
-\caption{proof-of-workの例}
-\label{fig:proof-of-work}
-\end{figure}
-
-
-2の条件については, 単純に$(桁数 - difficulty + 1) \times 10 > hash$とも置き換えることができる. 
-
-nonceを変えていくことで, hashはほぼ乱数のような状態になる. つまり, difficultyを増やすほど, 条件に当てはまるhashが少なくなっていくことがわかり, そのhashを探すための計算量も増えることがわかる. 
-
-これらがProof of Workでブロックを生成する手順である. これを用いることによって, ブロックが長くなればなるほど, すでに作られたブロックを変更することは計算量が膨大になるため, 不可能になっていく. 
-
-Proof of Workでノード間のコンセンサスを取る方法は単純で, ブロックの長さの差が一定以上になった場合, 最も長かったブロックを正しいものとする. これを図で表すと, 図\ref{fig:proof-of-work-fork}のようになる. 
+\section{編集位置の相違解消方法}
 
-\begin{figure}[H]
-\centering
-  \fbox{
-   \includegraphics[scale=0.5]{./images/proof-of-work-fork}
-  }
-\caption{Proof of Workでのコンセンサス}
-\label{fig:proof-of-work-fork}
-\end{figure}
-
-計算量の差が51\%以上になると, forkしたブロック同士で差が生まれる. それによって, IPアドレスでのコンセンサスではなく, CPUの性能によるコンセンサスを取ることができる.
-
-コンセンサスでは, ブロックの差が大きければ大きいほど, コンセンサスが正確に取れる. しかし, 正しいチェーンが決まるのに時間がかかる. そのため, コンセンサスに必要なブロックの差はコンセンサスの正確性と時間のトレードオフになっている. 
-
-この方法でコンセンサスを取る場合の欠点を挙げる.
-\begin{itemize}
-\item CPUのリソースを使用する. 
-\item Transactionが確定するのに時間がかかる. 
-\end{itemize}
+\section{document listenerによる編集オフセット番号の読み取り}
+    エディタ同士の基本通信環境の構成のため, Chrisitie と同様のjava 言語で作成したエディタのインスタンスを使い, 異なるマシン同士の同期の実現を目指した.  自作エディタは java. swingの機能で構成されており, 追記または削除されたオフセット位置とその内容の取得はDocumentListenrを使用した. DocumentListenerのクラスはswingで実装したエディタ部分の入力と削除を検知し, 動作するメソッドであり, DocumentEvent内に入力されたオフセットとその長さや文字列が入力されるため, それをChrisitie側で検知し処理を行った.  
+    
+\lstinputlisting[caption=DocumentListenerのコード部分, label=code:DocumentListener]{./src/DocumentListener.java}
 
 
-\section{Paxos}
-
-コンソーシアムブロックチェーンは許可したノードのみが参加できるブロックチェーンである. そのため, ノードの数も把握できるため, Paxosを使うことができる. Paxosはノードの多数決によってコンセンサスを取るアルゴリズムである. ただし, Paxosは次のような問題があっても値を一意に決めることができる.
-
-\begin{enumerate}
-\item プロセス毎に処理の速度が違う. つまり, メッセージの返信が遅い可能性がある
-\item 通信にどれだけの時間がかかるかわからず, その途中でメッセージが失われる可能性がある, 
-\item プロセスは停止する可能性がある. また, 復旧する可能性もある.
-\end{enumerate}
-
-Proof of Workにある特性の4がないが, コンソーシアムブロックチェーンは3つの問題を解決するだけで十分である. なぜならば, コンソーシアムブロックチェーンは許可したノードのみが参加可能だからである. つまり, 悪意あるノードが参加する可能性が少ないためだ. 
-
-Paxosは3つの役割のノードがある.
-
-\begin{description}
-\item[proposer] 値を提案するノード.
-\item[acceptor] 値を決めるノード.
-\item[learner] acceptorから値を集計し, 過半数以上のacceptorが持っている値を決める.
-\end{description}
-
-Paxosのアルゴリズムに入る前に, 定義された用語を説明する. 以下にその用語の定義を示す.\begin{description}
-\item[提案] 提案は, 異なる提案ごとにユニークな提案番号と値からなる. 提案番号とは, 異なる提案を見分けるための識別子であり, 単調増加する. 値は一意に決まってほしいデータである.
-\item[値(提案)がacceptされる] acceptorによって値(提案)が決まること. 
-\item[値(提案)が選択(chosen)される] 過半数以上のacceptorによって, 値(提案)がacceptされた場合, それを値(提案)が選択されたと言う.
-\end{description}
-
-
-Paxosのアルゴリズムは2フェーズある. 
-
-1つ目のフェーズ, prepare-promiseは次のような手順で動作する. 
-\begin{enumerate}
-\item proposerは提案番号nを設定した提案を過半数以上のacceptorに送る. これをprepareリクエストという. 
-\item acceptorはprepareリクエストが来たら次の動作をする. 
-\begin{enumerate}
-\item もし, 以前に送られたprepareリクエストの提案番号より, 今送られてきたprepareリクエストの提案番号のほうが大きければ, それ以下の提案番号の提案を拒否するという約束を返す. この状態をPromiseしたという.
-\item もし, 値がすでにacceptされていれば, accpetされた提案を返す. 
-\end{enumerate}
-
-\end{enumerate}
-
-1フェーズ目を図にしたものを図\ref{fig:prepare-promise}に示す.
+\section{Command パターンによる命令オブジェクトの作成}
+リモートエディタを実装する上において, 各エディタは自身に起きたバッファの変更を対応した他ノードに送信する必要がある. この変更の送り合いをCommand パターンとして実装した. Command パターンとは, 命令を一つのオブジェクトとして表現する方法である. コマンドパターンの利点として,
+\begin{itemize}
+\item インスタンスを利用して命令を作成するため, ChristieのGearの概念と相性が良い. 
+\item 命令に必要な内容をまとめて送信するため, 相違の発生を防ぐことができる. 
+\item 命令の管理が行いやすい, 行列に並ばせ命令の順番を管理したり, 命令の際実行, 取り消しが容易になる. 
+\end{itemize}
+といった点が挙げられる. ソースコード:\ref{code:Command}は書き込み, 送信を行う際の命令をクラスとして作成したものである. このクラスのインスタンスを命令オブジェクトとして送信し合う. 
 
-\begin{figure}[H]
-\centering
-  \fbox{
-   \includegraphics[scale=0.5]{./images/prepare-promise.pdf}
-  }
-\caption{prepare-promise}
-\label{fig:prepare-promise}
-\end{figure}
-
-
-2つ目のフェーズ, accept-acceptedは次のような手順で動作する. 
-\begin{enumerate}
-\item proposerは過半数のacceptorから返信が来たならば, 次の提案をacceptorに送る. これをacceptリクエストという.
-\begin{enumerate}
-\item もし, 約束のみが返ってきているならば, 任意の値vをprepareリクエストで送った提案に設定する.
-\item もし, acceptされた提案が返ってきたら, その中で最大の提案番号を持つ提案の値v'をprepareリクエストで送った提案の値として設定する.
-\end{enumerate}
-
-\item acceptorはacceptリクエストが来た場合, Promiseした提案よりもacceptリクエストで提案された提案番号が低ければ, その提案を拒否する. それ以外の場合はacceptする.
-\end{enumerate}
+\lstinputlisting[caption=Commandパターンとして実装した命令, label=code:Command]{./src/Command.java}
 
-2フェーズ目を図にしたものを図\ref{fig:accept-accepted}に示す.
-
-\begin{figure}[H]
-\centering
-  \fbox{
-   \includegraphics[scale=0.5]{./images/accept-accepted.pdf}
-  }
-\caption{accept-accepted}
-\label{fig:accept-accepted}
-\end{figure}
-
-
-このアルゴリズムによって, 各accptorごとに値が一意に決まる. 値を集計, 選択するのはLearnerの役割である. Learnerが値を集計する方法には2つの方法がある.
-
-\begin{enumerate}
-\item Acceptorによって値がacceptされた時に, 各Learnerに送信される. ただし, Message通信量が, $Acceptorの数 \times Learnerの数$になる.
-\item 1つのLearnerが各Learnerに選択された値を送信する. 1の方法に比べてMessage通信量が少なくなる($Acceptorの数 + Learnerの数$になる)代わりに, そのLearnerが故障した場合は各LearnerがMessageを受け取れない.
-\end{enumerate}
-
-2つの方法はメッセージ通信量と耐障害性のトレードオフになっていることがわかる.
-
-Paxosでコンセンサスを取ることは, Proof of Workと比較して次のようなメリットがある.
+\section{命令オブジェクトを実装する際に起きた問題}
+インスタンス化した命令を他ノードに送信する際にエラーが発生し, 送信に失敗してしまうという問題が発生した. クラスの送信の際のシリアライズはmsgpackクラスを利用していた. 原因を調査した結果, 以下の原因が見つかった.
 
 \begin{itemize}
-\item CPUのリソースを消費しない
-\item Transactionの確定に時間がかからない.
+\item Christieのjavaバージョンは11を使用していたが, msgpackバージョン0.6.12はjava11に対して対応していなかった.
+\item msgpackの最新版0.8.20はシリアライズ機能が含まれなくなった.
 \end{itemize}
 
-\section{Paxosによるブロックチェーン}
+以上の原因に対処するために以下のことを行った.
 
-PaxosはProof of Workに比べ, CPUのリソースを消費せず, Transactionの確定に時間がかからない. そのため, Paxosでブロックのコンセンサスを取るブロックチェーンを実装することにはメリットが有る.
-また, Paxos自体がリーダー選出に向いているアルゴリズムである. そのため, リーダーを決め, そのノードのブロックチェーンの一貫性のみを考えることもできる.
+\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 04 17:40:50 2020 +0900
+++ b/final_main/chapter4/chapter4.tex	Fri Feb 07 21:12:05 2020 +0900
@@ -3,134 +3,21 @@
 %%文書開始****************************
 \begin{document} 
 %%**************************************
-\chapter{Christieについて}
-
-Christieは当研究室で開発している分散フレームワークである. Christieには分散プログラムを簡潔に書くための工夫が複数ある.
-本章ではChristieについて述べる.
-\section{Christieとは}
-ChristieはJavaで書かれた分散フレームワークである. Christieは当研究室で開発している GearsOSに組み込まれる予定がある. そのため, GearsOS を構成する言語 Continuation based C と似た概念がある. Christie に存在する概念として次のようなものがある.
-
+\chapter{スター型接続によるネットワーク通信}
+リモートエディタのセッションに参加するノード(ユーザ)はスター型で接続を行う. スター型とは中心となるノードから放射状に他のノードにそれぞれ一対一の接続を行う接続である. 
+先行研究においてはノードの通信をリング型, つまりノード同士を円となる形で接続することで実装を試みたが, 
 \begin{itemize}
-\item CodeGear(以下 CG)
-\item DataGear(以下 DG)
-\item CodeGearManager(以下 CGM)
-\item DataGearManager(以下 DGM)
-\end{itemize}
-
-CGはクラス, スレッドに相当し, javaの継承を用いて記述する. DGは変数データに相当し, CG内でアノテーションを用いて変数データを取り出せる. CGM はノードであり, DGM, CG, DG を管理する. DGM は 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と似ているが, Remote DGM nameを指定することで, その接続先(Remote)のDGMからTake操作を行える.
-\item[PeekFrom(Remote DGM name)] Peekと似ているが, Remote DGM nameを指定することで, その接続先(Remote)のDGMからPeek操作を行える.
-\end{description}
-
-以上が, Christieの概要である.
-
-\section{プログラミングの例}
-ここでは, Christieで実際にプログラムを記述する例を述べる.
-CGMを作り, setup(new CodeGear)を動かすことにより, DGを待ち合わせ, DGが揃った場合にCodeGearが実行される. CGMを作る方法はStartCodeGear(以下SCG)を継承したものからcreateCGM(port) methodを実行することにより, CGMが作られる. SCGのコードの例をソースコード\ref{code:StartHelloWorld}に示す.
-
-\lstinputlisting[caption=StartHelloWorld,label=code:StartHelloWorld]{./src/HelloWorld/StartHelloWorld.java}
-
-
-\section{TopologyManagerの実装}
-Christieは当研究室で開発されたAliceを改良した分散フレームワークである. しかしAliceの機能を全て移行したわけではない. TopologyManagerは最たる例であり, 分散プログラムを簡潔に書くために必要である. そのため, ChristieにTopologyManagerを実装した.
-
-ここでは, TopologyManagerとはどのようなものかを述べる. そして, TopologyManagerを実装する際に, Christie自身のコードを変更する必要があったため, TopologyManagerでどのような問題が起こり, Christieの基本機能をどのような変更したかも述べる.
-
-TopologyManagerとは, Topologyを形成するため, 参加を表明したノード, TopologyNodeに名前を与え, 必要があればノード同士の配線も行うノードである. TopologyManagerのTopology形成方法として, 静的Topologyと動的Topologyがある. 静的Topologyはソースコード\ref{code:dot-example}のようなdotファイルを与えることで, ノードの関係を図\ref{fig:dot-example}のようにさせる. 静的Topologyはdotファイルのノード数と同等のTopologyNodeがあって初めて, CodeGearが実行される. 
-
-\lstinputlisting[caption=ring.dot,label=code:dot-example]{./src/ring.dot}
-
-\begin{figure}[H]
-\centering
-  \fbox{
-   \includegraphics[scale=1]{./images/ring.pdf}
-  }
-\caption{ソースコード\ref{code:dot-example}, ring.dotを図にしたもの}
-\label{fig:dot-example}
-\end{figure}
-
-
-
-動的Topologyは参加を表明したノードに対し, 動的にノード同士の関係を作る. 例えばTreeを構成する場合, 参加を表明したノードから順に, rootに近い位置の役割を与える. また, CodeGearはノードが参加し, parentに接続したあとに実行される.
-
-TopologyManagerを実装するに当たって, 以下の2つの問題点が出た.
-
-\begin{itemize}
-\item Take, Peek操作でSuperClassの型を持ったデータを取り出す際にNullPointerExceptionが表示される.
-\item ノード間で繋がる前にput操作を行うとデータが送られない.
+\item ノードごとのもつファイルの整合性の維持が難しい. 
+\item どこかのノード同士の通信が切断された際の再接続が難しく, また障害が全体に影響してしまう. 
+\item 障害からの復帰が難しい.
 \end{itemize}
-
-Take, Peek操作でSuperClassの型を持ったデータを取り出す際にNullPointerExceptionが表示される問題に対しては, DataGearでdataを代入する際にSuperClass, interfacesまで比較するように書き換えた. また, 型の不一致が起こった際は例外を投げるようにした. その修正後のコードをソースコード\ref{code:datagear}に示す. 
-
-\begin{lstlisting}[caption=修正後のDataGearのソースコード,label=code:datagear]
-public class DataGear<T>{
-   
-    ...
-   
-    public void setData(T data) {
-        Class dataClazz = data.getClass();
-
-        if(dataClazz == this.clazz){
-            this.data = data; return;
-        }
-
-        Class dataSuperClazz = dataClazz.getSuperclass();
-        while (dataSuperClazz != null) {
-            if(dataSuperClazz == this.clazz) {
-                this.data = data; return;
-            }
-            dataSuperClazz = dataSuperClazz.getSuperclass();
-        }
-
-        Class<?>[] interfaces = dataClazz.getInterfaces();
-        for (Class<?> interfaze : interfaces) {
-            if(interfaze == this.clazz) {
-                this.data = data; return;
-            }
-        }
-
-        throw new ClassCastException("datagear cannot set class from " + dataClazz.getName() + " to " + clazz.getName());
-
-    }
-
-}
-\end{lstlisting}
-
-setDataメソッドの中身を変更した. TopologyNodeにおいて, 実行するCodeGearをputしておき, 参加するノードがすべて揃ったら, そのCodeGearを実行する. しかし, 実際には実行するCodeGearはCodeGearを継承したものである. Christieは, putされたdataのクラスとTakeされるデータのクラスが一致したならばdataを代入し, それ以外なら無視するという処理を行っていた. SuperClass, interfacesの型までは比較をしていなかっため, 型の不一致が起こり, dataの代入をしないため, NullPointerExceptionが表示されていた. 
-
-
-ノード間で繋がる前にput操作を行うとデータが送られない問題に対しては, waitを付け加えた. そのコードをソースコード\ref{code:rdgm}に示す. 
-
-\lstinputlisting[caption=修正後のRemoteDataGearManagerのソースコード,label=code:rdgm]{./src/RemoteDataGearManager.java}
-
-具体的にはソースコード\ref{code:rdgm}の17行目から21行目にlockを付け加え, putメソッドの48行目にwaitするメソッドを置き, 54行目から63行目にwaitするメソッドを付け加えた. この問題は, ノードが繋がる前にconnection.writeを行うため, 相手のDataGearに書き込みが行われないために起きた. そのため, 相手とDataGearがつながるまでputメソッドをwaitしておき, つながってからconnection.write操作を行うように書き換えた.
-
-\section{Christieにおけるブロックチェーンの実装の利点と欠点}
-
-Christieにおいてブロック, トランザクション, Paxos, Proof of Workを実装した. 
-その際, Christieで実装した場合の便利な点を述べる.
-
+などの問題が見られた. リング型と比較した際のスター型の利点として, 
 \begin{itemize}
-\item データの取り出しが簡単. ChristieはDataGearという単位でデータを保持する. そのため, ブロックやトランザクションはDataGearに包めばいいため, どう送るかという問題を考えなくてすむ. 
-\item TopologyManagerでのテストが便利. dotファイルが有れば, TopologyManagerが任意の形でTopologyを作れる. そのため, ノードの配置については理想の環境を作れるため, 理想のテスト環境を作ることができる. 
-\item 機能ごとにファイルが実装できるため, 見通しが良い. ChristieはCbCのgotoと同じように関数が終わるとsetupによって別の関数に移動する. そのため自然に機能ごとにファイルを作るため, 見通しが良くなる.
+\item ノードの中心(サーバー)が正しいファイル状況を保持するため,整合性を保つことが容易である.
+\item どこかのノードの接続が切断されても, 障害の範囲をそのノードのみに抑えることができる.
+\item 新しいノードが参加した, もしくはノードの再接続の際にはサーバーのファイル状況を参照するのみで参加, 復帰ができる.
 \end{itemize}
-
-不便な点を以下に述べる.
-
-\begin{itemize}
-\item デバッグが難しい. cgm.setupでCodeGearが実行されるが, keyの待ち合わせで止まり, どこのCGで止まっているかわからないことが多かった. 例えば, putするkeyのスペルミスでコードの待ち合わせが起こり, CGが実行されず, エラーなども表示されずにwaitすることがある. その時に, どこで止まっているか特定するのが難しい.
-\item TakeFrom, PeekFromの使い方が難しい. TakeFrom, PeekFromは引数でDGM nameを指定する. しかし, DGMの名前を静的に与えるよりも, 動的に与えたい場合が多かった.
-\item Takeの待ち合わせでCGが実行されない. 2つのCGで同じ変数をTakeしようとすると, setupされた時点で変数がロックされる. このとき, 片方のCGはDGがすべて揃っているのに, すべての変数が揃っていないもう片方のCGに同名の変数がロックされ, 実行されない場合がある. 
-\end{itemize}
-
-
-
+と言ったことが挙げられる.
 
 \newpage
 
--- a/final_main/chapter5/chapter5.tex	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/chapter5/chapter5.tex	Fri Feb 07 21:12:05 2020 +0900
@@ -4,80 +4,11 @@
 %%文書開始****************************
 \begin{document} 
 %%**************************************
-\chapter{評価}
-
-本研究では, 実際にコンセンサスアルゴリズムPaxosを分散環境上で実行した. 分散環境上で動かすため, JobSchedulerの一種であるTorque Resource Manager(Torque)を使った. ここではTorqueとはなにか, どのような評価をしたかを述べる.
-
-\section{Torqueとは}
-
-PCクラスタ上でプログラムの実験を行う際には, 他のプログラムとリソースを取り合う懸念がある. それを防ぐためにTorqueを使用する. Torqueはjobという単位でプログラムを管理し, リソースを確保できたら実行する. jobはqsubというコマンドを使って複数登録することができる. また, 実行中の様子もqstatというコマンドを打つことで監視ができる.
-
-
-Torqueには主に3つのNodeの種類がある. 
-
-\begin{description}
-\item[Master Node] pbs\_serverを実行しているノード. 他のノードの役割とも併用できる.
-\item[Submit/Interactive Nodes] クライアントがjobを投入したり監視したりするノード. qsubやqstatのようなクライアントコマンドが実行できる.
-\item[Computer Nodes] 投入されたjobを実際に実行するノード. pbs\_momが実行されており, それによってjobをstart, kill, 管理する.
-\end{description}
-
-今回は図\ref{fig:kvm}のように, 学科のKVM上にMaster Node, Submit/Interactive Nodeの役割を持つVM1台と, Computer Nodesとして15台のVMを用意し, jobの投入を行った.
-
-\begin{figure}[H]
-\centering
-  \fbox{
-   \includegraphics[scale=0.5]{./images/kvm.pdf}
-  }
-\caption{実験環境}
-\label{fig:kvm}
-\end{figure}
-
-jobはシェルスクリプトの形で与えることができる. ソースコード\ref{code:torque-example}を例としてあげる. 
-
-\lstinputlisting[caption=torque-example.sh,label=code:torque-example]{./src/torque-example.sh}
-
-
-「\#PBS オプション」とすることにより実行環境を設定できる. 使用できるオプションは参考文献\cite{qsub-doc}に書かれてある. このスクリプトでは, ノード数10(vm0からvm9まで), jobの名前を「ExampleJob」という形で実行する設定をしている. もし, このコードを投入した場合, Submit/Interactive Nodesが各vmにsshし, hostnameコマンドを実行する. 
-実行後はstdout, stderrorの出力を「job名.o数字」, 「job名.e数字」というファイルに書き出す.
+\chapter{今後の課題}
+ここではリモートエディタの実装において今後開発, 修正しなければならないことについて解説する.
 
-\section{PCクラスタ上でのPaxosの実験}
-
-PCクラスタ上で実際にPaxosを動かしてみる. 今回は単純化し, proposerの数を2, acceptorの数を3, learnerの数を1としてPaxosを動かし, 値が一意に決まるかどうかを見る. また, わかりやすいように提案の値を整数とし, 各proposerごとに異なった値とした. 正確には, 「proposer + 数字」 の数字の部分を値とし, コンセンサスを取るようにした.
-
-実験を3回行い, シーケンス図で結果を示したものを図\ref{fig:paxos1}, 図\ref{fig:paxos2}, 図\ref{fig:paxos3}に示す. なおこの結果はプログラム中のLog4j2を用いたlogの出力を元にLeanerが値を選択するまでを図にしたものである. 
-
-\begin{figure}[H]
-\centering
-  \fbox{
-   \includegraphics[scale=0.5]{./images/paxos1.pdf}
-  }
-\caption{実験1回目のPaxos}
-\label{fig:paxos1}
-\end{figure}
-
-
-\begin{figure}[H]
-\centering
-  \fbox{
-   \includegraphics[scale=0.8]{./images/paxos2.pdf}
-  }
-\caption{実験2回目のPaxos}
-\label{fig:paxos2}
-\end{figure}
-
-
-\begin{figure}[H]
-\centering
-  \fbox{
-   \includegraphics[scale=0.8]{./images/paxos3.pdf}
-  }
-\caption{実験3回目のPaxos}
-\label{fig:paxos3}
-\end{figure}
-
-いずれも一意の値を決めることができている. また, Learnerが値を選択した後でも, Paxosは常に決めた値を持ち続けるアルゴリズムである. 参照したLog4j2の出力では提案番号25, 31まで提案を続けていたが, 値がこれ以降に覆ることはなかった.
-
-今回はわかりやすいように値を数字で行った実験だったが, これをトランザクション, ブロックに応用することで, ブロックチェーンにおけるコンセンサス部分を完成させることができる.
+\section{動的なStar型Topologyの構成機能}
+現開発段階では, Star型の接続をdotファイルを用いて静的に行っており, 先述したとおり, 
 
 
 %%文書終了****************************
--- a/final_main/main.aux	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/main.aux	Fri Feb 07 21:12:05 2020 +0900
@@ -3,63 +3,52 @@
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
 \newlabel{chap:introduction}{{1}{1}}
-\@writefile{toc}{\contentsline {chapter}{\numberline {第2章}ブロックチェーンについて}{2}\protected@file@percent }
-\@writefile{lof}{\addvspace {10\p@ }}
-\@writefile{lot}{\addvspace {10\p@ }}
-\@writefile{toc}{\contentsline {section}{\numberline {2.1}P2P}{2}\protected@file@percent }
-\@writefile{toc}{\contentsline {section}{\numberline {2.2}ブロックとその構造}{2}\protected@file@percent }
-\@writefile{lof}{\contentsline {figure}{\numberline {2.1}{\ignorespaces hash chain}}{3}\protected@file@percent }
-\newlabel{fig:chain}{{2.1}{3}}
-\@writefile{toc}{\contentsline {section}{\numberline {2.3}トランザクションとその構造}{3}\protected@file@percent }
-\@writefile{toc}{\contentsline {section}{\numberline {2.4}fork}{4}\protected@file@percent }
-\@writefile{toc}{\contentsline {chapter}{\numberline {第3章}コンセンサスアルゴリズム}{5}\protected@file@percent }
+\@writefile{toc}{\contentsline {chapter}{\numberline {第2章}分散フレームワークChrisiteについて}{2}\protected@file@percent }
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
-\@writefile{toc}{\contentsline {section}{\numberline {3.1}Proof of Workを用いたコンセンサス}{5}\protected@file@percent }
-\@writefile{lof}{\contentsline {figure}{\numberline {3.1}{\ignorespaces proof-of-workの例}}{6}\protected@file@percent }
-\newlabel{fig:proof-of-work}{{3.1}{6}}
-\@writefile{lof}{\contentsline {figure}{\numberline {3.2}{\ignorespaces Proof of Workでのコンセンサス}}{7}\protected@file@percent }
-\newlabel{fig:proof-of-work-fork}{{3.2}{7}}
-\@writefile{toc}{\contentsline {section}{\numberline {3.2}Paxos}{7}\protected@file@percent }
-\@writefile{lof}{\contentsline {figure}{\numberline {3.3}{\ignorespaces prepare-promise}}{9}\protected@file@percent }
-\newlabel{fig:prepare-promise}{{3.3}{9}}
-\@writefile{lof}{\contentsline {figure}{\numberline {3.4}{\ignorespaces accept-accepted}}{10}\protected@file@percent }
-\newlabel{fig:accept-accepted}{{3.4}{10}}
-\@writefile{toc}{\contentsline {section}{\numberline {3.3}Paxosによるブロックチェーン}{11}\protected@file@percent }
-\@writefile{toc}{\contentsline {chapter}{\numberline {第4章}Christieについて}{12}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {2.1}Chrisiteとは}{2}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {2.2}プログラムの例}{3}\protected@file@percent }
+\newlabel{code:nStartHelloWorld}{{2.1}{3}}
+\@writefile{lol}{\contentsline {lstlisting}{\numberline {2.1}StartHelloWorld}{3}\protected@file@percent }
+\newlabel{code:HelloWorldCodeGear}{{2.2}{4}}
+\@writefile{lol}{\contentsline {lstlisting}{\numberline {2.2}HelloWorldCodeGear}{4}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {2.3}TopologyManager について}{4}\protected@file@percent }
+\newlabel{code:dotFile}{{2.3}{4}}
+\@writefile{lol}{\contentsline {lstlisting}{\numberline {2.3}ringを構成するdotファイル}{4}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {2.1}{\ignorespaces ソースコード 2.3\@setref@ {} のdotファイルを図示化したもの}}{5}\protected@file@percent }
+\newlabel{fig:dot}{{2.1}{5}}
+\@writefile{toc}{\contentsline {chapter}{\numberline {第3章}リモートエディタ}{6}\protected@file@percent }
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
-\@writefile{toc}{\contentsline {section}{\numberline {4.1}Christieとは}{12}\protected@file@percent }
-\@writefile{toc}{\contentsline {section}{\numberline {4.2}プログラミングの例}{13}\protected@file@percent }
-\newlabel{code:StartHelloWorld}{{4.1}{13}}
-\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.1}StartHelloWorld}{13}\protected@file@percent }
-\@writefile{toc}{\contentsline {section}{\numberline {4.3}TopologyManagerの実装}{13}\protected@file@percent }
-\newlabel{code:dot-example}{{4.2}{14}}
-\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.2}ring.dot}{14}\protected@file@percent }
-\@writefile{lof}{\contentsline {figure}{\numberline {4.1}{\ignorespaces ソースコード4.2\@setref@ {}, ring.dotを図にしたもの}}{14}\protected@file@percent }
-\newlabel{fig:dot-example}{{4.1}{14}}
-\newlabel{code:datagear}{{4.3}{15}}
-\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.3}修正後のDataGearのソースコード}{15}\protected@file@percent }
-\newlabel{code:rdgm}{{4.4}{16}}
-\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.4}修正後のRemoteDataGearManagerのソースコード}{16}\protected@file@percent }
-\@writefile{toc}{\contentsline {section}{\numberline {4.4}Christieにおけるブロックチェーンの実装の利点と欠点}{18}\protected@file@percent }
-\@writefile{toc}{\contentsline {chapter}{\numberline {第5章}評価}{19}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {3.1}編集位置の相違}{6}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {3.2}編集位置の相違解消方法}{6}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {3.3}document listenerによる編集オフセット番号の読み取り}{6}\protected@file@percent }
+\newlabel{code:DocumentListener}{{3.1}{6}}
+\@writefile{lol}{\contentsline {lstlisting}{\numberline {3.1}DocumentListenerのコード部分}{6}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {3.4}Command パターンによる命令オブジェクトの作成}{7}\protected@file@percent }
+\newlabel{code:Command}{{3.2}{8}}
+\@writefile{lol}{\contentsline {lstlisting}{\numberline {3.2}Commandパターンとして実装した命令}{8}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {3.5}命令オブジェクトを実装する際に起きた問題}{8}\protected@file@percent }
+\@writefile{toc}{\contentsline {chapter}{\numberline {第4章}スター型接続によるネットワーク通信}{10}\protected@file@percent }
+\@writefile{lof}{\addvspace {10\p@ }}
+\@writefile{lot}{\addvspace {10\p@ }}
+\@writefile{toc}{\contentsline {chapter}{\numberline {第5章}評価}{11}\protected@file@percent }
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
-\@writefile{toc}{\contentsline {section}{\numberline {5.1}Torqueとは}{19}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {5.1}Torqueとは}{11}\protected@file@percent }
 \citation{qsub-doc}
-\@writefile{lof}{\contentsline {figure}{\numberline {5.1}{\ignorespaces 実験環境}}{20}\protected@file@percent }
-\newlabel{fig:kvm}{{5.1}{20}}
-\newlabel{code:torque-example}{{5.1}{20}}
-\@writefile{lol}{\contentsline {lstlisting}{\numberline {5.1}torque-example.sh}{20}\protected@file@percent }
-\@writefile{toc}{\contentsline {section}{\numberline {5.2}PCクラスタ上でのPaxosの実験}{20}\protected@file@percent }
-\@writefile{lof}{\contentsline {figure}{\numberline {5.2}{\ignorespaces 実験1回目のPaxos}}{21}\protected@file@percent }
-\newlabel{fig:paxos1}{{5.2}{21}}
-\@writefile{lof}{\contentsline {figure}{\numberline {5.3}{\ignorespaces 実験2回目のPaxos}}{22}\protected@file@percent }
-\newlabel{fig:paxos2}{{5.3}{22}}
-\@writefile{lof}{\contentsline {figure}{\numberline {5.4}{\ignorespaces 実験3回目のPaxos}}{23}\protected@file@percent }
-\newlabel{fig:paxos3}{{5.4}{23}}
-\@writefile{toc}{\contentsline {chapter}{\numberline {第6章}まとめ}{25}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {5.1}{\ignorespaces 実験環境}}{12}\protected@file@percent }
+\newlabel{fig:kvm}{{5.1}{12}}
+\newlabel{code:torque-example}{{5.1}{12}}
+\@writefile{lol}{\contentsline {lstlisting}{\numberline {5.1}torque-example.sh}{12}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {5.2}PCクラスタ上でのPaxosの実験}{12}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {5.2}{\ignorespaces 実験1回目のPaxos}}{13}\protected@file@percent }
+\newlabel{fig:paxos1}{{5.2}{13}}
+\@writefile{lof}{\contentsline {figure}{\numberline {5.3}{\ignorespaces 実験2回目のPaxos}}{14}\protected@file@percent }
+\newlabel{fig:paxos2}{{5.3}{14}}
+\@writefile{lof}{\contentsline {figure}{\numberline {5.4}{\ignorespaces 実験3回目のPaxos}}{15}\protected@file@percent }
+\newlabel{fig:paxos3}{{5.4}{15}}
+\@writefile{toc}{\contentsline {chapter}{\numberline {第6章}まとめ}{17}\protected@file@percent }
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
 \bibcite{christie}{1}
Binary file final_main/main.dvi has changed
--- a/final_main/main.lof	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/main.lof	Fri Feb 07 21:12:05 2020 +0900
@@ -1,16 +1,11 @@
+\addvspace {10\p@ }
+\addvspace {10\p@ }
+\contentsline {figure}{\numberline {2.1}{\ignorespaces ソースコード 2.3\@setref@ {} のdotファイルを図示化したもの}}{5}% 
+\addvspace {10\p@ }
 \addvspace {10\p@ }
 \addvspace {10\p@ }
-\contentsline {figure}{\numberline {2.1}{\ignorespaces hash chain}}{3}% 
-\addvspace {10\p@ }
-\contentsline {figure}{\numberline {3.1}{\ignorespaces proof-of-workの例}}{6}% 
-\contentsline {figure}{\numberline {3.2}{\ignorespaces Proof of Workでのコンセンサス}}{7}% 
-\contentsline {figure}{\numberline {3.3}{\ignorespaces prepare-promise}}{9}% 
-\contentsline {figure}{\numberline {3.4}{\ignorespaces accept-accepted}}{10}% 
+\contentsline {figure}{\numberline {5.1}{\ignorespaces 実験環境}}{12}% 
+\contentsline {figure}{\numberline {5.2}{\ignorespaces 実験1回目のPaxos}}{13}% 
+\contentsline {figure}{\numberline {5.3}{\ignorespaces 実験2回目のPaxos}}{14}% 
+\contentsline {figure}{\numberline {5.4}{\ignorespaces 実験3回目のPaxos}}{15}% 
 \addvspace {10\p@ }
-\contentsline {figure}{\numberline {4.1}{\ignorespaces ソースコード4.2\@setref@ {}, ring.dotを図にしたもの}}{14}% 
-\addvspace {10\p@ }
-\contentsline {figure}{\numberline {5.1}{\ignorespaces 実験環境}}{20}% 
-\contentsline {figure}{\numberline {5.2}{\ignorespaces 実験1回目のPaxos}}{21}% 
-\contentsline {figure}{\numberline {5.3}{\ignorespaces 実験2回目のPaxos}}{22}% 
-\contentsline {figure}{\numberline {5.4}{\ignorespaces 実験3回目のPaxos}}{23}% 
-\addvspace {10\p@ }
--- a/final_main/main.log	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/main.log	Fri Feb 07 21:12:05 2020 +0900
@@ -1,4 +1,4 @@
-This is e-pTeX, Version 3.14159265-p3.8.2-190131-2.6 (utf8.euc) (TeX Live 2019) (preloaded format=platex 2019.10.15)  3 FEB 2020 18:35
+This is e-pTeX, Version 3.14159265-p3.8.2-190131-2.6 (utf8.euc) (TeX Live 2019) (preloaded format=platex 2019.10.15)  7 FEB 2020 21:03
 entering extended mode
  restricted \write18 enabled.
  %&-line parsing enabled.
@@ -291,49 +291,36 @@
 LaTeX Font Info:    Font shape `JY1/mc/bx/n' in size <17.28> not available
 (Font)              Font shape `JY1/gt/m/n' tried instead on input line 10.
 LaTeX Font Info:    Trying to load font information for OMS+cmr on input line 1
-8.
+4.
 (/usr/local/texlive/2019/texmf-dist/tex/latex/base/omscmr.fd
 File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
 )
 LaTeX Font Info:    Font shape `OMS/cmr/m/n' in size <12> not available
-(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 18.
-File: ./images/chain.pdf Graphic file (type pdf)
-<./images/chain.pdf>
+(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 14.
  [2
 
-] [3])
-(./chapter3/chapter3.tex [4]
-第 3 章
-[5
-
-]
-File: ./images/proof-of-work.pdf Graphic file (type pdf)
-<./images/proof-of-work.pdf>
-File: ./images/proof-of-work-fork.pdf Graphic file (type pdf)
-<./images/proof-of-work-fork.pdf>
- [6] [7]
-File: ./images/prepare-promise.pdf Graphic file (type pdf)
-<./images/prepare-promise.pdf>
- [8]
-File: ./images/accept-accepted.pdf Graphic file (type pdf)
-<./images/accept-accepted.pdf>
- [9] [10]) (./chapter4/chapter4.tex [11]
-第 4 章
-[12
-
-] [13]
+] [3]
 File: ./images/ring.pdf Graphic file (type pdf)
 <./images/ring.pdf>
- [14] [15] [16] [17] [18]) (./chapter5/chapter5.tex
+ [4])
+(./chapter3/chapter3.tex [5]
+第 3 章
+[6
+
+] [7] [8]) (./chapter4/chapter4.tex [9]
+第 4 章
+[10
+
+]) (./chapter5/chapter5.tex
 第 5 章
 File: ./images/kvm.pdf Graphic file (type pdf)
 <./images/kvm.pdf>
-[19
+[11
 
 ]
 File: ./images/paxos1.pdf Graphic file (type pdf)
 <./images/paxos1.pdf>
- [20]
+ [12]
 File: ./images/paxos2.pdf Graphic file (type pdf)
 <./images/paxos2.pdf>
 
@@ -341,11 +328,11 @@
  [][] 
  []
 
-[21]
+[13]
 Overfull \vbox (42.47844pt too high) has occurred while \output is active []
 
 
-[22]
+[14]
 File: ./images/paxos3.pdf Graphic file (type pdf)
 <./images/paxos3.pdf>
 
@@ -357,9 +344,9 @@
 Overfull \vbox (42.47844pt too high) has occurred while \output is active []
 
 
-[23]) (./chapter6/chapter6.tex [24]
+[15]) (./chapter6/chapter6.tex [16]
 第 6 章
-) (./bibliography.tex [25
+) (./bibliography.tex [17
 
 ]
 Underfull \hbox (badness 10000) in paragraph at lines 29--32
@@ -379,9 +366,9 @@
 []2 / Content / topics /
  []
 
-) (./thanks.tex [26
+) (./thanks.tex [18
 
-]) [27
+]) [19
 
 ] (./main.aux)
 
@@ -389,12 +376,12 @@
 
  ) 
 Here is how much of TeX's memory you used:
- 4129 strings out of 492763
- 52211 string characters out of 6140193
- 470949 words of memory out of 5000000
- 8476 multiletter control sequences out of 15000+600000
+ 4101 strings out of 492763
+ 51502 string characters out of 6140193
+ 337890 words of memory out of 5000000
+ 8451 multiletter control sequences out of 15000+600000
  16433 words of font info for 66 fonts, out of 8000000 for 9000
  929 hyphenation exceptions out of 8191
- 31i,6n,36p,532b,1690s stack positions out of 5000i,500n,10000p,200000b,80000s
+ 31i,6n,36p,864b,1688s stack positions out of 5000i,500n,10000p,200000b,80000s
 
-Output written on main.dvi (31 pages, 86524 bytes).
+Output written on main.dvi (23 pages, 63184 bytes).
--- a/final_main/main.lol	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/main.lol	Fri Feb 07 21:12:05 2020 +0900
@@ -1,5 +1,6 @@
-\contentsline {lstlisting}{\numberline {4.1}StartHelloWorld}{13}% 
-\contentsline {lstlisting}{\numberline {4.2}ring.dot}{14}% 
-\contentsline {lstlisting}{\numberline {4.3}修正後のDataGearのソースコード}{15}% 
-\contentsline {lstlisting}{\numberline {4.4}修正後のRemoteDataGearManagerのソースコード}{16}% 
-\contentsline {lstlisting}{\numberline {5.1}torque-example.sh}{20}% 
+\contentsline {lstlisting}{\numberline {2.1}StartHelloWorld}{3}% 
+\contentsline {lstlisting}{\numberline {2.2}HelloWorldCodeGear}{4}% 
+\contentsline {lstlisting}{\numberline {2.3}ringを構成するdotファイル}{4}% 
+\contentsline {lstlisting}{\numberline {3.1}DocumentListenerのコード部分}{6}% 
+\contentsline {lstlisting}{\numberline {3.2}Commandパターンとして実装した命令}{8}% 
+\contentsline {lstlisting}{\numberline {5.1}torque-example.sh}{12}% 
Binary file final_main/main.pdf has changed
--- a/final_main/main.tex	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/main.tex	Fri Feb 07 21:12:05 2020 +0900
@@ -19,7 +19,7 @@
   breaklines=true,%自動で折り返す。
   columns=[l]{fullflexible},
   commentstyle={\footnotesize\ttfamily},
-  escapechar={@},
+  escapechar={},
   frame=single,
   framerule=.5pt,
   identifierstyle={\ttfamily},
--- a/final_main/main.toc	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/main.toc	Fri Feb 07 21:12:05 2020 +0900
@@ -1,19 +1,16 @@
 \contentsline {chapter}{\numberline {第1章}はじめに}{1}% 
-\contentsline {chapter}{\numberline {第2章}ブロックチェーンについて}{2}% 
-\contentsline {section}{\numberline {2.1}P2P}{2}% 
-\contentsline {section}{\numberline {2.2}ブロックとその構造}{2}% 
-\contentsline {section}{\numberline {2.3}トランザクションとその構造}{3}% 
-\contentsline {section}{\numberline {2.4}fork}{4}% 
-\contentsline {chapter}{\numberline {第3章}コンセンサスアルゴリズム}{5}% 
-\contentsline {section}{\numberline {3.1}Proof of Workを用いたコンセンサス}{5}% 
-\contentsline {section}{\numberline {3.2}Paxos}{7}% 
-\contentsline {section}{\numberline {3.3}Paxosによるブロックチェーン}{11}% 
-\contentsline {chapter}{\numberline {第4章}Christieについて}{12}% 
-\contentsline {section}{\numberline {4.1}Christieとは}{12}% 
-\contentsline {section}{\numberline {4.2}プログラミングの例}{13}% 
-\contentsline {section}{\numberline {4.3}TopologyManagerの実装}{13}% 
-\contentsline {section}{\numberline {4.4}Christieにおけるブロックチェーンの実装の利点と欠点}{18}% 
-\contentsline {chapter}{\numberline {第5章}評価}{19}% 
-\contentsline {section}{\numberline {5.1}Torqueとは}{19}% 
-\contentsline {section}{\numberline {5.2}PCクラスタ上でのPaxosの実験}{20}% 
-\contentsline {chapter}{\numberline {第6章}まとめ}{25}% 
+\contentsline {chapter}{\numberline {第2章}分散フレームワークChrisiteについて}{2}% 
+\contentsline {section}{\numberline {2.1}Chrisiteとは}{2}% 
+\contentsline {section}{\numberline {2.2}プログラムの例}{3}% 
+\contentsline {section}{\numberline {2.3}TopologyManager について}{4}% 
+\contentsline {chapter}{\numberline {第3章}リモートエディタ}{6}% 
+\contentsline {section}{\numberline {3.1}編集位置の相違}{6}% 
+\contentsline {section}{\numberline {3.2}編集位置の相違解消方法}{6}% 
+\contentsline {section}{\numberline {3.3}document listenerによる編集オフセット番号の読み取り}{6}% 
+\contentsline {section}{\numberline {3.4}Command パターンによる命令オブジェクトの作成}{7}% 
+\contentsline {section}{\numberline {3.5}命令オブジェクトを実装する際に起きた問題}{8}% 
+\contentsline {chapter}{\numberline {第4章}スター型接続によるネットワーク通信}{10}% 
+\contentsline {chapter}{\numberline {第5章}評価}{11}% 
+\contentsline {section}{\numberline {5.1}Torqueとは}{11}% 
+\contentsline {section}{\numberline {5.2}PCクラスタ上でのPaxosの実験}{12}% 
+\contentsline {chapter}{\numberline {第6章}まとめ}{17}% 
Binary file final_main/src/.DS_Store has changed
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/final_main/src/Command.java	Fri Feb 07 21:12:05 2020 +0900
@@ -0,0 +1,29 @@
+package christie.remoteTextEditor;
+
+import christie.textEditor.NewTextEditor;
+import org.msgpack.annotation.Message;
+
+@Message
+class Command {
+    public String string;
+    public int fastOffset;
+    public int endOffset;
+    public String nodename;
+    public  boolean isDeleteCommand = false;
+
+    public Command() {}
+
+//    delete用
+    public Command(int fastOffset, int endOffset, String nodeName){
+        this.fastOffset = fastOffset;
+        this.endOffset = endOffset;
+        this.nodename = nodeName;
+        this.isDeleteCommand = true;
+    }
+
+    public Command(int fastOffset, String string, String nodename) {
+        this.string = string;
+        this.fastOffset = fastOffset;
+        this.nodename = nodename;
+    }
+}
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/final_main/src/DocumentListener.java	Fri Feb 07 21:12:05 2020 +0900
@@ -0,0 +1,39 @@
+public class MyDocumentListener implements DocumentListener {
+    public void insertUpdate(DocumentEvent e) {
+        if(canWrite == true) {
+            Document doc = e.getDocument();
+            loc = e.getOffset();
+            sendLoc = loc;
+            try {
+                inserted_string = doc.getText(loc, 1);
+                System.out.println("string = " + doc.getText(loc, 1));
+            } catch (BadLocationException e1) {
+                e1.printStackTrace();
+            }
+            send = true;
+        }
+        canWrite = true;
+
+    }
+
+    @Override
+    public void removeUpdate(DocumentEvent e) {
+        if(canWrite == true) {
+            Document doc = e.getDocument();
+            sendLoc = e.getOffset();
+            int e_length = e.getLength();
+            endLoc = sendLoc + e_length;
+                if (e_length == 1) {
+                    System.out.println("delete " + sendLoc);
+                } else {
+                System.out.println("delete " + sendLoc + " to " + endLoc);
+            }
+            dFrag = true;
+        }
+        canWrite = true;
+    }
+
+    @Override
+    public void changedUpdate(DocumentEvent e) {
+    }
+}
Binary file final_main/src/HelloWorld/.DS_Store has changed
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/final_main/src/HelloWorld/FinishHelloWorld.java	Fri Feb 07 21:12:05 2020 +0900
@@ -0,0 +1,15 @@
+package christie.example.HelloWorld;
+
+import christie.annotation.Take;
+import christie.codegear.CodeGear;
+import christie.codegear.CodeGearManager;
+
+public class FinishHelloWorld extends CodeGear {
+    @Take String hello;
+    @Take String world;
+
+    @Override
+    protected void run(CodeGearManager cgm) {
+        cgm.getLocalDGM().finish();
+    }
+}
--- a/final_main/src/HelloWorld/HelloWorldCodeGear.java	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/src/HelloWorld/HelloWorldCodeGear.java	Fri Feb 07 21:12:05 2020 +0900
@@ -1,5 +1,6 @@
 package christie.example.HelloWorld;
 
+import christie.annotation.Peek;
 import christie.annotation.Take;
 import christie.codegear.CodeGear;
 import christie.codegear.CodeGearManager;
@@ -8,10 +9,10 @@
 
     @Take
     String helloWorld;
-
     @Override
     protected void run(CodeGearManager cgm) {
         System.out.print(helloWorld + " ");
         cgm.setup(new HelloWorldCodeGear());
+        cgm.getLocalDGM().put(helloWorld,helloWorld);
     }
 }
--- a/final_main/src/HelloWorld/StartHelloWorld.java	Tue Feb 04 17:40:50 2020 +0900
+++ b/final_main/src/HelloWorld/StartHelloWorld.java	Fri Feb 07 21:12:05 2020 +0900
@@ -12,6 +12,7 @@
     public static void main(String[] args){
         CodeGearManager cgm = createCGM(10000);
         cgm.setup(new HelloWorldCodeGear());
+        cgm.setup(new FinishHelloWorld());
         cgm.getLocalDGM().put("helloWorld","hello");
         cgm.getLocalDGM().put("helloWorld","world");
     }