view Todo @ 486:877aacde8651

new merge on going...
author one
date Thu, 21 Oct 2010 20:30:52 +0900
parents cc262a519b8a
children 455df381449a
line wrap: on
line source

Thu Oct 21 12:27:44 JST 2010

外部からのINESRT に USER_INSERTがはまりこんでいるが…

    Editor               SM
                                          <---INSERT----
       <---INSERT----       (start_merge)
       --U_INSERT1-->       truncate
       ----INSERT--->       start_merge
       --U_INSERT2-->       truncate
       <--START_M----       (U_INSERT1, U_INSERT2)

INSERTが来た時点でEditorをlockすれば、二つめは止めるが。
でも、問題はないはず。余計に tuncate しても問題ない。

                                          --U_INSERT0-->
                            (U_INSERT0)
                                          <---INSERT----
       <---INSERT----       (start_merge)
       --U_INSERT1-->                     --U_INSERT1-->
       ----INSERT--->       start_merge
                            (U_INSERT0, U_INSERT1, INSERT)
                                          --INSERT-->
       --U_INSERT2-->                     --U_INSERT2-->
       <--START_M----       (U_INSERT0, U_INSERT1, INSERT, *,  U_INSERT2)
       --U_INSERT3-->                     --U_INSERT3-->
       --STARTM_ACK->
       --U_INSERT4-->       (U_INSERT0, U_INSERT1, INSERT, *,  U_INSERT2, U_INSERT3, U_INSERT4)
                                          --U_INSERT4-->

ええと、INSERT は、U_INSERT[01] は追い越すべき。U_INSERT[2-4]
は追い越さない。* は merge_mark

start_merge 以降は外部commandはブロックされるので問題ない。

ってことは、まずいっていうことね。U_INSERT1/U_INSERT2 を
block しても良いのだが、undo は必要なのでblock出来ません。

    sentList, unMegeList には随時追加 (merge 中はtruncateしない)
    sort は、MERGE_MARK まで
    merge_end で、user command があれば、truncate

かな。で、preMergedCommand の送信タイミングは? 戻って来た順に出してしまって良い?

Wed Oct 20 20:35:53 JST 2010

    Editor1    Editor2    Editor3 
    c(eid=1)              a(eid=3)
    a(eid=3)*  c(eid=1)*          
               e(eid=2)t  c(eid=1)*
    c(eid=1)t  a(eid=3)*  e(eid=2)*
    e(eid=2)*  ca(eid=1)t a(eid=3)t
    aa(eid=3)t e(eid=2)t  ca(eid=1)t
    ca(eid=1)t aa(eid=3)t ea(eid=2)t  
    ea(eid=2)t ca(eid=1)t
                          ca(eid=1)t

    [c,e,a]   [c,e,a]    [c,e,a]

sort は、どの範囲?
    全部で良い
と言うことは、そこに MERGE_MARK は必要ない


Fri Oct 15 19:47:05 JST 2010

あまり良い変更でないので元に戻す。

   sentlist はあった方が良い
   今までのmergeも動いた方が良い

Thu Oct 14 14:27:22 JST 2010

でも単純ソートはうまくいかないはず。

あ、そうか。このアルゴリズムだと、sentListがクリアされないものがいるね。

二巡目のack で消すのだろうが...

あとsortの範囲の問題がやっぱりある。

Tue Oct 12 10:37:38 JST 2010

やっぱり二周目に割り込んだコマンドが正しくsortされない。

    Editor3   Editor2    Editor1 
              e(eid=2)
                         e(eid=2)
    e(eid=2)             
              e(eid=2)   c(eid=1)
                         ea(eid=2)*
    c(eid=1)
    ea(eid=2)* c(eid=1)
              ea(eid=2)* c(eid=1)
    ca(eid=1)* 
              ca(eid=1)* 
                         ca(eid=1)* 

    [e,c]     [e,c]      [c,e]

うーん。

    Editor3   Editor2    Editor1 
              e(eid=2)   a(eid=1)
    a(eid=1)             e(eid=2)
    e(eid=2)  a(eid=1)
              e(eid=2)*  c(eid=1)
                         a(eid=1)*
                         ea(eid=2)*
    c(eid=1)
    aa(eid=1)* c(eid=1)
    ea(eid=2)* aa(eid=1)* c(eid=1)* 
    ca(eid=1)* 
               ca(eid=1)*

    [a,e,c]   [a,e,c]    [a,e,c]

他のエディタのコマンドが来た時に、優先順位でいきなりソート(merge)して良い。o
    自分のコマンドは、過去の低い優先順位を追い越さない。 x
    一周(ack)が来たら、そこまでのundoは捨てて順位は固定。  x
既に他のコマンドを送信した後に、自コマンドが来たら、その前までの自編集以外の編集まで確定。o
自コマンドのackで、まだ確定してない場合は確定。o
他コマンドのackは何もしない o
merge 中の自コマンドは、確定させて処理(merge後に送信と同じ)

Ackが来たら確定で良い?

    Editor3   Editor2    Editor1 
    c(eid=3)  e(eid=2)   a(eid=1)
    a(eid=1)  c(eid=3)   e(eid=2)
    e(eid=2)  a(eid=1)   c(eid=3)
    c(eid=3)* e(eid=2)*  d(eid=1)   <- このd がsortされない必要があるらしい
    d(eid=1)  ca(eid=3)  a(eid=1)*
    aa(eid=1)* d(eid=1)  ea(eid=2)*
    ea(eid=2)* aa(eid=1)* ca(eid=3)*
                         d(eid=1)*
    da(eid=1)*
              da(eid=1)*

    [a,e,c,d]  [a,e,c,d]  [a,e,c,d]

優先順位1でない場合

    Editor1   Editor2    Editor3 
    c(eid=1)  e(eid=2)   a(eid=3)
    a(eid=3)  c(eid=1)   e(eid=2)
    e(eid=2)  a(eid=3)   c(eid=1)
    c(eid=1)* e(eid=2)*  d(eid=3)   <- このd がsortされない必要があるらしい
    d(eid=3)  ca(eid=1)  a(eid=3)*
    aa(eid=3)* d(eid=3)  ea(eid=2)*
    ea(eid=2)* aa(eid=3)* ca(eid=1)*
                         d(eid=3)*
    da(eid=3)*
              da(eid=3)*

    [c,e,a,d]  [c,e,a,d]  [c,e,a,d]

優先順位に関係なく、他コマンドの後の自分のコマンドは
sort しないものらしい。

そこにさらに他コマンドが割り込んだ場合は?

    Editor1   Editor2    Editor3 
    c(eid=1)             a(eid=3)
    a(eid=3)  c(eid=1)           
              a(eid=3)   c(eid=1)
    c(eid=1)* e(eid=2)   d(eid=3)   <- このe,d がsortされない必要があるらしい
    d(eid=3)  ca(eid=1)* a(eid=3)*
    aa(eid=3)* d(eid=3)  e(eid=2)   <- a(eid=3)は確定、d(eid=3)は未確定
    e(eid=2)  aa(eid=3)* ca(eid=1)* <- Editor1のe(eid=2)は、まだ未確定
              e(eid=2)*  d(eid=3)*
    da(eid=3)*           ea(eid=2)*
    ea(eid=2)* da(eid=3)*           <- e(eid=2)を確定

    [c,a,e,d] [c,a,e,d]  [c,a,e,d]

e(eid=2) は d(eid=3) を追い越す必要がある。

他のエディタのコマンドが来た時に、優先順位でいきなりソート(merge)して良い。o
既に他のコマンドを送信した後に、自コマンドが来たら、その前までの自編集以外の編集まで確定。o
自コマンドのackで、まだ確定してない場合は確定。o
他コマンドのackは 二周目のackが来たら、そのコマンドまで確定
merge 中の自コマンドは、確定させて処理(merge後に送信と同じ)

    Editor1   Editor2    Editor3 
    c(eid=1)             a(eid=3)
    a(eid=3)  c(eid=1)           
              a(eid=3)   c(eid=1)
    c(eid=1)* e(eid=2)   d(eid=3)   <- このe,d がsortされない必要があるらしい
    d(eid=3)             a(eid=3)*
              d(eid=3)   e(eid=2)
    e(eid=2) 
              e(eid=2)*  d(eid=3)*

    [c,a,e,d] [c,a,e,d]  [c,a,e,d]

もしかして、ack って必要ないの? え〜

    Editor1   Editor2    Editor3 
    c(eid=1)  e(eid=2)   a(eid=3)
    a(eid=3)  c(eid=1)   e(eid=2)
    e(eid=2)  a(eid=3)   c(eid=1)
    c(eid=1)* e(eid=2)*  d(eid=3)   <- このd がsortされない必要があるらしい
    d(eid=3)             a(eid=3)*
              d(eid=3)  
                         d(eid=3)*

    [c,e,a,d] [c,e,a,d]  [c,e,a,d]

4つの場合の特殊性はある?




Mon Oct 11 22:12:35 JST 2010

あ、そうか。singleton case 中のコマンドは無視されてしまうわけね。SYNC すれば良いはずだが。

残念ながら、SYNC すると正しく動かない。

Mon Oct 11 19:56:48 JST 2010

ackList を別にしたので、quit2 は ackList も見ないとだめだった。

ack が廻って来たら、ちゃんと全部ソートしないとダメ。

自分が出したコマンドもソートしちゃって良いの?

あれ? もしかして、できた?

Mon Oct 11 13:32:49 JST 2010

Translator がEditorと別ってのが超絶読みづらい。
本当は、Translator 単体でテストしたかったのだろうが。
自分で作ったような気もするよ。

Sat Oct  2 08:43:32 JST 2010

なんか振り出しに戻った感じ〜

Deak lock, Ack miss, 結果の不良と全部そろっている

Fri Oct  1 10:09:41 JST 2010

やっぱり、そんなに簡単には動かないか。slow merge だと dead lock する。

SMCMD_QUITをSMCMD_QUIT_2に変えているのは誰? Editor 側でやっているのかぁ。

自分のinsert commandを落してしまうらしい。ack のcheckと、editor list
をわけるべきなのか?

わけました。

sort は、確定したところまででないとだめ。

Tue Sep 28 10:43:14 JST 2010

廻る順序でコマンド順は確定する。
    方法は三つ
        nop 前置方式
        slow merge 方式 (二周後に確定)
        sort interval 方式

Editor1のc(eid=1) は、e(eid=2) よりは後になる。しかし、今の
方法だと前だと判断されてしまう。nop 方式だと、その前に付く
ので、そこで区切られる。

ea(eid=2)とnopは同じ意味だが、区別する方法は?

    START_MERGE INSET DELETE END_MERGE

となるはず。

    Editor1 では、sm e(eid=2) em c(eid=1)
    Editor3 では、sm e(eid=2) c(eid=1) em

となる? 

em 後がある em 後へ
sm-em間が空 ->sm-em 間へ
sm-em間にコマンドがある ->  
    同じsort interval  ->sm-em へ
    新しいsort interval  ->em以降 へ

Merge 後に sm-em は sm 以前に移される。
em 以降の次のsort interval がsm-em に移動。(全部?)

sort interval とは何? (良い質問だな〜)

    eid の順序の一塊
    新しい自分のコマンドは新しいsort interval を作る

(いけそうではあるな...)

途中の editor の脱落とかあると、どうしても同期がずれる?
再送の仕組みは?

Fri Sep 24 17:42:50 JST 2010

    Editor3   Editor2    Editor1 
              e(eid=2)
                         e(eid=2)
    e(eid=2)             c(eid=1)
    c(eid=1)  e(eid=2)
              c(eid=1)   ea(eid=2)*
    ea(eid=2)*           c(eid=1)
    ca(eid=1)*ea(eid=2)*
              ca(eid=1)*
                         ca(eid=1)*

    [e,c]     [e,c]      [e,c]

うーん、ack のみで merge するので良さそう。いや、そうすると、
二周目の間にコマンドが入るけど、その扱いは?

あ、そうか。他のeditorからのコマンドの前に自分のコマンドを入れる
ってのがあったような気がする。二周目のackは、それを実現できない
のか。

    Editor3   Editor2    Editor1 
              e(eid=2)
                         1e(eid=2)
    31e(eid=2)           c(eid=1)
    3c(eid=1) 231e(eid=2)*
              23c(eid=1) 231*
    23                   23c(eid=1)*
    12          23                
    ca(eid=1)*ea(eid=2)*
              ca(eid=1)*
                         ca(eid=1)*

    [c,e]     [c,e]      [c,e]

う、結構わからんな。

Fri Sep 24 17:42:50 JST 2010

順序がずれる問題は、送信キューをEditor localに持つことで解消。

結果がおかしいことがあるのは、(* は merge operation )

    Editor1   Editor2    Editor3 
              e(eid=2)
                         e(eid=2)
    e(eid=2)             c(eid=1)
    c(eid=1)  e(eid=2)*
              c(eid=1)   ea(eid=2)*
    ea(eid=2)*           c(eid=1)
    ca(eid=1) ea(eid=2)            
              ca(eid=1)  
                         ca(eid=1)  

    [e,c]     [c,e]      [e,c]

と巡回させた時に、Editor2 で e(eid=2) が確定してしまうかららしい。
つまり eid=1 か ack を待てば良い。(ack は all eid と考えて良い)

と言うことは、ack のみで merge するべきだってこと? 

それでは、だめなみたいだなぁ。

Thu Sep 23 14:57:57 JST 2010

やっぱり、send が

    Editor Object から Editor へのsend
    他の Editor Object から Editor へのsend

の二つに使われているのはダメだよ。片方をブロックしたい時があるのだから。

sendNext で分割してブロックはできた。問題は、途中で送られたものをどう
処理するかだが〜

うーん、すでにSession Manager の送信キューに入っているので、
blocking が効かないようだ。

そういうわけなので、受け側でなんとかした方が良いみたい。
可能なの? いや、無理だろうな。

    REPNode.send  他のところからの送信
    REPNode.write Serverの送信ループ

なので、Editor.write() で捕まえるか。

Thu Sep 23 12:13:19 JST 2010

START_MERGE から START_MERGE_ACK までにEditorから送られたコマンドは、
sentList に付け加えるべきでは?

しかし、その間、外部からEditorに送るコマンドは止める必要がある。

    Editor.merging     ...  START_MERGE ... START_MERGE_ACK ... END_MERGE
    Translaotr.merging ...  START_MERGE_ACK ... END_MERGE

と言うように区別するか。

START_MERGE は、 Editor から返って来るタイミングでブロックするので、
その段階で、Editor へ送られているコマンドをブロックできない。
もちろん、Editor からのUSER_INPUTもブロックできない。

Editorの undoが正しくなくなるだけでなく、
Merge phase  のコマンドが二つ続けて送られるのはよろしくない。

Wed Sep 22 19:59:26 JST 2010

NOPを廻す方式とAckを廻す方式は、

    E_{10} N_{11} E_{23} E_{01} E_{02} N_{11}

    E_{10}        E_{23} E_{01} E_{02} Eack_{10}

の対応だから、方法としては同じ。 

sort だけど、

    e3 e1 e2 e3 e1 e2 e3 e1 e2 e3 e1 e2 e3
     |---1---|----4---|--------|
        |----2---|--------|--------|
           |----3---|--------|--------|

1 では c1 のack で c1 c2 c3 の順序にmerge。c1 c2 c3 は確定。
なので、2,3 ではソートは必要ない? じゃぁ、Self merge だけ
すれば良いってこと? じゃぁ、その他の Ack の意味は?
さすがにそれはないです。

sort するリスト は、merge の時にclearして良いらしい。
と言うことは unMerge もclearして良い。
sentList にMarkを入れるか。


Fri Sep 17 16:31:04 JST 2010

あぁ、そうか。二つ続けてeditor commandを送ると、二つ続けて Merge することに
なる。Timeout みたいなので防げないこともないが、今は何もしない。

Optimizer が全然動いてないようだ。まぁ、それは良いが...

Undo は正しく行なわれているが、続いて起きる merge で余計なコマンドが入っている
ようだ。

EndMergeで、unMergedCmds を正しくなるように直してみる。少しは近くなったか?

Sat Sep 11 16:45:40 JST 2010

これ、やっぱり難しすぎ。getMergeAgain で、sentMergedList が空でない場合がある。

Termination するようにはなった。しかし、Merge はダメなようだ。

mergeAgain した時に、前のmerge command がeditorから返されることがあって、
それは、全部、読む必要がある。

Merge 中のcommandがblockされてない。

next.send(command) すると、直接、次のeditorに送られてしまうので、
merge 中に止められない。

Sat Jan 16 18:06:37 JST 2010

sentList 全部削除だと quit2 が早めに出されてしまうので、
ちゃんと終了しない。

Tue Jan 12 01:20:12 JST 2010

sentList の先頭を削除するのは、Merge が終った後。一周した部分は、
確定するはずなので全部削除で良い。その後、来た、Ack などは無視して良い。

quit を早く処理してしまう場合があるらしい。

だいぶ近くなって来た気がする。

Sat Jan  9 15:36:35 JST 2010

やっぱり全部ソートしちゃいけないのかな...

Merge のtriggerになるコマンドは、sentList の先頭
sort してはいけないものとは?

unMergedList は、Editor に送ったコマンド全部
sentList は、外部のエディタに送り出したもの全部

そっか、やっぱり、current command が外されちゃっているのはまずいらしい。
あと、sort の順序も良くない。

一回、sort したものは、外して良いっぽい。(ACKが来たものまでは確定)


Sat Jan  2 20:52:17 JST 2010

uMergeList のDELETE command のdeleted text が正しくない...
なので、最初の一回は良いのだが二回目ででたらめになってしまう。
これは、考えてなかった。
  Translator.checkMergeConflict 
が受け取っているので、それを uMergeList にすれば良いのだが...

ちょっと、やっかいなプログラムになるかも。

    unMergeList はMerge 後、削除  ( まだ merge してない list )
    sentList はいじれない         ( 自分が他のエディタに送信した list)

    sentMergedList                 ( 送信した merge command )
    mergeAgainList                ( merge 中に自分のeditorに割り込まれた分 )

確かに、mergeAgainList とかなんか、quueue が多すぎ。


sort なんだけど...

    e0 e1 e2 e0 e1 e2 e0 e1 e2 e0 e1 e2 e0
     |-------|--------|--------|
        |--------|--------|--------|
           |--------|--------|--------|

となる。なので、単純な editor id の順序では、まずいのでは?
(自分の以外はack) ack の eid からの剰余で廻せば良いはず。

mergeでeditorから返ってきたのを unMerge に入れるべき。でな
いと undo が狂う。Merge は unMergeをundoし sentList から構
成する。


Sat Jan  2 03:27:47 JST 2010

うーん、まだ、だめですね。

 Session Manager の quit protocol って入れてない気がする...
 切れた場合の対処も入れないといけないんだよな。

Sat Jan  2 00:02:41 JST 2010

Todo:
    writeLog に level/flag を付けるか?
Done:
    既に付いてました。

Selector.select() のフラグは意味がない。その後、必ず、
selectedKeys() を調べる必要がある。これは、Simulator
と実ソケットの動作が異なる部分。Warning とか出せないものか?

確かに、Merge 変かも。unMerged を undo するのは良いが、
sort するのは、unMerged であって、undo を付加したものではないはず。

いや、それは正しく出来ている。output に先にundoを入れて、
cmd には、そのまま残している。(順序は sort されるので関係ない)

でも、sortedCmds1 に add する時に、Comparator で順序付けされて
しまう。getPrecedence() は必要な列の切出しに使う。

Self Merge case
    E_{00} E_{12} E_{01} E_{23} E_{02} (E_{00})
Other Merge case
    E_{10} E_{11} E_{23} E_{01} E_{02} (Eack_{10})

ack が間に入ることはない(merge で消されるから)
original command の存在しない ack もない。
    (あったら、エラー。無視して良い)
ack の来ない original command は sequence エラーとなるなず。
    (あるいは time out)

ということは、getPrecedence せずに、うむを言わせず
全部 sort すれば良いってこと? ってことは実は、E_{12}
が来た段階で追い越せるかどうかはわかる?

Ack を受け取ったら、それは、必ず先頭にあるはず。

    E_{00} E_{10} E_{11} E_{23} E_{01} E_{02} (Eack_{10})

とかはない。ack は追い越せないから。この間の入力は確定で、
優先順位にしたがって順序付しsortする。次は、

           E_{10} E_{11} E_{23} E_{01} E_{02} (Eack_{10})
                  E_{11} E_{23} E_{01} E_{02} E_{12} (Eack_{11})

で、これは、E_{12} までをsort すれば良い。ということは、
取れるのは最初の一個だけってこと。

nop の場合は、command が着いた直後に出力されるけど、
ack の場合は、それは出力されないで、もう一周する
ack が流される。ack は、一つ前のエディタが出力した
nop に相当する。

この方法だと、編集コマンドの干渉を気にする必要はない。それは、
最適化フェーズで自動的に排除される。(はず) ということは、
getPrecedece の方で sort してやって、今の lineno の比較は
無意味なので排除ということですね。

2方向をスター型/木型に順々に処理する方法でも良いのか。

ということは、unMergedCmds と sendList って、おなじものってこと?

Wed Nov 26 15:15:16 JST 2008

Ring 構造なので、一部のeidtorで止まると全体が止まってしまう。
(非同期なのでeditorが止まることはない) これは、そういう設計
なので仕方がないんだが応答しないEditor/SesisionManagerを
切り離す機構は必要だろう。

このTodo list のmaintenanceをEclipse側で出来ないの? Perl Script でも
でも良いけど。

Wed Nov 26 08:44:29 JST 2008

Todo:
QUITで、まだ、処理があるのにEditorが止まってしまう状況が
あるらしい。

Done:
   syncText 中にquitが来ていたかららしい。

Tue Nov 25 09:13:42 JST 2008

Todo: 
だいたい動いたが、たまに爆発するバグが残っているらしい。
どうも、optimizerのbugっぽいな... いや、違いますね。
getMergeAgainの問題らしいが、直接の原因は良くわからない。

Done:
   なんと、Text.javaのdeleteの条件判断が間違ってました。

Mon Nov 24 22:51:45 JST 2008

watingCommandInMerge のqueueを一旦0にしてから、manageを
呼ぶと、queueが既にあるのに、lockが外れた状態になってしまう。

watingCommandInMerge にforwardedCommandManageから入れちゃうと、
User Editor Command と 一周して来てからのCommandを区別できない...

INSERT_USER/DELETE_USERを入れて回避。Editor側の変更も必要になるが、
まぁ、仕方がない。

Editor側で、自分が出したINSERT/DELETE commandは無視する必要がある。
ついでに、Editor側でINSERT_ACK/DELETE_ACKに書き換える方が良いらしい。

Todo:
INSERT_ACK/DELETE_ACKが出ない場合があるらしい。と言うか、最初の
一回しか出ていない。

Done:
   commandInMerge の扱いが変だった。

Wed Nov 19 19:21:47 JST 2008

ACK base に書き換えるのは良いが、途中でjoinして
きたeditorが、ACKだけを受け取った時には無視する必要が
ある。

Fri Oct 31 20:34:35 JST 2008

Note:

そもそも、NOPを付け加えるのがtrafficを増やしている。一周で
は、状態が確定しないので、INSERT/INSERT_ACKで、それぞれ一周、
計二周廻してやればいい。
    一週目で、そのコマンドを merge waiting queue にいれる
    二週目のAckコマンドを merge waiting queue と照合して、MERGE_STARTする
で、良いんじゃないか? もちろん、editorにfowardして、戻って来た
時点で判定する。
    Ackが戻って来た時点で、MERGE_STARTとみなして良い。
    何もなければ、MERGE_ENDを送り、コマンドがあれば、id=-2を送り、
    最後にMERGE_ENDを送る
なので、MERGE_STARTも必要ない。これで、NOPを付け加えるのと、動作は
同等になる。

ACK command はeditorでは実行しない。

ついでに、packet に source editor ID も付けるんじゃないか?

Tue Oct 28 09:50:23 JST 2008
Todo: (kono)
取り敢えず、動いたみたい。テスト用に、JavaなEditor + 複数のSession Manager 
+ Auto Selector があると良いらしい。

Sun Oct 26 17:36:40 JST 2008
Todo: (kono)
GUI のEditorの方が、どれがどれだか、さっぱりわからない。
せめて、sessionを持っているかとか出ないとだめっぽい。

Todo: (kono)
なんか、NO_NAMEってのが最初に出るらしい。なんだ?
    Done: vim のsession 管理バッファがまだ残っていたようです。
          復活させてもいいかな〜

Todo: (kono)
NOPが廻り続けるという症状があるらしい。
    Done: nop procotol は削除

Todo: (kono)
Optimizer が、まだ、たこならしい。

Sun Oct 26 14:33:51 JST 2008
Todo: (kono)
quit/close 処理が間違っているらしい。
    Done: quit は直しました

Sat Oct 25 10:52:05 JST 2008
Todo: (kono)
Editorからのmutli-sessoin の扱い、TestEditor でのmulti-session
の実装。REPNode.handle の中でreadしちゃうと、handle 間での処理
の引き渡しが出来ない。handlerの切替えにkeyは必要。

一つのeditorの中で、同じsessionに複数selectすると、コマンドを
判定出来なくなる。今でも、新しくchannelを開けるなら複数セッション
をselectすることは可能。channelで識別しているので。
新しいeditorが作られてしまうので、ダメなケースの判定は、直接接続し
ているSMでしか出来ない。と言うことは、selectのcancelのprotocolが
必要らしい。それは、結構、面倒。command に source editor id を
付けてやれば良いのだが...

Todo: (kono)
text editor のバッファが増えるバグがあるらしい。
    Done: たぶん、quit/quit2が動いてない。close の処理のがまずいせい。
          merge にbugがったので、そのせいかも。

Fri Oct 24 19:00:50 JST 2008
Note:
	XML に editor がselectされているかどうかのflagがあった方が良い。
	現状では、update はなんにも役に立たない。
	
Thu Oct 23 10:31:58 JST 2008

Todo: (kono)
UPDATE/UPDATE_ACKが出ない。
	Done: Fri Oct 24 19:00:50 JST 2008
	
Wed Oct 22 19:53:59 JST 2008

Todo: (kono)
やっぱり、END_MERGEが繰り返し出るバグがあるらしい。
    Done: Thu Oct 23 10:12:27 JST 2008 merge confilict 時にmode setを
         忘れてました。
         結局、flag を入れて対症療法しました。

Wed Oct 22 02:31:27 JST 2008

Todo: (kono)
editorの中で、next.getEID() とか next.setQuit2() とかやっているのは、
ditributed の場合は、うまく動かない。だまって、forward されるはず
だが... やっぱり、dummy editor ではなくて、専用のものを作らないと
だめ?
	Done: Wed Oct 22 02:56:30 JST 2008 
	ちょっとあれだが、next がdirecgtでない場合を判断して、向こうの
        forwarder側で処理するのが簡単らしい。
	
Todo: (kono)
Select後のupdateを流してないので、他の人が、そのsessionがselectされたのを
知り得ない。なので、複数のjoin_ackがありえる。
	Done: Sun Oct 26 17:39:05 JST 2008

Mon Oct 20 16:38:39 JST 2008

Todo: (kono)
routing で put の時には、上に上がるだけで良いのだが、下に行くときには、
routing table を持って行く必要がある。ということは、session list を
つける必要があるということだね。でも、tree だから、
  自分の直下んあるもの以外は、上に送る
で良いのか...
	Done: Wed Oct 22 02:56:30 JST 2008 

Todo: (kono)
put/put_ack は、udpateを兼ねる必要があるらしい。そうでないと、session list
が広まらない。
	Done: Wed Oct 22 02:56:30 JST 2008 
session list 中のlocalでないeditorをselectするした場合は、sessionManager
の方に再送してやれば良い。
	Done: Wed Oct 22 02:56:30 JST 2008 
	SELECT0 を作成
	
Mon Oct 20 10:22:02 JST 2008

Todo: (kono)
Inter-session での、editor の削除、master でないeditorのclose/quit。
	Done: Wed Nov 26 15:19:07 JST 2008
	動いているらしい

Sun Oct 19 21:23:27 JST 2008

Todo: IPv6 対応 (kono)
getAddress で取れたアドレスには、すべて、select/connect する
必要がある。localhost な hostname よりも大域的なhostnameを
優先した方が良い。
        Done: server 側は対応。server側のconnect がまだ。

Todo: dispatch先のEditorの作成 (kono)

Session は select 時に、channelを持つeditorが登録される。
外から来た場合は、新しくeditor を作って、それをsession
に登録する必要がある。SessionManagerの入口のforwarderを
session に登録してしまうと、Sessionが一つの時にしか動かない。

put_ack は、putの時にすぐに出してしまって構わない。select_ack
が廻るので、その時にput_ackを出しても良いが...
    Done: Sun Oct 19 23:10:52 JST 2008

Todo: (kono)
複数のsessionのテストを作成する

Sat Oct 18 20:03:10 JST 2008

Todo: Routing Table (kono)

Routing Table (Session, Editor)を作るには、上下双方向の通信が必要。
SessionID を master が作ると、一旦、multi cast した後、もう一度、
上に上げる必要がある。Select の時には、editor から上に上がるので、
その時に構築すれば良い。SessionManagerIDと組み合わせれば、eid/sid
ともに、下から構築出来る。

自分が出したjoin/put/sm_joinに対するackかどうかを見るために、
SessionManagerID は、どうせ必要。この方法だと、routing table
もSessionManagerIDに対してだけ構築すれば良い。とは、ならない。
Session は、複数のSessionManagerにまたがるので。

join_ack が来た時には、そのeditorのrouting tableは完成している、
あるいは、select が完成させるjoin_ackに追い付くことはない。
put_ack も同様。

select は、editorへのpathを探しながら、session routing table
を構築する。もっとも高位のsession managerへのrouting table
は、これで作成される。ここからjoinしたeditorまでのpathは、
そのeditor単一のpathだが、routing table に登録される。
select は、session ringに到達した時点で update を流す。
update は、木をさかのぼりrouting tableを構築する。
これで上方向のroutingは確定する。update_ackにより、
下方向のsesionn routing tableが確定する。
    Done: Sun Oct 19 21:29:08 JST 2008

Wed Oct 15 13:33:58 JST 2008

Todo: (kono)

Session List を渡すタイミング

    SM_JOIN_ACK (必須...)
    SM_JOIN では、Session List は0なはず。
    JOIN,PUT は、multi-cast されるので、その時に登録すれば良い。
       その時に、Session List を送っても良いが...
    SELECTは、joinするeditorからしか出ない。Session List は必要ない。
    SELECT_ACK は、UPDATEが出るので必要ない
    UPDATE,UPDATE_ACK には、Session List が付く
    GATHER,GATHER_ACK には、Session List が付く

Session List では、editor,session に対するroutingも作成する、必要
な情報を含む必要がある。
    eid, EditorName, FileName, sid, SessionManagerName
SessionManagerName が入っていれば、editor, session が
Session Listが来た方向にいるということになる。

SessionManagerName は、network 上でuniqueな必要がある。
sm_join した時に、そのchannelの名前が大域的に確定する。
sm_join は複数行なわれないから、名前が変わることはない。
sm_join された側の名前も、接続されて初めて確定する。
複数 sm_join されることはあるが、その場合は最初のもの
を使う。ということは、localにsm_join された後、大域的
に接続される場合があるってことか。ってことは、やっぱり、
session manager id を配布するべきだってことね。で、
SMの名前はあくまでも補助的に使う。
    Done: Sun Oct 19 21:29:08 JST 2008

Todo: (kono)
UPDATEの情報によって削除も行なう。delete entry が必要。

Todo: (kono)
Routing Table
    <eid, channel>
    <sid, channel>
null は、local。channel==parent なら、自分の下にはいない。
    Done: Sun Oct 19 21:29:08 JST 2008

Tue Oct 14 06:02:37 JST 2008

Todo: (kono)
取りあえず、sm_join()からか。次は、join(),put()。そして、
update()。select()。
    Done: Sun Oct 19 21:29:08 JST 2008

Todo: (kono)
最後に、gather()。

Todo: (kono)
Select用に、routing tableが必要らしい。session ringへの
方向を表すtableを、put, update, update_ack時に作成する。
    Done: Sun Oct 19 21:29:08 JST 2008

Mon Oct 13 12:34:39 JST 2008

Todo: (kono)
sm_join時のloop の検出。sm_joinを受け取った時には、sm接続にloopが
あるかどうかを調べる必要がある。これのテストも必要。
host_aからのsm_joinを受け取ったら、sm_join(host_a)を親に送る。
host_aがsm_join(host_a)を受け取ったら、それはloop。親がsm_join
を受け取れば、そこからsm_join_ackを流して終了。
    Done: Sun Oct 19 21:29:08 JST 2008

Note: (kono)
複数のsession managerにsm_joinする場合もある。その場合は、
親に代わりにsm_joinしてもらう? 親がreachableだとは限りませんが。
禁止してもいいけど...
 
sessionを持っているsm同士がsm_joinするとsidを付け直す必要が
ある。これは大変だなぁ。これも禁止? join/select待ちは許される。
まぁ、新しくsmを上げれば良いだけなんだが、内部的になんとか出来ないの?
面倒なので、取りあえず禁止で良いです。もしかして、updateって、
それよう?

sidのnatという手はあるのか。かなり複雑だけど。それだと複数の親が
いてもだいじょうぶか? ちゃんと書き換え出来るなら動くっぽい。あとで
入れることも可能か。				

selectが以外に難しい。sessionとjoinして来たeditorを見つけない
といけない。しかも、最短距離で。見つけるだけなら簡単だが...	取りあえず、
select は、join したsession managerでしか出来ないということに
する。そうでないと、joinしたeditorを探す必要があり、全部を見るか、
routing tableを作る必要がある。後者でも良いが。

Note: (kono)
Session間の通信は、木を作って、自分の親に送り、親がack/updateをmulti cast
すれば良い。sm_join した時に、どちらが親になるかはどうやって決める? 繋げた先が
親ってのが簡単。親がいないのがmasterとなる。親が死んだら自分が親。親が死んで、
sessionがmasterを失った時は? loop の検出も必要。
再接続は可能? 可能だが、再put/join/selectする必要がある。
put は、親まで上がってsidを決定しなければならない、その後、put_ackを出せる。
joinは、localでの処理で問題ないが、join_ackはselectが終わってから出る必要がある。
selectは session owner に行き着く必要がある。session がconnectionを
持っているとは限らない。親がselectする方が自然か?
put_ack/join_ack/select_ackは、updateを見てでの処理で良い? 対象イベント
が明示されていた方が楽だが...
この方法だと、session managerはidは持っていないが、木構造の中でuniqeな
位置を持つ。
(前の資料があれば良いのに...)

Mon Oct 13 02:57:45 JST 2008
Todo: (kono)
InterManagerのquit中のsessionへのjoinの扱い。(putは来ないがjoinはありえる)。
UPDATEで、sessionをlockしてからquitするか?
TestGUIで、selectする前にEditor0がquitしちゃう場合もある。

Todo: (kono)
SessionManager間のプロトコルの図が、どこにもない。あんなに苦労して考えたのに。
また、自分で書けってか。
 SessionManager SM_JOINと、masterの決定
 put/selectの生成、masterによるsession id の決定
 updateによるsessionの共有
 	Done:Mon Oct 13 19:02:42 JST 2008 (kono)

Sun Oct 12 19:12:20 JST 2008

Todo: (kono)
DELETE時のundoのための文字列は、SM/Editor間でだけ必要。Editorから戻って来た
コマンドをSM側で最新にする必要がある。外に出す時には使わないので消して良い。
	Done: 戻って来た時に、unMergedListに入れているらしい

Todo: (kono)
new String(hoge)。Javaの文字列は変更不可能なので、こんな
ことをする意味はない。
	Done:

Todo: (kono)
PUT の時に、master session managerまで行って、session番号を確定する
必要がある。それまでは、PUT_ACKを出してはならない。
    Done: Sun Oct 19 21:29:08 JST 2008 
	session manager IDを使ってuniqueにしたので、不要になった。
	即座に PUT_ACKを出して構わない。

Todo: (kono)
SM_JOIN時にmaster session managerを決定するプロトコルを実装する必要が
ある。たぶん、UPDATEだと思うが...
    Done: Sun Oct 19 21:29:08 JST 2008 
	木の根をmasterとして、変更しない。

Todo: (kono)
外から、きたSession Listを、ただしく自分に反映する。
    Done: Sun Oct 19 21:29:08 JST 2008 

Todo: (kono)
test.ServerSample.java はあるが、ClientSample.java がない。

Todo: (kono)
SYNC出すコードをまだ入れてない。

Sun Oct 12 10:33:36 JST 2008

Todo:
END_MERGEが繰り返し出てしまう(kono)
    Done: Sun Oct 19 21:29:08 JST 2008 
	直ったかな?

Sat Oct 11 22:28:49 JST 2008

Todo:
Session Manager をまたがった接続のテスト (kono)
	Done: Sun Oct 12 19:18:23 JST 2008

Todo:
Optimizerを使った場合のテスト (kono)
行番号0があるとだめらしい。
	Done: (takano) Thu Oct 23 13:05:52 JST 2008
	

Todo:
manager.remove(editor) の動作のタイミング、 channel closeの扱い
たぶん、quit2のackで、殺すのが正しいと思う。(kono)
	Done: Mon Oct 13 02:57:45 JST 2008
	

Fri Oct 10 15:24:42 JST 2008
sid は大域的にuniqueにする必要がある。UPDATEで新しくsessionを作ったことを
通知して、Masterが新しいsidを決定し、UPDATE_ACKで他のSessionManagerに知らせる(kono)
    Done: Sun Oct 19 21:29:08 JST 2008 
	put時に、そのsession managerでsession manager idを使って、
	uniqueなsidを作成する。put/join/ackで他のSessionManagerに知らせる。

Mon Oct  6 16:39:57 JST 2008

Todo: translator にある5つのqueueが、Editor にもある。merge のアルゴリズムの
実装を見直す必要がある。(kono)
	Done:Sat Oct 11 22:28:49 JST 2008

Todo:
SessionManager の向うにあるeditorにREPCommandを送るコードがない。Editor 扱いしても良いが、
Editor が複雑すぎるので、それは好ましくない。Editor に nextChannelを持たせるのが良いか? (kono)
    Done: Forwarder を作った

Todo:
SessionManger のeditor がmerge 中のeditor commandをblockするのは良いが、
sessionManger コマンドをblockされるのは困る。(kono)
	Done: Sat Oct 11 22:28:49 JST 2008

Wed Oct  1 20:58:51 JST 2008
	
Todo: Session ring 廻るcommand packetは、基本的に書き換えられるべきではない
  eid, seq の組でuniqueになる。現状では、そここで書き換えが起きているらしい。
   eid = -1 (Session Manager), eid = -2 (MergeCommand) あたりが
   特殊らしい。 でも、実際には生成されてないっぽい。(kono)
      Done: Mon Oct  6 16:40:14 JST 2008 (kono)

Todo: SessionManagerのprotocolのswitch文で、そこら中でgetEditor/getSessionが
  呼ばれている。これらは、for loopで探しているので、繰り返し行うのは変。(kono)

Todo: REPCMD_INSERTが止まらない... (kono)
      Done: Mon Oct  6 16:40:38 JST 2008 (kono)

Todo: SessionMnager のmessageをREPLogger baseに書き換える。 (kono)
	  Done: Thu Oct 23 13:05:52 JST 2008
	  
Wed Oct  1 15:35:44 JST 2008

Todo: SessionManager 複数のコマンドをまとめてeditorに送るとdead lockする
    可能性がある。送信キューを作り、select loop しながら、ひとつずつコマンドを
    送信する (kono)
	Done: (kono)

Todo: Editor quit, quit2 の実装
  quit2 では、自分の送信したコマンドが戻ってくるまで待つ必要がある。
  editor 毎の状態となる。(kono)
	Done: (kono)