p2p-sim-develop Mailing List for p2p-sim (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

阿部です。

プライベートIPでの参加ノードはどう取り扱いますか？
UDP通信ってポートを空けずに双方向通信ってできるの？

test1

test4

test

西村です。

案に対しての返信ではないんだけどこの議論の仕方ツリー構造
で管理していけば情報を整理していけそうだね

ツリー構造で意見をまとめられそうなツール探してみます。

--- P2Pシミュレータ開発
<p2p...@li...> wrote:

> 松永です。
>   
> いくつか気が付いた所があるので、以下に書きます。
>   
> 書き込む所には【】を埋め込みます。
>   
>
********************************************************************
> 【こっちをA案と呼ぶことにします】
> 条件付で、不完全なキャッシュのファイルキー登録を認め
る。
> [概要]
> キャッシュを保持するノードは、自身が持つ不完全なキャッ
シュを、キーサーバへのファイルキー登録を行わないことにし
ていた。
> これを撤廃して、キーサーバに完全なキャッシュのファイル
キーが１つでもあれば、不完全なファイルキーの登録も認める
。
> これを行うために、ファイルキーを完全と不完全の２つの状
態で管理する。
> キーサーバは完全なファイルキーが無くなれば、それ以降、
不完全なファイルキーの登録を認めない。
> 不完全なキャッシュを持つノードもファイルキーの登録を行
わない。
> この場合、ファイルは自然消滅する。
> [薦める理由]
> 不完全なキャッシュのファイルキー登録を認めない理由が、
不完全なキャッシュがネットワーク上にゴミとして残り、しか
も、どれがゴミなのかが明確にならない状態を防ぐためであっ
た。
> しかし、ここで薦める方法なら、その危険性が無くなる。
> また、一部分だけでもファイルの送信を行えるので、ファイ
ル共有の効率が上がる。
>  
>
********************************************************************
> 【こっちをB案と呼ぶことにします】
> 上記について、デメリットを以下に記載します。
> 不完全なファイルを持つノードに対してファイル取得要求を
投げた場合、
> どの箇所を保持しているか知らない以上、利用できない可能
性があります。
> 【キャッシュが不完全過ぎると、確かに無駄な通信が発生し
やすくねるね。A案でやるなら不完全すぎるキャッシュはキー
登録しないほうが良さそうだね。そうすれば、無駄な通信が発
生といってもたいした量じゃないと思うんだけど。】
> ファイルの前半しか持っていないノードが大量発生した場合
、結局意味のないノードリストになります。
> 【A案でも多重ダウンロードのやり方次第で、「ファイルの
前半しか持っていないノードが大量発生」は防げるよ。先頭か
らダウンロードするのをやめるだけ。】
> 無駄な通信が大量発生する原因となります。
> (後半部分がほしいのに、不完全キャッシュ保持ノードは前
半しかもっていない可能性)
>   
> キーサーバが不完全キャッシュ保持ノードリストと完全キャ
ッシュ保持ノードリストの2つを管理すると言うならば、同じ
コストである以下の機能を提案します。
> ・キーサーバは２分割前半キャッシュ保持ノードリストと２
分割後半キャッシュ保持ノードリストを持つ。
> ・完全キャッシュ保持ノードは両方のリストに登録する。
> ・半分のダウンロードが完了した時点でどちらかのリストに
登録する
> 【つまり、B案でファイル共有に貢献するためには、限定さ
れた一部分で、最低半分(1/n)のキャッシュを持たないといけ
なくなるね。そうすると、通信のコストは少し減るけど、キー
登録の条件が厳しくなって、ファイルの共有の効率も落ちるこ
とになるね。】
>   
> 各ノードの持っている部位がどこなのか明確なため無駄な通
信が発生しません。
> また、多重ダウンロードを行いやすくなります。
> さらに、各キャッシュサーバの必要容量が低下します。
>
【A案に対して、B案が減ると言っても、ファイル一個の半分(1/n)
分の容量だよね。ディスク容量に対して、たいした量じゃない
と思うんですけど。】
> キャッシュサーバは前半と後半のバランスを見て必要なほう
のキャッシュを保持します。
> 一般ノードはダウンロード時、前半と後半で別なサーバを用
いるため、多重ダウンロードが行いやすい。
> 【A案でも複数個のサーバを使って多重ダウンロードするよ
。その場合、数に制限が無いから、１つファイルに着目すれば
転送速度は速いよ。】
> 上記はキーサーバを同コストで利用する際の提案として記載
させていただいたためｎ分割と考えてもかまいません。
> 【最適な分割数の判断が難しいところだね。少なすぎるとキ
ー登録する条件が厳しすぎてファイル共有の効率が落ちるし、
多すぎると、ブロック単位の登録と変わらなくなるね】
>  
> 【なんとなくだけど、B案を、個人的な好みと勘で評価して
、ルールが美しくような気がするなー。まあ、根拠を説明して
いないんで戯言ですけど。】
>
********************************************************************
>  
> とりあえず、気になったところにコメント入れてみましたけ
ど、これじゃA案とB案どちらが良いかは見えにくいんで、A案
とB案の利点、欠点をまとめる必要がありそうだね。
>  
> とりあえず、以下を埋めてみよう。（代わりの案でも良いよ
）
>   ・A案
> [利点]
>    
>   [欠点]
>   
> ・B案
> [利点]
>    
>   [欠点]
>    
>    
>   ※松永は明日埋めます。
> 
>  
> 
> 
> ---------------------------------
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラ
ボ≫で！
> >
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get
> the chance to share your
> opinions on IT & business topics through brief
> surveys -- and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
_______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
>
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
> 

松永です。

  気が付いた所に【】を入れてコメントしときました。

  とりあえず、本当にちゃんと比較したいなら、以下の情報でも情報量が全然足りないと思いました。

  A案、B案それぞれの方向で、タスクとその処理内容、参照するテーブルを挙げて、それぞれの案である程度アルゴリズムを最適化した段階で検討しないと、本当の検討は出来ないよ。

  *******************************************************************************************************
  阿部です。

  A案とB案の利点と欠点を記載するまえに、気づいたんだけど、
A案とB案で戦わせるにあたり、いくつか不明な点があるんだよね。
だから、前提条件を固めたいんだけど。

  ◎前提条件定義

[B案について]
・条件を２分割と定義します。
　キーサーバの負荷を同じにして同条件で評価するため。
【キーサーバへのファイルキー登録の条件が違うのでキーサーバの負荷は同じにならない。
(「n%のキャッシュを保持しているか？」と「n分割した内の一部のキャッシュを完全にもっているか？」)
A案ではおそらく、完全キャッシュ保持ノードの割合が増えるにしたがって、不完全キャッシュのファイル登録の条件を厳しくすることになりそう。ファイルキー登録に必要なキャッシュの完全度%を徐々に引き上げる。(キャッシュ保持ノードが自律的に判断)】

  [A案について]
・完全キャッシュ、不完全キャッシュ選択アルゴリズムについて以下のように定
義
  １．現在のファイルの保持キャッシュ量が少ない場合
　　　高い確率で部分キャッシュ保持ノードからダウンロード試行
２．現在のファイルの保持キャッシュ量が1/2の場合
　　　部分キャッシュ保持ノードから取得するか、
　　　完全キャッシュ保持ノードから取得するかは1/2の確率
３．完全キャッシュに近い状態の場合
　    高い確率で完全キャッシュ保持ノードからダウンロード試行を行う
  と言う感じで保持キャッシュ量に応じて確率でダウンロード試行相手を切り替え
ていきます。
キャッシュ保持量が0に近ければ、どこから取得しても問題ないから、
部分キャッシュ保持ノードでOKだし、完全キャッシュに近ければ、できるだけ
完全キャッシュ保持ノードにしたほうが失敗は少なくなるはず。
  【A案ではおそらく、大雑把に以下のアルゴリズム(ルール？)を使う
1.多重ダウンロード最大数を決める(決まっている、またはユーザが決める？)。ここでは例えば20。☆A案では多重ダウンロード数を出来るだけ多く設定して1つのファイルを高速に集めることを心がける。そのために同時にダウンロードできるファイルの数が減っても構わない。
2.完全キャッシュ保持ノードと不完全キャッシュ保持ノードの割合を求める。ここでは例えば完全1:不完全3。
3.多重ダウンロード最大数を1:3(キャッシュ保持ノードの割合)で、完全ノード、不完全ノードの枠に割り当てる。
ここでは、完全5:不完全15。
4.不完全ノード15台からの多重ダウンロードを開始する。
5.完全ノード5台から、不完全ノードから集まらなかったブロックを優先して多重ダウンロードを開始する。
6.途中でノードが死んでも、他のノード情報を拾ってきて、枠を埋める。
7.不完全ノードが持っているブロックを落とし切ったら、完全ノードからのダウンロードだけを行う。】

  ・部分キャッシュ保持ノードは常に完全キャッシュを目指している。
上記定義はあってる？この条件によってA案の有利不利が確定するような気がする
でも普通に考えて、上記定義をとるしかないと思うんだけど・・・
【ノードがキャッシュをダウンロードする条件はダウンロード指定された時のみ。
キャッシュサーバであれば、キャッシュを部分的にでも持っていれば、自動的にダウンロード指定するための優先順位は上がる。(ただし割合次第)
全てのノードで、ディスク容量が少なくなれば部分キャッシュは最優先で削除する。】

  [A案B案共通]
キーサーバのキー保持量には限界が設定されている。(当たり前)
ファイルキー一つにつき登録可能ノードは常に一定数(未決定)であり
定期的にノードの入れ替えを行う
(ノードの入れ替えアルゴリズムについて)
1.キャッシュ保持ノードがダウンロード要求受け入れ限界に達したら
　ダウンロード要求受け入れ停止指示(仮)をキーサーバに送信する。  
2.キーサーバは上記指示を受け入れ、ファイルキーリストから該当ノードを削除
し
　別な候補ノードに差し替える
【システム管理サーバがキーサーバへ指示を出すのではなく、キーサーバがシステム管理サーバが公開しているキャッシュ保持ノード数と登録可能ノード数を見て、登録可否、どこに登録するかを判断する。(各ノードの連携は出来るだけ指示制ではなく、自律判断にする方向で←自律判断制の方が、仕組みを簡単にしやすい傾向にありそうなので)】

  つまり、上記アルゴリズムに従うのであれば、キャッシュ保持ノードが一定数を
超えてしまうと
キーサーバから全体数を把握するのは不可能となる。
【ファイルキーをキーサーバに登録するかは、各一般ノードの判断に任せるので、キャッシュ保持ノードが一定数を超えていなくても、キーサーバから全体数を把握するのは不可能。キーサーバから見てファイル保持ノード1つ1つがどのキーサーバにファイルキーを登録するかはわからない。】

  【ノードの入れ替えアルゴリズムについて、A案では以下のアルゴリズム(ルールかな？)を使おうと考えている。もっと考えればもっとアイデアは出ると思う(B案に使えるアイデアもある）
1.ファイルキーが持つキャッシュ保持ノード数の枠を決める。(決まっている)
2.完全か不完全どちらかのステータスでファイルキー登録を受け付ける。
3.キャッシュ保持ノード数の枠が一杯になったら、不完全ノードを優先的に追い出す。(不完全キャッシュを持つノードは自律的に登録をやめる)
4.タイムアウトに達したキャッシュ保持ノードをファイルキーから削除する】

  とりあえず、上記前提を受け入れてもらったとして、それぞれの利点、欠点を話
し合わせてください。
  *******************************************************************************************************

P2Pシミュレータ開発 <p2p...@li...> wrote:
    松永です。

  まだ追加するかもしれませんが、少しまとめてみました。
片方の利点が片方の欠点とも取れるので、妙にまとまってませんが、とりあえず勘弁して下さい。

  ただし、松永は直感的にA案びいきで、今日は考えることに疲れているので、不公平な判断をしていると思われます。
阿部君の意見も知りたいです。

  ・A案
[利点]
  1.１個のファイルに着目して、ダウンロードが高速
ブロック単位で多重ダウンロードするため、一個のファイルを高速に収集できる。

[欠点]
  1.ダウンロードを始める前に、ブロック単位でキャッシュの持ち主を探す必要があり、B案に比べて、無駄な通信コストがかかる。
  2.トレードオフがあり、そのバランスとりが難しい。
ファイルキーを登録できる、最低キャッシュの完全度の設定によって、ファイル共有効率と、通信コストのトレードオフがある。
完全度を下げると、ファイル共有の効率は上がるが、キャッシュの持ち主を探すための通信コストが上がる。
完全度を上げると、キャッシュの持ち主を探すための通信コストは下がるが、ファイル共有の効率は下がる。

  ・B案
[利点]
1.ダウンロードを始める前に、ブロック単位でキャッシュの持ち主を探す必要がない。

  [欠点]
1.多重ダウンロードとの相性が悪い。
いち早くファイル共有に貢献したければ、前半だけ高速に落としたいが、これをやると、B案の「多重ダウンロードをやりやすい」(前半と後半を同時に落とせば簡単？)という利点が消える。
  2.トレードオフがあり、そのバランスとりが難しい。
分割数の設定によって、ファイル共有効率と、キーサーバの負荷のトレードオフがある。
分割数を減らすと、キー管理の負荷は低いが、ファイル登録の条件が厳しくなり、ファイル共有の効率が落ちる。
分割数を増やすと、ファイル共有の効率が上がるが、キー管理の負荷が上がり、キーサーバが重くなる。
  3.キャッシュのサイズによって、分割数を切り替える制御が必要になりそう。
大きいファイルになればなるほど分割数を増やさないと、ファイルキー登録の条件がどんどん厳しくなる。
しかし、これをやると制御が難しくなる。キーサーバが重くなる。最適なバランスとりも難しい。
バランスのとり方を間違えるとファイル共有効率がかなり悪くなりそう。
  4.ファイルが複数ノードに分散する
分割して管理するので、ファイルが複数ノードに分散するのは免れない。
そうすると、確実な共有を行える可能性が下がる。

P2Pシミュレータ開発 <p2p...@li...> wrote:
    松永です。

いくつか気が付いた所があるので、以下に書きます。

書き込む所には【】を埋め込みます。

********************************************************************
【こっちをA案と呼ぶことにします】
条件付で、不完全なキャッシュのファイルキー登録を認める。
[概要]
キャッシュを保持するノードは、自身が持つ不完全なキャッシュを、キーサーバへのファイルキー登録を行わないことにしていた。
これを撤廃して、キーサーバに完全なキャッシュのファイルキーが１つでもあれば、不完全なファイルキーの登録も認める。
これを行うために、ファイルキーを完全と不完全の２つの状態で管理する。
キーサーバは完全なファイルキーが無くなれば、それ以降、不完全なファイルキーの登録を認めない。
不完全なキャッシュを持つノードもファイルキーの登録を行わない。
この場合、ファイルは自然消滅する。
[薦める理由]
不完全なキャッシュのファイルキー登録を認めない理由が、不完全なキャッシュがネットワーク上にゴミとして残り、しかも、どれがゴミなのかが明確にならない状態を防ぐためであった。
しかし、ここで薦める方法なら、その危険性が無くなる。
また、一部分だけでもファイルの送信を行えるので、ファイル共有の効率が上がる。
  ********************************************************************
【こっちをB案と呼ぶことにします】
上記について、デメリットを以下に記載します。
不完全なファイルを持つノードに対してファイル取得要求を投げた場合、
どの箇所を保持しているか知らない以上、利用できない可能性があります。
【キャッシュが不完全過ぎると、確かに無駄な通信が発生しやすくねるね。A案でやるなら不完全すぎるキャッシュはキー登録しないほうが良さそうだね。そうすれば、無駄な通信が発生といってもたいした量じゃないと思うんだけど。】
ファイルの前半しか持っていないノードが大量発生した場合、結局意味のないノードリストになります。
【A案でも多重ダウンロードのやり方次第で、「ファイルの前半しか持っていないノードが大量発生」は防げるよ。先頭からダウンロードするのをやめるだけ。】
無駄な通信が大量発生する原因となります。
(後半部分がほしいのに、不完全キャッシュ保持ノードは前半しかもっていない可能性)

キーサーバが不完全キャッシュ保持ノードリストと完全キャッシュ保持ノードリストの2つを管理すると言うならば、同じコストである以下の機能を提案します。
・キーサーバは２分割前半キャッシュ保持ノードリストと２分割後半キャッシュ保持ノードリストを持つ。
・完全キャッシュ保持ノードは両方のリストに登録する。
・半分のダウンロードが完了した時点でどちらかのリストに登録する
【つまり、B案でファイル共有に貢献するためには、限定された一部分で、最低半分(1/n)のキャッシュを持たないといけなくなるね。そうすると、通信のコストは少し減るけど、キー登録の条件が厳しくなって、ファイルの共有の効率も落ちることになるね。】

各ノードの持っている部位がどこなのか明確なため無駄な通信が発生しません。
また、多重ダウンロードを行いやすくなります。
さらに、各キャッシュサーバの必要容量が低下します。
【A案に対して、B案が減ると言っても、ファイル一個の半分(1/n)分の容量だよね。ディスク容量に対して、たいした量じゃないと思うんですけど。】
キャッシュサーバは前半と後半のバランスを見て必要なほうのキャッシュを保持します。
一般ノードはダウンロード時、前半と後半で別なサーバを用いるため、多重ダウンロードが行いやすい。
【A案でも複数個のサーバを使って多重ダウンロードするよ。その場合、数に制限が無いから、１つファイルに着目すれば転送速度は速いよ。】
上記はキーサーバを同コストで利用する際の提案として記載させていただいたためｎ分割と考えてもかまいません。
【最適な分割数の判断が難しいところだね。少なすぎるとキー登録する条件が厳しすぎてファイル共有の効率が落ちるし、多すぎると、ブロック単位の登録と変わらなくなるね】
  【なんとなくだけど、B案を、個人的な好みと勘で評価して、ルールが美しくような気がするなー。まあ、根拠を説明していないんで戯言ですけど。】
********************************************************************
  とりあえず、気になったところにコメント入れてみましたけど、これじゃA案とB案どちらが良いかは見えにくいんで、A案とB案の利点、欠点をまとめる必要がありそうだね。
  とりあえず、以下を埋めてみよう。（代わりの案でも良いよ）
  ・A案
[利点]

  [欠点]

・B案
[利点]

  [欠点]

  ※松永は明日埋めます。

---------------------------------
  [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
  [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
[10th Anniversary] special auction campaign now!

阿部です。

A案とB案の利点と欠点を記載するまえに、気づいたんだけど、
A案とB案で戦わせるにあたり、いくつか不明な点があるんだよね。
だから、前提条件を固めたいんだけど。

◎前提条件定義
[B案について]
・条件を２分割と定義します。
　キーサーバの負荷を同じにして同条件で評価するため。

[A案について]
・完全キャッシュ、不完全キャッシュ選択アルゴリズムについて以下のように定義

１．現在のファイルの保持キャッシュ量が少ない場合
　　　高い確率で部分キャッシュ保持ノードからダウンロード試行
２．現在のファイルの保持キャッシュ量が1/2の場合
　　　部分キャッシュ保持ノードから取得するか、
　　　完全キャッシュ保持ノードから取得するかは1/2の確率
３．完全キャッシュに近い状態の場合
　    高い確率で完全キャッシュ保持ノードからダウンロード試行を行う

と言う感じで保持キャッシュ量に応じて確率でダウンロード試行相手を切り替えていきます。
キャッシュ保持量が0に近ければ、どこから取得しても問題ないから、
部分キャッシュ保持ノードでOKだし、完全キャッシュに近ければ、できるだけ
完全キャッシュ保持ノードにしたほうが失敗は少なくなるはず。

・部分キャッシュ保持ノードは常に完全キャッシュを目指している。
上記定義はあってる？この条件によってA案の有利不利が確定するような気がする
でも普通に考えて、上記定義をとるしかないと思うんだけど・・・

[A案B案共通]
キーサーバのキー保持量には限界が設定されている。(当たり前)
ファイルキー一つにつき登録可能ノードは常に一定数(未決定)であり
定期的にノードの入れ替えを行う
(ノードの入れ替えアルゴリズムについて)
1.キャッシュ保持ノードがダウンロード要求受け入れ限界に達したら
　ダウンロード要求受け入れ停止指示(仮)をキーサーバに送信する。
2.キーサーバは上記指示を受け入れ、ファイルキーリストから該当ノードを削除し
　別な候補ノードに差し替える

つまり、上記アルゴリズムに従うのであれば、キャッシュ保持ノードが一定数を超えてしまうと
キーサーバから全体数を把握するのは不可能となる。

とりあえず、上記前提を受け入れてもらったとして、それぞれの利点、欠点を話し合わせてください。

06/09/30 に P2Pシミュレータ開発<p2p...@li...> さんは書きました:
> 松永です。
>
>  いくつか気が付いた所があるので、以下に書きます。
>
>  書き込む所には【】を埋め込みます。
>
> ********************************************************************
>  【こっちをA案と呼ぶことにします】
>  条件付で、不完全なキャッシュのファイルキー登録を認める。
>  [概要]
> キャッシュを保持するノードは、自身が持つ不完全なキャッシュを、キーサーバへのファイルキー登録を行わないことにしていた。
>  これを撤廃して、キーサーバに完全なキャッシュのファイルキーが１つでもあれば、不完全なファイルキーの登録も認める。
>  これを行うために、ファイルキーを完全と不完全の２つの状態で管理する。
>  キーサーバは完全なファイルキーが無くなれば、それ以降、不完全なファイルキーの登録を認めない。
>  不完全なキャッシュを持つノードもファイルキーの登録を行わない。
>  この場合、ファイルは自然消滅する。
>  [薦める理由]
> 不完全なキャッシュのファイルキー登録を認めない理由が、不完全なキャッシュがネットワーク上にゴミとして残り、しかも、どれがゴミなのかが明確にならない状態を防ぐためであった。
>  しかし、ここで薦める方法なら、その危険性が無くなる。
>  また、一部分だけでもファイルの送信を行えるので、ファイル共有の効率が上がる。
> ********************************************************************
>  【こっちをB案と呼ぶことにします】
>  上記について、デメリットを以下に記載します。
>  不完全なファイルを持つノードに対してファイル取得要求を投げた場合、
>  どの箇所を保持しているか知らない以上、利用できない可能性があります。
> 【キャッシュが不完全過ぎると、確かに無駄な通信が発生しやすくねるね。A案でやるなら不完全すぎるキャッシュはキー登録しないほうが良さそうだね。そうすれば、無駄な通信が発生といってもたいした量じゃないと思うんだけど。】
>  ファイルの前半しか持っていないノードが大量発生した場合、結局意味のないノードリストになります。
> 【A案でも多重ダウンロードのやり方次第で、「ファイルの前半しか持っていないノードが大量発生」は防げるよ。先頭からダウンロードするのをやめるだけ。】
>  無駄な通信が大量発生する原因となります。
>  (後半部分がほしいのに、不完全キャッシュ保持ノードは前半しかもっていない可能性)
>
> キーサーバが不完全キャッシュ保持ノードリストと完全キャッシュ保持ノードリストの2つを管理すると言うならば、同じコストである以下の機能を提案します。
>  ・キーサーバは２分割前半キャッシュ保持ノードリストと２分割後半キャッシュ保持ノードリストを持つ。
>  ・完全キャッシュ保持ノードは両方のリストに登録する。
>  ・半分のダウンロードが完了した時点でどちらかのリストに登録する
> 【つまり、B案でファイル共有に貢献するためには、限定された一部分で、最低半分(1/n)のキャッシュを持たないといけなくなるね。そうすると、通信のコストは少し減るけど、キー登録の条件が厳しくなって、ファイルの共有の効率も落ちることになるね。】
>
>  各ノードの持っている部位がどこなのか明確なため無駄な通信が発生しません。
>  また、多重ダウンロードを行いやすくなります。
>  さらに、各キャッシュサーバの必要容量が低下します。
> 【A案に対して、B案が減ると言っても、ファイル一個の半分(1/n)分の容量だよね。ディスク容量に対して、たいした量じゃないと思うんですけど。】
>  キャッシュサーバは前半と後半のバランスを見て必要なほうのキャッシュを保持します。
>  一般ノードはダウンロード時、前半と後半で別なサーバを用いるため、多重ダウンロードが行いやすい。
> 【A案でも複数個のサーバを使って多重ダウンロードするよ。その場合、数に制限が無いから、１つファイルに着目すれば転送速度は速いよ。】
>  上記はキーサーバを同コストで利用する際の提案として記載させていただいたためｎ分割と考えてもかまいません。
> 【最適な分割数の判断が難しいところだね。少なすぎるとキー登録する条件が厳しすぎてファイル共有の効率が落ちるし、多すぎると、ブロック単位の登録と変わらなくなるね】
> 【なんとなくだけど、B案を、個人的な好みと勘で評価して、ルールが美しくような気がするなー。まあ、根拠を説明していないんで戯言ですけど。】
> ********************************************************************
> とりあえず、気になったところにコメント入れてみましたけど、これじゃA案とB案どちらが良いかは見えにくいんで、A案とB案の利点、欠点をまとめる必要がありそうだね。
> とりあえず、以下を埋めてみよう。（代わりの案でも良いよ）
> ・A案
>  [利点]
>
> [欠点]
>
>  ・B案
>  [利点]
>
> [欠点]
>
>
> ※松永は明日埋めます。
>
>
>
>  ________________________________
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
>
>
>

松永です。

  まだ追加するかもしれませんが、少しまとめてみました。
片方の利点が片方の欠点とも取れるので、妙にまとまってませんが、とりあえず勘弁して下さい。

  ただし、松永は直感的にA案びいきで、今日は考えることに疲れているので、不公平な判断をしていると思われます。
阿部君の意見も知りたいです。

  ・A案
[利点]
  1.１個のファイルに着目して、ダウンロードが高速
ブロック単位で多重ダウンロードするため、一個のファイルを高速に収集できる。

[欠点]
  1.ダウンロードを始める前に、ブロック単位でキャッシュの持ち主を探す必要があり、B案に比べて、無駄な通信コストがかかる。
  2.トレードオフがあり、そのバランスとりが難しい。
ファイルキーを登録できる、最低キャッシュの完全度の設定によって、ファイル共有効率と、通信コストのトレードオフがある。
完全度を下げると、ファイル共有の効率は上がるが、キャッシュの持ち主を探すための通信コストが上がる。
完全度を上げると、キャッシュの持ち主を探すための通信コストは下がるが、ファイル共有の効率は下がる。

  ・B案
[利点]
1.ダウンロードを始める前に、ブロック単位でキャッシュの持ち主を探す必要がない。

  [欠点]
1.多重ダウンロードとの相性が悪い。
いち早くファイル共有に貢献したければ、前半だけ高速に落としたいが、これをやると、B案の「多重ダウンロードをやりやすい」(前半と後半を同時に落とせば簡単？)という利点が消える。
  2.トレードオフがあり、そのバランスとりが難しい。
分割数の設定によって、ファイル共有効率と、キーサーバの負荷のトレードオフがある。
分割数を減らすと、キー管理の負荷は低いが、ファイル登録の条件が厳しくなり、ファイル共有の効率が落ちる。
分割数を増やすと、ファイル共有の効率が上がるが、キー管理の負荷が上がり、キーサーバが重くなる。
  3.キャッシュのサイズによって、分割数を切り替える制御が必要になりそう。
大きいファイルになればなるほど分割数を増やさないと、ファイルキー登録の条件がどんどん厳しくなる。
しかし、これをやると制御が難しくなる。キーサーバが重くなる。最適なバランスとりも難しい。
バランスのとり方を間違えるとファイル共有効率がかなり悪くなりそう。
  4.ファイルが複数ノードに分散する
分割して管理するので、ファイルが複数ノードに分散するのは免れない。
そうすると、確実な共有を行える可能性が下がる。

P2Pシミュレータ開発 <p2p...@li...> wrote:
    松永です。

いくつか気が付いた所があるので、以下に書きます。

書き込む所には【】を埋め込みます。

********************************************************************
【こっちをA案と呼ぶことにします】
条件付で、不完全なキャッシュのファイルキー登録を認める。
[概要]
キャッシュを保持するノードは、自身が持つ不完全なキャッシュを、キーサーバへのファイルキー登録を行わないことにしていた。
これを撤廃して、キーサーバに完全なキャッシュのファイルキーが１つでもあれば、不完全なファイルキーの登録も認める。
これを行うために、ファイルキーを完全と不完全の２つの状態で管理する。
キーサーバは完全なファイルキーが無くなれば、それ以降、不完全なファイルキーの登録を認めない。
不完全なキャッシュを持つノードもファイルキーの登録を行わない。
この場合、ファイルは自然消滅する。
[薦める理由]
不完全なキャッシュのファイルキー登録を認めない理由が、不完全なキャッシュがネットワーク上にゴミとして残り、しかも、どれがゴミなのかが明確にならない状態を防ぐためであった。
しかし、ここで薦める方法なら、その危険性が無くなる。
また、一部分だけでもファイルの送信を行えるので、ファイル共有の効率が上がる。
  ********************************************************************
【こっちをB案と呼ぶことにします】
上記について、デメリットを以下に記載します。
不完全なファイルを持つノードに対してファイル取得要求を投げた場合、
どの箇所を保持しているか知らない以上、利用できない可能性があります。
【キャッシュが不完全過ぎると、確かに無駄な通信が発生しやすくねるね。A案でやるなら不完全すぎるキャッシュはキー登録しないほうが良さそうだね。そうすれば、無駄な通信が発生といってもたいした量じゃないと思うんだけど。】
ファイルの前半しか持っていないノードが大量発生した場合、結局意味のないノードリストになります。
【A案でも多重ダウンロードのやり方次第で、「ファイルの前半しか持っていないノードが大量発生」は防げるよ。先頭からダウンロードするのをやめるだけ。】
無駄な通信が大量発生する原因となります。
(後半部分がほしいのに、不完全キャッシュ保持ノードは前半しかもっていない可能性)

キーサーバが不完全キャッシュ保持ノードリストと完全キャッシュ保持ノードリストの2つを管理すると言うならば、同じコストである以下の機能を提案します。
・キーサーバは２分割前半キャッシュ保持ノードリストと２分割後半キャッシュ保持ノードリストを持つ。
・完全キャッシュ保持ノードは両方のリストに登録する。
・半分のダウンロードが完了した時点でどちらかのリストに登録する
【つまり、B案でファイル共有に貢献するためには、限定された一部分で、最低半分(1/n)のキャッシュを持たないといけなくなるね。そうすると、通信のコストは少し減るけど、キー登録の条件が厳しくなって、ファイルの共有の効率も落ちることになるね。】

各ノードの持っている部位がどこなのか明確なため無駄な通信が発生しません。
また、多重ダウンロードを行いやすくなります。
さらに、各キャッシュサーバの必要容量が低下します。
【A案に対して、B案が減ると言っても、ファイル一個の半分(1/n)分の容量だよね。ディスク容量に対して、たいした量じゃないと思うんですけど。】
キャッシュサーバは前半と後半のバランスを見て必要なほうのキャッシュを保持します。
一般ノードはダウンロード時、前半と後半で別なサーバを用いるため、多重ダウンロードが行いやすい。
【A案でも複数個のサーバを使って多重ダウンロードするよ。その場合、数に制限が無いから、１つファイルに着目すれば転送速度は速いよ。】
上記はキーサーバを同コストで利用する際の提案として記載させていただいたためｎ分割と考えてもかまいません。
【最適な分割数の判断が難しいところだね。少なすぎるとキー登録する条件が厳しすぎてファイル共有の効率が落ちるし、多すぎると、ブロック単位の登録と変わらなくなるね】
  【なんとなくだけど、B案を、個人的な好みと勘で評価して、ルールが美しくような気がするなー。まあ、根拠を説明していないんで戯言ですけど。】
********************************************************************
  とりあえず、気になったところにコメント入れてみましたけど、これじゃA案とB案どちらが良いかは見えにくいんで、A案とB案の利点、欠点をまとめる必要がありそうだね。
  とりあえず、以下を埋めてみよう。（代わりの案でも良いよ）
  ・A案
[利点]

  [欠点]

・B案
[利点]

  [欠点]

  ※松永は明日埋めます。

---------------------------------
  [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
[旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！

松永です。

  やっぱり、「これでよいかと思います」は撤回します。

  システムに参加している時間が少ないノードが、わざわざキャッシュしても、共有に貢献するチャンスが少なくて、転送分の効率が悪くなるだけのような気がします。

  というわけで、システムへの参加時間が長い、条件を満たしたノードだけがキャッシュするってこと良いと思います。

  どう？

P2Pシミュレータ開発 <p2p...@li...> wrote:
    松永です。

  ＞一般ノードには「固定サイズのキャッシュ領域を提供」を義務づける。
＞これでよいかと？

これでよいかと思います。

  もうひとついただいた指摘の方は、今から検討します。

阿部誠 <abe...@gm...> wrote:
  ---------- Forwarded message ----------
From: 阿部誠 
Date: 2006/09/27 23:00
Subject: Re: [p2p-sim-dev] ２日で考えたことのまとめ
To: p2p...@li...

阿部です。

さっきのは会社であわてて書いたので、改めて全体にチェックをかけました。
文中(■)に回答いたします

06/09/27 に P2Pシミュレータ開発
 さんは書きました:
> 松永です。
>
> 質問に答えるのを忘れてました。
>
> ＞そもそもユーザーがシステム管理サーバになりたいと思うメリットって何？
>
> １．ファイル共有に貢献したいという崇高？な気持ち。
> ２．仮定ですが、システム管理サーバがシステムの状態をある程度モニタリングして、それを描画できるとしたら、それを見てみたい！！とか？
>
> ...
>
> それか、システム管理サーバになりたい、とかなりたくないは、実はシステム内部の中間的な表現で、ユーザーインターフェース上では、「長時間つなぎっぱなしにしますか？」などのアンケートをとっていて、これを中間表現にすると「システム管理サーバになりたい」になるかもしれないって考えていたわけです。
>
> まあ、将来色々機能を考えていくうちになりたい理由が出てくるかもしれないって考えていました。
>
>
> P2Pシミュレータ開発 
wrote:
>
> 松永です。
>
> 了解です。
> 今日はシステム管理サーバの役割決定処理の詳細を考えていたんですが、
> そんな気がしていました。
>
> これらを踏まえて、後で、今日考えたシステム管理サーバの役割決定処理を文書化しますんで、
> その時、もう一回検証願います。
>
> P2Pシミュレータ開発 
wrote:
> お疲れ様です。阿部です。
> とりあえず今、気づいたところを回答いたします。
> 文中(●)参照
>
> 06/09/27 に P2Pシミュレータ開発 さんは書きました:
> > 松永です。
> > ここ２日で考えたことを記しておきます。
> >
> > 主に、週末に阿部君と話した内容と、その補正案です。
> >
> > 内容を検討してみて下さい。
> > 何言ってるかわからなかったら聞いて下さい。
> > 欠点みつけた時も聞いてく下さい。
> > 詰めが甘いところがありますので、補完をお願いします。
> > 上記について、気が向いたらで構いません。
> > 向かなかったら向かなかったで良いです。
> >
> > wikiには書き込んでいません。
> >
> >
> ********************************************************************
> > キャッシュサーバはキーサーバの指示でキャッシュを行うのではなく、キャッシュサーバ自身の判断でキャッシュを行う。
> > [概要]
> >
> キャッシュサーバは自身のクラスタキーワードのファイルキーを監視して、ファイルの需要に供給が追いついていないと判断したら、そのファイルをダウンロードして、共有に貢献する。
> > ファイルの供給は被参照量から知ることが出来るが、需要を知るには「ダウンロード要求量の管理」が必要になる。
> > ダウンロード要求量はキーサーバ上でファイルキーの情報の一部として管理する。
> >
> ファイルをダウンロードしたいノードは、ファイルのキーを持つキーサーバへ「ファイルをダウンロードしたいノードがいる」ということを伝え、キーサーバはこれをダウンロード要求量へ反映する。これはノードのダウンロードが完了するまで一定の間隔で行う。
> >
> ただし、この方法ではダウンロード要求量は増える一方なので、サーバは一定間隔でダウンロード要求量をカウントダウンする。
> > ダウンロード要求量の制御が適当ではあるが、厳密な数値は必要ないと判断。
> > ※1. ダウンロード要求量という名前は仮。
> > ※2. ファイル削除要求と考え方は同じ
> > [薦める理由]
> > キーサーバの指示でキャッシュサーバを動かすよりも制御が簡単。
> >
> >
> ********************************************************************
> > 「」の案が通る場合、キャッシュサーバの台数制限を特に設けない。
> > [概要]
> > キャッシュサーバになりたいノードは、誰の許可も得ずに自分自身の判断でキャッシュサーバとなる。
> > [薦める理由]
> > の案が通る場合、キャッシュサーバを制御するコストが無くなるので、キャッシュサーバが多いデメリットが無くなる。
> > デメリットが無ければ、キャッシュサーバは多いに越したことは無い。
> > 又、キャッシュサーバに制限を設けて指名制にするよりも制御が簡単。
> >
> ※、案が共に通ると、キャッシュサーバが完全に自立で動くため、システム管理サーバへのキャッシュサーバ登録が不要になるかも。
> >
> >
(■)
、について内容に関しては同意します。
ただし、キャッシュサーバではなく一般ノードの機能として適用させるべきだと考えます。
そして、一般ノードには「固定サイズのキャッシュ領域を提供」を義務づける。
これでよいかと？

もうひとつ意見があります。(下に続く)

> ********************************************************************
> > 条件付で、不完全なキャッシュのファイルキー登録を認める。
> > [概要]
> >
> キャッシュを保持するノードは、自身が持つ不完全なキャッシュを、キーサーバへのファイルキー登録を行わないことにしていた。
> > これを撤廃して、キーサーバに完全なキャッシュのファイルキーが１つでもあれば、不完全なファイルキーの登録も認める。
> > これを行うために、ファイルキーを完全と不完全の２つの状態で管理する。
> > キーサーバは完全なファイルキーが無くなれば、それ以降、不完全なファイルキーの登録を認めない。
> > 不完全なキャッシュを持つノードもファイルキーの登録を行わない。
> > この場合、ファイルは自然消滅する。
> > [薦める理由]
> >
> 不完全なキャッシュのファイルキー登録を認めない理由が、不完全なキャッシュがネットワーク上にゴミとして残り、しかも、どれがゴミなのかが明確にならない状態を防ぐためであった。
> > しかし、ここで薦める方法なら、その危険性が無くなる。
> > また、一部分だけでもファイルの送信を行えるので、ファイル共有の効率が上がる。
(■)
上記について、デメリットを以下に記載します。
不完全なファイルを持つノードに対してファイル取得要求を投げた場合、
どの箇所を保持しているか知らない以上、利用できない可能性があります。
ファイルの前半しか持っていないノードが大量発生した場合、結局意味のないノードリストになります。
無駄な通信が大量発生する原因となります。
(後半部分がほしいのに、不完全キャッシュ保持ノードは前半しかもっていない可能性)

キーサーバが不完全キャッシュ保持ノードリストと完全キャッシュ保持ノードリストの2つを管理すると言うならば、同じコストである以下の機能を提案します。

・キーサーバは２分割前半キャッシュ保持ノードリストと２分割後半キャッシュ保持ノードリスト
を持つ。
・完全キャッシュ保持ノードは両方のリストに登録する。
・半分のダウンロードが完了した時点でどちらかのリストに登録する

各ノードの持っている部位がどこなのか明確なため無駄な通信が発生しません。
また、多重ダウンロードを行いやすくなります。
さらに、各キャッシュサーバの必要容量が低下します。
キャッシュサーバは前半と後半のバランスを見て必要なほうのキャッシュを保持します。
一般ノードはダウンロード時、前半と後半で別なサーバを用いるため、多重ダウンロードが行いやすい。

上記はキーサーバを同コストで利用する際の提案として記載させていただいたため
ｎ分割と考えてもかまいません。

以上よろしくお願いします。
> >
> >
> ********************************************************************
> > ノードの役割決定について
> > 本ファイル共有システムは、システム管理サーバ、キーサーバ、キャッシュサーバ、一般ノードという役割があり、
> > 各ノードは自ノードの役割について希望を出すことが出来る。
> >
> 希望とは、システム管理サーバ、キーサーバ、キャッシュサーバそれぞれについて、自ノードが「なりたい」、「なっても良い」、「なりたくない」と指定することである。（「なりたい」は一種類の役割に対してしか設定出来ない）
> >
> ノードの希望とスペックによって、システム管理サーバから、それぞれの役割へ付くようにと指示が下ることになっていたが、この仕組みを考え直す。
> > [概要]
> >
> 1.ノードが「なりたい」指定をした場合、ノードは希望の役割に就ける。（というか、システム管理サーバの指示を必要とせずに勝手に就く）
> > 2.ノードが「なりたくない」指定をした場合、ノードはその役割には就かない。
> > 3.ノードが「なっても良い」指定をした場合、デフォルトで一般ノードをやりながら、システム管理サーバの指示に従う。
> > (システム管理サーバ１台の指示に従うのではなく、複数台からの指示が集まった場合に従う)
> > ただし、システム管理サーバが出す指示は、システム管理サーバ、キーサーバ、一般ノードのどれか。
> > キャッシュサーバは、一般ノードをしている時に勝手にやる。
> > 4.全てのノードはシステム管理サーバに自身の希望、スペック、現在の状態を一定間隔で送信する。
> > システム管理サーバはその情報を元に役割を割り振る。
> (●)
> 上記について、任意参加にするデメリットは大きいと考えます。
> もともとシステム管理サーバに指示出しを行わせるシステムにしたのは、
> システム全体のノード比率を一定にするという役割があったはずです。
> それを任意にしてしまうと、理想形が作れなくなる危険性が生じ、
> つまり、全体のシステム効率が落ちる危険性が生じます。
>
> そもそもユーザーがシステム管理サーバになりたいと思うメリットって何？
>
> とりあえず、以上です。
>
> >
> > 以上です。
> >
> >
> > ________________________________
> > [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
> >
> >
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys -- and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >
> > _______________________________________________
> > P2p-sim-develop mailing list
> > P2p...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
> >
> >
> >
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
>
>
>
> ________________________________
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
>
>
>
>
> ________________________________
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
>
>
>

---------------------------------
  [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
[旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！

松永です。

いくつか気が付いた所があるので、以下に書きます。

書き込む所には【】を埋め込みます。

********************************************************************
【こっちをA案と呼ぶことにします】
条件付で、不完全なキャッシュのファイルキー登録を認める。
[概要]
キャッシュを保持するノードは、自身が持つ不完全なキャッシュを、キーサーバへのファイルキー登録を行わないことにしていた。
これを撤廃して、キーサーバに完全なキャッシュのファイルキーが１つでもあれば、不完全なファイルキーの登録も認める。
これを行うために、ファイルキーを完全と不完全の２つの状態で管理する。
キーサーバは完全なファイルキーが無くなれば、それ以降、不完全なファイルキーの登録を認めない。
不完全なキャッシュを持つノードもファイルキーの登録を行わない。
この場合、ファイルは自然消滅する。
[薦める理由]
不完全なキャッシュのファイルキー登録を認めない理由が、不完全なキャッシュがネットワーク上にゴミとして残り、しかも、どれがゴミなのかが明確にならない状態を防ぐためであった。
しかし、ここで薦める方法なら、その危険性が無くなる。
また、一部分だけでもファイルの送信を行えるので、ファイル共有の効率が上がる。
  ********************************************************************
【こっちをB案と呼ぶことにします】
上記について、デメリットを以下に記載します。
不完全なファイルを持つノードに対してファイル取得要求を投げた場合、
どの箇所を保持しているか知らない以上、利用できない可能性があります。
【キャッシュが不完全過ぎると、確かに無駄な通信が発生しやすくねるね。A案でやるなら不完全すぎるキャッシュはキー登録しないほうが良さそうだね。そうすれば、無駄な通信が発生といってもたいした量じゃないと思うんだけど。】
ファイルの前半しか持っていないノードが大量発生した場合、結局意味のないノードリストになります。
【A案でも多重ダウンロードのやり方次第で、「ファイルの前半しか持っていないノードが大量発生」は防げるよ。先頭からダウンロードするのをやめるだけ。】
無駄な通信が大量発生する原因となります。
(後半部分がほしいのに、不完全キャッシュ保持ノードは前半しかもっていない可能性)

キーサーバが不完全キャッシュ保持ノードリストと完全キャッシュ保持ノードリストの2つを管理すると言うならば、同じコストである以下の機能を提案します。
・キーサーバは２分割前半キャッシュ保持ノードリストと２分割後半キャッシュ保持ノードリストを持つ。
・完全キャッシュ保持ノードは両方のリストに登録する。
・半分のダウンロードが完了した時点でどちらかのリストに登録する
【つまり、B案でファイル共有に貢献するためには、限定された一部分で、最低半分(1/n)のキャッシュを持たないといけなくなるね。そうすると、通信のコストは少し減るけど、キー登録の条件が厳しくなって、ファイルの共有の効率も落ちることになるね。】

各ノードの持っている部位がどこなのか明確なため無駄な通信が発生しません。
また、多重ダウンロードを行いやすくなります。
さらに、各キャッシュサーバの必要容量が低下します。
【A案に対して、B案が減ると言っても、ファイル一個の半分(1/n)分の容量だよね。ディスク容量に対して、たいした量じゃないと思うんですけど。】
キャッシュサーバは前半と後半のバランスを見て必要なほうのキャッシュを保持します。
一般ノードはダウンロード時、前半と後半で別なサーバを用いるため、多重ダウンロードが行いやすい。
【A案でも複数個のサーバを使って多重ダウンロードするよ。その場合、数に制限が無いから、１つファイルに着目すれば転送速度は速いよ。】
上記はキーサーバを同コストで利用する際の提案として記載させていただいたためｎ分割と考えてもかまいません。
【最適な分割数の判断が難しいところだね。少なすぎるとキー登録する条件が厳しすぎてファイル共有の効率が落ちるし、多すぎると、ブロック単位の登録と変わらなくなるね】
  【なんとなくだけど、B案を、個人的な好みと勘で評価して、ルールが美しくような気がするなー。まあ、根拠を説明していないんで戯言ですけど。】
********************************************************************
  とりあえず、気になったところにコメント入れてみましたけど、これじゃA案とB案どちらが良いかは見えにくいんで、A案とB案の利点、欠点をまとめる必要がありそうだね。
  とりあえず、以下を埋めてみよう。（代わりの案でも良いよ）
  ・A案
[利点]

  [欠点]

・B案
[利点]

  [欠点]

  ※松永は明日埋めます。

---------------------------------
[旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！

松永です。

  ＞一般ノードには「固定サイズのキャッシュ領域を提供」を義務づける。
＞これでよいかと？

これでよいかと思います。

  もうひとついただいた指摘の方は、今から検討します。

阿部誠 <abe...@gm...> wrote:
  ---------- Forwarded message ----------
From: 阿部誠 
Date: 2006/09/27 23:00
Subject: Re: [p2p-sim-dev] ２日で考えたことのまとめ
To: p2p...@li...

阿部です。

さっきのは会社であわてて書いたので、改めて全体にチェックをかけました。
文中(■)に回答いたします

06/09/27 に P2Pシミュレータ開発
 さんは書きました:
> 松永です。
>
> 質問に答えるのを忘れてました。
>
> ＞そもそもユーザーがシステム管理サーバになりたいと思うメリットって何？
>
> １．ファイル共有に貢献したいという崇高？な気持ち。
> ２．仮定ですが、システム管理サーバがシステムの状態をある程度モニタリングして、それを描画できるとしたら、それを見てみたい！！とか？
>
> ...
>
> それか、システム管理サーバになりたい、とかなりたくないは、実はシステム内部の中間的な表現で、ユーザーインターフェース上では、「長時間つなぎっぱなしにしますか？」などのアンケートをとっていて、これを中間表現にすると「システム管理サーバになりたい」になるかもしれないって考えていたわけです。
>
> まあ、将来色々機能を考えていくうちになりたい理由が出てくるかもしれないって考えていました。
>
>
> P2Pシミュレータ開発 
wrote:
>
> 松永です。
>
> 了解です。
> 今日はシステム管理サーバの役割決定処理の詳細を考えていたんですが、
> そんな気がしていました。
>
> これらを踏まえて、後で、今日考えたシステム管理サーバの役割決定処理を文書化しますんで、
> その時、もう一回検証願います。
>
> P2Pシミュレータ開発 
wrote:
> お疲れ様です。阿部です。
> とりあえず今、気づいたところを回答いたします。
> 文中(●)参照
>
> 06/09/27 に P2Pシミュレータ開発 さんは書きました:
> > 松永です。
> > ここ２日で考えたことを記しておきます。
> >
> > 主に、週末に阿部君と話した内容と、その補正案です。
> >
> > 内容を検討してみて下さい。
> > 何言ってるかわからなかったら聞いて下さい。
> > 欠点みつけた時も聞いてく下さい。
> > 詰めが甘いところがありますので、補完をお願いします。
> > 上記について、気が向いたらで構いません。
> > 向かなかったら向かなかったで良いです。
> >
> > wikiには書き込んでいません。
> >
> >
> ********************************************************************
> > キャッシュサーバはキーサーバの指示でキャッシュを行うのではなく、キャッシュサーバ自身の判断でキャッシュを行う。
> > [概要]
> >
> キャッシュサーバは自身のクラスタキーワードのファイルキーを監視して、ファイルの需要に供給が追いついていないと判断したら、そのファイルをダウンロードして、共有に貢献する。
> > ファイルの供給は被参照量から知ることが出来るが、需要を知るには「ダウンロード要求量の管理」が必要になる。
> > ダウンロード要求量はキーサーバ上でファイルキーの情報の一部として管理する。
> >
> ファイルをダウンロードしたいノードは、ファイルのキーを持つキーサーバへ「ファイルをダウンロードしたいノードがいる」ということを伝え、キーサーバはこれをダウンロード要求量へ反映する。これはノードのダウンロードが完了するまで一定の間隔で行う。
> >
> ただし、この方法ではダウンロード要求量は増える一方なので、サーバは一定間隔でダウンロード要求量をカウントダウンする。
> > ダウンロード要求量の制御が適当ではあるが、厳密な数値は必要ないと判断。
> > ※1. ダウンロード要求量という名前は仮。
> > ※2. ファイル削除要求と考え方は同じ
> > [薦める理由]
> > キーサーバの指示でキャッシュサーバを動かすよりも制御が簡単。
> >
> >
> ********************************************************************
> > 「」の案が通る場合、キャッシュサーバの台数制限を特に設けない。
> > [概要]
> > キャッシュサーバになりたいノードは、誰の許可も得ずに自分自身の判断でキャッシュサーバとなる。
> > [薦める理由]
> > の案が通る場合、キャッシュサーバを制御するコストが無くなるので、キャッシュサーバが多いデメリットが無くなる。
> > デメリットが無ければ、キャッシュサーバは多いに越したことは無い。
> > 又、キャッシュサーバに制限を設けて指名制にするよりも制御が簡単。
> >
> ※、案が共に通ると、キャッシュサーバが完全に自立で動くため、システム管理サーバへのキャッシュサーバ登録が不要になるかも。
> >
> >
(■)
、について内容に関しては同意します。
ただし、キャッシュサーバではなく一般ノードの機能として適用させるべきだと考えます。
そして、一般ノードには「固定サイズのキャッシュ領域を提供」を義務づける。
これでよいかと？

もうひとつ意見があります。(下に続く)

> ********************************************************************
> > 条件付で、不完全なキャッシュのファイルキー登録を認める。
> > [概要]
> >
> キャッシュを保持するノードは、自身が持つ不完全なキャッシュを、キーサーバへのファイルキー登録を行わないことにしていた。
> > これを撤廃して、キーサーバに完全なキャッシュのファイルキーが１つでもあれば、不完全なファイルキーの登録も認める。
> > これを行うために、ファイルキーを完全と不完全の２つの状態で管理する。
> > キーサーバは完全なファイルキーが無くなれば、それ以降、不完全なファイルキーの登録を認めない。
> > 不完全なキャッシュを持つノードもファイルキーの登録を行わない。
> > この場合、ファイルは自然消滅する。
> > [薦める理由]
> >
> 不完全なキャッシュのファイルキー登録を認めない理由が、不完全なキャッシュがネットワーク上にゴミとして残り、しかも、どれがゴミなのかが明確にならない状態を防ぐためであった。
> > しかし、ここで薦める方法なら、その危険性が無くなる。
> > また、一部分だけでもファイルの送信を行えるので、ファイル共有の効率が上がる。
(■)
上記について、デメリットを以下に記載します。
不完全なファイルを持つノードに対してファイル取得要求を投げた場合、
どの箇所を保持しているか知らない以上、利用できない可能性があります。
ファイルの前半しか持っていないノードが大量発生した場合、結局意味のないノードリストになります。
無駄な通信が大量発生する原因となります。
(後半部分がほしいのに、不完全キャッシュ保持ノードは前半しかもっていない可能性)

キーサーバが不完全キャッシュ保持ノードリストと完全キャッシュ保持ノードリストの2つを管理すると言うならば、同じコストである以下の機能を提案します。

・キーサーバは２分割前半キャッシュ保持ノードリストと２分割後半キャッシュ保持ノードリスト
を持つ。
・完全キャッシュ保持ノードは両方のリストに登録する。
・半分のダウンロードが完了した時点でどちらかのリストに登録する

各ノードの持っている部位がどこなのか明確なため無駄な通信が発生しません。
また、多重ダウンロードを行いやすくなります。
さらに、各キャッシュサーバの必要容量が低下します。
キャッシュサーバは前半と後半のバランスを見て必要なほうのキャッシュを保持します。
一般ノードはダウンロード時、前半と後半で別なサーバを用いるため、多重ダウンロードが行いやすい。

上記はキーサーバを同コストで利用する際の提案として記載させていただいたため
ｎ分割と考えてもかまいません。

以上よろしくお願いします。
> >
> >
> ********************************************************************
> > ノードの役割決定について
> > 本ファイル共有システムは、システム管理サーバ、キーサーバ、キャッシュサーバ、一般ノードという役割があり、
> > 各ノードは自ノードの役割について希望を出すことが出来る。
> >
> 希望とは、システム管理サーバ、キーサーバ、キャッシュサーバそれぞれについて、自ノードが「なりたい」、「なっても良い」、「なりたくない」と指定することである。（「なりたい」は一種類の役割に対してしか設定出来ない）
> >
> ノードの希望とスペックによって、システム管理サーバから、それぞれの役割へ付くようにと指示が下ることになっていたが、この仕組みを考え直す。
> > [概要]
> >
> 1.ノードが「なりたい」指定をした場合、ノードは希望の役割に就ける。（というか、システム管理サーバの指示を必要とせずに勝手に就く）
> > 2.ノードが「なりたくない」指定をした場合、ノードはその役割には就かない。
> > 3.ノードが「なっても良い」指定をした場合、デフォルトで一般ノードをやりながら、システム管理サーバの指示に従う。
> > (システム管理サーバ１台の指示に従うのではなく、複数台からの指示が集まった場合に従う)
> > ただし、システム管理サーバが出す指示は、システム管理サーバ、キーサーバ、一般ノードのどれか。
> > キャッシュサーバは、一般ノードをしている時に勝手にやる。
> > 4.全てのノードはシステム管理サーバに自身の希望、スペック、現在の状態を一定間隔で送信する。
> > システム管理サーバはその情報を元に役割を割り振る。
> (●)
> 上記について、任意参加にするデメリットは大きいと考えます。
> もともとシステム管理サーバに指示出しを行わせるシステムにしたのは、
> システム全体のノード比率を一定にするという役割があったはずです。
> それを任意にしてしまうと、理想形が作れなくなる危険性が生じ、
> つまり、全体のシステム効率が落ちる危険性が生じます。
>
> そもそもユーザーがシステム管理サーバになりたいと思うメリットって何？
>
> とりあえず、以上です。
>
> >
> > 以上です。
> >
> >
> > ________________________________
> > [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
> >
> >
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys -- and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >
> > _______________________________________________
> > P2p-sim-develop mailing list
> > P2p...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
> >
> >
> >
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
>
>
>
> ________________________________
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
>
>
>
>
> ________________________________
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
>
>
>

---------------------------------
[旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！

松永です。

>ディスク容量と「流行のファイル？？」の兼ね合いから
>何かのファイルを消して流行のファイルをキャッシュするって考えが出てきそうだけど
>そこらへんはどう考えてるの？？

とりあえず考えてみました。ダメだし、補完等お願いします。

キャッシュサーバは、キャッシュしたいキャッシュがあるけどディスク容量が足りない場合、
以下の方式でディスクに空きを作ります。
(内容の半分くらいは今考えました)

**************************************************************************************************************
[ディスク容量確保処理]

 以下の順番で処理します。

1.不完全なキャッシュを削除する

 ダウンロード指定中(ユーザの指定、キャッシュサーバとしての指定、関わらず)ではない、不完全なキャッシュを、
 完全度が低い順に、ディスク容量が確保できるまで削除する。

 ディスク容量が確保できなければ次へ進む。
 確保できれば処理完了。

2.現在保持しているキャッシュに優先度の点数を付ける

 点数のつけ方は完全に決めてないが、多分、以下の情報を種にして優先度を算出することになりそう。

  ・「現在保持しているキャッシュのクラスタキーワード※」と「ユーザがファイル検索用に設定しているクラスタキーワード」の繋がりの強さ(繋がりが強いほど高得点)
  ・現在保持しているキャッシュの需要と供給のバランス(供給が少ないほど高得点)

3.キャッシュしたいキャッシュにも優先度の点数を付ける

 2番と同じく、点数のつけ方は完全に決めてないが、やり方は同じ要領で。以下を種としそう。

  ・「キャッシュしたいキャッシュのクラスタキーワード※」と「ユーザがファイル検索用に設定しているクラスタキーワード」の繋がりの強さ(繋がりが強いほど高得点)
  ・キャッシュしたいキャッシュの需要と供給のバランス(供給が少ないほど高得点)

4.優先度が「キャッシュしたいファイル > 現在保持しているキャッシュ」な現在保持しているキャッシュを削除する

 優先度が「キャッシュしたいファイル > 現在保持しているキャッシュ」なキャッシュを見つけて、
 優先度が低い順に、ディスク容量が確保できるまで削除する。

 優先度が僅差で削除するのは効率が悪いので、ある程度の「しきい値」以上の差が出ないと削除しない事とする。

 ここまでやって、ディスク容量が確保できなければあきらめる。

※ファイルのクラスタキーワード
 １つ１つのキャッシュはクラスタキーワードを持つことができる。
 「どうやってクラスタキーワードを持たせるか」は完全には決まっていないが、
 恐らくファイル名に持たせるか、キャッシュファイルの内部に持たせることになりそう。

 クラスタキーワードをファイル名に持たせるならこんな感じ？

  [映画][アクション][グロ]マタリアン2.avi

 で、クラスタキーワードの各キーワードに重みを持たせられるなら、こんな感じ？

  [映画:2][アクション:3][グロ:20]マタリアン2.avi

**************************************************************************************************************

P2Pシミュレータ開発 <p2p...@li...> wrote:
  お疲れ様です。西村です。

ファイルのごみが残らないようにする案、いい考えだと思う。

ところで、この辺を考えていくとディスク容量と「流行のファ
イル？？」の兼ね合いから何かのファイルを消して流行のファ
イルをキャッシュするって考えが出てきそうだけどそこらへん
はどう考えてるの？？

--- P2Pシミュレータ開発

wrote:

> 松永です。
> ここ２日で考えたことを記しておきます。
> 
> 主に、週末に阿部君と話した内容と、その補正案です。
> 
> 内容を検討してみて下さい。
> 何言ってるかわからなかったら聞いて下さい。
> 欠点みつけた時も聞いてく下さい。
> 
> 詰めが甘いところがありますので、補完をお願いします。
> 上記について、気が向いたらで構いません。
> 向かなかったら向かなかったで良いです。
> 
> wikiには書き込んでいません。
> 
> 
>
********************************************************************
> キャッシュサーバはキーサーバの指示でキャッシュを行う
のではなく、キャッシュサーバ自身の判断でキャッシュを行う
。
> [概要]
> キャッシュサーバは自身のクラスタキーワードのファイルキ
ーを監視して、ファイルの需要に供給が追いついていないと判
断したら、そのファイルをダウンロードして、共有に貢献する
。
> 
> ファイルの供給は被参照量から知ることが出来るが、需要を
知るには「ダウンロード要求量の管理」が必要になる。
> 
> ダウンロード要求量はキーサーバ上でファイルキーの情報の
一部として管理する。
> ファイルをダウンロードしたいノードは、ファイルのキーを
持つキーサーバへ「ファイルをダウンロードしたいノードがい
る」ということを伝え、キーサーバはこれをダウンロード要求
量へ反映する。これはノードのダウンロードが完了するまで一
定の間隔で行う。
> ただし、この方法ではダウンロード要求量は増える一方なの
で、サーバは一定間隔でダウンロード要求量をカウントダウン
する。
> 
> ダウンロード要求量の制御が適当ではあるが、厳密な数値は
必要ないと判断。
> ※1. ダウンロード要求量という名前は仮。
> ※2. ファイル削除要求と考え方は同じ
> [薦める理由]
> キーサーバの指示でキャッシュサーバを動かすよりも制御が
簡単。
> 
>
********************************************************************
> 「」の案が通る場合、キャッシュサーバの台数制限を特
に設けない。
> [概要]
> キャッシュサーバになりたいノードは、誰の許可も得ずに自
分自身の判断でキャッシュサーバとなる。
> [薦める理由]
> の案が通る場合、キャッシュサーバを制御するコストが無
くなるので、キャッシュサーバが多いデメリットが無くなる。
> デメリットが無ければ、キャッシュサーバは多いに越したこ
とは無い。
> 又、キャッシュサーバに制限を設けて指名制にするよりも制
御が簡単。
> 
> ※、案が共に通ると、キャッシュサーバが完全に自立で
動くため、システム管理サーバへのキャッシュサーバ登録が不
要になるかも。
> 
>
********************************************************************
> 条件付で、不完全なキャッシュのファイルキー登録を認め
る。
> [概要]
> キャッシュを保持するノードは、自身が持つ不完全なキャッ
シュを、キーサーバへのファイルキー登録を行わないことにし
ていた。
> これを撤廃して、キーサーバに完全なキャッシュのファイル
キーが１つでもあれば、不完全なファイルキーの登録も認める
。
> 
> これを行うために、ファイルキーを完全と不完全の２つの状
態で管理する。
> キーサーバは完全なファイルキーが無くなれば、それ以降、
不完全なファイルキーの登録を認めない。
> 不完全なキャッシュを持つノードもファイルキーの登録を行
わない。
> この場合、ファイルは自然消滅する。
> [薦める理由]
> 不完全なキャッシュのファイルキー登録を認めない理由が、
不完全なキャッシュがネットワーク上にゴミとして残り、しか
も、どれがゴミなのかが明確にならない状態を防ぐためであっ
た。
> 
> しかし、ここで薦める方法なら、その危険性が無くなる。
> また、一部分だけでもファイルの送信を行えるので、ファイ
ル共有の効率が上がる。
> 
> 
>
********************************************************************
> ノードの役割決定について
> 
> 本ファイル共有システムは、システム管理サーバ、キーサー
バ、キャッシュサーバ、一般ノードという役割があり、
> 各ノードは自ノードの役割について希望を出すことが出来る
。
> 
> 希望とは、システム管理サーバ、キーサーバ、キャッシュサ
ーバそれぞれについて、自ノードが「なりたい」、「なっても
良い」、「なりたくない」と指定することである。（「なりた
い」は一種類の役割に対してしか設定出来ない）
> 
> ノードの希望とスペックによって、システム管理サーバから
、それぞれの役割へ付くようにと指示が下ることになっていた
が、この仕組みを考え直す。
> [概要]
> 1.ノードが「なりたい」指定をした場合、ノードは希望の役
割に就ける。（というか、システム管理サーバの指示を必要と
せずに勝手に就く）
> 
> 2.ノードが「なりたくない」指定をした場合、ノードはその
役割には就かない。
> 
> 3.ノードが「なっても良い」指定をした場合、デフォルトで
一般ノードをやりながら、システム管理サーバの指示に従う。
> (システム管理サーバ１台の指示に従うのではなく、複数台
からの指示が集まった場合に従う)
> ただし、システム管理サーバが出す指示は、システム管理サ
ーバ、キーサーバ、一般ノードのどれか。
> キャッシュサーバは、一般ノードをしている時に勝手にやる
。
> 
> 4.全てのノードはシステム管理サーバに自身の希望、スペッ
ク、現在の状態を一定間隔で送信する。
> システム管理サーバはその情報を元に役割を割り振る。
> 
> 以上です。
> 
> 
> 
> ---------------------------------
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラ
ボ≫で！
> >
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get
> the chance to share your
> opinions on IT & business topics through brief
> surveys -- and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
_______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
>
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
> 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
[旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！

お疲れ様です。西村です。

ファイルのごみが残らないようにする案、いい考えだと思う。

ところで、この辺を考えていくとディスク容量と「流行のファ
イル？？」の兼ね合いから何かのファイルを消して流行のファ
イルをキャッシュするって考えが出てきそうだけどそこらへん
はどう考えてるの？？

--- P2Pシミュレータ開発
<p2p...@li...> wrote:

> 松永です。
>   ここ２日で考えたことを記しておきます。
>    
>   主に、週末に阿部君と話した内容と、その補正案です。
>    
>   内容を検討してみて下さい。
>   何言ってるかわからなかったら聞いて下さい。
>   欠点みつけた時も聞いてく下さい。
>  
> 詰めが甘いところがありますので、補完をお願いします。
>   上記について、気が向いたらで構いません。
>   向かなかったら向かなかったで良いです。
>    
>   wikiには書き込んでいません。
>    
>  
>
********************************************************************
> キャッシュサーバはキーサーバの指示でキャッシュを行う
のではなく、キャッシュサーバ自身の判断でキャッシュを行う
。
>   [概要]
> キャッシュサーバは自身のクラスタキーワードのファイルキ
ーを監視して、ファイルの需要に供給が追いついていないと判
断したら、そのファイルをダウンロードして、共有に貢献する
。
>  
> ファイルの供給は被参照量から知ることが出来るが、需要を
知るには「ダウンロード要求量の管理」が必要になる。
>  
> ダウンロード要求量はキーサーバ上でファイルキーの情報の
一部として管理する。
> ファイルをダウンロードしたいノードは、ファイルのキーを
持つキーサーバへ「ファイルをダウンロードしたいノードがい
る」ということを伝え、キーサーバはこれをダウンロード要求
量へ反映する。これはノードのダウンロードが完了するまで一
定の間隔で行う。
> ただし、この方法ではダウンロード要求量は増える一方なの
で、サーバは一定間隔でダウンロード要求量をカウントダウン
する。
>  
> ダウンロード要求量の制御が適当ではあるが、厳密な数値は
必要ないと判断。
>   ※1. ダウンロード要求量という名前は仮。
> ※2. ファイル削除要求と考え方は同じ
>   [薦める理由]
> キーサーバの指示でキャッシュサーバを動かすよりも制御が
簡単。
>   
>
********************************************************************
> 「」の案が通る場合、キャッシュサーバの台数制限を特
に設けない。
>   [概要]
> キャッシュサーバになりたいノードは、誰の許可も得ずに自
分自身の判断でキャッシュサーバとなる。
>   [薦める理由]
> の案が通る場合、キャッシュサーバを制御するコストが無
くなるので、キャッシュサーバが多いデメリットが無くなる。
> デメリットが無ければ、キャッシュサーバは多いに越したこ
とは無い。
> 又、キャッシュサーバに制限を設けて指名制にするよりも制
御が簡単。
>  
> ※、案が共に通ると、キャッシュサーバが完全に自立で
動くため、システム管理サーバへのキャッシュサーバ登録が不
要になるかも。
>   
>
********************************************************************
> 条件付で、不完全なキャッシュのファイルキー登録を認め
る。
>   [概要]
> キャッシュを保持するノードは、自身が持つ不完全なキャッ
シュを、キーサーバへのファイルキー登録を行わないことにし
ていた。
> これを撤廃して、キーサーバに完全なキャッシュのファイル
キーが１つでもあれば、不完全なファイルキーの登録も認める
。
>  
> これを行うために、ファイルキーを完全と不完全の２つの状
態で管理する。
> キーサーバは完全なファイルキーが無くなれば、それ以降、
不完全なファイルキーの登録を認めない。
> 不完全なキャッシュを持つノードもファイルキーの登録を行
わない。
> この場合、ファイルは自然消滅する。
>   [薦める理由]
> 不完全なキャッシュのファイルキー登録を認めない理由が、
不完全なキャッシュがネットワーク上にゴミとして残り、しか
も、どれがゴミなのかが明確にならない状態を防ぐためであっ
た。
>  
> しかし、ここで薦める方法なら、その危険性が無くなる。
> また、一部分だけでもファイルの送信を行えるので、ファイ
ル共有の効率が上がる。
>    
>  
>
********************************************************************
> ノードの役割決定について
>  
> 本ファイル共有システムは、システム管理サーバ、キーサー
バ、キャッシュサーバ、一般ノードという役割があり、
> 各ノードは自ノードの役割について希望を出すことが出来る
。
>  
> 希望とは、システム管理サーバ、キーサーバ、キャッシュサ
ーバそれぞれについて、自ノードが「なりたい」、「なっても
良い」、「なりたくない」と指定することである。（「なりた
い」は一種類の役割に対してしか設定出来ない）
>  
> ノードの希望とスペックによって、システム管理サーバから
、それぞれの役割へ付くようにと指示が下ることになっていた
が、この仕組みを考え直す。
>   [概要]
> 1.ノードが「なりたい」指定をした場合、ノードは希望の役
割に就ける。（というか、システム管理サーバの指示を必要と
せずに勝手に就く）
>  
> 2.ノードが「なりたくない」指定をした場合、ノードはその
役割には就かない。
>  
> 3.ノードが「なっても良い」指定をした場合、デフォルトで
一般ノードをやりながら、システム管理サーバの指示に従う。
> (システム管理サーバ１台の指示に従うのではなく、複数台
からの指示が集まった場合に従う)
> ただし、システム管理サーバが出す指示は、システム管理サ
ーバ、キーサーバ、一般ノードのどれか。
> キャッシュサーバは、一般ノードをしている時に勝手にやる
。
>  
> 4.全てのノードはシステム管理サーバに自身の希望、スペッ
ク、現在の状態を一定間隔で送信する。
> システム管理サーバはその情報を元に役割を割り振る。
>    
>   以上です。
>  
> 
> 
> ---------------------------------
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラ
ボ≫で！
> >
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get
> the chance to share your
> opinions on IT & business topics through brief
> surveys -- and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
_______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
>
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
> 

西村です。

judeってUML設計用のツールがあるんだけどもしかするとうま
く使えるかも。
ただバージョンと有償バージョンがあるけど違いはページ単位
でのコピー＆ペーストができないだけ。

＃ところでこのメーリングリスト誰からのメールか分かるよう
にならないかなぁ
＃Fromのところメーリングリストのメアドになっちゃうし

--- P2Pシミュレータ開発
<p2p...@li...> wrote:

> 松永です。
>    
>   visio持ってる？
>   以前、仕事で使ったことあるけど、まあまあ使えるよ。
>    
>   持ってないなら、
>   open-officeに似たようなものないかな？
> 
> P2Pシミュレータ開発
> <p2p...@li...> wrote:
>     松永です。
>    
>   すみません。知りません。
>    
>   知らないけど、Excelじゃ不便だった？
>   最後にキャプチャとれば画像出せるし。
> 
> P2Pシミュレータ開発
> <p2p...@li...> wrote:
>   阿部です。
> 
> wikiの説明に図を使いたいんだけど、矢印とか
> 楕円とかを簡単にかける説明向きの図を書くのが得意なツー
ルって知らないかな？
> 
> ベクトル描画系でPNGとかJPGで最終出力できるフリーツール
希望です。
> 
> 以上よろしくお願いします。
> 
>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get
> the chance to share your
> opinions on IT & business topics through brief
> surveys -- and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
>
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
> 
>   
>     
> ---------------------------------
>  
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラ
ボ≫で！
>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get
> the chance to share your
> opinions on IT & business topics through brief
> surveys -- and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
>
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
> 
>  
> 
> 
> ---------------------------------
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラ
ボ≫で！
> >
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get
> the chance to share your
> opinions on IT & business topics through brief
> surveys -- and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
_______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
>
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
> 

松永です。

  visio持ってる？
  以前、仕事で使ったことあるけど、まあまあ使えるよ。

  持ってないなら、
  open-officeに似たようなものないかな？

P2Pシミュレータ開発 <p2p...@li...> wrote:
    松永です。

  すみません。知りません。

  知らないけど、Excelじゃ不便だった？
  最後にキャプチャとれば画像出せるし。

P2Pシミュレータ開発 <p2p...@li...> wrote:
  阿部です。

wikiの説明に図を使いたいんだけど、矢印とか
楕円とかを簡単にかける説明向きの図を書くのが得意なツールって知らないかな？

ベクトル描画系でPNGとかJPGで最終出力できるフリーツール希望です。

以上よろしくお願いします。

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
  [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
[旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！

松永です。

  すみません。
  自分でバグ見つけちゃいました。

  ×
  ↓
  しきい値 + 「キーサーバワーストランク表」[index].適正 < 「キーサーバ候補ベストランク表」[index]適正

  ○
  ↓
  しきい値 + 「キーサーバワーストランク表」[index].適正 > 「キーサーバ候補ベストランク表」[index]適正

P2Pシミュレータ開発 <p2p...@li...> wrote:
    松永です。

  以下について、検討願います。
  またまた、wikiには書き込んでいません。

  【システム管理サーバの役割推薦処理概要】

全てのノードは、いくつかのシステム管理サーバへ、自ノードの情報(希望、スペック、現在の役割)を一定間隔で送信する。

システム管理サーバは、一定時間の内で収集したノード情報を元に、以下情報を作成する。

・役割の比率
現在のファイル共有システム内の、システム管理サーバ、キーサーバ、キャッシュサーバ、一般ノードの比率。
(現在は、「ノード数」の比率で判断しているが、将来的には、「マシンスペック」の比率として考えるかもしれない)

・キーサーバワーストランク表
  キーサーバにキーサーバ適正ランクをつけてランキングしたもの。
  適正がないもののランキング。適正がないほど上位に来る。
  上位 n 個(未定)まで保持する。

・キーサーバ候補ベストランク表
  一般ノードにキーサーバ適正ランクをつけてランキングしたもの。
  適正があるもののランキング。適正があるほど上位に来る。
  上位 n 個(未定)まで保持する。

・システム管理サーバワーストランク表
  一般ノードにシステム管理サーバ適正ランクをつけてランキングしたもの。
  適正がないもののランキング。適正がないほど上位に来る。
  上位 n 個(未定)まで保持する。

・システム管理サーバ候補ベストランク表
 一般ノードにシステム管理サーバ適正ランクをつけてランキングしたもの。
  適正があるもののランキング。適正があるほど上位に来る。
  上位 n 個(未定)まで保持する。

システム管理サーバは上記情報を元に、ノード役割推薦処理を行う。
一定時間内に、システム管理サーバから多くの(数は未定)推薦を受けたノードは推薦に従う。

[ノード役割推薦処理](擬似言語)
※実際のコードをこのように書くという意図ではなく、説明の手段として擬似言語を用いる。

****************************************************************************************

//----------------------------------------------------------------
// キーサーバの調整
//----------------------------------------------------------------

if (キーサーバの数が足りているか？) {
 // キーサーバの数が足りている

 if(キーサーバの数が多すぎか？) {
  // キーサーバの数が多すぎ

  「キーサーバワーストランク表」の上位 "多すぎる数" 個のノードに対して、キーサーバを辞めるように推奨する;

 } else {
  // キーサーバの数がちょうど良い

  // ※1参照
  indexを0からカウントアップしていき、
  しきい値 + 「キーサーバワーストランク表」[index].適正 < 「キーサーバ候補ベストランク表」[index]適正
  となる、indexを見つける;

  「キーサーバワーストランク表」[0] 〜 [index - 1] のノードに対して、キーサーバを辞めるように推奨する;

  「キーサーバ候補ベストランク表」[0] 〜 [index - 1] のノードに対して、キーサーバに就くように推奨する;
 }

} else {
 // キーサーバの数が足りていない

 「キーサーバ候補ベストランク表」の上位 "足りていない数"個のノードに対してキーサーバに就くように推奨する;
}

//----------------------------------------------------------------
// システム管理サーバの調整
//----------------------------------------------------------------

キーサーバと同じ要領でシステム管理サーバの数を調整する;

  ※1
   適正値比較表

 ベストノード  ワーストサーバ
 10    > 3
 9    > 4
 8    > 5
 7    > 6
 6    < 7 ← ここを見つける。
 5    < 8  ここより上のワーストサーバは一般ノードを推奨
 4    < 9  ここより上のベストノードはサーバを推奨

僅差で交代するのは効率が悪いので、
「しきい」値以上の差が現れるまで交代しない。

****************************************************************************************

[キーサーバ適正とシステム管理サーバ適正の求め方]

細かい所まで考えていません。

種となる情報は以下の通り？

・希望   ... なりたい(補正値:×2)、なりたくない(補正値:×0.5)、どっちでも良い(補正値:×1)
・CPUパワー
・メモリ容量
・回線速度
・システムへの参加時間の期待値

「希望」以外の種情報から適正値を作り、希望により適正値に補正をかける。

「希望」以外の種情報から適正値を作る時は、
それぞれの種情報を同じ重みで計算出来るように、数を補正する必要がありそう。
例えば、「CPUパワー」、「メモリ容量」はMHz、MBytesと単位、数値の大きさが違うので、
一律0〜1000までの数値にマッピングする。
数値に重みの差を持たせたい場合は、マッピング後の数値に対して、掛け算することで、重みを作る。

  今日はここまで。

P2Pシミュレータ開発 <p2p...@li...> wrote:
    松永です。

  質問に答えるのを忘れてました。

  ＞そもそもユーザーがシステム管理サーバになりたいと思うメリットって何？

  １．ファイル共有に貢献したいという崇高？な気持ち。
  ２．仮定ですが、システム管理サーバがシステムの状態をある程度モニタリングして、それを描画できるとしたら、それを見てみたい！！とか？

  ...

  それか、システム管理サーバになりたい、とかなりたくないは、実はシステム内部の中間的な表現で、ユーザーインターフェース上では、「長時間つなぎっぱなしにしますか？」などのアンケートをとっていて、これを中間表現にすると「システム管理サーバになりたい」になるかもしれないって考えていたわけです。

  まあ、将来色々機能を考えていくうちになりたい理由が出てくるかもしれないって考えていました。

P2Pシミュレータ開発 <p2p...@li...> wrote:
    松永です。

  了解です。
  今日はシステム管理サーバの役割決定処理の詳細を考えていたんですが、
  そんな気がしていました。

  これらを踏まえて、後で、今日考えたシステム管理サーバの役割決定処理を文書化しますんで、
  その時、もう一回検証願います。

P2Pシミュレータ開発 <p2p...@li...> wrote:
  お疲れ様です。阿部です。
とりあえず今、気づいたところを回答いたします。
文中(●)参照

06/09/27 に P2Pシミュレータ開発
 さんは書きました:
> 松永です。
> ここ２日で考えたことを記しておきます。
>
> 主に、週末に阿部君と話した内容と、その補正案です。
>
> 内容を検討してみて下さい。
> 何言ってるかわからなかったら聞いて下さい。
> 欠点みつけた時も聞いてく下さい。
> 詰めが甘いところがありますので、補完をお願いします。
> 上記について、気が向いたらで構いません。
> 向かなかったら向かなかったで良いです。
>
> wikiには書き込んでいません。
>
> ********************************************************************
> キャッシュサーバはキーサーバの指示でキャッシュを行うのではなく、キャッシュサーバ自身の判断でキャッシュを行う。
> [概要]
> キャッシュサーバは自身のクラスタキーワードのファイルキーを監視して、ファイルの需要に供給が追いついていないと判断したら、そのファイルをダウンロードして、共有に貢献する。
> ファイルの供給は被参照量から知ることが出来るが、需要を知るには「ダウンロード要求量の管理」が必要になる。
> ダウンロード要求量はキーサーバ上でファイルキーの情報の一部として管理する。
> ファイルをダウンロードしたいノードは、ファイルのキーを持つキーサーバへ「ファイルをダウンロードしたいノードがいる」ということを伝え、キーサーバはこれをダウンロード要求量へ反映する。これはノードのダウンロードが完了するまで一定の間隔で行う。
> ただし、この方法ではダウンロード要求量は増える一方なので、サーバは一定間隔でダウンロード要求量をカウントダウンする。
> ダウンロード要求量の制御が適当ではあるが、厳密な数値は必要ないと判断。
> ※1. ダウンロード要求量という名前は仮。
> ※2. ファイル削除要求と考え方は同じ
> [薦める理由]
> キーサーバの指示でキャッシュサーバを動かすよりも制御が簡単。
>
> ********************************************************************
> 「」の案が通る場合、キャッシュサーバの台数制限を特に設けない。
> [概要]
> キャッシュサーバになりたいノードは、誰の許可も得ずに自分自身の判断でキャッシュサーバとなる。
> [薦める理由]
> の案が通る場合、キャッシュサーバを制御するコストが無くなるので、キャッシュサーバが多いデメリットが無くなる。
> デメリットが無ければ、キャッシュサーバは多いに越したことは無い。
> 又、キャッシュサーバに制限を設けて指名制にするよりも制御が簡単。
> ※、案が共に通ると、キャッシュサーバが完全に自立で動くため、システム管理サーバへのキャッシュサーバ登録が不要になるかも。
>
> ********************************************************************
> 条件付で、不完全なキャッシュのファイルキー登録を認める。
> [概要]
> キャッシュを保持するノードは、自身が持つ不完全なキャッシュを、キーサーバへのファイルキー登録を行わないことにしていた。
> これを撤廃して、キーサーバに完全なキャッシュのファイルキーが１つでもあれば、不完全なファイルキーの登録も認める。
> これを行うために、ファイルキーを完全と不完全の２つの状態で管理する。
> キーサーバは完全なファイルキーが無くなれば、それ以降、不完全なファイルキーの登録を認めない。
> 不完全なキャッシュを持つノードもファイルキーの登録を行わない。
> この場合、ファイルは自然消滅する。
> [薦める理由]
> 不完全なキャッシュのファイルキー登録を認めない理由が、不完全なキャッシュがネットワーク上にゴミとして残り、しかも、どれがゴミなのかが明確にならない状態を防ぐためであった。
> しかし、ここで薦める方法なら、その危険性が無くなる。
> また、一部分だけでもファイルの送信を行えるので、ファイル共有の効率が上がる。
>
> ********************************************************************
> ノードの役割決定について
> 本ファイル共有システムは、システム管理サーバ、キーサーバ、キャッシュサーバ、一般ノードという役割があり、
> 各ノードは自ノードの役割について希望を出すことが出来る。
> 希望とは、システム管理サーバ、キーサーバ、キャッシュサーバそれぞれについて、自ノードが「なりたい」、「なっても良い」、「なりたくない」と指定することである。（「なりたい」は一種類の役割に対してしか設定出来ない）
> ノードの希望とスペックによって、システム管理サーバから、それぞれの役割へ付くようにと指示が下ることになっていたが、この仕組みを考え直す。
> [概要]
> 1.ノードが「なりたい」指定をした場合、ノードは希望の役割に就ける。（というか、システム管理サーバの指示を必要とせずに勝手に就く）
> 2.ノードが「なりたくない」指定をした場合、ノードはその役割には就かない。
> 3.ノードが「なっても良い」指定をした場合、デフォルトで一般ノードをやりながら、システム管理サーバの指示に従う。
> (システム管理サーバ１台の指示に従うのではなく、複数台からの指示が集まった場合に従う)
> ただし、システム管理サーバが出す指示は、システム管理サーバ、キーサーバ、一般ノードのどれか。
> キャッシュサーバは、一般ノードをしている時に勝手にやる。
> 4.全てのノードはシステム管理サーバに自身の希望、スペック、現在の状態を一定間隔で送信する。
> システム管理サーバはその情報を元に役割を割り振る。
(●)
上記について、任意参加にするデメリットは大きいと考えます。
もともとシステム管理サーバに指示出しを行わせるシステムにしたのは、
システム全体のノード比率を一定にするという役割があったはずです。
それを任意にしてしまうと、理想形が作れなくなる危険性が生じ、
つまり、全体のシステム効率が落ちる危険性が生じます。

そもそもユーザーがシステム管理サーバになりたいと思うメリットって何？

とりあえず、以上です。

>
> 以上です。
>
>
> ________________________________
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
>
>
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
  [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
  [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
  [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
[旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！

松永です。

  以下について、検討願います。
  またまた、wikiには書き込んでいません。

  【システム管理サーバの役割推薦処理概要】

全てのノードは、いくつかのシステム管理サーバへ、自ノードの情報(希望、スペック、現在の役割)を一定間隔で送信する。

システム管理サーバは、一定時間の内で収集したノード情報を元に、以下情報を作成する。

・役割の比率
現在のファイル共有システム内の、システム管理サーバ、キーサーバ、キャッシュサーバ、一般ノードの比率。
(現在は、「ノード数」の比率で判断しているが、将来的には、「マシンスペック」の比率として考えるかもしれない)

・キーサーバワーストランク表
  キーサーバにキーサーバ適正ランクをつけてランキングしたもの。
  適正がないもののランキング。適正がないほど上位に来る。
  上位 n 個(未定)まで保持する。

・キーサーバ候補ベストランク表
  一般ノードにキーサーバ適正ランクをつけてランキングしたもの。
  適正があるもののランキング。適正があるほど上位に来る。
  上位 n 個(未定)まで保持する。

・システム管理サーバワーストランク表
  一般ノードにシステム管理サーバ適正ランクをつけてランキングしたもの。
  適正がないもののランキング。適正がないほど上位に来る。
  上位 n 個(未定)まで保持する。

・システム管理サーバ候補ベストランク表
 一般ノードにシステム管理サーバ適正ランクをつけてランキングしたもの。
  適正があるもののランキング。適正があるほど上位に来る。
  上位 n 個(未定)まで保持する。

システム管理サーバは上記情報を元に、ノード役割推薦処理を行う。
一定時間内に、システム管理サーバから多くの(数は未定)推薦を受けたノードは推薦に従う。

[ノード役割推薦処理](擬似言語)
※実際のコードをこのように書くという意図ではなく、説明の手段として擬似言語を用いる。

****************************************************************************************

//----------------------------------------------------------------
// キーサーバの調整
//----------------------------------------------------------------

if (キーサーバの数が足りているか？) {
 // キーサーバの数が足りている

 if(キーサーバの数が多すぎか？) {
  // キーサーバの数が多すぎ

  「キーサーバワーストランク表」の上位 "多すぎる数" 個のノードに対して、キーサーバを辞めるように推奨する;

 } else {
  // キーサーバの数がちょうど良い

  // ※1参照
  indexを0からカウントアップしていき、
  しきい値 + 「キーサーバワーストランク表」[index].適正 < 「キーサーバ候補ベストランク表」[index]適正
  となる、indexを見つける;

  「キーサーバワーストランク表」[0] 〜 [index - 1] のノードに対して、キーサーバを辞めるように推奨する;

  「キーサーバ候補ベストランク表」[0] 〜 [index - 1] のノードに対して、キーサーバに就くように推奨する;
 }

} else {
 // キーサーバの数が足りていない

 「キーサーバ候補ベストランク表」の上位 "足りていない数"個のノードに対してキーサーバに就くように推奨する;
}

//----------------------------------------------------------------
// システム管理サーバの調整
//----------------------------------------------------------------

キーサーバと同じ要領でシステム管理サーバの数を調整する;

  ※1
   適正値比較表

 ベストノード  ワーストサーバ
 10    > 3
 9    > 4
 8    > 5
 7    > 6
 6    < 7 ← ここを見つける。
 5    < 8  ここより上のワーストサーバは一般ノードを推奨
 4    < 9  ここより上のベストノードはサーバを推奨

僅差で交代するのは効率が悪いので、
「しきい」値以上の差が現れるまで交代しない。

****************************************************************************************

[キーサーバ適正とシステム管理サーバ適正の求め方]

細かい所まで考えていません。

種となる情報は以下の通り？

・希望   ... なりたい(補正値:×2)、なりたくない(補正値:×0.5)、どっちでも良い(補正値:×1)
・CPUパワー
・メモリ容量
・回線速度
・システムへの参加時間の期待値

「希望」以外の種情報から適正値を作り、希望により適正値に補正をかける。

「希望」以外の種情報から適正値を作る時は、
それぞれの種情報を同じ重みで計算出来るように、数を補正する必要がありそう。
例えば、「CPUパワー」、「メモリ容量」はMHz、MBytesと単位、数値の大きさが違うので、
一律0〜1000までの数値にマッピングする。
数値に重みの差を持たせたい場合は、マッピング後の数値に対して、掛け算することで、重みを作る。

  今日はここまで。

P2Pシミュレータ開発 <p2p...@li...> wrote:
    松永です。

  質問に答えるのを忘れてました。

  ＞そもそもユーザーがシステム管理サーバになりたいと思うメリットって何？

  １．ファイル共有に貢献したいという崇高？な気持ち。
  ２．仮定ですが、システム管理サーバがシステムの状態をある程度モニタリングして、それを描画できるとしたら、それを見てみたい！！とか？

  ...

  それか、システム管理サーバになりたい、とかなりたくないは、実はシステム内部の中間的な表現で、ユーザーインターフェース上では、「長時間つなぎっぱなしにしますか？」などのアンケートをとっていて、これを中間表現にすると「システム管理サーバになりたい」になるかもしれないって考えていたわけです。

  まあ、将来色々機能を考えていくうちになりたい理由が出てくるかもしれないって考えていました。

P2Pシミュレータ開発 <p2p...@li...> wrote:
    松永です。

  了解です。
  今日はシステム管理サーバの役割決定処理の詳細を考えていたんですが、
  そんな気がしていました。

  これらを踏まえて、後で、今日考えたシステム管理サーバの役割決定処理を文書化しますんで、
  その時、もう一回検証願います。

P2Pシミュレータ開発 <p2p...@li...> wrote:
  お疲れ様です。阿部です。
とりあえず今、気づいたところを回答いたします。
文中(●)参照

06/09/27 に P2Pシミュレータ開発
 さんは書きました:
> 松永です。
> ここ２日で考えたことを記しておきます。
>
> 主に、週末に阿部君と話した内容と、その補正案です。
>
> 内容を検討してみて下さい。
> 何言ってるかわからなかったら聞いて下さい。
> 欠点みつけた時も聞いてく下さい。
> 詰めが甘いところがありますので、補完をお願いします。
> 上記について、気が向いたらで構いません。
> 向かなかったら向かなかったで良いです。
>
> wikiには書き込んでいません。
>
> ********************************************************************
> キャッシュサーバはキーサーバの指示でキャッシュを行うのではなく、キャッシュサーバ自身の判断でキャッシュを行う。
> [概要]
> キャッシュサーバは自身のクラスタキーワードのファイルキーを監視して、ファイルの需要に供給が追いついていないと判断したら、そのファイルをダウンロードして、共有に貢献する。
> ファイルの供給は被参照量から知ることが出来るが、需要を知るには「ダウンロード要求量の管理」が必要になる。
> ダウンロード要求量はキーサーバ上でファイルキーの情報の一部として管理する。
> ファイルをダウンロードしたいノードは、ファイルのキーを持つキーサーバへ「ファイルをダウンロードしたいノードがいる」ということを伝え、キーサーバはこれをダウンロード要求量へ反映する。これはノードのダウンロードが完了するまで一定の間隔で行う。
> ただし、この方法ではダウンロード要求量は増える一方なので、サーバは一定間隔でダウンロード要求量をカウントダウンする。
> ダウンロード要求量の制御が適当ではあるが、厳密な数値は必要ないと判断。
> ※1. ダウンロード要求量という名前は仮。
> ※2. ファイル削除要求と考え方は同じ
> [薦める理由]
> キーサーバの指示でキャッシュサーバを動かすよりも制御が簡単。
>
> ********************************************************************
> 「」の案が通る場合、キャッシュサーバの台数制限を特に設けない。
> [概要]
> キャッシュサーバになりたいノードは、誰の許可も得ずに自分自身の判断でキャッシュサーバとなる。
> [薦める理由]
> の案が通る場合、キャッシュサーバを制御するコストが無くなるので、キャッシュサーバが多いデメリットが無くなる。
> デメリットが無ければ、キャッシュサーバは多いに越したことは無い。
> 又、キャッシュサーバに制限を設けて指名制にするよりも制御が簡単。
> ※、案が共に通ると、キャッシュサーバが完全に自立で動くため、システム管理サーバへのキャッシュサーバ登録が不要になるかも。
>
> ********************************************************************
> 条件付で、不完全なキャッシュのファイルキー登録を認める。
> [概要]
> キャッシュを保持するノードは、自身が持つ不完全なキャッシュを、キーサーバへのファイルキー登録を行わないことにしていた。
> これを撤廃して、キーサーバに完全なキャッシュのファイルキーが１つでもあれば、不完全なファイルキーの登録も認める。
> これを行うために、ファイルキーを完全と不完全の２つの状態で管理する。
> キーサーバは完全なファイルキーが無くなれば、それ以降、不完全なファイルキーの登録を認めない。
> 不完全なキャッシュを持つノードもファイルキーの登録を行わない。
> この場合、ファイルは自然消滅する。
> [薦める理由]
> 不完全なキャッシュのファイルキー登録を認めない理由が、不完全なキャッシュがネットワーク上にゴミとして残り、しかも、どれがゴミなのかが明確にならない状態を防ぐためであった。
> しかし、ここで薦める方法なら、その危険性が無くなる。
> また、一部分だけでもファイルの送信を行えるので、ファイル共有の効率が上がる。
>
> ********************************************************************
> ノードの役割決定について
> 本ファイル共有システムは、システム管理サーバ、キーサーバ、キャッシュサーバ、一般ノードという役割があり、
> 各ノードは自ノードの役割について希望を出すことが出来る。
> 希望とは、システム管理サーバ、キーサーバ、キャッシュサーバそれぞれについて、自ノードが「なりたい」、「なっても良い」、「なりたくない」と指定することである。（「なりたい」は一種類の役割に対してしか設定出来ない）
> ノードの希望とスペックによって、システム管理サーバから、それぞれの役割へ付くようにと指示が下ることになっていたが、この仕組みを考え直す。
> [概要]
> 1.ノードが「なりたい」指定をした場合、ノードは希望の役割に就ける。（というか、システム管理サーバの指示を必要とせずに勝手に就く）
> 2.ノードが「なりたくない」指定をした場合、ノードはその役割には就かない。
> 3.ノードが「なっても良い」指定をした場合、デフォルトで一般ノードをやりながら、システム管理サーバの指示に従う。
> (システム管理サーバ１台の指示に従うのではなく、複数台からの指示が集まった場合に従う)
> ただし、システム管理サーバが出す指示は、システム管理サーバ、キーサーバ、一般ノードのどれか。
> キャッシュサーバは、一般ノードをしている時に勝手にやる。
> 4.全てのノードはシステム管理サーバに自身の希望、スペック、現在の状態を一定間隔で送信する。
> システム管理サーバはその情報を元に役割を割り振る。
(●)
上記について、任意参加にするデメリットは大きいと考えます。
もともとシステム管理サーバに指示出しを行わせるシステムにしたのは、
システム全体のノード比率を一定にするという役割があったはずです。
それを任意にしてしまうと、理想形が作れなくなる危険性が生じ、
つまり、全体のシステム効率が落ちる危険性が生じます。

そもそもユーザーがシステム管理サーバになりたいと思うメリットって何？

とりあえず、以上です。

>
> 以上です。
>
>
> ________________________________
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
>
>
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
  [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
  [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
[旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！

松永です。

  質問に答えるのを忘れてました。

  ＞そもそもユーザーがシステム管理サーバになりたいと思うメリットって何？

  １．ファイル共有に貢献したいという崇高？な気持ち。
  ２．仮定ですが、システム管理サーバがシステムの状態をある程度モニタリングして、それを描画できるとしたら、それを見てみたい！！とか？

  ...

  それか、システム管理サーバになりたい、とかなりたくないは、実はシステム内部の中間的な表現で、ユーザーインターフェース上では、「長時間つなぎっぱなしにしますか？」などのアンケートをとっていて、これを中間表現にすると「システム管理サーバになりたい」になるかもしれないって考えていたわけです。

  まあ、将来色々機能を考えていくうちになりたい理由が出てくるかもしれないって考えていました。

P2Pシミュレータ開発 <p2p...@li...> wrote:
    松永です。

  了解です。
  今日はシステム管理サーバの役割決定処理の詳細を考えていたんですが、
  そんな気がしていました。

  これらを踏まえて、後で、今日考えたシステム管理サーバの役割決定処理を文書化しますんで、
  その時、もう一回検証願います。

P2Pシミュレータ開発 <p2p...@li...> wrote:
  お疲れ様です。阿部です。
とりあえず今、気づいたところを回答いたします。
文中(●)参照

06/09/27 に P2Pシミュレータ開発
 さんは書きました:
> 松永です。
> ここ２日で考えたことを記しておきます。
>
> 主に、週末に阿部君と話した内容と、その補正案です。
>
> 内容を検討してみて下さい。
> 何言ってるかわからなかったら聞いて下さい。
> 欠点みつけた時も聞いてく下さい。
> 詰めが甘いところがありますので、補完をお願いします。
> 上記について、気が向いたらで構いません。
> 向かなかったら向かなかったで良いです。
>
> wikiには書き込んでいません。
>
> ********************************************************************
> キャッシュサーバはキーサーバの指示でキャッシュを行うのではなく、キャッシュサーバ自身の判断でキャッシュを行う。
> [概要]
> キャッシュサーバは自身のクラスタキーワードのファイルキーを監視して、ファイルの需要に供給が追いついていないと判断したら、そのファイルをダウンロードして、共有に貢献する。
> ファイルの供給は被参照量から知ることが出来るが、需要を知るには「ダウンロード要求量の管理」が必要になる。
> ダウンロード要求量はキーサーバ上でファイルキーの情報の一部として管理する。
> ファイルをダウンロードしたいノードは、ファイルのキーを持つキーサーバへ「ファイルをダウンロードしたいノードがいる」ということを伝え、キーサーバはこれをダウンロード要求量へ反映する。これはノードのダウンロードが完了するまで一定の間隔で行う。
> ただし、この方法ではダウンロード要求量は増える一方なので、サーバは一定間隔でダウンロード要求量をカウントダウンする。
> ダウンロード要求量の制御が適当ではあるが、厳密な数値は必要ないと判断。
> ※1. ダウンロード要求量という名前は仮。
> ※2. ファイル削除要求と考え方は同じ
> [薦める理由]
> キーサーバの指示でキャッシュサーバを動かすよりも制御が簡単。
>
> ********************************************************************
> 「」の案が通る場合、キャッシュサーバの台数制限を特に設けない。
> [概要]
> キャッシュサーバになりたいノードは、誰の許可も得ずに自分自身の判断でキャッシュサーバとなる。
> [薦める理由]
> の案が通る場合、キャッシュサーバを制御するコストが無くなるので、キャッシュサーバが多いデメリットが無くなる。
> デメリットが無ければ、キャッシュサーバは多いに越したことは無い。
> 又、キャッシュサーバに制限を設けて指名制にするよりも制御が簡単。
> ※、案が共に通ると、キャッシュサーバが完全に自立で動くため、システム管理サーバへのキャッシュサーバ登録が不要になるかも。
>
> ********************************************************************
> 条件付で、不完全なキャッシュのファイルキー登録を認める。
> [概要]
> キャッシュを保持するノードは、自身が持つ不完全なキャッシュを、キーサーバへのファイルキー登録を行わないことにしていた。
> これを撤廃して、キーサーバに完全なキャッシュのファイルキーが１つでもあれば、不完全なファイルキーの登録も認める。
> これを行うために、ファイルキーを完全と不完全の２つの状態で管理する。
> キーサーバは完全なファイルキーが無くなれば、それ以降、不完全なファイルキーの登録を認めない。
> 不完全なキャッシュを持つノードもファイルキーの登録を行わない。
> この場合、ファイルは自然消滅する。
> [薦める理由]
> 不完全なキャッシュのファイルキー登録を認めない理由が、不完全なキャッシュがネットワーク上にゴミとして残り、しかも、どれがゴミなのかが明確にならない状態を防ぐためであった。
> しかし、ここで薦める方法なら、その危険性が無くなる。
> また、一部分だけでもファイルの送信を行えるので、ファイル共有の効率が上がる。
>
> ********************************************************************
> ノードの役割決定について
> 本ファイル共有システムは、システム管理サーバ、キーサーバ、キャッシュサーバ、一般ノードという役割があり、
> 各ノードは自ノードの役割について希望を出すことが出来る。
> 希望とは、システム管理サーバ、キーサーバ、キャッシュサーバそれぞれについて、自ノードが「なりたい」、「なっても良い」、「なりたくない」と指定することである。（「なりたい」は一種類の役割に対してしか設定出来ない）
> ノードの希望とスペックによって、システム管理サーバから、それぞれの役割へ付くようにと指示が下ることになっていたが、この仕組みを考え直す。
> [概要]
> 1.ノードが「なりたい」指定をした場合、ノードは希望の役割に就ける。（というか、システム管理サーバの指示を必要とせずに勝手に就く）
> 2.ノードが「なりたくない」指定をした場合、ノードはその役割には就かない。
> 3.ノードが「なっても良い」指定をした場合、デフォルトで一般ノードをやりながら、システム管理サーバの指示に従う。
> (システム管理サーバ１台の指示に従うのではなく、複数台からの指示が集まった場合に従う)
> ただし、システム管理サーバが出す指示は、システム管理サーバ、キーサーバ、一般ノードのどれか。
> キャッシュサーバは、一般ノードをしている時に勝手にやる。
> 4.全てのノードはシステム管理サーバに自身の希望、スペック、現在の状態を一定間隔で送信する。
> システム管理サーバはその情報を元に役割を割り振る。
(●)
上記について、任意参加にするデメリットは大きいと考えます。
もともとシステム管理サーバに指示出しを行わせるシステムにしたのは、
システム全体のノード比率を一定にするという役割があったはずです。
それを任意にしてしまうと、理想形が作れなくなる危険性が生じ、
つまり、全体のシステム効率が落ちる危険性が生じます。

そもそもユーザーがシステム管理サーバになりたいと思うメリットって何？

とりあえず、以上です。

>
> 以上です。
>
>
> ________________________________
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
>
>
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
  [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
[旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！

松永です。

  了解です。
  今日はシステム管理サーバの役割決定処理の詳細を考えていたんですが、
  そんな気がしていました。

  これらを踏まえて、後で、今日考えたシステム管理サーバの役割決定処理を文書化しますんで、
  その時、もう一回検証願います。

P2Pシミュレータ開発 <p2p...@li...> wrote:
  お疲れ様です。阿部です。
とりあえず今、気づいたところを回答いたします。
文中(●)参照

06/09/27 に P2Pシミュレータ開発
 さんは書きました:
> 松永です。
> ここ２日で考えたことを記しておきます。
>
> 主に、週末に阿部君と話した内容と、その補正案です。
>
> 内容を検討してみて下さい。
> 何言ってるかわからなかったら聞いて下さい。
> 欠点みつけた時も聞いてく下さい。
> 詰めが甘いところがありますので、補完をお願いします。
> 上記について、気が向いたらで構いません。
> 向かなかったら向かなかったで良いです。
>
> wikiには書き込んでいません。
>
> ********************************************************************
> キャッシュサーバはキーサーバの指示でキャッシュを行うのではなく、キャッシュサーバ自身の判断でキャッシュを行う。
> [概要]
> キャッシュサーバは自身のクラスタキーワードのファイルキーを監視して、ファイルの需要に供給が追いついていないと判断したら、そのファイルをダウンロードして、共有に貢献する。
> ファイルの供給は被参照量から知ることが出来るが、需要を知るには「ダウンロード要求量の管理」が必要になる。
> ダウンロード要求量はキーサーバ上でファイルキーの情報の一部として管理する。
> ファイルをダウンロードしたいノードは、ファイルのキーを持つキーサーバへ「ファイルをダウンロードしたいノードがいる」ということを伝え、キーサーバはこれをダウンロード要求量へ反映する。これはノードのダウンロードが完了するまで一定の間隔で行う。
> ただし、この方法ではダウンロード要求量は増える一方なので、サーバは一定間隔でダウンロード要求量をカウントダウンする。
> ダウンロード要求量の制御が適当ではあるが、厳密な数値は必要ないと判断。
> ※1. ダウンロード要求量という名前は仮。
> ※2. ファイル削除要求と考え方は同じ
> [薦める理由]
> キーサーバの指示でキャッシュサーバを動かすよりも制御が簡単。
>
> ********************************************************************
> 「」の案が通る場合、キャッシュサーバの台数制限を特に設けない。
> [概要]
> キャッシュサーバになりたいノードは、誰の許可も得ずに自分自身の判断でキャッシュサーバとなる。
> [薦める理由]
> の案が通る場合、キャッシュサーバを制御するコストが無くなるので、キャッシュサーバが多いデメリットが無くなる。
> デメリットが無ければ、キャッシュサーバは多いに越したことは無い。
> 又、キャッシュサーバに制限を設けて指名制にするよりも制御が簡単。
> ※、案が共に通ると、キャッシュサーバが完全に自立で動くため、システム管理サーバへのキャッシュサーバ登録が不要になるかも。
>
> ********************************************************************
> 条件付で、不完全なキャッシュのファイルキー登録を認める。
> [概要]
> キャッシュを保持するノードは、自身が持つ不完全なキャッシュを、キーサーバへのファイルキー登録を行わないことにしていた。
> これを撤廃して、キーサーバに完全なキャッシュのファイルキーが１つでもあれば、不完全なファイルキーの登録も認める。
> これを行うために、ファイルキーを完全と不完全の２つの状態で管理する。
> キーサーバは完全なファイルキーが無くなれば、それ以降、不完全なファイルキーの登録を認めない。
> 不完全なキャッシュを持つノードもファイルキーの登録を行わない。
> この場合、ファイルは自然消滅する。
> [薦める理由]
> 不完全なキャッシュのファイルキー登録を認めない理由が、不完全なキャッシュがネットワーク上にゴミとして残り、しかも、どれがゴミなのかが明確にならない状態を防ぐためであった。
> しかし、ここで薦める方法なら、その危険性が無くなる。
> また、一部分だけでもファイルの送信を行えるので、ファイル共有の効率が上がる。
>
> ********************************************************************
> ノードの役割決定について
> 本ファイル共有システムは、システム管理サーバ、キーサーバ、キャッシュサーバ、一般ノードという役割があり、
> 各ノードは自ノードの役割について希望を出すことが出来る。
> 希望とは、システム管理サーバ、キーサーバ、キャッシュサーバそれぞれについて、自ノードが「なりたい」、「なっても良い」、「なりたくない」と指定することである。（「なりたい」は一種類の役割に対してしか設定出来ない）
> ノードの希望とスペックによって、システム管理サーバから、それぞれの役割へ付くようにと指示が下ることになっていたが、この仕組みを考え直す。
> [概要]
> 1.ノードが「なりたい」指定をした場合、ノードは希望の役割に就ける。（というか、システム管理サーバの指示を必要とせずに勝手に就く）
> 2.ノードが「なりたくない」指定をした場合、ノードはその役割には就かない。
> 3.ノードが「なっても良い」指定をした場合、デフォルトで一般ノードをやりながら、システム管理サーバの指示に従う。
> (システム管理サーバ１台の指示に従うのではなく、複数台からの指示が集まった場合に従う)
> ただし、システム管理サーバが出す指示は、システム管理サーバ、キーサーバ、一般ノードのどれか。
> キャッシュサーバは、一般ノードをしている時に勝手にやる。
> 4.全てのノードはシステム管理サーバに自身の希望、スペック、現在の状態を一定間隔で送信する。
> システム管理サーバはその情報を元に役割を割り振る。
(●)
上記について、任意参加にするデメリットは大きいと考えます。
もともとシステム管理サーバに指示出しを行わせるシステムにしたのは、
システム全体のノード比率を一定にするという役割があったはずです。
それを任意にしてしまうと、理想形が作れなくなる危険性が生じ、
つまり、全体のシステム効率が落ちる危険性が生じます。

そもそもユーザーがシステム管理サーバになりたいと思うメリットって何？

とりあえず、以上です。

>
> 以上です。
>
>
> ________________________________
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
>
>
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
[旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！

お疲れ様です。阿部です。
とりあえず今、気づいたところを回答いたします。
文中(●)参照

06/09/27 に P2Pシミュレータ開発<p2p...@li...> さんは書きました:
> 松永です。
> ここ２日で考えたことを記しておきます。
>
> 主に、週末に阿部君と話した内容と、その補正案です。
>
> 内容を検討してみて下さい。
> 何言ってるかわからなかったら聞いて下さい。
> 欠点みつけた時も聞いてく下さい。
> 詰めが甘いところがありますので、補完をお願いします。
> 上記について、気が向いたらで構いません。
> 向かなかったら向かなかったで良いです。
>
> wikiには書き込んでいません。
>
> ********************************************************************
>  キャッシュサーバはキーサーバの指示でキャッシュを行うのではなく、キャッシュサーバ自身の判断でキャッシュを行う。
> [概要]
> キャッシュサーバは自身のクラスタキーワードのファイルキーを監視して、ファイルの需要に供給が追いついていないと判断したら、そのファイルをダウンロードして、共有に貢献する。
> ファイルの供給は被参照量から知ることが出来るが、需要を知るには「ダウンロード要求量の管理」が必要になる。
> ダウンロード要求量はキーサーバ上でファイルキーの情報の一部として管理する。
> ファイルをダウンロードしたいノードは、ファイルのキーを持つキーサーバへ「ファイルをダウンロードしたいノードがいる」ということを伝え、キーサーバはこれをダウンロード要求量へ反映する。これはノードのダウンロードが完了するまで一定の間隔で行う。
>  ただし、この方法ではダウンロード要求量は増える一方なので、サーバは一定間隔でダウンロード要求量をカウントダウンする。
> ダウンロード要求量の制御が適当ではあるが、厳密な数値は必要ないと判断。
> ※1. ダウンロード要求量という名前は仮。
>  ※2. ファイル削除要求と考え方は同じ
> [薦める理由]
>  キーサーバの指示でキャッシュサーバを動かすよりも制御が簡単。
>
> ********************************************************************
>  「」の案が通る場合、キャッシュサーバの台数制限を特に設けない。
> [概要]
>  キャッシュサーバになりたいノードは、誰の許可も得ずに自分自身の判断でキャッシュサーバとなる。
> [薦める理由]
>  の案が通る場合、キャッシュサーバを制御するコストが無くなるので、キャッシュサーバが多いデメリットが無くなる。
>  デメリットが無ければ、キャッシュサーバは多いに越したことは無い。
>  又、キャッシュサーバに制限を設けて指名制にするよりも制御が簡単。
> ※、案が共に通ると、キャッシュサーバが完全に自立で動くため、システム管理サーバへのキャッシュサーバ登録が不要になるかも。
>
> ********************************************************************
>  条件付で、不完全なキャッシュのファイルキー登録を認める。
> [概要]
> キャッシュを保持するノードは、自身が持つ不完全なキャッシュを、キーサーバへのファイルキー登録を行わないことにしていた。
>  これを撤廃して、キーサーバに完全なキャッシュのファイルキーが１つでもあれば、不完全なファイルキーの登録も認める。
> これを行うために、ファイルキーを完全と不完全の２つの状態で管理する。
>  キーサーバは完全なファイルキーが無くなれば、それ以降、不完全なファイルキーの登録を認めない。
>  不完全なキャッシュを持つノードもファイルキーの登録を行わない。
>  この場合、ファイルは自然消滅する。
> [薦める理由]
> 不完全なキャッシュのファイルキー登録を認めない理由が、不完全なキャッシュがネットワーク上にゴミとして残り、しかも、どれがゴミなのかが明確にならない状態を防ぐためであった。
> しかし、ここで薦める方法なら、その危険性が無くなる。
>  また、一部分だけでもファイルの送信を行えるので、ファイル共有の効率が上がる。
>
> ********************************************************************
>  ノードの役割決定について
> 本ファイル共有システムは、システム管理サーバ、キーサーバ、キャッシュサーバ、一般ノードという役割があり、
>  各ノードは自ノードの役割について希望を出すことが出来る。
> 希望とは、システム管理サーバ、キーサーバ、キャッシュサーバそれぞれについて、自ノードが「なりたい」、「なっても良い」、「なりたくない」と指定することである。（「なりたい」は一種類の役割に対してしか設定出来ない）
> ノードの希望とスペックによって、システム管理サーバから、それぞれの役割へ付くようにと指示が下ることになっていたが、この仕組みを考え直す。
> [概要]
> 1.ノードが「なりたい」指定をした場合、ノードは希望の役割に就ける。（というか、システム管理サーバの指示を必要とせずに勝手に就く）
> 2.ノードが「なりたくない」指定をした場合、ノードはその役割には就かない。
> 3.ノードが「なっても良い」指定をした場合、デフォルトで一般ノードをやりながら、システム管理サーバの指示に従う。
>  (システム管理サーバ１台の指示に従うのではなく、複数台からの指示が集まった場合に従う)
>  ただし、システム管理サーバが出す指示は、システム管理サーバ、キーサーバ、一般ノードのどれか。
>  キャッシュサーバは、一般ノードをしている時に勝手にやる。
> 4.全てのノードはシステム管理サーバに自身の希望、スペック、現在の状態を一定間隔で送信する。
>  システム管理サーバはその情報を元に役割を割り振る。
(●)
上記について、任意参加にするデメリットは大きいと考えます。
もともとシステム管理サーバに指示出しを行わせるシステムにしたのは、
システム全体のノード比率を一定にするという役割があったはずです。
それを任意にしてしまうと、理想形が作れなくなる危険性が生じ、
つまり、全体のシステム効率が落ちる危険性が生じます。

そもそもユーザーがシステム管理サーバになりたいと思うメリットって何？

とりあえず、以上です。

>
> 以上です。
>
>
>  ________________________________
> [旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> P2p-sim-develop mailing list
> P2p...@li...
> https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop
>
>
>

松永です。

  すみません。知りません。

  知らないけど、Excelじゃ不便だった？
  最後にキャプチャとれば画像出せるし。

P2Pシミュレータ開発 <p2p...@li...> wrote:
  阿部です。

wikiの説明に図を使いたいんだけど、矢印とか
楕円とかを簡単にかける説明向きの図を書くのが得意なツールって知らないかな？

ベクトル描画系でPNGとかJPGで最終出力できるフリーツール希望です。

以上よろしくお願いします。

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
P2p-sim-develop mailing list
P2p...@li...
https://lists.sourceforge.net/lists/listinfo/p2p-sim-develop

---------------------------------
[旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！

松永です。
  ここ２日で考えたことを記しておきます。

  主に、週末に阿部君と話した内容と、その補正案です。

  内容を検討してみて下さい。
  何言ってるかわからなかったら聞いて下さい。
  欠点みつけた時も聞いてく下さい。
  詰めが甘いところがありますので、補完をお願いします。
  上記について、気が向いたらで構いません。
  向かなかったら向かなかったで良いです。

  wikiには書き込んでいません。

  ********************************************************************
キャッシュサーバはキーサーバの指示でキャッシュを行うのではなく、キャッシュサーバ自身の判断でキャッシュを行う。
  [概要]
キャッシュサーバは自身のクラスタキーワードのファイルキーを監視して、ファイルの需要に供給が追いついていないと判断したら、そのファイルをダウンロードして、共有に貢献する。
  ファイルの供給は被参照量から知ることが出来るが、需要を知るには「ダウンロード要求量の管理」が必要になる。
  ダウンロード要求量はキーサーバ上でファイルキーの情報の一部として管理する。
ファイルをダウンロードしたいノードは、ファイルのキーを持つキーサーバへ「ファイルをダウンロードしたいノードがいる」ということを伝え、キーサーバはこれをダウンロード要求量へ反映する。これはノードのダウンロードが完了するまで一定の間隔で行う。
ただし、この方法ではダウンロード要求量は増える一方なので、サーバは一定間隔でダウンロード要求量をカウントダウンする。
  ダウンロード要求量の制御が適当ではあるが、厳密な数値は必要ないと判断。
  ※1. ダウンロード要求量という名前は仮。
※2. ファイル削除要求と考え方は同じ
  [薦める理由]
キーサーバの指示でキャッシュサーバを動かすよりも制御が簡単。

********************************************************************
「」の案が通る場合、キャッシュサーバの台数制限を特に設けない。
  [概要]
キャッシュサーバになりたいノードは、誰の許可も得ずに自分自身の判断でキャッシュサーバとなる。
  [薦める理由]
の案が通る場合、キャッシュサーバを制御するコストが無くなるので、キャッシュサーバが多いデメリットが無くなる。
デメリットが無ければ、キャッシュサーバは多いに越したことは無い。
又、キャッシュサーバに制限を設けて指名制にするよりも制御が簡単。
  ※、案が共に通ると、キャッシュサーバが完全に自立で動くため、システム管理サーバへのキャッシュサーバ登録が不要になるかも。

********************************************************************
条件付で、不完全なキャッシュのファイルキー登録を認める。
  [概要]
キャッシュを保持するノードは、自身が持つ不完全なキャッシュを、キーサーバへのファイルキー登録を行わないことにしていた。
これを撤廃して、キーサーバに完全なキャッシュのファイルキーが１つでもあれば、不完全なファイルキーの登録も認める。
  これを行うために、ファイルキーを完全と不完全の２つの状態で管理する。
キーサーバは完全なファイルキーが無くなれば、それ以降、不完全なファイルキーの登録を認めない。
不完全なキャッシュを持つノードもファイルキーの登録を行わない。
この場合、ファイルは自然消滅する。
  [薦める理由]
不完全なキャッシュのファイルキー登録を認めない理由が、不完全なキャッシュがネットワーク上にゴミとして残り、しかも、どれがゴミなのかが明確にならない状態を防ぐためであった。
  しかし、ここで薦める方法なら、その危険性が無くなる。
また、一部分だけでもファイルの送信を行えるので、ファイル共有の効率が上がる。

  ********************************************************************
ノードの役割決定について
  本ファイル共有システムは、システム管理サーバ、キーサーバ、キャッシュサーバ、一般ノードという役割があり、
各ノードは自ノードの役割について希望を出すことが出来る。
  希望とは、システム管理サーバ、キーサーバ、キャッシュサーバそれぞれについて、自ノードが「なりたい」、「なっても良い」、「なりたくない」と指定することである。（「なりたい」は一種類の役割に対してしか設定出来ない）
  ノードの希望とスペックによって、システム管理サーバから、それぞれの役割へ付くようにと指示が下ることになっていたが、この仕組みを考え直す。
  [概要]
1.ノードが「なりたい」指定をした場合、ノードは希望の役割に就ける。（というか、システム管理サーバの指示を必要とせずに勝手に就く）
  2.ノードが「なりたくない」指定をした場合、ノードはその役割には就かない。
  3.ノードが「なっても良い」指定をした場合、デフォルトで一般ノードをやりながら、システム管理サーバの指示に従う。
(システム管理サーバ１台の指示に従うのではなく、複数台からの指示が集まった場合に従う)
ただし、システム管理サーバが出す指示は、システム管理サーバ、キーサーバ、一般ノードのどれか。
キャッシュサーバは、一般ノードをしている時に勝手にやる。
  4.全てのノードはシステム管理サーバに自身の希望、スペック、現在の状態を一定間隔で送信する。
システム管理サーバはその情報を元に役割を割り振る。

  以上です。

---------------------------------
[旅行券１０万円分プレゼント！]　くわしくは≪未来携帯ラボ≫で！

阿部です。

wikiの説明に図を使いたいんだけど、矢印とか
楕円とかを簡単にかける説明向きの図を書くのが得意なツールって知らないかな？

ベクトル描画系でPNGとかJPGで最終出力できるフリーツール希望です。

以上よろしくお願いします。

阿部です。
ドキュメント書き始めましたので確認をお願いいたします。

http://p2p-sim.sourceforge.net/sitedev2/

Revision: 17
          http://svn.sourceforge.net/p2p-sim/?rev=17&view=rev
Author:   abe00makoto
Date:     2006-09-23 12:59:46 -0700 (Sat, 23 Sep 2006)

Log Message:
-----------
1.?\227?\131?\142?\227?\131?\188?\227?\131?\137?\227?\130?\175?\227?\131?\169?\227?\130?\185?\227?\129?\139?\227?\130?\137?\227?\131?\135?\227?\131?\188?\227?\130?\191?\233?\131?\168?\227?\130?\146?\229?\136?\134?\233?\155?\162
?\227?\128?\128?\227?\128?\128?\227?\130?\191?\227?\130?\185?\227?\130?\175?\231?\174?\161?\231?\144?\134?\227?\130?\146?\229?\136?\165?\227?\130?\175?\227?\131?\169?\227?\130?\185?\227?\129?\167?\230?\137?\177?\227?\129?\134?\227?\129?\171?\227?\129?\130?\227?\129?\159?\227?\130?\138?\227?\131?\135?\227?\131?\188?\227?\130?\191?\233?\131?\168?\227?\130?\146?\229?\136?\165?\227?\130?\175?\227?\131?\169?\227?\130?\185?\229?\140?\150?\227?\129?\151?\227?\129?\159
?\239?\188?\146?\239?\188?\142?\227?\130?\191?\227?\130?\185?\227?\130?\175?\231?\174?\161?\231?\144?\134?\227?\129?\174?\230?\138?\189?\232?\177?\161?\227?\130?\175?\227?\131?\169?\227?\130?\185?\227?\130?\146?\228?\189?\156?\230?\136?\144
?\239?\188?\147?\239?\188?\142etc?\227?\130?\175?\227?\131?\169?\227?\130?\185?\227?\130?\146?\228?\189?\156?\230?\136?\144?\227?\129?\151?\227?\129?\166?\227?\131?\142?\227?\131?\188?\227?\131?\137?\231?\168?\174?\229?\136?\165?\227?\129?\168?\227?\129?\139?\227?\131?\142?\227?\131?\188?\227?\131?\137?\230?\128?\167?\232?\131?\189?\229?\174?\154?\231?\190?\169?\227?\129?\170?\227?\129?\169?\227?\130?\146?\231?\167?\187?\231?\174?\161?\227?\129?\149?\227?\129?\155?\227?\129?\159

Modified Paths:
--------------
    trunk/ConectedNodeListManager.cs
    trunk/FileSharingSim.csproj
    trunk/Node.cs
    trunk/Sim.cs

Added Paths:
-----------
    trunk/Etc.cs
    trunk/NodeData.cs
    trunk/NodeTask.cs

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

p2p-sim-develop Mailing List for p2p-sim (Page 2)

p2p-sim-develop — 開発者よ集え！