comparison slide/thesis.md @ 17:55e745a21506 default tip

add abstruct & slide
author ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date Sun, 16 Feb 2020 17:54:28 +0900
parents 7293b6481e32
children
comparison
equal deleted inserted replaced
16:7293b6481e32 17:55e745a21506
4 lang: Japanese 4 lang: Japanese
5 code-engine: coderay 5 code-engine: coderay
6 6
7 ## 研究目的, 背景 7 ## 研究目的, 背景
8 - ペアプログラミングなどでは同時に複数人が一つのファイルを編集することができるリモートエディタが有効である。 8 - ペアプログラミングなどでは同時に複数人が一つのファイルを編集することができるリモートエディタが有効である。
9 - 既存のリモートエディタアプリケーションとしてVisual Stdio Codeがあげられる。 9 - 既存のリモートエディタアプリケーションとしてVisual Stdio Codeのlive share機能があげられる。
10 - しかし、セッションに参加する全員がVSCodeの環境を持っていなければならず、不便である。
11 - 編集に参加するユーザーがそれぞれ好きなエディタが使えるアプリケーションを作成する。 10 - 編集に参加するユーザーがそれぞれ好きなエディタが使えるアプリケーションを作成する。
12 - 本研究室で開発している分散フレームワークChristieを使い、簡潔な実装を目指す。 11 - 本研究室で開発している分散フレームワークChristieはGearという概念の性質上リモートエディタと相性が良い。
13 12
14 13 <!--
15 ## 発表の流れ 14 ## 発表の流れ
16 - リモートエディタの機能と開発手順の解説 15 - リモートエディタの機能と開発手順の解説
16 - javaで制作したテスト用エディタ
17 - コマンドパターンによる命令オブジェクトの作成
18 - 編集位置の相違とその解消方法
17 - スター型接続によるネットワーク通信 19 - スター型接続によるネットワーク通信
18 - Christieの解説 20 - Christieの解説
19 - Gearの概念 21 - Gearの概念
20 - アノテーション 22 - アノテーション
21 - TopologyManager 23 - TopologyManager
22 - 今後の課題とまとめ 24 - 今後の課題とまとめ
23 25 !-->
26
27 ## リモートエディタの概要説明
28 - 本研究で作成するリモートエディタはChristieの機能を用いて通信環境を構成する。
29 - 同期編集セッションに接続したユーザーは自身のマシン上でエディタを使って編集対象ファイルを開く。
30 - ユーザーが起こしたファイルへの変更を、命令コマンドとして接続しているサーバー(ハブ)へ送信&実行させる。
31 - 命令コマンドはサーバーへ集められ、サーバーは受け取ったコマンドを他の接続ノードへ送信し、実行させる。
32
33 <div style="text-align: center;">
34  <img src="images/RemoteEditor.pdf" alt="MetaGear" width="800">
35 </div>
36
37
38 ## テスト用テキストエディタ
39 - 通信の構成を行うChristieはjava言語で作成されているため、javaのswingを用いてテキストエディタを制作した。
40 - エディタ部分の入力、削除の取得はDocument Listenerクラスを使った。
41 - insertUpdate、removeUpdateメソッドがそれぞれ挿入、削除を検知した時に動作する。
42 - このエディタはファイルの内容をオフセット番号で取り扱っている。
43
44 <div style="text-align: center;">
45  <img src="images/Editor.png" alt="MetaGear" width="800">
46 </div>
47
48 ## DocumentListenerの記述部分
49
50 ```
51 public class MyDocumentListener implements DocumentListener {
52 @Override
53 public void insertUpdate(DocumentEvent e) {
54 Document doc = e.getDocument();
55 loc = e.getOffset();
56 System.out.println(loc);
57
58 }
59
60 @Override
61 public void removeUpdate(DocumentEvent e) {
62 Document doc = e.getDocument();
63 sendLoc = e.getOffset();
64 System.out.println("delete " + sendLoc);
65 }
66 @Override
67 public void changedUpdate(DocumentEvent e) {
68 }
69 }
70 ```
71
72 ## コマンドパターンの解説
73 - リモートエディタの通信では、各ノード(参加ユーザのエディタ)がそれぞれ自身のファイルの変更内容を他のノードに送信する。
74 - コマンドパターンとは命令を一つのオブジェクトとして表現するプログラム手法である。
75 - 命令を表すクラスを作成し、インスタンスを作成と同時に命令の中身を入力することで命令を作成する。
76 - リモートエディタにおいては「オフセットn番目に に 文字列 "A"を入力した」という変更を命令にして送信する。
77 - コマンドパターンの利点として、
78 - ChristieのGearの概念と相性がいい。
79 - 命令に必要な内容をまとめて送信するため、時間差による相違の発生が防げる。
80 - オブジェクトとして取り扱えるため管理が行いやすい。
81
82 ```
83 package christie.example.RemoteTake;
84 import org.msgpack.annotation.Message;
85
86 @Message
87 class RTCommand {
88 public String line;
89 public String cmd;
90 public int offset;
91
92 public RTCommand () {}
93
94 public RTCommand(String cmd, String line, int i) {
95 this.cmd = cmd;
96 this.line = line;
97 this.offset = i;
98 }
99
100 @Override
101 public String toString() {
102 return "RTCommand{" +
103 "line='" + line + '\'' +
104 ", cmd='" + cmd + '\'' +
105 ", offset=" + offset +
106 '}';
107 }
108 }
109 ```
110
111
112 ## コマンドパターン実装の際に起こった問題
113 - クラスを他ノードに送信するためには、クラスをシリアライズして送信する必要がある。
114 - コマンドの送信にはmsgpackクラスとjavassistを利用している。
115 - しかし、送信がうまく行えなかったため、原因を調査した。
116 - javaのバージョン進行のため、msgpackバージョン0.6.12が非対称となっていた。
117 - msgpackの最新バージョン0.8.20はシリアライズ機能が含まれなくなった。
118 - 以上の原因に対処するため
119 - javassistのバージョンを最新版へ変更した。
120 - シリアライズする命令クラスに対し、クラスをpublicに変更した。
121 - 以上の対処によりコマンドパターンでの命令実装を行うことができた。
122 - 自身でシリアライズ機能をChristieに内蔵してしまえば、これらのパッケージは不要になる。
123
124 ## 編集位置の相違
125 - 同期編集のセッションでは命令コマンドの送信のすれ違いにより、ノードごとのファイル状態が異なってしまうことがある。
126 - EditorAとEditorBはそれぞれの命令を自身のエディタバッファに施してから命令を送信するため、お互いバッファ状態が異なる状態で受け取った命令を実行してしまう。
127
128 <div style="text-align: center;">
129  <img src="images/difference_offset.pdf" alt="MetaGear" width="800">
130 </div>
131
132 ## 編集の相違の解消
133 - 同期編集のセッションはスター型の通信接続で行うため、サーバー対複数ノードの通信間で相違が発生する。
134 - 編集の相違を防ぐためには二つの処理を行う必要がある。
135 - サーバーとノード間の命令のすれ違いが発生したことを検知する。
136 - すれ違いが発生した際に、オフセットのズレを修正する。
137 - サーバーが正しいファイルの状態を保持するためサーバーの状態にノードが合わせる必要がある。
138
139 ## 命令コマンドに番号をつけ相違を解消する
140 - 命令コマンド番号には以下の特性がある。
141 - 全てのノード(サーバーを含める)は事前に処理した命令コマンドの番号を記憶している。
142 - 新しく作られた命令コマンドは作られたノードの命令実行済み番号+1 を自身の命令コマンド番号とする。
143 - ノードは自身が作成したか、他のノードに送られてきたかに関わらず命令コマンドを実行したら命令実行済み番号をその命令コマンドの番号と同じにする。
144 - もしノードが送られてきた命令コマンドを見て、そのコマンドが自身の実行済み番号と同値以下の場合、送信元のノードとの命令のすれ違いが発生していることが分かる。
145
146 <div style="text-align: center;">
147  <img src="images/FixCommand.pdf" alt="MetaGear" width="800">
148 </div>
149
150 ## すれ違いが発生した際の処理
151 - 全てのノードは自分が実行した命令コマンドを記録しており、後からオフセットや文字列を取り出すことができる。
152 - すれ違いが発生した時点からの命令の中身を集計、参照しすれ違いで送られてきたコマンドを修正する。
153 - insertを例とすると
154 - 受け取ったコマンドのオフセット > 受信コマンドとすれ違ったコマンドのオフセット のとき、受診したコマンドのオフセットに+1 する。
155 - 受け取ったコマンドのオフセット <= 受信コマンドとすれ違ったコマンドのオフセット のとき、受診したコマンドのオフセットを変えずにそのまま実行できる。
156
157
158
159 ## スター型通信
160 - Christieにはノードの通信接続を行うTopologyManagerという機能がある。
161 - 同期通信はスター型での接続を行う。
162 - スター型通信の利点は
163 - サーバーが正しいファイル状態を保持するため、整合性を保つことができる。
164 - どこかのノードが切断されても、要害の範囲をそのノードのみに抑えることができる。
165 - 新しいノードが参加した、もしくは復帰の際にはサーバーのファイル状況を参照するのみで参加、復帰ができる。
166
167 <div style="text-align: center;">
168  <img src="images/Star-Topology.pdf" alt="MetaGear" width="800">
169 </div>
24 170
25 ## Christie 171 ## Christie
26 - Christieは当研究室で開発している、信頼性を重視した分散フレームワークである. 172 - Christieは当研究室で開発している、信頼性を重視した分散フレームワークである.
27 - 現在はjava上で開発されているが、別言語(CbC)で構成されたGearsOSに組み込む予定があるため,それに向けて書き換え可能な構成となっている。 173 - 現在はjava上で開発されているが、別言語(CbC)で構成されたGearsOSに組み込む予定があるため,それに向けて書き換え可能な構成となっている。
28 - ChristieではデータをGearという単位で分割して記述を行う。 174 - ChristieではデータをGearという単位で分割して記述を行う。
34 - ノードに相当し, DG, CG, DataGearManagerの管理をする. 180 - ノードに相当し, DG, CG, DataGearManagerの管理をする.
35 - DataGearManager(以下DGM) 181 - DataGearManager(以下DGM)
36 - DGを管理するものであり, putという操作にて変数(DG)をkeyに格納する。 182 - DGを管理するものであり, putという操作にて変数(DG)をkeyに格納する。
37 183
38 184
39 ## Christieのコード例 185 ## Christieのコード例
40 ```code 186 ```
41 package christie.example.HelloWorld; 187 package christie.example.HelloWorld;
42 188
43 import christie.codegear.CodeGearManager; 189 import christie.codegear.CodeGearManager;
44 import christie.codegear.StartCodeGear; 190 import christie.codegear.StartCodeGear;
45 191
46 public class StartHelloWorld extends StartCodeGear { 192 public class StartHelloWorld extends StartCodeGear {
47 193
48 public StartHelloWorld(CodeGearManager cgm) { 194 public StartHelloWorld(CodeGearManager cgm) {
49 super(cgm); 195 super(cgm);
50 } 196 }
51 197
52 public static void main(String[] args){ 198 public static void main(String[] args){
53 CodeGearManager cgm = createCGM(10000); #ポート番号を指定してCGMを立ち上げ。 199 CodeGearManager cgm = createCGM(10000);
54 cgm.setup(new HelloWorldCodeGear()); #立ち上げたCGMへCGを待ちあわせる。 200 cgm.setup(new HelloWorldCodeGear());
55 cgm.getLocalDGM().put("helloWorld","hello"); #keyname "helloWorld"に文字列helloをput 201 cgm.setup(new FinishHelloWorld());
56 cgm.getLocalDGM().put("helloWorld","world"); 202 cgm.getLocalDGM().put("helloWorld","hello");
57 } 203 cgm.getLocalDGM().put("helloWorld","world");
58 } 204 }
59 205 }
60 ``` 206 ```
61 ``` 207
62 ChristieDaemon.listen: bind to /0:0:0:0:0:0:0:0:10000 208 ```
63 hello world 209 ChristieDaemon.listen: bind to /0:0:0:0:0:0:0:0:10000
64 ``` 210 hello world
65 <!-- 211 ```
66 - 立ち上げ後はManager名を指定してDataSegmentAPI用いてDSのやり取りを行うため、プログラマはManager名を意識することでLocalへの操作もRemoteへの操作も同様に扱える。 212
67 --> 213 <!--
214 - 立ち上げ後はManager名を指定してDataSegmentAPI用いてDSのやり取りを行うため、プログラマはManager名を意識することでLocalへの操作もRemoteへの操作も同様に扱える。
215 -->
68 216
69 <!-- 217 <!--
70 218
71 ## Christieの言語概念 219 ## Christieの言語概念
72 - CGはスレッド, クラスに相当し, javaの継承を用いて記述する. 220 - CGはスレッド, クラスに相当し, javaの継承を用いて記述する.
76 - DGMにはLocalDGMとRemoteDGMが存在する。LocalDGMは各ノード固有のデータベースである。RemoteDSMは他ノードのLocalDGMに対応するproxyであり、接続しているノードの数だけ存在する。 224 - DGMにはLocalDGMとRemoteDGMが存在する。LocalDGMは各ノード固有のデータベースである。RemoteDSMは他ノードのLocalDGMに対応するproxyであり、接続しているノードの数だけ存在する。
77 - DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ.Localであれば、LocalのCGMが管理するDGMに対しDGを格納し, Remoteの場合は接続したRemoteさきのCGMのDGMにDGを格納する. 225 - DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ.Localであれば、LocalのCGMが管理するDGMに対しDGを格納し, Remoteの場合は接続したRemoteさきのCGMのDGMにDGを格納する.
78 226
79 --> 227 -->
80 228
229
230 <!--
81 ## DGM 231 ## DGM
82 - DGMは分散システムの肝となる他のノード間とのデータのやり取りの際に重要となる。 232 - CGMはDGをputという操作を使って、自身や他ノードのDGMに書き込ませる。
83 - DGMにはLocalDGMとRemoteDGMが存在する。 233 - LocalDGMが自身、RemoteDGMが他ノードのDGMである。
84 - LocalDGM 234
85 - LocalなDGMのプールのkeyにデータの書き込みを行う。 235 <div style="text-align: center;">
86 - RemoteDGM 236 <img src="images/remote_datasegment.pdf" alt="MetaGear" width="800">
87 - Localに存在する、他のノードのLocalDGMに対応するプールのkeyにデータを書き込みする。接続しているノードの数だけ存在する。 237 </div>
88 - DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ.Localであれば、LocalのCGMが管理するDGMへ、 Remoteの場合は接続したRemote先のCGMのDGMにDGを格納する. 238
89 239 !-->
90 <div style="text-align: center;">
91 <img src="../paper/images/remote_datasegment.svg" alt="MetaGear" width="800">
92 </div>
93 240
94 <!-- 241 <!--
95 - RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。 242 - RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。
96 --> 243 -->
97 244
98 ## Annottation
99 - ChristieではInputDGの指定にはアノテーションを使う。
100 - アノテーションとはクラスやメソッド、パッケージに対して、付加情報を記述できるJavaのMeta Computationである。
101 - 先頭に@をつけることで記述する。オリジナルのアノテーションを定義することもでき、Input
102 される型の変数を直接宣言し、変数名としてkeyを記述する。その上にアノテーションでTakeもしくはPeekを指定する。
103
104 ```cc
105 package christie.example.HelloWorld;
106
107 import christie.annotation.Take;
108 import christie.codegear.CodeGear;
109 import christie.codegear.CodeGearManager;
110
111 public class HelloWorldCodeGear extends CodeGear {
112 @Take
113 String helloWorld;
114
115 @Override
116 protected void run(CodeGearManager cgm) {
117 System.out.print(helloWorld + " ");
118 cgm.setup(new HelloWorldCodeGear());
119 }
120 }
121
122 ```
123 245
124 ## DGのアノテーション 246 ## DGのアノテーション
125 - DGを取り出す際にはCG内で宣言した変数にアノテーションをつける。DGアノテーションには 247 - DGを取り出す際にはCG内で宣言した変数にアノテーションをつける。DGアノテーションには
126 Take、Peek、TakeFrom、PeekFrom、の4つがある。 248 Take、Peek、TakeFrom、PeekFrom、の4つがある。
127 - Take 249 - Take
131 - TakeFrom 253 - TakeFrom
132 - Remote DGM nameを指定することで、その接続先のDGM からTake操作をおこえる。 254 - Remote DGM nameを指定することで、その接続先のDGM からTake操作をおこえる。
133 - PeekFrom 255 - PeekFrom
134 - Remote DGM nameを指定することで、その接続先のDGM からPeek操作をおこえる。 256 - Remote DGM nameを指定することで、その接続先のDGM からPeek操作をおこえる。
135 257
136 258 ```
259 package christie.example.HelloWorld;
260
261 import christie.annotation.Peek;
262 import christie.annotation.Take;
263 import christie.codegear.CodeGear;
264 import christie.codegear.CodeGearManager;
265
266 public class HelloWorldCodeGear extends CodeGear {
267
268 @Take
269 String helloWorld;
270
271 @Override
272 protected void run(CodeGearManager cgm) {
273 System.out.print(helloWorld + " ");
274 cgm.setup(new HelloWorldCodeGear());
275 cgm.getLocalDGM().put(helloWorld,helloWorld);
276 }
277 }
278 ```
279
280 <!--
137 ## TopologyManager 281 ## TopologyManager
138 - TopologyManagerとはTopologyを形成のために、参加を表明したノード、TopologyNodeに名前を与え、必要があればノード同士の配線を行うノードである。 282 - TopologyManagerとはTopologyを形成のために、参加を表明したノード、TopologyNodeに名前を与え、必要があればノード同士の配線を行うノードである。
139 - TopologyManagerのTopology形成方法として、静的Topologyと動的Topologyがある。 283 - TopologyManagerのTopology形成方法として、静的Topologyと動的Topologyがある。
140 - 動的Topologyは参加を表明したノードに対し、動的にノード同士の関係を作る。例えばTreeを構成する場合、参加したノードから順にrootに近い役割を与え、またCodeGearはノードが参加し、parentに接続された後に実行される。 284 - 動的Topologyは参加を表明したノードに対し、動的にノード同士の関係を作る。例えばTreeを構成する場合、参加したノードから順にrootに近い役割を与え、またCodeGearはノードが参加し、parentに接続された後に実行される。
141 - 静的Toopologyはdotファイルを与えることノード関係の構築を行う。 285 - 静的Toopologyはdotファイルを与えることノード関係の構築を行う。
147 node2 -> node0 [label="right"] 291 node2 -> node0 [label="right"]
148 } 292 }
149 ``` 293 ```
150 294
151 <div style="text-align: center;"> 295 <div style="text-align: center;">
152  <img src="../paper/images/ring.svg" alt="MetaGear" width="500"> 296  <img src="images/ring.pdf" alt="MetaGear" width="500">
153 </div> 297 </div>
154 298 !-->
155
156
157
158
159 299
160 ## まとめとこれから 300 ## まとめとこれから
301 - 本研究発表ではリモートエディタの開発とそれに伴う技術について述べた。現時点で実装できた構成は以下である。
302 - リモートエディタの基本となる命令のやり取り部分のコマンドパターン実装。
303 - 編集相違を防ぐためのアルゴリズムの発案と検証。
304 - 現時点では最低限のセッションを動かすまでの最低限の実装は終わっていない。これから取り組まなければならない課題として以下が挙げられる。
305 - スター型Topologyの接続を動的に行わせる。
306 - 編集するファイルの共有方法
307 - ファイルをそのまま送信すると、負担が大きいと予想される。
308 - 既存のエディタを同期通信に対応させる。
309 - 以上の課題の課題に取り組み、これからも実装を続けていきたい。