- 1 名前：login:Penguin mailto:sage [03/06/22 19:40 ID:zhqumg4k]
- 今までのP2Pファイル共有ソフトに負けない機能、手軽さ、匿名性を備えた
全く新しいWWWベースのファイル共有ソフトを作るプロジェクトです。
-------------------- 535 ◆HO0OFh2RXI 氏による最初の発言 --------------------
03/04/30 23:19
pc.2ch.net/test/read.cgi/linux/1024473956/535
> みんなでデーモンとして動くようなLinux版Winnyつくらない？
> デーモンとして動かなくてもコンソールで使えればいいです。
> どうでしょうか？自分は、Linux C(C++)プログラマーです。
前スレ
Linny開発プロジェクト
pc.2ch.net/test/read.cgi/linux/1053087824/
Project Page
linny.sourceforge.jp/
議論用Wiki
linny.sourceforge.jp/wiki/
※プロジェクト参加希望の方は535氏<burner@users.sourceforge.jp>まで連絡してください。
また、本格的に参加する場合はSourceForge.jpのアカウントを取得してください。
- 278 名前： ◆HO0OFh2RXI mailto:sage [04/02/29 06:48 ID:lTwPvcXw]
- 原案
Winnyのオープンソース化を考えるスレ
winny.info/2ch/misc/1056020225.html
pc.2ch.net/test/read.cgi/linux/1056020225/354-
354案にいろいろと混ぜてみたものです。
細かいチャンクにする、通信にはコストがかかるとする、というのが基本です。
自分のUp/Downしたいものは隣のノードが欲しがっている/持っているとみなして行動。
Winnyの転送の多い時期で転送リンクブチブチ状態のイメージ。
やればやるほどFreenet…効率がとても悪そうです。
とりあえず置いておくんで好きにしてください。
- 279 名前：login:Penguin mailto:sage [04/02/29 06:49 ID:lTwPvcXw]
- ☆ネットワークを流れる情報は、すべてにIDが振られた小さなチャンクに分割される。
このIDは、内容により決められネットワーク上一意とする。
☆チャンクは2種類あり、書き換え可能なチャンクと内容が保護されたチャンクである。
書き換え可能なチャンクを回覧板、内容が保護されたチャンクを小包と呼称する。
★回覧板チャンクのIDは、内容のテーマにより決められ、内容に関知しない。
★小包チャンクの内容は公開鍵暗号を使用し、暗号化する。
そのIDは、暗号化済みの内容(鍵を含む)ともともとの内容の両方のハッシュに依存し、
それぞれ確かめ得るようにする。
☆すべてのチャンクのやり取りにコストを設定する。
正のコストのチャンクを受信すると、送信ノードに対し、送信債務が発生する。
要するにUpしてもらえる権ということです。
コストは、取引開始側が設定し、取引了承側が認証する。負のコストも許される。
言い値で決まるが、不満であれば取引が成立しない。
虚偽の取引を行った場合は直ちにリンクを切断し、以降の取引は行われない。
すべてのノードは、送信債務という借金状態を解消しようとすることが要請される。
つまり基本的にはDownすればUpすることが要請されます。
あるノードが借り逃げを行った場合、または著しい債務超過に陥った場合、
悪質ノードとして切断し、以降の接続を一定期間禁止する。
大きい値のコストの取引は、取引実績ができるまで行われない。
☆ファイルを流す際は、適当なサイズに分割しそれぞれを小包チャンクとする。
それぞれの小包のIDとその鍵のリスト、及び元のファイルの識別情報（ファイル名、元ハッシュなど）を
まとめて小包チャンクとし、フックチャンクとする。
このフックチャンクはWinnyでいうところの仮想キーに相当するヘッダ部分である。
★フックチャンクは、自ノードでは特別に処理が行われ、元ファイルの識別情報と対応がつけられている。
外部に対しては、直接指定された場合は単なる小包チャンクとして振る舞う
- 280 名前：login:Penguin mailto:sage [04/02/29 06:49 ID:lTwPvcXw]
- ☆チャンク情報の拡散
検索ワードを指定した回覧板チャンクをつくり、これを検索チャンクとする。
検索チャンクには、指定ワードと関連するファイルの、元ファイル識別識別情報とフックチャンクIDのセットが
リストになって入れてある。
受け取ったノードは、リストをフックチャンクプールに格納し、自分の情報を混ぜた上で再び検索チャンクを形成し
隣接ノードに転送する
☆チャンクの予約
タグワードを指定した回覧板チャンクをつくり、これをオークションチャンクとする。
オークションチャンクには、要求チャンクIDと取引成立時の予定コストとUp/Downのリストが入れてある。
受け取ったノードは、リストを来たノードをマークした上でオークションチャンクプールに格納する。
自らのダウン予約の都合を考えて、オークションチャンクを入れ替え、隣接ノードに転送する。
☆チャンクの取引
オークションチャンクの情報を元に、Up/Downの要求が一致すれば、送ってきた隣接ノードに取引要求する。
要求内容は、対象チャンクID･Up/Downの別･成立時の支払いコストとする。
要求を受け取ったノードは、以下の3つから行動を選ぶ
★要求を受諾し、チャンクを移動し、完了後コストが移動される。
★要求を拒絶する。
★要求は拒否するが、他のノードを紹介する。
検索チャンク、オークションチャンクも同様に扱う。
- 281 名前：login:Penguin mailto:sage [04/02/29 06:50 ID:lTwPvcXw]
- ＜データ入手までの流れ＞
ファイル名 →フックチャンクプールから検索(なければ検索チャンクで底引き)
→フックチャンクをオークションチャンクで予約→取引成立すればDown→展開
→内容チャンクを順次オークションチャンクで予約→取引成立チャンクからDown
→すべて揃い次第元に戻す
＜オークションチャンクと取引コスト＞
☆あるチャンクが欲しい時、大きいコストを設定してDown予約をかけると、
成立の可能性が高くなる。
所持ノードがUpしたときの利益が大きいので応じることが予想されるからである。
しかし、あまり大きいと新参者小取引の原則により無視される。
また、中間ノードが中継して(もっと小さいコストで元ノードから入手し)利益を得ようと
するので効率が悪くなる。
☆あるチャンクのDown予約が隣から流れてきた時、そのノードに対して債務がある場合、
自ら率先してそのチャンクを入手することが望まれる。
先に手に入れることができれば、そのノードに対しUpを行い借りを返すことができるからである。
☆オークションチャンクの転送時に予定コストを書き換えることで、転送利益を得ることができる。
☆あるチャンクが欲しい場合、Downで正のコストを設定する。
誰かが欲しがっているチャンクをUpする場合、Upで正のコストを設定する。
オークションチャンク、検索チャンクなどのどうしても受け取って欲しいチャンクを
Upする場合、Upで負のコストを設定する。
☆負のコストのUpを利用して、仮想アドレスタグをつけた小包チャンクを投げることで
IMのようなノード間通信が可能かも。
このとき、間のノードはコストの絶対値を少しずつ減じていくことで、利益を得ることが
できるのでコストに対し十分近ければ届く。
★所持チャンクのコスト評価値
Upする時のコスト目標値。有用だと自らが判断するチャンクに対しては高くつけておく。
需要が多ければ上げ、なければ下げる(でないとDownする人がいない)。
- 282 名前：login:Penguin mailto:sage [04/02/29 06:51 ID:lTwPvcXw]
- ＜検索およびオークションチャンクの転送経路＞
☆タグまたは検索ワードと、クラスタ化キーワードとの優先度比較で大きいノードに転送されやすくする。
☆送ってきたノードに直接返してはいけない。(取引の不正を防ぐため)
☆チャンク転送利益を得られないほどコストの絶対値の下がった、自分に不要なチャンクは破棄してよい。
＜ノードの接続条件、切断条件＞
(考え中)
☆クラスタワード制により、意図的に移動できるようなネットワーク距離を導入し、
近いノードに優先接続する
☆取引実績のあるノードは優先する
☆取引に嘘ついたノードは即切断、(覚えていられる限り)二度と許さない。(周りに伝達するかも)
☆取引がこちらの赤字の場合できるだけ切断しない
☆(主観基準の)大規模な借り逃げは、以降の接続を蹴る。(周りに伝達するかも)
☆ある程度の借りっぱは、次に接続した時に払ってもらう。動的IPの誤爆は気にしない。
☆小規模な貸し借りは、水に流す。
☆貸している側はいつでも切断できる。
- 283 名前：login:Penguin mailto:sage [04/02/29 06:51 ID:lTwPvcXw]
- ＜利点＞
☆2者間の通信のみで、不正ノードを判定できる。
☆部分キャッシュであるチャンクに価値をもたせられる。
☆チャンクそれ自体は、単独で意味を持たない。
☆チャンクの取引コストを、信頼度、優先度として準用できる。
☆チャンクを所持していることは、内容を知って公開していることを意味しない。
(中の人の判断基準は取引に有用であるかどうかのみ)
＜問題点＞
★大きいファイルの時チャンクが揃わない可能性。
★ネットワーク上の自分とその周りのノードが興味を持つチャンクすべてを把握する必要がある。
★膨大な数のチャンクの取引の必要があり、ネットワークが飽和する危険がある。
★検索がかけにくい。
★同一ファイル複数キャッシュ問題。暗号化キーが異なるチャンクは互換でない。
- 284 名前：補足考察 mailto:sage [04/02/29 06:52 ID:lTwPvcXw]
- ★ネットワーク的に価値をもたないチャンクの排除
フックチャンクの場合(ファイル名詐称など)は、無視リストを使用して所持しない、転送しない。
優良フックチャンクを高く評価し(取引コストを上げる)、相対的に排除。
平チャンクの場合、内容の評価は不可能。高値で取引できるのなら、中身については関知しない。
ゴミチャンクは意図的にDownをかける香具師がいない限り、コスト値が高いまま取引されることはない。
ローカルでチャンクの保持基準をコスト評価値と最終アクセス時を元に決めればそのうち消える。
★高い評価のゴミチャンクの可能性
自作自演によって可能。たとえ自分が騙されても、他に騙されるやつがいる限り
被害はない。平チャンクがどこのファイルの所属なのかをたどる方法は存在しないので、
アクセスがある限り消えることがない。
消える可能性は、Winnyでいうところの完全キャッシュのみにする操作をノードが
行うであろうこと。
HDDに余裕があるのならどうぞ飼ってやってください。
★優先度の詐称
高値のチャンクをUpすることが一番効率のよい方法。
★接続ノード限界
Upするノードの不足がもたらす。落としたいファイルを持つノードの優先接続条件に
適合するようにすれば回避できる。つまり熱心に奉仕汁
- 285 名前：login:Penguin mailto:sage [04/02/29 06:53 ID:lTwPvcXw]
- ★初期開放ノードの隠蔽、その必要性
フックチャンクが出回らない限り、平チャンクのアクセスは困難。
そのため、どうしても身元を隠蔽したいデータをUpする際は、自作自演をかけ
周りにチャンク単独での価値を知らしめ、拡散した後、フックチャンクを公開する。
自作自演にはコストがかかるので、どうしてもの時だけに。
Down要求を蹴って他のノードに回して、かつ、その他ノードに対しUp要求をかけると
隠蔽できるかも。
★Port0(外部からの接続不可)の取り扱い
未定
★大量のファイルの保持者の負荷
チャンクの要求があったとき、所持チャンクから検索しなければならない。
ファイルをネットワークに投入する際、ハッシュ計算で時間がかかる。
★IPをさらした上での匿名性
隣接ノードがUp要求をかけた際に、所持チャンクが確定できる。
ただし、これはファイルの所持に直結しない。
- 286 名前：login:Penguin mailto:sage [04/02/29 06:53 ID:lTwPvcXw]
- ★IPの変わる常時Up優良ノードの取り扱い
あまり長時間同一ノードと取引することは推奨されない、ノードの評価の保持は
一定期間であるということから、固定IPと比べ不利益はない
★繋ぎなおしでマイナス評価が消える
ネットワークへの接続はかなり厳しいものとなっているので、取引に必要な
評価を得ることへの手間がペナルティとなる
★途中の中継ノードによる、検索キーの捏造/改竄
IDは内容のハッシュを元にするので、破損として処理する。
破損チャンクは取引成立ではないのでリトライが強制される。
★ファイル名の詐称
フックチャンクの評価値により排除をする
★クラスタ位置を変えることによる評価の消滅
クラスタにとって有用でないノードはいらないと考える。
たとえ別クラスタで有用であったとしても、それはそれこれはこれ。
★流通するキーの一覧を作成することによる危険
目安になることは確かであるが、実際に完成するまで本当に存在するかは確定できない。
|
 |
