Subject: Re: [overlayweaver-ja] Re: macstshellのエミュレータについて
Kazuyuki Shudo
> From: Kazuyuki Shudo <20...@shudo.net>
> To: overlayw...@googlegroups.com
>> From: Itou <juku...@yahoo.co.jp>
>> Date: Mon, 7 Dec 2009 05:11:43 -0800 (PST)
>
>>> > ・ルーティングをPastry、Kademliaにしてマルチキャスト配信木を構築した際、全ての子が1つの親に集まるような深さ１の木が構築されてし
>>> > まうのですが、これは上手く動いているのでしょうか？尚、ルーティングをChordにした場合は深さ2以上の木が構成されました。
>>>
>>> 配信木は Scribe という方式を使ってます。
>>> 深さ 1ということは、担当ノードまでの経路長が 1だったということで、
>>> そういうものです。
>>> 経路長が比較的長くなる Chord では、経路長が 2以上になった場合もあった、
>>> ということかと想像します。
>>>
>>> ノード数がある程度多くならないと、経路は長くなりません。
>>> シナリオを拝見したところ、34ノードしか起動していないので、
>>> そんなものだと思います。
>>
>> ノード数が少ないということで、2000ノード、5000ノードと増やしてみましたが、やはり一つの親に集まってしまっているようです。
Mcast についても DHT と同様に
多数のノードを起動できるように変更しました。
(今、手元の開発用マシンから CVS commit できない状況でして、
変更済みのコードの配布には、少し時間がかかりそうです。)
で、1,000 ノードでひとつの配信木を作ってみたところ (*)、
Pastry でも高さ 2以上となりました。
(*) シナリオを添付します。
visualizer の図をウェブに置きました：
技術フェチ日記 2009/12/9
http://www.shudo.net/diary/2009dec.html#20091209
図を見ても木の高さはわかりませんが、
出力メッセージを見るに、確かに高さ 2以上にはなっていました。
Kazuyuki Shudo/首藤一幸 私をたばねないで あらせいとうの花のように
20...@shudo.net http://www.shudo.net/
Itou
回答ありがとうございました。
[木の深さに関して]
2000ノードや5000ノードでも動き、出力メッセージを見て深さも１になっていたのでおかしいなと思っていましたが、どうやら私のシナリオの作り方
が間違っていたようでした。
現在は思っていたように動くようになりました。
添付していただいたシナリオも大変参考になりました。お手数をおかけしました。
配信木の形についても理解できました。ありがとうございました。
質問続きで大変恐縮ですが、もう一つお聞きしたいのですが
--eventdrivenのオプションでイベント駆動にした際に、visualizerの起動が遅れ、ノードが上手く表示されないのです
イベント駆動で、次のコマンドへの待機時間を作る様な機能はありますでしょうか？
Kazuyuki Shudo
> Message-ID: <d65deca9-2104-4387...@2g2000prl.googlegroups.com>
> From: Itou <juku...@yahoo.co.jp>
> Date: Mon, 14 Dec 2009 05:56:52 -0800 (PST)
> 質問続きで大変恐縮ですが、もう一つお聞きしたいのですが
> --eventdrivenのオプションでイベント駆動にした際に、visualizerの起動が遅れ、ノードが上手く表示されないのです
> イベント駆動で、次のコマンドへの待機時間を作る様な機能はありますでしょうか？
以下、2通りの方法を示します。
それぞれ、0.9.8 向けのパッチを添付します。
パッチの適用方法がわからない場合、変更内容をなんとか目で読み取ってください。
パッチが当たるかどうかはともかく、
方法自体は 0.9.8 より前のバージョンにも通用します。
・invoke-synchronously.diff
Overlay Visualizer (owviz コマンド, ow.tool.visualizer.Main クラス) を
起動する際 main() メソッドを呼び出すわけですが、
スレッドプールを使うのではなく、
タイマ (ow.util.Timer) 自身が呼び出すようにします。
最初からそうしておけばいいのでは? と思うかもしれませんが、
一般のアプリは main() メソッドを呼んだら実行が済むまで返ってこないわけで、
タイマがそれを待たされてはかなわないので、スレッドプールを使ってます。
・wait-for-invocation.diff
event driven モードでも、schedule invoke の実行前に限っては
シナリオ通りの時間だけ待つようにします。
あまりきれいな方法ではありません。
Itou
パッチまで添付していただいて、ありがとうございました。
うまく動かすことができました。
遅くなりましたが、ありがとうございました。