|
0
|
1 -title: Remote Editing Protocol の実装と検証
|
|
|
2
|
|
|
3 --author: 与儀健人, 宮城健太, 河野真治
|
|
|
4
|
|
2
|
5 --はじめに
|
|
|
6
|
|
|
7 本研究室では、vim、Emacs、Ecpliseを相互接続するプロトコルを提案して来た。
|
|
|
8 今回は、Session Manager を導入することにより、より単純なユーザインタフェース
|
|
|
9 を実現するとともに、複雑なプロトコルをSession Manager側に閉じ込めて、
|
|
|
10 Editor側の実装の手間を軽くすることを提案する。
|
|
|
11
|
|
|
12 一方で、プロトコル自体がかなり複雑になったので、プロトコルの正しさ
|
|
|
13 及び、プロトコル実装の正しさを検証する必要が出て来た。
|
|
4
|
14 プロトコル検証では、Java PathFinder\cite{havelund98model}の
|
|
2
|
15 有効性が知られているが、それを用いるために、ソケット
|
|
|
16 通信をThread間の同期で実現するライブラリを作成した。
|
|
|
17 また、Editor側の実装の正しさの検証及びデバッグのために、
|
|
|
18 テスト用のEditorを作成した。
|
|
|
19
|
|
1
|
20 --Remote Editing Protocol の設計方針
|
|
|
21
|
|
2
|
22 複数人が同じテキストを共有して編集するプロトコルは、
|
|
|
23 さまざまなものが提案されているが、汎用エディタに実装
|
|
|
24 する前堤のプロトコルはほとんどない。Remote Editing Protocol
|
|
|
25 では、複数のSession Managerと、リング状のSession の上に
|
|
|
26 編集コマンドを循環させる方法を取っている。
|
|
|
27
|
|
3
|
28 <center><img src="fig/editor_to_editor2.pdf" alt="REPでの相互接続"></center>
|
|
|
29
|
|
2
|
30 この方法を採用した理由はいくつがある。
|
|
|
31 集中サーバを用いない\underline{分散実装}が一つの前堤になっている。
|
|
|
32 Session Manager 自体が分散していて、Session Manager は、
|
|
|
33 (分離されたMergerを除けば)編集コマンドを中継するだけである。
|
|
|
34 また、既存のエディタを用いるために、
|
|
|
35 \underline{localな編集}を妨げない点を重視している。遠隔/共有編集を実現
|
|
|
36 することによって、本来の編集機能が速度低下などにより損なわれることはない。
|
|
|
37 一度に大量の通信をすることなどを避け
|
|
|
38 \underline{Network負荷が軽い}こと。
|
|
|
39 複雑なコマンド入力などのない\underline{Simple なユーザInterface}。
|
|
|
40 これらを実現するために\underline{Conflictを非同期に解決}し、
|
|
|
41 変更の伝播の遅延は容認する。また、
|
|
|
42 \underline{小人数向け}の共有とする。遅延を容認するために、
|
|
|
43 \underline{遠距離でも使用可能}となる。また、オープンソースとして実装し、
|
|
4
|
44 \underline{教育用途}に向いている。特に、XP (eXtreme Programming) \cite{bib:xp}
|
|
2
|
45 における\underline{Pair Programming}での使用を意識しているので、
|
|
|
46 \underline{Emacs/vim/Eclipseの相互接続}を重視する。
|
|
|
47 将来的には、動的な変更を可能とする
|
|
|
48 \underline{Inter-Application Protocol}として使えるものを
|
|
|
49 目指している。
|
|
|
50 プロトコル自体の信頼性を増すために、プロトコル自体の正しさ、及び、
|
|
|
51 実装の正しさを調べることを可能にする。
|
|
|
52
|
|
1
|
53 --Protocol の構成
|
|
|
54
|
|
2
|
55 ここでは、REPをSession manager(SM), Session manager接続プロトコル、
|
|
|
56 Session 接続プロトコル、Editor Command、Mergeプロトコル、
|
|
|
57 MergeのSession Managerへの移動の順に説明する。
|
|
|
58
|
|
1
|
59 ---Session managerの導入
|
|
|
60
|
|
2
|
61 従来のREPはエディタ間を直接結んでいたが、その場合は相手の
|
|
|
62 エディタのホスト名やファイル名を直接入力する必要があった。
|
|
|
63 これは、ユーザに取って繁雑なだけでなく、個々のエディタでの
|
|
|
64 実装に複雑なUIを含める必要がある。
|
|
|
65
|
|
|
66 Session manager(SM)はエディタの動作するホストに一つあり、エディタ
|
|
|
67 は自動的に決まったポートを通してSMに接続(join/put)する。このようにすれば、
|
|
|
68 エディタ上でホスト名を入力する必要はない。一つのホスト上では、
|
|
|
69 単一のSMに複数のエディタが接続する。離れたホスト同士のエディタを
|
|
|
70 接続する場合は、まず、それぞれのホスト同士のSMを接続する。そして、
|
|
|
71 それぞれエディタがSMに接続した後で、ホスト間の接続を選択(select)する。
|
|
3
|
72 <center><img src="fig/one_session_manager.pdf" alt="Session Managerの導入"></center>
|
|
2
|
73
|
|
1
|
74 ---Session managerの接続protocol
|
|
|
75
|
|
2
|
76 SM同士の接続は、{\tt sm\_join}コマンドをSMに送ることによる。
|
|
|
77 接続により、接続したSM間でuniqueな session manager id
|
|
|
78 が決められる。SM同士の接続は木構造(SM木)になるようになっており、
|
|
|
79 唯一のmaster SMが存在する。
|
|
1
|
80
|
|
2
|
81 同時に相互に{\tt sm\_join}
|
|
|
82 が発行される場合もあるので、リングを避けるために、
|
|
|
83 {\tt sm\_join} はmaster SMまで転送される。自分自身に
|
|
|
84 {\tt sm\_join} が戻って来た場合は、その{\tt sm\_join} は
|
|
|
85 廃棄される。現在は、既にsession/editorを持つSMは、他のSMに
|
|
|
86 接続することは出来ない。
|
|
3
|
87 <center><img src="fig/many_session_manager.pdf" alt="Session Manager同士の接続"></center>
|
|
1
|
88
|
|
|
89 ---Session 接続 protocol
|
|
|
90
|
|
2
|
91 SMに接続したエディタは、自分の既にオープンしたファイルを持って接続する
|
|
|
92 {\tt put}と、他のエディタへ空のバッファを接続する{\tt join}の二種類の
|
|
|
93 接続を行なう。
|
|
|
94
|
|
|
95 接続が行なわれると、SMからeditor idをACKとして受け取る。editor idは、
|
|
|
96 session manager id (SM id)を含んでおり、全てのSM上でユニークとなる。
|
|
1
|
97
|
|
2
|
98 {\tt put}したファイルを持つエディタは、そのsessionのmasterとなる。
|
|
|
99 ファイルを共有するeditor群をsession と呼ぶ。session には、
|
|
|
100 SM id を含む session id が割り振られ、全てのSM上
|
|
|
101 でユニークとなる。
|
|
|
102
|
|
|
103 ユニークな SM id を使うので、editor id/sesison id はmaster SMに問い合わせる
|
|
|
104 ことなく生成が可能となる。
|
|
1
|
105
|
|
2
|
106 {\tt put}されたファイルはSM木を{\tt put｝コマンドで遡り、{\tt put\_ack}
|
|
|
107 によって、すべてのSMに通知される。このファイルの編集に参加したい場合は、
|
|
|
108 まず、Editorを空のバッファの状態でSMに{\tt join}コマンドで接続する。
|
|
|
109 すると、{\tt put}と同様に{\tt join}したEditorがすべてのSM上に通知される。
|
|
|
110 SMのGUI上の操作{\tt select}により、{\tt put}されたファイルと{\tt join}
|
|
|
111 したEditorが結びつけられる。
|
|
3
|
112 <center><img src="fig/sm_join.pdf" alt="join コマンド"></center>
|
|
1
|
113
|
|
2
|
114 {\tt select}操作では、{\tt join}したEditorと{\tt put}したエディタを
|
|
|
115 探し出す必要がある。そのために、SM木上にSM同士に到達するための
|
|
|
116 routing tableを構築している。これは、{\tt sm\_join}時に作成される。
|
|
|
117 まず{\tt put}したEditorを探し、見つかったら{\tt select\_ack}を、
|
|
|
118 session ring を構築しながら{\tt join}したEditorを探す。見つかったら
|
|
|
119 {\tt join\_ack}がEditorに返される。
|
|
|
120 この時に、必要があれば、{\tt join}側、{\tt put}側の認証を行なう。
|
|
|
121
|
|
|
122 {\tt join}したエディタは空のバッファを持っているので、Session master
|
|
|
123 ({\tt put}したEditor)に、必要な編集行を要求する{\tt sync}コマンドを
|
|
|
124 session ring に送る。Session master は、次のEditor Command を使って
|
|
|
125 必要な行を送信する。
|
|
3
|
126 <center><img src="fig/use_case_put_join_over_sm.pdf" alt="Session Managerを介したエディタの接続"></center>
|
|
1
|
127
|
|
|
128 ---Editor Command
|
|
|
129
|
|
2
|
130 Editorのコマンドは、すべて、{\tt insert},{\tt delete} に分解される。
|
|
|
131 SM上での混乱を避けるために、Editorが直接SMに送ったユーザが生成した
|
|
|
132 Editor Command {\tt user\_inert, user\_delete}と SM経由で送られた他のEditor Command は異なる
|
|
|
133 コマンドとして扱っている。
|
|
|
134
|
|
|
135 Editor は複数のsession を持つことも可能であるが、一つのEditor
|
|
|
136 が同じSessionに複数回{\tt join}すると、Editorの通信経路とEditor
|
|
|
137 id が対応しなくなる。問題はないが、実装はより複雑となる。
|
|
|
138
|
|
|
139 次のMerge Protocolでは、SM上でEditorのコマンドのundoを計算する
|
|
|
140 必要があるので、{\tt user\_delete}には、削除した行の内容が
|
|
|
141 付加されてSMに送られる。したがって、{\tt user\_delete}と
|
|
|
142 {\tt user\_insert}と見掛け上対称となる。
|
|
|
143
|
|
4
|
144 全文置換なども{\tt user\_inert, user\_delete}に分解する必要が
|
|
2
|
145 あり、その分解はEditorによって行なわれる。REPは歴史的理由で行指向の
|
|
|
146 プロトコルであり、行指向でないEditorでも行番号を付加する
|
|
|
147 必要がある。
|
|
|
148
|
|
|
149 {\tt sync}に対しては、要求された行に対して、
|
|
|
150 {\tt delete, insert}を順に送ることで、{\tt join}したEditorに
|
|
|
151 行を転送する。特別なバッファ転送コマンドはない。
|
|
|
152
|
|
|
153 置換を特別扱いすることによるコマンド短縮の利点があるように
|
|
|
154 思えるが、SMではundoを生成する必要があるので、変更前の行と
|
|
|
155 変更後の行を送る必要があり、
|
|
|
156 {\tt delete, insert}を順に送る場合との差は無視できる。
|
|
|
157
|
|
1
|
158 ---Merge Protocol
|
|
|
159
|
|
2
|
160 一つのSessionの上で、複数のEditorが同時に編集を行なった場合には、
|
|
|
161 その結果は、最終的に、Session 上で同じになる必要がある。
|
|
|
162
|
|
|
163 REPでは、二つのEditorの場合の編集の衝突の解決を行なう
|
|
|
164 手法を提案して来た。この方法(Merge Protocol (A))では自分のEditor Commandを
|
|
|
165 相手に送り、戻って来るまでのEditor Commandをキューに入れておく。
|
|
|
166 他のEditorのCommandを受け取った時には、その
|
|
4
|
167 キューと、そのCommandの可換性を調べて、キューを変更する\cite{kono04g}。
|
|
2
|
168 しかし、この方法は、三つ以上のEditorの場合はうまく動作しない。
|
|
1
|
169
|
|
2
|
170 そこで、以下のようなMerge Protocol (B)を導入する。(1) Editor Command
|
|
|
171 をSession Ring 上に流し、それが戻って来るまでに、他のEditorから
|
|
|
172 受け取った Editor Command をキューに入れておく。
|
|
|
173 (2) 戻って来たタイミングで、キュー上のEditor Commandを、eid とCommandの
|
|
|
174 順序を基にソートする。
|
|
|
175 (3) Editor Command がなくても、他のEditorからCommand を受け取ったら、
|
|
|
176 NOP Command を生成して、それが戻って来た時にソートを行なう。
|
|
|
177
|
|
3
|
178 <center><img src="fig/new_merge.pdf" alt="Session Ring上のREPコマンドの送信"></center>
|
|
|
179
|
|
2
|
180 この手法では、EditorがN個あるSessionの場合、一つのEditor Commandに対して、N-1
|
|
|
181 個のNOP Command が生成される。
|
|
1
|
182
|
|
2
|
183 そこで、以下のようなMerge Protocol (C)を導入する。(1) Editor Command
|
|
|
184 をSession Ring 上に流し、それが戻って来るまでに、他のEditorから
|
|
|
185 受け取った Editor Command をキューに入れておく。
|
|
|
186 (2) 戻って来たタイミングで、キュー上のEditor Commandを、eid とCommandの
|
|
|
187 順序を基にソートする。
|
|
|
188 (3) 他のEditorにソートのタイミングを与えるために、Editor Command の
|
|
|
189 ack を、もう一周させる。
|
|
|
190 (4) 他のEditorのCommandを受け取ってから、ack が来るまでのCommandをキューに
|
|
|
191 入れておき、ack が来たら、eid とCommandの順序を基にソートする。
|
|
|
192
|
|
|
193 Editor には、ソートした編集結果になるように、それまで行なった編集をUndo
|
|
|
194 して、ソートした編集結果を適用する。
|
|
1
|
195
|
|
|
196 ---Merge のSession Managerへの移動
|
|
|
197
|
|
2
|
198 Merge Protocol は、かなり複雑であり、すべてのEditor実装に対して
|
|
|
199 実装する必要がある。我々のターゲット(Vim, Emacs, Eclipse)は、
|
|
|
200 すべて異なる言語(C,Emacs Lisp,Java)で実装されており、そのすべてで、
|
|
|
201 複雑なプロトコルを実装するのは不可能ではないが、コストがかかる。
|
|
|
202
|
|
|
203 今回は、SMが一つのEditorに対して必ず存在するので、Merge Procotol
|
|
|
204 をSMに実装すると、SMの実装言語(Java)に実装するので十分になる。
|
|
|
205 しかし、Merge Protocol は編集バッファに対して複雑な操作をするので、
|
|
|
206 それをEditor Command を通して実装する必要がある。
|
|
|
207
|
|
|
208 まず、Editor Command がUndo(取消し)可能でなければならない。
|
|
|
209 このために、{\tt user\_delete} Command に削除した行の内容を
|
|
|
210 付加することにした。
|
|
1
|
211
|
|
2
|
212 次に、SMがMerge Protocolでソートした編集結果を適用した結果は、
|
|
|
213 (可能な最適化をした)Editor Command 列でEditorに反映する必要がある。
|
|
|
214 この時に、ユーザが編集コマンドを割り込ませる可能性がある。
|
|
|
215
|
|
|
216 これを防ぐ一つの方法は、Merge 作業が始まった段階で、ユーザ入力を
|
|
|
217 block してやれば良い(a)。もう一つの方法は、ユーザ入力の割り込みが
|
|
|
218 あった場合は、その入力込みで、もう一度、ソートを実行すれば良い(b)。
|
|
3
|
219 これはリマージと呼ばれる。
|
|
|
220
|
|
4
|
221 <center><img src="fig/reMerge.pdf" alt="リマージ"></center>
|
|
2
|
222
|
|
|
223 Merge 作業中には、他のSM/Editorからの入力をblockすることは問題ない。
|
|
|
224 それは、もともと非同期で動作しており、遅延は許容されるように
|
|
|
225 なっている。
|
|
|
226
|
|
|
227 ユーザ入力のlock(a)は、エディタの実装に依存していて、実装はさまざまで
|
|
|
228 ある。また、REP設計の一つの目標であるlocalな編集を妨げないという
|
|
|
229 点では問題が残る。(b) は、Merge Protocol の実装が繁雑になるが、
|
|
|
230 ユーザの入力を妨げることはない。また、エディタのlockを実装しなくて
|
|
|
231 すむ。(a),(b)はお互いに干渉しないので、エディタのlockの実装は
|
|
|
232 REPを実装する時の選択肢の一つとなる。lock がある方が大量の変更(コピー
|
|
|
233 ペースト)がある場合にスムースな動作が期待できる。
|
|
|
234
|
|
1
|
235
|
|
|
236 --Protocol の正しさ
|
|
|
237
|
|
2
|
238 Merge Protocol の正しさの証明は、Protocol自体の正しさと、
|
|
|
239 Protocolの実装を含めた正しさの二種類の正しさを示す必要がある。
|
|
|
240
|
|
|
241 ここでは、(A)のProtocolの正しさを示す。Editor $0..n$ が、
|
|
|
242 それぞれ、編集コマンド$C_{ij}$ (Editor $i$の$j$番目のコマンド,$j$は0から)を
|
|
|
243 入力したとする。このコマンドは、Session ring を巡回する。
|
|
|
244 巡回するたびに、各Editor $k$が{\tt NOP} Command $N_{kx}$を、その
|
|
|
245 コマンドの前に付加する。
|
|
|
246 % (A)では自分が既にCommandを送っていれば{\tt NOP}を付加する必要は
|
|
|
247 % ないが、ここでは、必ず付加することにする。
|
|
|
248 $x$は、コマンドの順序である。
|
|
|
249 % $C_{ij}$の$j$は、{\tt NOP}を含めた番号に付け換える。
|
|
|
250
|
|
|
251 Editor $m$では、
|
|
|
252 \[ C_{m0} C_{x0} N_{00} .... N_{yz} \]
|
|
|
253 などのコマンド列が実行されることになる。これを$C/N$の
|
|
4
|
254 区別のないコマンド記号($E_{ij}$)で置き換えよう。
|
|
2
|
255 \[ E_{m0} E_{x0} E_{00} .... E_{yz} \]
|
|
|
256 NOPの付加手順から、
|
|
|
257 他のEditorが送ったCommandには、その前の他のEditorからのCommandを
|
|
|
258 受け取った後の、
|
|
|
259 自分が送ったCommand(0以上の複数個)
|
|
|
260 または、{\tt NOP}
|
|
|
261 が必ず対応している。
|
|
|
262 対応するCommandとは、Session ring 上で同時に実行されたと考えられる
|
|
|
263 Command の集合と考えて良い。
|
|
|
264 Command はSession ring を一周するので、すべての
|
|
|
265 Editor が同じCommandの集合を受け取っている。
|
|
|
266
|
|
|
267 ここで、対応したCommandの集まり毎に列を分割し、
|
|
|
268 Editor iの
|
|
|
269 その集まりを集合と
|
|
|
270 みなし$S_{ij}$ とする。この集合の列を$Z_i$とする。
|
|
|
271 \[ Z_i = S_{i0} S_{i1} .... S_{in} \]
|
|
|
272 定義から隣同士の$S_{ij}$には、
|
|
|
273 対応したCommandが含まれることはない。
|
|
|
274
|
|
|
275 この集合列$Z$は、すべてのEditorで同一となる。
|
|
|
276 [証明]
|
|
|
277 Editor $i$とEditor $j$で、$S_{ik}$と、$j$の$S_{jk}$が異なっている
|
|
|
278 としよう。あるCommand $E_s$があって、
|
|
|
279 $E_s \in S_{ik}$であって$E_s \in S_{jk}$でない。
|
|
|
280 しかし、$E_s$
|
|
|
281 はsession ringを一周しているので、$S_{ik}$と$S_{jk}$の両方に
|
|
|
282 含まれているか、隣同士にあるはずである。両方に含まれていると
|
|
|
283 すると仮定と矛盾するので、隣同士になるはずである。しかし、隣同士で
|
|
|
284 あれば、Command の分割の方法に矛盾する。[証明終り]
|
|
|
285
|
|
|
286 従って、$S_i$をEditor idとCommand順序によってソートしてやれば、
|
|
|
287 すべてのEditorで、同一なCommand列を得ることが出来る。
|
|
|
288 ソートのタイミングは、対応するコマンドがすべて自分に到着した時点である。
|
|
|
289 自分の送った新しいコマンド、または、新しい{\tt NOP}が
|
|
|
290 来たことによって、その一つ前までが対応しているものだということがわかる
|
|
|
291 ので、その時点でソートしてやれば良い。従って、Merge Protocolにより、
|
|
|
292 すべてのEditorで同一の編集結果が得られることがわかった。
|
|
|
293
|
|
|
294 (B)では、{\tt NOP}の挿入の代わりに{\tt ack}を、もう一周させている。
|
|
|
295 {\tt ack} が来た時点で、対応するCommandの集合が確定する。あるいは、
|
|
|
296 仮想的に{\tt NOP}を挿入したと考えると、その{\tt NOP}は、{\tt ack}
|
|
|
297 の前に挿入されていると考えて良い。従って、(A)と同じように集合列$Z$
|
|
|
298 を、すべてのEditorで同一となるように決めることが出来る。
|
|
|
299
|
|
|
300 プロトコルの実装の正しさは、実装言語であるJavaに深く依存するので、
|
|
|
301 このように簡単に証明することは出来ない。そこで、
|
|
4
|
302 モデル検査器であるJava PathFinder\cite{havelund98model}を用いる。
|
|
1
|
303
|
|
|
304 --Protocol の実装
|
|
|
305
|
|
3
|
306 Session Manager はJava 1.5で実装されており、 Ecplise は Java によるPlug-in
|
|
|
307 となっている。 Emacs は、従来はCで書いたクライアントを接続していたが、
|
|
|
308 今は、すべて Emacs Lisp で書かれている。 Vim は、C で記述されており、
|
|
|
309 Merger もCで記述されていたが、今回の実装で取り外された。
|
|
1
|
310
|
|
3
|
311 今回の実装では、Editor 側の実装のコストが削減されており、Merge Protocol
|
|
|
312 部分でCで150行程度が削減されている。Editor 側の実装は、Editor Command を
|
|
|
313 {\tt insert, delete} に分解する部分の実装が大半である。
|
|
1
|
314
|
|
3
|
315 Editor 側で実装する必要があるのは、表\ref{tb:sync}の機能である。
|
|
|
316 \begin{table}[htdp]
|
|
|
317 \caption{Editor 側での実装}
|
|
|
318 \begin{center}
|
|
|
319 \begin{tabular}{|l|l|}
|
|
|
320 \hline
|
|
|
321 1 & 編集機能の{\tt user\_insert,user\_detele}への分解と、分解したEditor Command の送信 \\
|
|
|
322 \hline
|
|
|
323 2 & {\tt join,put} Command のUI部分と、Command の送信 \\
|
|
|
324 \hline
|
|
|
325 3 & {\tt join,put} Command のUI部分と、Command の送信 \\
|
|
|
326 \hline
|
|
|
327 4 & {\tt join\_ack,put\_ack} の受け取りとsid,eidの設定 \\
|
|
|
328 \hline
|
|
|
329 5 & 外部からのEditor Commandの非同期受け取りと実行 \\
|
|
|
330 \hline
|
|
4
|
331 6 & {\tt sync} Command を受け取った場合の{\tt user\_insert,user\_detele}の生成 \\
|
|
3
|
332 \hline
|
|
|
333 7 & Merge 時のlock (optional) \\
|
|
|
334 \hline
|
|
|
335 7 & {\tt quit} Command \\
|
|
|
336 \hline
|
|
|
337 \end{tabular}
|
|
|
338 \end{center}
|
|
|
339 \label{tb:sync}
|
|
|
340 \end{table}%
|
|
1
|
341
|
|
3
|
342 ファイルのオープン/セーブなどの機能はREPには含まれていない。Master Editor
|
|
|
343 も、それ以外のEditorも任意の時点でのローカルなセーブが可能である。
|
|
|
344 版管理なども、REP以外の部分で対応する。
|
|
|
345
|
|
|
346 外部からのEditor Command を受け取った場合のカーソルなどの制御は、規定されて
|
|
|
347 いない。移動した場合が便利な場合と、そうでない場合があると思われる。
|
|
1
|
348
|
|
|
349 --Socket Simulator
|
|
|
350
|
|
3
|
351 Java Pathfinder による検証を行なうために、直接、Socketを経由せずに、
|
|
|
352 Thread を通して通信を行なうライブラリを作成した。
|
|
|
353
|
|
|
354 このライブラリは、最初、java.nio互換ではなく作成し、Merge Protocol
|
|
|
355 (A)及び(B)の動作をJava PathFinder で確認した。編集結果の同一性を
|
|
|
356 調べるために、Session 内の Editor のquit プロトコルを実装している。
|
|
|
357
|
|
|
358 まず、 {\tt quit } Command がSessin ring に送られ、各Editorは、
|
|
|
359 {\tt quit}を受け取ると、自分のユーザ編集コマンドを停止する。その編集を
|
|
|
360 終了した後、{\tt quit}を返す。{\tt quit}を受け取った後も、他の
|
|
|
361 Editor からのEditor Commandは来る可能性がある。{\tt quit}を最初に
|
|
|
362 送ったEditorに{\tt quit}が戻ると、今度は{\tt quit2}をSession Ring
|
|
|
363 に流す。これより後に、ユーザ編集コマンドが来ることはない。Editor は
|
|
|
364 自分の待っているEditor Commandのackがすべて来るのを確認してから、
|
|
|
365 {\tt quit2}を次へ渡す。{\tt quit2}を渡した後は、Editor Command は
|
|
|
366 来ないので、終了して良い。最初のEditorへ{\tt quit2}が戻った時点で、
|
|
|
367 すべての編集が終了する。
|
|
|
368
|
|
|
369 この時に、Editor のバッファを比較して、
|
|
|
370 すべてのEditorのバッファが同じならば、正しくプロトコルが動いた
|
|
|
371 ことになる。これをJava PathFinderで検証を行なう。
|
|
|
372
|
|
|
373
|
|
|
374 (C)の実装を、実際のSession Manager 上で検証するために、java.nio と
|
|
|
375 Thread による通信のシミュレーションを切替えることが可能なライブラリ
|
|
|
376 を作成した。実際のSession Manager に対する Java PathFinder での
|
|
|
377 実行確認は、計算時間の制約により、まだ、可能とはなっていない。
|
|
1
|
378
|
|
|
379 --検証とデバッグ
|
|
|
380
|
|
3
|
381 (A)のプロトコルがEditor 二つで動作すること、及び、(B)のプロトコル
|
|
|
382 が複数のEditorで動作することを Java PathFinder で確認することが
|
|
|
383 出来た。
|
|
|
384
|
|
|
385 (C)は、実際のSession Managerの実装を含む検証となるので、よりハードルが
|
|
|
386 高い。現状では、Java PathFinder での動作確認は出来ていない。
|
|
|
387
|
|
|
388 Java PathFinder でvimやEmacsを含む検証は可能とはなっていないが、
|
|
|
389 Sample Editor をJava で実装することにより、Java PathFinderでの
|
|
|
390 Merge Protocolの検証が可能となっている。
|
|
|
391
|
|
|
392 実際には、vim やEmacs などのEditor側の実装が正しいかどうかを調べる
|
|
|
393 ことも重要である。それは、Merge Protocolを切った状態で、Javaの
|
|
|
394 Sample Editor に対する動作を確認することで調べることが出来る。
|
|
|
395
|
|
|
396
|
|
1
|
397 --比較
|
|
3
|
398
|
|
4
|
399 類似のProject としては、GroupKit \cite{bib:groupkit}, Soba Project\cite{bib:soba} がある。
|
|
3
|
400 vim やEmacs などのOpen source editor の実装を含むのが、REPの特徴
|
|
|
401 である。
|
|
|
402
|
|
|
403 また、Java で実装されていて、Session Manager 部分、Editor の改変部分、
|
|
|
404 Eclipse plugin のすべてが、LGPLで公開されているのも独自な特徴の
|
|
|
405 一つである。
|
|
|
406
|
|
|
407 GroupKit はtcl/tkで記述されており、検証などが困難だが、REPでは、
|
|
|
408 Java の部分をJava PathFinder で検証することが可能だと思われる。
|
|
|
409 しかし、現状では、まだ、検証までには至っていない。
|
|
|
410
|
|
|
411 GroupKit などで使われているマルチメディア編集の同期は、Masterが
|
|
|
412 一つ存在し、それに対するCommandの発行と、MasterからのCommandの
|
|
4
|
413 マルチキャストで実現されている\cite{bib:ellis}。REPでは、マルチキャスト
|
|
3
|
414 ではなく、Session ring によって同期を実現している。Ring は、
|
|
|
415 遅く信頼性に欠ける部分があるが、ネットワークに対する負荷が
|
|
|
416 軽いと言う特徴がある。(C)のMerge Protocolを使うことにより、
|
|
|
417 o(n)のパケットで同期を行なうことが出来る。また、マルチキャスト
|
|
|
418 を避けているので、WANなどの遅延が大きい部分に複数のストリーム
|
|
|
419 を張る必要がないという特徴がある。
|
|
|
420
|
|
|
421 また、Session Manager 上には、Editor Bufferが存在しないので、
|
|
|
422 大きなファイルを編集する場合でも、Session Manager のメモリを
|
|
|
423 消費することはない。
|
|
|
424
|
|
|
425 --最後に
|
|
|
426
|
|
4
|
427 このプロジェクトは、sourceforge を通じて公開\cite{rep-sourceforge}されており、まだ、
|
|
3
|
428 開発途上となっている。
|
|
|
429
|
|
|
430 残念ながら、実際のSession Manager 上でのJava Pathfinder での検証は
|
|
|
431 まだ、出来てはないが、通信ライブラリ上での処理をatomicにするなどの
|
|
|
432 工夫で可能になると期待している。
|
|
|
433
|
|
|
434
|
|
|
435
|
|
|
436
|
