# HG changeset patch
# User autobackup
# Date 1622041803 -32400
# Node ID 6c46d8f76ec4801ff5bb029bd02c36fde21bd157
# Parent a4f167def66b2568c731d21fa2ec41934d82da48
backup 2021-05-27
diff -r a4f167def66b -r 6c46d8f76ec4 user/Itsuki/sigos2021.md
--- a/user/Itsuki/sigos2021.md Wed May 26 00:10:03 2021 +0900
+++ b/user/Itsuki/sigos2021.md Thu May 27 00:10:03 2021 +0900
@@ -1,126 +1,118 @@
# GearsOSの分散ファイルシステムの設計
-author: Takahiro Ikki, Shinji Kono
-profile: 琉球大学
+author: 一木 貴裕, 河野 真治
+
+profile: 琉球大学理工学研究科情報工学専攻 河野研究室
+
lang: Japanese
+
code-engine: coderay
-## メモ
-従来のファイルシステムの問題を加える、
-
-
-## 研究概要
-- 当研究室ではOSの信頼性と拡張性の保証を目的としたGearsOSを開発している。
- - GearsOSは開発途上であり、実装が必要な機能が複数存在している。
-- GearsOSの分散ファイルシステムを開発したい。
-- 分散フレームワークChristieの構成をもとにGearsファイルシステムを構築する。
-- ファイルシステムの通信機構としてChristieが持つTopologyManagerという機能を使いたい。
+## OSと密に結合したファイルシステムの設計
+- 信頼性と拡張性の保証を目的としたGearsOSを開発中
+- GearsOSの分散ファイルシステムを開発したい
+- 分散フレームワークChristieの構成をもとにする
+- Christieが持つTopologyManagerという機能を使う
+ - プログラムの通信とストレージの接続を管理する
## 従来のファイルシステムの問題点
-- 総括的なファイルシステムAPIをTransactionとして提供していない。
- - 個別のファイルをロックする仕組み。
- - ディレクトリの名前の置き換えをトランザクションとして扱う。
-- ファイルの型がないという問題
- - 現状アプリケーションがファイルの処理を決めている？
- - OS自体がファイルの型を区分し、認識する必要性。
-- DBでない
-- 型
-- 名前がデータベースのkeyになっていない
- - uuidな名前を
-- ファイル単位
-- 分散
- - ファイルの位置、いろいろなところに
-- 重複度
- - 安全性、散らばったファイルは消せなくなる
- - 散らばったファイルを消したい
-- リカバリ
- - バックアップ、
-- 暗号化
-- 署名
- - 二重鍵、相互にエンコードデコードできる、ファイルを作成した人の判定、
- - 公開鍵からエンコードして秘密鍵を持っている人だけが読めるように
- - ファイルシステム自体にこの仕組みがない、メタデータで署名を持つ,
- - macOSは独自で持っている
- - ファイル全体を署名するのはおかしい
- - 鍵の管理もOSがしたい
-## GearsOS概要
-- アプリケーションを動かすOSには高い信頼性が保証されている必要がある。
-- OSの処理やコードの量は膨大であり、テストコードを用いた信頼性の保証は困難であると言える。
- - したがって数学的な背景に基づいた定理支援証明やモデル検査などの形式手法を用いて検証したい。
-- OSを形式手法にて証明するには状態遷移単位での記述が求められる。
-- メタレベルとノーマルレベルの計算を分離して記述が行える構成が必要となる。
- - メタレベルの計算でプログラムの整合性を検証する。
+- データベースになっていない
+- 重複度やリカバリをアプリケーションが担当している
+- 暗号化などのセキュリティもアプリケーションが担当している
+- OS自体がこれらの機能を持つのが望ましい
+
+### 従来のファイルシステムのトランザクション
+- レコードのTransactionとして提供していない
+ - 提供しているのは
+ - ファイルのロック
+ - ディレクトリの名前の置き換え
+- FileSystemのAPIを総括してトランザクションとして設計したい
+
+### ファイルの型
+- OSレベルから見たファイルの型が存在しない
+ - 実行形式のみをOSが認識している
+ - 型の区別はアプリケーションに委ねられている
+ - lsとreadmeなどの型の区別がつかない
+- OS自体がファイルの型を見分けるように設計したい
+
+### ファイルの名前自体がデータベースのkeyとなっていない
+- 従来ではファイル固有のIDとファイル名を紐付けしたりする
+- 様々なファイル単位が混同になっている
+ - 複数のレコード
+ - 複数の表
+ - sqlite3
+- OS自体がユニークなファイルIDのリストを保持する設計にしたい
+
+### 重複度とファイルリカバリ
+- ファイルの複製が行われた際の安全性が確保できない
+- バックアップデータを勝手な場所に置かれてしまう
+ - バックアップデータをOSが管理する
+
+### 署名と暗号化
+- ファイルの署名もしくは暗号化の機能をOSファイルシステムに持たせたい
+- 公開鍵と秘密鍵
+ - 秘密鍵を持つファイルを作成したユーザと公開鍵を持つ任意のユーザが相互にエンコードとデコードが行える仕組み
+ - 署名はファイルにメタデータとして保持できるようにする
+ - 鍵の管理もOSが担うようにしたい
+
+## OSの信頼性について
+- アプリケーションを動かすOSには高い信頼性が保証されるべきである
+- OSの処理やコードの量は膨大になる
+ - テストコードを用いた信頼性の保証は困難であると言える
+- 数学的な背景に基づいた形式手法を用いて検証したい
+ - 定理支援証明
+ - モデル検査
+- OSを形式手法にて証明するには状態遷移単位での記述が求められる
+- GearsOSはメタレベルとノーマルレベルの計算を分離して記述が行える構成である
+ - メタレベルの計算でプログラムの整合性を検証する
## Continuation based C(CbC)
-- CbCとは当研究室で開発しているC言語の下位言語である。
-- CbCは関数呼び出しでなくjmp命令で移動する継続を導入している。
- - スタック領域を用いずjmp命令でコード間を移動することにより軽量な継続を実現している。これを軽量継続と呼ぶ。
+- CbCとはC言語の下位言語である
+- CbCは関数呼び出しでなくjmp命令で移動する継続を導入している
+ - jmp命令でコード間を移動することにより軽量な継続を実現している
+ - CbCでは継続を用いてfor 文などのループ文を実装する
+- Gearというプログラム概念を持つ
- CbCでは関数の代わりにCodeGearという単位でプログラムを行う
- CodeGearによる記述は形式手法に必要な状態遷移そのものとして見ることができる。
-- CbCではこの軽量継続を用いてfor 文などのループ文を実装する。
-
-
## Gearsの概念
-- CodeGearはDataGearと呼ばれる変数データを入力として受け取り、その結果を別のDataGear に書き込む.
-- CodeGearは従来のプログラムやスレッド、DataGearは変数データにあたる。
- - 入力のDataGearをInputDataGear、出力されるDataGearをOutputDataGearと呼ぶ。
+- CodeGear:従来のプログラムやスレッド
+- DataGear:変数データ
+- CodeGearはDataGearと呼ばれる変数データを入力として受け取る
+ - CodeGearの処理結果を別のDataGear に書き込む
+- 入力のDataGearをInputDataGear
+- 出力されるDataGearをOutputDataGear
- CodeGearが参照できるDataGearはInput/output DataGearに限定される。
-- CodeGearは関数呼び出しのスタックを持たないため、一度CodeGearを遷移すると元の処理に戻ってくることができない。
+- CodeGearは関数呼び出しのスタックを持たない
+ - 一度コードブロックを遷移すると元の処理に戻ってこられない
-## CbC記述例
-- CbCを利用したシステムコール のディスパッチ部分を示す。
- - 特定のシステムコール の場合、CbCで実装された処理にgoto文を使って継続する。
-- CodeGearへのアドレス配列がcbccodesに格納されている。
-- 引数として渡しているcbc_retは、システムコールの返り値をレジスタに代入するCodeGearである。
-
-```code
-void syscall(void)
-{
- int num;
- int ret;
- if((num >= NELEM(syscalls)) && (num <= NELEM(cbccodes)) &&
- cbccodes[num]) {
- proc->cbc_arg.cbc_console_arg.num = num;
- goto (cbccodes[num])(cbc_ret);
- }
-```
-
-
-
-システムコールディスパッチの状態遷移図
-
## GearsOS
-- CbCを用いて記述された、CodeGearとその入出力であるDataGearを基本としたOSである。
-- 現在は並列フレームワークとして実装されており、実用的なOSのプロトタイプとして実装を目指している。
-- ノーマルレベルから見るとCodeGearの遷移は単純にCodeGearがDataGearをInput/Outputを繰り返し、コードブロックを移動するように見える。
- - 実際にはCodeGearから別のCodeGearへの遷移にはデータ整合性の確認などのメタ計算が必要となる。
-- 遷移する各CodeGearの実行に必要となるメタ計算は、MetaCodeGearと呼ばれるCodeGearごとに実装されたCodeGearで計算する。
- - MetaCodeGear内で参照されるDataGearをMetaDataGearと呼ぶ。
-- MetaCodeGearやMetaDataGearはプログラマが直接実行することはなく、現在はPerlスクリプトにより、GearsOSのビルド時に実行される。
+- CbCを用いて記述されたOSである
+ - CodeGearとその入出力であるDataGearを基本とする
+- 現在は並列フレームワークとして実装されている
+ - 実用的なOSのプロトタイプとして実装を目指している
+- ノーマルレベルからではCodeGearの遷移は単純にCodeGearがDataGearをInput/Outputを繰り返し、コードブロックを移動するように見える
+ - 実際にはCodeGearから別のCodeGearへの遷移の際、データ整合性の確認などのメタ計算が加わる
+ - これをMetaCodeGearと呼ぶ
+ - MetaCodeGearはCodeGearごとに実装される
+ - MetaCodeGear内で参照されるDataGearをMetaDataGearと呼ぶ
+- MetaCodeGearやMetaDataGearはプログラマが直接実装することはない
+- 現在はPerlスクリプトにより、GearsOSのビルド時に生成される
CodeGearから別のCodeGearへ遷移する際のDataGearなどの関係性
-## Context
-- 遷移先の CodeGear と MetaCodeGear の紐付けや、計算 に必要な DataGear を保存や管理を行う MetaDataGearとして context がある。
- - 処理に必要なCodeGearの番号と MetaCodeGear の対応表や、DataGearの格納場所を持つ。
- - 計算に必要なデータ構造と処理を持つデータ構造であることから、contextは従来のOSのプロセスに相当するものと言える。
-
-
-
-
-
## Christie
-- Christieはjava言語で記述された分散フレームワークである.
-- GearsOSのとは異なる、Gearというプログラミング概念をもつ。
- - Codegear、DataGear、CodeGearManager、DagaGearManagerの四種類が存在しする。
+- Christieは並列分散フレームワークである
+ - java言語で構成される
+- GearsOSと似てはいるが別のGearというプログラミング概念をもつ
+- Gearは以下の四種類が存在しする。
- CodeGear (CG) : スレッド、クラス
- DataGear (DG) : 変数データ
- CodeGearManager (CGM) : ノード
@@ -128,39 +120,28 @@
### CodeGear(以下CG)
-- プログラム(CG)内に記述された全てのDataGearのkeyにデータが格納されると動作し、DGを参照しながらプログラムを実行する。
-- CGMがsetupという処理を行うことで呼び出す。
-
+- DataGearを参照しながらプログラムを実行する
+- 処理に必要なDataGearのkeyをプログラム内に記述する必要がある
+- CGMがsetupという処理を行うことで待ち合わせが始まる
+- プログラム(CG)内に記述された全てのDataGearのkeyにデータが格納されると実行される
+
### DataGear(以下DG)
-- keyと変数データの組み合わせで構成される。
-- プリミティブ型を指定する必要がある。(int, string...)
-- アノテーションを用いて記述する。(後述)
-
+- keyと変数データの組み合わせで構成される
+- アノテーションを用いて記述する
+ - アノテーションの種類によりkeyの変数データの参照方法が変わる
+
### CodeGearManager(以下CGM)
-- CG,DG,DGMを管理する。
-- 分散処理のノードに相当するため、それぞれポートを持つ。
-- putという操作でDGを任意のCGMの持つDGMに格納する。
-
+- CodeGear,DataGear,DataGearManagerを管理する
+- 分散処理のノードに相当する
+ - それぞれポートを持つ
+- putという操作でDagaGearを任意のCGMの持つDataGearManagerに格納する
### DataGearManager(以下DGM)
-- 各CodeGearManagerが1つづつ所持している。
-- データプールになっておりCGMが利用するDGを全て保持している。
-- LocalDGMとRemoteDGMの二種類存在する。(後述)
-
+- 各CodeGearManagerが1つづつ所持している
+- データプールになっておりCGMが利用するDGを全て保持している
+- LocalDGMとRemoteDGMの二種類存在する(後述)
-## DataGearのアノテーション 消す
-- DGを取り出す際にはCG内で宣言した変数にアノテーションをつける。
-- DGアノテーションにはTake、Peek、TakeFrom、PeekFrom、の4つがある。
- - Take
- - DGMに保管された先頭のDGを読み込み、そのDGを削除する。
- - Peek
- - DGMに保管された先頭のDGを読み込むが、DGが消去されない。そのため特に操作をしない場合、同じデータを参照し続ける。
- - TakeFrom
- - Remote DGM nameを指定することで、その接続先のDGM からTake操作をおこえる。
- - PeekFrom
- - Remote DGM nameを指定することで、その接続先のDGM からPeek操作をおこえる。
-
-## Christieのコード例 消し
+## Christieのコード例
- Christieを用いてHelloWorldを記述した際のコードが以下となる。
```
public class StartHelloWorld extends StartCodeGear {
@@ -190,104 +171,112 @@
## LocalDGMとRemoteDGM
-- DGMにはLocalDGMとRemoteDGMが存在する。
- - LocalDGMは各ノード固有のデータプールである。
- - RemoteDGMは他ノードのLocalDGMに対応するプールであり、接続しているノードの数だけ存在する。
-- DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ。
- - Localであれば、LocalのCGMが管理するDGMに対しDGを格納。
- - RemoteDGMを指定してputすることで、接続している任意のノードにDGを送信することができる。
-- CGMの接続をする=接続先のRemoteDGMを作成すると言える。
+- LocalDGMは各ノード固有のデータプールである
+- RemoteDGMは他ノードのLocalDGMに対応するプールである
+ - 接続しているノードの数だけ存在する
+- DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ
+ - Localであれば、LocalのCGMが管理するDGMに対しDGを格納する
+ - RemoteDGMを指定してputすると、接続している任意のノードにDGを送信する
+- CGMの接続をする=接続先のRemoteDGMを作成する
## TopologyManager
-- 通信形成を簡潔に行う機能である。
- - Topologyに参加を表明したノードを自動的に配線する。
- - 自動的に接続しているノードに相対的にラベルをつける。
-- 静的Topology形成
- - dotファイルを与えることノード関係の構築を行う。
- - ノード数が想定と一致しないと動作しない。
-- 動的Topology形成
- - 参加を表明したノードに対し、動的にノード同士の関係を作る。
- - 例えばTreeを構成する場合、参加したノードから順にrootに近い役割を与える。
-- TopologyManagerを利用することで、ソケット接続などの処理を全てTopologyManagerに任せることができる。
+- Christieがもつ通信形成を簡潔に行う機能である
+ - Topologyに参加を表明したノードを自動的に配線する
+ - Topologyの形状に合わせ、各ノードにRemoteDGMを作成する
+ - ノードは相対的に接続された別のノードにラベルをつけ参照することができる
+- ソケット接続などの処理を全てTopologyManagerに任せることができる
## GearsOSのファイルアクセスAPI
-- Christieの分散ファイルシステムのAPIをWordCount例題を通して構築する。
- - WordCount例題とは指定したファイルの中身の文字列を読み取り、文字数と行列数、加えて文字列を出力すると言う例題である.
-- WordCountのコードブロックは大きく分けて二つに分類できる。
- - 指定した名前のファイルをFile構造体としてOpenするFileOpenスレッド
- - ファイル構造体を受け取り、文字列を表示し、文字数と行列、CountUpをするWordCountスレッド
-- WordCountとファイルの接続はUNIXのシェルのようにプログラムの外で接続される。
- - この接続は将来的にChristieTopologyManagerで接続を行う。
+- WordCount例題を通して構築する
+ - WordCount
+ - 指定したファイルの中身の文字列を読み取る
+ - 文字数と行列数のcount
+ - 加えて文字列を出力する
+- WordCountのコードブロックは大きく分けて二つに分類できる
+ - FileOpenスレッド
+ - 指定した名前のファイルをFile構造体としてOpenする
+ - ファイル内文字列を1行づつブロックとしてWordCountスレッドに送信する
+ - WordCountスレッド
+ - 文字列のブロックを受け取る
+ - 文字列を表示する
+ - 文字数と行列のCountUpをする
+- WordCountとファイルの接続はプログラムの外で接続される
+ - 将来的にChristieのTopologyManagerで接続を行いたい
-## ChristieAPI
-- GearsOS上のファイルは名前のついた大域的な資源であり, 複数のプロセスから競合的にアクセスされる。
-- 上記のAPIではファイルとWordCountが直接的に結合されているので競合的なアクセスは起きない。
- - そこでChristieを基盤としたDataGearsStreamに名前をつけてアクセスするAPIを導入する。
+## 競合アクセスを可能とするChristieAPI
+- GearsOS上のファイルは名前のついた大域的な資源として扱われる
+ - 複数のCodeGearから競合的にアクセスされる場合がある
+- 上記のAPIではファイルとWordCountが直接的に結合されている
+ - 競合的なアクセスには対応していない
+- Christieを元とした、DataGearsStreamに名前をつけてアクセスするAPIを導入する
-WordCountをRemoteDGMを用いて構成する際の遷移図
+WordCountをRemoteDGMを用いて構成する際の協調図
-- NodeAにて任意のファイルを開き、DGMを通して1行ごとに文字列をNodeBに送信する。NodeBにてWordCountの処理を行い、OutputとしてNodeBからWordCountの処理を送り返す。
-
+- NodeAにて任意のファイルを開く
+ - ファイルの中身を1行ごとに文字列をNodeBに送信する
+- NodeBにてWordCountの処理(countup,文字列表示など)を行う
+ - ackとしてフラグをNodeAに返信する
+- 文字列ブロックの送信と受け取りのフラグのやり取りでループする
+- NodeBがeofをフラグとしてNodeAから受け取った場合、WordCountの結果を表示する
+ - 両ノードの処理の終了を行う
+- NodeA,B間のファイル内文字列のBlockとフラグの送受信は、RemoteDGMを介して行う
+ - RemoteDGMにはkeyとデータの組み合わせとなる(Christie仕様の)DataGearが必要となる。
+ - DGのpushにあたる操作はmeta部分で実装を行う
-- File Interfaceはファイル内文字列のBlockをWordCountに送信するが、RemoteDGMとして参照ができるWordCountの名前がついたDataGearManagerのploxyに書き込む。
-
-- DGの受け取りはCodeGearの入力で行われるが、入力されたDGにkeyを設定するmetaCodeGearを使う。
- - Christieのpushに相当する操作をmeta部分で実装する。
- - 他のCodeGearがputしたDGに対応するCGがそのcontextで実行される。
-- 同じ名前を持つ(key)DGは複数のCGからアクセスされる。
-- FIleのeofなどはDGにフラグをつけ、関数型プログラミング的に処理される。
--
## FileSystem Implementation
-- GearsOS FileSystemは単なるDGのリストとなり、要求されたDGをリストから参照し、順次送信する形で構成される。
-- 持続的なファイルシステムはリストもしくはB-TreeをSSDなどのデバイスに格納する。
-- メモリ領域において、CodeGearなどに使われた不要になった資源はメタレベルで回収を行う。
-- DGM自体がファイルの概念に対応すると言える。
- - 別ノードからファイルを参照する際にはRemoteDGMを通してファイルの中身を送受信して管理する。
+- GearsOS FileSystemは単なるDGのリストとなる
+ - これはDataGearManagerにあたる
+ - ファイルの中身を要求された際、リスト内部のDGを順次に送受信する形となる
+- 別ノードからファイルを参照する際はRemoteDGMを通してファイルの中身を送受信する
+- 持続的なファイルシステムとして保存する場合、DGのリストをSSDなどのデバイスに格納する
+- メモリ領域において不要となったメモリはmeta部分にて回収を行う
+
-ファイルを別ノード上から参照する際の遷移図
+ファイルを別ノード上から参照する際の図
## File Persistency
-- 持続性のあるファイルとして保存されたDGMを操作するには、デバイス上に保存されたDGMをLocalDGMとして呼び出せば良い
-- 重複管理や変更履歴管理もDGMが行う。
+- 持続性のあるファイルとして保存されたDGMを操作するには、SSDなどデバイス上に保存されたDGMをLocalDGMとして呼び出せば良い
-デバイス上に保存されたDGMを呼び出す際の遷移図
+デバイス上に保存されたDGMを呼び出す際の図
-## 競合的アクセスを含む分散計算の検証
-- ChristieAPI は競合的なアクセスを含むので逐次型プログラミングのように検証することができない.
- - TopologyManagerは名前付きDataGearManagerを相互に接続するが、これも動的に変更される。
-- 可能な接続パターンとDGMの内容のパターンは膨大となるが、抽象化を用いることでより様々なレベルでの検証が期待できる。
-- 接続とDGMの内容のパターンが確定すればその範囲でプログラムは関数型プログラミングとして振る舞い、HoareLogicなどで検証が行える。
- - 証明が複雑な場合でも, DG のパターンをメタ計算で調べるなどの手法を用いることができる.
-
-## 比較 自分の理解した感じで、箇条書きに
-- UNIX FileSystem は API的には File Stream と Socket Stream は Read-Writeでアクセスするがその設定はプログラム内部で煩雑な処理が必要となる。
- - GearsOSではこの部分をTopologyManagerが担うため簡潔に行える。
-- UNIXではStreamに型がないので不完全なデータが生じてしまう。また、UNIXファイルシステムにはfsckと呼ばれる修復機能があるが、メモリに対する修復機能は存在しない。
- - GearsOSではこれらはDGMのメタな機能として実装することができる。
- - 例えばメモリの一部不良に対応するDGMを作るといったことが考えられる。？
-- DGMの名前とその中のDataGear Streamに対応するkeyでアクセスする対象が決まる。
- - これはUNIXでいうi-node番号に相当する。i-nodeの構成と名前空間の構成は独立で良いため自由な名前空間の構成が行える。
-
+## UNIX FileSystemとの比較
+- UNIX FileSystem において File Stream と Socket Stream は煩雑な処理が必要となる
+ - GearsOSではSocket Stream部分をTopologyManagerが担う
+ - FileStreamはmetaCodeGear部分で実装することでユーザレベルから隠蔽することができる
+- UNIXではStreamに型がないので不完全なデータが生じてしまう
+ - GearsOSではこれらはDGMのメタな機能として実装することができる
+- UNIXファイルシステムにはfsckと呼ばれる修復機能があるが、メモリに対する修復機能は存在しない。
+ - GearsOSではメモリの一部不良に対応する機能をDGMとして作るといったことが考えられる。
+- GearsOSではDGMの名前とその中のDataGear Streamに対応するkeyでアクセスする対象が決まる
+ - 自由な名前空間の構成が行える
+ - これはUNIXでいうi-node番号に相当する
+
## まとめ
-- GearsOS におけるファイルシステム API の設計に対して議論を行った
-- API は二種類あり、アプリケーションで閉じた決定的な実行を行う直接接続されたものと、もう一つはDataGearManagerに名前をつけて競合的アクセスを許す形でゆるく接続されるものである
-- DGMはファイルとして見ることもでき、分散環境での通信として見ることもできる。
\ No newline at end of file
+- GearsOS におけるファイルシステム API の設計を議論した
+- 現在のファイルシステムの問題点
+- Gearsファイルシステムに搭載する機能の考察
+- GearsファイルシステムのAPIは二種類が存在する
+ - アプリケーションで閉じた決定的な実行を行う直接接続したもの
+ - DataGearManagerに名称をつけ、競合的なアクセスを許可するもの
+- ファイルはDataGearManager
+- DataGearManagerは分散環境での通信でもある
+- 精進して実装していきたい
\ No newline at end of file
diff -r a4f167def66b -r 6c46d8f76ec4 user/riono210/sigos2021.md
--- a/user/riono210/sigos2021.md Wed May 26 00:10:03 2021 +0900
+++ b/user/riono210/sigos2021.md Thu May 27 00:10:03 2021 +0900
@@ -2,18 +2,30 @@
---
+author: Ryo Yasuda, Shinji Kono
+profile: 琉球大学理工学研究科情報工学専攻 河野研究室
+
+### 概要
+* オンラインゲームにおける通信にはクライアントサーバ方式が主流
+ * データの共有はサーバを経由するため低速
+* 当研究室で開発を行っているChristie の分散計算を使用することで、高速かつ安全に通信できると考えた
+* Christie をUnity で使用するためにC# で書き換えを行った
+* 実装としては、localDataGearManager を用いた同一プロセスで複数インスタンス立ち上げによる通信が可能
+
+---
+
### オンラインゲームにおけるデータ通信
-* オンラインゲームは複数のプレイヤーが関与する分散プログラムである
+* オンラインゲームは複数のプレイヤーが関与する分散プログラム
* 分散プログラムを正しく書くことは難しい
* 攻撃の標的になる場合が多い
-* クライアントの負荷軽減やチート対策のため、クライアントサーバ方式が主流である
- * データの同期にはサーバを経由するため低速である
+* クライアントの負荷軽減やチート対策のため、クライアントサーバ方式が主流
+ * データの同期にはサーバを経由するため低速
---
### オンラインゲームにおけるデータ通信
* 当研究室では並列分散通信フレームワークChristie を開発中である
- * 型のあるDataGear をKey を持つストリーム、DataGearManager として格納している
+ * 型のあるDataGear とKey を持つストリーム、DataGearManager として格納している
* 他のノードはDGM のproxyを持っており、proxy に書き込むことで通信を実現している
* DGM はトポロジーマネージャーによって自動的に構築される
* プログラム自体はDGM の名前を知っていれば良い
@@ -24,7 +36,7 @@
* チートに対する耐性がある
-* 本研究ではJava で書かれたChristieとC# で書かれたもの説明し、その機能と実装の差について考察を行う
+* 本研究ではJava で書かれたChristieとC# で書き換えを行ったChristie #を説明し、その機能と実装の差について考察を行う
---
@@ -40,11 +52,12 @@
---
### Christie の基礎概念
-
+
Christie を同一プロセスで複数インスタンス立ち上げた際の接続の構造図
+
* 全てのCGM はThreadPool と他のCGM をList として共有している
* ThreadPool はCPU に合わせた並列度でqueue に入ったThread を逐次実行していく
* 1つのThreadPool で処理を行うことでCPU のコア数に適したThread を管理でき、並列度を下げ流ことを防ぐ
@@ -69,7 +82,7 @@
---
### Topology Manager
-* Christie 場でNetwork Topology を形成する
+* Christie 上でNetwork Topology を形成する
* 参加を表明したノードに名前を与える
* 必要があればノード同士の配線を自動で行う
@@ -93,6 +106,7 @@
+
+
+---
+
+### Java からの変更点
+* Java とC# は基本的に書き方は変わらない
+
+
+```java:ex.java
+Java
+public class StartHelloWorld extends StartCodeGear { }
+
+@Override
+protected void run(CodeGearManager cgm) { }
+
+@Take String helloWorld;
+```
+
+```cs:ex.cs
+C#
+public class StartHelloWorld : StartCodeGear { }
+
+public override void Run(CodeGearManager cgm) { }
+
+[Take] string helloWorld;
+```
---
@@ -182,13 +222,24 @@
}
```
+1. Main関数でCGM のインスタンス生成
+2. 2つのCG をsetupして待ち状態にする
+3. key:hellowWorld data:"hello" がTake される
+4. 変数が揃ったためStartHelloWorld のRun が実行される
+5. "hello" がprintされ、再び待ち状態になる。 key:hellow data:"hello"がput される
+6. key:hellowWorld data:"world" がTake され、4,5と同様に処理される
+7. 変数hello とworld がput され揃ったため、FinishHelloWorld のRun が実行され、プログラムは終了する
+
+
+
+
### Unity
* UnityはUnity Technologies が開発を行っているゲームエンジンである
* 世界で最も使用されているゲームエンジン
* 非常に軽く、スペックが低いノートPCでもゲーム開発が可能
* プログラミング言語にはC# が採用されている
- * C# のAPIやUnity向けに拡張されたAPIも使用可能
- * 開発した機能をUnityに組み込むことも可能
+ * C# のAPI やUnity 向けに拡張されたAPIも使用可能
+ * 開発した機能をUnity に組み込むことも可能
---
@@ -216,6 +267,12 @@
}
}
```
+* HelloWorldCodeGearと、FinishHelloWorld はそのまま使用
+* StartHelloWorld をUnity で使用できるように書き換え
+ * Unity ではMonoBehaviour 継承したクラスが動作可能
+ * ゲーム開始時に1度だけ呼ばれるStart 関数
+ * Start 関数でCGM のインスタンスを生成
+ * Main 関数を名前を変えたRunCodeGear 関数を実行
---
@@ -240,12 +297,12 @@
---
### MessagePackの相違点
-* Christie ではデータを送信する際にMessagePack を使用してデータを圧縮し送受信している
+* Christie ではMessagePack を使用してデータを圧縮し送受信している
* インスタンス内のpublic 変数に対して圧縮可能
* バージョンが古いため、現在はサポートされていない
* そのため、最新版とは記述方法が異なる
-* シリアライズするクラスには@Message annotatoinをつける
+* 圧縮するクラスには@Message annotatoinをつける
* MessagePack インスタンスを作成後、write、read することでデータの圧縮解凍が可能
* 圧縮されたデータはbyte[] 型になる
@@ -394,14 +451,20 @@
### 実装の現状
* Local DGMを使用してUnity 上でデータ通信を行うことができている
* Scketo とMessagePack を用いた通信に関しては、書き換え途中
+ * 独自クラスをMessagePack でserialize できない
* 今後の予定
* Christie で実装されている例題
* Alice からChristie に書き換えた際に取り除かれた機能の洗い出しを行う
- * Unity でChristie #の検証としてFPS の作成
+ * Unity でChristie #の検証として60人規模のFPS の作成
---
### まとめ
+* Christie をUnity で使用するためにC# に書き換えを行った
+* 書き換え方針としては、attribute やMessagePack などC# 独自の機能に対応しつつ元のソースコードと同一になるようにした
+* 実装としては、localDataGearManager を用いた同一プロセスで複数インスタンス立ち上げによる通信が可能
+* Remote DataGearManager を使用した複数台の通信については書き換え途中であり、引き続き行っていく
+* Christie の検証のためUnity で60人規模のFPS を作成する