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

デバッグに詰まったので、ちょっと長文行きます。
>>72を詰めるという話の腰を折ったらもうしわけありません。

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

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

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

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

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

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

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

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

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

匿名性のために

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

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

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

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

捏造データ対応のために

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

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

DOM対策のために

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

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

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

課題と問題点

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

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


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

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

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

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

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

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

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

どうしても設計にミスがあることを認めたくないならオープンソース化される事はないんじゃない。

>>360

>>351>>353についてご意見を下さい

風呂入ってたら案の定277がｗそれも長い(;´Д｀)
>>347>>352
×もう>>72は系周辺ノードの範囲、評価基準、優先の方法など
○もう>>72系は周辺ノードの範囲、評価基準、優先の方法など
ね。(恥
俺に思いつく問題はもうこの部分にしかないのよ。

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

>>360
ん？
>>72>>2777にも確認したいのだが中継ノードであってもUL実績がなければ制限受ける
(つまり実績がないノードに中継されるとDL者もとばっちり受ける)って理解で合ってる？
(それでも時間によって最適化されるはずだけどね。)
どうも自分の理解に自信がなくなってきたよ。

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

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

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

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

>>354に関してはなんとなく話しが通じそうなので熟読させていただきます。

341と344って違う人なんですね・・・。

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

ハンドル固定しませんか？

>>362
>評価情報を受け取る場合、評価目的のIPと一致するIPからの情報は破棄する。
>>344の図で言うと最終的に2のみが1に評価を報告することになりますが
2のみを中継する限り、全ての情報は2によって改竄可能です。
2が評価目的のIPを適当に指定して中継を装えばDOMになることが出来るでしょう。

>中継ノードであってもUL実績がなければ制限受けるって理解で合ってる？
私のイメージではそうですね。どちらが>>72さんと同じかは問題ではないと思います。

>>364
俺は７２案を全面否定しているわけじゃない。
今のままでは問題があるといっているんだよ。
そして>>354のような発言は47氏を彷彿とさせるし
おまいのような発言はLinnyスレの535 ◆HO0OFh2RXI を彷彿とさせるだが。
多分図星かと。
本当にオープンソース化したいなら人の意見も聞けよ。

>>363
あなたは自分の話に矛盾が生じる事になる都合の悪い所は飛ばし読みするみたいですね。

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

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

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

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

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

特定する必要などありません。
意図的に捏造ファイルをアップしているノードは、
他のノードと比べて圧倒的に評価を下げられる可能性が高いからです。
これは現Winnyにある捏造警告と同じです。

>>363
>その時点でそういう状況だとして過去にどれだけWinnyのネットワークに貢献したかは判断できない。
>またそれをする為には新たな懸念が生じる

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

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


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

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

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




まずは>>72をしっかり読んで理解して下さい。

>>344

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

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

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

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

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

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

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

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

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

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

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

やはりLinnyスレの535 ◆HO0OFh2RXI だったか・・・
おまいの想定は局所的であらゆる情況を想定していないよ。
ネタを語るのはLinnyスレだけにしてくれ。
邪魔。

>>371
論理的に語ることが出来なくなったらくだらない煽りですか

自分の意見を正当化するための最後の手段ですね。

>>369
おお。
ちょっと待ってくれ。
色々検討してみる。

とりあえず、>354氏に期待。

>>360
>>それでも「何を」ULしたかまではわからない。
>７４案を実現知る為には誰がDL要求したかを知る必要があるし
>何をDLしたいかという情報がUPノード１に伝わらないとUPしようがないでしょ。
>現在は表示されない情報だがオープンソース化されたら何に対してDL要求が来たのかを
>明示的に表示する改造は可能なんだな。
今のNYでもUPファイルを10個ほどに限定して悲惨少量を監視していればクラックせずとも
何をULしているかはわかります。そもそも、これによって実際にどういった問題が起きる
のでしょうか。具体的な例を出してもらえますか？
私は具体例を考えた結果大きな問題ではないと判断しました。

>>363
>最終中継ノードが正常なノードかもしれないのに評価を下げるのか？
>本当のUP元の評価には何も影響しないぞ。
その辺は中継発生率や具体的な評価方法でカバーすべきところでは。
>UPに貢献しているノードの優先の方をDOM対策よりより大きな比重を置いている
程度問題だけど、これも具体的な評価方法の問題の範疇では。
システム自体に致命的な不備があるとは思わないなあ。

>>365 えっ？経路が一本てそういうこと？？>>72の図にこだわりすぎでは？？
繋がってる検索リンク全部に評価ｷﾎﾞﾝクエリ発行(寿命短)するぐらい景気良く行くものだと
思ってました。また仮に一本に限定したとしても運良く2の位置を確保できるとも限りません。

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


>>354
思いっきり端折ると管理責任と効率のトレードオフってことでおｋですか？多重転送は可能性だけ
に留めておく方が幸せだとと思いますが。あと質問ですが、キーのサイズはどのくらいを想定してますか？
また交換成立する確率はどのくらいだと当たりをつけてますか？

>>72案補足
中継ノードにUL実績が無いためDL要求ノードまでとばっちりを受けることについて。
優先/制限の方法を帯域制限のON/OFFで行わず、UL枠で行う。

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

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

帯域制限で行う場合でも時間によって最適化されるだろうけど、どっちが良いかはまだちょっと
わからない。>>354の交換開始後の動作としても使えるかもしれない？

>>354
なかなかいいですね。
私の考えとしては、周りに評価を聞くよりは、直接自分が評価を下せるほうが
うまくいくとおもうんで。
自分で評価するとなると交換をベースにしなくてはならないんで、そこをどうしようかと
考えて、上のほうでちょっと案を出してみたんですが、検索部分と実際の交換部分を
分けるところがいいと思います。

ただ、なかなか揃わない可能性がありますね。

>>376
多重転送にする必要はないのでは。ｎｙよりも細かいキャッシュがもっと散らばる感じに
思うのですが。

>>376
スマンかった

>>367,368,372
呆れた。

>>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についてはあとで考察させて頂きます。

>>381
失礼しました。
4の一部の情報を1にはそのまま流すんですね。

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

これは>>72案で言うと
一部のケーブルテレビなどISP側でグローバルIPを
割り当てられていないノードにも考えられることですね。

宇宙空間を自転しつつ公転している地球上を飛行機で一周した場合、
全体として前進しているのか後退しているのか良くわからないよね。

飛行機の中の人は進んでると思ってるけど
地球を外から見てると進んだり戻ったりして見えるよ。
もう少し離れた所から見れば行ったり来たりしながらも進んでるようにも見えるけど
宇宙全体から見れば行ったり来たりしながら回っているように見えるかもね。

＞＞>>379
＞＞多重転送にする必要はないのでは。
>>355
>例３対応
>　問い合わせを受けたノードがキャッシュを持っている場合にはそれを転送、無い場合には他の
>ノードからの転送で行う仕組みとすれば
>>358
>　各ノードは他ノードからの要求があったハッシュコードを記録しておき、他のノードからの
>転送要求に応じる際に、そのデータを要求することもできる。
また、大前提として中継によるDL要求か直接のDL要求かをUL側は判断できない(しない)。
これらを考慮すると、多重転送になる(〜にする、じゃなくて「なる」)ことが増えるでしょう。
……とか書いているうちに自分で対応策を思いつきました。まとめられたら書きます(前提条件が
かなり多いです)。先に>>354さん自身が書かれるかもしれませんが。

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

>>385
>この部分は良い解決策が浮かびません。ノード識別のための代案あればお願>いします。

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

クラスタ化が働いているなら、特定のDLノードの周りには特定のDLノードの評価が多いはずです。

>>385
IPの一部＋起動した時の秒の下100分の1秒とかのランダムな数字
にしたらかぶりにくいと

>>354案の基本部分はこんな感じですかね。

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

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

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

★各ノードはデータ(チャンク)を要求されたときに自ノードが必要とするデータ(チャンク)を
　相手に要求することができる。データが無いもしくは転送ができないといった応答を要求してきた
　ノードの場合には転送速度を絞るなどして、データを受けるだけのノードは不利益を被る構造とする。
★データのやり取りに関わるノードは、そのチャンクが完成するたびに
　ハッシュチェックを行い破損のチェックを行う。

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

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

＜問題点＞
★チャンクが広がっていない状態で、ちょっと離れたノードからダウンをかけると
　ものすごい数の転送が起こることとなる。
★チャンクのサイズの問題。
★チャンクの名前空間の問題。
★交換不成立時の制限の強さ。
★レアファイルの流通。
★大きいファイルの時チャンクが揃わない可能性。

>>387
それだとIDと同じなんですよね

今のWinnyのままでオープンソースにすると「仮想キー」の中の所有者のIP
(ある確率で中継者のIPに書き換わる)がまる見えなんだけど、これで十分な
匿名性があるといえるのだろうか。DOMがどうとかよりこのことの検討が先
だと思う。

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

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

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

個人的に「完全ファイルリストによる検索無しシステム」というアイデアを
出しておきます。

>>391
また出てきたか。
おまいはスレの流れってヤツが読めないのか？

> 392
私を誰だと思い込んでるのか知りませんが、このスレに書きこんだのは391が
始めてですよ。

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

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

もしWinny作者の47氏が見ておられましたら、Winnyオープン化の問題点について
もう少しくわしく示していただけたらありがたいです。

wineで動けば移植する必要ないんじゃないの？
動かないの？

どっちにしても作者はソース公開する必要ない。

どうせDelphiのソースだからこの板にいるLinux厨は誰も読めないしね。

つーかクレクレ五月蝿くして作者に迷惑かけるなよ＞屑ども

47氏は匿名性については中継発生率が0でないこと、それだけで充分と
考えてるのではないかな。
参考：http://winny.info/2ch/main/1049124224.html#333
この部分は俺も同感。でも匿名性云々は程度問題だからなあ。
人によって求める基準が変わってくるのは仕方ないことかもねえ。

ttp://.jp/staff/in.cgi?id=13675

>>393
>DOMがどうとかよりこのことの
今はDOM対策を優先して議論しているというのに
その理由も分かっていない奴は(ry

>>393
DOM対策が必要という話題で来ている所に匿名性の話題が出て
またDOM対策に話しが戻っている状態ですね。
現在のDOM対策は>>354のDOM対策という名の不正ノード対策の例となる以下の物の中で
4)ネットワークに入り込み、ひたすらデータをダウンロードするばかりでネットワークに貢献しないノード
5)ネットワークに入り込み、そのネットワークに捏造データやウイルスデータなど傷害の原因になる不正データを流し込むノード。
についての対策についての話題が主のようです。

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

もし完全な匿名化を実現できるのならどのようなファイルの流通に関わってしまったとしても
身元が特定される事はないのですからアップロードしないような改造を施す必要もなくなるかと思われるので
完全匿名化されれば4)についての対策はそれほど重要ではなくなっていくのではと思います。

むしろ最近の違法ファイルの流通に対しての取り締まりが強化され始めている現状からすると
そのようなノードを取り締まる為に投入されるかもしれない次のようなノードに対しての対策の方が重要ではないかと。
1)ネットワークに入り込み、そのネットワークにアクセスしているノードのIPアドレスを集めるノード。
2)ネットワークに入り込み、そのネットワークで流れているデータのリストを作成するノード。
3)ネットワークに入り込み、そのネットワークにつながれているノードがどのような情報を保持しているかのリストを作成するノード。

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

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

そのあたりも踏まえてDOM対策について考えてみたらいいと思うのですが
>>399はどのあたりのDOM対策を優先して議論したらいいと思われますか。

>4)についての対策はそれほど重要ではなくなっていくのではと思います。
これには同意し兼ねるね。

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

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

この点が>>72や>>354で固まっているならいいけど
どちらにもまだ問題はあるし、すぐに議題がフラつくのはどうかね。

> 397
今までどおりならともかく、オープンソース化されたら参加者のIPを簡単に
集められるので、検挙される可能性ははるかに高くなるとおもいます。

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

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

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

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

どうですか47氏。

>>403
初めて書き込む前にこのスレすら読んでないだろ？
本当に一度1-390まで読んだなら理由を書いてもいい。
403の内容にしたってスレ読んでないのがバレバレ。

>>402
ADSL回線での話しなら不正なノードというか現在の常時接続者の多数が
光よりADSL使用者が多い事を考えると不正ノード扱いは出来ないでしょう。
ADSLが問題ならば将来光が当たり前になって行けば解決する問題であり
それはDOM対策というよりインフラの問題かと。

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

あなたはどのあたりのDOM対策を優先して議論したらいいと思われますかというのが
聞きたかったのでそのあたりについての解釈を聞かせていただけませんか。

公開しません。

つーか自分らで作ったらいいじゃん。
どうせ互換性ないんだし。

>ADSL回線での話しなら不正なノードというか現在の常時接続者の多数が
>光よりADSL使用者が多い事を考えると不正ノード扱いは出来ないでしょう。
プログラム側で不正をして、ADSL回線のDOWN帯域をフルに活用しながらアップはほとんどしないノードが出てくるって言ってるんだが。

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

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

>>402でそれ書いたんだが、意図を分かってもらえなかったかな。

>>395
つーかC++だから
馬鹿じゃねぇの？

>>389

問題点について
１．ネットワークの飽和については次の発言で
２−３．チャンクのサイズと名前空間の問題
　小さいチャンクであることが反応の点では好ましいが、あまり小さいと効率が悪くなるとともに、名前空間を食い
つぶすことになる。適当と思われるサイズを検討する必要はあります。
　ただし、128ビットの名前空間があった場合、10＾(38)ほどの空間を持つことになる、個々に100万(10＾6)のファイルを
割り当てたとしても、各ファイルが(10^32)ほどのチャンクをもてる。逆もまたしかりで、空間についてはそれほど
気にしなくても良いかもしれません。
４．交換不成立時の制限の強さについては、1チャンクの交換が成立しなかった場合、「そのノードからの要求を
一定時間受けない」と言う方法も考えられます。1チャンクの転送にかかる時間を元に制限を設けるが良いかと
思います。逆に効率よく交換が行われている場合には、より転送に拍車がかかるように、作りこむことで効率を
あげることができると考えます．
５−６．レアファイルについては、検索の効力を高める以外には手に入れることは困難だというほかありません。
ただ、レアなファイルのハッシュコードを知っていれば、周りのノードにリクエストしているうちに、集まってくる
という構造も考えられます。同様に、多数のチャンクから成り立っているファイルの場合にも、周りのノードに
リクエストを掛けているうちに、集まってくるようにすればよいかとおもいます。

・ネットワークの飽和について　
　ネットワークを効率よく使うために過度の転送要求の発行や、転送要求の受付を行うことは好ましくないと考える。
　よって、各ノードは効率のよい転送を行うための転送枠を想定するものとする。
　転送枠を越えての要求の発行や、転送要求の受け入れはしない。これによって、ネットワークの飽和状態を
避けるものとする。もちろん転送速度の速い、光などで接続されている、ノードは多数の転送枠を持つことになる。
　また、偽装して過度の転送枠を取得したとしても、相手側がそれに応じなければ効果を得られることは無いように
設計する。転送枠は(極力)実際の転送能力から算定されるべきである。転送能力以上の枠を使用した場合
個々の転送能力は低下する。これによって相手側ノードの反応も低下するとした場合、効率よくデータを得ることは
できない。
　このような保護機能を設けることによって、単独ノードが利益を得る構造を防止する。
こんな感じでいかがでしょうか？

>>408
では聞きますが現在のADSLの最大のアップ量である１Mを最大に使ってアップしているノードが
それ以上の貢献をするにはどうしたらいいのでしょうか。
ADSLの仕様上フルに転送速度が出ることはありませんが仮にフルに速度が出たとして
アップ側１Mダウン側１２Mが出ているノードを不正なDOMノードとする事は
ノード側からではそれ以上のアップ速度をどうする事も出来ない以上不正なノードとは出来ませんよ。

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

ADSLで10:1を実現するには最大の転送速度での標準仕様がアップ１Mダウン０．１Mになりますが
そのような仕様にすることへの問題点はどう考えられますでしょうか。

>>412
>アップ側１Mダウン側１２Mが出ているノードを不正なDOMノードとする事は
>>72や>>354の案であればこういったノードの存在は難しくなる
しかし>>72や>>354で問題点が出ている以上この案で必ずしもいいとは言えない。
また詰めていったら他に致命的な問題点が出てくる可能性もある。
詰めていってる途中にスレも読んでいない奴が匿名性を語ろうとしてたから忠告しただけ。

>ADSLで10:1を実現するには最大の転送速度での標準仕様がアップ１Mダウン０．１Mになりますが
そうじゃなくて、現在のインフラを全く考えないなら
日本にUP10M、DOWN1MのADSLが普及していると仮定して作ってもいいだろうってこと。
実際には現状、せめて少し先のインフラを考えて作るしかない。
まだまだ普及するには時間の掛かる光回線を想定するのは時期尚早ではないかと。

> 404
このスレは出来てすぐから見てますし、読み返しもしてるんですがねぇ。

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

> 408
そのレベルの話なら、やはり「匿名性」の考察のほうが先だという考えに
変わりはないですね。ただし、私は興味ありませんが、他の人にDOM話を
するなとはいいませんよ。それぞれしたい話をしましょうよ。

ソースクレクレ厨のいるスレはここですか？

>>414
>このスレは出来てすぐから見てますし、読み返しもしてるんですがねぇ。
じゃあ理解力が足りないのか。いえ冗談です。
きりがない。

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

>それぞれしたい話をしましょうよ。
本気か？
興味がないだけで他の話を進めて、邪魔になるという認識はないのかね。

>>413
>将来っていつまで待つ気かな。
こう書かれたあなたがまだ実現化かも定かではないインフラを元に仮説を立てるのはどうかと。

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

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

同時進行で二つの話題を進めてはどうかということは、あなたが過去のレスをを良く読んで
理解しているのなら既に出てきた話題ですよね。
同時に詰めて行きましょう。
そして色々な案を最後に総括すればいい話です。

>>417
>同時進行で二つの話題を進めてはどうかということは、あなたが過去のレスをを良く読んで
>理解しているのなら既に出てきた話題ですよね。
そしてどれだけ見辛いスレになったかも理解しているよ。

> 416
からみますねぇ。

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

もうちょっと推敲したら?>all

DOM対策について

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

匿名性について

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


　この二つの問題は、ともに重要な問題であり、表裏をなす問題でもある。
　くだらない言い争いをするより、両方の話を平行して進めるほうがよっぽど有意義。
　DOM対策のために匿名性について考える必要もあるだろうし、匿名性のために
DOM対策について考えてみる必要があることもあるだろう。　

私のスタンスについて、少し説明させていただきます。
興味の無い方ごめんなさい。

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

他にも検討すべき事柄がまだまだあると思います。仲良くやりましょうよ。

永遠にオープンソース化なんてありえませんな。
クレクレ厨ウザイよ

>>422
>>354の5)については今のWinnyのシステムで解決できる問題であるし
1)から4)に関しても各ノードとそれぞれのファイルの匿名性が確保できれば全て解決できる問題だと
認識しています。

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

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

そうしないと両案の具体的な解決策がそれぞれ出ているのにそれぞれについての検討についての話題に
移行できない現状は時間だけが過ぎていき問題の解決へ近づける為の議論が中断してしまう結果になっているような気がします。

>>391
私も>>138を読んでまずいなと感じたので、それを回避できる354案がいいなと思うのですが。
Winnyでまともに運営できる程度の転送率ではファイルと所持者IPの対応がかなり推定される
と思います。確実ではないですが、あまり気持ちのよい状態ではないでしょう。
それに、大量にIP詐称キーを流されると、まともなファイルのやり取りすらできなくなります。
さらに、いったい誰がやったのか、特定することはできず、ネットワークから排除することも
できないと考えます。
この点で、354案は攻撃に対する強さがあると思うのですがどうでしょう。

>>424
DOM対策といわれていますが、ユーザサイドでどういう比率かは正味どっちでもよくて、
ネットワーク全体としてUP＜DOWNには絶対になりえないことが問題です。
誰かがUpしない限り、Downはありえません。ネットワーク自体が成り立たなくなるのです。
そのため、
MXでは、自分で(人間が見張って)なんとかする。
Winnyでは、40k程度1枠としてUP+2でシステム上制限。
72案では、周りの人に評判を聞いてみて、自分が判断して制限。(Winny風)
354案では、挙動不審な人には制限。(MX風)
などが考えられていると思うのですが、いかがでしょう。

Linuxで動いても誰も使わない罠。

ソースオープンにするってことはWinny以上の匿名性を実現するメカニズムを入れないとだめってことだ。
ソースが閉じてるからそれなりの匿名性たもちつつ速度が保たれているわけだから、
オープンソースにすると今度は速度が犠牲になる罠。

そしてそれはFreenetと何も変わらない。
Freenetの高速化でも考えた方が現実的ちゃうか？

つまり、

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

どれを取るのかってことだ。全部実現できればいいわけだがWinnyやFreenetを超えるものを作らんといかんな。

>>411
転送について

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

あきらめて他のチャンク探しにいったとき、ファイルが大きい場合、あるチャンクの存在を尋ねて、
再びそのチャンクの存在を聞くまでにかなり時間がかかるかも。
ノードをチェックしておいて、次接続がかかったら、さっき聞いてたの入荷しましたよとか
答えるほうが効率いいのかな。

オープンソース化したら、真っ先に警視庁のハイテク科に餌食にされそう

http://homepage.mac.com/hiroyuki44/

http://homepage.mac.com/hiroyuki44/

http://homepage.mac.com/hiroyuki44/

>>425
>ネットワーク全体としてUP＜DOWNには絶対になりえないことが問題です。
>誰かがUpしない限り、Downはありえません。ネットワーク自体が成り立たなくなるのです。
UP＜DOWNになりえないという情況というのが
アップするファイルの数＜ダウンするファイルの数、という事になってはいけないという事でしょうか。

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

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

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

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

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

もしそうなりそうなのであればオープン化すること自体をあきらめるべきではないか考えています。

匿名性を証明するスタブでも作ってから言えよ。
おまえらのしてることはクレクレ厨と変わらない。
どのみち現在のWinnyとは互換性ないんだから
オープンソース化は無意味だが。

>>435

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

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

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

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

蛇足
　150Gのデータを持つノードが150Gの転送をした段階でアップロード不要にはなりません。その
データを求めるノードが1000あれば、そしてダウンしたすべてのノードがすべてDOMノードであった
なら、150000Gの転送を要求されることになります。ダウンしたノードのすべてが優良ノードで
理想的な状態なら、1500Gの要求を受けるだけですみますが。

Freenet を C で書き直したら、速度速くなるかなぁ?
速くなるんだったら、やるけど。

むしろFreenetのいけてるﾌｧｲﾙ共有ﾌﾛﾝﾄｴﾝﾄﾞきぼん。

>>438
是非やってもらいたい。
転送速度はわからんけど、動作は間違いなく速くなる。
>439も是非。ｸﾚｸﾚですまん

重いのはHDDアクセスや暗号処理だろう。
しかし通信速度はFreenetじゃどうやっても早くならないはず。
チャンク物切れや隣への無差別プッシュをやめて中継を必要最低限にすべきだろうが
それやるとnyになる罠。

ﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙ
ｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰ
ﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌ
ﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟ
ﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙ
ｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰ
ﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌ
ﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟ
ﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙ
ｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰ
ﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌ
ﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟ
ﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙ
ｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰ
ﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌ
ﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟﾙｰﾌﾟ

>>435
>もし現在のWinnyよりも匿名性の低い仕様になったとしたらオープン化されたそのWinnyは廃れていく事になるでしょうね。
そうは思いませんね。

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

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

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

もちろん匿名性を確保できるに越したことはありませんが、
オープンソース化の利点を考えたら
>オープン化すること自体をあきらめるべきではないか考えています。
これを支持することは出来ません。

Linux厨＝ｸﾚｸﾚ厨

>>444
ｵﾏｴﾓﾅｰ
444getおめでとう。

>>437
各ノードのアップロード能力の差への現在のWinnyの考え方は47氏がかつて述べた所によると
１．回線が早いと自動的に神状態（大量のダウン要求がくるけど勝手に持ってけ状態）になるが
　　ダウン速度はHDDが大量にあればそれほど下がらないはず（キャッシュが効くから）
　　よって、回線が早く上流の位置にあたるホストは、無条件でキャッシュに
　　人気のあるお約束ファイルが溜まっていく。
　　高速回線でHDDに余裕があるノードは、暇なときに回線に繋ぎっぱなしにしておくと
　　暇なときに自分のキャッシュに検索かけた時にさくさくファイルが見つかる可能性が高い。

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

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

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

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

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

蛇足についてですがオープン化する事で自ノード以外すべてDOMノードばかりになってしまった時は
その対策が取れていないままオープンソース化されたWinnyであったなら何も落ちてこないでしょうね。
そのような状態で公開してしまったら最悪です。
そういう事体ならない為のメカニズムについて考えるのがここですし。

>>443
匿名性が低くていいのならMXを使う方が現実的ですね。

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

改正著作権法が執行されても自由を維持できるくらいの匿名性は必要だろな。

>>447
>匿名性が低くていいのならMXを使う方が現実的ですね。
意見が合わないようですね。
この話はこの辺でやめておきます。

>UPデータ量≧DOWNデータ量を実行するには自分がダウンした物を全て公開キャッシュとして
>取っておけば可能です。
かなり勘違いしているようですね。

なにやら紛糾してますねえ
>>354の案も別に強力な匿名性を得られるものでもないと思いますが。管理責任が少し軽くなるかな、
というぐらいでしょう。個人的には分割する意義がイマイチ感じられません。

>>452
　IPネットワークにおいて、強力な匿名性を得る手段としてどのような方法があると考えますか？
　また、どの程度の匿名性を実現すれば実用的といえるでしょうか？

>>453
　キャッシュの分割は、おっしゃるとおり責任の分割です。それ単体で意味を持たないパーツ化します。
　また、ロジックの簡易化も目的としています。

>>454
>キャッシュの分割は、おっしゃるとおり責任の分割です。
わたしは責任を逃れるためのシステムには反対です。
らくに情報を発信するためにnyを使うべきです。

デコード可能なファイルを中継する行為が違法なのは当たり前。
中継ってのははダウンロード＆アップロードすることで
アップロードが違法にあたるわけだ。
なので中継か直かの区別はナンセンス。

>>455
　楽に情報を発信するためだけであれば、FTPサーバーを立ち上げるなど方法があるでしょう。
　クライアントサーバ形態の負荷分散であればミラーサーバーを立ち上げることもできます。
　ただ、このP2Pネットワークは他のノードの協力によって成り立ちます。この協力に対して
あなたが負うと同じ責任を押し付けることはできません。よって、協力するものは責任を負う
ことなく協力できる構造を作成する必要があります。
　自分が良いから、他人のことは考えない。これはDOMと同様の考え方ですので
そのような考えの方は、P2Pを使用しないでいただきたいと思います。

　言葉遊びによって否定的なことを言う香具師はDOMのできないシステムを
好ましいと思っていないのだろうが、作れるものはしょうがない。

>>452
354の案は、ファイルを分割することにより単体で何であるか判別できないように
できるという利点と共に、システムとして、あるファイルが「どこに」あるかを一切
提供しないという案であると思います。

ｎｙの検索システムであれば、元であるか中継であるかはわかりませんが
確実に取って来れる場所というものが明記されています。
それに対し354案は、となりにあるものとして取ってくる、という動作なので、
自分の隣以外は関係なくなります。接続すればIPアドレスはバレバレなので
それはしょうがないとして、それ以外の場所を原理的に知ることが意味を持たない
というのは匿名性、および攻撃耐性につながるとおもいますがどうでしょう。

>>457
縦

>>459
　あちゃ、馬鹿に引っかかってしまったのか

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

　でも、いくらなんでも馬鹿すぎる話は疑ってかかるようにします。

w/HMBlGMってほんとに煽りが好きだな
以前注意されたのに全く懲りていない。

どうやらスレよりも糞みたいなプライドを守る主義のようだが。

>>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をキャッシュサーバとして使って転送するものを無理に違法化しようとしたら
インターネットそのものを違法としなければならなくなるから難しいらしいね。

>>462
　Nyが違法かどうかといった問題は、
　アップロード自体が違法だなんていってる>>455の例にもあるとおり一笑ですむはなしです。
　すでに幾度となく、繰り返されている話。

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

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

　で、煽りってこれでいいのかな？でも、煽りにならないのが実に残念(笑)

>>461

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

　これは、大笑い。気分よくデバッグできるぞ(^_^)

>>461
>>463
いったい何の話ですか？？？
煽って注意されたってことは535かな？

煽られたというのもうなずけますね。

464氏=354氏

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!!!

354氏=535氏

(ﾟДﾟ)ﾏｽﾞｰ

>>465
　さて、注意された覚えもありませんが、もっとも彼が注意してくれたとしても
注意と受け止めるより煽りだと受け止めてただろうけど(笑

　ちなみに、535ではありませんよ(笑

> 462
これに関しては
http://members.jcom.home.ne.jp/makina17/r/winny.html
のような判断もあります。

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

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

とは言いながら、現Winnyの匿名性の壁(特に参加者のIPアドレス収集の困難さ)は
非常に高いです。

>私のように1の47氏の発言をオープンソース支持者に対する
>挑戦状と解釈した
自意識過剰

>>469
>とは言いながら、現Winnyの匿名性の壁(特に参加者のIPアドレス収集の困難さ)は
>非常に高いです。

高いかぁ？

>>469
そのサイトは法解釈に誤りがある。
誰でも見たりＤＬしたりできる場所に置いてあるものを見たりＤＬしたりする事について
その行為を行った者には現在の法律では違法性は発生しない。

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

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

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

追加
>「完全ファイルリストによる検索無しシステム」というアイデア
完全ファイルリストが常に見れる状態にするには何らかの中央サーバが必要となる。

>>472 もういっかい真紀奈さんの文章を読み直してくださいな。

> 470
これは実際に47氏がそう考えていると言っているわけではなく、47氏の発言で
わたし自身がWinnyのオープン化に挑戦したくなったということを
ああいう表現にしただけです。

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

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

> 完全ファイルリストが常に見れる状態にするには何らかの中央サーバが必要となる。
これについては別稿にかきます。

>>469
>とは言いながら、現Winnyの匿名性の壁(特に参加者のIPアドレス収集の困難さ)は
>非常に高いです。
なるほど、よく考えてある文ですね。

確かに現Winnyで参加者IPの収集は困難だけれども、
>>354案を採用した場合は必然的に複数ノードへDL要求することになり
違法だと判定しているファイルをハッシュ指定などすれば、
正常な動作、つまり不正なファイルをUPしているノードを簡単に見つけることが出来る。

ここにいるﾔｼは語ることしかできねーのかな。
とりあえず書き始めればいいと思うんだけど。

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

俺？俺はSEだから無理。
まぁ、ネットワークは専門なんで、俺なりに考えてみるかな。

>>474
ほい
ttp://www.netarc.jp/doc/20030616p2p.html
それと、>のあとにスペース入れんでくれ

>>476
ここはWinnyのオープンソース版を作るスレではなく
その実装不可能性を「考える」スレだと何度言わせれば・・・

>>478
ああ、なるほどね。
スラドから渡ってきて1から追いかけたんだが、最新50を読む限り
オープンで作りたそうな感じになってるんで、勘違いしてたよ。

俺は実装可能だと思うけどね。
まずはモデリングでもしてみるかな。

>>476
　　　　　　∧＿∧
　　　　　 （　´Д｀）＜ >>476応援揚げ
　　　　　／ 　　　＼
　　＿＿| | 　 ２ 　| |＿_
　 ＼　 ￣￣￣￣￣　　 ＼
　　||＼　　　　　　　　　　　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||
と思ったが期待薄

>>479
記事でも載ってた？

>>477
なるほど、どういうプログラムを使ったのかかわかりませんが結構
あつまりますね。単にtcpdumpのログからIPアドレスひろっただけだったりする?
だとすると、この点でFreenetタイプより優れているということもない
ですね。

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

>>475
345ではありませんが、この手のシステムではひとつのノードからは、あるファイルが
存在するのは隣接するどれかのノードの方ということしかわからないので、実際の
UP元まではたどりにくいと思われます。

>>481
いや、お決まりのP2Pネタにこのスレが貼られてただけ。
なので、別にここをROMってたわけでもなく、ここに来てまだ1時間ぐらい。

それと、煽りでも釣りでもないんだが、
論議(特に技術なお話)のレベルがやたら低くないか？
学生が多いのかな？
少なくとも、本職ではない匂いがプンプンするんだけど。

「完全ファイルリストによる検索無しシステム」について

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

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

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

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

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

以上ですが、わかりにくいかな。

>>479
　可能なことですよ。

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

　期待期待

>>475
　揚げ足取り(w

　リクエストをしたことにより、そのノードがリクエストをしたノードが「違法と思うデータ」を将来的に保持することになります。
　そのノードにデータがあるかの確認のためにアクセスしたことが、さならるデータの拡散を招きます。
　そのノードが、その情報をもっているとは確定できません。持っていないといっても、持っているかもしれませんし、
持っていないといっても、持っているかもしれません。
　ただ、リクエストしたら、将来いつかもつことになるかもしれません。

>>483
http://pc.2ch.net/test/read.cgi/linux/1053087824/882
>882 ：47 ◆KbtLZwerNc ：03/06/19 08:50 ID:AhStOI42
>Winny作者ですが
>
>あれがクローズドシステムになっているのは、好きでそうしているわけではなく、
>こちらの設計能力不足によるものですので、もしオープンソースでも問題ないメカニズムが
>導入できるのなら、こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。

ソースをオープンにする場合に考えられる問題点とそれについての解決策を
具体的な技術のお話を交えて披露していただけませんか。

わざわざクローン作らんでも本家が条件クリアできれば公開してもいいって言ってるんだから
後は条件クリアするだけでしな。

檄文

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

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

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

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

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

　P2Pを利用したサービスはいろいろと考えられる。その大海に出て行くには小さな船では心もとない。
しかし、乗り込んだメンバーがそれぞれの力を尽くしサバイバルを乗り越えれば新たな大陸を見つける
こともできる。乗客は要らない。

ｲﾀﾀﾀ

>>489
P2P ｵｰｸｼｮﾝ ｷｳﾞｫﾝﾇ

>>487
あのさー、「こちらの設計能力不足」とは、Winnyはオープン化を
想定しないで設計しているということでしょ。どうやって、
閉じたソースの「オープンにする場合に考えられる問題点と
それについての解決策を具体的な技術のお話を交えて披露」
できるのかね？まぁ、nyのメカニズム自体はみなさん
想像できてると思うけど、具体的な技術論は展開できないよね。
だから、nyクローンを作ることを想定して、モデリングしようぜ
と言ってるわけなのさ。

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

なんか、俺、煽ってるカンジなんで、書かない方がいいのかな？
デスマーチ真っ最中で、最近は性格きつめだしね。

「匿名のP2Pに弁護の余地なし」と米連邦控訴裁
http://japan.cnet.com/news/media/story/0,2000047715,20059481,00.htm

「ファイル交換ツールは合法」との裁定に驚きの声
ttp://japan.cnet.com/news/media/story/0,2000047715,20053985,00.htm

だいぶと荒れてきましたねぇ

354さんも何処かへ行ってしまったようですし
テストベンチの作成に忙しいのかな

まあ実際「考える」段階で既に頓挫しているわけだが(苦笑)

>>496
その前に法律の問題をクリアしておく必要がありますし
その前に47氏が本当にWinny3以降行き詰るかどうかを
見届けないといけないので頓挫というよりも
このスレはいささか先走りすぎているという気がします。
ここは議論を差し戻して足元からしっかりと
固めていくべきではないでしょうか。

宿題もやらないようなアホしかおらんしな

誰も何も考えてないな。
ここの連中はただソースが欲しいだけ。
487はその典型

>>492,479=476？
SEでネットワークは専門だという前提でお聞きします。
実装可能だと言われていたので問題点の把握と解決法がわかるのだろうと思いました。
技術のお話のレベルがやたら低くないか、という事でしたので技術のお話について
ご教授していただけると思ったのですが。。。

>あのさー、「こちらの設計能力不足」とは、Winnyはオープン化を
>想定しないで設計しているということでしょ。
これについてですが47氏が設計からβバージョンの公開まで約一ヶ月で公開してきた事を考えると
47氏の謙遜も考えられます。
つまり暗に｢オープンソースで問題のないメカニズムは導入できないのでは｣と考えているようにも受け取れます。
しかしそう解釈してしまうとオープンソース化を考える事は無意味な物になってしまうので
本当に無理なのかをこのスレで考察中です。
そして無理である事が証明されてしまえばこのスレの存在自体が終了となってしまいますので
是非ともご協力を。。。

>どうやって、閉じたソースの「オープンにする場合に考えられる問題点と
>それについての解決策を具体的な技術のお話を交えて披露」できるのかね？
では私がソースが全てオープンされた場合に考えられる問題点をいくつかあげてみましょう。

ソースを元に改造する事が容易になることで一番最初に考えられるのはこのスレでよく話題になる不正ノードの出現です。
・UP0パッチ、UP0の状態でのDL枠の拡大。
・隣接するノードの解析を主目的とした改造。
・キャッシュファイルに何を持っているかの明示化。
・DL完了と同時のキャッシュファイル削除の自動化。
・DL中のキャッシュの他ノードへの転送の無効化。
・どのノードから何をDLしているかのリアルタイム表示。
・どのノードへどのキャッシュをUP中かのリアルタイム表示。
・転送が発生せず直接UPしている事を証明する為の何らかの改造。
列挙すればキリがないほどの問題点があるわけです。

これらの一つ一つについてどういう設計ならそれぞれの改造を行われてもWinnyのネットワークが崩壊しないかを考察する時
現在のWinnyのソースが全て明らかになっていなくても一つ一つについての技術論は出せるのではないのでしょうか。
そしてそれらの案が47氏が見ても穴のないものであった場合、47氏によってソースをオープンにする前に密かに実装テストされ
全ての問題が解決できたと判断されればそれらの案が実装されたWinnyがソースごとオープンにされるかもしれないという事です。
最後になりますがオープンソース化の最大の懸念はWinnyの通信部分のプロトコルがわかってしまう事ではないでしょうか。

>「現実的で実現可能なロジック」を思いついては書き出して、
>その現実性を確かめないと、どうやって「考えたこと」が
>現実的だと判別できるのかね？
個別のケースについてそれ検証可能な「現実的で実現可能なロジック」を組めるのなら
ぜひお願いします。

○
結論：Winnyのオープンソース化は不可能

------------------------終了--------------------------------

ヴァカ？

これは簡単。47氏がWinnyをオープンソースにできないことを証明して欲しいんでしょ。
直感的にはすぐに分かるがなぜかは議論してもらわないと示せないし。

>>505
　直感的に解るって、あなた、だったら私には直感的に出来ると思いますよ。
　もっとも、出来ると思っている人は議論に参加するけど、出来ないという人はなぜ出来ないか
議論に参加することも無く、「できないからできない」としか云ってない。
　単に、「できないことにしたい」だけですかね。
　できないといっている人ほど、実は出来ることを知っているのだろうか？

そうだよ、DOM抑止の方法なんて皆気づいてるよ。
ノード評価にこだわってややこしい認証を持ち出しておおよそ
健全なネットワーク形成できないようなプロトコルを妄想談義してる君らを
せせら笑ってるのさ。

簡単だろ。
up0標準にして1対1のチャットを可能にする。
そんでファイル鯖作ってお互いの共有を覗けるようにする。
これでDOM対策は完璧だろ？

>>507
　ほー(笑
　言うだけならタダってやつですね。数学的に証明できるといった香具師と同レベルのピーだ。
　何事にも不満も疑問も感じることなく人生しあわせですね。

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

　まぁ、これで「不可能」なんていう香具師のレベルも知れたってことだ。
　可能性が見えてきたよ

いいかげん、「数学的」ひきずってるヤツうざい。

ヤツの楽しみは揚げ足取りと煽ることしかないんだよ。

>>510
　そりゃウザイでしょう。傷口チクチク。
　でも、ウザイと感じてしまうとは、不幸なことだね。
　自分の世界の中だけで万能のスーパーマンで居れば、数学的な証明だって出来るし
効率の良い方法だって実現できるんだから。周りの世界が何を言ったって、俺はヒーローって
思っていれば、幸せなのに。できたらその幸せな世界に引きこもって外部に出てこなければ
こちらも、とっても幸せになれるのだけど。

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

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

>>511
　だってこんなに美味しそうな、揚げ物あったら満腹だって、ついつい食べたくなるでしょう。
　カーネルサンダースもびっくりな、美味しさです。
　揚げ足取られないぐらいに、じっくり煮込んだしっかりとした考え方を書いてくれれば
揚げ足なんて取らないで、まっとうに対応して挙げられるけど、底が浅くて向こうが透けて
見えるふぐの刺身みたいな書き込みではね。
　ま、俗に云う釣りなのかもしれないけど、釣られる香具師がいないと可愛そうだしな
ボランティアかも。

>>509
ｸﾀﾞﾗﾅｲ折れの釣りにﾏｼﾞﾚｽなんぞしとらんで何か示せ

>>513

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

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

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

　ただ、最後のファイル鯖つくっての下りだけは、純粋P2Pじゃないのでイマイチ
だが、中央サーバがあるとファイル検索が簡単に作れるというのは魅力。
　このあたりの効率化とトレードオフをどうするか。問題ですね。

>>512
勘違いしてるようだが、第三者の目から見てウザイんだよ君は。

>>515
　馬鹿の一つ覚えで、論証もせずに、「不可能」としか言わない人間も
当事者から見て、うざいんですよ。
　ただね、その馬鹿が偉そうにしているんで、信じてしまう人がいるかもしれないので
対応してるの。
　もちろん、数学的に証明されてしまえば、不可能だというのは事実なのでしょうが、
不可能だとか言ってる香具師は、数学的に証明可能だといった彼と同類で、
自分の頭の中だけでしか出来ないことを、実際に出来ると思って発言している
ピーですからね。さらに、自分を信じているから自信を持って偉そうにしている。
じつに、はた迷惑な存在です。そのくせ、持論を人に公開して崩されることを
恐れているから、たちが悪い。

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

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

　それにね、あなたが第三者だとしても、耳が痛いからうざいんでしょ(藁
　ここには当事者はいても第三者はいないのだよ。自分ひとりで偉くなれないと
他人を頼るというのも情けないよ。

>>516
論証もせずに不可能というやつもｳｻﾞｲが
とくに反論もないのに人を馬鹿あつかいするやつはもっとｳｻﾞｲ

>>512
ｷﾓﾁﾜﾙ

>>503

ここは愉快なお魚さんがいるスレッドですね
餌をあげると暴れ回って、自分の水槽めちゃくちゃにしてる姿は
みていて、とても藁えます。

このスレでの「オープンソース版Winny」のありかたについての認識が、
1の47氏の発言の解釈によって、主に2つに別れているように思います。

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

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

目的が1なら403で書いたような「オープンソース、クローズドバイナリ」で済む
ような気がしてなりませんが、それはともかく、わたし自身は2の立場で、
1よりの人もその立場で、議論の中身で競いましょう。

>>517
　馬鹿の振りしている香具師を馬鹿扱いして何か問題ある
　馬鹿じゃないとこ見せれば、馬鹿扱いなんか出来ない
　ｳｻﾞｲとかいってるけど、なぜ不愉快なのか考えてみな

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

　みごとな、三段活用

　お次は、思い通りにならないかといって、アバれるのかな

おまいら、そんな釣りくらいスルー汁！

>>521
建設的な意見だね。整理されていて分かりやすい。
俺はもちろん「2，全面的見直し派」の立場に立つよ。

ところで、このスレに常駐している連中は、
何だって47氏にすがりつくんだろうね？
オープン版がないなら、自分で一から作ればいいじゃん。
もちろん、偉大な先人の足跡(Winnyの設計プロセスや
Freenetのソースなど)は有効活用するんだけどね。

>>522
だから、不可能じゃないっていう根拠を言えって
それがいえないならおまえも一緒
だからｳｻﾞｲ

頭ごなしに決めつけるの（・Ａ・）ｲｸﾅｲ

それもそうだね。

47氏を巻き込むのは迷惑だと思わないのか？

>>487
「不正ノードの出現」の解決は以下の通り。
ttp://de-co.info/freenet/icsi.html

手抜きでスマソだが、言いたいことは分かるよね。

一から作ればいいとか言っているけど
本当にそんなことが出来る香具師がいる？
知識と時間があり余っていて、尚且つヤル気の続く香具師。

それを誰も先頭きって出来ないっていう前例があるから、
ここは「考える」スレなんだけどな。

「完全ファイルリストによる検索無しシステム」改め
「完全ファイルルーティングによる検索無しシステム」について補遺

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

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

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

>>524
おお、たのもしい。私も素人ながらFreenet的システムでの効率アップについて
書いてますんで、暇なときにでもつっこんでやってください。

>>524
　47氏が現在のWinnyの公開できない理由の設計の部分を公開されない限り
その部分の改良ということは出来ないでしょう。もちろん、その部分を公開する
ことにより現在のWinnyの脆弱性を公開することになってしまうのかもしれない
ので公開できないのかもしれませんが。

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

　ただ、そのロジックが使えるものだということで、次期Winnyに採用され
Winnyがオープンソース化されることはまったく問題のないことだと考えます。

ここの人って粘着だね。
Winnyのオープンソース化なんてありえないのに。

>>532
1嫁

煽りばっかで議論進んでないように見えるんだが……
場所移したほうがいいんじゃねえの?

>>521の2.を実践するなら
ここはスレ違いなんで丁度いいかもしれませんね。

オープンソースなんて
自分で作ってから言え

>>524
＞ところで、このスレに常駐している連中は、
＞何だって47氏にすがりつくんだろうね？

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

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

　前提は「出来る」。どうやって実現するかを考える。その考えに穴が
あるなら追及するのは有益な議論です。
　ただし、ただ「不可能」というのは妨害行為以外の何者でもない。

Freenetのまずいところってなんだっけ？

>>538
遅い

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

なぜなら発言40でMXの次はFreenetだと言っているからだ。
しかし47でWinny開発宣言。今のFreenetでは使い物にならないことを良く分かっていたのであろう。

よく口ばっかりで手が動かんと言いますが、口も動かん馬鹿ばかりでは

>>539
どこで遅くなってるんだろうか。理想はあんな感じでいい気がするんだが

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

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

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

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

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

もともとはFreenetクライアントがJavaで組まれてるのにぶち切れたのが
作りはじめた大きな理由なんで、その通りではありますが、
そもそもFreenetのアーキテクチャは匿名性ばかり重視して
しまっていて無駄が多いと思うんでFreenetプロトコルには準じない
（Freenetクライアントにはしない）で全部自分でやるって方針です。

>>524=492,479=476？
>何だって47氏にすがりつくんだろうね？
>オープン版がないなら、自分で一から作ればいいじゃん。

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

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

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

>>543

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

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

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

>>1より抜粋
>こちらの設計能力不足によるものですので、もしオープンソースでも問題ないメカニズムが
>導入できるのなら、こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。
>その際には現在のWinnyとの互換性はなくなると思いますが。

>>544
Winnyのソースをオープンにする事ができるのは47氏のみです。
Winnyのソースをオープンにする事によって起こりうるかもしれない不具合が
現在のWinnyネットワークに影響を与えないようにする為に、もしオープンソース化する場合は
わざと互換性のないものにするのだと考えられます。

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

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

Winny2のその次を考える時どうしても一人でやっているのは限界があり大規模化は避けて通れないが
その方法としてオープンシステム化だけでなく、別の方法による大規模化は出来ないのかという事も
視野に入れいるようです。
一つの方法だけ固執する事のない47氏の幅広い思考がうかがえる部分ですね。

>>545
　ならば、とりあえず実験用のプログラムを組むことを検討するのは別に問題ない事じゃないですか。
　ロジックを考えるのは大事です。しかしそのロジックが実際に機能するか確かめなければ机上の空論に過ぎません。
　うまく動くようなら、47氏がWinnyに組み込んで（というより新たなWinnyとしたプログラムに実装)することになるかもしれません。

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

くりかえします>>1より
>導入できるのなら、こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。
>とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので、考えるのだけはよろしくお願いします。

>>545
> 一つの方法だけ固執する事のない47氏の幅広い思考がうかがえる部分ですね。
皇族の報道みたいだな。

なんかドーデモイイ内容を仰々しい文体で書く香具師ばっかだね

ACCSの人も大変だな

>>487
＞わざと互換性のないものにするのだと考えられます。

（　ﾟдﾟ）ﾎﾟｶｰﾝ

>>546
あなたは>>524=492,479=476？ですか？
もしそうなら>>502でも書いたとおりです。
>個別のケースについてそれ検証可能な「現実的で実現可能なロジック」を組めるのなら
>ぜひお願いします。

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

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

>>543の本意はWinnyとは関係のないオープンソースの新しい共有システムを
一から開発し実用化しようという意味ならスレ違いだと言う意味だったのです。
もしそうであれば546が新しい神となり47氏のWinnyに縛られず独自の共有システムを開発していく方が
そのスレも盛り上がるでしょうしテスターも多くなると思ったものですから。
しかし勘違いだったのなら申し訳ない。

「跳び跳びファイル転送」

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

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

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

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

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

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

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

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

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

前掲の「完全ファイルルーティングによる検索無しシステム」とこの
「跳び跳びファイル転送」によりWinny並の効率を確保し得ると確信します。

オープンソース化なんてしなくていいからLinux版バイナリで配布してくれ。

>あなたは>>524=492,479=476？ですか？
申し訳ありませんが、違います。

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

　ところで、神はいらないでしょう。

http://www.k-514.com/
ボッキンキン

>>530
>>552
同じ方なのかな。
両方とも、実際のネットワークに落とし込むと破綻するよ。
あと、大規模なP2Pクライアントを作るなら、
マルチキャストはやめよう。

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

freenet、JXTAは結構参考になるね。

>>554
そうですか、ではロジックの提案は>>556に頼むしかないですね。

>>556
>>502でも書いたとおり
>個別のケースについてそれ検証可能な「現実的で実現可能なロジック」を組めるのなら
>ぜひお願いします。

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

このコメントを読む限り、シロウトというわけですか・・・。残念です。

>>558
なるほど。
よくわかりました。

さーてと、俺の考えるnyオープン版。
・nyと互換(こんなのは言わずもがなだよな)
・MXと接続(これは感覚的にいけそうだが、現実的ではないかも)
・匿名性をnyより上げる(代わりに帯域をすこし犠牲に)
・いちど書いたらどこでも走る言語で実装(個人的にUMLを使いたいだけ)

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

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

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

識者、情報もとむ。

>>560
Winnyと互換性のある物は47氏以外には出せませんよ。
ネットワークが専門の方なので失礼だとは思いますが念の為。

いまさらnyの互換アプリ作る意義なんてあるの？
しかも47氏に迷惑掛けてまで

>>556
このスレでの書き込みにはメール欄に初書き込み番号をいれてあります。

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

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

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

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

>>552案に関しては特に問題が思いつきません。

>>562
では、オープンにする意義を分かりやすくおとぎ話風味で。

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

まぁ、おとぎ話ですが、ﾐｯｷｰﾏｳｽ法をよしとしている我が国でも
起き得ることだと思いますね。オープンならそこらへんのリスクを
防ぐことができる。ただ、それだけの意味だね。

>>564=>>524=492,479=476？=483
>>483>論議(特に技術なお話)のレベルがやたら低くないか？
で言われたような話はやめてレベルの高い技術なお話が聞きたいです。

>>563
失礼、484を読んでいなかったよ。

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

システム的なツッコミでなく、申し訳ないけど。

>>566
そろそろ語るのはやめて実装可能ならモデリングした上で「現実的で実現可能なロジック」を思いついては書き出して、
その現実性を確かめながら「考えたこと」が現実的かどうか判別してくださいよ。

少し組み立ててから、討論しなきゃ意味ないでしょ？
｢シロウト｣な俺が｢クロウト｣のあなたに言うのも変な話だろうがな。

>>566
484案は、不正ノードや落ちたノードを考えなければ、自分が認識している
ハッシュ値を持つファイルに一直線にたどり着けます。これが「ルーティング」
の効率化で、552案は上で得たルートを短縮することによる「ファイル転送」
の効率化です。

たしかに「検索」なしにすると新しいファイルより定番のファイル集め
中心の使用感になるかも知れません。帯域をしぼって検索を実装しても
いいかも。

>>568
もっているリストの一部を隣に渡すのではなく、
隣に持っているか聞く、では無理かな。
そこは匿名性より効率取ったほうがやっぱりいいのかな

　とりあえずは、テストベンチは出来ました（まだかなりバギーな感じだけど)。
　現状では100ノードぐらいでノード情報のやり取りをしたネットワークの状態を視覚的に見ることが出来ます。
　ノードの機能をプロトコル毎にコーディングしてやればいろいろな機能を試すことが出来ると思います。
　もっとも、現状では各ノードの状態がどういう状態であるかがわからないので、Winnyのステータス画面のような
ノード毎の状態を見れるユーザーインターフェイスを追加しようと思っています。
　初めて使う言語でライブラリ周りが不明でちょっと苦戦しそうですが、やってみます。
　なんぞ、良い方法がでてきましたら、実装向け暫定プロトコルを設定して組み込んで見ます。
　とりあえず、354系列でテストしています。

　テストベンチで厄介なのは、テストデータを用意するところとテスト結果の検討です。ちょっとしんどい。

期待age

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.

354氏待ちで議論が止まってる･･･

むしろ47氏待ち。

>>574
47氏登場は実現のめどがたってからだろう

なにやら停滞しているのでネタ投下
どこにどの程度の匿名性が求められているのだろうか

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寄りになるかな。

47氏が何を何処まで必要としているのか分からないんだよね。
それこそ末端のアイディア一つで実装、公開出来る人だからなぁ。
前スレでの発言のタイミングと、以前の発言から
DOMの排除方法が一番（唯一？）ネックになっているんだろうけど。

>>576
>>354の案のおもしろいなと思った所は、探ろうとする動作そのものが
相手に影響を及ぼすところ。
持っているかと聞いたつもりが、新たなダウンロードをよび所持元が
わからなくなる。元々のダウン要求元もわからなくなる。

ただ、そんなに錯綜状態で検索ダウンロードがまともに動くのかが心配

354は懸案事項で、ノードごとの役割分担を
提案したものではないでしょう。

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

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

最終的に誰が見ても問題のある穴がない案になれば
ループを抜け出して次の話題へ移っていけるかも。

おまいら、もう時間がないかもしれません

【韓国企業】ＮＡＶＥＲと２ちゃんねる、本格的提携の模様【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/

というわけでますますnyのオープンソース化を期待する他力本願な塗れ

こっちも結局勢いなくなったな。
Linnyの呪いだ（ｗ

2chの危機どころじゃない
この日本を守るためにもBBS機能に特化したLinux版winnyの開発を！

>>作って奴
ソース出せ糞

>>579
354案というのは>>354-359のチャンク化に関する案のつもりで言った
>>388-389にまとめたつもりなのでよろ。

354氏がテストベンチの結果を出してくるまで議論は辛いんじゃない。

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

ｶﾞﾑﾊﾞ>>354

>72系への新しい提案が思いつかないので、とりあえず>>354系の気になるところ
を書き出してみる。

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

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

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


>>581みたいのには�dと疎いんですが隊長までゴソゴソやらざるを得ない状況なのかえ。
なんだかねえ。このスレもNY2BBSに引っ越すかい？(藁

藁が余計だわな。
答える気がしなくなるし。

>>589
IDがもう少しでUnix。惜しい。つか後ろも年号みたいでｶｺｲｲな。

>>588
NY2はまだバグがね〜(w

βだから仕方ないけど、今はβ4.2だったか。

>>588
一応私の見解です。
＞(1)
チャンク自身は自分からキーを発行しない。応答Upのみ行う。
ダウン率が落ちるのは、予約中継ダウンロードシステムによりカバーできるかどうかを
>>354がテストしてくれているみたい。

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

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

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

これってかつての暗号化キーがあった時に似ている気がするんだが
うまくいくのかな

＊＊＊終了＊＊＊

>>592
>チャンク自身は自分からキーを発行しない。応答Upのみ行う。
正直これでは無理ぽいと思うから確認したい訳でして。

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

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

あと、>>354のテストベンチは交換部分の調整(チャンクサイズと送り付けるキーのサイズ、対
応するデータ量の調整)のような気がしないでもないす。

＊＊＊終了＊＊＊

>>594
>>チャンク自身は自分からキーを発行しない。応答Upのみ行う。
>正直これでは無理ぽいと思うから確認したい訳でして。
この点がこの案の重要ポイント。できれば画期的解決案で無理なら廃案。
今のWinnyは、そんなに遠くまでキーが飛んでいるわけではないはず。
では、自分の隣のノードがキーのIPに書かれている状況はどのくらいだろう。
この確率が高ければ、あるキーを発行したのは送ってきたノードであると
みなしても見つけることは可能ではないか。また、予約制度を入れれば、
隣でなくとも要求が転送されることにより、見つかり次第自動で落とすことが
できるだろうと思う。
釣り糸を出しておいて、ネットワークを適当に動き回って引っ掛ける感じで。
糸が当たった人もまた、同じ糸を出して動き回る（こともできる）ので、
引っかかる可能性は上がるかと。

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

>>ファイルキー
完全ファイルキーは全チャンク補足or所持、部分ファイルキーは一部チャンク所持、
受可ファイルキーは部分ファイルキーのうち完全ファイルキーを受け取ってから
一定時間内のもの（Winnyの定義と異なった使用法なら指摘よろ）
とかして完全or受可なら外部に出すことができるでいけるかと。

あくまで暫定案

データの管理の構成

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

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

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


ダウンロードの手順

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

>>597
手順２までのハッシュ情報ファイルを落としてくる所までは、
Winny式にやってもいいと思う。

保守ってみるんだよもん。

>>484と>>552の案を検証するためのテストプログラムを
書いてみました。

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

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

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

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

もう少し粘ってみますが、>>484案は使えないよう気がしてきた。

期待あげ

広大は、器もい、しかも、エロい！！！！！！！！！死ね死ね市ね死ね死ね市ねーーーーーーーーー

広大は、男子には、死ねとか、暴言を言うけれど、女子には、イチャついたりしているから、きらわれているんだよ。　　　　　　　　　

その人の本名は、フジワラコウタ（藤原広大）きもいよーーーー！キャーヘンタイーーーーーーーーーーーーーーーーーーー！！！！！

>>600
　テストプログラム試してみました。
　
　Pythonは試してみたい言語ですが、これでまた試したくなってしまいました(罪作りな)

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

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

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

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

　面白いと想います。
　コードの読解してみます。

http://headlines.yahoo.co.jp/hl?a=20030714-00000003-zdn-sci
P2P実態解明へノード自動探索システムが稼働

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

関連スレ
P2P実態解明へノード自動探索システムが稼働
http://news4.2ch.net/test/read.cgi/news/1058181887/l50

>>606
クローズドでやっていても、ちょっと探せば、ネゴの仕方なんかは
プログラムの中にしか書いていないのだから避けられない。

対策としては、こういうことばかりしている不正ノードを弾く仕組みを考えるか、
こういう事されても構わない匿名性を確保するか

>>607
前半部分の文章が意味不明。
後半部分は同意。

>>605
感想ありがとうございます。

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

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

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

ちなみに
　def get_hash(self, hash, hops, route):
#　　print self.addr,route
の所のコメントをはずすとルート探索の途中経過がわかります。

>>600
おとせなかったんだが、おれだけ？
またあっぷしてくれるとうれしぃ

>>610
便乗きぼんぬアゲ

ほれ。
http://220.108.81.79/test.py

2〜3日したら消すので、必要な人はバックアップ取ってね。

http://220.108.81.79/fe8882a34470.zip
zip も置いておきます。

>>610
>>611
2ちゃん公式アップローダーはアップしてから24時間過ぎると落とせなく
なるらしいです。

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

そろそろ Winny もやばそうだね。
http://www.zdnet.co.jp/news/0307/14/njbt_05.html

>>615
禿矢場

DOM対策や●お世話した（UP先）ノード ●お世話になった（DL元）ノードの情報を残していく事が
オープンソース化する上でどのくらい無駄な議論かわかってもらえたかな。

多少効率が悪くても匿名性を確保する事が重要なんだな。

>>608
ソースを隠した所で、プログラムを展開する鍵も、どうやって通信するかも
プログラム中に書いていないと実行できないのだから、がんばって探せば
原理上はWinnyのノードですと、しゃべるノードをつくって情報をもっていく
ノードは作れる。
の意でした。すみません。

>>618
がんばって探せればいいね。
Winnyのノードで、しゃべるノードをつくって情報をもっていくノードを作るには
クローズドで更新が頻繁なソースでは厳しいと思うよ。

>>619
ここはオープンソース化を考えるスレですよ。

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

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

その他の部分をオープン

>>615-617
オープンソース化を考える上で参考になりそうなところは何一つないんだが。

それとネットアークの調査情報は>>477で既出。

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

(･∀･)renice!

http://tmp.2ch.net/test/read.cgi/download/1058199380/51

(´-`).｡oO(こっちでもこういうこと書いてくれれば無駄な争いも減らせたかもーね）
(´-`).｡oO(名無しでこっそり議論を誘導しようとしてたのかもしれんけど……)
(´-`).｡oO(……まあうまく誘導できるわけないわなｗ)

最近匿名性を話題に出したのは漏れのような気が・・・
47氏ここ見てたのならWinnyの匿名性についての説明乙でし

>解析されて改造されるとファイル共有効率が落ちるからです
オープンソース化にはこの部分が問題になるという認識でいいんですかね

>あと、匿名性がまた話題になっているようですが、nyの匿名性に暗号はほぼ>関係ありません。
>もしWinnyのソースを全て公開して暗号を全て取り除いた状態でもnyの匿名
>性は変わりません。
>
>通信内容、キャッシュなどを全て解析しても匿名性は保たれように設計され>ています。
>Winnyの匿名性の肝は転送動作であって暗号ではないからです。
（http://tmp.2ch.net/test/read.cgi/download/1058199380/51）

保守。
自分でシミュレータ書こうかと思ったけど挫折しそう･･･めんどい･･･

ぶっちゃけp2pの仕組みってどういうもんなの？
その辺りから説明してくれよ。p2pってファイル共有の為だけのものじゃないよな。

>>629
「P2Pがビジネスを変える」
「P2Pインターネットの新世紀」
でも読んどけ。

47氏の発言で紆余曲折が少しは減るかな。

今のNYBBSのスレは落ちてることが多いからさ
誰か常時起動できる人新しく立ててよ

354案はテストベンチ待ちだから取りあえず置いといて。


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

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

別に「全く新しい」形態でもいいけど、
それはコードを書く気のある人が別のスレでやってもらいたいね。

>>633
全員コード書くんじゃないのか(ｗ

>>633
ここはWinnyのソースを流用することを前提にするスレではありません。
47氏がソースをオープンにしてもいいと思えるように問題点を解決する方法を考えるスレです。

「P2Pファイル交換で禁固5年」の法案

米下院に7月16日、P2P経由のファイル交換を取り締まる法案が提出された。
インターネットユーザーが著作権者の許可なく1本でもファイルを交換した場合、
最大で禁固5年と罰金25万ドルを科す内容となっている。

http://www.zdnet.co.jp/news/0307/18/nebt_17.html

　市民団体の電子フロンティア財団（EFF）はこの法案を批判。
EFFのフレッド・フォン・ローマン弁護士は「ファイル交換を行った人物を刑務所に送ることは答えにはならない。
この法案の提案者は、プライバシーや革新、そしてわれわれの個人の自由さえも置き去りにし、
ファイル交換に対する戦争の巻き添えにしている」と話している。

http://www.zdnet.co.jp/news/0307/18/nebt_17.html

日本では3年以下の懲役または300万円以下の罰金だったから、ちょっと重いね。

>>634-635
ソースを一切流用しないのであれば、
47氏にWinnyをオープンにしてもらう必要はないって(w

>>634-635で言ってる事が特に間違ってるとは思わないけど、
Winnyのコード流用を前提にしないと話進まないのは事実だよ。
「全く新しい」ってことになるとLinnyの二の舞になる。

そもそも Linny 時代からネタであるわけですが。

>>639
話しがずれているよ。
それはオープンにされたあとの話題だろ。
オープンにされる事も決定していないのにその後の話をしてどうなる。

今はどうすればオープンにされるかを話す時なんだが。

>>633
354ではないが、354案なんだが。ちょっとテストプログラムを作ろうと
いろいろ考えていたら、問題点が。

検索システムについて、欲している人が探すのと、持っている人が調べるのと、
2つの方法がある。
Winnyは前者。これをするためには、持っている人の場所を明示しなければならない。
354案は後者。これにより匿名性は上がるものの、持っている人、または中継する
人に負荷がかかることとなる。
これが第1の問題。

第2に、チャンク分割による検索性の悪化の問題が挙げられる。
これは第1とも関連するが、Winnyであれば1つのキーで済んでいたものが、
10個100個1000個などと増えてしまう。さらに悪いことに、多重ダウンロードの
判断が要求側にある。Winnyでは1つの要求で済んでいたものが、パーツを
自ら探して、1つずつダウンの要求をかけなくてはならない。
(Winnyであれば送信側がある部分を持っていなかったとしても、
持っている部分を代わりに自動的にダウンすることができる)

送信側優先の匿名性の確保、2ノード間不正ノード判定などができる反面、
検索性の悪化、ダウン効率の悪化が考えられる。
この点について、テストベンチの結果が注目されると思う。

チャンクの問題点って、大したこと無いんじゃないの?
匿名性の確保が優先でしょう。

>>643
そんなあなたにはFreenetという素晴らしいソフトがありますよ。

へー。それはすごい。

>>614
いいや、オープン前の話題。

失礼>>641ね。

>>647
オープン後にソースを流用して問題点を改良しようというのは
オープン後の話では？

>>648
DOM対策が出来ればオープンに出来る
DOM対策である72案
それを採用した場合の利点(採用する理由)である>>633

これはオープン前にどの案を採用するか考えた場合に必要な要素だよ。
現実問題としてコードを書く人間の負担というのも起こり得るから。
他の条件が全く同じなら現在のソースを活用出来る方がいい。

ただそれだけなんだけど無駄に噛み付かれると疲れるな。

>>649
現在のソースを活用するのはオープン後の話では？

>>650
活用するのはオープン後でも活用出来る案かどうかを考えるのはオープン前
DOM対策をするのはオープン後でもDOM対策出来る案かどうかを考えるのはオープン前

釣りなのか？

話がループして参りました。

>>651
DOM対策をするのはオープン後？
オープン前の話では？

>>653
・・・はぁ、釣られていいのかな。

ソースを一切公開しない状態でDOM対策を組み込めるのは47氏だけだよ。
47氏が実装することを前提にしても、
結局47氏があなたの言う「オープン前」にソースを活用することになる。
47氏が実装しなかった場合はどっちも「オープン後」になるけどね。

このスレが立った経緯くらいは理解しといてよ。

>>654
47氏が「オープン前」にソースを活用することになるという詭弁ですか？
47氏が実装するに値するメカニズムをオープン前に考えるスレですが何か。

いい加減にしませんか？

>>655
詭弁だと思うのはあなたの勝手だけど。

ソースを活用出来るからこそ、ここはLinnyスレじゃないんだよ。
はっきり言って全く新しいものは作れない。
UNIX版を作れない47氏にもそこまで暇はないだろうね。
よって活用の度合いは一つの利点となる。
優先順位は低くてもね。

新しく作れる人はLinnyスレでも何処でもご自由にやって下さい。
ループするけどそれが出来なかったのがLinnyスレ。

釣りでもいい加減にしてくれよ。

寝る前に一言。
47氏が実装しなかった場合「オープン後」はありえません。
「オープン後」の話はナンセンスでし。
おやすみ。

>>657
>とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので
やっても良いってだけでやるとは言ってないよ。
ここを勘違いしていたようだね。

おやすみ。

ソース流用うんぬんはいいから、出てきた案の、うまくいくならいく、
いかないならいかない理由を考えろよ･･･

設計が煮詰まってもやらない場合があるのだとしたら
ますます「オープン後」の話はナンセンスでし。

既にあなたの論点に矛盾が生じているわけだが
どちらが勘違いしているかは第三者が判断してくれるでしょう。

>>660
また勘違いしているけど、やるやらないは47氏本人が実装するかどうかということ。

根拠も無しに詭弁だというあなたにこれ以上説明しても無駄なようだね。

>>661
47氏本人が実装してもよいと思えるような
メカニズムをオープン前に考えるスレですが何か。
「オープン後」の話しをする事にどのような根拠があるのかわかりかねます。

>47氏が実装しなかった場合はどっちも「オープン後」になるけどね。
>>657

根拠も何もあなたの理論が崩壊している時点でナンセンス。

ﾒﾀ議論はもういいよ(w

>>662
「オープン前」という表現が本当に間違っているなら詭弁と称する必要はない。
「オープン前」にソースを活用することになるのは事実。

まぁ前であっても後であっても(47氏が実装するにしても我々が実装するにしても)
>>633の利点は変わりないのだけど。

まだ寝ないの？(w

>>664
「オープン前」に未公開のソースをどのように活用するのかな？

>まぁ前であっても後であっても(47氏が実装するにしても我々が実装するにしても)
「オープン前」か「オープン後」かをなぜうやむやにするのか。

ここは「オープン前」にメカニズムを考えるスレなのだが。
オープン前に47氏が実装してみる場合と混同しないように。

ID:UBYdTaRC
ID:h9LZqKT7
おまえらまとめて寝ろ

>>665
一つのメカニズムには様々な要素がある。
>>633もその一つ。
実装するかどうかまで考えた場合、
先に様々な要素を洗い出しておく必要がある。

ただそれだけなんだが、何故分かろうとしないのか。

http://tmp.2ch.net/test/read.cgi/download/1058441304/793

>どうも最近、意図的に捏造ファイルを流している方がいらっしゃるようですが、
>逆に捏造減らしその他に使えかもということで新機能入れてみました。捏造警告です。
>
>ファイルに対する捏造警告は前からありましたが、今度はノードに対する捏造警告機能です。
>今までの捏造警告と使い方は同じで、無視条件でハッシュ指定して切断オプションもONですが
>（周囲のノードで見るとキーの参照量が赤くなる）、違うのはこの捏造無視条件にヒットする
>キーを送ってくるノードを、従来の無視ノード扱いと同じ扱いするということです。
>無視ノード警告が二種類になったと思ってください。
>
>警告出されるとそのノード間はつながらなくなるのでクラスタ分断します。
>これは無視ノード警告と基本的に同じ動作です。違うのは捏造警告の場合、該当キー
>一つだけで動作するということです（無視ノード警告ではたくさん送ってこないと警告出さない）
>
>無視ノードと捏造警告はポート警告と違い、接続停止したりしないので無視しても特に
>問題ないですが、あまり警告を無視していると他の通常クラスタと分断されます。
>
>とりあえず、捏造ファイルを送ってくるノードに繋がりたくない場合は、積極的に
>捏造警告出ているファイルに対して各自も捏造条件入れて排除してください。

ny2に実装された捏造ファイル対策、47氏談を一部抜粋。
DOM対策にも使えそうですね。

実際354案はFreenetよりも効率の悪くなる可能性を抱えているよなぁ

テストベンチの結果が楽しみだね

そんなことよりWinny1のバグ直してくれよ。落ち膜離。

あのね（ｒｙ

のね(ry

>>668
>どうも最近、意図的に捏造ファイルを流している方がいらっしゃるようですが

捏造・・・47ってヴァカ?

>>673
もうちょい詳しくその心を。

>>646
Winnyがオープン化したとしても今のWinnyとは全く違う別物になる事くらい少し考えれば分かりそうなものだろ。
47氏は、この先は再設計しかないとny2開発宣言の前に発言している。
現行Winnyとの互換性とかソース流用とか言ってる香具師はどこに問題があるか理解してない。
http://winny.info/2ch/main/1049655320.html#436

要するに47氏は
「今のWinny方式じゃ無理だから新しい方式を考えろ。
良い案が出たらコード書いてやる。」
と言ってるわけだ。

それでもまぁ、転送部とかハッシュのチェックとかは
Winnyのコードを流用することに価値はあると思うけどね。
逆に言えばそこにしかWinnyのソース流用に価値はない。


というか、そんなことはみんな判ってると思うんだけど、違うん？

「逆に言う」って表現流行ってるね。
逆に言えば、「逆に言う」と言いたいだけちゃうかと。

逆に言えば逆に言うと言いたい香具師はみなｼﾞｻｸ(･∀･)ｼﾞｴﾝちゃうんかと。

コードとか言ってる時点で間違っている。
プログラムを作るには最初に仕様書を書くだろ。
47氏のいうメカニズムという意味は新しい仕様を考えてくれと言ってるんだよ。
仕様が固まらないのにどうやってコードを考えるんだろうか。

>>676
Winnyのコードを流用して何がしたいんですか。
Linny？

このスレ立ってから一ヶ月以上経過したが何も進んでないな。
ループしまくり。

何処がループしているのやら。

今は完全に354のテストベンチ待ち状態。
これで有用だと判定出来ればもっと話を進められる。
逆に出来なければ72案を進められる。

>>675
>>679
>Winnyのソースを公開するのもありかと思ってます。
>>1くらい嫁

>こちらでそれを取り入れて
これが抜けてたな

>>682
>もしオープンソースでも問題ないメカニズムが
>導入できるのなら、こちらでそれを取り入れて

>>684
導入と取り入れるがほぼ同じ意味だから省略したけど。
完全に新しい仕様を考えることを導入とは言わんよ。
「再設計しかない」と言ったのを今回は「こちらの設計能力不足」と訂正している。
この意図も分からないかな。

本スレ住人がこの前スレから見ていれば、
47氏が何を必要としているか分かると思うんだが。

DOMを排除できる設計
今のｎｙに取り入れることが可能

この二つが実現できる設計をだれかが考え付いたら
それを取り入れた今のnyとは違うもののソースを公開してもいいってことだろ。

>>685
47氏が「もしオープンソースでも問題ないメカニズムが導入できるのなら」と言ってるのは
47氏にはオープンソースでも問題ないメカニズムが思いつかないと言ってる様に感じたのだが。

もし47氏でも思いつかないような問題のない仕様がlinuxスレ住人の685が思いつくのなら
その仕様を提示すればいいのでは。

>Winnyのソースを公開するのもありかと思ってます。
この前提には
>もしオープンソースでも問題ないメカニズムが
>導入できるのなら
があるということ。

47氏が何を必要としているかを分かっていないのは誰かな。

逆に言えば、ﾏﾀｰﾘ汁ってこと?

>>686
禿同

>>687
>その仕様を提示すればいいのでは。
72案を実装する。

これなら今のWinny方式のコードを追加、一部改変するだけで可能だろう。
問題点があるならご指摘どうぞ。

>>72が秀逸だと思うのは現行Winnyとの互換性が極めて高いこと
>>675の発言を未だに信じてしまっているようだけど
47氏が再度発言している部分に関してはちゃんと読まないと

４７氏が善意で作ってくれたのにオープンソースにしろっていうのは失礼だと思う

>>691
だれがオープンソースにしろって言ったの?

>>682
＞>Winnyのソースを公開するのもありかと思ってます。
＞>>1くらい嫁

そのWinnyが現行Winnyを改良したものになるとはどこにも書いてない。
名前だけ同じで中身が別物のソフトなんていくらでもある。
第一、47氏は互換性が無くなると予想している。

>>685
＞完全に新しい仕様を考えることを導入とは言わんよ。

全く新しいものを採用する場合でも導入という表現を使う。

＞「再設計しかない」と言ったのを今回は「こちらの設計能力不足」と訂正している。

47氏は現行方式のには先がない事を知ってるから再設計しかないと思ったのだろう。
ただし、それを数学的（wに証明出来ないから能力不足と表現したに過ぎない。
不可能な注文に対して「それは難しい」と断定を避けた回答をするのは良くある事。

>>689
＞問題点があるならご指摘どうぞ。

漏れが言いたいのは、何で現行方式との互換性にこだわるのか？と言う事。
47氏が必要としているのはオープンにしても大丈夫な設計であって、その設計が
現行Winnyと互換性を持っている必要はない。
もちろん互換性があっても構わないが、互換性にこだわる必要は全くない。
互換性を捨てる可能性を排除するべきではないと思うが？

# 47氏自身が互換性が無くなる事を予想しているのだから、
# 最初から互換性は考えなくていい。

>>693
どういう仕様にしろ現行のWinnyと接続するのは無理だろうね。
それは皆分かっているのでは？
互換性というのはコードそのものに対しての発言だと思うが。

>47氏は現行方式のには先がない事を知ってるから再設計しかないと思ったのだろう。
>ただし、それを数学的（wに証明出来ないから能力不足と表現したに過ぎない。
つまり現行のWinnyを拡張した形になる72案には先がないと？
だとしたら代案を是非聞かせて欲しいが。

>互換性を捨てる可能性を排除するべきではないと思うが？
誰も互換性を捨てないとは言ってないと思うが？

47氏が ｢現在のWinnyとの互換性はなくなると思いますが。｣と書いているのは
互換性がある物を作れないからではない。
現在のWinnyと互換性のないものにしようと思っているだけ。

47氏談
>オープンソースであったりプロトコルが公開できるのであれば
>そのソフトは生き続けますが、Winnyの場合、これをやるとDOMを排除できないので無理です。

オープンソースにしたりプロトコルを公開する事は解析されて改造されるのでDOMが現れると予想している。
だからもし仮にオープンソースにしたりプロトコルを公開する事があるなら現行のWinnyに影響が及ばないように
プロトコルに互換性のない別バージョン｢Winny v3.0｣になるという事かと。

>>694
コードそのものの互換性？

>喪前等
>アフォちゃうの？

喪前ﾓﾅー

>>695
>現在のWinnyと互換性のないものにしようと思っているだけ。
そもそも47氏の負担を完全に無くすためのオープンソース化なのだから、
現行のWinnyを47氏が更新しないなら現行のWinnyは生き続けない。

またどんな方法にしろDOM対策を実装するわけだから、
オープンソース化を無しにしても現行Winnyとの相互接続は出来ないだろう。

>コードそのものの互換性？
つまりオープンWinnyを作るにあたってどれだけソースの流用が効くかってこと。
47氏の負担を無くすためのオープン化でまた一から作って下さいとは言い難い。

こんなことはどうでもいいんだが。

>47氏は現行方式のには先がない事を知ってるから再設計しかないと思ったのだろう。
>ただし、それを数学的（wに証明出来ないから能力不足と表現したに過ぎない。
これについてもしあなたが72案に先がないと考えるなら、
その根拠と代案を聞かせてくれないか。

>>697
47氏の負担が軽くなるのはオープンシステム化かもしくは
別の方法による大規模化が実現した時になるだろうが
なんらかのメカニズムを47氏が取り入れてWinnyのソースを公開するところまでは
47氏の協力なしには実現しない。

オープンソース用の別バージョン｢Winny v3.0｣を47氏が作るにあたって47氏がどれだけ現在のソースを
流用するのかまた一から作り直すのかは分からないがそれは47氏が考える事だと思う。
ここで出来るのは案を出す事とそれを検討する事だけ。

それからDOM対策を実装できたとしても47氏が現行のnyと互換性を取るつもりならとれると思うよ。
だから47氏がわざと互換性のないものにしようとしてると思ったのだが。
理由は>>695で書いた通り。

72案に先がないかどうかについての質問は>>693へどうぞ。俺じゃない。

ただ72案に先があるかどうかは別として>>693の意見は理解できるし間違っていないと思う。

>>695
＞互換性がある物を作れないからではない。
＞現在のWinnyと互換性のないものにしようと思っているだけ。

クローズド前提の仕様をどうこね回したらオープンに出来るの？

＞47氏の負担を無くすためのオープン化でまた一から作って下さいとは言い難い。

47氏は一からBBS専用のプロトコルを実装し直すくらいだから心配ないよ。
その手間を惜しむような人ならny2に着手する事もなかっただろう。

＞これについてもしあなたが72案に先がないと考えるなら、

仮に47氏が現行方式を改良する形で72案を実装したとして、それは評価機能を除けばクローズドWinnyと同じものです。
公開されたソースを元にクローズドWinnyと互換性を持つUP0Winnyを作る事が出来てしまう。
（これまでに旧バージョンを排除してきた方法では切断出来ない不正ノードが出てくる）
だから72案で行くとしてもプロトコルは一から作り直しになるから互換性を気にする必要はない。

使えるかどうか分からない72案はクローズドのままで47氏に実験してもらうしかないんじゃないかな。
でも47氏から何もコメントがないようですし、恐らく47氏もこの案は検討した事があるんだと思いますよ。

>>698
>流用するのかまた一から作り直すのかは分からないがそれは47氏が考える事だと思う。
47氏の負担が少なくくて済む方法であると共に、
完成状態にあるWinnyを出来るだけ壊さない方法を考えてもいいと思うけどね。
Winny1のβテストを見てれば分かるけど、
分散型P2Pシステムを効率良く稼動させるのは並大抵のことではない。
47氏ですら開発当初は失敗するかもしれないと危惧していた程。


>72案に先がないかどうかについての質問は>>693へどうぞ。俺じゃない。
違う人だったか、これは失礼。
しかし>>693の発言は72案を否定したのか、そうでないのかが一番問題なわけだが。
それと現行Winnyを改良したものでないなら、
わざわざ47氏にオープンソース化を促す必要もない。

47氏！
また最初から別のファイル共有ソフトを作って
そのソフトのソースを全て公開してください！
Winnyだって一年掛からずβ取れたんだから今度も大丈夫でしょ？
時間的余裕でUNIX版は作れないらしいけど、UNIX版作るより楽だよね！？



ほんとに47氏がやると思ってる？
354案とかさぁ、無茶な設計してる香具師は自分が先導して作れば？
47氏に何を頼ってんの？

つーかはやくソースみせろよ！！！ぼけ！！

>>700
>それと現行Winnyを改良したものでないなら、
>わざわざ47氏にオープンソース化を促す必要もない。

要するにできるだけ現行のWinnyとソースが変わってない状態でオープンにされないと
意味がないということですか？
そうなると考えられるのはソースを見て自分なりに改造したWinnyで現在のネットワークに
入り込みたいというのが>>700の目的でもありそうですね。

47氏はそういうのを一番懸念しているんだと思いますよ。

下らん議論だ

>>703
滅茶苦茶言うね。

オープンソース版が出来れば現行のWinnyなんて誰も興味を示さなくなるよ。
何せ47氏が現行のWinnyの開発を終了したことになるのだから。
入り込むも何も、誰かがDOMパッチを配布していずれ現Winnyネットワークは崩壊する。

頼っているのは47氏が現在ほぼ完成した状態で所持しているソースであり。
何か別のものを新しく作ってもらう力ではない。

いくらなんでも47氏が全て最初から作るとは考えられないよ。

正直、ｎｙ以外の共有ソフトはみんなDOMを許すシステムにもかかわらず
破綻することはない。eDonkeyのように糞遅くなるだけだ。

それを気にしなければソース公開しても問題ないだろうしnyのクラックパッチが出回っても
システムが破綻しないと思われ。

宿り木は宿る木が無いと生きていけない。

>>705
あのさぁ…オープン化したとしてそれが機能するかはやってみるまで分からないんだよ。
オープン化ってのはソースを誰でも自由に扱えるという事だ。
一度オープンにしたら失敗したとしても元に戻すなんて事は出来ない。分かる？
下手に互換性の残ったWinnyをオープンにしてネットワークが成立しない事態になろうものなら、
あとには何も残らないんだが、そんなリスキーな真似を47氏がするわけ無かろう。

あなたは72案に自信があるようだけど、それが必ずうまく行くという保証はあるの？
無茶苦茶言ってるのはどっちなんだろうね。
別に72案に反対しているわけじゃないんだけど見通しが甘すぎるよ。

＞分散型P2Pシステムを効率良く稼動させるのは並大抵のことではない。

ってあなた自身が言った言葉を忘れてませんか？
現時点で「匿名性」「効率性」「オープンソース」
この3点を同時に満たすソフトは存在しないわけだ。
誰も踏み込んでいない領域に入ろうとしているのに良くもまあ、互換性だのと幻想を抱けるな。


>>706
すばらしい洞察+1

>>705
オープンソース版さえでれば現行のWinnyなんて誰も興味を示さなくなるのでしたら
>｢現行Winnyを改良したものでないなら、わざわざ47氏にオープンソース化を促す必要もない｣
現行Winnyを改良したものでないといけない理由はないのではないですか。

オープンソースになれば改造も容易になるからなんの対策も取られていなければ
DOMパッチ版と対策版のリリース合戦になりますよね。

ここで大事なのは各ノードが勝手にDOMパッチをあててもオープンシステム上で
なんらメリットを受ける事が出来ないもしくは逆にデメリットを受けるようなシステム
でなければならないと思うわけです。

現在のクローズドシステムでの47氏の無視ノード対策は
http://tmp.2ch.net/test/read.cgi/download/1058441304/793
・ 無視キーによる切断チェック処理を高速化した
・ 捏造警報条件にヒットするキーを送ってくるノードに捏造警告を出すようにした
・ ノードに対する捏造警告機能をつけた
・ 警告出されるとそのノード間はつながらなくなりクラスタを分断するようにした
・ 警告を無視していると他の通常クラスタと分断されるようにした

このようなものがあるわけですがこれは相手ノード側からは無視される事を止められません。
それについては問題もあるのですが、、

とにかくそのようなシステム上の仕組みを考えないとオープンソースにしたところで
ネットワークに影響がでるかもしれないですね。

やたらとのびてるからベンチできたのかと思ったら、ループしてただけか

ループと言うよりは同じ行にGOTOしてる感じ。

### 現時点で明らかな事

・今現在DOMり放題なのは、作者47だけ。絶対君主制

・もし47にWinnyオプソ化のメドがついていたとしても、自分だけDOMり放題という
　既得権益を手放してまでオプソ化するメリットはない

### もしオプソ化となった場合の今後の展望

・オプソ化によって小数のDOMれる人、多数のDOMられる人という封建貴族制へシフト

・一般のソフトウェアの場合と異なり、穴に気付いたごく小数の人だけが明確な利益を
　吸い上げられる状況において、善意のコミットがなされなくなるのでは？ 自分は少し
　ずつ損をしていっているのでは？、といった疑念が利用者の間で膨らんでいく。

・利用者の間で、このような疑念や不安のなかった古き良き「優しい独裁者」47による
　Winny時代へのノスタルジーが湧き起こる。

・公開されたソースをライセンスを無視して囲い込み、アレンジして利用者を呼び込も
　うと企む輩共が現れはじめ、利用者が分散していく。

・「覆水盆に返らず」一時のオプソ化への熱狂は、一体何だったんだろうね。
　と苦い後悔を噛みしめながら、FTPやMXで土下座してファイルを貰う乞食に戻る。

>>711
社会の時間で習った言葉を使う機会があって良かったね。

>>706
>それを気にしなければソース公開しても問題ないだろうし
気にしないならeDonkeyでもMX3.3でも勝手に使っててくれ。
遅くていいならFreenetでもいいだろう。

WinnyはFreenetの欠点、効率の悪さを補ったソフトであることをわすれちゃいいけない。

>>707
>オープン化したとしてそれが機能するかはやってみるまで分からないんだよ。
どのようなDOM対策を加えるにしても現行のWinnyとはプロトコルを変えてくるだろうし、
少しでも変わっていればクラックする手間も変わらない。
47氏が少しずつプロトコルを変更しているのもそのため。

>あなたは72案に自信があるようだけど
現実的なアイディアが他にないからまずは72案の可否を検討しようとしているだけ。
354案はテストベンチ待ちみたいだしね。

>>708
>現行Winnyを改良したものでないといけない理由はないのではないですか。
だから47氏が全て最初から作ってくれるのか、という話。
もしこのスレに来て「どんな設計でも新規にコーディングします」
と言ってもらえれば何も言うことは無いが>>1を見てもそうは思わない。
だから同じ条件なら現在のWinnyのコードを活用出来る案の方が
より現実的だろうと言っているんだが。

>オープンソースになれば改造も容易になるからなんの対策も取られていなければ
>とにかくそのようなシステム上の仕組みを考えないと
その対策、仕組みに72案などがあるのだが。

問題点があるならご指摘どうぞ。

どうせ47に作らせるんなら、新規に作ろうが、winnyを改造しようがどうでもいいことなのでは？
ユーザレベルのやつとか、DOM改造をなんとかして施そうと考えてるようなやつは、
ただまってればいいんだよ。

問題は、72とか354の案が理論上大丈夫っぽいとしても、
実験してレポートでも出さない限り、47も開発開始またはソース公開しないだろうってことだ。

>どうせ47に作らせるんなら、新規に作ろうが、winnyを改造しようがどうでもいいことなのでは？

新規だと47は作らない。
というか時間もモチベーションもなくてきっと作れないよね。

>>715
1ヶ月もかけてBBS専用のプロトコルやらトリップやらを新規に設計した実績があるじゃん。
ny2のファイル共有機能と掲示板機能は別ソフトと言っていいくらい違うものだよ。

47氏が言ってたよ。
「夏厨ごときが ”47に作らせる”とかえらそーに吠えてるのを見てやる気なくなった」
って。

あーあ

47氏って２ちゃんねる初心者？
その程度でやる気をなくしてるんじゃ
人間が出来てないね。

>>718
という釣られる藻前がsy(ry

Winnyがオープンソースだと使ってる人は色々と困るんじゃないのか？

なぁこのスレ夏坊で充満しててゴミレスばっか増えてくから
まともなWikiでても立ててやれば?

>>721
おまえがたてろや

オプソにしたらいろんな亜種ができてダメになるだけ。

わざわざオープンにしてなんか意味あるわけ？
お前らオープンにしたいだけだろ

>>713
プロトコルが変わるというのをどういう意味でつかってますか？
最近の話題を理解しておられるとは思えませんが。
既に説明が終わっている問題を又説明しないといけないのですか。

問題点があるとしたら話しがループしていることでは。

スレの流れを無視して思いついたことをひとつ

とりあえず通信経路はSSLで…


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

■─┬─┬─┬　　　1/3ぐらいずつファイルを転送
　　　●　 ●　 ●

■　　　　　　　　　　　　相互に通信して補完
　　　■→■→■
　　　　 ←←←

だめぽ

winnyスレ(MXの次)から流れてきました。
流し読みしたんですけど、発言者のDOMの定義がまちまちなように思えます。

私なりにDOM対策としての話の方向性を考えたのですけど
・winnyはダウンロードばかりする人もキャッシュ保持&転送(非port0)という点でネットワーク全体に貢献している(排除する必要が無い)
・オープンソースになった時、ネットワークに貢献しないでダウンロードに比重を置いた改造版が出回る点が懸念される
という点がDOM対策の要点だと思いました。

現在のwinnyで実現されている、転送動作アルゴリズムによる以下の特徴があるようです。
・winnyが回線速度申請を嘘申請したとしても、挙動は変わるが別にダウンばっかり出来るわけではない(過去ログ見つからず)
・通信内容、キャッシュなどを全て解析しても匿名性は保たれように設計されている(47氏の発言より)

そこで、われわれが考えるべきなのは、winnyの上記の特徴に加え
「オープンソースになってパラメーターをいじられたバージョンが出回っても、大多数が正常なバージョンである限り、
破綻しない転送動作アルゴリズム」
を考えるべきだと思います。

ソースがオープンになっても、問題が起きない(起き難い)アルゴリズム向けならば、47氏もソースを出しやすいんじゃないかと
思いますが、いかがでしょうか。>47氏

はぁ？
もともと問題が起きないロジックが出されない限り、
47はソースを公開しないんだよ。(ロジックがでても本当に公開するかもわからないが)
>>1 さえ見てない状態で本当に流し読みしてんのか？
話をループさせるな。

> 「オープンソースになってパラメーターをいじられたバージョンが出回っても、大多数が正常なバージョンである限り、
> 破綻しない転送動作アルゴリズム」

これがキーポイントだね

http://cgi.members.interq.or.jp/hokkaido/asato/upload/jam3ddr/OB0002065.gif
ループしている部分はここ

ちっとも次に進まない

A->Bに転送する場合
・A->Bから直接データを転送、またはA->C->BとCを中継する。
・と同時に転送データのMD5値をA->D->B経由で転送する。(D!=C)
・Bは受け取ったデータとMD5値を比較し・・・
　　・正しければデータを受け入れる。
　　・間違っていればA,(C,)Dを容疑者リストに登録し、転送を中断し別の経路で再開する。
　　　　・既に容疑者リストに登録されているホストは有罪確定リストに登録し、
　　　　　今後検索・転送・中継を拒否する。
・転送に成功したらA,(C,),Dの無罪確定リストに追加し、
　次回の転送時に優先的に利用する。

・各リストはクライアントログイン時に毎回初期化する。

　　　　　　　　　　　地震ワッショイ！！
　　　　　　＼＼　 　　地震ワッショイ！！　／／
　　+　　　+　＼＼　　　地震ワッショイ！！／+
　　　　　　　　　　　　　　　　　　　　　　　　　　　　+
.　　　　　+　　 ／■＼　.／■＼ 　 ／■＼　　+
　　　　　　　　（∀｀　 ） ∩ ´∀｀）　（　 ´∀）
　　　+　 （(　⊂　 　　つヽ　　　つ ⊂　　　つ　)）　　+
　　　　　　　　 ヽ （　ノ　 (ヽ　 （　　　）　） ヽ
　　　　　　　 　 (＿）し'　（＿）＿）　 （ .__）＿）





|_-)ﾐﾝﾅｼﾈﾊﾞｲｲﾉﾆ．．．

>>730
進めたい奴がいないから、進まないわけでは?

>>733
いや
反論の中の問題点（矛盾点）を指摘しているのに認めないみたいだから進まないんでしょ
そして戻る所はいつも72案

winnyという巨大ネットワーク(クラスタ)で各ノードの情報を共有し
相互にチェックしあう仕組みを作っている

あらすじはこんな感じですか？

>>734
ということにしたいのですね? :)
2ch固有の「知障」に反応するからいけないんだと思うんだがね。

>>736
いや
技術者なら矛盾が生じた時点で次の理論を考えるのは当たり前
目的は求めるものの完成であってその過程でつじつまの合わない理論につき合うのは非常に疲れる

>731
それ、面白そうだね

似非技術者が住むスレはここですか?

>726
■─┬─┬─┬
A　　B□ C□ D□


だめぽとか書いたけど、これ使えるかも
3人だったら1/3に分割してデータと、他のノードに送った部分のMD5値を送信。
あとは相互に通信して不足部分を補完。
こうすればDOMは防げる。
もしどれかのノードが不正データなどを流してきたらMD5でチェックして
無視ノードリストに追加。
こうすれば同時に複数のノードに無視されるようになる

効率を上げるなら
■─┬─┬─┬
　　　□　 □　 □
　　　↓　 ↓　 ↓
　　　□　 □　 □
こんなふうに多段につなげてもよし
匿名性を挙げるならAの一個後に転送をかませてもよし

メリット
・DOMはできない(厳密に言うとできるがネットワークに貢献している)
・B,C,Dは著作物を送信してない(ぁゃιぃ)

デメリット
・複数代のキューがたまるまで送信できない

>>740
>あとは相互に通信して不足部分を補完。
これ説明が無限後退してるよ(藁

単にA<->B<->C<->Dの双方向リストを形成して
上位ノードにリクエストを発行する。
下位ノードからリクエストがあったら自身のキャッシュを返す。
なければ上位ノードにリクエストを発行して返ってきたらそれを下位に返す。
# 下位への応答よりも自分のリクエストを優先させる。
# 結果リストの下っ端は転送効率が下がる。
データのチェックは各ノード間で行う
# 誰が怪しいかは分からないし
# データがおかしかった場合リスト全体を破棄するのはもったいないし
# 嵐に利用されかねないので。
というのじゃ駄目なの?

パフォーマンスをあげたい場合は複数本のリストを形成すればいいだけ。

うーん。なんというか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に無視ノードとして登録される

永久にファイルが落ちてこないような気もする…

>>730
>>734
本当にこのスレを見てるのかな。
誰も72案の問題点を出していない。
72案の問題点などを考えていればループすることもないんだがね。
>もしこのスレに来て「どんな設計でも新規にコーディングします」
>と言ってもらえれば何も言うことは無いが>>1を見てもそうは思わない。
それもこの部分の意見の相違ということで終了している。
354案などを47氏に実装してもらえるかどうかは47氏にしか分からない。

>>743
>>1からずっと見てますよ。
また反論に矛盾点がありますよ。
ループするんですか？

悪貨は良貨を駆逐するってのはこういうことか。
やっぱ場所変えたら? 2chじゃなくてMLとかに。

>>745
何も駆逐されてはいないと思うよ。

2chだからこそこれだけ人が集まるし、ゴミレスなんてものも気にしない。
明らかにレスする価値がないならしなければいいだけ。
その判断を出来る人間同士で議論すればいい。

ここは47氏へのおねだりスレですかｗ
結局犬はドザに媚びることしか出来ないのですな

んー、次スレはUnix板にでも建ててみるかい？
向こうなら多少違う風が当たるかもね。

カラアゲうまうまスレ住人とか。

>>748
ここでいいって。
何処へ逝ったってダウソ板住人が議論することになる。

通信技術板とかどう？過疎っぷりがいい感じかも。

このｽﾚみたい対象が小さいものは通信技術は微妙かも。デフォ節は魅力だけど。
あそこの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/

板の問題ではなく2chは議論には向かないって事だよ。

>>752
2chの問題ではなく議論に参加する人間の質に問題がある。
700みたいのは放置しなければならないんだが、それを徹底すれば何とかなる。

発言に煽りが入るのは論理に自信がない証拠。
そういうのは徹底して無視すればいい。

煽り云々の問題じゃなくって発言の文脈が捉え辛いのと
発言がゴミレスに埋まってしまうのが問題なんだよ。
ベースは2chのスレで構わないけどそれ以外に
議論を掘り下げていく別の場所が必要だよLinnyWiki立て直してくれよ。
新規でも構わないからさ。

Linny Project復活ですか？

そうだね２ｃｈにはゴミしかいないもんね
あれ
じゃあなんでここのスレの人達は２ｃｈにきてるのかな？

荒れてしまう前72案にご指摘。。。

各ノードが自分と関わりを持ったノードについて
単純で軽い（１つのノードが情報を捏造しても影響が少ない）情報を保持し
問い合わせがきた場合その情報を問い合わせ元へ応答するという
>>72案を実装した場合の問題点

いくつか考えられるがわかりやすく何点かにわけてあげてみる
一つ一つ想定する状況が違うので反論する場合はどの問題点についてか明示すること

【状況その壱】
・共有する気などまったくなくネットワークの崩壊だけが目的の団体、組織によるノード投入

　偽評価ノードの大量投入
〔活動〕
　ノード情報を集めその全てに対して最低の評価を応答する
〔結果〕
　各ノード同士が最低の効率での共有を強制させられる
〔考察〕
　その偽評価を各ノードが止める事は出来ない
　流れている評価が正しいものなのか偽物なのか判別は不能

〔聞きたいこと〕
　これを72案でどう防ぐのか

【状況その弐】
・サークル、グループなどある程度の仲間があつまった場合の集団による評価詐称

〔活動〕
　自分以外の各メンバーに対する問い合わせがきたら高評価であると応答する

〔結果〕
　DOMパッチを当てているにも関わらず高評価となり優遇される

〔聞きたいこと〕
　これを72案でどう防ぐのか

【状況その参】
・72案システムそのものが持つ問題点

　このシステムの場合初めは評価値ゼロのノードとしてULが開始されるが
　時間が経つにつれ評価は上がっていく

　しかしその為にはある程度の期間他のノードが自ノードの評価を保存していてくれる事が前提となっている
　自分に関係のない他ノードの評価の為に無駄なディスク容量を確保してもらえるのか
　またどんなに評価が高くなろうと、その情報を他ノードから削除されてしまえば自ノードの評価は＋にならない

　普段滅多に繋がらないクラスタに入ったときも評価は低い
　自分の貢献度を知らないノードに囲まれた時も自ノードの評価は０

【状況その四】

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

この様な場合DL要求ノードはマイナス評価になるので優先度が下がる仕様になるようだが
ノード評価システム上ではDL要求ノード側からするとULノードはULノードが０でない転送を
発生させている以上評価は下がらない

となるといつ終わるともわからない転送さえ発生するようにすればDOMパッチを当てるまでもなく
評価を下げない工夫ができることになる。

〔聞きたいこと〕
このあたりは72案はどのような場合に評価を下げるつもりなのか

まぁ>>758-761
なんか難しいことかいてオナニーしてるけど
ＣＵＩですますのかGUIにするのかGUIはqtにするのかGtkなのか
wxWindowなのかスレッドはpthreadでいいのかとか
そういう実装系の話ができるやつってここにはいないんでしょｗ

>>758
>>759

>【状況その壱】
>・共有する気などまったくなくネットワークの崩壊だけが目的の団体、組織によるノード投入
>　偽評価ノードの大量投入

>【状況その弐】
>・サークル、グループなどある程度の仲間があつまった場合の集団による評価詐称

悪意のあるノードが「組織的に」大量に投入された場合、破綻するのは（クローズで無い限り）どんなシステムでも同じのような気がする。
あと、マイナス評価ばかり返すノードのプラス評価を確認するとつじつまが合わない事がチェックできるかもしれない・・・
（マイナス評価を持っていると言う事はその相手がプラス評価を持っていると仮定できる？）

> 【状況その参】
> 自分に関係のない他ノードの評価の為に無駄なディスク容量を確保してもらえるのか

これは交換では無い共有ソフト全般に言える事じゃないかな。と思う。
nyの現状を見ると、断言は出来ないけれど他人のためにディスク容量を提供してくれるノードの数は少なくなさそう。

>>760
>【状況その四】
>DL要求ノード側からするとULノードはULノードが０でない転送を発生させている以上評価は下がらない

これ、ちょっと意味がわからなかった。
「ULノードが０でない転送を発生させている」てのはどんな動作なんだろう？

>>761
UIの持ち方とか、ライブラリに何を使うかとかは決める必要ないような気が・・・

ホラ釣られた

>>763
んじゃいったい君はなにがしたいの？
書いてることってWinnyや他のP2Pシステムを自分で解釈しただけジャン

＞＞７６４ EncLBj9h
ほら帰れよここは”塵だめ２ｃｈ”だぜ
/.Jかめーリングリスとにでもかえれよ

>>762
【状況その壱】
【状況その弐】
>マイナス評価ばかり返すノードのプラス評価を確認するとつじつまが合わない事がチェックできるかもしれない
大量の偽評価ノードがお互いにプラス評価を流しあっていたらつじつまがあってしまうかも

〔聞きたいこと〕
　これを72案でどう防ぐのか

【状況その参】
>nyの現状を見ると、断言は出来ないけれど他人のためにディスク容量を提供してくれるノードの数は少なくなさそう。
これは断片化したファイルは各ノードに持ってもらえないとFreenetの例を出して説明する人もいるから同意

【状況その四】
>これ、ちょっと意味がわからなかった。
>「ULノードが０でない転送を発生させている」てのはどんな動作なんだろう？

おそらく72案ではULをまったくしないDOMを想定していると思うのだが
少しづつでもULしていればDOMと認定されないのかという事を聞きたくて想定してみた

>>767
>【状況その壱】
>【状況その弐】
>〔聞きたいこと〕
>これを72案でどう防ぐのか

一応上で答えたつもりなんだけど防げないんじゃないかな。
加えて、自分は破綻させる方法は違っても組織的に悪意を持った大量ノードによる破綻てのは72に限った問題ではないように思う。

>【状況その四】
>おそらく72案ではULをまったくしないDOMを想定していると思うのだが
>少しづつでもULしていればDOMと認定されないのかという事を聞きたくて想定してみた

UL帯域を絞ってUL状態を意図的に長くするという感じ？
評価基準を詰めれば何とかなるかも。
申請速度と実際の転送速度差を見るとか、
受信データサイズを区切って評価を更新

nMBまで受けたら初めてプラス評価、
その後また次のnMBを受けるまで時限的にプラス保留。
期待した時間が来てもnMB受けていなければ評価ゼロ。
転送が続いていればnMB受けた時点でまたプラスに戻す

とか。

>>768
大量に、の度合いにもよるだろう。
過半数を正規ノードで占めれるくらい大きければ問題ない、はず。

>>768
【状況その壱】
【状況その弐】
>一応上で答えたつもりなんだけど防げないんじゃないかな。
>加えて、自分は破綻させる方法は違っても組織的に悪意を持った大量ノードによる破綻てのは72に限った問題ではないように思う。
おそらくそうかと
72案では防げないのではともおもうが、その対策を取ったシステムを考えれば防げるかもしれない
DOMが増えるとネットワークが崩壊するという人もいるし
崩壊してしまいそうなくらいDOMとか悪意を持った大量ノード増えた場合を想定した
システムでないといけないでしょう

だからそれについて72案を奨める人にどういう対策を考えているか聞いてみたい

【状況その四】
>UL帯域を絞ってUL状態を意図的に長くするという感じ？
そう、だらだらとDLさせている間に自分のDLを完了させて
その後キャッシュを削除もしくは転送を停止、結局完全な物は相手にDLさせないノードを想定してみた

>評価基準を詰めれば何とかなるかも。
>申請速度と実際の転送速度差を見るとか、
>受信データサイズを区切って評価を更新うんぬん

72案ではULをまったくしないDOMだけを想定しているわけではなく
nMBかまで受けたら初めてプラス評価するという案なのかな
nMBもないファイルのやり取りの場合もあるしどのくらいの受信があれば
評価するシステムにするつもりなんだろ

>>768
〔聞きたいこと〕
　これを72案でどう防ぐのか

というのは｢72案に問題点があるならご指摘どうぞ｣の方へ向けての質問なので
>>768へ質問しているわけではない

winny2から開発環境がC++ Builderに変わったそうで
ってことはkylix3を使えばLinuxにも簡単移植できるね。

>>772は馬鹿

>>773
お前も馬鹿（ｗ

>>772
　言語環境をそろえれば、OS環境の問題もないと想っている段階で馬鹿
>>722
　なぜかの説明もしないで、荒らしているだけなので馬鹿
>>773
　同上

　このように、ノイズが多いことが2chが共同の開発の場として向かない
ことを示している。

>>775
馬鹿は藻前では?

kylix3を使えば「比較的」簡単にLinuxに移植できる

47氏ならそういうの無くてもほいほい移植できそうだなぁ・・・

kylix3で移植できたとしても
VCLのGUIだけでしょ
Winsockまわりは書き直さないといけないし
ファイルのオープンクローズ、スレッド
はWINとは違うんだから
こうなりゃなるべくWINEでちゃんと動くように47氏に設定してもらったほうが楽
>>776
禿げ同

>>758-761
とても分かり易いご指摘ありがとう。


>>758
>【状況その壱】
>・共有する気などまったくなくネットワークの崩壊だけが目的の団体、組織によるノード投入
>　偽評価ノードの大量投入

ノード評価時の優先方法を相対的な帯域確保や待ちノードの順位優先で行う。
これならいくらネットワーク全体にマイナス評価を撒いたとしても、
標準ノードの基準値が下がるだけで相対的には正常な評価を出来る。

転送や待ちノードが一つもない場合、評価の低いDOMノードにUP帯域を100%喰われる可能性もあるが
転送ノード同士の関係で完全に収束するので問題ない。


>>759
>【状況その弐】
>・サークル、グループなどある程度の仲間があつまった場合の集団による評価詐称

もう少し考えてから書くので少しお待ちを。

ただ完全なDOMであっても1%未満(1000人程度?)など小規模な詐称、回線の圧迫であれば
現在のWinny同様あまり問題ないだろうと思うけど、より良い案や解決策があればいいね。

>>759
> 【状況その参】
>自分に関係のない他ノードの評価の為に無駄なディスク容量を確保してもらえるのか
>またどんなに評価が高くなろうと、その情報を他ノードから削除されてしまえば自ノードの評価は＋にならない

他ノードの評価のためのデータ保持は負担が軽微であると考える。
他ノードのプラス評価を削除することはメリットが希薄だと考える。
よってどちらも懸念すべき事項ではないだろうと考えられるはず。

>普段滅多に繋がらないクラスタに入ったときも評価は低い
>自分の貢献度を知らないノードに囲まれた時も自ノードの評価は０

評価を知らないのは全くお世話したことのない集団なので優先順位が低いのは諦める。
ある程度長時間接続する場合は次第に評価があがっていく。

また保持してあるノード情報から複数のクラスタを速やかに切り替えたり、同時に接続出来るようにする。
どうしても常に高速でダウンしたい場合はあまり繋がないクラスタ側にもいつもUP帯域を配分しておく。


>>760
>【状況その四】
>DL要求ノード側からするとULノードはULノードが０でない転送を発生させている以上評価は下がらない

10MBもしくは10MB以下のファイル一つを転送し終えた時点で評価を一つ上下する。
これでUP帯域を絞って評価を稼ぐことは出来ない。
分かりにくそうなのでそれらしい数値を入れたつもりだがどうだろうか。

72案で優先ノードになるための改造方法を考えてみました

　アップロードしてくれるノードが他のノードから受け取る評価値によって自分のノードの
優先度が決まるため、ダウンロードするノードでは優先度を変更することが困難としている
のが72案だと思われますが、各ノードが持つ評価値はどのようにして設定されるのでしょう？

　1つのパターンとして「ダウンロードさせてもらったときにそのノードに対する評価値を上げる」
と、云うことだとするとちょっとした細工が出来ます。

　ダウンロードさせてもらったときに、自分の保持する評価値を上げない。
　そうする事によって、相手の評価値は上がらないので、相対的に自分の評価値が下がる
ことはない。

また、
　ダウンロードをリクエストしてきたノードの優先順位を、そのノードを知るすべての評価値の
平均でとるとしたら、知らないノードへの問い合わせであっても0を返すことでそのノードの
評価値を下げることが出来る。
　ダウンロードをリクエストしてきたノードの優先順位を、そのノードを知るすべての評価値の
最大値でとるとしたら、2つ以上のノードで徒党を組むことによって評価値を操作することが
出来る。　

　あと、気になるのは評価の問い合わせをするノードの範囲の指定方法。

　とりあえず、こんなところ。

>>779
【状況その壱】
>ノード評価時の優先方法を相対的な帯域確保や待ちノードの順位優先で行う。
相対的な帯域確保がどうなっていたらどのように評価するのか、また待ちノードの順位とはなにか

>標準ノードの基準値が下がるだけで相対的には正常な評価を出来る。
評価を下げられなかったノードと下げられたノードが出る恐れがある
｢相対的には正常な評価を出来る｣と断定できる根拠はなにか

>転送ノード同士の関係で完全に収束するので問題ない。
何がどういう風に完全に収束するのか

よくわからないので以上の点を詳しく説明してもらえないかな


【状況その弐】
大規模な詐称の場合についても考慮された方がいいかも

>>780
【状況その参】
>他ノードの評価のためのデータ保持は負担が軽微であると考える。
>他ノードのプラス評価を削除することはメリットが希薄だと考える。
>よってどちらも懸念すべき事項ではないだろうと考えられるはず。
評価を消された場合についても検討しておかないとDOMを排除する為の評価システムそのものが
成り立たなくなりますよ

>評価を知らないのは全くお世話したことのない集団なので優先順位が低いのは諦める。
>ある程度長時間接続する場合は次第に評価があがっていく。
評価が消えないという前提にたったもので前提が崩れた場合は評価があがっていくかどうか不確実では

>また保持してあるノード情報から複数のクラスタを速やかに切り替えたり、同時に接続出来るようにする。
>どうしても常に高速でダウンしたい場合はあまり繋がないクラスタ側にもいつもUP帯域を配分しておく。
72案はDOMを排除する為に行われる評価であると思っていたのですが
評価をあげるたりするのは常に高速でダウンしたりする為なのですか

【状況その四】
>10MBもしくは10MB以下のファイル一つを転送し終えた時点で評価を一つ上下する。
>これでUP帯域を絞って評価を稼ぐことは出来ない。
UP帯域を絞ったノードの想定は評価を稼ぐ為ではなく評価を下げられないようにする為に
少しの転送を発生させる工夫をするDOMを想定しているのです

ところで問い合わせと応答によって帰ってくる情報を元にDOMを排除する72案は
最終的にDOMだと判断した場合はそのノードをどうするシステムなのかも回答をお願いします

>>783
　表現は悪い気がするが、現在のMXのように、リクエストに対するキューを設け
その中からダウンロードを開始するリクエストを選択すのに評価値を使うということでは
ないでしょうか。

よって
>ところで問い合わせと応答によって帰ってくる情報を元にDOMを排除する72案は
>最終的にDOMだと判断した場合はそのノードをどうするシステムなのかも回答をお願いします
に関して云えば
　リクエストが入っていても評価値が低いノードは、いつまでたってもダウンロードできなくなる。

　他のリクエストが入っていなければ、自動的にダウンロードが始まるため
>>779
>転送や待ちノードが一つもない場合、評価の低いDOMノードにUP帯域を100%喰われる可能性もあるが
>転送ノード同士の関係で完全に収束するので問題ない。

　の様な問題が起こるのでは？

リクエストを入れているのにいつまでたってもダウンロードさせんノードって評価が低くなりそうだな。

>>785

　他のノードにはアップロードしているのだから、そのノードの評価値が下がることはなく、このシステムなら
評価は上がるでしょう。
　自分のノードがアップロードをしていれば評価値が上がって、そのような状態にならなくなるわけだから
もし、自分のノードがそういう状態に置かれたとしたら因果応報ってやつで、そのノードをうらむのは
筋違いってことでしょう。

　ただし、評価システムが正常に動作している場合に限る話ですが。

・DL要求が届くのはどういう場合なのか
　検索リンクをたどってきた問い合わせに対して目的のファイルの場所を知っていると応答したノードにDL要求が届くので
　DL要求が届いたノードというのはそのファイルの場所を知っていて転送できるノードという事になる

・自ノードがDOMだと判断されて評価が下がるのはどんな場合なのか
　ファイルを転送できるはずなのに転送しない場合

・自ノードが相手ノードをDOMだと判断してDL要求ノードの評価を下げ転送を止めた場合
　相手ノード側はからするとファイルの場所を知っていて転送できるノードであるにも関わらず
　転送しないノードと判断される事になる

　これはどこからかDLして手に入れたファイルを持っているのに他のノードからのDL要求には応じないDOMの動作そのもの
　DOMを排除する為に転送を止めたのにUPしないノードとして自らがDOMと評価されかねない

　DOMを排除するほど自分の評価もDOMによって下げられててしまう事になるが
　これはDLさせたかどうかを判定材料とするシステム上では避けられない

・自ノードの評価が上がる場合はどんな場合なのか
　これはUPした場合になると思われるが
　共有させてやるほど自ノードの評価が上がっていくシステムなら
　DOMノードだろうと正常なノードだろうとかまわず共有させた方が自ノードの評価的には得になる
　自分がDL要求を出した時にUPした時の評価が他のノードに残っているなら他ノードから最大限優遇されるだろう

　そうなると自分が最大限優遇される為には他ノードに問い合わせる処理を省いて
　無条件に共有させた方がいいということになるので自分の評価を上げるのに最も有利なのは
　相手ノードがDOMかどうかを判断せずUPした場合ということになりそうだ
　
　DOMを排除しつつ自分は優遇されるようなシステムを目指しているのかもしれないが
　現時点ではかなり矛盾したシステムになると考えざるを得ないのでは

72案の根幹に関わる問題点
・評価を消される問題
・評価を操作される問題

システム設計は都合の良い条件だけを元におこなってはいけない
最悪の事態を想定してそれに耐えられるものでなくてはならない
その為にはできるだけ想定外の事態というものが無いように
都合の悪い条件も考慮して設計をおこなう必要がある
それにより想定外の事態に陥ることを防ぐ事が出来る

見通しの甘い設計は簡単に想定外の事態に陥る
万が一最悪の状況が起きた場合でもそれが設計の段階から想定していた状況であり
対処されているシステムは堅牢です
簡単には崩壊しない

72案の評価法が評価を消される問題に完全に対応できないのであれば
他ノードに評価を保存してもらうという設計に無理があることになる。
また評価を操作される問題が解決できないのなら他ノードによる評価という
72案システムそのものに問題があることになるので他の評価法を考えるか
評価システムという考えかたそのものに問題が無いか考えなくてはいけない

72案の問題点はダウン開始が異様に遅いだろうということと
オープンソースだと匿名性なさそうなことだな。

DOMを防げる可能性があるってだけで他の効率も匿名性もだめになると思う。

>>784
完璧な補足どうもです。


>>782
>評価を下げられなかったノードと下げられたノードが出る恐れがある
>｢相対的には正常な評価を出来る｣と断定できる根拠はなにか
評価を下げられたノードが出た場合、下げられなかったノードが相対的に優遇されることになる。
つまりネットワークの効率を悪化させ崩壊させることは出来ない。

よってDOMを目的としない【状況その壱】に偽評価を流すメリットがない。
それ以外の状況があるならまたどうぞ。

>>783
>評価をあげるたりするのは常に高速でダウンしたりする為なのですか
これはDOMとUPしているノードとを区別する為です。

>UP帯域を絞ったノードの想定は評価を稼ぐ為ではなく評価を下げられないようにする為
DLしているのにも関わらず評価を下げられないことも含めて稼ぐと書きました。

>>783
>評価を消された場合についても検討しておかないとDOMを排除する為の評価システムそのものが
>成り立たなくなりますよ
>評価が消えないという前提にたったもので前提が崩れた場合は評価があがっていくかどうか不確実では
1MB程度のディスク容量を稼ぐことや個人的にUP側の評価をプラスしないことが、
評価情報ファイルをわざわざ削除することや
正規版とは別にプラス評価を保持しないWinnyを導入する苦労に見合ったメリットとは思えない。

どのような不正ノードにも言えることだが、
不正することのメリットが無ければ不正ノードにはならない。

メリットが大きければ大きいほど不正ノードの比率は増える。
その中でもDOMになれることは最大のメリットだろうね。

よって対策案が必要になるわけだが
どのような対策案でも多くのノードは正常であるということを前提としてしか成り立たない。
メリットが極めて少ない不正ノードが大多数を占めるような場合は想定する必要がない。

自ノード以外の全てのノードが検索キーを遮断したら
自ノード以外の全てのノードが捏造ファイルしか共有していなかったら
自ノード以外の全てのノードがDOMパッチを当てていたら

と考えるようなもの。

【状況その弐】など想定出来る現実的な問題については対策する必要があるだろうが、
検索キーの遮断を防げないからといってそのネットワークが実用に耐えられないわけではない。

もちろん何も犠牲にせずに解決出来る問題であれば対策すべきだが
評価情報を保持しない極少数のノードの存在が72案を支持できない理由には成り得ないと思っている。

>>790
>【状況その壱】
>・共有する気などまったくなくネットワークの崩壊だけが目的の団体、組織によるノード投入
>　偽評価ノードの大量投入

>評価を下げられたノードが出た場合、下げられなかったノードが相対的に優遇されることになる。
>つまりネットワークの効率を悪化させ崩壊させることは出来ない。
実際の実情とずれた評価情報に流通することによって評価システムの信憑性がなくなります

>よってDOMを目的としない【状況その壱】に偽評価を流すメリットがない。
ネットワークの崩壊だけが目的の団体、組織とは何かについて具体例を出すまでもないでしょう
P2Pネットワークそのものがなくなればいいのにと思っている団体、組織は存在します
またP2Pネットワークがなくなることのメリットはそれらの団体にとって多大なメリットがあるかと

>これはDOMとUPしているノードとを区別する為です。
DOMを排除する為にUPしないノードとの区別はどうやってしますか
１回のUPが完了して評価が上がるまでの時間あたりの回数とオープン後増えると思われる多数のDOMからのDL要求に対して
UPをせずを排除する度にさがっていく時間あたりの評価の回数はどちらが多いと思いますか

>1MB程度のディスク容量を稼ぐことや個人的にUP側の評価をプラスしないことが、
>評価情報ファイルをわざわざ削除することや
>正規版とは別にプラス評価を保持しないWinnyを導入する苦労に見合ったメリットとは思えない。
個人的にUP側の評価をプラスしないことのメリットは>>781がかかれているようです
もちろんDOM側にメリットが生じる例のようですので実行する人が出てくる恐れは充分あります
>>791
>どのような不正ノードにも言えることだが、
>不正することのメリットが無ければ不正ノードにはならない。
メリットがある人を想定した設計にしたほうがいいのでは
想定していなくてなにかあとで問題がおきるより何か問題がおこった時に
｢その対策は織り込みずみです｣のほうがいいとおもうよ

>ただ完全なDOMであっても1%未満(1000人程度?)など小規模な詐称、回線の圧迫であれば >>779
>評価情報を保持しない極少数のノードの存在が72案を支持できない理由には成り得ないと思っている。 >>791

72案が成り立つ場合の想定を1%未満の詐称とか極少数の保持しないノードしかでないからと想定するのもいいけど
1%以上の詐称や多数の保持しないノードが出た場合をまったく想定してみないという事はそれらの事がおこった場合の
対策を考えていないという事になる
案としては実装する前に不具合が予想される時点で不完全なものになると思うのだが

＞個人的にUP側の評価をプラスしないことのメリットは>>781がかかれているようです>>792
これを見て思ったんだが自分がプラスしないだけなら十万分の一程度しか優待されないだろ
かな〜り意味がなくないか？個人的ではなく組織的にやるなら別だろうけどねぇ

＞案としては実装する前に不具合が予想される時点で不完全なものになると思うのだが>>793
つまり>>791で言ってるのはGnutella型一般に言える検索キーの遮断を防げないことや
新規のファイルの流入を許す限り捏造ファイルの共有は避けられないが
これも不具合や不完全と言えるのかってことでは
1%未満とか極少数じゃなくDOMが10%になったりや評価しないのが半数になっても大丈夫だと思うけどね
さすがに半数以上が嘘ついてDOMになったらやばいけど(藁

なんだお前らまだやってたのか

>>793
　意図的に、高い評価値を応える2個1組のノードがあれば、
　それぞれのノードは優先ノードになれるとも考えられます。

　他のノードの評価値を落として、自分を優先するよりこっちのほうが
よりお得といえそうだ。

>>791
>メリットが大きければ大きいほど不正ノードの比率は増える。
>その中でもDOMになれることは最大のメリットだろうね。
DOMになれることが最大のメリットであるならDOMとして排除されないような改造をする事は
DOMという行為を成立させる上で必ずおこなわれるメリットのある行為でしょう
自ノードの評価が下げられる事により自分が排除されかねないシステムなのに
わざわざ相手の評価を上げてやるDOMはいないのでは

DOMかどうかを判断する時の基準になる評価情報をDOM自身が消したり操作したりできるという
設計上の大穴が存在する以上０DOMパッチと共に０評価パッチが出回るのは想像に難くない
そうなるとDOMの数だけ評価を操作したノードが出てくるわけで
オープンソース化によりネットワークが成り立たないほどのDOMが増える事を想定しているのなら
同数の評価を操作するノードが出てくる事も想定しないとだめでしょう

評価が成り立たずDOMを排除できないのであれば
効率を落としてまで72案を取り入れる『メリット』はないですね

>>796
１回のUPが完了したら評価が上がるシステムであれば小さなファイルを2個1組のノード間で
高速になんどもやり取りして実績をあげれば瞬く間に最大評価に出来るかもしれない

つまるところDOM側で評価を操作できる時点で72案は終わってるような気が

>>797
だったら検索システムはどうするよ？
流れてきた検索キーに対する結果を減少したり遮断したり偽装すりゃ
キーを流した元ノードがDLし難くなる分少しは自分がDLしやすくなるだろ
だからといってほとんどのノードがそういう改造をするか？
相手の評価を保存しないのも誰か一人に評価を上げてもらうのもいっしょ
やればほ〜んの少しだけ優待されるけどそんな目にも見えない程度なら誰もやらない
それに今のwinnyのキャッシュシステムも同じことが言えるよ
不要なキャッシュを常に削除してればUPはなくなるけど
ほとんどのノードはそんなことをやっていないからwinnyはとっても使いやすいファイル共有ソフトのまま
大量に不正ノードが発生した時に運用できないことが不完全だというなら
これも設計上の大穴と言うのかねぇ
逆に72案ならこの手の不正ノードを抑制出来るはずだよ

他に考えるべき案はないんだしもっと詰めていってもいいと思うんだけどな
「終わってるような気が」とかあなた一人の考えで終わってるかどうかの判断されても仕方がないよ
それとも終わったことにしておいて他に何かこのスレで考えたいことでもあるわけ？
まだ議論も始まったばかりだし俺は「全然終わってない気が」とでも妄想しておこうかな
72案を採用した場合だけほとんど価値のない不正行為をする香具師がわっさわっさと出てくるってのは納得いかない
まるで今のwinnyに対するDOMパッチくらい価値があるみたいに言ってるし
このスレを見てるとなんか議論して可否を検討するよりも72案を潰したいだけの意図が見えて嫌だな

>>798
さてそろそろ72案の問題点にご指摘してもループするだけですので
72案の問題点について考えるスレから
Winnyのオープンソース化を考えるスレに話題を進めたほうが良さそうです

>>799
これがループか(藁
ループしてるのはあなただけだと思うよ
説明してるのには目もくれず(理解出来ないだけ？)
根拠も反論も無しに同じ文言を繰り返す
おまけにWinnyのオープンソース化を考えるスレで
72案を検討してる理由すら分かっていないようで
どうやら議論を混乱させて72案を潰したいだけってのが正解みたいだね

なんだ
追いかけてるのが自分の尻尾だと気付かない馬鹿が延々グルグル廻っている
隔離スレッドはここだったのか。

>>799
47氏がオープンソース化する上で必要と言っている
現在のnyにないDOM対策の数少ない素案を検討すること以上に
このスレで考える必要があることをどうぞ。

>>754
dasoudesu

>>801
禿同。
Linnyスレから見てるけど>>799には久しぶりに笑わしてもらったよ。

昔はLinnyとかあったね。
個人的にはあっちのほーが好きだな

>>805
コンセプトは全く「新しいファイル共有ソフト」だったね。
あれの欠点は535氏が47氏じゃなかったことか(w

>>798
　評価値の使い方をどのように行うかが不明なので、確定した話ではないのですが

　帰ってきた評価値の最大値を優先順位の設定のために使うという使い方を下場合、お互いに対して
最高値の評価値を返す2つのノードがあれば、その2つのノードは最高の優先ノードとなりえます。
　ちょっと上がる程度なら改造はしないといわれますが、これなら改造に値する効果といえるのでは
ないでしょうか。

　また、ちょっとのことで…というのならばSafeNyで騒いでいるのをみると、ちょっとしたことでも出来るのならば
やりたいと思う人間がいる例になるのではないでしょうか。Port0に帯域を取られるからと一生懸命細工しています。

　Winnyで不要なキャッシュを削除の話ですが、現状でキャッシュを消すという処理をするためには、ユーザーが
操作をしなければなりません。しかし、プログラムを改造することが出来れば、ダウンロードが完了し変換が終わった
後にそのキャッシュを消すような機能を追加すれば、そのノードについては不要なキャッシュを持たなくなるので
効率が良くなることでしょう。一度の改造で面倒なく当人にとって不要なキャッシュを消せるとしたらどれほどの人が
その改造を行いたいと思うことか。
　もっとも、多数のノードがその改造を行えば結局のところソースと各ノードの1対1の転送が基本になってしまい、
全体としての効率はひどくおちることになるでしょう。

でもって、72案支持者に質問

　Aというノードへの評価値を最大値で返すBというノードと、
　Bというノードへの評価値を最大値で返すAというノードが、
同じクラスタ内にいた場合に、評価が正当に行う方法はあるのか？

　「改造されたらどうするか」という話に対して、「改造なんかする奴居ない」で返せばループもするわな。

>>797>>799に賛同です。

>>807
評価値の使い方をどのように行うかが不明なのに話題を変えることに賛成ですか？
質問があるのに話題を変えるんですか？
矛盾していると思うんですが、いったいこのスレで何を考えたいのですか？

>>808
　評価値の使い方で、問題が解決されるならば、どのように評価値を使うのかを
答えて欲しいのですが。

　答えられないようなら、というか答えている人もいないようなので、72案はダメだろう
と思うだけです。

　答えられるなら、72案は進化できると思いますが、答えてくれますか？>>808

>>809
一度も通信をしたことのないノードにも平均評価値を返すことは前提にされてませんよね？

一応書いておきますが、
72案はあるノードからDL要求があった場合に複数のノードに問い合わせるわけですから、
例えば100ノードに問い合わせるとすれば

Aというノードへの評価値を最大値で返すBというノードと、
Bというノードへの評価値を最大値で返すAというノードが
あったとしてせいぜい1%の評価を左右することしか出来ないですよ。

常に最高の優先ノードになるためには同じクラスタにいる全てのノードに
評価値を最大値で返してもらう必要があるでしょう。

つまり個人的に評価を詐称するのはほぼ無意味です。

>>807
>また、ちょっとのことで…というのならばSafeNyで騒いでいるのをみると、ちょっとしたことでも出来るのならば
>やりたいと思う人間がいる例になるのではないでしょうか。Port0に帯域を取られるからと一生懸命細工しています。
これが本スレなどで騒がれているのは以前からUPノード側にポート0に対する害悪感情があったから。
何故、害悪感情があるかと言えば転送を行わないなどポート0はあまりネットワークに貢献しないから。

つまり騒いでいるのは普段からUPしていて共有ネットワークを正常に維持したい者達で、
己のために評価を詐称することや、DOMになることとは全くの別物。

>Winnyで不要なキャッシュを削除の話ですが、現状でキャッシュを消すという処理をするためには、
>ユーザーが操作をしなければなりません。
>一度の改造で面倒なく当人にとって不要なキャッシュを消せるとしたらどれほどの人が
>その改造を行いたいと思うことか。
残念ながら簡単な外部ツール（広範には出回っていないが）を使えば一々操作しなくても可能だよ。
キャッシュ変換されたDownフォルダに存在するファイルのサイズを調べて、
それとほぼ同じサイズを持つキャッシュをキャッシュフォルダから削除すればいいだけ。

しかしこのようなツールが騒がれず、一般に出回らないのは何故だろうか？
それもまたネットワークを正常に維持したいと思っているものがほとんどだからだろう。

>>797
根拠もなく評価を保持しない者が極少数であるとか、
72案を詰める必要があると言っているのではないよ。

こうした現在のWinnyの状況も踏まえて
大半のノードは目にも見えないようなメリットのために不正ノードにはならないと考えているから。

どちらが正しいかは出来るだけ多くの根拠を示した方が判断しやすい。

それと問題点を指摘して議論することで評価方法や評価基準も少しは具体的になった。
>現在のMXのように、リクエストに対するキューを設け
>その中からダウンロードを開始するリクエストを選択すのに評価値を使う
>10MBもしくは10MB以下のファイル一つを転送し終えた時点で評価を一つ上下する。
決してループしているわけではない。

また72案がどういった設計なのか個々に思い違いをしている部分が多い。
これのより良い解釈を発言してもらうだけでも価値はある。

もちろん評価を問い合わせる範囲はどの程度か、何段階の評価をするのか、
本当に10MB程度で評価を上下していいのか、【状況その弐】はどの程度の規模で効果が出るのか、
予測される範囲を上回るほど【状況その弐】が増えた場合は本当に何の対策もないのか、
他にも問題点はないかなど考えるべきことはあるだろう。


しかし議論もせず「72案は終わってる」とか「72案はダメだろう」と勝手に決め付けるのは随分乱暴ではないかと。

　すこしは前進しそうなので、もうしばらく

>>810
　評価値を100のノードに聞きその平均値で優先度を決めるので、個人的に評価を詐称することは
無意味とのこと、そこまでは了解しました。ただ、この方式にも問題点はあると思いますが、その前に
問題点を考えるための前提条件を詰めたいと思います。

　「72案では、ノードの特定を如何にするのか」。

　評価を行うためには、ノードの特定が必要です。
　IPアドレスを使う？ニックネームをつける？どのようにして解決しますか？

>>811
　外部ツールで可能。確かに可能です。しかし誤爆もあるでしょう。ま、誤爆の問題はおいておいて

　流れない理由としては、「多数のノードがそういったツールを使うことによってネットワーク自体が
崩壊すれば、流した本人にとっても利益にならない。」からじゃないかと思います。

　逆にいえば、ネットワークを崩壊したい人間はそういったツールを、便利なツールとして流すことも
出来るわけです。アメリカでは共有フォルダーにウイルスを入れてネットワークを崩壊させるなんて
ことも考えているぐらいですから。

　ユーザーに理性に過度に期待するより、攻撃に耐えられるシステムを構築することが必要だと
思うわけです。

問題点を指摘しているのはDOMを排除できるシステムを考える為であって72案を潰すためではない
72案が問題点に対処できるのなら詰めていくのもいいかもしれないが指摘した問題点に72案では構造上対策が取れない

72案の他ノードによる評価システムで命綱なのは評価情報であるが評価情報を撹乱されてしまえば評価システムは崩壊する
そういう穴がある以上評価情報を意味のないものにする為の改造を施されたバージョンが配布される恐れはあるし
大多数がそのように評価を改ざんする事態になったとしても72案ではそれを止められない＝DOM対策の失敗

72案を今後いくら詰めていってもあいている穴に対処する方法のない72案ではDOMを排除できない
この穴は他のノードの評価を元にDOMを判別しようとする事から来る穴なので
DOMの判別方法を他のノードの評価を元にしない別の方法に変えれば
72案の穴である
・評価を消される問題
・評価を操作される問題
というものは自然と消滅する

DOMを排除する事が一番の目的であるならば穴のなさそうな次のDOM判別法の案を出して
その案にまた別の問題が発生しないかを検討をしていくほうが建設的では

　　┌───────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(もし捏造対策がもう一歩進めば、自動擬似交換を模索できるかも…)

何度も言うがソース公開したらDOM対策は無理。

　あ　き　ら　め　ろ

>>816

　完全なDOM対策は無理でしょう。しかし、「こんなことならMXでDOMったほうがいいや」ってぐらいの
DOM対策は可能です。
　DOMらなければ「Ny使うより便利」ってことも可能です。

　単純に「無理」というのは思考停止。
　有効に機能するDOM対策を考えているスレッドに考える気もない人間は要らない。
　不可能だというのなら、出ている案の穴を指摘するぐらいのことをするべきでしょう。
　めんどくさいとか、暇がないなら、いちいち書き込まず無視していればよし。

最近のDOMerの動向
　72案に穴がることをしって、72案が採択されるように働きかける。
　72案の穴をふさごうとする行動に関して、改造はない「はず」といういけんでお茶を濁そうとする。
　72案を進化させようとする動きに対して、「DOM対策は無理」（DOMerの合言葉)で開発を止めようとする(藁。

あと何年くらい議論してるんだろうね。[w

>>813
>ユーザーに理性に過度に期待するより、攻撃に耐えられるシステムを構築することが必要だと
>思うわけです。
>>814
>DOMを排除する事が一番の目的であるならば穴のなさそうな次のDOM判別法の案を出して
確かに、匿名性を保ったまま100%DOMを排除出来て、Freenetには負けない効率を保てる
完全無欠な案が出てくれば是非検討したい。全く72案にこだわる理由はないからな。

だがそんな案は出ていないのだから無いものねだりしても仕方ないだろう。

どういったシステムであれ大多数がDL効率を最大にする不正ノードであれば成り立たないのは事実。
WinMXもGnutellaもFreenetもWinnyも同じこと。
それは評価システムに限ったことではない。それを受け入れないのか？

また少なくとも72案は現Winnyでは有効なキャッシュの削除を抑制する効果があり、
評価方法によっては捏造ファイルを多数流しているノードを周囲に警告することも出来る。

出来る限り不正を防げるような方法は考えるべきだし、もちろん考えているが、
どんな案だって大多数のノードが可能な限りDOMに徹するような状況だけを想定したら話も進まない。

>>819
>どんな案だって大多数のノードが可能な限りDOMに徹するような状況だけを想定したら話も進まない。
そもそもオープンソース化したら大多数のDOMが現れてｎｙのネットワークが崩壊するような状況を
想定しているからDOM対策が必要なんでしょう？

大多数のノードが可能な限りDOMに徹するような状況を想定せず小規模なDOMしか発生しない状況しか
想定しないのであればそのままオープンソース化すればいいということになってしまうよ

多数のDOMが現れる事を想定しているからこそ情報を改修する沢山のノードを想定するわけだし
また違う案が出たとしても多数のDOMが現れる事を想定して問題点を指摘することになると思う

1%未満とか小規模とか極少数のノードとか想定しないのであればDOMの存在もその程度と想定してはどうですか
DOM対策など考える必要がなくなりますし。。。

>>819

　72案は、絵に書いた餅としてはとても美味しそうですが、絵にかかれていない部分がどんなものか
知りたくて、話をしているつもりなのだけど。

　現状で完全無欠を期待しているわけではなく、72案にどれほどすっぱい部分があるのか考えておく
必要があるだろうということ。

　72案のすっぱさが許容範囲であれば食べるでしょう.。
　現状としては、72案を否定するわけではなく、72案を洗っている状態。
　もちろん、「確認なんかしてないで、甘いんだから喰え」って話ならきっぱり否定しますけど:-)

　で、ノードの特定の方法はどうするのでしょうか？

>>820
>そもそもオープンソース化したら大多数のDOMが現れてｎｙのネットワーク
>が崩壊するような状況を想定しているからDOM対策が必要なんでしょう？
それはWinnyをそのままオープンソース化した場合だろう。
今のままなら本当にDOMパッチ一つでアップ0のダウンし放題ということが可能だから、
何処かからパッチを落として当てるだけの労力に比べて極めてメリットが大きい。
配布を目的としないならDOMパッチを当てない意味がないほどに。

そこで72案は自ノードの改変だけでは左右できない他ノードによる評価というものを取り入れた。
これによりただアップしないだけのノードはダウンしずらくなる。
もちろんここで評価の詐称というのも考える。

まずノード単独での詐称は請求された相手の評価を常に最低で返すということが考えられる。
しかし常に100程度のノードに評価を請求するシステムにおいて
自ノードが評価請求先ノードの1/100に入った場合、
何処かの誰かが自分ではない可能性の高い他の誰かより1%ダウンしやすくなるだけ。

これではわざわざパッチを当てるメリットすらないだろう。

そこで2ノード以上を使った詐称が起きるわけだが少人数であれば>>810のように簡単にはいかない。

またこの時点で単独で行えるDOMと複数のノードとの協力が必要になるDOMでは労力が全く違う。
評価を詐称する場合には相手方のIPアドレスが必要になるだろうが、
それを固定IPなりDDNSなり、定常的に追っていける設備や知識があるものがどれだけいるだろうか。

どんなに優れたパッチが出回ろうと、ここでほとんどの初心者層は手が出ない。

もちろん知識もあって集団で行動出来るグループが詐称することも考えられるが。
Winnyをそのままオープンにした場合と同じように考えられても困るよ。

>>821
>「確認なんかしてないで、甘いんだから喰え」
「確認なんかしてないで、すっぱいんだから喰うな」
という話になっていたので否定していただけです。

こちらも無理して喰う気はさらさらない。
よりおいしそうな餅があればすぐそっちに飛びつくつもり。
無いからじっくり確認中。

>で、ノードの特定の方法はどうするのでしょうか？
以前議論した時の結論ではIPアドレスを使う方が有力ということになってたのでは？
ずっとそのつもりで書いてました。
これもいくつか問題ありそうだけど。

>>822
まず1/100という小規模の詐称を想定していますが1%の本人の詐称以外から帰ってくる
その他の99%の評価に信頼性がない可能性が出る事が問題になるのです

信頼性のない改修された評価が返ってくる事を防げないし信頼性のある情報かどうかも確認もできない72案は
DOMでない者をDOMと評価したり正常なノードをDOMと評価したりする恐れが捨てきれません

>どんなに優れたパッチが出回ろうと、ここでほとんどの初心者層は手が出ない。
DOMできる優れたパッチがでればパッチを当ててあるバージョンとして配布するものはすぐ出てくるでしょうし
そういう情報はすぐに広まるのでパッチを当てられない初心者層もすぐに使い始めると予想できます

つまり起こらない事を前提とするのではなくおこった場合でも大丈夫なシステムでなければだめじゃないのか
という事なのですが

同じような意見として>>813が
>攻撃に耐えられるシステムを構築することが必要だと思うわけです。
と書かれていますがまったく同意です

>Winnyをそのままオープンにした場合と同じように考えられても困るよ。
もちろんそのままではオープンに出来ないからこそ対策を考えているのだし
その対策として出てきている72案について問題点を指摘しているわけですが

>>824
>DOMできる優れたパッチがでればパッチを当ててあるバージョンとして配布するものはすぐ出てくるでしょうし
>そういう情報はすぐに広まるのでパッチを当てられない初心者層もすぐに使い始めると予想できます
かなり勘違いさせてしまったようだけど

>評価を詐称する場合には相手方のIPアドレスが必要になるだろうが、
>それを固定IPなりDDNSなり、定常的に追っていける設備や知識があるものがどれだけいるだろうか。
>どんなに優れたパッチが出回ろうと、ここでほとんどの初心者層は手が出ない。
822で初心者層と呼んでいるのはパッチすら当てられない者ではなくて、
クライアントとしてDDNSの運用が出来ない者。

これで大多数が不正ノードになれない理由の一つを理解してもらえるかな？

100ノードに問い合わせとか言ってますが問い合わせ頻度はどうなるのでしょうか？
DL開始時だけなら、DL始まったのを確認してからUPを切断してDOMになれる。

>>825
>>評価を詐称する場合には相手方のIPアドレスが必要になるだろうが、
　・
　・
>これで大多数が不正ノードになれない理由の一つを理解してもらえるかな？

問い合わせがあった時にそのIPアドレス（ノード）の情報に対して詐称評価を応答する時
IPアドレス（ノード）の情報は問い合わせに含まれているのでその時点でわかりますが

理由の一つについて解答しましたが他に無いようでしたらそろそろ次に行ってもよろしいか

>>826
UPを切ってDLばかりしていれば評価が下がる。
それでも大きいファイルの場合は時間で区切るか、データ転送量で区切るか別にして、
再問い合わせは必要だろうな。

>>827
勘違いでなかったなら構わないよ。

>>827
これがループか(藁
ループしてるのはあなただけだと思うよ
説明してるのには目もくれず(理解出来ないだけ？)
根拠も反論も無しに同じ文言を繰り返す
おまけにWinnyのオープンソース化を考えるスレで
72案を検討してる理由すら分かっていないようで
どうやら議論を混乱させて72案を潰したいだけってのが正解みたいだね

>>828
再問い合わせの間隔は？
あまり問い合わせが多いと問い合わせだけでずいぶんとトラフィックが流れそうだが。

漏れは無視されたままなんでしょうか
ID:iw2FAeVQ さん、>>815の解法はありますか？

>>822

　ノードの特定に使用されるものはIPアドレスもしくはドメイン名、および修飾するデータ(ポート番号など)ということでよしとして、

　さて、詐称の方法です。

１．あるノードAがノードBに対してダウンロード要求を発行します。
２．ノードBはノードA以外のいくつかのノードに対して評価値を求めます。求めるノードは、
すでに知っているノードリストにあるノード。
３．求められたノードは適当数同じ要求を他のノードにリレーします。その総数は100程度とする。
４．評価値を求められたノードは、その評価値をBに対して返す。
５．ノードBは戻ってきた評価値の平均をとるなりして最終的な優先順位をつける。

　ここまでが正常な動作。

　さて、2の段階で、「Aに対する評価をBに返してほしい」と依頼を出すわけですが、実際に問い合わせを受けていない
ノード(仮想でもかまわない)がBに対して「Aは優秀なノードだ」と評価値を送り込んだらどうなるでしょう。
　3の段階でリレーで評価依頼をまわすとしたら、B自体は自分が問い合わせたノード以外のどのノードから
評価値が戻ってくるか知ることは出来ません。よって虚偽の評価値を受け取らなければならなくなります。

　さて、帰ってきた評価値が正しいかを判断する方法は？


　ついでの疑問
　さて、新しいノードがたちました。当然このノードに対する評価は０です。また、このノードにはアップロードするような
ファイルがない。もしくは誰からもリクエストされないようなファイルしかもっていなかったとします。
　周りのノードは有効なファイルを共有し合っていて交換が頻繁に行われています。当然評価値も高くなっています。
　この環境につながれた、新しいノードはいつになったらファイルを落とせるようになるのでしょうか。

>>828
どうも
では散々問題点を指摘した手前まな板に乗ってみますか

DOMノードの判別方法を考えるにはどういうノードをDOMノードとするかを決めなくては判別できないが
MXと違って１対１でファイルを交換する訳ではなくマターリ共有のｎｙではDLしているノードが現在UPしているかどうかでは
判断できないしまた現在UPしているとしても過去にUPしているか将来UPするかはわからない
そこで単純に今現在自ノードに対して共有できる状態にあるかという事だけでDOMノードか否かの判別をすればいいかと

今現在共有できる状態にあるかどうかは相手に普通に問い合わせても帰ってくる情報に信頼性はないのでDL要求が来た時に
相手ノードから自ノードへ正規のULコネクションを確立させこちらから相手側へULしているあいだ切れないかを監視しつづける

自ノードに対してULコネクションを確立できる相手は正常ノードとする

基本はマッタリということでDOM対策はこれだけ

さて、ここでP2Pによるファイル共有を快く思わない組織があったとします

　その組織は、偽装ノードを作成しました。
　ノードの機能としては、どのようなノードがあるかのリストを作成する。
　作成されたノードのリストを元にノードの評価を問い合わせ、ノードの
転送量順のリストを作成する。
　上位にいるノードは人気のあるファイルを持っていると推定することが出来る。
　そのノードに対して、リクエストをかけてみる。
　「ないよ」と帰ってくるならよいが、「有るけど待って｣とかえってきたら…

>>833
　ちょっとまったぁ〜(笑

　それこそループネタですよ。
　ダウンロードしている間だけ、アップロードしてくれるノードに対してアップロードしていればよいのなら、
ダウンロードしたファイルを、他のノードにアップロードしてくれる保証にはなりはしない。

　ダウンロードが終わったところで、手のひらを返される可能性もある。

　正規のコネクションを確立させるといっても、プロトコル上正規であることは確認できても
相手のノードの中の機能が正規とは限らない。

　で、それに対する案として、52案もでています。が･･･

>>835
待ちましたｗ

>ダウンロードしたファイルを、他のノードにアップロードしてくれる保証にはなりはしない。
>ダウンロードが終わったところで、手のひらを返される可能性もある。

他のノードにアップするかどうかはどうでもいいのです
自ノードに対して正常であってくれればそれでDOMではないと判断します

>正規のコネクションを確立させるといっても、プロトコル上正規であることは確認できても
>相手のノードの中の機能が正規とは限らない。
とりあえずその時点でDL要求を出してきた相手ノードに対して欲しいファイルを要求するわけでもないので
コネクションが確認できるだけでULします

>>836

　い、いや、だから(汗)

　DOMパッチとして、自らがDL要求していないノードからのリクエストは蹴るみたいな
改造をしていたとしたら、十分機能してしまうのですが…

>>837
なるほど
自らがDL要求した場合にリクエストが蹴られたばあいはDOMノードとして
DOM警告を自動的にネットワーク上に流すうにするとかではどうでしょう

>>838

　その場合、他のノードをDOMノードとして認定させて自分だけがDOMノードと認定されないなんて姑息な考えで
　知ってるノードすべて（は云いすぎだとしても)に対して「DOM警告」を出すノードがでてくるかも知れません。

　また、それは、ネットワークの存在を破壊する攻撃としてもとても有効に機能します。

>>834
怖いな〜
ノードリストや大まかな転送量を調べられるって嫌だね。
今のnyはノードリストを作る事はできても誰がどれだけ転送したかは分からないもんね。
匿名性を保ったまま第三者による評価システムを機能させるのは無理があるよ。

>>839
確かにその可能性はあるな
ではネットワーク上にDOM警告を流してそれを他のノードが判断材料にするシステムは却下
単に自ノードとリクエストが蹴られたノードを切断してそのノードとは一定期間繋がないということにしてみます

実装はまだですか〜？

>841
相手の蹴る理由としていくつかのパターンが考えられるが

いずれにしても欲しいファイルは相手の手元にあり相手にとっては痛くない
痛いのは自分なのであまり利口な方法とはいえない

>>843
>相手の蹴る理由としていくつかのパターンが考えられるが
どのようなパターンでしょうか

>いずれにしても欲しいファイルは相手の手元にあり相手にとっては痛くない
>痛いのは自分なのであまり利口な方法とはいえない
リクエストを蹴るたびに他のノードと繋がらなくなっていくので結局リクエストを蹴ったノードが損をする事になるかと
またリクエストを蹴るノードは元々ULしてくれないのでそのノードを切断してそのノードとは一定期間繋がない事による
デメリットはあまり無いかと

>844

１．実際にそのファイルを持っていない場合
２．転送するための枠に溶融長い場合
３．アップロードする枠がない場合
４．転送する気がない場合

　大雑把に言っても4通りは考えられます

　ただし、転送による匿名性を期待するときこの4つの要因をリクエストしてきたノードに伝えることは危険です。
※３については危険性は低いと思いますが。

　どのみち、どの理由で蹴られてとしても、それが本当の理由であるかは不明です。
　よって、蹴られたことによってそのノードがDOMであるとは決め付けられません。

また、痛くないについて言えば
　そのデータを持っているダウンロード希望するノードに対してダウンロードを要求したノードが蹴るだけであってそのノードが
持っていないデータを持っているノードは蹴るという行為に成りません。
　蹴るという行為によって、欲しいデータを持っているノードを自主的に切断することは、蹴られた側としての感情的な対応としては
正しいかもしれませんが、蹴ってきたノードのデータを取得するための論理的な方法論としては正しいとはいえません。倫理的という
話は別次元においておいて。

　感情的な表現としては、欲しいデータを持っているノードがデータをよこさないときには悔しいから相手が要求してきても
断るということで、そのデータ自体が十分に拡散しているものであれば、切断されたノードは他のノードからダウンロードすれば
すむだけの話。

　ましてや、DOMに徹する気なら他からリクエストを受けるようなファイルを所持していなければ、リクエストを受けることもなく、
リクエストを蹴ることもなく、蹴ったことによって切断されることもなく、ダウンロードが可能となる。デメリットは期待できません。

　欲しがられたときに切断するなら、DOMに対してデメリット与えられます
　欲しがったときに蹴られた切断するんら、単なる僻みとしてDOMerが喜ぶだけです。

>>842
　現状での、DOMDOMゴーゴーでの実装でしたらば、一日の24時間プログラムに時間を割り当てられるならあなたでも、
1日もあれば実装可能です。ちょっと凝った造りをししたならば3日から1週間はかかるかもしれません。

　しかし、良識とプライドのあるプログラマーなら、仕様も決まっていない状態で実装して公開することはないでしょう。

　もちろん、これけネタの豊富なスレッドがあるのだから、実装実験のためのプログラムの作成および設計をしている人は
たくさんいると思いますが。

　さぁ、DOMDOMゴーゴーなプログラムを書いて、842氏と呼ばれるチャンスですよ。　がんばれ

>>845
>１．実際にそのファイルを持っていない場合
>２．転送するための枠に溶融長い場合
>３．アップロードする枠がない場合
>４．転送する気がない場合
どの理由による場合であってもULしてくれる事はないノードなのでそのノードを切断して一定期間繋がない事による自ノードのデメリットはあまり無いかと

>どのみち、どの理由で蹴られてとしても、それが本当の理由であるかは不明です。
>よって、蹴られたことによってそのノードがDOMであるとは決め付けられません。
どういうノードをDOMと決めるかによるが単純に自ノードに対してULしないものは全てDOMということで

ファイルを転送しない又はできないノードとは接続を切って一定期間繋がらないようにしてももともと転送が発生しないノードなわけだから
再度そのノードに繋ぎに行かないようにする事は検索の効率化から言ってもメリットがある

又どういう理由であったとしてもULしなかった相手ノードは接続が切れる事によって自ノード（こちら側）が持っているファイルを
落とせる状況にあったのに一定期間の制限が切れるまで落とせなくなるのでデメリットを受ける

結局１〜４のどの理由であってもULしなかったりできなかった時点で回りのノードから次々と切断されていく事になる
正常なノードであれば一定期間経過したあと再びつながり出すがまったくUPしないような０DOMパッチを当てていると
最終的に全てのノードから切断される事になるのでそのノードは孤立することになるかと

また完全に孤立してしまったノードであってもULを開始できる状態に戻せば再び回りのノードと繋がり出すのでDOMから正常ノードへの移行も簡単

あとこれは煽りでもなんでもないがもう少しわかりやすい文章をかいてくれ
意味を理解するまでにちょっと時間がかかったよ

ROMってたらどっちで進んでいるかわからなくなったので聞きます。

76案で、評価値を周りに聞くわけですが、その返答の方法は
1.返答をリレーして返す(中継する)
2.聞くときに返答先を入れておき、直接答えてもらう

のどちらを想定していますか？
1なら、返答ノードの特定はかなり困難。ありもしないノードからのうその返答を
捏造することができます。
２なら、それはできませんが(IPアドレスによって返答ノードが特定可能)、ものすごい
トラフィックが発生するかと。短時間に100ノードと短いながらも通信しなければ
ならないので負荷もすごいかと。
それと、いつか出てましたがネットワークに存在するノード数を効率的に数えられて
しまうことにもなりますが、それは気にしない、でいいんですかね。

>>848
＞それと、いつか出てましたがネットワークに存在するノード数を効率的に数えられて

それは今のWinnyでも同じです。
評価システムを組み込むと大まかな転送量も知る事ができます。

>>833
けれど結局これについては対抗策がないようですが。>>837
>DOMパッチとして、自らがDL要求していないノードからのリクエストは蹴るみたいな
>改造をしていたとしたら、十分機能してしまうのですが…

この案にある種の対策を取ったのが>>4です。

それに多数の捏造ファイルを共有していたらどうしますか？
リクエストを要求して相互にDLしたはいいが、それを落としてみるまで本物かどうか分からない。
相手からリクエストさえなければ切られることもないのでやる意味は十分でしょう。

また後からのリクエストでは落とし終えるまでに相手に切られてしまう可能性があります。
これでは先にDLしたもの勝ちです。
転送終了時を合わせるなら後にDLしたもの勝ちです。

MXではこの辺りの問題を匿名性がなくコミュニケーションを伴うことにより
相手の良心、初心者には「２ちゃんで晒すぞゴルァ！」への畏怖によりうまく機能しています。

単体で改造捏造し放題な考え方を匿名性の中に運んできても仕方がありません。

さらに次のステップとして複数ノードによる52案や72案のようなものが存在するわけです。

>>833
次に進むとはやっとWinnyと違い、72案なら大多数のノードが不正ノードになることは難しいと理解してくれて
無駄な論点から外れることだと思ったが、こんなことを考えることだったのか。

>つまり起こらない事を前提とするのではなくおこった場合でも大丈夫なシステムでなければだめじゃないのか
では大多数のノードが他ノードがDLしにくくするために
>>798検索結果を減少したり遮断したり偽装した場合に成り立つのか？
大多数のノードが捏造ファイルしか共有していなかった場合は成り立つのか？
大多数のノードが何も共有せずDOMに徹した場合は成り立つのか？

他にも問題はあるだろうが、大多数のノードが不正ノードになった場合に成り立つシステムとは到底思えない。

>>831
72案について思い違いをしていたので最初意味が分からなかったんだが、
確認しておくと>>815は>>848の1を想定した場合の話だと考えていいかな？

>>850
ID:pE8R9TFx ＝ ID:iNpxliz8

>DOMパッチとして、自らがDL要求していないノードからのリクエストは蹴るみたいな
>改造をしていたとしたら、十分機能してしまうのですが…
これの対抗策は>>841です

>それに多数の捏造ファイルを共有していたらどうしますか？
>リクエストを要求して相互にDLしたはいいが、それを落としてみるまで本物かどうか分からない。
>相手からリクエストさえなければ切られることもないのでやる意味は十分でしょう。
捏造ファイルについてはオープンソースになった時でも現在の47氏の対策だけで十分だと思う

>また後からのリクエストでは落とし終えるまでに相手に切られてしまう可能性があります。
>これでは先にDLしたもの勝ちです。
>転送終了時を合わせるなら後にDLしたもの勝ちです。
一時的に得したように見えてもそういう行為をするノードは次第にどのノードとも繋がらなくなっていく事になるかと

>単体で改造捏造し放題な考え方を匿名性の中に運んできても仕方がありません。
すいませんが意味不明です

>さらに次のステップとして複数ノードによる52案や72案のようなものが存在するわけです。
複数ノードによる評価システムには現状では穴があるのでだめでしょうね

あほですねお前ら、DOMに厳しい使用にするなら
IP監視して、数時間起動してる事が確認できるノードにしかファイルをUpしなければいいんですよ
これでお手軽にお宝ゲット出来なくなって敷居がたかくなりますようんこ

>>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りまくれる。

>>854

　一定時間接続を蹴る仕様の問題その２　ちょっとマクロに

　転送によって匿名性を高めるという機能がある。ノードAにあるデータをノードBを経由してノードCに渡す。
　ノードBはノードAにデータがあること知っている。
　ノードCはノードBが知っていることを知っている。
　ノードCはノードBにリクエストをかけた。
　ノードBはノードAにリクエストをかけた。
　しかし、ノードAは手一杯だったので断った。
　ノードBはノードAを一定期間接続拒否する
　ノードCはノードBがデータをよこさないのでノードCを一定期間接続拒否する。

　転送という機能を有効に働かすためには、ノードの稼働率を高めてノード同士が緊密に働かなければ
ならないのだが、こんなブチキレシステムでは協調して機能できないのでは？

>>854
>延々繰り返し？
何かの理由でULを拒否される限りなんどでも繰り返します
しかし実際問題としてはなんども繰り返される前にその他のノードから無事にDLできるので
延々繰り返されることはないでしょう

>ノードAにはノードBがほしがるファイルがいっぱい。ノードBにはノードAがほしがるファイルを
>持っていない。ノードAはノードBにリクエストをかけないから拒否条件は発生しない。
>ノードBはノードAから拒否されないのDOMりまくれる。
ノードBがノードAに対して正規のULコネクションを確立させDLが終わるまでノードAとのULコネクションを切らなければDLできます
この状況でのノードBのDLを許可しないことはまったく共有ファイルを持っていない新規参加者を許可しない事になる
またファイルを持っているのにDLさせないことは自分が相手から切断され一定期間制限される事になるかと

>>855
>転送という機能を有効に働かすためには、ノードの稼働率を高めてノード同士が緊密に働かなければ
>ならないのだが、こんなブチキレシステムでは協調して機能できないのでは？
いかなる理由であってもULしなかったりできなかった時点で回りのノードから切断されます
そして手一杯ではない他のノードと繋がります

>>856

>　ノードBがノードAに対して正規のULコネクションを確立させDLが終わるまでノードAとのULコネクションを
>切らなければDLできます
>この状況でのノードBのDLを許可しないことはまったく共有ファイルを持っていない新規参加者を許可しない事になる
>またファイルを持っているのにDLさせないことは自分が相手から切断され一定期間制限される事になるかと

　ファイルを持っているかの問い合わせに対して、持っていないと返答する改造をするだけで
DOMが自由に出来るシステムになるのでは？

>>854
>>856の補足
ULを拒否される限りなんどでも一定期間接続拒否なのですが接続拒否中の相手に拒否された場合は
ULの拒否ではなくコネクション自体の拒否なので
　
　ノードAがノードBにリクエストしたときに、何かの理由でULを拒否されたとします。
　ノードAはノードBを一定期間接続拒否します。
　ノードBはノードAにリクエストします。ノードAは拒否します。
　ノードBはノードAとコネクションできない
　ノードAは拒否期間が切れたところでノードBにリクエストをかけます。ノードBと接続。
　
>>854のミクロの場合の例ですと上のようになるとおもう

>>858
持っていないと返答するだけならULを拒否したわけではないので
今のままのシステムではそのノードが切断されて一定期間制限されることはないです

かりに持っていないと答えるノードが大多数になった場合は検索しても
ほとんどファイルが見つけられない状態になると考えられますね

>>859の修正
> ULを拒否される限りなんどでも一定期間接続拒否なのですが接続拒否中の相手に拒否された場合は
> ULの拒否ではなくコネクション自体の拒否なので
> 　
> 　ノードAがノードBにリクエストしたときに、何かの理由でULを拒否されたとします。
> 　ノードAはノードBを一定期間接続拒否します。
> 　ノードBはノードAとコネクションできない
> 　ノードAは拒否期間が切れたところでノードBにリクエストをかけます。ノードBと接続。
> 　
> >>854のミクロの場合の例ですと上のようになるとおもう

こうですね

>>860

　だとすると、DOMし放題のノードが作れて、それがリーク蔓延していったらネットワークは崩壊することに
なるのでは？

>>862
まだその事について詳しく検討してないですが検討した末にその問題が解決できそうもないなら
又別の案を考える事になるかも知れないです

問題点が出てきてそれが解決できない場合は次の案を出してそれにまた
別の問題点がないか検討することになるかと

それを繰り返していけば問題点のない案が完成するとおもう

>>862
となると、どのくらいのDOMに耐えられるか簡単な仮想ネットワークで
テストする必要があるかも。
DOMの数が少なければうまくいくのであれば、どこまで耐えられるかの
数字を出してみるのもいいかと

>>864
>DOMの数が少なければうまくいくのであれば、どこまで耐えられるかの
>数字を出してみるのもいいかと
ネットワークを崩壊してしまうほどのDOMは現れる筈がないのでDOMの数が少なければうまくいくのでは
という想定をしているのであればDOM対策は必要ありません

それが成り立つのであれば何の対策もせず現在のｎｙをオープンにした場合でも
ネットワークを崩壊してしまうほどのDOMは現れる筈がないという事になるからです

どこまで耐えられるかではなくどんなに増えても耐えられる対策を考えなくてはだめだとおもう
少ない時は耐えられるシステムというのは多くなった時は崩壊するわけですし。。。

もまえら、がんがれ!

☆★最新アダルト情報★yahoo検索から★☆
http://endou.kir.jp/marimo/link.html

http://homepage.mac.com/hiroyuki44/2ch.html

(´-`).｡ｏＯ(厨な意見かもしれないが、パッチ当ては実は難しくないんじゃないか？
WINNY自体がオープンソースになれば、パッチ当て済の
WINNYパッケージと言うのも作れるし、それがNYで流れたら、
それをインスコするだけなんだから。)

んで、そのパッチ当て済&配布者ノード＋パッチ当て配布者偽装のため
30−40ノードぐらいの評価MAXを返すようなパッケージが出回ればどうなるんだろう。
オープンソースにすると言うことは他の奴が
そのソースを基に改造して配布をできると言うものなんだが、
なんかパッケージそのものを偽装された場合の話がでてないような。

オープンソースって、、、K察対策は大丈夫なの？

実装が絶対無理
-----------------------
本来のソース
listen (myip){
if (相手のファイル要求){
connect(sock)
}
----------------------
改変ソース
listen (myip){
if (相手のファイル要求){
shutdown(sock)
}

こういうのをどう防ぐつもりだ？

>>872

　それはあからさますぎますね。
　ま、言いたいことは解るが、コード起こすほどのことでもない。
　というか、コードがそれだと突込みどころ満載すぎるｗ

WinnyでDOMる方法

・1分に１回キャッシュを全削除する。
ダウン中のファイルはロックされているので削除されることはない。
削除されるのはDown済みまたは転送用のゴミキャッシュのみ。

・Winnyを複数起動する。
Uploadしないと1クライアントあたりのダウン数が制限されるが
クライアント数を増やせば好きなだけDOMることができる。
# 複数起動の方法は各自工夫するように。やり方はいろいろある。

>>874

　自分がダウンロードしている最中で、途中まで落ちていて、切断された
ファイルまで消えるので効率が悪くなりますw

　タダですらメモリに負担がかかっているWinnywo複数立ち上げるとは豪気なw

>>875
>切断されたファイルまで消えるので効率が悪くなりますw
一時間以内の転送であれば切断される可能性はかなり低いので実質問題にはならない。
無駄な転送も発生するがそのコストは定額である以上個人には発生しない。
キャッシュのフォーマットも解析済みなのでより効率的なクリーンアップツールの作成も容易。

>　タダですらメモリに負担がかかっているWinnywo複数立ち上げるとは豪気なw
PC一台OS一つVM無しでも複数起動は可能。

しかし、実現が無理なことを真面目に考えている馬鹿どもが居るというのは、
面白いですな。

４７氏の依頼でオープンソース化が不可能なことを実証するスレですので

ﾁｮｰｳｹﾙ

へんじがない。ただのしかばねのようだ。

☆★　新商品　ゾク・ゾク　入荷！！　急げ〜！！　☆★☆
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★
☆★　送料激安！　　スピード発送！　　商品豊富！　　　
★☆　　　　　　http://www.get-dvd.com　　　　　　　　
☆★　激安ＤＶＤショップ　「ＧＥＴＤＶＤドットコム」　
★☆　　　　　　http://www.get-dvd.com　　　　　　　　
☆★　今すぐアクセス　Ｌｅｔ’ｓ　Ｇｏ！　　　急げ！　
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★

>>874
それならタイムスタンプ見て、一時間（一分？）以上更新されていないファイルを削除の方が効率いいと思うな。

＊＊＊終了＊＊＊

まだ終了したわけでもないのだがね

47氏は不可能だと思ってるわけだよね？自らの能力では

こういうのはアイディアの問題だから
どれだけ効率を落としてもいいのであれば
47氏だって色々考えられることはあっただろう

オープンにしてもWinnyを使い続ける価値があるほど
効率のいい実装方法は思い付かなかっただろうけどね

TCP/IPで操作できるようになるだけでかなり
利便性が高まるわけだが。

どうよ？

セキュリティとか問題はありげだけど。

>>863
>まだその事について詳しく検討してないですが
そろそろ詳しく検討出来ましたか？

>>887=>>888
自演ですか？

>>TCP/IPで操作できるようになるだけでかなり
>>利便性が高まるわけだが。

まったく意味がわからん
小学生にも理解できるよう説明よろ

>>890UZEEEEEEEEEE!!!ソンクライ理解しろﾎﾞｹ

自演というか、補足しただけ。
なんで同じIDで自演という発想が出てくる
のかがわからん。
やっぱり夏ですね。

わかりやすく説明すると
ブラウザとか通信ソフトで操作できたら
楽だよな。って意味だよ。

その場合パスフレーズとかないと危ないだろ？
わかった？

>>892
要は君がアホってことですね。
TCP/IPでwinnyと直接通信すれば？

まあ究極的にはみんなが脳にプラグ差し込んで脳内を共有するようになるんだけどね。
それまでのつなぎってことで > Winny

>>892 >>891
え？
じゃあ>>892はTCP/IPつかわずになに使おうとしてたわけ？
UDP/IPとか？
Rawで直接プロトコル作って直接通信するつもりですかｗ

>>880
藁

今度は>>863氏検討待ちですか。

待ちに入ると何故か荒れるよな。

>>897
>それを繰り返していけば問題点のない案が完成するとおもう
この文面で何か考えてるとは思えないけど。

ついでにｵﾌﾟｿになれば
>>874
的な改造も簡単になって協調的に動作する不正ノードが
(局所的に)多数派を占める事も可能になるね。

>>897
だれも待ってないしｗ
具だ具だいってCUI版すらできてないようじゃココの奴らって厨房なんだろｗ

具だ具だいって煽りすらできてないようじゃ>>899って厨房なんだろｗ

ひろみに会いたい人、ひろみが欲しい人、手ぇあげてっ！
はーい、その指をマウスにもってってぇ・・・
ここをclick! ☆ъ（　゜ー^)＞ http://www.gals-cafe.tv
１週間毎日１０分、がんばってサービスしますっ！来てください♪
・・・えっ？誰も手ぇあげてなかったってハナシ？
そんなんナシだよぉ〜〜〜。・°°・(>_<)・°°・。
会いたいよぉ。きてくださぁい（ ・O・）∞∞OOO○○○☆（〃。。〃）

とりあえず
オレの脳がおまえらに
ついていけないことがわかった

>>893
ブラウザとか通信ソフトとか専用クライアント
と言わなかった自分がアホでした。

>>895
>>887->>888 = >>892
> じゃあ>>892はTCP/IPつかわずになに使おうとしてたわけ？
どうやったらこういう結論に至ったのか…あんた天才すぎ。

>>898
じゃあ最近カキコがなかったのは何故？

>>862で指摘された穴を>>863氏が検討して
解決不可能だったらまた他の案を考えましょうって流れだと思ったんだけど。

>>902
Winny はもともと、 TCP/IP を使っている。

>>903
最近カキコがなかったのは、いろいろ出た案の問題点などを
考え中なので。
なかなかいい解決法を思いつかないんで、ほったらかし(w

>>902
君はプロトコルの勉強をした方がいい。
「OSI参照モデル　TCP/IP」でぐぐってみるといいかもね。

>>863
>それを繰り返していけば問題点のない案が完成するとおもう
ｱﾎだな。
いくら問題点を改善しようと4を奇数であると証明することは不可能なように
ｵﾌﾟｿでDOM対策はどうやっても不可能にだろ。

1と3に分ければ片方は奇数だけど。。。
そういう方法を考えるためのスレといことで。

逆に言えばオープンオースにしたい！って内容でLinux板にWinny/Linnyスレが起つってことは
Linuxユーザー(UNIXユーザーが)Windows以外のOSでのWinnyを使いたいわけだろ？
ってことは47氏が全てのOSのGUI周りに互換性のある
WideStudio使って互換性のあるWinnyを作ればいいだけのはなしなんじゃない？
開発したい香具師は別として使いたいだけの奴はそれでﾏﾝｾｰのような。

>>909
もっかい頭から読み直せ。
Linux で Winny を動かすだけなら既に可能。そういう問題ではなく、
Winnyの最大の弱点が47氏になっている現状をなんとかしようという話だ。

47氏負担の軽減も目指してるわけだからな。

>>906
普通に知ってます。
七階層あることぐらい。

で。TCP/IPでの具体的な手段を
あげたかった「だけ」なわけだが。
そこまで突っ込んでくれるとは
頭がよろしいね。

おまえら天才すぎるからさ。もういいよ。

http://www.symantec.com/region/jp/sarcj/data/w/w32.hllw.antinny.html

はぁー、だめだなこりゃ

＞＞９１２
おまえマジで何歳？
ヒッキーリアル厨房だろ
ちょっと基本情報さわってみましたみたいな
もうまじで書き込まないほうがいいよメッキがはがれるから

DOM対策なんて片付いてるのに、それにも気がつかないなんて…

これらが、いわゆる夏厨？

>>916
>>869-870は?

自分が実際にDL/ULした時の相手の行動での評価にウエイトを置いて、
外部の評価は参考程度にしておけばいいんじゃない？
それで、上記前者での評価が高いノードが送る評価のウエイトを少しあげるとか。

まあ、ある程度はDOMられるのはしかたないと思うけどね。

>>869-870にはあえてレスをしなかったが一応しておく

まずパッチ当てが難しいとは思っていない。
>>824で初心者層の範囲をパッチ当てに焦点を合わせて説明しているが、
パッチ当て済み、パッケージそのものの改変が行われた場合でも
>>822で説明しているように72案では自身にメリットのあるような動作は難しいだろう。
またDOMになるために嘘の評価値を返すならクラスタが別離してしまえば全く意味がなくなる。
常に嘘の評価値を吐いてネットワーク全体の評価値の信憑性を落とそうという動作も同じ。

重要なのはパッチでも改造パッケージでも、それを使う動機あるのかということ。
改造パッケージ配布用のサイトを開設してそんなものを配布したところで
一体何人がYahooにも登録されてないため見つかり難く、ウィルス入り、トロイ入りかもしれない上に
自身にとって何のメリットもないWinnyを公式ページ以外から落として使うのか。

はずがないはずがないで塗り固めた設計がまともにうごくはずもない。

>>919
初心者クラス→DOM化クライアント(ﾟдﾟ)ｳﾏｰ評価下がったら、再インスコで(ﾟдﾟ)ｳﾏｰ
DOMクライアントを手軽に使えると言うのは動機としてかなり強いと思うよ。
それに、公式でなくても一回それが安全だと誰かが確認したらいいのだし

ハッカークラス→初心者クラスによって評価値あがりまくったクライアントによってがんがん高速DOM(ﾟдﾟ)ｳﾏｰ
てか、その評価値を返すのはハッカークラスのクライアントじゃないし。

後、根本的にどんな評価問い合わせでも評価MAXを返す、、、と言うクライアントも作り得ると思う。
もっとも、それに対抗して、ランダムに５つ６つに付いての問い合わせをかけて、
そのクライアントがてきとうに答えを言ってないかと言うチェックするって方法もあるが。

だからDOM野郎が(ﾟдﾟ)ｳﾏｰい思いをしないようなｼｽﾃﾑを誰か思いつけよ！！！

コード書くことで47氏に協力がしたいのなら
氏が仕様を書いてリクエストした雑多なクラス・関数を
UnitTest付で実装してフィードバックする、
UIの改善案を出して、そのコードを提供する。
そうすれば氏はコア部分に集中しながら
同時に細かい瑣末な部分を
ブラッシュアップしていけると思う。

オープン・クローズドな折衷案として
あるいはこういう開発モデルがあっても良いのではないかな。

>フィードバックする、
フィードバックという言い方はおかしいな。
>コードを権利云々を一切主張しないで提供する。

ゼロ知識証明

なんでここに47氏が降臨しないのだろう？

前から不思議に思ってたんだけどさ、なんでlinux板で語ってるの？
download板なりソフトウェア板なりム板なりふさわしい板あると思うのだけどさ
なんで？オープンソース化を考えてるからってのは駄目だよ

Linnyスレからの派生だから。

DOMやられそうなところは，難読化しときゃええんちゃうのん？

オープンソースとはいえ初心者にはソースが読めない。で、そこそこスキルのあるやつが
DOM用に改造して公開。DOMから神扱い。

結局システムを煮詰めてDOMをしづらくするしかない、と。

>>921
>初心者クラス→DOM化クライアント(ﾟдﾟ)ｳﾏｰ評価下がったら、再インスコで(ﾟдﾟ)ｳﾏｰ
これは繋ぎ始めのノードがどれだけ効率よくダウンできるかによる。

もし繋ぎ始めのキャッシュ無しノードが現在のWinny程度の効率を得られるなら動機としては強いだろうが、
そうならないようにするための72案であり、ここらの動作はまだまだ熟考すべき部分だと思っている。

一つの方法としてはマイナス評価がどれだけあるかに関わらず、
プラス評価のあるノードとプラス評価の全くないノードの扱いに決定的な違いを儲けることだな。
転送、順番待ち状態でプラス評価の一つもないノードは常に最後尾に落とすことにする。

これならアップ帯域を1bpsも使用していないノードは他の不正ノードとの協力無しに
WinMX3.3以上の効率でDOMになることは出来ないだろう。

>ハッカークラス→初心者クラスによって評価値あがりまくったクライアントによってがんがん高速DOM(ﾟдﾟ)ｳﾏｰ
確かに今のところこれを防ぐ手立ては考え付いていない。
しかし初心者クラスではなく、ハッカークラスの人間がネットワークを正常に稼動出来なくするほど存在するとは思えない。
難易度は違うがクローズドWinnyを自分のためにクラックしてDOMになってるハッカークラスと同じことで、
その存在がネットワークを崩壊させるほど多いとは考えられない。

またわざわざ初心者クラスがハッカークラスの評価値を上げる理由も分からないが、
何より他ノードに協力してもらう必要があるから、ハッカークラスでDOMになりたいノードであっても
多数の他人の協力を得られないノードは不正を犯すことが出来ない。

つまりこのようなノードになることは難しく、ネットワークに影響がないほど極少数であると考えられる。

>後、根本的にどんな評価問い合わせでも評価MAXを返す、、、と言うクライアントも作り得ると思う。
評価MINならまだ分かるが、評価MAXを返して何か意味があるのだろうか。

>>931
だからそれはお前の脳内仮定だろう
いない
ありえない
どうしてそうなるのかわからない、俺ならこう思うだから俺が正しくて安全

議論にならない

とりあえず>>932に一票

>>932=865か？

取り合えず>>865の考え方が完全に間違っているから議論にならないと分かったよ。

俺も >>933 の考えでいいと思う。
みんな違法行為なんか絶対しないいい人たちだから、ネットワークをわざわざ崩壊させることもない。
winnyとかwinmxだって性格的に厨房なやつはやってないしね。

それに、崩壊したらしたで、そのとき考えればいいよね。
スーパーハカーが速攻でなおしてくれるから、人が流れることもないだろうし。

たぶんこれで47氏もOKだすよ。うん。

>>933 じゃなくて >931 だな。すまん。

>>902
オレの脳がおまえらに
ついていけないことがわかった

文章がそっくりだな
いつぞやの厨房かｗ
>>934
おまえIPの偽装の仕方とかわかってるかｗ
しょうじきwinに比べればLinux socketめちゃかんたんだぞ


このスレおもしろいなまじで

とかなんとか言っちゃって。
一番鼻息荒いのは>>937だよね。

やれやれ

>>983
(´`ｃ_,'` )ﾌﾟｯ

socketプログラムも出来ないタコがよくほざく

>>940
ふーん。根拠もなしによく言い切るね。
どうでもいいけどRawソケット使えるくらいでそれだと

痛すぎだよ？

>>834

>>865をよく読め。それでも解らなかったらカエレ

>>940みたいな馬鹿が沸いてこないようにこの板でやってるんだよね〜

IPアドレスの偽装って(ﾌﾟﾌﾟﾌﾟ
是非とも偽装したIPをどう使うのか聞きたいなぁ（藁

覚えたての知識で大興奮
っていう夏厨でしょ。

公開ｵﾅﾆｰも休み休みにしてください。

(ﾟДﾟ)ﾊｧ?
ＩＰ偽装したらネットワークは崩壊するだろ

ファイルサーバーポートを空けるＩＰに存在しない偽装ＩＰいれたら完全ＤＯＭだろ

>>945
あ〜この程度の理解でいきがってるんだから手に負えないわ
存在しない偽装IP入れて完全DOMね

つまり夏厨はMX3.3でもやってなさいってことだろ(w

　　　　　 n＿n
　　　　　（･A･）っ
　　　　　(っ　,ｒ　　　しゅたたた・・・
.　　　　　 i_ﾉ┘
　　 　 　 ∧＿∧
　　　 ⊂（ ･ A ･ ）
.　　　　　ヽ 　⊂）
　　　　　（⌒） ｜　　　しゅたたたたたたたたた・・・
　 　 　 　 三 `Ｊ
　　 　 /ヽ　　　　　/ヽ
　　　/　　ヽ＿＿_/　 ヽ
　　／　　　　　　　　 　 ＼
　　|　　●　ヽー/　●　　|　　あ〜この程度の理解でいきがってるんだから手に負えないわ
　　＼　　　　 ∨　　　　／

>>945
（　´,_ゝ`） ﾌﾟ
偽装したIPでどうやってTCPコネクション確立するんでつか？
不可能とは言わないが、お前がそれを出来る立場の人間でない事は確かだ。

>>948

TCPコネクション確立するだけなら
どっかのＷＢＥサーバー:port80につなげればいい
nyプロトコル偽装はまた別の話だが


アホはお前だｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

オープンソース版nyプロトコル偽装は楽勝だろう

ソースが公開されてるんだし

オープンソースはどうでもいいから、まずプロトコルの標準化が必要なのでは？
そのうえでオープンソースだったりそうじゃなかったりする
アプリケーションが作られていくってのが正しい手順だと思う。

なので、誰かI-D書いてIETFで発表してきてくれ。
ひろゆきマスクとか被って。

それとなんでDOMをそんなに毛嫌いしてるの？
NNTPのようにDOM許容ってのは駄目なの？
匿名性のないNNTPであれだけエロ画像や動画が流れているのを考慮すると
匿名性をウリにしてプロトコルが公開されたシステムならDOMを毛嫌いしなくても
とんでもない量のコンテンツが発生すると思う。

それから、プロトコル偽装っていうか、構築されたP2Pネットワークシステム自体の
動作に影響をおよぼす悪意のあるアプリの構築は当然容易なので、
I-D書いてSecurity Considerationの章でしっかり検討する必要があると思う。

>>951
>>匿名性をウリにしてプロトコルが公開されたシステムならDOMを毛嫌いしなくても
>>とんでもない量のコンテンツが発生すると思う。
禿同
それがオープンソースでやる場合の一番の価値だ。

四の五の言わずさっさと動くもの作ろうぜってこったな。

そして、よく言われることだけど、公開した後パッチがあてやすく
改編要求を吟味しやすい運用体制を作ることだ。
それができればDOMに絡む問題はそのうち解決されうだろうと
期待するって言う、前向きさで何とかなる。
どんな問題もコードに向けられる目の数が最良の解決手法だって
(どっかの誰かの)言葉を信じてみよう(･∀･)!

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が特定のファイルを持っていることを公開している」っていうのがイマイチかも。
この部分も別のノード経由で公開するとかいう必要があるな。
コメント求む。

>>953
↓このレベルと同じ
http://tmp.2ch.net/test/read.cgi/download/1060539227/
面白そうな転送方式を思いついたのでメモっとく。じゃだめだろ

ここはDOM否定派と容認派と中間派と一見さんが無責任な発言で
相手の発言をスクロールアウトさせて無限ループを楽しむスレですか?

http://homepage.mac.com/hiroyuki45/hankaku03.html

DOM容認派と中間派＝一見さん

このスレに最も不要なのはDOM対策不要論

>>953
メモっとくのはいいと思うんだけど、
せめてもう少し内容を考えてからメモって欲しいな。

現winny方式そのままならDOM対策必要かもね。
逆に言うとDOM＝悪という前提の限りwinnyはこれ以上利用されない。
DOM10人に対してUPが1人とかでも動くようなシステムじゃないと利用者は爆発的には増えない。
DOM＝悪という前提が不要な別のプロトコルが必要。
さらに言うと、DOMかそうでないか、ということすら匿名であり且つシステムに
悪影響をおよぼさないようなシステムが望ましい。

それと、プロトコル仕様公開＝オープンソース＝linuxという考えで
このスレがlinux板にあるのだとしたら、はっきり言って板違い。
プロトコル仕様は通信技術板の方が良い意見がでるはず。

>>953
分かった。匿名性を維持するには２ホップで十分ということだな。
それ以上になると転送効率が悪い。
winnyのように中途半端ないらんものを転送するのも効率悪し。
DOMの毛嫌いも利用者減す。
ところでBがスパイとか悪意のあるノードの場合、Cの鍵をAに正しく送れない気がするが、
B1とB2とか、複数のBを利用すれば解決できそうだな。
B1、B2経由で送られてきたCの鍵が違っていたらB1もB2も信用しない、とかな。
で、保持しているファイルの公開方法だが、953と同じ方法で匿名性を保ちつつ情報交換できるだろ？
匿名性は2ホップで確保、そして無造作に抽出した隣接ノード複数を利用して信頼性確保、
転送効率を最大限にしつつ匿名性を確保するため転送は最大２ホップ、
これ逝そうじゃないか？

初期ノード問題なんだけど、完全可逆じゃなく、情報が2bitから3bit
くらい欠落する不可逆暗号はどうよ？
つまり@hogehogehogehogeっていうのを解読すると
IPアドレスの候補としてA,B,C,Dくらいとportの候補としてx,yくらいが抽出されるとか。

>>961
空想科学ねっとっワークワンダバｎｙ
すごいね
んじゃ予測されるＩＰにＳＹＮうちまくりってわけかい
そこがペンタゴンだろうが、黒客だろうが

　　　　ｼｭﾎﾞｯ
　　　　　　　.,　∧＿∧
　　　　　　[]() （・ω・｀ ）　　　　　　ｌ二ヽ
　　　　 　　□と>>960）￣⊃　　　　　) )
　　　　　　⊂ （＿（＿つ　　￣⊃　　/￣￣￣ヽ
　　　　　　　⊂_　　　　　 .＿⊃　　　| （＼／） |
　　　　　　　　　⊂＿＿⊃.　　　　　 |　 >　< 　|
　　　　　　　　　　　　　　　　　　　　 | （／＼）. |
　　　　　　　　　　　　　　　　　　　　 ヽ＿＿＿/

　　　　　　　　　　从从
　　　　ｺﾞｫｫｫｫ 从从　从　　
　　　　　　　从从从∧ ::从::从
　　　　　　从从从;;;从）:::::::从::从　　ｌ二ヽ
　　　　 　从;;;](_;;;从从;;;从从从　　　　 ) )
　　　　　　从　;;;;;__从从从:::从　　　 /￣￣￣ヽ
　　　　　　从从::::　　:::::从从　　　　 | （＼／） |
　　　　　　　　　从从从从　　　　　 .|　 >　< 　|
　　　　　　　　　　　　　　　　　　　　 | （／＼）. |
　　　　　　　　　　　　　　　　　　　　 ヽ＿＿＿/

おまえらにはゲーム板がおにあい
仲間がいっぱいいるぞ
どっちにしても青果物の出ていないコノスれはいた違いだウソ板いけ
ゲ製作技術
http://pc2.2ch.net/gamedev/
Download
http://tmp.2ch.net/download/

>>962
うちまくりってほどじゃなく、１発ずつくらい。
めでたく張れればOK。
まぁpentagonやgo.jp、govが年間に食らうattackの回数を考えればSYNの一発くらい無問題だろ。
portも違うし。
でもヘボプログラマがコード書いたらうちまくりになるかもな。
OS標準のTCPのスタックなんか使うなということだ。
最初はraw socketでSYN一発うってSYN/ACKを待てということで。

しかしここみて思うんだけど、P2P分野って日本人に専門家いないの？
ああ、自分じゃ作れないけど評価と文献引用だけならできる類ならいるのか。

どこかの国内の学会で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=

winnyのオープンソース化とか言いながら、プロトコルの標準化とかIETFとかいう
言葉がでてきたのが950以降だというのがこのスレの駄スレっぷりを表してるな。

＞＞９６６

しかも最後は他人よがり