# HG changeset patch
# User Kazuma
# Date 1477056740 -32400
# Node ID 03e97e769bb083e1fa5363b4471a98eb4c7f277f
# Parent  202092f0f3099552317631f5ad923294aa177acd
fix

diff -r 202092f0f309 -r 03e97e769bb0 midterm.pdf
Binary file midterm.pdf has changed
diff -r 202092f0f309 -r 03e97e769bb0 midterm.tex
--- a/midterm.tex	Fri Oct 21 21:07:43 2016 +0900
+++ b/midterm.tex	Fri Oct 21 22:32:20 2016 +0900
@@ -28,78 +28,67 @@
 
 \section{非破壊木構造データベース}
 
-当研究室ではデータの変更の際に過去の木構造を保存しつつ新しく木構造を作成する非破壊的木構造を用いたデータベースであるJungleを開発している\cite{1}。
+当研究室ではデータの変更の際に過去の木構造を保存する非破壊木構造データベースであるJungleを開発している\cite{1}。
 
-本研究ではJungleの実用例として、ゲームのバックエンドとして利用出来るデータベースとしてJungle DBをC\#で再実装を行い、Unity向けに組み込みを行う。
+本研究ではJungleをUnityを用いたネットワークゲームで使用する方法を提案する。
+データベースとしてJungle DBをC\#で再実装を行い、Unity向けに組み込みを行う。
 
 Jugnleの木は、子供を複数持つノードからなる。子供は順序付けられており、任意の位置で作成削除することができる。
+ノードは属性名と属性値の組からなる表を持つ。
 
-Unityは３Dゲームエンジンである。
-ゲーム構造はシーングラフに類似している。
-ゲームシーンに子ノードのゲーム要素(GameObject)があり、その要素自身も親子関係になっている。
-Jungleはこれと同じ構造を持っているため、相性が良い。
+\section{UnityでのDBの取り扱い}
+
+Unityは3Dゲームエンジンで、ゲームを構成する要素(Object)をC\#で制御する。
+Objectは一つのゲームのシーン(一画面の状況)の中で木構造を持つ。
+これをシーングラフと言う。
+シーングラフをそのままJungleに格納するという手法が考えられる。
 
-% ので、過去の組織のデータを参照する必要が出てくる。よって過去のデータの参照が出来るJungleと相性が良い。
-% これらは、XMLで記述されており、
-% maTrixが保持している人、役職、役割等のデータはお互いに参照している。
-% ポリシーファイルは、組織の中で申請等を行った際に、どの権限によってその申請が許諾されるのかを指定している。
-% 組織のデータ、ポリシーファイル共に木構造のデータであるため、Jungleにそのまま格納できる。
+JungleはJavaで書かれていたので、Unityで使うにはJungleをC\#で実装する必要がある。
+クライアント側はC\#、サーバー側はJavaで動作するJungleを用いる。
+Jungleの分散機構を用いてネットワークゲームに必要な通信を行う。
+通信はMessagePackを基本に実装されている。
+従って、C\#側でもMessagePackを用いてデータのやり取りを行いたい。
 
-\section{Unityでの問題点}
-
-Unityではデータの保存の際にMySQL、SQlite3、PlayerPrefsといったDBがよく使われている。
-しかし、木構造でゲームは構成されているため、ゲーム構造を保存するにはRDB向けにノードの関係を変換する必要がある。
-つまり、そのまま格納することができればスケールアウトするデータにも対応でき、データベース設計も簡略化できると考え、C\#に書き直すことにした。
-
+Unityではデータの保存の際にSQlite3、PlayerPrefsといったDBがよく使われている。
 PlayerPrefsとは、Unityに特化したバイナリ形式でKey,Valueのみで保存されるものである。
+これらのDBにはObjectを直接格納することはできない。
+また、セーブ機能に特化していてメモリ上にDBを展開するものではない。
 
 \section{Jungle-Sharpの実装}
 
-JungleはJavaで書かれているものであったのでUnityで使うにはC\#で実装する必要があった。
-なお、将来的にはクライアント側はC\#、サーバー側はJavaで動作させMessagePackを用いてデータのやり取りを行う。
+%スムーズにできた部分を書く
+%Jungleがプログラミング言語に依存しないものだというのをかくほうがいい
+JavaとC\#はよく似た言語であり、移行はそれほど難しくはない。
+実際Jungleの中心部分である木構造とIndexを構成する赤黒木\cite{}のコードはほぼ変更なく移行できた。
+C\#ではインナークラスが使えないので明示的なクラスに変換する必要があった。
 
-\section{AtomicRefefarenceの実装}
+異なる部分は一つは木を変更した後、木のルートをAtomicに置き部分である。
+もう一つは木をたどる時に使うItertorである。
+
+%\section{AtomicRefefarenceの実装}
 % atomic reference問題
 Jungleの木の更新(commit)は、CAS(check and set*図1)を用いて atomic に行われる。競合している書き込みにの中で自分の書き込みが成功した場合に関数 \verb+success()+が成功する。
 JavaにはAtomicRefarenceが標準であるがC\#はなかったため、AtomicReferenceのClassを新たに作った。
 
-\begin{figure}[htbp]
-\includegraphics[width=8cm]{pic/cas.pdf}
-\label{fig:cas}
-\caption{Check and Set}
-\end{figure}
-
-
-\begin{itembox}[l]{ソースコード1 AtomicReference.cs}
+\begin{itembox}[l]{AtomicReplace}
 \begin{verbatim}
-public class AtomicReference <T> where T : class {
-  private T value;
-
-  public AtomicReference(T value) {
-    this.value = value;
-  }
-
-  public bool CompareAndSet(T newValue, T prevValue) {
+// C#  
+public bool CompareAndSet(T newValue, T prevValue) {
     T oldValue = value;
     return (oldValue 
         != Interlocked.CompareExchange (ref value, newValue, prevValue));
-  }
-    
-  public T Get() {
-    return value;
-  }
 }
+
+// Java
+
 \end{verbatim}
 \end{itembox}
 
-CompereAndSetメソッドではInterlocked Operationを利用した。
-これによりスレッドセーフな値の変更を行うことが可能になる。
+%\section{Listの実装}
+木やリストをたどる時にJavaではIteratorを用いる。
+Iteratorは次の値があるかを返すboolean hasNext()と、Tという型の次の値を取ってくるT next()を持つObjectである。
+C\#では木やリストをたどりながらyeildで次の値を返す。
 
-\section{Listの実装}
-Jungleでは、木の編集や、特定のNode下のTreeの探索、Nodeの親をたどるためには全てそのNodeへのPathが必要になる。
-その管理をListで行っている。
-Listを実装する際にIteratorが必要となる。
-JavaではインナークラスでIteratorを返すが
 \begin{itembox}[l]{ソースコード2 List.java}
 \begin{verbatim}
 public Iterator<T> iterator() {
@@ -168,7 +157,6 @@
   \end{tabular}
 \end{table}
 
-図3の結果よりJungleDBの速度を確認することができた。
 
 \section{これからの作業}