Mercurial > hg > Papers > 2022 > ikki-master

Binary file Paper/images/QueueElement.graffle.graffle has changed
Binary file Paper/images/QueueElement.pdf has changed
--- a/master.mm	Thu Feb 10 19:20:41 2022 +0900
+++ b/master.mm	Thu Feb 10 23:55:41 2022 +0900
@@ -501,7 +501,26 @@
 </node>
 <node CREATED="1644318991451" ID="ID_867291976" MODIFIED="1644318991451" POSITION="left" TEXT="">
 <node CREATED="1644318975258" HGAP="10" ID="ID_820337769" MODIFIED="1644319023040" TEXT="&#x30d7;&#x30ec;&#x30bc;&#x30f3;" VSHIFT="111">
-<node CREATED="1644318998218" ID="ID_875318355" MODIFIED="1644319045533" TEXT="GearsOS&#x306e;&#x30d5;&#x30a1;&#x30a4;&#x30eb;&#x30b7;&#x30b9;&#x30c6;&#x30e0;&#x306e;&#x8a2d;&#x8a08;&#x3068;&#x5b9f;&#x88c5;"/>
+<node CREATED="1644318998218" ID="ID_875318355" MODIFIED="1644493795007" TEXT="GearsOS&#x306e;&#x30d5;&#x30a1;&#x30a4;&#x30eb;&#x30b7;&#x30b9;&#x30c6;&#x30e0;&#x306e;&#x8a2d;&#x8a08;&#x3068;&#x5b9f;&#x88c5;">
+<node CREATED="1644493990037" ID="ID_1437097066" MODIFIED="1644494000605" TEXT="&#x5f93;&#x6765;&#x306e;&#x30d5;&#x30a1;&#x30a4;&#x30eb;&#x30b7;&#x30b9;&#x30c6;&#x30e0;">
+<node CREATED="1644494002587" ID="ID_237073362" MODIFIED="1644494068411" TEXT="&#x30ec;&#x30b3;&#x30fc;&#x30c9;&#x5358;&#x4f4d;&#x306e;&#x8aad;&#x307f;&#x66f8;&#x304d;&#x3057;&#x304b;&#x306a;&#x3044;"/>
+<node CREATED="1644494022729" ID="ID_1949750164" MODIFIED="1644494031361" TEXT="&#x578b;&#x5b9a;&#x7fa9;&#x306a;&#x3057;"/>
+<node CREATED="1644494031859" ID="ID_495902802" MODIFIED="1644494039392" TEXT="Transaction&#x306a;&#x3057;"/>
+</node>
+<node CREATED="1644493768478" ID="ID_277854483" MODIFIED="1644493777966" TEXT="DataGear&#x5358;&#x4f4d;&#x306e;Transaction"/>
+<node CREATED="1644493782053" ID="ID_548134677" MODIFIED="1644493909702" TEXT="API&#x3068;&#x3057;&#x3066;Take/Put/Peek">
+<node CREATED="1644493909704" ID="ID_1820143813" MODIFIED="1644493925463" TEXT="&#x30d5;&#x30a1;&#x30a4;&#x30eb;&#x30b7;&#x30b9;&#x30c6;&#x30e0;API&#x306f;&#x901a;&#x4fe1;&#x3068;&#x540c;&#x3058;"/>
+<node CREATED="1644493939833" ID="ID_1092784975" MODIFIED="1644493957584" TEXT="&#x30e1;&#x30e2;&#x30ea;&#x304b;&#x3089;SSD&#x306b;&#x901a;&#x4fe1;&#x3059;&#x308b;"/>
+</node>
+<node CREATED="1644493819117" ID="ID_711038096" MODIFIED="1644493825267" TEXT="GearsOS&#x306e;&#x30a4;&#x30f3;&#x30bf;&#x30fc;&#x30d5;&#x30a7;&#x30fc;&#x30b9;">
+<node CREATED="1644493830383" ID="ID_647229380" MODIFIED="1644493835145" TEXT="Queue"/>
+<node CREATED="1644493841254" ID="ID_550544456" MODIFIED="1644493968210" TEXT="RedBlackTree"/>
+</node>
+<node CREATED="1644493828224" ID="ID_1882286049" MODIFIED="1644493849454" TEXT="&#x5b9f;&#x88c5;">
+<node CREATED="1644493852740" ID="ID_1524843291" MODIFIED="1644493862193" TEXT="socket&#x306b;&#x3088;&#x308b;&#x901a;&#x4fe1;"/>
+<node CREATED="1644493975975" ID="ID_1363085335" MODIFIED="1644493980277" TEXT="WordCount"/>
+</node>
+</node>
 <node CREATED="1644319049338" ID="ID_1582565964" MODIFIED="1644319055504" TEXT="GearsOS">
 <node CREATED="1644319059291" ID="ID_1134665398" MODIFIED="1644319074395" TEXT="CodeGear">
 <node CREATED="1644320108252" ID="ID_736099080" MODIFIED="1644320110534" TEXT="goto"/>
Binary file slide/images/QueueElement.pdf has changed
Binary file slide/images/slideGearsWC.graffle.graffle has changed
--- a/slide/thesis.html	Thu Feb 10 19:20:41 2022 +0900
+++ b/slide/thesis.html	Thu Feb 10 23:55:41 2022 +0900
@@ -78,7 +78,7 @@
         <td>
           <div align="left">
               Takahiro Ikki, Shinji Kono
-              琉球大学
+              琉球大学理工学研究科情報工学専攻
             <hr style="color:#ffcc00;background-color:#ffcc00;text-align:left;border:none;width:100%;height:0.2em;">
           </div>
         </td>
@@ -91,22 +91,14 @@
 <div class='slide'>

 <!-- _S9SLIDE_ -->
-<h2 id="gearsosのファイルシステムの設計方針">GearsOSのファイルシステムの設計方針</h2>
+<h2 id="gearsosのファイルシステムの設計と実装">GearsOSのファイルシステムの設計と実装</h2>
 <ul>
-  <li>GearsOSはGearという単位で記述が行われているOSプロジェクトである</li>
-  <li>GearsOSのファイルシステムも同様にDataGearの単位で構成したい</li>
-  <li>GearsOSのファイルシステムの設計と実装を行った</li>
-  <li>ファイルに取り扱うデータに対応した複数のストリームを持たせたい
-    <ul>
-      <li>従来では異なるデータでも単一のストリームから入力される</li>
-    </ul>
-  </li>
-  <li>GearsOSには将来的にアプリケーションが担う重要な機能をOSに取り込みたい
-    <ul>
-      <li>ファイルの型認識</li>
-      <li>バックアップ</li>
-    </ul>
-  </li>
+  <li>DataGearとCodeGearという単位を用いるOS</li>
+  <li>従来のファイルシステムには型とTransactionが無い</li>
+  <li>DataGear単位のTransactionとしてファイルシステムを設計</li>
+  <li>APIとしてTake/Put/Peekを採用した</li>
+  <li>通信としてもDBアクセスとしても使える(メモリからSSDへの通信に見える)</li>
+  <li>本研究ではsocket baseな通信とWordCountの例題を作成した</li>
 </ul>


@@ -115,21 +107,23 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsosのgear概念12">GearsOSのGear概念(1/2)</h2>
+<h2 id="gearsosの基本単位">GearsOSの基本単位</h2>
 <ul>
-  <li>関数でなくGearという単位を用いて記述する</li>
-  <li>Gearは関数と異なり、スタックを持たないため軽量継続と呼ぶ</li>
   <li>CodeGear
     <ul>
-      <li>従来のThreadにあたる</li>
+      <li>実行Codeの単位</li>
+      <li>入力DataGearと出力DataGearを持つ</li>
       <li>goto文(jump命令)を使って遷移する</li>
+      <li>実行単位は途中で割り込まれたりしない(Atmocity)</li>
     </ul>
   </li>
   <li>DataGear
     <ul>
-      <li>従来の変数データにあたる</li>
+      <li>Cの構造体に相当する</li>
+      <li>ノーマルレベルでは変更されない(関数型プログラミング)</li>
     </ul>
   </li>
+  <li>C言語を拡張する形でCbC言語により実装される(gcc/llvm)</li>
 </ul>


@@ -138,10 +132,11 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsosのgear概念22">GearsOSのGear概念(2/2)</h2>
+<h2 id="codegearとdatagear">CodeGearとDataGear</h2>
 <ul>
-  <li>CodeGearは処理を行う際、DataGearを参照し処理を行う(InputDataGear)</li>
-  <li>CodeGearは処理の終了後、以降に必要なデータをDataGearとして出力する(OutputDataGear)</li>
+  <li>InputDataGearを受け取って、CodeGearが処理し、OutputDataGearを出力する</li>
+  <li>OutputDataGearは次のCodeGearのInputDataGearとなる</li>
+  <li>ファイルシステムではDataGearをkeyで待ち合わせる</li>
 </ul>
 <div style="text-align: center;">
   　<img src="images/cg-dg.pdf" alt="cgdgの関係図" width="600" />
@@ -155,9 +150,9 @@
   <!-- _S9SLIDE_ -->
 <h2 id="gearsosのinterface">GearsOSのInterface</h2>
 <ul>
-  <li>Object型指向の仕組み</li>
-  <li>APIとなるCodeGearとその参照するDataGearを宣言する</li>
-  <li>DataGear/CodeGearの一時的な置き場としての役割を持つ
+  <li>JavaのInterfaceに相当する</li>
+  <li>APIとなるCodeGearの名前と型を書く(__next(…)が継続)</li>
+  <li>引数渡しの構造体として使う(引数はすべてここに定義される必要がある)
     <pre><code>typedef struct Tree&lt;&gt;{
   union Data* tree;
   struct Node* node;
@@ -176,15 +171,15 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsosのimplement">GearsOSのImplement</h2>
+<h2 id="interfaceの呼び出し">Interfaceの呼び出し</h2>
 <ul>
-  <li>Interfaceを継承した実装の型定義ファイルである</li>
-  <li>実装で使われるデータ構造を記述する
-    <pre><code> typedef struct SynchronizedQueue &lt;&gt; impl Queue {
- struct Element* top;
- struct Element* last;
- struct Atomic* atomic;
- } SynchronizedQueue;
+  <li>createで作成する(通常の関数呼び出し)</li>
+  <li>DataGearとして作成する場合はnewを使う</li>
+  <li>gotoでputAPIを呼び出す(nextは継続)</li>
+  <li>InterfaceなどのDataGearはプロセスに相当するContextにすべて格納される
+    <pre><code>struct Queue* queue = createSychronizedQueue(context);
+struct Task* task = new Task();
+goto queue-&gt;put(task, next(...));
 </code></pre>
   </li>
 </ul>
@@ -195,31 +190,30 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="interfaceの呼び出し">Interfaceの呼び出し</h2>
+<h2 id="interfaceの実装">Interfaceの実装</h2>
 <ul>
-  <li>インターフェースは以下の記述で実装と呼び出しを行う
-    <pre><code>struct Queue* queue = new Queue();
-queue = createSychronizedQueue(context);
+  <li>Interfaceの実装に使われるデータ構造を記述するImplementがある</li>
+  <li>実装で使われるDataGearを記述する(ヒープに確保される)</li>
+  <li>create時にAPIを実装するCodeGearをInterfaceの構造体に代入される
+    <pre><code>typedef struct SynchronizedQueue &lt;&gt; impl Queue {
+struct Element* top;
+struct Element* last;
+struct Atomic* atomic;
+} SynchronizedQueue;
 </code></pre>
   </li>
 </ul>

-<pre><code>goto queue-&gt;put(task, next(...));
-</code></pre>
-


 </div>

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="メタレベルのgear13">メタレベルのGear(1/3)</h2>
+<h2 id="codegearとdatagearにはメタレベルなものが存在する">CodeGearとDataGearにはメタレベルなものが存在する</h2>
 <ul>
-  <li>CodeGearとDataGearにはユーザーが記述しない、メタレベルのものが存在する
-    <ul>
-      <li>メタレベルな記述はトランスコンパイラにより自動生成される</li>
-    </ul>
-  </li>
+  <li>メタレベルな記述はトランスコンパイラにより自動生成される(記述することも可能)</li>
+  <li>CodeGearの前後にMetaなCodeGearが挿入される</li>
 </ul>
 <div style="text-align: center;">
 　<img src="images/meta-cg-dg.pdf" alt="ノーマルレベルとメタレベルの視点からのGearの関係" width="800" />
@@ -231,33 +225,11 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="メタレベルのgear23">メタレベルのGear(2/3)</h2>
+<h2 id="stubcodegearとgoto-meta">stubCodeGearとgoto meta</h2>
 <ul>
-  <li>MetaCodeGear
-    <ul>
-      <li>CodeGearの処理前と処理後に参照される</li>
-      <li>Input/OutputDataGearを引き渡す</li>
-      <li>CodeGear処理前に呼ばれるものを特にstubCodeGearと呼ぶ</li>
-    </ul>
-  </li>
-</ul>
-<div style="text-align: center;">
-　<img src="images/meta-cg-dg.pdf" alt="ノーマルレベルとメタレベルの視点からのGearの関係" width="800" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="メタレベルのgear33">メタレベルのGear(3/3)</h2>
-<ul>
-  <li>MetaDataGear
-    <ul>
-      <li>MetaCodeGearにて参照されるDataGear</li>
-    </ul>
-  </li>
+  <li>ContextからInputDataGearを取り出す(stubCodeGear)</li>
+  <li>OutputDataGearをContextに書き込み、次のCodeGearを呼び出す(goto meta)</li>
+  <li>stubCodeGear/goto metaは変更可能(メタプログラミング)</li>
 </ul>
 <div style="text-align: center;">
 　<img src="images/meta-cg-dg.pdf" alt="ノーマルレベルとメタレベルの視点からのGearの関係" width="800" />
@@ -272,15 +244,16 @@
 <h2 id="gearsosのファイルシステムの設計">GearsOSのファイルシステムの設計</h2>
 <ul>
   <li>DataGearの単位でデータを操作したい</li>
-  <li>通信データに対応した複数のストリームを持ちたい</li>
-  <li>Transaction(マクロレベル)で操作したい
+  <li>通信データに対応した複数のストリームを持つ</li>
+  <li>Transactionとしてatomicに操作したい
     <ul>
-      <li>従来のファイルシステムは一部の操作のみTransactionである</li>
+      <li>従来のファイルシステムはTransactionはUserレベルで実装される</li>
     </ul>
   </li>
-  <li>ファイルそのものが通信を担当する
+  <li>ファイル操作と通信を同じAPIで実現する
     <ul>
       <li>ChristieのDataGearManagerを参考にする</li>
+      <li>Take/Put/Peek</li>
     </ul>
   </li>
 </ul>
@@ -291,42 +264,12 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsosのファイルデータ操作13">GearsOSのファイルデータ操作(1/3)</h2>
+<h2 id="takeputpeek">Take/Put/Peek</h2>
 <ul>
-  <li>GearsOSはDataGearのやりとりでプログラムが構成される
-    <ul>
-      <li>ファイルシステムも同様の実装にしたい = DataGear単位で操作したい</li>
-    </ul>
-  </li>
-</ul>
-<div style="text-align: center;">
-  　<img src="images/QueueElement.pdf" alt="Queueの構造" width="800" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="gearsosのファイルデータ操作23">GearsOSのファイルデータ操作(2/3)</h2>
-<ul>
-  <li>GearsOSのファイルデータは任意の型を持った構造体で実装される(ファイルレコード)</li>
-  <li>レコードは決められた順番で連続しており、Queueに保存される</li>
-</ul>
-<div style="text-align: center;">
-  　<img src="images/QueueElement.pdf" alt="Queueの構造" width="800" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="gearsosのファイルデータ操作33">GearsOSのファイルデータ操作(3/3)</h2>
-<ul>
-  <li>構造体の型を判別することで処理の切り替えが行える</li>
+  <li>ファイルはQueueで構成される</li>
+  <li>putでQueueに追加</li>
+  <li>takeでQueueからの取り出し</li>
+  <li>peekでQueueから取り出さない読み出し</li>
 </ul>
 <div style="text-align: center;">
   　<img src="images/QueueElement.pdf" alt="Queueの構造" width="800" />
@@ -340,55 +283,10 @@
   <!-- _S9SLIDE_ -->
 <h2 id="gearsfsのトランザクション">GearsFSのトランザクション</h2>
 <ul>
-  <li>GearsOSのDataGear操作はマクロな操作である
-    <ul>
-      <li>よってCodeGearはTransactionである</li>
-    </ul>
-  </li>
-  <li>ファイルシステム操作もCodeGearで記述されるためTransactionとなる</li>
-  <li>トランザクションな操作によってファイルシステムの整合性の保守が行いやすい</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="queueによるgearsosのファイル">QueueによるGearsOSのファイル</h2>
-<ul>
-  <li>GearsOSのファイルはファイルレコードを保持するQueueとなる</li>
-  <li>デバイスへの保存はQueueを保存すればよい</li>
-  <li>ファイルはQueueなのでファイルのAPIは大きく二つとなる
+  <li>GearsOSのCodeGear操作はatomicなので割り込まれない
     <ul>
-      <li>Put</li>
-      <li>Take</li>
-    </ul>
-  </li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="queueapi--put-">QueueAPI -Put-</h2>
-<ul>
-  <li>Put
-    <ul>
-      <li>Queueに対してファイルレコードを入力する</li>
-      <li>ファイルの変更をレコードとして書き込む
-        <pre><code>__code putSingleLinkedQueue(struct SingleLinkedQueue* queue, union Data* data, __code next(...)) {
-Element* element = new Element();
-element-&gt;data = data;
-element-&gt;next = NULL;
-queue-&gt;last-&gt;next  = element;
-queue-&gt;last = element;
-goto next(...);
-}
-</code></pre>
-      </li>
+      <li>atomicityはOSが保証する</li>
+      <li>これによりTake/Put/PeekがTransactionであることを保証する</li>
     </ul>
   </li>
 </ul>
@@ -399,27 +297,34 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="queueapi--take-">QueueAPI -Take-</h2>
+<h2 id="queueによるgearsosのファイル">QueueによるGearsOSのファイル</h2>
 <ul>
-  <li>Take
-    <ul>
-      <li>Queueからファイルレコードを取り出す</li>
-      <li>Queue内のレコードをループで全て取り出せば良い
-        <pre><code>__code takeSingleLinkedQueue(struct SingleLinkedQueue* queue, __code next(union Data* data, ...)) {
-printf("take\n");
-struct Element* top = queue-&gt;top;
-struct Element* nextElement = top-&gt;next;
-if (queue-&gt;top == queue-&gt;last) {
-    data = NULL;
-} else {
-    queue-&gt;top = nextElement;
-    data = nextElement-&gt;data;
-}
-goto next(data, ...);
+  <li>GearsOSのファイルはDataGearを保持するQueueとなる</li>
+  <li>オンメモリのファイルに相当する</li>
+  <li>Queueをデバイスにcopyして持続性を実現する</li>
+  <li>書き込み先はDataGearManagerで選択する</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="putのimplementation">PutのImplementation</h2>
+<ul>
+  <li>QueueのElementをnewで作成する</li>
+  <li>Queueのリンクを構築する</li>
+  <li>継続nextに跳ぶ
+    <pre><code>__code putSingleLinkedQueue(struct SingleLinkedQueue* queue, union Data* data, __code next(...)) {
+  Element* element = new Element();
+  element-&gt;data = data;
+  element-&gt;next = NULL;
+  queue-&gt;last-&gt;next  = element;
+  queue-&gt;last = element;
+  goto next(...);
 }
 </code></pre>
-      </li>
-    </ul>
   </li>
 </ul>

@@ -429,15 +334,25 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="ファイル通信の構成">ファイル通信の構成</h2>
+<h2 id="takeのimplementation">TakeのImplementation</h2>
 <ul>
-  <li>GearsOSのファイルは大域的に解放された資源としたい
-    <ul>
-      <li>ファイル自信を通信そのものとして実装する</li>
-      <li>Streamに対しsocket接続により遠隔にアクセスする</li>
-    </ul>
+  <li>QueueからElement経由でDataGearを取り出す</li>
+  <li>Queueのリンクを修正し、nextでデータを引き渡す</li>
+  <li>Elementには任意の型のDataGearが格納されている
+    <pre><code>__code takeSingleLinkedQueue(struct SingleLinkedQueue* queue, __code next(union Data* data, ...)) {
+  printf("take\n");
+  struct Element* top = queue-&gt;top;
+  struct Element* nextElement = top-&gt;next;
+  if (queue-&gt;top == queue-&gt;last) {
+      data = NULL;
+  } else {
+      queue-&gt;top = nextElement;
+      data = nextElement-&gt;data;
+  }
+  goto next(data, ...);
+}
+</code></pre>
   </li>
-  <li>分散フレームワークChristieのDataGearManagerの仕組みを利用する</li>
 </ul>


@@ -448,19 +363,13 @@
   <!-- _S9SLIDE_ -->
 <h2 id="datagearmanager">DataGearManager</h2>
 <ul>
-  <li>分散フレームワークChristieの仕組みの一つ</li>
-  <li>keyとvalueの組み合わせとなるDataGearを保持するデータプール</li>
-  <li>ChristieではCodeGearManagerと呼ばれるノードがCodeGearとDataGearを管理する</li>
-  <li>LocalDGMはノード本体に対応するデータプールである
-    <ul>
-      <li>CodeGearはLocalDGMに対してDataGearを参照する</li>
-    </ul>
-  </li>
-  <li>RemoteDGMは接続する相手ノードに対応するデータプールproxyである
-    <ul>
-      <li>RemoteDGMに対してDataGearを書き込むことで、対応するノードのLocalDGMにデータが書き込まれる</li>
-    </ul>
-  </li>
+  <li>Take/Put/PeekはDataGearManagerに対して行う</li>
+  <li>メモリ上のQueueはLocalDGMになる</li>
+  <li>RemoteDGMは他のノードやプロセスあるいはストレージデバイスをあらわす</li>
+  <li>一つのDataGearManager上に複数のQueueがあり、keyで識別する</li>
+  <li>RemoteDGMに書き込むと相手のLocalDGMに書き込まれる</li>
+  <li>Take/Peekは書き込みを待ち合わせる</li>
+  <li>複数のTakeを待ち合わせることができる</li>
 </ul>


@@ -472,6 +381,9 @@
 <h2 id="datagearmanagerによる通信構成">DataGearManagerによる通信構成</h2>
 <ul>
   <li>任意の相手のRemoteDGMを作成することでTopologyが形成される</li>
+  <li>手元のRemoteDGMに書き込むと相手のLocalDGMに書き込まれる</li>
+  <li>RemoteDGMはproxyとして動作する</li>
+  <li>この構成は分散フレームワークChristie(当研究室作成)と同じ</li>
 </ul>
 <div style="text-align: center;">
 　<img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="800" />
@@ -483,41 +395,13 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsos上のsocket通信">GearsOS上のsocket通信</h2>
+<h2 id="socket通信によるremotedgmの実装">socket通信によるRemoteDGMの実装</h2>
 <ul>
-  <li>GearsOS上のsocket通信を実装したい</li>
-  <li>Queueをsocketに接続し、簡易的なAPIの記述をした
-    <ul>
-      <li>Localなqueueに対してRemoteのqueueがソケット接続を行う
-        <pre><code>typedef struct CQueue&lt;&gt;{
-union Data* cQueue;
-union Data* data;
-
-__code whenEmpty(...);
-__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(...);
-} CQueue;
-</code></pre>
-      </li>
-    </ul>
-  </li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="senddata-codegear">sendData CodeGear</h2>
-<ul>
+  <li>GearsOSはUnix上の言語フレームワークとして実装されている</li>
+  <li>Unixのsocket通信を使ってQueueのputを実装する</li>
   <li>proxy側はQueueにputされたDataをsocketで送信する</li>
-  <li>送信されたDataはLocal側でgetDataAPIで取り出される
+  <li>送信されたDataはLocal側でgetDataAPIで取り出される</li>
+  <li>send/recvはUnixのAPI
     <pre><code>__code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
   char recv_buf;
   int send_size, recv_size;
@@ -537,7 +421,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="getdata-codegear">getData CodeGear</h2>
+<h2 id="受信側の実装">受信側の実装</h2>
 <ul>
   <li>ファイル本体(Local側)はsocketからDataを取り出す</li>
   <li>取り出されたデータはQueueにputされる
@@ -566,28 +450,13 @@
 <ul>
   <li>入力されるデータに応じた個別のstreamを備えたい
     <ul>
-      <li>streamと入力されたデータの処理を直接結びつけたい</li>
+      <li>例えばUSBは複数のチャネルを持つ</li>
+      <li>メタデータの取り出しは別streamになる</li>
+      <li>通信として使う場合に複数のプロトコルがある方が良い(FTP)</li>
     </ul>
   </li>
-  <li>最低でもInput/OutputStreamの二つが必要となる</li>
-  <li>ファイルは複数のStreamを持ったリストとして実装する</li>
   <li>Streamはkey nameを持ち、keyでアクセスを行う</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="複数のストリームを持つファイルの設計">複数のストリームを持つファイルの設計</h2>
-<ul>
-  <li>Queueのリストとして赤黒木を用いる
-    <ul>
-      <li>key/value storeなアクセスを行うことができる</li>
-      <li>GearsOS上にすでに実装が行われている</li>
-    </ul>
-  </li>
+  <li>赤黒木を用いる</li>
   <li>DataのTake/Put時には必ずkey nameの指定が必要となる</li>
 </ul>

@@ -597,10 +466,10 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="リスト単位の通信の構成">リスト単位の通信の構成</h2>
+<h2 id="socketを使ったremotedgm">socketを使ったRemoteDGM</h2>
 <ul>
-  <li>指定したkeyのQueueが探索で返される</li>
-  <li>proxyの場合、どのkeyに対してどんなDataを書き込んだかを通信で送信する</li>
+  <li>RemoteDGMに書き込みが行われるとsocketで通信が起きる</li>
+  <li>受信側はLocalDGMにDataGearを書き込む</li>
 </ul>
 <div style="text-align: center;">
   　<img src="images/socketCom.pdf" alt="socketを通じたレコード送信" width="800" />
@@ -612,14 +481,12 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="wordcount例題による通信apiの構築">wordCount例題による通信APIの構築</h2>
+<h2 id="wordcountの例題">wordCountの例題</h2>
 <ul>
-  <li>DataGearManagerによるファイル通信APIはWordCount例題を目指して設計した
-    <ul>
-      <li>ファイル内の文字列を1行づつ受け取り、文字列,行数をカウントする例題</li>
-    </ul>
-  </li>
+  <li>ファイル内の文字列を1行づつ受け取り、文字列,行数をカウントする例題</li>
   <li>文字列送信側とCount側を別ノード上で行うことで、ファイルの呼び出しと通信処理が構成できる</li>
+  <li>RemoteDGMへの書き込みで通信する</li>
+  <li>acknowredgeを逆方向のRemoteDGMによる通信で実現する(現在は直接送信)</li>
 </ul>
 <div style="text-align: center;">
 　<img src="images/slideGearsWC.pdf" alt="リモートDGMによるWordCount" width="800" />
@@ -710,6 +577,64 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
+<h2 id="結論">結論</h2>
+<ul>
+  <li>GearsOSのファイルの設計を行った
+    <ul>
+      <li>ファイルの構造の設計
+        <ul>
+          <li>DataGear単位での操作が行える</li>
+        </ul>
+      </li>
+      <li>socketによる通信部分の実装
+        <ul>
+          <li>GearsOS上でのソケット通信の記述</li>
+        </ul>
+      </li>
+      <li>APIの段階的な設計記述
+        <ul>
+          <li>Proxyによるファイル通信</li>
+        </ul>
+      </li>
+      <li>GearsOSの調査</li>
+    </ul>
+  </li>
+  <li>Streamのリスト単位での通信の完成</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="将来的な課題">将来的な課題</h2>
+<ul>
+  <li>TopoplogyManagerの設計
+    <ul>
+      <li>参加したノードを任意の形のTopologyに接続する機能</li>
+      <li>ファイルシステム向けの機能を追加したい
+        <ul>
+          <li>DNS</li>
+          <li>中枢としてのTopologyのノード監視</li>
+        </ul>
+      </li>
+    </ul>
+  </li>
+  <li>Securityシステムの追加
+    <ul>
+      <li>証明書などによるファイル操作制限</li>
+      <li>不正な分散ファイルシステムへのアクセス</li>
+    </ul>
+  </li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
 <h2 id="gearsosの生成形の問題点">GearsOSの生成形の問題点</h2>
 <ul>
   <li>GearsOSのメタレベルの処理の記述はトランスコンパイラにより行われる</li>
@@ -779,30 +704,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="結論">結論</h2>
-<ul>
-  <li>GearsOSのファイルの設計を行った
-    <ul>
-      <li>ファイルの構造の設計
-        <ul>
-          <li>DataGear単位での操作が行える</li>
-        </ul>
-      </li>
-      <li>socketによる通信部分の実装
-        <ul>
-          <li>GearsOS上でのソケット通信の記述</li>
-        </ul>
-      </li>
-      <li>APIの段階的な設計記述
-        <ul>
-          <li>Proxyによるファイル通信</li>
-        </ul>
-      </li>
-      <li>GearsOSの調査</li>
-    </ul>
-  </li>
-  <li>Streamのリスト単位での通信の完成</li>
-</ul>
+<h2 id="以下返答用">以下返答用</h2>


@@ -810,23 +712,16 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="将来的な課題">将来的な課題</h2>
+<h2 id="takeputpeek-1">Take/Put/Peek</h2>
 <ul>
-  <li>TopoplogyManagerの設計
+  <li>PeekはReadOnly (最新の設定を読みこむなど)</li>
+  <li>Take/PutはDGが一つならUpDataに相当する</li>
+  <li>書き込みが単一スレッドなら順序は保証される</li>
+  <li>書き込みが複数の場合、Putの順序は保証されない</li>
+  <li>データベースとの違い
     <ul>
-      <li>参加したノードを任意の形のTopologyに接続する機能</li>
-      <li>ファイルシステム向けの機能を追加したい
-        <ul>
-          <li>DNS</li>
-          <li>中枢としてのTopologyのノード監視</li>
-        </ul>
-      </li>
-    </ul>
-  </li>
-  <li>Securityシステムの追加
-    <ul>
-      <li>証明書などによるファイル操作制限</li>
-      <li>不正な分散ファイルシステムへのアクセス</li>
+      <li>putがQueueとして蓄積される</li>
+      <li>Keyが一つしかない(通信路として使える)</li>
     </ul>
   </li>
 </ul>
@@ -837,7 +732,14 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="この先保留">この先保留</h2>
+<h2 id="__code-nextint-ret-の意味">__code next(int ret, …)の意味</h2>
+<ul>
+  <li>軽量継続を表す</li>
+  <li>nextは引数として渡されたCodeGear</li>
+  <li>int ret は返す値</li>
+  <li>…は軽量継続の呼び出された時の値渡しのInterface</li>
+  <li>一段の呼び出しStackのような役割になる</li>
+</ul>


@@ -845,14 +747,14 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsosのディレクトリとバックアップ">GearsOSのディレクトリとバックアップ</h2>
+<h2 id="codegearと再帰呼び出し">CodeGearと再帰呼び出し</h2>
 <ul>
-  <li>又吉雄斗による並行研究にて、inodeによるファイルシステムが開発されている</li>
-  <li>赤黒木の非破壊な編集により、ディレクトリの履歴を残すことができる</li>
+  <li>再起呼び出ししなければ関数呼び出し的に使える(末尾再起)</li>
+  <li>再帰呼び出ししたい場合、明示的に自分でStackを作る</li>
+  <li>…はContextにすべて置かれている</li>
+  <li>Processはすべて異なるContextを持っている</li>
+  <li>Context自体は共有されない</li>
 </ul>
-<div style="text-align: center;">
-  　<img src="images/nonDestroyTreeEdit.pdf" alt="非破壊的なツリー編集" width="800" />
-</div>


@@ -860,18 +762,32 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="ファイルqueueに対するapi--peek-">ファイルQueueに対するAPI -Peek-</h2>
+<h2 id="datagearの型">DataGearの型</h2>
 <ul>
-  <li>Peek
+  <li>union Data は一つのプロセス(Context)で使われるすべてのDataGearのUnion</li>
+  <li>メタ部分に型に対応する番号を持っている</li>
+  <li>番号を使って型を識別することができる</li>
+  <li>任意の型を格納できるQueueやStackを作成することが可能</li>
+  <li>メタレベルではunion Dataを使ってDataGearの詳細に立ち入らず処理できる</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="remotedgmとacknowledge">RemoteDGMとacknowledge</h2>
+<ul>
+  <li>Take/Put/Peekのコマンドは TCP上でacknowledgeを使って通信されている</li>
+  <li>これとは別に自分と相手のCodeGearどうしのacknowledgeが必要</li>
+  <li>RemoteDataGearManager経由でacknowledgeを返すのが正しい</li>
+  <li>しかし、acknowledgeが重複してしまう</li>
+  <li>メタプログラミングを利用してこの重複を消すことは可能
     <ul>
-      <li>QueueのElementを参照するが、削除は行わない</li>
-      <li>現時点での実装は行っていない</li>
-      <li>QueueのTopのレコードを変更せずに出力すれば良い
-&lt;!–</li>
+      <li>しかし煩雑</li>
     </ul>
   </li>
-  <li>RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。
-–&gt;</li>
 </ul>

 </div>
--- a/slide/thesis.md	Thu Feb 10 19:20:41 2022 +0900
+++ b/slide/thesis.md	Thu Feb 10 23:55:41 2022 +0900
@@ -1,45 +1,43 @@
 title: GearsOSの分散ファイルシステムの設計
 author: Takahiro Ikki, Shinji Kono
-profile: 琉球大学
+profile: 琉球大学理工学研究科情報工学専攻
 lang: Japanese
 code-engine: coderay


-## GearsOSのファイルシステムの設計方針
-- GearsOSはGearという単位で記述が行われているOSプロジェクトである
-- GearsOSのファイルシステムも同様にDataGearの単位で構成したい
-- GearsOSのファイルシステムの設計と実装を行った
-- ファイルに取り扱うデータに対応した複数のストリームを持たせたい
-  - 従来では異なるデータでも単一のストリームから入力される
-- GearsOSには将来的にアプリケーションが担う重要な機能をOSに取り込みたい
-  - ファイルの型認識
-  - バックアップ
-
-## GearsOSのGear概念(1/2)
-- 関数でなくGearという単位を用いて記述する
-- Gearは関数と異なり、スタックを持たないため軽量継続と呼ぶ
-- CodeGear
-  - 従来のThreadにあたる
-  - goto文(jump命令)を使って遷移する
-- DataGear
-  - 従来の変数データにあたる
+## GearsOSのファイルシステムの設計と実装
+- DataGearとCodeGearという単位を用いるOS
+- 従来のファイルシステムには型とTransactionが無い
+- DataGear単位のTransactionとしてファイルシステムを設計
+- APIとしてTake/Put/Peekを採用した
+- 通信としてもDBアクセスとしても使える(メモリからSSDへの通信に見える)
+- 本研究ではsocket baseな通信とWordCountの例題を作成した


-## GearsOSのGear概念(2/2)
-- CodeGearは処理を行う際、DataGearを参照し処理を行う(InputDataGear)
-- CodeGearは処理の終了後、以降に必要なデータをDataGearとして出力する(OutputDataGear)
+## GearsOSの基本単位
+- CodeGear
+  - 実行Codeの単位
+  - 入力DataGearと出力DataGearを持つ
+  - goto文(jump命令)を使って遷移する
+  - 実行単位は途中で割り込まれたりしない(Atmocity)
+- DataGear
+  - Cの構造体に相当する
+  - ノーマルレベルでは変更されない(関数型プログラミング)
+- C言語を拡張する形でCbC言語により実装される(gcc/llvm)
+
+
+## CodeGearとDataGear
+- InputDataGearを受け取って、CodeGearが処理し、OutputDataGearを出力する
+- OutputDataGearは次のCodeGearのInputDataGearとなる
+- ファイルシステムではDataGearをkeyで待ち合わせる
 <div style="text-align: center;">
   　<img src="images/cg-dg.pdf" alt=cgdgの関係図 width="600">
 </div>

-
-
-
-
 ## GearsOSのInterface
-- Object型指向の仕組み
-- APIとなるCodeGearとその参照するDataGearを宣言する
-- DataGear/CodeGearの一時的な置き場としての役割を持つ
+- JavaのInterfaceに相当する
+- APIとなるCodeGearの名前と型を書く(__next(...)が継続)
+- 引数渡しの構造体として使う(引数はすべてここに定義される必要がある)
 ```
 typedef struct Tree<>{
     union Data* tree;
@@ -51,99 +49,81 @@
 } Tree;
 ```

-## GearsOSのImplement
-- Interfaceを継承した実装の型定義ファイルである
-- 実装で使われるデータ構造を記述する
- ```
- typedef struct SynchronizedQueue <> impl Queue {
-   struct Element* top;
-   struct Element* last;
-   struct Atomic* atomic;
- } SynchronizedQueue;
- ```
-

 ## Interfaceの呼び出し
-- インターフェースは以下の記述で実装と呼び出しを行う
+- createで作成する(通常の関数呼び出し)
+- DataGearとして作成する場合はnewを使う
+- gotoでputAPIを呼び出す(nextは継続)
+- InterfaceなどのDataGearはプロセスに相当するContextにすべて格納される
 ```
-struct Queue* queue = new Queue();
-queue = createSychronizedQueue(context);
-```
-
-```
+struct Queue* queue = createSychronizedQueue(context);
+struct Task* task = new Task();
 goto queue->put(task, next(...));
 ```


-## メタレベルのGear(1/3)
-- CodeGearとDataGearにはユーザーが記述しない、メタレベルのものが存在する
-  - メタレベルな記述はトランスコンパイラにより自動生成される
+## Interfaceの実装
+- Interfaceの実装に使われるデータ構造を記述するImplementがある
+- 実装で使われるDataGearを記述する(ヒープに確保される)
+- create時にAPIを実装するCodeGearをInterfaceの構造体に代入される
+```
+typedef struct SynchronizedQueue <> impl Queue {
+  struct Element* top;
+  struct Element* last;
+  struct Atomic* atomic;
+} SynchronizedQueue;
+```
+
+
+
+## CodeGearとDataGearにはメタレベルなものが存在する
+- メタレベルな記述はトランスコンパイラにより自動生成される(記述することも可能)
+- CodeGearの前後にMetaなCodeGearが挿入される
 <div style="text-align: center;">
 　<img src="images/meta-cg-dg.pdf" alt="ノーマルレベルとメタレベルの視点からのGearの関係" width="800">
 </div>

-## メタレベルのGear(2/3)
-- MetaCodeGear
-  - CodeGearの処理前と処理後に参照される
-  - Input/OutputDataGearを引き渡す
-  - CodeGear処理前に呼ばれるものを特にstubCodeGearと呼ぶ
-<div style="text-align: center;">
-　<img src="images/meta-cg-dg.pdf" alt="ノーマルレベルとメタレベルの視点からのGearの関係" width="800">
-</div>
-
-## メタレベルのGear(3/3)
-- MetaDataGear
-  - MetaCodeGearにて参照されるDataGear
+## stubCodeGearとgoto meta
+- ContextからInputDataGearを取り出す(stubCodeGear)
+- OutputDataGearをContextに書き込み、次のCodeGearを呼び出す(goto meta)
+- stubCodeGear/goto metaは変更可能(メタプログラミング)
 <div style="text-align: center;">
 　<img src="images/meta-cg-dg.pdf" alt="ノーマルレベルとメタレベルの視点からのGearの関係" width="800">
 </div>

 ## GearsOSのファイルシステムの設計
 - DataGearの単位でデータを操作したい
-- 通信データに対応した複数のストリームを持ちたい
-- Transaction(マクロレベル)で操作したい
-  - 従来のファイルシステムは一部の操作のみTransactionである
-- ファイルそのものが通信を担当する
+- 通信データに対応した複数のストリームを持つ
+- Transactionとしてatomicに操作したい
+  - 従来のファイルシステムはTransactionはUserレベルで実装される
+- ファイル操作と通信を同じAPIで実現する
   - ChristieのDataGearManagerを参考にする
+  - Take/Put/Peek

-## GearsOSのファイルデータ操作(1/3)
-- GearsOSはDataGearのやりとりでプログラムが構成される
-  - ファイルシステムも同様の実装にしたい = DataGear単位で操作したい
-<div style="text-align: center;">
-  　<img src="images/QueueElement.pdf" alt=Queueの構造 width="800">
-</div>
-
-## GearsOSのファイルデータ操作(2/3)
-- GearsOSのファイルデータは任意の型を持った構造体で実装される(ファイルレコード)
-- レコードは決められた順番で連続しており、Queueに保存される
+## Take/Put/Peek
+- ファイルはQueueで構成される
+- putでQueueに追加
+- takeでQueueからの取り出し
+- peekでQueueから取り出さない読み出し
 <div style="text-align: center;">
   　<img src="images/QueueElement.pdf" alt=Queueの構造 width="800">
 </div>

-## GearsOSのファイルデータ操作(3/3)
-- 構造体の型を判別することで処理の切り替えが行える
-<div style="text-align: center;">
-  　<img src="images/QueueElement.pdf" alt=Queueの構造 width="800">
-</div>
-
-
 ## GearsFSのトランザクション
-- GearsOSのDataGear操作はマクロな操作である
-  - よってCodeGearはTransactionである
-- ファイルシステム操作もCodeGearで記述されるためTransactionとなる
-- トランザクションな操作によってファイルシステムの整合性の保守が行いやすい
+- GearsOSのCodeGear操作はatomicなので割り込まれない
+  - atomicityはOSが保証する
+  - これによりTake/Put/PeekがTransactionであることを保証する

 ## QueueによるGearsOSのファイル
-- GearsOSのファイルはファイルレコードを保持するQueueとなる
-- デバイスへの保存はQueueを保存すればよい
-- ファイルはQueueなのでファイルのAPIは大きく二つとなる
-  - Put
-  - Take
+- GearsOSのファイルはDataGearを保持するQueueとなる
+- オンメモリのファイルに相当する
+- Queueをデバイスにcopyして持続性を実現する
+- 書き込み先はDataGearManagerで選択する

-## QueueAPI -Put-
-- Put
-  - Queueに対してファイルレコードを入力する
-  - ファイルの変更をレコードとして書き込む
+## PutのImplementation
+- QueueのElementをnewで作成する
+- Queueのリンクを構築する
+- 継続nextに跳ぶ
 ```
 __code putSingleLinkedQueue(struct SingleLinkedQueue* queue, union Data* data, __code next(...)) {
     Element* element = new Element();
@@ -155,10 +135,10 @@
 }
 ```

-## QueueAPI -Take-
-- Take
-  - Queueからファイルレコードを取り出す
-  - Queue内のレコードをループで全て取り出せば良い
+## TakeのImplementation
+- QueueからElement経由でDataGearを取り出す
+- Queueのリンクを修正し、nextでデータを引き渡す
+- Elementには任意の型のDataGearが格納されている
 ```
 __code takeSingleLinkedQueue(struct SingleLinkedQueue* queue, __code next(union Data* data, ...)) {
     printf("take\n");
@@ -174,54 +154,31 @@
 }
 ```

-
-## ファイル通信の構成
-- GearsOSのファイルは大域的に解放された資源としたい
-  - ファイル自信を通信そのものとして実装する
-  - Streamに対しsocket接続により遠隔にアクセスする
-- 分散フレームワークChristieのDataGearManagerの仕組みを利用する
-
-
 ## DataGearManager
-- 分散フレームワークChristieの仕組みの一つ
-- keyとvalueの組み合わせとなるDataGearを保持するデータプール
-- ChristieではCodeGearManagerと呼ばれるノードがCodeGearとDataGearを管理する
-- LocalDGMはノード本体に対応するデータプールである
-  - CodeGearはLocalDGMに対してDataGearを参照する
-- RemoteDGMは接続する相手ノードに対応するデータプールproxyである
-  - RemoteDGMに対してDataGearを書き込むことで、対応するノードのLocalDGMにデータが書き込まれる
+- Take/Put/PeekはDataGearManagerに対して行う
+- メモリ上のQueueはLocalDGMになる
+- RemoteDGMは他のノードやプロセスあるいはストレージデバイスをあらわす
+- 一つのDataGearManager上に複数のQueueがあり、keyで識別する
+- RemoteDGMに書き込むと相手のLocalDGMに書き込まれる
+- Take/Peekは書き込みを待ち合わせる
+- 複数のTakeを待ち合わせることができる

 ## DataGearManagerによる通信構成
 - 任意の相手のRemoteDGMを作成することでTopologyが形成される
+- 手元のRemoteDGMに書き込むと相手のLocalDGMに書き込まれる
+- RemoteDGMはproxyとして動作する
+- この構成は分散フレームワークChristie(当研究室作成)と同じ
 <div style="text-align: center;">
 　<img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="800">
 </div>


-## GearsOS上のsocket通信
-- GearsOS上のsocket通信を実装したい
-- Queueをsocketに接続し、簡易的なAPIの記述をした
-  - Localなqueueに対してRemoteのqueueがソケット接続を行う
-```
-typedef struct CQueue<>{
-    union Data* cQueue;
-    union Data* data;
-
-    __code whenEmpty(...);
-    __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(...);
-} CQueue;
-```
-
-
-## sendData CodeGear
+## socket通信によるRemoteDGMの実装
+- GearsOSはUnix上の言語フレームワークとして実装されている
+- Unixのsocket通信を使ってQueueのputを実装する
 - proxy側はQueueにputされたDataをsocketで送信する
 - 送信されたDataはLocal側でgetDataAPIで取り出される
+- send/recvはUnixのAPI
 ```
 __code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
     char recv_buf;
@@ -234,7 +191,7 @@
 }
 ```

-## getData CodeGear
+## 受信側の実装
 - ファイル本体(Local側)はsocketからDataを取り出す
 - 取り出されたデータはQueueにputされる
 ```
@@ -253,31 +210,26 @@

 ## 複数のストリームから構成されるファイル
 - 入力されるデータに応じた個別のstreamを備えたい
-  - streamと入力されたデータの処理を直接結びつけたい
-- 最低でもInput/OutputStreamの二つが必要となる
-- ファイルは複数のStreamを持ったリストとして実装する
+  - 例えばUSBは複数のチャネルを持つ
+  - メタデータの取り出しは別streamになる
+  - 通信として使う場合に複数のプロトコルがある方が良い(FTP)
 - Streamはkey nameを持ち、keyでアクセスを行う
-
-## 複数のストリームを持つファイルの設計
-- Queueのリストとして赤黒木を用いる
-  - key/value storeなアクセスを行うことができる
-  - GearsOS上にすでに実装が行われている
+- 赤黒木を用いる
 - DataのTake/Put時には必ずkey nameの指定が必要となる

-## リスト単位の通信の構成
-- 指定したkeyのQueueが探索で返される
-- proxyの場合、どのkeyに対してどんなDataを書き込んだかを通信で送信する
+## socketを使ったRemoteDGM
+- RemoteDGMに書き込みが行われるとsocketで通信が起きる
+- 受信側はLocalDGMにDataGearを書き込む
 <div style="text-align: center;">
   　<img src="images/socketCom.pdf" alt=socketを通じたレコード送信 width="800">
 </div>


-
-
-## wordCount例題による通信APIの構築
-- DataGearManagerによるファイル通信APIはWordCount例題を目指して設計した
-  - ファイル内の文字列を1行づつ受け取り、文字列,行数をカウントする例題
+## wordCountの例題
+- ファイル内の文字列を1行づつ受け取り、文字列,行数をカウントする例題
 - 文字列送信側とCount側を別ノード上で行うことで、ファイルの呼び出しと通信処理が構成できる
+- RemoteDGMへの書き込みで通信する
+- acknowredgeを逆方向のRemoteDGMによる通信で実現する(現在は直接送信)
 <div style="text-align: center;">
 　<img src="images/slideGearsWC.pdf" alt="リモートDGMによるWordCount" width="800">
 </div>
@@ -318,6 +270,29 @@
   - リスト単位での通信の記述


+## 結論
+- GearsOSのファイルの設計を行った
+  - ファイルの構造の設計
+    - DataGear単位での操作が行える
+  - socketによる通信部分の実装
+    - GearsOS上でのソケット通信の記述
+  - APIの段階的な設計記述
+    - Proxyによるファイル通信
+  - GearsOSの調査
+- Streamのリスト単位での通信の完成
+
+## 将来的な課題
+- TopoplogyManagerの設計
+  - 参加したノードを任意の形のTopologyに接続する機能
+  - ファイルシステム向けの機能を追加したい
+    - DNS
+    - 中枢としてのTopologyのノード監視
+- Securityシステムの追加
+  - 証明書などによるファイル操作制限
+  - 不正な分散ファイルシステムへのアクセス
+
+
+
 ## GearsOSの生成形の問題点
 - GearsOSのメタレベルの処理の記述はトランスコンパイラにより行われる
 - 場合によりメタレベルの記述を行わなくてはならない
@@ -360,43 +335,43 @@
   - par gotoでの使用を前提としたCodeGearを書かなくてはならない
 - 処理が重いという問題点も存在する

-
-## 結論
-- GearsOSのファイルの設計を行った
-  - ファイルの構造の設計
-    - DataGear単位での操作が行える
-  - socketによる通信部分の実装
-    - GearsOS上でのソケット通信の記述
-  - APIの段階的な設計記述
-    - Proxyによるファイル通信
-  - GearsOSの調査
-- Streamのリスト単位での通信の完成
-
-## 将来的な課題
-- TopoplogyManagerの設計
-  - 参加したノードを任意の形のTopologyに接続する機能
-  - ファイルシステム向けの機能を追加したい
-    - DNS
-    - 中枢としてのTopologyのノード監視
-- Securityシステムの追加
-  - 証明書などによるファイル操作制限
-  - 不正な分散ファイルシステムへのアクセス
-
-## この先保留
-
-## GearsOSのディレクトリとバックアップ
-- 又吉雄斗による並行研究にて、inodeによるファイルシステムが開発されている
-- 赤黒木の非破壊な編集により、ディレクトリの履歴を残すことができる
-<div style="text-align: center;">
-  　<img src="images/nonDestroyTreeEdit.pdf" alt=非破壊的なツリー編集 width="800">
-</div>
+## 以下返答用


-## ファイルQueueに対するAPI -Peek-
-- Peek
-  - QueueのElementを参照するが、削除は行わない
-  - 現時点での実装は行っていない
-  - QueueのTopのレコードを変更せずに出力すれば良い
-<!--
-- RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。
--->
+## Take/Put/Peek
+- PeekはReadOnly (最新の設定を読みこむなど)
+- Take/PutはDGが一つならUpDataに相当する
+- 書き込みが単一スレッドなら順序は保証される
+- 書き込みが複数の場合、Putの順序は保証されない
+- データベースとの違い
+  - putがQueueとして蓄積される
+  - Keyが一つしかない(通信路として使える)
+
+## __code next(int ret, ...)の意味
+- 軽量継続を表す
+- nextは引数として渡されたCodeGear
+- int ret は返す値
+- ...は軽量継続の呼び出された時の値渡しのInterface
+- 一段の呼び出しStackのような役割になる
+
+## CodeGearと再帰呼び出し
+- 再起呼び出ししなければ関数呼び出し的に使える(末尾再起)
+- 再帰呼び出ししたい場合、明示的に自分でStackを作る
+- ...はContextにすべて置かれている
+- Processはすべて異なるContextを持っている
+- Context自体は共有されない
+
+## DataGearの型
+- union Data は一つのプロセス(Context)で使われるすべてのDataGearのUnion
+- メタ部分に型に対応する番号を持っている
+- 番号を使って型を識別することができる
+- 任意の型を格納できるQueueやStackを作成することが可能
+- メタレベルではunion Dataを使ってDataGearの詳細に立ち入らず処理できる
+
+## RemoteDGMとacknowledge
+- Take/Put/Peekのコマンドは TCP上でacknowledgeを使って通信されている
+- これとは別に自分と相手のCodeGearどうしのacknowledgeが必要
+- RemoteDataGearManager経由でacknowledgeを返すのが正しい
+- しかし、acknowledgeが重複してしまう
+- メタプログラミングを利用してこの重複を消すことは可能
+  - しかし煩雑
--- a/slide/thesis.pdf.html	Thu Feb 10 19:20:41 2022 +0900
+++ b/slide/thesis.pdf.html	Thu Feb 10 23:55:41 2022 +0900
@@ -63,7 +63,7 @@
         <td>
           <div align="left">
                Takahiro Ikki, Shinji Kono
-               琉球大学
+               琉球大学理工学研究科情報工学専攻
             <hr style="color:#ffcc00;background-color:#ffcc00;text-align:left;border:none;width:100%;height:0.2em;">
           </div>
         </td>
@@ -75,22 +75,14 @@
 <div class='slide'>

 <!-- _S9SLIDE_ -->
-<h2 id="gearsosのファイルシステムの設計方針">GearsOSのファイルシステムの設計方針</h2>
+<h2 id="gearsosのファイルシステムの設計と実装">GearsOSのファイルシステムの設計と実装</h2>
 <ul>
-  <li>GearsOSはGearという単位で記述が行われているOSプロジェクトである</li>
-  <li>GearsOSのファイルシステムも同様にDataGearの単位で構成したい</li>
-  <li>GearsOSのファイルシステムの設計と実装を行った</li>
-  <li>ファイルに取り扱うデータに対応した複数のストリームを持たせたい
-    <ul>
-      <li>従来では異なるデータでも単一のストリームから入力される</li>
-    </ul>
-  </li>
-  <li>GearsOSには将来的にアプリケーションが担う重要な機能をOSに取り込みたい
-    <ul>
-      <li>ファイルの型認識</li>
-      <li>バックアップ</li>
-    </ul>
-  </li>
+  <li>DataGearとCodeGearという単位を用いるOS</li>
+  <li>従来のファイルシステムには型とTransactionが無い</li>
+  <li>DataGear単位のTransactionとしてファイルシステムを設計</li>
+  <li>APIとしてTake/Put/Peekを採用した</li>
+  <li>通信としてもDBアクセスとしても使える(メモリからSSDへの通信に見える)</li>
+  <li>本研究ではsocket baseな通信とWordCountの例題を作成した</li>
 </ul>


@@ -99,21 +91,23 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsosのgear概念12">GearsOSのGear概念(1/2)</h2>
+<h2 id="gearsosの基本単位">GearsOSの基本単位</h2>
 <ul>
-  <li>関数でなくGearという単位を用いて記述する</li>
-  <li>Gearは関数と異なり、スタックを持たないため軽量継続と呼ぶ</li>
   <li>CodeGear
     <ul>
-      <li>従来のThreadにあたる</li>
+      <li>実行Codeの単位</li>
+      <li>入力DataGearと出力DataGearを持つ</li>
       <li>goto文(jump命令)を使って遷移する</li>
+      <li>実行単位は途中で割り込まれたりしない(Atmocity)</li>
     </ul>
   </li>
   <li>DataGear
     <ul>
-      <li>従来の変数データにあたる</li>
+      <li>Cの構造体に相当する</li>
+      <li>ノーマルレベルでは変更されない(関数型プログラミング)</li>
     </ul>
   </li>
+  <li>C言語を拡張する形でCbC言語により実装される(gcc/llvm)</li>
 </ul>


@@ -122,10 +116,11 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsosのgear概念22">GearsOSのGear概念(2/2)</h2>
+<h2 id="codegearとdatagear">CodeGearとDataGear</h2>
 <ul>
-  <li>CodeGearは処理を行う際、DataGearを参照し処理を行う(InputDataGear)</li>
-  <li>CodeGearは処理の終了後、以降に必要なデータをDataGearとして出力する(OutputDataGear)</li>
+  <li>InputDataGearを受け取って、CodeGearが処理し、OutputDataGearを出力する</li>
+  <li>OutputDataGearは次のCodeGearのInputDataGearとなる</li>
+  <li>ファイルシステムではDataGearをkeyで待ち合わせる</li>
 </ul>
 <div style="text-align: center;">
   　<img src="images/cg-dg.pdf" alt="cgdgの関係図" width="600" />
@@ -139,9 +134,9 @@
   <!-- _S9SLIDE_ -->
 <h2 id="gearsosのinterface">GearsOSのInterface</h2>
 <ul>
-  <li>Object型指向の仕組み</li>
-  <li>APIとなるCodeGearとその参照するDataGearを宣言する</li>
-  <li>DataGear/CodeGearの一時的な置き場としての役割を持つ
+  <li>JavaのInterfaceに相当する</li>
+  <li>APIとなるCodeGearの名前と型を書く(__next(…)が継続)</li>
+  <li>引数渡しの構造体として使う(引数はすべてここに定義される必要がある)
     <pre><code>typedef struct Tree&lt;&gt;{
   union Data* tree;
   struct Node* node;
@@ -160,15 +155,15 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsosのimplement">GearsOSのImplement</h2>
+<h2 id="interfaceの呼び出し">Interfaceの呼び出し</h2>
 <ul>
-  <li>Interfaceを継承した実装の型定義ファイルである</li>
-  <li>実装で使われるデータ構造を記述する
-    <pre><code> typedef struct SynchronizedQueue &lt;&gt; impl Queue {
- struct Element* top;
- struct Element* last;
- struct Atomic* atomic;
- } SynchronizedQueue;
+  <li>createで作成する(通常の関数呼び出し)</li>
+  <li>DataGearとして作成する場合はnewを使う</li>
+  <li>gotoでputAPIを呼び出す(nextは継続)</li>
+  <li>InterfaceなどのDataGearはプロセスに相当するContextにすべて格納される
+    <pre><code>struct Queue* queue = createSychronizedQueue(context);
+struct Task* task = new Task();
+goto queue-&gt;put(task, next(...));
 </code></pre>
   </li>
 </ul>
@@ -179,31 +174,30 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="interfaceの呼び出し">Interfaceの呼び出し</h2>
+<h2 id="interfaceの実装">Interfaceの実装</h2>
 <ul>
-  <li>インターフェースは以下の記述で実装と呼び出しを行う
-    <pre><code>struct Queue* queue = new Queue();
-queue = createSychronizedQueue(context);
+  <li>Interfaceの実装に使われるデータ構造を記述するImplementがある</li>
+  <li>実装で使われるDataGearを記述する(ヒープに確保される)</li>
+  <li>create時にAPIを実装するCodeGearをInterfaceの構造体に代入される
+    <pre><code>typedef struct SynchronizedQueue &lt;&gt; impl Queue {
+struct Element* top;
+struct Element* last;
+struct Atomic* atomic;
+} SynchronizedQueue;
 </code></pre>
   </li>
 </ul>

-<pre><code>goto queue-&gt;put(task, next(...));
-</code></pre>
-


 </div>

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="メタレベルのgear13">メタレベルのGear(1/3)</h2>
+<h2 id="codegearとdatagearにはメタレベルなものが存在する">CodeGearとDataGearにはメタレベルなものが存在する</h2>
 <ul>
-  <li>CodeGearとDataGearにはユーザーが記述しない、メタレベルのものが存在する
-    <ul>
-      <li>メタレベルな記述はトランスコンパイラにより自動生成される</li>
-    </ul>
-  </li>
+  <li>メタレベルな記述はトランスコンパイラにより自動生成される(記述することも可能)</li>
+  <li>CodeGearの前後にMetaなCodeGearが挿入される</li>
 </ul>
 <div style="text-align: center;">
 　<img src="images/meta-cg-dg.pdf" alt="ノーマルレベルとメタレベルの視点からのGearの関係" width="800" />
@@ -215,33 +209,11 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="メタレベルのgear23">メタレベルのGear(2/3)</h2>
+<h2 id="stubcodegearとgoto-meta">stubCodeGearとgoto meta</h2>
 <ul>
-  <li>MetaCodeGear
-    <ul>
-      <li>CodeGearの処理前と処理後に参照される</li>
-      <li>Input/OutputDataGearを引き渡す</li>
-      <li>CodeGear処理前に呼ばれるものを特にstubCodeGearと呼ぶ</li>
-    </ul>
-  </li>
-</ul>
-<div style="text-align: center;">
-　<img src="images/meta-cg-dg.pdf" alt="ノーマルレベルとメタレベルの視点からのGearの関係" width="800" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="メタレベルのgear33">メタレベルのGear(3/3)</h2>
-<ul>
-  <li>MetaDataGear
-    <ul>
-      <li>MetaCodeGearにて参照されるDataGear</li>
-    </ul>
-  </li>
+  <li>ContextからInputDataGearを取り出す(stubCodeGear)</li>
+  <li>OutputDataGearをContextに書き込み、次のCodeGearを呼び出す(goto meta)</li>
+  <li>stubCodeGear/goto metaは変更可能(メタプログラミング)</li>
 </ul>
 <div style="text-align: center;">
 　<img src="images/meta-cg-dg.pdf" alt="ノーマルレベルとメタレベルの視点からのGearの関係" width="800" />
@@ -256,15 +228,16 @@
 <h2 id="gearsosのファイルシステムの設計">GearsOSのファイルシステムの設計</h2>
 <ul>
   <li>DataGearの単位でデータを操作したい</li>
-  <li>通信データに対応した複数のストリームを持ちたい</li>
-  <li>Transaction(マクロレベル)で操作したい
+  <li>通信データに対応した複数のストリームを持つ</li>
+  <li>Transactionとしてatomicに操作したい
     <ul>
-      <li>従来のファイルシステムは一部の操作のみTransactionである</li>
+      <li>従来のファイルシステムはTransactionはUserレベルで実装される</li>
     </ul>
   </li>
-  <li>ファイルそのものが通信を担当する
+  <li>ファイル操作と通信を同じAPIで実現する
     <ul>
       <li>ChristieのDataGearManagerを参考にする</li>
+      <li>Take/Put/Peek</li>
     </ul>
   </li>
 </ul>
@@ -275,42 +248,12 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsosのファイルデータ操作13">GearsOSのファイルデータ操作(1/3)</h2>
+<h2 id="takeputpeek">Take/Put/Peek</h2>
 <ul>
-  <li>GearsOSはDataGearのやりとりでプログラムが構成される
-    <ul>
-      <li>ファイルシステムも同様の実装にしたい = DataGear単位で操作したい</li>
-    </ul>
-  </li>
-</ul>
-<div style="text-align: center;">
-  　<img src="images/QueueElement.pdf" alt="Queueの構造" width="800" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="gearsosのファイルデータ操作23">GearsOSのファイルデータ操作(2/3)</h2>
-<ul>
-  <li>GearsOSのファイルデータは任意の型を持った構造体で実装される(ファイルレコード)</li>
-  <li>レコードは決められた順番で連続しており、Queueに保存される</li>
-</ul>
-<div style="text-align: center;">
-  　<img src="images/QueueElement.pdf" alt="Queueの構造" width="800" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="gearsosのファイルデータ操作33">GearsOSのファイルデータ操作(3/3)</h2>
-<ul>
-  <li>構造体の型を判別することで処理の切り替えが行える</li>
+  <li>ファイルはQueueで構成される</li>
+  <li>putでQueueに追加</li>
+  <li>takeでQueueからの取り出し</li>
+  <li>peekでQueueから取り出さない読み出し</li>
 </ul>
 <div style="text-align: center;">
   　<img src="images/QueueElement.pdf" alt="Queueの構造" width="800" />
@@ -324,55 +267,10 @@
   <!-- _S9SLIDE_ -->
 <h2 id="gearsfsのトランザクション">GearsFSのトランザクション</h2>
 <ul>
-  <li>GearsOSのDataGear操作はマクロな操作である
-    <ul>
-      <li>よってCodeGearはTransactionである</li>
-    </ul>
-  </li>
-  <li>ファイルシステム操作もCodeGearで記述されるためTransactionとなる</li>
-  <li>トランザクションな操作によってファイルシステムの整合性の保守が行いやすい</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="queueによるgearsosのファイル">QueueによるGearsOSのファイル</h2>
-<ul>
-  <li>GearsOSのファイルはファイルレコードを保持するQueueとなる</li>
-  <li>デバイスへの保存はQueueを保存すればよい</li>
-  <li>ファイルはQueueなのでファイルのAPIは大きく二つとなる
+  <li>GearsOSのCodeGear操作はatomicなので割り込まれない
     <ul>
-      <li>Put</li>
-      <li>Take</li>
-    </ul>
-  </li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="queueapi--put-">QueueAPI -Put-</h2>
-<ul>
-  <li>Put
-    <ul>
-      <li>Queueに対してファイルレコードを入力する</li>
-      <li>ファイルの変更をレコードとして書き込む
-        <pre><code>__code putSingleLinkedQueue(struct SingleLinkedQueue* queue, union Data* data, __code next(...)) {
-Element* element = new Element();
-element-&gt;data = data;
-element-&gt;next = NULL;
-queue-&gt;last-&gt;next  = element;
-queue-&gt;last = element;
-goto next(...);
-}
-</code></pre>
-      </li>
+      <li>atomicityはOSが保証する</li>
+      <li>これによりTake/Put/PeekがTransactionであることを保証する</li>
     </ul>
   </li>
 </ul>
@@ -383,27 +281,34 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="queueapi--take-">QueueAPI -Take-</h2>
+<h2 id="queueによるgearsosのファイル">QueueによるGearsOSのファイル</h2>
 <ul>
-  <li>Take
-    <ul>
-      <li>Queueからファイルレコードを取り出す</li>
-      <li>Queue内のレコードをループで全て取り出せば良い
-        <pre><code>__code takeSingleLinkedQueue(struct SingleLinkedQueue* queue, __code next(union Data* data, ...)) {
-printf("take\n");
-struct Element* top = queue-&gt;top;
-struct Element* nextElement = top-&gt;next;
-if (queue-&gt;top == queue-&gt;last) {
-    data = NULL;
-} else {
-    queue-&gt;top = nextElement;
-    data = nextElement-&gt;data;
-}
-goto next(data, ...);
+  <li>GearsOSのファイルはDataGearを保持するQueueとなる</li>
+  <li>オンメモリのファイルに相当する</li>
+  <li>Queueをデバイスにcopyして持続性を実現する</li>
+  <li>書き込み先はDataGearManagerで選択する</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="putのimplementation">PutのImplementation</h2>
+<ul>
+  <li>QueueのElementをnewで作成する</li>
+  <li>Queueのリンクを構築する</li>
+  <li>継続nextに跳ぶ
+    <pre><code>__code putSingleLinkedQueue(struct SingleLinkedQueue* queue, union Data* data, __code next(...)) {
+  Element* element = new Element();
+  element-&gt;data = data;
+  element-&gt;next = NULL;
+  queue-&gt;last-&gt;next  = element;
+  queue-&gt;last = element;
+  goto next(...);
 }
 </code></pre>
-      </li>
-    </ul>
   </li>
 </ul>

@@ -413,15 +318,25 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="ファイル通信の構成">ファイル通信の構成</h2>
+<h2 id="takeのimplementation">TakeのImplementation</h2>
 <ul>
-  <li>GearsOSのファイルは大域的に解放された資源としたい
-    <ul>
-      <li>ファイル自信を通信そのものとして実装する</li>
-      <li>Streamに対しsocket接続により遠隔にアクセスする</li>
-    </ul>
+  <li>QueueからElement経由でDataGearを取り出す</li>
+  <li>Queueのリンクを修正し、nextでデータを引き渡す</li>
+  <li>Elementには任意の型のDataGearが格納されている
+    <pre><code>__code takeSingleLinkedQueue(struct SingleLinkedQueue* queue, __code next(union Data* data, ...)) {
+  printf("take\n");
+  struct Element* top = queue-&gt;top;
+  struct Element* nextElement = top-&gt;next;
+  if (queue-&gt;top == queue-&gt;last) {
+      data = NULL;
+  } else {
+      queue-&gt;top = nextElement;
+      data = nextElement-&gt;data;
+  }
+  goto next(data, ...);
+}
+</code></pre>
   </li>
-  <li>分散フレームワークChristieのDataGearManagerの仕組みを利用する</li>
 </ul>


@@ -432,19 +347,13 @@
   <!-- _S9SLIDE_ -->
 <h2 id="datagearmanager">DataGearManager</h2>
 <ul>
-  <li>分散フレームワークChristieの仕組みの一つ</li>
-  <li>keyとvalueの組み合わせとなるDataGearを保持するデータプール</li>
-  <li>ChristieではCodeGearManagerと呼ばれるノードがCodeGearとDataGearを管理する</li>
-  <li>LocalDGMはノード本体に対応するデータプールである
-    <ul>
-      <li>CodeGearはLocalDGMに対してDataGearを参照する</li>
-    </ul>
-  </li>
-  <li>RemoteDGMは接続する相手ノードに対応するデータプールproxyである
-    <ul>
-      <li>RemoteDGMに対してDataGearを書き込むことで、対応するノードのLocalDGMにデータが書き込まれる</li>
-    </ul>
-  </li>
+  <li>Take/Put/PeekはDataGearManagerに対して行う</li>
+  <li>メモリ上のQueueはLocalDGMになる</li>
+  <li>RemoteDGMは他のノードやプロセスあるいはストレージデバイスをあらわす</li>
+  <li>一つのDataGearManager上に複数のQueueがあり、keyで識別する</li>
+  <li>RemoteDGMに書き込むと相手のLocalDGMに書き込まれる</li>
+  <li>Take/Peekは書き込みを待ち合わせる</li>
+  <li>複数のTakeを待ち合わせることができる</li>
 </ul>


@@ -456,6 +365,9 @@
 <h2 id="datagearmanagerによる通信構成">DataGearManagerによる通信構成</h2>
 <ul>
   <li>任意の相手のRemoteDGMを作成することでTopologyが形成される</li>
+  <li>手元のRemoteDGMに書き込むと相手のLocalDGMに書き込まれる</li>
+  <li>RemoteDGMはproxyとして動作する</li>
+  <li>この構成は分散フレームワークChristie(当研究室作成)と同じ</li>
 </ul>
 <div style="text-align: center;">
 　<img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="800" />
@@ -467,41 +379,13 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsos上のsocket通信">GearsOS上のsocket通信</h2>
+<h2 id="socket通信によるremotedgmの実装">socket通信によるRemoteDGMの実装</h2>
 <ul>
-  <li>GearsOS上のsocket通信を実装したい</li>
-  <li>Queueをsocketに接続し、簡易的なAPIの記述をした
-    <ul>
-      <li>Localなqueueに対してRemoteのqueueがソケット接続を行う
-        <pre><code>typedef struct CQueue&lt;&gt;{
-union Data* cQueue;
-union Data* data;
-
-__code whenEmpty(...);
-__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(...);
-} CQueue;
-</code></pre>
-      </li>
-    </ul>
-  </li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="senddata-codegear">sendData CodeGear</h2>
-<ul>
+  <li>GearsOSはUnix上の言語フレームワークとして実装されている</li>
+  <li>Unixのsocket通信を使ってQueueのputを実装する</li>
   <li>proxy側はQueueにputされたDataをsocketで送信する</li>
-  <li>送信されたDataはLocal側でgetDataAPIで取り出される
+  <li>送信されたDataはLocal側でgetDataAPIで取り出される</li>
+  <li>send/recvはUnixのAPI
     <pre><code>__code sendDataRemoteDGMQueue(struct RemoteDGMQueue* cQueue, union Data* data, __code next(...), __code whenError(...)){
   char recv_buf;
   int send_size, recv_size;
@@ -521,7 +405,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="getdata-codegear">getData CodeGear</h2>
+<h2 id="受信側の実装">受信側の実装</h2>
 <ul>
   <li>ファイル本体(Local側)はsocketからDataを取り出す</li>
   <li>取り出されたデータはQueueにputされる
@@ -550,28 +434,13 @@
 <ul>
   <li>入力されるデータに応じた個別のstreamを備えたい
     <ul>
-      <li>streamと入力されたデータの処理を直接結びつけたい</li>
+      <li>例えばUSBは複数のチャネルを持つ</li>
+      <li>メタデータの取り出しは別streamになる</li>
+      <li>通信として使う場合に複数のプロトコルがある方が良い(FTP)</li>
     </ul>
   </li>
-  <li>最低でもInput/OutputStreamの二つが必要となる</li>
-  <li>ファイルは複数のStreamを持ったリストとして実装する</li>
   <li>Streamはkey nameを持ち、keyでアクセスを行う</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="複数のストリームを持つファイルの設計">複数のストリームを持つファイルの設計</h2>
-<ul>
-  <li>Queueのリストとして赤黒木を用いる
-    <ul>
-      <li>key/value storeなアクセスを行うことができる</li>
-      <li>GearsOS上にすでに実装が行われている</li>
-    </ul>
-  </li>
+  <li>赤黒木を用いる</li>
   <li>DataのTake/Put時には必ずkey nameの指定が必要となる</li>
 </ul>

@@ -581,10 +450,10 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="リスト単位の通信の構成">リスト単位の通信の構成</h2>
+<h2 id="socketを使ったremotedgm">socketを使ったRemoteDGM</h2>
 <ul>
-  <li>指定したkeyのQueueが探索で返される</li>
-  <li>proxyの場合、どのkeyに対してどんなDataを書き込んだかを通信で送信する</li>
+  <li>RemoteDGMに書き込みが行われるとsocketで通信が起きる</li>
+  <li>受信側はLocalDGMにDataGearを書き込む</li>
 </ul>
 <div style="text-align: center;">
   　<img src="images/socketCom.pdf" alt="socketを通じたレコード送信" width="800" />
@@ -596,14 +465,12 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="wordcount例題による通信apiの構築">wordCount例題による通信APIの構築</h2>
+<h2 id="wordcountの例題">wordCountの例題</h2>
 <ul>
-  <li>DataGearManagerによるファイル通信APIはWordCount例題を目指して設計した
-    <ul>
-      <li>ファイル内の文字列を1行づつ受け取り、文字列,行数をカウントする例題</li>
-    </ul>
-  </li>
+  <li>ファイル内の文字列を1行づつ受け取り、文字列,行数をカウントする例題</li>
   <li>文字列送信側とCount側を別ノード上で行うことで、ファイルの呼び出しと通信処理が構成できる</li>
+  <li>RemoteDGMへの書き込みで通信する</li>
+  <li>acknowredgeを逆方向のRemoteDGMによる通信で実現する(現在は直接送信)</li>
 </ul>
 <div style="text-align: center;">
 　<img src="images/slideGearsWC.pdf" alt="リモートDGMによるWordCount" width="800" />
@@ -694,6 +561,64 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
+<h2 id="結論">結論</h2>
+<ul>
+  <li>GearsOSのファイルの設計を行った
+    <ul>
+      <li>ファイルの構造の設計
+        <ul>
+          <li>DataGear単位での操作が行える</li>
+        </ul>
+      </li>
+      <li>socketによる通信部分の実装
+        <ul>
+          <li>GearsOS上でのソケット通信の記述</li>
+        </ul>
+      </li>
+      <li>APIの段階的な設計記述
+        <ul>
+          <li>Proxyによるファイル通信</li>
+        </ul>
+      </li>
+      <li>GearsOSの調査</li>
+    </ul>
+  </li>
+  <li>Streamのリスト単位での通信の完成</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="将来的な課題">将来的な課題</h2>
+<ul>
+  <li>TopoplogyManagerの設計
+    <ul>
+      <li>参加したノードを任意の形のTopologyに接続する機能</li>
+      <li>ファイルシステム向けの機能を追加したい
+        <ul>
+          <li>DNS</li>
+          <li>中枢としてのTopologyのノード監視</li>
+        </ul>
+      </li>
+    </ul>
+  </li>
+  <li>Securityシステムの追加
+    <ul>
+      <li>証明書などによるファイル操作制限</li>
+      <li>不正な分散ファイルシステムへのアクセス</li>
+    </ul>
+  </li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
 <h2 id="gearsosの生成形の問題点">GearsOSの生成形の問題点</h2>
 <ul>
   <li>GearsOSのメタレベルの処理の記述はトランスコンパイラにより行われる</li>
@@ -763,30 +688,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="結論">結論</h2>
-<ul>
-  <li>GearsOSのファイルの設計を行った
-    <ul>
-      <li>ファイルの構造の設計
-        <ul>
-          <li>DataGear単位での操作が行える</li>
-        </ul>
-      </li>
-      <li>socketによる通信部分の実装
-        <ul>
-          <li>GearsOS上でのソケット通信の記述</li>
-        </ul>
-      </li>
-      <li>APIの段階的な設計記述
-        <ul>
-          <li>Proxyによるファイル通信</li>
-        </ul>
-      </li>
-      <li>GearsOSの調査</li>
-    </ul>
-  </li>
-  <li>Streamのリスト単位での通信の完成</li>
-</ul>
+<h2 id="以下返答用">以下返答用</h2>


@@ -794,23 +696,16 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="将来的な課題">将来的な課題</h2>
+<h2 id="takeputpeek-1">Take/Put/Peek</h2>
 <ul>
-  <li>TopoplogyManagerの設計
+  <li>PeekはReadOnly (最新の設定を読みこむなど)</li>
+  <li>Take/PutはDGが一つならUpDataに相当する</li>
+  <li>書き込みが単一スレッドなら順序は保証される</li>
+  <li>書き込みが複数の場合、Putの順序は保証されない</li>
+  <li>データベースとの違い
     <ul>
-      <li>参加したノードを任意の形のTopologyに接続する機能</li>
-      <li>ファイルシステム向けの機能を追加したい
-        <ul>
-          <li>DNS</li>
-          <li>中枢としてのTopologyのノード監視</li>
-        </ul>
-      </li>
-    </ul>
-  </li>
-  <li>Securityシステムの追加
-    <ul>
-      <li>証明書などによるファイル操作制限</li>
-      <li>不正な分散ファイルシステムへのアクセス</li>
+      <li>putがQueueとして蓄積される</li>
+      <li>Keyが一つしかない(通信路として使える)</li>
     </ul>
   </li>
 </ul>
@@ -821,7 +716,14 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="この先保留">この先保留</h2>
+<h2 id="__code-nextint-ret-の意味">__code next(int ret, …)の意味</h2>
+<ul>
+  <li>軽量継続を表す</li>
+  <li>nextは引数として渡されたCodeGear</li>
+  <li>int ret は返す値</li>
+  <li>…は軽量継続の呼び出された時の値渡しのInterface</li>
+  <li>一段の呼び出しStackのような役割になる</li>
+</ul>


@@ -829,14 +731,14 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="gearsosのディレクトリとバックアップ">GearsOSのディレクトリとバックアップ</h2>
+<h2 id="codegearと再帰呼び出し">CodeGearと再帰呼び出し</h2>
 <ul>
-  <li>又吉雄斗による並行研究にて、inodeによるファイルシステムが開発されている</li>
-  <li>赤黒木の非破壊な編集により、ディレクトリの履歴を残すことができる</li>
+  <li>再起呼び出ししなければ関数呼び出し的に使える(末尾再起)</li>
+  <li>再帰呼び出ししたい場合、明示的に自分でStackを作る</li>
+  <li>…はContextにすべて置かれている</li>
+  <li>Processはすべて異なるContextを持っている</li>
+  <li>Context自体は共有されない</li>
 </ul>
-<div style="text-align: center;">
-  　<img src="images/nonDestroyTreeEdit.pdf" alt="非破壊的なツリー編集" width="800" />
-</div>


@@ -844,18 +746,32 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="ファイルqueueに対するapi--peek-">ファイルQueueに対するAPI -Peek-</h2>
+<h2 id="datagearの型">DataGearの型</h2>
 <ul>
-  <li>Peek
+  <li>union Data は一つのプロセス(Context)で使われるすべてのDataGearのUnion</li>
+  <li>メタ部分に型に対応する番号を持っている</li>
+  <li>番号を使って型を識別することができる</li>
+  <li>任意の型を格納できるQueueやStackを作成することが可能</li>
+  <li>メタレベルではunion Dataを使ってDataGearの詳細に立ち入らず処理できる</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="remotedgmとacknowledge">RemoteDGMとacknowledge</h2>
+<ul>
+  <li>Take/Put/Peekのコマンドは TCP上でacknowledgeを使って通信されている</li>
+  <li>これとは別に自分と相手のCodeGearどうしのacknowledgeが必要</li>
+  <li>RemoteDataGearManager経由でacknowledgeを返すのが正しい</li>
+  <li>しかし、acknowledgeが重複してしまう</li>
+  <li>メタプログラミングを利用してこの重複を消すことは可能
     <ul>
-      <li>QueueのElementを参照するが、削除は行わない</li>
-      <li>現時点での実装は行っていない</li>
-      <li>QueueのTopのレコードを変更せずに出力すれば良い
-&lt;!–</li>
+      <li>しかし煩雑</li>
     </ul>
   </li>
-  <li>RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。
-–&gt;</li>
 </ul>

 </div>