--- a/Todo	Mon Oct 13 13:16:31 2008 +0900
+++ b/Todo	Mon Oct 13 16:56:39 2008 +0900
@@ -1,17 +1,41 @@
 Mon Oct 13 12:34:39 JST 2008
 
+Todo: (kono)
+sm_join時のloop の検出。sm_joinを受け取った時には、sm接続にloopが
+あるかどうかを調べる必要がある。これのテストも必要。
+host_aからのsm_joinを受け取ったら、sm_join_ackと同時に、親に
+ch_master(host_a)を送る。host_aがch_master(host_a)を
+受け取ったら、それはloop。sm_joinを送るのでも良いけど。
+
 Note: (kono)
-Session間の通信は、木を作って、自分の親に送り、親がACKをmulti castすれば良い。
-sm_join した時に、どちらが親になるかはどうやって決める? 繋げた先が親ってのが
-簡単。親がいないのがmasterとなる。親が死んだら自分が親。親が死んで、
-sessionがmasterを失った時は? loop の検出も必要。updateにunique idを
-付けて二度目が来たらloop、または重複。closeして良い。ch_masterは必要ない。
+複数のsession managerにsm_joinする場合もある。その場合は、
+親に代わりにsm_joinしてもらう? 親がreachableだとは限りませんが。
+禁止してもいいけど...
+ 
+sessionを持っているsm同士がsm_joinするとsidを付け直す必要が
+ある。これは大変だなぁ。これも禁止? join/select待ちは許される。
+まぁ、新しくsmを上げれば良いだけなんだが、内部的になんとか出来ないの?
+面倒なので、取りあえず禁止で良いです。もしかして、updateって、
+それよう?
+
+sidのnatという手はあるのか。かなり複雑だけど。それだと複数の親が
+いてもだいじょうぶか? ちゃんと書き換え出来るなら動くっぽい。あとで
+入れることも可能か。					
+
+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を見てでの処理で良い?
+put_ack/join_ack/select_ackは、updateを見てでの処理で良い? 対象イベント
+が明示されていた方が楽だが...
+この方法だと、session managerはidは持っていないが、木構造の中でuniqeな
+位置を持つ。
 (前の資料があれば良いのに...)
 
 Mon Oct 13 02:57:45 JST 2008