>>202 このシステムの本質は、キャッシュ評価ではなく、キー評価です。
完全キャッシュしか評価できないようするとしているのは、
その方がより信頼性が高まるからです。
評価できるのは完全キャッシュのみという制限を省略しても、システムとして十分成立します。
ただ、Winnyがキャッシュの匿名性という前提を崩している限り、
それに便乗した方が、より信頼性を高められるというだけです。
まあWinnyの場合、キャッシュの暗号化はあってないようなものですし、
キーをキャッシュファイル内に格納していたり、
キャッシュファイル名(ハッシュ)からファイル名を逆算できるようなシステムを取っている限り、
完全キャッシュの表示を無効化しても、本質的に何も変わらないというのが
正式版でも表示が無効化されなかった理由かと推測しています。
4Zx0fK18の脳内ではシステムは完成していますかーーーーー?!
そうですかそうですか!!モヒャヒャヒャヒャヒャヒャヒャヒャヒャ!
このシステムはおそらく検索でそのキーを見たときに
常時評価を見れるということでしょうが、かなり問題はあります
Winnyが純粋P2Pということを忘れていませんか?
このシステムはPCに絶大な負担を強いることとなります。決して微小ではありません
キー情報に少し書き足すだけ?それは違う
それを自分のPCで評価の統計を取る必要があるのです
同じIDを削除して信頼度の高さを参照して全体の評価を決める
これを全てのキーについて行う必要があります
中央鯖も無いのにこんなシステムは組み込めないと思いますが
>>203 なるほど・・・
話の前提となる部分が根本的に違うわけですね
>ただ、Winnyがキャッシュの匿名性という前提を崩している限り、
>それに便乗した方が、より信頼性を高められるというだけです。
かたや「完全でない匿名性を、なるべく効率を落とさずして、出来るだけ
匿名性を上げる」事を考え、かたや「完全でない匿名性は諦めて、ツール
としての利便性を求める」
併存が難しい課題の中で、47氏は最終的にどのあたりを落とし所と考え
ているんでしょうね
>>205 キーの評価の統計を取るプロセスを考えて見ましょう。
1,キーに付加されているIDを取得
2,IDの信頼度を調べる
3,良いのフラグがたっていたら、信頼度を良い評価に加算
4,悪いのフラグがたっていたら、信頼度を悪い評価に加算
5,1から4を付加されているIDの数(最大4)だけ繰り返す。
このプロセスが起動するのは以下の場合です。
1,キーの情報を画面上に表示するとき
2,同一ハッシュのキーが重なったとき
1については、一度に最大100個ぐらいでしょうか。
2については、たまに起こる程度ですね。
この程度の処理が絶大な負荷を強いるとは、ちょっと説明がつきませんね。
全てのキーについて行う必要があるというのは、
何か根本的な勘違いをしているか、データ構造やアルゴリズムが悪いだけでしょう。
ヽ、
__ 、、 / ̄i ヽヽ > ,.-─ 、 i ー┼
| ‐- l / ! / / / } } | |
─┴─ __ノ / ! / つ { ヽ、ノ / L ⊂! ̄
ヽ
= ヽヽ 土
| \ /─┐l l -┼┐\ ニ ,. ヽ ┌┐ /
/ \ / / | ─, |< 7 不< |  ̄
/ ノ / ノ \ へ__ i ー-
< , 土 l
ム┌‐┐ / --‐r エエ ┼ -−/
小 ノレ < / E三l 口 ┼ メ、 ,.へ
\ つ { / \ヽヽ 丿|\ / ヽ = }
'ー  ̄ ヽ、 ー' o
ヽ、
__ 、、 / ̄i ヽヽ > ,.-─ 、 i ー┼
| ‐- l / ! / / / } } | |
─┴─ __ノ / ! / つ { ヽ、ノ / L ⊂! ̄
ヽ
= ヽヽ 土
| \ /─┐l l -┼┐\ ニ ,. ヽ ┌┐ /
/ \ / / | ─, |< 7 不< |  ̄
/ ノ / ノ \ へ__ i ー-
< , 土 l
ム┌‐┐ / --‐r エエ ┼ -−/
小 ノレ < / E三l 口 ┼ メ、 ,.へ
\ つ { / \ヽヽ 丿|\ / ヽ = }
'ー  ̄ ヽ、 ー' o
ベータテストいつ始まるの?
そのまえにシミュレータ作成、αがあります。期待して待ちましょう。
131さん進捗はここで報告して貰えるんですか?
>>210 Winnyが正式版になって、やっとこれからという時に作り初めても仕方がないでしょう。
Winnyのキャッシュ転送に関する法解釈や、警察および著作権協会の動向を見てから
設計を行わない限り、次世代P2Pにはなりえません。
まあWinnyのシステムが限界に来たら改めて検討しますよ。
今は各要素の構想を煮詰めている段階です。
じゃあその次世代P2Pソフト作る時は131の名前で作ってくれよ
本気だとしたら面白いですねー>>131氏w
>>213 131様の脳内では既に仕様が固まってらっしゃるようですから、
すぐに着手なさってwinnyと並ぶ2大国産P2Pクライアントを目指されてもよいのでは。
>>213 > まあWinnyのシステムが限界に来たら改めて検討しますよ。
> 今は各要素の構想を煮詰めている段階です。
そうですか。
構想が煮詰まるのを楽しみに待ってます。
それまで、さようなら。
131の人格障害はクラスターAとBの境界だな
もっとクラスタ化しる!
>>220 酒を飲んで書き込むと人格が豹変しますのでご注意を。
なんだ、やっぱ口だけじゃんとか絶対に言うなよ
>>217 すごいなー。
こんなに症例が一致することがあるんだ。
結局、実現不可能だということが判明しただけか
まあ、131には実現不能と見るのが妥当だろうな。
なんでIDの数がたった4つでいいの?
そんなことはありません。131様は凄いお方なのです。
きっと人々があっと驚くような物を瞬く間にお作り下さるに違いありません。
さぁ皆さんも一緒に131様に祈りを捧げましょう。
>>226 当然、あちこちでIDが発生し、あちこちのノードから様々なIDが流れてきますが、
その中から自分の信頼しているIDが選別して残されていきます。
自分のノードにとって、信頼度の高いIDが4つでもあれば十分な信頼性を得られるのです。
もちろん各ノードごとに、同じキーでも付いているIDは様々という状況になるでしょうね。
それぞれのノードに、それぞれが信頼しているIDが残ることになります。
IDなんか誰も流さねーよ(藁
ここまで構想が固まってるんなら、もう机上検討の時期はとうに過ぎてるよね
シミュレーションしてみることをお勧めするよ
通常のクラスタリングによるキー拡散の部分は単純なモデル化で間に合うと思う
(あるいはクラスタに関してはバッサリ切り捨てていいと思うよ)
もちろん評価アルゴリズムの部分だけは完全なモデルを用意する。
主なパラメータは、捏造ファイルの混在率、積極的に評価するノードの割合、
ついでにプラス評価とマイナス評価を行う確率もかな?
スケールは自由だけど、キー拡散がある程度平衡化するのを待つといいだろうね。
ゴールは積極ノードと無関心ノードで捏造キーを保持する確率の比較と、
捏造キーがどの程度偏在化するかどうか。
結果にはちょっと関心があるので、是非131氏には頑張って欲しいところ。
>>230 そうだね、軽くシミュレーターでも書いてみるよ。
その言葉を待っていた。オープンソースのシミュきぼん
さて、議論ごっこを再開しましょうか
>>231 キタ━━(゜∀゜)━━!!
期待してます!!
システムの挙動に期待してる。
236 :
無駄age万歳:03/01/16 00:02 ID:njPdveD5
謎の多いシステムだな…説明してくれ。
>>207 "プロセスが起動"の
"1,キーの情報を画面上に表示するとき"ってどの時どの位なのか?
なぜ一度に最大100個なのか?
検索画面で表示するなら最大で検索表字に該当するキー全ての評価を
表示サイクルで評価する?
そうならID評価範囲が検索表字に該当するキー範囲内だけか?
あと、過去の信頼度の評価保存方法。
"2,同一ハッシュのキーが重なったとき"
該当ファイルが密集するクラスタなら毎評価時に起こりそうだが…
あとこれってキー流してるノードを切断、ノード評価するなら、
発信元はわかってるんだよな。
シミュレーション結果がでてくれば大体の傾向はわかるのか…
やっぱりゲイナークラスタではゲイ(ry
>>237 まあ、質問は実装が出来てからにしようや。
いまはインプリにがんばってもらいましょう。
>>231 がんばれー。
アプリの方も期待してるよ!
汚名返上なるか
汚名挽回。。。
名誉返上。。。
馬鹿な奴ら。
捏造にしたって、GAMEz、APPz系はちょっと起動しただけでは分からないようにした
バッドイメージ(あるDATAを破壊)を作成してるので、ny厨には分からないだろうな。
証拠に、俺が捏造した多数のファイルの参照数が凄い。親切にもバか共が広めて
くれるから。(w
ウィルスだって、ウィルスチェックにかからないものなどいくらでもあるぞ。
もしnyでAPPzやGAMEzを落としたことがあるやつがここにいたら、、気をつけろよと
忠告しておく。
時限爆弾式のやつを大量にばらまいたから、○ヶ月後の忘れた頃に、
貴方のHDDをきれいに掃除してくれるよ。本当にきれいさっぱりとね。
当然チェックしたって無駄、クリーンインストールするしかない。ま、感染源
がわからないから、例のGAME、APPを実行したらまたタイマーが作動。
怖かったら、PCの内部時計でも遅らせておけよ。ま、せいぜい掃除されないようにな
ギャハハハハハはははははh!
まあ、131の成果報告をマターリと待とう。
test
250
251 :
Y:03/01/16 02:11 ID:oEeYGBKX
こんな雰囲気の中にまじめに書いていいですか?
自動で数値で評価で楽っちゃらくだけど
結局は個人個人の趣味主張があるわけで みんなが糞評価のものでも欲しい人はいる
そういう情報が欲しい時もあるわけでして
つうことで 機械的な評価でなく 面倒な手動感想システム っていうのはどうよ
ハッシュに対応する 感想データをそのファイルのハッシュ情報と共に放流する
細かい仕様とかは 識者に任せるとして
想定してる操作方法としては
検索、ダウン、無視、タスク状況などで
ハッシュの取得できてるものところで右クリック で”評価・感想の入力”
みたいな感じで 書き込んで放流
逆に欲しいファイルの検索やダウン時は ”評価・感想の参照”で
その選択した検索中ファイルのハッシュをキーに感想を収集し、
そのファイルの評価感想をまとめて見れる
そのファイルに対する 専用掲示板みたいなもんになるわけですが
それぞれのジャンルの掲示板から情報収集するより かなり楽だと思われ
感想データ自体は 別データとして流して トラフィックの妨害にならないように
感想データ文字数は制限したほうがいいかもね
数値的な評価より こんな機能が欲しい
現行の掲示板システムの拡張で実装できないかなぁ
>>251 たしか既出だったと思うが、
技術うんぬんじゃなく、機能としては面白そう。
追加:感想などをうpした人がみれたらうp意欲向上(場合によっては減退)