Winnyのオープンソース化を考えるスレ
デバッグに詰まったので、ちょっと長文行きます。
>>72を詰めるという話の腰を折ったらもうしわけありません。
DOM対策という名の不正ノード対策
オープンソースのWinnyなりでの不正ノードのあり方
1)ネットワークに入り込み、そのネットワークにアクセスしているノードのIPアドレスを集めるノード。
2)ネットワークに入り込み、そのネットワークで流れているデータのリストを作成するノード。
3)ネットワークに入り込み、そのネットワークにつながれているノードがどのような情報を保持しているかのリストを作成するノード。
4)ネットワークに入り込み、ひたすらデータをダウンロードするばかりでネットワークに貢献しないノード
5)ネットワークに入り込み、そのネットワークに捏造データやウイルスデータなど傷害の原因になる不正データを流し込むノード。
とりあえず、ざっと考えてこれくらい。
>>72を詰めるという話の腰を折ったらもうしわけありません。
DOM対策という名の不正ノード対策
オープンソースのWinnyなりでの不正ノードのあり方
1)ネットワークに入り込み、そのネットワークにアクセスしているノードのIPアドレスを集めるノード。
2)ネットワークに入り込み、そのネットワークで流れているデータのリストを作成するノード。
3)ネットワークに入り込み、そのネットワークにつながれているノードがどのような情報を保持しているかのリストを作成するノード。
4)ネットワークに入り込み、ひたすらデータをダウンロードするばかりでネットワークに貢献しないノード
5)ネットワークに入り込み、そのネットワークに捏造データやウイルスデータなど傷害の原因になる不正データを流し込むノード。
とりあえず、ざっと考えてこれくらい。
|
|
|
例１対策
ノードの情報を少数他のノードに流すことによって制限する。
インターネットにつながっている以上、IPアドレスはさらされているものであり、ポートスキャンよりは
効率が良いかもしれないが、効率よくIPアドレスを収集されないように対応する。どの程度が適当な
少数であるかは要検討。
例２対応
ネットワーク上でキー情報が適度に流れていない限り、検索を十分に行うことができない。よって
これに対応することは困難。クラスタ化などによりキーの流通をある程度局所化できれば、全体を
把握することは困難になるかとも考える。
例３対応
問い合わせを受けたノードがキャッシュを持っている場合にはそれを転送、無い場合には他の
ノードからの転送で行う仕組みとすれば、自ノードが持っているリストをそのノードが公開しない限り、
実際に何を持っているかのリストの作成は困難になる。
例４対応
データは各ノードが交換するものとする。交換に応じないノードにはそれ相応の不利益を与えるような
構造にしておく。効率よくダウンロードするためにはネットワークのノードとして正しく機能しなければ
ならなくなる。
例５対応
不正データ自体はノードが必要とするものを転送受けることによって、無用なデータの飽和を防ぐように
する。また、現Winnyにあるような評価データを流すことによって不正データの氾濫を防ぐような構造を設ける。
ノードの情報を少数他のノードに流すことによって制限する。
インターネットにつながっている以上、IPアドレスはさらされているものであり、ポートスキャンよりは
効率が良いかもしれないが、効率よくIPアドレスを収集されないように対応する。どの程度が適当な
少数であるかは要検討。
例２対応
ネットワーク上でキー情報が適度に流れていない限り、検索を十分に行うことができない。よって
これに対応することは困難。クラスタ化などによりキーの流通をある程度局所化できれば、全体を
把握することは困難になるかとも考える。
例３対応
問い合わせを受けたノードがキャッシュを持っている場合にはそれを転送、無い場合には他の
ノードからの転送で行う仕組みとすれば、自ノードが持っているリストをそのノードが公開しない限り、
実際に何を持っているかのリストの作成は困難になる。
例４対応
データは各ノードが交換するものとする。交換に応じないノードにはそれ相応の不利益を与えるような
構造にしておく。効率よくダウンロードするためにはネットワークのノードとして正しく機能しなければ
ならなくなる。
例５対応
不正データ自体はノードが必要とするものを転送受けることによって、無用なデータの飽和を防ぐように
する。また、現Winnyにあるような評価データを流すことによって不正データの氾濫を防ぐような構造を設ける。
匿名性のために
データは「適当なサイズの」部分(チャンクと呼ぶ)に分割し、それぞれに
ハッシュコードを求めファイル化する。
そのハッシュコードのリストと、ファイルについての説明(実際のファイル名
など)をひとまとめにしたものをキー情報とする。それ自体もハッシュコードを
求めて区別を可能とする。
ファイル方のノードからの検索に応えるのは、キー情報のみとする。つまり
「こういった存在ががあるらしい」という情報だけを伝える。
各ノードは実際の転送には、各チャンクのハッシュコードを指定することによって
転送を要求する。各ノードは他のノードに対して、自分が持っているハッシュ情報の
リストを提供することはしない。
実際の転送手順
１．ノードはファイル名の部分などによっての検索によって、キー情報のハッシュ
コードを手に入れる。もしくは他の方法によってハッシュコードを手に入れる(BBSなど)
２．ノードはキー情報のハッシュコードを使いキー情報を手に入れる(これは１と
セットでもかまわないかも)。
３．キー情報の中に保存されているハッシュコードのリストを使用して実際の情報を手に入れる。
データは「適当なサイズの」部分(チャンクと呼ぶ)に分割し、それぞれに
ハッシュコードを求めファイル化する。
そのハッシュコードのリストと、ファイルについての説明(実際のファイル名
など)をひとまとめにしたものをキー情報とする。それ自体もハッシュコードを
求めて区別を可能とする。
ファイル方のノードからの検索に応えるのは、キー情報のみとする。つまり
「こういった存在ががあるらしい」という情報だけを伝える。
各ノードは実際の転送には、各チャンクのハッシュコードを指定することによって
転送を要求する。各ノードは他のノードに対して、自分が持っているハッシュ情報の
リストを提供することはしない。
実際の転送手順
１．ノードはファイル名の部分などによっての検索によって、キー情報のハッシュ
コードを手に入れる。もしくは他の方法によってハッシュコードを手に入れる(BBSなど)
２．ノードはキー情報のハッシュコードを使いキー情報を手に入れる(これは１と
セットでもかまわないかも)。
３．キー情報の中に保存されているハッシュコードのリストを使用して実際の情報を手に入れる。
捏造データ対応のために
細かく分割されたチャンクはその内容に応じたハッシュコードを持っている。分割された
部分の転送を受けるだけで、その情報が正しい情報であるかを確認できる。また、ノードは
「ハッシュコードを指定して」転送を受けるため、ノードが必要としていないデータを受け付ける
ことは無い。
ノードはキー情報に基づきダウンロード中に、ダウンロードを取りやめることもできる。
ファイル名指定の地引ダウンロード時の設定として、不正であると指摘のあるファイルの
ダウンロードを行うか行わないかを設定できるようにしておくことが好ましい。
細かく分割されたチャンクはその内容に応じたハッシュコードを持っている。分割された
部分の転送を受けるだけで、その情報が正しい情報であるかを確認できる。また、ノードは
「ハッシュコードを指定して」転送を受けるため、ノードが必要としていないデータを受け付ける
ことは無い。
ノードはキー情報に基づきダウンロード中に、ダウンロードを取りやめることもできる。
ファイル名指定の地引ダウンロード時の設定として、不正であると指摘のあるファイルの
ダウンロードを行うか行わないかを設定できるようにしておくことが好ましい。
DOM対策のために
各ノードはデータを要求されたときに自ノードが必要とするデータを相手に要求する
ことができる。データが無いもしくは転送ができないといった応答を要求してきたノードが
する場合には転送速度を絞るなどして、データを受けるだけのノードは不利益を得る
構造とする。
また、１つ貰ったら２つ返すといった構造にしておくことによって、限界いっぱいまでの
転送が行われることを期待することもできる。当然、キャッチボールが中断した際には
優先は無くなる。
各ノードは他ノードからの要求があったハッシュコードを記録しておき、他のノードからの
転送要求に応じる際に、そのデータを要求することもできる。これによって他のノードから
要求される情報を自ノード内に溜め込み、その後の転送を有利に進めることができるよう
になる。もちろん自ノード自体が必要としているデータがあるのならばそれを優先することも
かまわないが、そのデータを相手のノードが持っていないときなど、他のノードが欲しがって
いた情報を代わりに受け取ることができる。
この構造によりデータ自体をトークン化し、キャッシュ自体に価値をもたせることができる。
各ノードはデータを要求されたときに自ノードが必要とするデータを相手に要求する
ことができる。データが無いもしくは転送ができないといった応答を要求してきたノードが
する場合には転送速度を絞るなどして、データを受けるだけのノードは不利益を得る
構造とする。
また、１つ貰ったら２つ返すといった構造にしておくことによって、限界いっぱいまでの
転送が行われることを期待することもできる。当然、キャッチボールが中断した際には
優先は無くなる。
各ノードは他ノードからの要求があったハッシュコードを記録しておき、他のノードからの
転送要求に応じる際に、そのデータを要求することもできる。これによって他のノードから
要求される情報を自ノード内に溜め込み、その後の転送を有利に進めることができるよう
になる。もちろん自ノード自体が必要としているデータがあるのならばそれを優先することも
かまわないが、そのデータを相手のノードが持っていないときなど、他のノードが欲しがって
いた情報を代わりに受け取ることができる。
この構造によりデータ自体をトークン化し、キャッシュ自体に価値をもたせることができる。
課題と問題点
チャンクのサイズをどれくらいにするか。
チャンクサイズが細かいほど情報の正当性をチェックするタイミングが短くなるが、
ファイルとして持つ場合細かくするほど無駄が発生する。
また、１つのファイルが複数のハッシュを持つことになると、ハッシュが与える
名前空間が足りなくなることも考えられる。
交換に値するチャンクを持っていないノードに対する制限をどれほどのものにするか。
あまりにゆるくては不利益を受け入れるものがでてくるかもしれないし、あまりに
きつくてはデータの転送の制限になる。
要求の多いファイルはよく流通するようになるが、レアなファイルは流れにくくなる。
これについては検索が効率よく働くようにして対策するより無い。
理屈が理屈どおり動くかを試すためにテストベンチを作成中だがデバッグに詰まって、
チト長文を。お目汚し失礼。
匿名性と交換に関する蛇足
効率よくやっているMXの交換のようなものだが、すべては自動で行われ、交換のネタと
するためのチャンクはそれ自体では意味を持たない。交換のネタは他のノードから受け
取ったで他の転送であるかも知れず、交換といっても受け取る情報のソースはそのノードとは
限らない。また、そのノードからすべてのチャンクをダウンロードできたとすると、それは
リクエストをしたノードの要求に応じるための行動をそのノードが起こした結果であり、その
ノードにそろったチャンクがあるとしてもそのノードが望んだことではなく要求に応えた結果でしかない。
チャンクのサイズをどれくらいにするか。
チャンクサイズが細かいほど情報の正当性をチェックするタイミングが短くなるが、
ファイルとして持つ場合細かくするほど無駄が発生する。
また、１つのファイルが複数のハッシュを持つことになると、ハッシュが与える
名前空間が足りなくなることも考えられる。
交換に値するチャンクを持っていないノードに対する制限をどれほどのものにするか。
あまりにゆるくては不利益を受け入れるものがでてくるかもしれないし、あまりに
きつくてはデータの転送の制限になる。
要求の多いファイルはよく流通するようになるが、レアなファイルは流れにくくなる。
これについては検索が効率よく働くようにして対策するより無い。
理屈が理屈どおり動くかを試すためにテストベンチを作成中だがデバッグに詰まって、
チト長文を。お目汚し失礼。
匿名性と交換に関する蛇足
効率よくやっているMXの交換のようなものだが、すべては自動で行われ、交換のネタと
するためのチャンクはそれ自体では意味を持たない。交換のネタは他のノードから受け
取ったで他の転送であるかも知れず、交換といっても受け取る情報のソースはそのノードとは
限らない。また、そのノードからすべてのチャンクをダウンロードできたとすると、それは
リクエストをしたノードの要求に応じるための行動をそのノードが起こした結果であり、その
ノードにそろったチャンクがあるとしてもそのノードが望んだことではなく要求に応えた結果でしかない。