Winnyのオープンソース化を考えるスレ

このエントリーをはてなブックマークに追加
1 ：login:Penguin：
http://pc.2ch.net/test/read.cgi/linux/1053087824/882
>882 ：47 ◆KbtLZwerNc ：03/06/19 08:50 ID:AhStOI42
>Winny作者ですが
>
>あれがクローズドシステムになっているのは、好きでそうしているわけではなく、
>こちらの設計能力不足によるものですので、もしオープンソースでも問題ないメカニズムが
>導入できるのなら、こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。
>
>その際には現在のWinnyとの互換性はなくなると思いますが。
>
>今やってるWinny2のその次を考えるとどうしても一人でやっているのは限界があるわけで、
>オープンシステム化かもしくは別の方法による大規模化は避けて通れないでしょう。
>
>とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので、考えるのだけはよろしくお願いします。
>だめならソース非公開なままでUNIX版を作るという手もありですが、こちらの時間的余裕の問題で
>オープンにできないのであればUNIX版ができることは無いと思います。


関連スレ

lopster の次は何なんだ？
http://pc.2ch.net/test/read.cgi/linux/1051890709/
Linny開発プロジェクト
http://pc.2ch.net/test/read.cgi/linux/1053087824/
2 ：login:Penguin：03/06/19 20:00 ID:nCXOqHKi
3 ：login:Penguin：03/06/19 20:02 ID:2VKmAhAn
オープンソース化出来ればLinux版も出るってことね。
4 ：叩き台：03/06/19 20:04 ID:TyaZhHjT
907 ：login:Penguin ：03/06/19 19:13 ID:ZkZwmrMo
思いつきで書いちまうんだが交換じゃなくて共有って言う前提なら
常にUPし続けるシステムなんかどうかな。
特にリクエストがなくても周りのノードにUPしっぱなし。UPがないノードは蹴る。
キャッシュを持ってないノードは参加できないけど
それ以外にポジティブに捏造ファイルを作る理由はないし。
5 ：_：03/06/19 20:06 ID:IGr//tIP
http://homepage.mac.com/hiroyuki44/
6 ：login:Penguin：03/06/19 20:07 ID:0QDuRJl0
>>4
今までで一番現実的な方法だと思うな
運用するまではどうなるか分からないという意味では
7 ：login:Penguin：03/06/19 20:18 ID:MsRwmoVZ
>　攻撃的なノードが、見た目は正規な捏造データをネットワークに
>流し込むという攻撃を行ったときに多くのノードのキャッシュが
>飽和してしまい破綻することが考えられます。

前スレにも書いたけど，ゴミデータをばらまくノードは少数であると
仮定できるので問題ないと思う．ゴミキャッシュは各自捨てると
思うし．
8 ：login:Penguin：03/06/19 20:25 ID:0QDuRJl0
>>7
>　攻撃的なノードが、見た目は正規な捏造データをネットワークに
>流し込むという攻撃を行ったときに多くのノードのキャッシュが
>飽和してしまい破綻することが考えられます。

ACCSの調査によるとWinnyユーザーは20万人程度らしい

某著作権乱用団体なんかが捏造データをばら撒いたとして
大した問題にはならないだろうね
9 ：login:Penguin：03/06/19 20:40 ID:AHoeg/az
常時ばらまくモデルで、
さらに参照量が多いファイルを優先してばらまくようにするといいのかな。

問題はその「参照量」なわけだけど、Winnyと同様でいいか。
10 ：login:Penguin：03/06/19 20:42 ID:AHoeg/az
（´-`）.｡oO(linnyのプロジェクトページ、html汚いから書き直しちゃって良いかなぁ……。)
(´-`).｡oO(535氏はﾄﾘｯﾌﾟ漏れしてるみたいだし。)
11 ：login:Penguin：03/06/19 20:44 ID:yJk/nWs5
>>10
もう終わったんだんから消した方がいいんじゃない
12 ：login:Penguin：03/06/19 20:47 ID:AHoeg/az
作業場所としてはsf.jp便利だと思うからそのまま使っちゃえばいいと思ってるんだけど、
やっぱりプロジェクト作り直した方が良い？
13 ：login:Penguin：03/06/19 20:52 ID:laEhQ9SE
>>12
　管理が引き継げるならそのまま使ってしまったほうがよいのでは？
　作った当初の目的であれば無用なものであったかもしれないが
有効に使う方策が立ったなら使ったほうがsf.jpもありがたいのでは
14 ：login:Penguin：03/06/19 20:56 ID:yJk/nWs5
>>12
実際に47氏がオープンソース化するまではどうせいらないんだから
それがうまくいった時にﾌﾟﾛｼﾞｪｸﾄWinnyとして作った方がいいのでは
15 ：login:Penguin：03/06/19 20:56 ID:yJk/nWs5
そのへんは47氏がやることだけどね
16 ：login:Penguin：03/06/19 21:02 ID:AHoeg/az
とりあえずhtml書き直してリンクを新スレに張り替えた。
古いのはこっち。http://linny.sourceforge.jp/index-old.html

プロジェクトは当面今のまま、
オープンソースwinnyの話がちゃんと進んでいくようなら改めて作成、でFA？

問題は現状で535氏と漏れしかアカウント持ってなくて、
535が荒らしにめげて行方不明になると追加が出来ないことくらいか。
17 ：login:Penguin：03/06/19 21:06 ID:WrZtUSuN
>>16
WinnyはLinnyじゃないんだから新しく作らないと
47氏主導のﾌﾟﾛｼﾞｪｸﾄになったら自然と人は集まるでしょうね
18 ：login:Penguin：03/06/19 21:07 ID:AHoeg/az
（;´-`）.｡oO(IDがAhoだ……。)
19 ：login:Penguin：03/06/19 21:25 ID:laEhQ9SE
>>17
　47氏主導っていうけど、いままでの47氏のスタンスからすれば主導にはならないのでは
ないかと思う。
　「設計が煮詰まれば（って、煮詰まってどうするの(汗))実装はこちらでやっても良い」との
ことだし。
　47氏ってアイドルは便利だけど、すべてを期待してしまうのは間違いではないかな。
　47氏のオープン化への賛同の理由もWinny2のその次を考えるには一人ではやって
いけないってことだしね。現状ですら大変だと思うよ。
　実際Download板ではバージョンアップが遅れたといって「47野郎」呼ばわりする者まで
いるし。

>>9
　Winnyでの参照量の算定はどのように行っているのかわかりますか。挙動を考えてみた
のですが「これだ」と思うものに到達していないので解るようでしたらお願いします。
　あと、参照量自体がキーといっしょに流れているとするとセットで捏造されると
捏造データが優先的にプッシュされることになってしまいます。
20 ：login:Penguin：03/06/19 21:28 ID:WrZtUSuN
>>19
主導っていうと語弊があったね
主催ってところかな

今や日本のフリーソフト開発者の中で一番有名だから
21 ：login:Penguin：03/06/19 21:30 ID:+TEnjlEi
upフォルダ内のファイルの名前をランダムに交換したり
先頭100バイトを0fillするスクリプトを作りましたが
どこに公開すればいいですか?
22 ：login:Penguin：03/06/19 21:32 ID:AHoeg/az
うぷろだにでも上げてください。
23 ：login:Penguin：03/06/19 21:35 ID:1+tZNCNU
>　攻撃的なノードが、見た目は正規な捏造データをネットワークに
>流し込むという攻撃を行ったときに多くのノードのキャッシュが
>飽和してしまい破綻することが考えられます。

別にUPされてきたものをHDDに保存しなくてもいいと思った。
どうせDOMを防ぐためなんだし。
24 ：_：03/06/19 21:37 ID:poA7qbf1
http://homepage.mac.com/hiroyuki44/
25 ：login:Penguin：03/06/19 21:44 ID:WrZtUSuN
A
>>23
ADSLを考えた場合UPは1Mbit/s以下
ダウン側に400MB/hの速度が出たとして
一日でキャッシュが10Gほど流れるか

当然光もいるし、こればっかりはやってみないと分からないかも
26 ：login:Penguin：03/06/19 22:11 ID:HPZajc5b
日本のブロードバンド回線をパンパンにするのは反対
よって常にUPも反対
27 ：login:Penguin：03/06/19 22:11 ID:+hK5HNJy
>>23
＞別にUPされてきたものをHDDに保存しなくてもいいと思った。
＞どうせDOMを防ぐためなんだし。

　だとすると、Winny的に言えばキャッシュが拡散しないし、送られてきた
データが捏造であるかの確認もできずにDOM天国になってしまいます。
28 ：login:Penguin：03/06/19 22:16 ID:8/LP+43v
>>26
普通に使ってるだけでUPは100%近くになると思うけど

ちゃんとキャッシュを溜めてればね
29 ：login:Penguin：03/06/19 22:18 ID:41HCWwjN
今のWinnyだと
送り主→転送→転送→届け先
こんな感じだけど
送り主→転送→転送→届け先→誰か
みたいな感じでダウンロードした物をその場でアップすれば
アップしている間だけダウンみたいな感じに・・・

・・・すみません、馬鹿の妄想です
30 ：login:Penguin：03/06/19 22:20 ID:8/LP+43v
>>23
アップされてきたファイルを全く保存しない機能が
最初からついてるのはダメじゃない

特別悪意を持っていなくてもある程度の捏造を用意しておいて
UPされてきたファイルはUPしない場所に保存ってことが出来てしまうから
31 ：login:Penguin：03/06/19 22:25 ID:1+tZNCNU
>>27
DOMの動機ってのは帯域の損得と、危ないファイルをUPしたくないの二つだと思うんだが
前者は、捏造をUPしようが本物をUPしようが変わらないし、
後者は、ファイルの評価とクラスタリングを使えばどうにかならない・・・かな。
ちょっと妄想が過ぎたな。ｽﾏｿ
32 ：login:Penguin：03/06/19 22:37 ID:3h8M22AO
>>4
アップしてるかどうかを具体的に考えた時に

人気のあるファイルを持っており多くのダウンが掛かっているために
帯域が足りなくてアップ出来ない、または極めて遅いのか
不正なフログラムだからアップしてないのか
ってのをどうやって判断する？
33 ：login:Penguin：03/06/19 22:42 ID:+hK5HNJy
>>31
　帯域の損得というのは、UP枠がふさがるとDOWN効率が悪くなるっていう
ADSLの問題点のことを言っているのでしょうか。

　DOMの動機としてはこういうほうが直接的じゃないかな
３．とにかく欲しい。何が何でも欲しい
４．俺だけが持っていればいい。ほかのやつにはやる必要もない。
５．ハードディスクがいっぱいで公開することができません。

対策？
１．帯域を気にしている人に関しては、UP帯域とDOWN帯域を適度に
使うようにしなければ成らなくなることで対応。
２．危ないファイルをUPしたくない人に関しては、危ないファイルは
アップロードしなければ良いです。あなたのマシンを転送に使わせて
貰うかもしれませんが、ディスクスペースの共有ということでよろしく
３．欲しいものを手に入れるには、必要な手続きをしなければいけない。
それは(本人の意思とは関係なくとも)アップロードですということで。
４．これが一番タチが悪いです。が、(本人の意思に関係なくとも)アップ
ロードしなければダウンロードできないとすれば致し方なしとなるかな
５．共有システムですので共有資源を提供いただけない方はそれなりの
不利益を受けることになりますが、そこのところご了承ください。てな
感じでどうでしょう。
34 ：login:Penguin：03/06/19 22:50 ID:1+tZNCNU
>>32
ノードが不正なノードでない場合
そのUPされなかったノードとはつながらないだろうが、
そのことで問題はおきないのでは。

と、思ったのだが
けるって言うのは、単純につながないって意味だと捉えたんだけど、
ネットワーク全体ではじくって意味なのかな・・・
読解力なくてｽﾏｿ
35 ：login:Penguin：03/06/19 22:53 ID:+TEnjlEi
お前ら貧乏くさすぎ。余剰リソースを多少DOMられたからってそれがなんだ。
そもそものお前らは他人様の著作物を盗み取っているんだということを忘れるな。
36 ：32：03/06/19 23:00 ID:3h8M22AO
>>34
>ネットワーク全体ではじくって意味なのかな・・・
>>4はそう意味だと思ってたけど違うのかな、どっちも考えればいいけど

>そのUPされなかったノードとはつながらないだろうが、
繋がらないのは問題じゃない
人気のあるファイルを持っているノードは
そのファイルを落としに来てるノードからしかダウン出来なくなるし
37 ：login:Penguin：03/06/19 23:05 ID:1+tZNCNU
>>36
なるほど、そうするとキャッシュが拡散するまでのあいだDLしにくくなって
人気ファイルを持っている利点がなくなるわけか。
難しいね。
38 ：login:Penguin：03/06/19 23:11 ID:+hK5HNJy
>>35
　DOMなノードは共有ネットワークにおいての、デッドエンドポイントとなるので
ネットワークの構築には役に立たない。また、そのようなノードが多数になれば
ネットワーク自体の構成も難しくなる。よってネットワークを維持するためにも
DOM対策は必要。

　そりゃ「けちけちせずにDOMらせろ」っていうDOM君にとっては、DOM対策を
されるのはたまらないだろうが、あきらめてもらうしかない。

　別に犯罪データを共有するためにシステムを作ろうというのではなく、オープン
ソースで効率の良い共有システムを作れるかを考えているのですよ。

　ま、DOM対策は無理だなんていう者は、DOM対策されたくないからDOM対策は
不可能と信じ込ませたい輩だろうし気にすることもなし。

　ま、不可能であることを数学的に証明されたら諦めるしかないかもしれないけど
39 ：login:Penguin：03/06/19 23:12 ID:3h8M22AO
>>37
大量のファイルをもっている場合にも当てはまることだね
40 ：login:Penguin：03/06/19 23:13 ID:3h8M22AO
>>38
いちいちレスせんでよろしい
41 ：login:Penguin：03/06/19 23:18 ID:+hK5HNJy
>>34
　ネットワーク内でのノードが特定できないシステムであるとすればネットワーク全体として
そのノードを弾くのは不可能です。
　また、弾くにしても恒久的ではなく期限を設定したものにしないとネットワークが破綻して
いってしまいます。

　とりあえず、話をしてみて通じないやつだったらしばらく無視する。
　もし話が通じるようだったら付き合ってもいいかな。
　てな、感じで
42 ：login:Penguin：03/06/19 23:20 ID:19J+1+c1
>>38
こういうのがいると必ず荒れるんだよなぁ。
前スレからみたいだけどさ。
43 ：login:Penguin：03/06/19 23:27 ID:+hK5HNJy
>>40
　すまん、実際言いたいことは前の4行。

　あとはおまけだが、おまけのほうが長くなってしまった。
　さらに、はしゃがせたようなので、申し訳ない。

　最後の2行にかんしては、ここで考えている人にとっては
既知のことだったようで蛇足でした。
44 ：login:Penguin：03/06/19 23:28 ID:V/wzj31q
>>41
>ネットワーク内でのノードが特定できないシステムであるとすればネットワーク全体として
>そのノードを弾くのは不可能です。
何故不可能なのですか？

例えばnyにある検索リンクとして接続している相手から必ずUPを受けるようにして、
UPがなければ切断、という方法が取れると思うんですが。

実際のファイルを転送していなければ匿名性を考える必要もないですし。
45 ：login:Penguin：03/06/19 23:32 ID:V/wzj31q
>>44
>例えばnyにある検索リンクとして接続している相手から必ずUPを受けるようにして、
すみません、ただのUPじゃなく中継です
46 ：login:Penguin：03/06/19 23:40 ID:+TEnjlEi
お前らドケチどもは顕在化しようもないDOM問題を
無意味に恐れながら一生停滞してなさいってこった。
47 ：login:Penguin：03/06/19 23:45 ID:+hK5HNJy
>>44
　読解力不足でした。
　ここのノードが独自判断で弾くことにより、システム全体として弾くという意味であれば
可能だと思います。また、そのような各ノードの行動が全体のシステムの動作を決めていく
という点でも妥当であると思います。

　不可能だといったのは、「ネットワーク全体ではじく」の部分を「ネットワーク全体が
同期して弾く」と言う意味でとったためです。

　繰り返しますが、個々のノードが独自判断で弾くことによって全体として正しい動きに
成っていくというのはシステムとして正しいことだと思います。
48 ：login:Penguin：03/06/19 23:57 ID:ydzyJuet
俺厨なんで皆様みたいに賢くないんですけど。

nyってみんなファイルの運び屋さんで、あるノードは別のノードから
他のノードにファイルの断片を運ぶだけなんで、どこのノードがdom
なのかって判断しにくいと思うんです。

できるとしたら、このノードはファイルの断片をこれだけくれた
って言う評価を全ノードで共有するとかなのかなぁ。
あんまりdom対策にならないような気がしますが。

ふと思ったんですが、nyのバイナリ配布サーバから公開鍵を落としてきて
自nyバイナリのハッシュをnyのプロトコルに載せてそれが異なるノード
とは接続できなくするってのは可能なんでしょうか？
さらにすすんで信頼するnyのハッシュを管理できるようにして異なるny
とも接続可能にするって言うのは？

なんか楽しそうなんでカキコしてみました。
nyのオープンソース化楽しみです。
49 ：login:Penguin：03/06/20 00:03 ID:LIs+wP43
>>48
>できるとしたら、このノードはファイルの断片をこれだけくれた
>って言う評価を全ノードで共有するとかなのかなぁ。
落とした相手のノードを特定する情報がないんでそれは無理ですよ。

>自nyバイナリのハッシュをnyのプロトコルに載せてそれが異なるノード
>とは接続できなくするってのは可能なんでしょうか？
自ノードでプロトコルを制御する限り偽装が出来てしまうんで意味ないです。

出来れば前スレも読んで来て下さいね
50 ：login:Penguin：03/06/20 00:04 ID:aGx9wvKJ
つーかさ、前々スレで不可能って
結論が出てたんじゃないのか？
またループしようっての？

よほど天才的な人物が現れて画期的な
仕組みを考え出さないとムリ。はっきり言って
モマエらのような凡人は考えるだけムダ。
51 ：login:Penguin：03/06/20 00:06 ID:8+gPf7Ha
>>50
あなたが証明してくれるまでいつまでもどこまでも続けますよ。
52 ：login:Penguin：03/06/20 00:08 ID:gLRzIDOG
思いつきですがこんなんどうでしょ？
最後の通知経路は直接だとUL側を特定できてしまうので、適当なノードを必ず何段か経由するようにするとかが必要かも。

　■─┬─┬─┬　　　DL待機ノードが幾つか並んでいて、
　　　　□　 □　 □

　■─┬─┬─┬　　　その１つにULを開始する際、
　 　 　↓　 □　 □
　 　 　■

　■─┬─┬─┬　　　DL待機ノードを１つ渡して
　 　 　↓　　　　 □
　 　 　■─┬　　　
　 　 　 　 　□

　■─┬─┬─┬　　　
　 　 　↓　　　　 □　　　
　 　 　■─┬　　　　　　UL先のノードに渡したDL待機ノードへのULをさせる。
　 　 　 　 　↓　　　　　　落とす物が同じならばDLした物をUL。
　 　 　 　 　■　　　　　　違うものならば転送。

　■─┬─┬─┬　　　
　↑ 　↓　　　　 □　　　UL先のノードが働いているかを渡したDL待機ノードからの通知で監視。
　｜ 　■─┬　　　　　　全データをチェックする必要はないので適当な間隔をおいて、
　｜ 　 　 　↓　　　　　　受信データの一部のCRCみたいな物を通知。
　└───■　　　　　　通知を受けたUL側は自身の持つデータと一致するか確認。
53 ：login:Penguin：03/06/20 00:10 ID:LIs+wP43
>>50
私も以前は不可能だと思っていたんですが、どうやら間違っていたようです
それと前々スレから見てますがこのスレからはまだループしてません
一見非常に単純に見えてある意味>>4は画期的な仕組みかもしれませんね

>>51
煽らないようにね
54 ：login:Penguin：03/06/20 00:22 ID:LIs+wP43
>>52
これはまた複雑だけど面白い仕組みだね

ただファイル所持数の少ない、又は人気の低いノードには
待機ノードが足らなくなるのでは？
55 ：login:Penguin：03/06/20 00:24 ID:A4nFU5Ui
>>52
もし二つ目のノードが不正ノードだった場合、
この仕組みの中で最低限NWに貢献すさせることはできるけど
そのノードからUPをはじめさせることはできない。
でも、善意のノードがある程度あれば成り立ちそうだし、
現実的な解決案のひとつかもと、俺は思った。

後、転送をはさむ場合最後の通知経路をどうやって最終ノードに伝えるのか
思いつかなかったんだが、解説求む。
56 ：login:Penguin：03/06/20 00:33 ID:tqul4aq8
>>55
>後、転送をはさむ場合最後の通知経路をどうやって最終ノードに伝えるのか
>思いつかなかったんだが、解説求む。
52ではないけれど

例えば>>44のような転送用ノードをDL待機ノードの前に置いて
それを経由して通知すればどう？
57 ：login:Penguin：03/06/20 00:37 ID:A4nFU5Ui
>>56
なるほど、THX
58 ：login:Penguin：03/06/20 00:46 ID:gLRzIDOG
>>54
>待機ノードが足らなくなるのでは？

そうですね。

　■─┬　　　　　　　　　この形を理想形として帯域制限無し。
　↑ 　↓
　｜ 　■─┬
　｜ 　 　 　↓
　└───■

　■─┬　　　　　　　　　この形の場合は帯域制限付き（かどうかをUL側が設定できても良いかも）。
　 　 　↓　　　　　　　　　で、DL待ちノードが現れたらそこから理想形を目指すとか。
　 　 　■

>>55
>後、転送をはさむ場合最後の通知経路をどうやって最終ノードに伝えるのか

通知経路用のノードを接続中のノードから適当に持ってきて

　■─┬─┬─┬　　　
　 　 　↓　　　　
　 　 　■─┬　　　　　　　
　 　 　 　 　□─┬　　　DL待機ノードから、UL用ノードを１つ
　 　 　 　 　 　 　通　　　通知経路用のノードを１つ（以上）付加して、

　■─┬　　　　　　　　　この形を理想形として帯域制限無し。
　↑ 　↓
　｜ 　■─┬
　｜ 　 　 　↓
　｜　　　　 ■─┬
　└─────通　　　通知経路用のノードを経由して通知、とか・・・・・・・ますます複雑にｗ
59 ：login:Penguin：03/06/20 00:53 ID:aGx9wvKJ
>>53
はは、なかなか大人だね。



ところで、考えるのは自由だけどさ、今現在も
nyはファイルの転送効率や検索キーの拡散方法
から言っていっぱいいっぱいなのに、これ以上
システムを複雑化させて、freenetなんかの
二の舞ならないか？
60 ：login:Penguin：03/06/20 00:59 ID:tqul4aq8
>>59
どうなるかは実装するまで分からないのでは
以前47氏が作ってた様にシュミレーターが必要になるかもしれませんね
61 ：login:Penguin：03/06/20 01:09 ID:tBoo6esK
趣味ですか。
62 ：login:Penguin：03/06/20 01:11 ID:ru8WTorJ
>>60
　Winnyは実装後にいろいろ変更を加えた部分もあり、検索については
効率が良くない部分もあるので、作り方自体では効率が上がる可能性も
あります。
63 ：login:Penguin：03/06/20 01:11 ID:tqul4aq8
アホな内容に誤字か

突っ込まないでよ(w
64 ：login:Penguin：03/06/20 01:42 ID:GbocMa+T
>>59
複雑化に伴う問題っていうのは
ネットワーク全体の回線品質や個々のノードのスペック
の向上によって解決してくれる可能性があるよね


良い案も出てるようなので今は議論に集中しましょうよ
65 ：login:Penguin：03/06/20 02:23 ID:GK2rT6YP
>>20
> >>19
> 主導っていうと語弊があったね
> 主催ってところかな
>
> 今や日本のフリーソフト開発者の中で一番有名だから

うーん…。
66 ：login:Penguin：03/06/20 02:32 ID:Ff/87RlX
いまのところ>>4と>>52が議論の対象となるアイディアかな

>>4は>>32っていう問題が出てるね
67 ：login:Penguin：03/06/20 02:45 ID:Ff/87RlX
>>32
>人気のあるファイルを持っており多くのダウンが掛かっているために
>帯域が足りなくてアップ出来ない、または極めて遅いのか
>不正なフログラムだからアップしてないのか
>ってのをどうやって判断する？
他からの要求は無理にでも切ってもらって、
ダウンの何分の一かは必ずアップさせなければいけないのでは。
68 ：login:Penguin：03/06/20 02:48 ID:7WOI7lfu
>>52他
おもしろそう。
多段転送の確率が0でなければ2つ目の■から通知経路もらっても大して
問題ないのでは。
でもNYのキーにはIPの下半分しか書かれてない気がしないでもない(自信全無)
から、NYの検索システムを踏襲した上でこういうことやるとキーロスト多発するかも。

また、違法性阻却事由(ｹﾞﾗ は一定確率の中継によるキャッシュ保持に任せて、
通信経路の匿名性はあまり重視しなくても(早い話が今のNYと同程度)いいんで
はないかとも思うます。
69 ：login:Penguin：03/06/20 03:13 ID:ENwsXcg1
せっかくうまくいきそうなところに悪いんだけど、
あんまり4つも5つもノードが絡んでくるとまずくないかな。
ｎｙでは見えて隣の隣までだけど、それくらいで判断
できるようにならないかな。
70 ：login:Penguin：03/06/20 03:20 ID:Ff/87RlX
>>69
>>52のモデルなら最低3ノードで実現可能だよ
現在のWinnyも基本は転送が入って3ノードだから
大きくは変わらないのでは
71 ：login:Penguin：03/06/20 03:57 ID:Db+7WLBh
>>58
Ａ■─┬　　　　　　　　　
　↑ 　↓
　｜ Ｂ■─┬
　｜ 　 　 　↓
　└───■Ｃ
上記の関係にノードA、ノードB、ノードCと名付けます

１つのDOM作戦
　ノードBはノードAとノードCの関係においてノードCのみ転送を行う。
　転送が終了しノードBにデータがたまったらデータを変換しキャッシュをクリアする。
当然他のノードからの転送要求は受け付けない。
※単なるDOMよりはネットワーク上での損害は少ないが、ネットワークの効率を落とす。

１つのネットワーク攻撃作戦
　リクエストをしておいて、ノードBに指定されたら、中止をする。
　ノードCに指定されたらノードAに異常データを返す。
　これによってノードBが異常ノードと識別され転送を妨害することができる。

　上記DOMノードは、貰うまではヘコヘコしているのに手に入ると居直るパターン。
＃対象ノード数が少なければ、「まぁいいけど」ですむとも言える。

　上記攻撃ノードは、実質1つのノードでポートを複数用意し、すべてのポートが別ノードにリクエストを
掛けるように仕込むことによって、かなり大規模な攻撃を可能とすることができる。
　単純にIPアドレスでポートをくくりノードを特定する方法はFWやNATを越えられないのでP2Pとしては
今ひとつな構造といえるでしょう。

　もちろん、どちらのタイプも全体に対する絶対量が少なければネットワークは維持できます。
72 ：52：03/06/20 08:49 ID:gLRzIDOG
寝て起きて少し考えました。52の案は指摘されているように複雑な所、複雑な割に効果が少なそうな所が駄目っぽいですね。

もう少し単純なノードの評価方法を考えてみました。nyではクラスタ化によって、ある程度のカタマリが形成されますよね。
なので・・・各ノードの行動（UL／DL）がクラスタ内で記憶されるようにして、その足跡を見てノードを評価するするという感じの案です。
-----------------------------------
まず、各ノードは自分と関わりを持ったノードについて、
●お世話した（UP先）ノード
●お世話になった（DL元）ノード
程度の情報を覚えておく事とします。各ノードが覚えておく情報は単純で軽い（１つのノードが情報を捏造しても影響が少ない）ほうが良いので上の２つ程度が適当かと思います。

つぎに、あるノードからDL要求が来た場合に近隣ノードへ「そのノードを知っているか？」を問い合わせます。
問い合わせは伝播（DL要求ノードを除く）していき、知っているノードがそれぞれ問い合わせ元へ応答するという感じです。

　 　 　　　　　　　　　　　　　　　　隣 　 ｜　 　 　　　　　　　　　　　　　　　　隣
　 　 　　　　　　　　　　　　　隣＜ 　　　｜　 　 　←─ 応 答 ─── 隣
　■─問い合わせ→ 隣＜　　　隣 　 ｜　■←─ 応 答 ── 隣 　 　 　隣
　↑ 　　　　　　　　　　　　　隣＜ 　　　｜　｜ 　←─ 応 答 ─── 隣
DL要求 　 　 　 　 　 　 　　　　　隣　　｜　｜ 　 　 　 　 　 　 　 　 　 　 　 隣
　｜ 　 　 　 　　　　　　　　　　　　　　　｜　↓
　□ 　 　 　 　　　　　　　　　　　　　　　｜　■

近隣ノードからの応答を待ちつつ、とりあえず評価値ゼロのノードとしてULを開始。
近隣ノードから応答が来た場合はそれを見て評価値を増減（DLばかりしているノードはマイナス評価とか）させます。
問い合わせはDLが継続する間、たまーに行ってその都度値を修正。

どの程度の数の応答を持って評価値を増減させるのか、評価値ゼロの時点ではどの程度DLできるようにバランスさせるか、など調整が難しそうですが・・・・どうでしょう？
73 ：login:Penguin：03/06/20 08:58 ID:F2cdAxV/
>>72
出来の悪いﾙｰﾀの様なｼｽﾃﾑだな
練ればかなり面白そうだ
74 ：login:Penguin：03/06/20 18:04 ID:Ba7cbsLM
俺は、535氏が最初に言ってたWWWベースのファイル共有ソフトってのが
楽しみなんだが。47氏が通信部分を作ってくれてWinny完全互換だったらかなりｲｲと思いまつ。
75 ：login:Penguin：03/06/20 19:10 ID:df48QXeq
>>72
>●お世話した（UP先）ノード
>●お世話になった（DL元）ノード
>程度の情報を覚えておく事とします。
この情報としてIPアドレスは使えませんよね
となるとWinnyと違いIDのようなものが必要になりますが

UP元ノードを特定しやすくなったり
優良ノードのIDを捏造される可能性がありますね

しかし非常に面白いシステムだと思います
76 ：login:Penguin：03/06/20 21:58 ID:TDKoiyll
>>75
IPでいいんじゃないすか？
UP元が分かっても自分の意志でUPしてるのか転送なのかキャッシュなのか分からないし。
77 ：login:Penguin：03/06/20 22:04 ID:pAxCdI+v
優良ノードの捏造対策には、公開鍵認証を使うというのが良いと思う。

相手の公開鍵に自分の鍵で署名したのを、評価情報としてネットに流す。
評価は各自ノードにキャッシュされていく。

ダウンする側は、ちまたでの自分の評価を検証してもらうために、相手に公開鍵を渡す。
アップする側は、第三者に相手の評価を問い合わせて、ダウン速度を変えたりする。
評価のキャッシュをたくさん持っている人にも、インセンティブを与えてあげる。

自画自賛のニセ評価が流れるという問題はあり。
何人かを「神」として認証局を作り、そこを信頼するというのも手ではあるが、個人的には面白くないな。

78 ：login:Penguin：03/06/20 22:05 ID:4qswm/8t
>>76
（　´,_ゝ`）ｱﾌｫ？
79 ：login:Penguin：03/06/20 22:13 ID:TDKoiyll
>>78
何かおかしいところがあったら具体的に指摘してください。
80 ：login:Penguin：03/06/20 22:19 ID:4qswm/8t
>>79
固定でもない限りIPアドレスは変わるんだが。
これでいいか？

（　´,_ゝ`）だから何とかはなしな
81 ：login:Penguin：03/06/20 23:28 ID:TDKoiyll
評価情報を永久に保存するシステムなんですか？
一定時間以上立った情報は捨てて行くものだと思ったのですが。
82 ：login:Penguin：03/06/20 23:35 ID:aGx9wvKJ
>>80
評価情報は検索キーの寿命と
ほぼ等しくするんじゃないの？

そもそも、検索キーの寿命は
そのあたりを考慮して短くして
あるんじゃないのかな？
83 ：login:Penguin：03/06/20 23:55 ID:4qswm/8t
>>81
評価情報は捨てるのではなくてその都度変わっていく方がいいかと。
実装されればの話だけどな。

>>82
>●お世話した（UP先）ノード
>●お世話になった（DL元）ノード
>程度の情報を覚えておく事とします。

短命な情報でいいならどれだけの価値があるんだ？
不利な情報が溜まった時に接続しなおせば良いだけだったら実装する価値はないな。

長期的に個人を特定する為にIDなどを導入したらどうかという話なんだが
そうするとUP元ノードがしやすくなったり
優良ノードのIDを捏造される可能性があるんじゃないかということなんだよ。
そのあたりを理解した上でよい案がないか探しているわけ。

とにかく邪魔になるから案を出すとき以外は引っ込んでいようか。
84 ：login:Penguin：03/06/20 23:59 ID:4qswm/8t
>そうするとUP元ノードがしやすくなったり

修正
>そうするとUP元ノードが特定しやすくなったり
85 ：login:Penguin：03/06/21 00:13 ID:6lCIwQke
>>83
マイナス評価を付けるなんてどこに書いてあるの？
お世話になったら評価するプラス評価システムなら不利な情報が貯まる事はない。
繋ぎ直したらプラス評価がゼロになるから何も得にならない。
86 ：login:Penguin：03/06/21 00:19 ID:JfPoXaTz
>>85
>>72
>近隣ノードから応答が来た場合はそれを見て評価値を増減（DLばかりしているノードはマイナス評価とか）させます。
87 ：login:Penguin：03/06/21 00:25 ID:wI5XQnj0
つか、 ny の DOM って厳密な意味での DOM じゃないんとちゃうのん。
本人は DOM ってるつもりでも、使ってるだけでキャッシュが蓄積され、勝手に知らない人に使われるワケで。

てか DOM 対策だとか、わざわざノードの数減らすようなコトしてる意味が分からん。
88 ：login:Penguin：03/06/21 00:27 ID:6lCIwQke
>>86
だったらマイナス評価はするべきじゃない。
正常なクライアントで繋いでいる限り、時間が経てば勝手にプラス評価が付いて優遇されるようになる。
プラス評価の無いノードの優先度を落とすだけで目的は達成されるはず。
89 ：login:Penguin：03/06/21 00:29 ID:e8S1JIBF
ノードの評価。。。

もしかして、ここはACCSのためのツールを
開発しようっていうスレですか？
90 ：login:Penguin：03/06/21 00:29 ID:wI5XQnj0
いまさりげなく >>89 が良いこと言った。
91 ：login:Penguin：03/06/21 00:33 ID:JfPoXaTz
>>88
オープン化されたソースになった時に
正常なクライアントだけならいいけどな。

少しだけで良いから過去ログよめよ。
92 ：login:Penguin：03/06/21 00:48 ID:6lCIwQke
>>91
複数の不正なクライアントでプラス評価を付けあう可能性はあるが、
それは第三者による評価システムを使う時点で絶対に避けられない問題。
ネットワーク全体で正常なノードが多数を占めているなら問題は表面化しない。
不正なノードの割合が一定以下なら成り立つシステムを考えてるんじゃないの？

ごく僅かでも不正なノードが混じる事を心配してるなら評価システムを検討する意味がない。
93 ：login:Penguin：03/06/21 01:02 ID:JfPoXaTz
>>92
それはそうなんだが不正なノードを評価するシステムを
検討する必要があるのはここがオープンソース化の話だからでしょう。
そういう話じゃなくてどうするかを考えようか。
94 ：login:Penguin：03/06/21 01:12 ID:e8S1JIBF
議論に水を差すようで悪いが、オープンソース化を
前提にした話として、各ノードの匿名性なども重視する
必要のあるP2Pファイル共有ツールで、あるノードが
DOMであるとか、ネットに積極的に貢献してるとか、
そのような評価を「他のノード」から可能にしようってこと
自体が間違ってると思う。
95 ：login:Penguin：03/06/21 01:30 ID:iD3sRfOi
>94 なるほど。根本的な発想を変えなければいけないのかも。

ところで、優良ノードの条件として、「キャッシュを多く持っている」
だけが評価されていたけど、「帯域が広い」も条件に上げていいんじゃ
ないかな。

キャッシュを提供できないノードは帯域を提供する、とか。
proxyとして働いてもらえるノードも優良ノードと。
96 ：login:Penguin：03/06/21 01:35 ID:wsRCK5Ki
とりあえずさ、マイナスな意見を言うのは待とうよ

色んな案をだしまくってから良いとこ取りをしないかい？
97 ：login:Penguin：03/06/21 01:37 ID:JfPoXaTz
それじゃとりあえずDOMの話はおいといてオープンソース化した上で
どういう風に匿名性を高めるかの方を問題にするということでいいのかな。
98 ：login:Penguin：03/06/21 02:20 ID:wsRCK5Ki
賛同してくれた方がいたのでとりあえず匿名性について相談しましょ。
まぁノード名の持ち方の話になるとDOMの話によってしまいそうなのが心配ですな

自分の持っているデータをどうやって相手に渡すのが良いか考えますか。

とりあえず暗号通信ならsshがありますが、他になんかエレガントな方法ありますか？
99 ：login:Penguin：03/06/21 02:21 ID:7csnPUWe
匿名性は、Winnyの方式で実用上ほぼ問題ない回答が出てると思う。
WinnyをクローズドソースたらしめているのがDOM、捏造対策で、それが解決できれば47氏が
オープンソース化して良いとまでいっているんだから、そっちの話をすすめたいな。
100 ：login:Penguin：03/06/21 02:30 ID:e8S1JIBF
>>99
いや、ちょっと違う。

> 匿名性は、Winnyの方式で実用上ほぼ問題ない回答が出てると思う。

これもクローズドだから実現できてる。オープンにしたら、どうなるかは
誰も検証してない。
101 ：login:Penguin：03/06/21 02:35 ID:e8S1JIBF
つまり、匿名性を考慮せずに、純粋に技術論で
DOM対策を語るのはナンセンスだし、逆に
匿名性を重視するあまり、DOM対策をないがしろに
したら、ファイル共有システムが崩壊する。

たぶん、かなりの発想の転換というか、考え方の
飛躍が必要になると思う。
102 ：login:Penguin：03/06/21 02:41 ID:wsRCK5Ki
>>1で47氏が言っているのは現状のwinnyは
オープンじゃ実現できないって事なんじゃないのかな？

# ただ実現できないのは匿名性なのかDOM対策なのかわかんないけど

>WinnyをクローズドソースたらしめているのがDOM、捏造対策

ノードと通信内容の匿名性がとりあえずの問題って事で
103 ：login:Penguin：03/06/21 02:54 ID:7csnPUWe
>83
>優良ノードのIDを捏造される可能性があるんじゃないかということなんだよ。
>そのあたりを理解した上でよい案がないか探しているわけ。
は >77 の公開鍵案で良いだろ。

ただし >84
>そうするとUP元ノードが特定しやすくなったり
は起こりうるのはたしかにそう。
でも、ノードの存在自体を匿名化するのはWinnyでも実現できていないだろう。
(現状で自分のところに繋げているマシンがどのIPかというのは秘匿しようがない)
Winnyの匿名性はそのノードが何をどれだけUp/Downしたかを知られない、
行きかうファイルの元がどこから来たのか分からないというところにある。

ノードの評価をID付けして行ないつつ、別の部分で匿名性を図ることはできるんじゃないかな。
104 ：login:Penguin：03/06/21 03:19 ID:gAV6oDw2
nyは隣の隣まで、つまりあるノードがネゴかけてきたノードに別のノードを紹介する時が、
ノードの評価が遠くまで届く最大だと思うんだけど、あまり遠くまで情報を飛ばすのは
どうかと思うんだが。よからぬことができそうで怖い。
判断するのは自分自身の情報のみ、ってしとかないとデマがまわった時にネットワークが
混乱しそうなんだが大丈夫かな。
ノードの評価は誰かが評価した内容をみんなで共有するのではなく、ただ唯一信じるのは
自分のみにしたほうがいい気がする。
105 ：login:Penguin：03/06/21 03:42 ID:e8S1JIBF
現在のnyをそのままオープンソース化したら、ノードの
匿名性などが大きく損なわれる例。

検索キーの伝播だけど、途中のノードでIPの書き換えが
ある一定の比率（かなり低いらしい）で行われてるらしい。
つまり、書き換えた場合には中継が発生し、匿名性を
高めてるわけだ。

ところが、さまざまなノードに検索リンクを張って特定の
検索キーを集め、書かれてるIPを検査すると、容易に
UP元を特定できる。

また、DOM対策と関係するが、IPを 書き換えないバージョンを
作って、自ノードは中継を完全に拒否することができる。
（UPだけしたいとか）

たぶん、検索キーの配布や中継の仕組みなど、根本的な
部分から見直す必要が出てきそうだ。
106 ：login:Penguin：03/06/21 04:49 ID:488Y7y4V
　極端な話とすればWinnyをDOMツール化することは３バイトもしくは５バイトのの書き換えと数１０バイトの
追加コードで完全とはいえないまでも実現可能です。

　ＴＣＰ/IPなど、インターネットの機能を使う限り、実際の転送を行っているもノード同士に関しては
匿名性などは存在しえません。匿名性と汎用性を実現するためにノード間の転送機能が使えます。

　ノード間転送機能は、NATやFWの影に入っているノードであってもP2Pに参加できるというメリットを
もたらし、すべてのインターネットにつながっているコンピュータがP2Pのネットワークに参加できるという
メリットをもたらします。効率が悪いなどの理由によってPort0を禁止しようなどという考え方はP2Pの
基本的な思想に似合わないものであり、Port0同士の(直接的ではないにせよ)通信ができないものも
P2Pシステムとしては不十分なものであると考えられます。

　ノード間転送機能によってもたらす匿名性について述べるなら、ソースが誰であるかを特定できない点に
つきます。各ノードにスキャンを掛けることによって、そのノードが保持しているキーのリストを収集できる
かもしれないが、実際にデータのソースとなった者の特定は困難とすることが可能です。もし、各ノードの
責任を分担する必要を考えるならば、各ノードは部分としては意味を持たない断片を持ちながら全体に
貢献する行動をするように変更しなければならない。

　とりあえず、言うまでも無いかもしれないが、基本手な考え方を表明として記述します。
107 ：login:Penguin：03/06/21 05:16 ID:gAV6oDw2
>>105
あるファイルを、(自分が要求したのか、転送なのかを明らかにせず)強制使いっ走りさせて、
中継をさせるとどうだろう。ｎｙでのBBS読み書き要求のように。
一部分でも、誰かが完生体を持っている限り、元Upファイルキャッシュと同等に振舞うのであれば
かなり撹乱されるのでは。
108 ：login:Penguin：03/06/21 06:46 ID:xvZrH5JD
>>105
>たぶん、検索キーの配布や中継の仕組みなど、根本的な
>部分から見直す必要が出てきそうだ。
他にも案はありますし、当面その必要はないでしょう
すぐに白紙にして考えようとするのは良くないと思いますよ

そもそも>>1の発言はDOM対策について議論している時のものですから
まずはシステム上で匿名性を保ったDOM対策が出来る数少ない案を
徹底的に検討することが必要かと
109 ：login:Penguin：03/06/21 07:08 ID:ry5P9A0d
>>92以前の議論をまとめると。
>>72
>●お世話した（UP先）ノード
>●お世話になった（DL元）ノード
>程度の情報を覚えておく事とします。
この情報にIPアドレスを使用しても問題なさそうだね。

>>93以降はあらぬ方向に話がズレているようだけれど・・・。
110 ：login:Penguin：03/06/21 08:11 ID:zrHuDJse
>>72を基本に話が進んでいる中悪いがもう一度>>52を見直して欲しい
Ａ■─┬
　↑ 　↓
　｜ Ｂ■─┬
　｜　　 　　↓
　└───■Ｃ
この図で言えばBの評価はCの実績を元にAがリアルタイムで行う、つまりBには
自身の評価を操作することがほぼできない、というところが秀逸だと思う。事実上
Bは素直に中継を受け持つのが一番楽になるはず。
それが>72ではDL要求元が捏造でもなんでもとにかくファイルをUPすることで
自身の評価を操作できてしまう。またUP元の情報をばら撒くということはUP元の
情報を抽出することもできてしまう。特にこの点で俺は>72を推せない。

また、前スレでは中継を挟むのがデフォのように語られていたけど、中継発生率を30%
程度まで上げれば多段転送の可能性も上がり、違法性推定の困難さは維持できる(※1)
と思われる。>>55>>58の通知経路も、多段転送が結構な確率であるならBを使っても
問題は無いだろう。

その上で、ノード評価にはUL実績ではなく中継実績を使う。中継発生しないように改造
した場合それは自分の首を締める事になる上、評価は他者(例ではAとC)が行うため
Bには自分の評価を操作できない。評価による制限で良いバランスが取れれば、悪質
ノードは自然と減るのではなかおるか。

※1オープンソース化するとキャッシュドライブ内表示ツールは確実に作られるし、
その機能を持ったLinnyが主流になるかもしれない。そうすると管理責任が問題に
なるだろう、が、それでも”リアルタイムの”キャッシュドライブの管理責任まで問う
のは(プロクシの例を出すまでも無く)難しいだろう。それはつまり…ｺﾞﾆｮｺﾞﾆｮ。
111 ：105：03/06/21 09:59 ID:e8S1JIBF
>>105のレスは、>>99の
> 匿名性は、Winnyの方式で実用上ほぼ問題ない回答が出てると思う。
という発言に対する疑問を1例を上げて示したものだ。

>>106 > 基本手な考え方を表明として記述します。

nyの匿名性については、(1)転送されてきたデータがUPフォルダにあるのか
キャッシュ・フォルダにあるのか分からない、(2)間に中継を挟んだ転送かも
しれない、という2点に尽きる。

>>105は、このうちの後者について例だ。

検索キー伝播途中でのIPの付け替えによってファイル転送時に中継が
挟まれるわけだけど、無制限にIPの書き換えが行われるわけではなく、
必ずIP書き換え回数（中継段数）を制限するためのチェックが行われてる
はずだ。想像だけど、検索キーの中にIP情報とともに、書き換え回数が
書かれているはずだ。ということは、オープンソース化すると、上の後者の
匿名性は完全に崩れる可能性がある。

たぶん、オープンソース化によって、基本部分の大きな修正が要求される
ような気がする。このあたりを抑えてないと、単なる机上の空論に終わりそうだ。

また、匿名性などの話をすると、なぜかDOM対策だけに話を絞りたいという
方向修正のレスが登場するが。。。何か特別な意図があるのかな？
もしかしてACCSの回し者？(ry

冗談はさておき、すぐに方法を考えるのもいいけど、まず、オープンソース化
によって発生するであろう問題点を可能な限り出して、その後で、それぞれの
解決策を考えるのが道筋じゃないだろうか？

ハッキリ言って、DOM対策は解決が難しい問題だけど、問題自体としては
二次的なものだ。
112 ：login:Penguin：03/06/21 10:38 ID:zrHuDJse
>>111
>必ずIP書き換え回数（中継段数）を制限するためのチェックが行われてる
>はずだ。想像だけど、検索キーの中にIP情報とともに、書き換え回数が
>書かれているはずだ。
～はずだ。てあんた(ｗ
キー寿命が切れるまでに渡り歩くノード数(ホップ数)と、書き換え率(プッシュ率)
の低さを工夫すればそんな無駄なカウントはつける必要はないだろ。47氏も
多重転送が起こる確率はわからない、けど0ではない、って言ってたぞ。

匿名性とDOM、オープンソース化の問題は、一つづつならけっこう容易に解決
できるけど一度に全部解決するのが難しいわけで、やっぱり並行して話を進め
ていくのがいいんでない？
オープンソース化による問題の洗い出しは良いと思うけど。(がんがれよ>>
113 ：login:Penguin：03/06/21 11:28 ID:sJlq9whA
>>111

＞ハッキリ言って、DOM対策は解決が難しい問題だけど、問題自体としては
＞二次的なものだ。

　転送によって作成されるキャッシュによって、ファイルの拡散が拡散され
効率の良い転送が行われるということを期待している。
　また、拡散によって投入したノードの特定も困難になる。

　DOM対策をしないとDOMクライアントが蔓延し実質的にサーバークライアント
に戻ってしまい、また情報提供者の匿名性にも問題が発生する。

　ということで、DOMは不公平だとかいう問題ではなく、
ネットワークの維持と効率性と匿名性の実現のためにも
DOM対策は必要であると思います。

　まぁ、DOM対策というのが表現としてよろしくないとすれば
「不正ノード対策」でも良いのですけど。

　逆に正規のノードとしての機能を突き詰めてみてはいかがでしょうか
114 ：login:Penguin：03/06/21 13:21 ID:JfPoXaTz
>>106
中継する事のリスク低減とファイル自体の匿名化を考えてみた。
あるファイルを持っている者にそれが欲しいとDL要求が到着した後の
流れを匿名化する案なのだが下の例を見てもらいたい。


DL要求が届いたノードはまずそのファイルを断片化して複数のノードにファイルの一部分だけを転送する。

UP元　　　　　　■　　　　それぞれのノードへはファイルの断片しか渡さない
　　　　　　┌─┬─┐　
　　　　　　□　 □　 □　その後は通常のWinnyと同じ過程をへてDL要求を出した者へ伝わる
　　　　　　↓　 ↓ 　↓
　　　　　　└─┼─┘
DL元　　　　　　■　　　　DL要求者はいくつかの断片を別々に受け取り復元する


　更に強固にファイルの匿名化
１：ファイルを断片化する時にそれぞれを暗号化し鍵をかける。
２：それぞれの断片はそれだけでは復元不可能とする。
３：全ての断片が一体化した場合には鍵を使って復元可能とする。

　匿名性の要点
１：元のファイルの持ち主は誰にも完全なファイルを渡していない。
２：中継した者には意味不明なファイルであり復元も不可能。
３：受け取った者も直前の転送者それぞれからは完全なファイルを受け取っていない。
４：受け取った者に直前の転送者のIPがわかってもそれぞれの違法性を問う事は困難。
115 ：login:Penguin：03/06/21 14:02 ID:SbK/XQBP
>>111
>ハッキリ言って、DOM対策は解決が難しい問題だけど、問題自体としては
>二次的なものだ。
一次的ですよ
現状のWinnyをそのままオープンソースにしてもある程度の匿名性は保たれます
しかしDOMは一気に拡散してネットワークを食い潰し崩壊してしまう

>冗談はさておき、すぐに方法を考えるのもいいけど、まず、オープンソース化
>によって発生するであろう問題点を可能な限り出して、その後で、それぞれの
>解決策を考えるのが道筋じゃないだろうか？
すぐ方法を考えてもいいですよね
今は２スレも前から出ている問題点である、DOMの解決策を考えているところです
問題点を出すのはいいと思いますが、匿名性の一方方向に流れを変える必要なないでしょう

思考材料となるレス自体が多くありませんから
完全平行してもいいと思いますけどね
116 ：login:Penguin：03/06/21 14:17 ID:7csnPUWe
>114
ほとんどfreenetに近いという罠。実は俺はあの考え方は好きだ。

あれは匿名性としては良かったと思うが普及しなかった。
1.全然ファイルがヒットしない。
2.転送効率が悪い。
3.各ノードはなんだか分からないキャッシュを抱えこまないとならない。
など、導入に抵抗が大きかったのがあると思う。
この問題はWinnyが今のようにメジャーになるために通ってきた道でもある。

1,2の欠点はノードが充分にあれば、使えるようになっていくはず。
freenetの失敗は3に抵抗感があるから、1,2が解決しないという悪循環が原因でないかと俺は思ってる。
なら、3のキャッシュを持たせるためのインセンティブを与えてやれば良い。
117 ：login:Penguin：03/06/21 14:34 ID:LMV9GHVA
>>116
3を除いた場合
Winnyでも転送リンクが切れて他のノードを経由していれば似たようなことをやってますよ
複数同時ではなく、切れたら他って感じですけどね
あとは効率の問題でどの程度実用的になるかは実装してみるまで分からないかも
現Winnyの転送率などを把握している47氏なら想像は出来ると思いますけどね
118 ：login:Penguin：03/06/21 15:27 ID:x2o3Cy/X
>>110
>その上で、ノード評価にはUL実績ではなく中継実績を使う。
そもそもDLノードからは中継かそうでないか判断出来ないんで
単純に「DLさせてくれたノード」と評価するしかないと思います
あとはファイルの中身を判断して評価を取り消したりですかね

どうでもいいけどLinnyはもう終わってます(w
119 ：login:Penguin：03/06/21 15:38 ID:onklUT8r
Linnyｽﾚが1000逝ったらこちらに統合させてください。
120 ：login:Penguin：03/06/21 15:46 ID:x2o3Cy/X
>>80
ルーター無しで繋いでいるなどIPアドレスが頻繁に変わる場合や
どうしてもノード評価を維持したい場合にはDDNSを使えます

初心者には不向きですし、P2PNWとして根本的な解決策ではありませんが一つの方法です
121 ：login:Penguin：03/06/21 15:57 ID:6abN2ckM
>>119
統合というかあれとこれは別の目的を持ったスレだから、
移りたい人だけこっちに移れば、自然とあっちは消滅でしょうけど。
535氏とLinnyなんてのはネタ以外の何物でもないw
47氏とWinnyこそ考えるべきもの。

ｺﾞﾐﾚｽ失礼しました。
122 ：login:Penguin：03/06/21 16:10 ID:idEqaXxw
ほんとｺﾞﾐﾚｽだな
自覚してるなら書き込まなければいいのに
123 ：login:Penguin：03/06/21 16:44 ID:zTC2nHLg
>>81
一定時間ノードを発見できない場合に、
評価をクリアするってことでいいんじゃないかな。
IPアドレスが変わっては当然接続出来なくなるし、
逆に常時接続しUPしてる優良ノードは優遇する必要がある。
124 ：login:Penguin：03/06/21 17:59 ID:zTC2nHLg
>>88
>だったらマイナス評価はするべきじゃない。
マイナス評価もするべきだと思う。
そのときにプラスとマイナスの評価値を転送量からみて2：1程度差をつける必要がある。

1.ダウンしかしないノード
2.ダウンもしているがアップも同等にしているノード
3.ダウンは滅多にしないがアップは十分しているノード

ネットワーク上のノードを大きくこの三つに分けた場合、
1はどんどんマイナス評価が高くなるので繋ぎ直す必要があり
悪意の少ない者への抑止力になる、マイナス評価の高いノードはUP元が接続拒否してもいい。

2は転送量が多くなればなるほど評価が上がっていくので、
ネットワークに繋ぎ始めの評価値のないノードと区別出来る。

3のように本当に欲しいものだけを落としているノード等は十分に評価され、
実際にダウンを要求するときに効率がいい。
125 ：login:Penguin：03/06/21 19:25 ID:6lCIwQke
>>124
繋ぎ直す程度でマイナス評価が消えるような欠陥システムは採用するべきじゃないって言ってるんだが。
126 ：login:Penguin：03/06/21 19:28 ID:JfPoXaTz
大前提ですが。

Winnyは最終的に１対１でファイル交換を行うUPとDLだけのファイル交換ソフトではない。
高速性と匿名性のを兼ね備えたファイル共有ソフトで、UPする物がない新規参加者でも
欲しいファイルが落ちてくるし、落としている最中でもDL要求が来れば別ノードへそのファイルが転送されていく。

現在のクローズドソースのWinnyはDOMだけという概念は存在せず
立ち上げて接続しているだけで全てのノードの検索と転送に協力していることになる。

オープンソース化された時にUPや転送をしないように改造して
DLだけしようとする者が出る事は確かに予想されるが
UP量の多いノードを優遇しようとするあまりノードの特定化を進めすぎると
Winnyのネットワークをよく思わない人達からそのノードが真っ先に目を付けられることになる。
これはMXの例からも明らか。

そこで基本設計の考え方を進めるには不正ノードの排除と同等かそれ以上に匿名化を重視していく事が
Winnyをオープンソース化を考える上で外せない事項であると思われる。


>>116
>3.各ノードはなんだか分からないキャッシュを抱えこまないとならない。
なんだかわからないから転送によるリスクを減らせるのですが
それを数多く持っている事にインセンティブを与えてやるという案も面白そうですね。
127 ：login:Penguin：03/06/21 19:39 ID:fRd6VaIx
>>125
>繋ぎ直す程度で
繋ぎ直すことはかなりの抑止力になると思います。
繋ぎ直すためにはどうしても一度転送を切断しなければなりません
また大きな悪意をもってツールでも使っていれば別ですが、
ほとんどの利用者にとって面倒なことです。

それと繋ぎ直せばプラス評価も消えますが、
これは>>124の2と3を区別するのに有効です
理想は3のようなノードだけで構成されることですが、
無意味に地引する人も多く、そうはならないので、
出来るだけ3を優遇する必要があります。
128 ：login:Penguin：03/06/21 20:05 ID:fRd6VaIx
>>126
不正ノードの排除出来ないシステムが成り立たないことも大前提です。

言い分は分かりますが匿名性を保ったまま
不正ノードを排除出来る方法が潤沢に出てきていない以上、
現在のアイディアを限界まで詰めていくしかないんですから。
129 ：login:Penguin：03/06/21 20:23 ID:Z5YioSBn
Linnyスレからリアルタイムで見ていた者と
47氏降臨後からこぞって流れてきたWinny本スレ住人では
ずいぶん意識の違いがあるようだね
130 ：login:Penguin：03/06/21 20:46 ID:6lCIwQke
>>127
自分で言ってる事を理解してますか？

マイナス評価システムを導入したと仮定して、
何故DOMがわざわざ繋ぎ直すか考えて見れ。
普通に落としてるうちは繋ぎ直す必要はない。
落ちてこなくなったら繋ぎ直してマイナス評価をクリアする。

＞繋ぎ直すためにはどうしても一度転送を切断しなければなりません

だからこんな事は起こりません。
繋ぎ直す時には既に落ちてこなくなってる。
131 ：login:Penguin：03/06/21 21:06 ID:qbyBI6PA
完全ｵｰﾌﾟﾝｿｰｽは理想だけどそれにこだわらんでもええんちゃうのん？
132 ：login:Penguin：03/06/21 21:24 ID:N2ShZ/c2
>>131
普段は決して関わることのできないｵﾌﾟｿﾌﾟﾛｼﾞｪｸﾄに
参加しているという幻想を抱けるんだからそりゃこだわりたくもなるだろう。
という彼らの心情を汲んであげなよ。
133 ：login:Penguin：03/06/21 21:25 ID:OV35jTjl
>>130
もう少し冷静になって下さいね。

>＞繋ぎ直すためにはどうしても一度転送を切断しなければなりません
>だからこんな事は起こりません。
>繋ぎ直す時には既に落ちてこなくなってる。
この部分以外は納得してもらえたようですが、
マイナス評価をすることの利点を
一つでも多く理解してもらいたいので説明します。

>繋ぎ直す時には既に落ちてこなくなってる。
ダウン転送量に応じてマイナス評価（制限）が与えられるわけですから、
全くアップも転送もしていないノードの場合本当に
接続拒否をされる(実装次第ですが)までは序々に落ちてこなくなるわけです。

目的のファイルを一ずつゆっくりと落としていくなら別ですが
一般的な用語で地引などをしてる場合、または多数のハッシュ指定をしている場合など
全てのダウンリンクが完全に切れてしまうことは少ないです。

よって帯域制限が厳しくなった時には、落としきれなかったダウンリンクを切断することが十分考えられます。

また評価を厳しくすればたった一つのファイルすら落させずに再接続を要求できます。

この辺りはバランス次第ですが、キャッシュを溜めて帯域を確保していれば
制限を受けることはないので問題ないはずです。
134 ：login:Penguin：03/06/21 21:30 ID:LB78JCLg
>>131
>完全ｵｰﾌﾟﾝｿｰｽは理想だけどそれにこだわらんでもええんちゃうのん？
完全オープンじゃないってことは誰か一人がクローズドな部分を作るってことだよ
47氏が時間無いって言ってる今、誰が作るの？

135 ：login:Penguin：03/06/21 21:40 ID:qbyBI6PA
>>134
47氏は全て一人でやってるから時間がないんでない？
GUI周りとか特に影響がない部分だけでもｵｰﾌﾟﾝにできればだいぶ違うと思うんやけどね

でもこれ以上はスレ違いかもって気がしてこないでもしたりしなかったり、、、
136 ：login:Penguin：03/06/21 21:56 ID:e8S1JIBF
>>112
なるほど、ご指摘ありがとう。

本スレで以前、中継は必ず1段以下で、発生の比率は
かなり低いと誰かが発言してから、てっきりIP書き換え
回数をチェックしてるのだと思い込んでた。

でも、そこまで断言てるんだから、>>112さんは47氏
ということでいいですね。
137 ：login:Penguin：03/06/21 21:59 ID:LB78JCLg
>>135
理由は他にもあるから関連スレでも見てきてね
138 ：login:Penguin：03/06/21 22:03 ID:e8S1JIBF
ところで、DOM対策と同じように考慮する必要があるのが
途中のノードによる検索キー情報の捏造／改ざんだ。

たとえば、ファイル名やハッシュを悪意でを改ざんする
ことが考えられるな。

また、IP情報を「京都府警ハイテク犯罪対策室」のIPにすり替え
たりするイタズラが横行しそうだ。

これは捏造ファイルなどの比じゃなく、P2Pネットを崩壊させる
だけの危険性がある。
139 ：login:Penguin：03/06/21 22:08 ID:cVEhdV4A
>>136
今のWinnyがどちらの実装方法だったとしても、
>>112さんが47氏ではなくても構わないでしょう。
要は>>111で指摘されている匿名性の問題が>>112の方法で解決可能なんだから。
140 ：login:Penguin：03/06/21 22:12 ID:cVEhdV4A
>また、IP情報を「京都府警ハイテク犯罪対策室」のIPにすり替え
>たりするイタズラが横行しそうだ。
しないだろ(w

Winnyにも初期ノード情報に登録するっていたずらはあったけど横行はしなかったぞ(w
141 ：login:Penguin：03/06/21 22:32 ID:KdeXiLMg
>>138 >>140
キー情報中の IP アドレスが捏造でも、
その IP アドレスからファイルを落とせないだけ。

アップ側がハッシュを書き換えても、
ダウン側でブロックごとにハッシュチェックを行うので、
ダウン側に完全な捏造を掴ませるのは難しい。

キャッシュからダウンロード済みファイルに変換するときにも
ハッシュチェックを行うので、「誕生日攻撃」などがあっても
捏造を掴まされる確率はさらに低くなる。

ファイル名の改ざんについては、
今の Winny でも完全な対応は出来ていない。
ハッシュが一致した正しいファイルではあるので、
自分でリネームすることが対応策かなあ。
142 ：110：03/06/21 23:57 ID:zrHuDJse
>>118
評価するのはULノードであり、また、中継込UL(A→B→C)は、C→Aの
CRCチェック(仮)が行われるため直接UL(A→B)と区別できる。
中継込ULをしているノードBは直接DLする時優先する、というのはでき
ないかね？そういやもうLinnyの話ではなかったねw ｽﾏｿ

>>114
キャッシュフォルダ内の改竄を防ぐ良い方法をみつけられたらこっちの
方がスマートだね。色々工夫できそうなのも>>114だな……むう。

>>136
言い切ってしまったのは悪かったよ。
143 ：login:Penguin：03/06/22 00:07 ID:hEvv6EaI
>>142
>>114は単に効率を下げて匿名性を上げたっていうものですよ。
不正ノード対策には何の役にも立ちませんし、関連スレの方で既出です。

今は議論するには値しないものだと思いますが・・・。
144 ：login:Penguin：03/06/22 00:14 ID:gFCzUpdj
>>143
議論に値しないのはDOM対策でしょう。
こんな見当違いな部分にに固執しているおかげで
>-------------------- HO0OFh2RXI 氏による最初の発言 --------------------
>03/04/30 23:19
からもう二ヶ月になろうとしてるのにほとんど何も決まっていないですね。
145 ：login:Penguin：03/06/22 00:20 ID:D5w57dRG
>>144
だからここはLinnyスレじゃないんだって。
始まったのは47氏が発言した03/06/19 08:50から

まだ三日しか経っていないにもかかわらず、
既に三つのアイディアが生まれた。
146 ：login:Penguin：03/06/22 00:32 ID:b+/XnSvp
>>144
まだ何かを決める段階じゃないし
今はいいアイディアが出てきたからそれを練っているところ

やっぱり安心して議論出来るのはアイディアを
47氏が実装してくれる可能性があるからかな

実装までは無理だとしてもWinnyのソースを公開してくれれば
こちら側での実装が極めて楽になる
147 ：login:Penguin：03/06/22 00:33 ID:H5zMraLm
>>138
これは厳しいなあ。イタズラIPの方はキーにはIPの下半分しか書かずに、
ノードバッファの中から一致するのがあればそこにDL要求するようにすれば
なんとか。最大1000/65536だから重複でエラー出す確率は…微妙かもｗ
ハッシュ、ファイル名改竄の方は防ぐ方法を思いつかない。

>>143
>キャッシュフォルダ内の改竄を防ぐ良い方法をみつけられたら
という条件付です。
キャッシュフォルダには自分がDLしたファイルと中継で貯まったファイル
のみを置き、UPファイルをキャッシュ化したものは別のフォルダに保存。
で、キャッシュフォルダの容量で優先/制限をつける。キャッシュは今の
Winnyみたいにわかりやすいｗ ヘッダにしなければ改竄、水増しはある
程度防げるはず…だけど、オープンソースにするということはそれを止め
られないということでもあるわけで。
だから改竄を防ぐ良い方法が見つかればなあ、と。
148 ：login:Penguin：03/06/22 00:47 ID:U/zTl1Uv
>>147
>で、キャッシュフォルダの容量で優先/制限をつける。
これは自ノードからの情報となるからいくらでも捏造が可能では。
肝心のインセンティブにはならない。
キャッシュの暗号化にしてもご指摘されている通り。

オープンソースで考えれば問題だらけだと思います、既出なんですが。
149 ：login:Penguin：03/06/22 00:51 ID:MuGfQStf
>>72に関しては一度実装して実験したいくらいに練れてきましたね。
150 ：login:Penguin：03/06/22 00:57 ID:g9C0juo7
思うのだけど、藻前らは Yet Another Winny を作ろうとしているの?
それとも、Winny に contribute して、そのままクローズド化されてパクられたいの?
151 ：login:Penguin：03/06/22 01:06 ID:6bPXKzbs
>>150
ここは「Winnyのオープンソース化を考えるスレ」です
152 ：login:Penguin：03/06/22 01:09 ID:g9C0juo7
だよな。ここでいくら議論したところでmuda(ry
153 ：login:Penguin：03/06/22 01:20 ID:q5bBg9mg
そうそう、ここは考えるスレだから変に気負わなくていいんだよ。

考えたい人が考えればいい、何処にでもあるスレだね。
154 ：login:Penguin：03/06/22 02:03 ID:dw1U6vCL
>>72
これに関してだけど、ノードがネットワークに存在することが保証されてしまう。
ｎｙであればネゴしてみないと本当に正しいかわからないという、ある種の匿名性が
あるんだけれど。(あの調査はどうやってしたのかは実際不思議･･･)

>>138
IP書き換えは洒落にならないほどやばいと思われますがどうでしょう。
来たキーを転送で書き換えるのと同じように、100%でどこそこのIPに
書き換えられると、ネットワークに参加するノードのかなりの部分が
丸裸にされる恐れが。
155 ：login:Penguin：03/06/22 02:25 ID:q5bBg9mg
>>142
>中継込ULをしているノードBは直接DLする時優先する、というのはでき
>ないかね？
この中継込UL(A→B→C)というのは全体として信頼性が高いので
Bに限らずA、B、C)が互いにプラス評価をして、
効率の良い直接UL(A→B)が出来るようにするというのもいいかもしれませんね。

逆に言えば一度も中継込UL(A→B→C)をしていなければ直接転送は出来ないという方法です。

例えば一定時間以上中継転送をしたノードのIPアドレスを記憶しておいて、
転送リンクが切れたあともお互いに認証を行い、許可し合えば直接転送が可能になる。
これは>>72と違い自ノードの情報だけを元に認証を行いますから匿名性も多少は高いのではないでしょうか。

また一度中継すればダウンし放題では困るので優待ノードの接続回数を制限したり
ノードCを優待するのを抑えたりするなどの方法も必要かと思います

まだ詰めれる所は多そうですね。
156 ：login:Penguin：03/06/22 15:28 ID:w/Feg9gP
>>154
>>72
>これに関してだけど、ノードがネットワークに存在することが保証されてしまう。
保証されてしまう理由は何ですか？

>来たキーを転送で書き換えるのと同じように、100%でどこそこのIPに
>書き換えられると、ネットワークに参加するノードのかなりの部分が
>丸裸にされる恐れが。
その根拠は何ですか？
157 ：login:Penguin：03/06/22 16:05 ID:S9apVEtr
>>155
直接転送しあったら効率は最大になるが匿名性は何もないな。
158 ：login:Penguin：03/06/22 16:13 ID:yPqcY7My
>>157
先に>>110を見てもらえましたか？

この場合の直接転送とはCRCチェック(仮)の行われない転送ということです。

よってBが現在のWinnyにある中継の役であっても構いません。
159 ：login:Penguin：03/06/22 16:30 ID:S9apVEtr
その後ノードBが直接DLする時優先するって事ではないの？
それだったら直接転送した時点で匿名性はないよ。
160 ：login:Penguin：03/06/22 17:23 ID:yPqcY7My
>>159
表現が悪かったですね、すみません。


通常は中継込UL、データは(A→B→C)、CRCは(C→A)を行います。

ノードBがダウンしかしない、という不正が出来ないようにするものです。
(CがCRCを渡すだけの不正なノードかもしれませんが)

直接転送とはWinnyと同じ(?→?→A→B)の形でA→B部分のことを言ってます。

違いはダウンノードであるBがにデータを送信せず、AからはBが全くアップをしない不正なノードであるか判らない点です。
よって先に信頼性を判断する必要があります。

この場合Aがアップ元ノードである必要はありません。
161 ：login:Penguin：03/06/22 18:19 ID:g9C0juo7
だれか freenet の実装をわかりやすく説明してくれよ。
162 ：login:Penguin：03/06/22 18:27 ID:yPqcY7My
>>161どうぞ
http://linny.sourceforge.jp/wiki/?Freenet
163 ：login:Penguin：03/06/22 18:31 ID:WOgJ9F5E
http://linny.sourceforge.jp/index.html
なんか勝手にここが本スレにされてるよ

http://pc.2ch.net/test/read.cgi/linux/1053087824/935
またやり始めるみたいだからこっちに書き換えとけよ
164 ：login:Penguin：03/06/22 18:34 ID:g9C0juo7
>>162
プロトコルの詳細な説明のページってある？
165 ：login:Penguin：03/06/22 20:06 ID:K99crfwK
お、>>147にさりげなく47氏が降臨してるね
166 ：login:Penguin：03/06/22 20:11 ID:0NO1WE2B
>>165
いや、絶対違うし(w
167 ：login:Penguin：03/06/22 21:10 ID:S9apVEtr
>>160
不正なノードを判別する方法なのはわかるがどの部分に匿名性があるの？

匿名性の持たせ方については>>114で書き込んだんだが
不正ノード対策には何の役にも立たないし議論するには値しないという事なので静観しているんだけど。
168 ：login:Penguin：03/06/22 21:27 ID:0adni7Ua
>>167
Aがアップ元ノードである必要がなく、
中継かUP元かの判別が出来ない点です。
169 ：login:Penguin：03/06/22 21:48 ID:lZt2FUG0
>>167
そんなことでｽﾈて他に当たるなよ

静観してないし(w
170 ：login:Penguin：03/06/22 22:00 ID:S9apVEtr
>>168
元ファイルのUP元の匿名性はあったとしても最後に中継した者の匿名性は薄いと思うけど。
>>169
そういうなよ、ちょっとだけ落ち込んでるだけだから（ｗ
171 ：login:Penguin：03/06/22 22:03 ID:zD85xP7h
>>72
これってクラスタ位置を変えるだけで評価が消えてしまうよね？

なんらかの救済策はないかな
172 ：login:Penguin：03/06/22 22:04 ID:zD85xP7h
>>170
今のWinnyとは変わらないわな、多分
173 ：login:Penguin：03/06/22 22:11 ID:H5zMraLm
>>166に47氏ｷﾀ━(ﾟ∀ﾟ)━ !!!!!……こういうのはともかく(ｗ、、、だ
「匿名性」と「違法性の推定」は文言上でも明確に区別すべきかね。ややこしい。

>>167(=114?)
>114はキャシュ保持の動機付けと、効率化が難しそうですがもう少し詰めても面白そう
だと思います。別に評価の軸を一本に限定する必要はないで寿司。

>>110のは「違法性の推定」対策には中継失敗したDL(今のNYでもULは切れたのに
転送DLは続いていることがよくあるっしょ)もある程度の率であることが必要になるなあ。
174 ：login:Penguin：03/06/22 22:15 ID:zD85xP7h
>>173
違法違法って言ってる香具師がいるけど
違法性を問われることに何か問題あるの？
175 ：login:Penguin：03/06/22 23:57 ID:gFCzUpdj
初期ノードの登録で躓きそうな予感。
176 ：login:Penguin：03/06/23 00:00 ID:JteYKQbA
>>175
なんで？
177 ：login:Penguin：03/06/23 00:34 ID:y/vXpR9g
>>156
評価が返ってくるということはネットワークにいるってことかと思ったんだが
時間差で落ちられてるかもしれないから保証はできないのか。
聞いてみるだけで、あるノードが本当にネットワークに近い最近にいたとが
わかるのはまずくないかなと。

大量にキーをやり取りするノードで、あるログをとっているノード(IPとポートの組)に
書き換えられると、キーが伝播する広さにもよるが、調べられるかと。
特定のキーワードのキーを書き換えることにより、(転送による誤認はあるが)
何を落とそうとしているかまで。
178 ：login:Penguin：03/06/23 00:42 ID:JteYKQbA
>>177
>聞いてみるだけで、あるノードが本当にネットワークに近い最近にいたとが
>わかるのはまずくないかなと。
直接繋ぎにいった方が早いよな

聞けるってことはIPアドレス分かってるんだから
179 ：login:Penguin：03/06/23 00:51 ID:JteYKQbA
>>178
ちゃんと読んでなかったな

近い最近のノードを探すことは余計意味が分からないけど
180 ：login:Penguin：03/06/23 00:59 ID:4aAOAR0g
>>141
>ファイル名の改ざんについては、
>今の Winny でも完全な対応は出来ていない。
>ハッシュが一致した正しいファイルではあるので、
>自分でリネームすることが対応策かなあ。

ハッシュからファイル名を検索できれば
検索リストをみて自分で判断することが可能
181 ： ：03/06/23 01:18 ID:OsfirLd5
>>180
それをやるには、キーをある程度サーバントに貯め込む必要がある。
現在の Winny ではそれはあえてやっていないようだ。
なぜなら、流通しているキーの一覧を作成されてしまうから。

もっとも、その機能を持つ外部ツールがあるし、
オープンソースになったら標準でこの機能を持つクライアントが
配布されると思うけどね。
182 ：login:Penguin：03/06/23 01:32 ID:jcm+36yK
お前らもっとDOM対策について議論しろよ。

なんでWinnyがオープンソースに出来ないか分かってんのか？
183 ：login:Penguin：03/06/23 01:51 ID:negvN1K9
議論が足りないからでしょう。
無理にオープンソース化する必要もないし。
まず案を出せってとこですかね。
184 ：login:Penguin：03/06/23 01:56 ID:2T40n5w+
>>183
オープンソース化する気がないならスレ違い。

47氏が何故オープンソースに出来ないと言っていたか考えろ。
185 ：login:Penguin：03/06/23 02:03 ID:tvgzlMla
オープンソースでDOM対策あるよ？
教えてやらないけどね
186 ：login:Penguin：03/06/23 02:10 ID:2T40n5w+
>>183
こういうスレタイすら分かってないアホがいるから
議論が進まないんだろう。

前々スレから見てきたがDOM対策DOM対策DOM対策ときて
議論が進み始めたところで97の前あたりから
「DOMの話は置いといて」
だと？

そんな深夜に2ch見てる奴なんてそういないんだよ、
無理に話を変えてんじゃねぇっつーの。
187 ：login:Penguin：03/06/23 02:33 ID:a26IWp8t
「DOM 対策」についてですが、必要と思っている人間が対策を考えるべき
であって、開発する連中が「考えてあげる」性質のものではないです。
そもそも、オープソンースni(ry
188 ：login:Penguin：03/06/23 02:37 ID:2T40n5w+
>>187
どうしようもないアホだな。

開発者である47氏がオープンソース化するために必要だと言ってるんだよ。

そんなことも分かってない奴はじっくり過去ログ読み直せ。
189 ：login:Penguin：03/06/23 02:39 ID:a26IWp8t
あれ?
このスレって、Winny 風の中途半端なものを作ってるんじゃなかったの?
47 一人にコーディングを任せようとしている時点で間違ってると思うがね。
190 ：login:Penguin：03/06/23 02:43 ID:y/vXpR9g
>>179
繋がなくても有効であるかが確かめられるな、という意味です。
何に使うかは知りませんが。
191 ：login:Penguin：03/06/23 02:47 ID:2T40n5w+
>>189
それはLinnyとかいうネタのことだろうが。

47氏はオープンソースに出来るメカニズムが導入出来れば、
Winnyに実装してソースを公開し開発を進めてもいいって言ってるんだよ。

>>1くらい読んどけ。
192 ：login:Penguin：03/06/23 02:51 ID:atr4Arx5
>>188
97は94を受けての発言でしょう。

47氏の過去発言は一つしかないわけだが
>もしオープンソースでも問題ないメカニズムが導入できるのなら、
>こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。
問題が解決できないのならソースは公開できないという事なので
問題の解決方法を探ってるのですが。

>だめならソース非公開なままでUNIX版を作るという手もありですが、こちらの時間的余裕の問題で
>オープンにできないのであればUNIX版ができることは無いと思います。

問題解決の為にDOM対策が必要なら突っかかってないで案をだして具体化していかないと
いつまでたってもUNIX版が公開される事はないですよ。
オープン化を望むのなら案を出し合おうよ。
193 ：login:Penguin：03/06/23 03:00 ID:2T40n5w+
>>192
47氏の過去の発言は一つしかないだと？
47氏発言集でも読んで来い。

出てるDOM対策の案を検討してるところで無理矢理に話しを流そうとしてる
アホな輩がいるんだよ。
194 ：login:Penguin：03/06/23 03:10 ID:pDtr9a1U
>>184
確かにオープンソースにすればWinnyは生き続けるけど
そうするとDOMを排除できないから無理ですって言ってましたね
195 ：login:Penguin：03/06/23 03:25 ID:y/vXpR9g
IP書き換え対策としてこんなのを考えてみた。

キーに所持ノード(or転送ノード)を記録するのはやめにして、
代わりにどの検索リンクから来たかだけ記録しておく。
検索リンクが切れる時に該当リンクからのキーを削除する。
キーを新規生成できるのは完全キャッシュか(含UPキャッシュ)、
部分キャッシュで完全キャッシュが近くにいるもののみにする。

こうしておいて、落としたいキーがあれば、またはダウン要求がくれば
キーが来た検索リンクに対してダウンロードを要求する。
このままでは、ものすごい転送が発生するのでそれを避けるため
次のようにする。

ダウンを要求されたノードは、
　1.キーが既になくなっていれば、そんなキーは知らないと答える。
　2.キーが存在すれば、
　　a.あたかも自分が落とそうとしたかのように、ダウン要求をかけ
　　　要求元には自分が持っていたかのように振舞う(転送)
　　b.あたかも自分が落とそうとしたかのように、ダウン要求をかけ、
　　　ダウン元が見つかったら、要求元からダウン要求が来ていると伝え、
　　　要求元にここに接続しなさいと伝える(仲介)
　　c.キーが来たノードに、要求元からダウン要求が来ていると伝え、
　　　ダウン元にここに接続しなさいと伝える(丸投げ)
　　d.知っているのに知らないふり(無視)
　3.実は自分が持っていれば、
　　a.持っていると答える
　　b.1or2と同じ動作をする(知らない振り)
という動作をする。どうするかは、自分のダウンリスト、接続の優先度、
回線の空き具合をみて選ぶ。
196 ：195続き：03/06/23 03:26 ID:y/vXpR9g
ダウンを要求したノードは、たらいまわしにあった(2bc)、
キーがロストしていた(1,2d)の場合には優先度を下げる。
ダウンを要求されたノードは、ないものねだりされた(1)
場合には優先度を下げる。
誰かが丸投げされて来た場合、もし接続中のノードが丸投げしていたら
優先度を下げる。

優先度の著しく低いノードは、ネゴしてきても知らん顔をする。
なので、あまり意地悪なノードはキーすらまわってこなくなる。
197 ：login:Penguin：03/06/23 03:34 ID:a26IWp8t
DOM を排除できなかったとして、どのくらい不利益が出るの?
そもそも、盗聴不可能で劣りノードがぶら下がっても大丈夫なような
設計にすれば、DOM 排除なんて必要ないべ?
198 ：login:Penguin：03/06/23 03:37 ID:y/vXpR9g
>>197
誰もDown許さなければ、どこから落としてくるの
199 ：login:Penguin：03/06/23 03:37 ID:a26IWp8t
そういうことは現実にありえないわけで。
200 ：login:Penguin：03/06/23 03:45 ID:y/vXpR9g
>>195-196
この上で、DOM対策をするとなると接続優先度が使える。
落とすためには、必ずネットワークに参加せねばならない。
ネットワークから弾かれると検索すらできない。
落とさせてもらっているノードは、そのノードからのダウン要求に
持っている(転送含む)以外の回答をすると、切られる可能性がでるので
応じざるを得ない。つまり、強制的にUpさせられる。
また、同ノードとのUpとDownを双対にして優先度を上げ、切れにくくすると
ちゃんとUpしてくれるノードにはDownさせるといったこともできる。

こうすれば検索に非協力なノード、転送に非協力なノードは、
ネットワークに入ることができないと思う。

>>197
改造することもできるんだろ。鍵取り放題の暗号化と、
寛容な光さんがそんなに大多数でない状況はどうする
201 ：login:Penguin：03/06/23 03:51 ID:a26IWp8t
>>200
あたかも検索に協力しているかのように見せかければ、
そういう接続優先度の問題もクリアできるわけで。

嘘反応をする daemon 100 個くらいぶら下げておけば、・・・。
202 ：login:Penguin：03/06/23 03:58 ID:atr4Arx5
>>200
違っていたら悪いけどあなたLinnyの人？
考え方が非常にMXに近いと思うのだがWinnyのコンセプトとはずれてるよ。
203 ：login:Penguin：03/06/23 04:18 ID:y/vXpR9g
>>201
検索に協力しても、Upしないかぎりダウンロード要求側には切られる。つもり
検索に協力したら、自分の要求側は切れないはずなだけ。
A　1→　B　2→　C 3→･･･
でBは検索に協力すれば2の接続は切れないはずだが、1側は切れるはず。
BがAから落としている時にこれは困るとおもって。

>>202
Winnyの動作で、Upしてるかを相互通信のみで確かめる方法考えてたら
こんなんになりました。Linnyスレから追っかけてきましたがまずいですか。
MXでもめんどくなければ、Winny並に楽であれば問題ないと思うのですが。
204 ：login:Penguin：03/06/23 04:23 ID:a26IWp8t
>>203
空論ばっかり並べてないで、検証してみれば?
205 ：login:Penguin：03/06/23 06:40 ID:1uY/o971
>>195
>2b
>ダウン元が見つかったら
目的のファイル保持ノードが余程近くにいるならともかく、例えば5ホップ
かかるぐらい離れているとたどり着けるかね？このシステムだと俺には
検索リンク自動切断の間隔を長くすべきか短くすべきかもわからない。

>>202
>>1>>オープンソースでも問題ないメカニズム
これは過去のWINNYのコンセプトのままでは達成できないと思うのよ。MXに近
くなるのも一つの方法じゃないかね。まあ個人的には「自動化」「放置」という
売りは継承して欲しいけど。

>>204
>201のデーモン100個みたいなことまで考慮してたら何もできないわな。
それと、DOM排除しないでも上手く回るシステムの図を、もっと具体的に描いて
くれたら俺はDOM対策必要派から鞍替えするかもよ。DOM排除しないでいい
なら今より楽に考えられるからね。。
206 ：login:Penguin：03/06/23 08:15 ID:wB+TE3TK
47はこのスレのおかげでｵﾌﾟｿ版の実装不可能性を証明できるし、
ｵﾌﾟｿ化を迫るｱﾌｫをこのスレに押し付けられるから願ったりかなったりだよな。
所詮お前らは47の捨石に過ぎないんだよ。
207 ：login:Penguin：03/06/23 09:14 ID:tvgzlMla
>>206
そうだよね、47氏のこの板でのレス読んで
単純に「オープンもありです」って言ってるんだと認識してる純粋な人が多いよね。
47が大昔から｢Linux｣という言葉を敬遠してる事に気づいてないのかな、皆？
208 ：login:Penguin：03/06/23 09:24 ID:KTlGFaqz
>197
　DOMは何が良いか
１．キャッシュを維持する必要がないためハードディスクの容量が食われない
２．アップロード帯域を食われないため効率よくダウンロードできる
　などが、考えられる

　DOMの何が悪いか
１．キャッシュの共有による匿名性の減少
２．供給ノードの減少によるダウンロードの効率の減少

　「このノードはDOMノードだ」と特定する方法がないにせよ、DOMに不利益を
もたらす構造を作ればよい。DOMと思わしきノードに対してはアップロード速度を
規制する。すると、「DOMの何が良いか」の２番をなくすことが出来る。
　「DOMと思わしきノード」でない判定は、アップロードをするかを見れば出来る。
その評価に応えるためにノードは努力をしなければならない。それによって
「DOMの何が良いか」の１番をなくさせることが出来る。
　もちろんすべての動作は、無人で自動的に行われなければならない。

　すでにあるシステムとして、「アップロードをトークンに変え、そのトークンに
応じたダウンロードが出来る」というのがあったがファイル自体をトークン化して
しまえば、実現可能だと考えています。
　効率については実験中。

209 ：login:Penguin：03/06/23 11:58 ID:a26IWp8t
>>208
DOM が不利益を被る構造を押し付ける為に、無駄な議論が繰り返されて
結局全ての開発が止まってるわけでしょ?

DOM らない人間に取っても不利益なんだよね。
210 ：login:Penguin：03/06/23 12:15 ID:wB+TE3TK
普通ならDOM対策有り無しで分岐して議論していくんだが
ここの連中やたら排他的で全体主義的だからそれすらもできないんだな。
211 ：login:Penguin：03/06/23 12:44 ID:a26IWp8t
まず、「普通」ってのが何なのかを定義しないといけないわけだが。
212 ：login:Penguin：03/06/23 13:29 ID:FwxXxaFM
一度DOM対策無し、ノード評価無しのシステムで動作を検証してみたいな。
本当に上で言われるように、DOMが増殖してネットワークが崩壊するのだろうか。
213 ：login:Penguin：03/06/23 13:33 ID:a26IWp8t
freenet はクソ遅いだけで、崩壊には至ってないしなぁ。
214 ：login:Penguin：03/06/23 13:53 ID:aS6bPXdP
DOMがある程度までなら効率が悪くなるだけで崩壊はしないでしょう。

ただ、Winnyはある程度DOMを牽制して効率を上げることで、
ようやく実用に至っているとも思うけど。
215 ：login:Penguin：03/06/23 14:06 ID:atr4Arx5
>>208
正常なノードは悪意を持ってUPをしない場合だけではなくて
現状のWinnyでは自分からはネットワーク上に｢このファイルを持ってないですか｣
という情報を送りだす事しかできない。

自分から能動的に｢このファイルいりませんか｣とかはできなくて
自分の持っているキャッシュにあるもので相手から｢このファイルを持ってないですか｣と
要求が来た時に受動的にしかUPできない。
つまり誰からもDL要求がなければUPしたくてもUPできない場合もある。

そしてオープンソースになったらUPする機能自体を停止ししDLだけできる不良ノードが
現れるかもしれないので不良ノード対策が必要になるという事もわかる。

結局どういうシステムを最終形にしたほうがいいと考えますか。

１：完全にDOMを排除でき匿名性も完全。
２：完全にDOMを排除でき匿名性が少し低い
３：DOMを完全には排除出来ないが匿名性は高い
４：DOMを完全には排除出来ないし匿名性も少し低い

１は理想で４は妥協案ですが
現実的には２と３ではどちらが受け入れられるかな。
216 ：login:Penguin：03/06/23 15:20 ID:ywjQ0v7y
参考文献

http://seclab.dti.unimi.it/p2prep/
217 ：login:Penguin：03/06/23 17:44 ID:1hWmVwc7
Linny消えたみたいだね。
http://sourceforge.jp/projects/linny/
218 ：login:Penguin：03/06/23 18:13 ID:hJcF54er
>>199
お前はnyしか使ったことない初心者か？

ファイル共有ソフトであるMX3系を見てみろ。
ある程度のノードがUP0パッチを当ててDOMがキューを入れまくったら、
交換なしには落ちてこないシステムになるんだよ。
ダウン要求がアップ要求を圧倒的に上回ってることは明らかだ。
>>212
こいつもそうだが、MXで実証済みだ。
糞みたいな効率の悪さでカバーするならFreenetでも使ってろ。
219 ：login:Penguin：03/06/23 18:16 ID:j/t68km4
>>218
MXの匿名性はどうかと思うがな。
220 ：login:Penguin：03/06/23 18:17 ID:a26IWp8t
>>218
lopster をほげって、いろんなところで蜜を吸ってる者ですが何か?
そもそも、匿名性を導入するはずなのに、どうやって交換するんですか?
221 ：login:Penguin：03/06/23 18:17 ID:hJcF54er
>>202
話にはオープンソース化っていう新しいコンセプトが加わってんだよ。
その程度のことは理解して発言しろ。

>>206
>47はこのスレのおかげでｵﾌﾟｿ版の実装不可能性を証明できるし、
未だにそんなことを言ってる大馬鹿者がいたとはな。天然記念物だよお前は。

>普通ならDOM対策有り無しで分岐して議論していくんだが。
DOM対策が最優先で必要であることを理解していない奴は、
議論に参加する最低限の基準さえ満たしていない。
222 ：login:Penguin：03/06/23 18:17 ID:a26IWp8t
ああ。>>219 向けだ。
223 ：login:Penguin：03/06/23 18:18 ID:a26IWp8t
ん。番号がずれてたと思ったら、あってるじゃん。
>>218 向けでした。
224 ：login:Penguin：03/06/23 18:20 ID:a26IWp8t
> >普通ならDOM対策有り無しで分岐して議論していくんだが。
> DOM対策が最優先で必要であることを理解していない奴は、
> 議論に参加する最低限の基準さえ満たしていない。

基準とするならば、この発言の論拠を示して下さい。
妄想を論拠としているのなら、基準にはなりえません。
225 ：login:Penguin：03/06/23 18:20 ID:hJcF54er
>>220
>そもそも、匿名性を導入するはずなのに、どうやって交換するんですか?
アホ、だから交換の出来ないnyにはDOMの有り触れた
システムとして成り立たないと言ってるんだ。
226 ：login:Penguin：03/06/23 18:21 ID:hJcF54er
>>224
>>225
論拠だ、まずはこのスレを最初から見て来い。
227 ：login:Penguin：03/06/23 18:21 ID:a26IWp8t
>>225
煽りにマジレスしてはるんですか？
228 ：login:Penguin：03/06/23 18:22 ID:hJcF54er
>>227
お前の読解力の無さは分かってる。
229 ：login:Penguin：03/06/23 18:22 ID:a26IWp8t
>>226
>>225 をどう解釈すれば論拠と呼べるようになるんですか?
230 ：login:Penguin：03/06/23 18:24 ID:hJcF54er
>>229
煽りか？
それとも真性の馬鹿か？
231 ：login:Penguin：03/06/23 18:25 ID:a26IWp8t
「真性の馬鹿」の定義は?
232 ：login:Penguin：03/06/23 18:26 ID:hJcF54er
どうやら馬鹿の方だな。
233 ：login:Penguin：03/06/23 18:28 ID:a26IWp8t
まあ、妄想を書き込んで議論している気になっている人間というもの
は、どちらに該当するのかは漏れにはわからないけどね。
234 ：login:Penguin：03/06/23 19:24 ID:fvTihaVC
　DOM対策は無理だ、無駄だと言う意見を書いている香具師は
DOMりたい人間で、DOM対策をされては困る香具師。

　だから、そういった煽りは無視してよし

　DOMりたい香具師以外でDOMが不可能だというのならば
不可能である理由を述べよ。

　妄想結構、その妄想が実現しなければWinnyのオープンソース化は
できない。妄想だといわれているものを現実にするためにこのレスは
ある。

　妄想であるとしか思えない香具師はみてるだけでよし。
　妄想であるといわれていることを実現できると思うものは発言せよ。
235 ：login:Penguin：03/06/23 19:25 ID:atr4Arx5
一度は却下された>>114の案は匿名性がある程度あればUPとDL同士のIPがばれる事は
それほど重要ではなくてがバレバレでも違法性を問われないという物なんだがなぁ。
あともしWinnyがオープンソース化されたとしても現在のWinnyとの互換性はなくなるかもね。
47氏もそういってるし。
236 ：login:Penguin：03/06/23 19:45 ID:fvTihaVC
>>235
>>114の案は良いと思いますよ。ただし、効率が高くできるならでしょう。
　却下された理由は同様の方法をとっているfreenetが効率が悪いといわれているからであって
実装方法によっては効率を高くすることもできるかもしれない。
237 ：login:Penguin：03/06/23 19:53 ID:hJcF54er
>>235
渡ってきたキャッシュには価値がなく、
削除の対象であると共にキャシュ拡散効率及び転送効率を落とし、
中継するノードを減らしてしまうものでもある。
またWinnyですら複数ノードを経由する可能性はあり
現状と比べても効果は薄い。>>117に書いてあるな。

よほど画期的であるならまた別だが既知の技術であり、
効率と完全に背反する匿名性の強化など
システムそのものを成り立たせるためのDOM対策を考えてからするべきだ。
匿名性を上げるだけなら検索キーの中継発生率を100%にしてもいい。

DOM対策はおいといて、こんなことを言ってたんじゃ話にならん。
238 ：login:Penguin：03/06/23 20:16 ID:hJcF54er
>>234
そもそも>>4>>52>>72と中継を持ったまま多くのDOMを排除することが
不可能でない方法があるからな。

不可能なんて言ってる奴はこのスレすら読んでないか、
ただ邪魔したいだけのどちらかだ。
239 ：login:Penguin：03/06/23 20:20 ID:atr4Arx5
>>237
なるほど。
ではなにか画期的な技術を思いついたらよろしく。

それから必ず100%の中継をしても最後に中継する人の匿名性はどうしますか。
DOM対策と効率を上げるためにどの程度までなら匿名性を下げてもいいと思われますか。
ぜひ意見を聞きたい。
240 ：login:Penguin：03/06/23 20:35 ID:hJcF54er
>>239
どの程度なんてのは実装してからの効率を見て考えるしかない。
47氏がこれだけのために何度バージョンアップさせたと思ってる。
匿名性を上げたいなら中継発生率を100%にでも3分割転送でもすればいいが

そんな話はDOM対策のモデルが出来上がった後にしろと言ってるんだ。

どんなに匿名性を上げるためのアイディアを出しても、
ある程度DOM対策が出来ていなければ47氏がソースを公開することもなく全て無駄になる。

そのくらいの順序があることも分かってないのか。
241 ：login:Penguin：03/06/23 20:47 ID:atr4Arx5
ではDOM対策から先でもいいですよ。
どのようなモデルが良いでしょうか。
242 ：login:Penguin：03/06/23 21:02 ID:hJcF54er
DOM対策についてここまでの議論をまとめてくる、少しまちな。
243 ：login:Penguin：03/06/23 21:02 ID:lM38LKbq
>238
その辺の話だってさ、間に入っている奴が捏造なり、インチキなりしてる奴等
が多いと成り立たないだろう。
DOM対策って言うのが悪ければ、不正ノード対策、逆に言い換えれば、ノード
間の信頼関係を築く方法が無ければ、今のところ成り立たないシステムばかり
じゃないの。

口は悪いが俺は今日は >221 を支持。
244 ：login:Penguin：03/06/23 21:17 ID:fvTihaVC
>>237
　わたってきたキャッシュに価値をもたせる方法があるとすれば？いかがですか
245 ：login:Penguin：03/06/23 21:35 ID:hJcF54er
>>243
>>221は>>238だぞ、それはどうでもいいとして。
>その辺の話だってさ、間に入っている奴が捏造なり、インチキなりしてる奴等
>が多いと成り立たないだろう。
それは現在のWinnyでも同じ。

多くのノードがDOMパッチを当ててたりUPファイルを捏造していれば成り立たない。
しかしWinnyにはソースコードを秘匿するための処置がされているために
簡単にはDOMパッチを作成出来ない。
出来たとしても配布が小規模であり、プロトコル部分を少し変えるだけで対抗可能なので
苦労の割にクラックするメリットも薄い。

また最初にファイルを用意しなくても良く、
匿名性が高いためにアップすることのリスクも少なく、捏造する意味も薄い。
捏造してる奴はよっぽど慎重な奴かネットワークに悪戯をしたい奴か。

不正なノードが全体としては少ない。

なんにしろ現在もWinnyネットワークが成り立っているのはこれが大きな理由だ。
あとは過去ログでも読んどきな。

しかしソースコードをオープンにすればプロトコルの変更など小手先の対抗技術は使えない。
よって>>4>>52>>72などのDOMノードにおけるプログラムの改変に対抗出来る案が必要なわけだが。

やっと良い案が出てきたと思ったら検証もせず、
DOM対策の話はおいとこうなんてことになっていたからその愚かさを忠告しただけだ。
246 ：login:Penguin：03/06/23 21:58 ID:atr4Arx5
>>245
念のためですが>>221の中の>>202=>>215なのでオープンソース化する為には
何が必要かは理解してますよ。
結局最後には全て検証しないといけないのですがどれから先でも良いのでとりあえず
DOMの話に戻すという事でかまいません。
>>4>>52>>72について検証すればいいですか。
247 ：login:Penguin：03/06/23 21:58 ID:FwxXxaFM
>>244
キャッシュ自身に評価情報を持たせたらどうだろうか。
各ノードに乱数をハッシュしたようなIDを持たせる。
ファイル送信完了時に、キャッシュの公開鍵に自分のIDを付加したものを送信する。
ノードを渡り歩くごとにIDが追記されていく。
各ノードは自分のキャッシュ履歴を元に、隣接ノード評価する。

メリット
クラックに強い…と思う。

デメリット
狭い範囲の評価しか出来ない。
匿名性に問題有り。
処理が重そう。
その他諸々（ｗ

MX的思想かも。
248 ：login:Penguin：03/06/23 22:23 ID:hJcF54er
>>244
方法を聞いていないから何とも言えない。
オープンソースを前提にした上での有用な方法であればいいがな。

>>245
>結局最後には全て検証しないといけないのですがどれから先でも良いのでとりあえず
>DOMの話に戻すという事でかまいません。
これについてだが、どれから先でもいいわけじゃない。
DOMを排除する方法さえまとまれば47氏がソースを公開する可能性がある。
つまりオープンソース化によって匿名性に致命的な問題は出ないだろうってことだ。

MXの次はなんなんだ？ part109
>結局、Winnyの大きな問題としては私一人で作っているために、作者が一番のウイークポイントと
>なってしまっていることでしょう。オープンソースであったりプロトコルが公開できるのであれば
>そのソフトは生き続けますが、Winnyの場合、これをやるとDOMを排除できないので無理です。
>>1だけじゃなくここからもそれは伺えるな。

転送率なども含めて、現在のWinnyが匿名性に対してどの程度の強度を持っているか分からない以上、
出来るだけ元のWinnyを理解しておく必要がある。
>>112>>136のような話を生まないためにもな。

ここらは47氏次第だが>>240からも言えるようにDOM対策が先だ。
249 ：login:Penguin：03/06/23 22:33 ID:sFuDzbfG
>>205
ｎｙのクラスタ化のようなものをいれて近づけるか、検索クエリをとばして
できるだけ近くのノードからスタートできるようにとか。

こうするとリストアップされたとしても、誰がなに持ってるのかわからないな
と思ったんだけど、転送率の高いｎｙよりおとせないのかな･･･
250 ：login:Penguin：03/06/23 23:20 ID:atr4Arx5
>>248
まず>>4についてですが
参考意見>>32>>34>>36>>37>>39>>41>>44>>45>>47>>67
常にUPし続けるには誰かに強制的にDLさせる必要があり非現実的かも。

次に>>52の参考意見>>54>>55>>56>>58>>68>>69>>70>>71>>72>>110
検証途中

次に>>72=>>52参考意見>>73>>75>>76>>77>>
検証途中
251 ：login:Penguin：03/06/23 23:21 ID:atr4Arx5
検証途中の物はこのくらいですかね。
DOM対策が先で良いですから案を出しましょうよ。

>>236
効率を高くする方法の前にしばらくDOMの方をしなければいけないようです。
実装方法についての話はDOM対策の方が終わってからになりそうです。
252 ：login:Penguin：03/06/23 23:30 ID:hJcF54er
>>250
このスレぐらいは全て読んでくるべきだが、
それだけでは分かりにくいので今まとめている。
253 ：login:Penguin：03/06/24 00:53 ID:WlKdO1dp
>>4案のまとめ
帯域に余りがなくアップできない人気のあるノードなのか、
アップしていない不正なノードなのか判断できない>>32
他からの要求は無理にでも切ってアップさせる>>67


>>52案のまとめ
待機ノードが足らなくなる>>54
不完全な状態でも待機ノードが増えるまで帯域制限をしてアップする>>58

ノード評価にはUL実績ではなく中継実績を使う>>110
中継込ULをしているノードBを直接DLする時優先する方法を模索>>142
優先する方法についての具体的な案>>155
254 ：login:Penguin：03/06/24 00:54 ID:WlKdO1dp
>>72案のまとめ
可変のIPアドレスであれば長時間評価を維持できないので
ノードの評価をIDで行う、しかしID捏造や匿名性の低下が考えられる>>75
ノード評価は一定時間で捨てていくためにIPアドレスでいい>>81
評価情報は捨てるのではなくてその都度変わっていく方がいい>>83
一定時間ノードを発見できない場合に評価をクリアする>>81
どうしてもノード評価を維持したい場合にはDDNSを使う>>120

マイナス評価をすべきでないという意見>>88
マイナス評価をしないことを否定>>124>>127>>133
プラス評価、マイナス評価の方法についての具体的な案>>124

クラスタ位置を変えるだけで評価が消えてしまうこと>>171
これについてはまだ何も議論されていない
255 ：login:Penguin：03/06/24 01:04 ID:WlKdO1dp
>>253>>254
この中にもまだまだ突っ込みどころがあるし、分かり易いかは不明だ。

ある程度主観を省いてまとめたつもりだが、抜けている意見があるなら言ってくれ。

ただ見落としている可能性もあるが、
まとめに入れる程根拠のないと判断したものは抜いてある。

そういったものは議論の対象になるだろう。
256 ：login:Penguin：03/06/24 01:10 ID:R6r5zQyJ
>>253=>>252ですな。
>>250=>>255です。

それらについて先に検証を進めれば納得されるのですな。
ではしばらくその方向で進んだ上で新しい案が出てきたときも検討していくという事で。
オープンソース化されるように色々考えて見ましょう。
ではもう寝ます（ｗ
257 ：login:Penguin：03/06/24 01:12 ID:R6r5zQyJ
×>>250=>>255です。
>>250です。
ですなスマソ。
258 ：login:Penguin：03/06/24 01:26 ID:OH5X91UA
52の案は>>155
72の案は>>124
これを叩き台にして進めた方が良さそうだね。

4の案は確かにDOMを防ぐ一つの方法ではあるけど、
無駄なアップロードを含まない>>72には見劣りするなぁ。
259 ：login:Penguin：03/06/24 10:17 ID:02SsvGlj
wiki きぼんぬ
260 ：login:Penguin：03/06/24 10:36 ID:CQQLst6W
とりあえず、絶賛放置プレイ中のinfoのwikiとか。
ttp://winny.info/wiki/

（´-`）.｡oO(誰かがsf.jp辺りでプロジェクト申請してくるならそっちでも良いと思うけど。)
261 ：login:Penguin：03/06/24 13:42 ID:A4IFQkuw
>>260
また形から入る必要はないでしょう。
プロジェクトを申請するなら47氏がソースを公開してからです。
262 ：login:Penguin：03/06/24 13:55 ID:GJeNwLLC
>>261
まずはそのための議論からですね。

完成に近いWinnyの基本を大きく変えないのであれば>>4か>>72でしょう。
アイディアとしては面白いんですが>>52の実装は難しいと思います。
263 ：login:Penguin：03/06/24 14:18 ID:DfFgtJKL
バグを探してハクしようとするやつが増えるだけじゃない?
264 ：login:Penguin：03/06/24 14:21 ID:nmbalijm
http://japan.cnet.com/news/pers/story/0,2000047682,20055361,00.htm
ビジネス+で見たのでコピペ、
265 ：login:Penguin：03/06/24 14:31 ID:GJeNwLLC
>>263
オープンソースにすればバグを探して修正しようと
するやつも増えるからね。
266 ：login:Penguin：03/06/24 15:38 ID:JrWoTYCz
>>72
DL要求が発生してから初めて評価を聞きに行っていたんじゃ遅いと思う

最初に接続した時点でクラスタ化キーワード情報と一緒に
評価を集めておいた方がいいのでは。

集めると言っても各ノードにつき10段階程度の評価一つだけで
他ノードから集めた評価は周りに一切渡さない。

きっちり100のノードで構成されているクラスタは
100のノードにつきそれぞれ10段階程度の評価を個々に持つ。

それから各ノードに問い合わせてそれぞれの評価も足し、各ノードにどの程度UPするか判断する。
この場合最大評価値は990、最低は0。
マイナス評価を用いる場合、繋ぎ始めのノードは495点からスタートか。

ノードを二つ以上使って自ノードの評価を常に最大にしている
不正なノードを避けるためには、
1.評価を問い合わせるノードの数を多くする。

2.各ノードの評価の価値を下げる
簡単に言えば少しアップするだけで10点満点が取れるようにする
優か不かを0点と1点だけで判断するのも方法かな。
これだと値が極端に変わり過ぎて>>124の2みたいなノードに柔軟な対応が出来ないけど。

3.自ノードの評価の価値の割合を上げる。
自7*10点+他5点+他1点+他8+...のような

もちろん評価を更新する必要があるので、
最初にノードに繋がってから一定時間でまた評価を聞き直す。
ダウン要求があったら取りあえずアップを始めてすぐに聞き直した方がいいかも。
267 ：login:Penguin：03/06/24 15:49 ID:SuBmkSuW
犯罪性についてなんの疑問ももってないところがこの板らしいスレですね
268 ：login:Penguin：03/06/24 15:50 ID:zvTDS3QX
>>267
ソフトに犯罪性なんて存在しない
そんな話はスレ違いだ
269 ：login:Penguin：03/06/24 16:23 ID:QYj9x54l
現在のWinnyが直接繋がっている（相手のIPが分かっている）
ノードってのは100程度ですよね。
まずノード評価をここにあるノード全てに聞くことが出来るけど

>>72にある縮小モデルでもキーが伝播する場合、
キーを渡したノード*4のノードに問い合わせている。
となると計400ですね。

当然それぞれのノードが同じことをやるわけだから単位時間辺り一要求につき400の回答を要求される。
平均7分に一回の接続要求でも、毎秒誰かに回答をしなくてはならない。
アップ回線が太ければ太いほど、アップするもののデータ量が小さければ小さいほど、この感覚は短くなりますね。

アップする毎に評価を聞き直すのは難しいかもしれない。
かと言って直接繋がっているノードだけでは評価が足りない。
少し外れたクラスタにいたら100ノードの中で誰も相手を知らない可能性があるから。

さてどうしましょう。
270 ：login:Penguin：03/06/24 16:26 ID:QYj9x54l
>>171
>これってクラスタ位置を変えるだけで評価が消えてしまうよね？
>なんらかの救済策はないかな
これは評価収集キーの寿命を長くしてより遠くから評価を探してくるのが一つの方法ですね。

もっとも>>269の問題がでますが。
271 ：login:Penguin：03/06/24 16:29 ID:DfFgtJKL
なんかいろいろ意見でてるけど実際話は進んでるの?
272 ：login:Penguin：03/06/24 16:32 ID:QYj9x54l
>>271
自分で判断して下さい。
273 ：login:Penguin：03/06/24 18:03 ID:7kn3tBSu
はやく「考える」が「実行する」に遷移しますように。
274 ：login:Penguin：03/06/24 18:06 ID:Ei5eFob2
「実行する」場合は、しっかり穴を残しておけよ～。
275 ：login:Penguin：03/06/24 19:33 ID:gkSJJut1
>>273
「実行する」のは47氏
ソース公開なり、DOM対策実装なりね
ここは「考える」スレだから
まずは穴のないようにしっかり考えて47氏に提案しなければならない

どうも勘違いしてる連中が多いね
276 ：login:Penguin：03/06/24 20:05 ID:UvONvcAZ
>>1で47氏が述べているのは

１．もしオープンソースでも問題ないメカニズムが導入できるのなら
　　こちらでそれを取り入れてWinnyのソースを公開するのもありかも。

２．その際には現在のWinnyとの互換性はなくなると思う。

３．今やってるWinny2のその次を考えるとどうしても一人でやっているのは限界があるわけで
　　オープンシステム化かもしくは別の方法による大規模化は避けて通れない。

４．とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので
　　考えるのだけはよろしくお願いします。

５．オープンソースでも問題ないメカニズムが導入出来ないなら
　　ソース非公開なままでUNIX版を作るという手もありですが
　　こちらの時間的余裕の問題でUNIX版ができることは無いと思います。


　　　　　　　　　　　つまりここは

　　　　　　　　　　　【Winnyがオープンソースになっても問題の起きないメカニズムを考えるスレ】

　　　　　　　　　　　という事になるので

　　　　　　　　　　　オープンソースになっても問題の起きないメカニズムが導入できそうもないときは

　　　　　　　　　　　Winnyのオープンソース化の話は自然消滅となります。

　　　　　　　　　　　案を出しながら問題点を検証し考えよう。
277 ：login:Penguin：03/06/24 20:31 ID:PpYnFWwz
>>72
>>118にも似たようなことが書いてあるけど

ある最終中継ノード（UP元の可能性もある）からファイルを落とし終えた後に中身を判断して
捏造だったら最終中継ノードの評価を下げ、本物だったら逆に評価を上げてもいいかも。
本当にただの中継ノードだった場合はやや不幸だと思うけど、
中継発生率が低い場合ネットワーク全体としては有効に働くのではないだろうか。

それとハッシュ指定でダウンした場合は相手の評価を自動的に上げることが有効なのではと思う。

地引と違ってある程度、もしくはほぼ確実にファイルの正当性を評価してダウンしているから、
最終中継者となったノードは捏造ファイルだけしかアップせず、
ダウンしたキャッシュファイルを全て別に保管しているようなDOMノードではない可能性が高い。
278 ：277：03/06/24 20:46 ID:PpYnFWwz
>本当にただの中継ノードだった場合はやや不幸だと思うけど、
これは評価を下げる場合についてです。
評価を上げる場合は問題ないと思います。
279 ：login:Penguin：03/06/24 21:07 ID:N6rOl/Dc
>>277
捏造か本物かの判断は人間にしかできないので、
ずっと張り付いてないと評価できない･･･
280 ：277：03/06/24 21:18 ID:PpYnFWwz
>>279
もちろん人間にしかできません。

よって捏造であったキャッシュファイルを削除する時などに
アクションを起こさなければいけません。
今のnyにも捏造警告をつけて削除したりしますよね。

あとで評価をすることになりますから、
ダウンしたファイル毎にどのノードから落ちてきたのかを一定時間記憶しておく必要もあります。
281 ：login:Penguin：03/06/24 21:53 ID:l4KJ5A1S
>>277
中継発生率は高くする方向がいいかと。

>本当にただの中継ノードだった場合はやや不幸だと思うけど
不幸な人が出るシステムは設計がよくない。
問題があると指摘された場合は再検討しましょう。

あとDOMノードの評価を下げて行く事でネットワーク全体の正常化を図るのは歓迎だが
有料中継ノードの評価を上げていく事は程々でよいとおもう。
DOM対策とUPに貢献しているノードの優遇措置は切り離さないと問題がややこしくなる。
優遇化を突き詰めていくと元ファイルを流しているノードが突き止められるから適当なとこまででいい。

>>280
基本的に｢マッタリ共有｣｢リクエストして一晩放置しておけば朝にはザックリ｣の路線は変えたくないな。
282 ：login:Penguin：03/06/24 23:36 ID:x0vcM8Am
｣｢リクエストして一晩放置しておけば朝にはザックリ
同感！！
283 ：login:Penguin：03/06/25 00:03 ID:X7FnoJxQ
>>281
>中継発生率は高くする方向がいいかと。
これは転送効率とのバランスの問題で、当然ただ高ければいいってわけじゃないです。

>不幸な人が出るシステムは設計がよくない。
捏造ファイルをたまたま中継してしまい、ダウンノードが捏造を確認し、
こちらの接続が終了するまでに評価を下げられる確立は高くないでしょう。

現Winnyでもたまたま何処かで中継しキャッシュに残った捏造ファイルのせいで
優良ノードに切断されているかもしれません。

ソースを見てから実用性に足らないほど転送率が高ければ実装しなければいいだけです。
47氏の過去の発言からはこれが実用に足らないほど高くない転送率であると思っていますが。

所詮は1ノードの評価などしれています。
全体として適切な評価を受ければいいんです。

これはあくまで捏造ファイルを積極的に流している不正なノードが多かった場合、
それを抑制するための案ですから。
284 ：277=283：03/06/25 00:04 ID:X7FnoJxQ
>DOM対策とUPに貢献しているノードの優遇措置は切り離さないと問題がややこしくなる。
アップ量とダウン量を切り離してしまうことは出来ません。
これは平均値を何処に取るか、という問題だからです。

またDOMノードの評価を下げようにも再接続されれば意味がありません。
よって前述されていますがどちらかと言えばUPノードの優遇が主な手段となります。

>有料中継ノードの評価を上げていく事は程々でよいとおもう。
これには同意します。
ある程度アップに貢献しているノードはほぼ等しく満点の評価を受けていいと思っています。
現在と比べれば「優遇」ではなく「通常の扱い」と言い換えても差し支えありません。
一部の不正なノードが差別を受けるだけです。

>優遇化を突き詰めていくと元ファイルを流しているノードが突き止められから適当なとこまででいい。
突き止められる根拠は何でしょうか？
このノードの評価方から分かるのはどのノードのアップ量がダウン量に比べて高いか、ということです。
はっきり言ってしまえば、こんなものはネットワークに接続しなくてもプロバイダ側からより詳細に把握出来ます。

>>280
>基本的に｢マッタリ共有｣｢リクエストして一晩放置しておけば朝にはザックリ｣の路線は変えたくないな。
それはそうですね。
ただ一部マッタリしてない不正なノードがある以上、
全体でマッタリするための対策は必要でしょう。

実装してからバランスを取らないと分かりませんが、
不正なノードにならなければ何の問題もないはずです。
285 ：login:Penguin：03/06/25 00:19 ID:bN77+7nX
>>277
現状ｎｙでは、ファイルはすべてハッシュで管理されている。自動ダウンであっても、
最終的にはハッシュで落としている。
捏造というのは、ファイル名と中身が違うことであるから、その判断をするには
ファイル名とハッシュ(つまり中身)がセットになって保持されなければならない。

つまり、ハッシュに対してファイル名がロックされなければならないんだけど
それをすると逆に検索の効率が落ちるんでないかい。

それと捏造チェックは主観が入るから（「かわいい～」とかついていたらどうする）
あまり当てにできないと思うが
286 ：277：03/06/25 00:30 ID:X7FnoJxQ
>>285
>それと捏造チェックは主観が入るから（「かわいい～」とかついていたらどうする）
>あまり当てにできないと思うが
あまり当てに出来なくてもいいんです。

積極的に捏造ファイルを作らなければ、特定のノードに支障が出るほど
マイナス評価が重なることは考えられません。

また不正でないノードに捏造ファイルが多く出回って
全体の優先度が一様に下がれば、何も変わりません。
287 ：login:Penguin：03/06/25 00:37 ID:t1Po41k0
たくさんファイルを持っていてアップもたくさんしているノードが有利で
少ししかファイルを持っていなくてダウンばかりしているノードは追い出すという考え方はMXに多い

出回っていないレアファイルを持っている事でファイルを交換する時に優位にたち気に入らない奴にはダウンさせない
DOM防止パッチを当て気に入ったファイルを持っているものとだけファイルを交換する傾向を強めていった結果
目を付けられおとり捜査でQを入れられ違法ファイルの交換に応じた者が見せしめの為にﾀｲｰﾎされた

nyは自分のキャッシュを知らない間に勝手に持っていかせる代わりに自分も勝手に貰ってこれる
同じキャッシュをたくさんのノードに分散させたほうがどれが最初のキャッシュなのかわかりにくくなるので
キャッシュが知らない間に勝手にダウンされていく事はかえって自分の為になる。

レアなファイルを自分しか持っていない状態やｎｙのネットワークによく貢献していることの情報などが
広く知れ渡る事は自分の首をしめていくようなもの
ましてや貢献度が最大になったノードと１対１で直接接続して最大効率の転送を行おうとするようなものを目指しているのなら
MXの二の舞になる


結論はファイルをアップせずにダウンだけするDOMを弾きたくてたくさんファイルをアップしてくれる
ノードとだけやり取りしたかったらオープンソースのnyなんかあてにせず今出回っているMXをしてなさいってこった
288 ：277：03/06/25 00:38 ID:X7FnoJxQ
>>285
それと捏造にもいろいろありますよね。

問題なのは中身に捏造と書いてあるような捏造ファイルです。
ウィルスであったり、サイズを稼ぐために同じ画像がコピーされているようなもの。

これらはある程度積極的に排除していく必要があると思います。
289 ：login:Penguin：03/06/25 00:45 ID:PzL0WCMQ
>>287
>ダウンばかりしているノードは追い出すという考え方はMXに多い
nyにもDOM対策がなされいる理由は何かよく考えてごらん。

>１対１で直接接続して最大効率の転送を行おうとするようなものを目指して>いるのなら
妄想が激しいね

>結論は
実に参考にならない結論だね。

>オープンソースのnyなんかあてにせず
お前はもうこのスレに来るなよ。
こういうこと言う奴はどうせDOMなんだから。
290 ：login:Penguin：03/06/25 00:46 ID:+WOQp0Ch
>>287
MX に匿名性なんかあったっけ?
291 ：login:Penguin：03/06/25 00:51 ID:bN77+7nX
>>288
では、現状nyのキー削除＋大量に送ってくるノードを無視、見たいな動作ってことかな
292 ：login:Penguin：03/06/25 00:52 ID:u+9m1TPK
47氏がnyの開発当初述べていたDOMっていう概念と
ここで述べられているDOMの概念を未だに同義にしてる奴がいるね

あれはnyそのものに細工が施されていないことを前提にしたDOMなのに
分かっていない奴は47氏発言集を「DOM」で検索してみなさい
293 ：login:Penguin：03/06/25 00:54 ID:xh9kmyKE
あんつーかすげー見にくいスレだなと思うのはオレだけか？
初期のlinnyスレの方がまだ見やすかったな。
294 ：login:Penguin：03/06/25 00:56 ID:+WOQp0Ch
まあ、妄想と議論が混じってるから仕方がないんじゃないの?

悪い事してるんじゃないから、ふつーに ml 作って議論すりゃいいのになぁ。
もしくは、議論する人間はトリップ付きコテハンとか。
295 ：login:Penguin：03/06/25 00:59 ID:bN77+7nX
何が論点かすぐぶれるからな
296 ：login:Penguin：03/06/25 01:27 ID:Z8Szdf72
要点まとめ wiki きぼんぬ
297 ：login:Penguin：03/06/25 01:28 ID:VNbU6J3/
>>296
まだいらない

議論の途中だから
298 ：login:Penguin：03/06/25 01:30 ID:Z8Szdf72
>>292 みたいな FAQ だけでもまとめていただければ。
299 ：login:Penguin：03/06/25 01:30 ID:Twz7MxC1
キャッシュなんてｲﾗﾈ
ﾀﾞｳｿしてその人間が価値が高いと認めて削除せずに
残しておいたもののみを検索・アップロード対象とすべきだね。
ゴミファイルが勝手にキャッシュされるなんてシステムは
ファイルの質を低下させるだけ。
なので転送時のみワンタイムのキーを発行して暗号化しろ。
DOMDOM逝ってないでﾐｰﾑを軸にシステムを構築しなさい。
300 ：login:Penguin：03/06/25 01:34 ID:1t0Oik7D
オレ馬鹿なんで的外れだったならば指摘してほしいんですけど、

2つのノードだけでは偽ノード（DOMか偽造か改竄ノード）かどうかは
判断できないことを証明すれば、3つのノードで真偽を判断する方法しか
なくなるのでは？（重くなっても）

2つのノードの組み合わせ。
パターン1 Aノード真（Bに検索対象有）　Bノード（Aに検索対象有）真
パターン2 Aノード真（Bに検索対象有）　Bノード（Aに検索対象有）偽
パターン3 Aノード偽（Bに検索対象有）　Bノード（Aに検索対象有）偽
パターン4 Aノード真（Bに検索対象無）　Bノード（Aに検索対象有）真
パターン5 Aノード真（Bに検索対象無）　Bノード（Aに検索対象有）偽
パターン6 Aノード偽（Bに検索対象無）　Bノード（Aに検索対象有）偽
パターン7 Aノード真（Bに検索対象無）　Bノード（Aに検索対象無）真
パターン8 Aノード真（Bに検索対象無）　Bノード（Aに検索対象無）偽
パターン9 Aノード偽（Bに検索対象無）　Bノード（Aに検索対象無）偽

ただ、検索対象になっているのかキャッシュがあるのかによっても
DOM的な動作になってしまう場合があるというところがありえるので…
301 ：login:Penguin：03/06/25 01:37 ID:+WOQp0Ch
>>300
ダラダラ長い記述をするんじゃなくて、わかりやすく表にしてくれよ。
302 ：login:Penguin：03/06/25 01:40 ID:VNbU6J3/
>>300
はっきり言って意味不明。
言いたいことは分かるがそんな議論は終わってるからまずはスレ読んで来い。
303 ：login:Penguin：03/06/25 01:49 ID:1t0Oik7D
>>301
>>302
すいません、もう一回ログ読んできまつ
おやすみなさい。
304 ：login:Penguin：03/06/25 02:41 ID:1zxwnBN4
　MD5によるハッシュ生成の処理時間というものはどれほどのものなのか判る方いらっしゃいますか

　たとば、最近のマシンならPentium 4/2GHzでATA１００のハードディスクといった条件で。
　もちろんFSBやチップセットHDDの回転速度、I/O周りの性能などで変化することは前提としていますが
おおよその値で、1MByteのファイルを処理したときにどれくらいの時間がかかるかを知りたいと思っています。

　もし、参考値を持ってる方がいらっしゃらないようなら、プログラムを組むなりして試すのですが
知っていらっしゃる方がいれば、その分時間短縮になるのでおねがいします
305 ：login:Penguin：03/06/25 02:42 ID:+WOQp0Ch
>>304
md5sum というコマンドがあるので、ご自分で試されては?
306 ：login:Penguin：03/06/25 02:58 ID:wI/zICWM
ハッシュ生成時間はHDDアクセス時間で決まると思われ
307 ：login:Penguin：03/06/25 03:38 ID:vv9HUHz6
>>304
FastHashっていうソフトでハッシュの計算速度測定もできるみたいだから
そちらの環境で実行して計ればいいかと（ただしWindows版のみ）
ttp://hp.vector.co.jp/authors/VA033110/

MD5の計算負荷は、今時のPCだったら無視できるくらいの負荷だと思う
308 ：login:Penguin：03/06/25 03:57 ID:SZNBsgkb
>>304
実際にmd5sumとかmd5とかしてみればいいし、
他のアルゴリズムとの比較がしたければ、linnyｽﾚに大昔書いたけどここらへん参照。
http://www.esat.kuleuven.ac.be/~bosselae/fast.html
http://www.eskimo.com/~weidai/benchmarks.html
309 ：login:Penguin：03/06/25 06:35 ID:EntisZ+1
Celeron850で毎秒100Mbyteってことになってるから1Mなら10msec以下だな
310 ：login:Penguin：03/06/25 13:00 ID:tBw5J34G
>>283
ソースを見てからってなんだよ。
仕様が完全に問題なく出来上がらないとソースなんか公開されないぞ。

>>284
あるノードが100Gの自作ポエムを公開キャッシュにしていたらどうなるんだ。
100Gも公開している無改造の正常なノードなのに他のノードからポエムへのDL要求が少ない時はアップ量は僅か
そのノードが何か１つでもダウンしている最中ならアップ量に比べてダウン量の多い不正ノード扱いになるのか？
また10Gをアップしているノードで50Gダウンしているノードの10G分の貢献度はどう判断するのか？
アップよりダウンが多いからDOMノードだとは決定できないよ。

また実装してからバランスを取るといってもそのあたりの判断方法を確立しないとソースも公開されないし
ソースが公開されたあとの実装の話なんて本末転倒。夢の話でしかないよ。

おまいはDOM対策とかいいながら肝心なDOM onry ノードの事よりも
いかにアップに貢献しているかだけを判断材料にしているだけだろ。
アップに貢献しているノードを優先する事で相対的にDOM onry　ノードを孤立化させても
根本的なDOM対策にはなっていないのでソースが公開される為に必要なシステム作りの議論とは程遠いよ。

ソースが公開されたらそれを元にとか妄想してる奴は議論の邪魔。
311 ：login:Penguin：03/06/25 13:02 ID:sHpLSamw
onry ﾜﾗﾀ
312 ：login:Penguin：03/06/25 13:08 ID:tBw5J34G
onlyだな。
なんつーか俺もﾆｶﾞﾜﾗﾀ
313 ：login:Penguin：03/06/25 13:49 ID:S2N2SNnq
DOMと言うからおかしくなるんだろうな。
不正ノードとかクラックノードとか、正常な動作をしていないノード対策でないと駄目だよな。
だから、正常な動作さえしてれば捏造とかどうとかは問題ないはずだ。
で、外部から動いてるプログラムが正常なものか確認する方法があるのかと言うと、どうも無さそうなんだな。

お手上げ。
314 ：login:Penguin：03/06/25 15:24 ID:vDMnAAHg
>>305>>306>>>307>>308>>309
　ありがとうございます。試してみたところ、１GBで30秒ほど（セレロン１G)でした。
　120GBのデータでも1時間ぐらいですむようで、もっとも常にやるわけではないので
それほど気にしなくても良いのですけど、なんとかなりそうです。
　ありがとうございました。
315 ：login:Penguin：03/06/25 16:24 ID:Yvy2it1l
あるファイルのDL要求があって、そのファイルを持っているノード
がDL要求元にULするときに、DL要求元の共有領域のチェックを行う。

チェック内容は、巷に共有されているファイルが１つでもあるか
どうか。１つも無いのであればそのノードにはULしない(DLさせない)

という単純な物じゃ駄目なの？
316 ：login:Penguin：03/06/25 16:25 ID:+WOQp0Ch
という単純なものだと、/usr/bin あたりを共有しておけばいいということに
なるんでないの?
317 ：login:Penguin：03/06/25 16:39 ID:Yvy2it1l
そりゃそうだ。すみません馬鹿でした。
318 ：77777：03/06/25 16:43 ID:zgWGL9Pk
http://my.vector.co.jp/servlet/System.FileDownload/download/ftp/0/287703/pack/win95/game/table/pachinko/majomika.lzh

http://my.vector.co.jp/servlet/System.FileDownload/download/ftp/0/281853/pack/win95/game/table/pachinko/SUTING.LZH

http://www5b.biglobe.ne.jp/~ryo-kyo/
319 ：login:Penguin：03/06/25 17:56 ID:Zp6VzCvW
Gnutellaっていう選択肢は無いのか？
320 ：login:Penguin：03/06/25 17:56 ID:PAgtoa9N
Gnutellaの匿名性はMXと変わらん
321 ：login:Penguin：03/06/25 19:11 ID:jZRWONoQ
Gnutellaも日本語ファイル名が最初からとおればブレイクしてたかもな
322 ：login:Penguin：03/06/25 19:13 ID:bN77+7nX
>>310
ネットワークの誰もが見向きをしない巨大なキャッシュは、単なる捏造と見分けがつかず
あってもあんまり意味がないので、切ってもいいんじゃない。
どうしてもネットワークに入れたければ、ちょっと有名なキャッシュをそれと一緒に持っていれば
いいわけだし
323 ：login:Penguin：03/06/25 19:51 ID:Upf271sm
こんなスレあったんですね。　今までのまとめとかないですか？

以前Winnyのスレは暇があったんで追っかけてました。
ttp://winny.info/の情報ぐらいは押さえています。

現在のWinnyでクローズドソースによって守られているところ。
秘密キーで暗号化されている部分とか。
そのへんは整理ついてるんでしょうか？

そんでそれがfreenetではどう実装されているのか？
324 ：ますたーべーしょん：03/06/25 20:16 ID:04+sGuz0
癒す清涼サイト
http://homepage3.nifty.com/coco-nut/
325 ：login:Penguin：03/06/25 21:37 ID:tBw5J34G
>>322
そりゃおまいがポエムに興味がないだけだろ。
自分の興味のないファイルを持っているノードは切るんかい。
ポエムという例えが悪ければグロ、死体、心霊などはどうよ。
おまいは興味がなくても特定のクラスタには人が集まっている。

何が有名なファイルにあたるのかはジャンルによって違う。
おまいは俺の中では有名なあのグロい死体ファイルを
ネットワークに入る為におまいのキャッシュの中に持っておいてくれるのか？

DL要求があまり来ない特殊なファイルを持っている正常なノードが
>>284のような設計だと不良ノード扱いになってしまう例をあげただけだよ。
326 ：login:Penguin：03/06/25 22:16 ID:r/k57S6j
個々のノードを評価しようとするからいけない気がする。

接続方向別に、その向こう側のネット全体を評価すれば、趣味違いで
評価下げる仕組みでも、クラスタ分離するだけに止められそうだけど…
327 ：login:Penguin：03/06/25 22:19 ID:hzMpZ4yQ
で、実際Winnyを逆汗してみた人はいますか?
328 ：login:Penguin：03/06/25 23:47 ID:QWgFmx9u
>>325
その辺も含めてクラスタ化っつーものの意義があると思うんだがな。
ついでに、NY1BBSに中継だけでキャッシュを貯めようというスレがあった
(今も有る？1は最近触ってないので)んだが、中継で序々に完全キャッシュ
が増え、中継していなくてもUPが始まるようになってたぞ。
329 ：277：03/06/26 00:57 ID:kopmv1wo
>>291
そうですね。
切断のだけだと他から落とされてしまえば意味がないので
他ノードにもある程度の共有が出来る、評価を下げる方法ということです。
330 ：login:Penguin：03/06/26 01:01 ID:ldLUGJy7
今、Winny1 を qemu wine Winny.exe として起動することにより
逆汗しようと思ってる(デバッグでコード吐いてくれる)んだが、
sigaltstack が実装されて無くて起動せーへんのよね。

漏れは馬鹿なので、システムコールなんか知らないのに面倒だ。
331 ：login:Penguin：03/06/26 01:21 ID:6uxgciV8
Winny で流れてるポエムって、どんなのがあるんですか?
一つだけでいいんで晒していただけませんか?
332 ：login:Penguin：03/06/26 01:25 ID:ldLUGJy7
>>331
蓮絵を見た感動を表現したポエムとかもあったよ。
純粋な感動を表したポエムが多いので、ご自分の目で確かめられたほうが
よろしいかと。
333 ：277：03/06/26 04:01 ID:kopmv1wo
>>310
>ソースを見てからってなんだよ。
>仕様が完全に問題なく出来上がらないとソースなんか公開されないぞ。

>>277は>>72が他の案より自由な実装が可能だ、ということを示す一つの案です。
これは実際に実装するシステムはどれか、と考えたとき>>72を選択する上での判断材料になります。
それぞれのシステムについて何が出来るかは、一つでも多く把握しておくべきでしょう。

>また実装してからバランスを取るといってもそのあたりの判断方法を確立しないと

中継発生率を10％にするのか、20%にするのか、30％にすればいいのか
そんなことは実装するまで47氏ですら分かりません。

判断方法は明記しています。
よってバランスを取るための細かい数字の修正は必須です。
またバランスを取れるというのはある程度の自由が効くことも示しています。
334 ：277：03/06/26 04:02 ID:kopmv1wo
>>310
>あるノードが100Gの自作ポエムを公開キャッシュにしていたらどうなるんだ。

100G、つまり最低容量2Gで50分割が必要なファイル(旧Windowsとの相互接続を考えた場合)を
現状の帯域で拡散させようというのが間違いです。
これが1Gであればキャッシュの拡散効率という点で随分話が変わってきます。
またキャッシュ拡散効率を抜きにしても。

100Gの自作ポエムを公開している人は、もちろん自作ポエムのクラスタにいますよね。

同じ趣向を持つ者同士で接続しているはずなのに、
何故100Gのポエムを公開しているノードにはダウン要求が来ないんでしょう。
誰にも必要とされない人に、何かを供給する必要はありません。

自分が何かを欲しているなら他の人が必要とするものも手に入れれば済む話です。
100Gのポエム＋被参照量の多いポエム10Gを持ちましょう。
これは評価値0のノードがネットワークに接続出来る限り、難しいことではありません。

こんなことを言うとまたMXだの交換だの1対1だのという話が出てきそうですが、勘違いしないで頂きたい。
>>72の評価方法は


「誰かに必要とされている人であれば、私も何かを供給してあげよう」というものです。
335 ：277：03/06/26 04:02 ID:kopmv1wo
>>310
>いかにアップに貢献しているかだけを判断材料にしているだけだろ。
正常なファイルを全くアップしていないノード(DOM)に対する評価法も含めて>>277で書いてあるのですが、
見ていただけなかったですかね。

それと根本的なことを理解していないようです。
>>72のシステムではDOMノードに対し、特別厳しい評価をすることが出来ません。
それは>>284にも記述していますが、再接続の問題です。
分からなければ>>72以降を読み直して下さい。

再接続の問題を解決出来たり、他に良いアイディアがあるならばお聞かせ下さい。

>根本的なDOM対策にはなっていないので

あくまで>>72に付随する案だと記憶されているでしょうか。
336 ：277：03/06/26 04:03 ID:kopmv1wo
>>310
否定はいくらしてもらっても構いませんが、なんらかの根拠をお願いします。
>>284で指摘した点も含めて回答がないようですが、そもそも根拠が希薄に思えます。
議論する気がなく、ただ他の何かのために否定したいだけであれば反論する価値がありません。

などと書くとまた妄想だとか、邪魔だとか煽られそうですが、
レスを短縮し、議論を進める上でどうしても必要な事なので今回は書いておきます。

それとDOMとは「Down Only Member」のことです。
スペルの間違いはどうでもいいんですが、DOMをダウンしかしていない、
又は正常なファイルをほぼ全くアップしていないノードと理解して下さい。

こちらの意味を取り違えている部分もいくつか見受けられます。

>アップよりダウンが多いからDOMノードだとは決定できないよ。
ここなど。

「DOM only」と「DOM」を区別されているようですが、
「DOM」の方はそのまま「Down」と言い換えられそうですしね。
337 ：login:Penguin：03/06/26 07:31 ID:0NcGQ218
Winnyって前見たとき、デバッガ上で動いてるかどうかチェック入れて
動作変えてたけど今でもそうかい？
338 ：login:Penguin：03/06/26 11:24 ID:CoR87Gwy
Down Only Member onry
何も落ちてこないクラスタですかね。
339 ：login:Penguin：03/06/26 14:12 ID:gvwgKP/5
>>336
おまいは自分の話に矛盾が生じる事になる都合の悪い所は飛ばし読みするみたいだな。

>>333について
>>283のおまいの書き込み
>ソースを見てから実用性に足らないほど転送率が高ければ実装しなければいいだけです。

ソースを公開してしまったあとに実用性がなかったと気がついても
一度公開してしまったソースを再びクローズすることはできない。
オープンソースにしました、問題があるようなのでやめます、というわけにはいかない。
>>283の意見だととりあえず公開して試してみてだめなら止めれば良いという無責任な発言に見えるが？

>>334について
>あるノードが100Gの自作ポエムを公開キャッシュにしていたらどうなるんだ。
おまいはこれを読んで一つで100Gあるポエムだと本気でおもったの？

>また10Gをアップしているノードで50Gダウンしているノードの10G分の貢献度はどう判断するのか？
これは10Gのファイル１個をアップして50Gのファイル１個をダウンという意味だと本気でおもったの？
340 ：login:Penguin：03/06/26 14:13 ID:gvwgKP/5
>>300で書いたこと
>おまいはDOM対策とかいいながら肝心なDOM onry ノードの事よりも
>いかにアップに貢献しているかだけを判断材料にしているだけだろ。

これについてのおまいの返事
>それとDOMとは「Down Only Member」のことです。
>スペルの間違いはどうでもいいんですが、DOMをダウンしかしていない、
>又は正常なファイルをほぼ全くアップしていないノードと理解して下さい。

肝心なDOM onry（これは後に訂正した） ノードの事とは
DOM対策に肝心なダウンしかしていないノードのことよりも、という意味なのだが
俺の書き方が変なのかおまいの文章解釈が変なのかどっちだ？

おまいの意見だと>>72の案は｢どのノードのアップ量がダウン量に比べて高いか｣しかわからないんだろ？
>このノードの評価方から分かるのはどのノードのアップ量がダウン量に比べて高いか、ということです。
>はっきり言ってしまえば、こんなものはネットワークに接続しなくてもプロバイダ側からより詳細に把握出来ます。

プロバイダーにわかることとWinnyとの関係が不明。その情報をWinnyから取れるわけじゃあるまいし。
アップの量とダウンの量からだけでは不正なノードか正常なノードかどうかわからない
といっているのだが、意味が通じないのか。
341 ：login:Penguin：03/06/26 14:14 ID:gvwgKP/5
>>334
>100Gの自作ポエムを公開している人は、もちろん自作ポエムのクラスタにいますよね。
ポエムを公開しているからといって他のジャンルをDLしたい時は他のクラスタにいる場合もある。
おまいの想定は局所的であらゆる状況を想定できていない。

>「誰かに必要とされている人であれば、私も何かを供給してあげよう」というものです。
だから自分の興味のないものを持っているノードは不正ノードなのかという話なのだが
おまえはたとえ話という物を理解できないのか。

＞>>284で指摘した点も含めて回答がないようですが、というのは
>>310もそうだがそれ以外でも意見が出ている。
それともこれもどの意見がそうなのかわからないとかかなら
おまいに理解させるのはお手上げだな・・・
342 ：login:Penguin：03/06/26 14:19 ID:gvwgKP/5
>>340の訂正

>>310で書いたこと
343 ：277：03/06/26 21:05 ID:Fr0tq0ry
>>339-341
レスをする前に確認したいのですが
>>281とは同一人物ですか？
344 ：login:Penguin：03/06/26 22:30 ID:gvwgKP/5
>>343
　　　　　△

　　　１▲U△
　　　　／
　　２△　△　△
　　　　＼
　　△３△　△　△
　　　　／
　△４▲D△　△　△

△　△　△　△　△　△

７２案を元にしたDOM対策としてお世話したか（UP先）お世話になった（DL元）事があるかを元に
自ノードではなく他ノードに評価してもらう時の弊害

DL要求元の４から検索リンクを伝わってそのキャッシュを持っているノード１にDL要求が届く。
７２案によるとここで問い合わせが発生する。
>あるノードからDL要求が来た場合に近隣ノードへ「そのノードを知っているか？」を問い合わせます。
>問い合わせは伝播（DL要求ノードを除く）していき、知っているノードがそれぞれ問い合わせ元へ応答するという感じです。

このままでは転送ノード２について聞くことになるのでその問題を修正しながら考えてみよう。
UPノード１が知りたいのはDLノード４の評価であるはずだがWinnyでは最終DLノード（最初にそのキャッシュへのDL要求を出したノード、以下DLノード４と表記）の情報は通常匿名化されている。
しかしDLノード４について近隣ノードへ問い合わせる為にはDL要求者であるDLノード４を識別できる情報を
UPノード１が知る必要が出てくる。（懸念その１）
345 ：login:Penguin：03/06/26 22:31 ID:gvwgKP/5

その一つの案としてはDLノード４のDL要求をそのまま伝播して行きUPノード１にDLノード４の情報を伝えるという事が考えられるが
これはオープンソース化されたWinnyになった場合どのノードが何のキャッシュに対してDL要求を出したかわかってしまう事になる。

Winnyのネットワーク上で同時に存在しない唯一無比の情報のIPをUPノード１に伝えた場合どうなるかというと（IPを使ってはいけない）
例（わかりやすく日本語化）
　｢（最終DLノードの）YahooBB4195152**001.bbtec.netですがエロDVD変換.mpgをDL要求です｣（懸念その２）
この情報がUPノード１に伝わりその情報を元にUPノード１から近接ノードに問い合わせが発生する。
　｢YahooBB4195152**001.bbtec.netをお世話したか（UP先）お世話になった（DL元）事がありますか？｣
近接ノードからその情報が帰ってくる。
　｢YahooBB4195152**001.bbtec.netをお世話しましたした（UP先）お世話になりました（DL元）｣（懸念その３）

ここで>>284に書いてあるUPノードの優遇の為の処理が発生。
今回の場合UPノード１がUPした事を知っているのは中継ノード２になる。
当然UPノード１を今後優遇する為にはIPと共にUPノード１の情報を中継ノード２が保存する事になる（懸念その４）
例
　｢ZD21**25.ppp.dion.ne.jpはUPに貢献した｣という情報を中継ノード２が保存。（懸念その５）
346 ：login:Penguin：03/06/26 22:31 ID:gvwgKP/5

IPを使わない様にする為にIDなどを導入する場合
UPノード１にDLノード４のIP情報を伝えないようにする為にネットワーク上で同時に存在しない唯一無比の情報に
なるようなIDであって接続しなおした場合でも特定のノードがわかるようなIDの生成はどうするのか。
しかもそのIDから逆変換でIPを特定されないような生成法があるのか。

懸念その１とは
UPノードに最終的にどのノードがわかる事で最初のDL要求者の匿名性が失われる。

懸念その２とは
UPノード元と転送ノードにはどのノードがDL要求を出したか何をDLしたかまでわかる。

懸念その３とは
Winnyのネットワークを良く思わない団体が改造したおとりノードを投入してDL要求が来ていないのに
近接ノードに対して特定のノードの情報を問い合わせできる。
その結果どのノードがどれだけお世話しましか（UP先）お世話になったか（DL元）簡単に調べられる。

懸念その４とは
元キャッシュもしくはそれを中継しネットワーク上に流したノードの情報が第三者の元に残る。

懸念その５とは
違法なファイルのDLに関しての違法性は今後の状況次第だとしても
違法なファイルをUPした事実がノードを特定されてわかってしまうような事になってしまうDOM対策の為の設計はどうかと。
DOMを排除しようとする事だけなら匿名性低下はDLノードだけの問題に限られそうなので現時点では問題なさそうだが
UPノードを優遇しようとする為の匿名性の低下は現在の日本の法律では（ｒｙ

>DOM対策とUPに貢献しているノードの優遇措置は切り離さないと問題がややこしくなる。
DOM対策が必要なのはわかるからこの意味もわかってくれ。
347 ：login:Penguin：03/06/26 23:47 ID:CtwhnHaR
>>344-346
多分277が答えるだろうが勝手に補足しとく。
ノード評価のための実績記録、問い合わせにはIPの下半分(又は一部を除いたもの=例***.12*.123.123)
を用いれば充分だろう。

>懸念1
4は中継DLしているだけで本当のDL要求者は5かもしれない。
>懸念2
UPノードがわかるのは転送ノードの情報かもしれないしDL要求元の情報かもしれない。
転送ノードにわかるのはDL要求元の情報かもしれないし、多重転送が起こっていた場合はさらに中継
しているノードの情報かもしれない。
>懸念その3、4、5
第3者にわかるのはどのノードがどこにUL(DL)したか、ということであって、どのファイル、キャッシュ
をUPしたかはわからない。派手にUPしているノードはわかるだろう。が、それでも「何を」ULしたか
まではわからない。どんなものを転送しているか判断できるのは直接転送に携わった者だけであり、
(繰り返しになるが)それも中継によるものか直接要求されたものなのかは判断できない。
今のWINNYより大幅に匿名性が失われるとは思えないがね。

>>277
もう>>72は系周辺ノードの範囲、評価基準、優先の方法など具体的なことに論点を移しても良いのでは。
穴らしい穴が見つからないんだよねえ(ｗ もちろん新規の案はいつでも大歓迎のままで。
348 ：277：03/06/26 23:54 ID:Fr0tq0ry
>>339
>とりあえず公開して試してみてだめなら止めれば良いという無責任な発言に見えるが？
あくまで>>72に付随する案だと記憶されているでしょうか。

これは根本的なシステムである>>72をより強化するためのオプションであり、
実装すれば他ノードと協力してより捏造を防げますが、しなければ個々で対応する現在のWinnyと変わりません。

実装出来る可能性が低いと思われるなら（そうは思いませんが）
>>72のシステムを選択する上での要素として
この案に対する評価を0.7掛けでも0.1掛けでもして下さい。

>おまいはこれを読んで一つで100Gあるポエムだと本気でおもったの？
思いました(w
先に>>322の方も同じことを思ったようですが。

しかしそれを抜きに考えてあるので文章全体に問題ありません。

>これは10Gのファイル１個をアップして50Gのファイル１個をダウンという意味だと本気でおもったの？
思っていません
349 ：277：03/06/26 23:54 ID:Fr0tq0ry
>>340
>>いかにアップに貢献しているかだけを判断材料にしているだけだろ。
>正常なファイルを全くアップしていないノード(DOM)に対する評価法も含めて>>277で書いてあるのですが、
>見ていただけなかったですかね。
>
>それと根本的なことを理解していないようです。
>>>72のシステムではDOMノードに対し、特別厳しい評価をすることが出来ません。
>それは>>284にも記述していますが、再接続の問題です。
>分からなければ>>72以降を読み直して下さい。
>
>再接続の問題を解決出来たり、他に良いアイディアがあるならばお聞かせ下さい。


これをどう読めば下のようになるのでしょう。


>>おまいはDOM対策とかいいながら肝心なDOM onry ノードの事よりも
>>いかにアップに貢献しているかだけを判断材料にしているだけだろ。
>
>これについてのおまいの返事
>>それとDOMとは「Down Only Member」のことです。
>>スペルの間違いはどうでもいいんですが、DOMをダウンしかしていない、
>>又は正常なファイルをほぼ全くアップしていないノードと理解して下さい。
350 ：277：03/06/26 23:55 ID:Fr0tq0ry
>>341
>だから自分の興味のないものを持っているノードは不正ノードなのかという話なのだが
>おまえはたとえ話という物を理解できないのか。


「ある最終中継ノード（UP元の可能性もある）からファイルを落とし終えた後に中身を判断して
捏造だったら最終中継ノードの評価を下げ、本物だったら逆に評価を上げてもいいかも。 >>277」

これの何処が興味のないファイルだというだけで捏造ファイルや不正ノードと判断する案なのですか？

捏造ファイルだと判断されなければアップした分の評価が取り消されることはありません。
ファイル名からして興味のないファイルはそもそも誰もダウンしません。

>アップの量とダウンの量からだけでは不正なノードか正常なノードかどうかわからない
長時間100Mbpsでダウンしているノードが最高1Mbpsのアップする、
そんなシステムがご希望ですか？
当然ダウンしたいのであれば相応にネットワーク全体に貢献する必要があります。

>ポエムを公開しているからといって他のジャンルをDLしたい時は他のクラスタにいる場合もある。
他のジャンルのファイルを持てばいいだけです。
351 ：277：03/06/26 23:55 ID:Fr0tq0ry
とまぁ>>343以前に書いてあった内容を一部削除し
>>344-346に対応してコピペしたのですが。


>>344を書いて頂いてやっと分かりました
>>72に対するイメージがかなり違っていたようです(w


>このままでは転送ノード２について聞くことになるのでその問題を修正しながら考えてみよう。
こちらのイメージしていた>>72ではこれは問題とならないんです。

中継ノードであろうと、ダウンノードであろうと同じように問い合わせます（保持評価の参照を含む）
そして評価の芳しくないノードであれば帯域制限を掛けるのです。

それをネットワーク全体で行うことで、一部の不正なノードが住み辛いものにしようということでした。


と思ったら>>347で補足されてました(w
352 ：login:Penguin：03/06/26 23:57 ID:Fr0tq0ry
>もう>>72は系周辺ノードの範囲、評価基準、優先の方法など具体的なことに>論点を移しても良いのでは。
そうですね、さて何から考えますか。
353 ：login:Penguin：03/06/27 00:05 ID:lb1idtHr
すみません、よく読むと違ったようです。

>ノード評価のための実績記録、問い合わせにはIPの下半分(又は一部を除いたもの=例***.12*.123.123)
>を用いれば充分だろう。
これだと途中で評価情報を中継したものに評価の捏造を許してしまいます。
単一のノードを目指す限り、複数の経路を使うことも出来ませんから。

よって>>351の形がいいと思うのですが、どうでしょうか？
354 ：login:Penguin：03/06/27 00:08 ID:oOuhKOV/
デバッグに詰まったので、ちょっと長文行きます。
>>72を詰めるという話の腰を折ったらもうしわけありません。

DOM対策という名の不正ノード対策

　オープンソースのWinnyなりでの不正ノードのあり方

1)ネットワークに入り込み、そのネットワークにアクセスしているノードのIPアドレスを集めるノード。
2)ネットワークに入り込み、そのネットワークで流れているデータのリストを作成するノード。
3)ネットワークに入り込み、そのネットワークにつながれているノードがどのような情報を保持しているかのリストを作成するノード。
4)ネットワークに入り込み、ひたすらデータをダウンロードするばかりでネットワークに貢献しないノード
5)ネットワークに入り込み、そのネットワークに捏造データやウイルスデータなど傷害の原因になる不正データを流し込むノード。

　とりあえず、ざっと考えてこれくらい。

355 ：354：03/06/27 00:09 ID:oOuhKOV/
例１対策
　ノードの情報を少数他のノードに流すことによって制限する。
　インターネットにつながっている以上、IPアドレスはさらされているものであり、ポートスキャンよりは
効率が良いかもしれないが、効率よくIPアドレスを収集されないように対応する。どの程度が適当な
少数であるかは要検討。

例２対応
　ネットワーク上でキー情報が適度に流れていない限り、検索を十分に行うことができない。よって
これに対応することは困難。クラスタ化などによりキーの流通をある程度局所化できれば、全体を
把握することは困難になるかとも考える。

例３対応
　問い合わせを受けたノードがキャッシュを持っている場合にはそれを転送、無い場合には他の
ノードからの転送で行う仕組みとすれば、自ノードが持っているリストをそのノードが公開しない限り、
実際に何を持っているかのリストの作成は困難になる。

例４対応
　データは各ノードが交換するものとする。交換に応じないノードにはそれ相応の不利益を与えるような
構造にしておく。効率よくダウンロードするためにはネットワークのノードとして正しく機能しなければ
ならなくなる。

例５対応
　不正データ自体はノードが必要とするものを転送受けることによって、無用なデータの飽和を防ぐように
する。また、現Winnyにあるような評価データを流すことによって不正データの氾濫を防ぐような構造を設ける。

356 ：354：03/06/27 00:10 ID:oOuhKOV/
匿名性のために

　データは「適当なサイズの」部分(チャンクと呼ぶ)に分割し、それぞれに
ハッシュコードを求めファイル化する。
　そのハッシュコードのリストと、ファイルについての説明(実際のファイル名
など)をひとまとめにしたものをキー情報とする。それ自体もハッシュコードを
求めて区別を可能とする。

　ファイル方のノードからの検索に応えるのは、キー情報のみとする。つまり
「こういった存在ががあるらしい」という情報だけを伝える。

　各ノードは実際の転送には、各チャンクのハッシュコードを指定することによって
転送を要求する。各ノードは他のノードに対して、自分が持っているハッシュ情報の
リストを提供することはしない。

実際の転送手順
１．ノードはファイル名の部分などによっての検索によって、キー情報のハッシュ
　　コードを手に入れる。もしくは他の方法によってハッシュコードを手に入れる(BBSなど)
２．ノードはキー情報のハッシュコードを使いキー情報を手に入れる(これは１と
　　セットでもかまわないかも)。
３．キー情報の中に保存されているハッシュコードのリストを使用して実際の情報を手に入れる。

357 ：354：03/06/27 00:11 ID:oOuhKOV/
捏造データ対応のために

　細かく分割されたチャンクはその内容に応じたハッシュコードを持っている。分割された
部分の転送を受けるだけで、その情報が正しい情報であるかを確認できる。また、ノードは
「ハッシュコードを指定して」転送を受けるため、ノードが必要としていないデータを受け付ける
ことは無い。

　ノードはキー情報に基づきダウンロード中に、ダウンロードを取りやめることもできる。
ファイル名指定の地引ダウンロード時の設定として、不正であると指摘のあるファイルの
ダウンロードを行うか行わないかを設定できるようにしておくことが好ましい。

358 ：354：03/06/27 00:12 ID:oOuhKOV/
DOM対策のために

　各ノードはデータを要求されたときに自ノードが必要とするデータを相手に要求する
ことができる。データが無いもしくは転送ができないといった応答を要求してきたノードが
する場合には転送速度を絞るなどして、データを受けるだけのノードは不利益を得る
構造とする。
　また、１つ貰ったら２つ返すといった構造にしておくことによって、限界いっぱいまでの
転送が行われることを期待することもできる。当然、キャッチボールが中断した際には
優先は無くなる。

　各ノードは他ノードからの要求があったハッシュコードを記録しておき、他のノードからの
転送要求に応じる際に、そのデータを要求することもできる。これによって他のノードから
要求される情報を自ノード内に溜め込み、その後の転送を有利に進めることができるよう
になる。もちろん自ノード自体が必要としているデータがあるのならばそれを優先することも
かまわないが、そのデータを相手のノードが持っていないときなど、他のノードが欲しがって
いた情報を代わりに受け取ることができる。

　この構造によりデータ自体をトークン化し、キャッシュ自体に価値をもたせることができる。

359 ：354：03/06/27 00:13 ID:oOuhKOV/
課題と問題点

　チャンクのサイズをどれくらいにするか。
　チャンクサイズが細かいほど情報の正当性をチェックするタイミングが短くなるが、
ファイルとして持つ場合細かくするほど無駄が発生する。
　また、１つのファイルが複数のハッシュを持つことになると、ハッシュが与える
名前空間が足りなくなることも考えられる。
　交換に値するチャンクを持っていないノードに対する制限をどれほどのものにするか。
　あまりにゆるくては不利益を受け入れるものがでてくるかもしれないし、あまりに
きつくてはデータの転送の制限になる。
　要求の多いファイルはよく流通するようになるが、レアなファイルは流れにくくなる。
これについては検索が効率よく働くようにして対策するより無い。

　理屈が理屈どおり動くかを試すためにテストベンチを作成中だがデバッグに詰まって、
チト長文を。お目汚し失礼。


匿名性と交換に関する蛇足

　効率よくやっているMXの交換のようなものだが、すべては自動で行われ、交換のネタと
するためのチャンクはそれ自体では意味を持たない。交換のネタは他のノードから受け
取ったで他の転送であるかも知れず、交換といっても受け取る情報のソースはそのノードとは
限らない。また、そのノードからすべてのチャンクをダウンロードできたとすると、それは
リクエストをしたノードの要求に応じるための行動をそのノードが起こした結果であり、その
ノードにそろったチャンクがあるとしてもそのノードが望んだことではなく要求に応えた結果でしかない。

360 ：login:Penguin：03/06/27 00:19 ID:6RsW/nym
>>347
>ノード評価のための実績記録、問い合わせにはIPの下半分(又は一部を除いたもの=例***.12*.123.123)
>を用いれば充分だろう。
それがWinnyのネットワーク上で同時に存在しない唯一無比の情報になるなら十分かもね。

>4は中継DLしているだけで本当のDL要求者は5かもしれない。
一応DLノード４が本当のDL要求者であった場合の話をしているのだが
本当のDL要求者が5だったのなら７４案による隣接ノードへの問い合わせは無意味な物になるだろうな。

>それでも「何を」ULしたかまではわからない。
７４案を実現知る為には誰がDL要求したかを知る必要があるし
何をDLしたいかという情報がUPノード１に伝わらないとUPしようがないでしょ。
現在は表示されない情報だがオープンソース化されたら何に対してDL要求が来たのかを
明示的に表示する改造は可能なんだな。

>(繰り返しになるが)それも中継によるものか直接要求されたものなのかは判断できない。
オープンソース化されてもそうなのだとしたら７２案のDOMノードかどうかを判断する為の
案は崩壊したも同然だね。

オープンスース化された上で現在も進化し続けているApacheなどの例を出すなら
セキュリティホールの報告や不具合情報などに対してはその情報を無視する事もなく
対策を練るボランティアの方が圧倒的に多いわけだが。

どうしても設計にミスがあることを認めたくないならオープンソース化される事はないんじゃない。
361 ：277：03/06/27 00:29 ID:lb1idtHr
>>360

>>351>>353についてご意見を下さい
362 ：login:Penguin：03/06/27 00:37 ID:HNd2M4Z9
風呂入ってたら案の定277がｗそれも長い(;´Д｀)
>>347>>352
×もう>>72は系周辺ノードの範囲、評価基準、優先の方法など
○もう>>72系は周辺ノードの範囲、評価基準、優先の方法など
ね。(恥
俺に思いつく問題はもうこの部分にしかないのよ。

>>353
>これだと途中で評価情報を中継したものに評価の捏造を許してしまいます。
評価情報を受け取る場合、評価目的のIPと一致するIPからの情報は破棄する。
(←受け取る側のノードの動作なので操作不可)
グローバルIPを複数持っている場合も考えて一つ目のプラス評価も破棄する。
(アイスダンスの審査員みたいに一番上と一番下の評価を捨てる、とか。3つ以
上のIPを使った評価操作については考慮しない。というかキリがない。)
>単一のノードを目指す限り、複数の経路を使うことも出来ませんから。
？すまん。よくわからない。

>>360
ん？
>>72>>2777にも確認したいのだが中継ノードであってもUL実績がなければ制限受ける
(つまり実績がないノードに中継されるとDL者もとばっちり受ける)って理解で合ってる？
(それでも時間によって最適化されるはずだけどね。)
どうも自分の理解に自信がなくなってきたよ。
363 ：login:Penguin：03/06/27 00:51 ID:6RsW/nym
>>350
>「ある最終中継ノード（UP元の可能性もある）からファイルを落とし終えた後に中身を判断して
>捏造だったら最終中継ノードの評価を下げ、本物だったら逆に評価を上げてもいいかも。 >>277」
最終中継ノードが正常なノードかもしれないのに評価を下げるのか？
本当のUP元の評価には何も影響しないぞ。

捏造ファイルを最初にUPしたノードを特定する方法が何も述べられていないが
設計に不備があるとは認めないのかい。

>長時間100Mbpsでダウンしているノードが最高1Mbpsのアップする、
>そんなシステムがご希望ですか？
その時点でそういう状況だとして過去にどれだけWinnyのネットワークに貢献したかは判断できない。
またそれをする為には新たな懸念が生じる。

>>354
UPに貢献しているノードの優先の方をDOM対策よりより大きな比重を置いている>>277には
そのあたりが伝わらないようだ。

>>354に関してはなんとなく話しが通じそうなので熟読させていただきます。
364 ：277：03/06/27 00:57 ID:lb1idtHr
341と344って違う人なんですね・・・。

ゴミレスをいくつも入れてしまった。

ハンドル固定しませんか？
365 ：277：03/06/27 01:47 ID:lb1idtHr
>>362
>評価情報を受け取る場合、評価目的のIPと一致するIPからの情報は破棄する。
>>344の図で言うと最終的に2のみが1に評価を報告することになりますが
2のみを中継する限り、全ての情報は2によって改竄可能です。
2が評価目的のIPを適当に指定して中継を装えばDOMになることが出来るでしょう。

>中継ノードであってもUL実績がなければ制限受けるって理解で合ってる？
私のイメージではそうですね。どちらが>>72さんと同じかは問題ではないと思います。
366 ：login:Penguin：03/06/27 01:49 ID:6RsW/nym
>>364
俺は７２案を全面否定しているわけじゃない。
今のままでは問題があるといっているんだよ。
そして>>354のような発言は47氏を彷彿とさせるし
おまいのような発言はLinnyスレの535 ◆HO0OFh2RXI を彷彿とさせるだが。
多分図星かと。
本当にオープンソース化したいなら人の意見も聞けよ。
367 ：277：03/06/27 02:16 ID:lb1idtHr
>>363
あなたは自分の話に矛盾が生じる事になる都合の悪い所は飛ばし読みするみたいですね。

>最終中継ノードが正常なノードかもしれないのに評価を下げるのか？
>本当のUP元の評価には何も影響しないぞ。

これは根本的なシステムである>>72をより強化するためのオプションであり、
実装すれば他ノードと協力してより捏造を防げますが、しなければ個々で対応する現在のWinnyと変わりません。

捏造ファイルをたまたま中継してしまい、ダウンノードが捏造を確認し、
こちらの接続が終了するまでに評価を下げられる確立は高くないでしょう。

ソースを見てから実用性に足らないほど転送率が高ければ実装しなければいいだけです。
47氏の過去の発言からはこれが実用に足らないほど高くない転送率であると思っていますが。

>捏造ファイルを最初にUPしたノードを特定する方法が何も述べられていないが
>設計に不備があるとは認めないのかい

特定する必要などありません。
意図的に捏造ファイルをアップしているノードは、
他のノードと比べて圧倒的に評価を下げられる可能性が高いからです。
これは現Winnyにある捏造警告と同じです。
368 ：277：03/06/27 02:16 ID:lb1idtHr
>>363
>その時点でそういう状況だとして過去にどれだけWinnyのネットワークに貢献したかは判断できない。
>またそれをする為には新たな懸念が生じる

>>72すら読んでいないようですね。
>●お世話した（UP先）ノード
>●お世話になった（DL元）ノード
>程度の情報を覚えておく事とします。

一定時間評価を保持するのです、議論する以前の話ですね。


>UPに貢献しているノードの優先の方をDOM対策よりより大きな比重を置いている
UPに貢献することとDOWNで利益を得ることは表裏一体です。

UPノードを優先することで相対的にDOWNノードを抑制します。

>おまいのような発言はLinnyスレの535 ◆HO0OFh2RXI を彷彿とさせるだが。
>多分図星かと。
あなたの理解がこの程度だからでしょう。




まずは>>72をしっかり読んで理解して下さい。
369 ：login:Penguin：03/06/27 02:18 ID:oOuhKOV/
>>344

　ノードを特定するIDの設定の仕方は別として

　ノード１は回りのノードにノード2の評価を聞き対応する
　ノード2は回りのノードにノード3の評価を聞き対応する
　ノード3は回りのノードにノード4の評価を聞き対応する

　と、いったように部分に分ければ、ノード1がノード4の情報を知る必要は無くなる。
　ただ、中間に入ったノードの評価が悪かった場合など、下流のノードが優良でも
制限を受けたダウンロードし返られない。

これで、懸念1と懸念2はクリア

懸念3は、転送内容については評価に入れない。評価するのはアップロードの量や質だけとすれば
クリアできる。

懸念4は部分を分けることによって、各ノードに経路は残らないためクリアされる。
ただし、後に記述する問題は起こりうる。

懸念5は懸念4と同様に部分に分けることによってクリアできる。

370 ：369：03/06/27 02:18 ID:oOuhKOV/
　問題点
　評価情報をネットワークに流すことによって、2番のノードが1番のノードからのダウンロードを受けた
という情報を、他のノードが受けることができる。同様に3番のノードが2番のノードからのダウンロードを
受けたこと、同様に4番のノードについても他のノードが情報を受け取ることができる。
　あまたある、評価情報を収集し分析するノードがネットワーク内に存在した場合流れを分析することが
できる。ただし、その情報量がとてつもなく多いとき現実的であるかというは謎であるが。

　また、他ノードの評価情報をどれほど保持するか、そのデータ量はどれほどのものか。

　ダウンロードを受けた振りをして、不正な評価情報を流した場合、不正な評価を流されたノードは
不利益を受けることになる。

　また、ネットワーク上に不正な評価と正当な評価がとあるノードについて流れたときにその統合は
どのようにするのか。2番のノードが3番とその隣のノード(仮に5番とする)にダウンロードをしたとする。
3番のノードと5番のノードはそれぞれに評価する。それぞれの評価をどのようにして統合するか？

371 ：login:Penguin：03/06/27 02:22 ID:6RsW/nym
やはりLinnyスレの535 ◆HO0OFh2RXI だったか・・・
おまいの想定は局所的であらゆる情況を想定していないよ。
ネタを語るのはLinnyスレだけにしてくれ。
邪魔。
372 ：277：03/06/27 02:24 ID:lb1idtHr
>>371
論理的に語ることが出来なくなったらくだらない煽りですか

自分の意見を正当化するための最後の手段ですね。
373 ：login:Penguin：03/06/27 02:27 ID:6RsW/nym
>>369
おお。
ちょっと待ってくれ。
色々検討してみる。
374 ：login:Penguin：03/06/27 02:32 ID:BkawyOit
とりあえず、>354氏に期待。
375 ：login:Penguin：03/06/27 07:14 ID:HNd2M4Z9
>>360
>>それでも「何を」ULしたかまではわからない。
>７４案を実現知る為には誰がDL要求したかを知る必要があるし
>何をDLしたいかという情報がUPノード１に伝わらないとUPしようがないでしょ。
>現在は表示されない情報だがオープンソース化されたら何に対してDL要求が来たのかを
>明示的に表示する改造は可能なんだな。
今のNYでもUPファイルを10個ほどに限定して悲惨少量を監視していればクラックせずとも
何をULしているかはわかります。そもそも、これによって実際にどういった問題が起きる
のでしょうか。具体的な例を出してもらえますか？
私は具体例を考えた結果大きな問題ではないと判断しました。

>>363
>最終中継ノードが正常なノードかもしれないのに評価を下げるのか？
>本当のUP元の評価には何も影響しないぞ。
その辺は中継発生率や具体的な評価方法でカバーすべきところでは。
>UPに貢献しているノードの優先の方をDOM対策よりより大きな比重を置いている
程度問題だけど、これも具体的な評価方法の問題の範疇では。
システム自体に致命的な不備があるとは思わないなあ。
376 ：347：03/06/27 07:15 ID:HNd2M4Z9
>>365 えっ？経路が一本てそういうこと？？>>72の図にこだわりすぎでは？？
繋がってる検索リンク全部に評価ｷﾎﾞﾝクエリ発行(寿命短)するぐらい景気良く行くものだと
思ってました。また仮に一本に限定したとしても運良く2の位置を確保できるとも限りません。

>>366
>そして>>354のような発言は47氏を彷彿とさせるし
>おまいのような発言はLinnyスレの535 ◆HO0OFh2RXI を彷彿とさせるだが。
こういうのはつまらんからやめよう。自分を貶める、ひいてはあんたが支持しかけている>354
すら貶めかねない発言ですぜ。
>おまいの想定は局所的であらゆる情況を想定していないよ。
局所的すぎる想定は問題だけど、あらゆる状況の想定までする必要はあるかね？最大公
約数的に場の最適化を目指すべきであって、時には妥協も必要だと思うがどうよ。


>>354
思いっきり端折ると管理責任と効率のトレードオフってことでおｋですか？多重転送は可能性だけ
に留めておく方が幸せだとと思いますが。あと質問ですが、キーのサイズはどのくらいを想定してますか？
また交換成立する確率はどのくらいだと当たりをつけてますか？
377 ：347：03/06/27 07:28 ID:HNd2M4Z9
>>72案補足
中継ノードにUL実績が無いためDL要求ノードまでとばっちりを受けることについて。
優先/制限の方法を帯域制限のON/OFFで行わず、UL枠で行う。

まず、maxUL枠の2割くらい(仮にね)を優先UL枠に取っておく。残りの8割が埋まるまでは評価を
尋ねずに普通にULする。それ以上にULする場合は周りにDL要求してきたノードの評価を周りに
尋ねる。実績おｋならUL開始。悪評価なら放置。

これだととばっちりを受けるといっても転送自体が始まらないのでただのキーロスト等と
変わらない。またDL枠を消費しないので元々のDL要求元は直接DLに行くか、あるいは新しい
中継先にDL依頼することになるか。帯域制限によって継続的にとばっちりを受け続けるよりは
マシだろう。

帯域制限で行う場合でも時間によって最適化されるだろうけど、どっちが良いかはまだちょっと
わからない。>>354の交換開始後の動作としても使えるかもしれない？
378 ：login:Penguin：03/06/27 12:43 ID:AkiesX5d
>>354
なかなかいいですね。
私の考えとしては、周りに評価を聞くよりは、直接自分が評価を下せるほうが
うまくいくとおもうんで。
自分で評価するとなると交換をベースにしなくてはならないんで、そこをどうしようかと
考えて、上のほうでちょっと案を出してみたんですが、検索部分と実際の交換部分を
分けるところがいいと思います。

ただ、なかなか揃わない可能性がありますね。
379 ：login:Penguin：03/06/27 12:46 ID:AkiesX5d
>>376
多重転送にする必要はないのでは。ｎｙよりも細かいキャッシュがもっと散らばる感じに
思うのですが。
380 ：login:Penguin：03/06/27 19:23 ID:6RsW/nym
>>376
スマンかった

>>367,368,372
呆れた。
381 ：277：03/06/27 21:22 ID:D7qtnz+o
>>376
>繋がってる検索リンク全部に評価ｷﾎﾞﾝクエリ発行(寿命短)するぐらい景気良く行くものだと
>思ってました。また仮に一本に限定したとしても運良く2の位置を確保できるとも限りません。
DL要求が4→3→2→1と流れていった時点で
1は2のみ、2は1と3、3は2と4、4は3のみのIPしか持ち合わせていませんよね。
そしてこの順に全て繋げないと1と4はやり取りを出来ない。

1から見て2以外のノードでは4のノードに辿りつく道がないと思っていたのですが
何か勘違いしているでしょうか？あまり自信がないんですが。

>>377
>優先/制限の方法を帯域制限のON/OFFで行わず、UL枠で行う。
それはいいですね、考え付きませんでした。


>>354についてはあとで考察させて頂きます。
382 ：login:Penguin：03/06/27 21:39 ID:D7qtnz+o
>>381
失礼しました。
4の一部の情報を1にはそのまま流すんですね。

IPの一部を削除した場合
他ノードとの重複の可能性は捨てるということでいいんでしょうか？

これは>>72案で言うと
一部のケーブルテレビなどISP側でグローバルIPを
割り当てられていないノードにも考えられることですね。
383 ：login:Penguin：03/06/27 23:00 ID:bEF7uzg0
宇宙空間を自転しつつ公転している地球上を飛行機で一周した場合、
全体として前進しているのか後退しているのか良くわからないよね。
384 ：login:Penguin：03/06/27 23:25 ID:6RsW/nym
飛行機の中の人は進んでると思ってるけど
地球を外から見てると進んだり戻ったりして見えるよ。
もう少し離れた所から見れば行ったり来たりしながらも進んでるようにも見えるけど
宇宙全体から見れば行ったり来たりしながら回っているように見えるかもね。
385 ：login:Penguin：03/06/28 07:48 ID:Htm2dKm8
＞＞>>379
＞＞多重転送にする必要はないのでは。
>>355
>例３対応
>　問い合わせを受けたノードがキャッシュを持っている場合にはそれを転送、無い場合には他の
>ノードからの転送で行う仕組みとすれば
>>358
>　各ノードは他ノードからの要求があったハッシュコードを記録しておき、他のノードからの
>転送要求に応じる際に、そのデータを要求することもできる。
また、大前提として中継によるDL要求か直接のDL要求かをUL側は判断できない(しない)。
これらを考慮すると、多重転送になる(～にする、じゃなくて「なる」)ことが増えるでしょう。
……とか書いているうちに自分で対応策を思いつきました。まとめられたら書きます(前提条件が
かなり多いです)。先に>>354さん自身が書かれるかもしれませんが。

>>382
>一部のケーブルテレビなどISP側でグローバルIPを
>割り当てられていないノードにも考えられることですね。
これは完全に頭から抜けてました。困った。かといってID制にするのもちょっと……。うーん、
この部分は良い解決策が浮かびません。ノード識別のための代案あればお願いします。
無ければ識別の必要の無い>>354案をさらに進めるか、あるいはｹﾌﾞﾗｰには泣いてもらうか…。
386 ：login:Penguin：03/06/28 10:37 ID:KEGx+y0g
>>385
>この部分は良い解決策が浮かびません。ノード識別のための代案あればお願>いします。

これに関しては評価を要請する範囲をあまり広範にしなければ問題ないと思います。

クラスタ化が働いているなら、特定のDLノードの周りには特定のDLノードの評価が多いはずです。
387 ：login:Penguin：03/06/28 12:28 ID:74se3O39
>>385
IPの一部＋起動した時の秒の下100分の1秒とかのランダムな数字
にしたらかぶりにくいと
388 ：login:Penguin：03/06/28 16:27 ID:74se3O39
>>354案の基本部分はこんな感じですかね。

☆ファイルを適当なサイズに分割する。これを「チャンク」と呼び、データのやり取りは
　このチャンクを単位として行う。それぞれはハッシュ値を求め一意に区別できるようにする。
☆ファイルのチャンクのハッシュ値のリスト、および実際のファイル名などの人間が
　識別できるための情報をひとまとめにしたものを用意し、これを「キー情報」と呼ぶ。
　これにもハッシュコードつけ、一意に区別できるようにする。

＜データ入手までの流れ＞
ファイル名 → キー情報のハッシュ → キー情報本体 → チャンクのハッシュ → チャンク本体

★ファイル名からの検索に対して、応対ノードはキー情報のみ答える。
　つまり、存在と入手手段しかわからない。
★実際のデータ請求は、チャンクのハッシュコードを指定することにより行う。
　各ノードは、自分の持っているチャンクのハッシュ情報は他に漏らさない。

★各ノードはデータ(チャンク)を要求されたときに自ノードが必要とするデータ(チャンク)を
　相手に要求することができる。データが無いもしくは転送ができないといった応答を要求してきた
　ノードの場合には転送速度を絞るなどして、データを受けるだけのノードは不利益を被る構造とする。
★データのやり取りに関わるノードは、そのチャンクが完成するたびに
　ハッシュチェックを行い破損のチェックを行う。
389 ：login:Penguin：03/06/28 16:45 ID:74se3O39
こうした構造の上で、
★各ノードは他ノードからの要求があった(チャンクの)ハッシュコードを記録しておき、
　他のノードからの転送要求に応じる際に、そのデータを要求することもできる。
　これによって他のノードから要求される情報を自ノード内に溜め込み、その後の転送を
　有利に進めることができるようになる。
　もちろん自ノード自体が必要としているデータがあるのならばそれを優先することも
　かまわないが、そのデータを相手のノードが持っていないときなど、他のノードが
　欲しがっていた情報を代わりに受け取ることができる。

＜利点＞
☆「ハッシュコードを指定して」転送を受けるため、ノードが必要としていないデータを
　受け付けることは無い。
☆2者間の通信のみで、不正ノードを判定できる。
☆誰がどのファイルを持っているのかを追跡することが困難。
☆部分キャッシュであるチャンクに価値をもたせられる。
☆チャンクそれ自体は、単独で意味を持たない。

＜問題点＞
★チャンクが広がっていない状態で、ちょっと離れたノードからダウンをかけると
　ものすごい数の転送が起こることとなる。
★チャンクのサイズの問題。
★チャンクの名前空間の問題。
★交換不成立時の制限の強さ。
★レアファイルの流通。
★大きいファイルの時チャンクが揃わない可能性。
390 ：login:Penguin：03/06/28 19:34 ID:KEGx+y0g
>>387
それだとIDと同じなんですよね
391 ：login:Penguin：03/06/28 20:46 ID:ijqsOCbm
今のWinnyのままでオープンソースにすると「仮想キー」の中の所有者のIP
(ある確率で中継者のIPに書き換わる)がまる見えなんだけど、これで十分な
匿名性があるといえるのだろうか。DOMがどうとかよりこのことの検討が先
だと思う。

354案ではその問題はないが、いくつかの疑問が。

１．各ノードの構成はどうするのか。Winnyではおそらく検索の効率をあげる
　　ためにピラミッド状の構成をとっている。工夫なしの検索ではマルチキャスト
　　するしかないので帯域も食うしヒット率もわるくなるはず。

２．原則的に中継者が入るシステムで交換を必須にすれば、他のひともいっているように
　　交換条件のキャッシュがつねに手元に無いかぎり、一度のリクエストで
　　全体におよぼす影響が多すぎる。

個人的に「完全ファイルリストによる検索無しシステム」というアイデアを
出しておきます。
392 ：login:Penguin：03/06/28 20:50 ID:y6pwrrU0
>>391
また出てきたか。
おまいはスレの流れってヤツが読めないのか？
393 ：391：03/06/28 21:22 ID:ijqsOCbm
> 392
私を誰だと思い込んでるのか知りませんが、このスレに書きこんだのは391が
始めてですよ。

> おまいはスレの流れってヤツが読めないのか？
流れっていわれても、ここ最近、277と誰かの不毛な論争と、354の新案との
他になにかありましたか。

スレの始めから391で書いた「匿名性」に関しては何の話もされていませんが
このことについてあなたはどう考えますか。

もしWinny作者の47氏が見ておられましたら、Winnyオープン化の問題点について
もう少しくわしく示していただけたらありがたいです。
394 ：login:Penguin：03/06/28 21:41 ID:6hyOetbc
wineで動けば移植する必要ないんじゃないの？
動かないの？

どっちにしても作者はソース公開する必要ない。
395 ：login:Penguin：03/06/28 21:43 ID:6hyOetbc
どうせDelphiのソースだからこの板にいるLinux厨は誰も読めないしね。
396 ：login:Penguin：03/06/28 21:45 ID:6hyOetbc
つーかクレクレ五月蝿くして作者に迷惑かけるなよ＞屑ども
397 ：login:Penguin：03/06/28 21:46 ID:Htm2dKm8
47氏は匿名性については中継発生率が0でないこと、それだけで充分と
考えてるのではないかな。
参考：http://winny.info/2ch/main/1049124224.html#333
この部分は俺も同感。でも匿名性云々は程度問題だからなあ。
人によって求める基準が変わってくるのは仕方ないことかもねえ。
398 ：FLA1Acx132.tky.mesh.ad.jp：03/06/28 21:51 ID:NaGuX1Xc
ttp://.jp/staff/in.cgi?id=13675
399 ：login:Penguin：03/06/28 22:04 ID:y6pwrrU0
>>393
>DOMがどうとかよりこのことの
今はDOM対策を優先して議論しているというのに
その理由も分かっていない奴は(ry
400 ：login:Penguin：03/06/28 22:35 ID:e5oAvSuR
>>393
DOM対策が必要という話題で来ている所に匿名性の話題が出て
またDOM対策に話しが戻っている状態ですね。
現在のDOM対策は>>354のDOM対策という名の不正ノード対策の例となる以下の物の中で
4)ネットワークに入り込み、ひたすらデータをダウンロードするばかりでネットワークに貢献しないノード
5)ネットワークに入り込み、そのネットワークに捏造データやウイルスデータなど傷害の原因になる不正データを流し込むノード。
についての対策についての話題が主のようです。

5)については現在のWinnyの捏造警告システムを踏襲して気がついたものが
評価データを流せばいいであろうかと思われるのですが
現在の話題の主になっている4)のようなノードが発生する原因の最大の理由は
不法なファイルを故意又は知らずにその流通に関わる事によって自分が何らかの摘発を
受ける事を危惧するノードだと思われます。
その結果ダウンロードはしてもアップロードはしない改造を施すノードが出てくるわけです。

もし完全な匿名化を実現できるのならどのようなファイルの流通に関わってしまったとしても
身元が特定される事はないのですからアップロードしないような改造を施す必要もなくなるかと思われるので
完全匿名化されれば4)についての対策はそれほど重要ではなくなっていくのではと思います。
401 ：login:Penguin：03/06/28 22:36 ID:e5oAvSuR
むしろ最近の違法ファイルの流通に対しての取り締まりが強化され始めている現状からすると
そのようなノードを取り締まる為に投入されるかもしれない次のようなノードに対しての対策の方が重要ではないかと。
1)ネットワークに入り込み、そのネットワークにアクセスしているノードのIPアドレスを集めるノード。
2)ネットワークに入り込み、そのネットワークで流れているデータのリストを作成するノード。
3)ネットワークに入り込み、そのネットワークにつながれているノードがどのような情報を保持しているかのリストを作成するノード。

このような情報を収集しようと試みるノードに対してアップの貢献度やWinnyのネットワークの中で
どれだけ重要な流通元として活躍しているかなどの情報を収集されないようなシステムにするかも
新たに考えておいたほうが良いですね。

もちろんこれに関しても収集された情報の各ノードのやファイルについての匿名性が完全であれば
問題ないわけなのです。

そのあたりも踏まえてDOM対策について考えてみたらいいと思うのですが
>>399はどのあたりのDOM対策を優先して議論したらいいと思われますか。
402 ：login:Penguin：03/06/28 22:56 ID:y6pwrrU0
>4)についての対策はそれほど重要ではなくなっていくのではと思います。
これには同意し兼ねるね。

理由の一つはADSLなどの非対称な回線が圧倒的に多いということ。
現在も8Mbpsやら12MbpsなどのDOWNを優先した回線が多いが、
UP帯域によって制限を受ける。
MXもnyもUPが1MbpsならDOWNも1Mbps程度しか出ない。

簡単にダウンロードばかりが出来る方法があるなら、
一部の人間はUP枠の10倍もあるDOWN枠を使って、さらにDOWNしようとする。
これはDOWN24Mbps～30Mbps(UP1Mbps～2Mbps?)のADSLが普及し始めたらもっと深刻な問題となるだろう。

この点が>>72や>>354で固まっているならいいけど
どちらにもまだ問題はあるし、すぐに議題がフラつくのはどうかね。
403 ：391：03/06/28 22:57 ID:ijqsOCbm
> 397
今までどおりならともかく、オープンソース化されたら参加者のIPを簡単に
集められるので、検挙される可能性ははるかに高くなるとおもいます。

いつ警察にふみこまれてもいいように、コマンド１発であぶないデータ消せる
ようにしておくか、って不正することが前提になってるよ。まじめに生きよう。

> 399
> その理由も分かっていない奴は(ry
もったいぶらないで、その「理由」を聞かせて下さいよ。

話はかわりますが、考え方をかえればWinnyをオープンソース化するのは
意外と簡単です。

１．まずWinnyのソースの「ほとんど」を公開する。
２．47氏がそのソースにパケット解析防止とバイナリプログラムのハック防止
　　のためのコードを加えてバイナリを作成、公開する。
３．ユーザーはそのバイナリを使うことで、今と同じ安心度でWinnyを利用できる。

どうですか47氏。
404 ：login:Penguin：03/06/28 23:05 ID:y6pwrrU0
>>403
初めて書き込む前にこのスレすら読んでないだろ？
本当に一度1-390まで読んだなら理由を書いてもいい。
403の内容にしたってスレ読んでないのがバレバレ。
405 ：login:Penguin：03/06/28 23:16 ID:e5oAvSuR
>>402
ADSL回線での話しなら不正なノードというか現在の常時接続者の多数が
光よりADSL使用者が多い事を考えると不正ノード扱いは出来ないでしょう。
ADSLが問題ならば将来光が当たり前になって行けば解決する問題であり
それはDOM対策というよりインフラの問題かと。

議題がふらつくという意見はよくわからないです。
どの時点に戻したいのかわかりませんがあなたの言われる話の流れという事でなら
話題がその都度移り変わっていく事を妨げるのは流れをさえぎる事になりますが。

あなたはどのあたりのDOM対策を優先して議論したらいいと思われますかというのが
聞きたかったのでそのあたりについての解釈を聞かせていただけませんか。
406 ：login:Penguin：03/06/28 23:27 ID:6hyOetbc
公開しません。
407 ：login:Penguin：03/06/28 23:28 ID:6hyOetbc
つーか自分らで作ったらいいじゃん。
どうせ互換性ないんだし。
408 ：login:Penguin：03/06/28 23:39 ID:y6pwrrU0
>ADSL回線での話しなら不正なノードというか現在の常時接続者の多数が
>光よりADSL使用者が多い事を考えると不正ノード扱いは出来ないでしょう。
プログラム側で不正をして、ADSL回線のDOWN帯域をフルに活用しながらアップはほとんどしないノードが出てくるって言ってるんだが。

光でもUPよりDOWN帯域の方が通常は多い。
ADSLのDOWN帯域が拡大しようとする今後、将来っていつまで待つ気かな。
インフラを考えないならUP:DONWが10:1のノードのみを対象にした設計でもいいわけで。

>あなたはどのあたりのDOM対策を優先して議論したらいいと思われますか
4)ネットワークに入り込み、ひたすらデータをダウンロードするばかりでネットワークに貢献しないノード

>>402でそれ書いたんだが、意図を分かってもらえなかったかな。
409 ：login:Penguin：03/06/28 23:43 ID:dLDbAbX9
>>395
つーかC++だから
馬鹿じゃねぇの？
410 ：354：03/06/28 23:52 ID:RgJuKfgS
>>389

問題点について
１．ネットワークの飽和については次の発言で
２－３．チャンクのサイズと名前空間の問題
　小さいチャンクであることが反応の点では好ましいが、あまり小さいと効率が悪くなるとともに、名前空間を食い
つぶすことになる。適当と思われるサイズを検討する必要はあります。
　ただし、128ビットの名前空間があった場合、10＾(38)ほどの空間を持つことになる、個々に100万(10＾6)のファイルを
割り当てたとしても、各ファイルが(10^32)ほどのチャンクをもてる。逆もまたしかりで、空間についてはそれほど
気にしなくても良いかもしれません。
４．交換不成立時の制限の強さについては、1チャンクの交換が成立しなかった場合、「そのノードからの要求を
一定時間受けない」と言う方法も考えられます。1チャンクの転送にかかる時間を元に制限を設けるが良いかと
思います。逆に効率よく交換が行われている場合には、より転送に拍車がかかるように、作りこむことで効率を
あげることができると考えます．
５－６．レアファイルについては、検索の効力を高める以外には手に入れることは困難だというほかありません。
ただ、レアなファイルのハッシュコードを知っていれば、周りのノードにリクエストしているうちに、集まってくる
という構造も考えられます。同様に、多数のチャンクから成り立っているファイルの場合にも、周りのノードに
リクエストを掛けているうちに、集まってくるようにすればよいかとおもいます。
411 ：410：03/06/28 23:52 ID:RgJuKfgS
・ネットワークの飽和について　
　ネットワークを効率よく使うために過度の転送要求の発行や、転送要求の受付を行うことは好ましくないと考える。
　よって、各ノードは効率のよい転送を行うための転送枠を想定するものとする。
　転送枠を越えての要求の発行や、転送要求の受け入れはしない。これによって、ネットワークの飽和状態を
避けるものとする。もちろん転送速度の速い、光などで接続されている、ノードは多数の転送枠を持つことになる。
　また、偽装して過度の転送枠を取得したとしても、相手側がそれに応じなければ効果を得られることは無いように
設計する。転送枠は(極力)実際の転送能力から算定されるべきである。転送能力以上の枠を使用した場合
個々の転送能力は低下する。これによって相手側ノードの反応も低下するとした場合、効率よくデータを得ることは
できない。
　このような保護機能を設けることによって、単独ノードが利益を得る構造を防止する。
こんな感じでいかがでしょうか？
412 ：login:Penguin：03/06/28 23:57 ID:e5oAvSuR
>>408
では聞きますが現在のADSLの最大のアップ量である１Mを最大に使ってアップしているノードが
それ以上の貢献をするにはどうしたらいいのでしょうか。
ADSLの仕様上フルに転送速度が出ることはありませんが仮にフルに速度が出たとして
アップ側１Mダウン側１２Mが出ているノードを不正なDOMノードとする事は
ノード側からではそれ以上のアップ速度をどうする事も出来ない以上不正なノードとは出来ませんよ。

4)ネットワークに入り込み、ひたすらデータをダウンロードするばかりでネットワークに貢献しないノード
についての議論を優先するという事からもアップ側が最大である１Mを確保してダウンしているノードは
>>405で書いたとおりインフラの問題でありどうしようもないということは理解されていますでしょうか。

ADSLで10:1を実現するには最大の転送速度での標準仕様がアップ１Mダウン０．１Mになりますが
そのような仕様にすることへの問題点はどう考えられますでしょうか。
413 ：login:Penguin：03/06/29 00:26 ID:Psi+mf1f
>>412
>アップ側１Mダウン側１２Mが出ているノードを不正なDOMノードとする事は
>>72や>>354の案であればこういったノードの存在は難しくなる
しかし>>72や>>354で問題点が出ている以上この案で必ずしもいいとは言えない。
また詰めていったら他に致命的な問題点が出てくる可能性もある。
詰めていってる途中にスレも読んでいない奴が匿名性を語ろうとしてたから忠告しただけ。

>ADSLで10:1を実現するには最大の転送速度での標準仕様がアップ１Mダウン０．１Mになりますが
そうじゃなくて、現在のインフラを全く考えないなら
日本にUP10M、DOWN1MのADSLが普及していると仮定して作ってもいいだろうってこと。
実際には現状、せめて少し先のインフラを考えて作るしかない。
まだまだ普及するには時間の掛かる光回線を想定するのは時期尚早ではないかと。
414 ：931：03/06/29 00:29 ID:QXs8STjy
> 404
このスレは出来てすぐから見てますし、読み返しもしてるんですがねぇ。

> 403の内容にしたってスレ読んでないのがバレバレ。
どのあたりが「バレバレ」なのか教えていただけませんか。いえ冗談です。
きりがない。

> 408
そのレベルの話なら、やはり「匿名性」の考察のほうが先だという考えに
変わりはないですね。ただし、私は興味ありませんが、他の人にDOM話を
するなとはいいませんよ。それぞれしたい話をしましょうよ。
415 ：login:Penguin：03/06/29 00:30 ID:opmlwDs4
ソースクレクレ厨のいるスレはここですか？
416 ：login:Penguin：03/06/29 00:40 ID:Psi+mf1f
>>414
>このスレは出来てすぐから見てますし、読み返しもしてるんですがねぇ。
じゃあ理解力が足りないのか。いえ冗談です。
きりがない。

>そのレベルの話なら
あんたには言ってないけど？
これと>>399で書いた「理由」は全く別、もっと基本的なことだからね。

>それぞれしたい話をしましょうよ。
本気か？
興味がないだけで他の話を進めて、邪魔になるという認識はないのかね。
417 ：login:Penguin：03/06/29 00:44 ID:k9RlU53G
>>413
>将来っていつまで待つ気かな。
こう書かれたあなたがまだ実現化かも定かではないインフラを元に仮説を立てるのはどうかと。

>実際には現状、せめて少し先のインフラを考えて作るしかない。
>まだまだ普及するには時間の掛かる光回線を想定するのは時期尚早ではないかと。
少し先のインフラを考えて作るしかないといいながら、もうすぐくるかもしれない光回線を想定するのは
時期尚早ってのがよくわからないですね。

では話の流れからこうしましょう。
あなたはそのDOM対策についてここで詰めていく。
その他の話題をしている人はそちらを詰めていく。

同時進行で二つの話題を進めてはどうかということは、あなたが過去のレスをを良く読んで
理解しているのなら既に出てきた話題ですよね。
同時に詰めて行きましょう。
そして色々な案を最後に総括すればいい話です。
418 ：login:Penguin：03/06/29 00:47 ID:Psi+mf1f
>>417
>同時進行で二つの話題を進めてはどうかということは、あなたが過去のレスをを良く読んで
>理解しているのなら既に出てきた話題ですよね。
そしてどれだけ見辛いスレになったかも理解しているよ。
419 ：391：03/06/29 00:50 ID:QXs8STjy
> 416
からみますねぇ。

> 興味がないだけで他の話を進めて、邪魔になるという認識はないのかね。
少なくともスレッドにあった話題で、自分では有用だと思う話題を書き込むことに
なんの躊躇もありませんよ。
いったいあなたはどういう理由でDOM話以外の話題を否定できるのでしょうか。
謎。

420 ：login:Penguin：03/06/29 01:01 ID:fgtjRn4Q
もうちょっと推敲したら?>all
421 ：login:Penguin：03/06/29 01:09 ID:YGlaZ6VR
DOM対策について

　データを転送共有することによってデータの拡散を行い、一極集中となるサーバークライアント方と異なる
ネットワークシステムP2Pを実現するという目的において、DOMの存在はネットワークの障害になる。
　よってDOM対策は必要。

匿名性について

　各々のノードは、それぞれの記憶領域を提供することによって、共有ネットワークを実現する。
　しかし、各々の共有領域は全体のものとして使う反面、個人のものでもある。各々がどのような
目的で何をしているか、などつかめる状態はプライバシーの侵害であり、自由な行動の制限となる。
　そういったことが起きないために、匿名性を維持する必要がある。


　この二つの問題は、ともに重要な問題であり、表裏をなす問題でもある。
　くだらない言い争いをするより、両方の話を平行して進めるほうがよっぽど有意義。
　DOM対策のために匿名性について考える必要もあるだろうし、匿名性のために
DOM対策について考えてみる必要があることもあるだろう。　
422 ：391：03/06/29 01:26 ID:QXs8STjy
私のスタンスについて、少し説明させていただきます。
興味の無い方ごめんなさい。

私がなぜDOM話より匿名性にこだわるのかといえば、かりに今のWinnyが
オープンソース化された場合に匿名性が不足しているのなら、やはり
Freenetや354案のようなシステムにする必要があるかもしれません。
この場合いまのDOM話の前提がまるで違ってしまいます。
だからといって、もちろんDOM話をするなとはいいませんが。

他にも検討すべき事柄がまだまだあると思います。仲良くやりましょうよ。
423 ：login:Penguin：03/06/29 01:50 ID:opmlwDs4
永遠にオープンソース化なんてありえませんな。
クレクレ厨ウザイよ
424 ：login:Penguin：03/06/29 01:53 ID:k9RlU53G
>>422
>>354の5)については今のWinnyのシステムで解決できる問題であるし
1)から4)に関しても各ノードとそれぞれのファイルの匿名性が確保できれば全て解決できる問題だと
認識しています。

しかし匿名性とは関係なく4)の問題が重要であるとするなら
アップにあまり貢献しないでダウンだけするものは許せない、という感情論ではないかと思ってみたりしてます。

DOMの話と匿名化の話、どちらをするかというところで留まっていると話しが進まないので
どちらの話題も平行して実現可能な具体的な話題に移って行く事が近道だと思われます。

そうしないと両案の具体的な解決策がそれぞれ出ているのにそれぞれについての検討についての話題に
移行できない現状は時間だけが過ぎていき問題の解決へ近づける為の議論が中断してしまう結果になっているような気がします。
425 ：login:Penguin：03/06/29 03:18 ID:qpf1h6Bx
>>391
私も>>138を読んでまずいなと感じたので、それを回避できる354案がいいなと思うのですが。
Winnyでまともに運営できる程度の転送率ではファイルと所持者IPの対応がかなり推定される
と思います。確実ではないですが、あまり気持ちのよい状態ではないでしょう。
それに、大量にIP詐称キーを流されると、まともなファイルのやり取りすらできなくなります。
さらに、いったい誰がやったのか、特定することはできず、ネットワークから排除することも
できないと考えます。
この点で、354案は攻撃に対する強さがあると思うのですがどうでしょう。

>>424
DOM対策といわれていますが、ユーザサイドでどういう比率かは正味どっちでもよくて、
ネットワーク全体としてUP＜DOWNには絶対になりえないことが問題です。
誰かがUpしない限り、Downはありえません。ネットワーク自体が成り立たなくなるのです。
そのため、
MXでは、自分で(人間が見張って)なんとかする。
Winnyでは、40k程度1枠としてUP+2でシステム上制限。
72案では、周りの人に評判を聞いてみて、自分が判断して制限。(Winny風)
354案では、挙動不審な人には制限。(MX風)
などが考えられていると思うのですが、いかがでしょう。
426 ：login:Penguin：03/06/29 03:21 ID:opmlwDs4
Linuxで動いても誰も使わない罠。
427 ：login:Penguin：03/06/29 03:31 ID:/k74ddZw
ソースオープンにするってことはWinny以上の匿名性を実現するメカニズムを入れないとだめってことだ。
ソースが閉じてるからそれなりの匿名性たもちつつ速度が保たれているわけだから、
オープンソースにすると今度は速度が犠牲になる罠。
428 ：login:Penguin：03/06/29 03:32 ID:/k74ddZw
そしてそれはFreenetと何も変わらない。
Freenetの高速化でも考えた方が現実的ちゃうか？
429 ：login:Penguin：03/06/29 03:34 ID:/k74ddZw
つまり、

オープンソース、回線速度、匿名性

どれを取るのかってことだ。全部実現できればいいわけだがWinnyやFreenetを超えるものを作らんといかんな。
430 ：login:Penguin：03/06/29 03:35 ID:qpf1h6Bx
>>411
転送について

チャンクを要求されて、実際は持っていない場合、どのくらいの割合でほんとにないと
返答するのだろうか。
他のノードに問い合わせて、返事が返ってくるまで、要求ノードを待たせる？

あきらめて他のチャンク探しにいったとき、ファイルが大きい場合、あるチャンクの存在を尋ねて、
再びそのチャンクの存在を聞くまでにかなり時間がかかるかも。
ノードをチェックしておいて、次接続がかかったら、さっき聞いてたの入荷しましたよとか
答えるほうが効率いいのかな。
431 ：login:Penguin：03/06/29 03:48 ID:opmlwDs4
オープンソース化したら、真っ先に警視庁のハイテク科に餌食にされそう
432 ：_：03/06/29 03:52 ID:tfH50UOX
http://homepage.mac.com/hiroyuki44/
433 ：_：03/06/29 06:49 ID:tfH50UOX
http://homepage.mac.com/hiroyuki44/
434 ：_：03/06/29 08:28 ID:tfH50UOX
http://homepage.mac.com/hiroyuki44/
435 ：login:Penguin：03/06/29 14:16 ID:k9RlU53G
>>425
>ネットワーク全体としてUP＜DOWNには絶対になりえないことが問題です。
>誰かがUpしない限り、Downはありえません。ネットワーク自体が成り立たなくなるのです。
UP＜DOWNになりえないという情況というのが
アップするファイルの数＜ダウンするファイルの数、という事になってはいけないという事でしょうか。

Winnyのようなファイル共有ネットワークはネット上に仮想の巨大データベースがあるようなものです。
その共有されたデータベースの総量が何テラなのかまたそれ以上の単位になるのかわかりませんが
ネットワーク上で共有されているデータ以上のファイルを自分のローカル環境に持てる筈もなく

自分がまだ持っていないファイルをダウンしようとすればいつかは
アップするファイルの数＜ダウンするファイルの数、という情況になる事は明らかであり
現在150G分のファイルを公開しているノードであったとしても
ダウンしたファイルの総量が150Gを越えた時点でUP＜DOWN となるノードになってしまうわけです。

ですからUP＜DOWN であるだけでそのノードを
不正なノード又は貢献していないノードと決め付ける事には無理があります。

>誰かがUpしない限り、Downはありえません。ネットワーク自体が成り立たなくなるのです。
匿名性が高いネットワークであれば誰もアップしないという情況がありえないのは
現在のWinnyの高い匿名性が支持されて爆発的にファイルの共有が増えつづけている事からも明らかです。

Winnyをオープンソース化する為の仕様をどのような物にすればいいかはまだ議論中ですが
もし現在のWinnyよりも匿名性の低い仕様になったとしたらオープン化されたそのWinnyは廃れていく事になるでしょうね。

もしそうなりそうなのであればオープン化すること自体をあきらめるべきではないか考えています。
436 ：login:Penguin：03/06/29 14:49 ID:wsrrFCsT
匿名性を証明するスタブでも作ってから言えよ。
おまえらのしてることはクレクレ厨と変わらない。
どのみち現在のWinnyとは互換性ないんだから
オープンソース化は無意味だが。
437 ：login:Penguin：03/06/29 15:24 ID:Okl07V0G
>>435

>ネットワーク全体としてUP＜DOWNには絶対になりえないことが問題です。
>誰かがUpしない限り、Downはありえません。ネットワーク自体が成り立たなくなるのです。

　これの意味するところは、アップロード能力の総数＜ダウンロードの結果という意味でしょう。
この意味では正しいです。理想はUP=DOWNですが、そうはなかなかなりにくい。

　従来のサーバークライアント方では、UPは常にサーバーの能力で絞られます。P2Pでファイル
共有をする場合には、UPは論理的最大値としては参加しているノードのアップロード能力の総和
となります。これによって、サーバークライアント形式より、よりデータのやり取りがしやすい
構造を作り出すことを目的としているともいえます。

　この目的を達成するためには、ここのノードはUPデータ量≧DOWNデータ量を実行しなければ
なりません。

蛇足
　150Gのデータを持つノードが150Gの転送をした段階でアップロード不要にはなりません。その
データを求めるノードが1000あれば、そしてダウンしたすべてのノードがすべてDOMノードであった
なら、150000Gの転送を要求されることになります。ダウンしたノードのすべてが優良ノードで
理想的な状態なら、1500Gの要求を受けるだけですみますが。
438 ：login:Penguin：03/06/29 15:52 ID:xt4WHg2a
Freenet を C で書き直したら、速度速くなるかなぁ?
速くなるんだったら、やるけど。
439 ：login:Penguin：03/06/29 16:01 ID:4nZERqq/
むしろFreenetのいけてるﾌｧｲﾙ共有ﾌﾛﾝﾄｴﾝﾄﾞきぼん。
440 ：login:Penguin：03/06/29 16:28 ID:LERGS0vL
>>438
是非やってもらいたい。
転送速度はわからんけど、動作は間違いなく速くなる。
>439も是非。ｸﾚｸﾚですまん
441 ：login:Penguin：03/06/29 16:29 ID:2k66C4Y4
重いのはHDDアクセスや暗号処理だろう。
しかし通信速度はFreenetじゃどうやっても早くならないはず。
チャンク物切れや隣への無差別プッシュをやめて中継を必要最低限にすべきだろうが
それやるとnyになる罠。
442 ：login:Penguin：03/06/29 16:51 ID:fgtjRn4Q
ﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙ
ｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰ
ﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌ
ﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟ
ﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙ
ｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰ
ﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌ
ﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟ
ﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙ
ｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰ
ﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌ
ﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟ
ﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙ
ｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰ
ﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌ
ﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟ
443 ：login:Penguin：03/06/29 18:56 ID:nb81qkZW
>>435
>もし現在のWinnyよりも匿名性の低い仕様になったとしたらオープン化されたそのWinnyは廃れていく事になるでしょうね。
そうは思いませんね。

低いというのがどの程度なのかは分かりませんが
匿名性のかけらもないMXですらnyを数倍も上回る人が使用しています。

今のnyをそのままオープンソース化してもDOM対策が出来ていれば
十分に利用価値があると思います。

nyの主要な機能である中継者かUP元か「確実」に判別出来ない
というだけでかなりの匿名性を保持できるでしょう。

もちろん匿名性を確保できるに越したことはありませんが、
オープンソース化の利点を考えたら
>オープン化すること自体をあきらめるべきではないか考えています。
これを支持することは出来ません。
444 ：login:Penguin：03/06/29 19:50 ID:wsrrFCsT
Linux厨＝ｸﾚｸﾚ厨
445 ：login:Penguin：03/06/29 20:04 ID:9BhMF5/R
>>444
ｵﾏｴﾓﾅｰ
444getおめでとう。
446 ：login:Penguin：03/06/29 20:35 ID:k9RlU53G
>>437
各ノードのアップロード能力の差への現在のWinnyの考え方は47氏がかつて述べた所によると
１．回線が早いと自動的に神状態（大量のダウン要求がくるけど勝手に持ってけ状態）になるが
　　ダウン速度はHDDが大量にあればそれほど下がらないはず（キャッシュが効くから）
　　よって、回線が早く上流の位置にあたるホストは、無条件でキャッシュに
　　人気のあるお約束ファイルが溜まっていく。
　　高速回線でHDDに余裕があるノードは、暇なときに回線に繋ぎっぱなしにしておくと
　　暇なときに自分のキャッシュに検索かけた時にさくさくファイルが見つかる可能性が高い。

２．回線が早いのにHDDが無い（キャッシュを小さく設定）にしていると
　　昔一度読んだデータでもまた他からダウンしにいくので、ダウン速度が下がる。
　　よって基本は、太い回線者ほどキャッシュフォルダを大きくとったほうがいい。

３．回線が細い人はDOWN専用になってまず転送に加担しないが、貴重なファイルを持っていると
　　高確率で吸い出されて行く。
　　貴重なファイルを持っているほど検索速度やダウン効率が高くなるようになる。

４．基本は、回線太い人がよく見かけて大きいファイルを分配させる人になり
　　回線細い人はあまり見かけないけどリクエスト受けやすいファイルを提供する人に役割分担される。

ダウンされる事と中継にはこのように利点があったと記憶してます。

UPデータ量≧DOWNデータ量を実行するには自分がダウンした物を全て公開キャッシュとして
取っておけば可能です。
その為にはWinnyをやり続けている間、無尽蔵にHDの増設と大容量化を繰り返していかなければなりません。
一切のキャッシュを消す事をせず、既に賞味期限が切れ必要のなくなったかつてのキャッシュも
全て取っておけば可能でしょう。

蛇足についてですがオープン化する事で自ノード以外すべてDOMノードばかりになってしまった時は
その対策が取れていないままオープンソース化されたWinnyであったなら何も落ちてこないでしょうね。
そのような状態で公開してしまったら最悪です。
そういう事体ならない為のメカニズムについて考えるのがここですし。
447 ：login:Penguin：03/06/29 20:38 ID:k9RlU53G
>>443
匿名性が低くていいのならMXを使う方が現実的ですね。
448 ：login:Penguin：03/06/29 21:06 ID:xD/JTIPi
MXのオープンソース化を考えるスレ
449 ：login:Penguin：03/06/29 21:07 ID:5YC2VqaE
改正著作権法が執行されても自由を維持できるくらいの匿名性は必要だろな。
450 ：login:Penguin：03/06/29 23:00 ID:nb81qkZW
>>447
>匿名性が低くていいのならMXを使う方が現実的ですね。
意見が合わないようですね。
この話はこの辺でやめておきます。
451 ：login:Penguin：03/06/29 23:03 ID:oa9iimYc
>UPデータ量≧DOWNデータ量を実行するには自分がダウンした物を全て公開キャッシュとして
>取っておけば可能です。
かなり勘違いしているようですね。
452 ：login:Penguin：03/06/29 23:37 ID:wOKBqyLu
なにやら紛糾してますねえ
>>354の案も別に強力な匿名性を得られるものでもないと思いますが。管理責任が少し軽くなるかな、
というぐらいでしょう。個人的には分割する意義がイマイチ感じられません。
453 ：login:Penguin：03/06/30 00:39 ID:w/HMBlGM
>>452
　IPネットワークにおいて、強力な匿名性を得る手段としてどのような方法があると考えますか？
　また、どの程度の匿名性を実現すれば実用的といえるでしょうか？
454 ：login:Penguin：03/06/30 00:45 ID:w/HMBlGM
>>453
　キャッシュの分割は、おっしゃるとおり責任の分割です。それ単体で意味を持たないパーツ化します。
　また、ロジックの簡易化も目的としています。
455 ：login:Penguin：03/06/30 01:12 ID:wzuAkgD7
>>454
>キャッシュの分割は、おっしゃるとおり責任の分割です。
わたしは責任を逃れるためのシステムには反対です。
らくに情報を発信するためにnyを使うべきです。
456 ：login:Penguin：03/06/30 01:38 ID:b+bVp9Qm
デコード可能なファイルを中継する行為が違法なのは当たり前。
中継ってのははダウンロード＆アップロードすることで
アップロードが違法にあたるわけだ。
なので中継か直かの区別はナンセンス。
457 ：login:Penguin：03/06/30 01:43 ID:w/HMBlGM
>>455
　楽に情報を発信するためだけであれば、FTPサーバーを立ち上げるなど方法があるでしょう。
　クライアントサーバ形態の負荷分散であればミラーサーバーを立ち上げることもできます。
　ただ、このP2Pネットワークは他のノードの協力によって成り立ちます。この協力に対して
あなたが負うと同じ責任を押し付けることはできません。よって、協力するものは責任を負う
ことなく協力できる構造を作成する必要があります。
　自分が良いから、他人のことは考えない。これはDOMと同様の考え方ですので
そのような考えの方は、P2Pを使用しないでいただきたいと思います。

　言葉遊びによって否定的なことを言う香具師はDOMのできないシステムを
好ましいと思っていないのだろうが、作れるものはしょうがない。
458 ：login:Penguin：03/06/30 01:48 ID:WL4DxTIj
>>452
354の案は、ファイルを分割することにより単体で何であるか判別できないように
できるという利点と共に、システムとして、あるファイルが「どこに」あるかを一切
提供しないという案であると思います。

ｎｙの検索システムであれば、元であるか中継であるかはわかりませんが
確実に取って来れる場所というものが明記されています。
それに対し354案は、となりにあるものとして取ってくる、という動作なので、
自分の隣以外は関係なくなります。接続すればIPアドレスはバレバレなので
それはしょうがないとして、それ以外の場所を原理的に知ることが意味を持たない
というのは匿名性、および攻撃耐性につながるとおもいますがどうでしょう。
459 ：login:Penguin：03/06/30 01:56 ID:b+4U+rtq
>>457
縦
460 ：login:Penguin：03/06/30 02:10 ID:w/HMBlGM
>>459
　あちゃ、馬鹿に引っかかってしまったのか

　とはいえ、必要なことは記述できたので、まあよしです。

　でも、いくらなんでも馬鹿すぎる話は疑ってかかるようにします。
461 ：login:Penguin：03/06/30 18:29 ID:KV6XW+0L
w/HMBlGMってほんとに煽りが好きだな
以前注意されたのに全く懲りていない。

どうやらスレよりも糞みたいなプライドを守る主義のようだが。
462 ：login:Penguin：03/06/30 19:12 ID:l8TteOz9
>>456

206 名前：[名無し]さん(bin+cue).rar 投稿日：03/06/25 23:41 ID:dRVOe0vy
http://headlines.yahoo.co.jp/hl?a=20030625-00000991-wir-sci
Winnyに違法性はなさそう

213 名前：[名無し]さん(bin+cue).rar 投稿日：03/06/26 12:37 ID:hlEx0hJE

>Winnyを起動している別の誰かのPCをキャッシュサーバとして利用することで、
>あるファイルを誰がアップロードしたのかを追跡困難にする仕組みを取り入れている。

インターネット上でプロ串を通して何らかの違法ファイルをやり取りしてそのキャッシュが
プロ串に残ったとしてもプロ串自体に違法性は問えないんじゃない？

>ソフトウェア自体に違法性を認定した場合、その判例は拡張され、
>最終的にはコンピュータやネットワークの存在それ自体が違法化されかねないものだったから。
>Winnyを含むP2P型ファイル交換ソフトウェアについて否定的な見方をする人たちがいる一方で、
>今のところ、その存在自体は違法なものではない。

結局Winnyのように他のPCをキャッシュサーバとして使って転送するものを無理に違法化しようとしたら
インターネットそのものを違法としなければならなくなるから難しいらしいね。
463 ：login:Penguin：03/06/30 19:47 ID:FooJfKOQ
>>462
　Nyが違法かどうかといった問題は、
　アップロード自体が違法だなんていってる>>455の例にもあるとおり一笑ですむはなしです。
　すでに幾度となく、繰り返されている話。

　相変わらず、作られるのがいやな香具師が頑張っているようですが、きにしない、きにしない。

>>461
　煽られたことはあったが、煽った覚えはないんだけどね。
　で、宿題は出来たの？糞ほどのプライド無いから宿題なんてわすれてるか(笑)。
　もっとも、糞ほどのプライドも無い香具師を煽るのは不可能だよな。

　で、煽りってこれでいいのかな？でも、煽りにならないのが実に残念(笑)
464 ：login:Penguin：03/06/30 19:50 ID:FooJfKOQ
>>461

　あ、そうか。バカといわれて>>461が反応しているって事は、煽りに成功したって事になるのか！！

　これは、大笑い。気分よくデバッグできるぞ(^_^)
465 ：login:Penguin：03/06/30 20:29 ID:7Yj/PF2p
>>461
>>463
いったい何の話ですか？？？
煽って注意されたってことは535かな？

煽られたというのもうなずけますね。
466 ：login:Penguin：03/06/30 20:43 ID:/yoiIztl
464氏=354氏

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!!!
467 ：login:Penguin：03/06/30 20:46 ID:Yc04vdyz
354氏=535氏

(ﾟДﾟ)ﾏｽﾞｰ
468 ：login:Penguin：03/06/30 21:12 ID:w/HMBlGM
>>465
　さて、注意された覚えもありませんが、もっとも彼が注意してくれたとしても
注意と受け止めるより煽りだと受け止めてただろうけど(笑

　ちなみに、535ではありませんよ(笑
469 ：login:Penguin：03/06/30 22:09 ID:2DHwCAIC
> 462
これに関しては
http://members.jcom.home.ne.jp/makina17/r/winny.html
のような判断もあります。

私は法律には全くの素人なので、とりあえず、最悪のパターンに対処する意味でも、
上のサイトの解釈を常に頭にいれています。

法律論を抜きにしても、私のように1の47氏の発言をオープンソース支持者に対する
挑戦状と解釈した場合、オープンソース版Winnyが現在のWinnyより劣る部分(匿名性)
を残すことを容認できません。

とは言いながら、現Winnyの匿名性の壁(特に参加者のIPアドレス収集の困難さ)は
非常に高いです。
470 ：login:Penguin：03/06/30 22:24 ID:AldNrD0z
>私のように1の47氏の発言をオープンソース支持者に対する
>挑戦状と解釈した
自意識過剰
471 ：login:Penguin：03/06/30 22:37 ID:MzgfiUoh
>>469
>とは言いながら、現Winnyの匿名性の壁(特に参加者のIPアドレス収集の困難さ)は
>非常に高いです。

高いかぁ？
472 ：login:Penguin：03/06/30 23:19 ID:l8TteOz9
>>469
そのサイトは法解釈に誤りがある。
誰でも見たりＤＬしたりできる場所に置いてあるものを見たりＤＬしたりする事について
その行為を行った者には現在の法律では違法性は発生しない。

もしその行為が違法になるのならマスメディアで違法な画像や情報が流れてしまった場合
その情報を見た者も罪に問われる事になる。

違法性が発生するのは誰でも見たりＤＬしたりできる場所に法的に問題のあるものを
公開する事なのだがWinnyの場合はそれを行った人物は特定できないので無問題。

その情報が中継される事に関してはキャッシュ串を通してなんの情報を得ようとも
中継したキャッシュ串自体が違法性を問われた事はない。
また現在のWinnyではポエムしか公開されていない。

追加
>「完全ファイルリストによる検索無しシステム」というアイデア
完全ファイルリストが常に見れる状態にするには何らかの中央サーバが必要となる。
473 ：login:Penguin：03/06/30 23:36 ID:0v7W8kLa
>>472 もういっかい真紀奈さんの文章を読み直してくださいな。
474 ：login:Penguin：03/06/30 23:48 ID:2DHwCAIC
> 470
これは実際に47氏がそう考えていると言っているわけではなく、47氏の発言で
わたし自身がWinnyのオープン化に挑戦したくなったということを
ああいう表現にしただけです。

> 471
あれっ、できるの?
だとすると話は簡単になるんだけど。

> 472
上に書いたように法律は知らないので議論はできません。ただ性格的に
なにごとにも簡単には楽観できないだけです。

> 完全ファイルリストが常に見れる状態にするには何らかの中央サーバが必要となる。
これについては別稿にかきます。
475 ：login:Penguin：03/06/30 23:50 ID:AldNrD0z
>>469
>とは言いながら、現Winnyの匿名性の壁(特に参加者のIPアドレス収集の困難さ)は
>非常に高いです。
なるほど、よく考えてある文ですね。

確かに現Winnyで参加者IPの収集は困難だけれども、
>>354案を採用した場合は必然的に複数ノードへDL要求することになり
違法だと判定しているファイルをハッシュ指定などすれば、
正常な動作、つまり不正なファイルをUPしているノードを簡単に見つけることが出来る。
476 ：login:Penguin：03/06/30 23:54 ID:FY4xlZAX
ここにいるﾔｼは語ることしかできねーのかな。
とりあえず書き始めればいいと思うんだけど。

まずはnyクローンでいいんじゃねーの。
少し組み立ててから、討論しなきゃ意味ないでしょ。

俺？俺はSEだから無理。
まぁ、ネットワークは専門なんで、俺なりに考えてみるかな。
477 ：login:Penguin：03/06/30 23:57 ID:MzgfiUoh
>>474
ほい
ttp://www.netarc.jp/doc/20030616p2p.html
それと、>のあとにスペース入れんでくれ
478 ：login:Penguin：03/07/01 00:15 ID:U16umlTI
>>476
ここはWinnyのオープンソース版を作るスレではなく
その実装不可能性を「考える」スレだと何度言わせれば・・・
479 ：login:Penguin：03/07/01 00:26 ID:WQxEK+38
>>478
ああ、なるほどね。
スラドから渡ってきて1から追いかけたんだが、最新50を読む限り
オープンで作りたそうな感じになってるんで、勘違いしてたよ。

俺は実装可能だと思うけどね。
まずはモデリングでもしてみるかな。
480 ：login:Penguin：03/07/01 00:35 ID:cHSprU71
>>476
　　　　　　∧＿∧
　　　　　 （　´Д｀）＜ >>476応援揚げ
　　　　　／ 　　　＼
　　＿＿| | 　 ２ 　| |＿_
　 ＼　 ￣￣￣￣￣　　 ＼
　　||＼　　　　　　　　　　　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||
と思ったが期待薄
481 ：login:Penguin：03/07/01 00:37 ID:yJnqGhoC
>>479
記事でも載ってた？
482 ：login:Penguin：03/07/01 00:52 ID:Fl0HL3fQ
>>477
なるほど、どういうプログラムを使ったのかかわかりませんが結構
あつまりますね。単にtcpdumpのログからIPアドレスひろっただけだったりする?
だとすると、この点でFreenetタイプより優れているということもない
ですね。

>それと、>のあとにスペース入れんでくれ
失礼、navi2chだとこれでリンクされるようだったので。
といいつつmozillaで書き込み。

>>475
345ではありませんが、この手のシステムではひとつのノードからは、あるファイルが
存在するのは隣接するどれかのノードの方ということしかわからないので、実際の
UP元まではたどりにくいと思われます。
483 ：login:Penguin：03/07/01 01:12 ID:WQxEK+38
>>481
いや、お決まりのP2Pネタにこのスレが貼られてただけ。
なので、別にここをROMってたわけでもなく、ここに来てまだ1時間ぐらい。

それと、煽りでも釣りでもないんだが、
論議(特に技術なお話)のレベルがやたら低くないか？
学生が多いのかな？
少なくとも、本職ではない匂いがプンプンするんだけど。
484 ：login:Penguin：03/07/01 01:56 ID:Fl0HL3fQ
「完全ファイルリストによる検索無しシステム」について

これはFreenetのような形態でのファイルの取得を効率化するものです。
各ノードは複数のノードと接続を持ち、その隣接しているノード以外とは
通信を行いません。

このリストの中身はハッシュ値(ファイルを識別するユニークなID)だけで
実際には「完全」ではなく、帯域とノード間距離を換算してリストサイズの上限が
きまります。

あとは基本的に自ノードが認識しているファイルリストを定期的に(例えば10分ごと)
隣接ノードにおくるだけです。

ファイル要求は蓄積されたリストから選択し、そのリストを送って来た
ノードに要求をだすことで確実にファイル所持者までたどれます。

この手のシステムで検索するにはマルチキャストにならざるを得ないので
効率も悪いし帯域も浪費しますが、このアイデアによりかなりの効率化が
期待できます。

以上ですが、わかりにくいかな。
485 ：login:Penguin：03/07/01 03:19 ID:ibuqU07B
>>479
　可能なことですよ。

　ここで不可能とかいってる香具師は、DOMが出来ないシステムが出来ることを恐れている
香具師です。

　期待期待
486 ：login:Penguin：03/07/01 03:27 ID:ibuqU07B
>>475
　揚げ足取り(w

　リクエストをしたことにより、そのノードがリクエストをしたノードが「違法と思うデータ」を将来的に保持することになります。
　そのノードにデータがあるかの確認のためにアクセスしたことが、さならるデータの拡散を招きます。
　そのノードが、その情報をもっているとは確定できません。持っていないといっても、持っているかもしれませんし、
持っていないといっても、持っているかもしれません。
　ただ、リクエストしたら、将来いつかもつことになるかもしれません。
487 ：login:Penguin：03/07/01 13:03 ID:cHSprU71
>>483
http://pc.2ch.net/test/read.cgi/linux/1053087824/882
>882 ：47 ◆KbtLZwerNc ：03/06/19 08:50 ID:AhStOI42
>Winny作者ですが
>
>あれがクローズドシステムになっているのは、好きでそうしているわけではなく、
>こちらの設計能力不足によるものですので、もしオープンソースでも問題ないメカニズムが
>導入できるのなら、こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。

ソースをオープンにする場合に考えられる問題点とそれについての解決策を
具体的な技術のお話を交えて披露していただけませんか。
488 ：login:Penguin：03/07/01 13:32 ID:s11Chu7x
わざわざクローン作らんでも本家が条件クリアできれば公開してもいいって言ってるんだから
後は条件クリアするだけでしな。
489 ：login:Penguin：03/07/01 17:21 ID:ibuqU07B
檄文

　Winnyが現状の構造のままでオープンソース化することは出来ない。
　次世代のWinnyの開発は一人で行うのにも無理がある。

　よって、現在のWinnyと互換性はないものになるかもしれないが、オープンソースなり
他の方法なりにせよ、開発を大規模化する必要がある。

＞とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので、考えるのだけはよろしくお願いします。

　求められているのは、考えること。
　どうしたら実現できるかのアイディアを出し、そのアイディアの穴を探し、再検討をして穴をふさぐ。
　現実的で実現可能なロジックが出来れば、コード化することは困難ではない。

　オープンソースのメリットは、一人の人間が考えることによる思考の限界を複数の人間によって
突破することと開発能力の人的資源の確保。

　P2Pを利用したサービスはいろいろと考えられる。その大海に出て行くには小さな船では心もとない。
しかし、乗り込んだメンバーがそれぞれの力を尽くしサバイバルを乗り越えれば新たな大陸を見つける
こともできる。乗客は要らない。
490 ：login:Penguin：03/07/01 18:16 ID:Kr6ZVKoX
ｲﾀﾀﾀ
491 ：login:Penguin：03/07/01 18:53 ID:xNxeVq8j
>>489
P2P ｵｰｸｼｮﾝ ｷｳﾞｫﾝﾇ
492 ：483：03/07/01 21:55 ID:WQxEK+38
>>487
あのさー、「こちらの設計能力不足」とは、Winnyはオープン化を
想定しないで設計しているということでしょ。どうやって、
閉じたソースの「オープンにする場合に考えられる問題点と
それについての解決策を具体的な技術のお話を交えて披露」
できるのかね？まぁ、nyのメカニズム自体はみなさん
想像できてると思うけど、具体的な技術論は展開できないよね。
だから、nyクローンを作ることを想定して、モデリングしようぜ
と言ってるわけなのさ。

で、>>487
あのね、分かってると思うけど、「設計」が一番難しいわけなのよ。
(これ、釣りだよね。真面目に語ってないよな？)
「現実的で実現可能なロジック」を思いついては書き出して、
その現実性を確かめないと、どうやって「考えたこと」が
現実的だと判別できるのかね？

なんか、俺、煽ってるカンジなんで、書かない方がいいのかな？
デスマーチ真っ最中で、最近は性格きつめだしね。
493 ：login:Penguin：03/07/01 22:04 ID:42y6vZ+A
「匿名のP2Pに弁護の余地なし」と米連邦控訴裁
http://japan.cnet.com/news/media/story/0,2000047715,20059481,00.htm
494 ：login:Penguin：03/07/01 22:55 ID:ibuqU07B
「ファイル交換ツールは合法」との裁定に驚きの声
ttp://japan.cnet.com/news/media/story/0,2000047715,20053985,00.htm
495 ：login:Penguin：03/07/01 23:06 ID:+vgqbIz4
だいぶと荒れてきましたねぇ

354さんも何処かへ行ってしまったようですし
テストベンチの作成に忙しいのかな
496 ：login:Penguin：03/07/01 23:43 ID:q46Dfj+J
まあ実際「考える」段階で既に頓挫しているわけだが(苦笑)
497 ：login:Penguin：03/07/02 00:46 ID:s6UDSLAz
>>496
その前に法律の問題をクリアしておく必要がありますし
その前に47氏が本当にWinny3以降行き詰るかどうかを
見届けないといけないので頓挫というよりも
このスレはいささか先走りすぎているという気がします。
ここは議論を差し戻して足元からしっかりと
固めていくべきではないでしょうか。
498 ：login:Penguin：03/07/02 00:54 ID:UgTqDi+v
宿題もやらないようなアホしかおらんしな
499 ：login:Penguin：03/07/02 01:15 ID:WhgTo52d
誰も何も考えてないな。
ここの連中はただソースが欲しいだけ。
487はその典型
500 ：487：03/07/02 01:59 ID:5reUV9Aa
>>492,479=476？
SEでネットワークは専門だという前提でお聞きします。
実装可能だと言われていたので問題点の把握と解決法がわかるのだろうと思いました。
技術のお話のレベルがやたら低くないか、という事でしたので技術のお話について
ご教授していただけると思ったのですが。。。

>あのさー、「こちらの設計能力不足」とは、Winnyはオープン化を
>想定しないで設計しているということでしょ。
これについてですが47氏が設計からβバージョンの公開まで約一ヶ月で公開してきた事を考えると
47氏の謙遜も考えられます。
つまり暗に｢オープンソースで問題のないメカニズムは導入できないのでは｣と考えているようにも受け取れます。
しかしそう解釈してしまうとオープンソース化を考える事は無意味な物になってしまうので
本当に無理なのかをこのスレで考察中です。
そして無理である事が証明されてしまえばこのスレの存在自体が終了となってしまいますので
是非ともご協力を。。。
501 ：487：03/07/02 01:59 ID:5reUV9Aa
>どうやって、閉じたソースの「オープンにする場合に考えられる問題点と
>それについての解決策を具体的な技術のお話を交えて披露」できるのかね？
では私がソースが全てオープンされた場合に考えられる問題点をいくつかあげてみましょう。

ソースを元に改造する事が容易になることで一番最初に考えられるのはこのスレでよく話題になる不正ノードの出現です。
・UP0パッチ、UP0の状態でのDL枠の拡大。
・隣接するノードの解析を主目的とした改造。
・キャッシュファイルに何を持っているかの明示化。
・DL完了と同時のキャッシュファイル削除の自動化。
・DL中のキャッシュの他ノードへの転送の無効化。
・どのノードから何をDLしているかのリアルタイム表示。
・どのノードへどのキャッシュをUP中かのリアルタイム表示。
・転送が発生せず直接UPしている事を証明する為の何らかの改造。
列挙すればキリがないほどの問題点があるわけです。
502 ：487：03/07/02 02:00 ID:5reUV9Aa
これらの一つ一つについてどういう設計ならそれぞれの改造を行われてもWinnyのネットワークが崩壊しないかを考察する時
現在のWinnyのソースが全て明らかになっていなくても一つ一つについての技術論は出せるのではないのでしょうか。
そしてそれらの案が47氏が見ても穴のないものであった場合、47氏によってソースをオープンにする前に密かに実装テストされ
全ての問題が解決できたと判断されればそれらの案が実装されたWinnyがソースごとオープンにされるかもしれないという事です。
最後になりますがオープンソース化の最大の懸念はWinnyの通信部分のプロトコルがわかってしまう事ではないでしょうか。

>「現実的で実現可能なロジック」を思いついては書き出して、
>その現実性を確かめないと、どうやって「考えたこと」が
>現実的だと判別できるのかね？
個別のケースについてそれ検証可能な「現実的で実現可能なロジック」を組めるのなら
ぜひお願いします。
503 ：login:Penguin：03/07/02 02:06 ID:3lfalxH2
○
結論：Winnyのオープンソース化は不可能

------------------------終了--------------------------------
504 ：login:Penguin：03/07/02 03:16 ID:UgTqDi+v
ヴァカ？
505 ：login:Penguin：03/07/02 07:15 ID:8mViBT1y
これは簡単。47氏がWinnyをオープンソースにできないことを証明して欲しいんでしょ。
直感的にはすぐに分かるがなぜかは議論してもらわないと示せないし。
506 ：login:Penguin：03/07/02 14:44 ID:jSbp4B2K
>>505
　直感的に解るって、あなた、だったら私には直感的に出来ると思いますよ。
　もっとも、出来ると思っている人は議論に参加するけど、出来ないという人はなぜ出来ないか
議論に参加することも無く、「できないからできない」としか云ってない。
　単に、「できないことにしたい」だけですかね。
　できないといっている人ほど、実は出来ることを知っているのだろうか？
507 ：login:Penguin：03/07/02 16:34 ID:jdRnFbUE
そうだよ、DOM抑止の方法なんて皆気づいてるよ。
ノード評価にこだわってややこしい認証を持ち出しておおよそ
健全なネットワーク形成できないようなプロトコルを妄想談義してる君らを
せせら笑ってるのさ。
508 ：login:Penguin：03/07/02 17:21 ID:pIrRqhNz
簡単だろ。
up0標準にして1対1のチャットを可能にする。
そんでファイル鯖作ってお互いの共有を覗けるようにする。
これでDOM対策は完璧だろ？
509 ：login:Penguin：03/07/02 18:07 ID:jSbp4B2K
>>507
　ほー(笑
　言うだけならタダってやつですね。数学的に証明できるといった香具師と同レベルのピーだ。
　何事にも不満も疑問も感じることなく人生しあわせですね。

>>508
　根本が間違ってます。顔を洗ってなんていいません、生まれ変わってください。

　まぁ、これで「不可能」なんていう香具師のレベルも知れたってことだ。
　可能性が見えてきたよ
510 ：login:Penguin：03/07/02 18:18 ID:hlojC4LW
いいかげん、「数学的」ひきずってるヤツうざい。
511 ：login:Penguin：03/07/02 18:29 ID:2rnpohS0
ヤツの楽しみは揚げ足取りと煽ることしかないんだよ。
512 ：login:Penguin：03/07/02 19:30 ID:jSbp4B2K
>>510
　そりゃウザイでしょう。傷口チクチク。
　でも、ウザイと感じてしまうとは、不幸なことだね。
　自分の世界の中だけで万能のスーパーマンで居れば、数学的な証明だって出来るし
効率の良い方法だって実現できるんだから。周りの世界が何を言ったって、俺はヒーローって
思っていれば、幸せなのに。できたらその幸せな世界に引きこもって外部に出てこなければ
こちらも、とっても幸せになれるのだけど。

　ま、プライドが外に向いてきたって事は、多少快方に向かっているって事でめでたいかな。

　まぁ、これがウザイなんて逃げ言葉じゃなくて前向きに対応して、自らを証明できるように
なれば、全快の日もユメではないのだが。

>>511
　だってこんなに美味しそうな、揚げ物あったら満腹だって、ついつい食べたくなるでしょう。
　カーネルサンダースもびっくりな、美味しさです。
　揚げ足取られないぐらいに、じっくり煮込んだしっかりとした考え方を書いてくれれば
揚げ足なんて取らないで、まっとうに対応して挙げられるけど、底が浅くて向こうが透けて
見えるふぐの刺身みたいな書き込みではね。
　ま、俗に云う釣りなのかもしれないけど、釣られる香具師がいないと可愛そうだしな
ボランティアかも。
513 ：login:Penguin：03/07/02 19:55 ID:pIrRqhNz
>>509
ｸﾀﾞﾗﾅｲ折れの釣りにﾏｼﾞﾚｽなんぞしとらんで何か示せ
514 ：login:Penguin：03/07/02 20:47 ID:jSbp4B2K
>>513

　ｸﾀﾞﾗﾅｲ釣りなんかして邪魔しないで、とかボケておいて

　でも、ある意味正しい書き込みでもあるんだよな。そこに書かれていたものは
パッチ当てたMXだけど、それを完全無人で行えればよいのだから。

　内容に対する人の価値観まではコンピュータに入れることは出来ないだろうけど
無駄と思えることもコンピュータが代行してくれるから人間はより時間を有意義に
使えるようになる。

　ただ、最後のファイル鯖つくっての下りだけは、純粋P2Pじゃないのでイマイチ
だが、中央サーバがあるとファイル検索が簡単に作れるというのは魅力。
　このあたりの効率化とトレードオフをどうするか。問題ですね。
515 ：login:Penguin：03/07/02 20:51 ID:hlojC4LW
>>512
勘違いしてるようだが、第三者の目から見てウザイんだよ君は。
516 ：login:Penguin：03/07/02 21:48 ID:UgTqDi+v
>>515
　馬鹿の一つ覚えで、論証もせずに、「不可能」としか言わない人間も
当事者から見て、うざいんですよ。
　ただね、その馬鹿が偉そうにしているんで、信じてしまう人がいるかもしれないので
対応してるの。
　もちろん、数学的に証明されてしまえば、不可能だというのは事実なのでしょうが、
不可能だとか言ってる香具師は、数学的に証明可能だといった彼と同類で、
自分の頭の中だけでしか出来ないことを、実際に出来ると思って発言している
ピーですからね。さらに、自分を信じているから自信を持って偉そうにしている。
じつに、はた迷惑な存在です。そのくせ、持論を人に公開して崩されることを
恐れているから、たちが悪い。

　そういった香具師の口車に善良な人がのせられないことを祈っているのですよ。
　数学的に証明できるといったかれは、可能であることの証明として今後とも
語り継がせていただきます(藁

　それが、いやなら数学的に証明をするか、出来ないとはっきり言えばいい。
　もちろん、出来もしないことを偉そうに出来るといって人をだまそうとした
事実は残るがね。

　それにね、あなたが第三者だとしても、耳が痛いからうざいんでしょ(藁
　ここには当事者はいても第三者はいないのだよ。自分ひとりで偉くなれないと
他人を頼るというのも情けないよ。
517 ：login:Penguin：03/07/02 21:58 ID:99rKsszv
>>516
論証もせずに不可能というやつもｳｻﾞｲが
とくに反論もないのに人を馬鹿あつかいするやつはもっとｳｻﾞｲ
518 ：login:Penguin：03/07/02 22:08 ID:2rnpohS0
>>512
ｷﾓﾁﾜﾙ
519 ：login:Penguin：03/07/02 22:13 ID:3lfalxH2
>>503
520 ：login:Penguin：03/07/02 22:15 ID:jdRnFbUE
ここは愉快なお魚さんがいるスレッドですね
餌をあげると暴れ回って、自分の水槽めちゃくちゃにしてる姿は
みていて、とても藁えます。
521 ：login:Penguin：03/07/02 22:17 ID:onFQ9uR6
このスレでの「オープンソース版Winny」のありかたについての認識が、
1の47氏の発言の解釈によって、主に2つに別れているように思います。

1，現Winnyの部分的改良派
2，全面的見直し派

1の立場は47氏の発言中の
>今やってるWinny2のその次を考えるとどうしても一人でやっているのは限界があるわけで、
>オープンシステム化かもしくは別の方法による大規模化は避けて通れないでしょう。
に注目した「開発者のマンパワー」を得るためのオープンソーソース化で、
2の立場は
>こちらの設計能力不足によるものですので、もしオープンソースでも問題ないメカニズムが
の部分を重視したオープンソースを前提とした「再設計」が目的であるといえると
思います。

目的が1なら403で書いたような「オープンソース、クローズドバイナリ」で済む
ような気がしてなりませんが、それはともかく、わたし自身は2の立場で、
1よりの人もその立場で、議論の中身で競いましょう。
522 ：login:Penguin：03/07/02 22:28 ID:UgTqDi+v
>>517
　馬鹿の振りしている香具師を馬鹿扱いして何か問題ある
　馬鹿じゃないとこ見せれば、馬鹿扱いなんか出来ない
　ｳｻﾞｲとかいってるけど、なぜ不愉快なのか考えてみな

>>518
　１．邪魔扱いする
　２．他人の威を借る
　３．生理的嫌悪ということにして排除する

　みごとな、三段活用

　お次は、思い通りにならないかといって、アバれるのかな
523 ：login:Penguin：03/07/02 22:33 ID:hcEpAvIN
おまいら、そんな釣りくらいスルー汁！
524 ：492,479=476？：03/07/02 22:41 ID:G5bikgo3
>>521
建設的な意見だね。整理されていて分かりやすい。
俺はもちろん「2，全面的見直し派」の立場に立つよ。

ところで、このスレに常駐している連中は、
何だって47氏にすがりつくんだろうね？
オープン版がないなら、自分で一から作ればいいじゃん。
もちろん、偉大な先人の足跡(Winnyの設計プロセスや
Freenetのソースなど)は有効活用するんだけどね。
525 ：login:Penguin：03/07/02 22:41 ID:99rKsszv
>>522
だから、不可能じゃないっていう根拠を言えって
それがいえないならおまえも一緒
だからｳｻﾞｲ

頭ごなしに決めつけるの（・Ａ・）ｲｸﾅｲ
526 ：login:Penguin：03/07/02 22:41 ID:2rnpohS0
それもそうだね。
527 ：login:Penguin：03/07/02 22:43 ID:3lfalxH2
47氏を巻き込むのは迷惑だと思わないのか？
528 ：492,479=476？：03/07/02 22:54 ID:G5bikgo3
>>487
「不正ノードの出現」の解決は以下の通り。
ttp://de-co.info/freenet/icsi.html

手抜きでスマソだが、言いたいことは分かるよね。
529 ：login:Penguin：03/07/02 22:54 ID:Td8Yo/t6
一から作ればいいとか言っているけど
本当にそんなことが出来る香具師がいる？
知識と時間があり余っていて、尚且つヤル気の続く香具師。

それを誰も先頭きって出来ないっていう前例があるから、
ここは「考える」スレなんだけどな。
530 ：login:Penguin：03/07/02 23:20 ID:onFQ9uR6
「完全ファイルリストによる検索無しシステム」改め
「完全ファイルルーティングによる検索無しシステム」について補遺

システムの名前をより機能の内容を表しているものに変えました。

>>484では、どの隣接ノードからどんなハッシュ値のファイルが取得可能かしか
説明されてませんでしたが、ユーザーが欲しいファイルを選択するための
ハッシュ値を含むファイル情報も、各隣接ノードに定期的に送られます。

このデータは帯域の負担にならないほどのサイズでやりとりされますが、
ルーティング用ファイルリストと違って、永久に有効なので時間が
立つほど選べるファイルが増えていきます。いわゆる「検索」はローカルに
存在するこのファイル情報のリストに対してだけ行われます。

>>524
おお、たのもしい。私も素人ながらFreenet的システムでの効率アップについて
書いてますんで、暇なときにでもつっこんでやってください。
531 ：login:Penguin：03/07/02 23:33 ID:UgTqDi+v
>>524
　47氏が現在のWinnyの公開できない理由の設計の部分を公開されない限り
その部分の改良ということは出来ないでしょう。もちろん、その部分を公開する
ことにより現在のWinnyの脆弱性を公開することになってしまうのかもしれない
ので公開できないのかもしれませんが。

　改良という方法が出来ない以上、全面的な見直しということを前提にして、
ロジックを考えていくしかないでしょう。ということで私も2番の立場です。

　ただ、そのロジックが使えるものだということで、次期Winnyに採用され
Winnyがオープンソース化されることはまったく問題のないことだと考えます。
532 ：login:Penguin：03/07/02 23:35 ID:3lfalxH2
ここの人って粘着だね。
Winnyのオープンソース化なんてありえないのに。
533 ：login:Penguin：03/07/02 23:50 ID:guNtfN7g
>>532
1嫁
534 ：login:Penguin：03/07/03 00:33 ID:05VpI32v
煽りばっかで議論進んでないように見えるんだが……
場所移したほうがいいんじゃねえの?
535 ：login:Penguin：03/07/03 00:47 ID:Bl3VoMMT
>>521の2.を実践するなら
ここはスレ違いなんで丁度いいかもしれませんね。
536 ：login:Penguin：03/07/03 01:35 ID:+iO83F2a
オープンソースなんて
自分で作ってから言え
537 ：login:Penguin：03/07/03 01:58 ID:8R4IePcz
>>524
＞ところで、このスレに常駐している連中は、
＞何だって47氏にすがりつくんだろうね？

　一部の優良なテスターを除けば、テスターと称している人たちは
47氏という名の神に仕える神官のようなものです。47氏という
唯一無二の神に使えることによって自分たちの地位があるものと
信じているのでしょう。
　しかし、47氏に代わる、新たな神やテスターより上位となる（？）
47氏の協力者といったものが現れることにより自らの地位が
危うくなることを恐れているのだとおもいます。
　そうでなければ、47氏に協力するためにも、もっとアイディアを
出すとか検討するとかするものでしょう。
　まぁ、実態についてはWinnyのスレッド「MXの次は～」を見れば
一目瞭然ですが。

　47氏にしても、この板に書き込みしたのはどのような結果が出るかを
楽しみにしてのことだと思いますが、思考実験にすらなっていない
現状には、あきれていることと思います。

　前提は「出来る」。どうやって実現するかを考える。その考えに穴が
あるなら追及するのは有益な議論です。
　ただし、ただ「不可能」というのは妨害行為以外の何者でもない。
538 ：login:Penguin：03/07/03 02:26 ID:pbnKOpbH
Freenetのまずいところってなんだっけ？
539 ：login:Penguin：03/07/03 02:34 ID:AKrZzvxn
>>538
遅い

氏は単純にFreentが遅くて使い物にならないからWinnyを作り始めたと思われる。

なぜなら発言40でMXの次はFreenetだと言っているからだ。
しかし47でWinny開発宣言。今のFreenetでは使い物にならないことを良く分かっていたのであろう。
540 ：login:Penguin：03/07/03 02:45 ID:ib+7aTo3
よく口ばっかりで手が動かんと言いますが、口も動かん馬鹿ばかりでは
541 ：login:Penguin：03/07/03 03:01 ID:pbnKOpbH
>>539
どこで遅くなってるんだろうか。理想はあんな感じでいい気がするんだが
542 ：login:Penguin：03/07/03 05:26 ID:PmVJcKuV

586 名前：47 投稿日：02/04/06 18:13 ID:tI2XpLS7
ある程度中身を理解してる人もいるようで。

確かにFreenetを超えるところは無いはずですし、
いろんなものの寄せ集めで新規な所は何も無いです。

ただ、だからこそすぐに作れるわけだし
匿名性を重視するのならFreenetを使えばいいだけだし、
交換効率重視ならMXを使い続ければいいだけ。
今回のシステムのことは見なかったことにすればいい。

だからといってFreenetやMXが完全ってわけでもないわけで、
自分としては、もっとMXに近いけどFreenetの要素を含む
新システムが欲しいから自分で作るってだけの話です。

> Freenet を C で再実装するとかいうなら理解出来るけど。

もともとはFreenetクライアントがJavaで組まれてるのにぶち切れたのが
作りはじめた大きな理由なんで、その通りではありますが、
そもそもFreenetのアーキテクチャは匿名性ばかり重視して
しまっていて無駄が多いと思うんでFreenetプロトコルには準じない
（Freenetクライアントにはしない）で全部自分でやるって方針です。
543 ：487：03/07/03 07:48 ID:0/MZkSfO
>>524=492,479=476？
>何だって47氏にすがりつくんだろうね？
>オープン版がないなら、自分で一から作ればいいじゃん。

なにか勘違いしてませんか？
Winnyに良く似た新しいWinnyを作る為のスレではありませんよ。
あなたはネットワークは専門なのではないのですか。

Winnyの通信部分のプロトコルがわからない以上良く似たシステムを作ったとしても
Winnyのネットワークには繋げないという事は当然理解して書き込まれてますか？

Winnyと互換性のない新しいシステムを作りたいのならスレ違いなので
新しく別スレを立ててそちらで話し合われたほうがよろしいかと。
544 ：login:Penguin：03/07/03 10:43 ID:Sm1ItFKG
>>543

＞Winnyの通信部分のプロトコルがわからない以上良く似たシステムを作ったとしても
＞Winnyのネットワークには繋げないという事は当然理解して書き込まれてますか？

＞Winnyと互換性のない新しいシステムを作りたいのならスレ違いなので
＞新しく別スレを立ててそちらで話し合われたほうがよろしいかと。

　なにか勘違いをしていませんか？
　>>1にある47氏の発言を読みましょう。

>>1より抜粋
>こちらの設計能力不足によるものですので、もしオープンソースでも問題ないメカニズムが
>導入できるのなら、こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。
>その際には現在のWinnyとの互換性はなくなると思いますが。
545 ：487：03/07/03 12:27 ID:0/MZkSfO
>>544
Winnyのソースをオープンにする事ができるのは47氏のみです。
Winnyのソースをオープンにする事によって起こりうるかもしれない不具合が
現在のWinnyネットワークに影響を与えないようにする為に、もしオープンソース化する場合は
わざと互換性のないものにするのだと考えられます。

そのような仕様にする事でもしオープンソース化が実現したあと何らかの想定外な不正ノードや
問題点が現れたとしても現在のWinnyネットワークは影響を受けることなく存続しつづけられるので
非常に賢明で先を見越した想定であると思います。

また>>1の47氏発言にはこのようにも書いてあります。
>今やってるWinny2のその次を考えるとどうしても一人でやっているのは限界があるわけで、
>オープンシステム化かもしくは別の方法による大規模化は避けて通れないでしょう。

Winny2のその次を考える時どうしても一人でやっているのは限界があり大規模化は避けて通れないが
その方法としてオープンシステム化だけでなく、別の方法による大規模化は出来ないのかという事も
視野に入れいるようです。
一つの方法だけ固執する事のない47氏の幅広い思考がうかがえる部分ですね。
546 ：login:Penguin：03/07/03 14:30 ID:Sm1ItFKG
>>545
　ならば、とりあえず実験用のプログラムを組むことを検討するのは別に問題ない事じゃないですか。
　ロジックを考えるのは大事です。しかしそのロジックが実際に機能するか確かめなければ机上の空論に過ぎません。
　うまく動くようなら、47氏がWinnyに組み込んで（というより新たなWinnyとしたプログラムに実装)することになるかもしれません。

　47氏を神聖視化するあまりに47氏に負担をかけるのではなく、47氏のよき協力者として47氏の負担を少しでも
減らそうとは考えませんか。

くりかえします>>1より
>導入できるのなら、こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。
>とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので、考えるのだけはよろしくお願いします。
547 ：login:Penguin：03/07/03 14:35 ID:IJAWrPCP
>>545
> 一つの方法だけ固執する事のない47氏の幅広い思考がうかがえる部分ですね。
皇族の報道みたいだな。
548 ：login:Penguin：03/07/03 17:13 ID:yshaWZNq
なんかドーデモイイ内容を仰々しい文体で書く香具師ばっかだね
549 ：login:Penguin：03/07/03 18:36 ID:jtU3L2Nv
ACCSの人も大変だな
550 ：login:Penguin：03/07/03 18:39 ID:1lzCTXeO
>>487
＞わざと互換性のないものにするのだと考えられます。

（　ﾟдﾟ）ﾎﾟｶｰﾝ
551 ：487：03/07/03 19:31 ID:0/MZkSfO
>>546
あなたは>>524=492,479=476？ですか？
もしそうなら>>502でも書いたとおりです。
>個別のケースについてそれ検証可能な「現実的で実現可能なロジック」を組めるのなら
>ぜひお願いします。

>>524で書かれた｢オープン版がないなら、自分で一から作ればいいじゃん｣というのが
74氏のオープン版を出す為にオープンソースを前提とした「再設計」を考え
その検証モデルを一から作ってみるというのであればこのスレの主旨に合います。

そしてその再設計の為には今まで話し合われていたような個別の問題点の検証が必要になるわけで。
どちらにしてもSEとしての知識を貸していただきたいという事です。

>>543の本意はWinnyとは関係のないオープンソースの新しい共有システムを
一から開発し実用化しようという意味ならスレ違いだと言う意味だったのです。
もしそうであれば546が新しい神となり47氏のWinnyに縛られず独自の共有システムを開発していく方が
そのスレも盛り上がるでしょうしテスターも多くなると思ったものですから。
しかし勘違いだったのなら申し訳ない。
552 ：login:Penguin：03/07/03 20:55 ID:C7NbLLrp
「跳び跳びファイル転送」

Freenetタイプでのファイル転送はＡがあるファイルを要求した場合

Ａ＝要求ノード、Ｂ＝所持ノード、○＝中間ノード

Ａからの要求－＞
Ａ－○－○－○－○－○－Ｂ
ファイルデータ＜－

となりますが間にノードが増えるほど、速度も確実性も落ちて行きます。

匿名性は落ちますが、効率をあげるために次のように改良します。

Ａ＝要求ノード、Ｂ＝所持ノード、○＝中継拒否ノード、●＝中継許可ノード

Ａからの要求－＞
Ａ－○－●－○－●－○－Ｂ
中継ノードのIPアドレス ＜－

実際のファイル転送要求－＞
Ａ－●－●－Ｂ
ファイルデータ＜－

上記の様にＡＢ間のノードは、自分もそのファイルが欲しいとき、または
帯域に余裕がある場合にある確率で、中継を受け入れます。これにより
ＡＢ間の距離が実用的な距離まで近付くことを期待できます。

前掲の「完全ファイルルーティングによる検索無しシステム」とこの
「跳び跳びファイル転送」によりWinny並の効率を確保し得ると確信します。
553 ：login:Penguin：03/07/03 21:13 ID:ShxkB6pA
オープンソース化なんてしなくていいからLinux版バイナリで配布してくれ。
554 ：546：03/07/03 21:16 ID:Sm1ItFKG
>あなたは>>524=492,479=476？ですか？
申し訳ありませんが、違います。

　ただ、同じような考えにたどり着いた者です。というより、現状で何かしようと思えば
その方法しかないわけです。

　ところで、神はいらないでしょう。
555 ：”ヘ(￣-￣ )：03/07/03 21:23 ID:uITgZpN4
http://www.k-514.com/
ボッキンキン
556 ：492,479=476？：03/07/03 21:38 ID:sl74oCMz
>>530
>>552
同じ方なのかな。
両方とも、実際のネットワークに落とし込むと破綻するよ。
あと、大規模なP2Pクライアントを作るなら、
マルチキャストはやめよう。

P2Pクライアントの設計を考えているなら
既に読んでいるかもしれないが、
以下の本をお勧めするよ。
http://www.amazon.co.jp/exec/obidos/ASIN/4822281566/ref%3Db%5Fbb%5F1%5F27/250-7817488-4574604

freenet、JXTAは結構参考になるね。
557 ：487：03/07/03 21:45 ID:0/MZkSfO
>>554
そうですか、ではロジックの提案は>>556に頼むしかないですね。

>>556
>>502でも書いたとおり
>個別のケースについてそれ検証可能な「現実的で実現可能なロジック」を組めるのなら
>ぜひお願いします。
558 ：492,479=476？：03/07/03 21:54 ID:sl74oCMz
>>487
>Winnyの通信部分のプロトコルがわからない以上良く似たシステムを作ったとしても
>Winnyのネットワークには繋げないという事は当然理解して書き込まれてますか？

このコメントを読む限り、シロウトというわけですか・・・。残念です。
559 ：487：03/07/03 22:05 ID:0/MZkSfO
>>558
なるほど。
よくわかりました。
560 ：492,479=476？：03/07/03 22:16 ID:sl74oCMz
さーてと、俺の考えるnyオープン版。
・nyと互換(こんなのは言わずもがなだよな)
・MXと接続(これは感覚的にいけそうだが、現実的ではないかも)
・匿名性をnyより上げる(代わりに帯域をすこし犠牲に)
・いちど書いたらどこでも走る言語で実装(個人的にUMLを使いたいだけ)

47氏同様、freenetベースでいく予定。
なので、SourceForgeに逝ってきます。

ところで、nyの設計の時にMXと接続という話は出なかったのかな？
出たとしても、ドロップした推移を知りたいんだが。

俺も、年末まではnyにコメントしてたんだが、
忙しくなって追えなくなったので、そのへん知らないんだよね。

識者、情報もとむ。
561 ：487：03/07/03 22:25 ID:0/MZkSfO
>>560
Winnyと互換性のある物は47氏以外には出せませんよ。
ネットワークが専門の方なので失礼だとは思いますが念の為。
562 ：login:Penguin：03/07/03 22:40 ID:+iO83F2a
いまさらnyの互換アプリ作る意義なんてあるの？
しかも47氏に迷惑掛けてまで
563 ：login:Penguin：03/07/03 22:50 ID:C7NbLLrp
>>556
このスレでの書き込みにはメール欄に初書き込み番号をいれてあります。

>>マルチキャストはやめよう。
あれっ、マルチキャストしないシステムとして構想したつもりですが
ファイルリストのやりとりをマルチキャストと解釈したんですか。
私としてはこれは、あくまで隣接ノードとの情報交換で、あるノード
から来たパケットをそのまま別のノードに転送するわけではないので
マルチキャストではないと考えます。

>両方とも、実際のネットワークに落とし込むと破綻するよ。
>>530は>>484の付け足しで484のほうが本質なんですがこっちの方も
読んでいただけましたか。

484では、はっきり書きませんでしたが実際には「完全」なファイルリスト
ではなく、最長到達ノード距離以内のリストで、自ノードからのおおよその
距離も含みます。このファイルを見てどの隣接ノード方向にどんなファイルが
どれだけの距離にあるか決まります。

というか484案ではリストが収束しないという話?

>>552案に関しては特に問題が思いつきません。
564 ：492,479=476？：03/07/03 23:00 ID:sl74oCMz
>>562
では、オープンにする意義を分かりやすくおとぎ話風味で。

1. 当局者がひろ(ryから47氏のIPを採取、ISPを押さえて個人情報取得
2. 司法取引でnyにノードを追跡するスパイウェアを混入
3. 一斉摘発
4. 莫大な収入を得て、ﾄの治安も回復だよね

まぁ、おとぎ話ですが、ﾐｯｷｰﾏｳｽ法をよしとしている我が国でも
起き得ることだと思いますね。オープンならそこらへんのリスクを
防ぐことができる。ただ、それだけの意味だね。
565 ：487：03/07/03 23:14 ID:0/MZkSfO
>>564=>>524=492,479=476？=483
>>483>論議(特に技術なお話)のレベルがやたら低くないか？
で言われたような話はやめてレベルの高い技術なお話が聞きたいです。
566 ：492,479=476？：03/07/03 23:20 ID:sl74oCMz
>>563
失礼、484を読んでいなかったよ。

で、ひとつ質問。
>この手のシステムで検索するにはマルチキャストにならざるを得ないので
>効率も悪いし帯域も浪費しますが、このアイデアによりかなりの効率化が
>期待できます。
検索はマルチキャストで効率悪く帯域を浪費すると。
で、「かなりの効率化」ってファイル転送のことだよね。
これでは、使用感がかなり悪くないかな。

システム的なツッコミでなく、申し訳ないけど。
567 ：487：03/07/03 23:44 ID:0/MZkSfO
>>566
そろそろ語るのはやめて実装可能ならモデリングした上で「現実的で実現可能なロジック」を思いついては書き出して、
その現実性を確かめながら「考えたこと」が現実的かどうか判別してくださいよ。

少し組み立ててから、討論しなきゃ意味ないでしょ？
｢シロウト｣な俺が｢クロウト｣のあなたに言うのも変な話だろうがな。
568 ：login:Penguin：03/07/04 00:25 ID:2qy5ighQ
>>566
484案は、不正ノードや落ちたノードを考えなければ、自分が認識している
ハッシュ値を持つファイルに一直線にたどり着けます。これが「ルーティング」
の効率化で、552案は上で得たルートを短縮することによる「ファイル転送」
の効率化です。

たしかに「検索」なしにすると新しいファイルより定番のファイル集め
中心の使用感になるかも知れません。帯域をしぼって検索を実装しても
いいかも。
569 ：login:Penguin：03/07/04 01:59 ID:fVdodLi4
>>568
もっているリストの一部を隣に渡すのではなく、
隣に持っているか聞く、では無理かな。
そこは匿名性より効率取ったほうがやっぱりいいのかな
570 ：354：03/07/04 03:59 ID:ageU1dgR
　とりあえずは、テストベンチは出来ました（まだかなりバギーな感じだけど)。
　現状では100ノードぐらいでノード情報のやり取りをしたネットワークの状態を視覚的に見ることが出来ます。
　ノードの機能をプロトコル毎にコーディングしてやればいろいろな機能を試すことが出来ると思います。
　もっとも、現状では各ノードの状態がどういう状態であるかがわからないので、Winnyのステータス画面のような
ノード毎の状態を見れるユーザーインターフェイスを追加しようと思っています。
　初めて使う言語でライブラリ周りが不明でちょっと苦戦しそうですが、やってみます。
　なんぞ、良い方法がでてきましたら、実装向け暫定プロトコルを設定して組み込んで見ます。
　とりあえず、354系列でテストしています。

　テストベンチで厄介なのは、テストデータを用意するところとテスト結果の検討です。ちょっとしんどい。
571 ：login:Penguin：03/07/04 21:23 ID:yMcJe7lS
期待age
572 ：login:Penguin：03/07/05 00:31 ID:2upqs6/d
bittorrentが狭い意味でのDOMにかなり良く対応しているっぽいね。

http://slashdot.org/article.pl?sid=03/06/02/1216202

> What sets BitTorrent apart is its very robust technique
> for rewarding specifically the peers which upload the most,
> known as leech resistance. On the highest level, this
> prevents a long-term meltdown of the system from being
> caused by people running leeching clients. It also causes
> upload and download rates to be somewhat correlated, so
> peers on good pipes get decent download rates, which
> increases general good feeling about how the system behaves.
573 ：login:Penguin：03/07/06 18:36 ID:fnCbnxqU
354氏待ちで議論が止まってる･･･
574 ：login:Penguin：03/07/06 21:45 ID:FQk5UWqJ
むしろ47氏待ち。
575 ：login:Penguin：03/07/07 00:54 ID:fYSkUx98
>>574
47氏登場は実現のめどがたってからだろう
576 ：login:Penguin：03/07/07 01:34 ID:VL6DoDu+
なにやら停滞しているのでネタ投下
どこにどの程度の匿名性が求められているのだろうか

1.参加者の情報
2.ファイル所持者の情報
3.ファイルUL者の情報
4.ファイルUL可能化している者の情報
5.ファイルDL者の情報
6.ファイルDL要求者の情報

これらをAわからない、B工夫すればわかる(一部の人にはわかる) C誰にでもわかる
で分類すると…今のWINNYでは
1-B　2-A　3-B　4-B　5-B　6-A
こんなもんか。Bをさらに細かく分けるべきかもしれないけれども。
>>354の案だと6が少しB寄りになるかな。
577 ：login:Penguin：03/07/07 03:47 ID:LZyofFSO
47氏が何を何処まで必要としているのか分からないんだよね。
それこそ末端のアイディア一つで実装、公開出来る人だからなぁ。
前スレでの発言のタイミングと、以前の発言から
DOMの排除方法が一番（唯一？）ネックになっているんだろうけど。
578 ：login:Penguin：03/07/07 04:05 ID:fYSkUx98
>>576
>>354の案のおもしろいなと思った所は、探ろうとする動作そのものが
相手に影響を及ぼすところ。
持っているかと聞いたつもりが、新たなダウンロードをよび所持元が
わからなくなる。元々のダウン要求元もわからなくなる。

ただ、そんなに錯綜状態で検索ダウンロードがまともに動くのかが心配
579 ：login:Penguin：03/07/07 04:32 ID:31ve844M
354は懸案事項で、ノードごとの役割分担を
提案したものではないでしょう。
580 ：login:Penguin：03/07/07 13:29 ID:KTSbE55M
>求められているのは、考えること。
>　どうしたら実現できるかのアイディアを出し、そのアイディアの穴を探し、再検討をして穴をふさぐ。
>　現実的で実現可能なロジックが出来れば、コード化することは困難ではない。

穴があることを認めず持論の良い所だけに執着すると
見つけた穴をふさぐ為の再検討が出来ず話しがループする。
354案にしてもその他の案にしても決定案ではないわけだし問題がありそうならその部分を指摘して
検討すればいいのでは。

最終的に誰が見ても問題のある穴がない案になれば
ループを抜け出して次の話題へ移っていけるかも。
581 ：biosmania：03/07/07 19:20 ID:2HADiIwq
おまいら、もう時間がないかもしれません

【韓国企業】ＮＡＶＥＲと２ちゃんねる、本格的提携の模様【2ch】★３
http://news2.2ch.net/test/read.cgi/newsplus/1057570784/

まちBBSの鯖が過日NEVER運営になったがそれに続く事実が出た

http://www.naver.co.jp/内の右側のカテ一覧に
>暮 ダイエット | ドライブ | 美容 | レシピ
>網 オークション | broad band | 2ちゃん
>　　　　　　　　　　　　　　　　　　 ~~~~~~~~
>遊 ゴルフ | 自遊空間 | 釣り | 競馬

と何故か２ちゃんカテが出現（7/5確認）
（他のポータルサイトにも２ちゃんカテ自体は存在するがトップからのリンクは異例）

関連情報

ひろゆき訪韓・ゼロ襲撃・夜勤引退・韓国鯖（＠ｗ荒
http://matarine.web.infoseek.co.jp/tmp/1056845588.html#R110
過去ログ：http://matarine.web.infoseek.co.jp/tmp/tmp_list.htm
東京kittyアンテナ（＠ｗ荒：http://ch.kitaguni.tv/u/310/

そして、このネタの裏を取った切り込み隊長
http://219.113.143.242/blog/kirik/archives/000167.html

前スレ　http://news2.2ch.net/test/read.cgi/newsplus/1057564388/
前々スレhttp://news2.2ch.net/test/read.cgi/newsplus/1057556218/
582 ：login:Penguin：03/07/07 22:08 ID:yLk6mdwI
というわけでますますnyのオープンソース化を期待する他力本願な塗れ
583 ：login:Penguin：03/07/07 22:58 ID:HPtENnq/
こっちも結局勢いなくなったな。
Linnyの呪いだ（ｗ
584 ：login:Penguin：03/07/08 03:10 ID:L4K+tiMU
2chの危機どころじゃない
この日本を守るためにもBBS機能に特化したLinux版winnyの開発を！
585 ：login:Penguin：03/07/08 07:41 ID:MI9Gg+ur
>>作って奴
ソース出せ糞
586 ：login:Penguin：03/07/08 07:57 ID:1cmrXgpg
>>579
354案というのは>>354-359のチャンク化に関する案のつもりで言った
>>388-389にまとめたつもりなのでよろ。
587 ：login:Penguin：03/07/08 23:04 ID:MZGgfqrL
354氏がテストベンチの結果を出してくるまで議論は辛いんじゃない。

理論通りにはいきませんでしたってことになったら、
354案は破棄するしかないからね。

ｶﾞﾑﾊﾞ>>354
588 ：login:Penguin：03/07/09 23:02 ID:TBpnoDNY
>72系への新しい提案が思いつかないので、とりあえず>>354系の気になるところ
を書き出してみる。

(1)それぞれのチャンク自身もキー発信しないと検索効率が大幅に落ちる。また、仮
に平均して10分割することになるなら今のWINNY並の検索効率を維持するためには
10倍のキーを保持、伝播させる必要がある。

(2)便宜的にチャンクの発信するキーをチャンクキー、完全ファイル(UPファイル)の
発信するキーをファイルキーと呼び分けることにする。
チャンクキーにはハッシュ、ファイルの場所(仮にIP)、キー寿命が書かれ、
ファイルキーにはチャンク毎のハッシュ(リスト)、ファイル名、キー寿命が書かれる
ことになるだろうか。
・ファイルキーはいつ、どこに保存するのか？
UPフォルダにファイルを入れた時、能動的にDLした時はokとしても、特に中継で対応
チャンクが「揃ってしまった」場合は？
・ファイルキーを発信する条件は？
・チャンク分割の基準と管理責任の関係

こちらでもある程度想像できますが、あくまで想像のため一人よがりで誤解している恐れ
があります。この辺の知識は共有しておいた方が議論もしやすいでしょうから、できれば説
明お願いします。交換云々の部分にも色々言いたいことがありますがまとまる気配がない
のでいずれまた。


>>581みたいのには㌧と疎いんですが隊長までゴソゴソやらざるを得ない状況なのかえ。
なんだかねえ。このスレもNY2BBSに引っ越すかい？(藁
589 ：login:Penguin：03/07/09 23:29 ID:Unx1986E
藁が余計だわな。
答える気がしなくなるし。
590 ：login:Penguin：03/07/10 00:38 ID:YxZ70vxb
>>589
IDがもう少しでUnix。惜しい。つか後ろも年号みたいでｶｺｲｲな。
591 ：login:Penguin：03/07/10 01:40 ID:oH/mO9X1
>>588
NY2はまだバグがね～(w

βだから仕方ないけど、今はβ4.2だったか。
592 ：login:Penguin：03/07/10 05:18 ID:JbVPt0Kx
>>588
一応私の見解です。
＞(1)
チャンク自身は自分からキーを発行しない。応答Upのみ行う。
ダウン率が落ちるのは、予約中継ダウンロードシステムによりカバーできるかどうかを
>>354がテストしてくれているみたい。

＞(2)
よってチャンクには所在を示すキーがない。
ファイルキーはnyでいうところの検索をかけることにより引っ掛けてくるか、
隣から滲み出してくるのを拾うか、このあたりは未定。

ファイルキーは、あるファイルがネットワークに存在するかどうかの指標となる。
これは、自由に配布されてよい。
チャンクは、ファイルの本体であり、誰かの要求がない限り流れることはない。
ただし、いったん誰かが要求すれば、かなり広がる(予定)。

ファイルキーはnyでいうキーに相当するので、部分ファイルキーとか完全ファイル
キーとかをつくって区別するのがよいのかな？

これってかつての暗号化キーがあった時に似ている気がするんだが
うまくいくのかな
593 ：ひっそりと：03/07/10 22:24 ID:5PeM0Im/
＊＊＊終了＊＊＊
594 ：login:Penguin：03/07/11 02:00 ID:+ildmI86
>>592
>チャンク自身は自分からキーを発行しない。応答Upのみ行う。
正直これでは無理ぽいと思うから確認したい訳でして。

>隣から滲み出してくるのを拾うか
こうするとやはり所在を示すものが必要だと思います。

>ファイルキー
まず、私も今のNYでの完全キーと部分キーについての理解が完全にはできてない、と断って
おきます。間違ったことを延々と書いているようでしたらすみません。指摘して下さい。
完全キーについてはいいとして、部分キーを発信するのはそのファイルをDLしている最中、
もしくは部分キャッシュを持っていてその完全キーをよそから拾えている時に限られている
と私は思っています。(こうしないと完全キャッシュがないキーも流れてしまう)
>>354案のファイルキー発信も内部に書かれているハッシュリストに対応するチャンクを捕捉
できている時だけなのか、できてなくても常に発信するのか、等々確認したいのですよ。今の
ままではかなりの妄想家しか354にレスできません。面白そうな案だけにもったいないと感じます。

あと、>>354のテストベンチは交換部分の調整(チャンクサイズと送り付けるキーのサイズ、対
応するデータ量の調整)のような気がしないでもないす。
595 ：＊＊＊終了＊＊＊：03/07/11 03:07 ID:Z8Cz9ONJ
＊＊＊終了＊＊＊
596 ：login:Penguin：03/07/11 04:04 ID:x9X9br5r
>>594
>>チャンク自身は自分からキーを発行しない。応答Upのみ行う。
>正直これでは無理ぽいと思うから確認したい訳でして。
この点がこの案の重要ポイント。できれば画期的解決案で無理なら廃案。
今のWinnyは、そんなに遠くまでキーが飛んでいるわけではないはず。
では、自分の隣のノードがキーのIPに書かれている状況はどのくらいだろう。
この確率が高ければ、あるキーを発行したのは送ってきたノードであると
みなしても見つけることは可能ではないか。また、予約制度を入れれば、
隣でなくとも要求が転送されることにより、見つかり次第自動で落とすことが
できるだろうと思う。
釣り糸を出しておいて、ネットワークを適当に動き回って引っ掛ける感じで。
糸が当たった人もまた、同じ糸を出して動き回る（こともできる）ので、
引っかかる可能性は上がるかと。

>こうするとやはり所在を示すものが必要だと思います。
ファイルキーは「見つけ方」を示すもので「どこから落とすか」ではない。
よって、ファイルキーの中にあるチャンクのハッシュを手に入れることができれば
それでよい。ファイルキーに関してはWinnyでいう普通のファイルと同様に
扱ってもよいかも。データ本体の通信をチャンクシステムに移行し、検索部を
Winnyのダウンを利用するといった感じで。

>>ファイルキー
完全ファイルキーは全チャンク補足or所持、部分ファイルキーは一部チャンク所持、
受可ファイルキーは部分ファイルキーのうち完全ファイルキーを受け取ってから
一定時間内のもの（Winnyの定義と異なった使用法なら指摘よろ）
とかして完全or受可なら外部に出すことができるでいけるかと。
597 ：354：03/07/11 22:22 ID:9tLFzU3M
あくまで暫定案

データの管理の構成

１．キー情報
　メモリ上に作成されるため、ファイル名は無し
　ファイル名　ファイルサイズ　ハッシュリストのハッシュ

２．ハッシュ情報
　ハッシュリストデータ部を元にしたハッシュを作成しファイル名とする
　ファイル名　ファイルサイズ　ハッシュリスト

３．実データ(チャンク)
　全体ファイルを分割しヘッダを付加した後、それぞれのデータをもとにハッシュを作成しファイル名とする。


ダウンロードの手順

手順1
　検索をかけるノードは、周りのノードにクエリを送り込む。応答としては、「キー情報」が帰ってくる。
手順2
　このキー情報に含まれる、ハッシュコードによって、ハッシュ情報ファイルをダウンロードする。
手順3
　ハッシュ情報ファイルに含まれる、ハッシュリストのコードによって、実データをダウンロードする。
手順4
　ハッシュリストに含まれているデータがすべてそろえば、実データに変換する。


598 ：login:Penguin：03/07/11 23:29 ID:loU3FVpx
>>597
手順２までのハッシュ情報ファイルを落としてくる所までは、
Winny式にやってもいいと思う。
599 ：login:Penguin：03/07/13 01:46 ID:rgB503QV
保守ってみるんだよもん。
600 ：login:Penguin：03/07/13 13:36 ID:5o2m2cGG
>>484と>>552の案を検証するためのテストプログラムを
書いてみました。

http://up.isp.2ch.net/up/fe8882a34470.zipから取得できます。

zipの中のファイルのMD5値は
ef2ffedeff2e9b6e36c5c97cb67ec6ee test.py
です。

安全のためにコードをチェックしてから使って下さい。

やってみた感想ですが、ハッシュがどの隣接ノードからもたどれることが
多くて、想像していたような目的のハッシュまで一直線というようには
いかないような感じです。

もう少し粘ってみますが、>>484案は使えないよう気がしてきた。
601 ：login:Penguin：03/07/14 14:08 ID:HCYsg5XT
期待あげ
602 ：ｂ8：03/07/14 14:15 ID:cXO+7SOr
広大は、器もい、しかも、エロい！！！！！！！！！死ね死ね市ね死ね死ね市ねーーーーーーーーー
603 ：ｂ8：03/07/14 14:21 ID:cXO+7SOr
広大は、男子には、死ねとか、暴言を言うけれど、女子には、イチャついたりしているから、きらわれているんだよ。　　　　　　　　　
604 ：ｂ1：03/07/14 14:24 ID:cXO+7SOr
その人の本名は、フジワラコウタ（藤原広大）きもいよーーーー！キャーヘンタイーーーーーーーーーーーーーーーーーーー！！！！！
605 ：login:Penguin：03/07/14 19:47 ID:yV8EE/6A
>>600
　テストプログラム試してみました。
　
　Pythonは試してみたい言語ですが、これでまた試したくなってしまいました(罪作りな)

　コードのほうは読みきっていないのですが動作させてみたところでは、

　ソースの秘匿の必要があるため、ソースまでの距離を明確にすることが出来ない。
これにより、最短ルートのルーティングをすることは出来ないという状況になっているようです。

　しかし、実際には一度中継したノードはその情報を持つことになるので、他のノードからの
ダウンロード要請に対するルーティングは縮小する可能性はあると想います。

　ただ、複数のノードから情報をもらったノードは、ノードの選択によってはループすることもありうると
おもいます。そのあたりをどうするか。また、中間に入るノードが低速であった場合全体のスループットが
落ちてしまうなど、動的に考えながらチェックをする必要があるかもしれません。

　面白いと想います。
　コードの読解してみます。
606 ：login:Penguin：03/07/14 21:12 ID:t2ssTi7V
http://headlines.yahoo.co.jp/hl?a=20030714-00000003-zdn-sci
P2P実態解明へノード自動探索システムが稼働

オープンソース化の実現の為にはこのような不正ノード対策が重要です。
オープンソース化による開発効率も重要ですがその為に匿名性が下がるのならWinnyの存続にかかわります。
オープンソース化によりこのような不正ノードによる自動探索システムの開発が進む恐れもあることを
よく考えなくてはいけません。

関連スレ
P2P実態解明へノード自動探索システムが稼働
http://news4.2ch.net/test/read.cgi/news/1058181887/l50
607 ：login:Penguin：03/07/14 21:47 ID:ccgr7gSW
>>606
クローズドでやっていても、ちょっと探せば、ネゴの仕方なんかは
プログラムの中にしか書いていないのだから避けられない。

対策としては、こういうことばかりしている不正ノードを弾く仕組みを考えるか、
こういう事されても構わない匿名性を確保するか
608 ：login:Penguin：03/07/14 21:59 ID:t2ssTi7V
>>607
前半部分の文章が意味不明。
後半部分は同意。
609 ：login:Penguin：03/07/14 22:02 ID:Nx6wgJAy
>>605
感想ありがとうございます。

pythonはいい言語ですが、このプログラムは自分でもあきれるほど
へぼいコードになってしまいました。

本当は各ノードが独立して動くシミュレーション的なものにしたかった
のですが、手抜きでただのループ処理になってます。

実はプログラム中でハッシュリストをノード間距離ごとにまとめてあるので
それを判断につかえば、最短ノードにつながるかも知れませんが、実用化時
にはおっしゃるとおり、匿名性に問題があるのでなんらかの工夫がいりますね。

ちなみに
　def get_hash(self, hash, hops, route):
#　　print self.addr,route
の所のコメントをはずすとルート探索の途中経過がわかります。
610 ：login:Penguin：03/07/14 22:25 ID:9Xfbfjma
>>600
おとせなかったんだが、おれだけ？
またあっぷしてくれるとうれしぃ
611 ：login:Penguin：03/07/14 22:52 ID:hKBtqnkL
>>610
便乗きぼんぬアゲ
612 ：login:Penguin：03/07/14 22:56 ID:Mwd/Ww2m
ほれ。
http://220.108.81.79/test.py

2～3日したら消すので、必要な人はバックアップ取ってね。
613 ：login:Penguin：03/07/14 22:57 ID:Mwd/Ww2m
http://220.108.81.79/fe8882a34470.zip
zip も置いておきます。
614 ：login:Penguin：03/07/14 23:04 ID:Nx6wgJAy
>>610
>>611
2ちゃん公式アップローダーはアップしてから24時間過ぎると落とせなく
なるらしいです。

>>600のテストプログラムはあくまで検討用で、落とせなくて残念がる
ほどの出来ではありません。
次はもう少しちゃんとしたものを上げますので、その時にはよろしく。

615 ：login:Penguin：03/07/14 23:14 ID:Mwd/Ww2m
そろそろ Winny もやばそうだね。
http://www.zdnet.co.jp/news/0307/14/njbt_05.html
616 ：login:Penguin：03/07/14 23:37 ID:GFE5xF1K
>>615
禿矢場
617 ：login:Penguin：03/07/14 23:55 ID:t2ssTi7V
DOM対策や●お世話した（UP先）ノード ●お世話になった（DL元）ノードの情報を残していく事が
オープンソース化する上でどのくらい無駄な議論かわかってもらえたかな。

多少効率が悪くても匿名性を確保する事が重要なんだな。
618 ：login:Penguin：03/07/15 00:42 ID:J3ySrY7V
>>608
ソースを隠した所で、プログラムを展開する鍵も、どうやって通信するかも
プログラム中に書いていないと実行できないのだから、がんばって探せば
原理上はWinnyのノードですと、しゃべるノードをつくって情報をもっていく
ノードは作れる。
の意でした。すみません。
619 ：login:Penguin：03/07/15 01:07 ID:dSAJKcFV
>>618
がんばって探せればいいね。
Winnyのノードで、しゃべるノードをつくって情報をもっていくノードを作るには
クローズドで更新が頻繁なソースでは厳しいと思うよ。
620 ：login:Penguin：03/07/15 02:30 ID:tTjDCeMh
>>619
ここはオープンソース化を考えるスレですよ。
621 ：名無し：03/07/15 03:04 ID:EilAIe2R

トラフィックはノードの増減やいろんな関係で将来いくらでも変わってしまうので
瑣末なことを追いかけず
トラフィックの対応部分は分離
あれこれ変更しないですむようにするか、簡単に交換できるようにする

匿秘性の部分は公開が難しいなら
そこは分離して作者が作る

その他の部分をオープン
622 ：login:Penguin：03/07/15 04:23 ID:AjmCy8BO
>>615-617
オープンソース化を考える上で参考になりそうなところは何一つないんだが。

それとネットアークの調査情報は>>477で既出。
623 ：山崎 渉：03/07/15 11:13 ID:doz396Fq

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣
624 ：login:Penguin：03/07/15 11:43 ID:Fo16Kpwc
(･∀･)renice!
625 ：login:Penguin：03/07/15 21:28 ID:dUUmXgWX
http://tmp.2ch.net/test/read.cgi/download/1058199380/51

(´-`).｡oO(こっちでもこういうこと書いてくれれば無駄な争いも減らせたかもーね）
(´-`).｡oO(名無しでこっそり議論を誘導しようとしてたのかもしれんけど……)
(´-`).｡oO(……まあうまく誘導できるわけないわなｗ)
626 ：login:Penguin：03/07/15 22:10 ID:dSAJKcFV
最近匿名性を話題に出したのは漏れのような気が・・・
47氏ここ見てたのならWinnyの匿名性についての説明乙でし

>解析されて改造されるとファイル共有効率が落ちるからです
オープンソース化にはこの部分が問題になるという認識でいいんですかね
627 ：login:Penguin：03/07/15 23:30 ID:CYYtbrCQ
>あと、匿名性がまた話題になっているようですが、nyの匿名性に暗号はほぼ>関係ありません。
>もしWinnyのソースを全て公開して暗号を全て取り除いた状態でもnyの匿名
>性は変わりません。
>
>通信内容、キャッシュなどを全て解析しても匿名性は保たれように設計され>ています。
>Winnyの匿名性の肝は転送動作であって暗号ではないからです。
（http://tmp.2ch.net/test/read.cgi/download/1058199380/51）
628 ：login:Penguin：03/07/17 04:21 ID:xF1H6Rc0
保守。
自分でシミュレータ書こうかと思ったけど挫折しそう･･･めんどい･･･
629 ：login:Penguin：03/07/17 05:43 ID:OeliwBSU
ぶっちゃけp2pの仕組みってどういうもんなの？
その辺りから説明してくれよ。p2pってファイル共有の為だけのものじゃないよな。
630 ：login:Penguin：03/07/17 08:05 ID:U+HfWnIL
>>629
「P2Pがビジネスを変える」
「P2Pインターネットの新世紀」
でも読んどけ。
631 ：login:Penguin：03/07/17 08:36 ID:L9KbWLd6
47氏の発言で紆余曲折が少しは減るかな。
632 ：login:Penguin：03/07/18 05:12 ID:anYs31i+
今のNYBBSのスレは落ちてることが多いからさ
誰か常時起動できる人新しく立ててよ
633 ：login:Penguin：03/07/18 05:46 ID:ma39FHuR
354案はテストベンチ待ちだから取りあえず置いといて。


>>72案は他の案と比べて現在のWinnyから変更が少ないのもいいね。

上でWinny風とか言われてるけど、
Winnyのソースを流用することを前提にするなら、
これも利点として少なからず存在するのでは。

別に「全く新しい」形態でもいいけど、
それはコードを書く気のある人が別のスレでやってもらいたいね。
634 ：login:Penguin：03/07/18 07:56 ID:Yc3H9yCB
>>633
全員コード書くんじゃないのか(ｗ
635 ：login:Penguin：03/07/18 08:10 ID:ucJ0JITP
>>633
ここはWinnyのソースを流用することを前提にするスレではありません。
47氏がソースをオープンにしてもいいと思えるように問題点を解決する方法を考えるスレです。
636 ：login:Penguin：03/07/18 11:44 ID:ZiHDCk/h
「P2Pファイル交換で禁固5年」の法案

米下院に7月16日、P2P経由のファイル交換を取り締まる法案が提出された。
インターネットユーザーが著作権者の許可なく1本でもファイルを交換した場合、
最大で禁固5年と罰金25万ドルを科す内容となっている。

http://www.zdnet.co.jp/news/0307/18/nebt_17.html
637 ：login:Penguin：03/07/18 12:54 ID:XE/ekwx4
　市民団体の電子フロンティア財団（EFF）はこの法案を批判。
EFFのフレッド・フォン・ローマン弁護士は「ファイル交換を行った人物を刑務所に送ることは答えにはならない。
この法案の提案者は、プライバシーや革新、そしてわれわれの個人の自由さえも置き去りにし、
ファイル交換に対する戦争の巻き添えにしている」と話している。

http://www.zdnet.co.jp/news/0307/18/nebt_17.html
638 ：login:Penguin：03/07/18 13:26 ID:DVVO737a
日本では3年以下の懲役または300万円以下の罰金だったから、ちょっと重いね。
639 ：login:Penguin：03/07/18 13:46 ID:ma39FHuR
>>634-635
ソースを一切流用しないのであれば、
47氏にWinnyをオープンにしてもらう必要はないって(w

>>634-635で言ってる事が特に間違ってるとは思わないけど、
Winnyのコード流用を前提にしないと話進まないのは事実だよ。
「全く新しい」ってことになるとLinnyの二の舞になる。
640 ：login:Penguin：03/07/18 14:20 ID:EEjWwWdS
そもそも Linny 時代からネタであるわけですが。
641 ：login:Penguin：03/07/18 18:58 ID:XE/ekwx4
>>639
話しがずれているよ。
それはオープンにされたあとの話題だろ。
オープンにされる事も決定していないのにその後の話をしてどうなる。

今はどうすればオープンにされるかを話す時なんだが。
642 ：login:Penguin：03/07/18 20:59 ID:EYHDul3c
>>633
354ではないが、354案なんだが。ちょっとテストプログラムを作ろうと
いろいろ考えていたら、問題点が。

検索システムについて、欲している人が探すのと、持っている人が調べるのと、
2つの方法がある。
Winnyは前者。これをするためには、持っている人の場所を明示しなければならない。
354案は後者。これにより匿名性は上がるものの、持っている人、または中継する
人に負荷がかかることとなる。
これが第1の問題。

第2に、チャンク分割による検索性の悪化の問題が挙げられる。
これは第1とも関連するが、Winnyであれば1つのキーで済んでいたものが、
10個100個1000個などと増えてしまう。さらに悪いことに、多重ダウンロードの
判断が要求側にある。Winnyでは1つの要求で済んでいたものが、パーツを
自ら探して、1つずつダウンの要求をかけなくてはならない。
(Winnyであれば送信側がある部分を持っていなかったとしても、
持っている部分を代わりに自動的にダウンすることができる)

送信側優先の匿名性の確保、2ノード間不正ノード判定などができる反面、
検索性の悪化、ダウン効率の悪化が考えられる。
この点について、テストベンチの結果が注目されると思う。
643 ：login:Penguin：03/07/18 21:47 ID:EEjWwWdS
チャンクの問題点って、大したこと無いんじゃないの?
匿名性の確保が優先でしょう。
644 ：login:Penguin：03/07/18 22:05 ID:Voskgdhg
>>643
そんなあなたにはFreenetという素晴らしいソフトがありますよ。
645 ：login:Penguin：03/07/18 22:21 ID:EEjWwWdS
へー。それはすごい。
646 ：login:Penguin：03/07/18 22:41 ID:8Ir1t5r1
>>614
いいや、オープン前の話題。
647 ：646：03/07/18 22:50 ID:8Ir1t5r1
失礼>>641ね。
648 ：login:Penguin：03/07/18 23:23 ID:XE/ekwx4
>>647
オープン後にソースを流用して問題点を改良しようというのは
オープン後の話では？
649 ：646：03/07/19 00:04 ID:h9LZqKT7
>>648
DOM対策が出来ればオープンに出来る
DOM対策である72案
それを採用した場合の利点(採用する理由)である>>633

これはオープン前にどの案を採用するか考えた場合に必要な要素だよ。
現実問題としてコードを書く人間の負担というのも起こり得るから。
他の条件が全く同じなら現在のソースを活用出来る方がいい。

ただそれだけなんだけど無駄に噛み付かれると疲れるな。
650 ：login:Penguin：03/07/19 00:12 ID:UBYdTaRC
>>649
現在のソースを活用するのはオープン後の話では？
651 ：646：03/07/19 00:32 ID:h9LZqKT7
>>650
活用するのはオープン後でも活用出来る案かどうかを考えるのはオープン前
DOM対策をするのはオープン後でもDOM対策出来る案かどうかを考えるのはオープン前

釣りなのか？
652 ：login:Penguin：03/07/19 00:39 ID:zTw6adp8
話がループして参りました。
653 ：login:Penguin：03/07/19 00:48 ID:UBYdTaRC
>>651
DOM対策をするのはオープン後？
オープン前の話では？
654 ：646：03/07/19 01:12 ID:h9LZqKT7
>>653
・・・はぁ、釣られていいのかな。

ソースを一切公開しない状態でDOM対策を組み込めるのは47氏だけだよ。
47氏が実装することを前提にしても、
結局47氏があなたの言う「オープン前」にソースを活用することになる。
47氏が実装しなかった場合はどっちも「オープン後」になるけどね。

このスレが立った経緯くらいは理解しといてよ。
655 ：login:Penguin：03/07/19 01:19 ID:UBYdTaRC
>>654
47氏が「オープン前」にソースを活用することになるという詭弁ですか？
47氏が実装するに値するメカニズムをオープン前に考えるスレですが何か。

いい加減にしませんか？
656 ：646：03/07/19 01:42 ID:h9LZqKT7
>>655
詭弁だと思うのはあなたの勝手だけど。

ソースを活用出来るからこそ、ここはLinnyスレじゃないんだよ。
はっきり言って全く新しいものは作れない。
UNIX版を作れない47氏にもそこまで暇はないだろうね。
よって活用の度合いは一つの利点となる。
優先順位は低くてもね。

新しく作れる人はLinnyスレでも何処でもご自由にやって下さい。
ループするけどそれが出来なかったのがLinnyスレ。

釣りでもいい加減にしてくれよ。
657 ：login:Penguin：03/07/19 01:42 ID:UBYdTaRC
寝る前に一言。
47氏が実装しなかった場合「オープン後」はありえません。
「オープン後」の話はナンセンスでし。
おやすみ。
658 ：646：03/07/19 01:46 ID:h9LZqKT7
>>657
>とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので
やっても良いってだけでやるとは言ってないよ。
ここを勘違いしていたようだね。

おやすみ。
659 ：login:Penguin：03/07/19 02:04 ID:lhzVi20w
ソース流用うんぬんはいいから、出てきた案の、うまくいくならいく、
いかないならいかない理由を考えろよ･･･
660 ：login:Penguin：03/07/19 02:09 ID:UBYdTaRC
設計が煮詰まってもやらない場合があるのだとしたら
ますます「オープン後」の話はナンセンスでし。

既にあなたの論点に矛盾が生じているわけだが
どちらが勘違いしているかは第三者が判断してくれるでしょう。
661 ：646：03/07/19 02:16 ID:h9LZqKT7
>>660
また勘違いしているけど、やるやらないは47氏本人が実装するかどうかということ。

根拠も無しに詭弁だというあなたにこれ以上説明しても無駄なようだね。
662 ：login:Penguin：03/07/19 02:30 ID:UBYdTaRC
>>661
47氏本人が実装してもよいと思えるような
メカニズムをオープン前に考えるスレですが何か。
「オープン後」の話しをする事にどのような根拠があるのかわかりかねます。

>47氏が実装しなかった場合はどっちも「オープン後」になるけどね。
>>657

根拠も何もあなたの理論が崩壊している時点でナンセンス。
663 ：login:Penguin：03/07/19 02:31 ID:CAtfeROK
ﾒﾀ議論はもういいよ(w
664 ：646：03/07/19 02:42 ID:h9LZqKT7
>>662
「オープン前」という表現が本当に間違っているなら詭弁と称する必要はない。
「オープン前」にソースを活用することになるのは事実。

まぁ前であっても後であっても(47氏が実装するにしても我々が実装するにしても)
>>633の利点は変わりないのだけど。

まだ寝ないの？(w
665 ：login:Penguin：03/07/19 02:56 ID:UBYdTaRC
>>664
「オープン前」に未公開のソースをどのように活用するのかな？

>まぁ前であっても後であっても(47氏が実装するにしても我々が実装するにしても)
「オープン前」か「オープン後」かをなぜうやむやにするのか。

ここは「オープン前」にメカニズムを考えるスレなのだが。
オープン前に47氏が実装してみる場合と混同しないように。
666 ：login:Penguin：03/07/19 02:57 ID:92R+8lD3
ID:UBYdTaRC
ID:h9LZqKT7
おまえらまとめて寝ろ
667 ：646：03/07/19 03:08 ID:h9LZqKT7
>>665
一つのメカニズムには様々な要素がある。
>>633もその一つ。
実装するかどうかまで考えた場合、
先に様々な要素を洗い出しておく必要がある。

ただそれだけなんだが、何故分かろうとしないのか。
668 ：login:Penguin：03/07/20 16:37 ID:2NbyuoTB
http://tmp.2ch.net/test/read.cgi/download/1058441304/793

>どうも最近、意図的に捏造ファイルを流している方がいらっしゃるようですが、
>逆に捏造減らしその他に使えかもということで新機能入れてみました。捏造警告です。
>
>ファイルに対する捏造警告は前からありましたが、今度はノードに対する捏造警告機能です。
>今までの捏造警告と使い方は同じで、無視条件でハッシュ指定して切断オプションもONですが
>（周囲のノードで見るとキーの参照量が赤くなる）、違うのはこの捏造無視条件にヒットする
>キーを送ってくるノードを、従来の無視ノード扱いと同じ扱いするということです。
>無視ノード警告が二種類になったと思ってください。
>
>警告出されるとそのノード間はつながらなくなるのでクラスタ分断します。
>これは無視ノード警告と基本的に同じ動作です。違うのは捏造警告の場合、該当キー
>一つだけで動作するということです（無視ノード警告ではたくさん送ってこないと警告出さない）
>
>無視ノードと捏造警告はポート警告と違い、接続停止したりしないので無視しても特に
>問題ないですが、あまり警告を無視していると他の通常クラスタと分断されます。
>
>とりあえず、捏造ファイルを送ってくるノードに繋がりたくない場合は、積極的に
>捏造警告出ているファイルに対して各自も捏造条件入れて排除してください。

ny2に実装された捏造ファイル対策、47氏談を一部抜粋。
DOM対策にも使えそうですね。
669 ：login:Penguin：03/07/21 18:41 ID:/v/UGx9B
実際354案はFreenetよりも効率の悪くなる可能性を抱えているよなぁ

テストベンチの結果が楽しみだね
670 ：login:Penguin：03/07/22 21:54 ID:MhPQb/BO
そんなことよりWinny1のバグ直してくれよ。落ち膜離。
671 ：login:Penguin：03/07/23 17:18 ID:c59ro/pP
あのね（ｒｙ
672 ：login:Penguin：03/07/23 20:34 ID:o3pNgotT
のね(ry
673 ：login:Penguin：03/07/24 16:17 ID:XyYhmRaD
>>668
>どうも最近、意図的に捏造ファイルを流している方がいらっしゃるようですが

捏造・・・47ってヴァカ?
674 ：login:Penguin：03/07/24 23:34 ID:opt3EYUW
>>673
もうちょい詳しくその心を。
675 ：login:Penguin：03/07/25 16:35 ID:bWYFsZLK
>>646
Winnyがオープン化したとしても今のWinnyとは全く違う別物になる事くらい少し考えれば分かりそうなものだろ。
47氏は、この先は再設計しかないとny2開発宣言の前に発言している。
現行Winnyとの互換性とかソース流用とか言ってる香具師はどこに問題があるか理解してない。
http://winny.info/2ch/main/1049655320.html#436

要するに47氏は
「今のWinny方式じゃ無理だから新しい方式を考えろ。
良い案が出たらコード書いてやる。」
と言ってるわけだ。
676 ：login:Penguin：03/07/25 16:51 ID:zoirbZEj
それでもまぁ、転送部とかハッシュのチェックとかは
Winnyのコードを流用することに価値はあると思うけどね。
逆に言えばそこにしかWinnyのソース流用に価値はない。


というか、そんなことはみんな判ってると思うんだけど、違うん？
677 ：login:Penguin：03/07/25 17:30 ID:1PH6GFp1
「逆に言う」って表現流行ってるね。
逆に言えば、「逆に言う」と言いたいだけちゃうかと。
678 ：login:Penguin：03/07/25 18:47 ID:zoirbZEj
逆に言えば逆に言うと言いたい香具師はみなｼﾞｻｸ(･∀･)ｼﾞｴﾝちゃうんかと。
679 ：login:Penguin：03/07/25 20:40 ID:4/qhN2aK
コードとか言ってる時点で間違っている。
プログラムを作るには最初に仕様書を書くだろ。
47氏のいうメカニズムという意味は新しい仕様を考えてくれと言ってるんだよ。
仕様が固まらないのにどうやってコードを考えるんだろうか。

>>676
Winnyのコードを流用して何がしたいんですか。
Linny？
680 ：login:Penguin：03/07/25 21:40 ID:hKN027FU
このスレ立ってから一ヶ月以上経過したが何も進んでないな。
ループしまくり。
681 ：login:Penguin：03/07/25 22:13 ID:gZ6CD1ZH
何処がループしているのやら。

今は完全に354のテストベンチ待ち状態。
これで有用だと判定出来ればもっと話を進められる。
逆に出来なければ72案を進められる。
682 ：login:Penguin：03/07/25 22:18 ID:QX7drl9A
>>675
>>679
>Winnyのソースを公開するのもありかと思ってます。
>>1くらい嫁
683 ：login:Penguin：03/07/25 22:24 ID:QX7drl9A
>こちらでそれを取り入れて
これが抜けてたな
684 ：login:Penguin：03/07/25 22:25 ID:4/qhN2aK
>>682
>もしオープンソースでも問題ないメカニズムが
>導入できるのなら、こちらでそれを取り入れて
685 ：login:Penguin：03/07/25 22:44 ID:QX7drl9A
>>684
導入と取り入れるがほぼ同じ意味だから省略したけど。
完全に新しい仕様を考えることを導入とは言わんよ。
「再設計しかない」と言ったのを今回は「こちらの設計能力不足」と訂正している。
この意図も分からないかな。

本スレ住人がこの前スレから見ていれば、
47氏が何を必要としているか分かると思うんだが。
686 ：login:Penguin：03/07/25 22:58 ID:217mh3+h
DOMを排除できる設計
今のｎｙに取り入れることが可能

この二つが実現できる設計をだれかが考え付いたら
それを取り入れた今のnyとは違うもののソースを公開してもいいってことだろ。
687 ：login:Penguin：03/07/25 23:02 ID:4/qhN2aK
>>685
47氏が「もしオープンソースでも問題ないメカニズムが導入できるのなら」と言ってるのは
47氏にはオープンソースでも問題ないメカニズムが思いつかないと言ってる様に感じたのだが。

もし47氏でも思いつかないような問題のない仕様がlinuxスレ住人の685が思いつくのなら
その仕様を提示すればいいのでは。

>Winnyのソースを公開するのもありかと思ってます。
この前提には
>もしオープンソースでも問題ないメカニズムが
>導入できるのなら
があるということ。

47氏が何を必要としているかを分かっていないのは誰かな。
688 ：login:Penguin：03/07/25 23:05 ID:1PH6GFp1
逆に言えば、ﾏﾀｰﾘ汁ってこと?
689 ：login:Penguin：03/07/25 23:46 ID:QX7drl9A
>>686
禿同

>>687
>その仕様を提示すればいいのでは。
72案を実装する。

これなら今のWinny方式のコードを追加、一部改変するだけで可能だろう。
問題点があるならご指摘どうぞ。
690 ：login:Penguin：03/07/25 23:55 ID:ZNZEJMfd
>>72が秀逸だと思うのは現行Winnyとの互換性が極めて高いこと
>>675の発言を未だに信じてしまっているようだけど
47氏が再度発言している部分に関してはちゃんと読まないと
691 ：login:Penguin：03/07/26 00:27 ID:kF1XIna2
４７氏が善意で作ってくれたのにオープンソースにしろっていうのは失礼だと思う
692 ：login:Penguin：03/07/26 00:28 ID:n1dqqG7H
>>691
だれがオープンソースにしろって言ったの?
693 ：login:Penguin：03/07/26 03:19 ID:pv4xx+QD
>>682
＞>Winnyのソースを公開するのもありかと思ってます。
＞>>1くらい嫁

そのWinnyが現行Winnyを改良したものになるとはどこにも書いてない。
名前だけ同じで中身が別物のソフトなんていくらでもある。
第一、47氏は互換性が無くなると予想している。

>>685
＞完全に新しい仕様を考えることを導入とは言わんよ。

全く新しいものを採用する場合でも導入という表現を使う。

＞「再設計しかない」と言ったのを今回は「こちらの設計能力不足」と訂正している。

47氏は現行方式のには先がない事を知ってるから再設計しかないと思ったのだろう。
ただし、それを数学的（wに証明出来ないから能力不足と表現したに過ぎない。
不可能な注文に対して「それは難しい」と断定を避けた回答をするのは良くある事。

>>689
＞問題点があるならご指摘どうぞ。

漏れが言いたいのは、何で現行方式との互換性にこだわるのか？と言う事。
47氏が必要としているのはオープンにしても大丈夫な設計であって、その設計が
現行Winnyと互換性を持っている必要はない。
もちろん互換性があっても構わないが、互換性にこだわる必要は全くない。
互換性を捨てる可能性を排除するべきではないと思うが？

# 47氏自身が互換性が無くなる事を予想しているのだから、
# 最初から互換性は考えなくていい。
694 ：login:Penguin：03/07/26 04:00 ID:RUNOvRLx
>>693
どういう仕様にしろ現行のWinnyと接続するのは無理だろうね。
それは皆分かっているのでは？
互換性というのはコードそのものに対しての発言だと思うが。

>47氏は現行方式のには先がない事を知ってるから再設計しかないと思ったのだろう。
>ただし、それを数学的（wに証明出来ないから能力不足と表現したに過ぎない。
つまり現行のWinnyを拡張した形になる72案には先がないと？
だとしたら代案を是非聞かせて欲しいが。

>互換性を捨てる可能性を排除するべきではないと思うが？
誰も互換性を捨てないとは言ってないと思うが？
695 ：login:Penguin：03/07/26 08:40 ID:PrfbQlpX
47氏が ｢現在のWinnyとの互換性はなくなると思いますが。｣と書いているのは
互換性がある物を作れないからではない。
現在のWinnyと互換性のないものにしようと思っているだけ。

47氏談
>オープンソースであったりプロトコルが公開できるのであれば
>そのソフトは生き続けますが、Winnyの場合、これをやるとDOMを排除できないので無理です。

オープンソースにしたりプロトコルを公開する事は解析されて改造されるのでDOMが現れると予想している。
だからもし仮にオープンソースにしたりプロトコルを公開する事があるなら現行のWinnyに影響が及ばないように
プロトコルに互換性のない別バージョン｢Winny v3.0｣になるという事かと。

>>694
コードそのものの互換性？
696 ：login:Penguin：03/07/26 12:54 ID:3tJwvlxg
>喪前等
>アフォちゃうの？

喪前ﾓﾅー
697 ：login:Penguin：03/07/26 14:37 ID:RUNOvRLx
>>695
>現在のWinnyと互換性のないものにしようと思っているだけ。
そもそも47氏の負担を完全に無くすためのオープンソース化なのだから、
現行のWinnyを47氏が更新しないなら現行のWinnyは生き続けない。

またどんな方法にしろDOM対策を実装するわけだから、
オープンソース化を無しにしても現行Winnyとの相互接続は出来ないだろう。

>コードそのものの互換性？
つまりオープンWinnyを作るにあたってどれだけソースの流用が効くかってこと。
47氏の負担を無くすためのオープン化でまた一から作って下さいとは言い難い。

こんなことはどうでもいいんだが。

>47氏は現行方式のには先がない事を知ってるから再設計しかないと思ったのだろう。
>ただし、それを数学的（wに証明出来ないから能力不足と表現したに過ぎない。
これについてもしあなたが72案に先がないと考えるなら、
その根拠と代案を聞かせてくれないか。
698 ：login:Penguin：03/07/26 15:34 ID:PrfbQlpX
>>697
47氏の負担が軽くなるのはオープンシステム化かもしくは
別の方法による大規模化が実現した時になるだろうが
なんらかのメカニズムを47氏が取り入れてWinnyのソースを公開するところまでは
47氏の協力なしには実現しない。

オープンソース用の別バージョン｢Winny v3.0｣を47氏が作るにあたって47氏がどれだけ現在のソースを
流用するのかまた一から作り直すのかは分からないがそれは47氏が考える事だと思う。
ここで出来るのは案を出す事とそれを検討する事だけ。

それからDOM対策を実装できたとしても47氏が現行のnyと互換性を取るつもりならとれると思うよ。
だから47氏がわざと互換性のないものにしようとしてると思ったのだが。
理由は>>695で書いた通り。

72案に先がないかどうかについての質問は>>693へどうぞ。俺じゃない。

ただ72案に先があるかどうかは別として>>693の意見は理解できるし間違っていないと思う。
699 ：login:Penguin：03/07/26 16:22 ID:oFNQVGCI
>>695
＞互換性がある物を作れないからではない。
＞現在のWinnyと互換性のないものにしようと思っているだけ。

クローズド前提の仕様をどうこね回したらオープンに出来るの？

＞47氏の負担を無くすためのオープン化でまた一から作って下さいとは言い難い。

47氏は一からBBS専用のプロトコルを実装し直すくらいだから心配ないよ。
その手間を惜しむような人ならny2に着手する事もなかっただろう。

＞これについてもしあなたが72案に先がないと考えるなら、

仮に47氏が現行方式を改良する形で72案を実装したとして、それは評価機能を除けばクローズドWinnyと同じものです。
公開されたソースを元にクローズドWinnyと互換性を持つUP0Winnyを作る事が出来てしまう。
（これまでに旧バージョンを排除してきた方法では切断出来ない不正ノードが出てくる）
だから72案で行くとしてもプロトコルは一から作り直しになるから互換性を気にする必要はない。

使えるかどうか分からない72案はクローズドのままで47氏に実験してもらうしかないんじゃないかな。
でも47氏から何もコメントがないようですし、恐らく47氏もこの案は検討した事があるんだと思いますよ。
700 ：login:Penguin：03/07/26 16:25 ID:RUNOvRLx
>>698
>流用するのかまた一から作り直すのかは分からないがそれは47氏が考える事だと思う。
47氏の負担が少なくくて済む方法であると共に、
完成状態にあるWinnyを出来るだけ壊さない方法を考えてもいいと思うけどね。
Winny1のβテストを見てれば分かるけど、
分散型P2Pシステムを効率良く稼動させるのは並大抵のことではない。
47氏ですら開発当初は失敗するかもしれないと危惧していた程。


>72案に先がないかどうかについての質問は>>693へどうぞ。俺じゃない。
違う人だったか、これは失礼。
しかし>>693の発言は72案を否定したのか、そうでないのかが一番問題なわけだが。
それと現行Winnyを改良したものでないなら、
わざわざ47氏にオープンソース化を促す必要もない。
701 ：login:Penguin：03/07/26 16:38 ID:6OGPdonj
47氏！
また最初から別のファイル共有ソフトを作って
そのソフトのソースを全て公開してください！
Winnyだって一年掛からずβ取れたんだから今度も大丈夫でしょ？
時間的余裕でUNIX版は作れないらしいけど、UNIX版作るより楽だよね！？



ほんとに47氏がやると思ってる？
354案とかさぁ、無茶な設計してる香具師は自分が先導して作れば？
47氏に何を頼ってんの？
702 ：login:Penguin：03/07/26 16:51 ID:mQ7ku/EV
つーかはやくソースみせろよ！！！ぼけ！！
703 ：login:Penguin：03/07/26 17:49 ID:PrfbQlpX
>>700
>それと現行Winnyを改良したものでないなら、
>わざわざ47氏にオープンソース化を促す必要もない。

要するにできるだけ現行のWinnyとソースが変わってない状態でオープンにされないと
意味がないということですか？
そうなると考えられるのはソースを見て自分なりに改造したWinnyで現在のネットワークに
入り込みたいというのが>>700の目的でもありそうですね。

47氏はそういうのを一番懸念しているんだと思いますよ。
704 ：login:Penguin：03/07/26 17:55 ID:OoxTsL/+
下らん議論だ
705 ：700：03/07/26 19:58 ID:tBFNHTeC
>>703
滅茶苦茶言うね。

オープンソース版が出来れば現行のWinnyなんて誰も興味を示さなくなるよ。
何せ47氏が現行のWinnyの開発を終了したことになるのだから。
入り込むも何も、誰かがDOMパッチを配布していずれ現Winnyネットワークは崩壊する。

頼っているのは47氏が現在ほぼ完成した状態で所持しているソースであり。
何か別のものを新しく作ってもらう力ではない。

いくらなんでも47氏が全て最初から作るとは考えられないよ。
706 ：login:Penguin：03/07/26 21:50 ID:SSl/B1to
正直、ｎｙ以外の共有ソフトはみんなDOMを許すシステムにもかかわらず
破綻することはない。eDonkeyのように糞遅くなるだけだ。

それを気にしなければソース公開しても問題ないだろうしnyのクラックパッチが出回っても
システムが破綻しないと思われ。

宿り木は宿る木が無いと生きていけない。
707 ：login:Penguin：03/07/26 21:54 ID:elJLvqEL
>>705
あのさぁ…オープン化したとしてそれが機能するかはやってみるまで分からないんだよ。
オープン化ってのはソースを誰でも自由に扱えるという事だ。
一度オープンにしたら失敗したとしても元に戻すなんて事は出来ない。分かる？
下手に互換性の残ったWinnyをオープンにしてネットワークが成立しない事態になろうものなら、
あとには何も残らないんだが、そんなリスキーな真似を47氏がするわけ無かろう。

あなたは72案に自信があるようだけど、それが必ずうまく行くという保証はあるの？
無茶苦茶言ってるのはどっちなんだろうね。
別に72案に反対しているわけじゃないんだけど見通しが甘すぎるよ。

＞分散型P2Pシステムを効率良く稼動させるのは並大抵のことではない。

ってあなた自身が言った言葉を忘れてませんか？
現時点で「匿名性」「効率性」「オープンソース」
この3点を同時に満たすソフトは存在しないわけだ。
誰も踏み込んでいない領域に入ろうとしているのに良くもまあ、互換性だのと幻想を抱けるな。


>>706
すばらしい洞察+1
708 ：login:Penguin：03/07/26 22:24 ID:PrfbQlpX
>>705
オープンソース版さえでれば現行のWinnyなんて誰も興味を示さなくなるのでしたら
>｢現行Winnyを改良したものでないなら、わざわざ47氏にオープンソース化を促す必要もない｣
現行Winnyを改良したものでないといけない理由はないのではないですか。

オープンソースになれば改造も容易になるからなんの対策も取られていなければ
DOMパッチ版と対策版のリリース合戦になりますよね。

ここで大事なのは各ノードが勝手にDOMパッチをあててもオープンシステム上で
なんらメリットを受ける事が出来ないもしくは逆にデメリットを受けるようなシステム
でなければならないと思うわけです。

現在のクローズドシステムでの47氏の無視ノード対策は
http://tmp.2ch.net/test/read.cgi/download/1058441304/793
・ 無視キーによる切断チェック処理を高速化した
・ 捏造警報条件にヒットするキーを送ってくるノードに捏造警告を出すようにした
・ ノードに対する捏造警告機能をつけた
・ 警告出されるとそのノード間はつながらなくなりクラスタを分断するようにした
・ 警告を無視していると他の通常クラスタと分断されるようにした

このようなものがあるわけですがこれは相手ノード側からは無視される事を止められません。
それについては問題もあるのですが、、

とにかくそのようなシステム上の仕組みを考えないとオープンソースにしたところで
ネットワークに影響がでるかもしれないですね。
709 ：login:Penguin：03/07/26 22:26 ID:V7oI1UsC
やたらとのびてるからベンチできたのかと思ったら、ループしてただけか
710 ：login:Penguin：03/07/27 00:43 ID:qf1cFajX
ループと言うよりは同じ行にGOTOしてる感じ。
711 ：login:Penguin：03/07/27 00:53 ID:LTX/9vlS
### 現時点で明らかな事

・今現在DOMり放題なのは、作者47だけ。絶対君主制

・もし47にWinnyオプソ化のメドがついていたとしても、自分だけDOMり放題という
　既得権益を手放してまでオプソ化するメリットはない

### もしオプソ化となった場合の今後の展望

・オプソ化によって小数のDOMれる人、多数のDOMられる人という封建貴族制へシフト

・一般のソフトウェアの場合と異なり、穴に気付いたごく小数の人だけが明確な利益を
　吸い上げられる状況において、善意のコミットがなされなくなるのでは？ 自分は少し
　ずつ損をしていっているのでは？、といった疑念が利用者の間で膨らんでいく。

・利用者の間で、このような疑念や不安のなかった古き良き「優しい独裁者」47による
　Winny時代へのノスタルジーが湧き起こる。

・公開されたソースをライセンスを無視して囲い込み、アレンジして利用者を呼び込も
　うと企む輩共が現れはじめ、利用者が分散していく。

・「覆水盆に返らず」一時のオプソ化への熱狂は、一体何だったんだろうね。
　と苦い後悔を噛みしめながら、FTPやMXで土下座してファイルを貰う乞食に戻る。
712 ：login:Penguin：03/07/27 01:16 ID:UBxiSlie
>>711
社会の時間で習った言葉を使う機会があって良かったね。
713 ：700：03/07/27 06:34 ID:ynqfcVn4
>>706
>それを気にしなければソース公開しても問題ないだろうし
気にしないならeDonkeyでもMX3.3でも勝手に使っててくれ。
遅くていいならFreenetでもいいだろう。

WinnyはFreenetの欠点、効率の悪さを補ったソフトであることをわすれちゃいいけない。

>>707
>オープン化したとしてそれが機能するかはやってみるまで分からないんだよ。
どのようなDOM対策を加えるにしても現行のWinnyとはプロトコルを変えてくるだろうし、
少しでも変わっていればクラックする手間も変わらない。
47氏が少しずつプロトコルを変更しているのもそのため。

>あなたは72案に自信があるようだけど
現実的なアイディアが他にないからまずは72案の可否を検討しようとしているだけ。
354案はテストベンチ待ちみたいだしね。

>>708
>現行Winnyを改良したものでないといけない理由はないのではないですか。
だから47氏が全て最初から作ってくれるのか、という話。
もしこのスレに来て「どんな設計でも新規にコーディングします」
と言ってもらえれば何も言うことは無いが>>1を見てもそうは思わない。
だから同じ条件なら現在のWinnyのコードを活用出来る案の方が
より現実的だろうと言っているんだが。

>オープンソースになれば改造も容易になるからなんの対策も取られていなければ
>とにかくそのようなシステム上の仕組みを考えないと
その対策、仕組みに72案などがあるのだが。

問題点があるならご指摘どうぞ。
714 ：login:Penguin：03/07/27 10:31 ID:84k+oAW4
どうせ47に作らせるんなら、新規に作ろうが、winnyを改造しようがどうでもいいことなのでは？
ユーザレベルのやつとか、DOM改造をなんとかして施そうと考えてるようなやつは、
ただまってればいいんだよ。

問題は、72とか354の案が理論上大丈夫っぽいとしても、
実験してレポートでも出さない限り、47も開発開始またはソース公開しないだろうってことだ。
715 ：login:Penguin：03/07/27 11:53 ID:3Cbd34rj
>どうせ47に作らせるんなら、新規に作ろうが、winnyを改造しようがどうでもいいことなのでは？

新規だと47は作らない。
というか時間もモチベーションもなくてきっと作れないよね。
716 ：login:Penguin：03/07/27 12:41 ID:s3hqn1im
>>715
1ヶ月もかけてBBS専用のプロトコルやらトリップやらを新規に設計した実績があるじゃん。
ny2のファイル共有機能と掲示板機能は別ソフトと言っていいくらい違うものだよ。
717 ：login:Penguin：03/07/27 13:05 ID:ZUPf/QFC
47氏が言ってたよ。
「夏厨ごときが ”47に作らせる”とかえらそーに吠えてるのを見てやる気なくなった」
って。

あーあ
718 ：login:Penguin：03/07/27 16:48 ID:xnuzWTbw
47氏って２ちゃんねる初心者？
その程度でやる気をなくしてるんじゃ
人間が出来てないね。
719 ：login:Penguin：03/07/27 17:05 ID:2Mlyaf5O
>>718
という釣られる藻前がsy(ry
720 ：login:Penguin：03/07/27 18:17 ID:xEeNPoOE
Winnyがオープンソースだと使ってる人は色々と困るんじゃないのか？
721 ：login:Penguin：03/07/27 18:22 ID:v8nNpTJm
なぁこのスレ夏坊で充満しててゴミレスばっか増えてくから
まともなWikiでても立ててやれば?
722 ：login:Penguin：03/07/27 18:25 ID:umn/qrYD
>>721
おまえがたてろや
723 ：login:Penguin：03/07/27 18:53 ID:NmejElh2
オプソにしたらいろんな亜種ができてダメになるだけ。
724 ：login:Penguin：03/07/27 19:28 ID:rUEZfXAZ
わざわざオープンにしてなんか意味あるわけ？
お前らオープンにしたいだけだろ
725 ：login:Penguin：03/07/27 21:36 ID:2TwB4F2h
>>713
プロトコルが変わるというのをどういう意味でつかってますか？
最近の話題を理解しておられるとは思えませんが。
既に説明が終わっている問題を又説明しないといけないのですか。

問題点があるとしたら話しがループしていることでは。
726 ：login:Penguin：03/07/27 22:33 ID:wqBUfqHj
スレの流れを無視して思いついたことをひとつ

とりあえず通信経路はSSLで…


■─┬─┬─┬　　　DL待機ノードが幾つか並んでいて、
　　　□　 □　 □

■─┬─┬─┬　　　1/3ぐらいずつファイルを転送
　　　●　 ●　 ●

■　　　　　　　　　　　　相互に通信して補完
　　　■→■→■
　　　　 ←←←

だめぽ
727 ：login:Penguin：03/07/27 23:02 ID:rN1ydOkM
winnyスレ(MXの次)から流れてきました。
流し読みしたんですけど、発言者のDOMの定義がまちまちなように思えます。

私なりにDOM対策としての話の方向性を考えたのですけど
・winnyはダウンロードばかりする人もキャッシュ保持&転送(非port0)という点でネットワーク全体に貢献している(排除する必要が無い)
・オープンソースになった時、ネットワークに貢献しないでダウンロードに比重を置いた改造版が出回る点が懸念される
という点がDOM対策の要点だと思いました。

現在のwinnyで実現されている、転送動作アルゴリズムによる以下の特徴があるようです。
・winnyが回線速度申請を嘘申請したとしても、挙動は変わるが別にダウンばっかり出来るわけではない(過去ログ見つからず)
・通信内容、キャッシュなどを全て解析しても匿名性は保たれように設計されている(47氏の発言より)

そこで、われわれが考えるべきなのは、winnyの上記の特徴に加え
「オープンソースになってパラメーターをいじられたバージョンが出回っても、大多数が正常なバージョンである限り、
破綻しない転送動作アルゴリズム」
を考えるべきだと思います。

ソースがオープンになっても、問題が起きない(起き難い)アルゴリズム向けならば、47氏もソースを出しやすいんじゃないかと
思いますが、いかがでしょうか。>47氏
728 ：login:Penguin：03/07/27 23:15 ID:84k+oAW4
はぁ？
もともと問題が起きないロジックが出されない限り、
47はソースを公開しないんだよ。(ロジックがでても本当に公開するかもわからないが)
>>1 さえ見てない状態で本当に流し読みしてんのか？
話をループさせるな。
729 ：login:Penguin：03/07/27 23:27 ID:wqBUfqHj
> 「オープンソースになってパラメーターをいじられたバージョンが出回っても、大多数が正常なバージョンである限り、
> 破綻しない転送動作アルゴリズム」

これがキーポイントだね
730 ：login:Penguin：03/07/28 00:04 ID:UOab1VMx
http://cgi.members.interq.or.jp/hokkaido/asato/upload/jam3ddr/OB0002065.gif
ループしている部分はここ

ちっとも次に進まない
731 ：login:Penguin：03/07/28 00:10 ID:PLU0kmiy
A->Bに転送する場合
・A->Bから直接データを転送、またはA->C->BとCを中継する。
・と同時に転送データのMD5値をA->D->B経由で転送する。(D!=C)
・Bは受け取ったデータとMD5値を比較し・・・
　　・正しければデータを受け入れる。
　　・間違っていればA,(C,)Dを容疑者リストに登録し、転送を中断し別の経路で再開する。
　　　　・既に容疑者リストに登録されているホストは有罪確定リストに登録し、
　　　　　今後検索・転送・中継を拒否する。
・転送に成功したらA,(C,),Dの無罪確定リストに追加し、
　次回の転送時に優先的に利用する。

・各リストはクライアントログイン時に毎回初期化する。
732 ：login:Penguin：03/07/28 00:16 ID:mSmK5diG
　　　　　　　　　　　地震ワッショイ！！
　　　　　　＼＼　 　　地震ワッショイ！！　／／
　　+　　　+　＼＼　　　地震ワッショイ！！／+
　　　　　　　　　　　　　　　　　　　　　　　　　　　　+
.　　　　　+　　 ／■＼　.／■＼ 　 ／■＼　　+
　　　　　　　　（∀｀　 ） ∩ ´∀｀）　（　 ´∀）
　　　+　 （(　⊂　 　　つヽ　　　つ ⊂　　　つ　)）　　+
　　　　　　　　 ヽ （　ノ　 (ヽ　 （　　　）　） ヽ
　　　　　　　 　 (＿）し'　（＿）＿）　 （ .__）＿）





|_-)ﾐﾝﾅｼﾈﾊﾞｲｲﾉﾆ．．．
733 ：login:Penguin：03/07/28 01:05 ID:/og+v/se
>>730
進めたい奴がいないから、進まないわけでは?
734 ：login:Penguin：03/07/28 01:15 ID:UOab1VMx
>>733
いや
反論の中の問題点（矛盾点）を指摘しているのに認めないみたいだから進まないんでしょ
そして戻る所はいつも72案
735 ：login:Penguin：03/07/28 01:15 ID:xOgH5iwt
winnyという巨大ネットワーク(クラスタ)で各ノードの情報を共有し
相互にチェックしあう仕組みを作っている

あらすじはこんな感じですか？
736 ：login:Penguin：03/07/28 01:34 ID:/og+v/se
>>734
ということにしたいのですね? :)
2ch固有の「知障」に反応するからいけないんだと思うんだがね。
737 ：login:Penguin：03/07/28 01:50 ID:UOab1VMx
>>736
いや
技術者なら矛盾が生じた時点で次の理論を考えるのは当たり前
目的は求めるものの完成であってその過程でつじつまの合わない理論につき合うのは非常に疲れる
738 ：login:Penguin：03/07/28 01:52 ID:jnERDJoJ
>731
それ、面白そうだね
739 ：login:Penguin：03/07/28 01:53 ID:/og+v/se
似非技術者が住むスレはここですか?
740 ：login:Penguin：03/07/28 13:23 ID:jnERDJoJ
>726
■─┬─┬─┬
A　　B□ C□ D□


だめぽとか書いたけど、これ使えるかも
3人だったら1/3に分割してデータと、他のノードに送った部分のMD5値を送信。
あとは相互に通信して不足部分を補完。
こうすればDOMは防げる。
もしどれかのノードが不正データなどを流してきたらMD5でチェックして
無視ノードリストに追加。
こうすれば同時に複数のノードに無視されるようになる

効率を上げるなら
■─┬─┬─┬
　　　□　 □　 □
　　　↓　 ↓　 ↓
　　　□　 □　 □
こんなふうに多段につなげてもよし
匿名性を挙げるならAの一個後に転送をかませてもよし

メリット
・DOMはできない(厳密に言うとできるがネットワークに貢献している)
・B,C,Dは著作物を送信してない(ぁゃιぃ)

デメリット
・複数代のキューがたまるまで送信できない
741 ：login:Penguin：03/07/28 14:07 ID:pwWXu7BM
>>740
>あとは相互に通信して不足部分を補完。
これ説明が無限後退してるよ(藁

単にA<->B<->C<->Dの双方向リストを形成して
上位ノードにリクエストを発行する。
下位ノードからリクエストがあったら自身のキャッシュを返す。
なければ上位ノードにリクエストを発行して返ってきたらそれを下位に返す。
# 下位への応答よりも自分のリクエストを優先させる。
# 結果リストの下っ端は転送効率が下がる。
データのチェックは各ノード間で行う
# 誰が怪しいかは分からないし
# データがおかしかった場合リスト全体を破棄するのはもったいないし
# 嵐に利用されかねないので。
というのじゃ駄目なの?

パフォーマンスをあげたい場合は複数本のリストを形成すればいいだけ。
742 ：login:Penguin：03/07/28 14:27 ID:jnERDJoJ
うーん。なんというかDOM対策と転送時の個々のノードの負担低減の案ということで
説明を補完すると

■─┬─┬─┬　　　DL待機ノードが幾つか並んでいて、
A　　□　 □　 □
　　　B　　C　　D

■→┬→┬→┬　　　Aから1/3ぐらいずつファイルとB,C,DのIP、B,C,Dに送ったデータのMD5値を転送
　　　●　 ●　 ●

■　　　　　　　　　　　　B,C,Dが、送られてきたデータをもとにAとは切り離して残り2/3を転送しあう。
　　　■→■→■ 　　 MD5値が一致しなかったら無視ノードに追加
　　　　 ←←← 　　　　Bが不正ノードだったらCとDに無視ノードとして登録される

永久にファイルが落ちてこないような気もする…
743 ：login:Penguin：03/07/28 16:39 ID:T5IftzV/
>>730
>>734
本当にこのスレを見てるのかな。
誰も72案の問題点を出していない。
72案の問題点などを考えていればループすることもないんだがね。
>もしこのスレに来て「どんな設計でも新規にコーディングします」
>と言ってもらえれば何も言うことは無いが>>1を見てもそうは思わない。
それもこの部分の意見の相違ということで終了している。
354案などを47氏に実装してもらえるかどうかは47氏にしか分からない。
744 ：login:Penguin：03/07/28 21:12 ID:UOab1VMx
>>743
>>1からずっと見てますよ。
また反論に矛盾点がありますよ。
ループするんですか？
745 ：login:Penguin：03/07/28 22:03 ID:6qDc2qw7
悪貨は良貨を駆逐するってのはこういうことか。
やっぱ場所変えたら? 2chじゃなくてMLとかに。
746 ：login:Penguin：03/07/28 23:32 ID:PEc7MW48
>>745
何も駆逐されてはいないと思うよ。

2chだからこそこれだけ人が集まるし、ゴミレスなんてものも気にしない。
明らかにレスする価値がないならしなければいいだけ。
その判断を出来る人間同士で議論すればいい。
747 ：login:Penguin：03/07/29 00:14 ID:nS1HyMeD
ここは47氏へのおねだりスレですかｗ
結局犬はドザに媚びることしか出来ないのですな
748 ：login:Penguin：03/07/29 01:00 ID:x+1EUQfc
んー、次スレはUnix板にでも建ててみるかい？
向こうなら多少違う風が当たるかもね。

カラアゲうまうまスレ住人とか。
749 ：login:Penguin：03/07/29 01:19 ID:EBDXZzHU
>>748
ここでいいって。
何処へ逝ったってダウソ板住人が議論することになる。
750 ：login:Penguin：03/07/29 04:19 ID:89jQhEwm
通信技術板とかどう？過疎っぷりがいい感じかも。
751 ：login:Penguin：03/07/29 11:29 ID:x+1EUQfc
このｽﾚみたい対象が小さいものは通信技術は微妙かも。デフォ節は魅力だけど。
あそこのP2Pスレは閉鎖騒動の名残だし、今建てても一蹴されそう。

Unix板はﾈﾀ好きが多いから、そこそこ盛り上がれば人が来るのと、
板住人的に荒らし耐性が全般的に強い。
そもそも別にオープンソースになれば対象はLinuxだけじゃない。

両板の関連スレッドはこんなかんじだった。
　winmx羨ましい。。
　　　http://pc.2ch.net/test/read.cgi/unix/1005660365/
　P2P関係全般質問スレッド
　　　http://pc.2ch.net/test/read.cgi/network/999877930/
　WinMXに代わる次世代P2Pクライアントを作ろう！
　　　http://pc.2ch.net/test/read.cgi/network/1030686407/
752 ：login:Penguin：03/07/29 11:39 ID:EncLBj9h
板の問題ではなく2chは議論には向かないって事だよ。
753 ：login:Penguin：03/07/29 15:22 ID:5JagbZS1
>>752
2chの問題ではなく議論に参加する人間の質に問題がある。
700みたいのは放置しなければならないんだが、それを徹底すれば何とかなる。
754 ：login:Penguin：03/07/29 17:55 ID:zt2r+Ss7
発言に煽りが入るのは論理に自信がない証拠。
そういうのは徹底して無視すればいい。
755 ：login:Penguin：03/07/29 20:00 ID:EncLBj9h
煽り云々の問題じゃなくって発言の文脈が捉え辛いのと
発言がゴミレスに埋まってしまうのが問題なんだよ。
ベースは2chのスレで構わないけどそれ以外に
議論を掘り下げていく別の場所が必要だよLinnyWiki立て直してくれよ。
新規でも構わないからさ。
756 ：login:Penguin：03/07/29 20:08 ID:jPC1PZ55
Linny Project復活ですか？
757 ：login:Penguin：03/07/29 20:08 ID:LNF0VP0P
そうだね２ｃｈにはゴミしかいないもんね
あれ
じゃあなんでここのスレの人達は２ｃｈにきてるのかな？
758 ：login:Penguin：03/07/29 20:40 ID:k3z4jvYX
荒れてしまう前72案にご指摘。。。

各ノードが自分と関わりを持ったノードについて
単純で軽い（１つのノードが情報を捏造しても影響が少ない）情報を保持し
問い合わせがきた場合その情報を問い合わせ元へ応答するという
>>72案を実装した場合の問題点

いくつか考えられるがわかりやすく何点かにわけてあげてみる
一つ一つ想定する状況が違うので反論する場合はどの問題点についてか明示すること

【状況その壱】
・共有する気などまったくなくネットワークの崩壊だけが目的の団体、組織によるノード投入

　偽評価ノードの大量投入
〔活動〕
　ノード情報を集めその全てに対して最低の評価を応答する
〔結果〕
　各ノード同士が最低の効率での共有を強制させられる
〔考察〕
　その偽評価を各ノードが止める事は出来ない
　流れている評価が正しいものなのか偽物なのか判別は不能

〔聞きたいこと〕
　これを72案でどう防ぐのか
759 ：login:Penguin：03/07/29 20:41 ID:k3z4jvYX
【状況その弐】
・サークル、グループなどある程度の仲間があつまった場合の集団による評価詐称

〔活動〕
　自分以外の各メンバーに対する問い合わせがきたら高評価であると応答する

〔結果〕
　DOMパッチを当てているにも関わらず高評価となり優遇される

〔聞きたいこと〕
　これを72案でどう防ぐのか

【状況その参】
・72案システムそのものが持つ問題点

　このシステムの場合初めは評価値ゼロのノードとしてULが開始されるが
　時間が経つにつれ評価は上がっていく

　しかしその為にはある程度の期間他のノードが自ノードの評価を保存していてくれる事が前提となっている
　自分に関係のない他ノードの評価の為に無駄なディスク容量を確保してもらえるのか
　またどんなに評価が高くなろうと、その情報を他ノードから削除されてしまえば自ノードの評価は＋にならない

　普段滅多に繋がらないクラスタに入ったときも評価は低い
　自分の貢献度を知らないノードに囲まれた時も自ノードの評価は０
760 ：login:Penguin：03/07/29 20:41 ID:k3z4jvYX
【状況その四】

　 　 　　　　　　　　　　　　　　　　隣 　 ｜　 　 　　　　　　　　　　　　　　　　隣
　 　 　　　　　　　　　　　　　隣＜ 　　　｜　 　 　←─ 評価低応 答 ─── 隣
　■─問い合わせ→ 隣＜　　　隣 　 ｜　■←─ 評価低応 答 ── 隣 　 　 　隣
　↑ 　　　　　　　　　　　　　隣＜ 　　　｜　｜ 　←─ 評価低応 答 ─── 隣
DL要求 　 　 　 　 　 　 　　　　　隣　　｜　｜ 　 　 　 　 　 　 　 　 　 　 　 隣
　｜ 　 　 　 　　　　　　　　　　　　　　　｜　↓
　□ 　 　 　 　　　　　　　　　　　　　　　｜　■

この様な場合DL要求ノードはマイナス評価になるので優先度が下がる仕様になるようだが
ノード評価システム上ではDL要求ノード側からするとULノードはULノードが０でない転送を
発生させている以上評価は下がらない

となるといつ終わるともわからない転送さえ発生するようにすればDOMパッチを当てるまでもなく
評価を下げない工夫ができることになる。

〔聞きたいこと〕
このあたりは72案はどのような場合に評価を下げるつもりなのか
761 ：login:Penguin：03/07/29 21:31 ID:LNF0VP0P
まぁ>>758-761
なんか難しいことかいてオナニーしてるけど
ＣＵＩですますのかGUIにするのかGUIはqtにするのかGtkなのか
wxWindowなのかスレッドはpthreadでいいのかとか
そういう実装系の話ができるやつってここにはいないんでしょｗ
762 ：login:Penguin：03/07/29 21:35 ID:zu5I516M
>>758
>>759

>【状況その壱】
>・共有する気などまったくなくネットワークの崩壊だけが目的の団体、組織によるノード投入
>　偽評価ノードの大量投入

>【状況その弐】
>・サークル、グループなどある程度の仲間があつまった場合の集団による評価詐称

悪意のあるノードが「組織的に」大量に投入された場合、破綻するのは（クローズで無い限り）どんなシステムでも同じのような気がする。
あと、マイナス評価ばかり返すノードのプラス評価を確認するとつじつまが合わない事がチェックできるかもしれない・・・
（マイナス評価を持っていると言う事はその相手がプラス評価を持っていると仮定できる？）

> 【状況その参】
> 自分に関係のない他ノードの評価の為に無駄なディスク容量を確保してもらえるのか

これは交換では無い共有ソフト全般に言える事じゃないかな。と思う。
nyの現状を見ると、断言は出来ないけれど他人のためにディスク容量を提供してくれるノードの数は少なくなさそう。

>>760
>【状況その四】
>DL要求ノード側からするとULノードはULノードが０でない転送を発生させている以上評価は下がらない

これ、ちょっと意味がわからなかった。
「ULノードが０でない転送を発生させている」てのはどんな動作なんだろう？
763 ：login:Penguin：03/07/29 21:42 ID:zu5I516M
>>761
UIの持ち方とか、ライブラリに何を使うかとかは決める必要ないような気が・・・
764 ：login:Penguin：03/07/29 21:49 ID:EncLBj9h
ホラ釣られた
765 ：login:Penguin：03/07/29 21:49 ID:LNF0VP0P
>>763
んじゃいったい君はなにがしたいの？
書いてることってWinnyや他のP2Pシステムを自分で解釈しただけジャン
766 ：login:Penguin：03/07/29 21:52 ID:LNF0VP0P
＞＞７６４ EncLBj9h
ほら帰れよここは”塵だめ２ｃｈ”だぜ
/.Jかめーリングリスとにでもかえれよ
767 ：login:Penguin：03/07/29 22:05 ID:k3z4jvYX
>>762
【状況その壱】
【状況その弐】
>マイナス評価ばかり返すノードのプラス評価を確認するとつじつまが合わない事がチェックできるかもしれない
大量の偽評価ノードがお互いにプラス評価を流しあっていたらつじつまがあってしまうかも

〔聞きたいこと〕
　これを72案でどう防ぐのか

【状況その参】
>nyの現状を見ると、断言は出来ないけれど他人のためにディスク容量を提供してくれるノードの数は少なくなさそう。
これは断片化したファイルは各ノードに持ってもらえないとFreenetの例を出して説明する人もいるから同意

【状況その四】
>これ、ちょっと意味がわからなかった。
>「ULノードが０でない転送を発生させている」てのはどんな動作なんだろう？

おそらく72案ではULをまったくしないDOMを想定していると思うのだが
少しづつでもULしていればDOMと認定されないのかという事を聞きたくて想定してみた
768 ：login:Penguin：03/07/29 22:28 ID:zu5I516M
>>767
>【状況その壱】
>【状況その弐】
>〔聞きたいこと〕
>これを72案でどう防ぐのか

一応上で答えたつもりなんだけど防げないんじゃないかな。
加えて、自分は破綻させる方法は違っても組織的に悪意を持った大量ノードによる破綻てのは72に限った問題ではないように思う。

>【状況その四】
>おそらく72案ではULをまったくしないDOMを想定していると思うのだが
>少しづつでもULしていればDOMと認定されないのかという事を聞きたくて想定してみた

UL帯域を絞ってUL状態を意図的に長くするという感じ？
評価基準を詰めれば何とかなるかも。
申請速度と実際の転送速度差を見るとか、
受信データサイズを区切って評価を更新

nMBまで受けたら初めてプラス評価、
その後また次のnMBを受けるまで時限的にプラス保留。
期待した時間が来てもnMB受けていなければ評価ゼロ。
転送が続いていればnMB受けた時点でまたプラスに戻す

とか。
769 ：login:Penguin：03/07/29 22:49 ID:gR/4qr/d
>>768
大量に、の度合いにもよるだろう。
過半数を正規ノードで占めれるくらい大きければ問題ない、はず。
770 ：login:Penguin：03/07/29 23:09 ID:k3z4jvYX
>>768
【状況その壱】
【状況その弐】
>一応上で答えたつもりなんだけど防げないんじゃないかな。
>加えて、自分は破綻させる方法は違っても組織的に悪意を持った大量ノードによる破綻てのは72に限った問題ではないように思う。
おそらくそうかと
72案では防げないのではともおもうが、その対策を取ったシステムを考えれば防げるかもしれない
DOMが増えるとネットワークが崩壊するという人もいるし
崩壊してしまいそうなくらいDOMとか悪意を持った大量ノード増えた場合を想定した
システムでないといけないでしょう

だからそれについて72案を奨める人にどういう対策を考えているか聞いてみたい

【状況その四】
>UL帯域を絞ってUL状態を意図的に長くするという感じ？
そう、だらだらとDLさせている間に自分のDLを完了させて
その後キャッシュを削除もしくは転送を停止、結局完全な物は相手にDLさせないノードを想定してみた

>評価基準を詰めれば何とかなるかも。
>申請速度と実際の転送速度差を見るとか、
>受信データサイズを区切って評価を更新うんぬん

72案ではULをまったくしないDOMだけを想定しているわけではなく
nMBかまで受けたら初めてプラス評価するという案なのかな
nMBもないファイルのやり取りの場合もあるしどのくらいの受信があれば
評価するシステムにするつもりなんだろ
771 ：login:Penguin：03/07/29 23:15 ID:k3z4jvYX
>>768
〔聞きたいこと〕
　これを72案でどう防ぐのか

というのは｢72案に問題点があるならご指摘どうぞ｣の方へ向けての質問なので
>>768へ質問しているわけではない
772 ：login:Penguin：03/07/30 02:35 ID:AtS51Duz
winny2から開発環境がC++ Builderに変わったそうで
ってことはkylix3を使えばLinuxにも簡単移植できるね。
773 ：login:Penguin：03/07/30 14:37 ID:grIDxfqG
>>772は馬鹿
774 ：login:Penguin：03/07/30 15:34 ID:BXG8bjRF
>>773
お前も馬鹿（ｗ
775 ：login:Penguin：03/07/30 16:43 ID:0lRS7tcz
>>772
　言語環境をそろえれば、OS環境の問題もないと想っている段階で馬鹿
>>722
　なぜかの説明もしないで、荒らしているだけなので馬鹿
>>773
　同上

　このように、ノイズが多いことが2chが共同の開発の場として向かない
ことを示している。
776 ：login:Penguin：03/07/30 17:04 ID:/6phmhbn
>>775
馬鹿は藻前では?
777 ：login:Penguin：03/07/30 18:38 ID:mA14HU+8
kylix3を使えば「比較的」簡単にLinuxに移植できる

47氏ならそういうの無くてもほいほい移植できそうだなぁ・・・
778 ：login:Penguin：03/07/30 19:27 ID:0ecLmeNQ
kylix3で移植できたとしても
VCLのGUIだけでしょ
Winsockまわりは書き直さないといけないし
ファイルのオープンクローズ、スレッド
はWINとは違うんだから
こうなりゃなるべくWINEでちゃんと動くように47氏に設定してもらったほうが楽
>>776
禿げ同
779 ：login:Penguin：03/07/30 21:12 ID:C/XjVJGR
>>758-761
とても分かり易いご指摘ありがとう。


>>758
>【状況その壱】
>・共有する気などまったくなくネットワークの崩壊だけが目的の団体、組織によるノード投入
>　偽評価ノードの大量投入

ノード評価時の優先方法を相対的な帯域確保や待ちノードの順位優先で行う。
これならいくらネットワーク全体にマイナス評価を撒いたとしても、
標準ノードの基準値が下がるだけで相対的には正常な評価を出来る。

転送や待ちノードが一つもない場合、評価の低いDOMノードにUP帯域を100%喰われる可能性もあるが
転送ノード同士の関係で完全に収束するので問題ない。


>>759
>【状況その弐】
>・サークル、グループなどある程度の仲間があつまった場合の集団による評価詐称

もう少し考えてから書くので少しお待ちを。

ただ完全なDOMであっても1%未満(1000人程度?)など小規模な詐称、回線の圧迫であれば
現在のWinny同様あまり問題ないだろうと思うけど、より良い案や解決策があればいいね。
780 ：login:Penguin：03/07/30 21:13 ID:C/XjVJGR
>>759
> 【状況その参】
>自分に関係のない他ノードの評価の為に無駄なディスク容量を確保してもらえるのか
>またどんなに評価が高くなろうと、その情報を他ノードから削除されてしまえば自ノードの評価は＋にならない

他ノードの評価のためのデータ保持は負担が軽微であると考える。
他ノードのプラス評価を削除することはメリットが希薄だと考える。
よってどちらも懸念すべき事項ではないだろうと考えられるはず。

>普段滅多に繋がらないクラスタに入ったときも評価は低い
>自分の貢献度を知らないノードに囲まれた時も自ノードの評価は０

評価を知らないのは全くお世話したことのない集団なので優先順位が低いのは諦める。
ある程度長時間接続する場合は次第に評価があがっていく。

また保持してあるノード情報から複数のクラスタを速やかに切り替えたり、同時に接続出来るようにする。
どうしても常に高速でダウンしたい場合はあまり繋がないクラスタ側にもいつもUP帯域を配分しておく。


>>760
>【状況その四】
>DL要求ノード側からするとULノードはULノードが０でない転送を発生させている以上評価は下がらない

10MBもしくは10MB以下のファイル一つを転送し終えた時点で評価を一つ上下する。
これでUP帯域を絞って評価を稼ぐことは出来ない。
分かりにくそうなのでそれらしい数値を入れたつもりだがどうだろうか。
781 ：login:Penguin：03/07/30 23:45 ID:0lRS7tcz
72案で優先ノードになるための改造方法を考えてみました

　アップロードしてくれるノードが他のノードから受け取る評価値によって自分のノードの
優先度が決まるため、ダウンロードするノードでは優先度を変更することが困難としている
のが72案だと思われますが、各ノードが持つ評価値はどのようにして設定されるのでしょう？

　1つのパターンとして「ダウンロードさせてもらったときにそのノードに対する評価値を上げる」
と、云うことだとするとちょっとした細工が出来ます。

　ダウンロードさせてもらったときに、自分の保持する評価値を上げない。
　そうする事によって、相手の評価値は上がらないので、相対的に自分の評価値が下がる
ことはない。

また、
　ダウンロードをリクエストしてきたノードの優先順位を、そのノードを知るすべての評価値の
平均でとるとしたら、知らないノードへの問い合わせであっても0を返すことでそのノードの
評価値を下げることが出来る。
　ダウンロードをリクエストしてきたノードの優先順位を、そのノードを知るすべての評価値の
最大値でとるとしたら、2つ以上のノードで徒党を組むことによって評価値を操作することが
出来る。　

　あと、気になるのは評価の問い合わせをするノードの範囲の指定方法。

　とりあえず、こんなところ。
782 ：login:Penguin：03/07/30 23:56 ID:/QiGwPjI
>>779
【状況その壱】
>ノード評価時の優先方法を相対的な帯域確保や待ちノードの順位優先で行う。
相対的な帯域確保がどうなっていたらどのように評価するのか、また待ちノードの順位とはなにか

>標準ノードの基準値が下がるだけで相対的には正常な評価を出来る。
評価を下げられなかったノードと下げられたノードが出る恐れがある
｢相対的には正常な評価を出来る｣と断定できる根拠はなにか

>転送ノード同士の関係で完全に収束するので問題ない。
何がどういう風に完全に収束するのか

よくわからないので以上の点を詳しく説明してもらえないかな


【状況その弐】
大規模な詐称の場合についても考慮された方がいいかも
783 ：login:Penguin：03/07/30 23:56 ID:/QiGwPjI
>>780
【状況その参】
>他ノードの評価のためのデータ保持は負担が軽微であると考える。
>他ノードのプラス評価を削除することはメリットが希薄だと考える。
>よってどちらも懸念すべき事項ではないだろうと考えられるはず。
評価を消された場合についても検討しておかないとDOMを排除する為の評価システムそのものが
成り立たなくなりますよ

>評価を知らないのは全くお世話したことのない集団なので優先順位が低いのは諦める。
>ある程度長時間接続する場合は次第に評価があがっていく。
評価が消えないという前提にたったもので前提が崩れた場合は評価があがっていくかどうか不確実では

>また保持してあるノード情報から複数のクラスタを速やかに切り替えたり、同時に接続出来るようにする。
>どうしても常に高速でダウンしたい場合はあまり繋がないクラスタ側にもいつもUP帯域を配分しておく。
72案はDOMを排除する為に行われる評価であると思っていたのですが
評価をあげるたりするのは常に高速でダウンしたりする為なのですか

【状況その四】
>10MBもしくは10MB以下のファイル一つを転送し終えた時点で評価を一つ上下する。
>これでUP帯域を絞って評価を稼ぐことは出来ない。
UP帯域を絞ったノードの想定は評価を稼ぐ為ではなく評価を下げられないようにする為に
少しの転送を発生させる工夫をするDOMを想定しているのです

ところで問い合わせと応答によって帰ってくる情報を元にDOMを排除する72案は
最終的にDOMだと判断した場合はそのノードをどうするシステムなのかも回答をお願いします
784 ：login:Penguin：03/07/31 00:12 ID:5SXfUrVO
>>783
　表現は悪い気がするが、現在のMXのように、リクエストに対するキューを設け
その中からダウンロードを開始するリクエストを選択すのに評価値を使うということでは
ないでしょうか。

よって
>ところで問い合わせと応答によって帰ってくる情報を元にDOMを排除する72案は
>最終的にDOMだと判断した場合はそのノードをどうするシステムなのかも回答をお願いします
に関して云えば
　リクエストが入っていても評価値が低いノードは、いつまでたってもダウンロードできなくなる。

　他のリクエストが入っていなければ、自動的にダウンロードが始まるため
>>779
>転送や待ちノードが一つもない場合、評価の低いDOMノードにUP帯域を100%喰われる可能性もあるが
>転送ノード同士の関係で完全に収束するので問題ない。

　の様な問題が起こるのでは？
785 ：login:Penguin：03/07/31 01:34 ID:qUVPTMwV
リクエストを入れているのにいつまでたってもダウンロードさせんノードって評価が低くなりそうだな。
786 ：login:Penguin：03/07/31 01:53 ID:5SXfUrVO
>>785

　他のノードにはアップロードしているのだから、そのノードの評価値が下がることはなく、このシステムなら
評価は上がるでしょう。
　自分のノードがアップロードをしていれば評価値が上がって、そのような状態にならなくなるわけだから
もし、自分のノードがそういう状態に置かれたとしたら因果応報ってやつで、そのノードをうらむのは
筋違いってことでしょう。

　ただし、評価システムが正常に動作している場合に限る話ですが。
787 ：login:Penguin：03/07/31 12:16 ID:zJvq/kd6
・DL要求が届くのはどういう場合なのか
　検索リンクをたどってきた問い合わせに対して目的のファイルの場所を知っていると応答したノードにDL要求が届くので
　DL要求が届いたノードというのはそのファイルの場所を知っていて転送できるノードという事になる

・自ノードがDOMだと判断されて評価が下がるのはどんな場合なのか
　ファイルを転送できるはずなのに転送しない場合

・自ノードが相手ノードをDOMだと判断してDL要求ノードの評価を下げ転送を止めた場合
　相手ノード側はからするとファイルの場所を知っていて転送できるノードであるにも関わらず
　転送しないノードと判断される事になる

　これはどこからかDLして手に入れたファイルを持っているのに他のノードからのDL要求には応じないDOMの動作そのもの
　DOMを排除する為に転送を止めたのにUPしないノードとして自らがDOMと評価されかねない

　DOMを排除するほど自分の評価もDOMによって下げられててしまう事になるが
　これはDLさせたかどうかを判定材料とするシステム上では避けられない

・自ノードの評価が上がる場合はどんな場合なのか
　これはUPした場合になると思われるが
　共有させてやるほど自ノードの評価が上がっていくシステムなら
　DOMノードだろうと正常なノードだろうとかまわず共有させた方が自ノードの評価的には得になる
　自分がDL要求を出した時にUPした時の評価が他のノードに残っているなら他ノードから最大限優遇されるだろう

　そうなると自分が最大限優遇される為には他ノードに問い合わせる処理を省いて
　無条件に共有させた方がいいということになるので自分の評価を上げるのに最も有利なのは
　相手ノードがDOMかどうかを判断せずUPした場合ということになりそうだ
　
　DOMを排除しつつ自分は優遇されるようなシステムを目指しているのかもしれないが
　現時点ではかなり矛盾したシステムになると考えざるを得ないのでは
788 ：login:Penguin：03/07/31 12:17 ID:zJvq/kd6

72案の根幹に関わる問題点
・評価を消される問題
・評価を操作される問題

システム設計は都合の良い条件だけを元におこなってはいけない
最悪の事態を想定してそれに耐えられるものでなくてはならない
その為にはできるだけ想定外の事態というものが無いように
都合の悪い条件も考慮して設計をおこなう必要がある
それにより想定外の事態に陥ることを防ぐ事が出来る

見通しの甘い設計は簡単に想定外の事態に陥る
万が一最悪の状況が起きた場合でもそれが設計の段階から想定していた状況であり
対処されているシステムは堅牢です
簡単には崩壊しない

72案の評価法が評価を消される問題に完全に対応できないのであれば
他ノードに評価を保存してもらうという設計に無理があることになる。
また評価を操作される問題が解決できないのなら他ノードによる評価という
72案システムそのものに問題があることになるので他の評価法を考えるか
評価システムという考えかたそのものに問題が無いか考えなくてはいけない
789 ：login:Penguin：03/07/31 16:13 ID:FjbboMl2
72案の問題点はダウン開始が異様に遅いだろうということと
オープンソースだと匿名性なさそうなことだな。

DOMを防げる可能性があるってだけで他の効率も匿名性もだめになると思う。
790 ：login:Penguin：03/07/31 23:18 ID:sIJ6pAL4
>>784
完璧な補足どうもです。


>>782
>評価を下げられなかったノードと下げられたノードが出る恐れがある
>｢相対的には正常な評価を出来る｣と断定できる根拠はなにか
評価を下げられたノードが出た場合、下げられなかったノードが相対的に優遇されることになる。
つまりネットワークの効率を悪化させ崩壊させることは出来ない。

よってDOMを目的としない【状況その壱】に偽評価を流すメリットがない。
それ以外の状況があるならまたどうぞ。

>>783
>評価をあげるたりするのは常に高速でダウンしたりする為なのですか
これはDOMとUPしているノードとを区別する為です。

>UP帯域を絞ったノードの想定は評価を稼ぐ為ではなく評価を下げられないようにする為
DLしているのにも関わらず評価を下げられないことも含めて稼ぐと書きました。

>>783
>評価を消された場合についても検討しておかないとDOMを排除する為の評価システムそのものが
>成り立たなくなりますよ
>評価が消えないという前提にたったもので前提が崩れた場合は評価があがっていくかどうか不確実では
1MB程度のディスク容量を稼ぐことや個人的にUP側の評価をプラスしないことが、
評価情報ファイルをわざわざ削除することや
正規版とは別にプラス評価を保持しないWinnyを導入する苦労に見合ったメリットとは思えない。
791 ：login:Penguin：03/07/31 23:19 ID:sIJ6pAL4
どのような不正ノードにも言えることだが、
不正することのメリットが無ければ不正ノードにはならない。

メリットが大きければ大きいほど不正ノードの比率は増える。
その中でもDOMになれることは最大のメリットだろうね。

よって対策案が必要になるわけだが
どのような対策案でも多くのノードは正常であるということを前提としてしか成り立たない。
メリットが極めて少ない不正ノードが大多数を占めるような場合は想定する必要がない。

自ノード以外の全てのノードが検索キーを遮断したら
自ノード以外の全てのノードが捏造ファイルしか共有していなかったら
自ノード以外の全てのノードがDOMパッチを当てていたら

と考えるようなもの。

【状況その弐】など想定出来る現実的な問題については対策する必要があるだろうが、
検索キーの遮断を防げないからといってそのネットワークが実用に耐えられないわけではない。

もちろん何も犠牲にせずに解決出来る問題であれば対策すべきだが
評価情報を保持しない極少数のノードの存在が72案を支持できない理由には成り得ないと思っている。
792 ：login:Penguin：03/08/01 00:09 ID:s25HrALe
>>790
>【状況その壱】
>・共有する気などまったくなくネットワークの崩壊だけが目的の団体、組織によるノード投入
>　偽評価ノードの大量投入

>評価を下げられたノードが出た場合、下げられなかったノードが相対的に優遇されることになる。
>つまりネットワークの効率を悪化させ崩壊させることは出来ない。
実際の実情とずれた評価情報に流通することによって評価システムの信憑性がなくなります

>よってDOMを目的としない【状況その壱】に偽評価を流すメリットがない。
ネットワークの崩壊だけが目的の団体、組織とは何かについて具体例を出すまでもないでしょう
P2Pネットワークそのものがなくなればいいのにと思っている団体、組織は存在します
またP2Pネットワークがなくなることのメリットはそれらの団体にとって多大なメリットがあるかと

>これはDOMとUPしているノードとを区別する為です。
DOMを排除する為にUPしないノードとの区別はどうやってしますか
１回のUPが完了して評価が上がるまでの時間あたりの回数とオープン後増えると思われる多数のDOMからのDL要求に対して
UPをせずを排除する度にさがっていく時間あたりの評価の回数はどちらが多いと思いますか

>1MB程度のディスク容量を稼ぐことや個人的にUP側の評価をプラスしないことが、
>評価情報ファイルをわざわざ削除することや
>正規版とは別にプラス評価を保持しないWinnyを導入する苦労に見合ったメリットとは思えない。
個人的にUP側の評価をプラスしないことのメリットは>>781がかかれているようです
もちろんDOM側にメリットが生じる例のようですので実行する人が出てくる恐れは充分あります
>>791
>どのような不正ノードにも言えることだが、
>不正することのメリットが無ければ不正ノードにはならない。
メリットがある人を想定した設計にしたほうがいいのでは
想定していなくてなにかあとで問題がおきるより何か問題がおこった時に
｢その対策は織り込みずみです｣のほうがいいとおもうよ
793 ：login:Penguin：03/08/01 00:35 ID:s25HrALe
>ただ完全なDOMであっても1%未満(1000人程度?)など小規模な詐称、回線の圧迫であれば >>779
>評価情報を保持しない極少数のノードの存在が72案を支持できない理由には成り得ないと思っている。 >>791

72案が成り立つ場合の想定を1%未満の詐称とか極少数の保持しないノードしかでないからと想定するのもいいけど
1%以上の詐称や多数の保持しないノードが出た場合をまったく想定してみないという事はそれらの事がおこった場合の
対策を考えていないという事になる
案としては実装する前に不具合が予想される時点で不完全なものになると思うのだが
794 ：login:Penguin：03/08/01 02:21 ID:DmhVi7Yy
＞個人的にUP側の評価をプラスしないことのメリットは>>781がかかれているようです>>792
これを見て思ったんだが自分がプラスしないだけなら十万分の一程度しか優待されないだろ
かな～り意味がなくないか？個人的ではなく組織的にやるなら別だろうけどねぇ

＞案としては実装する前に不具合が予想される時点で不完全なものになると思うのだが>>793
つまり>>791で言ってるのはGnutella型一般に言える検索キーの遮断を防げないことや
新規のファイルの流入を許す限り捏造ファイルの共有は避けられないが
これも不具合や不完全と言えるのかってことでは
1%未満とか極少数じゃなくDOMが10%になったりや評価しないのが半数になっても大丈夫だと思うけどね
さすがに半数以上が嘘ついてDOMになったらやばいけど(藁
795 ：login:Penguin：03/08/01 05:46 ID:2UY8lTdI
なんだお前らまだやってたのか
796 ：login:Penguin：03/08/01 09:04 ID:asRIh5gW
>>793
　意図的に、高い評価値を応える2個1組のノードがあれば、
　それぞれのノードは優先ノードになれるとも考えられます。

　他のノードの評価値を落として、自分を優先するよりこっちのほうが
よりお得といえそうだ。
797 ：login:Penguin：03/08/01 12:29 ID:s25HrALe
>>791
>メリットが大きければ大きいほど不正ノードの比率は増える。
>その中でもDOMになれることは最大のメリットだろうね。
DOMになれることが最大のメリットであるならDOMとして排除されないような改造をする事は
DOMという行為を成立させる上で必ずおこなわれるメリットのある行為でしょう
自ノードの評価が下げられる事により自分が排除されかねないシステムなのに
わざわざ相手の評価を上げてやるDOMはいないのでは

DOMかどうかを判断する時の基準になる評価情報をDOM自身が消したり操作したりできるという
設計上の大穴が存在する以上０DOMパッチと共に０評価パッチが出回るのは想像に難くない
そうなるとDOMの数だけ評価を操作したノードが出てくるわけで
オープンソース化によりネットワークが成り立たないほどのDOMが増える事を想定しているのなら
同数の評価を操作するノードが出てくる事も想定しないとだめでしょう

評価が成り立たずDOMを排除できないのであれば
効率を落としてまで72案を取り入れる『メリット』はないですね

>>796
１回のUPが完了したら評価が上がるシステムであれば小さなファイルを2個1組のノード間で
高速になんどもやり取りして実績をあげれば瞬く間に最大評価に出来るかもしれない

つまるところDOM側で評価を操作できる時点で72案は終わってるような気が
798 ：login:Penguin：03/08/01 23:34 ID:P5CFLuZr
>>797
だったら検索システムはどうするよ？
流れてきた検索キーに対する結果を減少したり遮断したり偽装すりゃ
キーを流した元ノードがDLし難くなる分少しは自分がDLしやすくなるだろ
だからといってほとんどのノードがそういう改造をするか？
相手の評価を保存しないのも誰か一人に評価を上げてもらうのもいっしょ
やればほ～んの少しだけ優待されるけどそんな目にも見えない程度なら誰もやらない
それに今のwinnyのキャッシュシステムも同じことが言えるよ
不要なキャッシュを常に削除してればUPはなくなるけど
ほとんどのノードはそんなことをやっていないからwinnyはとっても使いやすいファイル共有ソフトのまま
大量に不正ノードが発生した時に運用できないことが不完全だというなら
これも設計上の大穴と言うのかねぇ
逆に72案ならこの手の不正ノードを抑制出来るはずだよ

他に考えるべき案はないんだしもっと詰めていってもいいと思うんだけどな
「終わってるような気が」とかあなた一人の考えで終わってるかどうかの判断されても仕方がないよ
それとも終わったことにしておいて他に何かこのスレで考えたいことでもあるわけ？
まだ議論も始まったばかりだし俺は「全然終わってない気が」とでも妄想しておこうかな
72案を採用した場合だけほとんど価値のない不正行為をする香具師がわっさわっさと出てくるってのは納得いかない
まるで今のwinnyに対するDOMパッチくらい価値があるみたいに言ってるし
このスレを見てるとなんか議論して可否を検討するよりも72案を潰したいだけの意図が見えて嫌だな
799 ：login:Penguin：03/08/01 23:46 ID:s25HrALe
>>798
さてそろそろ72案の問題点にご指摘してもループするだけですので
72案の問題点について考えるスレから
Winnyのオープンソース化を考えるスレに話題を進めたほうが良さそうです
800 ：login:Penguin：03/08/02 00:03 ID:rLTHBCFJ
>>799
これがループか(藁
ループしてるのはあなただけだと思うよ
説明してるのには目もくれず(理解出来ないだけ？)
根拠も反論も無しに同じ文言を繰り返す
おまけにWinnyのオープンソース化を考えるスレで
72案を検討してる理由すら分かっていないようで
どうやら議論を混乱させて72案を潰したいだけってのが正解みたいだね
801 ：login:Penguin：03/08/02 00:07 ID:mou8IbHX
なんだ
追いかけてるのが自分の尻尾だと気付かない馬鹿が延々グルグル廻っている
隔離スレッドはここだったのか。
802 ：login:Penguin：03/08/02 00:14 ID:26W7ED1c
>>799
47氏がオープンソース化する上で必要と言っている
現在のnyにないDOM対策の数少ない素案を検討すること以上に
このスレで考える必要があることをどうぞ。
803 ：login:Penguin：03/08/02 00:16 ID:pE8R9TFx
>>754
dasoudesu
804 ：login:Penguin：03/08/02 00:32 ID:oVqFm3vz
>>801
禿同。
Linnyスレから見てるけど>>799には久しぶりに笑わしてもらったよ。
805 ：login:Penguin：03/08/02 00:34 ID:EtWy8Xgc
昔はLinnyとかあったね。
個人的にはあっちのほーが好きだな
806 ：login:Penguin：03/08/02 00:38 ID:oVqFm3vz
>>805
コンセプトは全く「新しいファイル共有ソフト」だったね。
あれの欠点は535氏が47氏じゃなかったことか(w
807 ：login:Penguin：03/08/02 02:35 ID:3wKKGm71
>>798
　評価値の使い方をどのように行うかが不明なので、確定した話ではないのですが

　帰ってきた評価値の最大値を優先順位の設定のために使うという使い方を下場合、お互いに対して
最高値の評価値を返す2つのノードがあれば、その2つのノードは最高の優先ノードとなりえます。
　ちょっと上がる程度なら改造はしないといわれますが、これなら改造に値する効果といえるのでは
ないでしょうか。

　また、ちょっとのことで…というのならばSafeNyで騒いでいるのをみると、ちょっとしたことでも出来るのならば
やりたいと思う人間がいる例になるのではないでしょうか。Port0に帯域を取られるからと一生懸命細工しています。

　Winnyで不要なキャッシュを削除の話ですが、現状でキャッシュを消すという処理をするためには、ユーザーが
操作をしなければなりません。しかし、プログラムを改造することが出来れば、ダウンロードが完了し変換が終わった
後にそのキャッシュを消すような機能を追加すれば、そのノードについては不要なキャッシュを持たなくなるので
効率が良くなることでしょう。一度の改造で面倒なく当人にとって不要なキャッシュを消せるとしたらどれほどの人が
その改造を行いたいと思うことか。
　もっとも、多数のノードがその改造を行えば結局のところソースと各ノードの1対1の転送が基本になってしまい、
全体としての効率はひどくおちることになるでしょう。

でもって、72案支持者に質問

　Aというノードへの評価値を最大値で返すBというノードと、
　Bというノードへの評価値を最大値で返すAというノードが、
同じクラスタ内にいた場合に、評価が正当に行う方法はあるのか？

　「改造されたらどうするか」という話に対して、「改造なんかする奴居ない」で返せばループもするわな。

>>797>>799に賛同です。
808 ：login:Penguin：03/08/02 03:02 ID:oVqFm3vz
>>807
評価値の使い方をどのように行うかが不明なのに話題を変えることに賛成ですか？
質問があるのに話題を変えるんですか？
矛盾していると思うんですが、いったいこのスレで何を考えたいのですか？
809 ：login:Penguin：03/08/02 03:11 ID:K8UG6wEJ
>>808
　評価値の使い方で、問題が解決されるならば、どのように評価値を使うのかを
答えて欲しいのですが。

　答えられないようなら、というか答えている人もいないようなので、72案はダメだろう
と思うだけです。

　答えられるなら、72案は進化できると思いますが、答えてくれますか？>>808
810 ：login:Penguin：03/08/02 03:42 ID:oVqFm3vz
>>809
一度も通信をしたことのないノードにも平均評価値を返すことは前提にされてませんよね？

一応書いておきますが、
72案はあるノードからDL要求があった場合に複数のノードに問い合わせるわけですから、
例えば100ノードに問い合わせるとすれば

Aというノードへの評価値を最大値で返すBというノードと、
Bというノードへの評価値を最大値で返すAというノードが
あったとしてせいぜい1%の評価を左右することしか出来ないですよ。

常に最高の優先ノードになるためには同じクラスタにいる全てのノードに
評価値を最大値で返してもらう必要があるでしょう。

つまり個人的に評価を詐称するのはほぼ無意味です。
811 ：login:Penguin：03/08/02 08:54 ID:+5/fIriQ
>>807
>また、ちょっとのことで…というのならばSafeNyで騒いでいるのをみると、ちょっとしたことでも出来るのならば
>やりたいと思う人間がいる例になるのではないでしょうか。Port0に帯域を取られるからと一生懸命細工しています。
これが本スレなどで騒がれているのは以前からUPノード側にポート0に対する害悪感情があったから。
何故、害悪感情があるかと言えば転送を行わないなどポート0はあまりネットワークに貢献しないから。

つまり騒いでいるのは普段からUPしていて共有ネットワークを正常に維持したい者達で、
己のために評価を詐称することや、DOMになることとは全くの別物。

>Winnyで不要なキャッシュを削除の話ですが、現状でキャッシュを消すという処理をするためには、
>ユーザーが操作をしなければなりません。
>一度の改造で面倒なく当人にとって不要なキャッシュを消せるとしたらどれほどの人が
>その改造を行いたいと思うことか。
残念ながら簡単な外部ツール（広範には出回っていないが）を使えば一々操作しなくても可能だよ。
キャッシュ変換されたDownフォルダに存在するファイルのサイズを調べて、
それとほぼ同じサイズを持つキャッシュをキャッシュフォルダから削除すればいいだけ。

しかしこのようなツールが騒がれず、一般に出回らないのは何故だろうか？
それもまたネットワークを正常に維持したいと思っているものがほとんどだからだろう。
812 ：login:Penguin：03/08/02 08:54 ID:+5/fIriQ
>>797
根拠もなく評価を保持しない者が極少数であるとか、
72案を詰める必要があると言っているのではないよ。

こうした現在のWinnyの状況も踏まえて
大半のノードは目にも見えないようなメリットのために不正ノードにはならないと考えているから。

どちらが正しいかは出来るだけ多くの根拠を示した方が判断しやすい。

それと問題点を指摘して議論することで評価方法や評価基準も少しは具体的になった。
>現在のMXのように、リクエストに対するキューを設け
>その中からダウンロードを開始するリクエストを選択すのに評価値を使う
>10MBもしくは10MB以下のファイル一つを転送し終えた時点で評価を一つ上下する。
決してループしているわけではない。

また72案がどういった設計なのか個々に思い違いをしている部分が多い。
これのより良い解釈を発言してもらうだけでも価値はある。

もちろん評価を問い合わせる範囲はどの程度か、何段階の評価をするのか、
本当に10MB程度で評価を上下していいのか、【状況その弐】はどの程度の規模で効果が出るのか、
予測される範囲を上回るほど【状況その弐】が増えた場合は本当に何の対策もないのか、
他にも問題点はないかなど考えるべきことはあるだろう。


しかし議論もせず「72案は終わってる」とか「72案はダメだろう」と勝手に決め付けるのは随分乱暴ではないかと。
813 ：login:Penguin：03/08/02 11:43 ID:3wKKGm71
　すこしは前進しそうなので、もうしばらく

>>810
　評価値を100のノードに聞きその平均値で優先度を決めるので、個人的に評価を詐称することは
無意味とのこと、そこまでは了解しました。ただ、この方式にも問題点はあると思いますが、その前に
問題点を考えるための前提条件を詰めたいと思います。

　「72案では、ノードの特定を如何にするのか」。

　評価を行うためには、ノードの特定が必要です。
　IPアドレスを使う？ニックネームをつける？どのようにして解決しますか？

>>811
　外部ツールで可能。確かに可能です。しかし誤爆もあるでしょう。ま、誤爆の問題はおいておいて

　流れない理由としては、「多数のノードがそういったツールを使うことによってネットワーク自体が
崩壊すれば、流した本人にとっても利益にならない。」からじゃないかと思います。

　逆にいえば、ネットワークを崩壊したい人間はそういったツールを、便利なツールとして流すことも
出来るわけです。アメリカでは共有フォルダーにウイルスを入れてネットワークを崩壊させるなんて
ことも考えているぐらいですから。

　ユーザーに理性に過度に期待するより、攻撃に耐えられるシステムを構築することが必要だと
思うわけです。
814 ：login:Penguin：03/08/02 11:55 ID:pE8R9TFx
問題点を指摘しているのはDOMを排除できるシステムを考える為であって72案を潰すためではない
72案が問題点に対処できるのなら詰めていくのもいいかもしれないが指摘した問題点に72案では構造上対策が取れない

72案の他ノードによる評価システムで命綱なのは評価情報であるが評価情報を撹乱されてしまえば評価システムは崩壊する
そういう穴がある以上評価情報を意味のないものにする為の改造を施されたバージョンが配布される恐れはあるし
大多数がそのように評価を改ざんする事態になったとしても72案ではそれを止められない＝DOM対策の失敗

72案を今後いくら詰めていってもあいている穴に対処する方法のない72案ではDOMを排除できない
この穴は他のノードの評価を元にDOMを判別しようとする事から来る穴なので
DOMの判別方法を他のノードの評価を元にしない別の方法に変えれば
72案の穴である
・評価を消される問題
・評価を操作される問題
というものは自然と消滅する

DOMを排除する事が一番の目的であるならば穴のなさそうな次のDOM判別法の案を出して
その案にまた別の問題が発生しないかを検討をしていくほうが建設的では
815 ：login:Penguin：03/08/02 12:16 ID:APsWJckr
　　┌───────B←────┐
　　│　　　　　　　　　 │　　　　　　　 │
　　│　　　　　　　　　 │.　　 ┌→ Ｆ ┘
　　↓　　　　　　　　　 ↓.　　 │
　　Ｃ←──────A──┼─→E
　　↑　　　　　　　　　 │.　　 │
　　│　　　　　　　　　 │.　　 └→G
　　│　　　　　　　　　 ↓
　　└───────D
・BがAにUL要求。Aは周りにBの評価を尋ねる。
・CはBからDLしたことがあるノードで、Bをプラス評価する。
・FはBにULしたことがあるノードで、Bをマイナス評価する。

Bの評価の重複を防ぐために、C、F(Bの直接の評価者)のIP(一部でも可)を
付与したBの評価をAに送ることになるだろう。

BとCがグルだったとしても上げられる評価は最高で一つ。
AはEFG経由でもBの評価を尋ねるので影響は少ない。
ここまでは既出。

だが、
BとDが組んでBの評価を不正に操作する場合は問題が大きい。
つまりDが架空のC1、C2、C3のIPを付与したBの評価をAに送った場合。
これはキツイ。俺では対抗策を考えつかない。
(実はC自身が架空のC1、C2、C3のIPを付与したBの評価をAに送る方が単純
なんだが、図にするとさらにわかりにくくなったので……汲んでくれｗ)


(´-`).。oO(もし捏造対策がもう一歩進めば、自動擬似交換を模索できるかも…)
816 ：login:Penguin：03/08/02 12:52 ID:tQee7kZd
何度も言うがソース公開したらDOM対策は無理。

　あ　き　ら　め　ろ
817 ：login:Penguin：03/08/02 13:45 ID:3wKKGm71
>>816

　完全なDOM対策は無理でしょう。しかし、「こんなことならMXでDOMったほうがいいや」ってぐらいの
DOM対策は可能です。
　DOMらなければ「Ny使うより便利」ってことも可能です。

　単純に「無理」というのは思考停止。
　有効に機能するDOM対策を考えているスレッドに考える気もない人間は要らない。
　不可能だというのなら、出ている案の穴を指摘するぐらいのことをするべきでしょう。
　めんどくさいとか、暇がないなら、いちいち書き込まず無視していればよし。

最近のDOMerの動向
　72案に穴がることをしって、72案が採択されるように働きかける。
　72案の穴をふさごうとする行動に関して、改造はない「はず」といういけんでお茶を濁そうとする。
　72案を進化させようとする動きに対して、「DOM対策は無理」（DOMerの合言葉)で開発を止めようとする(藁。
818 ：login:Penguin：03/08/02 17:03 ID:xGAlKt5s
あと何年くらい議論してるんだろうね。[w
819 ：login:Penguin：03/08/02 17:12 ID:iw2FAeVQ
>>813
>ユーザーに理性に過度に期待するより、攻撃に耐えられるシステムを構築することが必要だと
>思うわけです。
>>814
>DOMを排除する事が一番の目的であるならば穴のなさそうな次のDOM判別法の案を出して
確かに、匿名性を保ったまま100%DOMを排除出来て、Freenetには負けない効率を保てる
完全無欠な案が出てくれば是非検討したい。全く72案にこだわる理由はないからな。

だがそんな案は出ていないのだから無いものねだりしても仕方ないだろう。

どういったシステムであれ大多数がDL効率を最大にする不正ノードであれば成り立たないのは事実。
WinMXもGnutellaもFreenetもWinnyも同じこと。
それは評価システムに限ったことではない。それを受け入れないのか？

また少なくとも72案は現Winnyでは有効なキャッシュの削除を抑制する効果があり、
評価方法によっては捏造ファイルを多数流しているノードを周囲に警告することも出来る。

出来る限り不正を防げるような方法は考えるべきだし、もちろん考えているが、
どんな案だって大多数のノードが可能な限りDOMに徹するような状況だけを想定したら話も進まない。
820 ：login:Penguin：03/08/02 18:46 ID:pE8R9TFx
>>819
>どんな案だって大多数のノードが可能な限りDOMに徹するような状況だけを想定したら話も進まない。
そもそもオープンソース化したら大多数のDOMが現れてｎｙのネットワークが崩壊するような状況を
想定しているからDOM対策が必要なんでしょう？

大多数のノードが可能な限りDOMに徹するような状況を想定せず小規模なDOMしか発生しない状況しか
想定しないのであればそのままオープンソース化すればいいということになってしまうよ

多数のDOMが現れる事を想定しているからこそ情報を改修する沢山のノードを想定するわけだし
また違う案が出たとしても多数のDOMが現れる事を想定して問題点を指摘することになると思う

1%未満とか小規模とか極少数のノードとか想定しないのであればDOMの存在もその程度と想定してはどうですか
DOM対策など考える必要がなくなりますし。。。
821 ：login:Penguin：03/08/02 18:54 ID:3wKKGm71
>>819

　72案は、絵に書いた餅としてはとても美味しそうですが、絵にかかれていない部分がどんなものか
知りたくて、話をしているつもりなのだけど。

　現状で完全無欠を期待しているわけではなく、72案にどれほどすっぱい部分があるのか考えておく
必要があるだろうということ。

　72案のすっぱさが許容範囲であれば食べるでしょう.。
　現状としては、72案を否定するわけではなく、72案を洗っている状態。
　もちろん、「確認なんかしてないで、甘いんだから喰え」って話ならきっぱり否定しますけど:-)

　で、ノードの特定の方法はどうするのでしょうか？
822 ：login:Penguin：03/08/02 19:45 ID:iw2FAeVQ
>>820
>そもそもオープンソース化したら大多数のDOMが現れてｎｙのネットワーク
>が崩壊するような状況を想定しているからDOM対策が必要なんでしょう？
それはWinnyをそのままオープンソース化した場合だろう。
今のままなら本当にDOMパッチ一つでアップ0のダウンし放題ということが可能だから、
何処かからパッチを落として当てるだけの労力に比べて極めてメリットが大きい。
配布を目的としないならDOMパッチを当てない意味がないほどに。

そこで72案は自ノードの改変だけでは左右できない他ノードによる評価というものを取り入れた。
これによりただアップしないだけのノードはダウンしずらくなる。
もちろんここで評価の詐称というのも考える。

まずノード単独での詐称は請求された相手の評価を常に最低で返すということが考えられる。
しかし常に100程度のノードに評価を請求するシステムにおいて
自ノードが評価請求先ノードの1/100に入った場合、
何処かの誰かが自分ではない可能性の高い他の誰かより1%ダウンしやすくなるだけ。

これではわざわざパッチを当てるメリットすらないだろう。

そこで2ノード以上を使った詐称が起きるわけだが少人数であれば>>810のように簡単にはいかない。

またこの時点で単独で行えるDOMと複数のノードとの協力が必要になるDOMでは労力が全く違う。
評価を詐称する場合には相手方のIPアドレスが必要になるだろうが、
それを固定IPなりDDNSなり、定常的に追っていける設備や知識があるものがどれだけいるだろうか。

どんなに優れたパッチが出回ろうと、ここでほとんどの初心者層は手が出ない。

もちろん知識もあって集団で行動出来るグループが詐称することも考えられるが。
Winnyをそのままオープンにした場合と同じように考えられても困るよ。
823 ：login:Penguin：03/08/02 20:03 ID:iw2FAeVQ
>>821
>「確認なんかしてないで、甘いんだから喰え」
「確認なんかしてないで、すっぱいんだから喰うな」
という話になっていたので否定していただけです。

こちらも無理して喰う気はさらさらない。
よりおいしそうな餅があればすぐそっちに飛びつくつもり。
無いからじっくり確認中。

>で、ノードの特定の方法はどうするのでしょうか？
以前議論した時の結論ではIPアドレスを使う方が有力ということになってたのでは？
ずっとそのつもりで書いてました。
これもいくつか問題ありそうだけど。
824 ：login:Penguin：03/08/02 20:30 ID:pE8R9TFx
>>822
まず1/100という小規模の詐称を想定していますが1%の本人の詐称以外から帰ってくる
その他の99%の評価に信頼性がない可能性が出る事が問題になるのです

信頼性のない改修された評価が返ってくる事を防げないし信頼性のある情報かどうかも確認もできない72案は
DOMでない者をDOMと評価したり正常なノードをDOMと評価したりする恐れが捨てきれません

>どんなに優れたパッチが出回ろうと、ここでほとんどの初心者層は手が出ない。
DOMできる優れたパッチがでればパッチを当ててあるバージョンとして配布するものはすぐ出てくるでしょうし
そういう情報はすぐに広まるのでパッチを当てられない初心者層もすぐに使い始めると予想できます

つまり起こらない事を前提とするのではなくおこった場合でも大丈夫なシステムでなければだめじゃないのか
という事なのですが

同じような意見として>>813が
>攻撃に耐えられるシステムを構築することが必要だと思うわけです。
と書かれていますがまったく同意です

>Winnyをそのままオープンにした場合と同じように考えられても困るよ。
もちろんそのままではオープンに出来ないからこそ対策を考えているのだし
その対策として出てきている72案について問題点を指摘しているわけですが
825 ：login:Penguin：03/08/02 21:07 ID:iw2FAeVQ
>>824
>DOMできる優れたパッチがでればパッチを当ててあるバージョンとして配布するものはすぐ出てくるでしょうし
>そういう情報はすぐに広まるのでパッチを当てられない初心者層もすぐに使い始めると予想できます
かなり勘違いさせてしまったようだけど

>評価を詐称する場合には相手方のIPアドレスが必要になるだろうが、
>それを固定IPなりDDNSなり、定常的に追っていける設備や知識があるものがどれだけいるだろうか。
>どんなに優れたパッチが出回ろうと、ここでほとんどの初心者層は手が出ない。
822で初心者層と呼んでいるのはパッチすら当てられない者ではなくて、
クライアントとしてDDNSの運用が出来ない者。

これで大多数が不正ノードになれない理由の一つを理解してもらえるかな？
826 ：login:Penguin：03/08/02 21:14 ID:OvlDsUpI
100ノードに問い合わせとか言ってますが問い合わせ頻度はどうなるのでしょうか？
DL開始時だけなら、DL始まったのを確認してからUPを切断してDOMになれる。
827 ：login:Penguin：03/08/02 21:16 ID:pE8R9TFx
>>825
>>評価を詐称する場合には相手方のIPアドレスが必要になるだろうが、
　・
　・
>これで大多数が不正ノードになれない理由の一つを理解してもらえるかな？

問い合わせがあった時にそのIPアドレス（ノード）の情報に対して詐称評価を応答する時
IPアドレス（ノード）の情報は問い合わせに含まれているのでその時点でわかりますが

理由の一つについて解答しましたが他に無いようでしたらそろそろ次に行ってもよろしいか
828 ：login:Penguin：03/08/02 21:44 ID:iw2FAeVQ
>>826
UPを切ってDLばかりしていれば評価が下がる。
それでも大きいファイルの場合は時間で区切るか、データ転送量で区切るか別にして、
再問い合わせは必要だろうな。

>>827
勘違いでなかったなら構わないよ。
829 ：login:Penguin：03/08/02 21:53 ID:xjtc+cBO
>>827
これがループか(藁
ループしてるのはあなただけだと思うよ
説明してるのには目もくれず(理解出来ないだけ？)
根拠も反論も無しに同じ文言を繰り返す
おまけにWinnyのオープンソース化を考えるスレで
72案を検討してる理由すら分かっていないようで
どうやら議論を混乱させて72案を潰したいだけってのが正解みたいだね
830 ：login:Penguin：03/08/02 21:56 ID:OvlDsUpI
>>828
再問い合わせの間隔は？
あまり問い合わせが多いと問い合わせだけでずいぶんとトラフィックが流れそうだが。
831 ：815：03/08/02 22:32 ID:APsWJckr
漏れは無視されたままなんでしょうか
ID:iw2FAeVQ さん、>>815の解法はありますか？
832 ：login:Penguin：03/08/02 23:15 ID:3wKKGm71
>>822

　ノードの特定に使用されるものはIPアドレスもしくはドメイン名、および修飾するデータ(ポート番号など)ということでよしとして、

　さて、詐称の方法です。

１．あるノードAがノードBに対してダウンロード要求を発行します。
２．ノードBはノードA以外のいくつかのノードに対して評価値を求めます。求めるノードは、
すでに知っているノードリストにあるノード。
３．求められたノードは適当数同じ要求を他のノードにリレーします。その総数は100程度とする。
４．評価値を求められたノードは、その評価値をBに対して返す。
５．ノードBは戻ってきた評価値の平均をとるなりして最終的な優先順位をつける。

　ここまでが正常な動作。

　さて、2の段階で、「Aに対する評価をBに返してほしい」と依頼を出すわけですが、実際に問い合わせを受けていない
ノード(仮想でもかまわない)がBに対して「Aは優秀なノードだ」と評価値を送り込んだらどうなるでしょう。
　3の段階でリレーで評価依頼をまわすとしたら、B自体は自分が問い合わせたノード以外のどのノードから
評価値が戻ってくるか知ることは出来ません。よって虚偽の評価値を受け取らなければならなくなります。

　さて、帰ってきた評価値が正しいかを判断する方法は？


　ついでの疑問
　さて、新しいノードがたちました。当然このノードに対する評価は０です。また、このノードにはアップロードするような
ファイルがない。もしくは誰からもリクエストされないようなファイルしかもっていなかったとします。
　周りのノードは有効なファイルを共有し合っていて交換が頻繁に行われています。当然評価値も高くなっています。
　この環境につながれた、新しいノードはいつになったらファイルを落とせるようになるのでしょうか。
833 ：login:Penguin：03/08/02 23:16 ID:pE8R9TFx
>>828
どうも
では散々問題点を指摘した手前まな板に乗ってみますか

DOMノードの判別方法を考えるにはどういうノードをDOMノードとするかを決めなくては判別できないが
MXと違って１対１でファイルを交換する訳ではなくマターリ共有のｎｙではDLしているノードが現在UPしているかどうかでは
判断できないしまた現在UPしているとしても過去にUPしているか将来UPするかはわからない
そこで単純に今現在自ノードに対して共有できる状態にあるかという事だけでDOMノードか否かの判別をすればいいかと

今現在共有できる状態にあるかどうかは相手に普通に問い合わせても帰ってくる情報に信頼性はないのでDL要求が来た時に
相手ノードから自ノードへ正規のULコネクションを確立させこちらから相手側へULしているあいだ切れないかを監視しつづける

自ノードに対してULコネクションを確立できる相手は正常ノードとする

基本はマッタリということでDOM対策はこれだけ
834 ：login:Penguin：03/08/02 23:27 ID:3wKKGm71
さて、ここでP2Pによるファイル共有を快く思わない組織があったとします

　その組織は、偽装ノードを作成しました。
　ノードの機能としては、どのようなノードがあるかのリストを作成する。
　作成されたノードのリストを元にノードの評価を問い合わせ、ノードの
転送量順のリストを作成する。
　上位にいるノードは人気のあるファイルを持っていると推定することが出来る。
　そのノードに対して、リクエストをかけてみる。
　「ないよ」と帰ってくるならよいが、「有るけど待って｣とかえってきたら…
835 ：login:Penguin：03/08/02 23:37 ID:3wKKGm71
>>833
　ちょっとまったぁ～(笑

　それこそループネタですよ。
　ダウンロードしている間だけ、アップロードしてくれるノードに対してアップロードしていればよいのなら、
ダウンロードしたファイルを、他のノードにアップロードしてくれる保証にはなりはしない。

　ダウンロードが終わったところで、手のひらを返される可能性もある。

　正規のコネクションを確立させるといっても、プロトコル上正規であることは確認できても
相手のノードの中の機能が正規とは限らない。

　で、それに対する案として、52案もでています。が･･･
836 ：login:Penguin：03/08/02 23:47 ID:pE8R9TFx
>>835
待ちましたｗ

>ダウンロードしたファイルを、他のノードにアップロードしてくれる保証にはなりはしない。
>ダウンロードが終わったところで、手のひらを返される可能性もある。

他のノードにアップするかどうかはどうでもいいのです
自ノードに対して正常であってくれればそれでDOMではないと判断します

>正規のコネクションを確立させるといっても、プロトコル上正規であることは確認できても
>相手のノードの中の機能が正規とは限らない。
とりあえずその時点でDL要求を出してきた相手ノードに対して欲しいファイルを要求するわけでもないので
コネクションが確認できるだけでULします
837 ：login:Penguin：03/08/02 23:51 ID:3wKKGm71
>>836

　い、いや、だから(汗)

　DOMパッチとして、自らがDL要求していないノードからのリクエストは蹴るみたいな
改造をしていたとしたら、十分機能してしまうのですが…
838 ：login:Penguin：03/08/02 23:56 ID:pE8R9TFx
>>837
なるほど
自らがDL要求した場合にリクエストが蹴られたばあいはDOMノードとして
DOM警告を自動的にネットワーク上に流すうにするとかではどうでしょう
839 ：login:Penguin：03/08/03 00:00 ID:CJNbKCU1
>>838

　その場合、他のノードをDOMノードとして認定させて自分だけがDOMノードと認定されないなんて姑息な考えで
　知ってるノードすべて（は云いすぎだとしても)に対して「DOM警告」を出すノードがでてくるかも知れません。

　また、それは、ネットワークの存在を破壊する攻撃としてもとても有効に機能します。
840 ：login:Penguin：03/08/03 00:03 ID:dVbVv1j/
>>834
怖いな～
ノードリストや大まかな転送量を調べられるって嫌だね。
今のnyはノードリストを作る事はできても誰がどれだけ転送したかは分からないもんね。
匿名性を保ったまま第三者による評価システムを機能させるのは無理があるよ。
841 ：login:Penguin：03/08/03 00:11 ID:iNpxliz8
>>839
確かにその可能性はあるな
ではネットワーク上にDOM警告を流してそれを他のノードが判断材料にするシステムは却下
単に自ノードとリクエストが蹴られたノードを切断してそのノードとは一定期間繋がないということにしてみます
842 ：login:Penguin：03/08/03 00:28 ID:kORWYWIr
実装はまだですか～？
843 ：login:Penguin：03/08/03 00:36 ID:NSwrTVAf
>841
相手の蹴る理由としていくつかのパターンが考えられるが

いずれにしても欲しいファイルは相手の手元にあり相手にとっては痛くない
痛いのは自分なのであまり利口な方法とはいえない
844 ：login:Penguin：03/08/03 00:45 ID:iNpxliz8
>>843
>相手の蹴る理由としていくつかのパターンが考えられるが
どのようなパターンでしょうか

>いずれにしても欲しいファイルは相手の手元にあり相手にとっては痛くない
>痛いのは自分なのであまり利口な方法とはいえない
リクエストを蹴るたびに他のノードと繋がらなくなっていくので結局リクエストを蹴ったノードが損をする事になるかと
またリクエストを蹴るノードは元々ULしてくれないのでそのノードを切断してそのノードとは一定期間繋がない事による
デメリットはあまり無いかと
845 ：login:Penguin：03/08/03 04:02 ID:OODkz1Wd
>844

１．実際にそのファイルを持っていない場合
２．転送するための枠に溶融長い場合
３．アップロードする枠がない場合
４．転送する気がない場合

　大雑把に言っても4通りは考えられます

　ただし、転送による匿名性を期待するときこの4つの要因をリクエストしてきたノードに伝えることは危険です。
※３については危険性は低いと思いますが。

　どのみち、どの理由で蹴られてとしても、それが本当の理由であるかは不明です。
　よって、蹴られたことによってそのノードがDOMであるとは決め付けられません。

また、痛くないについて言えば
　そのデータを持っているダウンロード希望するノードに対してダウンロードを要求したノードが蹴るだけであってそのノードが
持っていないデータを持っているノードは蹴るという行為に成りません。
　蹴るという行為によって、欲しいデータを持っているノードを自主的に切断することは、蹴られた側としての感情的な対応としては
正しいかもしれませんが、蹴ってきたノードのデータを取得するための論理的な方法論としては正しいとはいえません。倫理的という
話は別次元においておいて。

　感情的な表現としては、欲しいデータを持っているノードがデータをよこさないときには悔しいから相手が要求してきても
断るということで、そのデータ自体が十分に拡散しているものであれば、切断されたノードは他のノードからダウンロードすれば
すむだけの話。

　ましてや、DOMに徹する気なら他からリクエストを受けるようなファイルを所持していなければ、リクエストを受けることもなく、
リクエストを蹴ることもなく、蹴ったことによって切断されることもなく、ダウンロードが可能となる。デメリットは期待できません。

　欲しがられたときに切断するなら、DOMに対してデメリット与えられます
　欲しがったときに蹴られた切断するんら、単なる僻みとしてDOMerが喜ぶだけです。
846 ：login:Penguin：03/08/03 04:10 ID:OODkz1Wd
>>842
　現状での、DOMDOMゴーゴーでの実装でしたらば、一日の24時間プログラムに時間を割り当てられるならあなたでも、
1日もあれば実装可能です。ちょっと凝った造りをししたならば3日から1週間はかかるかもしれません。

　しかし、良識とプライドのあるプログラマーなら、仕様も決まっていない状態で実装して公開することはないでしょう。

　もちろん、これけネタの豊富なスレッドがあるのだから、実装実験のためのプログラムの作成および設計をしている人は
たくさんいると思いますが。

　さぁ、DOMDOMゴーゴーなプログラムを書いて、842氏と呼ばれるチャンスですよ。　がんばれ

847 ：login:Penguin：03/08/03 10:13 ID:iNpxliz8
>>845
>１．実際にそのファイルを持っていない場合
>２．転送するための枠に溶融長い場合
>３．アップロードする枠がない場合
>４．転送する気がない場合
どの理由による場合であってもULしてくれる事はないノードなのでそのノードを切断して一定期間繋がない事による自ノードのデメリットはあまり無いかと

>どのみち、どの理由で蹴られてとしても、それが本当の理由であるかは不明です。
>よって、蹴られたことによってそのノードがDOMであるとは決め付けられません。
どういうノードをDOMと決めるかによるが単純に自ノードに対してULしないものは全てDOMということで

ファイルを転送しない又はできないノードとは接続を切って一定期間繋がらないようにしてももともと転送が発生しないノードなわけだから
再度そのノードに繋ぎに行かないようにする事は検索の効率化から言ってもメリットがある

又どういう理由であったとしてもULしなかった相手ノードは接続が切れる事によって自ノード（こちら側）が持っているファイルを
落とせる状況にあったのに一定期間の制限が切れるまで落とせなくなるのでデメリットを受ける

結局１～４のどの理由であってもULしなかったりできなかった時点で回りのノードから次々と切断されていく事になる
正常なノードであれば一定期間経過したあと再びつながり出すがまったくUPしないような０DOMパッチを当てていると
最終的に全てのノードから切断される事になるのでそのノードは孤立することになるかと

また完全に孤立してしまったノードであってもULを開始できる状態に戻せば再び回りのノードと繋がり出すのでDOMから正常ノードへの移行も簡単

あとこれは煽りでもなんでもないがもう少しわかりやすい文章をかいてくれ
意味を理解するまでにちょっと時間がかかったよ
848 ：login:Penguin：03/08/03 10:13 ID:Ymg5BV8l
ROMってたらどっちで進んでいるかわからなくなったので聞きます。

76案で、評価値を周りに聞くわけですが、その返答の方法は
1.返答をリレーして返す(中継する)
2.聞くときに返答先を入れておき、直接答えてもらう

のどちらを想定していますか？
1なら、返答ノードの特定はかなり困難。ありもしないノードからのうその返答を
捏造することができます。
２なら、それはできませんが(IPアドレスによって返答ノードが特定可能)、ものすごい
トラフィックが発生するかと。短時間に100ノードと短いながらも通信しなければ
ならないので負荷もすごいかと。
それと、いつか出てましたがネットワークに存在するノード数を効率的に数えられて
しまうことにもなりますが、それは気にしない、でいいんですかね。
849 ：login:Penguin：03/08/03 11:11 ID:dVbVv1j/
>>848
＞それと、いつか出てましたがネットワークに存在するノード数を効率的に数えられて

それは今のWinnyでも同じです。
評価システムを組み込むと大まかな転送量も知る事ができます。
850 ：login:Penguin：03/08/03 14:59 ID:q8Cmdxdq
>>833
けれど結局これについては対抗策がないようですが。>>837
>DOMパッチとして、自らがDL要求していないノードからのリクエストは蹴るみたいな
>改造をしていたとしたら、十分機能してしまうのですが…

この案にある種の対策を取ったのが>>4です。

それに多数の捏造ファイルを共有していたらどうしますか？
リクエストを要求して相互にDLしたはいいが、それを落としてみるまで本物かどうか分からない。
相手からリクエストさえなければ切られることもないのでやる意味は十分でしょう。

また後からのリクエストでは落とし終えるまでに相手に切られてしまう可能性があります。
これでは先にDLしたもの勝ちです。
転送終了時を合わせるなら後にDLしたもの勝ちです。

MXではこの辺りの問題を匿名性がなくコミュニケーションを伴うことにより
相手の良心、初心者には「２ちゃんで晒すぞゴルァ！」への畏怖によりうまく機能しています。

単体で改造捏造し放題な考え方を匿名性の中に運んできても仕方がありません。

さらに次のステップとして複数ノードによる52案や72案のようなものが存在するわけです。
851 ：login:Penguin：03/08/03 16:39 ID:B4XX934Z
>>833
次に進むとはやっとWinnyと違い、72案なら大多数のノードが不正ノードになることは難しいと理解してくれて
無駄な論点から外れることだと思ったが、こんなことを考えることだったのか。

>つまり起こらない事を前提とするのではなくおこった場合でも大丈夫なシステムでなければだめじゃないのか
では大多数のノードが他ノードがDLしにくくするために
>>798検索結果を減少したり遮断したり偽装した場合に成り立つのか？
大多数のノードが捏造ファイルしか共有していなかった場合は成り立つのか？
大多数のノードが何も共有せずDOMに徹した場合は成り立つのか？

他にも問題はあるだろうが、大多数のノードが不正ノードになった場合に成り立つシステムとは到底思えない。

>>831
72案について思い違いをしていたので最初意味が分からなかったんだが、
確認しておくと>>815は>>848の1を想定した場合の話だと考えていいかな？
852 ：login:Penguin：03/08/03 16:53 ID:iNpxliz8
>>850
ID:pE8R9TFx ＝ ID:iNpxliz8

>DOMパッチとして、自らがDL要求していないノードからのリクエストは蹴るみたいな
>改造をしていたとしたら、十分機能してしまうのですが…
これの対抗策は>>841です

>それに多数の捏造ファイルを共有していたらどうしますか？
>リクエストを要求して相互にDLしたはいいが、それを落としてみるまで本物かどうか分からない。
>相手からリクエストさえなければ切られることもないのでやる意味は十分でしょう。
捏造ファイルについてはオープンソースになった時でも現在の47氏の対策だけで十分だと思う

>また後からのリクエストでは落とし終えるまでに相手に切られてしまう可能性があります。
>これでは先にDLしたもの勝ちです。
>転送終了時を合わせるなら後にDLしたもの勝ちです。
一時的に得したように見えてもそういう行為をするノードは次第にどのノードとも繋がらなくなっていく事になるかと

>単体で改造捏造し放題な考え方を匿名性の中に運んできても仕方がありません。
すいませんが意味不明です

>さらに次のステップとして複数ノードによる52案や72案のようなものが存在するわけです。
複数ノードによる評価システムには現状では穴があるのでだめでしょうね
853 ：login:Penguin：03/08/03 16:54 ID:24L6Hjqc
あほですねお前ら、DOMに厳しい使用にするなら
IP監視して、数時間起動してる事が確認できるノードにしかファイルをUpしなければいいんですよ
これでお手軽にお宝ゲット出来なくなって敷居がたかくなりますようんこ
854 ：login:Penguin：03/08/03 17:02 ID:CJNbKCU1
>>847

　自分にアップロードしてこないノードをDOMノードと認定し、一定期間接続を拒否する。といった使用の場合

　ミクロに考えると、

　ノードAはノードBのデータがほしい。
　ノードBはノードAのデータがほしい。この条件で

　ノードAがノードBにリクエストしたときに、何かの理由でULを拒否されたとします。
　ノードAはノードBを一定期間接続拒否します。
　ノードBはノードAにリクエストします。ノードAは拒否します。
　ノードBはノードAを一定期間接続拒否します。
　ノードAは拒否期間が切れたところでノードBにリクエストをかけます。ノードBは拒否します。
　ノードAはノードBを一定期間接続拒否します。
　ノードBは拒否期間が切れたところでノードAにリクエストをかけます。ノードBは拒否します。
　ノードBはノードAを一定期間接続拒否します。
　ノードAは拒否期間が切れたところでノードBにリクエストをかけます。ノードBは拒否します。
　ノードAはノードBを一定期間接続拒否します。
　ノードBは拒否期間が切れたところでノードAにリクエストをかけます。ノードBは拒否します。

　延々繰り返し？

　もうひとつの難点

　ノードAにはノードBがほしがるファイルがいっぱい。ノードBにはノードAがほしがるファイルを
持っていない。ノードAはノードBにリクエストをかけないから拒否条件は発生しない。
　ノードBはノードAから拒否されないのDOMりまくれる。
855 ：login:Penguin：03/08/03 17:09 ID:CJNbKCU1
>>854

　一定時間接続を蹴る仕様の問題その２　ちょっとマクロに

　転送によって匿名性を高めるという機能がある。ノードAにあるデータをノードBを経由してノードCに渡す。
　ノードBはノードAにデータがあること知っている。
　ノードCはノードBが知っていることを知っている。
　ノードCはノードBにリクエストをかけた。
　ノードBはノードAにリクエストをかけた。
　しかし、ノードAは手一杯だったので断った。
　ノードBはノードAを一定期間接続拒否する
　ノードCはノードBがデータをよこさないのでノードCを一定期間接続拒否する。

　転送という機能を有効に働かすためには、ノードの稼働率を高めてノード同士が緊密に働かなければ
ならないのだが、こんなブチキレシステムでは協調して機能できないのでは？
856 ：login:Penguin：03/08/03 17:19 ID:iNpxliz8
>>854
>延々繰り返し？
何かの理由でULを拒否される限りなんどでも繰り返します
しかし実際問題としてはなんども繰り返される前にその他のノードから無事にDLできるので
延々繰り返されることはないでしょう

>ノードAにはノードBがほしがるファイルがいっぱい。ノードBにはノードAがほしがるファイルを
>持っていない。ノードAはノードBにリクエストをかけないから拒否条件は発生しない。
>ノードBはノードAから拒否されないのDOMりまくれる。
ノードBがノードAに対して正規のULコネクションを確立させDLが終わるまでノードAとのULコネクションを切らなければDLできます
この状況でのノードBのDLを許可しないことはまったく共有ファイルを持っていない新規参加者を許可しない事になる
またファイルを持っているのにDLさせないことは自分が相手から切断され一定期間制限される事になるかと
857 ：login:Penguin：03/08/03 17:25 ID:iNpxliz8
>>855
>転送という機能を有効に働かすためには、ノードの稼働率を高めてノード同士が緊密に働かなければ
>ならないのだが、こんなブチキレシステムでは協調して機能できないのでは？
いかなる理由であってもULしなかったりできなかった時点で回りのノードから切断されます
そして手一杯ではない他のノードと繋がります
858 ：login:Penguin：03/08/03 17:57 ID:CJNbKCU1
>>856

>　ノードBがノードAに対して正規のULコネクションを確立させDLが終わるまでノードAとのULコネクションを
>切らなければDLできます
>この状況でのノードBのDLを許可しないことはまったく共有ファイルを持っていない新規参加者を許可しない事になる
>またファイルを持っているのにDLさせないことは自分が相手から切断され一定期間制限される事になるかと

　ファイルを持っているかの問い合わせに対して、持っていないと返答する改造をするだけで
DOMが自由に出来るシステムになるのでは？
859 ：login:Penguin：03/08/03 18:05 ID:iNpxliz8
>>854
>>856の補足
ULを拒否される限りなんどでも一定期間接続拒否なのですが接続拒否中の相手に拒否された場合は
ULの拒否ではなくコネクション自体の拒否なので
　
　ノードAがノードBにリクエストしたときに、何かの理由でULを拒否されたとします。
　ノードAはノードBを一定期間接続拒否します。
　ノードBはノードAにリクエストします。ノードAは拒否します。
　ノードBはノードAとコネクションできない
　ノードAは拒否期間が切れたところでノードBにリクエストをかけます。ノードBと接続。
　
>>854のミクロの場合の例ですと上のようになるとおもう
860 ：login:Penguin：03/08/03 18:22 ID:iNpxliz8
>>858
持っていないと返答するだけならULを拒否したわけではないので
今のままのシステムではそのノードが切断されて一定期間制限されることはないです

かりに持っていないと答えるノードが大多数になった場合は検索しても
ほとんどファイルが見つけられない状態になると考えられますね
861 ：login:Penguin：03/08/03 18:41 ID:iNpxliz8
>>859の修正
> ULを拒否される限りなんどでも一定期間接続拒否なのですが接続拒否中の相手に拒否された場合は
> ULの拒否ではなくコネクション自体の拒否なので
> 　
> 　ノードAがノードBにリクエストしたときに、何かの理由でULを拒否されたとします。
> 　ノードAはノードBを一定期間接続拒否します。
> 　ノードBはノードAとコネクションできない
> 　ノードAは拒否期間が切れたところでノードBにリクエストをかけます。ノードBと接続。
> 　
> >>854のミクロの場合の例ですと上のようになるとおもう

こうですね
862 ：login:Penguin：03/08/03 19:20 ID:CJNbKCU1
>>860

　だとすると、DOMし放題のノードが作れて、それがリーク蔓延していったらネットワークは崩壊することに
なるのでは？
863 ：login:Penguin：03/08/03 19:56 ID:iNpxliz8
>>862
まだその事について詳しく検討してないですが検討した末にその問題が解決できそうもないなら
又別の案を考える事になるかも知れないです

問題点が出てきてそれが解決できない場合は次の案を出してそれにまた
別の問題点がないか検討することになるかと

それを繰り返していけば問題点のない案が完成するとおもう
864 ：login:Penguin：03/08/03 22:34 ID:ks4t1m6I
>>862
となると、どのくらいのDOMに耐えられるか簡単な仮想ネットワークで
テストする必要があるかも。
DOMの数が少なければうまくいくのであれば、どこまで耐えられるかの
数字を出してみるのもいいかと
865 ：login:Penguin：03/08/03 23:45 ID:iNpxliz8
>>864
>DOMの数が少なければうまくいくのであれば、どこまで耐えられるかの
>数字を出してみるのもいいかと
ネットワークを崩壊してしまうほどのDOMは現れる筈がないのでDOMの数が少なければうまくいくのでは
という想定をしているのであればDOM対策は必要ありません

それが成り立つのであれば何の対策もせず現在のｎｙをオープンにした場合でも
ネットワークを崩壊してしまうほどのDOMは現れる筈がないという事になるからです

どこまで耐えられるかではなくどんなに増えても耐えられる対策を考えなくてはだめだとおもう
少ない時は耐えられるシステムというのは多くなった時は崩壊するわけですし。。。
866 ：login:Penguin：03/08/04 01:25 ID:Dcmr7FqU
もまえら、がんがれ!
867 ：ｊ：03/08/04 01:31 ID:t0MabX2H
☆★最新アダルト情報★yahoo検索から★☆
http://endou.kir.jp/marimo/link.html
868 ：_：03/08/04 01:32 ID:xlV3irWs
http://homepage.mac.com/hiroyuki44/2ch.html
869 ：login:Penguin：03/08/04 05:16 ID:mWSv6Pod
(´-`).｡ｏＯ(厨な意見かもしれないが、パッチ当ては実は難しくないんじゃないか？
WINNY自体がオープンソースになれば、パッチ当て済の
WINNYパッケージと言うのも作れるし、それがNYで流れたら、
それをインスコするだけなんだから。)
870 ：login:Penguin：03/08/04 05:30 ID:mWSv6Pod
んで、そのパッチ当て済&配布者ノード＋パッチ当て配布者偽装のため
30－40ノードぐらいの評価MAXを返すようなパッケージが出回ればどうなるんだろう。
オープンソースにすると言うことは他の奴が
そのソースを基に改造して配布をできると言うものなんだが、
なんかパッケージそのものを偽装された場合の話がでてないような。
871 ：login:Penguin：03/08/04 18:26 ID:YyefoMOD
オープンソースって、、、K察対策は大丈夫なの？
872 ：login:Penguin：03/08/04 19:19 ID:uP9gtrEx
実装が絶対無理
-----------------------
本来のソース
listen (myip){
if (相手のファイル要求){
connect(sock)
}
----------------------
改変ソース
listen (myip){
if (相手のファイル要求){
shutdown(sock)
}

こういうのをどう防ぐつもりだ？
873 ：login:Penguin：03/08/04 20:41 ID:TzYW+82F
>>872

　それはあからさますぎますね。
　ま、言いたいことは解るが、コード起こすほどのことでもない。
　というか、コードがそれだと突込みどころ満載すぎるｗ
874 ：login:Penguin：03/08/04 21:01 ID:ozWsRf9l
WinnyでDOMる方法

・1分に１回キャッシュを全削除する。
ダウン中のファイルはロックされているので削除されることはない。
削除されるのはDown済みまたは転送用のゴミキャッシュのみ。

・Winnyを複数起動する。
Uploadしないと1クライアントあたりのダウン数が制限されるが
クライアント数を増やせば好きなだけDOMることができる。
# 複数起動の方法は各自工夫するように。やり方はいろいろある。

875 ：login:Penguin：03/08/04 21:22 ID:TzYW+82F
>>874

　自分がダウンロードしている最中で、途中まで落ちていて、切断された
ファイルまで消えるので効率が悪くなりますw

　タダですらメモリに負担がかかっているWinnywo複数立ち上げるとは豪気なw
876 ：login:Penguin：03/08/04 21:48 ID:ozWsRf9l
>>875
>切断されたファイルまで消えるので効率が悪くなりますw
一時間以内の転送であれば切断される可能性はかなり低いので実質問題にはならない。
無駄な転送も発生するがそのコストは定額である以上個人には発生しない。
キャッシュのフォーマットも解析済みなのでより効率的なクリーンアップツールの作成も容易。

>　タダですらメモリに負担がかかっているWinnywo複数立ち上げるとは豪気なw
PC一台OS一つVM無しでも複数起動は可能。
877 ：login:Penguin：03/08/04 22:00 ID:UlSwc4wM
しかし、実現が無理なことを真面目に考えている馬鹿どもが居るというのは、
面白いですな。
878 ：login:Penguin：03/08/05 04:55 ID:a48Mzoxz
４７氏の依頼でオープンソース化が不可能なことを実証するスレですので
879 ：login:Penguin：03/08/05 06:01 ID:xyfMAUwn
ﾁｮｰｳｹﾙ
880 ：login:Penguin：03/08/07 16:57 ID:Ft2JiRDc
へんじがない。ただのしかばねのようだ。
881 ：GET! DVD：03/08/07 17:01 ID:ZNIaOXzX
☆★　新商品　ゾク・ゾク　入荷！！　急げ～！！　☆★☆
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★
☆★　送料激安！　　スピード発送！　　商品豊富！　　　
★☆　　　　　　http://www.get-dvd.com　　　　　　　　
☆★　激安ＤＶＤショップ　「ＧＥＴＤＶＤドットコム」　
★☆　　　　　　http://www.get-dvd.com　　　　　　　　
☆★　今すぐアクセス　Ｌｅｔ’ｓ　Ｇｏ！　　　急げ！　
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★
882 ：login:Penguin：03/08/07 23:19 ID:igvvkM01
>>874
それならタイムスタンプ見て、一時間（一分？）以上更新されていないファイルを削除の方が効率いいと思うな。
883 ：＊＊＊終了＊＊＊：03/08/08 00:45 ID:R+Y5ZB7j
＊＊＊終了＊＊＊
884 ：login:Penguin：03/08/08 04:44 ID:eexFRAuw
まだ終了したわけでもないのだがね
885 ：login:Penguin：03/08/08 09:37 ID:pysKV+fu
47氏は不可能だと思ってるわけだよね？自らの能力では
886 ：login:Penguin：03/08/08 10:24 ID:RJNg0ItE
こういうのはアイディアの問題だから
どれだけ効率を落としてもいいのであれば
47氏だって色々考えられることはあっただろう

オープンにしてもWinnyを使い続ける価値があるほど
効率のいい実装方法は思い付かなかっただろうけどね
887 ：login:Penguin：03/08/08 12:31 ID:drc0EuYM
TCP/IPで操作できるようになるだけでかなり
利便性が高まるわけだが。

どうよ？
888 ：login:Penguin：03/08/08 12:31 ID:drc0EuYM
セキュリティとか問題はありげだけど。
889 ：login:Penguin：03/08/08 15:40 ID:RJNg0ItE
>>863
>まだその事について詳しく検討してないですが
そろそろ詳しく検討出来ましたか？
890 ：login:Penguin：03/08/08 19:02 ID:LxQFIiEb
>>887=>>888
自演ですか？

>>TCP/IPで操作できるようになるだけでかなり
>>利便性が高まるわけだが。

まったく意味がわからん
小学生にも理解できるよう説明よろ
891 ： ◆8ll0DtPXyM ：03/08/08 20:00 ID:m5t+r+1B
>>890UZEEEEEEEEEE!!!ソンクライ理解しろﾎﾞｹ
892 ：login:Penguin：03/08/08 20:25 ID:drc0EuYM
自演というか、補足しただけ。
なんで同じIDで自演という発想が出てくる
のかがわからん。
やっぱり夏ですね。

わかりやすく説明すると
ブラウザとか通信ソフトで操作できたら
楽だよな。って意味だよ。

その場合パスフレーズとかないと危ないだろ？
わかった？
893 ：login:Penguin：03/08/08 20:43 ID:kwuIFHBe
>>892
要は君がアホってことですね。
TCP/IPでwinnyと直接通信すれば？
894 ：login:Penguin：03/08/08 20:45 ID:vWfIt5Pc
まあ究極的にはみんなが脳にプラグ差し込んで脳内を共有するようになるんだけどね。
それまでのつなぎってことで > Winny
895 ：login:Penguin：03/08/08 20:54 ID:hBi6g2oM
>>892 >>891
え？
じゃあ>>892はTCP/IPつかわずになに使おうとしてたわけ？
UDP/IPとか？
Rawで直接プロトコル作って直接通信するつもりですかｗ
896 ：login:Penguin：03/08/08 20:59 ID:57sQzZEC
>>880
藁
897 ：login:Penguin：03/08/08 21:08 ID:MJxsF02r
今度は>>863氏検討待ちですか。

待ちに入ると何故か荒れるよな。
898 ：login:Penguin：03/08/08 21:15 ID:xXfEmrLp
>>897
>それを繰り返していけば問題点のない案が完成するとおもう
この文面で何か考えてるとは思えないけど。

ついでにｵﾌﾟｿになれば
>>874
的な改造も簡単になって協調的に動作する不正ノードが
(局所的に)多数派を占める事も可能になるね。
899 ：login:Penguin：03/08/08 21:16 ID:hBi6g2oM
>>897
だれも待ってないしｗ
具だ具だいってCUI版すらできてないようじゃココの奴らって厨房なんだろｗ
900 ：login:Penguin：03/08/08 21:21 ID:57sQzZEC
具だ具だいって煽りすらできてないようじゃ>>899って厨房なんだろｗ
901 ：login:Penguin：03/08/08 21:25 ID:i6Y2s5Fh
ひろみに会いたい人、ひろみが欲しい人、手ぇあげてっ！
はーい、その指をマウスにもってってぇ・・・
ここをclick! ☆ъ（　゜ー^)＞ http://www.gals-cafe.tv
１週間毎日１０分、がんばってサービスしますっ！来てください♪
・・・えっ？誰も手ぇあげてなかったってハナシ？
そんなんナシだよぉ～～～。・°°・(>_<)・°°・。
会いたいよぉ。きてくださぁい（ ・O・）∞∞OOO○○○☆（〃。。〃）
902 ：login:Penguin：03/08/08 21:33 ID:drc0EuYM
とりあえず
オレの脳がおまえらに
ついていけないことがわかった

>>893
ブラウザとか通信ソフトとか専用クライアント
と言わなかった自分がアホでした。

>>895
>>887->>888 = >>892
> じゃあ>>892はTCP/IPつかわずになに使おうとしてたわけ？
どうやったらこういう結論に至ったのか…あんた天才すぎ。
903 ：login:Penguin：03/08/08 22:05 ID:MJxsF02r
>>898
じゃあ最近カキコがなかったのは何故？

>>862で指摘された穴を>>863氏が検討して
解決不可能だったらまた他の案を考えましょうって流れだと思ったんだけど。
904 ：login:Penguin：03/08/08 22:49 ID:TtXzbnA1
>>902
Winny はもともと、 TCP/IP を使っている。
905 ：login:Penguin：03/08/09 01:55 ID:TBgOMgmf
>>903
最近カキコがなかったのは、いろいろ出た案の問題点などを
考え中なので。
なかなかいい解決法を思いつかないんで、ほったらかし(w
906 ：マジレス：03/08/09 13:14 ID:/A6Yy6AB
>>902
君はプロトコルの勉強をした方がいい。
「OSI参照モデル　TCP/IP」でぐぐってみるといいかもね。
907 ：login:Penguin：03/08/09 13:28 ID:p+xkYynr
>>863
>それを繰り返していけば問題点のない案が完成するとおもう
ｱﾎだな。
いくら問題点を改善しようと4を奇数であると証明することは不可能なように
ｵﾌﾟｿでDOM対策はどうやっても不可能にだろ。
908 ：login:Penguin：03/08/09 16:34 ID:nD8FiTUs
1と3に分ければ片方は奇数だけど。。。
そういう方法を考えるためのスレといことで。
909 ：login:Penguin：03/08/09 18:09 ID:UGLH+Ykj
逆に言えばオープンオースにしたい！って内容でLinux板にWinny/Linnyスレが起つってことは
Linuxユーザー(UNIXユーザーが)Windows以外のOSでのWinnyを使いたいわけだろ？
ってことは47氏が全てのOSのGUI周りに互換性のある
WideStudio使って互換性のあるWinnyを作ればいいだけのはなしなんじゃない？
開発したい香具師は別として使いたいだけの奴はそれでﾏﾝｾｰのような。
910 ：login:Penguin：03/08/09 18:41 ID:WqYG5iid
>>909
もっかい頭から読み直せ。
Linux で Winny を動かすだけなら既に可能。そういう問題ではなく、
Winnyの最大の弱点が47氏になっている現状をなんとかしようという話だ。
911 ：login:Penguin：03/08/09 20:11 ID:EZtworKp
47氏負担の軽減も目指してるわけだからな。
912 ：login:Penguin：03/08/09 20:44 ID:dICHz3On
>>906
普通に知ってます。
七階層あることぐらい。

で。TCP/IPでの具体的な手段を
あげたかった「だけ」なわけだが。
そこまで突っ込んでくれるとは
頭がよろしいね。

おまえら天才すぎるからさ。もういいよ。
913 ：login:Penguin：03/08/09 20:57 ID:KPuA7794
http://www.symantec.com/region/jp/sarcj/data/w/w32.hllw.antinny.html
914 ：login:Penguin：03/08/09 22:00 ID:y+cJYTCP
はぁー、だめだなこりゃ
915 ：login:Penguin：03/08/09 22:05 ID:QOBlHNM5
＞＞９１２
おまえマジで何歳？
ヒッキーリアル厨房だろ
ちょっと基本情報さわってみましたみたいな
もうまじで書き込まないほうがいいよメッキがはがれるから
916 ：login:Penguin：03/08/09 23:05 ID:HuYja1Sy
DOM対策なんて片付いてるのに、それにも気がつかないなんて…

これらが、いわゆる夏厨？
917 ：login:Penguin：03/08/09 23:14 ID:dSBtpMUe
>>916
>>869-870は?
918 ：login:Penguin：03/08/09 23:42 ID:JfF5493I
自分が実際にDL/ULした時の相手の行動での評価にウエイトを置いて、
外部の評価は参考程度にしておけばいいんじゃない？
それで、上記前者での評価が高いノードが送る評価のウエイトを少しあげるとか。

まあ、ある程度はDOMられるのはしかたないと思うけどね。
919 ：login:Penguin：03/08/10 00:26 ID:5LffyCr3
>>869-870にはあえてレスをしなかったが一応しておく

まずパッチ当てが難しいとは思っていない。
>>824で初心者層の範囲をパッチ当てに焦点を合わせて説明しているが、
パッチ当て済み、パッケージそのものの改変が行われた場合でも
>>822で説明しているように72案では自身にメリットのあるような動作は難しいだろう。
またDOMになるために嘘の評価値を返すならクラスタが別離してしまえば全く意味がなくなる。
常に嘘の評価値を吐いてネットワーク全体の評価値の信憑性を落とそうという動作も同じ。

重要なのはパッチでも改造パッケージでも、それを使う動機あるのかということ。
改造パッケージ配布用のサイトを開設してそんなものを配布したところで
一体何人がYahooにも登録されてないため見つかり難く、ウィルス入り、トロイ入りかもしれない上に
自身にとって何のメリットもないWinnyを公式ページ以外から落として使うのか。
920 ：login:Penguin：03/08/10 02:13 ID:zOFHSppA
はずがないはずがないで塗り固めた設計がまともにうごくはずもない。
921 ：login:Penguin：03/08/10 03:35 ID:80uH7ouu
>>919
初心者クラス→DOM化クライアント(ﾟдﾟ)ｳﾏｰ評価下がったら、再インスコで(ﾟдﾟ)ｳﾏｰ
DOMクライアントを手軽に使えると言うのは動機としてかなり強いと思うよ。
それに、公式でなくても一回それが安全だと誰かが確認したらいいのだし

ハッカークラス→初心者クラスによって評価値あがりまくったクライアントによってがんがん高速DOM(ﾟдﾟ)ｳﾏｰ
てか、その評価値を返すのはハッカークラスのクライアントじゃないし。

後、根本的にどんな評価問い合わせでも評価MAXを返す、、、と言うクライアントも作り得ると思う。
もっとも、それに対抗して、ランダムに５つ６つに付いての問い合わせをかけて、
そのクライアントがてきとうに答えを言ってないかと言うチェックするって方法もあるが。
922 ：login:Penguin：03/08/10 10:21 ID:2RE/8g7F
だからDOM野郎が(ﾟдﾟ)ｳﾏｰい思いをしないようなｼｽﾃﾑを誰か思いつけよ！！！
923 ：login:Penguin：03/08/10 19:25 ID:ra8PWABE
コード書くことで47氏に協力がしたいのなら
氏が仕様を書いてリクエストした雑多なクラス・関数を
UnitTest付で実装してフィードバックする、
UIの改善案を出して、そのコードを提供する。
そうすれば氏はコア部分に集中しながら
同時に細かい瑣末な部分を
ブラッシュアップしていけると思う。

オープン・クローズドな折衷案として
あるいはこういう開発モデルがあっても良いのではないかな。
924 ：login:Penguin：03/08/10 19:31 ID:ra8PWABE
>フィードバックする、
フィードバックという言い方はおかしいな。
>コードを権利云々を一切主張しないで提供する。
925 ：login:Penguin：03/08/10 20:07 ID:MPbg8TYF
ゼロ知識証明
926 ：login:Penguin：03/08/10 21:25 ID:aLv4N4ei
なんでここに47氏が降臨しないのだろう？
927 ：login:Penguin：03/08/10 21:35 ID:Qn/bQWTA
前から不思議に思ってたんだけどさ、なんでlinux板で語ってるの？
download板なりソフトウェア板なりム板なりふさわしい板あると思うのだけどさ
なんで？オープンソース化を考えてるからってのは駄目だよ
928 ：login:Penguin：03/08/10 21:46 ID:JOrqTCfh
Linnyスレからの派生だから。
929 ：login:Penguin：03/08/10 22:07 ID:Jr1dklaA
DOMやられそうなところは，難読化しときゃええんちゃうのん？
930 ：login:Penguin：03/08/10 22:23 ID:ka8UIR6M
オープンソースとはいえ初心者にはソースが読めない。で、そこそこスキルのあるやつが
DOM用に改造して公開。DOMから神扱い。

結局システムを煮詰めてDOMをしづらくするしかない、と。
931 ：login:Penguin：03/08/10 23:16 ID:5LffyCr3
>>921
>初心者クラス→DOM化クライアント(ﾟдﾟ)ｳﾏｰ評価下がったら、再インスコで(ﾟдﾟ)ｳﾏｰ
これは繋ぎ始めのノードがどれだけ効率よくダウンできるかによる。

もし繋ぎ始めのキャッシュ無しノードが現在のWinny程度の効率を得られるなら動機としては強いだろうが、
そうならないようにするための72案であり、ここらの動作はまだまだ熟考すべき部分だと思っている。

一つの方法としてはマイナス評価がどれだけあるかに関わらず、
プラス評価のあるノードとプラス評価の全くないノードの扱いに決定的な違いを儲けることだな。
転送、順番待ち状態でプラス評価の一つもないノードは常に最後尾に落とすことにする。

これならアップ帯域を1bpsも使用していないノードは他の不正ノードとの協力無しに
WinMX3.3以上の効率でDOMになることは出来ないだろう。

>ハッカークラス→初心者クラスによって評価値あがりまくったクライアントによってがんがん高速DOM(ﾟдﾟ)ｳﾏｰ
確かに今のところこれを防ぐ手立ては考え付いていない。
しかし初心者クラスではなく、ハッカークラスの人間がネットワークを正常に稼動出来なくするほど存在するとは思えない。
難易度は違うがクローズドWinnyを自分のためにクラックしてDOMになってるハッカークラスと同じことで、
その存在がネットワークを崩壊させるほど多いとは考えられない。

またわざわざ初心者クラスがハッカークラスの評価値を上げる理由も分からないが、
何より他ノードに協力してもらう必要があるから、ハッカークラスでDOMになりたいノードであっても
多数の他人の協力を得られないノードは不正を犯すことが出来ない。

つまりこのようなノードになることは難しく、ネットワークに影響がないほど極少数であると考えられる。

>後、根本的にどんな評価問い合わせでも評価MAXを返す、、、と言うクライアントも作り得ると思う。
評価MINならまだ分かるが、評価MAXを返して何か意味があるのだろうか。
932 ：login:Penguin：03/08/11 00:11 ID:NRWEeCiy
>>931
だからそれはお前の脳内仮定だろう
いない
ありえない
どうしてそうなるのかわからない、俺ならこう思うだから俺が正しくて安全

議論にならない
933 ：login:Penguin：03/08/11 00:13 ID:22CIM/zg
とりあえず>>932に一票
934 ：login:Penguin：03/08/11 00:15 ID:GGbDsx3s
>>932=865か？

取り合えず>>865の考え方が完全に間違っているから議論にならないと分かったよ。
935 ：login:Penguin：03/08/11 00:49 ID:0cU6W8cL
俺も >>933 の考えでいいと思う。
みんな違法行為なんか絶対しないいい人たちだから、ネットワークをわざわざ崩壊させることもない。
winnyとかwinmxだって性格的に厨房なやつはやってないしね。

それに、崩壊したらしたで、そのとき考えればいいよね。
スーパーハカーが速攻でなおしてくれるから、人が流れることもないだろうし。

たぶんこれで47氏もOKだすよ。うん。
936 ：935：03/08/11 00:50 ID:0cU6W8cL
>>933 じゃなくて >931 だな。すまん。
937 ：login:Penguin：03/08/11 00:52 ID:NRWEeCiy
>>902
オレの脳がおまえらに
ついていけないことがわかった

文章がそっくりだな
いつぞやの厨房かｗ
>>934
おまえIPの偽装の仕方とかわかってるかｗ
しょうじきwinに比べればLinux socketめちゃかんたんだぞ


このスレおもしろいなまじで
938 ：login:Penguin：03/08/11 01:11 ID:22CIM/zg
とかなんとか言っちゃって。
一番鼻息荒いのは>>937だよね。
939 ：login:Penguin：03/08/11 01:12 ID:4Ov3ma3l
やれやれ
940 ：login:Penguin：03/08/11 01:13 ID:NRWEeCiy
>>983
(´`ｃ_,'` )ﾌﾟｯ

socketプログラムも出来ないタコがよくほざく
941 ：login:Penguin：03/08/11 01:21 ID:22CIM/zg
>>940
ふーん。根拠もなしによく言い切るね。
どうでもいいけどRawソケット使えるくらいでそれだと

痛すぎだよ？
942 ：login:Penguin：03/08/11 01:25 ID:G8P3yijJ
>>834

>>865をよく読め。それでも解らなかったらカエレ
943 ：login:Penguin：03/08/11 01:27 ID:3CrLLADX
>>940みたいな馬鹿が沸いてこないようにこの板でやってるんだよね～

IPアドレスの偽装って(ﾌﾟﾌﾟﾌﾟ
是非とも偽装したIPをどう使うのか聞きたいなぁ（藁
944 ：login:Penguin：03/08/11 01:29 ID:22CIM/zg
覚えたての知識で大興奮
っていう夏厨でしょ。

公開ｵﾅﾆｰも休み休みにしてください。
945 ：login:Penguin：03/08/11 01:51 ID:NRWEeCiy
(ﾟДﾟ)ﾊｧ?
ＩＰ偽装したらネットワークは崩壊するだろ

ファイルサーバーポートを空けるＩＰに存在しない偽装ＩＰいれたら完全ＤＯＭだろ
946 ：login:Penguin：03/08/11 01:59 ID:be4R9EN4
>>945
あ～この程度の理解でいきがってるんだから手に負えないわ
存在しない偽装IP入れて完全DOMね

つまり夏厨はMX3.3でもやってなさいってことだろ(w
947 ：ｗ：03/08/11 02:06 ID:NRWEeCiy
　　　　　 n＿n
　　　　　（･A･）っ
　　　　　(っ　,ｒ　　　しゅたたた・・・
.　　　　　 i_ﾉ┘
　　 　 　 ∧＿∧
　　　 ⊂（ ･ A ･ ）
.　　　　　ヽ 　⊂）
　　　　　（⌒） ｜　　　しゅたたたたたたたたた・・・
　 　 　 　 三 `Ｊ
　　 　 /ヽ　　　　　/ヽ
　　　/　　ヽ＿＿_/　 ヽ
　　／　　　　　　　　 　 ＼
　　|　　●　ヽー/　●　　|　　あ～この程度の理解でいきがってるんだから手に負えないわ
　　＼　　　　 ∨　　　　／
948 ：login:Penguin：03/08/11 02:56 ID:4ptG8zaZ
>>945
（　´,_ゝ`） ﾌﾟ
偽装したIPでどうやってTCPコネクション確立するんでつか？
不可能とは言わないが、お前がそれを出来る立場の人間でない事は確かだ。
949 ：login:Penguin：03/08/11 03:14 ID:0ri0wVBC
>>948

TCPコネクション確立するだけなら
どっかのＷＢＥサーバー:port80につなげればいい
nyプロトコル偽装はまた別の話だが


アホはお前だｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
950 ：login:Penguin：03/08/11 03:16 ID:0ri0wVBC
オープンソース版nyプロトコル偽装は楽勝だろう

ソースが公開されてるんだし
951 ：login:Penguin：03/08/11 04:01 ID:bHGMc4Bh
オープンソースはどうでもいいから、まずプロトコルの標準化が必要なのでは？
そのうえでオープンソースだったりそうじゃなかったりする
アプリケーションが作られていくってのが正しい手順だと思う。

なので、誰かI-D書いてIETFで発表してきてくれ。
ひろゆきマスクとか被って。

それとなんでDOMをそんなに毛嫌いしてるの？
NNTPのようにDOM許容ってのは駄目なの？
匿名性のないNNTPであれだけエロ画像や動画が流れているのを考慮すると
匿名性をウリにしてプロトコルが公開されたシステムならDOMを毛嫌いしなくても
とんでもない量のコンテンツが発生すると思う。

それから、プロトコル偽装っていうか、構築されたP2Pネットワークシステム自体の
動作に影響をおよぼす悪意のあるアプリの構築は当然容易なので、
I-D書いてSecurity Considerationの章でしっかり検討する必要があると思う。
952 ：login:Penguin：03/08/11 04:20 ID:dj1fqF8c
>>951
>>匿名性をウリにしてプロトコルが公開されたシステムならDOMを毛嫌いしなくても
>>とんでもない量のコンテンツが発生すると思う。
禿同
それがオープンソースでやる場合の一番の価値だ。

四の五の言わずさっさと動くもの作ろうぜってこったな。

そして、よく言われることだけど、公開した後パッチがあてやすく
改編要求を吟味しやすい運用体制を作ることだ。
それができればDOMに絡む問題はそのうち解決されうだろうと
期待するって言う、前向きさで何とかなる。
どんな問題もコードに向けられる目の数が最良の解決手法だって
(どっかの誰かの)言葉を信じてみよう(･∀･)!
953 ：login:Penguin：03/08/11 04:50 ID:E2TwHnz+
nyと関係あるか分からないけど、面白そうな転送方式を思いついたのでメモっとく。

ノード
A B C
1)ノードAは欲しいファイルがCにあることをどうにかして知る。
(ただし、Aがそれを欲しがっていることをCに知らてはならない)
2)ノードAは暇そうなノードBを探してコネクション張る。
(Bの上り下り速度が重要)
3)ノードAはノードBに「Cとコネクションはれや」とお願いする。
(ノードBはノードA-Cの間のデータ転送責任を追う)
4)ノードAはノードB経由でノードCからCの公開鍵を受信。
5)ノードAはノードB経由で先ほどの鍵を使って暗号化して、欲しいファイル名とAの公開鍵を送信。
6)ノードCはノードAにAの鍵で暗号化してファイルをB経由で送信。

分散共有ではなく、単発送信もののファイル共有プロトコルだけど
転送部分に関しては匿名性が保てそうじゃない？
Bは何が転送されているのか知らない。
Cは誰に転送しているのか知らない。
ただ、「Cが特定のファイルを持っていることを公開している」っていうのがイマイチかも。
この部分も別のノード経由で公開するとかいう必要があるな。
コメント求む。
954 ：login:Penguin：03/08/11 05:13 ID:0ri0wVBC
>>953
↓このレベルと同じ
http://tmp.2ch.net/test/read.cgi/download/1060539227/
面白そうな転送方式を思いついたのでメモっとく。じゃだめだろ
955 ：login:Penguin：03/08/11 05:23 ID:4Ov3ma3l
ここはDOM否定派と容認派と中間派と一見さんが無責任な発言で
相手の発言をスクロールアウトさせて無限ループを楽しむスレですか?
956 ：_：03/08/11 05:33 ID:n2Ixq72V
http://homepage.mac.com/hiroyuki45/hankaku03.html
957 ：login:Penguin：03/08/11 05:34 ID:Aj+z8BpF
DOM容認派と中間派＝一見さん

このスレに最も不要なのはDOM対策不要論
958 ：login:Penguin：03/08/11 05:38 ID:Aj+z8BpF
>>953
メモっとくのはいいと思うんだけど、
せめてもう少し内容を考えてからメモって欲しいな。
959 ：login:Penguin：03/08/11 06:17 ID:f0vE7mZH
現winny方式そのままならDOM対策必要かもね。
逆に言うとDOM＝悪という前提の限りwinnyはこれ以上利用されない。
DOM10人に対してUPが1人とかでも動くようなシステムじゃないと利用者は爆発的には増えない。
DOM＝悪という前提が不要な別のプロトコルが必要。
さらに言うと、DOMかそうでないか、ということすら匿名であり且つシステムに
悪影響をおよぼさないようなシステムが望ましい。

それと、プロトコル仕様公開＝オープンソース＝linuxという考えで
このスレがlinux板にあるのだとしたら、はっきり言って板違い。
プロトコル仕様は通信技術板の方が良い意見がでるはず。
960 ：login:Penguin：03/08/11 06:33 ID:nDZ7QPEn
>>953
分かった。匿名性を維持するには２ホップで十分ということだな。
それ以上になると転送効率が悪い。
winnyのように中途半端ないらんものを転送するのも効率悪し。
DOMの毛嫌いも利用者減す。
ところでBがスパイとか悪意のあるノードの場合、Cの鍵をAに正しく送れない気がするが、
B1とB2とか、複数のBを利用すれば解決できそうだな。
B1、B2経由で送られてきたCの鍵が違っていたらB1もB2も信用しない、とかな。
で、保持しているファイルの公開方法だが、953と同じ方法で匿名性を保ちつつ情報交換できるだろ？
匿名性は2ホップで確保、そして無造作に抽出した隣接ノード複数を利用して信頼性確保、
転送効率を最大限にしつつ匿名性を確保するため転送は最大２ホップ、
これ逝そうじゃないか？
961 ：login:Penguin：03/08/11 06:45 ID:nDZ7QPEn
初期ノード問題なんだけど、完全可逆じゃなく、情報が2bitから3bit
くらい欠落する不可逆暗号はどうよ？
つまり@hogehogehogehogeっていうのを解読すると
IPアドレスの候補としてA,B,C,Dくらいとportの候補としてx,yくらいが抽出されるとか。
962 ：login:Penguin：03/08/11 06:52 ID:0ri0wVBC
>>961
空想科学ねっとっワークワンダバｎｙ
すごいね
んじゃ予測されるＩＰにＳＹＮうちまくりってわけかい
そこがペンタゴンだろうが、黒客だろうが
963 ：逝そうじゃないか？：03/08/11 07:03 ID:0ri0wVBC
　　　　ｼｭﾎﾞｯ
　　　　　　　.,　∧＿∧
　　　　　　[]() （・ω・｀ ）　　　　　　ｌ二ヽ
　　　　 　　□と>>960）￣⊃　　　　　) )
　　　　　　⊂ （＿（＿つ　　￣⊃　　/￣￣￣ヽ
　　　　　　　⊂_　　　　　 .＿⊃　　　| （＼／） |
　　　　　　　　　⊂＿＿⊃.　　　　　 |　 >　< 　|
　　　　　　　　　　　　　　　　　　　　 | （／＼）. |
　　　　　　　　　　　　　　　　　　　　 ヽ＿＿＿/
964 ：login:Penguin：03/08/11 07:04 ID:0ri0wVBC
　　　　　　　　　　从从
　　　　ｺﾞｫｫｫｫ 从从　从　　
　　　　　　　从从从∧ ::从::从
　　　　　　从从从;;;从）:::::::从::从　　ｌ二ヽ
　　　　 　从;;;](_;;;从从;;;从从从　　　　 ) )
　　　　　　从　;;;;;__从从从:::从　　　 /￣￣￣ヽ
　　　　　　从从::::　　:::::从从　　　　 | （＼／） |
　　　　　　　　　从从从从　　　　　 .|　 >　< 　|
　　　　　　　　　　　　　　　　　　　　 | （／＼）. |
　　　　　　　　　　　　　　　　　　　　 ヽ＿＿＿/

おまえらにはゲーム板がおにあい
仲間がいっぱいいるぞ
どっちにしても青果物の出ていないコノスれはいた違いだウソ板いけ
ゲ製作技術
http://pc2.2ch.net/gamedev/
Download
http://tmp.2ch.net/download/
965 ：login:Penguin：03/08/11 07:05 ID:lp9Z/a+D
>>962
うちまくりってほどじゃなく、１発ずつくらい。
めでたく張れればOK。
まぁpentagonやgo.jp、govが年間に食らうattackの回数を考えればSYNの一発くらい無問題だろ。
portも違うし。
でもヘボプログラマがコード書いたらうちまくりになるかもな。
OS標準のTCPのスタックなんか使うなということだ。
最初はraw socketでSYN一発うってSYN/ACKを待てということで。
966 ：login:Penguin：03/08/11 07:15 ID:cYWF4CJY
しかしここみて思うんだけど、P2P分野って日本人に専門家いないの？
ああ、自分じゃ作れないけど評価と文献引用だけならできる類ならいるのか。
967 ：login:Penguin：03/08/11 07:20 ID:x0Fhbrqd
どこかの国内の学会でP2Pの論文見た。
というかまずググれ。
http://www.google.co.jp/search?q=P2P+%E8%AB%96%E6%96%87&ie=UTF-8&oe=UTF-8&hl=ja&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=
968 ：login:Penguin：03/08/11 07:36 ID:HdFP0eqv
winnyのオープンソース化とか言いながら、プロトコルの標準化とかIETFとかいう
言葉がでてきたのが950以降だというのがこのスレの駄スレっぷりを表してるな。
969 ：login:Penguin：03/08/11 07:40 ID:0ri0wVBC
＞＞９６６

しかも最後は他人よがり
970 ：login:Penguin：03/08/11 07:57 ID:r1gCWZLq
>>969
たぶん勘違してるよ。
965!=966 965=967
さっさとゲーム板に消えろ。
971 ：login:Penguin：03/08/11 07:59 ID:P9K1oWih
この板にこのスレが立ってる理由は

Winnyオープンソース化＝UNIX版誕生＝linux板住人(ﾟдﾟ)ｳﾏｰ

プロトコルの標準化とかIETFとかいう言葉が必要だと思ってるのが
一見さんの馬鹿っぷりを表しているな
972 ：login:Penguin：03/08/11 08:04 ID:r1gCWZLq
漏れも一見なんだけど、>>971だとするとスレタイトルと>>1の内容が不適切じゃないか？
オープンソースにしようと思ったらプロトコルは公開されたも同然でクローンもいくらでも出てくるしそしたら標準nyプロトコルが必要でそ？
と、マジレスしてみる。
973 ：login:Penguin：03/08/11 08:08 ID:XT3mPgOK
>>971
実はIETFも知らない香具師（プ
974 ：login:Penguin：03/08/11 08:11 ID:XT3mPgOK
>>971
>Winnyオープンソース化＝UNIX版誕生＝linux板住人(ﾟдﾟ)ｳﾏｰ
夏厨氏ねよ
975 ：_：03/08/11 08:11 ID:n2Ixq72V
http://homepage.mac.com/hiroyuki45/hankaku05.html
976 ：login:Penguin：03/08/11 08:12 ID:P9K1oWih
>>972
>こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。
ここはDOM対策のモデルを考えるスレであって何かを作るスレではない
標準化も何も全ては47氏のソース公開次第
977 ：login:Penguin：03/08/11 08:13 ID:0eZRt+Po
>>971
>Winnyオープンソース化＝UNIX版誕生＝linux板住人(ﾟдﾟ)ｳﾏｰ
真性馬鹿だな。
オープンソースになったらUNIX版の前に悪意のあるくろーんが先に出現するだろうよ。
それを阻止しつつWinnyを動かすための話題だろ。
978 ：login:Penguin ：03/08/11 08:17 ID:+J4lJK8u
>>971
だからオープンソースでUNIX版を作るには安全な標準プロトコルが(ry
もちろんクローズでUNIX版を作るなら標準はいらないが。
でもこのスレはオープンソースって書いてあるよな？
たのむから氏んでくれ。
979 ：_：03/08/11 08:20 ID:n2Ixq72V
http://homepage.mac.com/hiroyuki45/
980 ：login:Penguin：03/08/11 08:20 ID:HtDD9pyl
>>978
クローズでもオープンでもご自由に作って下さい




他のスレで
981 ：login:Penguin：03/08/11 08:23 ID:1nFn0wyt
>>976
オープンソースで問題になるのはDOMだけじゃないだろ。
嘘キャッシュ生成、ハッシュは正しく申告するけど送るデータは嘘、
通知する自分以外のIPアドレスを全て同一にしてDDOSに利用する、
など山ほどある。
982 ：login:Penguin：03/08/11 08:33 ID:4rsQWK3i
>>981
>オープンソースで問題になるのはDOMだけじゃないだろ。
>嘘キャッシュ生成、ハッシュは正しく申告するけど送るデータは嘘、
他ノードの必要とするようなデータをアップしない者はDOMと呼んでいるけどな。

47氏がWinnyをオープンソース化する場合に最大の弊害となっているのがDOM対策なのは間違いない。
よってそれを考えるスレなわけだが、
どうもスレタイも>>1も関連スレも見ずに
未だに何かを一から作ると勘違いしている方がいるようで。
983 ：login:Penguin：03/08/11 08:36 ID:DydBX9R9
>>976
夏厨はさっさと氏寝よ。
47氏のソース公開とこのスレの議論は無関係。
47氏が今のソース公開したら、現winnyネットワークは崩壊する。
だから、公開可能な新方式について議論しているんだよ。
1から読み直せ。
984 ：login:Penguin：03/08/11 08:38 ID:4rsQWK3i
>>983
>こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。
>
>その際には現在のWinnyとの互換性はなくなると思いますが。
誰でもいいけど>>1はちゃんと読もうね。
985 ：login:Penguin：03/08/11 08:41 ID:DydBX9R9
>>982
だから>>1読めよ。「互換性なくなる」ソースなんだぞ。
今のソースじゃないっての。
そのときに今のソースを公開するかもしれないけど、それはもう破綻した
winny仕様なんだよ。
今のソースを今公開したらwinnyネットワークは即破綻。
だから新方式を考えてそれを「取り入れてからソース公開」なんだって。
986 ：login:Penguin：03/08/11 08:47 ID:XV+YTzEG
現プロトコルにDOM対策だけ入れても破綻するってのにマジで気が付かないのか？
987 ：login:Penguin：03/08/11 08:47 ID:GGbDsx3s


一　見　さ　ん　必　死　だ　な　(藁


あれだけ有識者ぶって>>1すら読まずに暴言吐いてたんだから、
今更引き下がれないわなぁ。
>>1
>考えるのだけはよろしくお願いします。
作る？作るって何ですか？(禿藁
988 ：login:Penguin：03/08/11 08:51 ID:YrJBAIAc
>>987
必死だな → 何も言えなくなった
ってコピペがどこかにあったな。そのとおりだな。

とりあえず
ttp://www.ietf.org/rfc/
でも読んで公開されているプロトコルがどれくらいセキュリティをケアしているか勉強してこい。
989 ：login:Penguin：03/08/11 08:54 ID:qr8behbH
なあ、このスレ半分ぐらい読んで思ったんだが、
あるネットワークaの信頼性を、
ネットワークbを使って向上させようとすると、
またそのネットワークbの信頼性が問題になるから、
堂々巡りでないか?

それにノードの評価とノードの匿名化はトレードオフだと思うんだが。
990 ：login:Penguin：03/08/11 08:54 ID:PLaaR26+
>>988
それを読むべきなのは47氏ではなくて？
991 ：login:Penguin：03/08/11 08:55 ID:YrJBAIAc
ネットワークbを多重化して信頼性を向上でどうよ。
ノードの評価とノードの匿名性のトレードオフってのは良くわからん。
992 ：login:Penguin：03/08/11 08:57 ID:waML40uD
>>990
47氏も含めてwinnyのプロトコルを考える人全部じゃないか。
993 ：login:Penguin：03/08/11 08:58 ID:PLaaR26+
>>992
動くものとして公開されるまでプロトコルは47氏が組み上げるんじゃないの？
994 ：login:Penguin：03/08/11 09:01 ID:waML40uD
>>993
>>1で「とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので、考えるのだけはよろしくお願いします。」
って言っているので方式を考えるのは47氏以外だと思う。
995 ：_：03/08/11 09:07 ID:n2Ixq72V
http://homepage.mac.com/hiroyuki45/
996 ：login:Penguin：03/08/11 09:07 ID:PLaaR26+
>>994
考える内容っていうのは>>988みたいな堅苦しいものじゃなくて、
MXの次スレで開発当初やっていたようなアイディア募集って感じのものだと思うけどな。
997 ：login:Penguin：03/08/11 09:12 ID:GbQbVXfZ
>>996
煮詰まれば、考えるのだけはよろしく、とも書いてある。
なのでアイデアにとどまらず仕様上のセキュリティホールなく動くくらいまで
煮詰るべきじゃないかと思うが、2chじゃ無理っぽいね。
もちろんどんな小さくてもいいからアイデアを出し合うのは重要だと思うけど。
998 ：login:Penguin：03/08/11 09:16 ID:GIGqCIgP
ciasbod vfwfiowcknsdfpojqeojojopqwqiOP23910757902oif co doonwoiefnwpienf
fNWEOFWOEjofpjwopjfonoepnfpnv pp923ur9u29
999 ：login:Penguin：03/08/11 09:18 ID:GIGqCIgP
んじゃ２chくんなよ AAAaAOXJOJA
OJOSSSっっっっここギリシャあいあj
あぢぢqwひこだおjどあjどwじょqjどjwqおjqおwjqぽじょpjwpjqぺjpqじぇp
＞＞１＝１００１
死ね死ねいんしえんしねいsねいんしえ
死ね死ねsにえ
1000 ：login:Penguin：03/08/11 09:19 ID:GbQbVXfZ
999げっと
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。