5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

Linny開発プロジェクト Part2

1 :login:Penguin:03/06/22 19:40 ID:zhqumg4k
今までのP2Pファイル共有ソフトに負けない機能、手軽さ、匿名性を備えた
全く新しいWWWベースのファイル共有ソフトを作るプロジェクトです。

-------------------- 535 ◆HO0OFh2RXI 氏による最初の発言 --------------------
03/04/30 23:19
http://pc.2ch.net/test/read.cgi/linux/1024473956/535
> みんなでデーモンとして動くようなLinux版Winnyつくらない?
> デーモンとして動かなくてもコンソールで使えればいいです。
> どうでしょうか?自分は、Linux C(C++)プログラマーです。

前スレ
Linny開発プロジェクト
http://pc.2ch.net/test/read.cgi/linux/1053087824/

Project Page
http://linny.sourceforge.jp/

議論用Wiki
http://linny.sourceforge.jp/wiki/

※プロジェクト参加希望の方は535氏<burner@users.sourceforge.jp>まで連絡してください。
 また、本格的に参加する場合はSourceForge.jpのアカウントを取得してください。

244 :login:Penguin:03/12/04 02:10 ID:0dWBPS/h
ソフト開発出来る人、参加して下さい。オープンソースでの開発を目標にしています。

次期P2Pの仕様 part5
http://tmp2.2ch.net/test/read.cgi/download/1070113264/


245 :login:Penguin:03/12/04 02:10 ID:0dWBPS/h
age忘れました。

246 :login:Penguin:03/12/04 05:04 ID:AK3fWQow
>>244
コードは書けんが、テストなら協力できますよ

247 :login:Penguin:03/12/04 08:15 ID:LZsdqusC
>>244
アップはできんが、ダウンなら協力できますよ

248 :login:Penguin:03/12/06 16:41 ID:ASv9zxaf
典型的なプロジェクト失敗例を見せてくれたスレ

249 :login:Penguin:03/12/07 00:28 ID:1ZK45BnP
プロジェクトにすらなってないけどな

250 :login:Penguin:03/12/20 19:45 ID:uF39G1i3
http://mute-net.sourceforge.net/

> MUTE File Sharing is a new peer-to-peer network
> that provides easy search-and-download functionality while also protecting your privacy.
> MUTE protects your privacy by avoiding direct connections with
> your sharing partners in the network.

だそうです。

251 :login:Penguin:03/12/20 20:17 ID:orBV6cTG
http://pc.2ch.net/test/read.cgi/prog/1071794941/l50

252 :login:Penguin:03/12/21 00:53 ID:Tnk+ergb
>>250
これ、期待できそうです。

253 :login:Penguin:03/12/21 01:21 ID:7KaUReeK
で、251のスレでWinny2のソースらしきものが張られているわけだが・・・。

254 :login:Penguin:03/12/21 01:42 ID:UW66JoV+
>>253
ところで、パスワードは割りましたか?

255 :login:Penguin:03/12/22 05:22 ID:Fx01jsVP
>>254
ダウソすらできてないわけだが・・・。
どのプロキシ使えば落とせるのやら。

256 :login:Penguin:03/12/22 17:21 ID:C9mRSYV4
>>250 /.本家より

MUTE: Simple, Private File Sharing
http://slashdot.org/article.pl?sid=03/12/19/1750250

だそうだ

257 :login:Penguin:03/12/23 20:17 ID:UofXNrH/
蟻が食べ物を見付ける方法からインスピレーションを得たってなんか凄いな・・・


258 :login:Penguin:03/12/24 09:19 ID:p5RJmfHH
>>256
で、どうよ。使えそうか?
俺の環境(RedHat9)では固まりまくるが。

259 :login:Penguin:04/01/08 12:45 ID:91Mu2rfW
Mute Ver.0.2
http://mute-net.sourceforge.net/

Known issues with version 0.2:
Linux:
--Strange system-wide freeze on LinuxPPC. Happens when receiving
a series of connections (shows up in log). Freezes happen with both
text and GUI. Must be triggering a kernel crash (bug in kernel).
LinuxPPC kernel v2.2.15-2.9.0

--No crashes seen in Linux.

260 :login:Penguin:04/01/12 19:03 ID:H2XKicfm
age
がんばれ

261 :login:Penguin:04/01/14 00:07 ID:Qid/c1ot
俺もRedHat9ですが接続先を追加できないっぽいです

262 :login:Penguin:04/01/29 21:39 ID:gWkVseHH
ほしゅ

263 :login:Penguin:04/01/31 00:08 ID:PjoeMZsH
んでいつできるんだ?

264 :login:Penguin:04/02/04 10:13 ID:3zoKxviV
MUTEを日本語使えるようにすりゃいいじゃん。



265 :login:Penguin:04/02/11 23:48 ID:2/PKzn50
俺、linuxというかUnix版のWinny作ってるんだけど、
やっぱ公開すると、家宅捜索とかされちゃうのかな?

266 :login:Penguin:04/02/12 02:55 ID:gusrgYRS
そもそも君の場合は、コードが手元にない狂言なので、大丈夫かと。

267 :Seisei_Yamaguchi:04/02/15 02:29 ID:NKg64qLe
警察の中の人はソースが欲しかったから
ジオシティー日本から辿ったんとちゃう ?


268 :login:Penguin:04/02/17 20:23 ID:l3npdv3O
Winnyパケットをブロックするソフトが出たみたいだね。
age

269 :login:Penguin:04/02/18 11:15 ID:9aTdwy7Y
>>268
これのことだろ。
http://itpro.nikkeibp.co.jp/free/ITPro/NEWS/20040217/139906/
モニタしてるキャプ画像があるんだが、暗号は完全に解読された模様。
もうwineでwinny動かしてる場合じゃないぞ、おまいら。

270 :login:Penguin:04/02/18 12:14 ID:gem58jl9
これって暗号が解読されてるのかな…
あれだけだと、 winny network に偽の node として参加してるようにも見えるけど。
参加できれば、検索とかの query 読んで、その関連する packet 落とす…とかもできるだろうし。

271 :login:Penguin:04/02/18 13:47 ID:INzA8wD0
ふつーに、どこかの板に、不完全なソースコードが転がってます。
ソースコードの中には埋め込まれた暗号鍵も付いてます。

272 :login:Penguin:04/02/18 18:34 ID:ysm3TANi
Winny は相互接続する時に相手で本当に Winny が動作しているかどうかの確認
と、回線速度情報、クラスタワード を交換します。どうもその時の情報をデコー
ドするのに成功したようですね。通信内容は無理っぽい。

Netagent で公開されてる資料の13ページ見ると手がかりがありますな。


273 :login:Penguin:04/02/19 21:44 ID:YUXcILLr
どっちにしてもKとACCSは完全なソースを持っている。

274 :login:Penguin:04/02/27 19:11 ID:OzDpoA/F
もまいら、winnyはいよいよ駄目だぞ。
http://www.itmedia.co.jp/lifestyle/articles/0402/26/news078.html
暗号さえもっと強固なものだったら良かったのかね?

275 :login:Penguin:04/02/27 21:00 ID:WZTEm3ZQ
だから暗号と匿名性は無関係だとなんど言えば。


276 :login:Penguin:04/02/28 22:34 ID:S72mqHhA
>>275
>杉浦氏は、1個のパケットを見て、どこから来たものか解析することはある程度可能だと話す。
>「たどっていけば、1次配布先も分かるだろう」(杉浦氏)。
と言ってるからだと思われ。

ただ、
>「ソースコードを見たり、パケットを解析したりしながら、試行錯誤してデータを逆アセンブルしていった」(同氏)
最初は、ソースは入手していないメモリ解析と書かれていたと思うのだが
この辺の供述が曖昧な辺りが、この記事で発言している人物の信憑性に疑問を持たせる。


277 :login:Penguin:04/02/28 23:51 ID:WXc+IhON
>>276
まぁ、本人はその筋では結構有名な人だから、技術者としてはどっかの
ネットアークと較べればかなりまともな筈。

逆アセしたソースを見たと言ってたんじゃないかなぁ。データを逆アセ
するってのもなんか表現が変。この記者の信頼性もいまいちなので...

ttp://aki.nekoruri.jp/diary/200401c#D30_5



278 : ◆HO0OFh2RXI :04/02/29 06:48 ID:lTwPvcXw
原案
Winnyのオープンソース化を考えるスレ
http://winny.info/2ch/misc/1056020225.html
http://pc.2ch.net/test/read.cgi/linux/1056020225/354-

354案にいろいろと混ぜてみたものです。
細かいチャンクにする、通信にはコストがかかるとする、というのが基本です。
自分のUp/Downしたいものは隣のノードが欲しがっている/持っているとみなして行動。
Winnyの転送の多い時期で転送リンクブチブチ状態のイメージ。

やればやるほどFreenet…効率がとても悪そうです。
とりあえず置いておくんで好きにしてください。

279 :login:Penguin:04/02/29 06:49 ID:lTwPvcXw
☆ネットワークを流れる情報は、すべてにIDが振られた小さなチャンクに分割される。
 このIDは、内容により決められネットワーク上一意とする。
☆チャンクは2種類あり、書き換え可能なチャンクと内容が保護されたチャンクである。
 書き換え可能なチャンクを回覧板、内容が保護されたチャンクを小包と呼称する。
 ★回覧板チャンクのIDは、内容のテーマにより決められ、内容に関知しない。
 ★小包チャンクの内容は公開鍵暗号を使用し、暗号化する。
  そのIDは、暗号化済みの内容(鍵を含む)ともともとの内容の両方のハッシュに依存し、
  それぞれ確かめ得るようにする。
☆すべてのチャンクのやり取りにコストを設定する。
 正のコストのチャンクを受信すると、送信ノードに対し、送信債務が発生する。
 要するにUpしてもらえる権ということです。
 コストは、取引開始側が設定し、取引了承側が認証する。負のコストも許される。
 言い値で決まるが、不満であれば取引が成立しない。
 虚偽の取引を行った場合は直ちにリンクを切断し、以降の取引は行われない。
 すべてのノードは、送信債務という借金状態を解消しようとすることが要請される。
 つまり基本的にはDownすればUpすることが要請されます。
 あるノードが借り逃げを行った場合、または著しい債務超過に陥った場合、
 悪質ノードとして切断し、以降の接続を一定期間禁止する。
 大きい値のコストの取引は、取引実績ができるまで行われない。

☆ファイルを流す際は、適当なサイズに分割しそれぞれを小包チャンクとする。
 それぞれの小包のIDとその鍵のリスト、及び元のファイルの識別情報(ファイル名、元ハッシュなど)を
 まとめて小包チャンクとし、フックチャンクとする。
 このフックチャンクはWinnyでいうところの仮想キーに相当するヘッダ部分である。
★フックチャンクは、自ノードでは特別に処理が行われ、元ファイルの識別情報と対応がつけられている。
 外部に対しては、直接指定された場合は単なる小包チャンクとして振る舞う


280 :login:Penguin:04/02/29 06:49 ID:lTwPvcXw
☆チャンク情報の拡散
 検索ワードを指定した回覧板チャンクをつくり、これを検索チャンクとする。
 検索チャンクには、指定ワードと関連するファイルの、元ファイル識別識別情報とフックチャンクIDのセットが
 リストになって入れてある。
 受け取ったノードは、リストをフックチャンクプールに格納し、自分の情報を混ぜた上で再び検索チャンクを形成し
 隣接ノードに転送する

☆チャンクの予約
 タグワードを指定した回覧板チャンクをつくり、これをオークションチャンクとする。
 オークションチャンクには、要求チャンクIDと取引成立時の予定コストとUp/Downのリストが入れてある。
 受け取ったノードは、リストを来たノードをマークした上でオークションチャンクプールに格納する。
 自らのダウン予約の都合を考えて、オークションチャンクを入れ替え、隣接ノードに転送する。

☆チャンクの取引
 オークションチャンクの情報を元に、Up/Downの要求が一致すれば、送ってきた隣接ノードに取引要求する。
 要求内容は、対象チャンクID・Up/Downの別・成立時の支払いコストとする。
 要求を受け取ったノードは、以下の3つから行動を選ぶ
  ★要求を受諾し、チャンクを移動し、完了後コストが移動される。
  ★要求を拒絶する。
  ★要求は拒否するが、他のノードを紹介する。
 検索チャンク、オークションチャンクも同様に扱う。


281 :login:Penguin: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:04/02/29 06:51 ID:lTwPvcXw
<検索およびオークションチャンクの転送経路>
☆タグまたは検索ワードと、クラスタ化キーワードとの優先度比較で大きいノードに転送されやすくする。
☆送ってきたノードに直接返してはいけない。(取引の不正を防ぐため)
☆チャンク転送利益を得られないほどコストの絶対値の下がった、自分に不要なチャンクは破棄してよい。

<ノードの接続条件、切断条件>
(考え中)
☆クラスタワード制により、意図的に移動できるようなネットワーク距離を導入し、
 近いノードに優先接続する
☆取引実績のあるノードは優先する
☆取引に嘘ついたノードは即切断、(覚えていられる限り)二度と許さない。(周りに伝達するかも)
☆取引がこちらの赤字の場合できるだけ切断しない
☆(主観基準の)大規模な借り逃げは、以降の接続を蹴る。(周りに伝達するかも)
☆ある程度の借りっぱは、次に接続した時に払ってもらう。動的IPの誤爆は気にしない。
☆小規模な貸し借りは、水に流す。
☆貸している側はいつでも切断できる。


283 :login:Penguin:04/02/29 06:51 ID:lTwPvcXw
<利点>
☆2者間の通信のみで、不正ノードを判定できる。
☆部分キャッシュであるチャンクに価値をもたせられる。
☆チャンクそれ自体は、単独で意味を持たない。
☆チャンクの取引コストを、信頼度、優先度として準用できる。
☆チャンクを所持していることは、内容を知って公開していることを意味しない。
 (中の人の判断基準は取引に有用であるかどうかのみ)

<問題点>
★大きいファイルの時チャンクが揃わない可能性。
★ネットワーク上の自分とその周りのノードが興味を持つチャンクすべてを把握する必要がある。
★膨大な数のチャンクの取引の必要があり、ネットワークが飽和する危険がある。
★検索がかけにくい。
★同一ファイル複数キャッシュ問題。暗号化キーが異なるチャンクは互換でない。


284 :補足考察:04/02/29 06:52 ID:lTwPvcXw
★ネットワーク的に価値をもたないチャンクの排除
 フックチャンクの場合(ファイル名詐称など)は、無視リストを使用して所持しない、転送しない。
 優良フックチャンクを高く評価し(取引コストを上げる)、相対的に排除。
 平チャンクの場合、内容の評価は不可能。高値で取引できるのなら、中身については関知しない。
 ゴミチャンクは意図的にDownをかける香具師がいない限り、コスト値が高いまま取引されることはない。
 ローカルでチャンクの保持基準をコスト評価値と最終アクセス時を元に決めればそのうち消える。

★高い評価のゴミチャンクの可能性
 自作自演によって可能。たとえ自分が騙されても、他に騙されるやつがいる限り
 被害はない。平チャンクがどこのファイルの所属なのかをたどる方法は存在しないので、
 アクセスがある限り消えることがない。
 消える可能性は、Winnyでいうところの完全キャッシュのみにする操作をノードが
 行うであろうこと。
 HDDに余裕があるのならどうぞ飼ってやってください。

★優先度の詐称
 高値のチャンクをUpすることが一番効率のよい方法。

★接続ノード限界
 Upするノードの不足がもたらす。落としたいファイルを持つノードの優先接続条件に
 適合するようにすれば回避できる。つまり熱心に奉仕汁


285 :login:Penguin:04/02/29 06:53 ID:lTwPvcXw
★初期開放ノードの隠蔽、その必要性
 フックチャンクが出回らない限り、平チャンクのアクセスは困難。
 そのため、どうしても身元を隠蔽したいデータをUpする際は、自作自演をかけ
 周りにチャンク単独での価値を知らしめ、拡散した後、フックチャンクを公開する。
 自作自演にはコストがかかるので、どうしてもの時だけに。
 Down要求を蹴って他のノードに回して、かつ、その他ノードに対しUp要求をかけると
 隠蔽できるかも。

★Port0(外部からの接続不可)の取り扱い
 未定

★大量のファイルの保持者の負荷
 チャンクの要求があったとき、所持チャンクから検索しなければならない。
 ファイルをネットワークに投入する際、ハッシュ計算で時間がかかる。

★IPをさらした上での匿名性
 隣接ノードがUp要求をかけた際に、所持チャンクが確定できる。
 ただし、これはファイルの所持に直結しない。


286 :login:Penguin:04/02/29 06:53 ID:lTwPvcXw
★IPの変わる常時Up優良ノードの取り扱い
 あまり長時間同一ノードと取引することは推奨されない、ノードの評価の保持は
 一定期間であるということから、固定IPと比べ不利益はない

★繋ぎなおしでマイナス評価が消える
 ネットワークへの接続はかなり厳しいものとなっているので、取引に必要な
 評価を得ることへの手間がペナルティとなる

★途中の中継ノードによる、検索キーの捏造/改竄
 IDは内容のハッシュを元にするので、破損として処理する。
 破損チャンクは取引成立ではないのでリトライが強制される。

★ファイル名の詐称
 フックチャンクの評価値により排除をする

★クラスタ位置を変えることによる評価の消滅
 クラスタにとって有用でないノードはいらないと考える。
 たとえ別クラスタで有用であったとしても、それはそれこれはこれ。

★流通するキーの一覧を作成することによる危険
 目安になることは確かであるが、実際に完成するまで本当に存在するかは確定できない。


287 :login:Penguin:04/02/29 07:46 ID:KT/zUJUZ
おお!? Linnyプロジェクト再起動か!?

288 :login:Penguin:04/03/01 21:27 ID:rhb6VIeO
すでにバッテリーもへたってるから、腐った燃料では動きもしない・・・と。

289 :login:Penguin:04/03/02 00:45 ID:9lmYd62z
>>278-286 まで読んで見たものの、言葉だけではボンヤリとコンセプトだけで
具体的な手続きの順序とか、階層とかそういったものが共有できない…
それぞれ得意な分野を分担して実装すれば、ソース公開の意味があって
いいと思うんだけど、誰が何から実装するのかという、
最初の取っ掛かりがあればねえ。

俺も含めて他力本願なんだろうけど。

290 :login:Penguin:04/03/02 02:33 ID:9lmYd62z
次期P2Pの仕様 part9
http://tmp2.2ch.net/test/read.cgi/download/1075400646/

需要として参考になるのかな。

291 :login:Penguin:04/03/02 23:46 ID:j+7Rtc66
freenetのNGRが良い感じ。

292 :login:Penguin:04/03/09 02:54 ID:lz/xxrRp
>>290
ちょうど今、これ>>278-286と似たようなことが話題になってるな。
サーバを置くのが効率的には絶対にいいと思うんだけど、いろいろと問題ありそう。

eDonkeyが価値評価を導入してるらしい。参考になるかな

293 :login:Penguin:04/03/13 02:35 ID:it57ICZi
せっかく>>290のスレで課金可能性について論じられていたので278案での実現可能性について書いておきます。

ネットワーク内で使用している取引コストとして、現実世界のお金を使用することで課金できると思います。
ただしこの場合、信頼できる通貨サーバが必要ですが。

内容は暗号化し、ネットワークに流しておきます。
フックチャンクを2種類用意し、1つは集めることはできるが復号はできないもの(不完全フックチャンク)、
もう1つは復号できるもの(完全フックチャンク)とします。
不完全フックチャンクは通常と同じに流通させますが、完全フックチャンクは特殊な取引によってのみ流通させます。
内容が欲しいノードは、通常の手順で不完全フックチャンクを元に、パーツをそろえます。
次に、完全フックチャンクを持っているノードと、通貨サーバと通信できる状態にします。
チャンクの取引には、通常だと取引コストとしてDown権を渡すわけですが、完全フックチャンクの取引には
通貨サーバによる支払い証明を取引コストとして渡すことになります。

この取引において、完全フックチャンクを所持しているノードが正規の手続きなしに流してしまうと
そのファイルに対する課金が崩壊してしまいます。
転送報奨としていくらか分け前を与えるとか、完全フックチャンクに所持ノードIDを書いておくとかしか
思いつかないんで、他にもっといい方法があるかも。

75 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)