--- a/Paper/chapter/4-Christie.tex	Wed Feb 09 22:26:31 2022 +0900
+++ b/Paper/chapter/4-Christie.tex	Wed Feb 09 22:43:17 2022 +0900
@@ -50,7 +50,7 @@
 LocalDGMは所有しているCodeGearManager自身に対応するDGMである。
 LocalDGMにput操作を行うことで自身の持つkeyに対してDataGearを送ることができる。
 
-RemoteDGMは別のCodeGearManagerが持つLocalDGMのploxyに相当する。
+RemoteDGMは別のCodeGearManagerが持つLocalDGMのproxyに相当する。
 つまり、RemoteDGMは別のCodeGearManagerに必ず対応しており、
 RemoteDGMにput操作すると対応したCGMが持つLocalDGMへDataGearをputすることができる。
 図\ref{fig:gearsRelation}に示す。

--- a/Paper/chapter/5-Implementation.tex	Wed Feb 09 22:26:31 2022 +0900
+++ b/Paper/chapter/5-Implementation.tex	Wed Feb 09 22:43:17 2022 +0900
@@ -111,7 +111,7 @@
 \section{GearsFile APIによるWordCount}
 GearsFSはChristieのLocalDataGearManagerとRemoteDataGearManagerによる通信の仕組みを用いてファイルデータの送受信を構成する。これをGearsFile APIと呼ぶ。
 ChrstieAPIではファイルをDataGearManagerと見なすことができ、
-Local上にRemote先のファイルのploxyとなるRemoteDGMを作成し、
+Local上にRemote先のファイルのproxyとなるRemoteDGMを作成し、
 これに対しLocalのファイルへの書き込みと同様に操作を行うことで自動的に通信を行ってくれる。
 
 ChiristieのDataGearManagerの仕組みを基準としたGearsFile APIによるWordCountの設計を行った。
@@ -141,31 +141,33 @@
 \end{figure}
 
 
-\section{Socket付きQueue}
+\section{GearsOS上のSocket通信}
 RemoteDGMとLocalDGMの接続の際にはLocalDGMが持つsocketに対してRemoteDGMが接続を行い、
 Dataの書き込み先のkeyを指定してsocket経由でコマンドとして送信する。
 
 socketを所有したQueueによるWordCount例題の記述を行うことでGearsOSにおけるsocket通信の実装を行った。
 接続元と接続先のsocketは、Queueの作成時に行われ、
-socketへのアクセスはQueueにCodeGearとして実装を行った。
+socketへのアクセスはQueueに新しくAPIとして追記を行った。
+ソースコード\ref{src:cQueue}にsocket操作を追加したQueueのInterfaceを示す。
 ソースコード\ref{src:LDGMQueue}にLocalDGM側にあたる、Socket付きのQueueのCodeGear:getData部分を示す。
 加えてソースコード\ref{src:RDGMQueue}にRemoteDGM側にあたるSocket付きのQueueのCodeGear:sendData部分を示す。
 CodeGear:getDataではsocketなどによるError発生時やEoFフラグがあるデータを受信した場合の遷移先を指定する必要ある。
 
+\lstinputlisting[label=src:cQueue, caption=socketの操作を追加したQueue Interface]{src/TQueue.h}
+
 二つのQueueはmainプログラムによりsocketの接続が行われ、一方が文字列の送信を行い、もう一方がCount処理を行うことによってWordCountが行われる。
 socketはC言語のSocketインターフェースを用いており、
 socketのImplementのコンストラクタにあたるcreateLocalDGMQueueにて呼び出され、
 Implのメンバ変数であるsocketに置かれている。
-ソースコード\ref{src:LDGQh}に受信側となるLocalなQueueのImplementを示す。
-socketはint型で宣言されている。Implで宣言したsocket変数へsocketを保存をすることで、
+ソースコード\ref{src:LDGQh}に受信側となるLocalなQueueのImplementに使われるデータ構造を示す。
+socketはint型で宣言されている。Implementファイルで宣言したsocket変数へsocketを保存をすることで、
 Implの実装となるプログラム内ならどのCodeGearからでもsocketの参照が行える。
 
-また、既存のQueueから新たなAPIを追加するためにQueueInterfaceを新しく書き換えたcQueue(Communicate Queue)Interfaceを継承している。
 Local側のgetDataはAPIとしての呼び出しが可能となっている。socketが受け取ったデータを最終的にdataとしてQueueに対してputを行う。
 Remote側のsendDataはAPIとしては呼び出しは行えず、putAPIが呼び出されQueueへのput処理が終了した後に遷移され、
 putしたDataを接続先のQueueに対して送信する。
 
-\lstinputlisting[label=src:LDGQh, caption=LocalDGMQueueのImplement]{src/LocalDGMQueue.h}
+\lstinputlisting[label=src:LDGQh, caption=LocalDGMQueueで使われるデータ構造たい]{src/LocalDGMQueue.h}
 
 現状ではデータの通信に行われるDataGearは全てのDataGearのUnion(共用体)となるData型を用いている。
 送信データのサイズをUnion Data型のサイズにしている理由は、sizeof関数で返される値は共用体に含まれる構造体の中で最も大きなメモリサイズを返すためである。

Binary file Paper/master_paper.pdf has changed

--- a/Paper/src/TQueue.h	Wed Feb 09 22:26:31 2022 +0900
+++ b/Paper/src/TQueue.h	Wed Feb 09 22:43:17 2022 +0900
@@ -1,16 +1,14 @@
-typedef struct TQueue<>{
-    union Data* tQueue;
+typedef struct CQueue<>{
+    union Data* cQueue;
     union Data* data;
-    struct FileString* string;
+
 
     __code whenEmpty(...);
     __code whenEOF(...);
-    __code clear(Impl* tQueue, __code next(...));
-    __code put(Impl* tQueue, union Data* data, __code next(...));
-    __code take(Impl* tQueue, __code next(union Data* data, ...));
-    __code isEmpty(Impl* tQueue, __code next(...), __code whenEmpty(...));
-
-    __code sendData(Impl* tQueue, union Data* data, __code next(...));
-    __code getData(Impl* tQueue, __code next(...), __code whenEOF(...));
+    __code clear(Impl* cQueue, __code next(...));
+    __code put(Impl* cQueue, union Data* data, __code next(...));
+    __code take(Impl* cQueue, __code next(union Data* data, ...));
+    __code isEmpty(Impl* cQueue, __code next(...), __code whenEmpty(...));
+    __code getData(Impl* cQueue, __code next(...), __code whenEOF(...));
     __code next(...);
-} TQueue;
+} CQueue;

--- a/slide/thesis.md	Wed Feb 09 22:26:31 2022 +0900
+++ b/slide/thesis.md	Wed Feb 09 22:43:17 2022 +0900
@@ -121,9 +121,9 @@
 - ChristieではCodeGearManagerと呼ばれるノードがCodeGearとDataGearを管理する
 - LocalDGMはノード本体に対応するデータプールである
   - CodeGearはLocalDGMに対してDataGearを参照する
-- RemoteDGMは接続する相手ノードに対応するデータプールploxyである
+- RemoteDGMは接続する相手ノードに対応するデータプールproxyである
   - RemoteDGMに対してDataGearを書き込むことで、対応するノードのLocalDGMにデータが書き込まれる
-- GearsFSも同様にファイルploxyを通して通信を行う
+- GearsFSも同様にファイルproxyを通して通信を行う
 
 ## DataGearManager
 <div style="text-align: center;">
@@ -194,12 +194,12 @@
 ## main部分によるAPI
 - readの場合(リモート側に読み込みたいファイルが存在する)
   - (手順1)ローカル側は空のファイルを作成し、socketを持たせる
-  - (手順2)リモート側は, ローカル側の持つ空ファイルのploxyを作成する
-  - (手順3)リモート側はploxyに対して、目的のファイルのデータをputする
+  - (手順2)リモート側は, ローカル側の持つ空ファイルのproxyを作成する
+  - (手順3)リモート側はproxyに対して、目的のファイルのデータをputする
 - writeの場合(リモート側に書き込みたいファイルが存在する)
   - (手順1)リモート側は対象ファイルにsocketを持たせる
-  - (手順2)ローカル側は対象のファイルに対応するploxyを作成する
-  - (手順3)ローカル側はploxyのkeyに対してデータをputする
+  - (手順2)ローカル側は対象のファイルに対応するproxyを作成する
+  - (手順3)ローカル側はproxyのkeyに対してデータをputする
 
 
 ## wordCountの例題
@@ -288,7 +288,7 @@
   - socketによる通信部分の実装
   - 単純化した通信APIの記述
   - GearsOSの調査
-- ファイルploxyによる通信実現を行いたい
+- ファイルproxyによる通信実現を行いたい
 
 ## これからの課題
 - TopoplogyManagerの設計