次期P2Pの仕様 part8
1 ：[名無し]さん(bin+cue).rar：
#次世代P2Pの仕様を話し合うスレです。
このスレのまとめサイト（Wikiへの直リンク禁止）
http://s2net.s41.xrea.com/
過去ログ等を置いてある簡易まとめサイト
http://2.csx.jp/~p2p/
前スレ Part7
http://tmp2.2ch.net/test/read.cgi/download/1070647427/
関連
次期P2Pのクリアすべき課題を法的な観点から考察（Part2）
http://tmp2.2ch.net/test/read.cgi/download/1070500722/
次期P2Pに対する要望スレ
http://tmp2.2ch.net/test/read.cgi/download/1070085137/
P2P総合
http://pc2.2ch.net/test/read.cgi/tech/1048668198/
次世代P2Pの名前を考えるスレ
http://tmp2.2ch.net/test/read.cgi/download/1069996070/
850レスを超えたら、次スレの準備をする為に、議論を一時中断して下さい。
あと、スレ住人はキシュツに敏感なので必ずテンプレ、過去ログ嫁
荒らし、煽り、過去ログ等読まない奴は放置。
またーり下げ進行でお願いします。
テンプレは
>>2-20
#---------------------------------------------------------#
このスレのまとめサイト（Wikiへの直リンク禁止）
http://s2net.s41.xrea.com/
過去ログ等を置いてある簡易まとめサイト
http://2.csx.jp/~p2p/
前スレ Part7
http://tmp2.2ch.net/test/read.cgi/download/1070647427/
関連
次期P2Pのクリアすべき課題を法的な観点から考察（Part2）
http://tmp2.2ch.net/test/read.cgi/download/1070500722/
次期P2Pに対する要望スレ
http://tmp2.2ch.net/test/read.cgi/download/1070085137/
P2P総合
http://pc2.2ch.net/test/read.cgi/tech/1048668198/
次世代P2Pの名前を考えるスレ
http://tmp2.2ch.net/test/read.cgi/download/1069996070/
850レスを超えたら、次スレの準備をする為に、議論を一時中断して下さい。
あと、スレ住人はキシュツに敏感なので必ずテンプレ、過去ログ嫁
荒らし、煽り、過去ログ等読まない奴は放置。
またーり下げ進行でお願いします。
テンプレは
>>2-20
#---------------------------------------------------------#
|
|
|
2 ：[名無し]さん(bin+cue).rar：03/12/15 03:56 ID:uN02Bxt9
2
3 ：[名無し]さん(bin+cue).rar：03/12/15 04:04 ID:wGENn+sO
1, こ こ は "仕 様" を 決 め る ス レ ッ ド で す。
→ 実装 法律 に関しては、他のスレッドでお願いします。
2, 単発のアイデアは良く考えてから、カキコしてください。
十中八九、ｶﾞｲｼｭﾂとかスレ違いとかﾋﾟﾝﾄはずれと言われちゃいます。」
UDP/コネクションレス/IP偽装/コネクションハイジャック…は、既出。
3, Mac版は？ Unix / Linux / BSD 版は？
→ 次期Winnyでは一般的なプラットフォームをターゲットにしていますので
→ Unix板 Linux板 Mac板の方もアイディア・技術提供、宜しくお願い致します。
しかし、要望スレに自己主張してくれないと反映されないかも知れません。
※【神】UNIXにWinnyを移植【降臨】 http://pc.2ch.net/test/read.cgi/unix/1065863581/
※Linny開発プロジェクト Part2 http://pc.2ch.net/test/read.cgi/linux/1056278411/
4, 「現時点で組み始めたいんだけど」
→ まだ仕様が決まっていないので、余り先走らないで下さい。
→ しかし検証コード・テストコードを書くのは推奨しています。
5, 今回のﾀｲｰﾎは別件逮捕だと聞いたけど？
→ ガセ。Winnyが解析された可能性がある。
6, IPの偽装はできないのか？
→ 現実的ではない。
7, ソフト名を決めずに、検索エンジン等でかからなくするのが良い・ソフト名を放送禁止用語にすれ
→ モノができてから考えれ。
→ 実装 法律 に関しては、他のスレッドでお願いします。
2, 単発のアイデアは良く考えてから、カキコしてください。
十中八九、ｶﾞｲｼｭﾂとかスレ違いとかﾋﾟﾝﾄはずれと言われちゃいます。」
UDP/コネクションレス/IP偽装/コネクションハイジャック…は、既出。
3, Mac版は？ Unix / Linux / BSD 版は？
→ 次期Winnyでは一般的なプラットフォームをターゲットにしていますので
→ Unix板 Linux板 Mac板の方もアイディア・技術提供、宜しくお願い致します。
しかし、要望スレに自己主張してくれないと反映されないかも知れません。
※【神】UNIXにWinnyを移植【降臨】 http://pc.2ch.net/test/read.cgi/unix/1065863581/
※Linny開発プロジェクト Part2 http://pc.2ch.net/test/read.cgi/linux/1056278411/
4, 「現時点で組み始めたいんだけど」
→ まだ仕様が決まっていないので、余り先走らないで下さい。
→ しかし検証コード・テストコードを書くのは推奨しています。
5, 今回のﾀｲｰﾎは別件逮捕だと聞いたけど？
→ ガセ。Winnyが解析された可能性がある。
6, IPの偽装はできないのか？
→ 現実的ではない。
7, ソフト名を決めずに、検索エンジン等でかからなくするのが良い・ソフト名を放送禁止用語にすれ
→ モノができてから考えれ。
4 ：[名無し]さん(bin+cue).rar：03/12/15 04:04 ID:Wq+SeEp1
２ちゃんねるにおけるDownload板のレベルの推移
┃ / （尚も上昇中）
神┃ /
┃ /
┃ │
高┃ /
┃ /
┃ │
中┃ │
┃ /
┃ │
低┃ │
┃ ／
┃ ／
厨┃ ＿ ＿＿＿／
┃＿＿＿＿＿＿＿＿／ ＼＿＿＿／
━╋━━━━━━┳━━━━━━┳━━━━━━┳━━━
年┃ ２ ０ ０ ０ ┃ ２ ０ ０ １ ┃ ２ ０ ０ ２ ┃２００３
↑
さくらたんスレの誕生
WPNP閉鎖や逮捕に対する恐怖で困惑していたダウンロード板に現れた天使、さくらたんによって
以前は割れ厨の巣窟と言われていたダウンロード板をここまで救済しました。
おかげでダウソ板はいまやどんな板にも引けを取らぬ高度な知識、技術力、モラルを備えています。
┃ / （尚も上昇中）
神┃ /
┃ /
┃ │
高┃ /
┃ /
┃ │
中┃ │
┃ /
┃ │
低┃ │
┃ ／
┃ ／
厨┃ ＿ ＿＿＿／
┃＿＿＿＿＿＿＿＿／ ＼＿＿＿／
━╋━━━━━━┳━━━━━━┳━━━━━━┳━━━
年┃ ２ ０ ０ ０ ┃ ２ ０ ０ １ ┃ ２ ０ ０ ２ ┃２００３
↑
さくらたんスレの誕生
WPNP閉鎖や逮捕に対する恐怖で困惑していたダウンロード板に現れた天使、さくらたんによって
以前は割れ厨の巣窟と言われていたダウンロード板をここまで救済しました。
おかげでダウソ板はいまやどんな板にも引けを取らぬ高度な知識、技術力、モラルを備えています。
5 ：[名無し]さん(bin+cue).rar：03/12/15 04:08 ID:Wq+SeEp1
～～２０００ ナップスター流行
２０００後期 MX登場
２００１ MX流行りだす、２ｃｈ、各種雑誌の特集
２００１、１０ ネットランナーの暴走加速化、表紙が「TVアイドル」から「ちゆ１２歳」に
２００２，４ MXで逮捕者、同時に世界初のP2P逮捕者であり全宇宙騒然
２００２，５ Winny誕生
２００２，６ Windy誕生
２００３，４ Winny1開発停止
２００３，５ Winny2β開発開始
２００３，１１ Winny2で逮捕者
２００３、１２ 次期P2Pの仕様 part76 でWindy2誕生
２０００後期 MX登場
２００１ MX流行りだす、２ｃｈ、各種雑誌の特集
２００１、１０ ネットランナーの暴走加速化、表紙が「TVアイドル」から「ちゆ１２歳」に
２００２，４ MXで逮捕者、同時に世界初のP2P逮捕者であり全宇宙騒然
２００２，５ Winny誕生
２００２，６ Windy誕生
２００３，４ Winny1開発停止
２００３，５ Winny2β開発開始
２００３，１１ Winny2で逮捕者
２００３、１２ 次期P2Pの仕様 part76 でWindy2誕生
6 ：[名無し]さん(bin+cue).rar ：03/12/15 04:09 ID:Rx4NNvI5
>>1
乙ー
乙ー
7 ：[名無し]さん(bin+cue).rar：03/12/15 04:10 ID:wGENn+sO
8, 特定のIP（ACCSとかJASRACとか）は、拒否する設定が良い
→ 一般のプロバイダが用いられた捜査に対して全く無意味。
9, 作者の身元を隠さなくていいのか？
→ 後で（公開の段階で）考えるべし。現状何もできてないので問題ない。
※今回の件から推測すると、実装し頒布した場合の作者さんは、
家 宅 捜 索 等 の 危 険 も 大 き い の で 決 し て 身 元 を 明 か さ ぬ 様 に、
書き込み・垢の取得に"充分"気を付けて下さい。
早い話、2chで「作るyo!」・「ﾃﾞｷﾀｰ!!」と言ったら、
「将来、逮捕・家宅捜索される危険がありますよ」って事。
10, K察・ACCSは使用禁止にしよう
. ・雑誌掲載を禁止しよう
. ・初心者には容易に使えないソフトが良い、
. ・初期設定を難しくしよう、等
→ 後で（公開の段階で）考えるべし。公開直前にでも何とかなる。
→ また現実問題、スレのＵＲＬの転載を止める手段はない。
11, 通信径路上でのデータの暗号化にはＸＸが良い
. ・「鍵は～～で流すのが良い」等 暗号関連
→ 暗号化はあくまでもプロバイダに特定されないためのもので、問題の本質ではない。
→ 例えば相手ノードが警察のＰＣだった場合などは、あらゆる暗号化は無意味。
→ どちらかというと、責任逃れの方法を考えなければならない
→ 一般のプロバイダが用いられた捜査に対して全く無意味。
9, 作者の身元を隠さなくていいのか？
→ 後で（公開の段階で）考えるべし。現状何もできてないので問題ない。
※今回の件から推測すると、実装し頒布した場合の作者さんは、
家 宅 捜 索 等 の 危 険 も 大 き い の で 決 し て 身 元 を 明 か さ ぬ 様 に、
書き込み・垢の取得に"充分"気を付けて下さい。
早い話、2chで「作るyo!」・「ﾃﾞｷﾀｰ!!」と言ったら、
「将来、逮捕・家宅捜索される危険がありますよ」って事。
10, K察・ACCSは使用禁止にしよう
. ・雑誌掲載を禁止しよう
. ・初心者には容易に使えないソフトが良い、
. ・初期設定を難しくしよう、等
→ 後で（公開の段階で）考えるべし。公開直前にでも何とかなる。
→ また現実問題、スレのＵＲＬの転載を止める手段はない。
11, 通信径路上でのデータの暗号化にはＸＸが良い
. ・「鍵は～～で流すのが良い」等 暗号関連
→ 暗号化はあくまでもプロバイダに特定されないためのもので、問題の本質ではない。
→ 例えば相手ノードが警察のＰＣだった場合などは、あらゆる暗号化は無意味。
→ どちらかというと、責任逃れの方法を考えなければならない
8 ：[名無し]さん(bin+cue).rar：03/12/15 04:13 ID:wGENn+sO
12, 「**機能付きにしる！」・「インターフェイスは**！」
→ それ専用のスレッドが御座いますので、そちらに書き込んで頂くか
→ プログラム組む時(実装時・設計時)に、再度お願いします。 項目14も参考に読む事。
※次期P2Pに対する要望スレ http://tmp2.2ch.net/test/read.cgi/download/1070085137/
13, これ作っても違法なんじゃないの？
→ 法的な問題については専用のスレッドが御座いますので、そちらにお願いいたします。
→ そちらでは現在、法律に詳しい方を探しています。
※次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070084504/
14, 基本部分をプラグイン・ライブラリの形で提供してはどうか
良いアイデアだが、それは実装段階の話に近いので、要望スレで。
15, オープンソースにする利点、またはリスクは？
リスク：オープンソースにすると言う事は、Ｋ察にもソースを公開するということ。
Ｋ察のおとり捜査が容易になるので、
かなり厳密な設計が必要になってくる。
利点：ググったら腐るほど出てくるので、そちらで勉強して下さい。
. ※暗号化・複合化部は、一番肝になる部分ですので
. ライブラリとして,バイナリでの提供を考えています。
→ それ専用のスレッドが御座いますので、そちらに書き込んで頂くか
→ プログラム組む時(実装時・設計時)に、再度お願いします。 項目14も参考に読む事。
※次期P2Pに対する要望スレ http://tmp2.2ch.net/test/read.cgi/download/1070085137/
13, これ作っても違法なんじゃないの？
→ 法的な問題については専用のスレッドが御座いますので、そちらにお願いいたします。
→ そちらでは現在、法律に詳しい方を探しています。
※次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070084504/
14, 基本部分をプラグイン・ライブラリの形で提供してはどうか
良いアイデアだが、それは実装段階の話に近いので、要望スレで。
15, オープンソースにする利点、またはリスクは？
リスク：オープンソースにすると言う事は、Ｋ察にもソースを公開するということ。
Ｋ察のおとり捜査が容易になるので、
かなり厳密な設計が必要になってくる。
利点：ググったら腐るほど出てくるので、そちらで勉強して下さい。
. ※暗号化・複合化部は、一番肝になる部分ですので
. ライブラリとして,バイナリでの提供を考えています。
9 ：[名無し]さん(bin+cue).rar：03/12/15 04:17 ID:xsUthoVE
>>8
このスレッドは次スレに移行しています。
次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070084504/
↓
次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070500722/
このスレッドは次スレに移行しています。
次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070084504/
↓
次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070500722/
10 ：関連ありそうなものを適当に：03/12/15 04:18 ID:wGENn+sO
P2P匿名掲示板「新月」、完成してる模様
実験的にファイルアップロード機能をつけてます
オープンソースなんで検証してみるといいかも
ttp://fuktommy.hp.infoseek.co.jp/perl.html#shingetsu
wiki
ttp://fuktommy.hp.infoseek.co.jp/cgi-bin/wiki.cgi?%BF%B7%B7%EE
■P2P匿名掲示板「新月」■
http://tmp2.2ch.net/test/read.cgi/download/1070720320/
実験的にファイルアップロード機能をつけてます
オープンソースなんで検証してみるといいかも
ttp://fuktommy.hp.infoseek.co.jp/perl.html#shingetsu
wiki
ttp://fuktommy.hp.infoseek.co.jp/cgi-bin/wiki.cgi?%BF%B7%B7%EE
■P2P匿名掲示板「新月」■
http://tmp2.2ch.net/test/read.cgi/download/1070720320/
11 ：関連ありそうなものを適当に：03/12/15 04:23 ID:wGENn+sO
Freenet & Frost スタートアップ
http://yellow.ribbon.to/~xanacopy/fff01.html
初心者向け。導入の手引き。
freenet + frost
ttp://tmp2.2ch.net/test/read.cgi/download/1069942913/l50
Invisible IRC Project
ttp://www.invisiblenet.net/iip/
the zigumo project
ttp://www.zigumo.org/
Vojta
ttp://vojtaproject.kicks-ass.org/
Tiara
消えた．．．
http://yellow.ribbon.to/~xanacopy/fff01.html
初心者向け。導入の手引き。
freenet + frost
ttp://tmp2.2ch.net/test/read.cgi/download/1069942913/l50
Invisible IRC Project
ttp://www.invisiblenet.net/iip/
the zigumo project
ttp://www.zigumo.org/
Vojta
ttp://vojtaproject.kicks-ass.org/
Tiara
消えた．．．
12 ：[名無し]さん(bin+cue).rar：03/12/15 04:27 ID:wGENn+sO
テンプレ案が無かったんで適当にやりました。
誰か適当に訂正・突っ込み・修正よろしく。
一人でテンプレまでやるには時間帯的に連投制限きつすぎ。
誰か適当に訂正・突っ込み・修正よろしく。
一人でテンプレまでやるには時間帯的に連投制限きつすぎ。
13 ：[名無し]さん(bin+cue).rar：03/12/15 04:32 ID:mQOao8ZG
Winnyで鳴らした俺達特攻部隊は、濡れ衣を着せられＫに家捜されたが、P2P
を脱出し、サーバにもぐった。しかし、サーバでくすぶっているような俺達じゃあない。
PINGさえ通ればプロトコル次第でなんでもやってのける命知らず、不可能を可能にし著作権法を
粉砕する、俺達、特攻野郎 Ｐチーム！
俺は、リーダー47。通称47氏。だが今はＫの追跡を巻くため名無しさんだ。
プログラミングの名人でWinnyの開発者。
俺のような天才プログラマーでなければ百戦錬磨のハッカーどものリーダーは務まらん。
俺はむーむー。通称むーむー氏。
自慢のストレージ健全化で、Ｋの囮捜査もイチコロさ。
ハッタリかまして、P2Pファイル交換からP2Pオセロまで、何でもそろえてみせるぜ。
よおお待ちどう。俺様こそP2Pの仕様を考えるの管理人。通称26氏。
.NETプログラマーとしての腕は天下一品！
メモリリーク？IP漏れ？だから何。
隣接ノードに情報を漏らさない方式の提案者。通称◆Fw0Kir8iYA。
情報を漏らさない天才だ。背後からJASRACの偉い人でもブン殴ってみせらぁ。
でもタイーホだけはかんべんな。
俺達は、言論の自由の通らぬ世の中にあえて挑戦する。
頼りになる次期P2Pクリエイター、特攻 野郎 Ｐチーム ！
助けを借りたいときは、いつでも言ってくれ。
を脱出し、サーバにもぐった。しかし、サーバでくすぶっているような俺達じゃあない。
PINGさえ通ればプロトコル次第でなんでもやってのける命知らず、不可能を可能にし著作権法を
粉砕する、俺達、特攻野郎 Ｐチーム！
俺は、リーダー47。通称47氏。だが今はＫの追跡を巻くため名無しさんだ。
プログラミングの名人でWinnyの開発者。
俺のような天才プログラマーでなければ百戦錬磨のハッカーどものリーダーは務まらん。
俺はむーむー。通称むーむー氏。
自慢のストレージ健全化で、Ｋの囮捜査もイチコロさ。
ハッタリかまして、P2Pファイル交換からP2Pオセロまで、何でもそろえてみせるぜ。
よおお待ちどう。俺様こそP2Pの仕様を考えるの管理人。通称26氏。
.NETプログラマーとしての腕は天下一品！
メモリリーク？IP漏れ？だから何。
隣接ノードに情報を漏らさない方式の提案者。通称◆Fw0Kir8iYA。
情報を漏らさない天才だ。背後からJASRACの偉い人でもブン殴ってみせらぁ。
でもタイーホだけはかんべんな。
俺達は、言論の自由の通らぬ世の中にあえて挑戦する。
頼りになる次期P2Pクリエイター、特攻 野郎 Ｐチーム ！
助けを借りたいときは、いつでも言ってくれ。
14 ：[名無し]さん(bin+cue).rar：03/12/15 04:47 ID:dePBYe0V
15 ：[名無し]さん(bin+cue).rar：03/12/15 06:07 ID:hysrZtba
16 ：[名無し]さん(bin+cue).rar：03/12/15 06:15 ID:1aqftNvm
>>13
面白いな。
どうでもいいけど、C#でメモリリーク起こしたと作者本人が言ったの？
本当だったらかなりの素人かもしれんな。ぴっかぴっかの大学一年だ。
いや、Javaじゃないからおきなくは無いんだがね。
あと、このレベルだと多分マウスのイベントに直接ネット系の処理とか
重たいのを入れたりしてるだろう。どうだ、当たったか？
外れたらスマンと誤っとこう。
面白いな。
どうでもいいけど、C#でメモリリーク起こしたと作者本人が言ったの？
本当だったらかなりの素人かもしれんな。ぴっかぴっかの大学一年だ。
いや、Javaじゃないからおきなくは無いんだがね。
あと、このレベルだと多分マウスのイベントに直接ネット系の処理とか
重たいのを入れたりしてるだろう。どうだ、当たったか？
外れたらスマンと誤っとこう。
17 ：[名無し]さん(bin+cue).rar：03/12/15 06:18 ID:1aqftNvm
.NetだからC#だと安直に考えたが、C#じゃ無かったらさらにスマン。
18 ：[名無し]さん(bin+cue).rar：03/12/15 07:47 ID:8i7NhWUd
>>16
メモリリークではなくデッドロックみたいです
メモリリークではなくデッドロックみたいです
19 ：[名無し]さん(bin+cue).rar：03/12/15 09:29 ID:xqEJH7Xa
20 ：[名無し]さん(bin+cue).rar：03/12/15 09:29 ID:zW17+/NG
21 ：[名無し]さん(bin+cue).rar：03/12/15 10:07 ID:gicioo5R
議論だけして結局何も作りませんよ
22 ：[名無し]さん(bin+cue).rar：03/12/15 10:50 ID:BIUcpOe+
>>19
放送禁止用語の名前にしたところで、
「新型のP2P」とか「Winnyの後継ソフト」とか適当な表現でスルーされる。
もしくはACCSや報道機関が勝手に名前をつける事もあるだろう。
ちなみに、MSBLASTの亜種で「PENIS32」とかいうのがあったが、ニュースで取り上げられる事はなかった。
新スレだから一応書いとく。
放送禁止用語の名前にしたところで、
「新型のP2P」とか「Winnyの後継ソフト」とか適当な表現でスルーされる。
もしくはACCSや報道機関が勝手に名前をつける事もあるだろう。
ちなみに、MSBLASTの亜種で「PENIS32」とかいうのがあったが、ニュースで取り上げられる事はなかった。
新スレだから一応書いとく。
23 ：[名無し]さん(bin+cue).rar：03/12/15 11:07 ID:4Ciowubj
24 ：[名無し]さん(bin+cue).rar：03/12/15 11:12 ID:4ZGznlDx
名前議論しだすと馬鹿が騒ぎ出すんで、まとめサイトでやったほうがよくないかな？
ダウソ板でやるとまた名前スレみたいな状態になるだろうし。
ダウソ板でやるとまた名前スレみたいな状態になるだろうし。
25 ：[名無し]さん(bin+cue).rar：03/12/15 11:21 ID:BIUcpOe+
26 ：[名無し]さん(bin+cue).rar：03/12/15 12:00 ID:U5zCUnVm
仕様の話をしようか・・ ﾅﾝﾁﾃ (=^ω^)ｸﾌﾌﾌ
27 ：[名無し]さん(bin+cue).rar：03/12/15 12:16 ID:AecVnNrq
あえて書かせていただこう。 ￣ー￣
・
・
・
・
Part7 を使い切ってからどうぞ。
・
・
・
・
Part7 を使い切ってからどうぞ。
28 ：[名無し]さん(bin+cue).rar：03/12/15 13:21 ID:Wpupsldn
なあ、このSoftEtherつうVPNシステム使えば色々出来そうでないか？
http://www.softether.com/jp/
コピペ:
"SoftEther" とは、"Software Ethernet" (ソフトウェア的なイーサネット) の
略語です。Ethernet は現在ほとんどの LAN で利用されている通信方式であり、
これをソフトウェア的にエミュレートすることにより仮想ネットワーク (VPN) を
構築することが可能です。現在、SoftEther ソフトウェアは
Windows 2000、Windows XP、Windows Server 2003 に対応しています。
SoftEther は、現在の制限の多い LAN やインターネット上で、完全に自由な
通信を行うために開発された仮想ネットワーク通信ソフトウェアです。
SoftEther の仮想ネットワークにより、離れた場所にあるコンピュータ同士や
ネットワーク同士を、暗号化されたカプセル化通信により接続することができます。
途中にファイアウォールやプロキシ サーバーが存在する場合も、
それらの障壁を回避して通信可能です。
http://www.softether.com/jp/
コピペ:
"SoftEther" とは、"Software Ethernet" (ソフトウェア的なイーサネット) の
略語です。Ethernet は現在ほとんどの LAN で利用されている通信方式であり、
これをソフトウェア的にエミュレートすることにより仮想ネットワーク (VPN) を
構築することが可能です。現在、SoftEther ソフトウェアは
Windows 2000、Windows XP、Windows Server 2003 に対応しています。
SoftEther は、現在の制限の多い LAN やインターネット上で、完全に自由な
通信を行うために開発された仮想ネットワーク通信ソフトウェアです。
SoftEther の仮想ネットワークにより、離れた場所にあるコンピュータ同士や
ネットワーク同士を、暗号化されたカプセル化通信により接続することができます。
途中にファイアウォールやプロキシ サーバーが存在する場合も、
それらの障壁を回避して通信可能です。
29 ：[名無し]さん(bin+cue).rar：03/12/15 13:37 ID:oXDma7h8
おもしろそうだね
商用以外は自由に使っていいのか
でも作者さんに迷惑かかんないかな?
商用以外は自由に使っていいのか
でも作者さんに迷惑かかんないかな?
30 ：[名無し]さん(bin+cue).rar：03/12/15 13:54 ID:vVFxdaKh
31 ：[名無し]さん(bin+cue).rar：03/12/15 14:01 ID:4Ciowubj
32 ：[名無し]さん(bin+cue).rar：03/12/15 14:04 ID:dePBYe0V
33 ：[名無し]さん(bin+cue).rar：03/12/15 14:05 ID:DpLLyxrE
>>28
つーかこれは既にnyで行われている事じゃないのか？
限られた端末（ノード）同士の仮想ネットワークだろ。
nyはさらに動的にネットワーク（クラスタ）が変化するが。
ファイヤーウォールなどの障壁を回避するってのも、Port0という形で実現されていた。
（Port0の転送の発生確率が低く設定されていたが）
暗号化だってされてたし。VPNの場合はそれをトンネリングと呼ぶみたいだが。
つーかこれは既にnyで行われている事じゃないのか？
限られた端末（ノード）同士の仮想ネットワークだろ。
nyはさらに動的にネットワーク（クラスタ）が変化するが。
ファイヤーウォールなどの障壁を回避するってのも、Port0という形で実現されていた。
（Port0の転送の発生確率が低く設定されていたが）
暗号化だってされてたし。VPNの場合はそれをトンネリングと呼ぶみたいだが。
34 ：[名無し]さん(bin+cue).rar：03/12/15 14:09 ID:xSRyVPw/
仮想ハードウェアで実現しているところが技術的に評価できる・・・。があまり使い道がない。
こいつならドライバ屋になれるな。
こいつならドライバ屋になれるな。
35 ：[名無し]さん(bin+cue).rar：03/12/15 14:16 ID:4Ciowubj
>>33
全然違う。
nyは基本的にはグヌーテラクローン。
検索キーとかは仮想に乗ってるけどファイルのﾀﾞｳｿは（おそらく）http。
これは全部仮想に乗る。
つかこのソフトの革新的なトコはなんだ？
見た感じただのVPN・・・
全然違う。
nyは基本的にはグヌーテラクローン。
検索キーとかは仮想に乗ってるけどファイルのﾀﾞｳｿは（おそらく）http。
これは全部仮想に乗る。
つかこのソフトの革新的なトコはなんだ？
見た感じただのVPN・・・
36 ：[名無し]さん(bin+cue).rar：03/12/15 14:25 ID:DpLLyxrE
>>35
ファイルのダウンがhttpってどういうことだよｗ
httpわかってる？
このソフトの価値は
専用のハードを使わずにVPNを実現していること。
片方の出口がグローバルな環境でなくてもよいこと。
この通信をソフト等から扱う時、通常の通信の同じように扱えること。
ただ、このスレ的には新しいネタを与えてくれるものではないと思う。
ファイルのダウンがhttpってどういうことだよｗ
httpわかってる？
このソフトの価値は
専用のハードを使わずにVPNを実現していること。
片方の出口がグローバルな環境でなくてもよいこと。
この通信をソフト等から扱う時、通常の通信の同じように扱えること。
ただ、このスレ的には新しいネタを与えてくれるものではないと思う。
37 ：[名無し]さん(bin+cue).rar：03/12/15 14:37 ID:4Ciowubj
38 ：[名無し]さん(bin+cue).rar：03/12/15 14:39 ID:DpLLyxrE
このスレの主旨には反するが、>>28とｎｙ or MX or FTPを組み合わせると、
かなり匿名性の高いシステムが作れるな。
問題は、
「仮想HUB」が晒されなければならないこと。
「仮想HUB」に転送量の負担が集中すること、か。
まあ、これまで散々議論されてた、「必ず中継を挟めばいいんじゃないか（もちろん、異論もあるだろうが）」というのを
既存のソフトの組み合わせでやるだけなんだがな。
かなり匿名性の高いシステムが作れるな。
問題は、
「仮想HUB」が晒されなければならないこと。
「仮想HUB」に転送量の負担が集中すること、か。
まあ、これまで散々議論されてた、「必ず中継を挟めばいいんじゃないか（もちろん、異論もあるだろうが）」というのを
既存のソフトの組み合わせでやるだけなんだがな。
39 ：[名無し]さん(bin+cue).rar：03/12/15 14:41 ID:DpLLyxrE
40 ：[名無し]さん(bin+cue).rar：03/12/15 14:41 ID:3MGBPrED
なんでhttpプロトコルを利用してるんだろう・・・
41 ：[名無し]さん(bin+cue).rar：03/12/15 14:46 ID:4Ciowubj
>>39
まあキャプチャした訳じゃ無いし正確なトコはわからんよ・・・
使ってて転送エラー多かったから勝手に妄想してた。
じゃあ更に訂正。
～TCP/IPプロトコルアプリケーション層を～
これで勘弁して下さいｗ
まあキャプチャした訳じゃ無いし正確なトコはわからんよ・・・
使ってて転送エラー多かったから勝手に妄想してた。
じゃあ更に訂正。
～TCP/IPプロトコルアプリケーション層を～
これで勘弁して下さいｗ
42 ：[名無し]さん(bin+cue).rar：03/12/15 14:53 ID:czt+Eu4N
>>7
>>. ・初心者には容易に使えないソフトが良い、
ってあるけどさ、初心者が比較的用意に使えるからこそ
Winnyが普及したんじゃないのか？
初心者が出来ない、ファイルのやり取りの方法なんて
けっこう幾らでもあるっしょ。
このスレの、ソフト作ろうって思ってるプログラマーの人がどう思ってるか知らないけど
「Winnyの次」だったら、PCを普通に使えるエンドユーザーが簡単に出来るべきだと思われ
>>. ・初心者には容易に使えないソフトが良い、
ってあるけどさ、初心者が比較的用意に使えるからこそ
Winnyが普及したんじゃないのか？
初心者が出来ない、ファイルのやり取りの方法なんて
けっこう幾らでもあるっしょ。
このスレの、ソフト作ろうって思ってるプログラマーの人がどう思ってるか知らないけど
「Winnyの次」だったら、PCを普通に使えるエンドユーザーが簡単に出来るべきだと思われ
43 ：[名無し]さん(bin+cue).rar：03/12/15 15:00 ID:4ZGznlDx
44 ：[名無し]さん(bin+cue).rar：03/12/15 15:24 ID:czt+Eu4N
45 ：[名無し]さん(bin+cue).rar：03/12/15 16:40 ID:mzOAOaMO
このスレでのP2P開発者は
むーむー氏と26氏か・・・
最近むーむー氏見かけないんだけど・・・いずこへ？
むーむー氏と26氏か・・・
最近むーむー氏見かけないんだけど・・・いずこへ？
46 ：[名無し]さん(bin+cue).rar：03/12/15 16:53 ID:JlE761vP
かたくそうさく
47 ：[名無し]さん(bin+cue).rar：03/12/15 17:04 ID:GWzxMrJJ
平日は時間取れない人も多いだろうけど
もうすぐ冬休みだから
いろいろ期待できそうだね。
もうすぐ冬休みだから
いろいろ期待できそうだね。
48 ：[名無し]さん(bin+cue).rar：03/12/15 17:47 ID:HFOw2mOg
49 ：[名無し]さん(bin+cue).rar：03/12/15 18:09 ID:JBIkEElW
50 ：[名無し]さん(bin+cue).rar：03/12/15 22:33 ID:s8Vt5n90
51 ：[名無し]さん(bin+cue).rar：03/12/15 22:53 ID:C3Q2wpA5
>>28
ASCIIで紹介されて棚
ASCIIで紹介されて棚
52 ：[名無し]さん(bin+cue).rar：03/12/16 01:17 ID:p5goFrJ7
>>28
2000以降て事はあれか、IPSec使ってるだけ？
2000以降て事はあれか、IPSec使ってるだけ？
53 ：[名無し]さん(bin+cue).rar：03/12/16 01:18 ID:CIMQ2mo+
54 ：[名無し]さん(bin+cue).rar：03/12/16 01:54 ID:kH8DLO12
現在のnyネットワークを生かす道は出た？
今問題になっているクラック厨対策のために、新たなパッチを導入して
パッチを導入したもの同士しか通信できないようにすれば実質的なバ
ージョンアップになるし、４７氏無き今、パッチを皆で小細工する事に
よってクラックに柔軟に対応できそうなんだけど・・・
あと作者問題も解決できる？
例としては、かちゅ～しゃのkageのように
素人だからツッコミどころ満載だろうな
今問題になっているクラック厨対策のために、新たなパッチを導入して
パッチを導入したもの同士しか通信できないようにすれば実質的なバ
ージョンアップになるし、４７氏無き今、パッチを皆で小細工する事に
よってクラックに柔軟に対応できそうなんだけど・・・
あと作者問題も解決できる？
例としては、かちゅ～しゃのkageのように
素人だからツッコミどころ満載だろうな
55 ：[名無し]さん(bin+cue).rar：03/12/16 09:42 ID:eligySwi
>>54
できる。ツーか俺やってる最中。
できる。ツーか俺やってる最中。
56 ：[名無し]さん(bin+cue).rar：03/12/16 16:01 ID:IMYDJNqI
俺しかいない予感
57 ：[名無し]さん(bin+cue).rar：03/12/16 16:15 ID:y3XECff9
じゃあオレも
58 ：[名無し]さん(bin+cue).rar：03/12/16 16:36 ID:7wSRtdu5
>>54
漏れ漏れも
漏れ漏れも
59 ：[名無し]さん(bin+cue).rar：03/12/16 17:07 ID:V/K9AomN
60 ：[名無し]さん(bin+cue).rar：03/12/16 17:48 ID:Py+Sw66n
>>59
SNは別にいいんじゃない？
SNは別にいいんじゃない？
61 ：[名無し]さん(bin+cue).rar：03/12/16 18:43 ID:aAUhMOLg
>>54
良いアイデアだと思うけど。
良いアイデアだと思うけど。
62 ：[名無し]さん(bin+cue).rar：03/12/16 18:50 ID:MooDw8g5
まあ一時しのぎにはなるんでないの。次のソフトは安定動作となるともう少し時間懸かりそうだし
63 ：[名無し]さん(bin+cue).rar：03/12/16 21:42 ID:M4U5dIO0
むーむさん見てますか？
最近来ないようなので進行状況などが気になるかもー。
最近来ないようなので進行状況などが気になるかもー。
64 ：[名無し]さん(bin+cue).rar：03/12/16 21:52 ID:OX+4kgkP
あのさあファイルを送信するときにコネクションを頻繁に切断して
ルーティングを書き換えて経由するＰＣをどんどん変えるのは？
あとひとつのファイルにつき落とせる量たとえば5から10KBにして
あまった大域が100KBあったら10から20のファイル（ダミー）を同時に
落とし続けるわけ。それぞれ強力な暗号化（ＥＣＣで256bitぐらいなら糞強固）
を施し鍵のパラメータはランダムに生成する。長さは一緒。
それによって20のファイルの中のどれが著作権に反してるかわからない。
1個つまり自分の意思で落としてるものがどれかわからない。
おそらく100以上のＰＣが関与することになるから特定するのは不可能では？それぞれ同じ大きさだし。
暗号化してあるし。キャッシュがあるとバレルから落としてる最中というか
送信されてるときは表示しない。
いっとくけどこのシステムを使う場合経由するＰＣを頻繁に変えるから
通常とは逆の向きのコネクションをはることになる。
ルーティングを書き換えて経由するＰＣをどんどん変えるのは？
あとひとつのファイルにつき落とせる量たとえば5から10KBにして
あまった大域が100KBあったら10から20のファイル（ダミー）を同時に
落とし続けるわけ。それぞれ強力な暗号化（ＥＣＣで256bitぐらいなら糞強固）
を施し鍵のパラメータはランダムに生成する。長さは一緒。
それによって20のファイルの中のどれが著作権に反してるかわからない。
1個つまり自分の意思で落としてるものがどれかわからない。
おそらく100以上のＰＣが関与することになるから特定するのは不可能では？それぞれ同じ大きさだし。
暗号化してあるし。キャッシュがあるとバレルから落としてる最中というか
送信されてるときは表示しない。
いっとくけどこのシステムを使う場合経由するＰＣを頻繁に変えるから
通常とは逆の向きのコネクションをはることになる。
65 ：[名無し]さん(bin+cue).rar：03/12/16 22:14 ID:bS/yDFlv
＞あとひとつのファイルにつき落とせる量たとえば5から10KBにして
＞あまった大域が100KBあったら10から20のファイル（ダミー）を同時に
＞落とし続けるわけ。それぞれ強力な暗号化（ＥＣＣで256bitぐらいなら糞強固）
＞を施し鍵のパラメータはランダムに生成する。長さは一緒。
＞それによって20のファイルの中のどれが著作権に反してるかわからない。
こういうのは見てるだけの人間にはわからないけど、動作してるプログラム
からすれば一目瞭然で無意味だと思う。
＞あまった大域が100KBあったら10から20のファイル（ダミー）を同時に
＞落とし続けるわけ。それぞれ強力な暗号化（ＥＣＣで256bitぐらいなら糞強固）
＞を施し鍵のパラメータはランダムに生成する。長さは一緒。
＞それによって20のファイルの中のどれが著作権に反してるかわからない。
こういうのは見てるだけの人間にはわからないけど、動作してるプログラム
からすれば一目瞭然で無意味だと思う。
66 ：[名無し]さん(bin+cue).rar：03/12/16 22:15 ID:yIaNoTIu
>>64
そんな糞仕様を思いついた自分が恥ずかしくないか?
そんな糞仕様を思いついた自分が恥ずかしくないか?
67 ：[名無し]さん(bin+cue).rar：03/12/16 22:29 ID:XShwhrBc
>>64
・過去ログを読んでいない。
・問題点が何なのかわかっていない。
・nyでどんな技術が実装されてるかわかっていないッぽい。
・暗号に関係した単語をむやみに使いたがる。
見本のような人ですね。と。
・過去ログを読んでいない。
・問題点が何なのかわかっていない。
・nyでどんな技術が実装されてるかわかっていないッぽい。
・暗号に関係した単語をむやみに使いたがる。
見本のような人ですね。と。
68 ：[名無し]さん(bin+cue).rar：03/12/16 22:32 ID:7rT+2Kut
ねーねー
26とかムームーとかが作ってるプログラムは
使っても逮捕されないの？
26とかムームーとかが作ってるプログラムは
使っても逮捕されないの？
69 ：[名無し]さん(bin+cue).rar：03/12/16 22:51 ID:yIaNoTIu
逮捕以前に普及しない
70 ：[名無し]さん(bin+cue).rar：03/12/16 23:07 ID:JryzlC/L
＞使っても逮捕されないの？
ﾁｷﾝ、逝くべし
ﾁｷﾝ、逝くべし
71 ：[名無し]さん(bin+cue).rar：03/12/16 23:17 ID:7rT+2Kut
72 ：[名無し]さん(bin+cue).rar：03/12/16 23:21 ID:M4U5dIO0
そうじゃなくても恥ずかしいから大丈夫だよ。
73 ：[名無し]さん(bin+cue).rar：03/12/16 23:29 ID:7rT+2Kut
74 ：[名無し]さん(bin+cue).rar：03/12/16 23:31 ID:SKDdDUsH
ぶっちゃけ、Nyはスーパープレイ集める為にやってるのだが。
ペン移しの動画はすごいよ。
ペン移しの動画はすごいよ。
75 ：[名無し]さん(bin+cue).rar：03/12/16 23:39 ID:ranMMNUc
作る人間は警察の家宅捜査に耐えられるだけの精神力が必要だな
76 ：[名無し]さん(bin+cue).rar：03/12/16 23:49 ID:BvU/orAh
>>71
sａge→ａを半角にしないとsageにならんのだが
sａge→ａを半角にしないとsageにならんのだが
77 ：[名無し]さん(bin+cue).rar：03/12/16 23:56 ID:7rT+2Kut
78 ：[名無し]さん(bin+cue).rar：03/12/16 23:58 ID:4fcCy6Oa
>>76
メール欄がおかしかったらネタと思っていい。
メール欄がおかしかったらネタと思っていい。
79 ：[名無し]さん(bin+cue).rar：03/12/17 00:04 ID:NRBb9JkV
80 ：[名無し]さん(bin+cue).rar：03/12/17 00:15 ID:VIKhWYGk
裁判長「被告>>71は、○○ソフトのゲーム「恋する妹はせつなくてお兄ちゃんを想うとすぐＨしちゃうの」
および「大好きな先生にＨなおねだりしちゃうおませなボクの／私のぷにぷに」を無断で
アップロードしたに相違ありませんね？」
>>71 「聞き取れませんですた。もう一度おながいします。」
裁判長「被告>>71は、○○ソフトのゲーム「恋する妹はせつなくてお兄ちゃんを想うとすぐＨしちゃうの」
および「大好きな先生にＨなおねだりしちゃうおませなボクの／私のぷにぷに」を無断で
アップロードしたに相違ありませんね？」
>>71 「はあ? 違います。私がアップロードしたのは「(個人撮影)超美少女セックス大好き女子高生
が風呂場で中出しだらだらでほんとにいいのか？(めちゃかわいいです）」という動画ファイルであって、
「恋する妹はせつなくてお兄ちゃんを想うとすぐＨしちゃうの」とか「大好きな先生にＨなおねだり
しちゃうおませなボクの／私のぷにぷに」などというゲームは全く知りません。
裁判長「えっ、では被告>>71は、○○ソフトのゲーム「恋する妹はせつなくてお兄ちゃんを想うとすぐＨしちゃうの」
および「大好きな先生にＨなおねだりしちゃうおませなボクの／私のぷにぷに」を無断で
アップロードしたのでは無く、・・・ん んん 「(個人撮影)超美少女セックス大好き女子高生
が風呂場で中出しだらだらでほんとにいいのか？(めちゃかわいいです）」という動画ファイルをアップロード
したのだね」
>>71 「 え ?すんません。聞き取れませんですたのでもう一度おながいします。」
および「大好きな先生にＨなおねだりしちゃうおませなボクの／私のぷにぷに」を無断で
アップロードしたに相違ありませんね？」
>>71 「聞き取れませんですた。もう一度おながいします。」
裁判長「被告>>71は、○○ソフトのゲーム「恋する妹はせつなくてお兄ちゃんを想うとすぐＨしちゃうの」
および「大好きな先生にＨなおねだりしちゃうおませなボクの／私のぷにぷに」を無断で
アップロードしたに相違ありませんね？」
>>71 「はあ? 違います。私がアップロードしたのは「(個人撮影)超美少女セックス大好き女子高生
が風呂場で中出しだらだらでほんとにいいのか？(めちゃかわいいです）」という動画ファイルであって、
「恋する妹はせつなくてお兄ちゃんを想うとすぐＨしちゃうの」とか「大好きな先生にＨなおねだり
しちゃうおませなボクの／私のぷにぷに」などというゲームは全く知りません。
裁判長「えっ、では被告>>71は、○○ソフトのゲーム「恋する妹はせつなくてお兄ちゃんを想うとすぐＨしちゃうの」
および「大好きな先生にＨなおねだりしちゃうおませなボクの／私のぷにぷに」を無断で
アップロードしたのでは無く、・・・ん んん 「(個人撮影)超美少女セックス大好き女子高生
が風呂場で中出しだらだらでほんとにいいのか？(めちゃかわいいです）」という動画ファイルをアップロード
したのだね」
>>71 「 え ?すんません。聞き取れませんですたのでもう一度おながいします。」
81 ：[名無し]さん(bin+cue).rar：03/12/17 00:54 ID:KhoNBhPY
新違法ファイル交換ツールはまだですか？
82 ：[名無し]さん(bin+cue).rar：03/12/17 02:07 ID:FeaBVxJF
ふと思ったんだが、ネットでソースを公開していて転載も自由な場合、
47氏のように家宅捜索を受ける可能性ってあるのか？
47氏のように家宅捜索を受ける可能性ってあるのか？
83 ：[名無し]さん(bin+cue).rar：03/12/17 02:27 ID:2QI2MEP4
>>82
いったい何度同じことが繰り返されれば気が済むのです
いったい何度同じことが繰り返されれば気が済むのです
84 ：[名無し]さん(bin+cue).rar：03/12/17 02:56 ID:KFIlazd4
>>82
元々ツール開発者に責任を問うのは難しいという定説を、更に責任の拡散により
薄くする、もしくはプログラム開発という純粋な行為として確立させる効果はあるよね。
しかし、以後この話題は既出なので他の各当スレへ。
元々ツール開発者に責任を問うのは難しいという定説を、更に責任の拡散により
薄くする、もしくはプログラム開発という純粋な行為として確立させる効果はあるよね。
しかし、以後この話題は既出なので他の各当スレへ。
85 ：[名無し]さん(bin+cue).rar：03/12/17 03:35 ID:P7fcPVO4
漏れはpart4の途中からROMってる者だが。
既に開発に着手してる奴がいて、技術検証版らしきものがﾎﾞﾁﾎﾞﾁ出てきてるのはｽｹﾞｰと思う。
漏れもかつてﾊｶｰに憧れてたしな。
みんなの努力には頭が下がる思いなんだが、ちと方向性に懸念を覚える。
前に誰かが言ってたと思うが、みんなP2P/匿名/ファイル共有を一緒くたに考えてないか？
OSIモデルみたいにプロトコルを階層化して、挙動の定義から始めた方が良さそうに思えるんだが。
漏れとしては匿名P2Pレイヤの上に各アプリ(ファイル共有/BBS/IM)が乗ってる形態を推奨する。
その方がオープンソース化して後の改良が進みやすいだろうし、プロトコルと各アプリを切り離して
メンテナンスできると思われ。
ｴﾗｿｰな台詞吐くなら具体案だせと言われそうなんで、これにて沈黙。
以上。
既に開発に着手してる奴がいて、技術検証版らしきものがﾎﾞﾁﾎﾞﾁ出てきてるのはｽｹﾞｰと思う。
漏れもかつてﾊｶｰに憧れてたしな。
みんなの努力には頭が下がる思いなんだが、ちと方向性に懸念を覚える。
前に誰かが言ってたと思うが、みんなP2P/匿名/ファイル共有を一緒くたに考えてないか？
OSIモデルみたいにプロトコルを階層化して、挙動の定義から始めた方が良さそうに思えるんだが。
漏れとしては匿名P2Pレイヤの上に各アプリ(ファイル共有/BBS/IM)が乗ってる形態を推奨する。
その方がオープンソース化して後の改良が進みやすいだろうし、プロトコルと各アプリを切り離して
メンテナンスできると思われ。
ｴﾗｿｰな台詞吐くなら具体案だせと言われそうなんで、これにて沈黙。
以上。
86 ：[名無し]さん(bin+cue).rar：03/12/17 05:34 ID:G8Dcokh0
87 ：[名無し]さん(bin+cue).rar：03/12/17 07:51 ID:lMVColcl
88 ：[名無し]さん(bin+cue).rar：03/12/17 10:58 ID:FVHX5baC
>>85
夕べ公開されたSoftEtherみたいに、デバイスドライバ形式が良いね。
インストールして初期ノード突っ込めば、ネットワークドライブとして認識されて、
フォルダ追加したらそのフォルダ名で勝手にファイルキーを検索、
アプリで読み込み・ファイルコピー・ダブルクリック等そのファイルに何らかの
アクセスがあったら、自動ダウン登録、落ちた先から使用可能。
なんてのが理想だが・・・うーん危険すぎるｗ
夕べ公開されたSoftEtherみたいに、デバイスドライバ形式が良いね。
インストールして初期ノード突っ込めば、ネットワークドライブとして認識されて、
フォルダ追加したらそのフォルダ名で勝手にファイルキーを検索、
アプリで読み込み・ファイルコピー・ダブルクリック等そのファイルに何らかの
アクセスがあったら、自動ダウン登録、落ちた先から使用可能。
なんてのが理想だが・・・うーん危険すぎるｗ
89 ：[名無し]さん(bin+cue).rar：03/12/17 12:29 ID:3vjPZFhd
近々47氏のリベンジバージョンがありそうだな
90 ：[名無し]さん(bin+cue).rar：03/12/17 12:33 ID:nz7fvM4E
>>89
根拠は？
根拠は？
91 ：[名無し]さん(bin+cue).rar：03/12/17 12:40 ID:3vjPZFhd
>>90
公式覗いてみな
公式覗いてみな
92 ：[名無し]さん(bin+cue).rar：03/12/17 12:48 ID:FVHX5baC
http://p2plocalhost/1268bda1ec55f4439beef1b1a0c06546
http://p2plocalhost/1268bda1ec55f4439beef1b1a0c06546/Winny/Readme.html
こんなんでIE・Irvineとかからファイル・zip圧縮してあるファイルにアクセス出来れば良いな。
てかこういう仮想web、nyBBSと似た手法で出来るのと思ったのに、やらない理由でもあったのか？
http://p2plocalhost/1268bda1ec55f4439beef1b1a0c06546/Winny/Readme.html
こんなんでIE・Irvineとかからファイル・zip圧縮してあるファイルにアクセス出来れば良いな。
てかこういう仮想web、nyBBSと似た手法で出来るのと思ったのに、やらない理由でもあったのか？
93 ：[名無し]さん(bin+cue).rar：03/12/17 13:39 ID:AGQB05QW
断片化しているファイルの転送を、積極的にして欲しいね。
「UPしている=完全なファイルの所持者、もしくはその中継者」の2択だけじゃやばい。
情報キーがとんでもないことになる可能性があるけど、どうなんだろ。
「UPしている=完全なファイルの所持者、もしくはその中継者」の2択だけじゃやばい。
情報キーがとんでもないことになる可能性があるけど、どうなんだろ。
94 ：[名無し]さん(bin+cue).rar：03/12/17 18:03 ID:9skhCJpH
95 ：[名無し]さん(bin+cue).rar：03/12/17 18:10 ID:RR/quUWO
96 ：[名無し]さん(bin+cue).rar：03/12/17 18:17 ID:eyp4pB+R
なんも決まってない段階で聞くのもなんだが
もしオープンな暗号方式を使うとしたら何がいいと思う？
通信に使うのかローカルディスクに使うかによっても違うし、
公開鍵か共通鍵方式とかいろいろあるけど。
もしオープンな暗号方式を使うとしたら何がいいと思う？
通信に使うのかローカルディスクに使うかによっても違うし、
公開鍵か共通鍵方式とかいろいろあるけど。
97 ：[名無し]さん(bin+cue).rar：03/12/17 18:28 ID:PIlBBvFB
>>91
こ、これは一体・・・？
こ、これは一体・・・？
98 ：[名無し]さん(bin+cue).rar：03/12/17 20:32 ID:qKLQomwP
>>96
通信部はOpenSSL
通信部はOpenSSL
99 ：[名無し]さん(bin+cue).rar：03/12/17 20:34 ID:eyp4pB+R
書き忘れたけど、IDみりゃわかるか
101 ：[名無し]さん(bin+cue).rar：03/12/17 21:12 ID:P1FAmDPq
102 ：[名無し]さん(bin+cue).rar：03/12/17 21:30 ID:aacnuJX9
103 ：[名無し]さん(bin+cue).rar：03/12/17 21:37 ID:qKLQomwP
>>101
SSLについてちゃんと勉強しとこ
昔勉強のためにRSAとRC4を１から実装して通信ソフト作ったことあるけど、
RSAの実装はつらかったな
テスト＋実験用にコード書くときに暗号アルゴリズム決まってると多少やりやすくなるからね
SSLについてちゃんと勉強しとこ
昔勉強のためにRSAとRC4を１から実装して通信ソフト作ったことあるけど、
RSAの実装はつらかったな
テスト＋実験用にコード書くときに暗号アルゴリズム決まってると多少やりやすくなるからね
105 ：[名無し]さん(bin+cue).rar：03/12/17 21:57 ID:rC46UJlB
51 名前： 47 ◆KbtLZwerNc [sage] 投稿日： 03/07/15 01:57 ID:hsfdr3mD
匿名性がまた話題になっているようですが、nyの匿名性に暗号はほぼ関係ありません。
もしWinnyのソースを全て公開して暗号を全て取り除いた状態でもnyの匿名性は変わりません。
通信内容、キャッシュなどを全て解析しても匿名性は保たれように設計されています。
Winnyの匿名性の肝は転送動作であって暗号ではないからです。
わざわざ各所を暗号化したり本体の改造を困難にしたり、通信内容を暗号化しているのは
単に解析を困難にさせるためです。そして、なぜ解析を困難にするかというと、
解析されて改造されるとファイル共有効率が落ちるからです
（ただ、キャッシュの暗号化は管理責任の問題があるかな？）
あと、Winnyが起動されているノード情報はもちろんTCPでコネクション繋いでいる以上
ログを取れば判明しますが、これは初期ノードリスト解析することと同じことです。
ここは一番暗号の弱いところで解析されてもほとんど影響の無い部分です。
初期ノードを暗号化しているのは気分的な問題（公開の際の心理的影響考慮）であって、
ここはデコードされてもほぼ匿名性に影響ないと思います。
それでわかるのはそこでnyが起動されているということだけですので
匿名性がまた話題になっているようですが、nyの匿名性に暗号はほぼ関係ありません。
もしWinnyのソースを全て公開して暗号を全て取り除いた状態でもnyの匿名性は変わりません。
通信内容、キャッシュなどを全て解析しても匿名性は保たれように設計されています。
Winnyの匿名性の肝は転送動作であって暗号ではないからです。
わざわざ各所を暗号化したり本体の改造を困難にしたり、通信内容を暗号化しているのは
単に解析を困難にさせるためです。そして、なぜ解析を困難にするかというと、
解析されて改造されるとファイル共有効率が落ちるからです
（ただ、キャッシュの暗号化は管理責任の問題があるかな？）
あと、Winnyが起動されているノード情報はもちろんTCPでコネクション繋いでいる以上
ログを取れば判明しますが、これは初期ノードリスト解析することと同じことです。
ここは一番暗号の弱いところで解析されてもほとんど影響の無い部分です。
初期ノードを暗号化しているのは気分的な問題（公開の際の心理的影響考慮）であって、
ここはデコードされてもほぼ匿名性に影響ないと思います。
それでわかるのはそこでnyが起動されているということだけですので
106 ：[名無し]さん(bin+cue).rar：03/12/17 22:05 ID:TBodwy0H
107 ：[名無し]さん(bin+cue).rar：03/12/17 22:06 ID:q6NOTck7
>>96-104くらいの人達へ。
67 名前：[名無し]さん(bin+cue).rar 投稿日：2003/12/16(火) 22:29 ID:XShwhrBc
>>64
・過去ログを読んでいない。
・問題点が何なのかわかっていない。
・nyでどんな技術が実装されてるかわかっていないッぽい。
・暗号に関係した単語をむやみに使いたがる。
見本のような人ですね。と。
67 名前：[名無し]さん(bin+cue).rar 投稿日：2003/12/16(火) 22:29 ID:XShwhrBc
>>64
・過去ログを読んでいない。
・問題点が何なのかわかっていない。
・nyでどんな技術が実装されてるかわかっていないッぽい。
・暗号に関係した単語をむやみに使いたがる。
見本のような人ですね。と。
108 ：[名無し]さん(bin+cue).rar：03/12/17 22:21 ID:aacnuJX9
109 ：[名無し]さん(bin+cue).rar：03/12/17 23:23 ID:9hb50+3a
110 ：[名無し]さん(bin+cue).rar：03/12/18 00:19 ID:RV7Opq5I
111 ：[名無し]さん(bin+cue).rar：03/12/18 00:50 ID:QNngEzRH
112 ：[名無し]さん(bin+cue).rar：03/12/18 00:58 ID:ert/Ph8a
>>111
その論文のポインタきぼん
その論文のポインタきぼん
113 ：[名無し]さん(bin+cue).rar：03/12/18 01:25 ID:QNngEzRH
>>105 >>107
指摘サンクス
ただ、ローカルの暗号化はパスワードをルートキーにしておけば
他人にディスクの中身を見られたときに役に立つし、
通信も1つのISPに依存している以上
ログを解析されれば、リアルタイムの転送かキャッシュからかぐらいは簡単にわかるし
キャッシュからか自分で初放流したのかもわかる可能性高いから
やっといたほうがいいと思うぞ。
そりゃ接続してるノードが全て攻撃者のおとりノードだったら意味ないけどな。
もちろん匿名性で一番大事なのはほかの部分で、
個々の暗号が完璧でも後がだめならいみないんだが、
完全に無視するには大きすぎると思うぞ。
（レス長すぎなんで分けます）
指摘サンクス
ただ、ローカルの暗号化はパスワードをルートキーにしておけば
他人にディスクの中身を見られたときに役に立つし、
通信も1つのISPに依存している以上
ログを解析されれば、リアルタイムの転送かキャッシュからかぐらいは簡単にわかるし
キャッシュからか自分で初放流したのかもわかる可能性高いから
やっといたほうがいいと思うぞ。
そりゃ接続してるノードが全て攻撃者のおとりノードだったら意味ないけどな。
もちろん匿名性で一番大事なのはほかの部分で、
個々の暗号が完璧でも後がだめならいみないんだが、
完全に無視するには大きすぎると思うぞ。
（レス長すぎなんで分けます）
47氏の話は大体あってると思うが、
「nyの匿名性に暗号は"ほぼ"関係ありません」
であって100%ではないと思う。
ちなみに初期ノードのあたりの話はまさにその通りだと思う。
ただ、７月の発言だから今あんまり気にしてもな。
「nyの匿名性に暗号は"ほぼ"関係ありません」
であって100%ではないと思う。
ちなみに初期ノードのあたりの話はまさにその通りだと思う。
ただ、７月の発言だから今あんまり気にしてもな。
116 ：[名無し]さん(bin+cue).rar：03/12/18 02:05 ID:ert/Ph8a
>>115
お前が作るんならAESだろうがTripleDESだろうがカオス暗号だろうが
RIPEMD-160だろうがSHA512だろうが好きな奴を使えばいいだろ。
やっちゃいかんとは言わないが、ロクに考えもしないでむーむー氏や
26氏の負担だけでかくするような提案ばっかすんなって事だよ。
「暗号を強くすればセキュリティがより強い物になると思います」
そんなの誰でも言えるじゃん
お前が作るんならAESだろうがTripleDESだろうがカオス暗号だろうが
RIPEMD-160だろうがSHA512だろうが好きな奴を使えばいいだろ。
やっちゃいかんとは言わないが、ロクに考えもしないでむーむー氏や
26氏の負担だけでかくするような提案ばっかすんなって事だよ。
「暗号を強くすればセキュリティがより強い物になると思います」
そんなの誰でも言えるじゃん
118 ：[名無し]さん(bin+cue).rar：03/12/18 02:24 ID:JD1ZSEV6
>>106 >>110
誰かすごいのいるのか？
RC4そのものを解読したんじゃなくて、プロトコルとか鍵のほうを解読したんだと思うが。
>>111
今年の春ぐらいにWEPの解読に関する論文読んだ気がするけどそれか？
確かそれはWEPのIVを突いて解読するとかだったような。
もしそれだったらこのスレにはそれほど関係ないけど、違ったらスマソ
誰かすごいのいるのか？
RC4そのものを解読したんじゃなくて、プロトコルとか鍵のほうを解読したんだと思うが。
>>111
今年の春ぐらいにWEPの解読に関する論文読んだ気がするけどそれか？
確かそれはWEPのIVを突いて解読するとかだったような。
もしそれだったらこのスレにはそれほど関係ないけど、違ったらスマソ
119 ：[名無し]さん(bin+cue).rar：03/12/18 02:42 ID:JD1ZSEV6
>>117
一応前スレまででは提案とか評価とかいろいろしてたけど、
このスレになってからまだ話しがないから
その前にちょっと話し出してみようと思っただけ。
前スレまでの仕様の話さえぎってるようならスマン
そっちを優先してください。
一応前スレまででは提案とか評価とかいろいろしてたけど、
このスレになってからまだ話しがないから
その前にちょっと話し出してみようと思っただけ。
前スレまでの仕様の話さえぎってるようならスマン
そっちを優先してください。
120 ：[名無し]さん(bin+cue).rar：03/12/18 02:56 ID:hKASuyeH
ステガノグラフィとかどうかな。
「ジャッカル！！」の自主制作映画とかにデータ埋め込んでしまえば、
たとえその中から何かデータが抽出できたとしても言い逃れできそうな気がする。
資金さえあれば人工衛星打ち上げて宇宙空間にサーバー立てれば
誰も手出し出来ない気はするけど。
「ジャッカル！！」の自主制作映画とかにデータ埋め込んでしまえば、
たとえその中から何かデータが抽出できたとしても言い逃れできそうな気がする。
資金さえあれば人工衛星打ち上げて宇宙空間にサーバー立てれば
誰も手出し出来ない気はするけど。
121 ：[名無し]さん(bin+cue).rar：03/12/18 03:13 ID:QNngEzRH
122 ：[名無し]さん(bin+cue).rar：03/12/18 03:30 ID:3PB3Tgh3
>>120
衛生ジャックして、姿勢制御弄ってオマイの家に落とす
衛生ジャックして、姿勢制御弄ってオマイの家に落とす
123 ：[名無し]さん(bin+cue).rar：03/12/18 06:56 ID:AnjIq6MK
124 ：[名無し]さん(bin+cue).rar：03/12/18 06:57 ID:whA83TLA
nyの場合匿名性っていうか当局への言い逃れ機能だろ
125 ：[名無し]さん(bin+cue).rar：03/12/18 07:58 ID:uYtu7clT
匿名性の定義の違い。
何を何からどれだけ匿うのかということ。
最初にネットワークにファイルを流通させた者を高レベルで匿う機能(キャッシュ)
DLをしている利用者が他の利用者から見てそのファイルを本当に要求しているものかどうか、
その意思を匿う機能もある(中継)
他にもいくつかあるが。
今回の逮捕に関しても実際特定ファイルのULに対して、
故意か過失かで裁判を争うことになればどういう判決が出るのか分からない。
>>123は安易にWinnyに匿名性は無いと言いたいだけちゃうんかと。
何を何からどれだけ匿うのかということ。
最初にネットワークにファイルを流通させた者を高レベルで匿う機能(キャッシュ)
DLをしている利用者が他の利用者から見てそのファイルを本当に要求しているものかどうか、
その意思を匿う機能もある(中継)
他にもいくつかあるが。
今回の逮捕に関しても実際特定ファイルのULに対して、
故意か過失かで裁判を争うことになればどういう判決が出るのか分からない。
>>123は安易にWinnyに匿名性は無いと言いたいだけちゃうんかと。
126 ：[名無し]さん(bin+cue).rar：03/12/18 09:45 ID:Unp0uvGf
127 ：[名無し]さん(bin+cue).rar：03/12/18 09:54 ID:xQYcUsyG
ブロッグってのは日記みたいな奴じゃないのか？
また別物だとおもうのだが・・・似てるといえば似てるか・・・
また別物だとおもうのだが・・・似てるといえば似てるか・・・
128 ：[名無し]さん(bin+cue).rar：03/12/18 10:30 ID:xEey/Z9c
ウェブロ
129 ：[名無し]さん(bin+cue).rar：03/12/18 11:38 ID:UY9YEQIm
まとめスレ見たけど
匿名部分と非匿名部分が混在する仕様になってるみたいだね
神認定したい気分
匿名部分と非匿名部分が混在する仕様になってるみたいだね
神認定したい気分
130 ：[名無し]さん(bin+cue).rar：03/12/18 12:22 ID:ert/Ph8a
131 ：[名無し]さん(bin+cue).rar：03/12/18 13:06 ID:kuAo7WJZ
132 ：[名無し]さん(bin+cue).rar：03/12/18 13:07 ID:qtERktof
現在もnyやってる人達にとっては正直、nyの匿名性うんちくはどーでもいい。
もう個人個人の自己責任の問題なんだから注意するだけ無駄。
「ny使用しただけの逮捕者」が出ないとみんな止めない。nyの危険性を理解して使用しない人はそーしてりゃいいんじゃん。
もう個人個人の自己責任の問題なんだから注意するだけ無駄。
「ny使用しただけの逮捕者」が出ないとみんな止めない。nyの危険性を理解して使用しない人はそーしてりゃいいんじゃん。
133 ：[名無し]さん(bin+cue).rar：03/12/18 13:40 ID:kuAo7WJZ
>>132
＞「ny使用しただけの逮捕者」
それは流石に無理だ。
こういうのもあるしな。
【合法】nyで合法ファイル流してみない？ part7
http://tmp2.2ch.net/test/read.cgi/download/1070990816/l50
いくら胡散臭かろうが、こういう活動を弾圧するのは基本的人権の侵害だぞ？
＞「ny使用しただけの逮捕者」
それは流石に無理だ。
こういうのもあるしな。
【合法】nyで合法ファイル流してみない？ part7
http://tmp2.2ch.net/test/read.cgi/download/1070990816/l50
いくら胡散臭かろうが、こういう活動を弾圧するのは基本的人権の侵害だぞ？
134 ：[名無し]さん(bin+cue).rar：03/12/18 15:22 ID:oSkfN9m3
そろそろスレ違いですよと言ってみる。
135 ：[名無し]さん(bin+cue).rar：03/12/18 15:46 ID:oO+503uQ
匿名性を優先して拡散効率や性能落とすより、
まず性能重視でバリバリ冗長化・完全キャッシュ保持指向でインフラ整備。
こりゃベンリだね、とweb・BBS・ストリーム配信・分散処理等が出来てきたところで、
おもむろに匿名性とキャッシュ分散化を主としたDLツールをそのインフラの上に乗せる、
という段階を踏んではどうか。
まず性能重視でバリバリ冗長化・完全キャッシュ保持指向でインフラ整備。
こりゃベンリだね、とweb・BBS・ストリーム配信・分散処理等が出来てきたところで、
おもむろに匿名性とキャッシュ分散化を主としたDLツールをそのインフラの上に乗せる、
という段階を踏んではどうか。
136 ：[名無し]さん(bin+cue).rar：03/12/18 15:58 ID:ert/Ph8a
>>135
言いたいことはわかる。
しかし、匿名性の実現のために取る仕組みによって通信方法などが大幅に
変わってしまうことがあるため、匿名性の仕組みを後から追加するというのは
難しい。
逆に、匿名の通信手段を構築してからキー流通やキャッシュ拡散を載せるというのなら
可能かも知れない。
いずれにせよ、見切り発車してもあんまりいいことはないと思うよ。
言いたいことはわかる。
しかし、匿名性の実現のために取る仕組みによって通信方法などが大幅に
変わってしまうことがあるため、匿名性の仕組みを後から追加するというのは
難しい。
逆に、匿名の通信手段を構築してからキー流通やキャッシュ拡散を載せるというのなら
可能かも知れない。
いずれにせよ、見切り発車してもあんまりいいことはないと思うよ。
137 ：[名無し]さん(bin+cue).rar：03/12/18 16:30 ID:kuAo7WJZ
>>135
＞まず性能重視でバリバリ冗長化・完全キャッシュ保持指向でインフラ整備。
＞こりゃベンリだね、とweb・BBS・ストリーム配信・分散処理等が出来てきたところで
つーかそれはインターネットプロトコルそのものじゃないのか？
インターネットプロトコルの上で、それより性能重視して改善できる余地なんてあるのか？
＞まず性能重視でバリバリ冗長化・完全キャッシュ保持指向でインフラ整備。
＞こりゃベンリだね、とweb・BBS・ストリーム配信・分散処理等が出来てきたところで
つーかそれはインターネットプロトコルそのものじゃないのか？
インターネットプロトコルの上で、それより性能重視して改善できる余地なんてあるのか？
138 ：[名無し]さん(bin+cue).rar：03/12/18 16:34 ID:oO+503uQ
生IP・NAT・FW内部の区別無くリンク可能なノード管理、ファイル同一性の保障 （nyのブロック毎・完全ハッシュチェック程度）
ファイルキーとファイルデータのIDを分離 （キャッシュ作成時にGUIDを付与し更新可能、実データはハッシュで管理）
とりあえず最低限ファイル名でキー検索可能、トリップ・コメント等はナシ
出来る限り冗長性の確保、暗号化は一切ナシ、効率重視、余計な統計管理ナシ、性善説第一
通常のファイル感覚でキャッシュを扱う為に、Winのネットワークプレースとして仮想ディスクを登録 （WebDAVでシステム管理）
最低限これだけの機能を持つインフラを先に作る。
とにかくなるたけnyユーザーを素早く取り込んで、分散ストレージとしてのデファクトスタンダードを強引に分捕っちゃえ、というわけ。
このシステムの上に匿名DLツールを作るという事は、「データは全てディスクを介してやりとりする」
わけで、キーの転送も一旦キャッシュ化して投網で集めるとか・・・やっぱダメかｗ
（分散メモリ共有まで視野に入れれば、あるいは・・・）
ファイルキーとファイルデータのIDを分離 （キャッシュ作成時にGUIDを付与し更新可能、実データはハッシュで管理）
とりあえず最低限ファイル名でキー検索可能、トリップ・コメント等はナシ
出来る限り冗長性の確保、暗号化は一切ナシ、効率重視、余計な統計管理ナシ、性善説第一
通常のファイル感覚でキャッシュを扱う為に、Winのネットワークプレースとして仮想ディスクを登録 （WebDAVでシステム管理）
最低限これだけの機能を持つインフラを先に作る。
とにかくなるたけnyユーザーを素早く取り込んで、分散ストレージとしてのデファクトスタンダードを強引に分捕っちゃえ、というわけ。
このシステムの上に匿名DLツールを作るという事は、「データは全てディスクを介してやりとりする」
わけで、キーの転送も一旦キャッシュ化して投網で集めるとか・・・やっぱダメかｗ
（分散メモリ共有まで視野に入れれば、あるいは・・・）
139 ：[名無し]さん(bin+cue).rar：03/12/18 16:39 ID:tNgwsvaa
次世代ファイル共有はWindowsの共有ファイル機能！
・SoftEther
http://tmp2.2ch.net/test/read.cgi/download/1071460423/l50
今、共有フォルダを公開している神がいる！
・SoftEther
http://tmp2.2ch.net/test/read.cgi/download/1071460423/l50
今、共有フォルダを公開している神がいる！
140 ：[名無し]さん(bin+cue).rar：03/12/18 16:42 ID:4g05Weis
>>138
自分で作れば誰も文句ないでしょ
自分で作れば誰も文句ないでしょ
141 ：[名無し]さん(bin+cue).rar：03/12/18 16:59 ID:tZdOfLAc
何度も言うが俺が作ってるからグタグタ言うんじゃねーよ。ヴァカ。
作れるスキルがあるやつは、言われなくても全部わかってんだよ。
作れるスキルがあるやつは、言われなくても全部わかってんだよ。
142 ：[名無し]さん(bin+cue).rar：03/12/18 17:05 ID:oO+503uQ
>>138 無理。（きっぱり）
誰かこれwinに移植してよ。
http://www.aist.go.jp/aist_j/press_release/pr2003/pr20031125/pr20031125.html
誰かこれwinに移植してよ。
http://www.aist.go.jp/aist_j/press_release/pr2003/pr20031125/pr20031125.html
143 ：[名無し]さん(bin+cue).rar：03/12/18 17:05 ID:oO+503uQ
間違い。>>140
144 ：[名無し]さん(bin+cue).rar：03/12/18 17:21 ID:HS55YUAV
:::::::::::::::::::::::::::::::::| / ,,|:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::| //''" ||:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|/ -=･ｯ|:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|| ;:.;..:.|:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|し |:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|::::::一 |:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|ヽ .／|:::::::::::::::::::::::::::::::::
こ の ス レ は 監 視 さ れ て ま す
:::::::::::::::::::::::::::::::::| //''" ||:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|/ -=･ｯ|:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|| ;:.;..:.|:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|し |:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|::::::一 |:::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::|ヽ .／|:::::::::::::::::::::::::::::::::
こ の ス レ は 監 視 さ れ て ま す
145 ：[名無し]さん(bin+cue).rar：03/12/18 17:42 ID:qVMssd5h
146 ：[名無し]さん(bin+cue).rar：03/12/18 17:45 ID:AOs/xOlV
>>118
亀レスだが暗号を独自方法で解読したとか書いて有った様な気がした。
亀レスだが暗号を独自方法で解読したとか書いて有った様な気がした。
147 ：[名無し]さん(bin+cue).rar：03/12/18 17:56 ID:oO+503uQ
企業・優良ユーザーをどうにかしてシステムに参加させて、
「その過半数の違法ユーザーの動向によっては、システムが崩壊する」状況を作り出したい。
「ディスク容量の拠出」という代償をカードにしたnyが、最も近い存在だった。
nyによるアニメ動画のオンデマンド配信サービスが実用的に稼動してたら、
「ny使っただけで逮捕もあり得る」なんて言葉は完全に営業妨害。
せめてDDE拡張でもあれば・・・ nykageとか作ってよ >>141
「その過半数の違法ユーザーの動向によっては、システムが崩壊する」状況を作り出したい。
「ディスク容量の拠出」という代償をカードにしたnyが、最も近い存在だった。
nyによるアニメ動画のオンデマンド配信サービスが実用的に稼動してたら、
「ny使っただけで逮捕もあり得る」なんて言葉は完全に営業妨害。
せめてDDE拡張でもあれば・・・ nykageとか作ってよ >>141
148 ：[名無し]さん(bin+cue).rar：03/12/18 20:50 ID:ueO66rX4
中継するＰＣの数って簡単に制御できるかなあ？
検索かけて直接ファイル持ってるやつに会ったら直接
ダウソする仕組みでしょ？
検索かけて直接ファイル持ってるやつに会ったら直接
ダウソする仕組みでしょ？
149 ：[名無し]さん(bin+cue).rar：03/12/18 21:29 ID:qvI8aR1N
想像してみる。絶対破れない匿名性のあるｎｙが開発されたとする。
で、それを繋げっ放しで起動させ続けるよな。
もちろんそんなことしてたら、転送量が人より格段に多くなる。
丸一日高負荷かけてるから注目されるのはまぁ当たり前。
だったら後は別件ﾀｲｰﾎ発動させて、PC内部を調べればいいだけだな。
で、それを繋げっ放しで起動させ続けるよな。
もちろんそんなことしてたら、転送量が人より格段に多くなる。
丸一日高負荷かけてるから注目されるのはまぁ当たり前。
だったら後は別件ﾀｲｰﾎ発動させて、PC内部を調べればいいだけだな。
150 ：[名無し]さん(bin+cue).rar：03/12/18 21:49 ID:C+5g8uzs
151 ：[名無し]さん(bin+cue).rar：03/12/18 22:49 ID:lRmcXy3u
152 ：[名無し]さん(bin+cue).rar：03/12/18 23:08 ID:P7FP5+53
だ か ら、著作権の詰めは現実的な側面からもう終わってるので既にスレ違いの上に既出。
他スレでやれよ。
ここは、仕様を語るスレ。
ついでにもう作り始めてる（と思われる）神の意見交換の為のスレ。
故意にループさせてるとＡＣＣＳのレッテル貼られて常連にはスルーされてる
ことにいいかげん気づけ。
まったく。ばかじゃねーの。
他スレでやれよ。
ここは、仕様を語るスレ。
ついでにもう作り始めてる（と思われる）神の意見交換の為のスレ。
故意にループさせてるとＡＣＣＳのレッテル貼られて常連にはスルーされてる
ことにいいかげん気づけ。
まったく。ばかじゃねーの。
153 ：[名無し]さん(bin+cue).rar：03/12/18 23:14 ID:LpqRijMQ
>>149
自分ではﾀﾞｳｿせず、ひたすらキャッシュノードに徹する。
自分では落とさないからキャッシュに何が入っているかは全く分からない。
Kが踏み込んで家宅捜査したは良いが、容疑を裏付ける証拠が見つからなかったら面白い事になりそうだな。
もちろんKに踏み込まれる事を前提に弁護士と予め相談してすぐに呼べるようにしておく。
もちろん、部分キャッシュから復元できないシステムでないとダメだが。
これで違法ならISP自体がﾔｳﾞｧｲ。
自分とこの施設でファイル交換されているだけでアウト。
自分ではﾀﾞｳｿせず、ひたすらキャッシュノードに徹する。
自分では落とさないからキャッシュに何が入っているかは全く分からない。
Kが踏み込んで家宅捜査したは良いが、容疑を裏付ける証拠が見つからなかったら面白い事になりそうだな。
もちろんKに踏み込まれる事を前提に弁護士と予め相談してすぐに呼べるようにしておく。
もちろん、部分キャッシュから復元できないシステムでないとダメだが。
これで違法ならISP自体がﾔｳﾞｧｲ。
自分とこの施設でファイル交換されているだけでアウト。
154 ：[名無し]さん(bin+cue).rar：03/12/18 23:21 ID:lRmcXy3u
155 ：[名無し]さん(bin+cue).rar：03/12/18 23:24 ID:oSkfN9m3
こうやって匿名性を長々と語る人にこそテストして欲しいと思うんだが…。
156 ：[名無し]さん(bin+cue).rar：03/12/18 23:44 ID:QgcSxbuD
まとめページも見れない臆病者はしね
157 ：[名無し]さん(bin+cue).rar：03/12/18 23:45 ID:vl/r87W7
>>154は只の教えて君
158 ：[名無し]さん(bin+cue).rar：03/12/18 23:57 ID:lRmcXy3u
ふはははは！
安全だと言い切れるヤツは居ないようだな！
どうやら俺の勝ちのようだな。
俺様にひざまずけチンカスども。
安全だと言い切れるヤツは居ないようだな！
どうやら俺の勝ちのようだな。
俺様にひざまずけチンカスども。
159 ：[名無し]さん(bin+cue).rar：03/12/18 23:58 ID:l2xM7rVu
>>125
>>153の様なノードがある可能性があると言う部分は確かに
説明していないが、こういうノードかどうかを調べる方法がある。
まず警察はファイルを探しているターゲットに
そのファイルのある位置は警察ですよ、と言うキーを返す。
(予断だが、クラスタ化は仕様上たまたま実現した物だ。
この不出来な検索システム故に友好な値を返す警察クラスタに
容易に突入し、且つ居座ってしまう)
そしてDL要求が来たら他ノードからファイルを転送してDLさせてあげる。
これでそのノードからそのファイルが長期にアップされているのを
確認すれば、そいつは犯罪行為をしていると確定する。
ソースさえあればおれがこれを可能にするツールを作れると言ってるんだ。
おれが作れるんだから、某警察のハイテク担当なら簡単に作れるだろう。
だからソースを押収したんだとおれは思っているんだが、他に理由があるのか？
警察が単に見たかっただけと言う理由で押収するはず無いでしょうに。
この様なおとり捜査をヘビーユーザーを対象に行われる可能性がある。
わざわざライトユーザーに対し行うには酷だからね。
>>153の様なノードがある可能性があると言う部分は確かに
説明していないが、こういうノードかどうかを調べる方法がある。
まず警察はファイルを探しているターゲットに
そのファイルのある位置は警察ですよ、と言うキーを返す。
(予断だが、クラスタ化は仕様上たまたま実現した物だ。
この不出来な検索システム故に友好な値を返す警察クラスタに
容易に突入し、且つ居座ってしまう)
そしてDL要求が来たら他ノードからファイルを転送してDLさせてあげる。
これでそのノードからそのファイルが長期にアップされているのを
確認すれば、そいつは犯罪行為をしていると確定する。
ソースさえあればおれがこれを可能にするツールを作れると言ってるんだ。
おれが作れるんだから、某警察のハイテク担当なら簡単に作れるだろう。
だからソースを押収したんだとおれは思っているんだが、他に理由があるのか？
警察が単に見たかっただけと言う理由で押収するはず無いでしょうに。
この様なおとり捜査をヘビーユーザーを対象に行われる可能性がある。
わざわざライトユーザーに対し行うには酷だからね。
160 ：[名無し]さん(bin+cue).rar：03/12/19 00:03 ID:YpKJ/TJA
161 ：[名無し]さん(bin+cue).rar：03/12/19 00:04 ID:G0uA5NJf
作ってる人達と常連（テスター陣）はあまりのスレの酷さにひたすらスルー状態だな
162 ：[名無し]さん(bin+cue).rar：03/12/19 00:04 ID:gGMkB8N/
163 ：[名無し]さん(bin+cue).rar：03/12/19 00:07 ID:YpKJ/TJA
164 ：[名無し]さん(bin+cue).rar：03/12/19 00:12 ID:G0uA5NJf
>>163
本物の馬鹿発見・・・
本物の馬鹿発見・・・
165 ：[名無し]さん(bin+cue).rar：03/12/19 00:32 ID:YpKJ/TJA
166 ：[名無し]さん(bin+cue).rar：03/12/19 00:53 ID:uMPX6jJh
>>159
＞まず警察はファイルを探しているターゲットに
＞そのファイルのある位置は警察ですよ、と言うキーを返す。
＞そしてDL要求が来たら他ノードからファイルを転送してDLさせてあげる。
違法捜査？
＞まず警察はファイルを探しているターゲットに
＞そのファイルのある位置は警察ですよ、と言うキーを返す。
＞そしてDL要求が来たら他ノードからファイルを転送してDLさせてあげる。
違法捜査？
167 ：[名無し]さん(bin+cue).rar：03/12/19 04:05 ID:Bs49sqF+
新しいＰ2Ｐが出てくると困る人がこのスレで必死なのが良くわかるレスが続いているのですね。
168 ：[名無し]さん(bin+cue).rar：03/12/19 06:57 ID:Vaxn1jcS
nyみたく転送動作自体に匿名性を持たせる方法ってどんなのがあるよ？
169 ：[名無し]さん(bin+cue).rar：03/12/19 16:46 ID:At6ov0nj
ここまでまともな話がないと
提案していいのか迷うわけだが
提案していいのか迷うわけだが
170 ：[名無し]さん(bin+cue).rar：03/12/19 16:47 ID:o0bVhOxe
>>169
Wikiに投稿しとけ
Wikiに投稿しとけ
三井不動産の真実（元社員告発）
大企業の理由なき横暴を阻止するよう
皆様のご協力をお願いいたします
是非ご高覧の程、よろしくお願い申し上げます
http://www.geocities.co.jp/WallStreet-Bull/8779/
大企業の理由なき横暴を阻止するよう
皆様のご協力をお願いいたします
是非ご高覧の程、よろしくお願い申し上げます
http://www.geocities.co.jp/WallStreet-Bull/8779/
172 ：[名無し]さん(bin+cue).rar：03/12/19 18:15 ID:ZbvA9+UL
173 ：[名無し]さん(bin+cue).rar：03/12/19 23:13 ID:i0LtG7Do
174 ：[名無し]さん(bin+cue).rar：03/12/19 23:15 ID:OuCWEI9h
>>173
脊椎が反射するのか？
脊椎が反射するのか？
175 ：[名無し]さん(bin+cue).rar：03/12/19 23:18 ID:8XZKEcJV
ここもこのまま雑談ｽﾚ化するのか？
176 ：[名無し]さん(bin+cue).rar：03/12/19 23:23 ID:isx+fxHi
雑談 ＆ プロジェクトをウォッチするスレかな。
177 ：[名無し]さん(bin+cue).rar：03/12/19 23:24 ID:At6ov0nj
ちょっとだけ案があるけど、ぜんぜんまとまってない。
178 ：[名無し]さん(bin+cue).rar：03/12/19 23:27 ID:fgNfdUJr
人がいなくなった。。。
179 ：[名無し]さん(bin+cue).rar：03/12/19 23:28 ID:i0LtG7Do
>>174
既出
既出
180 ：[名無し]さん(bin+cue).rar：03/12/19 23:42 ID:jVTJyBJY
YpKJ/TJA =i0LtG7Do
sageたりsageれてなかったりうざい奴だな （ ・∀・ ）ｶｴﾚ!!
sageたりsageれてなかったりうざい奴だな （ ・∀・ ）ｶｴﾚ!!
182 ：[名無し]さん(bin+cue).rar：03/12/19 23:51 ID:XSKtGgCB
>>179
それこそ既出
それこそ既出
183 ：[名無し]さん(bin+cue).rar：03/12/20 00:09 ID:cpfogyuE
ネトゲにファイル交換機能みたいなのをつけて、
ゲームのパケットなのか何なのかわかりにくくするとか。
オープンソースのネトゲ自体はSourceForgeで開発が実際行われているらしいが。
ゲームのパケットなのか何なのかわかりにくくするとか。
オープンソースのネトゲ自体はSourceForgeで開発が実際行われているらしいが。
184 ：[名無し]さん(bin+cue).rar：03/12/20 00:15 ID:Zt6wrvEM
完成近いんでお前らの愚考などゴミ以下なんだよ
185 ：[名無し]さん(bin+cue).rar：03/12/20 00:18 ID:Xd0dI+e7
テスターした上で問題点解決できる提案できる香具師希望ってことだね
186 ：[名無し]さん(bin+cue).rar：03/12/20 00:22 ID:kyrR0DAr
提案したいがその前提として、
RAIDだとかの分散しているものをダウンロードする方式だと
初UPする人の匿名性の確保も課題の１つ。
通信路を暗号化していない場合、ひとつのノードの通信を全て記録し、
一度も受け取ったことのないデータ（ファイル）を送信した場合、初UPが確定する。
の、２つは間違ってないかな？
RAIDだとかの分散しているものをダウンロードする方式だと
初UPする人の匿名性の確保も課題の１つ。
通信路を暗号化していない場合、ひとつのノードの通信を全て記録し、
一度も受け取ったことのないデータ（ファイル）を送信した場合、初UPが確定する。
の、２つは間違ってないかな？
187 ：[名無し]さん(bin+cue).rar：03/12/20 00:36 ID:hKj1vq3G
ある程度意見は出尽くしたし、作ってる人はまとめサイトのほうでやってるし
今はできるのを待ってる状態だろうな。
何かできんことには膠着状態だろう。
そういやまとめサイトに出てた次期P2Pの名前OZ(オープンゼロ)はいい名前だと思うし
それにして欲しかったりする
今はできるのを待ってる状態だろうな。
何かできんことには膠着状態だろう。
そういやまとめサイトに出てた次期P2Pの名前OZ(オープンゼロ)はいい名前だと思うし
それにして欲しかったりする
188 ：[名無し]さん(bin+cue).rar：03/12/20 00:55 ID:qDZJBvsV
189 ：[名無し]さん(bin+cue).rar：03/12/20 00:58 ID:VnziwXBF
考えがまとまって来たので、そろそろ提案をブッこんで行きたい。
匿名性は低いかもしれないが、逮捕されないシステムを考えた。
概要なので詳細は詰めないといけないがまぁ聞いてくれ。
外国だがハッキングされたと言い訳して無罪になった人が多い。
そこで、次期P2Pソフトは自分と同じプログラムに対して
バッファオーバーフローでハックする機能を持てば良い。
乗っ取られスレッドでも用意しといてそのスレッドは攻撃者の欲しいファイルを
ダウンして勝手にキャッシュ作って攻撃者に送信する。
ハックしたシステムに既にキャッシュがあれば当然それを送信。
これでアップの違法性は問われない。
ソースコードは自分が作ってるわけだから穴開けるのもハックするのも容易だ。
乗っ取られスレッドの数を制限する事も技術的には可能だから、
コントロールされたセキュリティホールということだ。
これは単なるファイルの共有ではなく、各ノード間で処理（責任）を
譲位しあうというかつてないパラダイムシフトなシステムだ。
唯一問題があるとすれば、単にハッキングで罪に問われるということだ。
匿名性は低いかもしれないが、逮捕されないシステムを考えた。
概要なので詳細は詰めないといけないがまぁ聞いてくれ。
外国だがハッキングされたと言い訳して無罪になった人が多い。
そこで、次期P2Pソフトは自分と同じプログラムに対して
バッファオーバーフローでハックする機能を持てば良い。
乗っ取られスレッドでも用意しといてそのスレッドは攻撃者の欲しいファイルを
ダウンして勝手にキャッシュ作って攻撃者に送信する。
ハックしたシステムに既にキャッシュがあれば当然それを送信。
これでアップの違法性は問われない。
ソースコードは自分が作ってるわけだから穴開けるのもハックするのも容易だ。
乗っ取られスレッドの数を制限する事も技術的には可能だから、
コントロールされたセキュリティホールということだ。
これは単なるファイルの共有ではなく、各ノード間で処理（責任）を
譲位しあうというかつてないパラダイムシフトなシステムだ。
唯一問題があるとすれば、単にハッキングで罪に問われるということだ。
190 ：[名無し]さん(bin+cue).rar：03/12/20 01:05 ID:WJ3L002Q
オープンゼロでいくと、解説サイトが出来たときに
『オープンゼロに搭載されたゼロシステムとは、人間の(以下略)』
というガンオタのコメントがつくことが危惧されます。
これはサンクキングうわなにをするやめ
『オープンゼロに搭載されたゼロシステムとは、人間の(以下略)』
というガンオタのコメントがつくことが危惧されます。
これはサンクキングうわなにをするやめ
191 ：[名無し]さん(bin+cue).rar：03/12/20 01:12 ID:nsK9mZ8N
受信側の何かを監視したり、操作するのは、オープンなら駄目だろう。
サクッとクラックてゆうか、監視を欺くバージョン作られるだけ。
サイズに比べて参照量が少ないファイルは、アップするブロックごとに
分けてランダムにアップするブロックを変えるのがいいと思う。
「PC-A」がファイル「F」をアップするとして
「PC-B」にはF(1)
「PC-C」にはF(2)
「PC-D」にはF(3)
それぞれにアップすると、B-C-D間でも保管できる。
サクッとクラックてゆうか、監視を欺くバージョン作られるだけ。
サイズに比べて参照量が少ないファイルは、アップするブロックごとに
分けてランダムにアップするブロックを変えるのがいいと思う。
「PC-A」がファイル「F」をアップするとして
「PC-B」にはF(1)
「PC-C」にはF(2)
「PC-D」にはF(3)
それぞれにアップすると、B-C-D間でも保管できる。
192 ：[名無し]さん(bin+cue).rar：03/12/20 01:15 ID:nsK9mZ8N
>>188
サンクス
最近はISPにもいろいろとあるからね。
ただ、大きな組織が攻撃（盗聴とか）してくる場合は、
接続先ノードの複数に悪意がある（おとり）こともあるから、
暗号化すればいいってもんじゃないんだよな～。
なんか俺以外の人が先に提案してくれたけど、
これはギャグと受け止めていいのかな？
サンクス
最近はISPにもいろいろとあるからね。
ただ、大きな組織が攻撃（盗聴とか）してくる場合は、
接続先ノードの複数に悪意がある（おとり）こともあるから、
暗号化すればいいってもんじゃないんだよな～。
なんか俺以外の人が先に提案してくれたけど、
これはギャグと受け止めていいのかな？
ギャグっていったのは>>189のことね。
195 ：[名無し]さん(bin+cue).rar：03/12/20 01:33 ID:cUMmlzqW
すすすすすすすすすす、すいません。
オープンゼロってめためためためためためためたｶｺｲｲ!
宇宙ヤバイぐらいｶｺｲｲ!ネーミングセンスがたまらない。
オープンゼロ!オープンゼロ!オープンゼロ!オープンゼロ!
失敬。
オープンゼロってめためためためためためためたｶｺｲｲ!
宇宙ヤバイぐらいｶｺｲｲ!ネーミングセンスがたまらない。
オープンゼロ!オープンゼロ!オープンゼロ!オープンゼロ!
失敬。
196 ：[名無し]さん(bin+cue).rar：03/12/20 02:07 ID:+ZXXnv8V
さすがにギャグだろ…と思いたい。
そんな事したら好きなコード実行されてしまうよ…
そんな事したら好きなコード実行されてしまうよ…
197 ：[名無し]さん(bin+cue).rar：03/12/20 02:35 ID:te1rkut7
思い付きを文章にしてたら、途中でボツな可能性が大きいことに気づいた。
せっかくだから、一応下に書いとく。
1.まず各ノードが公開鍵を用意し公開・中継する。
このとき各中継ノードはダウン要求（送信要求）キーのように、
どの接続先から来たものかを識別子などで識別できるようにする。
2.UPしたい人は、UP対象のファイルを(RAIDなどの)分割法にのっとり分割する。
3.流れてきた公開鍵の中から１つを選び、その鍵で分割した断片を暗号化し公開鍵を中継してきたノードに返す。
実際には共通鍵方式とのハイブリッド方式で暗号化する。
4.暗号化された断片がその公開鍵を作ったノードまで届いた場合、
そのノードは断片を復号（解読）しここで初めて他の全てのノードにファイルそのものをUPする。
この場合、実際にファイルを公開するノードは、ファイルを作成したノードとは異なることになる。
また公開鍵を作ったノードは、誰が自分の鍵で暗号化して
送ってきたのかが中継によってわかりにくくなっている。
このときの公開鍵は"UP要求キー"のようなものなので、初UPファイル以外で拡散させる必要のある断片を送信
するときなどにも使わないと、攻撃者が初UPを検出するためのものになってしまうだけ。
さらに、公開鍵を作ったノードが悪意を持ってて（おとりノードで）、
その鍵で初UPをしたノードと隣接していたら・・・。
そもそも、初UPノードと公開ノードとの間で通信量が増えるわけで、
公開ノードが悪意を持っていた場合に、初UPノードまでルートが隠せないと意味がない・・・・。
要するに、公開ノードが初UPノード特定できなければいいわけだが、それができたら苦労しない・・・。
しかもこの場合中継しても暗号化されてるからキャッシュする意味ないし、
ファイルサイズが大きい場合、途中で切れたらどうするんだって話なわけで・・・。
ついでに帯域の無駄多すぎかな・・・。
もう眠すぎるからこのへんで。
せっかくだから、一応下に書いとく。
1.まず各ノードが公開鍵を用意し公開・中継する。
このとき各中継ノードはダウン要求（送信要求）キーのように、
どの接続先から来たものかを識別子などで識別できるようにする。
2.UPしたい人は、UP対象のファイルを(RAIDなどの)分割法にのっとり分割する。
3.流れてきた公開鍵の中から１つを選び、その鍵で分割した断片を暗号化し公開鍵を中継してきたノードに返す。
実際には共通鍵方式とのハイブリッド方式で暗号化する。
4.暗号化された断片がその公開鍵を作ったノードまで届いた場合、
そのノードは断片を復号（解読）しここで初めて他の全てのノードにファイルそのものをUPする。
この場合、実際にファイルを公開するノードは、ファイルを作成したノードとは異なることになる。
また公開鍵を作ったノードは、誰が自分の鍵で暗号化して
送ってきたのかが中継によってわかりにくくなっている。
このときの公開鍵は"UP要求キー"のようなものなので、初UPファイル以外で拡散させる必要のある断片を送信
するときなどにも使わないと、攻撃者が初UPを検出するためのものになってしまうだけ。
さらに、公開鍵を作ったノードが悪意を持ってて（おとりノードで）、
その鍵で初UPをしたノードと隣接していたら・・・。
そもそも、初UPノードと公開ノードとの間で通信量が増えるわけで、
公開ノードが悪意を持っていた場合に、初UPノードまでルートが隠せないと意味がない・・・・。
要するに、公開ノードが初UPノード特定できなければいいわけだが、それができたら苦労しない・・・。
しかもこの場合中継しても暗号化されてるからキャッシュする意味ないし、
ファイルサイズが大きい場合、途中で切れたらどうするんだって話なわけで・・・。
ついでに帯域の無駄多すぎかな・・・。
もう眠すぎるからこのへんで。
199 ：[名無し]さん(bin+cue).rar：03/12/20 03:23 ID:qDZJBvsV
>>198
んー、狙ってる方向性を突き詰めると「隣接ノードに情報を漏らさない」方式に
なるような気がする。その方式では、リクを受けたのと別な方向のノードに
暗号化した状態でデータを中継してもらうことで問題を解決してる。
もしまだ読んでないなら読んでみるといい鴨。
ただし、
> しかもこの場合中継しても暗号化されてるからキャッシュする意味ないし、
> ファイルサイズが大きい場合、途中で切れたらどうするんだって話なわけで・・・。
> ついでに帯域の無駄多すぎかな・・・。
この辺はやはり隣接云々形式でも泣き所。なんとかなんないもんかね。
んー、狙ってる方向性を突き詰めると「隣接ノードに情報を漏らさない」方式に
なるような気がする。その方式では、リクを受けたのと別な方向のノードに
暗号化した状態でデータを中継してもらうことで問題を解決してる。
もしまだ読んでないなら読んでみるといい鴨。
ただし、
> しかもこの場合中継しても暗号化されてるからキャッシュする意味ないし、
> ファイルサイズが大きい場合、途中で切れたらどうするんだって話なわけで・・・。
> ついでに帯域の無駄多すぎかな・・・。
この辺はやはり隣接云々形式でも泣き所。なんとかなんないもんかね。
200 ：[名無し]さん(bin+cue).rar：03/12/20 05:45 ID:S+7dWfRQ
まとめページのトップ、「ストレージ上の共有ファイル」へのリンクが間違ってる
201 ：[名無し]さん(bin+cue).rar：03/12/20 06:48 ID:mYAzS+Q4
あのー、、、通信効率と３種類ある（もっとか？）匿名性ってのは
結局トレードオフな関係にあると思うわけですが、
その内どれを優先したいかってのは、人によって違うわけで、
いくら議論しても一致した意見は得られないような気がするんですが、
その辺はどうなるんでしょう？
やっぱりなんとしてでも一致させるしかないんですかねえ？
それとも例えば暗号化したい人と、そんなもんよりRAID5にしろって人の間で
通信することってできるんでしょうか？
もっと言うと、２７氏の作ってるものと、むーむー氏の作ってるものは
最終的には相互に通信できるようになるんでしょうか？
結局トレードオフな関係にあると思うわけですが、
その内どれを優先したいかってのは、人によって違うわけで、
いくら議論しても一致した意見は得られないような気がするんですが、
その辺はどうなるんでしょう？
やっぱりなんとしてでも一致させるしかないんですかねえ？
それとも例えば暗号化したい人と、そんなもんよりRAID5にしろって人の間で
通信することってできるんでしょうか？
もっと言うと、２７氏の作ってるものと、むーむー氏の作ってるものは
最終的には相互に通信できるようになるんでしょうか？
202 ：[名無し]さん(bin+cue).rar：03/12/20 07:02 ID:Xd0dI+e7
というか、むーむー氏は最近見ないなぁ。どうしてるんだろ。
その代わりディスク共有システムの方の人が頑張ってるみたいだけど。
27氏のは着々と進んでるみたいですね。何気に新月の作者も来てるみたいだし。
どれかが基本になって統合されてという形になるんだろうか？
その代わりディスク共有システムの方の人が頑張ってるみたいだけど。
27氏のは着々と進んでるみたいですね。何気に新月の作者も来てるみたいだし。
どれかが基本になって統合されてという形になるんだろうか？
203 ：[名無し]さん(bin+cue).rar：03/12/20 07:12 ID:8lTOyWU/
26氏(27だっけ?)はオープンソースだけど、ディスク共有は
クローズ開発だから、統合はないと思われ
むーむー氏と26氏の統合はあるかも
むーむー氏かむばああああっく
クローズ開発だから、統合はないと思われ
むーむー氏と26氏の統合はあるかも
むーむー氏かむばああああっく
204 ：[名無し]さん(bin+cue).rar：03/12/20 09:00 ID:Owb0Hgj7
むーむーはウインドウズのプログラム作れないから期待するだけ無駄
新月の作者もクローン作る人探してるようだけど
よほど人気があるプログラムでならともかく
他人が作ったもの移植するぐらいなら、最初から自分で作るだろう。
新月の作者もクローン作る人探してるようだけど
よほど人気があるプログラムでならともかく
他人が作ったもの移植するぐらいなら、最初から自分で作るだろう。
205 ：[名無し]さん(bin+cue).rar：03/12/20 11:16 ID:LVunGCSF
>>201
> やっぱりなんとしてでも一致させるしかないんですかねえ？
んなこたーない。別に全員でたった１つの作品を作ろうとしてるわけじゃない。
どの方式も一長一短なので、開発してる人それぞれが改良するなり
組み合わせるなりして好きな方法を使えばいい。
それに、今はまだ実用目的のものが出てくる段階ではないと思う。
むー氏が作ってるものも実証用なので、他方式との統合も無意味。
むー氏は独自方式で各種の問題を解決できると考えているようだ。
残念ながら詳細な仕様が出てきてないので判断できないが、
テスト用コードでそれが証明されれば、その方式をまねて誰かが Windows
ネイティブで作るでしょう（別に移植や互換である必要はない）。
実用段階のが出てくるとしたら、それが一番早いシナリオかもね。
しかしむーむー氏出てこないなあ。開発に専念してくれた方がいいけど、
最低でも２日に１回くらいは顔出してくれれば安心できるんだが。
> やっぱりなんとしてでも一致させるしかないんですかねえ？
んなこたーない。別に全員でたった１つの作品を作ろうとしてるわけじゃない。
どの方式も一長一短なので、開発してる人それぞれが改良するなり
組み合わせるなりして好きな方法を使えばいい。
それに、今はまだ実用目的のものが出てくる段階ではないと思う。
むー氏が作ってるものも実証用なので、他方式との統合も無意味。
むー氏は独自方式で各種の問題を解決できると考えているようだ。
残念ながら詳細な仕様が出てきてないので判断できないが、
テスト用コードでそれが証明されれば、その方式をまねて誰かが Windows
ネイティブで作るでしょう（別に移植や互換である必要はない）。
実用段階のが出てくるとしたら、それが一番早いシナリオかもね。
しかしむーむー氏出てこないなあ。開発に専念してくれた方がいいけど、
最低でも２日に１回くらいは顔出してくれれば安心できるんだが。
206 ：[名無し]さん(bin+cue).rar：03/12/20 11:30 ID:nUczmZF1
207 ：[名無し]さん(bin+cue).rar：03/12/20 11:35 ID:LVunGCSF
208 ：[名無し]さん(bin+cue).rar：03/12/20 11:42 ID:UvXQa1C7
209 ：[名無し]さん(bin+cue).rar：03/12/20 11:59 ID:nUczmZF1
>>208
そこまで違うものなん！？？ まあ、ＳＳＬのやり方真似ればいいと思うけど。
公開鍵方式を共通鍵の交換のためだけに使うやつ。
>>209
なんかキツイ書き方でスマソ。
公開鍵で暗号化したものは秘密鍵で復号化できるし、秘密鍵で暗号化した
ものは公開鍵で復号化できる。
そこまで違うものなん！？？ まあ、ＳＳＬのやり方真似ればいいと思うけど。
公開鍵方式を共通鍵の交換のためだけに使うやつ。
>>209
なんかキツイ書き方でスマソ。
公開鍵で暗号化したものは秘密鍵で復号化できるし、秘密鍵で暗号化した
ものは公開鍵で復号化できる。
211 ：[名無し]さん(bin+cue).rar：03/12/20 13:09 ID:HqBcGW8K
>>199
ほんとだかなり似てた。
「隣接ノードに情報を漏らさない」は全部読んでないけど、
時間があるときにしっかり読んでおかないと。
ただ、悪意のある隣接ノードがあたかもその先にノードがあるように見せかけて、
結局隣接ノード間で通信しようとするかもしれないし・・・。
他にもいくつか考えたけど、やっぱり"完璧"を求めるのは厳しい。
というか、"完璧にはできない"と証明できそうな勢い・・。
ほんとだかなり似てた。
「隣接ノードに情報を漏らさない」は全部読んでないけど、
時間があるときにしっかり読んでおかないと。
ただ、悪意のある隣接ノードがあたかもその先にノードがあるように見せかけて、
結局隣接ノード間で通信しようとするかもしれないし・・・。
他にもいくつか考えたけど、やっぱり"完璧"を求めるのは厳しい。
というか、"完璧にはできない"と証明できそうな勢い・・。
213 ：[名無し]さん(bin+cue).rar：03/12/20 14:26 ID:xj+WrkcI
214 ：[名無し]さん(bin+cue).rar：03/12/20 14:30 ID:GaRrB9l2
freenet + frost
http://tmp2.2ch.net/test/read.cgi/download/1069942913/715n
> 715 [名無し]さん(bin+cue).rar sage 03/12/20 12:36 ID:SvoR6AQo
> ──────────────────────────────────────────────────
> 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.
> http://mute-net.sourceforge.net/
> 海外製Winny？
http://tmp2.2ch.net/test/read.cgi/download/1069942913/715n
> 715 [名無し]さん(bin+cue).rar sage 03/12/20 12:36 ID:SvoR6AQo
> ──────────────────────────────────────────────────
> 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.
> http://mute-net.sourceforge.net/
> 海外製Winny？
215 ：[名無し]さん(bin+cue).rar：03/12/20 14:54 ID:VPiTh6pN
>>213
アイデアぱくって何か悪いのか？
プログラミングなんて基本的にパクりだろ。
ネタ師かもしれないってのは、みんな思ってる。
（真面目にやって頓挫するのも含めて）
そういうのもわかった上で、みんな楽しんでるんだよ。
おまえこそ空気嫁よ。
アイデアぱくって何か悪いのか？
プログラミングなんて基本的にパクりだろ。
ネタ師かもしれないってのは、みんな思ってる。
（真面目にやって頓挫するのも含めて）
そういうのもわかった上で、みんな楽しんでるんだよ。
おまえこそ空気嫁よ。
216 ：[名無し]さん(bin+cue).rar：03/12/20 14:56 ID:xj+WrkcI
>>215
自分が考えたようにいうのは詐欺だよ。ﾊﾞｰｶ。
実際はreadmeか何かに参考文献書いてるだろうが。
何が「むーむーが考える仕様」だ从ﾘ ﾟдﾟﾉﾘ ﾎﾞｫｹ
頓挫じゃなくはじめから作ってねーんだよ。
思ってるじゃなくてネタ師だよ
自分が考えたようにいうのは詐欺だよ。ﾊﾞｰｶ。
実際はreadmeか何かに参考文献書いてるだろうが。
何が「むーむーが考える仕様」だ从ﾘ ﾟдﾟﾉﾘ ﾎﾞｫｹ
頓挫じゃなくはじめから作ってねーんだよ。
思ってるじゃなくてネタ師だよ
217 ：[名無し]さん(bin+cue).rar：03/12/20 14:57 ID:Xd0dI+e7
218 ：[名無し]さん(bin+cue).rar：03/12/20 14:59 ID:rVwuSmdj
単なる個人攻撃なら他でやってくれ
219 ：[名無し]さん(bin+cue).rar：03/12/20 15:01 ID:xj+WrkcI
220 ：[名無し]さん(bin+cue).rar：03/12/20 15:01 ID:Xd0dI+e7
>>216
とマジレスした後に思ったのだが、君はむーむー氏にパクリだ！って
必死に粘着してた某ド厨掲示板の住人かな？
ネタだったとしても、仕様を考える上で問題点の洗い出しとして有意義だったし。
少なくとも君よりは存在価値はあるね。
とマジレスした後に思ったのだが、君はむーむー氏にパクリだ！って
必死に粘着してた某ド厨掲示板の住人かな？
ネタだったとしても、仕様を考える上で問題点の洗い出しとして有意義だったし。
少なくとも君よりは存在価値はあるね。
221 ：[名無し]さん(bin+cue).rar：03/12/20 15:05 ID:VPiTh6pN
そういえばいたな。そんなヤツが。
また湧いて来たのか。
また湧いて来たのか。
222 ：[名無し]さん(bin+cue).rar：03/12/20 15:10 ID:GaRrB9l2
作者がどうのってくだらんはなしばかりかよ
223 ：[名無し]さん(bin+cue).rar：03/12/20 15:14 ID:hOzsmjLM
>>216
たとえパクリだろーとネタだろーと、お前が怒る理由なんてどこにも見当たらないんだが。
たとえパクリだろーとネタだろーと、お前が怒る理由なんてどこにも見当たらないんだが。
224 ：[名無し]さん(bin+cue).rar：03/12/20 15:15 ID:kyrR0DAr
オープンソースになれば、そんなに作者にこだわらなくても・・・
225 ：RAID5マン（良いトリップ検索ちう）：03/12/20 15:21 ID:7LtWxVLF
■変形RAID5Ver2
前回私が提案した方式の変形RAID5についてさまざまな意見が寄せられた
のでもう一度問題点の洗い出しと実装について考え直しました。以下は激しく
独断と偏見に満ちたオデの脳ﾐｿ0721です。とりあえずライブラリを書いてる
最中です。たぶん5年後ぐらいには完成すると思う（ｫｨ
■nyやmxの問題点
①完全なファイルイメージそのものをやり取りするため、中継や暗号化でごまか
しても使用するユーザは自己から放出しているファイルを把握できうる。これが
原因で意図しない権利侵害に問われる可能性があり、実際にそうなった。
②捏造ファイルが多数出回り無駄なディスク領域を使用させられていた。
③ネットワーク全体の負荷になっていた。
他にもあるでしょうが主要なところでこんな感じだと理解しています。ただし
P2Pである以上は③の問題点については回避不能でしょうが負荷を低下させ
ることは方法によっては可能だと思います。以下の私の新提案については主
に①の問題を解決するための方法と付随的に②を解決する方法にについて考
えています。
前回私が提案した方式の変形RAID5についてさまざまな意見が寄せられた
のでもう一度問題点の洗い出しと実装について考え直しました。以下は激しく
独断と偏見に満ちたオデの脳ﾐｿ0721です。とりあえずライブラリを書いてる
最中です。たぶん5年後ぐらいには完成すると思う（ｫｨ
■nyやmxの問題点
①完全なファイルイメージそのものをやり取りするため、中継や暗号化でごまか
しても使用するユーザは自己から放出しているファイルを把握できうる。これが
原因で意図しない権利侵害に問われる可能性があり、実際にそうなった。
②捏造ファイルが多数出回り無駄なディスク領域を使用させられていた。
③ネットワーク全体の負荷になっていた。
他にもあるでしょうが主要なところでこんな感じだと理解しています。ただし
P2Pである以上は③の問題点については回避不能でしょうが負荷を低下させ
ることは方法によっては可能だと思います。以下の私の新提案については主
に①の問題を解決するための方法と付随的に②を解決する方法にについて考
えています。
226 ：RAID5マン（良いトリップ検索ちう）：03/12/20 15:22 ID:7LtWxVLF
■暗号化の有効な範囲をきちんと把握する
スレでも散々暗号化が話題にのぼっていますが、暗号化には２つのパターンがあり
それぞれの有効範囲をきちんと理解する必要があります。
一つ目は通信経路の暗号化でSSLに代表されるような通信暗号化、二つ目は固定
記録情報（ファイル）を暗号化する固定記録暗号化です。
このうち一つ目の暗号化通信についてはファイル共有を目的としたP2Pアプリケー
ションではまったく意味をなしません。これは第三者からの盗聴を防ぐのが目的で
あって、通信当事者同士ではコーデックを介してメモリ上に生データが生成される
ためです。このため①の問題を根本的に解決することは出来ないのです。
二つ目の暗号化固定記録はデータを安全に格納するために用いるものであり、
使い方を間違えなければ非常に有効ですが、過信するのはよくありません。暗号化
して複合できると言うことはファイル共有P2Pの場合は必ず何らかの形でキーを流す
はずで、単純に総当りで解読するよりも効率的に復号する方法は見つかるはずです。
技術的に優れた暗号であっても、それを解く方法論は技術とは関係のない部分から
崩壊することを理解しておく必要があります。
スレでも散々暗号化が話題にのぼっていますが、暗号化には２つのパターンがあり
それぞれの有効範囲をきちんと理解する必要があります。
一つ目は通信経路の暗号化でSSLに代表されるような通信暗号化、二つ目は固定
記録情報（ファイル）を暗号化する固定記録暗号化です。
このうち一つ目の暗号化通信についてはファイル共有を目的としたP2Pアプリケー
ションではまったく意味をなしません。これは第三者からの盗聴を防ぐのが目的で
あって、通信当事者同士ではコーデックを介してメモリ上に生データが生成される
ためです。このため①の問題を根本的に解決することは出来ないのです。
二つ目の暗号化固定記録はデータを安全に格納するために用いるものであり、
使い方を間違えなければ非常に有効ですが、過信するのはよくありません。暗号化
して複合できると言うことはファイル共有P2Pの場合は必ず何らかの形でキーを流す
はずで、単純に総当りで解読するよりも効率的に復号する方法は見つかるはずです。
技術的に優れた暗号であっても、それを解く方法論は技術とは関係のない部分から
崩壊することを理解しておく必要があります。
227 ：RAID5マン（良いトリップ検索ちう）：03/12/20 15:23 ID:7LtWxVLF
■安全なファイルの分散の準備（問題①の解決）
ここでは具体的な実装方法についての特にバイナリレベルでの処理を説明
しています。実際には自律機能のためにこのバイナリをオブジェクトラッッピ
ングしますので、自律機能の項目で別途説明します。
ネットワークの通信部の考え方は後述しますのでここでの考察はあくまで
バイナリレベルの秘匿性を評価するために見てください。
※小文字は値、大文字は実体ファイル関係で表記しています
①ファイル[F]のバイナリ列を元にハッシュ[h]を生成する
②[F]を鍵[k]を用いて暗号化し、暗号化ファイル[EF]を生成する
③[EF]のバイナリ列を元にハッシュ[eh]を生成する
④[EF]を偶数アドレスバイトブロックファイル[EBF]と奇数アドレスバイトブロックファイル
[OBF]に分割する
⑤[EBF]と[OBF]をxorしてパリティブロックファイル[PBF]を生成する
⑥[EBF][OBF][PBF]をそれぞれ1024KB細分化ブロック片[ebfp][obfp][pbfp]に分離する。
⑦⑥で求めたブロック片にハッシュ[h]をファイル名として識別子[ebfp,obfp,pbfp]と連番[n]
を拡張子としてファイル化する。
⑧鍵[k]を格納したファイル[KF]を生成するために、③で求めた[eh]をファイル名とし、ランダ
ム識別子[ebfp,obfp,pbfp]と[eh]の一桁目を用いた偽装番号で拡張子としたファイルを
作成する。これも1024KB固定化。
⑨ここまでで下準備が完了し、n個の分割ファイルと1個のキーファイルが作成された。
最後にこれらを既存の圧縮アルゴリズム（zip等）で圧縮する。この圧縮により無駄な領域
は低減される。
ここでは具体的な実装方法についての特にバイナリレベルでの処理を説明
しています。実際には自律機能のためにこのバイナリをオブジェクトラッッピ
ングしますので、自律機能の項目で別途説明します。
ネットワークの通信部の考え方は後述しますのでここでの考察はあくまで
バイナリレベルの秘匿性を評価するために見てください。
※小文字は値、大文字は実体ファイル関係で表記しています
①ファイル[F]のバイナリ列を元にハッシュ[h]を生成する
②[F]を鍵[k]を用いて暗号化し、暗号化ファイル[EF]を生成する
③[EF]のバイナリ列を元にハッシュ[eh]を生成する
④[EF]を偶数アドレスバイトブロックファイル[EBF]と奇数アドレスバイトブロックファイル
[OBF]に分割する
⑤[EBF]と[OBF]をxorしてパリティブロックファイル[PBF]を生成する
⑥[EBF][OBF][PBF]をそれぞれ1024KB細分化ブロック片[ebfp][obfp][pbfp]に分離する。
⑦⑥で求めたブロック片にハッシュ[h]をファイル名として識別子[ebfp,obfp,pbfp]と連番[n]
を拡張子としてファイル化する。
⑧鍵[k]を格納したファイル[KF]を生成するために、③で求めた[eh]をファイル名とし、ランダ
ム識別子[ebfp,obfp,pbfp]と[eh]の一桁目を用いた偽装番号で拡張子としたファイルを
作成する。これも1024KB固定化。
⑨ここまでで下準備が完了し、n個の分割ファイルと1個のキーファイルが作成された。
最後にこれらを既存の圧縮アルゴリズム（zip等）で圧縮する。この圧縮により無駄な領域
は低減される。
228 ：RAID5マン（良いトリップ検索ちう）：03/12/20 15:23 ID:7LtWxVLF
※②ここで用いる暗号化は、どちらかと言うと偽装化できればよいので強度より速度や
暗号化後の容量を優先してアルゴリズムを決定する
※③ハッシュ関数の場合はこの時点で[h]と[eh]はまったく無関係な値になっている
※たとえば「24C890E89749.ebfp.001」とか「24C890E89749.obfp.001」
※⑥1024KBに満たない場合でも固定長化する。転送量デメリットの回避は⑨
この方式のメリットはファイルを分割することで一人が全体をキャッシュする危険性を
回避することと、分割＆分散により同時並行ダウンロードが可能になるための効率アップです。
この準備のキモは最初に求めたハッシュhを暗号分割後のファイル名に用いることです。
複合化のためにはいったん暗号化・分割化されたものを集めてそれをもとに自己で
ハッシュehを算出することでキーファイルが判明する方式を取っています。このため、
部分キャッシュから意味のある情報を取得するコトはほぼ不可能です。
暗号化後の容量を優先してアルゴリズムを決定する
※③ハッシュ関数の場合はこの時点で[h]と[eh]はまったく無関係な値になっている
※たとえば「24C890E89749.ebfp.001」とか「24C890E89749.obfp.001」
※⑥1024KBに満たない場合でも固定長化する。転送量デメリットの回避は⑨
この方式のメリットはファイルを分割することで一人が全体をキャッシュする危険性を
回避することと、分割＆分散により同時並行ダウンロードが可能になるための効率アップです。
この準備のキモは最初に求めたハッシュhを暗号分割後のファイル名に用いることです。
複合化のためにはいったん暗号化・分割化されたものを集めてそれをもとに自己で
ハッシュehを算出することでキーファイルが判明する方式を取っています。このため、
部分キャッシュから意味のある情報を取得するコトはほぼ不可能です。
229 ：RAID5マン（良いトリップ検索ちう）：03/12/20 15:24 ID:7LtWxVLF
■パリティの計算方法とデータ量増加とその効果
ここまでのバイナリレベルの処理はRAID5の方法論をもとに考えました。
しかし問題点としてパリティが50%にも及ぶため初期放流者の負担が増え
てしまいます。後述しますが、この解決としては奇数、偶数、パリティのい
ずれかを欠落させることも視野に入れてもいいと思います。
しかしいまもうひとつのパリティ計算ライブラリを作成しているのですが、
1次元方向のパリティに加えて2次元方向にもクロスでパリティを持つことで、
より強固なパリティ効果と容量低減が出来そうです。
イメージ的には
ad|+0 |+1 |+2 |+3 |+4 |+5 |+6 |+7 |
-------------------------------------
00| P | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
10| 0 | P | 2 | 3 | 4 | 5 | 6 | 7 |
20| 0 | 1 | P | 3 | 4 | 5 | 6 | 7 |
30| 0 | 1 | 2 | P | 4 | 5 | 6 | 7 |
40| 0 | 1 | 2 | 3 | P | 5 | 6 | 7 |
50| 0 | 1 | 2 | 3 | 4 | P | 6 | 7 |
60| 0 | 1 | 2 | 3 | 4 | 5 | P | 7 |
70| 0 | 1 | 2 | 3 | 4 | 5 | 6 | P |
-------------------------------------
このような感じでブロック化を行い、addr00のパリティPは
01-07,10,20,30,40,50,60,70でxorパリティを取ります。つまり上の表で言えば
タテヨコ全部でパリティを取るってコトですね。
たとえばこのブロックのaddr10-17が欠落してしまっても縦方向でのパリティ
計算で復元できます。
このような構成をとった場合はパリティ容量に対してその効果が高くなるため
RAID5のかなり変形パリティとして有効に活用できそうですが、復号のアルゴリ
ズムが複雑になりそうです。最終的にはこちらで実装する予定です。
ここまでのバイナリレベルの処理はRAID5の方法論をもとに考えました。
しかし問題点としてパリティが50%にも及ぶため初期放流者の負担が増え
てしまいます。後述しますが、この解決としては奇数、偶数、パリティのい
ずれかを欠落させることも視野に入れてもいいと思います。
しかしいまもうひとつのパリティ計算ライブラリを作成しているのですが、
1次元方向のパリティに加えて2次元方向にもクロスでパリティを持つことで、
より強固なパリティ効果と容量低減が出来そうです。
イメージ的には
ad|+0 |+1 |+2 |+3 |+4 |+5 |+6 |+7 |
-------------------------------------
00| P | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
10| 0 | P | 2 | 3 | 4 | 5 | 6 | 7 |
20| 0 | 1 | P | 3 | 4 | 5 | 6 | 7 |
30| 0 | 1 | 2 | P | 4 | 5 | 6 | 7 |
40| 0 | 1 | 2 | 3 | P | 5 | 6 | 7 |
50| 0 | 1 | 2 | 3 | 4 | P | 6 | 7 |
60| 0 | 1 | 2 | 3 | 4 | 5 | P | 7 |
70| 0 | 1 | 2 | 3 | 4 | 5 | 6 | P |
-------------------------------------
このような感じでブロック化を行い、addr00のパリティPは
01-07,10,20,30,40,50,60,70でxorパリティを取ります。つまり上の表で言えば
タテヨコ全部でパリティを取るってコトですね。
たとえばこのブロックのaddr10-17が欠落してしまっても縦方向でのパリティ
計算で復元できます。
このような構成をとった場合はパリティ容量に対してその効果が高くなるため
RAID5のかなり変形パリティとして有効に活用できそうですが、復号のアルゴリ
ズムが複雑になりそうです。最終的にはこちらで実装する予定です。
230 ：[名無し]さん(bin+cue).rar：03/12/20 15:25 ID:KzxjJBdk
ｷﾀ━━━━wvﾍ√ﾚvwu/~ヽ(ﾟ∀ﾟ )ﾉwvﾍ√ﾚvwu/~━━━━ｯ!!!!
ほんと、久々の光臨ですね。
ほんと、久々の光臨ですね。
231 ：RAID5マン（良いトリップ検索ちう）：03/12/20 15:25 ID:7LtWxVLF
ネットワーク転送部はまた夜にでも書きます。
今仕事にきてるので、サボりながらしこしこコーディングしてまふ
今仕事にきてるので、サボりながらしこしこコーディングしてまふ
232 ：[名無し]さん(bin+cue).rar：03/12/20 15:26 ID:Xd0dI+e7
お、久々ですね。お疲れです。wikiの方にも掲載よろしくです。
233 ：[名無し]さん(bin+cue).rar：03/12/20 15:27 ID:iwJpBDtQ
RAID5マンさん もかえりー
234 ：RAID5マン（良いトリップ検索ちう）：03/12/20 15:29 ID:7LtWxVLF
wikiのほうはIP不安なので仕事帰りにマンガ喫茶からでも書いておくです。
ネットワーク転送部の説明もそれまでにまとめれれば。
ネットワーク転送部の説明もそれまでにまとめれれば。
235 ：[名無し]さん(bin+cue).rar：03/12/20 15:30 ID:TxxtTLVx
うぇーぶれっと方式みたい？なかんじですかね。
236 ：RAID5マン（良いトリップ検索ちう）：03/12/20 15:34 ID:7LtWxVLF
会社で残業代もらいながら次期P2P作成っていうｵﾅﾆｰするのはｲｲﾃﾞｽﾈ！
ばれたらｸﾋﾞになりそうだけど他の仕事と区別つかんだろうからまぁ大丈夫でしょうｗ
ばれたらｸﾋﾞになりそうだけど他の仕事と区別つかんだろうからまぁ大丈夫でしょうｗ
237 ：[名無し]さん(bin+cue).rar：03/12/20 15:41 ID:kyrR0DAr
RAID5マンお疲れ様です
⑦以降がちょっとわかりにくいような・・。
実際にネットワークに流れる断片の形は
⑥で細分化した[ebfp][obfp][pbfp]をひとつずつ流すってこと？
⑦以降がちょっとわかりにくいような・・。
実際にネットワークに流れる断片の形は
⑥で細分化した[ebfp][obfp][pbfp]をひとつずつ流すってこと？
238 ：[名無し]さん(bin+cue).rar：03/12/20 15:48 ID:3Qza8AuI
239 ：[名無し]さん(bin+cue).rar：03/12/20 15:52 ID:hOzsmjLM
将来、RAID5マンさんに上司が「この共有ソフトいいんだよー。」って進めてきたら面白いっすね。
240 ：[名無し]さん(bin+cue).rar：03/12/20 16:00 ID:TxxtTLVx
241 ：[名無し]さん(bin+cue).rar：03/12/20 16:23 ID:kyrR0DAr
厨な質問だが、⑧をもうちょっと説明してくれるとうれしい。
242 ：[名無し]さん(bin+cue).rar：03/12/20 16:28 ID:xj+WrkcI
厨な質問だが、Xマスまでに作ってくれるとうれしい。
243 ：[名無し]さん(bin+cue).rar：03/12/20 17:15 ID:RF/+uk9E
Most likely it was because of a privacy issue that emerged early in 1999.
MicrosoftR Office was using the GUID as a unique identifier in data files.
This had the unfortunate side effect of allowing a document to be linked back to
its creator via the NIC address used in the GUID. Putting GUIDs in data files,
it turned out, was bad for security: it broke anonymity.
msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dnnetsec/html/strongNames.asp
GUIDで大丈夫？
MicrosoftR Office was using the GUID as a unique identifier in data files.
This had the unfortunate side effect of allowing a document to be linked back to
its creator via the NIC address used in the GUID. Putting GUIDs in data files,
it turned out, was bad for security: it broke anonymity.
msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dnnetsec/html/strongNames.asp
GUIDで大丈夫？
244 ：[名無し]さん(bin+cue).rar：03/12/20 17:23 ID:rVr9L3AM
245 ：[名無し]さん(bin+cue).rar：03/12/20 17:57 ID:kyrR0DAr
>>229
そのパリティの方法はかなりいいかも
そのパリティの方法はかなりいいかも
246 ：[名無し]さん(bin+cue).rar：03/12/20 17:58 ID:kyrR0DAr
それにしても、何でこんなに盛り上がらないんだ？
247 ：softether-gateway.softether.net：03/12/20 18:03 ID:WmKl99V0
みんなついて来れなくなってるんだよ
(ノ_･､)ｸﾞｽﾝ
(ノ_･､)ｸﾞｽﾝ
248 ：[名無し]さん(bin+cue).rar：03/12/20 18:05 ID:LuhHAlvY
おつです。
>>227
具体的にお聞きしたいです。
「ファイルの暗号化を解くためのキー」と「そのキーを解くためのキー」を生成して流して、その二つがそろって初めてファイルが見れるということですね。
①ファイル→MD5で「ファイル自体をハッシュ名」
②ファイルをDESで暗号化し、「キー」と「暗号化ファイル」に分割
③「暗号化ファイル」→MD5で「暗号化ファイルをハッシュ名」
④「暗号化ファイルをハッシュ名」を偶数と奇数のアドレス空間に分割
⑤「偶数アドレス空間」と「奇数アドレス空間」の同じだったら0違ったら1にするルーチンにかけ「新たなファイル」を作成
⑥「偶数アドレス空間」、「奇数アドレス空間」、「新たなファイル」を1024KBに分割し「1024KBに分割されたそれぞれのファイル」を作成
⑦「1024KBに分割されたそれぞれのファイル」に「ファイル自体のハッシュ名」をつけて、番号を振る
⑧（ここの一桁目を用いた偽装番号がわからない）で1024KBで固定
⑨完成
質問なのですが、⑧のファイルから[eh]はどのようにして取り出すのでしょうか？
>>229
垂直パリティ・水平パリティを用いれば確かに１ビットの誤りを訂正できるようになりますね。
>>227
具体的にお聞きしたいです。
「ファイルの暗号化を解くためのキー」と「そのキーを解くためのキー」を生成して流して、その二つがそろって初めてファイルが見れるということですね。
①ファイル→MD5で「ファイル自体をハッシュ名」
②ファイルをDESで暗号化し、「キー」と「暗号化ファイル」に分割
③「暗号化ファイル」→MD5で「暗号化ファイルをハッシュ名」
④「暗号化ファイルをハッシュ名」を偶数と奇数のアドレス空間に分割
⑤「偶数アドレス空間」と「奇数アドレス空間」の同じだったら0違ったら1にするルーチンにかけ「新たなファイル」を作成
⑥「偶数アドレス空間」、「奇数アドレス空間」、「新たなファイル」を1024KBに分割し「1024KBに分割されたそれぞれのファイル」を作成
⑦「1024KBに分割されたそれぞれのファイル」に「ファイル自体のハッシュ名」をつけて、番号を振る
⑧（ここの一桁目を用いた偽装番号がわからない）で1024KBで固定
⑨完成
質問なのですが、⑧のファイルから[eh]はどのようにして取り出すのでしょうか？
>>229
垂直パリティ・水平パリティを用いれば確かに１ビットの誤りを訂正できるようになりますね。
249 ：[名無し]さん(bin+cue).rar：03/12/20 18:08 ID:xj+WrkcI
>>246
難しすぎてついていけない人が増えたのかも
難しすぎてついていけない人が増えたのかも
250 ：[名無し]さん(bin+cue).rar：03/12/20 18:09 ID:kyrR0DAr
251 ：[名無し]さん(bin+cue).rar：03/12/20 18:11 ID:kyrR0DAr
>>249
そういえば俺も時間がなくて読み落としが多いな
そういえば俺も時間がなくて読み落としが多いな
252 ：[名無し]さん(bin+cue).rar：03/12/20 18:37 ID:2PzZGQfl
暗号化されたら圧縮きかねーべ？
253 ：[名無し]さん(bin+cue).rar：03/12/20 18:41 ID:kyrR0DAr
そういやそうだな。
あとネットワークを流れるファイルはもともと圧縮されてるものがほとんどでは？
あとネットワークを流れるファイルはもともと圧縮されてるものがほとんどでは？
254 ：[名無し]さん(bin+cue).rar：03/12/20 18:48 ID:Q4j6iICA
255 ：[名無し]さん(bin+cue).rar：03/12/20 18:50 ID:j2JlFx6T
>>243
ダウンするときはダイレクトアクセスと書いてあるような・・・
ダウンするときはダイレクトアクセスと書いてあるような・・・
256 ：[名無し]さん(bin+cue).rar：03/12/20 19:35 ID:ciYvqGMv
257 ：[名無し]さん(bin+cue).rar：03/12/20 19:39 ID:wnjnHuZ4
>>214
> 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.
> http://mute-net.sourceforge.net/
これいいね。nyより匿名性を重視して、効率性を落としてるみたい。
でも速度がどれくらいでるかは、本格的に稼動してみないとわからないなあ。
> 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.
> http://mute-net.sourceforge.net/
これいいね。nyより匿名性を重視して、効率性を落としてるみたい。
でも速度がどれくらいでるかは、本格的に稼動してみないとわからないなあ。
258 ：[名無し]さん(bin+cue).rar：03/12/20 20:06 ID:dT1AA7Zf
>>257
すいませーん素人ですが、コレってスゴイのですか？
今読んだら、ＩＰがわかんなくなるようなＰ2Ｐだと思えたのですが、
これってパーソナルＦＷ使ってもわかんない？
取りあえずｎｙより匿名性が高くてfreenet より早いのなら、絶対に導入検討します。
教えて、よろ。
すいませーん素人ですが、コレってスゴイのですか？
今読んだら、ＩＰがわかんなくなるようなＰ2Ｐだと思えたのですが、
これってパーソナルＦＷ使ってもわかんない？
取りあえずｎｙより匿名性が高くてfreenet より早いのなら、絶対に導入検討します。
教えて、よろ。
freenet + frost
http://tmp2.2ch.net/test/read.cgi/download/1069942913/
こっちに詳しい説明有りました。
おおおおお。ちょっと入れてみよ。ほじゃ。
http://tmp2.2ch.net/test/read.cgi/download/1069942913/
こっちに詳しい説明有りました。
おおおおお。ちょっと入れてみよ。ほじゃ。
260 ：[名無し]さん(bin+cue).rar：03/12/20 21:11 ID:hC370f6o
ついにWinnyのソース公開！
http://pc.2ch.net/test/read.cgi/prog/1071794941/
6.6らしいです。どうやらスレの流れからマジらしい。エロイ方ガンガレ。
http://pc.2ch.net/test/read.cgi/prog/1071794941/
6.6らしいです。どうやらスレの流れからマジらしい。エロイ方ガンガレ。
261 ：[名無し]さん(bin+cue).rar：03/12/20 21:11 ID:otg89jIW
>>258
お前はもう発言するな
お前はもう発言するな
262 ：[名無し]さん(bin+cue).rar：03/12/20 21:13 ID:srhgE0Le
>>261
うっせー、ばか。
うっせー、ばか。
263 ：ひみつの文字列さん：2024/11/29(金) 04:18:12 ID:MarkedRes
日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。
264 ：[名無し]さん(bin+cue).rar：03/12/20 21:33 ID:O10RTiL0
ブラウザで落としたらサイズ0バイトだったからネタかと思ったけど
irvineで落とせたよ
irvineで落とせたよ
265 ：[名無し]さん(bin+cue).rar：03/12/20 21:35 ID:TxxtTLVx
ブラウザでも普通に落とせた
266 ：[名無し]さん(bin+cue).rar：03/12/20 22:28 ID:yRXY6j+I
結構ソース見やすいな。
asmからCにしたとは思えん。
asmからCにしたとは思えん。
267 ：[名無し]さん(bin+cue).rar：03/12/20 23:41 ID:Xd0dI+e7
ソース化スレがネタスレ化してるから、ここに貼っとけば誰かやってくれると
思っただけっぽいのだが。激しく迷惑な気がしないでもないでもない。
思っただけっぽいのだが。激しく迷惑な気がしないでもないでもない。
268 ：[名無し]さん(bin+cue).rar：03/12/20 23:55 ID:kyrR0DAr
RAID5マンは、またくるのだろうか？
269 ：[名無し]さん(bin+cue).rar：03/12/21 00:24 ID:3nv+a9dx
アセンブラからソース化した割りには随分なソースだ。
これ本当のソースなんじゃないか？あとソースがメチャ汚い。
やはりsrc2の方も必要な様だ。取り合えずコンパイルしてみたが、
エラーがでた。該当部分をコメント化してもやはり駄目。
誰かsrc2のパスワード教えてくれ。
これ本当のソースなんじゃないか？あとソースがメチャ汚い。
やはりsrc2の方も必要な様だ。取り合えずコンパイルしてみたが、
エラーがでた。該当部分をコメント化してもやはり駄目。
誰かsrc2のパスワード教えてくれ。
270 ：[名無し]さん(bin+cue).rar：03/12/21 02:07 ID:oLL1rbXb
パス解析か・・・
辞書使う？
辞書使う？
271 ：[名無し]さん(bin+cue).rar：03/12/21 02:18 ID:oLL1rbXb
272 ：[名無し]さん(bin+cue).rar：03/12/21 02:19 ID:cXEEAfmr
>>270
Winnyをソース化しよう
http://tmp2.2ch.net/test/read.cgi/download/1071258282/40
40 ：[名無し]さん(bin+cue).rar [] ：03/12/19 18:46 ID:b+bt1Gd4
src2.zipのパス、１０文字で総当りアタックしたけどダメだった、、、＿|￣|○
らしいですよ
Winnyをソース化しよう
http://tmp2.2ch.net/test/read.cgi/download/1071258282/40
40 ：[名無し]さん(bin+cue).rar [] ：03/12/19 18:46 ID:b+bt1Gd4
src2.zipのパス、１０文字で総当りアタックしたけどダメだった、、、＿|￣|○
らしいですよ
273 ：[名無し]さん(bin+cue).rar：03/12/21 02:26 ID:2G7xLsFr
このスレの住人は真面目だなぁ。
解析・開発に飢えてるというかなんていうか。
他のスレとは大違いだｗ
解析・開発に飢えてるというかなんていうか。
他のスレとは大違いだｗ
274 ：[名無し]さん(bin+cue).rar：03/12/21 02:35 ID:oLL1rbXb
ソース見たけど、キレイ。
このlarkって人は全部ソース持ってるわけでしょ？
結局主導権は向こうか。
こっちで今から開発するのとどっちが早いか。
暗号化は思ったよりも標準的なRSA。ハッシュは思った通り単純MD5。
あとは、loop.cppとhost.cppが解析不能。dmmyの部分とsubloopを独自で実装できればよいかもしれないが。
dmmy000.cpp
dmmy2000.cpp
subloop000.cpp
subloop1000.cpp
とりあえずloopはノードを探す部分でdmmyはよくわからん。
RSAをAESに変更してはいかがでしょうか？
このlarkって人は全部ソース持ってるわけでしょ？
結局主導権は向こうか。
こっちで今から開発するのとどっちが早いか。
暗号化は思ったよりも標準的なRSA。ハッシュは思った通り単純MD5。
あとは、loop.cppとhost.cppが解析不能。dmmyの部分とsubloopを独自で実装できればよいかもしれないが。
dmmy000.cpp
dmmy2000.cpp
subloop000.cpp
subloop1000.cpp
とりあえずloopはノードを探す部分でdmmyはよくわからん。
RSAをAESに変更してはいかがでしょうか？
275 ：[名無し]さん(bin+cue).rar：03/12/21 02:41 ID:oLL1rbXb
ホストの暗号化を別に実装する方法が必要だな～。
RAID5マンのネットワーク部分がノード探索に使えれば。
ワクワクしてきたぞ。(w
RAID5マンのネットワーク部分がノード探索に使えれば。
ワクワクしてきたぞ。(w
276 ：[名無し]さん(bin+cue).rar：03/12/21 02:45 ID:2G7xLsFr
今頃気づいたけどスレ乱立してるね。
意味わからず騒いでるスレばっかりで、どっこも分析してないのが笑えるけど。
このスレだけマターリ分析ってスタンスがよさげ。
larkって人は逆アセンブルしてるだけだからどうなるかわからないけど、
小出しにしてるとこを見ると何か考えがあるのだろうか？
意味わからず騒いでるスレばっかりで、どっこも分析してないのが笑えるけど。
このスレだけマターリ分析ってスタンスがよさげ。
larkって人は逆アセンブルしてるだけだからどうなるかわからないけど、
小出しにしてるとこを見ると何か考えがあるのだろうか？
277 ：[名無し]さん(bin+cue).rar：03/12/21 02:46 ID:ekm0o80U
278 ：[名無し]さん(bin+cue).rar：03/12/21 02:54 ID:XBv0oi86
>>248
> 質問なのですが、⑧のファイルから[eh]はどのようにして取り出すのでしょうか？
放流主には[eh]はわかる。
ＤＬ側は、断片を集めて、全部揃った時点で自分で全体のハッシュを計算する
ことで[eh]がわかる。全部揃わないと[eh]がわからない。
こうすると、キャッシュ全体と暗号キーのすべてが揃わないと部分的にも復号
できなくなる、というのを狙っているらしい。
しかし、ネット上を「ファイル名」と「ハッシュ情報[h]」を含んだキー情報が
流通するはずで（これがないと断片を集められない）、キー情報があれば結局
手元のファイルが何のファイルの断片なのかはわかってしまう。
盛れ的には、データ断片とファイル名などの情報を別管理するだけで充分な
気がする。部分復号を防ぐためだけにここまでオーバーヘッドを増やす意味が
よくわからない。
今回のは単にバイナリレベルの秘匿性だけの話とのことなので、通信部の話が
出ればこの辺の疑問も解消するのかな？
もう１つわからないのは、なぜ追加パリティで容量低減ができるのか。
oex 方式の特徴は、３つのうち２つがあればオリジナルを復元できること。
つまりオリジナルと同じデータ量だけダウン／キャッシュすればよかった。
しかし追加パリティを加えると、データ訂正ができるのでエラーがあったときの
再ダウンは低減されるが、転送容量、ストレージ容量は逆に増加するはず。
誰かわかる香具師、解説きぼん
> 質問なのですが、⑧のファイルから[eh]はどのようにして取り出すのでしょうか？
放流主には[eh]はわかる。
ＤＬ側は、断片を集めて、全部揃った時点で自分で全体のハッシュを計算する
ことで[eh]がわかる。全部揃わないと[eh]がわからない。
こうすると、キャッシュ全体と暗号キーのすべてが揃わないと部分的にも復号
できなくなる、というのを狙っているらしい。
しかし、ネット上を「ファイル名」と「ハッシュ情報[h]」を含んだキー情報が
流通するはずで（これがないと断片を集められない）、キー情報があれば結局
手元のファイルが何のファイルの断片なのかはわかってしまう。
盛れ的には、データ断片とファイル名などの情報を別管理するだけで充分な
気がする。部分復号を防ぐためだけにここまでオーバーヘッドを増やす意味が
よくわからない。
今回のは単にバイナリレベルの秘匿性だけの話とのことなので、通信部の話が
出ればこの辺の疑問も解消するのかな？
もう１つわからないのは、なぜ追加パリティで容量低減ができるのか。
oex 方式の特徴は、３つのうち２つがあればオリジナルを復元できること。
つまりオリジナルと同じデータ量だけダウン／キャッシュすればよかった。
しかし追加パリティを加えると、データ訂正ができるのでエラーがあったときの
再ダウンは低減されるが、転送容量、ストレージ容量は逆に増加するはず。
誰かわかる香具師、解説きぼん
279 ：[名無し]さん(bin+cue).rar：03/12/21 02:56 ID:gV+mQu/i
>>276
larkは基本的に愉快犯だから
larkは基本的に愉快犯だから
280 ：[名無し]さん(bin+cue).rar：03/12/21 03:27 ID:oLL1rbXb
larkってあのlark？
lark氏・・・
元HNはtaku。漏れが知る限りは管理しない尻有倶楽部というサイトがあった頃からカリスマ的なシェアウェアクラッカーとして活躍していた。
今でも某尻有掲示板に出没。ただし最近は某MPEGエンコソフトにしか興味がないご様子。
シリアル集をtakuやlarkで検索すると名前が大量にヒットする。
アセンブル言語はもちろん、ほぼ全てのプログラミング言語を読んだり書いたりできる。RSA暗号などの暗号理論にも精通。
愛用ツールはw32dasmとExSTANDらしい。逆アセンブルした結果からソースに戻すのは朝飯前。
自サイトで高速にアーカイブのパスを解析するツールなどを開発して置いていたような気がする。
lark氏・・・
元HNはtaku。漏れが知る限りは管理しない尻有倶楽部というサイトがあった頃からカリスマ的なシェアウェアクラッカーとして活躍していた。
今でも某尻有掲示板に出没。ただし最近は某MPEGエンコソフトにしか興味がないご様子。
シリアル集をtakuやlarkで検索すると名前が大量にヒットする。
アセンブル言語はもちろん、ほぼ全てのプログラミング言語を読んだり書いたりできる。RSA暗号などの暗号理論にも精通。
愛用ツールはw32dasmとExSTANDらしい。逆アセンブルした結果からソースに戻すのは朝飯前。
自サイトで高速にアーカイブのパスを解析するツールなどを開発して置いていたような気がする。
281 ：[名無し]さん(bin+cue).rar：03/12/21 03:28 ID:S9MsOF7C
282 ：[名無し]さん(bin+cue).rar：03/12/21 08:07 ID:3nv+a9dx
本物のソースかと思ったが、今見てみると、かなりリバースエンジニアした感じだっ。
特に構造体の部分がかなり機械的だ。（簡単なサイズ合わせだけしてる的）
半端ではあれ、かなり変更しているようで関数の機能等デバッグして少しずつ確かめた形跡がある。
手間は一から作るより掛かってるんじゃないか？
特に構造体の部分がかなり機械的だ。（簡単なサイズ合わせだけしてる的）
半端ではあれ、かなり変更しているようで関数の機能等デバッグして少しずつ確かめた形跡がある。
手間は一から作るより掛かってるんじゃないか？
283 ：[名無し]さん(bin+cue).rar：03/12/21 08:27 ID:bRBNgb/+
それだけの技術があるならP2Pソフト作れよとおもた。
284 ：[名無し]さん(bin+cue).rar：03/12/21 09:07 ID:dvjf4TSk
おまえら「クラッカー・プログラム大全」の読み過ぎ
285 ：[名無し]さん(bin+cue).rar：03/12/21 09:25 ID:Yq70CDiR
>>278
全部ダウンしないと、何のファイルかわからないようになってるってこと？
それだとなにか捏造対策が必要になってくるような。
oexだと例えばそれぞれ最後の１ブロックずつがダウンできなかった場合
必要な部分が全部集まらないことになるけど、
このパリティ方式の場合、２次元的にパリティをすることによって
最後の１ブロックも復元できるのでは？
（説明わかりにくくてスマソ）
oexもパリティも、最低限ダウンする必要のある容量は同じだと思う。
だけど、このパリティ方式の場合、そのときの組み合わせ方が多いのでは。
俺が思うに、このパリティ方式の要は"２次元"にあると思う。
oexもパリティといえばパリティじゃん。
全部ダウンしないと、何のファイルかわからないようになってるってこと？
それだとなにか捏造対策が必要になってくるような。
oexだと例えばそれぞれ最後の１ブロックずつがダウンできなかった場合
必要な部分が全部集まらないことになるけど、
このパリティ方式の場合、２次元的にパリティをすることによって
最後の１ブロックも復元できるのでは？
（説明わかりにくくてスマソ）
oexもパリティも、最低限ダウンする必要のある容量は同じだと思う。
だけど、このパリティ方式の場合、そのときの組み合わせ方が多いのでは。
俺が思うに、このパリティ方式の要は"２次元"にあると思う。
oexもパリティといえばパリティじゃん。
>>285
> 全部ダウンしないと、何のファイルかわからないようになってるってこと？
> それだとなにか捏造対策が必要になってくるような。
確かに。ny で言うところの先頭ブロック表示や部分キャッシュの強制変換が
できなくなるので、捏造が流通した場合のダメージは ny より大きいかも。
> このパリティ方式の場合、２次元的にパリティをすることによって
> 最後の１ブロックも復元できるのでは？
なるほど、ブロックをまたいでパリティを取るってことね。ブロック内で
パリティを取る方法しか思いつかなかった。それなら確かに、欠落ブロックを
復元できるケースも出てくるかも。
しかしRAID5マン氏のカキコからその辺はよく読み取れないし、はっきりと
「容量低減」と書かれているのが気になる。いずれにせよ、容量は増える
ことはあっても減りはしないはず。
> 全部ダウンしないと、何のファイルかわからないようになってるってこと？
> それだとなにか捏造対策が必要になってくるような。
確かに。ny で言うところの先頭ブロック表示や部分キャッシュの強制変換が
できなくなるので、捏造が流通した場合のダメージは ny より大きいかも。
> このパリティ方式の場合、２次元的にパリティをすることによって
> 最後の１ブロックも復元できるのでは？
なるほど、ブロックをまたいでパリティを取るってことね。ブロック内で
パリティを取る方法しか思いつかなかった。それなら確かに、欠落ブロックを
復元できるケースも出てくるかも。
しかしRAID5マン氏のカキコからその辺はよく読み取れないし、はっきりと
「容量低減」と書かれているのが気になる。いずれにせよ、容量は増える
ことはあっても減りはしないはず。
287 ：[名無し]さん(bin+cue).rar：03/12/21 13:14 ID:ekm0o80U
やっとPikaZipの使い方が分かった。
PC3台繋いで検索中。
PC3台繋いで検索中。
288 ：[名無し]さん(bin+cue).rar：03/12/21 15:01 ID:ekm0o80U
1回に検索するパスワードを21億にしたら物凄く速くなった。
22億だとPNCがフリーズしてしまうが。
現在8桁。
22億だとPNCがフリーズしてしまうが。
現在8桁。
289 ：[名無し]さん(bin+cue).rar：03/12/21 15:06 ID:wMQ13A5q
>>280
つまりハッカーなのか？
つまりハッカーなのか？
290 ：[名無し]さん(bin+cue).rar：03/12/21 15:20 ID:ETS9ts4r
[h]と[k]を混同するな。
291 ：[名無し]さん(bin+cue).rar：03/12/21 16:33 ID:yc29LJfM
世の中にはすごい人がいるもんだね…ﾊﾊﾊ
292 ：[名無し]さん(bin+cue).rar：03/12/21 16:52 ID:oLL1rbXb
>>289
crakerと俺は認識してる。hackerではないんじゃない？
すごいことはすごいかも。
最近は出てこないけど、もっとすごい人はいたりもした。
いわゆるUGの人達ね。
まあ、板違いなので。セキュリティ板かな。
crakerと俺は認識してる。hackerではないんじゃない？
すごいことはすごいかも。
最近は出てこないけど、もっとすごい人はいたりもした。
いわゆるUGの人達ね。
まあ、板違いなので。セキュリティ板かな。
293 ：[名無し]さん(bin+cue).rar：03/12/21 18:19 ID:DKNuxm5Y
vladﾀﾝとか
>>286
自分もわからない部分が歩けど、
「容量低減」はoexにくらべると少なくなるということでは？
最低限必要な量はどっとも同じだけど、
２次元のほうが無駄になる部分が少ないから、
最終的に「容量低減」になるのでは？
ところでここはいつから「パスワード解読スレ」になった？
他がネタスレ化してるからか？
自分もわからない部分が歩けど、
「容量低減」はoexにくらべると少なくなるということでは？
最低限必要な量はどっとも同じだけど、
２次元のほうが無駄になる部分が少ないから、
最終的に「容量低減」になるのでは？
ところでここはいつから「パスワード解読スレ」になった？
他がネタスレ化してるからか？
＞最低限必要な量はどっとも同じだけど
どっちも
どっちも
296 ：[名無し]さん(bin+cue).rar：03/12/21 18:23 ID:a7mzQJm+
「歩けど」はいいのか
まだ誤字があったか・・・
急いで書くとろくな事ないな。
指摘ありがと
急いで書くとろくな事ないな。
指摘ありがと
298 ：[名無し]さん(bin+cue).rar：03/12/21 18:58 ID:0aQMSlMr
>>294
> 「容量低減」はoexにくらべると少なくなるということでは？
いや、oex 方式より容量を少なくすることはできないはず。
もし x ブロックのサイズを小さくできるとしたら、
oex 方式の「３つのうち任意の２つがあれば復元できる」というメリットを
捨てるか、「どんなデータでも小さくできる万能の圧縮技術」を開発するか
２つに１つ。
> 「容量低減」はoexにくらべると少なくなるということでは？
いや、oex 方式より容量を少なくすることはできないはず。
もし x ブロックのサイズを小さくできるとしたら、
oex 方式の「３つのうち任意の２つがあれば復元できる」というメリットを
捨てるか、「どんなデータでも小さくできる万能の圧縮技術」を開発するか
２つに１つ。
まず気になるのが説明では8x8の正方形で説明してるけど、
実際のファイルでは固定長の正方形に分割するんだろうか？
実際のファイルでは固定長の正方形に分割するんだろうか？
300 ：[名無し]さん(bin+cue).rar：03/12/21 19:48 ID:/AyoqzKC
今だ！300げっとぉぉぉーー！！
＼＿＿＿＿ ＿＿＿＿＿＿＿＿＿／
|/
∧＿∧ ド
（ ´Д｀ )っ ド
( つ / ォ
（ | （⌒）｀） ォ
（´ ´し'⌒＾ミ ｀）｀）ォ
＼＿＿＿＿ ＿＿＿＿＿＿＿＿＿／
|/
∧＿∧ ド
（ ´Д｀ )っ ド
( つ / ォ
（ | （⌒）｀） ォ
（´ ´し'⌒＾ミ ｀）｀）ォ
301 ：[名無し]さん(bin+cue).rar：03/12/21 21:08 ID:0aQMSlMr
>>299
ブロックサイズを 1024kB 固定にするのは、おそらくパリティ処理のためと
想像してみる。
たぶん固定長の正方形だと思う。ブロックをまたいでパリティ生成するのなら、
可変長かも知れない。
想像だけであまり細かいところまで議論するのもツライので、そろそろ
RAID5マン氏に降臨して欲しいところだなあ。
ブロックサイズを 1024kB 固定にするのは、おそらくパリティ処理のためと
想像してみる。
たぶん固定長の正方形だと思う。ブロックをまたいでパリティ生成するのなら、
可変長かも知れない。
想像だけであまり細かいところまで議論するのもツライので、そろそろ
RAID5マン氏に降臨して欲しいところだなあ。
302 ：[名無し]さん(bin+cue).rar：03/12/21 21:17 ID:3nv+a9dx
>>RAID5マン
無駄が多すぎる。意味が無い。お前はマゾか。勉強しなおせ。
無意識に全てダウンロードした事を前提に話しているよな。
つまり正常なファイルであっても転送量は増加する。
欠落しても良いのであればパリティを欠落させとけ。
破損を出来る限り少なくしたいのであれば例えば何等分かにファイルを別け、
それぞれにCRCを入れておくだけで事は足りる。
破損時は破損部分だけをダウンロードしなおせば良い。
破損時のみの少ない転送量増加のみの上に単純でバグも比較すると減るだろう。
プロバイダにも多少優しくなる筈だろ？
無駄が多すぎる。意味が無い。お前はマゾか。勉強しなおせ。
無意識に全てダウンロードした事を前提に話しているよな。
つまり正常なファイルであっても転送量は増加する。
欠落しても良いのであればパリティを欠落させとけ。
破損を出来る限り少なくしたいのであれば例えば何等分かにファイルを別け、
それぞれにCRCを入れておくだけで事は足りる。
破損時は破損部分だけをダウンロードしなおせば良い。
破損時のみの少ない転送量増加のみの上に単純でバグも比較すると減るだろう。
プロバイダにも多少優しくなる筈だろ？
303 ：[名無し]さん(bin+cue).rar：03/12/21 21:45 ID:wMQ13A5q
freenetなんかだとFECエンコードとかいう処理で冗長性持たせることで、
うpするファイルの容量は増加するんだけど落とす時は全て落とす必要がない。
ある程度のブロックが揃うと足りないブロックはFECデコードで補完される。
デコード完了するとヒールブロックを周りのノードに少しバラ撒く。
うpするファイルの容量は増加するんだけど落とす時は全て落とす必要がない。
ある程度のブロックが揃うと足りないブロックはFECデコードで補完される。
デコード完了するとヒールブロックを周りのノードに少しバラ撒く。
そういえばFECって動画の配信のときに聞いたような・・・
ちょっと勉強します
ちょっと勉強します
305 ：[名無し]さん(bin+cue).rar：03/12/21 22:29 ID:iCyD2/h8
ネットワーク経由で解くバージョンがあんじゃん
みんなでやろうよ。
みんなでやろうよ。
306 ：[名無し]さん(bin+cue).rar：03/12/21 22:31 ID:3nv+a9dx
>>303
フム、Freenetは推測する所
ファイルは完全ファイルで中身にパリティが入っている奴だな。
（RAID5の言うパリティとは違ってCRCの役割に近い物）
んで破損があったらターゲットのヒールブロックをDLすると言う感じだろう。
RAID5のはパリティと言う名の巨大ヒールブロック(容量の50%にも及ぶ)を
流すので結局前半後半だけ流すのと替わらん訳だ。Freenetのは
こなれていると思うので、採用しても問題ないぞ。
フム、Freenetは推測する所
ファイルは完全ファイルで中身にパリティが入っている奴だな。
（RAID5の言うパリティとは違ってCRCの役割に近い物）
んで破損があったらターゲットのヒールブロックをDLすると言う感じだろう。
RAID5のはパリティと言う名の巨大ヒールブロック(容量の50%にも及ぶ)を
流すので結局前半後半だけ流すのと替わらん訳だ。Freenetのは
こなれていると思うので、採用しても問題ないぞ。
だれかFECおしえてくれ
もしくは、リンクきぼん
もしくは、リンクきぼん
308 ：[名無し]さん(bin+cue).rar：03/12/21 22:46 ID:wMQ13A5q
freenetプロジェクトのFECについて書いてるページかな？
http://freenet.sourceforge.net/index.php?page=fec
漏れは技術的な事はほとんど分からんけど。
http://freenet.sourceforge.net/index.php?page=fec
漏れは技術的な事はほとんど分からんけど。
310 ：[名無し]さん(bin+cue).rar：03/12/21 22:50 ID:wMQ13A5q
PDFだけど
http://www.sanda.gr.jp/PRUG-kyoto99/docs/NNemoto99a.pdf
↑のHTML版Googleキャッシュ
http://216.239.57.104/search?q=cache:KBCElXVDPU0J:www.sanda.gr.jp/PRUG-kyoto99/docs/NNemoto99a.pdf+FEC+code&hl=ja&lr=lang_ja&ie=UTF-8
http://www.sanda.gr.jp/PRUG-kyoto99/docs/NNemoto99a.pdf
↑のHTML版Googleキャッシュ
http://216.239.57.104/search?q=cache:KBCElXVDPU0J:www.sanda.gr.jp/PRUG-kyoto99/docs/NNemoto99a.pdf+FEC+code&hl=ja&lr=lang_ja&ie=UTF-8
311 ：[名無し]さん(bin+cue).rar：03/12/21 22:57 ID:wMQ13A5q
http://mi.cs.titech.ac.jp/funada/kyoto/tech.html
＞EC(Forward Error Collection)とは、通信路にはエラーがつきものです。
＞通信路において発生したエラーを検出し、そのエラーを回復する必要が
＞あります。エラーを回復するためには、エラーしたものをもう一度送り直
＞してもらう方法(ARQ方式)と冗長な情報を送っておいて受信した側で
＞エラーを訂正する方法(FEC方式)があります。 ARQ方式では、もう一度
＞送り返してもらう要求パケットを送らなくてはなりませんので、スループット
＞が悪くなります。FEC方式ではエラーを訂正するために計算が必要で、
＞CPUパワーが必要になります。また、誤り訂正に組み合わせてインター
＞リーブを用いることで、連続したビットの誤り (バースト誤り)にもある程度
＞対処することができます。
FECってのは特定のアルゴリズムを指している分けじゃなくて、冗長性の
あるデータを送って受信側でエラー訂正する方式の総称だったのか。
＞EC(Forward Error Collection)とは、通信路にはエラーがつきものです。
＞通信路において発生したエラーを検出し、そのエラーを回復する必要が
＞あります。エラーを回復するためには、エラーしたものをもう一度送り直
＞してもらう方法(ARQ方式)と冗長な情報を送っておいて受信した側で
＞エラーを訂正する方法(FEC方式)があります。 ARQ方式では、もう一度
＞送り返してもらう要求パケットを送らなくてはなりませんので、スループット
＞が悪くなります。FEC方式ではエラーを訂正するために計算が必要で、
＞CPUパワーが必要になります。また、誤り訂正に組み合わせてインター
＞リーブを用いることで、連続したビットの誤り (バースト誤り)にもある程度
＞対処することができます。
FECってのは特定のアルゴリズムを指している分けじゃなくて、冗長性の
あるデータを送って受信側でエラー訂正する方式の総称だったのか。
312 ：RAID5マン ◆H2RAID5./g ：03/12/21 23:45 ID:2G0CQUR6
徹夜明けで帰ってきました。すんません放置して。
捏造ファイルの問題ですが、これはバイナリ処理や通信理論で解決できるもんじゃないと
思うので、事後対応式の通報システムでかんがえてます。
通信部のほうで説明するといっておきながらまだ説明まとめきれてないデス・・・
圧縮は暗号化済みファイルに対してはかからねーだろﾊﾞｶﾔﾛｳのご指摘はごもっともです。
確かに暗号化してあったら圧縮利きませんよね。
圧縮持ち出したのはブロックサイズ以下のファイルの処理を考えた結果なので、ブロック化
したときに生じる無駄な領域をつめる効果しかありませんし、全部圧縮するとなればオーバー
ヘッド高すぎますね。
この部分は意味がなさそうなのでいったん実装からはずします。
ちょっと風呂はいったらまた通信部まとめます。
脳みそｵﾅﾆｰなんで突っ込まれると気持ちｲｲので突っ込んでください。
捏造ファイルの問題ですが、これはバイナリ処理や通信理論で解決できるもんじゃないと
思うので、事後対応式の通報システムでかんがえてます。
通信部のほうで説明するといっておきながらまだ説明まとめきれてないデス・・・
圧縮は暗号化済みファイルに対してはかからねーだろﾊﾞｶﾔﾛｳのご指摘はごもっともです。
確かに暗号化してあったら圧縮利きませんよね。
圧縮持ち出したのはブロックサイズ以下のファイルの処理を考えた結果なので、ブロック化
したときに生じる無駄な領域をつめる効果しかありませんし、全部圧縮するとなればオーバー
ヘッド高すぎますね。
この部分は意味がなさそうなのでいったん実装からはずします。
ちょっと風呂はいったらまた通信部まとめます。
脳みそｵﾅﾆｰなんで突っ込まれると気持ちｲｲので突っ込んでください。
313 ：[名無し]さん(bin+cue).rar：03/12/21 23:54 ID:zpMuroD5
314 ：[名無し]さん(bin+cue).rar：03/12/22 00:17 ID:J4HJPYX3
>RAID5マン さん
新仕様のパリティは目的は何？
もともとの仕様だと、EとOとパリティのどれか２つで復号できるってのがあったと思うけど
新仕様は、EとOは必須でパリティが、単純にチェックするためだけのように見える。
新仕様のパリティは目的は何？
もともとの仕様だと、EとOとパリティのどれか２つで復号できるってのがあったと思うけど
新仕様は、EとOは必須でパリティが、単純にチェックするためだけのように見える。
315 ：[名無し]さん(bin+cue).rar：03/12/22 00:25 ID:a9C460Sh
なにはともあれlarkさんお疲れ様です。
一部とはいえWinnyのソースによって、このスレ・MUTEが
どうなっていくのか楽しみです！
一部とはいえWinnyのソースによって、このスレ・MUTEが
どうなっていくのか楽しみです！
316 ：[名無し]さん(bin+cue).rar：03/12/22 00:47 ID:qfp2TwuH
freenetの欠点は
勝手にキャッシュが消えてしまう点だな
ファイルアーカイブとしては使えない
セキュアなwebページとして使うくらいしかないなぁ
勝手にキャッシュが消えてしまう点だな
ファイルアーカイブとしては使えない
セキュアなwebページとして使うくらいしかないなぁ
317 ：RAID5マン ◆H2RAID5./g ：03/12/22 01:16 ID:B3KqleNm
>314
えっとですね、oexの方式の場合は3つで1セットになり、2つ集めれば
復号できますよね。てことは1セット中で1つは欠落可能てことになる
んですが、この「セット」を超えて欠落できないのが欠点なんです。
つまり3セットあったらデータは9個で3つ欠落させられますが、その3つが
同じセット内で欠落しちゃうと復号できないんですね。
新方式でRAID5と同じ冗長率50%だとブロック化は3ｘ3になるんですが
こちらの場合は9個のうちどれでも3つ欠落させられる利点があります。
4x4だと冗長率33%になるため復号可能性は多少犠牲になりますが
16個中どこでも4つ欠落しても復号できます。
つまり新方式は辺長n二乗のデータブロック数に対してn個のパリティを
含むため、n個の欠落を許容できるてことになります。
旧方式は2+1で固定されるため、復号可能性の表面値が同一であっても
強度は低くなるということです。
こんな説明ですがわかりますかね？
えっとですね、oexの方式の場合は3つで1セットになり、2つ集めれば
復号できますよね。てことは1セット中で1つは欠落可能てことになる
んですが、この「セット」を超えて欠落できないのが欠点なんです。
つまり3セットあったらデータは9個で3つ欠落させられますが、その3つが
同じセット内で欠落しちゃうと復号できないんですね。
新方式でRAID5と同じ冗長率50%だとブロック化は3ｘ3になるんですが
こちらの場合は9個のうちどれでも3つ欠落させられる利点があります。
4x4だと冗長率33%になるため復号可能性は多少犠牲になりますが
16個中どこでも4つ欠落しても復号できます。
つまり新方式は辺長n二乗のデータブロック数に対してn個のパリティを
含むため、n個の欠落を許容できるてことになります。
旧方式は2+1で固定されるため、復号可能性の表面値が同一であっても
強度は低くなるということです。
こんな説明ですがわかりますかね？
318 ：[名無し]さん(bin+cue).rar：03/12/22 01:35 ID:J4HJPYX3
>317
なるほど、分かりました。
パリティの計算にパワーが必要になりますが、同じ冗長率なら明らかに優れていますね。
なるほど、分かりました。
パリティの計算にパワーが必要になりますが、同じ冗長率なら明らかに優れていますね。
>>317
仕組みについては大体理解してたけど、
説明方法の勉強になりました。
それ以前にトリップがすごいかも。
捏造対策について思いついたことがあるから、
明日あたりまとめて書くわ。
といっても、このスレになるちょっと前から、
１つもあたりがない・・・。
仕組みについては大体理解してたけど、
説明方法の勉強になりました。
それ以前にトリップがすごいかも。
捏造対策について思いついたことがあるから、
明日あたりまとめて書くわ。
といっても、このスレになるちょっと前から、
１つもあたりがない・・・。
>>317
＞16個中どこでも4つ欠落しても復号できます。
ここがどうもわからないんだが、
P 1 2 3
0 P 2 3
0 1 P 3
0 1 2 P
のとき、
P 1 2 3
0 x x 3
0 x x 3
0 1 2 P
（xが欠落部分）
見たいな欠落が発生したとき、どう復号するんだ？
＞16個中どこでも4つ欠落しても復号できます。
ここがどうもわからないんだが、
P 1 2 3
0 P 2 3
0 1 P 3
0 1 2 P
のとき、
P 1 2 3
0 x x 3
0 x x 3
0 1 2 P
（xが欠落部分）
見たいな欠落が発生したとき、どう復号するんだ？
322 ：[名無し]さん(bin+cue).rar：03/12/22 04:59 ID:X6CXrgIT
ハラタツぞおまえら。何で批判の場合は真面目に見ないんだ？
どうして全部DLしたのを前提にして考えるの？意味ねえぞ。
多少替わった様だから容量は150%になったりは無い様だが、意味は無い。
まぁお前らの為にちゃんと説明してやろう。
よ～～～く考えてみろ。Pって何だ？お前ら本質を理解できませんか？
Pはいったい何処に対応したPなんだ？おかしいな、4つ無い分データが圧縮されたぞ？
100分の1に圧縮するアルリズムでも開発したのか？
例えば>>321の例で(x0,y1)が破損している為に復元したい時、どのような手順で
復元を行うのかを曖昧な表現ではなく細かく記述をしてみよ。誰でもいいから。
まぁお前らの事だ、何処からか湧いてきた(0,1)に対応するPが出現して
縦と横へXORを行うとでも言うんだろ。
それとも(0,0)に対応したPを代用するのか？おお、たまたま一致したバイナリだったら成功するな。
こりゃまいったな、RAID5素人アルゴリズムの大勝利だ。
どうして全部DLしたのを前提にして考えるの？意味ねえぞ。
多少替わった様だから容量は150%になったりは無い様だが、意味は無い。
まぁお前らの為にちゃんと説明してやろう。
よ～～～く考えてみろ。Pって何だ？お前ら本質を理解できませんか？
Pはいったい何処に対応したPなんだ？おかしいな、4つ無い分データが圧縮されたぞ？
100分の1に圧縮するアルリズムでも開発したのか？
例えば>>321の例で(x0,y1)が破損している為に復元したい時、どのような手順で
復元を行うのかを曖昧な表現ではなく細かく記述をしてみよ。誰でもいいから。
まぁお前らの事だ、何処からか湧いてきた(0,1)に対応するPが出現して
縦と横へXORを行うとでも言うんだろ。
それとも(0,0)に対応したPを代用するのか？おお、たまたま一致したバイナリだったら成功するな。
こりゃまいったな、RAID5素人アルゴリズムの大勝利だ。
323 ：[名無し]さん(bin+cue).rar：03/12/22 05:09 ID:X6CXrgIT
補足しとこう。Pが縦横全てに対応したものと言う意味だとしたら、
転送量はどれだけ大きくなるかな？ヒントは1.5倍以上だ。
転送量はどれだけ大きくなるかな？ヒントは1.5倍以上だ。
324 ：[名無し]さん(bin+cue).rar：03/12/22 05:25 ID:WS7ylUpX
>>323
・・・・最初から答え書けば?
・・・・最初から答え書けば?
325 ：[名無し]さん(bin+cue).rar：03/12/22 06:52 ID:28zz+T4I
326 ：[名無し]さん(bin+cue).rar：03/12/22 09:13 ID:2XcJIu2F
RAID5マン氏、いくつか質問させてください。
全部ＤＬし終わらないと暗号解除キーが手に入らない仕様になっているのは、
部分キャッシュ状態では復号できないようにするためという解釈で合って
ますか？ これは何を意図したものでしょうか。単にキャッシュ保持者が
中身を見れないようにすることを確実にするためだけですか？
もう１つはパリティについてなんですが、オリジナルを手に入れるために
最低限必要なＤＬ量は、オリジナルと１００とするとどのくらいですか？
単純な oex 方式だと１００でしたが・・・。
１００を越えるとしたら、ある程度通信路のエラーレートが高くないと
ARQ 方式に対してメリットがないと思うのですが、エラーレートの採算
分岐点はどのくらいでしょうか？
全部ＤＬし終わらないと暗号解除キーが手に入らない仕様になっているのは、
部分キャッシュ状態では復号できないようにするためという解釈で合って
ますか？ これは何を意図したものでしょうか。単にキャッシュ保持者が
中身を見れないようにすることを確実にするためだけですか？
もう１つはパリティについてなんですが、オリジナルを手に入れるために
最低限必要なＤＬ量は、オリジナルと１００とするとどのくらいですか？
単純な oex 方式だと１００でしたが・・・。
１００を越えるとしたら、ある程度通信路のエラーレートが高くないと
ARQ 方式に対してメリットがないと思うのですが、エラーレートの採算
分岐点はどのくらいでしょうか？
327 ：[名無し]さん(bin+cue).rar：03/12/22 09:16 ID:2XcJIu2F
× オリジナルと１００とすると
○ オリジナルを１００とすると
○ オリジナルを１００とすると
328 ：RAID5マン（トリップ家に置き忘れ）：03/12/22 09:57 ID:2ZbDqQE0
>>326
■暗号化済み分割ファイルを全部入手しないと復号キーが
わからないようにしてある件
簡単に言えばキャッシュを持つ行為への危険性の低減です。
具体的に言えば、キャッシュ（と言っていいのかどうか微妙
ですが）を保持している人が、その内容を知り得ない状況を
作り出すことが目的です。
当初はoexに分割する案でしたが、単純にこれを行うと原本
同一性の証明が容易であるため、暗号化した上で新方式パリティ
を採用することで、バイナリレベルで原本同一性がまったく
無い状態を作り出しています。
[単純oex方式]
→1ビットおきでの原本同一性が証明できる。
→キャッシュ保持者はそれとわからないかもしれないが、原
本保持者にはそれが原本の一部であることを素片の一部から
証明できる。
[暗号化済み二次パリティ方式]
→原本同一性はバイナリレベルで皆無
→キャッシュ保持者も原本所持者も一部からは全体を証明できない。
→仮に原本Xとアルゴリズムaと暗号化鍵kを何らかの手段で解明し
暗号化済みEXを生成して同一のブロック化処理を施せば、ブロック
同一性を証明できるが、それを証明してもキャッシュ保持者はそれを
知り得ないであろうから責任を問えない。
■暗号化済み分割ファイルを全部入手しないと復号キーが
わからないようにしてある件
簡単に言えばキャッシュを持つ行為への危険性の低減です。
具体的に言えば、キャッシュ（と言っていいのかどうか微妙
ですが）を保持している人が、その内容を知り得ない状況を
作り出すことが目的です。
当初はoexに分割する案でしたが、単純にこれを行うと原本
同一性の証明が容易であるため、暗号化した上で新方式パリティ
を採用することで、バイナリレベルで原本同一性がまったく
無い状態を作り出しています。
[単純oex方式]
→1ビットおきでの原本同一性が証明できる。
→キャッシュ保持者はそれとわからないかもしれないが、原
本保持者にはそれが原本の一部であることを素片の一部から
証明できる。
[暗号化済み二次パリティ方式]
→原本同一性はバイナリレベルで皆無
→キャッシュ保持者も原本所持者も一部からは全体を証明できない。
→仮に原本Xとアルゴリズムaと暗号化鍵kを何らかの手段で解明し
暗号化済みEXを生成して同一のブロック化処理を施せば、ブロック
同一性を証明できるが、それを証明してもキャッシュ保持者はそれを
知り得ないであろうから責任を問えない。
329 ：RAID5マン（トリップ家に置き忘れ）：03/12/22 09:58 ID:2ZbDqQE0
■新方式パリティの計算と復号の関係
今回のパリティ方式であってもオリジナルデータ量が100とした
場合にダウンロードに必要なデータ量も100になります。
当初送信総データ量はパリティ率次第ですがおおむね150%以下です。
当然ながらパリティ率を低下させれば当初送信量は減りますが
複合可能性も低下してしまいますのでこのへんはサジ加減でしょうか。
パリティ計算に用いるxor演算はどれだけ計算を重ねてもデータ
量は一定ですし、その効果もパリティ数までの欠落しか許容できないのは
どの手法でも同じはずです。
今回のパリティ方式であってもオリジナルデータ量が100とした
場合にダウンロードに必要なデータ量も100になります。
当初送信総データ量はパリティ率次第ですがおおむね150%以下です。
当然ながらパリティ率を低下させれば当初送信量は減りますが
複合可能性も低下してしまいますのでこのへんはサジ加減でしょうか。
パリティ計算に用いるxor演算はどれだけ計算を重ねてもデータ
量は一定ですし、その効果もパリティ数までの欠落しか許容できないのは
どの手法でも同じはずです。
330 ：RAID5マン（トリップ家に置き忘れ）：03/12/22 11:03 ID:2ZbDqQE0
>>321
いいかげんな説明をしてやはり突っ込まれました（汗
指摘のあったような状態でのタテヨコのブロック状欠落は複合できません。
正確に言うと復元しようとするデータは必ず2つのパリティが係っていますが
二つとも同時に失われた状態が発生すると復元できません。
ですからある程度の自由度はありますが「どこでも」ってわけじゃないですね。
いいかげんな説明をしてやはり突っ込まれました（汗
指摘のあったような状態でのタテヨコのブロック状欠落は複合できません。
正確に言うと復元しようとするデータは必ず2つのパリティが係っていますが
二つとも同時に失われた状態が発生すると復元できません。
ですからある程度の自由度はありますが「どこでも」ってわけじゃないですね。
331 ：[名無し]さん(bin+cue).rar：03/12/22 11:09 ID:tzx4WmVc
うーーーーーーーん
やりたいことは判ったが、なぜこうここまで複雑化させないといけないのかが
わからんなあ。リスクを分散させるってのはいいと思うのだが、これってのは
あくまで「可能性を下げる」だけの話で、「不可能にする」じゃないだろ？
例えば、極端な例だが、3ノードに分散してULしたときにそのうち2ノードが協力
関係ならこの方法は使えないよな
しかも、この方法だと、20MBのファイルを落とす為に必要なファイル情報が
元の22倍になるよな(ファイルサイズ(MB)/10+2)。それだけ仮想ファイルキー
や検索キーが増えるのは非現実的だと思うんだが・・・
もし、完全にDLしないと原本同一性を証明できないようにしたければ、256B
程度の固定のランダムキーで暗号化をかけて、
「暗号化キー＋暗号化したファイル」を”ファイルの後ろ”から、奇数バイト,偶数
バイトで別のノードに送るだけでも実現できると思うんだが？
エラー訂正とかそういうのは302の言うとおり、暗号化部分とは別に作った方が
いいと思われ。そもそもパリティ程度じゃ通信エラーに完全に対応するのは不可能
やりたいことは判ったが、なぜこうここまで複雑化させないといけないのかが
わからんなあ。リスクを分散させるってのはいいと思うのだが、これってのは
あくまで「可能性を下げる」だけの話で、「不可能にする」じゃないだろ？
例えば、極端な例だが、3ノードに分散してULしたときにそのうち2ノードが協力
関係ならこの方法は使えないよな
しかも、この方法だと、20MBのファイルを落とす為に必要なファイル情報が
元の22倍になるよな(ファイルサイズ(MB)/10+2)。それだけ仮想ファイルキー
や検索キーが増えるのは非現実的だと思うんだが・・・
もし、完全にDLしないと原本同一性を証明できないようにしたければ、256B
程度の固定のランダムキーで暗号化をかけて、
「暗号化キー＋暗号化したファイル」を”ファイルの後ろ”から、奇数バイト,偶数
バイトで別のノードに送るだけでも実現できると思うんだが？
エラー訂正とかそういうのは302の言うとおり、暗号化部分とは別に作った方が
いいと思われ。そもそもパリティ程度じゃ通信エラーに完全に対応するのは不可能
332 ：[名無し]さん(bin+cue).rar：03/12/22 11:13 ID:8NAw9ae9
333 ：[名無し]さん(bin+cue).rar：03/12/22 12:36 ID:2XcJIu2F
オリジナルデータに対し、新RAID5 で９種のデータを作った場合と、
旧RAID5を使って、オリジナルを３分割したものからそれぞれ oex を作って
同じく９種のデータを作った場合とを比較してみた。
これら９種のデータをネット上に大量にばらまいて、無作為にキャッシュが
消され、ついに６個のデータだけになってしまった場合を考える。
９種から６個を取る組み合わせは 9^6 で５３万通り。
旧RAID5でオリジナルが復元できる組合わせは (3x2)^3 で 1300 通り。
新RAID5でオリジナルが復元できる組合わせは 9!/3! で６万通り。
つまり旧RAID5のデータ復元確率は 0.04% なのに対し、新方式は 11% まで
上昇する。どちらもデータサイズによるペナルティは同じなので、これだけ
見ると確かに新方式の方が優れていると言えそうだ。
しかしこの計算をしていて気付いたんだが、オリジナルファイルが大きくて
ブロックがあまりに細かく分かれてしまい、各ブロックがネットワーク上の
あちこちのノードに分散してしまうとしたら、残存キャッシュ容量がオリジナルの
容量と同じになったときの復元確率は、結局どちらの方式を取ったとしても
０％に収束してしまう（ブロック数が増えると、上記の計算で言うところの
分母の方が分子よりも増加ペースが激しいため）。
つまり、oex だろうが新RAID5だろうが効果はほとんどなくなってしまう。
旧RAID5を使って、オリジナルを３分割したものからそれぞれ oex を作って
同じく９種のデータを作った場合とを比較してみた。
これら９種のデータをネット上に大量にばらまいて、無作為にキャッシュが
消され、ついに６個のデータだけになってしまった場合を考える。
９種から６個を取る組み合わせは 9^6 で５３万通り。
旧RAID5でオリジナルが復元できる組合わせは (3x2)^3 で 1300 通り。
新RAID5でオリジナルが復元できる組合わせは 9!/3! で６万通り。
つまり旧RAID5のデータ復元確率は 0.04% なのに対し、新方式は 11% まで
上昇する。どちらもデータサイズによるペナルティは同じなので、これだけ
見ると確かに新方式の方が優れていると言えそうだ。
しかしこの計算をしていて気付いたんだが、オリジナルファイルが大きくて
ブロックがあまりに細かく分かれてしまい、各ブロックがネットワーク上の
あちこちのノードに分散してしまうとしたら、残存キャッシュ容量がオリジナルの
容量と同じになったときの復元確率は、結局どちらの方式を取ったとしても
０％に収束してしまう（ブロック数が増えると、上記の計算で言うところの
分母の方が分子よりも増加ペースが激しいため）。
つまり、oex だろうが新RAID5だろうが効果はほとんどなくなってしまう。
334 ：[名無し]さん(bin+cue).rar：03/12/22 12:37 ID:2XcJIu2F
これを解消するためには、あるノードはあるファイルの oex ブロックの
いずれかを「すべて」保持するようにする必要がある。
そして、ノードが保持しているキャッシュが消されるときは、１つのファイルの
o ブロック（または ex）全部が一度に消されるようにする。こうすれば、
ネット全体で見た必要ストレージ容量が同じであるにも関わらず、オリジナルの
復元確率はなんと 67% にまで跳ね上がる。
この法則を勘案すると、残念ながら新RAID5のパリティによるメリットはなくなって
しまう。旧oexの組み合わせが 2/3 に対し新RAID5は 6/9 と自由度が高いように
思えるが、１つのノードが完全キャッシュを持たないようにするにはたかだか２つの
ノードが協力すればよいので、分子が２であるoexがベスト。むしろ新RAID5で
ノードに変な組み合わせを許してしまうと、逆に復元確率が低くなってしまう。
結論。ノードに完全キャッシュを保持させるのが嫌ならoexを採用すべし。また、
１つのノードはあるファイルの oex いずれかをすべて保持し、消すときは一括で
消すようにすべし。
以上、新RAID5の効果を数字で計ろうと妄想を進めたところ、漏れ的には逆の
結論に達してしまったので、一応妄想ログを残しておく。
いずれかを「すべて」保持するようにする必要がある。
そして、ノードが保持しているキャッシュが消されるときは、１つのファイルの
o ブロック（または ex）全部が一度に消されるようにする。こうすれば、
ネット全体で見た必要ストレージ容量が同じであるにも関わらず、オリジナルの
復元確率はなんと 67% にまで跳ね上がる。
この法則を勘案すると、残念ながら新RAID5のパリティによるメリットはなくなって
しまう。旧oexの組み合わせが 2/3 に対し新RAID5は 6/9 と自由度が高いように
思えるが、１つのノードが完全キャッシュを持たないようにするにはたかだか２つの
ノードが協力すればよいので、分子が２であるoexがベスト。むしろ新RAID5で
ノードに変な組み合わせを許してしまうと、逆に復元確率が低くなってしまう。
結論。ノードに完全キャッシュを保持させるのが嫌ならoexを採用すべし。また、
１つのノードはあるファイルの oex いずれかをすべて保持し、消すときは一括で
消すようにすべし。
以上、新RAID5の効果を数字で計ろうと妄想を進めたところ、漏れ的には逆の
結論に達してしまったので、一応妄想ログを残しておく。
335 ：[名無し]さん(bin+cue).rar：03/12/22 14:24 ID:W21MQKTC
ｹﾞﾝｷﾀﾞｼﾃ(｡･ω･)ﾉﾞ (;つД｀) ←開発者
337 ：[名無し]さん(bin+cue).rar：03/12/22 18:56 ID:Fladia+4
オープンソースとDOM対策を両立させる中継契約方式を提案したい。
吸ったら吸われ、吸われたら吸う。これだけ。
キモは現物の交換でなくて中継権の交換というところ。現物の交換は交換する
ファイルがないと始まらないが、中継権の交換は目当てのファイルを自分が持っ
ているかどうかは関係ない。お互いに中継しているかどうかだけ。
接続しようとするなら中継権を交換しなければいけないが、中継権を行使する
かは自由。要するにDOMは出来ないが神になりたければなれる。
オープンソースとDOM対策を両立させ、拡散効率も良いと思うのだがどうだろう？
吸ったら吸われ、吸われたら吸う。これだけ。
キモは現物の交換でなくて中継権の交換というところ。現物の交換は交換する
ファイルがないと始まらないが、中継権の交換は目当てのファイルを自分が持っ
ているかどうかは関係ない。お互いに中継しているかどうかだけ。
接続しようとするなら中継権を交換しなければいけないが、中継権を行使する
かは自由。要するにDOMは出来ないが神になりたければなれる。
オープンソースとDOM対策を両立させ、拡散効率も良いと思うのだがどうだろう？
338 ：[名無し]さん(bin+cue).rar：03/12/22 19:37 ID:XVxNGL7r
339 ：[名無し]さん(bin+cue).rar：03/12/22 19:38 ID:Fladia+4
340 ：[名無し]さん(bin+cue).rar：03/12/22 19:57 ID:F1ijIcNt
GUIに猫が入ってればなんでもいいよ
341 ：[名無し]さん(bin+cue).rar：03/12/22 20:27 ID:Am9gu4D1
これはどうよ。
常に20前後のPCとコネクションを確立する。それぞれデータ量を
ほぼ同じにする。データを送信するときは間に絶対挟むんだけど
そんときに経由するPCを頻繁に変える。受信してるほうからはそれぞれ暗号化してるから
実際落としきってみないとどれが著作権に違反してるファイルか分からない。
20ぐらいのデータの1つが本物だから。
常に20前後のPCとコネクションを確立する。それぞれデータ量を
ほぼ同じにする。データを送信するときは間に絶対挟むんだけど
そんときに経由するPCを頻繁に変える。受信してるほうからはそれぞれ暗号化してるから
実際落としきってみないとどれが著作権に違反してるファイルか分からない。
20ぐらいのデータの1つが本物だから。
342 ：[名無し]さん(bin+cue).rar：03/12/22 20:45 ID:AmMEcUMi
343 ：[名無し]さん(bin+cue).rar：03/12/22 20:57 ID:hwPf8Wa7
344 ：[名無し]さん(bin+cue).rar：03/12/22 21:28 ID:XVxNGL7r
>>341
あんたって、ほんっっっっとにバカね
あんたって、ほんっっっっとにバカね
345 ：[名無し]さん(bin+cue).rar：03/12/22 21:32 ID:VDWRW6zh
>>341
バカシンジ！
バカシンジ！
346 ：[名無し]さん(bin+cue).rar：03/12/22 22:06 ID:MIVdkBnk
347 ：[名無し]さん(bin+cue).rar：03/12/22 23:59 ID:K6acvWE+
348 ： ◆Fw0Kir8iYA ：03/12/23 00:37 ID:XJ5F+szJ
他の掲示板に書き込んだついでに、こっちにも遅れすです。
>>199
＞ > しかもこの場合中継しても暗号化されてるからキャッシュする意味ないし、
＞ > ファイルサイズが大きい場合、途中で切れたらどうするんだって話なわけで・・・。
＞ > ついでに帯域の無駄多すぎかな・・・。
＞この辺はやはり隣接云々形式でも泣き所。なんとかなんないもんかね。
現在の「隣接ノードに…」の仕様では、キャッシュは利用可能です。
このとき、キャッシュをupする人にはキャッシュの中身は分からない
ように工夫してあります。
また、途中で接続が切れても問題ありません。
帯域の無駄は、匿名性を確保できる範囲で最小限に抑えているつもりです。
>>199
＞ > しかもこの場合中継しても暗号化されてるからキャッシュする意味ないし、
＞ > ファイルサイズが大きい場合、途中で切れたらどうするんだって話なわけで・・・。
＞ > ついでに帯域の無駄多すぎかな・・・。
＞この辺はやはり隣接云々形式でも泣き所。なんとかなんないもんかね。
現在の「隣接ノードに…」の仕様では、キャッシュは利用可能です。
このとき、キャッシュをupする人にはキャッシュの中身は分からない
ように工夫してあります。
また、途中で接続が切れても問題ありません。
帯域の無駄は、匿名性を確保できる範囲で最小限に抑えているつもりです。
349 ：[名無し]さん(bin+cue).rar：03/12/23 01:06 ID:hv/d+Xp9
キャッシュを再利用するなら、それがどんなファイルの一部であるか
分からないと利用できないと思うんだが。
分からないと利用できないと思うんだが。
350 ：[名無し]さん(bin+cue).rar：03/12/23 01:08 ID:D30kbkB2
どんな仕組みになるにしろ、転送効率が極端に悪くなっては意味が無いな
351 ：[名無し]さん(bin+cue).rar：03/12/23 02:50 ID:WvqoKGaL
>>337
Winnyのオープンソース化を考えるスレ
http://pc.2ch.net/test/read.cgi/linux/1056020225/354-359
http://winny.info/2ch/misc/1056020225.html#354
こんな案もかつて出ていました。参考まで
Winnyのオープンソース化を考えるスレ
http://pc.2ch.net/test/read.cgi/linux/1056020225/354-359
http://winny.info/2ch/misc/1056020225.html#354
こんな案もかつて出ていました。参考まで
352 ：[名無し]さん(bin+cue).rar：03/12/23 12:12 ID:yp3gq30c
>RAID5マン氏
新RAID5は、突き詰めていくと過去ログ（part6）にある「秘密分散法」になるのでは?
この仕様なら、ファイル分割方式は独自形式にこだわる理由はないと思うんですが。
フリーのライブラリもあるみたいですし。
それより、>>332にあるように、匿名性や効率に直接かかわってくる
通信部の仕様について詳しく解説してほしいです。
特に聞きたいのは、自分の持っているキャッシュが何のファイルの1部か
分かるかどうかということ。この問題がクリアできていないなら、RAID10、
RAID3のほうが優れているのでは?
新RAID5は、突き詰めていくと過去ログ（part6）にある「秘密分散法」になるのでは?
この仕様なら、ファイル分割方式は独自形式にこだわる理由はないと思うんですが。
フリーのライブラリもあるみたいですし。
それより、>>332にあるように、匿名性や効率に直接かかわってくる
通信部の仕様について詳しく解説してほしいです。
特に聞きたいのは、自分の持っているキャッシュが何のファイルの1部か
分かるかどうかということ。この問題がクリアできていないなら、RAID10、
RAID3のほうが優れているのでは?
353 ：[名無し]さん(bin+cue).rar：03/12/23 17:43 ID:b+zIfd8W
書き込む人と共にスレ主の匿名性を守るP2P掲示板の仕様を考えてみた。
スレ立て人とスレ持ち人を分離する方式だ。
スレ立て人は他のPCでスレを立てさせ、スレ持ち人を作る。
スレ持ち人はスレ持ち人とされた事が分からない。
スレ持ち人のPCは更に他のPCにスレを転送し、スレ持ち団を作る。
スレ持ち団は互いにリンクし、欠員が出た場合は新たにスレ持ち人を作る。
こうする事によりスレの消滅を防ぐ。
nybbsのスレ主の匿名性の低さと使いにくさを同時に解決できると思うのだが、どうだろう？
スレ立て人とスレ持ち人を分離する方式だ。
スレ立て人は他のPCでスレを立てさせ、スレ持ち人を作る。
スレ持ち人はスレ持ち人とされた事が分からない。
スレ持ち人のPCは更に他のPCにスレを転送し、スレ持ち団を作る。
スレ持ち団は互いにリンクし、欠員が出た場合は新たにスレ持ち人を作る。
こうする事によりスレの消滅を防ぐ。
nybbsのスレ主の匿名性の低さと使いにくさを同時に解決できると思うのだが、どうだろう？
354 ：[名無し]さん(bin+cue).rar：03/12/23 18:10 ID:lCtdbMqy
放流者の同一性を確認しにくくするため、送信者と受信者のIPの積をとって情報キーを作り
同一IPに対して自分のIPが変わらない限り、ファイル全体の49%以上はUPしない。
効率は悪くなるが、3回以上の転送の切断は、今でもよくあることなのでそれほどストレスも
溜まらないと思う。UPを開始するファイル上の位置をIPごとに変えれば補完もしやすくなる。
ただ、完全なファイル以外の情報キーがどれくらいの量になるか。場合によっては、かなり
の帯域を占有してしまう可能性もある。
同一IPに対して自分のIPが変わらない限り、ファイル全体の49%以上はUPしない。
効率は悪くなるが、3回以上の転送の切断は、今でもよくあることなのでそれほどストレスも
溜まらないと思う。UPを開始するファイル上の位置をIPごとに変えれば補完もしやすくなる。
ただ、完全なファイル以外の情報キーがどれくらいの量になるか。場合によっては、かなり
の帯域を占有してしまう可能性もある。
355 ：[名無し]さん(bin+cue).rar：03/12/23 18:44 ID:InXlhLL+
>>353
荒らされたときのあぼーんは誰がどうやってするの？
荒らされたときのあぼーんは誰がどうやってするの？
356 ：[名無し]さん(bin+cue).rar：03/12/23 19:08 ID:b+zIfd8W
>>355
荒らし書き込みだったら、管理者パスワードシステムでも付ければ良いだろう。
荒らし書き込みだったら、管理者パスワードシステムでも付ければ良いだろう。
間違って投稿ボタン押してしまった。
しかし、荒らしスレだった場合は・・・どうしよう。
しかし、荒らしスレだった場合は・・・どうしよう。
358 ：[名無し]さん(bin+cue).rar：03/12/23 19:21 ID:Rsoy930C
全部落とさないと、何のファイルのキャッシュかわからない。
いったいどうやってダウンロードするんだ？
神経衰弱？
いったいどうやってダウンロードするんだ？
神経衰弱？
359 ：[名無し]さん(bin+cue).rar：03/12/23 19:22 ID:I+wRUglx
ヤミ鍋？
360 ：[名無し]さん(bin+cue).rar：03/12/23 20:12 ID:LVCIU0kx
例えば 全データのDLを完了した時に登録したキーワードが含まれていたら
そのデータはファイル化かしなければ継続して分散送信化ってのは？
そのデータはファイル化かしなければ継続して分散送信化ってのは？
361 ：[名無し]さん(bin+cue).rar：03/12/24 05:26 ID:F1pdCjnG
>>360
そのデータがファイル化しなかった時点で分散送信意味なし
そのデータがファイル化しなかった時点で分散送信意味なし
362 ：[名無し]さん(bin+cue).rar：03/12/24 12:00 ID:ZiBo+p2c
皆さん作ってますか？
経過報告とかしてくださいね。
経過報告とかしてくださいね。
363 ：[名無し]さん(bin+cue).rar：03/12/24 12:09 ID:YRkjpORW
>>362
いつのまにか pre-alpha.14++.zip とかでてるぞ
> 14++です。更新点は
> ・サムネイルサイズ以下の画像はそのままのサイズで表示するようにした
> ・レスへのジャンプが出来るようになった
> →2chと異なり新規ウィンドウではなくスクロールするだけです。
> ・未読スレへのリンクをクリックしてもリクエストが発行されないのを修正
>
> サムネイルサイズ以下の画像のサムネイルが既にある場合は
> サムネイルフォルダからデータを削除すれば再生成されます。
>
> 要求等は「要望まとめスレ (文字のみ)」にお願いします。
> bbs://6edeab44-4c7a-431a-9b8d-291e8da647b7
> 要求だけ書き込んでください。議論は今まで通りのスレで。
いつのまにか pre-alpha.14++.zip とかでてるぞ
> 14++です。更新点は
> ・サムネイルサイズ以下の画像はそのままのサイズで表示するようにした
> ・レスへのジャンプが出来るようになった
> →2chと異なり新規ウィンドウではなくスクロールするだけです。
> ・未読スレへのリンクをクリックしてもリクエストが発行されないのを修正
>
> サムネイルサイズ以下の画像のサムネイルが既にある場合は
> サムネイルフォルダからデータを削除すれば再生成されます。
>
> 要求等は「要望まとめスレ (文字のみ)」にお願いします。
> bbs://6edeab44-4c7a-431a-9b8d-291e8da647b7
> 要求だけ書き込んでください。議論は今まで通りのスレで。
364 ：[名無し]さん(bin+cue).rar：03/12/24 13:25 ID:xPNpXuoY
>>362
37妻子スレで報告してますが何か?
37妻子スレで報告してますが何か?
365 ：[名無し]さん(bin+cue).rar：03/12/24 16:43 ID:ppZYxXRv
あげの罪で逮捕
366 ：[名無し]さん(bin+cue).rar：03/12/24 20:35 ID:Gn8O/+I3
増えるであろう情報キーの圧縮は必須だな。
367 ：RAID5マン ◆H2RAID5./g ：03/12/25 02:31 ID:7vkSQcRb
ぉはょぅございます。
いろいろな考え方や見方が聞けて面白いです。
>>352で指摘されたようにファイル分割＆分散をつきつめていくと
秘密情報分散法にいきつきますねぇ。あれでファイル容量の増加率とか
がもっと低ければいいんですがね～
なんかもうローカルで暗号化してそれを固定分割（2とか4とか適当に）
＆分散保持するだけで良いような気がしてきました。
いろいろ脳ﾐｿ使うｵﾅﾆｰだからわざわざ難しいほうに進んで行ってしまった
気がしてきました。
いったん脳ﾐｿﾘｾｯﾄしてきます。
いろいろな考え方や見方が聞けて面白いです。
>>352で指摘されたようにファイル分割＆分散をつきつめていくと
秘密情報分散法にいきつきますねぇ。あれでファイル容量の増加率とか
がもっと低ければいいんですがね～
なんかもうローカルで暗号化してそれを固定分割（2とか4とか適当に）
＆分散保持するだけで良いような気がしてきました。
いろいろ脳ﾐｿ使うｵﾅﾆｰだからわざわざ難しいほうに進んで行ってしまった
気がしてきました。
いったん脳ﾐｿﾘｾｯﾄしてきます。
368 ：191 ◆XoFE2Orpbo ：03/12/25 04:35 ID:vG7HRjvB
誰も気にしてなかったと思うけど、
ちょっと忙しくて年末も時間取れそうにありません。
ってことで、開発は一旦停止させてもらいますｗ。
また時間できて、Ｐ２Ｐやりたくなったら再開しますわ。
26氏、RAID5マン氏、がんばってくださいな～。
ちょっと忙しくて年末も時間取れそうにありません。
ってことで、開発は一旦停止させてもらいますｗ。
また時間できて、Ｐ２Ｐやりたくなったら再開しますわ。
26氏、RAID5マン氏、がんばってくださいな～。
369 ：[名無し]さん(bin+cue).rar：03/12/25 09:01 ID:MNY1LUzW
370 ：[名無し]さん(bin+cue).rar：03/12/25 09:11 ID:MMpXXwyg
>>369
なんか、ここの始めの方のpartで出てた気がする。
こういう研究とこのスレで議論されてるものの決定的な違いは
それぞれの端末が当たり前のようにネットワークから離脱したり戻ってきたりすることなんだよなぁ。
データの一部に欠落が・・・
とか言う仮定での議論ももちろんされてるけど、
あくまで通常は端末が安定してネットワークの機能を担う、って言う事を前提にしてる。
もちろん、だから使えないんじゃなくて、
応用できそうな部分は拾ってくれば良いんだけどね。
なんか、ここの始めの方のpartで出てた気がする。
こういう研究とこのスレで議論されてるものの決定的な違いは
それぞれの端末が当たり前のようにネットワークから離脱したり戻ってきたりすることなんだよなぁ。
データの一部に欠落が・・・
とか言う仮定での議論ももちろんされてるけど、
あくまで通常は端末が安定してネットワークの機能を担う、って言う事を前提にしてる。
もちろん、だから使えないんじゃなくて、
応用できそうな部分は拾ってくれば良いんだけどね。
371 ：[名無し]さん(bin+cue).rar：03/12/25 09:35 ID:jR08V5Ru
「ヤフー」に投稿者アドレス開示命令 (読売新聞)
大阪証券取引所（大阪市中央区）と役員２人が、インターネット掲示板に書き込まれた投稿で名誉を傷つけられたとして、
掲示板を管理するネット接続大手「ヤフー」（東京都港区）に、投稿者のパソコンを特定できるアドレスなどの開示を求めた
訴訟で、東京地裁は２４日、ヤフーに開示を命じる判決を言い渡した。
奥田隆文裁判長は「投稿は論評の域を逸脱した人身攻撃で、損害賠償請求の対象になるため、（ヤフーには）プロバイダ
ー責任法に基づく開示義務がある」と述べた。
http://news.www.infoseek.co.jp/topics/business/yahoo.html?d=24yomiuri20031224it13&cat=35&typ=t
大阪証券取引所（大阪市中央区）と役員２人が、インターネット掲示板に書き込まれた投稿で名誉を傷つけられたとして、
掲示板を管理するネット接続大手「ヤフー」（東京都港区）に、投稿者のパソコンを特定できるアドレスなどの開示を求めた
訴訟で、東京地裁は２４日、ヤフーに開示を命じる判決を言い渡した。
奥田隆文裁判長は「投稿は論評の域を逸脱した人身攻撃で、損害賠償請求の対象になるため、（ヤフーには）プロバイダ
ー責任法に基づく開示義務がある」と述べた。
http://news.www.infoseek.co.jp/topics/business/yahoo.html?d=24yomiuri20031224it13&cat=35&typ=t
372 ：[名無し]さん(bin+cue).rar：03/12/25 12:26 ID:XMUTnpkA
やっぱり何かまとまりが無いなあ。
テンプレ4.みたいなことも一応書いてあるけど
仕様固めてさっさと作っちゃってる人も居るみたいだし。
＞14, 基本部分をプラグイン・ライブラリの形で提供してはどうか
＞→良いアイデアだが、それは実装段階の話に近いので、要望スレで。
p2pはやっぱりできるだけ多くの参加者を一つのネットワークに集中させる
ことが重要なんだからこういう工夫は必要だと思うけどなあ。
そもそも「ここは仕様を決めるスレです」とか言って、
実装の話をかたくなに拒む理由が良く分からん。
実装の話をするためのスレが立ってるわけでもないし。
要望スレは実装の話をする場所じゃないでしょ？
テンプレ4.みたいなことも一応書いてあるけど
仕様固めてさっさと作っちゃってる人も居るみたいだし。
＞14, 基本部分をプラグイン・ライブラリの形で提供してはどうか
＞→良いアイデアだが、それは実装段階の話に近いので、要望スレで。
p2pはやっぱりできるだけ多くの参加者を一つのネットワークに集中させる
ことが重要なんだからこういう工夫は必要だと思うけどなあ。
そもそも「ここは仕様を決めるスレです」とか言って、
実装の話をかたくなに拒む理由が良く分からん。
実装の話をするためのスレが立ってるわけでもないし。
要望スレは実装の話をする場所じゃないでしょ？
373 ：[名無し]さん(bin+cue).rar：03/12/25 12:44 ID:80HtREDE
>>372
誰もが納得できるたった１つの仕様が作れるのならいいが、どうもそれは
無理そうな雲行き。勝手に仕様固めて作り始める人が出るのはいいんじゃない？
漏れ的には、ここは仕様案や使えそうなアイデアのパーツを練り上げる場と
いうことでいいと思う。実装の話を始めると瑣末なことが多すぎてアイデアの
本質が見えづらくなる。
それに、実装の話をするスレならまとめサイトの掲示板にいくつか立ってるよ。
実装段階に入ったプロジェクトはそっちに移るというやり方でいいんじゃん？
＞14, 基本部分をプラグイン・ライブラリの形で提供してはどうか
基本部分の仕様案の話なら大歓迎。方向性が決まって、詳細を詰める段階に
なったらやはり別スレに移行する必要があると思うが、別にそれで問題ない
でしょ。
誰もが納得できるたった１つの仕様が作れるのならいいが、どうもそれは
無理そうな雲行き。勝手に仕様固めて作り始める人が出るのはいいんじゃない？
漏れ的には、ここは仕様案や使えそうなアイデアのパーツを練り上げる場と
いうことでいいと思う。実装の話を始めると瑣末なことが多すぎてアイデアの
本質が見えづらくなる。
それに、実装の話をするスレならまとめサイトの掲示板にいくつか立ってるよ。
実装段階に入ったプロジェクトはそっちに移るというやり方でいいんじゃん？
＞14, 基本部分をプラグイン・ライブラリの形で提供してはどうか
基本部分の仕様案の話なら大歓迎。方向性が決まって、詳細を詰める段階に
なったらやはり別スレに移行する必要があると思うが、別にそれで問題ない
でしょ。
374 ： ：03/12/25 13:22 ID:e6QoIqV8
帯域使ったっていいじゃん？ISPに目を付けられる可能性は別にあるが、逮捕されるよりはるかにマシ。
それに通信技術もどんどん進歩していくだろうし。
それに通信技術もどんどん進歩していくだろうし。
375 ：[名無し]さん(bin+cue).rar：03/12/25 13:25 ID:DSbKKY8y
376 ：[名無し]さん(bin+cue).rar：03/12/25 13:30 ID:80HtREDE
帯域使いまくっていいなら、すでに FreeNet なり Mute なりがあるから
ここで議論する必要はないな。
それらにユーザが群がらないということは、やはりみんな匿名性と効率の
バランスを求めているということじゃない？
ここで議論する必要はないな。
それらにユーザが群がらないということは、やはりみんな匿名性と効率の
バランスを求めているということじゃない？
377 ：[名無し]さん(bin+cue).rar：03/12/25 13:33 ID:DSbKKY8y
いや、まあ、ある程度は使いまくることは前提になってるんだが。
以下>>376の下２行に同意。
以下>>376の下２行に同意。
378 ：[名無し]さん(bin+cue).rar：03/12/25 14:23 ID:FtX2TF9b
＞匿名性と効率のバランス
匿名性と効率・即答性が二律背反という事は、世のP2Pアプリ達がイヤという程証明してくれた。
ﾀﾞｳｿ住人と一般ユーザー・企業両方が食いつくような仕組みを、一つのシステムで
実現する事は不可能だと思う。
だって普通にネトゲーだのwebだの動画配信だのやろうと思ったって、暗号化なんて不必要だし、
レスポンス命なのに鍵交換だの中継だのチンタラしてられんし。
P2Pインフラと匿名性重視のファイル交換アプリを切り離して開発して欲しい。
匿名性と効率・即答性が二律背反という事は、世のP2Pアプリ達がイヤという程証明してくれた。
ﾀﾞｳｿ住人と一般ユーザー・企業両方が食いつくような仕組みを、一つのシステムで
実現する事は不可能だと思う。
だって普通にネトゲーだのwebだの動画配信だのやろうと思ったって、暗号化なんて不必要だし、
レスポンス命なのに鍵交換だの中継だのチンタラしてられんし。
P2Pインフラと匿名性重視のファイル交換アプリを切り離して開発して欲しい。
379 ：[名無し]さん(bin+cue).rar：03/12/25 14:25 ID:gVV4lcTY
>>378
そんなもん放っとけばどっかの企業が開発するんじゃないのか？
そんなもん放っとけばどっかの企業が開発するんじゃないのか？
380 ：[名無し]さん(bin+cue).rar：03/12/25 14:32 ID:DSbKKY8y
ちょっと教えて君ですまんが、質問があります。
匿名性が高いと言われているFreenetに関することなんだが、
Freenetスレが落ちてるみたいなんで、わかる人は教えてください。
解説ページ教えてくれるだけでも良いです。
この仕様スレではWinnyより匿名性を上げる方法は、
・必ず転送を挟む
・完全キャッシュを持たないようにする
っていう２つの結論だったよな？
これはFreenetで実装されてるの？
それとも他に匿名性を上げる要素がある？
匿名性が高いと言われているFreenetに関することなんだが、
Freenetスレが落ちてるみたいなんで、わかる人は教えてください。
解説ページ教えてくれるだけでも良いです。
この仕様スレではWinnyより匿名性を上げる方法は、
・必ず転送を挟む
・完全キャッシュを持たないようにする
っていう２つの結論だったよな？
これはFreenetで実装されてるの？
それとも他に匿名性を上げる要素がある？
381 ：[名無し]さん(bin+cue).rar：03/12/25 14:51 ID:FtX2TF9b
>>379 もう開発されてたらぜひ教えてくれ
余計なモンいらん。暗号・中継・冗長化・匿名・データ分割、なーんもいらん。
とにかくP2PでHTTP並みの応答速度が欲しいんじゃ！
それがDLLorサービスで提供されてて簡単に（ファイル処理っぽく）扱えれば尚ヨシ！
・・・というニーズに応えられるベースがあれば、その上にnyっぽいシステム乗せられると思・・・わない？
余計なモンいらん。暗号・中継・冗長化・匿名・データ分割、なーんもいらん。
とにかくP2PでHTTP並みの応答速度が欲しいんじゃ！
それがDLLorサービスで提供されてて簡単に（ファイル処理っぽく）扱えれば尚ヨシ！
・・・というニーズに応えられるベースがあれば、その上にnyっぽいシステム乗せられると思・・・わない？
382 ：[名無し]さん(bin+cue).rar：03/12/25 15:16 ID:gVV4lcTY
>>381
P2PでHTTP並の応答速度はまず無理かと。
特定の鯖と直接通信するのとP2Pネットワークと通信するのとじゃ、
応答速度に差が出るのは避けられないだろう。
どうだろう？
俺は外国語からっきしなんで、外国産のソフトはほとんど使った事がないんだが、
KazaaとかはP2Pで直接接続じゃないの？
今RIAAに訴えられまくってるソフト。
P2PでHTTP並の応答速度はまず無理かと。
特定の鯖と直接通信するのとP2Pネットワークと通信するのとじゃ、
応答速度に差が出るのは避けられないだろう。
どうだろう？
俺は外国語からっきしなんで、外国産のソフトはほとんど使った事がないんだが、
KazaaとかはP2Pで直接接続じゃないの？
今RIAAに訴えられまくってるソフト。
383 ：[名無し]さん(bin+cue).rar：03/12/25 15:17 ID:9mEWS9TZ
kazaa?
384 ：[名無し]さん(bin+cue).rar：03/12/25 15:26 ID:gVV4lcTY
>>380
気になってたんだけど、完全キャッシュを持たない事に意味があるんだろうか？
アップしたらまずいものを送信可能化した場合、
全部でも一部でもアウトになると思うんだけど。
ただ効率が落ちるだけではないかな？
気になってたんだけど、完全キャッシュを持たない事に意味があるんだろうか？
アップしたらまずいものを送信可能化した場合、
全部でも一部でもアウトになると思うんだけど。
ただ効率が落ちるだけではないかな？
385 ：[名無し]さん(bin+cue).rar：03/12/25 15:32 ID:80HtREDE
>>380
漏れも仕組みが詳しく載ってるページ探してるんだけどね。
ttp://www.sfc.wide.ad.jp/~egichan/mlecture/netsec2000f/kadai3.html
ttp://de-co.info/freenet/icsi.html
ここ見る限り、結局のところ匿名性の根拠は多段転送だけ、という気がして仕方ないんだが、
なんかそうではないような言われ方をしているのも聞くし、よくわからない。
詳しい人がいたら、ぜひ簡単でいいので解説キボン。
> この仕様スレではWinnyより匿名性を上げる方法は、
> ・必ず転送を挟む
> ・完全キャッシュを持たないようにする
> っていう２つの結論だったよな？
他にも、「隣接ノードに情報を漏らさない方式」とか「無作為XOR方式」とかが出てる。
まあ、隣接形式も多段転送の一種と言えなくもないが。
あとは、信頼できるノードとしか取引しない、っていう方向性もあるかな。
漏れも仕組みが詳しく載ってるページ探してるんだけどね。
ttp://www.sfc.wide.ad.jp/~egichan/mlecture/netsec2000f/kadai3.html
ttp://de-co.info/freenet/icsi.html
ここ見る限り、結局のところ匿名性の根拠は多段転送だけ、という気がして仕方ないんだが、
なんかそうではないような言われ方をしているのも聞くし、よくわからない。
詳しい人がいたら、ぜひ簡単でいいので解説キボン。
> この仕様スレではWinnyより匿名性を上げる方法は、
> ・必ず転送を挟む
> ・完全キャッシュを持たないようにする
> っていう２つの結論だったよな？
他にも、「隣接ノードに情報を漏らさない方式」とか「無作為XOR方式」とかが出てる。
まあ、隣接形式も多段転送の一種と言えなくもないが。
あとは、信頼できるノードとしか取引しない、っていう方向性もあるかな。
386 ：[名無し]さん(bin+cue).rar：03/12/25 15:41 ID:mQ6IRkDt
387 ：[名無し]さん(bin+cue).rar：03/12/25 15:42 ID:DSbKKY8y
>>384
漏れの解釈。
それだけでは意味のないファイルＡ，Ｂがあって、
それを組み合わせて変換すると著作権に保護されたファイルＣが出来るとする。
そこで著作権侵害の「材料」となるＡ、Ｂをupするのは違法かどうかだが、
・酸素系洗剤、塩素系洗剤（混ざると毒ガス発生、ガスの状態で売るのは違法）のように合法
・麻薬のように原材料だけでも違法
となるか、法解釈の分かれるところだと思う。
つまり、合法になるのでなく、法解釈が難しい（前例の無い状態に持っていく）やり方だと思う。
>>385
レスサンクス。
そのサイトはさっきから見てるｗ
やっぱりFreenetの匿名性もWinnyと同レベルなのかな？（除くnyBBS)
漏れの解釈。
それだけでは意味のないファイルＡ，Ｂがあって、
それを組み合わせて変換すると著作権に保護されたファイルＣが出来るとする。
そこで著作権侵害の「材料」となるＡ、Ｂをupするのは違法かどうかだが、
・酸素系洗剤、塩素系洗剤（混ざると毒ガス発生、ガスの状態で売るのは違法）のように合法
・麻薬のように原材料だけでも違法
となるか、法解釈の分かれるところだと思う。
つまり、合法になるのでなく、法解釈が難しい（前例の無い状態に持っていく）やり方だと思う。
>>385
レスサンクス。
そのサイトはさっきから見てるｗ
やっぱりFreenetの匿名性もWinnyと同レベルなのかな？（除くnyBBS)
388 ：[名無し]さん(bin+cue).rar：03/12/25 15:48 ID:80HtREDE
>>387
> やっぱりFreenetの匿名性もWinnyと同レベルなのかな？
いや、そんなことはないはず。ny は中継率低かったから元放流者と繋がる可能性も
低くないので、手間をかければ絞り込むことができた。
FreeNet は経路上のすべてのノードで中継が起こるから、辿るのは不可能に近い。
・・・と解釈しているが、全然自信がないw
> やっぱりFreenetの匿名性もWinnyと同レベルなのかな？
いや、そんなことはないはず。ny は中継率低かったから元放流者と繋がる可能性も
低くないので、手間をかければ絞り込むことができた。
FreeNet は経路上のすべてのノードで中継が起こるから、辿るのは不可能に近い。
・・・と解釈しているが、全然自信がないw
389 ：[名無し]さん(bin+cue).rar：03/12/25 15:49 ID:FtX2TF9b
>>382
極端な事を言えば、要するに「全ノードHTTPサーバント計画」なんだよね。
それも、zip解凍して一つ二つ設定してポンと使えちゃうような、nyレベルの。
ここで出てくる様々なアイデアを、「実際に実装してみる」という段階に移行しやすい状況が欲しい。
新しい仕様を携えた有志が、またイチからSocket使ってPort0対策して・・・なんて煩わしい事
せずに済むよう、汎用・簡易な枠組みを『ﾀﾞｳｿ住人が作る』・・・これが大事。
極端な事を言えば、要するに「全ノードHTTPサーバント計画」なんだよね。
それも、zip解凍して一つ二つ設定してポンと使えちゃうような、nyレベルの。
ここで出てくる様々なアイデアを、「実際に実装してみる」という段階に移行しやすい状況が欲しい。
新しい仕様を携えた有志が、またイチからSocket使ってPort0対策して・・・なんて煩わしい事
せずに済むよう、汎用・簡易な枠組みを『ﾀﾞｳｿ住人が作る』・・・これが大事。
390 ：[名無し]さん(bin+cue).rar：03/12/25 15:57 ID:80HtREDE
>>389
> ここで出てくる様々なアイデアを、「実際に実装してみる」という段階に移行しやすい状況が欲しい。
> 新しい仕様を携えた有志が、またイチからSocket使ってPort0対策して・・・なんて煩わしい事
理想はわかるんだけどね。Port0対策にしても、どういうネットワーク構成を取るかで対策が違ってくるし、
すべての方式で使える最大公約数的な部分というのは案外少ないような気がする。
オープンソースで行くなら、先人のコードを拝借すれば済むじゃん、なんて思ってみたり。
> ここで出てくる様々なアイデアを、「実際に実装してみる」という段階に移行しやすい状況が欲しい。
> 新しい仕様を携えた有志が、またイチからSocket使ってPort0対策して・・・なんて煩わしい事
理想はわかるんだけどね。Port0対策にしても、どういうネットワーク構成を取るかで対策が違ってくるし、
すべての方式で使える最大公約数的な部分というのは案外少ないような気がする。
オープンソースで行くなら、先人のコードを拝借すれば済むじゃん、なんて思ってみたり。
391 ：[名無し]さん(bin+cue).rar：03/12/25 16:02 ID:DSbKKY8y
>>388
「隣接ノードに情報を漏らさない方式」にも通じるけど、
中継ゼロを明確に禁止するアルゴリズムがなければほとんど意味がないんだよね。
転送の効率から言えば、直接の接続が最も良いはずで、
「転送が成功した」集合の中で言えば、直接転送の割合がどうしても多くなると思う。
Muteも、公式の概念図はFreenetみたいだったけど、
どうも実際には直接転送以外ほとんど成功しないみたいだったし。
それと、転送が一段増える毎に転送効率はどんどん落ちていくけど、
匿名性に関しては、転送ゼロと転送１には大きな違いがあるが、
１以上に関しては変わらないと思う。→多段転送はムダと思う。
「隣接ノードに情報を漏らさない方式」にも通じるけど、
中継ゼロを明確に禁止するアルゴリズムがなければほとんど意味がないんだよね。
転送の効率から言えば、直接の接続が最も良いはずで、
「転送が成功した」集合の中で言えば、直接転送の割合がどうしても多くなると思う。
Muteも、公式の概念図はFreenetみたいだったけど、
どうも実際には直接転送以外ほとんど成功しないみたいだったし。
それと、転送が一段増える毎に転送効率はどんどん落ちていくけど、
匿名性に関しては、転送ゼロと転送１には大きな違いがあるが、
１以上に関しては変わらないと思う。→多段転送はムダと思う。
392 ：[名無し]さん(bin+cue).rar：03/12/25 16:23 ID:FtX2TF9b
nyの中継・転送のキモって、
「何段中継されているか、そもそも中継せず直接転送なのかは、状況によって不定」
なトコだよね？
中継段数を1固定にしたら、IP特定難度は確実に落ちるな。
7.1は中継しないらしいが・・・低確率になっただけじゃないのかね。
（確立パラメータの決定権を、47氏ひとりが握っていたのは大問題だったけど）
「何段中継されているか、そもそも中継せず直接転送なのかは、状況によって不定」
なトコだよね？
中継段数を1固定にしたら、IP特定難度は確実に落ちるな。
7.1は中継しないらしいが・・・低確率になっただけじゃないのかね。
（確立パラメータの決定権を、47氏ひとりが握っていたのは大問題だったけど）
393 ：[名無し]さん(bin+cue).rar：03/12/25 16:30 ID:DSbKKY8y
>>392
ただし、キャッシュと言うものがあることによって、
（キャッシュか元ファイルか区別が出来なければ）
そのデータが元々どこから来たのか、直接接続してるノードのユーザーが
そのデータの存在を認識してるのか、分からない状態ですからね。
特に問題は無いのではないかと。
7.1、実際に使ってて中継してます。
今ダウンリストに何も登録してない状態ですが、それだとかなりの確率で転送動作するみたいです。
ただし、キャッシュと言うものがあることによって、
（キャッシュか元ファイルか区別が出来なければ）
そのデータが元々どこから来たのか、直接接続してるノードのユーザーが
そのデータの存在を認識してるのか、分からない状態ですからね。
特に問題は無いのではないかと。
7.1、実際に使ってて中継してます。
今ダウンリストに何も登録してない状態ですが、それだとかなりの確率で転送動作するみたいです。
394 ：[名無し]さん(bin+cue).rar：03/12/25 16:31 ID:gVV4lcTY
>>386>>387
商標権や毒物規制と著作権は全く違うだろう。
部分的に同じって、
例えば2時間の映画の1時間分を他の映画からコピーして、
もう1時間を自主製作映画で埋めたものを2つ作ったとして、
それを売ったら合法と認められるだろうか？
多分変換処理を要しても法的には無意味だろう。
まぁ、前例の無い状態には持っていけるけどね。
>>389
それ、聞いた事あるよ。
ソフトとしてあるのか、構想としてあったのか分からないけど。
汎用・簡易な枠組みというと、オープンソースって事かな？
クローズドだとどうしても汎用性は落ちるよね。
商標権や毒物規制と著作権は全く違うだろう。
部分的に同じって、
例えば2時間の映画の1時間分を他の映画からコピーして、
もう1時間を自主製作映画で埋めたものを2つ作ったとして、
それを売ったら合法と認められるだろうか？
多分変換処理を要しても法的には無意味だろう。
まぁ、前例の無い状態には持っていけるけどね。
>>389
それ、聞いた事あるよ。
ソフトとしてあるのか、構想としてあったのか分からないけど。
汎用・簡易な枠組みというと、オープンソースって事かな？
クローズドだとどうしても汎用性は落ちるよね。
395 ：[名無し]さん(bin+cue).rar：03/12/25 17:38 ID:cHjxM5nJ
「こんなソースがありました」なんて紹介もどんどんやればいい。
P2PソフトやDownloadソフトを作るためなんだから、板違いでもない。
P2PソフトやDownloadソフトを作るためなんだから、板違いでもない。
396 ：[名無し]さん(bin+cue).rar：03/12/25 18:16 ID:AMbkc0B9
多段転送は無駄じゃないだろ。
転送が1つだけなら転送しているノードへの接続をしらみつぶしすれば分かってしまう。
転送が1つだけなら転送しているノードへの接続をしらみつぶしすれば分かってしまう。
397 ：[名無し]さん(bin+cue).rar：03/12/25 18:20 ID:DSbKKY8y
398 ：[名無し]さん(bin+cue).rar：03/12/25 18:21 ID:gVV4lcTY
>>396
そんな事しなくても攻撃者に中継されたらアウト。
そんな事しなくても攻撃者に中継されたらアウト。
399 ：[名無し]さん(bin+cue).rar：03/12/25 19:50 ID:FO5xN39D
また、おんなじとこ行ったり来たりか…
>>388
> 「隣接ノードに情報を漏らさない方式」にも通じるけど、
> 中継ゼロを明確に禁止するアルゴリズムがなければほとんど意味がないんだよね。
隣接ノードに情報を漏らさないんだから中継ゼロ禁止ということを明確に言ってるんでは？
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>398
もそうだし「隣接ノードに情報を漏らさない方式」もそうだが
これが匿名性の核心部分。
「隣接ノードに情報を漏らさない方式」は完璧ではないが
この難問に正面から解決案を提示している。
>>388
> 「隣接ノードに情報を漏らさない方式」にも通じるけど、
> 中継ゼロを明確に禁止するアルゴリズムがなければほとんど意味がないんだよね。
隣接ノードに情報を漏らさないんだから中継ゼロ禁止ということを明確に言ってるんでは？
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>398
もそうだし「隣接ノードに情報を漏らさない方式」もそうだが
これが匿名性の核心部分。
「隣接ノードに情報を漏らさない方式」は完璧ではないが
この難問に正面から解決案を提示している。
401 ：[名無し]さん(bin+cue).rar：03/12/25 21:39 ID:gVV4lcTY
402 ：[名無し]さん(bin+cue).rar：03/12/25 21:57 ID:FO5xN39D
>>400
ボケてたかも。了解。
>>401
ん～。受信者のＩＰなんか分かってもいいんだが、
ようは送信者（放流元）にとっての送信先が攻撃者だとまずいということだと思ってるんだが、
まずくなければ１段転送でもなんなら直でもいいわけだし。
で、どうするかを考えるのが重要ではないかと思ったりしてるわけです。
ボケてたかも。了解。
>>401
ん～。受信者のＩＰなんか分かってもいいんだが、
ようは送信者（放流元）にとっての送信先が攻撃者だとまずいということだと思ってるんだが、
まずくなければ１段転送でもなんなら直でもいいわけだし。
で、どうするかを考えるのが重要ではないかと思ったりしてるわけです。
403 ：[名無し]さん(bin+cue).rar：03/12/25 22:37 ID:3zkhPbV6
404 ：[名無し]さん(bin+cue).rar：03/12/25 22:41 ID:lZnSrNrL
405 ：[名無し]さん(bin+cue).rar：03/12/25 22:47 ID:roebqDMd
中継は見たこと無いから頻度は少なそう。
多分、中継=ポート0への中継なのでは？
多分、中継=ポート0への中継なのでは？
406 ：[名無し]さん(bin+cue).rar：03/12/25 23:09 ID:YZtMr46x
冬 厨 警 報
407 ：[名無し]さん(bin+cue).rar：03/12/25 23:55 ID:vG7HRjvB
ポート０への中継？？
確率とかわからないけど、７．１でも中継はしてるよ。
ｎｙはキー情報にＩＰ入れちゃってるから匿名性が下がるんよ。
Ｆｒｅｅｎｅｔってキーの流通とかあったっけ？
確率とかわからないけど、７．１でも中継はしてるよ。
ｎｙはキー情報にＩＰ入れちゃってるから匿名性が下がるんよ。
Ｆｒｅｅｎｅｔってキーの流通とかあったっけ？
408 ：[名無し]さん(bin+cue).rar：03/12/26 00:48 ID:6tAJs4ei
>>402
中継機能によってキャッシュを持っているのがバレても良いなら、
中継機能さえあれば直接接続でも構わないね。
どうなんだろう。
確実にnyより匿名性は下がってしまうが・・・。
匿名性云々よりも、どのような仕様にすれば法的問題をクリアできるかを考える方が
先決なんだろうか？
中継機能によってキャッシュを持っているのがバレても良いなら、
中継機能さえあれば直接接続でも構わないね。
どうなんだろう。
確実にnyより匿名性は下がってしまうが・・・。
匿名性云々よりも、どのような仕様にすれば法的問題をクリアできるかを考える方が
先決なんだろうか？
409 ：[名無し]さん(bin+cue).rar：03/12/26 00:56 ID:3d6P9h+6
違法ファイルを扱っている時点で
どうあがいてもどこかで黒になると思われ
転送や部分キャッシュについては判例がないため灰
一度判決出てみないと分からんでしょ
どうあがいてもどこかで黒になると思われ
転送や部分キャッシュについては判例がないため灰
一度判決出てみないと分からんでしょ
410 ：[名無し]さん(bin+cue).rar：03/12/26 00:58 ID:ZngyYjnu
nyの場合、キーのIPがアップ主ってわけじゃないから匿名性に問題は無い
完全キャッシュをアップしててもそこにキャッシュがあることを利用者が
把握できないでアップが意図的なものじゃないってのがnyの匿名性だからな。
完全キャッシュをアップしててもそこにキャッシュがあることを利用者が
把握できないでアップが意図的なものじゃないってのがnyの匿名性だからな。
411 ：[名無し]さん(bin+cue).rar：03/12/26 01:00 ID:ZngyYjnu
nyを発展させるとしたら、ダウンロードと言う概念をなくして、
ファイルのやりとりは全部ファイルのプッシュ。
ダウンしたいときは相手から自分にプッシュさせる。
あと、勝手に人のキャッシュにこちらのファイルを突っ込む
ことで匿名性を成り立たせるという手はあるな。
アップが自覚できなければいいわけだから。
ファイルのやりとりは全部ファイルのプッシュ。
ダウンしたいときは相手から自分にプッシュさせる。
あと、勝手に人のキャッシュにこちらのファイルを突っ込む
ことで匿名性を成り立たせるという手はあるな。
アップが自覚できなければいいわけだから。
412 ：[名無し]さん(bin+cue).rar：03/12/26 01:44 ID:9eZYYitt
>>411
「ノード情報」タブ・通信ステータスが非表示になってるだけで、大分違うな
解説サイトが、技術的な情報を分かりやすく説明していれば、それ読んだ弁護士によって
法解釈が180度変わりそうな気がするしなぁ
「ノード情報」タブ・通信ステータスが非表示になってるだけで、大分違うな
解説サイトが、技術的な情報を分かりやすく説明していれば、それ読んだ弁護士によって
法解釈が180度変わりそうな気がするしなぁ
413 ：[名無し]さん(bin+cue).rar：03/12/26 02:22 ID:6tAJs4ei
プロバイダ責任制限法があるからね。
それをいかに活用するかが鍵だと思う。
俺がnyの最大の問題点と考えているのは、キャッシュを把握できてしまう事だ。
この機能をなくせばプロバイダ責任制限法による免責は
かなり高い確率で可能だと思う。
それをいかに活用するかが鍵だと思う。
俺がnyの最大の問題点と考えているのは、キャッシュを把握できてしまう事だ。
この機能をなくせばプロバイダ責任制限法による免責は
かなり高い確率で可能だと思う。
414 ：[名無し]さん(bin+cue).rar：03/12/26 02:26 ID:boXijD7Z
質問ばっかりで悪いんだが、結局このスレは
「ファイルを○○個くらいに分割・中継すれば安全なんじゃねーか？」
「効率悪すぎ。××個で充分。」「間を取って△△個でどうだ？」
「そんなことより斬新な分割法を考えたんだが、、、」
「さんざんガイシュツ」
というやり取りをひたすら繰り返しながら神が現れて奇跡的なアイディアを
出してくれるのを待ち続けて「それだ！！！」ってな具合に仕様が決まるのを
期待するだけのスレなのか？
ファイルの転送法が違う人同士でもファイル共有できる仕組みを
考えた方が早いんじゃないのか？
要望を出しまくるスレと、実装のことないも考えないで
アイディアを出しまくるスレを分ける必要性は何？
ファイルの送受信の話ばっかりしてるけど他に議論することは無いのか？
ファイルの検索法のこととかは考えなくて大丈夫なのか？
「ファイルを○○個くらいに分割・中継すれば安全なんじゃねーか？」
「効率悪すぎ。××個で充分。」「間を取って△△個でどうだ？」
「そんなことより斬新な分割法を考えたんだが、、、」
「さんざんガイシュツ」
というやり取りをひたすら繰り返しながら神が現れて奇跡的なアイディアを
出してくれるのを待ち続けて「それだ！！！」ってな具合に仕様が決まるのを
期待するだけのスレなのか？
ファイルの転送法が違う人同士でもファイル共有できる仕組みを
考えた方が早いんじゃないのか？
要望を出しまくるスレと、実装のことないも考えないで
アイディアを出しまくるスレを分ける必要性は何？
ファイルの送受信の話ばっかりしてるけど他に議論することは無いのか？
ファイルの検索法のこととかは考えなくて大丈夫なのか？
415 ：[名無し]さん(bin+cue).rar：03/12/26 02:29 ID:boXijD7Z
訂正
×実装のことないも考えないで
○実装のことも何も考えないで
追加
法律議論は別のスレでやるんじゃなかったのか？
×実装のことないも考えないで
○実装のことも何も考えないで
追加
法律議論は別のスレでやるんじゃなかったのか？
416 ：[名無し]さん(bin+cue).rar：03/12/26 02:36 ID:6tAJs4ei
>>414
何が言いたいの？
どんな仕様にすれば良いか繰り返し議論する事に何か問題が？
検索法の事を考えるべきだと思うなら、それも議論すれば良いだろう。
法律議論は確かにスレ違いだな。
http://tmp2.2ch.net/test/read.cgi/download/1070500722/
でやるか。
何が言いたいの？
どんな仕様にすれば良いか繰り返し議論する事に何か問題が？
検索法の事を考えるべきだと思うなら、それも議論すれば良いだろう。
法律議論は確かにスレ違いだな。
http://tmp2.2ch.net/test/read.cgi/download/1070500722/
でやるか。
417 ：[名無し]さん(bin+cue).rar：03/12/26 03:07 ID:3d6P9h+6
>ファイルの転送法が違う人同士でもファイル共有できる仕組み
難しいんじゃないか?
暗号化や分割方法が違うだけならソフト側で対処できそうだけど。
難しいんじゃないか?
暗号化や分割方法が違うだけならソフト側で対処できそうだけど。
418 ：[名無し]さん(bin+cue).rar：03/12/26 04:07 ID:9eZYYitt
>>394
＞汎用・簡易な枠組みというと、オープンソースって事かな？
えっと、オープンクローズ関係なくて、アプリ開発者から見てシンプルなのか？って事。
SDLみたいにさ、CでDLL1個リンクして即サクサクAPI呼んでPureP2Pアプリ組みたいわけ。
findfirst()、findnext()、open()、close()、read()、write()
こんだけで必要十分。
Freenet・nyを筆頭に、SOBAだのGfarmだのVojtaだの新月だの26氏のだの、
P2Pインフラとしてあまりにゴテゴテし過ぎてる印象が強い。 （他の使い道が見出しにくい）
LinuxだのJavaだの移植性だのってさぁ・・・普通にCで作れよまったく
なんか無い？もっとシンプルで汎用性・応答性重視なやつ。
＞汎用・簡易な枠組みというと、オープンソースって事かな？
えっと、オープンクローズ関係なくて、アプリ開発者から見てシンプルなのか？って事。
SDLみたいにさ、CでDLL1個リンクして即サクサクAPI呼んでPureP2Pアプリ組みたいわけ。
findfirst()、findnext()、open()、close()、read()、write()
こんだけで必要十分。
Freenet・nyを筆頭に、SOBAだのGfarmだのVojtaだの新月だの26氏のだの、
P2Pインフラとしてあまりにゴテゴテし過ぎてる印象が強い。 （他の使い道が見出しにくい）
LinuxだのJavaだの移植性だのってさぁ・・・普通にCで作れよまったく
なんか無い？もっとシンプルで汎用性・応答性重視なやつ。
419 ：[名無し]さん(bin+cue).rar：03/12/26 04:47 ID:3d6P9h+6
>418
接続とかをDLLにまとめてしまうのはいいかも知れないね。
あとAPIとしてはsend()とCALLBACKProcも欲しいところ。
接続とかをDLLにまとめてしまうのはいいかも知れないね。
あとAPIとしてはsend()とCALLBACKProcも欲しいところ。
420 ：[名無し]さん(bin+cue).rar：03/12/26 05:59 ID:FCjn4n1i
隣接ノードに情報を漏らさない、発案者に質問があります。
wikiにある＜１．キー拡散段階＞
⑥ Cはこのキーを他のノードのリクエストに応じて送信する。
あるいは強制転送によりキーを拡散させる。
とありますが、この強制転送の詳しいやり方を教えてください。
②でAが取った方法と同じ方法では、Cが任意のノードに強制転送することはできません。
どのようにして強制転送するのでしょうか？
それと＜２．ファイル転送段階＞で
ダウンロード用キーのIDをDの共通鍵で暗号化していますが、
このIDは結局Dしか使用しないので意味がないと思うのですが
何か暗号化しなければならない理由があるのでしょうか？
wikiにある＜１．キー拡散段階＞
⑥ Cはこのキーを他のノードのリクエストに応じて送信する。
あるいは強制転送によりキーを拡散させる。
とありますが、この強制転送の詳しいやり方を教えてください。
②でAが取った方法と同じ方法では、Cが任意のノードに強制転送することはできません。
どのようにして強制転送するのでしょうか？
それと＜２．ファイル転送段階＞で
ダウンロード用キーのIDをDの共通鍵で暗号化していますが、
このIDは結局Dしか使用しないので意味がないと思うのですが
何か暗号化しなければならない理由があるのでしょうか？
421 ：[名無し]さん(bin+cue).rar：03/12/26 06:58 ID:PUDOvQv7
JXTAでもつかってれ
422 ：[名無し]さん(bin+cue).rar：03/12/26 08:08 ID:WQl0O1aI
>>418
自分で作れば？
自分で作れば？
423 ：[名無し]さん(bin+cue).rar：03/12/26 10:16 ID:503FBU9I
完全キャッシュの保持を隣接ノードからは調査不能にするために、ダウソしたキャッシュを外部からは最大8割程度の部分キャッシュ
のみ保持に見せかけるのはどうだろう？残り２割は別のノードからダウソして合体させる。
狙い撃ち対策にどうでしょうか？
のみ保持に見せかけるのはどうだろう？残り２割は別のノードからダウソして合体させる。
狙い撃ち対策にどうでしょうか？
424 ：[名無し]さん(bin+cue).rar：03/12/26 10:28 ID:VO84Kq5h
>>349,350を見てちょっと悲しくなったんですが、仕様を読んだ上で議論してくださっている方(>>420etc.)
もいらっしゃるようですね。ありがとうございます。
>>349
wikiにある仕様のうち少なくとも「RAID10」、「RAID3」、「隣接…」はこの問題をクリアしてます。
>>350
「隣接…」は、winnyの転送効率を保ちつつ、winnyより高い匿名性を確保することを目指しています。
>>368
ずっと気になってました。いったん開発から手を引くとのことで残念です。忙しいそうなので
無理にとは言えませんが、これまでのように各仕様の問題点の指摘だけでも続けて頂ければ幸いです。
>>420
質問の1つ目ですが、ノードCがファイルを持っていないことが保証されています。
したがって、接続している任意のノードに堂々と送りつけても問題ないと思います。
2つ目はおっしゃるとおりですね。鋭いつっこみありがとうございます（というか、私があほなだけ）。
後でwikiを修正しておきます。他にも多数の凡ミス、改善可能な点があると思うので、どんどん
ご指摘お願いします。
もいらっしゃるようですね。ありがとうございます。
>>349
wikiにある仕様のうち少なくとも「RAID10」、「RAID3」、「隣接…」はこの問題をクリアしてます。
>>350
「隣接…」は、winnyの転送効率を保ちつつ、winnyより高い匿名性を確保することを目指しています。
>>368
ずっと気になってました。いったん開発から手を引くとのことで残念です。忙しいそうなので
無理にとは言えませんが、これまでのように各仕様の問題点の指摘だけでも続けて頂ければ幸いです。
>>420
質問の1つ目ですが、ノードCがファイルを持っていないことが保証されています。
したがって、接続している任意のノードに堂々と送りつけても問題ないと思います。
2つ目はおっしゃるとおりですね。鋭いつっこみありがとうございます（というか、私があほなだけ）。
後でwikiを修正しておきます。他にも多数の凡ミス、改善可能な点があると思うので、どんどん
ご指摘お願いします。
425 ：[名無し]さん(bin+cue).rar：03/12/26 10:31 ID:VO84Kq5h
あと、「winnyで絶対転送するようにすればいい」という意見が時々出ますが、winnyの仕様
そのままでは不可能だと思います。理由は、↓ここにあるとおりですが、winnyバージョンに
直してみます。
ttp://tmp2.2ch.net/test/read.cgi/download/1071970653/571
winnyのシステムで、例えばA→B→Cとファイルを送信する場合、次のようになります。
１．Aは自分の所有するファイルの情報とIPアドレスをセットにしてキーを作製し、Bに送信する。
２．Bはある確率でキーのIPアドレスをAからBに書き換え、Cに送信する。
３．Cはファイル情報を見て、もし欲しいファイルがあれば、キー内のIPアドレスを用いて
ファイルをリクエストする。
このとき、BがIPアドレスを書き換えていればBを経由してダウンロード、書き換えていなければ
Aから直接ダウンロードになります。この仕様では、BがAのファイルをリクエストする場合、どう
やっても転送にはなりません。だからといって、AがBに「おまえは俺のファイルを落とすな」
というメッセージを送ると、Aが放流者であることがBに分かってしまい、本末転倒です。
また、たとえ転送を義務づけることができても、BとCが両方危険ノードであれば意味がありません。
Cのnoderef.txtにBを登録すると、BとCは簡単につながります。その後、同様にしてBからAに
接続し、Cからリクエストを送信すれば、転送があってもなくても同じことになります。
「隣接ノードに…」の匿名性は、「必ず転送をはさむこと」に基づいているのではありません。
その核心は、「リクエストの送信先とファイルのダウンロード先を分離したこと」と、「キーや
ファイルの転送者を放流者が選べること」です。これにより、たとえIPアドレスが記録される
掲示板で放流予告をしても、winny等のように簡単には匿名性を破ることはできません。
もちろん完璧ではありませんが。
そのままでは不可能だと思います。理由は、↓ここにあるとおりですが、winnyバージョンに
直してみます。
ttp://tmp2.2ch.net/test/read.cgi/download/1071970653/571
winnyのシステムで、例えばA→B→Cとファイルを送信する場合、次のようになります。
１．Aは自分の所有するファイルの情報とIPアドレスをセットにしてキーを作製し、Bに送信する。
２．Bはある確率でキーのIPアドレスをAからBに書き換え、Cに送信する。
３．Cはファイル情報を見て、もし欲しいファイルがあれば、キー内のIPアドレスを用いて
ファイルをリクエストする。
このとき、BがIPアドレスを書き換えていればBを経由してダウンロード、書き換えていなければ
Aから直接ダウンロードになります。この仕様では、BがAのファイルをリクエストする場合、どう
やっても転送にはなりません。だからといって、AがBに「おまえは俺のファイルを落とすな」
というメッセージを送ると、Aが放流者であることがBに分かってしまい、本末転倒です。
また、たとえ転送を義務づけることができても、BとCが両方危険ノードであれば意味がありません。
Cのnoderef.txtにBを登録すると、BとCは簡単につながります。その後、同様にしてBからAに
接続し、Cからリクエストを送信すれば、転送があってもなくても同じことになります。
「隣接ノードに…」の匿名性は、「必ず転送をはさむこと」に基づいているのではありません。
その核心は、「リクエストの送信先とファイルのダウンロード先を分離したこと」と、「キーや
ファイルの転送者を放流者が選べること」です。これにより、たとえIPアドレスが記録される
掲示板で放流予告をしても、winny等のように簡単には匿名性を破ることはできません。
もちろん完璧ではありませんが。
426 ：[名無し]さん(bin+cue).rar：03/12/26 11:12 ID:FvAlZicc
ttp://internet.watch.impress.co.jp/cda/news/2003/12/25/1624.html
コアラまで規制始めた。そのうち、全プロバイダで全滅だな。
帯域制限の機器にP2Pとして認識されない通信手段のファイル共有ソフトを考えてくれ。
コアラまで規制始めた。そのうち、全プロバイダで全滅だな。
帯域制限の機器にP2Pとして認識されない通信手段のファイル共有ソフトを考えてくれ。
427 ：[名無し]さん(bin+cue).rar：03/12/26 11:14 ID:vBywIAYH
こいうふうに多段じゃなくて多重で送れば転送入れても速いんじゃないの？
┌→B─┐
A┼→C─┼→E
└→D─┘
┌→B─┐
A┼→C─┼→E
└→D─┘
428 ：[名無し]さん(bin+cue).rar：03/12/26 12:36 ID:dIGDTT6q
>>425
そのファイルをP2Pネットワークに持ち込んだ（放流した）ユーザーと、
ファイル転送においてUP元になるユーザーというのをちゃんと分けて認識したほうが良い。
ファイル転送の元ノードであっても、無意識にキャッシュを保持しているだけのケースもある。
そこの上のほうに書かれている方法では、
ファイルのミラーが作成される前に捜査する側がその手順を実行しなければならない。
しかもそれでわかるのは、ファイル転送のUP元であるということだけ。
UPフォルダに入れられたファイルとキャッシュの区別が出来ない以上、
無意識にキャッシュを保持しているだけのケースも否定できない。
そのファイルをP2Pネットワークに持ち込んだ（放流した）ユーザーと、
ファイル転送においてUP元になるユーザーというのをちゃんと分けて認識したほうが良い。
ファイル転送の元ノードであっても、無意識にキャッシュを保持しているだけのケースもある。
そこの上のほうに書かれている方法では、
ファイルのミラーが作成される前に捜査する側がその手順を実行しなければならない。
しかもそれでわかるのは、ファイル転送のUP元であるということだけ。
UPフォルダに入れられたファイルとキャッシュの区別が出来ない以上、
無意識にキャッシュを保持しているだけのケースも否定できない。
429 ：[名無し]さん(bin+cue).rar：03/12/26 14:14 ID:UBhnZYve
既出すぎて突っ込む気も起きない。得意げにほざいているやつらよ。恥じを知れ。
430 ：[名無し]さん(bin+cue).rar：03/12/26 14:24 ID:WQl0O1aI
431 ：[名無し]さん(bin+cue).rar：03/12/26 14:26 ID:l91ZIk4F
>>427
Ａがうまくロードバランスをとりつつアップすれば、転送ノードに足を
引っ張られるケースは少なくできるかもね。
秘匿性を保ちつつ複数の転送ノードを見つけることはよりハードルが高くなるし、
中間ノードでキャッシュしづらくなるのが問題かな。
まあ、転送時にデータをキャッシュするのも匿名性の問題を抱えてるので、
転送はただの転送と割り切ってしまえば後者は問題ないのかも知れんが。
Ａがうまくロードバランスをとりつつアップすれば、転送ノードに足を
引っ張られるケースは少なくできるかもね。
秘匿性を保ちつつ複数の転送ノードを見つけることはよりハードルが高くなるし、
中間ノードでキャッシュしづらくなるのが問題かな。
まあ、転送時にデータをキャッシュするのも匿名性の問題を抱えてるので、
転送はただの転送と割り切ってしまえば後者は問題ないのかも知れんが。
432 ：[名無し]さん(bin+cue).rar：03/12/26 14:57 ID:tjMkXjlO
要望スレも沈んでしまってるようだし、これを期に何を議論するべきなのか
もう少し整理し直してスレを分けた方が良くないですか？
提案としては1.に投稿するときは2.を必ず読むこと、などとして
1. 新しいアイディアや要望を募集するスレ
2. 頻繁に出る既出のアイディアの実現可能性を検討するスレ
3. 匿名性と効率のバランスを考えるスレ
4. 合法なP2P利用法について検討するスレ
まあ今のところwikiが2.の役目を果たしてるみたいですけど、掲示板の方が
便利な部分もある気がするので。
wikiサイトの掲示板も、26氏のpre-alphaスレ以外あんまり人が居ないし、
イマイチ有効活用されてない気がするから、もっと気軽に使わせてもらっても
いいんじゃないでしょうか？
まあ厨房があふれ返っては困るのも分かるんですが。
もう少し整理し直してスレを分けた方が良くないですか？
提案としては1.に投稿するときは2.を必ず読むこと、などとして
1. 新しいアイディアや要望を募集するスレ
2. 頻繁に出る既出のアイディアの実現可能性を検討するスレ
3. 匿名性と効率のバランスを考えるスレ
4. 合法なP2P利用法について検討するスレ
まあ今のところwikiが2.の役目を果たしてるみたいですけど、掲示板の方が
便利な部分もある気がするので。
wikiサイトの掲示板も、26氏のpre-alphaスレ以外あんまり人が居ないし、
イマイチ有効活用されてない気がするから、もっと気軽に使わせてもらっても
いいんじゃないでしょうか？
まあ厨房があふれ返っては困るのも分かるんですが。
433 ：[名無し]さん(bin+cue).rar：03/12/26 15:31 ID:dIsmvu7u
↓このサイト、どこのスレで最初にリンク張られたんだ？
http://member.nifty.ne.jp/tnishita/p2p/tokumei1.html
http://member.nifty.ne.jp/tnishita/p2p/tokumei1.html
434 ：[名無し]さん(bin+cue).rar：03/12/26 15:32 ID:dIsmvu7u
h取るの忘れた。スマン
435 ：[名無し]さん(bin+cue).rar：03/12/26 16:12 ID:3d6P9h+6
>424
ちょっと聞きたいんだけどさ、
１のキー拡散段階で、AはCを狙ってAの公開鍵+upファイルの情報+共通鍵を送るんだよね。
Aは下流のノードの公開鍵しか知りえないから、下流のノードにしかキーを送れないってこと？
キーの拡散効率が凄く悪い気がするけど。
ちょっと聞きたいんだけどさ、
１のキー拡散段階で、AはCを狙ってAの公開鍵+upファイルの情報+共通鍵を送るんだよね。
Aは下流のノードの公開鍵しか知りえないから、下流のノードにしかキーを送れないってこと？
キーの拡散効率が凄く悪い気がするけど。
436 ：[名無し]さん(bin+cue).rar：03/12/26 16:46 ID:VO84Kq5h
>>435
Cのノード情報の拡散先を限定してしまうと、匿名性が低下するので、
上流、下流などは関係なく、全てのノード間で対等に拡散させるつもりです。
上流、下流を決めてキーを効率よく拡散させるのは、Cが検索用のキーを
作製した後（wikiの＜１．キー拡散段階＞の⑥）ということになります。
ただ、これについても、今夜wikiの仕様を若干変更します。
今、時間がないので。すいません。
Cのノード情報の拡散先を限定してしまうと、匿名性が低下するので、
上流、下流などは関係なく、全てのノード間で対等に拡散させるつもりです。
上流、下流を決めてキーを効率よく拡散させるのは、Cが検索用のキーを
作製した後（wikiの＜１．キー拡散段階＞の⑥）ということになります。
ただ、これについても、今夜wikiの仕様を若干変更します。
今、時間がないので。すいません。
437 ：[名無し]さん(bin+cue).rar：03/12/26 17:38 ID:OD7kcxCX
初期ノード以外のIPリストや情報キーを再起動やキーの寿命に関係なく
保持できるようにしておいた方が、クラスタ化が容易になるって言われな
てもソースを改変するやつはいるだろうけど。
保持できるようにしておいた方が、クラスタ化が容易になるって言われな
てもソースを改変するやつはいるだろうけど。
438 ：[名無し]さん(bin+cue).rar：03/12/26 19:47 ID:3d6P9h+6
>>436
上流、下流関係ないとすると、
A→B→Cの向きにもAのIPアドレス+公開鍵の情報が１．①同様に流れるてことになるよね。
Cはそうやって送られてきたIPアドレスと公開鍵をリストとして持ってるってことになるでしょ。
そこにAのデータがある場合、Gから送られてきたものを複号して得た公開鍵とこのリストを見比べることで
A(IPアドレス)がその公開鍵の持ち主（=UPした人）って特定できそうだけど。
あるいは、１．①でAがEにもCの鍵とIPを流していた場合、
Eが１．③で受け取ったとき、Eが持っている公開鍵のリストを片っ端から試せば
Cの鍵で複号できちゃう。そうなるとやっぱりAがULしたって特定できそうだよ。
時間があるときにでも見直してみてくらはい。
上流、下流関係ないとすると、
A→B→Cの向きにもAのIPアドレス+公開鍵の情報が１．①同様に流れるてことになるよね。
Cはそうやって送られてきたIPアドレスと公開鍵をリストとして持ってるってことになるでしょ。
そこにAのデータがある場合、Gから送られてきたものを複号して得た公開鍵とこのリストを見比べることで
A(IPアドレス)がその公開鍵の持ち主（=UPした人）って特定できそうだけど。
あるいは、１．①でAがEにもCの鍵とIPを流していた場合、
Eが１．③で受け取ったとき、Eが持っている公開鍵のリストを片っ端から試せば
Cの鍵で複号できちゃう。そうなるとやっぱりAがULしたって特定できそうだよ。
時間があるときにでも見直してみてくらはい。
439 ：[名無し]さん(bin+cue).rar：03/12/26 19:49 ID:3d6P9h+6
×複号
○復号
ﾊｽﾞｲﾏﾁｶﾞｲｽﾏｿ
○復号
ﾊｽﾞｲﾏﾁｶﾞｲｽﾏｿ
>>424
> したがって、接続している任意のノードに堂々と送りつけても問題ないと思います。
了解しました
隣接～は、なかなか興味深い方法ですね
実際に動作するものを作ってみたいです
C++でのライブラリ作成くらいはできますので微力ながら協力したいと思います
DLL化とかの話もあるようですが、これは良いと思います
DLL化すればUIも色々でてきて楽しそうですし…
それはそうと隣接～方式で、もう既にどなたか作成されているんでしょうか？
もうやってるのなら、今詳細な仕様書を作成してるのが無駄になりそうですが(；´Д｀)
>>438
wikiに
> 暗号には、公開鍵暗号方式と、公開鍵で共通鍵を交換する方式を併用する（part6,118氏thx）。
> ただし、検索キー（後述）に添付する公開鍵は使い捨てとする。
とあり、同じ公開鍵を使わないのでバレないと思います
> したがって、接続している任意のノードに堂々と送りつけても問題ないと思います。
了解しました
隣接～は、なかなか興味深い方法ですね
実際に動作するものを作ってみたいです
C++でのライブラリ作成くらいはできますので微力ながら協力したいと思います
DLL化とかの話もあるようですが、これは良いと思います
DLL化すればUIも色々でてきて楽しそうですし…
それはそうと隣接～方式で、もう既にどなたか作成されているんでしょうか？
もうやってるのなら、今詳細な仕様書を作成してるのが無駄になりそうですが(；´Д｀)
>>438
wikiに
> 暗号には、公開鍵暗号方式と、公開鍵で共通鍵を交換する方式を併用する（part6,118氏thx）。
> ただし、検索キー（後述）に添付する公開鍵は使い捨てとする。
とあり、同じ公開鍵を使わないのでバレないと思います
441 ：[名無し]さん(bin+cue).rar：03/12/26 20:50 ID:3d6P9h+6
旧仕様のほうか…
見落としてました。
他にも勘違い多数、438は忘れてください．
見落としてました。
他にも勘違い多数、438は忘れてください．
442 ：[名無し]さん(bin+cue).rar：03/12/26 22:42 ID:OD7kcxCX
http://www.mneme.co.jp/p_alliance/
>個人情報保護ソリューションにご興味をお持ちの企業様
>個人情報を保護する匿名P2Pネットワーク基盤プロジェクト
>- IPA平成14年・15年次世代ソフトウェア開発事業 －（PPTファイル）
だそうです。
>個人情報保護ソリューションにご興味をお持ちの企業様
>個人情報を保護する匿名P2Pネットワーク基盤プロジェクト
>- IPA平成14年・15年次世代ソフトウェア開発事業 －（PPTファイル）
だそうです。
443 ：[名無し]さん(bin+cue).rar：03/12/26 23:13 ID:whGqDAjl
>>442
ざっとみましたが、何をしたいのか良くわかりません。
＞ 目的
＞ ユーザ主権・リスク極小化を原則として個人情報の保護と活用を両立する
匿名性を保証したネットワークで個人情報を扱う？？？
P2Pベースに商取引のシステムを、とか言う狙いがあるのかもしれませんが・・・
＞個人情報漏洩という観点から
＞ 情報漏洩を防ぐことは不可能。漏洩した場合の被害を極小化するのが最善策
＞ 中央サーバ管理者は情報漏洩に対する補償問題に怯えている
＞堅牢性・スケーラビリティ・運用性という観点から
＞ 中央サーバが堅牢性・負荷集中・運用管理面でシステムの可用性を下げる
単一のサーバー上の情報漏洩に怯える無能管理者が
一旦流れてしまったら止める事の出来ないP2Pを使ってどうにかすると言うのが理解できない。
負荷集中を避けるには効果的だと思うが、運用管理面では逆効果だろ。
技術的に新しそうな事は書いてなかったように思います。
ny始め、ｶﾞｲｼｭﾂのP2Pのコピー？
厨企画な印象を持ったのは俺だけでしょうか？
ざっとみましたが、何をしたいのか良くわかりません。
＞ 目的
＞ ユーザ主権・リスク極小化を原則として個人情報の保護と活用を両立する
匿名性を保証したネットワークで個人情報を扱う？？？
P2Pベースに商取引のシステムを、とか言う狙いがあるのかもしれませんが・・・
＞個人情報漏洩という観点から
＞ 情報漏洩を防ぐことは不可能。漏洩した場合の被害を極小化するのが最善策
＞ 中央サーバ管理者は情報漏洩に対する補償問題に怯えている
＞堅牢性・スケーラビリティ・運用性という観点から
＞ 中央サーバが堅牢性・負荷集中・運用管理面でシステムの可用性を下げる
単一のサーバー上の情報漏洩に怯える無能管理者が
一旦流れてしまったら止める事の出来ないP2Pを使ってどうにかすると言うのが理解できない。
負荷集中を避けるには効果的だと思うが、運用管理面では逆効果だろ。
技術的に新しそうな事は書いてなかったように思います。
ny始め、ｶﾞｲｼｭﾂのP2Pのコピー？
厨企画な印象を持ったのは俺だけでしょうか？
444 ： ◆Fw0Kir8iYA ：03/12/26 23:21 ID:IIvl1vh5
wiki更新しました。>>420で指摘された点の修正の他、何カ所かの仕様を若干変更しました。
特に、＜Ⅱ．キー拡散段階＞の①と考察の2番目は重要なので、すでに過去の仕様を読まれている方も、
もう1度読んで頂ければ幸いです。考察の最後に読者への挑戦状を用意してありますので、
これについてもコメントお待ちしてます。
…と書いておいて申し訳ないですが、わけあって今日はもう休みます。申し訳ありません。
レスは明日、お返しします。
>>440
微力なのはプログラミングのできない私のほうです。ぜひお願いします。
この仕様については、P2P Network Service pre-alphaの作者、26氏も興味を
示してくださってますが、今は匿名掲示板の作成に追われているので、こちら
までは手が回っていないのではないかと思います。また、26氏もオープン
ソース化を念頭に開発されているので、協力者は歓迎されると思います。
特に、＜Ⅱ．キー拡散段階＞の①と考察の2番目は重要なので、すでに過去の仕様を読まれている方も、
もう1度読んで頂ければ幸いです。考察の最後に読者への挑戦状を用意してありますので、
これについてもコメントお待ちしてます。
…と書いておいて申し訳ないですが、わけあって今日はもう休みます。申し訳ありません。
レスは明日、お返しします。
>>440
微力なのはプログラミングのできない私のほうです。ぜひお願いします。
この仕様については、P2P Network Service pre-alphaの作者、26氏も興味を
示してくださってますが、今は匿名掲示板の作成に追われているので、こちら
までは手が回っていないのではないかと思います。また、26氏もオープン
ソース化を念頭に開発されているので、協力者は歓迎されると思います。
445 ：RAID5マン ◆H2RAID5./g ：03/12/26 23:50 ID:SwE/zHVU
ええとちょっと質問です。
POP鯖だとかSMTP鯖ってのはDNSで名前解決しないと通信できないもんなのかな？
IPベースで直接やり取りすれば良いような気がするんだけどメール関係は疎くて知らないのです。
いやなんでこんなこと聞くのかって言うと、どっかの記事でP2Pソフトウェアの帯域制限
をかけるISPが増えてて、その機能を実現するソフトウェアメーカの香具師が
「P2Pでも特にファイル交換類のものは"あきらかに異質な通信"をしてるから検出は簡単」
見たいなことヌカしてたので、私としてはこの話をすごく曲解してじゃぁファイル転送中継部に
SMTPとか使えばいいんじゃ？受信者はPOPとかで受け取ればいいんじゃ？て思ったからです。
別に独自の通信プロトコル作る必要もないし、これならIISインストールすればあとはバイナリ処理を
ローカルでするだけで済むじゃないかなぁと。
①アプリケーション層（独自P2P）
→検索やキー情報の受け渡しだけに使う。当然独自P2Pプロトコルとして
のデータ転送はかなりすくない。
②トランスファー層（SMTP、POP）
→メール添付ファイル形式で送受信。必ず外部のSMTP通すようにすればnyの中継と
同様の効果かも。データの通信量はいままでどおり。たぶんヘッダ分は増えると思う。
③ビルドロジック層
→添付ファイル形式で送られてきたものを復元したり、これから放流するものを分割＆メール化
する。
こんな感じでどーかな？もしもIP直でSMTP使えないならDDNS使用を前提としても良いかも。
完全な思い付きなんで激しく突っ込んでください
POP鯖だとかSMTP鯖ってのはDNSで名前解決しないと通信できないもんなのかな？
IPベースで直接やり取りすれば良いような気がするんだけどメール関係は疎くて知らないのです。
いやなんでこんなこと聞くのかって言うと、どっかの記事でP2Pソフトウェアの帯域制限
をかけるISPが増えてて、その機能を実現するソフトウェアメーカの香具師が
「P2Pでも特にファイル交換類のものは"あきらかに異質な通信"をしてるから検出は簡単」
見たいなことヌカしてたので、私としてはこの話をすごく曲解してじゃぁファイル転送中継部に
SMTPとか使えばいいんじゃ？受信者はPOPとかで受け取ればいいんじゃ？て思ったからです。
別に独自の通信プロトコル作る必要もないし、これならIISインストールすればあとはバイナリ処理を
ローカルでするだけで済むじゃないかなぁと。
①アプリケーション層（独自P2P）
→検索やキー情報の受け渡しだけに使う。当然独自P2Pプロトコルとして
のデータ転送はかなりすくない。
②トランスファー層（SMTP、POP）
→メール添付ファイル形式で送受信。必ず外部のSMTP通すようにすればnyの中継と
同様の効果かも。データの通信量はいままでどおり。たぶんヘッダ分は増えると思う。
③ビルドロジック層
→添付ファイル形式で送られてきたものを復元したり、これから放流するものを分割＆メール化
する。
こんな感じでどーかな？もしもIP直でSMTP使えないならDDNS使用を前提としても良いかも。
完全な思い付きなんで激しく突っ込んでください
446 ：[名無し]さん(bin+cue).rar：03/12/26 23:59 ID:whGqDAjl
>>445
IP直でもいけるはずです。
確かにISPの検閲をすり抜ける方法としては効果ありかもしれません。
参考になるかどうかわかりませんが、以下、某muteスレに貼られたコピペ。
某プロバイダの規制について
今回導入を決定したトラフィック制御機器は、「誰が」とか「何のファイルを」
とかを見ているわけではなく、レイア7においてトラフィックパターンの
マッチング（例えて言えば、ウィルスチェッカーやスパムフィルターみたいな
ものと似た技術）により、アプリケーション毎に分類して制御するものです。
＃例えが悪いかもしれませんが、高速道路の上り車線において、これらのアプリ
ケーションの専用車線を新たに設けただけで、その車線にどんな荷物を積んだ
車が走っているかを見ているわけではありません。
よって、Port単位の制御やIPアドレス単位（ユーザ単位）の制御ではなく、アプリ
ケーション単位の制御となりますので、「WinMX」「Winny」等のアプリケーション
をご利用になっていない場合は、一切の制御の影響を受けることはありません。
＃逆に言えば、「WinMX」「Winny」等をご利用の場合、Portを変更したり、IPアドレス
を変更してもすべて制御の対象となります。
また法に抵触するかどうかは、弊社顧問弁護士とも充分に相談しております
のでご心配には及びません。
IP直でもいけるはずです。
確かにISPの検閲をすり抜ける方法としては効果ありかもしれません。
参考になるかどうかわかりませんが、以下、某muteスレに貼られたコピペ。
某プロバイダの規制について
今回導入を決定したトラフィック制御機器は、「誰が」とか「何のファイルを」
とかを見ているわけではなく、レイア7においてトラフィックパターンの
マッチング（例えて言えば、ウィルスチェッカーやスパムフィルターみたいな
ものと似た技術）により、アプリケーション毎に分類して制御するものです。
＃例えが悪いかもしれませんが、高速道路の上り車線において、これらのアプリ
ケーションの専用車線を新たに設けただけで、その車線にどんな荷物を積んだ
車が走っているかを見ているわけではありません。
よって、Port単位の制御やIPアドレス単位（ユーザ単位）の制御ではなく、アプリ
ケーション単位の制御となりますので、「WinMX」「Winny」等のアプリケーション
をご利用になっていない場合は、一切の制御の影響を受けることはありません。
＃逆に言えば、「WinMX」「Winny」等をご利用の場合、Portを変更したり、IPアドレス
を変更してもすべて制御の対象となります。
また法に抵触するかどうかは、弊社顧問弁護士とも充分に相談しております
のでご心配には及びません。
447 ：[名無し]さん(bin+cue).rar：03/12/27 00:00 ID:p5rc0T6h
NNTPっつーのはどーだろーか・・・
RAIDマン5氏のトランスファー層で使えないのかな。
RAIDマン5氏のトランスファー層で使えないのかな。
448 ：[名無し]さん(bin+cue).rar：03/12/27 00:10 ID:1l0tWrOw
ちょっと俺の考えを書かせてもらうと、
電気通信事業法第3条(検閲の禁止)
電気通信事業者の取扱中に係る通信は、検閲してはならない。
ISPがP2Pを規制するのは上記の法律に抵触しているはず。
>>446のコピペでは例え話を持ち出して誤魔化し、弁護士と相談、と書いてありますが、
これが検閲に当たらないはずは無く、確実に違法だと思っています。
電気通信事業法第3条(検閲の禁止)
電気通信事業者の取扱中に係る通信は、検閲してはならない。
ISPがP2Pを規制するのは上記の法律に抵触しているはず。
>>446のコピペでは例え話を持ち出して誤魔化し、弁護士と相談、と書いてありますが、
これが検閲に当たらないはずは無く、確実に違法だと思っています。
449 ：RAID5マン ◆H2RAID5./g ：03/12/27 00:29 ID:buXx5qWC
>>446
レスさんきぅです。ちと明日にでも本屋で資料そろえて見ます。
muteスレのコピペの記事も確かに見かけました。あの規制が入ったときに知り合いの
通信専門のSEと話をしてたんですが、ISPで自己ネットワーク全トラフィックを調べる
のは処理量的に不可能だから、おそらく問題の"無い"アプリケーションの通信を
パターン化してシグネチャ？として登録し、適合するものはスルー、しなければ制限
というような仕組みではないかと言ってました。
なんかよくわかりませんがこの仕組みだったらCiscoのルータにちょこっと細工すれば
実現できるそうです。
ですから逆に言えばこうしたシグネチャに適合する通信をすればよいわけで、
シグネチャは処理速度のことも考えればおそらく最初の数パケットのみで判断する
でしょうからPOPやSMTPは仕組み的に言っても最適だろうなぁと妄想してます。
もしこれで制限かけられたら>>448のように「POPやSMTPは"おそらく"通信文のやりとり」
と判断せざるを得ない（検閲の禁止に抵触するから中身を確認すること自体違法）
のに制限をかけたからISPにｺﾞﾙｧすればいいかと思います。
通信量が極端に多くても、もしかしたらすんごいハイクオリティなデザインデータを
添付ファイルとして送ってるだけかも知れないじゃないですか（笑）
そしてその内容を答える義務は利用者にはないですしね～
>>447
NNTPも考えたんですけどP2Pに応用するには鯖間の同期でシャレにならない
同期転送が発生しそうなんで選択からはずしました。やり方しだいで解決でき
るかも知れないですけど、ぶっちゃけnewsdは触ったこと無いデス（ぉ
レスさんきぅです。ちと明日にでも本屋で資料そろえて見ます。
muteスレのコピペの記事も確かに見かけました。あの規制が入ったときに知り合いの
通信専門のSEと話をしてたんですが、ISPで自己ネットワーク全トラフィックを調べる
のは処理量的に不可能だから、おそらく問題の"無い"アプリケーションの通信を
パターン化してシグネチャ？として登録し、適合するものはスルー、しなければ制限
というような仕組みではないかと言ってました。
なんかよくわかりませんがこの仕組みだったらCiscoのルータにちょこっと細工すれば
実現できるそうです。
ですから逆に言えばこうしたシグネチャに適合する通信をすればよいわけで、
シグネチャは処理速度のことも考えればおそらく最初の数パケットのみで判断する
でしょうからPOPやSMTPは仕組み的に言っても最適だろうなぁと妄想してます。
もしこれで制限かけられたら>>448のように「POPやSMTPは"おそらく"通信文のやりとり」
と判断せざるを得ない（検閲の禁止に抵触するから中身を確認すること自体違法）
のに制限をかけたからISPにｺﾞﾙｧすればいいかと思います。
通信量が極端に多くても、もしかしたらすんごいハイクオリティなデザインデータを
添付ファイルとして送ってるだけかも知れないじゃないですか（笑）
そしてその内容を答える義務は利用者にはないですしね～
>>447
NNTPも考えたんですけどP2Pに応用するには鯖間の同期でシャレにならない
同期転送が発生しそうなんで選択からはずしました。やり方しだいで解決でき
るかも知れないですけど、ぶっちゃけnewsdは触ったこと無いデス（ぉ
450 ：[名無し]さん(bin+cue).rar：03/12/27 00:49 ID:vg/NwjY7
>>449
> おそらく問題の"無い"アプリケーションの通信を
> パターン化してシグネチャ？として登録し、適合するものはスルー、しなければ制限
一般的な通信には、ヘッダとセッションがあるから簡単かと。
> POP鯖だとかSMTP鯖ってのはDNSで名前解決しないと通信できないもんなのかな？
DomainNameのMXレコードから名前の解決をする。
少しマイナーなSMTP鯖は、MXレコードがない物は拒否する物もあるし。
/* SPAM防止にSMTPに制限掛けてるISPもありそうな悪寒 */
> おそらく問題の"無い"アプリケーションの通信を
> パターン化してシグネチャ？として登録し、適合するものはスルー、しなければ制限
一般的な通信には、ヘッダとセッションがあるから簡単かと。
> POP鯖だとかSMTP鯖ってのはDNSで名前解決しないと通信できないもんなのかな？
DomainNameのMXレコードから名前の解決をする。
少しマイナーなSMTP鯖は、MXレコードがない物は拒否する物もあるし。
/* SPAM防止にSMTPに制限掛けてるISPもありそうな悪寒 */
451 ：[名無し]さん(bin+cue).rar：03/12/27 00:58 ID:FwJzMH59
452 ：[名無し]さん(bin+cue).rar：03/12/27 01:08 ID:p5rc0T6h
>>449
そうだ・・・
NNTPには全鯖同期があるんだった・・・
トランスファー層で送られるのは分割＆暗号化されたふぁいる？
>>451
時代は逆行しWEB割れへ・・・ｗ
WEBのストレージ共有だと目を誤魔化せないか・・・。
そうだ・・・
NNTPには全鯖同期があるんだった・・・
トランスファー層で送られるのは分割＆暗号化されたふぁいる？
>>451
時代は逆行しWEB割れへ・・・ｗ
WEBのストレージ共有だと目を誤魔化せないか・・・。
453 ：[名無し]さん(bin+cue).rar：03/12/27 01:37 ID:Ppp5IZAb
SMTP案だけど、メール鯖はメールにIPをくっつけて下さるので
データの送信元がバレバレだと思います。
あと、外部（yahooとかhotmailとか）使うなら垢取らないと無理ですし。
P2PソフトにSMTP鯖機能を付けると鯖立て禁止のISPではキツイかも？
データの送信元がバレバレだと思います。
あと、外部（yahooとかhotmailとか）使うなら垢取らないと無理ですし。
P2PソフトにSMTP鯖機能を付けると鯖立て禁止のISPではキツイかも？
454 ：[名無し]さん(bin+cue).rar：03/12/27 03:19 ID:sXTTsug1
455 ：[名無し]さん(bin+cue).rar：03/12/27 03:25 ID:Sieby77k
とりあえずアプリの紹介記事を規制することから考えて欲しい。
今のp2p紹介記事・攻略w本は害悪にしかならん
今のp2p紹介記事・攻略w本は害悪にしかならん
456 ：[名無し]さん(bin+cue).rar：03/12/27 03:27 ID:sXTTsug1
457 ：[名無し]さん(bin+cue).rar：03/12/27 08:27 ID:Rr3ZJf2X
今までの流れ、空気が読めない奴>>455
458 ：[名無し]さん(bin+cue).rar：03/12/27 08:35 ID:5+C4Qaxj
>>448
検閲は行政がやると違法になるがISPでは検閲と言わない
検閲は行政がやると違法になるがISPでは検閲と言わない
459 ：[名無し]さん(bin+cue).rar：03/12/27 09:24 ID:1l0tWrOw
>>458
嘘つけ。
電話でもNTTが細工して繋いだり繋がなかったりしたら大問題だろ。
>>450>>453
RAID5マンさんの案はあくまでパケットをPOP3、SMTPと同じ形式にするということで、
（本気でIIS使うならまた話は別だけど）
既存のDaemon/Clientがどんな仕様になっているかってのは関係ないんじゃないですかね。
その辺りの動作は
＞①アプリケーション層（独自P2P）
にて、独自開発の部分が担えばいいだけなので。
嘘つけ。
電話でもNTTが細工して繋いだり繋がなかったりしたら大問題だろ。
>>450>>453
RAID5マンさんの案はあくまでパケットをPOP3、SMTPと同じ形式にするということで、
（本気でIIS使うならまた話は別だけど）
既存のDaemon/Clientがどんな仕様になっているかってのは関係ないんじゃないですかね。
その辺りの動作は
＞①アプリケーション層（独自P2P）
にて、独自開発の部分が担えばいいだけなので。
460 ：[名無し]さん(bin+cue).rar：03/12/27 10:02 ID:XVq6beJb
>>446
関係ないかもしれないが、管理側の人が集まって
SoftEtherの検出について話してますよ
ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?mode=viewtopic&topic=8345&forum=14&start=60
関係ないかもしれないが、管理側の人が集まって
SoftEtherの検出について話してますよ
ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?mode=viewtopic&topic=8345&forum=14&start=60
461 ：RAID5マン（トリップ家に忘れた）：03/12/27 10:36 ID:/XUdLMm7
>>459さんフォローさんくす。
本気でIISでメール添付とか検討してるわけじゃないです。
帯域制限の話が最近ちらほら聞かれるようになったから回避策の
検討のために話題にしただけです。
"外部のSMTP鯖の使用"て表現は激しく誤解を招いたようですが
P2PサーバントにSMTPとかPOPの機能を持たせて、"外部のノード"
のSMTPを使うってことです。ISPの鯖のことじゃないです。
まぁどっちにしても興味本位の思い付きを話題にしたんですが
ファイル転送と制御に同一プロトコルを用いる必要は無いんじゃ
ない？ってのが趣旨です
本気でIISでメール添付とか検討してるわけじゃないです。
帯域制限の話が最近ちらほら聞かれるようになったから回避策の
検討のために話題にしただけです。
"外部のSMTP鯖の使用"て表現は激しく誤解を招いたようですが
P2PサーバントにSMTPとかPOPの機能を持たせて、"外部のノード"
のSMTPを使うってことです。ISPの鯖のことじゃないです。
まぁどっちにしても興味本位の思い付きを話題にしたんですが
ファイル転送と制御に同一プロトコルを用いる必要は無いんじゃ
ない？ってのが趣旨です
462 ：[名無し]さん(bin+cue).rar：03/12/27 12:46 ID:L2p4YJsk
>>460
検出の仕方について論議してるんでなくて、管理者が作者批判してるだけやん。
検出の仕方について論議してるんでなくて、管理者が作者批判してるだけやん。
463 ：[名無し]さん(bin+cue).rar：03/12/27 12:47 ID:L2p4YJsk
>>444
なるほど、まだファイル共有の実装までは行ってないということですね
とりあえずこのまま仕様書の作成を続行します
んで、またまた質問です
キーの拡散ですが、Ⅱの①でC側からは、ほしいファイルの名前とか
ファイルのハッシュとかは指定できないのですか？
自分の希望のファイルを見つける方法の詳細が知りたいです
もしこちらからは何も指定できないとなると、自分のノードへ勝手に送信されてきた
キーからしか検索できませんが、それだと希望のファイルが見つかる確率が減りそうです
逆に、指定できるとすれば、匿名性の方は大丈夫か？
という問題もありそうですが、この辺の詳細が知りたいです
それと、現状の方法ではファイルキーに含める "AのUPファイル情報" は
1つのUPファイル情報しか入れないという認識でOKでしょうか？
そのUPファイル情報を使い捨ての公開鍵で暗号化するということですよね？
つまり、1つの公開鍵で1つのファイルのキーを作成することになります
ここでちょっと気になったのですが、
公開鍵方式というのは非常に処理時間がかかる暗号方式と聞きます
(私は暗号化とかには疎いのでこの辺のことはさっぱりわかりません)
ファイルキー1つ(約100byte)を作るのにどれほど時間がかかるのか
Crypto++を使って時間を計測しようと思ったんですが、
使い方がさっぱり分かりませんでした＿|￣|○
Crypto++での暗号化の一連の手順を説明してあるところとか誰か知りませんか？
なるほど、まだファイル共有の実装までは行ってないということですね
とりあえずこのまま仕様書の作成を続行します
んで、またまた質問です
キーの拡散ですが、Ⅱの①でC側からは、ほしいファイルの名前とか
ファイルのハッシュとかは指定できないのですか？
自分の希望のファイルを見つける方法の詳細が知りたいです
もしこちらからは何も指定できないとなると、自分のノードへ勝手に送信されてきた
キーからしか検索できませんが、それだと希望のファイルが見つかる確率が減りそうです
逆に、指定できるとすれば、匿名性の方は大丈夫か？
という問題もありそうですが、この辺の詳細が知りたいです
それと、現状の方法ではファイルキーに含める "AのUPファイル情報" は
1つのUPファイル情報しか入れないという認識でOKでしょうか？
そのUPファイル情報を使い捨ての公開鍵で暗号化するということですよね？
つまり、1つの公開鍵で1つのファイルのキーを作成することになります
ここでちょっと気になったのですが、
公開鍵方式というのは非常に処理時間がかかる暗号方式と聞きます
(私は暗号化とかには疎いのでこの辺のことはさっぱりわかりません)
ファイルキー1つ(約100byte)を作るのにどれほど時間がかかるのか
Crypto++を使って時間を計測しようと思ったんですが、
使い方がさっぱり分かりませんでした＿|￣|○
Crypto++での暗号化の一連の手順を説明してあるところとか誰か知りませんか？
465 ：[名無し]さん(bin+cue).rar：03/12/27 16:51 ID:6IdvZf9g
ここ、読んでるだけで勉強になる。
みなさんありがとう。
それとがんばって。
みなさんありがとう。
それとがんばって。
>>464
やはり仕様書を作成されている方の質問は、具体性がありますね。
＞それと、現状の方法ではファイルキーに含める "AのUPファイル情報" は
＞1つのUPファイル情報しか入れないという認識でOKでしょうか？
ここはずっと悩んでいるところなので、今までごまかして書いていました。
暗号鍵の容量は決して小さくはないので、可能であれば「複数のファイルにキー1つ」
にしたいと思っているんですが、そうするとダミー情報を混ぜる時（wikiの考察２）
に不都合が出ます。なので、「キー1つにつきファイル1つ」でお願いします。
＞自分の希望のファイルを見つける方法の詳細が知りたいです
実際に検索を行うのは、段階Ⅲです。
いろんなノードが段階Ⅱを行っていると考えてください。
今、CがAのファイル情報を知るためにA→E→G→Cと転送を行ったのと
同じようにD→C→BとかF→A→E→Gとかで同じ処理を行うと、
BにはDの、GにはFの所有するファイルが分かります。
そして、DやGはⅡ-⑥で、Cにファイル情報を教えます。
これでCは、AだけでなくDとFの所有するファイルも検索できます。
実際にはこれをネットワーク全体で行うので、Cは全てのノードの
持つファイルを検索できます。
>>RAID5マン氏
SMTPの利用で帯域制限がなくなるのであれば、非常に有用なアイデアですね。
「隣接ノード…」でもSMTPの利用は可能ではないかと思うのですが、いかがでしょうか?
やはり仕様書を作成されている方の質問は、具体性がありますね。
＞それと、現状の方法ではファイルキーに含める "AのUPファイル情報" は
＞1つのUPファイル情報しか入れないという認識でOKでしょうか？
ここはずっと悩んでいるところなので、今までごまかして書いていました。
暗号鍵の容量は決して小さくはないので、可能であれば「複数のファイルにキー1つ」
にしたいと思っているんですが、そうするとダミー情報を混ぜる時（wikiの考察２）
に不都合が出ます。なので、「キー1つにつきファイル1つ」でお願いします。
＞自分の希望のファイルを見つける方法の詳細が知りたいです
実際に検索を行うのは、段階Ⅲです。
いろんなノードが段階Ⅱを行っていると考えてください。
今、CがAのファイル情報を知るためにA→E→G→Cと転送を行ったのと
同じようにD→C→BとかF→A→E→Gとかで同じ処理を行うと、
BにはDの、GにはFの所有するファイルが分かります。
そして、DやGはⅡ-⑥で、Cにファイル情報を教えます。
これでCは、AだけでなくDとFの所有するファイルも検索できます。
実際にはこれをネットワーク全体で行うので、Cは全てのノードの
持つファイルを検索できます。
>>RAID5マン氏
SMTPの利用で帯域制限がなくなるのであれば、非常に有用なアイデアですね。
「隣接ノード…」でもSMTPの利用は可能ではないかと思うのですが、いかがでしょうか?
また初歩的なミスしてました＿|￣|○
wikiの＜Ⅲ．ファイル転送段階＞を若干更新。
リクエストIDをAの公開鍵で暗号化するのを忘れてました。
連カキ失礼。
wikiの＜Ⅲ．ファイル転送段階＞を若干更新。
リクエストIDをAの公開鍵で暗号化するのを忘れてました。
連カキ失礼。
>>466
> やはり仕様書を作成されている方の質問は、具体性がありますね。
これからも細かいところとか重箱の隅つつきするかもしれませんがよろしくです
> 「キー1つにつきファイル1つ」でお願いします。
了解しました
以前のwikiの説明だと、複数のファイル情報を入れるものだと思ってました
やっぱり 1ファイル＝1公開鍵 だと鍵の容量とか問題になりますね
鍵の容量はECC(楕円曲線暗号)だと160bit(20byte)程度でかなりの強度を
持つらしいですから、ECCならこの問題はクリアできそうです
が、相変わらずどうやってCrypto++で暗号化するのか分かりません
情けないプログラマですみません
> 実際に検索を行うのは、段階Ⅲです。
なるほど、了解しました
また何か質問とかあったら書きますね
> やはり仕様書を作成されている方の質問は、具体性がありますね。
これからも細かいところとか重箱の隅つつきするかもしれませんがよろしくです
> 「キー1つにつきファイル1つ」でお願いします。
了解しました
以前のwikiの説明だと、複数のファイル情報を入れるものだと思ってました
やっぱり 1ファイル＝1公開鍵 だと鍵の容量とか問題になりますね
鍵の容量はECC(楕円曲線暗号)だと160bit(20byte)程度でかなりの強度を
持つらしいですから、ECCならこの問題はクリアできそうです
が、相変わらずどうやってCrypto++で暗号化するのか分かりません
情けないプログラマですみません
> 実際に検索を行うのは、段階Ⅲです。
なるほど、了解しました
また何か質問とかあったら書きますね
469 ：[名無し]さん(bin+cue).rar：03/12/27 20:33 ID:PIgbexun
要望スレがみあたらないので仕様スレに書いちゃいます。
トリップを一歩進めて、電子署名までいって欲しい。
署名からの検索も出来るようになればなおうれしい。
トリップを一歩進めて、電子署名までいって欲しい。
署名からの検索も出来るようになればなおうれしい。
470 ：[名無し]さん(bin+cue).rar：03/12/27 22:17 ID:LOuXOjJC
471 ：[名無し]さん(bin+cue).rar：03/12/27 23:18 ID:OyNGFmur
nyでﾀｲｰﾎが出たのは結局、実際には中継率が低かったからだと思うよ。
つまり、P to P to P が少なく、ほとんどは P to P じゃなかったかな。
47氏はテストでの通信効率を上げるために、仕方なく中継率を下げたんじゃないかなあ。
つまり、P to P to P が少なく、ほとんどは P to P じゃなかったかな。
47氏はテストでの通信効率を上げるために、仕方なく中継率を下げたんじゃないかなあ。
472 ：[名無し]さん(bin+cue).rar：03/12/27 23:31 ID:jf8Tgi1y
473 ：[名無し]さん(bin+cue).rar：03/12/27 23:45 ID:Rr3ZJf2X
474 ：[名無し]さん(bin+cue).rar：03/12/27 23:47 ID:1CHIlUVD
スルー汁。
475 ：[名無し]さん(bin+cue).rar：03/12/28 00:21 ID:kxziYVT7
みそ汁
476 ：[名無し]さん(bin+cue).rar：03/12/28 01:09 ID:x/2PTJ+v
【ゴールデンレス】
このレスを見た人はコピペでもいいので10分以内に3つのスレへ貼り付けてください。
そうすれば１４日後好きな人から告白されるわ宝くじは当たるわ出世しまくるわ体の悪い所全部治るわでえらい事です
このレスを見た人はコピペでもいいので10分以内に3つのスレへ貼り付けてください。
そうすれば１４日後好きな人から告白されるわ宝くじは当たるわ出世しまくるわ体の悪い所全部治るわでえらい事です
>>470
鍵の生成にも時間が結構かかるのですか
高速なアルゴリズムというのは富士通研究所が作成したソフトのことですか？
ぐぐったらこんなとこがでてきましたが…
ttps://www.netsecurity.ne.jp/article/1/109.html
ttp://www.labs.fujitsu.com/freesoft/modularpoly/
いったいどういうものなんでしょうかこれ
まぁ暗号化に関してはあとからどうにでもなるので
アルゴリズム自体の強度だとか、鍵の長さ・強度、処理速度とかは
暗号学に詳しいエロイ人にまかせたいと思います
Crypto++の使い方も分からないし、私には向いてないようです＿|￣|○
鍵の生成にも時間が結構かかるのですか
高速なアルゴリズムというのは富士通研究所が作成したソフトのことですか？
ぐぐったらこんなとこがでてきましたが…
ttps://www.netsecurity.ne.jp/article/1/109.html
ttp://www.labs.fujitsu.com/freesoft/modularpoly/
いったいどういうものなんでしょうかこれ
まぁ暗号化に関してはあとからどうにでもなるので
アルゴリズム自体の強度だとか、鍵の長さ・強度、処理速度とかは
暗号学に詳しいエロイ人にまかせたいと思います
Crypto++の使い方も分からないし、私には向いてないようです＿|￣|○
478 ： ◆Fw0Kir8iYA ：03/12/28 13:49 ID:6iRGlmmv
またまたwikiを更新しました。
・ノードEやFとして、あらかじめ接続しているノードは選ばない
・相手から接続してきた場合、ノード情報（各ノードのIPアドレス、公開鍵）を受け取らない
の2つの条件を加えました。
変更点は、wikiの「基本的な仕様、初期条件」、「Ⅱ-①,②」、「Ⅲ-⑤」、「考察５」
ですが、それほど大きな変更ではないので、すでに読んでいる方は、wikiまで
読む必要はないと思います。たびたび更新して申し訳ありません。
>>477
オープンソースが前提なら、転送処理の部分だけ作成し、暗号化部分はほかの人に
任せるのも1つのアイデアですね。お手伝いできず申し訳ないんですが、せめて
応援だけ。がんばってください。
あと、26氏もそろそろ開発に着手しているかもしれません。よろしければ、p2p network
serviceの掲示板もご覧になってください。
・ノードEやFとして、あらかじめ接続しているノードは選ばない
・相手から接続してきた場合、ノード情報（各ノードのIPアドレス、公開鍵）を受け取らない
の2つの条件を加えました。
変更点は、wikiの「基本的な仕様、初期条件」、「Ⅱ-①,②」、「Ⅲ-⑤」、「考察５」
ですが、それほど大きな変更ではないので、すでに読んでいる方は、wikiまで
読む必要はないと思います。たびたび更新して申し訳ありません。
>>477
オープンソースが前提なら、転送処理の部分だけ作成し、暗号化部分はほかの人に
任せるのも1つのアイデアですね。お手伝いできず申し訳ないんですが、せめて
応援だけ。がんばってください。
あと、26氏もそろそろ開発に着手しているかもしれません。よろしければ、p2p network
serviceの掲示板もご覧になってください。
>>478
26氏の作成されたソフトを見てきました
なんというか…私のやることはあるの？
みたいな感じでしたｗ
ちょっとさわっただけですがかなり良い感じですね
すでにファイルの共有もできてるみたいです
(1MB未満のファイルのみ共有可能？)
これが完全に隣接～の仕様に準拠しているのか気になりますね
今26氏はどこにいるんでしょう？
なんかP2P掲示板に潜り込まれているようなんですがｗ
> オープンソースが前提なら、転送処理の部分だけ作成し、
> 暗号化部分はほかの人に任せるのも1つのアイデアですね。
とりあえずそのようにしようと思います
まぁいつかは暗号化処理もできるようになると思います
26氏の作成されたソフトを見てきました
なんというか…私のやることはあるの？
みたいな感じでしたｗ
ちょっとさわっただけですがかなり良い感じですね
すでにファイルの共有もできてるみたいです
(1MB未満のファイルのみ共有可能？)
これが完全に隣接～の仕様に準拠しているのか気になりますね
今26氏はどこにいるんでしょう？
なんかP2P掲示板に潜り込まれているようなんですがｗ
> オープンソースが前提なら、転送処理の部分だけ作成し、
> 暗号化部分はほかの人に任せるのも1つのアイデアですね。
とりあえずそのようにしようと思います
まぁいつかは暗号化処理もできるようになると思います
480 ：[名無し]さん(bin+cue).rar：03/12/28 17:04 ID:b9EU8MqQ
26氏は実家に帰りました
[36] zRl0 ：26◆26Iim/mUZlZp1w ：2003/12/28 14:37:17
pre-alpha.17.3です。
いろいろ細かいところを変更しました。
スレ立てはスレ管理から行います。
キーボードショートカットにも一応対応。
時間がないので、これくらいです。
今日から実家に帰るので今年の更新は終わりです。
皆さんよいお年をお迎え下さい。
[36] zRl0 ：26◆26Iim/mUZlZp1w ：2003/12/28 14:37:17
pre-alpha.17.3です。
いろいろ細かいところを変更しました。
スレ立てはスレ管理から行います。
キーボードショートカットにも一応対応。
時間がないので、これくらいです。
今日から実家に帰るので今年の更新は終わりです。
皆さんよいお年をお迎え下さい。
482 ：[名無し]さん(bin+cue).rar：03/12/29 03:32 ID:rIK8iy5R
キャッシュをNY互換かNYから低性能パソでもすぐ変換できるなら乗り換えがスムーズになると思われ。
むしろそうしないとよっぽどのことがない限り乗り換えいないと思う。
むしろそうしないとよっぽどのことがない限り乗り換えいないと思う。
483 ：[名無し]さん(bin+cue).rar：03/12/29 03:57 ID:ozDjXy5/
どうでもいいことで age んな。
そんなもんはモノができてから考えればいいし、このスレの開発者が面倒見ることじゃ
ない。
あと、そうして欲しいなら ny のキャッシュ構造の解析資料出してくれ。
そんなもんはモノができてから考えればいいし、このスレの開発者が面倒見ることじゃ
ない。
あと、そうして欲しいなら ny のキャッシュ構造の解析資料出してくれ。
484 ：[名無し]さん(bin+cue).rar：03/12/29 04:03 ID:rIK8iy5R
>>483
いちいち空白開けるな
いちいち空白開けるな
485 ： ◆Fw0Kir8iYA ：03/12/29 04:14 ID:ehYcO1Km
某匿名掲示板で非常に鋭い指摘を受けたので、wiki更新しました。
wikiに更新履歴をつけておいたので、変更点についてはそちらを参照してください。
420氏、たびたびの仕様変更、ほんとにごめんなさい。
それと、もしよろしければ、あちらの掲示板で私が立てたスレをご覧ください。
今回の仕様変更の経緯がわかります。
wikiに更新履歴をつけておいたので、変更点についてはそちらを参照してください。
420氏、たびたびの仕様変更、ほんとにごめんなさい。
それと、もしよろしければ、あちらの掲示板で私が立てたスレをご覧ください。
今回の仕様変更の経緯がわかります。
>>485
仕様変更はバンバンしてもらっていいですよん
匿名性に穴があるままプログラム全部作っちゃったら
後から変更するのが大変になる場合もあるので、
仕様書を作成している今のうちにできるだけ完璧な
方向を目指してもらいたいです
仕様変更はバンバンしてもらっていいですよん
匿名性に穴があるままプログラム全部作っちゃったら
後から変更するのが大変になる場合もあるので、
仕様書を作成している今のうちにできるだけ完璧な
方向を目指してもらいたいです
487 ：[名無し]さん(bin+cue).rar：03/12/29 10:37 ID:rmt8gURu
>>479
26氏の制作されたP2PBBSは「隣接ノード～」の仕様を使っていませんよ。
いずれ制作される予定のファイル共有部分でその仕様を使うみたいです。
26氏が「隣接ノード～」の原案者らしいですし。（Part5の514）
26氏の制作されたP2PBBSは「隣接ノード～」の仕様を使っていませんよ。
いずれ制作される予定のファイル共有部分でその仕様を使うみたいです。
26氏が「隣接ノード～」の原案者らしいですし。（Part5の514）
488 ：[名無し]さん(bin+cue).rar：03/12/29 11:07 ID:ehYcO1Km
489 ： ◆Fw0Kir8iYA ：03/12/29 11:16 ID:ehYcO1Km
というわけで追加しました。
それから、申し訳ないですが、都合により年内の更新は
これで終了します。皆さん、よいお年を。
それから、申し訳ないですが、都合により年内の更新は
これで終了します。皆さん、よいお年を。
490 ：[名無し]さん(bin+cue).rar：03/12/29 11:28 ID:Nn7wr+jd
>>487-488
そうだったんですか
最近このスレを見始めたので
誰がどういうことをしているのかさっぱりです
他にもなんか変な誤解とかしてたらごめんなさい
> いずれ制作される予定のファイル共有部分でその仕様を使うみたいです。
了解しました
> というわけで追加しました。
> それから、申し訳ないですが、都合により年内の更新は
> これで終了します。皆さん、よいお年を。
おつかれさまです、◆Fw0Kir8iYAさんも良いお年をお迎えください
そうだったんですか
最近このスレを見始めたので
誰がどういうことをしているのかさっぱりです
他にもなんか変な誤解とかしてたらごめんなさい
> いずれ制作される予定のファイル共有部分でその仕様を使うみたいです。
了解しました
> というわけで追加しました。
> それから、申し訳ないですが、都合により年内の更新は
> これで終了します。皆さん、よいお年を。
おつかれさまです、◆Fw0Kir8iYAさんも良いお年をお迎えください
492 ：[名無し]さん(bin+cue).rar：03/12/29 11:44 ID:LR0nysHk
>>199 で、「隣接～方式」について「帯域の無駄が多すぎる」などとケチをつけた者です。
新しい仕様をよく読みなおしてみたところ、確かに「中継で残ったキャッシュが再利用される」ことと
「中継者が中継したキャッシュの内容を（偶然に頼らずには）知りえない」ことが
両立されていることが理解できました。
現在では、十分な効率と匿名性を備えているものと認識を改めています。
気になった点をいくつか書きます。
1) キャッシュ保持者は高確率でダウンロード者である
現在の仕様だと、純粋な転送でキャッシュを保持するノードはＦＨの２つだけです
（数が変動することは理解しています）。しかしそれ以外のキャッシュ保持ノードは、
放流ノードか、または積極的にダウンロードを行ったノードかのいずれかです。
十分に拡散したキャッシュの場合、キャッシュ保持者はほぼ確実にキャッシュの内容に
責任があることになります。
これを解決するためには、IV の段階で「キャッシュ検索キー」を流通させるとき、
Winny と同じ方式で途中のノードがキー内のＩＰアドレスを自ノードのものに書き換え、
代理でリクエストを受け、中継した内容をキャッシュするようにする必要があると思われます。
新しい仕様をよく読みなおしてみたところ、確かに「中継で残ったキャッシュが再利用される」ことと
「中継者が中継したキャッシュの内容を（偶然に頼らずには）知りえない」ことが
両立されていることが理解できました。
現在では、十分な効率と匿名性を備えているものと認識を改めています。
気になった点をいくつか書きます。
1) キャッシュ保持者は高確率でダウンロード者である
現在の仕様だと、純粋な転送でキャッシュを保持するノードはＦＨの２つだけです
（数が変動することは理解しています）。しかしそれ以外のキャッシュ保持ノードは、
放流ノードか、または積極的にダウンロードを行ったノードかのいずれかです。
十分に拡散したキャッシュの場合、キャッシュ保持者はほぼ確実にキャッシュの内容に
責任があることになります。
これを解決するためには、IV の段階で「キャッシュ検索キー」を流通させるとき、
Winny と同じ方式で途中のノードがキー内のＩＰアドレスを自ノードのものに書き換え、
代理でリクエストを受け、中継した内容をキャッシュするようにする必要があると思われます。
493 ：[名無し]さん(bin+cue).rar：03/12/29 11:44 ID:LR0nysHk
2) 放流者Ａがユニークな特性を持つことへの懸念
現在の仕様だと放流者Ａだけが暗号化した状態でファイル名を含んだ情報を発信しており、
これが放流者だけが持つ特徴となってしまっています。
これを使って放流者Ａを特定する簡便な手段は思いつきません。しかし、元放流者が
ユニークな特徴を持つことは危険なのではないかと思います。
これについては、Ｃの立場にあるノードが、気まぐれにＡと同じ形式でキーを拡散するように
すればよいと思われます。
また、十分にファイル名を含んだキー情報が拡散したら、自ノードはキー情報を消し、
単なる中継者と同じ立場に変化するようにするという手も有効ではないでしょうか。
3) 呼び名について
「隣接ノードに情報を漏らさない」という名前ですが、長すぎです(w
「隣接秘匿形式」とか、もうちょっと簡潔な名前にならないものでしょうか。
いや、別にこだわりがあるならいいんですが。
現在の仕様だと放流者Ａだけが暗号化した状態でファイル名を含んだ情報を発信しており、
これが放流者だけが持つ特徴となってしまっています。
これを使って放流者Ａを特定する簡便な手段は思いつきません。しかし、元放流者が
ユニークな特徴を持つことは危険なのではないかと思います。
これについては、Ｃの立場にあるノードが、気まぐれにＡと同じ形式でキーを拡散するように
すればよいと思われます。
また、十分にファイル名を含んだキー情報が拡散したら、自ノードはキー情報を消し、
単なる中継者と同じ立場に変化するようにするという手も有効ではないでしょうか。
3) 呼び名について
「隣接ノードに情報を漏らさない」という名前ですが、長すぎです(w
「隣接秘匿形式」とか、もうちょっと簡潔な名前にならないものでしょうか。
いや、別にこだわりがあるならいいんですが。
494 ：[名無し]さん(bin+cue).rar：03/12/29 12:00 ID:LR0nysHk
495 ：[名無し]さん(bin+cue).rar：03/12/29 12:23 ID:wkyYYsTd
>>494
そう
そう
496 ：[名無し]さん(bin+cue).rar：03/12/29 12:51 ID:LR0nysHk
>>495
ありがとうございます、早速インスコして見に行ってみます。
ありがとうございます、早速インスコして見に行ってみます。
497 ：[名無し]さん(bin+cue).rar：03/12/29 15:08 ID:0Ux4FSNo
498 ：[名無し]さん(bin+cue).rar：03/12/30 02:51 ID:c9otF3C0
>>497
空気嫁
空気嫁
499 ：[名無し]さん(bin+cue).rar：03/12/30 03:17 ID:EuDogbrF
帯域制限がうまくいかねえ(三日目)。転送テストばっかり行っている今日近頃。
どこかに匿名性の高いHP公開方法はないだろうか。近日公開したいと思っている。
故47の二の舞だけは御免だ。
どこかに匿名性の高いHP公開方法はないだろうか。近日公開したいと思っている。
故47の二の舞だけは御免だ。
500 ：[名無し]さん(bin+cue).rar：03/12/30 04:05 ID:j1cQmewr
nyに流せば。
501 ：[名無し]さん(bin+cue).rar：03/12/30 05:15 ID:ud0ZG0fx
502 ：[名無し]さん(bin+cue).rar：03/12/30 06:45 ID:vcGaiEY+
匿名性を気にしてるならFreenetを知らないはずは無いと思うんだが。
HP公開にこだわるなら自宅以外からうｐしないと駄目。
つーかこんな所で聞いてる時点でだめぽ。
HP公開にこだわるなら自宅以外からうｐしないと駄目。
つーかこんな所で聞いてる時点でだめぽ。
503 ：[名無し]さん(bin+cue).rar：03/12/30 10:52 ID:sHg9/I8N
499氏のツール → 個人情報ダダ漏れ
504 ：[名無し]さん(bin+cue).rar：03/12/30 13:11 ID:2hF1LOBx
別に今の段階でIP取られたって問題あるまい。
まさか警察もブラックリストに載せるから個人情報を寄越せなどとは言わないだろうし。
公開するときに気を付ければ大丈夫だ。
まさか警察もブラックリストに載せるから個人情報を寄越せなどとは言わないだろうし。
公開するときに気を付ければ大丈夫だ。
505 ：[名無し]さん(bin+cue).rar：03/12/30 21:29 ID:eb0jZcpN
落ちているのでage
506 ：[名無し]さん(bin+cue).rar：03/12/30 21:33 ID:FMI+k2AJ
ܲ
507 ：[名無し]さん(bin+cue).rar：03/12/30 23:09 ID:x2ojC3IU
508 ：[名無し]さん(bin+cue).rar：03/12/30 23:44 ID:eVQc0LaK
509 ：[名無し]さん(bin+cue).rar：03/12/31 12:01 ID:/bU6M3TU
nyで1G超のファイルが分割うｐされてる状況を見ても
キャッシュでファイル分割を自動的にさせる機能は必
要かどうかは分からない。
ファイ分割結合ソフトは外部あればいい気もするし・・・
キャッシュでファイル分割を自動的にさせる機能は必
要かどうかは分からない。
ファイ分割結合ソフトは外部あればいい気もするし・・・
510 ：[名無し]さん(bin+cue).rar：03/12/31 16:15 ID:9ocT5jX1
>>509
何言ってんの？
何言ってんの？
511 ：[名無し]さん(bin+cue).rar：03/12/31 16:17 ID:jhsapOw6
>>509
機械翻訳？変なところで改行してるし。
機械翻訳？変なところで改行してるし。
512 ：[名無し]さん(bin+cue).rar：03/12/31 16:21 ID:QZBMYoFG
32Gまでのファイルに対応して開発していますがなにか?
高性能なリカバリ機能を搭載しているので超巨大ファイルも安心です。
高性能なリカバリ機能を搭載しているので超巨大ファイルも安心です。
513 ：[名無し]さん(bin+cue).rar：03/12/31 16:38 ID:KFNk5M+s
514 ：[名無し]さん(bin+cue).rar：04/01/01 04:01 ID:Cc7NClL4
515 ：[名無し]さん(bin+cue).rar：04/01/01 05:55 ID:D36sC89g
>>514
説明見た限り、匿名性の根拠は「強制アップロード」だけのように読める。
一応クラック対策は考えてるみたいだが、クラックされたらすべてが崩れるんだろうなぁ。
どうも、自分がネオ47氏になれることを夢見てるような雰囲気が感じられる。
こういうノリで開発してる香具師、他にも何人もいるんだろうな。
説明見た限り、匿名性の根拠は「強制アップロード」だけのように読める。
一応クラック対策は考えてるみたいだが、クラックされたらすべてが崩れるんだろうなぁ。
どうも、自分がネオ47氏になれることを夢見てるような雰囲気が感じられる。
こういうノリで開発してる香具師、他にも何人もいるんだろうな。
516 ：[名無し]さん(bin+cue).rar：04/01/01 06:00 ID:yUy9G+y0
>>515
「強制アップロード」だけだとまずいかな？
法律論議スレにも書き込んだが、まだ反応がない。
クラック対策については継続的なバージョンアップ以外にないだろう。
絶対にクラックできないソフトなんて期待する方が間違ってる。
まぁ、そんな事言ったら47氏だって夢とノリで作ったんだろうさ。
俺にも夢とノリがあるから開発に協力してる訳だしな。
「強制アップロード」だけだとまずいかな？
法律論議スレにも書き込んだが、まだ反応がない。
クラック対策については継続的なバージョンアップ以外にないだろう。
絶対にクラックできないソフトなんて期待する方が間違ってる。
まぁ、そんな事言ったら47氏だって夢とノリで作ったんだろうさ。
俺にも夢とノリがあるから開発に協力してる訳だしな。
517 ：[名無し]さん(bin+cue).rar：04/01/01 06:07 ID:Opw6dWyu
ノード間の通信の仕組みとかファイルのやり取りの流れとかの説明は無し？
518 ：[名無し]さん(bin+cue).rar：04/01/01 07:20 ID:uD60Dkcd
>>516
アホか。
DL完了時にキャッシュが生成される仕組みだったらnyと同じ事の様に思える。
また転送が無いのなら、強制にアップされて来たデータは
すなわち手持ちファイルと言う事になる。
これは初めに知られたくないノードに繋がった場合、即終了と言う事だね。
あと無駄が少ないという事はそれだけ高度な算術を駆使した対処が必要になるぞ。
（匿名性は必要無しと言うなら話は別）
一人で作るのは止めとけ。誰かの手伝いする方を奨める。
アホか。
DL完了時にキャッシュが生成される仕組みだったらnyと同じ事の様に思える。
また転送が無いのなら、強制にアップされて来たデータは
すなわち手持ちファイルと言う事になる。
これは初めに知られたくないノードに繋がった場合、即終了と言う事だね。
あと無駄が少ないという事はそれだけ高度な算術を駆使した対処が必要になるぞ。
（匿名性は必要無しと言うなら話は別）
一人で作るのは止めとけ。誰かの手伝いする方を奨める。
519 ：[名無し]さん(bin+cue).rar：04/01/01 07:26 ID:D36sC89g
>>516
> 「強制アップロード」だけだとまずいかな？
放流主がばれないようにするのには有効だろうね。ただ、強制アップした相手に
知られないような対策が必要になる。これについてちゃんと考えられているのか心配。
あと、キャッシュ保持者の保護についても何も考えられていないような気がする。
> クラック対策については継続的なバージョンアップ以外にないだろう。
このスレでは、オープンソースでも匿名性が保てる方式を検討しているわけだが。
効率も必要だけど、それ以上にみんなが求めてるのは安心感だと思うんだが、
どうもそれに欠けるな。もうちょっと仕組みを詳しく書いてくれれば検討もできるんだが。
今後に期待しよう。
> 「強制アップロード」だけだとまずいかな？
放流主がばれないようにするのには有効だろうね。ただ、強制アップした相手に
知られないような対策が必要になる。これについてちゃんと考えられているのか心配。
あと、キャッシュ保持者の保護についても何も考えられていないような気がする。
> クラック対策については継続的なバージョンアップ以外にないだろう。
このスレでは、オープンソースでも匿名性が保てる方式を検討しているわけだが。
効率も必要だけど、それ以上にみんなが求めてるのは安心感だと思うんだが、
どうもそれに欠けるな。もうちょっと仕組みを詳しく書いてくれれば検討もできるんだが。
今後に期待しよう。
520 ：[名無し]さん(bin+cue).rar：04/01/01 08:33 ID:yUy9G+y0
>>518
何故即終了？
キャッシュ化した人と強制アップした人の区別は付かないらしいけど？
下の行については安心しろ。
プログラミングなど全くできんからなｗ
>>519
強制アップした相手に知られないって、誰が何をアップしたかを？
このシステムの考えは、強制アップならアップした内容に法的責任を問われない、という事だと思うのだが。
まぁ、それが正しいかは法律論議スレで。
オープンソースもクローズドソースも関係ないだろう。
クラック対策には継続的なバージョンアップ以外にない。
ま、詳しい仕様が公表されてないから、まだ分からない部分も多いね。
俺も今後に期待。
何故即終了？
キャッシュ化した人と強制アップした人の区別は付かないらしいけど？
下の行については安心しろ。
プログラミングなど全くできんからなｗ
>>519
強制アップした相手に知られないって、誰が何をアップしたかを？
このシステムの考えは、強制アップならアップした内容に法的責任を問われない、という事だと思うのだが。
まぁ、それが正しいかは法律論議スレで。
オープンソースもクローズドソースも関係ないだろう。
クラック対策には継続的なバージョンアップ以外にない。
ま、詳しい仕様が公表されてないから、まだ分からない部分も多いね。
俺も今後に期待。
521 ：[名無し]さん(bin+cue).rar：04/01/01 08:39 ID:D36sC89g
ふう・・・、かなりキてるな。どこからツッコミを入れたものか。
522 ：[名無し]さん(bin+cue).rar：04/01/01 09:00 ID:Opw6dWyu
作者が出てきて詳細な仕様を説明するかしないと検討も何も無いと思うんだが。
ところでyUy9G+y0はどこでそのサイト見つけたの？ログ検索したけどどこにも無いから初出のようだけど。
ところでyUy9G+y0はどこでそのサイト見つけたの？ログ検索したけどどこにも無いから初出のようだけど。
523 ：[名無し]さん(bin+cue).rar：04/01/01 09:15 ID:rTBY3xsK
nyより進歩した部分は何も無い、
これを使うんだったらnyでいいじゃん。・・・こんな感じかな？
ID表示させてるけど、その分匿名性が下がるのわかってるのかな？
これを使うんだったらnyでいいじゃん。・・・こんな感じかな？
ID表示させてるけど、その分匿名性が下がるのわかってるのかな？
524 ：[名無し]さん(bin+cue).rar：04/01/01 09:19 ID:rTBY3xsK
後もう一つ。
＞(無駄は嫌いです)
と書いてあるが、強制UPの対象になるファイルの選び方をどうするかで、
ものすごい無駄が発生するかもしれないんだが、わかってるんだろうか？
（誰にも必要とされて無い糞ファイルのキャッシュが拡散する可能性がある）
＞(無駄は嫌いです)
と書いてあるが、強制UPの対象になるファイルの選び方をどうするかで、
ものすごい無駄が発生するかもしれないんだが、わかってるんだろうか？
（誰にも必要とされて無い糞ファイルのキャッシュが拡散する可能性がある）
525 ：[名無し]さん(bin+cue).rar：04/01/01 09:46 ID:rTBY3xsK
最後に。よくわからない部分。
＞インテリジェントなダウンロードスケジュール管理システムによってトラフィックを抑えます。
具体的な事が書いて無いのでよくわからないが、
P2Pネットワークというノードが落ちたり戻って来たりを繰り返す中での不安定な環境で、
有効な手法を開発できたのなら、これは大きな功績だろう。
本当に有効ならね。詳細ｷﾎﾞﾝ。
＞インテリジェントなダウンロードスケジュール管理システムによってトラフィックを抑えます。
具体的な事が書いて無いのでよくわからないが、
P2Pネットワークというノードが落ちたり戻って来たりを繰り返す中での不安定な環境で、
有効な手法を開発できたのなら、これは大きな功績だろう。
本当に有効ならね。詳細ｷﾎﾞﾝ。
526 ：[名無し]さん(bin+cue).rar：04/01/01 10:18 ID:Z/8hOUjQ
実行画面みた限りは、まともそうじゃん。
なんかごちゃごちゃ言ってるのは、自分が作れないからすねてるだけだと思う。
とりあえずWinnyと同じような感じのができれば、
そこから何かが生まれる可能性は非常に高いと思う。
なんかごちゃごちゃ言ってるのは、自分が作れないからすねてるだけだと思う。
とりあえずWinnyと同じような感じのができれば、
そこから何かが生まれる可能性は非常に高いと思う。
527 ：[名無し]さん(bin+cue).rar：04/01/01 10:34 ID:mVcJBnOJ
528 ：[名無し]さん(bin+cue).rar：04/01/01 10:35 ID:D36sC89g
>>526
> なんかごちゃごちゃ言ってるのは、自分が作れないからすねてるだけだと思う。
そうか？
「キャッシュ化した人と強制アップした人の区別は付かないらしいけど」とか
サイトの文章からは読み取れない内容のこと書いてるあたり何か怪しい気がするが(w
> とりあえずWinnyと同じような感じのができれば、
> そこから何かが生まれる可能性は非常に高いと思う。
そうか？
オープンソースならそういうこともあるかも知らんが、クローズドでnyと同じもの
出されても何の発展もないと思うが。
> なんかごちゃごちゃ言ってるのは、自分が作れないからすねてるだけだと思う。
そうか？
「キャッシュ化した人と強制アップした人の区別は付かないらしいけど」とか
サイトの文章からは読み取れない内容のこと書いてるあたり何か怪しい気がするが(w
> とりあえずWinnyと同じような感じのができれば、
> そこから何かが生まれる可能性は非常に高いと思う。
そうか？
オープンソースならそういうこともあるかも知らんが、クローズドでnyと同じもの
出されても何の発展もないと思うが。
529 ：[名無し]さん(bin+cue).rar：04/01/01 10:36 ID:Opw6dWyu
>>526
> 実行画面みた限りは、まともそうじゃん。
GUIなんて作ろうと思えばそれっぽく作れる。それが効率や匿名性を備えるかどうかは別。
> なんかごちゃごちゃ言ってるのは、自分が作れないからすねてるだけだと思う。
つっこみに異論があるなら指摘すればいいじゃん。
> とりあえずWinnyと同じような感じのができれば、
> そこから何かが生まれる可能性は非常に高いと思う。
そりゃ何かが出来上がるかもしれないけど、それが使えるかどうかの話をしてるんじゃないの？
> 実行画面みた限りは、まともそうじゃん。
GUIなんて作ろうと思えばそれっぽく作れる。それが効率や匿名性を備えるかどうかは別。
> なんかごちゃごちゃ言ってるのは、自分が作れないからすねてるだけだと思う。
つっこみに異論があるなら指摘すればいいじゃん。
> とりあえずWinnyと同じような感じのができれば、
> そこから何かが生まれる可能性は非常に高いと思う。
そりゃ何かが出来上がるかもしれないけど、それが使えるかどうかの話をしてるんじゃないの？
>>520
あんたどう見ても作者だと思ったが、違うのか？まぁいいや。
細かい記述が無いからはっきりしないけど、
起動時必ず受信とかの前にファイルアップするんでしょ？
その場合、アップしたユーザーが初めて使った時は必ず転送元な訳だ。
（ファイルを保持していないDOMはアレだが）
プロバイダからの簡易ログ提供の協力さえあれば、ポート、転送量、
acceptやconnectのパターン(ネット版指紋)で初めてかどうかを調べるのは容易。
通信の秘密は破られる事無しに把握可能。
正直あんな曖昧なのだけだと曖昧な答えしか出せんから、
もう少し詳しい説明を作者から聞いて来てくれ。
あんたどう見ても作者だと思ったが、違うのか？まぁいいや。
細かい記述が無いからはっきりしないけど、
起動時必ず受信とかの前にファイルアップするんでしょ？
その場合、アップしたユーザーが初めて使った時は必ず転送元な訳だ。
（ファイルを保持していないDOMはアレだが）
プロバイダからの簡易ログ提供の協力さえあれば、ポート、転送量、
acceptやconnectのパターン(ネット版指紋)で初めてかどうかを調べるのは容易。
通信の秘密は破られる事無しに把握可能。
正直あんな曖昧なのだけだと曖昧な答えしか出せんから、
もう少し詳しい説明を作者から聞いて来てくれ。
531 ：[名無し]さん(bin+cue).rar：04/01/01 11:03 ID:aHKKhdXq
情報が少ないからなんともいえないけど
アップロードの情報がDB化されてるのは非常に危険だと
思うんだけど、なにがメリットあるんだろう?
アップロードの情報がDB化されてるのは非常に危険だと
思うんだけど、なにがメリットあるんだろう?
532 ：[名無し]さん(bin+cue).rar：04/01/01 11:08 ID:Z/8hOUjQ
> プロバイダからの簡易ログ提供の協力さえあれば、ポート、転送量、
> acceptやconnectのパターン(ネット版指紋)で初めてかどうかを調べるのは容易。
> 通信の秘密は破られる事無しに把握可能。
>>530
これソースある？
どう考えても電波発言にしかみえないけど
> acceptやconnectのパターン(ネット版指紋)で初めてかどうかを調べるのは容易。
> 通信の秘密は破られる事無しに把握可能。
>>530
これソースある？
どう考えても電波発言にしかみえないけど
533 ：[名無し]さん(bin+cue).rar：04/01/01 11:09 ID:aHKKhdXq
534 ：[名無し]さん(bin+cue).rar：04/01/01 11:15 ID:aHKKhdXq
仕様を考える上で、ISPに協力させた事で可能な調査方法を洗い出してみたらどうでしょう?
思いつくのは、
1.日時指定でのIPアドレスによる発信者の個人情報取得
2.一定時間の特定IPアドレスの通信ログ
くらいしかないんですけど
でもこれらをISPに聞くには、最終段階じゃないとできないんですよね?
まだ疑わしいだけの段階ではなにができるんでしょうか?
よく話ででている、ファイアウォールつかって、特定ノードにしかつながらなくするみたいのは
ISPが容疑段階でそこまで協力するものなんでしょうかねえ?
既出ならスマソ
思いつくのは、
1.日時指定でのIPアドレスによる発信者の個人情報取得
2.一定時間の特定IPアドレスの通信ログ
くらいしかないんですけど
でもこれらをISPに聞くには、最終段階じゃないとできないんですよね?
まだ疑わしいだけの段階ではなにができるんでしょうか?
よく話ででている、ファイアウォールつかって、特定ノードにしかつながらなくするみたいのは
ISPが容疑段階でそこまで協力するものなんでしょうかねえ?
既出ならスマソ
535 ：[名無し]さん(bin+cue).rar：04/01/01 11:19 ID:Opw6dWyu
個人的に抽象的で都合のいいことばかり並べてるのが気になるんだよなぁ。
そういうソフトと運命を共にしたくないし。詳細な仕様が分かるまで放置でいいや。
曖昧な事にツッコミ入れても無駄に疲れるだけだし。
そういうソフトと運命を共にしたくないし。詳細な仕様が分かるまで放置でいいや。
曖昧な事にツッコミ入れても無駄に疲れるだけだし。
536 ：[名無し]さん(bin+cue).rar：04/01/01 11:20 ID:uD60Dkcd
>>532
プログラマの視点から見れば、内部を見ずに判断する場合は先程書いた様な
方法であれば可能だと思う訳だよ。
通信中のプログラムが何かを特定する技術があると言うのを
聞いた事あるか？恐らくこう言ったパターンを検出して判断するプログラムだと、
プログラマだったら思うよな、普通。それともそんな事は不可能だと思う？
むしろ一旦コードが完成したとしたら、以降は簡単に出来ると思う筈。
プログラマの視点から見れば、内部を見ずに判断する場合は先程書いた様な
方法であれば可能だと思う訳だよ。
通信中のプログラムが何かを特定する技術があると言うのを
聞いた事あるか？恐らくこう言ったパターンを検出して判断するプログラムだと、
プログラマだったら思うよな、普通。それともそんな事は不可能だと思う？
むしろ一旦コードが完成したとしたら、以降は簡単に出来ると思う筈。
537 ：[名無し]さん(bin+cue).rar：04/01/01 11:23 ID:uD60Dkcd
538 ：[名無し]さん(bin+cue).rar：04/01/01 11:27 ID:Z/8hOUjQ
539 ：[名無し]さん(bin+cue).rar：04/01/01 11:30 ID:XdmHPBm+
540 ：[名無し]さん(bin+cue).rar：04/01/01 11:32 ID:uD60Dkcd
>>538
へぇ、ポート記録して無いの？その場合は多少難しくなるな。
全部とは言わず、IPヘッダだけでも取れればサイズとかで判断出来るかな…
まぁともかく、プロバイダと協力さえすればなんとなかるんでない？
へぇ、ポート記録して無いの？その場合は多少難しくなるな。
全部とは言わず、IPヘッダだけでも取れればサイズとかで判断出来るかな…
まぁともかく、プロバイダと協力さえすればなんとなかるんでない？
541 ：[名無し]さん(bin+cue).rar：04/01/01 11:40 ID:aHKKhdXq
>>537
534です
これは自分のマシンのログをとって接続先IPを調べるって意味であってますか?
中継がある通信の場合であれば、これだけだけしかできないなら、疑わしいってだけですよね
アップロードが長期間に渡れば容疑濃厚って事かな
この程度の状態でもISPに協力させる事ってできるんでしょうか?
534です
これは自分のマシンのログをとって接続先IPを調べるって意味であってますか?
中継がある通信の場合であれば、これだけだけしかできないなら、疑わしいってだけですよね
アップロードが長期間に渡れば容疑濃厚って事かな
この程度の状態でもISPに協力させる事ってできるんでしょうか?
>>541
例えば特定のアプリケーションの違法性が高いと判明した場合は
使った時点でマークされるんじゃないかな。
(多分nyはマークされてる)
ぷららとかは通信ソフトを判定するプログラムをかませている様だし、
(判定するには最小限でもポートとソケ単位サイズの解析が必要だと言える）
まぁプロバイダーによって変わって来そうな感じ。
少なくとも送信データ以外のヘッダは監視されているのを前提にしたほうが
良いんじゃないかと思われるが、（ここは調べても通信の秘密は守られるとか）
ジシンガナクナッテキタヨ。
例えば特定のアプリケーションの違法性が高いと判明した場合は
使った時点でマークされるんじゃないかな。
(多分nyはマークされてる)
ぷららとかは通信ソフトを判定するプログラムをかませている様だし、
(判定するには最小限でもポートとソケ単位サイズの解析が必要だと言える）
まぁプロバイダーによって変わって来そうな感じ。
少なくとも送信データ以外のヘッダは監視されているのを前提にしたほうが
良いんじゃないかと思われるが、（ここは調べても通信の秘密は守られるとか）
ジシンガナクナッテキタヨ。
543 ：[名無し]さん(bin+cue).rar：04/01/01 12:14 ID:vRckZqyK
>>542
日経コミュニケーションの最新号に
２００４年の通信装置の動向なんて
特集があるけど、最近帯域制御装置って
言うのがISPに飛ぶように売れているらしい。
例えば
ttp://www.mctokyo.com/p-cube/index.html
上流でP2Pトラフィックだけをまとめて制限するから
逃げようがない。例えば上流幹線がGbEならそのうち
100Mbps以上はP2Pを認めないって感じで・・・・。
Ｐ２Ｐを新しい装置技術でつぶしていく
方向になりそうだね。
＃このソリューションのナイスなところは
＃ユーザに知られずにＰ２Ｐを制限できるところ。
日経コミュニケーションの最新号に
２００４年の通信装置の動向なんて
特集があるけど、最近帯域制御装置って
言うのがISPに飛ぶように売れているらしい。
例えば
ttp://www.mctokyo.com/p-cube/index.html
上流でP2Pトラフィックだけをまとめて制限するから
逃げようがない。例えば上流幹線がGbEならそのうち
100Mbps以上はP2Pを認めないって感じで・・・・。
Ｐ２Ｐを新しい装置技術でつぶしていく
方向になりそうだね。
＃このソリューションのナイスなところは
＃ユーザに知られずにＰ２Ｐを制限できるところ。
544 ：[名無し]さん(bin+cue).rar：04/01/01 12:19 ID:Z/8hOUjQ
545 ：[名無し]さん(bin+cue).rar：04/01/01 12:22 ID:NnmFSqZv
>>542
そのぷららがやってるny制限も裁判になったら違法認定されると思うんだが。
まあそれが違法かどうかともかくとして、
実際にそういう手法が使われ出してるのだから、
このスレ的には対策しておく必要はあるだろうね。
そのぷららがやってるny制限も裁判になったら違法認定されると思うんだが。
まあそれが違法かどうかともかくとして、
実際にそういう手法が使われ出してるのだから、
このスレ的には対策しておく必要はあるだろうね。
546 ：[名無し]さん(bin+cue).rar：04/01/01 12:41 ID:Z/8hOUjQ
547 ：[名無し]さん(bin+cue).rar：04/01/01 12:41 ID:uD60Dkcd
>>543
ほほう、これはすごい。パターン識別を実現しとるよ。
P2Pの種類を判定して使用状況の程度を伝える機能もしっかりついとる。
nyとか使っていると言うログもプロバイダは取ってる確率高そうだ。
>>544
普通のルーターとか短期に情報を捨てる奴は別だな。
ほほう、これはすごい。パターン識別を実現しとるよ。
P2Pの種類を判定して使用状況の程度を伝える機能もしっかりついとる。
nyとか使っていると言うログもプロバイダは取ってる確率高そうだ。
>>544
普通のルーターとか短期に情報を捨てる奴は別だな。
548 ：[名無し]さん(bin+cue).rar：04/01/01 12:47 ID:Z/8hOUjQ
549 ：[名無し]さん(bin+cue).rar：04/01/01 12:52 ID:aHKKhdXq
令状がでた場合、通信ログの提出ではなく、今後の通信を記録させる
権限まであるのかが気になっています
つまり、ISPにはログ提出までしか義務がなかったと思うのですけど
令状がでたからといって、それ以降無制限に調査する権限まで
与えられたんですかねえ
それとログ以外の調査の協力義務もあるんでしょうか?
義務ではなく任意に協力した場合は、ISPは通信傍受で法律違反に
なると思うのですがいかがでしょう?
権限まであるのかが気になっています
つまり、ISPにはログ提出までしか義務がなかったと思うのですけど
令状がでたからといって、それ以降無制限に調査する権限まで
与えられたんですかねえ
それとログ以外の調査の協力義務もあるんでしょうか?
義務ではなく任意に協力した場合は、ISPは通信傍受で法律違反に
なると思うのですがいかがでしょう?
550 ：[名無し]さん(bin+cue).rar：04/01/01 13:05 ID:Z/8hOUjQ
>>549
令状が出れば警察が直接盗聴して捜査するでしょう。
令状が出れば警察が直接盗聴して捜査するでしょう。
551 ：[名無し]さん(bin+cue).rar：04/01/01 13:35 ID:Cc7NClL4
>>539
素で間違えたらしい。
>>531
DBは対リネーム対策です。これはローカルだけで機能するものです。個人的なメモ超みたいなものです。
IDはIMと共用です。IDはつけないことも可能です。というよりこの仕様はまだ少し変えようか悩んでいます。
トラフィック対策は他にもう1つある方法が実装済みです。このスレでは一度も出てきていない方法です。
以上、中の人談でした。
素で間違えたらしい。
>>531
DBは対リネーム対策です。これはローカルだけで機能するものです。個人的なメモ超みたいなものです。
IDはIMと共用です。IDはつけないことも可能です。というよりこの仕様はまだ少し変えようか悩んでいます。
トラフィック対策は他にもう1つある方法が実装済みです。このスレでは一度も出てきていない方法です。
以上、中の人談でした。
552 ：[名無し]さん(bin+cue).rar：04/01/01 13:42 ID:1GavcJQY
553 ：[名無し]さん(bin+cue).rar：04/01/01 13:42 ID:NnmFSqZv
>>551
本人か友達か知らんが乙。
しかし、技術的に新しい要素がないんならスレ違いだと思うんだが。
ここは新しいアイデアをみんなでつついて、
使えないものを捨てたり、より完成度の高いものにしようとするスレなので。
それ用のスレを建てるか、
37氏とは関係ないが、ネタに飢えてるであろう
37歳氏と新P2Pソフト完成をマターリ待つ会 Part6
http://tmp2.2ch.net/test/read.cgi/download/1072860371/
に行くかした方が良いんじゃないか？
後法律関係の話題も、そっちのスレに行きましょう。
本人か友達か知らんが乙。
しかし、技術的に新しい要素がないんならスレ違いだと思うんだが。
ここは新しいアイデアをみんなでつついて、
使えないものを捨てたり、より完成度の高いものにしようとするスレなので。
それ用のスレを建てるか、
37氏とは関係ないが、ネタに飢えてるであろう
37歳氏と新P2Pソフト完成をマターリ待つ会 Part6
http://tmp2.2ch.net/test/read.cgi/download/1072860371/
に行くかした方が良いんじゃないか？
後法律関係の話題も、そっちのスレに行きましょう。
554 ：[名無し]さん(bin+cue).rar：04/01/01 13:45 ID:Cc7NClL4
>>553
そのスレ、前に見つからなかった。スマソ。いつもはそっちに書き込んでいる。
そのスレ、前に見つからなかった。スマソ。いつもはそっちに書き込んでいる。
1) 26氏 隣接ノードに情報を漏らさない方式
掲示板サービスはほぼ完成し、共有部分に着手する予定。
2) 420氏 隣接ノードに情報を漏らさない方式
シミュ作るらしい。26氏と競争中？
>26 ：2003/12/27 0:19:40
>420,440さんを見てみましたが、どうやらベース作るみたいなので
>残念ながら私のとは相容れません。
>掲示板も一段落がつくので私も一応作ってみますが、
>結果的にどちらかが廃れるでしょうｗ
3) ( ´Д`)氏 キャッシュの意思に基づく秘密分散方式
仕様はほぼ完成？シミュ開発中。
ttp://kyouzin2ch.hp.infoseek.co.jp/p2p/
ココで落とせる。けっこうｵﾓｼﾛｲ。
4) T氏、N氏 Winny方式？
Winnyクローン？
不明。
掲示板サービスはほぼ完成し、共有部分に着手する予定。
2) 420氏 隣接ノードに情報を漏らさない方式
シミュ作るらしい。26氏と競争中？
>26 ：2003/12/27 0:19:40
>420,440さんを見てみましたが、どうやらベース作るみたいなので
>残念ながら私のとは相容れません。
>掲示板も一段落がつくので私も一応作ってみますが、
>結果的にどちらかが廃れるでしょうｗ
3) ( ´Д`)氏 キャッシュの意思に基づく秘密分散方式
仕様はほぼ完成？シミュ開発中。
ttp://kyouzin2ch.hp.infoseek.co.jp/p2p/
ココで落とせる。けっこうｵﾓｼﾛｲ。
4) T氏、N氏 Winny方式？
Winnyクローン？
不明。
5) むーむー氏 改良RAID5氏方式？ Perl
強制アップロード＋Google-PageRankを真似たノード評価方式
詳細不明
強制アップロード＋Google-PageRankを真似たノード評価方式
詳細不明
557 ：[名無し]さん(bin+cue).rar：04/01/01 15:06 ID:aHKKhdXq
558 ：[名無し]さん(bin+cue).rar：04/01/01 17:39 ID:aSwnJO4m
>>528
>「キャッシュ化した人と強制アップした人の区別は付かないらしいけど」とか
>サイトの文章からは読み取れない内容のこと書いてるあたり何か怪しい気がするが(w
>自動アップロード実装予定。(この機能により公開した瞬間からファイル保持者が多重化し、
>外から見ると誰が最初の公開者かわかりにくくなります)
から読み取ったんだが。他にどう解釈したんだ？
>>530
俺は作者じゃないよ。
及ばずながら、P2Pの情報集めたり法律調べたりして、
様々な次期P2Pシステムの開発に協力させてもらっているだけだ。
プログラミングの知識はプの字もない。
受信の前にアップするとは書いてないね。
上にも書いたが俺は作者じゃないから、URLに書いてある事以上の事は分からないよ。
まだ説明が曖昧すぎるのには同意。
俺も詳しい説明を聞いて来たいところだが連絡先がわからん。
>>557
通信傍受法は麻薬、組織的殺人、集団密航と言った、
組織性、国家に対する危険性が非常に強い犯罪に限定されてるね。
他にもあったかもしれんが著作権法違反への適用は有り得ない。
傍受できる法的根拠も他にはない。
相当に権限を絞った通信傍受法でも憲法との整合性がかなり問題になったし。
公安調査庁が革マル派やオウム真理教などの危険な組織の
通信傍受を行っているのは公然の秘密だが、当然非合法。
まさかたかだか著作権法違反でそんな事やるとは思えないが。
>「キャッシュ化した人と強制アップした人の区別は付かないらしいけど」とか
>サイトの文章からは読み取れない内容のこと書いてるあたり何か怪しい気がするが(w
>自動アップロード実装予定。(この機能により公開した瞬間からファイル保持者が多重化し、
>外から見ると誰が最初の公開者かわかりにくくなります)
から読み取ったんだが。他にどう解釈したんだ？
>>530
俺は作者じゃないよ。
及ばずながら、P2Pの情報集めたり法律調べたりして、
様々な次期P2Pシステムの開発に協力させてもらっているだけだ。
プログラミングの知識はプの字もない。
受信の前にアップするとは書いてないね。
上にも書いたが俺は作者じゃないから、URLに書いてある事以上の事は分からないよ。
まだ説明が曖昧すぎるのには同意。
俺も詳しい説明を聞いて来たいところだが連絡先がわからん。
>>557
通信傍受法は麻薬、組織的殺人、集団密航と言った、
組織性、国家に対する危険性が非常に強い犯罪に限定されてるね。
他にもあったかもしれんが著作権法違反への適用は有り得ない。
傍受できる法的根拠も他にはない。
相当に権限を絞った通信傍受法でも憲法との整合性がかなり問題になったし。
公安調査庁が革マル派やオウム真理教などの危険な組織の
通信傍受を行っているのは公然の秘密だが、当然非合法。
まさかたかだか著作権法違反でそんな事やるとは思えないが。
559 ：[名無し]さん(bin+cue).rar：04/01/01 17:42 ID:lhYA8vOC
560 ：[名無し]さん(bin+cue).rar：04/01/01 21:57 ID:aSwnJO4m
Share(仮称)の作者さん、見てますか？
過去ログに出てる、某P2P匿名掲示板にスレ立てて下さい。
そこならスレ主も安全だと思いますので。
過去ログに出てる、某P2P匿名掲示板にスレ立てて下さい。
そこならスレ主も安全だと思いますので。
561 ：[名無し]さん(bin+cue).rar：04/01/01 23:41 ID:cyVxdmWi
562 ：[名無し]さん(bin+cue).rar：04/01/01 23:59 ID:mVcJBnOJ
563 ：[名無し]さん(bin+cue).rar：04/01/02 05:23 ID:PODkK5v2
share見てきたけど
転送は効率が悪いからきらいって書いてあるけど
本当にそうか？
転送は効率が悪いからきらいって書いてあるけど
本当にそうか？
564 ：[名無し]さん(bin+cue).rar：04/01/02 09:43 ID:SZfg/1kj
565 ：[名無し]さん(bin+cue).rar：04/01/02 15:21 ID:0pimPiip
566 ：[名無し]さん(bin+cue).rar：04/01/02 15:58 ID:90AxdvYR
567 ：[名無し]さん(bin+cue).rar：04/01/02 19:32 ID:tgEkh2Ze
パソコンの２１世紀
第２集 大量共有の完成：２ちゃんねるのDownload板住人たちは凄まじいＰ２Ｐの出現を見た
warezから、きらめきと魔術的な美がついに奪い盗られてしまった。
ファミコン決死隊やiSONEWSが、warezerたちと危険を分かち合いながら、
偽装ツールでネット上を駆け巡り、サイトの運命を決する。
そんなことはもうなくなった。
これからのwarezerは、安全で静かで、物憂い事務室にいてハードディスクに囲まれて座る。
一方、何千というソフトウエア会社が、光回線でファイル共有ソフトの力によって殺され息の根を止められる。
これから先に開発されるるファイル共有ソフトは、女性や子供や一般市民全体の労働意欲をなくすことになるだろう。
やがて、それぞれの国々は大規模で、限界のない、一度発動されたら制御不能となるような
コンテンツ産業崩壊の為のシステムを産み出すことになる。
人類は、初めて自分たちの欲望を満たすことが出来る道具を手に入れた。
これこそが、人類の栄光と苦労の全てが最後に到達した運命である。
第２集 大量共有の完成：２ちゃんねるのDownload板住人たちは凄まじいＰ２Ｐの出現を見た
warezから、きらめきと魔術的な美がついに奪い盗られてしまった。
ファミコン決死隊やiSONEWSが、warezerたちと危険を分かち合いながら、
偽装ツールでネット上を駆け巡り、サイトの運命を決する。
そんなことはもうなくなった。
これからのwarezerは、安全で静かで、物憂い事務室にいてハードディスクに囲まれて座る。
一方、何千というソフトウエア会社が、光回線でファイル共有ソフトの力によって殺され息の根を止められる。
これから先に開発されるるファイル共有ソフトは、女性や子供や一般市民全体の労働意欲をなくすことになるだろう。
やがて、それぞれの国々は大規模で、限界のない、一度発動されたら制御不能となるような
コンテンツ産業崩壊の為のシステムを産み出すことになる。
人類は、初めて自分たちの欲望を満たすことが出来る道具を手に入れた。
これこそが、人類の栄光と苦労の全てが最後に到達した運命である。
568 ：[名無し]さん(bin+cue).rar：04/01/02 20:26 ID:ht/Is8bX
569 ：[名無し]さん(bin+cue).rar：04/01/02 21:39 ID:uPmUNgw8
ユビキタスな
570 ：[名無し]さん(bin+cue).rar：04/01/02 21:42 ID:7jq7I2BV
571 ：[名無し]さん(bin+cue).rar：04/01/03 04:51 ID:m4su8vz9
何それ？
572 ：[名無し]さん(bin+cue).rar：04/01/03 05:03 ID:udVQCYGs
たぶん強制アップロードの方が転送より効率悪くて匿名性低い
573 ：[名無し]さん(bin+cue).rar：04/01/03 05:11 ID:wlIBWZE1
283 ：朝まで名無しさん ：04/01/03 04:50 ID:aX47Kqja
241 ：名無しさん＠お腹いっぱい。 ：04/01/01 23:32 ID:gqKEeAym
逮捕されたね
http://www.okumura-tanaka-law.com/www/okumura/tyosaku/WINMX.html
第2 Ｄ社（法人代表法務最高責任者）が著作権を有する映画の著作物である
邦題名「U」のデータを不特定多数のインターネット利用者に送信しようと企て、
平成年月25日午前1時47分ころから同日午前3時18分ころまでの間、
自宅において、被疑者使用のパーソナルコンピュータ内に、同データを記憶蔵置させ、
インターネットに接続し、同パーソナルコンピュータ内のファイル共有ソフト「Winny」を起動させて、
同パーソナルコンピュータをインターネットに接続されている自動公衆送信装置とし、
同パーソナルコンピュータにアクセスしてきた不特定多数のインターネット利用者に自動公衆送信可能な状態にし、
もって同著作権者の有する著作権（公衆送信権に含まれる自動公衆送信の場合における送信可能化権）を侵害したものである。
241 ：名無しさん＠お腹いっぱい。 ：04/01/01 23:32 ID:gqKEeAym
逮捕されたね
http://www.okumura-tanaka-law.com/www/okumura/tyosaku/WINMX.html
第2 Ｄ社（法人代表法務最高責任者）が著作権を有する映画の著作物である
邦題名「U」のデータを不特定多数のインターネット利用者に送信しようと企て、
平成年月25日午前1時47分ころから同日午前3時18分ころまでの間、
自宅において、被疑者使用のパーソナルコンピュータ内に、同データを記憶蔵置させ、
インターネットに接続し、同パーソナルコンピュータ内のファイル共有ソフト「Winny」を起動させて、
同パーソナルコンピュータをインターネットに接続されている自動公衆送信装置とし、
同パーソナルコンピュータにアクセスしてきた不特定多数のインターネット利用者に自動公衆送信可能な状態にし、
もって同著作権者の有する著作権（公衆送信権に含まれる自動公衆送信の場合における送信可能化権）を侵害したものである。
574 ：[名無し]さん(bin+cue).rar：04/01/03 05:29 ID:JUJj2ZjC
だからそのurlのWINMX.htmlつ～のは何なのかと小一時間（ｒ
575 ：[名無し]さん(bin+cue).rar：04/01/03 12:13 ID:+u5xDPNS
576 ：[名無し]さん(bin+cue).rar：04/01/03 15:20 ID:QxXDWGjX
何を言いたいの？
頭がおかしいんじゃないの？
頭がおかしいんじゃないの？
577 ：[名無し]さん(bin+cue).rar：04/01/03 15:29 ID:+u5xDPNS
>>576
google のキャッシュには残っているんだが。↓を全部つなげて見てみ。
http://www.google.co.jp/search?q=cache:l4u2BUPg64IJ:www.okumura-tanaka-law.com/www/okumura/tyosaku/WINMX.html+
%EF%BC%A4%E7%A4%BE%EF%BC%88%E6%B3%95%E4%BA%BA%E4%BB%A3%E8%A1%A8%E6%B3%95%E5%8B%99%E6%9C%80%E9%AB
%98%E8%B2%AC%E4%BB%BB%E8%80%85%EF%BC%89&hl=ja&start=3&ie=UTF-8
google のキャッシュには残っているんだが。↓を全部つなげて見てみ。
http://www.google.co.jp/search?q=cache:l4u2BUPg64IJ:www.okumura-tanaka-law.com/www/okumura/tyosaku/WINMX.html+
%EF%BC%A4%E7%A4%BE%EF%BC%88%E6%B3%95%E4%BA%BA%E4%BB%A3%E8%A1%A8%E6%B3%95%E5%8B%99%E6%9C%80%E9%AB
%98%E8%B2%AC%E4%BB%BB%E8%80%85%EF%BC%89&hl=ja&start=3&ie=UTF-8
578 ：[名無し]さん(bin+cue).rar：04/01/03 15:52 ID:09mzhPV+
579 ：[名無し]さん(bin+cue).rar：04/01/03 15:57 ID:+u5xDPNS
なんで、そんなに必死なの？
580 ： ◆Fw0Kir8iYA ：04/01/04 17:14 ID:LHY4ntO/
ようやく帰ってきました。皆さん、あけましておめでとうございます。
さっそくですが、休み前に420氏、492氏、( ´Д`)氏に指摘された疑問点、問題点についていろいろ考えた結果、
またまた大幅な仕様変更をしようかと考えています。ただ、新仕様にはまだあいまいな部分が
あるので、現在の仕様をver.1として残したまま、新しい仕様をver2βとして今日中に公開しようと思っています。
また、420氏の仕事を増やすことになりそうです。申し訳ない。大幅な変更とはいえ、今まで
作成した部分については無駄にはならないと思いますのでご容赦を。
>>492
つっこみありがとうございます。
＞ 1) キャッシュ保持者は高確率でダウンロード者である
これ、ほんとに重大な問題点ですね。これと、420氏の「レジュームはどうするか?」という
質問が、ver2発案の引き金となりました。感謝です。後ほどupする新仕様において、この
問題点が緩和しているかどうか、確認お願いします。
＞ 2) 放流者Ａがユニークな特性を持つことへの懸念
これについては、考察2で述べている方法でよろしいでしょうか?
＞また、十分にファイル名を含んだキー情報が拡散したら、自ノードはキー情報を消し、
＞単なる中継者と同じ立場に変化するようにするという手も有効ではないでしょうか。
これはグッドアイデアですね。ver2βに追加させていただきます。
＞ 3) 呼び名について
この名称は、おそらくwikiの管理者さんが転載されたときにつけられたもので、それをそのまま
引きずっているだけです。私がつけた名前ではないので、一切こだわりはありませんw
というわけで、名前募集中です。とりあえず候補１は「隣接秘匿形式」でお願いします。
その他、wikiの説明で用いている「Yのupファイルの情報（ファイル名、ハッシュ等）」
とか、「Aがファイルの暗号化に用いた共通鍵」等の語句についても、分かりやすい呼称
を提案していただけると助かります。
さっそくですが、休み前に420氏、492氏、( ´Д`)氏に指摘された疑問点、問題点についていろいろ考えた結果、
またまた大幅な仕様変更をしようかと考えています。ただ、新仕様にはまだあいまいな部分が
あるので、現在の仕様をver.1として残したまま、新しい仕様をver2βとして今日中に公開しようと思っています。
また、420氏の仕事を増やすことになりそうです。申し訳ない。大幅な変更とはいえ、今まで
作成した部分については無駄にはならないと思いますのでご容赦を。
>>492
つっこみありがとうございます。
＞ 1) キャッシュ保持者は高確率でダウンロード者である
これ、ほんとに重大な問題点ですね。これと、420氏の「レジュームはどうするか?」という
質問が、ver2発案の引き金となりました。感謝です。後ほどupする新仕様において、この
問題点が緩和しているかどうか、確認お願いします。
＞ 2) 放流者Ａがユニークな特性を持つことへの懸念
これについては、考察2で述べている方法でよろしいでしょうか?
＞また、十分にファイル名を含んだキー情報が拡散したら、自ノードはキー情報を消し、
＞単なる中継者と同じ立場に変化するようにするという手も有効ではないでしょうか。
これはグッドアイデアですね。ver2βに追加させていただきます。
＞ 3) 呼び名について
この名称は、おそらくwikiの管理者さんが転載されたときにつけられたもので、それをそのまま
引きずっているだけです。私がつけた名前ではないので、一切こだわりはありませんw
というわけで、名前募集中です。とりあえず候補１は「隣接秘匿形式」でお願いします。
その他、wikiの説明で用いている「Yのupファイルの情報（ファイル名、ハッシュ等）」
とか、「Aがファイルの暗号化に用いた共通鍵」等の語句についても、分かりやすい呼称
を提案していただけると助かります。
581 ：[名無し]さん(bin+cue).rar：04/01/04 17:21 ID:m1vztXNR
ファイル鍵
582 ： ◆Fw0Kir8iYA ：04/01/05 00:12 ID:s6WKlnpv
更新しました。
ver1→2βの大きな変更点は2つです。
① ファイル情報とキャッシュの完全な分離
② 強制upによるDOM、キャッシュ即消し対策の導入
①の変更により、ver1で残っていた「ノードFからのキャッシュダウンロード法」の
問題が解決します。また、この変更は初期放流者の安全性の向上にもつながると
思われます。
②の変更のメリットは上の2つだけではありません。その他の重要な問題点の
解消にもつながっています。詳細はwiki参照。
ただし、まだまだ問題点が多いので、とりあえず提案してみた段階と考えて
ください。強制upについては賛否両論あると思いますので、ご意見お待ちしています。
>>581
ども。ver2についてもよろしくお願いします。
ver1→2βの大きな変更点は2つです。
① ファイル情報とキャッシュの完全な分離
② 強制upによるDOM、キャッシュ即消し対策の導入
①の変更により、ver1で残っていた「ノードFからのキャッシュダウンロード法」の
問題が解決します。また、この変更は初期放流者の安全性の向上にもつながると
思われます。
②の変更のメリットは上の2つだけではありません。その他の重要な問題点の
解消にもつながっています。詳細はwiki参照。
ただし、まだまだ問題点が多いので、とりあえず提案してみた段階と考えて
ください。強制upについては賛否両論あると思いますので、ご意見お待ちしています。
>>581
ども。ver2についてもよろしくお願いします。
583 ：[名無し]さん(bin+cue).rar：04/01/05 04:35 ID:KGwiOVSJ
DOMとファイル捏造についてですが、
WinMXでは、これらをどうやって防いでいたんでしょうか。
WinnyよりもDOMしにくい仕組みなわけで、捏造が溢れかえると思うんですが。
WinMXでは、これらをどうやって防いでいたんでしょうか。
WinnyよりもDOMしにくい仕組みなわけで、捏造が溢れかえると思うんですが。
584 ：[名無し]さん(bin+cue).rar：04/01/05 05:00 ID:dBeRRvwI
>>583
WinMXは交換でしょう。
あまりに面倒で少ししか使ってなかったけれど、
あれは中央サーバに接続してファイルを検索するタイプで、
探し出した相手と直接接続されてIM送ったり帯域制限掛けたり接続切ったりできる。
DOMを弾くには切断ボタンを押せば良いだけで、それを自動的にやってくれるツールもあった。
nyが共有ソフトならMXは交換ソフトって訳だ。
WinMXは交換でしょう。
あまりに面倒で少ししか使ってなかったけれど、
あれは中央サーバに接続してファイルを検索するタイプで、
探し出した相手と直接接続されてIM送ったり帯域制限掛けたり接続切ったりできる。
DOMを弾くには切断ボタンを押せば良いだけで、それを自動的にやってくれるツールもあった。
nyが共有ソフトならMXは交換ソフトって訳だ。
585 ：[名無し]さん(bin+cue).rar：04/01/05 05:06 ID:KGwiOVSJ
586 ：[名無し]さん(bin+cue).rar：04/01/05 06:49 ID:/3xT5waO
捏造を防いでたのはMXerの良心だよ。
ほんとは攻撃されることへの恐怖心だけどな。
ほんとは攻撃されることへの恐怖心だけどな。
587 ：[名無し]さん(bin+cue).rar：04/01/05 12:26 ID:dBeRRvwI
588 ：[名無し]さん(bin+cue).rar：04/01/05 20:11 ID:dlKVz/hd
nyの捏造警告もアテにならんからなぁ。二律背反って感じ。お、俺いいこと言った。
589 ：[名無し]さん(bin+cue).rar：04/01/05 20:57 ID:TrL+zzUh
590 ：[名無し]さん(bin+cue).rar：04/01/05 21:00 ID:pUw7Hy9n
>>589
強制アップは未実装。
強制アップは未実装。
591 ：[名無し]さん(bin+cue).rar：04/01/05 21:16 ID:TrL+zzUh
さすが >>499 氏
592 ：[名無し]さん(bin+cue).rar：04/01/06 00:49 ID:1pkUcxKj
P2P匿名チャット動き出しました。
すごく快適（驚
[49] 9Gfa ：26◆26Iim/mUZlZp1w ：2004/01/06 0:23:58
Pre-Alpha.22です。
・接続数の制限をちょっと強化
・IMに対応
・チャットルームに対応
Pre-Alpha.22.zip (116.45 KB)
[50] hh// ：26◆26Iim/mUZlZp1w ：2004/01/06 0:26:53
Pre-Alpha.22の更新内容に追加で、
・メッセージ圧縮を無効にした
圧縮率微妙＆負荷大なので、一時的に無効にします。
ちなみに、マネージドコードのAdaptiveHuffmanだけで圧縮してました。
すごく快適（驚
[49] 9Gfa ：26◆26Iim/mUZlZp1w ：2004/01/06 0:23:58
Pre-Alpha.22です。
・接続数の制限をちょっと強化
・IMに対応
・チャットルームに対応
Pre-Alpha.22.zip (116.45 KB)
[50] hh// ：26◆26Iim/mUZlZp1w ：2004/01/06 0:26:53
Pre-Alpha.22の更新内容に追加で、
・メッセージ圧縮を無効にした
圧縮率微妙＆負荷大なので、一時的に無効にします。
ちなみに、マネージドコードのAdaptiveHuffmanだけで圧縮してました。
593 ：[名無し]さん(bin+cue).rar：04/01/06 07:26 ID:4hPFH78U
shareスレが盛り上がってるのに26氏のソフトはすれも立たずにひっそりですか。
おいら的には26氏のほうに期待してるんだけどな。
おいら的には26氏のほうに期待してるんだけどな。
594 ：[名無し]さん(bin+cue).rar：04/01/06 08:56 ID:Uv8YDgJJ
>>593
あちらはプロフェッショナルの集まりだから
あちらはプロフェッショナルの集まりだから
595 ：[名無し]さん(bin+cue).rar：04/01/06 09:15 ID:z3DqXlW4
ファイル共有が付くまでは今のままでいいんじゃね。
ダウソ民的にも興味がわかないだろうし。
それなりにテスターも居るし、こつこつマターリやって行けばいいよ。
ダウソ民的にも興味がわかないだろうし。
それなりにテスターも居るし、こつこつマターリやって行けばいいよ。
596 ：[名無し]さん(bin+cue).rar：04/01/06 09:24 ID:lpEFDGmT
もう共有付いてて新バージョンはその共有機能で公開されてるはずだが
597 ：[名無し]さん(bin+cue).rar：04/01/06 11:33 ID:lQoQODIr
該当スレを見つけきれないへたれ
598 ：[名無し]さん(bin+cue).rar：04/01/06 11:37 ID:etJ6npGQ
26氏は、完成度を高めてから公開するつもりなんじゃないでしょうか。
正しい姿勢だと思います。
正しい姿勢だと思います。
599 ：[名無し]さん(bin+cue).rar：04/01/06 11:43 ID:lQoQODIr
んじゃ表に出てくるまで待ちます(´･ω･`)
600 ：[名無し]さん(bin+cue).rar：04/01/06 12:07 ID:Uv8YDgJJ
>>599
26氏は現在チャット中です
26氏は現在チャット中です
601 ：[名無し]さん(bin+cue).rar：04/01/06 19:48 ID:1pkUcxKj
みんな体育館の裏で密談してる…。(´∀｀)
602 ：[名無し]さん(bin+cue).rar：04/01/06 22:05 ID:sb8c3jE4
全部丸見えだけどねｗ
603 ：[名無し]さん(bin+cue).rar：04/01/06 22:26 ID:FgWoEnrA
afe
604 ：[名無し]さん(bin+cue).rar：04/01/07 08:14 ID:F4uosHAP
プログラムしたいから取り合えずC#買ったけど、どうも通常の環境では
動かないexeが作成されてしまうようだ。
フリーソフト出すにも.Netランタムが入って無い環境の人が大半だから
誰も使わないだろう。
そうだ、どんなに手間が掛かっても使う種類のソフトがあるじゃないか。
同期とか例外とかまったく訳がわからん漏れが作ったクソソフトでも
一躍英雄になれる。どうせ練習で作るのなら、あれを作るしかないな。
動かないexeが作成されてしまうようだ。
フリーソフト出すにも.Netランタムが入って無い環境の人が大半だから
誰も使わないだろう。
そうだ、どんなに手間が掛かっても使う種類のソフトがあるじゃないか。
同期とか例外とかまったく訳がわからん漏れが作ったクソソフトでも
一躍英雄になれる。どうせ練習で作るのなら、あれを作るしかないな。
605 ：[名無し]さん(bin+cue).rar：04/01/07 08:58 ID:4v5FxX4q
ソリティア？
606 ：[名無し]さん(bin+cue).rar：04/01/07 10:40 ID:uLXSZTth
>.Netランタム
美味しそう。食べたい
美味しそう。食べたい
607 ：[名無し]さん(bin+cue).rar：04/01/07 16:19 ID:s9wJ0WLG
C#で作るぐらいならJavaで組む
608 ：[名無し]さん(bin+cue).rar：04/01/07 16:21 ID:Pu1hZKwO
609 ：[名無し]さん(bin+cue).rar：04/01/07 17:31 ID:fHlVS3Wi
漏れはM$嫌いだからJAVA。マクでも動くし
610 ：[名無し]さん(bin+cue).rar：04/01/07 17:34 ID:bUr6OdaL
M$嫌いならなおさらC++でしょ
Winで動かなくなるし
Winで動かなくなるし
611 ：[名無し]さん(bin+cue).rar：04/01/07 19:21 ID:Kl0H0vGv
Microsoft Visual C++
http://www.microsoft.com/japan/msdn/visualc/
http://www.microsoft.com/japan/msdn/visualc/
612 ：[名無し]さん(bin+cue).rar：04/01/07 19:25 ID:Pu1hZKwO
>>610
Linux使い？
Linux使い？
613 ：[名無し]さん(bin+cue).rar：04/01/07 23:07 ID:XI7UtmR7
とにかく26氏にはじっくりやってもらいたい
614 ：[名無し]さん(bin+cue).rar：04/01/07 23:24 ID:4v5FxX4q
んだんだ。
47氏だって家宅捜索されなきゃ未だｎｙが最強だったはず。
47氏だって家宅捜索されなきゃ未だｎｙが最強だったはず。
615 ：[名無し]さん(bin+cue).rar：04/01/08 00:13 ID:bHdYwlRY
まだまだnyが最強だけどね
616 ：[名無し]さん(bin+cue).rar：04/01/08 09:23 ID:GkEAxRT6
警察関係者の皆さん
新P2Pソフトを公開 → ユーザーが集まり違法ファイルを流通させる → ファイルのやり取りを記録する
こうすれば簡単に一斉検挙できますよ。
新P2Pソフトを公開 → ユーザーが集まり違法ファイルを流通させる → ファイルのやり取りを記録する
こうすれば簡単に一斉検挙できますよ。
617 ：[名無し]さん(bin+cue).rar：04/01/08 13:48 ID:ClLWjMoH
それを世間様ではおとり捜査といいます
618 ：[名無し]さん(bin+cue).rar：04/01/08 15:38 ID:GkEAxRT6
ttp://internet.watch.impress.co.jp/static/column/jiken/2004/01/07/index.htm
＞おとり捜査は日本では違法のように思われているが、
＞容疑者が最初から犯意があるような場合は合法的な捜査手法と判断されている。
＞おとり捜査は日本では違法のように思われているが、
＞容疑者が最初から犯意があるような場合は合法的な捜査手法と判断されている。
619 ：[名無し]さん(bin+cue).rar：04/01/08 15:40 ID:8yT4Cien
>>618
麻薬の売人や組織暴力と一緒にすんな
麻薬の売人や組織暴力と一緒にすんな
620 ：[名無し]さん(bin+cue).rar：04/01/08 15:45 ID:GkEAxRT6
>>619
＞かつて違法なファイル交換が「オフ交換」――つまり、インターネット上で情報交換を行ない、
＞その後に実際に会ってCD-ROMなどを交換するという仕組みで行なわれていたころは、
＞警察のおとり捜査によって摘発されたケースも少なくなかったと見られる。
＞一般ユーザーのふりをしてメールなどで誘い出し、違法ソフトの入ったCD-ROMを交換しようとしたところで現行犯逮捕、という手法だ。
文句があるなら警察に言ってくれ。
＞かつて違法なファイル交換が「オフ交換」――つまり、インターネット上で情報交換を行ない、
＞その後に実際に会ってCD-ROMなどを交換するという仕組みで行なわれていたころは、
＞警察のおとり捜査によって摘発されたケースも少なくなかったと見られる。
＞一般ユーザーのふりをしてメールなどで誘い出し、違法ソフトの入ったCD-ROMを交換しようとしたところで現行犯逮捕、という手法だ。
文句があるなら警察に言ってくれ。
621 ：[名無し]さん(bin+cue).rar：04/01/08 16:22 ID:G4wp94Z7
まあその場合捜査員が先に受け取ると( ﾟДﾟ)ﾏｽﾞｰなので
そもそもマークされている時点でダメポ
そもそもマークされている時点でダメポ
622 ：[名無し]さん(bin+cue).rar：04/01/08 16:24 ID:0BLV2LiD
>>620
「見られる」って書いてあるけど、INTERNET WATCHが勝手に「見ている」だけでは？
オフ交換で摘発って1件しか聞いた事ないんだが。
あと、47氏の身元はともかく、nyの匿名性を破ったって、匿名で言うような事なのか？
ハッタリな気がしてならんのだが。
公式に言った方がユーザー減らせるのは明らかなのにね。
「見られる」って書いてあるけど、INTERNET WATCHが勝手に「見ている」だけでは？
オフ交換で摘発って1件しか聞いた事ないんだが。
あと、47氏の身元はともかく、nyの匿名性を破ったって、匿名で言うような事なのか？
ハッタリな気がしてならんのだが。
公式に言った方がユーザー減らせるのは明らかなのにね。
623 ：[名無し]さん(bin+cue).rar：04/01/08 17:22 ID:GkEAxRT6
624 ：[名無し]さん(bin+cue).rar：04/01/08 18:20 ID:G4wp94Z7
多段串状態で転送元までわかるとは思えないが
そこまで追跡できるのならすごいな
全てのノードをトレースするって事だから
ありえねー
そこまで追跡できるのならすごいな
全てのノードをトレースするって事だから
ありえねー
625 ：[名無し]さん(bin+cue).rar：04/01/08 18:47 ID:0BLV2LiD
>>623
ソースを公開してもnyの匿名性については問題なかったらしいからさ。
クラックされやすくなっちゃうけど。
それが嘘なら元も子もないがね。
ただ、本当に匿名性を破ったなら公式に言わないのはおかしいんじゃないかな。
MXも2年間逮捕者出てないんだし、これじゃハッタリだと思われるのが当然だろう。
ソースを公開してもnyの匿名性については問題なかったらしいからさ。
クラックされやすくなっちゃうけど。
それが嘘なら元も子もないがね。
ただ、本当に匿名性を破ったなら公式に言わないのはおかしいんじゃないかな。
MXも2年間逮捕者出てないんだし、これじゃハッタリだと思われるのが当然だろう。
626 ：[名無し]さん(bin+cue).rar：04/01/08 18:49 ID:etVRFQYT
そもそもnyの匿名性には疑問があるが、お前ら信者に何言っても無駄だろうな。
それに非オープンソースのソースコードだぜ？穴だらけに決まってるだろう。
ヘッダを多少弄るだけで匿名性に関する機構が無効化されてしまう様な穴が
沢山あるだろうさ。
それに非オープンソースのソースコードだぜ？穴だらけに決まってるだろう。
ヘッダを多少弄るだけで匿名性に関する機構が無効化されてしまう様な穴が
沢山あるだろうさ。
627 ：[名無し]さん(bin+cue).rar：04/01/08 18:52 ID:etVRFQYT
お前らはマイクロソフト製品は安全だと
絶対の自信を持って言っているアホと同じに見えるよ。
絶対の自信を持って言っているアホと同じに見えるよ。
628 ：[名無し]さん(bin+cue).rar：04/01/08 18:58 ID:d3NfGiL6
匿名性ってキーの上書きによる中継だけだろ、
こんな小さなことに穴があるとも思えんが。
こんな小さなことに穴があるとも思えんが。
629 ：[名無し]さん(bin+cue).rar：04/01/08 18:58 ID:UI9CRppS
630 ：[名無し]さん(bin+cue).rar：04/01/08 19:40 ID:fnYyO7dr
P2PWiki にあった無差別XOR方式に対して意見。
・ブロックサイズを固定にしてすべてのファイルサイズを統一する。
→1つのファイルのためにそれなりのファイル数集める必要があるため、
数が多いからキーデータがないと元データの復元が不可能。
≒ キーが無きゃキャッシュはただのゴミ。(問題点 x4)
→数が多いため意図的に流したキャッシュが使われても、その対応するブロックの
転送者を特定しにくい。( メモリダンプで見れるから確実じゃない。 ) (問題点 x2)
→ブロックごとに違うタネを使うから多重ダウンも可能。(問題点 x5)
なお、ブロックサイズで半端になる分はランダムデータで埋めておく。
当然逆変換時に切り落とすわけだが、キャッシュで持ってれば再利用できる。
・ＵＰファイルはすぐに周囲ノードに転送。ついでに多重化して送っておく。(問題点 x7)
→オンラインじゃなきゃＵＰできないが……ADSLレベルを期待して問題ないんじゃないかなぁ…
あと、「拡散に使ってもよい帯域」を設定して、キャッシュ普及をたくさんすれば問題点x6軽減かな。
既出ならゴメン。問題点とかあったらツッコミおねがい。
多分スレ違いではないと思っているけど…
・ブロックサイズを固定にしてすべてのファイルサイズを統一する。
→1つのファイルのためにそれなりのファイル数集める必要があるため、
数が多いからキーデータがないと元データの復元が不可能。
≒ キーが無きゃキャッシュはただのゴミ。(問題点 x4)
→数が多いため意図的に流したキャッシュが使われても、その対応するブロックの
転送者を特定しにくい。( メモリダンプで見れるから確実じゃない。 ) (問題点 x2)
→ブロックごとに違うタネを使うから多重ダウンも可能。(問題点 x5)
なお、ブロックサイズで半端になる分はランダムデータで埋めておく。
当然逆変換時に切り落とすわけだが、キャッシュで持ってれば再利用できる。
・ＵＰファイルはすぐに周囲ノードに転送。ついでに多重化して送っておく。(問題点 x7)
→オンラインじゃなきゃＵＰできないが……ADSLレベルを期待して問題ないんじゃないかなぁ…
あと、「拡散に使ってもよい帯域」を設定して、キャッシュ普及をたくさんすれば問題点x6軽減かな。
既出ならゴメン。問題点とかあったらツッコミおねがい。
多分スレ違いではないと思っているけど…
631 ：[名無し]さん(bin+cue).rar：04/01/08 20:10 ID:Kc9jQA4L
>>626
winnyに満足していればここには来ない。
匿名性に疑問があるなら試しに言ってみてくれ。
最近ネタないから、既出の問題点でもかまわんし。
>>630
全部wikiに書いてある気がするんだが?
＞・ブロックサイズを固定にしてすべてのファイルサイズを統一する。
問題点x5の解決法に、「ブロックを 2^n サイズにするのではなく、64kB など
小さい固定長にすれば多重ダウンとほぼ同じことが可能」と書いてある。
＞・ＵＰファイルはすぐに周囲ノードに転送。ついでに多重化して送っておく。
問題点x6の解決法に「キャッシュ強制拡散、冗長性管理などの機構が必要」と書いてある。
winnyに満足していればここには来ない。
匿名性に疑問があるなら試しに言ってみてくれ。
最近ネタないから、既出の問題点でもかまわんし。
>>630
全部wikiに書いてある気がするんだが?
＞・ブロックサイズを固定にしてすべてのファイルサイズを統一する。
問題点x5の解決法に、「ブロックを 2^n サイズにするのではなく、64kB など
小さい固定長にすれば多重ダウンとほぼ同じことが可能」と書いてある。
＞・ＵＰファイルはすぐに周囲ノードに転送。ついでに多重化して送っておく。
問題点x6の解決法に「キャッシュ強制拡散、冗長性管理などの機構が必要」と書いてある。
632 ：[名無し]さん(bin+cue).rar：04/01/08 20:47 ID:fnYyO7dr
>>631
あわわわ・・・・ごめんなさい！
回線切って首吊ってきまつ…
ところで、このスレって結局現在はどういう段階なんでしょ？
いつまでも仕様について話してても仕方ないし、どこかで
次の段階にすすむべきじゃないかなぁ…などと思いながら...
回線切って首吊ってきまつ。
あわわわ・・・・ごめんなさい！
回線切って首吊ってきまつ…
ところで、このスレって結局現在はどういう段階なんでしょ？
いつまでも仕様について話してても仕方ないし、どこかで
次の段階にすすむべきじゃないかなぁ…などと思いながら...
回線切って首吊ってきまつ。
633 ：[名無し]さん(bin+cue).rar：04/01/08 20:49 ID:UI9CRppS
634 ：[名無し]さん(bin+cue).rar：04/01/08 21:12 ID:56CIz5Xc
このスレで開発に取りかかってる人って２６氏だけ？ムームーとかどうなったんだろ。
作ってんのかな？
作ってんのかな？
635 ：[名無し]さん(bin+cue).rar：04/01/08 21:12 ID:g4pN1SRz
良い仕様が出たらやる気のある奴がそれを実装すれば良し。
636 ：[名無し]さん(bin+cue).rar：04/01/08 21:52 ID:psE+VbxP
【WinMX】ﾌｧｲﾙ交換ｿﾌﾄでわいせつ画像を公開【逮捕】
http://news5.2ch.net/test/read.cgi/newsplus/1073548855/
http://age.tubo.80.kg/upl2/img/960.mpg
http://news5.2ch.net/test/read.cgi/newsplus/1073548855/
http://age.tubo.80.kg/upl2/img/960.mpg
637 ：[名無し]さん(bin+cue).rar：04/01/08 21:54 ID:fnYyO7dr
638 ：[名無し]さん(bin+cue).rar：04/01/08 22:06 ID:aEsuIyZG
今のところ26氏とCELLA(´Д｀)氏が作成ちゅ。（>>555）
639 ：[名無し]さん(bin+cue).rar：04/01/08 22:19 ID:ekKpNUrF
京都府警内の人の内部告発に期待したいところだが
公務員は色々しがらみあって難しいだろうな。
公務員は色々しがらみあって難しいだろうな。
640 ：[名無し]さん(bin+cue).rar：04/01/08 22:21 ID:UYs4u2e0
>>639
一般公務員ならまだしも、警察は特にアレだからな。
一般公務員ならまだしも、警察は特にアレだからな。
641 ：[名無し]さん(bin+cue).rar：04/01/08 23:06 ID:5fzSWPK7
郵便屋で郵送しる
642 ：[名無し]さん(bin+cue).rar：04/01/08 23:55 ID:ZV+N+KiA
手軽にP2Pファイル交換の実験ができるスクリプト言語とかできないかな？
接続許可条件とかＤＬするファイルとか、if文とかで
簡単なスクリプトを書くだけで自由に設定・変更できるの。
接続許可条件とかＤＬするファイルとか、if文とかで
簡単なスクリプトを書くだけで自由に設定・変更できるの。
643 ： ◆Fw0Kir8iYA ：04/01/09 00:35 ID:vIswp9EI
wikiの「隣接ノードに情報を漏らさないver2」を更新しました。
あまりにも長文になってしまったので、全部読まなくても大体の内容がわかるよう、
要約をつけてみました。今まで、「こんな長文読めるか!!」とお怒りだった方は、
「１．緒言」、「２．ファイル転送システムの概略」、「４．メリット・デメリット」の3項目だけでも
読んでいただければ幸いです。
>>637
実は>>631は私だったりします。
また、wikiのトップに、
＞2chスレで出た内容を追加（コメントありがとうございました m(_ _)m ）
とありますが、この日議論していた2人のうち一方も私だったりします。
無作為XORは個人的にはかなり面白いアイデアだと思っています。がんばってください。
あまりにも長文になってしまったので、全部読まなくても大体の内容がわかるよう、
要約をつけてみました。今まで、「こんな長文読めるか!!」とお怒りだった方は、
「１．緒言」、「２．ファイル転送システムの概略」、「４．メリット・デメリット」の3項目だけでも
読んでいただければ幸いです。
>>637
実は>>631は私だったりします。
また、wikiのトップに、
＞2chスレで出た内容を追加（コメントありがとうございました m(_ _)m ）
とありますが、この日議論していた2人のうち一方も私だったりします。
無作為XORは個人的にはかなり面白いアイデアだと思っています。がんばってください。
644 ：[名無し]さん(bin+cue).rar：04/01/09 01:27 ID:yffMuZbZ
>>642
そのスクリプト言語で、むーむー氏の言ってたノード評価みたいなのを
扱えるようにするとかなり面白いことになる気がする。
・各ノードは他のノードやファイルに対する自分の評価（点数）を自由に設定できる
・スクリプトのコマンドで、任意のノードからの、別のノードやファイルへの評価を参照できる
・評価に応じてファイルをＤＬするか、相手の要求を受け入れるかどうか等を決定
・たくさんのノードから信頼されているノードの評価がより信頼できる、など色々考えられる
・要求はファイル要求の他に、転送の協力・グリッドコンピューティングなど
そのスクリプト言語で、むーむー氏の言ってたノード評価みたいなのを
扱えるようにするとかなり面白いことになる気がする。
・各ノードは他のノードやファイルに対する自分の評価（点数）を自由に設定できる
・スクリプトのコマンドで、任意のノードからの、別のノードやファイルへの評価を参照できる
・評価に応じてファイルをＤＬするか、相手の要求を受け入れるかどうか等を決定
・たくさんのノードから信頼されているノードの評価がより信頼できる、など色々考えられる
・要求はファイル要求の他に、転送の協力・グリッドコンピューティングなど
645 ：[名無し]さん(bin+cue).rar：04/01/09 02:46 ID:WOZ4MNjB
646 ：[名無し]さん(bin+cue).rar：04/01/09 03:19 ID:BNY9KCUG
Winnyの匿名性は「Upしてる本人かどうかが不明」なだけ。
それはプロトコルで実装されている。
その匿名性は暗号化とは無関係だし、ソースが公開されていても影響はない。
暗号を解読とWinnyの持つ匿名性を破ることは無関係。
このスレで求められている匿名性は、このＷｉｎｎｙよりもさらに匿名性が高いものなんだろ？
それはプロトコルで実装されている。
その匿名性は暗号化とは無関係だし、ソースが公開されていても影響はない。
暗号を解読とWinnyの持つ匿名性を破ることは無関係。
このスレで求められている匿名性は、このＷｉｎｎｙよりもさらに匿名性が高いものなんだろ？
647 ：[名無し]さん(bin+cue).rar：04/01/09 04:39 ID:kjUP6vPV
Winnyの問題点はアップしてると別のルートで宣言すると直接繋げて落とせたらアウト判定できることだから
より匿名性を高くするならここを直せばいい。
より匿名性を高くするならここを直せばいい。
648 ：[名無し]さん(bin+cue).rar：04/01/09 08:05 ID:rZDhrD4C
http://internet.watch.impress.co.jp/static/column/jiken/2004/01/07/7
こんなの出てた。
学校板の協力があれば個人を特定する事が可能かもな。
こんなの出てた。
学校板の協力があれば個人を特定する事が可能かもな。
649 ：[名無し]さん(bin+cue).rar：04/01/09 08:06 ID:rZDhrD4C
すまん。
あげちまった。
あげちまった。
650 ：[名無し]さん(bin+cue).rar：04/01/09 08:06 ID:v85IkxSC
nyで自分の建てスレで告知しなけりゃそれで良いって言う説もあるけどな。
651 ：[名無し]さん(bin+cue).rar：04/01/09 08:09 ID:rZDhrD4C
今なら配布手段として26氏の物もあることだし。
開発続けようと思えばできると思うけどきっとネットは警察の監視付きだろうな。
開発続けようと思えばできると思うけどきっとネットは警察の監視付きだろうな。
652 ：[名無し]さん(bin+cue).rar：04/01/09 09:19 ID:hj8O3rVX
いくら匿名性を高めようが結局は逮捕者が出る罠
653 ：[名無し]さん(bin+cue).rar：04/01/09 10:09 ID:1WG8x52x
何処の国もネットを検閲している！
憂慮すべき時が遂に訪れた。
我々はFreenetに救いを求めるしか道はないのだろうか。。。
憂慮すべき時が遂に訪れた。
我々はFreenetに救いを求めるしか道はないのだろうか。。。
654 ：[名無し]さん(bin+cue).rar：04/01/09 10:55 ID:7lNoF+RQ
655 ：[名無し]さん(bin+cue).rar：04/01/09 11:25 ID:yffMuZbZ
>>644
・要求に応えてくれたノードの評価は上げる
・価値観の合うノード同士のクラスタ化が期待できる
と言うわけだね。
>>654
全然違う。freenetは匿名性が高い代わりにファイル転送効率が極端に低い。
・要求に応えてくれたノードの評価は上げる
・価値観の合うノード同士のクラスタ化が期待できる
と言うわけだね。
>>654
全然違う。freenetは匿名性が高い代わりにファイル転送効率が極端に低い。
656 ：[名無し]さん(bin+cue).rar：04/01/09 11:29 ID:7lNoF+RQ
657 ：[名無し]さん(bin+cue).rar：04/01/09 11:45 ID:edFN9dNh
>>648
Not Found
Not Found
658 ：[名無し]さん(bin+cue).rar：04/01/09 12:07 ID:wMPQd9Uw
>>656
>・一つのノードから全てのファイルデータが落とされることがある
まさか、そんなことはないですよ、使ってみればわかりますが
1MBくらいのファイルでも10個程度に分割されますしばらばらに転送されますから
>・一つのノードから全てのファイルデータが落とされることがある
まさか、そんなことはないですよ、使ってみればわかりますが
1MBくらいのファイルでも10個程度に分割されますしばらばらに転送されますから
659 ：[名無し]さん(bin+cue).rar：04/01/09 12:10 ID:7lNoF+RQ
660 ：[名無し]さん(bin+cue).rar：04/01/09 12:15 ID:IUIe/luz
>>659
全部で２台しかないとか？
全部で２台しかないとか？
661 ：[名無し]さん(bin+cue).rar：04/01/09 12:19 ID:7lNoF+RQ
662 ：[名無し]さん(bin+cue).rar：04/01/09 12:22 ID:wMPQd9Uw
>>659
でもnyと違ってツール使ってキャッシュの中身確認できないですし
完全キャッシュはnyと違ってないわけですよね分割したファイルしか。
nyの場合接続が切れずに一人の人からDL出来る場合もありますから、nyより
は安全なのではないでしょうか。
でもnyと違ってツール使ってキャッシュの中身確認できないですし
完全キャッシュはnyと違ってないわけですよね分割したファイルしか。
nyの場合接続が切れずに一人の人からDL出来る場合もありますから、nyより
は安全なのではないでしょうか。
663 ：[名無し]さん(bin+cue).rar：04/01/09 12:33 ID:wMPQd9Uw
>>659
それに直接にしては掲示板のメッセージはまるでリアルタイムじゃないです。
ほとんど2時間くらいは最低でもレスするのに時間がかかってます。
直接DLしてることがあるのでしたらもっと早いのもあっていいと思いますが。
それに直接にしては掲示板のメッセージはまるでリアルタイムじゃないです。
ほとんど2時間くらいは最低でもレスするのに時間がかかってます。
直接DLしてることがあるのでしたらもっと早いのもあっていいと思いますが。
664 ：[名無し]さん(bin+cue).rar：04/01/09 12:53 ID:IUIe/luz
A
／ ＼
B ── C
３台だとネットというよりは、リンクの感じだね。
／ ＼
B ── C
３台だとネットというよりは、リンクの感じだね。
665 ：[名無し]さん(bin+cue).rar：04/01/09 17:27 ID:hguMzzmX
インターネット上に一つでも完璧に近い匿名空間があると、
色々と応用が利くから違法コピー捜査関係者はfreenetをﾀﾞｳｿ板で強調されるとマズイのです。
それでfreenetスレに食って掛かったり、このスレで噛み付いて
freenetの匿名性は「低い」ということにしたいらしい。
しかしfreenetは対国家P2Pです。CIAや各国政府などにも脅かされない
基本構造。そのかわり動作はﾏﾀｰﾘ。
別にこんなトコで聞かなくてもfreenetの匿名性の情報に関しては少しググれば
誰でも手に入る。
そんなことも知らない厨房が仕様スレなんかに来るなよ。
色々と応用が利くから違法コピー捜査関係者はfreenetをﾀﾞｳｿ板で強調されるとマズイのです。
それでfreenetスレに食って掛かったり、このスレで噛み付いて
freenetの匿名性は「低い」ということにしたいらしい。
しかしfreenetは対国家P2Pです。CIAや各国政府などにも脅かされない
基本構造。そのかわり動作はﾏﾀｰﾘ。
別にこんなトコで聞かなくてもfreenetの匿名性の情報に関しては少しググれば
誰でも手に入る。
そんなことも知らない厨房が仕様スレなんかに来るなよ。
666 ：[名無し]さん(bin+cue).rar：04/01/09 17:58 ID:SX0nTv26
Freenetの匿名性は高いけど、他の匿名性低いところで放流宣言されたらFreenetといえども逮捕できるって言いたいんでしょ。
これはnyでも同じだし、たぶん今回の騒ぎはこれだし。
これはnyでも同じだし、たぶん今回の騒ぎはこれだし。
667 ：[名無し]さん(bin+cue).rar：04/01/09 19:34 ID:cWHbniFc
定期あげ
668 ：[名無し]さん(bin+cue).rar：04/01/09 19:35 ID:cWHbniFc
すまそ誤爆
669 ：[名無し]さん(bin+cue).rar：04/01/09 19:43 ID:QqnaTkXv
完璧な匿名性なんて無いんです。
クラック不可能なソフトが無いように。
厨房はその辺が判らないんです。
人の話鵜呑みにしてるただのバカなんです。
クラック不可能なソフトが無いように。
厨房はその辺が判らないんです。
人の話鵜呑みにしてるただのバカなんです。
670 ：[名無し]さん(bin+cue).rar：04/01/09 19:59 ID:wrSaERXu
>>669
Freenetはほとんど完璧ですよ。
それを覆したいなら、海外で定説化している検証を引用しながら覆して
見せてください。
で、そういうのはここではなくFreenetスレでやって下さい。
>>666
逆。
放流宣言や暗号化ファイルのパスワード公開をFreenetでやられると
捜査上非常に厄介なことになるンです。
ともかく、こういう解りきったことを今更ここのスレ住人にいったって釈迦に説法。
↓こちらで
Freenet
http://tmp2.2ch.net/test/read.cgi/download/1072973943/
Freenetはほとんど完璧ですよ。
それを覆したいなら、海外で定説化している検証を引用しながら覆して
見せてください。
で、そういうのはここではなくFreenetスレでやって下さい。
>>666
逆。
放流宣言や暗号化ファイルのパスワード公開をFreenetでやられると
捜査上非常に厄介なことになるンです。
ともかく、こういう解りきったことを今更ここのスレ住人にいったって釈迦に説法。
↓こちらで
Freenet
http://tmp2.2ch.net/test/read.cgi/download/1072973943/
671 ：[名無し]さん(bin+cue).rar：04/01/09 20:22 ID:xwzkaczd
なんかキモいのが一匹いるな
672 ：[名無し]さん(bin+cue).rar：04/01/09 20:26 ID:WJyw2/q7
>>670
転送されてきたデータから著作権のあるファイルに復元出来た場合、
例えそれが元ファイルの100分の1でも逮捕される可能性はあるからね。
分割されてれば逮捕し難いってだけ。
今回のny逮捕劇にしても放流主の匿名性なんてのは全く関係なさそうだし。
完璧なんてありえないよ。
転送されてきたデータから著作権のあるファイルに復元出来た場合、
例えそれが元ファイルの100分の1でも逮捕される可能性はあるからね。
分割されてれば逮捕し難いってだけ。
今回のny逮捕劇にしても放流主の匿名性なんてのは全く関係なさそうだし。
完璧なんてありえないよ。
673 ：[名無し]さん(bin+cue).rar：04/01/09 20:29 ID:MpOMDvbx
放置しる。
674 ：[名無し]さん(bin+cue).rar：04/01/09 20:33 ID:SBMTD4KT
ID:wrSaERXu
675 ：[名無し]さん(bin+cue).rar：04/01/09 20:37 ID:G733JwlI
>>672
↓こちらでこのスレの1にあるリンク先を全て熟読した上でどうぞ。
Freenet
http://tmp2.2ch.net/test/read.cgi/download/1072973943/
では以後この仕様スレでFreenetの話題はスルーで。
荒らしは今までどおり放置で。
↓こちらでこのスレの1にあるリンク先を全て熟読した上でどうぞ。
Freenet
http://tmp2.2ch.net/test/read.cgi/download/1072973943/
では以後この仕様スレでFreenetの話題はスルーで。
荒らしは今までどおり放置で。
676 ：[名無し]さん(bin+cue).rar：04/01/09 21:25 ID:1nVnu8xc
Freenetに限らず、既存のP2Pの技術的な議論はしても構わないと思うんだが･･･
まあ、ループするとうざいか・・・
まあ、ループするとうざいか・・・
677 ：[名無し]さん(bin+cue).rar：04/01/09 21:28 ID:9CufC1e6
技術的な議論ならな
678 ：[名無し]さん(bin+cue).rar：04/01/09 21:39 ID:MvN9JWG4
仕様決定まだー？(・ε・)
679 ：[名無し]さん(bin+cue).rar：04/01/09 22:03 ID:1JFr394r
キャッシュ自動消滅があるとなぁ
用途によっては困ったことになる
用途によっては困ったことになる
680 ：[名無し]さん(bin+cue).rar：04/01/10 06:18 ID:otGf3EkE
自動消滅しても問題ないと思うよ。
消滅するとしても、それは人気の低いやつでしょ。
消滅するとしても、それは人気の低いやつでしょ。
681 ：[名無し]さん(bin+cue).rar：04/01/10 07:20 ID:tnrfCWgk
レアなファイルがどんどん消えて似たようなファイルだらけに
なるっていうのもな～．．．
なるっていうのもな～．．．
682 ：[名無し]さん(bin+cue).rar：04/01/10 09:20 ID:kNv1DuE8
その辺りのバランスが一番難しいところだと思う。
あとは大量の共有物を持って、一気に参入してきた人のキャッシュがどれくらいのスピードで拡散するかとか、
拡散が不十分な時にデータの一部を受け取ったノードがデータを消すなりP2P止めるなりして、
復号が出来なくなってしまったらどうするのかとか。
あとは大量の共有物を持って、一気に参入してきた人のキャッシュがどれくらいのスピードで拡散するかとか、
拡散が不十分な時にデータの一部を受け取ったノードがデータを消すなりP2P止めるなりして、
復号が出来なくなってしまったらどうするのかとか。
683 ：[名無し]さん(bin+cue).rar：04/01/10 10:01 ID:otGf3EkE
とりあえず、どうやって流通量を調べるのがいいかな。
流通量さえわかれば色々応用できるからな。
流通量さえわかれば色々応用できるからな。
684 ：[名無し]さん(bin+cue).rar：04/01/10 22:28 ID:DucuDUks
Pre-alphaの仕様でたね。
685 ：[名無し]さん(bin+cue).rar：04/01/11 13:58 ID:4ObzBAPm
BBSにアップローダ機能が欲しい
686 ：[名無し]さん(bin+cue).rar：04/01/11 21:14 ID:iT1vyIxC
仕様まとまったのか？
687 ：[名無し]さん(bin+cue).rar：04/01/11 21:30 ID:epf+t+k2
つーか、仕様自体、出尽くしてるのか？
なんとか5月の連休くらいまでには
β版くらい出てて欲しいと思う今日この頃。
なんとか5月の連休くらいまでには
β版くらい出てて欲しいと思う今日この頃。
688 ：[名無し]さん(bin+cue).rar：04/01/11 21:42 ID:ilr7e2M7
P2Pでの匿名通信路（実践編）
http://member.nifty.ne.jp/tnishita/p2p/tokumei3.html
http://member.nifty.ne.jp/tnishita/p2p/tokumei3.html
689 ：[名無し]さん(bin+cue).rar：04/01/11 22:00 ID:RLziKOZo
>>688
このサイトって４７氏が作ってるっぽくない？
このサイトって４７氏が作ってるっぽくない？
690 ：[名無し]さん(bin+cue).rar：04/01/12 00:02 ID:M9qdhj7l
ttp://www.flets.com/dotnet/f_tenso.html
これの
「フレッツ・ドットネットでは、パソコンごとに登録できるFdNネームを使って、パソコンどうしをダイレクトに接続します。
インターネットやサーバを経由しないので、サーバの容量制限を受けることなく、メッセージはもちろんメールでは送信できないような動画などの大容量ファイルもスムーズに送信できます。」
こういうのうまく使えないものかのぉ。
これの
「フレッツ・ドットネットでは、パソコンごとに登録できるFdNネームを使って、パソコンどうしをダイレクトに接続します。
インターネットやサーバを経由しないので、サーバの容量制限を受けることなく、メッセージはもちろんメールでは送信できないような動画などの大容量ファイルもスムーズに送信できます。」
こういうのうまく使えないものかのぉ。
691 ：[名無し]さん(bin+cue).rar：04/01/12 01:19 ID:8CvZvvwv
692 ：[名無し]さん(bin+cue).rar：04/01/12 01:41 ID:JkBuznKI
693 ：[名無し]さん(bin+cue).rar：04/01/12 17:37 ID:GAoduYJ2
694 ：[名無し]さん(bin+cue).rar：04/01/13 00:28 ID:aGsbOyO2
意見は出尽くしたようだな・・・
これからどうするよ？このスレ。
これからどうするよ？このスレ。
695 ：[名無し]さん(bin+cue).rar：04/01/13 05:49 ID:EyXtH9pR
696 ：[名無し]さん(bin+cue).rar：04/01/13 07:21 ID:TPXZSdO0
意見は出尽くしてないだろ。結局オープンソースでも大丈夫な仕様は出てないんだから。
697 ：[名無し]さん(bin+cue).rar：04/01/13 11:26 ID:MPTR0KlL
あと>>679-683の辺りとかな。
698 ：[名無し]さん(bin+cue).rar：04/01/13 12:20 ID:7VWCJBPB
>>696
中枢部分だけプラグイン方式にするという案もあるが
中枢部分だけプラグイン方式にするという案もあるが
699 ：[名無し]さん(bin+cue).rar：04/01/13 23:48 ID:uxkzCJMy
age
700 ：[名無し]さん(bin+cue).rar：04/01/13 23:49 ID:MGo+ADWE
701 ：[名無し]さん(bin+cue).rar：04/01/14 00:56 ID:hTSKQlFv
>>642, >>644にスクリプト言語と言う案も出てるな。
結構おもしろそうな感じはするんだが
やっぱりイマイチ具体性というか現実味が無いんだよな…
匿名性に関する議論も出尽くしたようだし、
もう一回時期p2pに求められる事項を整理しなおしてみたらどうだ？
結構おもしろそうな感じはするんだが
やっぱりイマイチ具体性というか現実味が無いんだよな…
匿名性に関する議論も出尽くしたようだし、
もう一回時期p2pに求められる事項を整理しなおしてみたらどうだ？
702 ：[名無し]さん(bin+cue).rar：04/01/14 20:35 ID:MjFt6vtX
１・効率的なデータ配信
２・強いネットワーク耐性
３・データ配信者の匿名性
２・強いネットワーク耐性
３・データ配信者の匿名性
703 ：[名無し]さん(bin+cue).rar：04/01/14 22:54 ID:JUqlC+Qa
次は。効率的なデータ配信についての議論か？
今まで仕様を結構見てきたけど効率的なものが無いんだな。
ただ、匿名性と効率は相反するものだからそこら辺のバランスをどうするかが問題でし。
良い例がﾌﾘﾈとMXだな偏りすぎで・・・。
今まで仕様を結構見てきたけど効率的なものが無いんだな。
ただ、匿名性と効率は相反するものだからそこら辺のバランスをどうするかが問題でし。
良い例がﾌﾘﾈとMXだな偏りすぎで・・・。
704 ：[名無し]さん(bin+cue).rar：04/01/14 23:44 ID:JY7CU3A4
やっぱこれ以上の議論は試作品みてからか
となると神があらわれんうちはどうしようもないな
となると神があらわれんうちはどうしようもないな
705 ：[名無し]さん(bin+cue).rar：04/01/15 00:19 ID:vwf1NgOf
Share(仮称)で実装予定の強制アップってのはどうなんだろ？
706 ：[名無し]さん(bin+cue).rar：04/01/15 00:22 ID:PNJhV3Xc
迫真の(ry
707 ：[名無し]さん(bin+cue).rar：04/01/15 00:24 ID:h2suj5oj
さあ。どんな仕組みにしたいのかまだよくわからんし。
708 ：[名無し]さん(bin+cue).rar：04/01/15 00:25 ID:HdXu2ODm
http://member.nifty.ne.jp/tnishita/p2p/tokumei3.html
このページのMIX-netについては議論されてないよね。
投票にも使われてる堅牢な通信経路みたいだけど、どうなの？
このページのMIX-netについては議論されてないよね。
投票にも使われてる堅牢な通信経路みたいだけど、どうなの？
709 ：[名無し]さん(bin+cue).rar：04/01/15 00:26 ID:vwf1NgOf
安全性と効率性を両立できる良案だと思うんだけどね。
問題はShare(仮称)にはまだ実装されてないって事だな・・・。
問題はShare(仮称)にはまだ実装されてないって事だな・・・。
710 ：[名無し]さん(bin+cue).rar：04/01/15 00:31 ID:c9GmzT1d
暗号系統とか、無視リストみたいな
絶対使うだろう部分のDLL公開ギボン
このあたりはフライングしてよさそーじゃない？
絶対使うだろう部分のDLL公開ギボン
このあたりはフライングしてよさそーじゃない？
711 ：[名無し]さん(bin+cue).rar：04/01/15 01:03 ID:c0zGsqEs
「効率的なデータ配信」を実現しようとすれば、誰が何を持っているのか
何を欲しがっているのか、各Peerに通知する必要がある。
何を欲しがっているのか、各Peerに通知する必要がある。
712 ：[名無し]さん(bin+cue).rar：04/01/15 01:07 ID:f6IJB4cf
>>702, >>703
いや、それももちろんそうなんだけどさあ、
その中でも、どういう種類の効率を優先したいのかなんていう話もあるじゃん。
例えば「とにかくたくさんのファイルをＤＬしたい」って言う人も居るかもしれないけど、
実は「自分が欲しいファイルを見つけてそれだけを的確に素早くＤＬしたい」
っていう人のほうが多いんじゃないか、とか俺は思ってたりする。
だから、むやみやたらとファイルを拡散させれば良い、っていうもんでも
ない気がするんだよね。むしろこの場合ファイル検索システムが鍵になる気がする。
で、どうすれば理想的なシステムに仕上がるかってのはやっぱり色々と実験してみなきゃ
分からないわけだけど、どう言う実験をするべきなのかもまとまってないし、
それどころか、どういう状態を理想としているのかも具体的には明確じゃなかったりする。
現状では、とにかく匿名性以外の部分については製作者一人にまかせっきりにして、
出来上がってからものを見てから色々注文を付けよう、みたいなスタンスのようだけど、
それだと作る側としてはやりづらいと思う。とにかく議論すべきことは山のようにある。
みんなで議論を積み重ねてこそのオープンソースだと思うんだけどな。
いや、それももちろんそうなんだけどさあ、
その中でも、どういう種類の効率を優先したいのかなんていう話もあるじゃん。
例えば「とにかくたくさんのファイルをＤＬしたい」って言う人も居るかもしれないけど、
実は「自分が欲しいファイルを見つけてそれだけを的確に素早くＤＬしたい」
っていう人のほうが多いんじゃないか、とか俺は思ってたりする。
だから、むやみやたらとファイルを拡散させれば良い、っていうもんでも
ない気がするんだよね。むしろこの場合ファイル検索システムが鍵になる気がする。
で、どうすれば理想的なシステムに仕上がるかってのはやっぱり色々と実験してみなきゃ
分からないわけだけど、どう言う実験をするべきなのかもまとまってないし、
それどころか、どういう状態を理想としているのかも具体的には明確じゃなかったりする。
現状では、とにかく匿名性以外の部分については製作者一人にまかせっきりにして、
出来上がってからものを見てから色々注文を付けよう、みたいなスタンスのようだけど、
それだと作る側としてはやりづらいと思う。とにかく議論すべきことは山のようにある。
みんなで議論を積み重ねてこそのオープンソースだと思うんだけどな。
713 ：[名無し]さん(bin+cue).rar：04/01/15 02:07 ID:f6IJB4cf
>>710
まず「絶対使うだろう」と思われる部分をリストアップすることから
始めた方が良さそうな気がする。
レジューム機能は必須だろうし、ファイル内容から検索キーを生成するための
ハッシュ関数等は統一した方が便利なんじゃないかな。
>>711
「誰が何を持っているのか」とかも、匿名性のことを考えると
あんまりあからさまには通知できないわけで、例えば
「ノードa、b、cのうちどれかが、それぞれファイルA,B,Cのうちどれかを持っている」
みたいな通知法も考えられるけど、やっぱり効率とのトレードオフになる。
クラスタ化を工夫すれば改善できるかもしれないとか言う話もあるし、
これも議論してみんなで考えたほうが良いだろうね。
まず「絶対使うだろう」と思われる部分をリストアップすることから
始めた方が良さそうな気がする。
レジューム機能は必須だろうし、ファイル内容から検索キーを生成するための
ハッシュ関数等は統一した方が便利なんじゃないかな。
>>711
「誰が何を持っているのか」とかも、匿名性のことを考えると
あんまりあからさまには通知できないわけで、例えば
「ノードa、b、cのうちどれかが、それぞれファイルA,B,Cのうちどれかを持っている」
みたいな通知法も考えられるけど、やっぱり効率とのトレードオフになる。
クラスタ化を工夫すれば改善できるかもしれないとか言う話もあるし、
これも議論してみんなで考えたほうが良いだろうね。
714 ：[名無し]さん(bin+cue).rar：04/01/15 06:06 ID:G23AMsm7
>>679
この自動消滅だけど、人気のあるファイルにこそ自動消滅した方がいいと思うんだけどどうだろうか？
この自動消滅だけど、人気のあるファイルにこそ自動消滅した方がいいと思うんだけどどうだろうか？
715 ：[名無し]さん(bin+cue).rar：04/01/15 06:34 ID:+hJebQ82
>>714
冗長度管理ね。
確かにny方式だと一部の人気ファイルのキャッシュばかりが増えてしまう。
みんなが供出できるストレージ容量は有限だから、あまり偏らないように
するのが理想。
うまくインテリジェントに管理できれば、人気ファイルもレアファイルも
バランスよく手に入るようにできるかも知れない。
冗長度管理については、RAID5マン氏やむーむー氏が考察してたような気が
するけど、どうだったかな。
冗長度管理ね。
確かにny方式だと一部の人気ファイルのキャッシュばかりが増えてしまう。
みんなが供出できるストレージ容量は有限だから、あまり偏らないように
するのが理想。
うまくインテリジェントに管理できれば、人気ファイルもレアファイルも
バランスよく手に入るようにできるかも知れない。
冗長度管理については、RAID5マン氏やむーむー氏が考察してたような気が
するけど、どうだったかな。
716 ：[名無し]さん(bin+cue).rar：04/01/15 08:21 ID:g40zLay3
>>714-715
禿げ同・・・と言いたいが俺は逆がいいと思う
つまり、人気のあるファイルを自動消滅させるのではなく、
人気の無いファイルを拡散させる事により偏りをなくす
・・・のが理想だと思うがどうだろうか？
禿げ同・・・と言いたいが俺は逆がいいと思う
つまり、人気のあるファイルを自動消滅させるのではなく、
人気の無いファイルを拡散させる事により偏りをなくす
・・・のが理想だと思うがどうだろうか？
717 ：[名無し]さん(bin+cue).rar：04/01/15 08:44 ID:+hJebQ82
>>716
一応それも冗長度管理の１つということで。
ネットワーク上にどのファイルがどれだけキャッシュされているか検知して、
それぞれのoexブロックが２だか３セットだけ存在するように強制拡散、または
自動消滅するようにする、という方式を誰かが書いてた覚えがある。
ファイル入手の確実性という意味ではベストという気がするけど、
捏造ファイルも自動的に冗長化されてしまうので対策が必要だよね。
あとは、流行しているファイルは一時的に多めにキャッシュする、という機構も欲しい。
いずれにせよ、ネットワーク上にどれだけキャッシュがあるのか検知する方法が
一番の問題ですな。それさえクリアできれば、あとは簡単だと思うんだけどね。
一応それも冗長度管理の１つということで。
ネットワーク上にどのファイルがどれだけキャッシュされているか検知して、
それぞれのoexブロックが２だか３セットだけ存在するように強制拡散、または
自動消滅するようにする、という方式を誰かが書いてた覚えがある。
ファイル入手の確実性という意味ではベストという気がするけど、
捏造ファイルも自動的に冗長化されてしまうので対策が必要だよね。
あとは、流行しているファイルは一時的に多めにキャッシュする、という機構も欲しい。
いずれにせよ、ネットワーク上にどれだけキャッシュがあるのか検知する方法が
一番の問題ですな。それさえクリアできれば、あとは簡単だと思うんだけどね。
718 ：[名無し]さん(bin+cue).rar：04/01/15 10:22 ID:CbrIOQ3q
人気の無いファイルを優先的に拡散、なんて仕様にしたらHDDがいくらあっても足りんぞ。
719 ：[名無し]さん(bin+cue).rar：04/01/15 10:29 ID:+hJebQ82
そりゃそうだ。
ファイルの人気とストレージの余裕から、ファイルごとにベストな冗長度を割り出して、
それを保つようにインテリジェントに管理できるのが理想かな。
もちろん「ベストな冗長度」が０の場合もあり（場合によっては完全消去もやむなし）
ファイルの人気とストレージの余裕から、ファイルごとにベストな冗長度を割り出して、
それを保つようにインテリジェントに管理できるのが理想かな。
もちろん「ベストな冗長度」が０の場合もあり（場合によっては完全消去もやむなし）
720 ：[名無し]さん(bin+cue).rar：04/01/15 12:05 ID:hysrZtba
どれだけ拡散しているかを把握するのが大変なんだよなぁ。
721 ：[名無し]さん(bin+cue).rar：04/01/15 13:21 ID:ggWISHSL
その辺の調整は非公開にしないといらんことになるから47氏は一人で調整していたんだろうけどな
結論は消さないということのようだが
結論は消さないということのようだが
>>715
うまくまとめてもらってありがとうです。
>>720
素人考えなので、穴があると思うけど
キャッシュのコピー回数を示すものを設けて
コピーが行われるたびにランダムに数字が上がるというシステム
ランダムに数字が上げるのはファイルの最初の配信者を隠すためです。
でも、完璧ではないんだよなぁ
うまくまとめてもらってありがとうです。
>>720
素人考えなので、穴があると思うけど
キャッシュのコピー回数を示すものを設けて
コピーが行われるたびにランダムに数字が上がるというシステム
ランダムに数字が上げるのはファイルの最初の配信者を隠すためです。
でも、完璧ではないんだよなぁ
723 ：[名無し]さん(bin+cue).rar：04/01/15 20:02 ID:TZNusTG5
724 ：[名無し]さん(bin+cue).rar：04/01/15 23:52 ID:+BdDD7w/
>>712
そうだな。
やっぱりむやみやたらとじゃなくて、
自分のほしいファイルをしっかりと掴んで、それを的確にダウンする事が必要だな。
ただ、それだと、拡散以外にもあんたが言ってるように検索機能の向上とか。
あとは捏造に向ける対処とか、いろいろな面での強化が必要に成ってくると思う。
そのノードやファイルの優越を決定するアルゴリズムにも左右されるしね。
まぁ意見を山ほど積み上げて選定していこうよ。
そうだな。
やっぱりむやみやたらとじゃなくて、
自分のほしいファイルをしっかりと掴んで、それを的確にダウンする事が必要だな。
ただ、それだと、拡散以外にもあんたが言ってるように検索機能の向上とか。
あとは捏造に向ける対処とか、いろいろな面での強化が必要に成ってくると思う。
そのノードやファイルの優越を決定するアルゴリズムにも左右されるしね。
まぁ意見を山ほど積み上げて選定していこうよ。
725 ：[名無し]さん(bin+cue).rar：04/01/16 00:58 ID:VmdsbwmQ
726 ：[名無し]さん(bin+cue).rar：04/01/16 11:13 ID:AL92reju
新ソフト同士は普通に通信可能で
nyからは一方的に吸えるソフトにすれば一気に次世代機になるな。
nyからは一方的に吸えるソフトにすれば一気に次世代機になるな。
727 ：[名無し]さん(bin+cue).rar：04/01/16 11:14 ID:AL92reju
ついでにage
728 ：[名無し]さん(bin+cue).rar：04/01/16 16:52 ID:w5CfaqfS
>>726
SONYのゲーム機みたいだなw
SONYのゲーム機みたいだなw
729 ：[名無し]さん(bin+cue).rar：04/01/16 17:49 ID:yRM9wW9e
>>726
一方的に吸える=Crack成功とほぼ同義では
一方的に吸える=Crack成功とほぼ同義では
730 ：小太郎 ◆r7Y88Tobf2 ：04/01/16 20:24 ID:s8UqDbfc
ずっとROMしていたんですけどみなさんが困っているようなので投票することにしました。
これは思い切った考えで反対派の人も多いと思いますけど
聞いてください。たとえばA君とB君という人たちがいるとします。
そしてAがBにキューを入れた瞬間そのファイルはそのとき共有ソフトを
使ってる人と同じ数だけ分割され、全ての人を通ってAに行くという
仕組みです。
図に表すとこうなります。＞
これの利点
・絶対UPをしなくてはいけないのでDOMはできない
・接続すると絶対うｐしなくてはいかないので警察も巻き添えにできる
・多分、ぼくが考えてるなかではかなり転送速度は上がるはず
これは賛成派が多ければ作ってみようと思います。
これは思い切った考えで反対派の人も多いと思いますけど
聞いてください。たとえばA君とB君という人たちがいるとします。
そしてAがBにキューを入れた瞬間そのファイルはそのとき共有ソフトを
使ってる人と同じ数だけ分割され、全ての人を通ってAに行くという
仕組みです。
図に表すとこうなります。＞
これの利点
・絶対UPをしなくてはいけないのでDOMはできない
・接続すると絶対うｐしなくてはいかないので警察も巻き添えにできる
・多分、ぼくが考えてるなかではかなり転送速度は上がるはず
これは賛成派が多ければ作ってみようと思います。
731 ：[名無し]さん(bin+cue).rar：04/01/16 20:25 ID:s8UqDbfc
732 ：小太郎 ◆8DcQWhttmU ：04/01/16 20:27 ID:s8UqDbfc
意見をどうぞお願いします。ｍ（＿ ＿）ｍ
733 ：[名無し]さん(bin+cue).rar：04/01/16 20:29 ID:s8UqDbfc
ほう・・・
734 ：[名無し]さん(bin+cue).rar：04/01/16 20:52 ID:al2cqs5D
ネタかw
735 ：[名無し]さん(bin+cue).rar：04/01/16 21:02 ID:jw5pcFNK
>>731
これはすごい！すごすぎる！
これはすごい！すごすぎる！
736 ：小太郎 ◆r7Y88Tobf2 ：04/01/16 21:04 ID:s8UqDbfc
図はめちゃめちゃ手抜きですｗご了承を
737 ：[名無し]さん(bin+cue).rar：04/01/16 21:07 ID:EByRDXtE
738 ：[名無し]さん(bin+cue).rar：04/01/16 21:14 ID:s044/Gqj
>>736
PCの負荷がどうなるのか考えてみましょう。
PCの負荷がどうなるのか考えてみましょう。
739 ：小太郎 ◆8DcQWhttmU ：04/01/16 21:39 ID:s8UqDbfc
負担は何とか軽くできると思います
740 ：[名無し]さん(bin+cue).rar：04/01/16 21:43 ID:xYYltm+G
分割する同じファイルもってない状態は
どうなるんですか？
そのときは ＵＰしないとＤＬできない矛盾はないですか？
どうなるんですか？
そのときは ＵＰしないとＤＬできない矛盾はないですか？
741 ：小太郎 ◆r7Y88Tobf2 ：04/01/16 21:49 ID:s8UqDbfc
>>740
言ってることがよくわかりましぇ～ん
言ってることがよくわかりましぇ～ん
742 ：[名無し]さん(bin+cue).rar：04/01/16 21:51 ID:al2cqs5D
743 ：[名無し]さん(bin+cue).rar：04/01/16 21:53 ID:s8UqDbfc
この方法には大きな欠点が何個かあります。
１・多分すごい数の分割ファイルになるので、ファイルが無くなる可能性が
高い
２・DOWNしている途中で何人かが切断
これは高い補完機能をつけてカバーするつもりです。
１・多分すごい数の分割ファイルになるので、ファイルが無くなる可能性が
高い
２・DOWNしている途中で何人かが切断
これは高い補完機能をつけてカバーするつもりです。
744 ：[名無し]さん(bin+cue).rar：04/01/16 21:57 ID:gdfsHAG6
皆が
仮想HUB公開して(ログOFF)、DHCP鯖立てておく
最低１つ仮想HUB同士をブリッジする
を繰り返すとネットワーク破綻かな
でもひろゆきみたいに訴えられてお金はなくなるな。
仮想HUB公開して(ログOFF)、DHCP鯖立てておく
最低１つ仮想HUB同士をブリッジする
を繰り返すとネットワーク破綻かな
でもひろゆきみたいに訴えられてお金はなくなるな。
745 ：[名無し]さん(bin+cue).rar：04/01/16 21:59 ID:P4XcUfh+
>744
仮想ハブたてまくって、つなぎまくったら、
ねっとびゅーいのトラフィックで破綻しないかな。
仮想ハブたてまくって、つなぎまくったら、
ねっとびゅーいのトラフィックで破綻しないかな。
746 ：[名無し]さん(bin+cue).rar：04/01/16 22:03 ID:gdfsHAG6
するんだろーな。
そんときはそんとき
なんかインターネットの中にインターネット作るっていいな。
そんときはそんとき
なんかインターネットの中にインターネット作るっていいな。
747 ：[名無し]さん(bin+cue).rar：04/01/16 22:13 ID:nYXkDM1L
すまん次世代共有ソフトさっき思いついた。
しかもかなりバカバカしい仕様。
でもおそらく反論できない。
WinnyやMXの発想から離れれば何のことはない、
匿名性は結果であってP2P真の目的ではない。
カンのいい奴なら気付くと思う、
コロンブスの卵ってやつ。
よって俺の中でこの議論は終結した。
しかもかなりバカバカしい仕様。
でもおそらく反論できない。
WinnyやMXの発想から離れれば何のことはない、
匿名性は結果であってP2P真の目的ではない。
カンのいい奴なら気付くと思う、
コロンブスの卵ってやつ。
よって俺の中でこの議論は終結した。
748 ：[名無し]さん(bin+cue).rar：04/01/16 22:15 ID:jw5pcFNK
す
し
で
Wi
匿
カ
コ
よ
し
で
Wi
匿
カ
コ
よ
749 ：小太郎 ◆r7Y88Tobf2 ：04/01/16 22:15 ID:s8UqDbfc
だから、ぼくは警察を巻き添えにするという方法を考えたのじゃないですか
750 ：[名無し]さん(bin+cue).rar：04/01/16 22:22 ID:nYXkDM1L
>749
著作権法違反は著作者の許可が無い場合だから、
警察が著作者の許可得てればUPも無問題。
著作権法違反は著作者の許可が無い場合だから、
警察が著作者の許可得てればUPも無問題。
751 ：小太郎 ◆r7Y88Tobf2 ：04/01/16 22:25 ID:s8UqDbfc
>>750
そうですか・・・あきらめます
そうですか・・・あきらめます
752 ：[名無し]さん(bin+cue).rar：04/01/16 22:35 ID:aKhPzMKx
753 ：[名無し]さん(bin+cue).rar：04/01/16 22:53 ID:Ll853o6t
素人も意見ですが
nyのBBSを2chのようにサーバーに書き込むようにはできないのでしょうか？
ただし、それだとスレが永遠に残ってしまうので時間寿命を設けたらどうでしょうか？
技術的に受け入れられないようでしたらスルーして下さい
nyのBBSを2chのようにサーバーに書き込むようにはできないのでしょうか？
ただし、それだとスレが永遠に残ってしまうので時間寿命を設けたらどうでしょうか？
技術的に受け入れられないようでしたらスルーして下さい
754 ：[名無し]さん(bin+cue).rar：04/01/16 22:54 ID:nYXkDM1L
ちなみに次世代共有ソフトの仕様だけど、
となりの共有ファイルを根こそぎ移し続けるだけ。
最終的に全員が同じ共有ファイルを持つことになる。
バカバカしいけど匿名性、転送速度、拡散性、安全性、
これ以上の物は思いつかない。
となりの共有ファイルを根こそぎ移し続けるだけ。
最終的に全員が同じ共有ファイルを持つことになる。
バカバカしいけど匿名性、転送速度、拡散性、安全性、
これ以上の物は思いつかない。
755 ：[名無し]さん(bin+cue).rar：04/01/16 22:58 ID:aKhPzMKx
756 ：[名無し]さん(bin+cue).rar：04/01/16 23:31 ID:JMU+Ll1u
757 ：[名無し]さん(bin+cue).rar：04/01/16 23:36 ID:aKhPzMKx
>>756
すばらしいですね。
すばらしいですね。
758 ：[名無し]さん(bin+cue).rar：04/01/17 00:25 ID:OO0vDErG
>>753
nybbsはスレ主がサーバーになったのでは？
nybbsはスレ主がサーバーになったのでは？
あきらめて寝ようとしたらまたひらめいた。
>755
検索ワードを設定してとなりのファイルに対して検索を行う、
そして検索にかからなかったファイルはダミーとしてファイル名だけ保存する。
（もちろん検索にかかったファイルはそのままコピーされる）
別のとなりがダミーとして保存したファイルの本体が欲しかった場合
となりの組み換えが行われる。
これにより検索とファイルの近いもの同士がくっつく。
>755
検索ワードを設定してとなりのファイルに対して検索を行う、
そして検索にかからなかったファイルはダミーとしてファイル名だけ保存する。
（もちろん検索にかかったファイルはそのままコピーされる）
別のとなりがダミーとして保存したファイルの本体が欲しかった場合
となりの組み換えが行われる。
これにより検索とファイルの近いもの同士がくっつく。
追加
ネットワークは基本的にリング状でとなり同士のやりとりになるけど、
転送速度とＣＰＵを持て余せば複数のやりとりもOK。
Ａ＝Ｂ＝Ｃ＝Ｄ
→→→→↓
↑ ↓
Ａ＝Ｂ＝Ｃ＝Ｄ
すみません半分ネタのつもりだったんですが、
なんか行けそうな気がしてきたんで前言撤回。
実はネットワーク関係は聞きかじりの素人です、
アドバイスよろしくお願いします。
ネットワークは基本的にリング状でとなり同士のやりとりになるけど、
転送速度とＣＰＵを持て余せば複数のやりとりもOK。
Ａ＝Ｂ＝Ｃ＝Ｄ
→→→→↓
↑ ↓
Ａ＝Ｂ＝Ｃ＝Ｄ
すみません半分ネタのつもりだったんですが、
なんか行けそうな気がしてきたんで前言撤回。
実はネットワーク関係は聞きかじりの素人です、
アドバイスよろしくお願いします。
761 ：[名無し]さん(bin+cue).rar：04/01/17 13:24 ID:aNsOndVW
>>760
昨日もレスしたがトラフィックの問題が出てくるので却下。
それ以前にリング状の仮想ネット構想だとフリネで実現してるはず。
それに単純なリング状であった場合データの伝達が上手くいかない。
効率も格段に落ちると思う。
昨日もレスしたがトラフィックの問題が出てくるので却下。
それ以前にリング状の仮想ネット構想だとフリネで実現してるはず。
それに単純なリング状であった場合データの伝達が上手くいかない。
効率も格段に落ちると思う。
762 ：[名無し]さん(bin+cue).rar：04/01/17 13:38 ID:WY7Mwfa5
763 ：tomo：04/01/17 15:21 ID:TyLZebpv
C#でP2Pプログラムをしています。ホームページで
どんな感じか書いてみましたので目を通してみてください。
ホームページに掲示板を設定していないので質問などはメールで
お願いします。
ソフトウェアの開発状況はなかなかいい感じです。
そろそろ、テスターがほしいです。ローカルテストだと限界があるので・・・
テストしてもいいという方がおられましたらメールお願いします。
（掲示板作ったほうがいいみたい・・・）
スレ違いだったらすまん。
あっあとガイシュツだったら指摘お願いします。
では。
http://tomo.panicode.com/
どんな感じか書いてみましたので目を通してみてください。
ホームページに掲示板を設定していないので質問などはメールで
お願いします。
ソフトウェアの開発状況はなかなかいい感じです。
そろそろ、テスターがほしいです。ローカルテストだと限界があるので・・・
テストしてもいいという方がおられましたらメールお願いします。
（掲示板作ったほうがいいみたい・・・）
スレ違いだったらすまん。
あっあとガイシュツだったら指摘お願いします。
では。
http://tomo.panicode.com/
764 ：[名無し]さん(bin+cue).rar：04/01/17 15:23 ID:rC46UJlB
>>763
C#は止めてくれ
C#は止めてくれ
765 ：tomo：04/01/17 15:33 ID:TyLZebpv
.NET Frameworkが必要というのが難点です。
しかもスペックが低いPCだと動かない可能性があります。
ただ開発効率を考えると、どうしてもC#になってしまうのです。
（自己中ですいません・・・）
ちゃんと動くようになったらC++などでの開発も考慮しています。
しかもスペックが低いPCだと動かない可能性があります。
ただ開発効率を考えると、どうしてもC#になってしまうのです。
（自己中ですいません・・・）
ちゃんと動くようになったらC++などでの開発も考慮しています。
766 ：[名無し]さん(bin+cue).rar：04/01/17 15:35 ID:TymoIY33
むしろPreAlphaをぱくりました。
僕が開発しようとしているのはGUIDでホームページにアクセスする方法です。
本来の方法ですと、GeoCitiesやTriPodなどにホームページスペースを
おいてホームページを運営しますが、このシステムを使うと固定のアドレスでの
ホームページ運営ができます。（アップデートなど）
CGI（独自の言語）もがんばって対応させたいです。
僕が開発しようとしているのはGUIDでホームページにアクセスする方法です。
本来の方法ですと、GeoCitiesやTriPodなどにホームページスペースを
おいてホームページを運営しますが、このシステムを使うと固定のアドレスでの
ホームページ運営ができます。（アップデートなど）
CGI（独自の言語）もがんばって対応させたいです。
768 ：[名無し]さん(bin+cue).rar：04/01/17 15:45 ID:VsmTr8EG
>>763
> そろそろ、テスターがほしいです。ローカルテストだと限界があるので・・・
> テストしてもいいという方がおられましたらメールお願いします。
> （掲示板作ったほうがいいみたい・・・）
2chにスレ立てちゃえばOK
> そろそろ、テスターがほしいです。ローカルテストだと限界があるので・・・
> テストしてもいいという方がおられましたらメールお願いします。
> （掲示板作ったほうがいいみたい・・・）
2chにスレ立てちゃえばOK
すいません。実はあんまり書き込みをしたことがないんです。
いつも読むだけって感じです。
いつも読むだけって感じです。
770 ：[名無し]さん(bin+cue).rar：04/01/17 17:05 ID:mCqB6iuX
RAID5方式についてちょっと質問があるんだけど
奇数ビットと偶数ビットってなに？（汗
誰か教えてくださいm(_ _)m
奇数ビットと偶数ビットってなに？（汗
誰か教えてくださいm(_ _)m
771 ：[名無し]さん(bin+cue).rar：04/01/17 17:06 ID:J/0+EDGV
もちろんすぐに全員が同じ共有ファイルになるとは思わないけど、
マターリ常時接続すれば1～2Gぐらいなら一晩でたまりそうな気がする。
（まあ環境にもよるけど…）
図が悪かったかな自分の予想では検索や他への転送が軽い分Winnyより早いはず。
BとCが極端に遅い場合
→→→→↓
↑→↓ ↓
↑ ↓ ↓
A=B=C=D
基本はリング型だけど転送が極端に遅い部分は余った転送を次となりにまわして補える。
結果的に（ちょっと違うけど）Winnyと同じピラミッド型になる。
検索部分から構造がWinnyやMXとは違うんで戸惑うかもしれないけど、
Winnyが弱かった細かいファイル（.jpgなど）の完全補完に適してると思われる。
ピンポイント検索の大容量ファイルの共有には向かないかな…
その点は検索を細かくして工夫する余地が有ると思う。
例えばファイル容量や共有ファイルの残り量も絞込みの対象にするなど。
ぶっちゃけ仕様自体がDOMし放題だからオープンソースでもいけると思う。
マターリ常時接続すれば1～2Gぐらいなら一晩でたまりそうな気がする。
（まあ環境にもよるけど…）
図が悪かったかな自分の予想では検索や他への転送が軽い分Winnyより早いはず。
BとCが極端に遅い場合
→→→→↓
↑→↓ ↓
↑ ↓ ↓
A=B=C=D
基本はリング型だけど転送が極端に遅い部分は余った転送を次となりにまわして補える。
結果的に（ちょっと違うけど）Winnyと同じピラミッド型になる。
検索部分から構造がWinnyやMXとは違うんで戸惑うかもしれないけど、
Winnyが弱かった細かいファイル（.jpgなど）の完全補完に適してると思われる。
ピンポイント検索の大容量ファイルの共有には向かないかな…
その点は検索を細かくして工夫する余地が有ると思う。
例えばファイル容量や共有ファイルの残り量も絞込みの対象にするなど。
ぶっちゃけ仕様自体がDOMし放題だからオープンソースでもいけると思う。
スマソ上は>>761へのレス
774 ：[名無し]さん(bin+cue).rar：04/01/17 18:04 ID:OO0vDErG
>>774
WinnyやMXから考えると妙かもしれないけど、
仮に100人が共有ゼロのDOMに徹してたとする。
その内の一人がファイルをUPしたとたん、
そのファイルは一挙に100人に転送される。
それこそまさにP2Pの真髄だと思う。
WinnyやMXから考えると妙かもしれないけど、
仮に100人が共有ゼロのDOMに徹してたとする。
その内の一人がファイルをUPしたとたん、
そのファイルは一挙に100人に転送される。
それこそまさにP2Pの真髄だと思う。
776 ：[名無し]さん(bin+cue).rar：04/01/17 19:17 ID:l9YF/pSy
ぶっちゃけBitTorrentのクローンですか。
>776
これは知らなかった、多分似たようなものがあるだろうとは思ってたけど…
ただ昨日思いついた検索部分を特化すればBitTorrentの改良も可能だと思う。
2chネラ向けなBitTorrentって感じに(ｗ
と言うかこの検索の性能がミソになると思う。
（ネタとマジの分かれ目だった…）
とまあエラソに騙ってしまったけどスキルはゼロなんで、
あとプロトコルとかセキュリティとか（？）実装はエロい人お願いします。
面白い方向だとは思うんだけど…
これは知らなかった、多分似たようなものがあるだろうとは思ってたけど…
ただ昨日思いついた検索部分を特化すればBitTorrentの改良も可能だと思う。
2chネラ向けなBitTorrentって感じに(ｗ
と言うかこの検索の性能がミソになると思う。
（ネタとマジの分かれ目だった…）
とまあエラソに騙ってしまったけどスキルはゼロなんで、
あとプロトコルとかセキュリティとか（？）実装はエロい人お願いします。
面白い方向だとは思うんだけど…
778 ：[名無し]さん(bin+cue).rar：04/01/17 21:09 ID:CGQARoGn
>>754
方向性としては面白いと思うけど
極端な話、1000のファイルが流れていたら一人が1000のファイルを持つ事に
ユーザー1人が10のファイルを流したとしても
一人当たり「ユーザー数×10」のファイル分のHDD容量が必要になる
HDDが圧迫してくると今度は容量節約のために、キャッシュを削除する事になるので
実用性としてはどうかなと思うんだけど…。
方向性としては面白いと思うけど
極端な話、1000のファイルが流れていたら一人が1000のファイルを持つ事に
ユーザー1人が10のファイルを流したとしても
一人当たり「ユーザー数×10」のファイル分のHDD容量が必要になる
HDDが圧迫してくると今度は容量節約のために、キャッシュを削除する事になるので
実用性としてはどうかなと思うんだけど…。
779 ：[名無し]さん(bin+cue).rar：04/01/17 21:17 ID:ZBpNVFEe
ユースネットのサーバー
780 ：[名無し]さん(bin+cue).rar：04/01/17 21:24 ID:CGQARoGn
>>763
良く調べてみたら、前にnemuの部屋に宣伝カキコした人じゃないですか(笑
以前、公開していたランチャーなどはHPでは公開予定なしですか？
ttp://rd.vector.co.jp/soft/win95/util/se290627.html
良く調べてみたら、前にnemuの部屋に宣伝カキコした人じゃないですか(笑
以前、公開していたランチャーなどはHPでは公開予定なしですか？
ttp://rd.vector.co.jp/soft/win95/util/se290627.html
781 ：[名無し]さん(bin+cue).rar：04/01/17 21:26 ID:y5SlLW3x
>これは知らなかった、多分似たようなものがあるだろうとは思ってたけど…
>ただ昨日思いついた検索部分を特化すればBitTorrentの改良も可能だと思う。
bittorrentを知らなかった時点でP2Pに本気で関わろうとしているとは思えん。
782 ：[名無し]さん(bin+cue).rar：04/01/17 21:28 ID:y5SlLW3x
>>763
freenetにwebページ作ってますけど、freenetと比べてアピールしたい点はある?
freenetにwebページ作ってますけど、freenetと比べてアピールしたい点はある?
783 ：[名無し]さん(bin+cue).rar：04/01/17 21:32 ID:jRpLmtq/
前から思ってたんですけど、意見をもっと聞くために
age進行にしません？
荒らしがでたらsage進行に戻しましょうよ。
age進行にしません？
荒らしがでたらsage進行に戻しましょうよ。
>778
その為の検索とダミーファイルですね。
単純に削除すると構造上すぐに復活してしまうので、
削除するのではなくダミーに登録する。
ファイル名としては残るがそのファイルの中身は無い。
Winnyなどと違う点は、検索して欲しいファイルを探すと言うより、
大量のファイルからいらないファイルを消していく（ダミー登録する）と言うことだと思います。
ちなみに検索の性能を上げれば同名だけど容量が違うとか、
ファイルが欠損してないものとかピンポイント検索も可能じゃないかと思う（多分…）
>781
スマソ、本当に素人です。
マジ必死で捕まりたくないけどWinnyしたいんです（ｗ
その為の検索とダミーファイルですね。
単純に削除すると構造上すぐに復活してしまうので、
削除するのではなくダミーに登録する。
ファイル名としては残るがそのファイルの中身は無い。
Winnyなどと違う点は、検索して欲しいファイルを探すと言うより、
大量のファイルからいらないファイルを消していく（ダミー登録する）と言うことだと思います。
ちなみに検索の性能を上げれば同名だけど容量が違うとか、
ファイルが欠損してないものとかピンポイント検索も可能じゃないかと思う（多分…）
>781
スマソ、本当に素人です。
マジ必死で捕まりたくないけどWinnyしたいんです（ｗ
結果として不要なファイルほど、
キャッシュが少なくなることは言うまでもないですね。
キャッシュが少なくなることは言うまでもないですね。
786 ：[名無し]さん(bin+cue).rar：04/01/17 21:58 ID:OO0vDErG
787 ：[名無し]さん(bin+cue).rar：04/01/17 22:02 ID:OO0vDErG
>786
その辺はネットワーク上にどの程度ファイルが出回るかなんで計りしれないですね。
HDメーカにとっては喜ばしい状況ではないでしょうか（ｗ
Winny以上にマークされることは予想されるので、
匿名性とか暗号化に関しては専門科の皆様にお任せしたい。
>787
ありがとうございます。
その辺はネットワーク上にどの程度ファイルが出回るかなんで計りしれないですね。
HDメーカにとっては喜ばしい状況ではないでしょうか（ｗ
Winny以上にマークされることは予想されるので、
匿名性とか暗号化に関しては専門科の皆様にお任せしたい。
>787
ありがとうございます。
これ冷静に考え直してみたら、
捕まるとシャレになんないっすね。
決して違法ファイルは共有しないように…（ｗ
捕まるとシャレになんないっすね。
決して違法ファイルは共有しないように…（ｗ
790 ：[名無し]さん(bin+cue).rar：04/01/17 22:48 ID:nj0xIxts
>>789
ｗ
っつーか単に円形的なネットワークだと警察に間入られたらおしまいだな。
あとは自分のほしくないものもすべて入ってきちまうことと、UPしない人でもファイルをDLできてしまうことかな・・・。
ｗ
っつーか単に円形的なネットワークだと警察に間入られたらおしまいだな。
あとは自分のほしくないものもすべて入ってきちまうことと、UPしない人でもファイルをDLできてしまうことかな・・・。
>790
ははは、
個人的には合法ファイルが中心の共有スペースになって、
違法ファイルは影でひっそりとが理想なんですが…（ｗ
P2P技術って人類皆兄弟みたいな所が面白いなと思ってます。
もちろんfreenetと言う選択肢もあるけれど、
どうも外国の低速回線がネックになってる感じがする（おそらく…）
日本はADSLや光では世界的にも恵まれていたはず（確か…）
日本でこそ中心となれるようなP2Pネットワークが出てきていいんじゃないかな（あくまで他力本願）
と、言うわけでエロい方よろしくお願いします（ｗ
ははは、
個人的には合法ファイルが中心の共有スペースになって、
違法ファイルは影でひっそりとが理想なんですが…（ｗ
P2P技術って人類皆兄弟みたいな所が面白いなと思ってます。
もちろんfreenetと言う選択肢もあるけれど、
どうも外国の低速回線がネックになってる感じがする（おそらく…）
日本はADSLや光では世界的にも恵まれていたはず（確か…）
日本でこそ中心となれるようなP2Pネットワークが出てきていいんじゃないかな（あくまで他力本願）
と、言うわけでエロい方よろしくお願いします（ｗ
792 ：[名無し]さん(bin+cue).rar：04/01/17 23:09 ID:e31g0oLj
> P2P技術って人類皆兄弟みたいな所が面白いなと思ってます。
現実には、犯罪者皆兄弟
現実には、犯罪者皆兄弟
793 ：[名無し]さん(bin+cue).rar：04/01/17 23:11 ID:nj0xIxts
794 ：[名無し]さん(bin+cue).rar：04/01/17 23:14 ID:aZTAHCDf
中継者にとって意味の無い転送するしかないような、
A→B→C
Cの公開鍵を使ってAが暗号化、
Aが送信、Bを通ってCへ、
Cは秘密鍵でAから送られたファイルを復号
これで経路ごとに暗号化して、断片化した転送をリアルタイムで行わない、
AからBへの数分後、BからCへみてーな感じだと、
パケットダンプじゃ、解析は無理。
帯域は回線の帯域／転送数で
暗号化は転送毎に二回でCPUに優しくないけど。
必要な匿名性のレベルで転送数設定するとか、
でも、どうAにリクエスト送ればいいんだべ。
A→B→C
Cの公開鍵を使ってAが暗号化、
Aが送信、Bを通ってCへ、
Cは秘密鍵でAから送られたファイルを復号
これで経路ごとに暗号化して、断片化した転送をリアルタイムで行わない、
AからBへの数分後、BからCへみてーな感じだと、
パケットダンプじゃ、解析は無理。
帯域は回線の帯域／転送数で
暗号化は転送毎に二回でCPUに優しくないけど。
必要な匿名性のレベルで転送数設定するとか、
でも、どうAにリクエスト送ればいいんだべ。
795 ：[名無し]さん(bin+cue).rar：04/01/17 23:18 ID:nj0xIxts
別のDをかますとか。
でもそうするとDからリクエストをどうやって送るかってことになってさらにEを用意しても・・・・。
ﾀﾞﾒﾎﾟ。
でもそうするとDからリクエストをどうやって送るかってことになってさらにEを用意しても・・・・。
ﾀﾞﾒﾎﾟ。
796 ：[名無し]さん(bin+cue).rar：04/01/17 23:30 ID:aZTAHCDf
A,B,C,D,EのPCがあるとして、
Aがリクエスト愛のポエム+公開鍵を送る
Bはリクエストを受け取ると、受信元としてAを保存して愛のポエムをCへ
Cは同じく受信元Bを保存して愛のポエムをDへ、
D同上
E愛のポエムを持ってるので公開鍵で断片を暗号化Dへ送信。
受信元をたどってAへ、
DはEが送信元だとは判らない。
AもBが受信元だとは判らない。
ダンプしても経路ごとに暗号化されてるので意味を成さない情報で、
ABCDEで転送が発生しているともわからないはず、大まかな予測しかできない。
五台の優良ノードがあれば
ポエムぐらいなら転送可能。
ﾀﾞ､ﾀﾞﾒﾎﾟ
Aがリクエスト愛のポエム+公開鍵を送る
Bはリクエストを受け取ると、受信元としてAを保存して愛のポエムをCへ
Cは同じく受信元Bを保存して愛のポエムをDへ、
D同上
E愛のポエムを持ってるので公開鍵で断片を暗号化Dへ送信。
受信元をたどってAへ、
DはEが送信元だとは判らない。
AもBが受信元だとは判らない。
ダンプしても経路ごとに暗号化されてるので意味を成さない情報で、
ABCDEで転送が発生しているともわからないはず、大まかな予測しかできない。
五台の優良ノードがあれば
ポエムぐらいなら転送可能。
ﾀﾞ､ﾀﾞﾒﾎﾟ
797 ：[名無し]さん(bin+cue).rar：04/01/17 23:42 ID:SN2oDpsk
なんか議論がループしてないか?
「隣接ノードに情報を漏らさない」
はどうした。
「隣接ノードに情報を漏らさない」
はどうした。
798 ：[名無し]さん(bin+cue).rar：04/01/17 23:42 ID:aZTAHCDf
同じリクエスト同士を発見したら、同じ秘密鍵を共有。
して転送してくなら回線の帯域／転送数を元の回線の帯域に近づけてく
事はできそうだな、もちょっと考えてみます。
なんていうか、どう工夫しても不特定多数に復号可能な
暗号化に意味が無いと思うのは俺だけか。
して転送してくなら回線の帯域／転送数を元の回線の帯域に近づけてく
事はできそうだな、もちょっと考えてみます。
なんていうか、どう工夫しても不特定多数に復号可能な
暗号化に意味が無いと思うのは俺だけか。
799 ：[名無し]さん(bin+cue).rar：04/01/18 15:54 ID:yLxFI9uw
ようするに暗号化がめちゃめちゃ強力ならいいんだよ。
だから次のP2PのシステムはWinnyとそう変わらなくてもいいけど
暗号化に力をいれたほうがいい。
そうすれば匿名性は保たれると思う。
だから次のP2PのシステムはWinnyとそう変わらなくてもいいけど
暗号化に力をいれたほうがいい。
そうすれば匿名性は保たれると思う。
800 ：[名無し]さん(bin+cue).rar：04/01/18 15:54 ID:pzup/VUv
さんざん既出な予感がするけど、
コネクションレスでIPは偽総しておいて一方通行のネットワークにするってのは?
コネクションレスでIPは偽総しておいて一方通行のネットワークにするってのは?
801 ：[名無し]さん(bin+cue).rar：04/01/18 15:56 ID:vm40nsAD
暗号化はどういったファイルをやり取りしているかを誤魔化すだけであって、匿名性とは関係ないだろ。
転送の仕組みが肝だ。
転送の仕組みが肝だ。
802 ：[名無し]さん(bin+cue).rar：04/01/18 16:03 ID:f2rDBMvy
暗号化bit数を大きくする程、複合化に時間がかかり、その分効率が悪くなるような気がするけど・・・。
っつーか強化するとしたらどっちの暗号を強化したほうが良いんだろう。通信？ファイルそのもの？
っつーか強化するとしたらどっちの暗号を強化したほうが良いんだろう。通信？ファイルそのもの？
803 ：[名無し]さん(bin+cue).rar：04/01/18 16:15 ID:AthZfKcL
オープンソースで行くんなら、「自分が転送したデータや保持しているキャッシュの
内容を私は知りませんでした」と言うために内容が暗号化されてればいいだけじゃねーの？
だったら、脆弱でもいいから軽い暗号の方がいいと思うが。
内容を私は知りませんでした」と言うために内容が暗号化されてればいいだけじゃねーの？
だったら、脆弱でもいいから軽い暗号の方がいいと思うが。
804 ：[名無し]さん(bin+cue).rar：04/01/18 16:21 ID:b2CsO3tv
ｎｙの匿名性はキャッシュを勝手にウプすることによって、自分の意思で
著作物をUPしたんじゃないってことだよ。この仕組みのおかげでDL先がKであっても
問題ないわけだ。
著作物をUPしたんじゃないってことだよ。この仕組みのおかげでDL先がKであっても
問題ないわけだ。
805 ：[名無し]さん(bin+cue).rar：04/01/18 16:35 ID:AthZfKcL
806 ：[名無し]さん(bin+cue).rar：04/01/18 17:10 ID:e9MN3oHQ
807 ：[名無し]さん(bin+cue).rar：04/01/18 17:44 ID:slt3/YB4
仮想HDとキャッシュ全部そろわないと複合化できないシステムはどうなったの？
あと、プロトコル部分と暗号化部分をプラグイン方式にすれば末永く使えるわけだし。
ついでに自分の持ってるキャッシュ見えないようにすれば・・・
あと、プロトコル部分と暗号化部分をプラグイン方式にすれば末永く使えるわけだし。
ついでに自分の持ってるキャッシュ見えないようにすれば・・・
808 ：[名無し]さん(bin+cue).rar：04/01/18 18:41 ID:49A0k4Qm
早く作れよクズども
47氏は１ヶ月でプロトタイプを作ったぞ
マジで雑魚は何人集まっても一人の天才に劣るな
47氏は１ヶ月でプロトタイプを作ったぞ
マジで雑魚は何人集まっても一人の天才に劣るな
809 ：[名無し]さん(bin+cue).rar：04/01/18 18:43 ID:slt3/YB4
>>808
ならお前が作れ・・・と言いたいがそれも事実なんだよなぁ
ならお前が作れ・・・と言いたいがそれも事実なんだよなぁ
810 ：[名無し]さん(bin+cue).rar：04/01/18 19:17 ID:Vid9q0qs
せめてこのスレにレスでも付けてくれたらねぇ...
それらしい人はいないな。
それらしい人はいないな。
811 ：[名無し]さん(bin+cue).rar：04/01/18 19:22 ID:AthZfKcL
nyの頃とは要求されている難易度が違うし、誰もが暇人ばかりじゃない。
それに、すでに初期のnyよりは完成度が高いが、もっと完成度を高めるまでは影で開発を
進めてる開発者もいる。
どうでもいいが、なんか808より809がむかつくのは俺だけか？
それに、すでに初期のnyよりは完成度が高いが、もっと完成度を高めるまでは影で開発を
進めてる開発者もいる。
どうでもいいが、なんか808より809がむかつくのは俺だけか？
812 ：[名無し]さん(bin+cue).rar：04/01/18 19:36 ID:h7+qK9ZH
別にどちらにもむかつかないけど
813 ：[名無し]さん(bin+cue).rar：04/01/18 19:58 ID:tvdNJNC8
814 ：[名無し]さん(bin+cue).rar：04/01/18 20:00 ID:AthZfKcL
限定公開されてるって意味っすよ。
815 ：[名無し]さん(bin+cue).rar：04/01/18 20:10 ID:50aVS3bS
どうでもいいが、なんか808より809より911がむかつくのは俺だけか？
816 ：[名無し]さん(bin+cue).rar：04/01/18 20:16 ID:xBKL3cB3
>>911
に期待しよう。
に期待しよう。
817 ：[名無し]さん(bin+cue).rar：04/01/18 20:20 ID:49A0k4Qm
いいから、お前らは俺たちのために逮捕されないシステムを作れよ
お前らは次期P2Pが完成するまではクズでゴミでカスで奴隷な
完成したら神と呼んでやるよ
お前らは次期P2Pが完成するまではクズでゴミでカスで奴隷な
完成したら神と呼んでやるよ
818 ：[名無し]さん(bin+cue).rar：04/01/18 20:42 ID:rqib8FJR
819 ：[名無し]さん(bin+cue).rar：04/01/18 20:46 ID:AthZfKcL
>>817
藻前いい香具師だな。ちゃんとsageてるし。
藻前いい香具師だな。ちゃんとsageてるし。
820 ：[名無し]さん(bin+cue).rar：04/01/18 20:58 ID:0Rsiga4a
ziguzakude
yarebaiiyo
yarebaiiyo
821 ：[名無し]さん(bin+cue).rar：04/01/18 21:06 ID:yAkzfaYh
ふむ…なにやら実装に向けて世論が動いている…？(激謎)
よーし。それじゃ私が実装してみる。ただし、完成するかはわからんがな。(まて)
例の無差別XOR方式で行きたいと思っている。
なんか搭載してほしい機能とかあったら言ってくれ。
よーし。それじゃ私が実装してみる。ただし、完成するかはわからんがな。(まて)
例の無差別XOR方式で行きたいと思っている。
なんか搭載してほしい機能とかあったら言ってくれ。
822 ：[名無し]さん(bin+cue).rar：04/01/18 21:22 ID:AthZfKcL
「無作為」だってば(w
同じ書き間違いしてるところを見ると、上の方で開発宣言したのと同じ人かな？
wiki にも書かれてるけど、無作為XORはいろいろ問題多いよ。もしなにかうまい解決策を考えてるのなら、
興味あるのでぜひ聞かせて欲しい。
要望としては、「信用情報方式」と組み合わせて欲しいってことかな。信頼できるノードが
見つけられるなら、無作為XORはいけると思う（トラフィックの無駄が多いのが懸念だけど）。
「信用情報方式」の改良案が確かこのスレでいくつか出てたから、うまく取り込むといいかも。
同じ書き間違いしてるところを見ると、上の方で開発宣言したのと同じ人かな？
wiki にも書かれてるけど、無作為XORはいろいろ問題多いよ。もしなにかうまい解決策を考えてるのなら、
興味あるのでぜひ聞かせて欲しい。
要望としては、「信用情報方式」と組み合わせて欲しいってことかな。信頼できるノードが
見つけられるなら、無作為XORはいけると思う（トラフィックの無駄が多いのが懸念だけど）。
「信用情報方式」の改良案が確かこのスレでいくつか出てたから、うまく取り込むといいかも。
823 ：[名無し]さん(bin+cue).rar：04/01/18 21:53 ID:pKTcYkrS
>>775
DOMってのはUPしない連中の事を言うのだから、たとえDOM1000人にファイルが
広がったとしてもそこから先への広がりが期待できない。
つまり、広がってないのと同じ事。
それどころか無駄に接続数や帯域を食われて本当に迷惑以外の何者でもない。
P2Pにコバンザメは必要ない。
DOMってのはUPしない連中の事を言うのだから、たとえDOM1000人にファイルが
広がったとしてもそこから先への広がりが期待できない。
つまり、広がってないのと同じ事。
それどころか無駄に接続数や帯域を食われて本当に迷惑以外の何者でもない。
P2Pにコバンザメは必要ない。
訂正 できる幼い頭で限り考えてみます。 => 幼い頭でできる限り考えてみます。
826 ：[名無し]さん(bin+cue).rar：04/01/18 23:02 ID:vRKthmLj
ここは某村長よりきたいできそうなひとばいぱいでつね
827 ：[名無し]さん(bin+cue).rar：04/01/18 23:14 ID:yAkzfaYh
>>822
ぐはっ…ばれたか。しかも漢字の間違いって……
あー。もう一回小学生からやり直すべきか？私ゃ……
とりあえず >>630 辺りのことを実装してみるつもり。
キャッシュは適当な大きさに固定 ( 10MB か 1MB 位が妥当かなぁ… ) して、
ブロックごとに作業をするようにしてみる。
１．ファイル検索情報 ： ファイル名・ファイルサイズ・全体のハッシュ
２．ファイル内のブロック情報 ： 全体のハッシュ・各ブロックの生データのハッシュ
３．ブロック情報 ： ブロックの生データのハッシュ・XOR済みデータのハッシュ×３
の三種類のパケットでネットワークを構築しようと思ってる。
で、リクエストを送るときには、ハッシュ文字列をさらに MD5 か何かでハッシュを取れば、
経路上では、自分が持ってるキャッシュのハッシュ文字列のMD5 と比較する関係上、
自分がそのデータを持っていないがぎり、何をほしがってるのかわかることはほぼ不可能になるという寸法。
ついでに、生データのハッシュで覚えておくことによって、同一ファイルをもう一回アップした場合に、
違うキャッシュを使ってXORデータを生成したとしても、それを混ぜることが出来るという効果もある。
すると、アップ回数が多ければ多いほどいろんなハッシュで作られたXORデータが出回り、落としやすくなる。
あ。XORデータは、生データ＆無作為キャッシュ二個 で作ろうかと。効率悪すぎるかなぁ…
とりあえず、重くても効率悪くても安全なものを目指したいなぁ…
叩き過ぎない程度にツッコミ希望。
ぐはっ…ばれたか。しかも漢字の間違いって……
あー。もう一回小学生からやり直すべきか？私ゃ……
とりあえず >>630 辺りのことを実装してみるつもり。
キャッシュは適当な大きさに固定 ( 10MB か 1MB 位が妥当かなぁ… ) して、
ブロックごとに作業をするようにしてみる。
１．ファイル検索情報 ： ファイル名・ファイルサイズ・全体のハッシュ
２．ファイル内のブロック情報 ： 全体のハッシュ・各ブロックの生データのハッシュ
３．ブロック情報 ： ブロックの生データのハッシュ・XOR済みデータのハッシュ×３
の三種類のパケットでネットワークを構築しようと思ってる。
で、リクエストを送るときには、ハッシュ文字列をさらに MD5 か何かでハッシュを取れば、
経路上では、自分が持ってるキャッシュのハッシュ文字列のMD5 と比較する関係上、
自分がそのデータを持っていないがぎり、何をほしがってるのかわかることはほぼ不可能になるという寸法。
ついでに、生データのハッシュで覚えておくことによって、同一ファイルをもう一回アップした場合に、
違うキャッシュを使ってXORデータを生成したとしても、それを混ぜることが出来るという効果もある。
すると、アップ回数が多ければ多いほどいろんなハッシュで作られたXORデータが出回り、落としやすくなる。
あ。XORデータは、生データ＆無作為キャッシュ二個 で作ろうかと。効率悪すぎるかなぁ…
とりあえず、重くても効率悪くても安全なものを目指したいなぁ…
叩き過ぎない程度にツッコミ希望。
828 ：[名無し]さん(bin+cue).rar：04/01/18 23:19 ID:ojkFoUFV
上のほうでIP偽装ってあるけど、
送信側のIPって偽装できるの？
送信側のIPって偽装できるの？
829 ：[名無し]さん(bin+cue).rar：04/01/18 23:54 ID:AthZfKcL
>>827
うおー、無作為データ２つっすか！？ さすがに効率悪すぎでは・・・
個人的には、どれがオリジナルから生成したデータなのか判別できないようにする部分さえ
しっかり作れば、無作為データは１つで十分ではないかと思う。逆に言うと、
そこがおろそかだと幾つ増やしても無駄なわけだし。
どうしてもということなら、コンパイル時のオプションで無作為データの数を変えられるとか、
放流者が数を自由に選べるようにするとかがいいなあ。
> 経路上では、自分が持ってるキャッシュのハッシュ文字列のMD5 と比較する関係上、
> 自分がそのデータを持っていないがぎり、何をほしがってるのかわかることはほぼ不可能になるという寸法。
リクエストを送るときはハッシュをそのまま送るのではなく、ハッシュ文字列をさらに
MD5にかけたものを使うようにすることで、リクエストを傍受した第三者にはどのデータの
リクエストなのかわからないようにするってこと？
んー、ファイル検索情報とブロック情報を分離するだけで十分なような。
ブロックのハッシュからファイル名を検索することはできないわけだから、結局同じ
ことではないかという気がする。
あと、個人的には wiki にある問題点 X7 が一番難しいところだと思うので、
これをどう解決するのかが気になる。
なんか否定的なことが多くなってしまったけど、期待してますよん。
うおー、無作為データ２つっすか！？ さすがに効率悪すぎでは・・・
個人的には、どれがオリジナルから生成したデータなのか判別できないようにする部分さえ
しっかり作れば、無作為データは１つで十分ではないかと思う。逆に言うと、
そこがおろそかだと幾つ増やしても無駄なわけだし。
どうしてもということなら、コンパイル時のオプションで無作為データの数を変えられるとか、
放流者が数を自由に選べるようにするとかがいいなあ。
> 経路上では、自分が持ってるキャッシュのハッシュ文字列のMD5 と比較する関係上、
> 自分がそのデータを持っていないがぎり、何をほしがってるのかわかることはほぼ不可能になるという寸法。
リクエストを送るときはハッシュをそのまま送るのではなく、ハッシュ文字列をさらに
MD5にかけたものを使うようにすることで、リクエストを傍受した第三者にはどのデータの
リクエストなのかわからないようにするってこと？
んー、ファイル検索情報とブロック情報を分離するだけで十分なような。
ブロックのハッシュからファイル名を検索することはできないわけだから、結局同じ
ことではないかという気がする。
あと、個人的には wiki にある問題点 X7 が一番難しいところだと思うので、
これをどう解決するのかが気になる。
なんか否定的なことが多くなってしまったけど、期待してますよん。
830 ：[名無し]さん(bin+cue).rar：04/01/18 23:56 ID:AthZfKcL
831 ：[名無し]さん(bin+cue).rar：04/01/19 00:37 ID:QyPYALsu
今まで話題にでたかわからんけどLimeWireはどうですか？
832 ：[名無し]さん(bin+cue).rar：04/01/19 01:34 ID:yHC4X4tZ
LimeWireってnyより前からあるグヌーテラクローンだよね
匿名性なんて考えて作られた無いはずだが
匿名性なんて考えて作られた無いはずだが
833 ：[名無し]さん(bin+cue).rar：04/01/19 02:11 ID:K2UGmE17
どういったデータをやり取りしているかを隠すためのデータ暗号化。
クラックによるネットワーク崩壊を防ぐための自己暗号化。
データの出所を隠すための転送動作。
後はトラフィックの増大をどう誤魔化すか。
クラックによるネットワーク崩壊を防ぐための自己暗号化。
データの出所を隠すための転送動作。
後はトラフィックの増大をどう誤魔化すか。
834 ：[名無し]さん(bin+cue).rar：04/01/19 04:43 ID:oSJ/vW/n
>>832
アホ発見
アホ発見
>823
クラック版のことですか？
一応この仕様の最終目的は完全共有でDLもUPもまとめて共有なんでDOMも更なるDOMへのUPに役立ってます。
むしろ常時接続のDOMは貴重なファイルサーバーとしてネットワーク維持に貢献することになるでしょう。
自分としてはUPは良心（？）でするものだから仕様をどうこうしても仕方ない気がするんですよ。
もちろんWinnyのような巧妙な仕組みも考えられるけど、それでもDOMる人はいるわけだし…
クラック対策に時間を費やすより最初からクラック版みたいな仕様にしちゃえみたいな（ｗ
後は技術の進歩が解決する問題だと思います。
ドッグイヤーなんて言われるように、回線はどんどん早くなるし、HDの容量も上がってるし。
いずれ自宅のパソコンにWeb上すべての情報がパンパンに詰まってるような時代が来るんじゃないかなと…
ただ今のところ匿名性の方が緊急課題っぽいので、実現は第6世代P2Pぐらいに持ち越しですかね（ｗ
クラック版のことですか？
一応この仕様の最終目的は完全共有でDLもUPもまとめて共有なんでDOMも更なるDOMへのUPに役立ってます。
むしろ常時接続のDOMは貴重なファイルサーバーとしてネットワーク維持に貢献することになるでしょう。
自分としてはUPは良心（？）でするものだから仕様をどうこうしても仕方ない気がするんですよ。
もちろんWinnyのような巧妙な仕組みも考えられるけど、それでもDOMる人はいるわけだし…
クラック対策に時間を費やすより最初からクラック版みたいな仕様にしちゃえみたいな（ｗ
後は技術の進歩が解決する問題だと思います。
ドッグイヤーなんて言われるように、回線はどんどん早くなるし、HDの容量も上がってるし。
いずれ自宅のパソコンにWeb上すべての情報がパンパンに詰まってるような時代が来るんじゃないかなと…
ただ今のところ匿名性の方が緊急課題っぽいので、実現は第6世代P2Pぐらいに持ち越しですかね（ｗ
836 ：[名無し]さん(bin+cue).rar：04/01/19 07:25 ID:393nkMUh
>730
私も同じようなことを考えてました。
ただ、分割数はファイル放流者に決定させたほうが良いです。
共有ソフトの使用人数を把握し、全てを転送に参加させることは恐らく不可能です。
私はこの方式の利点を、当局を巻き添えにさせるのではなく
一つのファイルを完全結合するために、分割数人分の捜査が必要になる点だと思います。
恐らく大人数の一斉捜査は現実的ではないと考えます。
ファイルの一部をアップロードしてもﾀｲ━━━━||Φ|(|ﾟ|∀|ﾟ|)|Φ||━━━━ﾎ!!な判例が出るまでは
使える方式だと思います。
私も同じようなことを考えてました。
ただ、分割数はファイル放流者に決定させたほうが良いです。
共有ソフトの使用人数を把握し、全てを転送に参加させることは恐らく不可能です。
私はこの方式の利点を、当局を巻き添えにさせるのではなく
一つのファイルを完全結合するために、分割数人分の捜査が必要になる点だと思います。
恐らく大人数の一斉捜査は現実的ではないと考えます。
ファイルの一部をアップロードしてもﾀｲ━━━━||Φ|(|ﾟ|∀|ﾟ|)|Φ||━━━━ﾎ!!な判例が出るまでは
使える方式だと思います。
今のところオープンソースは考えてませせん。というか無事完成するのか
わからないって感じです（汗
ある程度動くようになればオープンソースも考えてみたいです。
ただオープンソースにするとクラック版（？）などが簡単に作られてしまいます。
もし、オープンソースにするのなら
ネットワークの構造が壊れないために新しい仕様を考える必要があると思っています。
わからないって感じです（汗
ある程度動くようになればオープンソースも考えてみたいです。
ただオープンソースにするとクラック版（？）などが簡単に作られてしまいます。
もし、オープンソースにするのなら
ネットワークの構造が壊れないために新しい仕様を考える必要があると思っています。
839 ：[名無し]さん(bin+cue).rar：04/01/19 17:52 ID:393nkMUh
DOM防止策です。
A→B→C
このような流れで転送が行われているとします。
最初、Aは下流転送速度を0(若しくは超低速)にします。
BはCへ、Aへの転送証明要求を通知します。
CはAへ、BがCに平均?KでUPしている証明を通知します。
Aは通知された証明を元に、徐々に転送速度を上げていきます。
この策では、自分のUP速度によってDOWN速度が変化します。
クラックしたとしても、何も徳はありません。
P2Pファイル共有を成り立たせるには、
最低 UP/DOWN 5:5 の帯域が必要です。
nyよりも効率は落ちますが、崩壊はしない方法です。
A→B→C
このような流れで転送が行われているとします。
最初、Aは下流転送速度を0(若しくは超低速)にします。
BはCへ、Aへの転送証明要求を通知します。
CはAへ、BがCに平均?KでUPしている証明を通知します。
Aは通知された証明を元に、徐々に転送速度を上げていきます。
この策では、自分のUP速度によってDOWN速度が変化します。
クラックしたとしても、何も徳はありません。
P2Pファイル共有を成り立たせるには、
最低 UP/DOWN 5:5 の帯域が必要です。
nyよりも効率は落ちますが、崩壊はしない方法です。
840 ：[名無し]さん(bin+cue).rar：04/01/19 18:00 ID:IrbO1yHL
さんざ繰り返された議論なわけだが・・・。
この場合の転送は、C から A の身元を隠すためという解釈でいい？
だとしたら C は A に直接は接続できない。
C が A に証明を送るとき、もし B を介して送る仕組みにするのなら、
B は実際には転送を行っていないのに、C に転送を行っているように
見せかけて、A に偽造した証明を送ることができるのでは？
この場合の転送は、C から A の身元を隠すためという解釈でいい？
だとしたら C は A に直接は接続できない。
C が A に証明を送るとき、もし B を介して送る仕組みにするのなら、
B は実際には転送を行っていないのに、C に転送を行っているように
見せかけて、A に偽造した証明を送ることができるのでは？
>>838
レスどもです。
とりあえず、適度にサイトをチェックしておくことにしますね。
>オープンソースにするとクラック版
ちょっと認識が違ったみたいです。
あまりUGライクなものではなく、もう少しオープンなソフトなのかと思ってました。
レスどもです。
とりあえず、適度にサイトをチェックしておくことにしますね。
>オープンソースにするとクラック版
ちょっと認識が違ったみたいです。
あまりUGライクなものではなく、もう少しオープンなソフトなのかと思ってました。
842 ：[名無し]さん(bin+cue).rar：04/01/19 18:14 ID:6eUWlMZc
>840
この場合の「転送」は単なるtransferの意味であって中継とは違います。
AtoB BtoC でやり取りしているファイルはどちらも別物です。
BはCにAの生IPアドレスを証明要求に付加して通知します。
これでCはAに直接証明通知出来ますし、
この動作自体は、単に速度を通知しているだけですので
どんなファイルをやり取りしているかといったことは一切わからないはずです。
前から言いたかったのですが、どうでも良いデータを無理にリレー転送するのは無意味だと思います。
この場合の「転送」は単なるtransferの意味であって中継とは違います。
AtoB BtoC でやり取りしているファイルはどちらも別物です。
BはCにAの生IPアドレスを証明要求に付加して通知します。
これでCはAに直接証明通知出来ますし、
この動作自体は、単に速度を通知しているだけですので
どんなファイルをやり取りしているかといったことは一切わからないはずです。
前から言いたかったのですが、どうでも良いデータを無理にリレー転送するのは無意味だと思います。
843 ：[名無し]さん(bin+cue).rar：04/01/19 18:20 ID:IrbO1yHL
自分がＵＰしていることを第三者に証明してもらわないと、まともな速度でＵＰして
もらえないってことね？ なるほど。
複数ＩＰを使うとか、２者が共謀するクラック方法は考えられるけど、
まあいいんでない？
もらえないってことね？ なるほど。
複数ＩＰを使うとか、２者が共謀するクラック方法は考えられるけど、
まあいいんでない？
ああ、そういえばそんな感じのアイデアが前に出てたのを思い出した。
リスクを冒さずにダウンしたいと考える連中が捏造をＵＰしまくる恐れがあるので
却下になった覚えがある。
リスクを冒さずにダウンしたいと考える連中が捏造をＵＰしまくる恐れがあるので
却下になった覚えがある。
845 ：[名無し]さん(bin+cue).rar：04/01/19 18:37 ID:393nkMUh
なるほと、そういう恐れがあるんですね。
根本的な解決にはなりませんが、
現行nyの捏造警告に、警告者のトリップを付加する案を考えました。
誰でも良いから信用するのではなく、特定の人物を信用する方法です。
これでもいたちごっこになるかも知れませんが
そこまでの根気をDOMが持たないことを祈ってみるテスト
根本的な解決にはなりませんが、
現行nyの捏造警告に、警告者のトリップを付加する案を考えました。
誰でも良いから信用するのではなく、特定の人物を信用する方法です。
これでもいたちごっこになるかも知れませんが
そこまでの根気をDOMが持たないことを祈ってみるテスト
846 ：[名無し]さん(bin+cue).rar：04/01/19 18:48 ID:IrbO1yHL
確かそういうアイデアが出てたような・・・というわけで探してみた。
前スレの 786-787 に出てるやつなんかがそういう方向性じゃないかな。
http://fire.prohosting.com/p2pt/2ch-log/007.html
前スレの 786-787 に出てるやつなんかがそういう方向性じゃないかな。
http://fire.prohosting.com/p2pt/2ch-log/007.html
>>829
とりあえずキリが良いので名前821で行くことにするか…
やっぱり無作為データ二つは多すぎですか…では一個の方向で行くことにしましょう。。
ブロック情報のパケットのサイズとか統一したいのてネットワーク全体で統一します。
ハッシュ文字列からさらにハッシュを求めることについてですが、
検索・ＤＬ効率の点から、検索情報・ブロック情報のパケットは無差別にどんどん広めていきます。
ファイル内のブロック情報はちょっと大きくなる可能性があるので無差別拡散はちょっと無謀かと。
そういう関係上、キャッシュ転送要求を中継していくときに、１～３のパケットをたどれば何がほしいのか
わかってしまうため、パケットをたどることが不可能になるよう、こういう手段を考えました。
３のパケットに関しては流れているファイル数の数倍に比例する膨大な数が流れるため、
一個ずつ全部調べるのはほぼ不可能。で、キャッシュファイル内に記録されてるハッシュは既に
ハッシュ文字列のハッシュにしておくことで、手元のキャッシュファイルの特定は可能だが
復号後のファイルに関してはを知ることが出来ないようになります。
問題点 x7 に関しては、キャッシュ拡散の大義名分の元に(謎)、さも "普通のキャッシュです" と
いう風に周りに転送していきます。UPしなくてもキャッシュ拡散の転送をするため見分けられないでしょう。
で、全部広め終わってから検索用のデータを流します。
まだいろんなアイデアを練っている段階なので、意見感想ツッコミお待ちしております。
とりあえずキリが良いので名前821で行くことにするか…
やっぱり無作為データ二つは多すぎですか…では一個の方向で行くことにしましょう。。
ブロック情報のパケットのサイズとか統一したいのてネットワーク全体で統一します。
ハッシュ文字列からさらにハッシュを求めることについてですが、
検索・ＤＬ効率の点から、検索情報・ブロック情報のパケットは無差別にどんどん広めていきます。
ファイル内のブロック情報はちょっと大きくなる可能性があるので無差別拡散はちょっと無謀かと。
そういう関係上、キャッシュ転送要求を中継していくときに、１～３のパケットをたどれば何がほしいのか
わかってしまうため、パケットをたどることが不可能になるよう、こういう手段を考えました。
３のパケットに関しては流れているファイル数の数倍に比例する膨大な数が流れるため、
一個ずつ全部調べるのはほぼ不可能。で、キャッシュファイル内に記録されてるハッシュは既に
ハッシュ文字列のハッシュにしておくことで、手元のキャッシュファイルの特定は可能だが
復号後のファイルに関してはを知ることが出来ないようになります。
問題点 x7 に関しては、キャッシュ拡散の大義名分の元に(謎)、さも "普通のキャッシュです" と
いう風に周りに転送していきます。UPしなくてもキャッシュ拡散の転送をするため見分けられないでしょう。
で、全部広め終わってから検索用のデータを流します。
まだいろんなアイデアを練っている段階なので、意見感想ツッコミお待ちしております。
848 ：[名無し]さん(bin+cue).rar：04/01/19 19:38 ID:0OkvE3U0
DOM対策に関することなんて
Winnyのオープンソース化を考えるスレで出た以上のことは何も出てないな
Winnyのオープンソース化を考えるスレで出た以上のことは何も出てないな
849 ：[名無し]さん(bin+cue).rar：04/01/19 19:42 ID:rQgftwXP
なつかしいな。Linux板だっけか?
>>848
議論が匿名経路メインになってきたので横レスですが、
私の完全共有型には具体策があります。
となりファイルの検索の段階で自分へのUPが無い場合はスルーする様な設定は理論上可能です。
このソフトの特徴である検索を内部化してることの利ですね。
（基本なしくみはとなりのファイルリストをDLしとなりに無いファイルをUPする）
しかしこれをガリガリにやられてしまうと完全共有が機能しないという罠。
ネットワークが充実して要らないファイルが増え始めたら、
バージョンアップさせようと出し惜しみするつもりだったんですが…（ｗ
実は今密かにプログラミング勉強中、
いったんJAVAでサンプル組んでみようかと考えてます。
議論が匿名経路メインになってきたので横レスですが、
私の完全共有型には具体策があります。
となりファイルの検索の段階で自分へのUPが無い場合はスルーする様な設定は理論上可能です。
このソフトの特徴である検索を内部化してることの利ですね。
（基本なしくみはとなりのファイルリストをDLしとなりに無いファイルをUPする）
しかしこれをガリガリにやられてしまうと完全共有が機能しないという罠。
ネットワークが充実して要らないファイルが増え始めたら、
バージョンアップさせようと出し惜しみするつもりだったんですが…（ｗ
実は今密かにプログラミング勉強中、
いったんJAVAでサンプル組んでみようかと考えてます。
いかん、完全共有がハッタリだとバレてしまう（ｗ
基本仕様に追加、
＞（基本なしくみはとなりのファイルリストをDLしとなりに無いファイルをUPする）
自分に無いファイルが検索にひっかからない物ならダミーにする。
UPは強制でスルー出来るような仕様は考えておりません（ｗ
基本仕様に追加、
＞（基本なしくみはとなりのファイルリストをDLしとなりに無いファイルをUPする）
自分に無いファイルが検索にひっかからない物ならダミーにする。
UPは強制でスルー出来るような仕様は考えておりません（ｗ
852 ：[名無し]さん(bin+cue).rar：04/01/19 22:02 ID:393nkMUh
自分へのUPが無い場合はスルーする これが具体策ですか？
>852
うん、
クラック版は抜きにして、
「となりのファイルリストをDLしとなりに無いファイルをUPする」
が正常に機能してれば可能。
MXで言う交換条件を検索が肩代わりする感じ、
もちろんこの検索が賢くなれば「○○」をもってる奴と交換とかも出来る。
なんだか完全共有の目的が崩れてきたなぁ（ｗ
うん、
クラック版は抜きにして、
「となりのファイルリストをDLしとなりに無いファイルをUPする」
が正常に機能してれば可能。
MXで言う交換条件を検索が肩代わりする感じ、
もちろんこの検索が賢くなれば「○○」をもってる奴と交換とかも出来る。
なんだか完全共有の目的が崩れてきたなぁ（ｗ
854 ：[名無し]さん(bin+cue).rar：04/01/19 22:40 ID:IrbO1yHL
>>847
ハッシュ文字列からさらにハッシュを求めることについて
> ３のパケットに関しては流れているファイル数の数倍に比例する膨大な数が流れるため、
> 一個ずつ全部調べるのはほぼ不可能。
ブロックのハッシュからさらに別なハッシュを求めるには計算コストがかかるので、
流れているブロックハッシュ情報すべてと照合するのは難しくなる、ということですよね？
その気になれば流れてきたすべてのブロックハッシュをハッシュ処理して蓄えておき、
流れてきた検索クエリと照合することはできそう。Ｋ君ならそのくらいはするかも。
もしくは、ピンポイントで特定のファイルをダウンしようとしているノードを見張るのなら
もっと簡単でしょう。
というわけで匿名性の根拠にするにはちょっと弱いような気がしますが、でも確かに
特定を難しくする効果はあると思います。あと、やるなら、MD5 よりもっと計算コストが高い
ハッシュアルゴリズムを使った方がよいのではという気もします。
> 問題点 x7 に関しては、キャッシュ拡散の大義名分の元に(謎)、さも "普通のキャッシュです" と
> いう風に周りに転送していきます。UPしなくてもキャッシュ拡散の転送をするため見分けられないでしょう。
> で、全部広め終わってから検索用のデータを流します。
なるほど、強制拡散しておくわけですね。
あとは、強制ＵＰした相手に放流元が特定される危険がないのかがちょっと心配です。
相手は、後から流れてきた検索キーを見て、「あ、こないだキャッシュをＵＰしてきた
あいつ、放流主じゃないか？」と気付くケースはないのかと。
あともう１点。１つのファイルをダウンするためのデータの断片があちこちのノードに
分散することになるので、>>333-334 にある復元確率低下の問題が起こる危険があります。
これも考えておかないといけないのではと思います。
ハッシュ文字列からさらにハッシュを求めることについて
> ３のパケットに関しては流れているファイル数の数倍に比例する膨大な数が流れるため、
> 一個ずつ全部調べるのはほぼ不可能。
ブロックのハッシュからさらに別なハッシュを求めるには計算コストがかかるので、
流れているブロックハッシュ情報すべてと照合するのは難しくなる、ということですよね？
その気になれば流れてきたすべてのブロックハッシュをハッシュ処理して蓄えておき、
流れてきた検索クエリと照合することはできそう。Ｋ君ならそのくらいはするかも。
もしくは、ピンポイントで特定のファイルをダウンしようとしているノードを見張るのなら
もっと簡単でしょう。
というわけで匿名性の根拠にするにはちょっと弱いような気がしますが、でも確かに
特定を難しくする効果はあると思います。あと、やるなら、MD5 よりもっと計算コストが高い
ハッシュアルゴリズムを使った方がよいのではという気もします。
> 問題点 x7 に関しては、キャッシュ拡散の大義名分の元に(謎)、さも "普通のキャッシュです" と
> いう風に周りに転送していきます。UPしなくてもキャッシュ拡散の転送をするため見分けられないでしょう。
> で、全部広め終わってから検索用のデータを流します。
なるほど、強制拡散しておくわけですね。
あとは、強制ＵＰした相手に放流元が特定される危険がないのかがちょっと心配です。
相手は、後から流れてきた検索キーを見て、「あ、こないだキャッシュをＵＰしてきた
あいつ、放流主じゃないか？」と気付くケースはないのかと。
あともう１点。１つのファイルをダウンするためのデータの断片があちこちのノードに
分散することになるので、>>333-334 にある復元確率低下の問題が起こる危険があります。
これも考えておかないといけないのではと思います。
855 ：[名無し]さん(bin+cue).rar：04/01/19 22:42 ID:393nkMUh
ようするにはフォルダ同期だよね。
そういうのは仲間内でやったほうが良いと思うな。
そういうのは仲間内でやったほうが良いと思うな。
856 ：[名無し]さん(bin+cue).rar：04/01/19 23:15 ID:nfdtYqPl
>>853
Wikiの「交換仕様によるDOMの抑制」を見れ。
Wikiの「交換仕様によるDOMの抑制」を見れ。
>>854
ハッシュ文字列からさらにハッシュを求めることについて
> その気になれば流れてきたすべてのブロックハッシュをハッシュ処理して蓄えておき、
> 流れてきた検索クエリと照合することはできそう。Ｋ君ならそのくらいはするかも。
ny のように、二万三万もファイルがあるようならば、XORデータの数はさらにその数倍あるので、
仮に MD5 だとしても、16Bytes…あぁ、計算してみると現実的な範囲かも？
それでは、おとりとして膨大な数のブロック情報でも流しちゃいますか。(まて)
> もしくは、ピンポイントで特定のファイルをダウンしようとしているノードを見張るのなら
> もっと簡単でしょう。
こっちの対処は共有なP2Pでやる限りほぼ不可能に近いでしょうね。
１つのファイル辺りに落とすキャッシュの数が多いので、信用情報方式をとっても、
ユーザは質問に答えるのが嫌になってくるだろうし……
放流主特定について
> あとは、強制ＵＰした相手に放流元が特定される危険がないのかがちょっと心配です。
> 相手は、後から流れてきた検索キーを見て、「あ、こないだキャッシュをＵＰしてきた
> あいつ、放流主じゃないか？」と気付くケースはないのかと。
この点に関しては大丈夫だと思います。自分は放流キャッシュだけでなく、普通に流れてる
キャッシュの拡散をやってるのと周囲ノードから見れば変わらないですし、
そのアップされた周囲のノードももっと周囲に拡散させていきますから、
受けたほうでは、放流主なのか、放流主に押し付けられて拡散してるのか、見分けられないでしょう。
<続く>
ハッシュ文字列からさらにハッシュを求めることについて
> その気になれば流れてきたすべてのブロックハッシュをハッシュ処理して蓄えておき、
> 流れてきた検索クエリと照合することはできそう。Ｋ君ならそのくらいはするかも。
ny のように、二万三万もファイルがあるようならば、XORデータの数はさらにその数倍あるので、
仮に MD5 だとしても、16Bytes…あぁ、計算してみると現実的な範囲かも？
それでは、おとりとして膨大な数のブロック情報でも流しちゃいますか。(まて)
> もしくは、ピンポイントで特定のファイルをダウンしようとしているノードを見張るのなら
> もっと簡単でしょう。
こっちの対処は共有なP2Pでやる限りほぼ不可能に近いでしょうね。
１つのファイル辺りに落とすキャッシュの数が多いので、信用情報方式をとっても、
ユーザは質問に答えるのが嫌になってくるだろうし……
放流主特定について
> あとは、強制ＵＰした相手に放流元が特定される危険がないのかがちょっと心配です。
> 相手は、後から流れてきた検索キーを見て、「あ、こないだキャッシュをＵＰしてきた
> あいつ、放流主じゃないか？」と気付くケースはないのかと。
この点に関しては大丈夫だと思います。自分は放流キャッシュだけでなく、普通に流れてる
キャッシュの拡散をやってるのと周囲ノードから見れば変わらないですし、
そのアップされた周囲のノードももっと周囲に拡散させていきますから、
受けたほうでは、放流主なのか、放流主に押し付けられて拡散してるのか、見分けられないでしょう。
<続く>
>>854
ダウンロード効率について
> あともう１点。１つのファイルをダウンするためのデータの断片があちこちのノードに
> 分散することになるので、>>333-334 にある復元確率低下の問題が起こる危険があります。
> これも考えておかないといけないのではと思います。
完全キャッシュを手にした場合には、そのファイルを自動で最放流しようかと考えています。
その際には当然違う無作為キャッシュを使って。このためにブロック情報を二段階に分けたのです。
これによって、たとえば、「Ａさん作の第一ブロック＋Ｂさん作の第二ブロック＋Ｆさん作の第三ブロック…」という
集め方が可能になります。こうすれば、収集者が多いファイルほど落としやすくなります。
これじゃキャッシュが増え過ぎそうなので乱数で確率的にしようとは思っていますが。
とりあえず、キャッシュフォルダから適当に大きな奴だけ削除する奴等を排除するため、
キャッシュファイルはチェイン構造にして記録させようかと思っています。
キャッシュA には キャッシュB と書いてあり、B には C、C には D …と書いておく奴です。
一個消すと続き全部のキャッシュが読めなくなる仕掛けです。
その上で、持っているキャッシュが少ないと損をする仕掛けを模索しています。
ダウンロード効率について
> あともう１点。１つのファイルをダウンするためのデータの断片があちこちのノードに
> 分散することになるので、>>333-334 にある復元確率低下の問題が起こる危険があります。
> これも考えておかないといけないのではと思います。
完全キャッシュを手にした場合には、そのファイルを自動で最放流しようかと考えています。
その際には当然違う無作為キャッシュを使って。このためにブロック情報を二段階に分けたのです。
これによって、たとえば、「Ａさん作の第一ブロック＋Ｂさん作の第二ブロック＋Ｆさん作の第三ブロック…」という
集め方が可能になります。こうすれば、収集者が多いファイルほど落としやすくなります。
これじゃキャッシュが増え過ぎそうなので乱数で確率的にしようとは思っていますが。
とりあえず、キャッシュフォルダから適当に大きな奴だけ削除する奴等を排除するため、
キャッシュファイルはチェイン構造にして記録させようかと思っています。
キャッシュA には キャッシュB と書いてあり、B には C、C には D …と書いておく奴です。
一個消すと続き全部のキャッシュが読めなくなる仕掛けです。
その上で、持っているキャッシュが少ないと損をする仕掛けを模索しています。
>>857-858
なんか、かなりちゃんと考えられてますね。
誰も欲しがらないファイルであっても多量のキャッシュを広めてしまうシステムなようなので、
強制拡散に帯域が食われることと、トコロテン式に価値のあるキャッシュが消えてしまうのが心配です。
でも、匿名性に関しては問題なさげですね。私としては期待モードです。
個人的には「隣接～」方式がすでに完成されたと言っていい状態にあるようなので、
次世代ファイル共有はこれで決まりかな、と思ってます。しかし、
もし法的に「内容を知らなくても違法なキャッシュを持つと責任を問われる」ことに
なったとしたら、「隣接～」方式はアウトですが無作為XOR方式なら生き残れる可能性があるので、
無作為XORは重要な方式であると認識してます。
β版が出てくるのが楽しみです。821氏、期待してます、ぜひ頑張ってください！
なんか、かなりちゃんと考えられてますね。
誰も欲しがらないファイルであっても多量のキャッシュを広めてしまうシステムなようなので、
強制拡散に帯域が食われることと、トコロテン式に価値のあるキャッシュが消えてしまうのが心配です。
でも、匿名性に関しては問題なさげですね。私としては期待モードです。
個人的には「隣接～」方式がすでに完成されたと言っていい状態にあるようなので、
次世代ファイル共有はこれで決まりかな、と思ってます。しかし、
もし法的に「内容を知らなくても違法なキャッシュを持つと責任を問われる」ことに
なったとしたら、「隣接～」方式はアウトですが無作為XOR方式なら生き残れる可能性があるので、
無作為XORは重要な方式であると認識してます。
β版が出てくるのが楽しみです。821氏、期待してます、ぜひ頑張ってください！
>856
失礼しました、オープンソースでのDOM対策ですね。
>855
ぶっちゃけそうかも…
仕組みばっかり説明してたので雰囲気としては、
MXの転送をBitTorrent風にして回線めいいっぱい使って、
アホ検索による大量DLでキャッシュ増えまくりって感じ。
単なるモラルハザード版MXとも言える。
ついでに第一UPの問題があるけどBitTorrentの説明で使えるかなと思ったのが、
細かく分けたファイルをとなり同士別々に半分ずつ流してみよう、
（1つのIPに半分しか流さないように2つのIPに流す設定）
最高だとネットワークリングの反対側、最短で2つ先で結ばれて1つのファイルになる。
ストーキングするぐらい熱狂的なポエムファンも大丈夫（？）
っとそろそろヤヴァい話になってきたんで消えます。
失礼しました、オープンソースでのDOM対策ですね。
>855
ぶっちゃけそうかも…
仕組みばっかり説明してたので雰囲気としては、
MXの転送をBitTorrent風にして回線めいいっぱい使って、
アホ検索による大量DLでキャッシュ増えまくりって感じ。
単なるモラルハザード版MXとも言える。
ついでに第一UPの問題があるけどBitTorrentの説明で使えるかなと思ったのが、
細かく分けたファイルをとなり同士別々に半分ずつ流してみよう、
（1つのIPに半分しか流さないように2つのIPに流す設定）
最高だとネットワークリングの反対側、最短で2つ先で結ばれて1つのファイルになる。
ストーキングするぐらい熱狂的なポエムファンも大丈夫（？）
っとそろそろヤヴァい話になってきたんで消えます。
861 ： ◆XoFE2Orpbo ：04/01/20 13:55 ID:WboQRHdx
個人的まとめｗ
長いですｽﾏｿ。でも各開発者は以下を考慮すべーし。
・どうやってUP人の匿名性が保持されるのか
・ついでにDL人の匿名性が保持されているか
以上は最低限考えるべきことだし、このスレでは様々な案が出ている。
考えるポイント
・中継、仲介ノードはどのように利用されるのか。
（またどれくらいの頻度で起こりうるのか）
・転送が中継か直か分からないようになっているか。
（逆に言うと、もし直転送であっても匿名性が保持されるか）
（100%中継保証を考える場合はそのアルゴリズムの有効性は十分か）
・迅速に必要なファイルを検索し発見できるか。
（目的のファイルをDLする時と、ﾏﾀｰﾘとキーワードで落とす時）
・キャッシュおよび転送ブロックに情報の秘匿性があるか。
（ローカルで内容が確認できないようになっているか）
・Port0や新規ファイルをUPしない人たちでも利用しうるか
（これらを排除すべきでは無いと考える。どう活用するのか）
・低速なノードをどうするか
（排除するのか否か、及び転送効率のボトルネックについて）
長いですｽﾏｿ。でも各開発者は以下を考慮すべーし。
・どうやってUP人の匿名性が保持されるのか
・ついでにDL人の匿名性が保持されているか
以上は最低限考えるべきことだし、このスレでは様々な案が出ている。
考えるポイント
・中継、仲介ノードはどのように利用されるのか。
（またどれくらいの頻度で起こりうるのか）
・転送が中継か直か分からないようになっているか。
（逆に言うと、もし直転送であっても匿名性が保持されるか）
（100%中継保証を考える場合はそのアルゴリズムの有効性は十分か）
・迅速に必要なファイルを検索し発見できるか。
（目的のファイルをDLする時と、ﾏﾀｰﾘとキーワードで落とす時）
・キャッシュおよび転送ブロックに情報の秘匿性があるか。
（ローカルで内容が確認できないようになっているか）
・Port0や新規ファイルをUPしない人たちでも利用しうるか
（これらを排除すべきでは無いと考える。どう活用するのか）
・低速なノードをどうするか
（排除するのか否か、及び転送効率のボトルネックについて）
862 ： ◆XoFE2Orpbo ：04/01/20 13:56 ID:WboQRHdx
・ネットワーク全体のトラフィックについて考えられているか
（不必要に大量の通信を行うことは好ましくない）
・キャッシュの拡散は十分に行われるか
（特にUP初期の拡散と、その安全性）
・どのような段階でファイルがネットワークから消滅するか
（古いファイル？需要の少ないファイル？何らかの消去要求がある場合？）
・捏造ファイルへの対策は十分か
（拡散を抑えられるか。利用者がDLしないで済む方法はあるか）
・存在しない（消滅した？）ファイル・ハッシュのDL要求が無限に転送されないか
（また、存在しないファイルのキー情報がネットワーク上に残りうる危険について）
・違法ファイル交換の温床と揶揄されないための機能はあるか
（BBS？メッセ？ネトゲ？そのほか）
オープンソース化する場合や耐クラックで、特に以下の点が十分か
１．改造によって中継操作を誤魔化されないか（UPノードに直接続できないか）
２．上に関連してUP者の匿名性を落とされる危険はないか
（１，２は即ち、匿名性の障壁とならないか）
３．中継ノードが転送ブロックをキャッシュ化しなくなる恐れ
４．DL中ファイル以外のキャッシュを即消しされないか
（３，４は即ち、キャッシュの分散に障壁とならないか）
５．UP枠をなくし、DOMを演じることは出来ないか
（５は即ち、不公平な利用を可能としないか）
（不必要に大量の通信を行うことは好ましくない）
・キャッシュの拡散は十分に行われるか
（特にUP初期の拡散と、その安全性）
・どのような段階でファイルがネットワークから消滅するか
（古いファイル？需要の少ないファイル？何らかの消去要求がある場合？）
・捏造ファイルへの対策は十分か
（拡散を抑えられるか。利用者がDLしないで済む方法はあるか）
・存在しない（消滅した？）ファイル・ハッシュのDL要求が無限に転送されないか
（また、存在しないファイルのキー情報がネットワーク上に残りうる危険について）
・違法ファイル交換の温床と揶揄されないための機能はあるか
（BBS？メッセ？ネトゲ？そのほか）
オープンソース化する場合や耐クラックで、特に以下の点が十分か
１．改造によって中継操作を誤魔化されないか（UPノードに直接続できないか）
２．上に関連してUP者の匿名性を落とされる危険はないか
（１，２は即ち、匿名性の障壁とならないか）
３．中継ノードが転送ブロックをキャッシュ化しなくなる恐れ
４．DL中ファイル以外のキャッシュを即消しされないか
（３，４は即ち、キャッシュの分散に障壁とならないか）
５．UP枠をなくし、DOMを演じることは出来ないか
（５は即ち、不公平な利用を可能としないか）
863 ： ◆XoFE2Orpbo ：04/01/20 14:03 ID:WboQRHdx
これだけ全部考えるのは大変だなぁ。
ただ、満たしている分だけ将来性や利用者のメリットにはなるわな。
＞・違法ファイル交換の温床と揶揄されないための機能はあるか
違法ファイルを推奨してるわけではありませんので！
ただ、行うなと書くだけではやはり不十分。
健全なファイル・利用者をどう確保するかという問題でもあります。
ただ、満たしている分だけ将来性や利用者のメリットにはなるわな。
＞・違法ファイル交換の温床と揶揄されないための機能はあるか
違法ファイルを推奨してるわけではありませんので！
ただ、行うなと書くだけではやはり不十分。
健全なファイル・利用者をどう確保するかという問題でもあります。
864 ：[名無し]さん(bin+cue).rar：04/01/20 14:14 ID:9X2U4ipv
>>863
無理
無理
865 ：[名無し]さん(bin+cue).rar：04/01/20 14:43 ID:k3E/0YUY
独り言だけど
今大規模P2Pチャット目指してる。
気が向けばMSNメッセ程度のファイル共有機能は実装する予定。
上位互換性を考えるとなかなか前に進めない(´･ω･｀)
匿名性はおそらくそこそこある(多段中継)
オープンソース化すると
中継途中でメッセージを破棄(チャットとしては致命的)
匿名性の喪失(こちらは効率を多少犠牲にして回避できるかもしれない)
他いろいろな問題が発生しそう
テスト環境がないのでもしかするとこちらでα版を公開させていただくかもしれない。
866 ：[名無し]さん(bin+cue).rar：04/01/20 15:10 ID:fZUndjan
村長の強制UP案も検討対象に入れてくれ。
あとクラックについては、ゲームソフトで
改造対策に使われているファイルチェックなどを導入してはどうだろうか。
もちろん時間稼ぎに過ぎないだろうが。
低速ノードについてはnyと同様、利用するか否かはダウン側に選択させれば良いかと。
新規ファイルをUPしない人は、転送ノードとしては十分利用可能。
Port0はUPしてくれれば良いし、してくれなくても転送ノードとしては利用できる。
それにPort0にしたらPort0の人とは通信できなくなる訳だし、
わざわざPort0にする人っているんだろうか？
あとクラックについては、ゲームソフトで
改造対策に使われているファイルチェックなどを導入してはどうだろうか。
もちろん時間稼ぎに過ぎないだろうが。
低速ノードについてはnyと同様、利用するか否かはダウン側に選択させれば良いかと。
新規ファイルをUPしない人は、転送ノードとしては十分利用可能。
Port0はUPしてくれれば良いし、してくれなくても転送ノードとしては利用できる。
それにPort0にしたらPort0の人とは通信できなくなる訳だし、
わざわざPort0にする人っているんだろうか？
867 ：[名無し]さん(bin+cue).rar：04/01/20 16:20 ID:uAMIRyHm
Winnyの捏造対策機能を応用して、特定のファイルに対して指定以上の捏造警告キーを受け取ったとき、そのキャッシュを自動的に削除するのはどう？
868 ：[名無し]さん(bin+cue).rar：04/01/20 17:22 ID:FAdeVfDe
自動的にキャッシュを消す仕組みを実装するということは
あるキャッシュを消したい人間がちょっと努力をすれば消せてしまうということです
警告キーの数だけで考えるのは甘いと思いますよ
あるキャッシュを消したい人間がちょっと努力をすれば消せてしまうということです
警告キーの数だけで考えるのは甘いと思いますよ
869 ：[名無し]さん(bin+cue).rar：04/01/20 17:23 ID:lYT2Qilm
キャッシュを消したい人間 の意味は、分かりますよね？
870 ：[名無し]さん(bin+cue).rar：04/01/20 17:26 ID:UPSNUOQb
>>863
合法スレでちょっと話に出しましたがライセンス管理の機能が必要です
合法スレでちょっと話に出しましたがライセンス管理の機能が必要です
871 ：[名無し]さん(bin+cue).rar：04/01/20 17:36 ID:edRz1zDy
捏造ファイルっていうのは無制限に増やすことができるから、駆逐することは難しい。
むしろ、健全なファイルや信頼できるトリップの情報を共有する方法を考えるべき。
むしろ、健全なファイルや信頼できるトリップの情報を共有する方法を考えるべき。
正直P2Pはまだ早い
正直C#で作ってるんだろ
874 ：[名無し]さん(bin+cue).rar：04/01/20 18:58 ID:lYT2Qilm
ちょっとだけﾜﾗﾀ
875 ：[名無し]さん(bin+cue).rar：04/01/20 20:46 ID:fZUndjan
捏造についてはACCSのインタビューが掲載されたディープネットに載ってたんだが、
nyの機能だけでも案外有効だそうだ。
意図的に流しても2週間ほどで消えたらしい。
もちろん更に期間を縮小したいところだけどね。
ところで合法スレ見たんだがライセンス管理のレスが見当たらない。
どの辺だか教えてくれませんか？
nyの機能だけでも案外有効だそうだ。
意図的に流しても2週間ほどで消えたらしい。
もちろん更に期間を縮小したいところだけどね。
ところで合法スレ見たんだがライセンス管理のレスが見当たらない。
どの辺だか教えてくれませんか？
876 ：[名無し]さん(bin+cue).rar：04/01/20 20:59 ID:edRz1zDy
捏造したところで本物は消えないわけだから、それほど問題でもないしな。
877 ：[名無し]さん(bin+cue).rar：04/01/20 22:34 ID:Qc9ZXlDD
CELLA氏のはどうなったの？
878 ：[名無し]さん(bin+cue).rar：04/01/20 23:22 ID:9qGalthH
あからさまにリア厨の意見が混じってると笑えるな
879 ：[名無し]さん(bin+cue).rar：04/01/20 23:38 ID:lYT2Qilm
リアル厨坊の発想が画期的な仕様を生み出す可能性は否定できない
ただもう少し自分の意見を客観的に見直す時間を持ってみるべき
ただもう少し自分の意見を客観的に見直す時間を持ってみるべき
880 ：[名無し]さん(bin+cue).rar：04/01/21 01:51 ID:cW67WmM+
まあ、猿にタイプライターを渡したら名文が出来る可能性もあるわけだしな
881 ：[名無し]さん(bin+cue).rar：04/01/21 02:24 ID:y3KNmEqP
つまらんな
882 ： ◆Fw0Kir8iYA ：04/01/21 02:25 ID:9UtfBxc8
ご無沙汰してます。「隣接…」の提案者です。
>>859
自演と思われそうなので、一応カキコ。859は私じゃないです。
＞もし法的に「内容を知らなくても違法なキャッシュを持つと責任を問われる」ことに
＞なったとしたら、「隣接～」方式はアウトですが無作為XOR方式なら生き残れる可能性があるので、
「隣接…」のキャッシュは、winnyに比べて違法性が低くなるよう設計してありますが、
ご指摘の通り「内容のわからない部分キャッシュ」までアウトになると、今の「隣接…」の
仕様でも対処できません。ただし、これは「隣接…」の問題ではなく、キャッシュ作成法の
問題です。
「隣接…」のメインは、あくまで『強制アップロードすることなく匿名性を確保
できる転送法』であり、キャッシュの作成法は無関係です。もし「内容のわからない
部分キャッシュ」も不可になれば、「隣接…」でも無作為XORを採用するかもしれません。
＞個人的には「隣接～」方式がすでに完成されたと言っていい状態にあるようなので、
仕様はだいぶ落ち着いてきましたが、まだまだ某所にていろいろ検討中です。
ご意見お待ちしてます。
＞次世代ファイル共有はこれで決まりかな、と思ってます。
うれしい一言ですが、これは過大評価ですよw
>>866で書かれている強制アップロード案も、現時点では有効な仕様です。
どちらかが主流になるというわけではなく、両方が共存することになるのでは
ないかと思っています。
>>859
自演と思われそうなので、一応カキコ。859は私じゃないです。
＞もし法的に「内容を知らなくても違法なキャッシュを持つと責任を問われる」ことに
＞なったとしたら、「隣接～」方式はアウトですが無作為XOR方式なら生き残れる可能性があるので、
「隣接…」のキャッシュは、winnyに比べて違法性が低くなるよう設計してありますが、
ご指摘の通り「内容のわからない部分キャッシュ」までアウトになると、今の「隣接…」の
仕様でも対処できません。ただし、これは「隣接…」の問題ではなく、キャッシュ作成法の
問題です。
「隣接…」のメインは、あくまで『強制アップロードすることなく匿名性を確保
できる転送法』であり、キャッシュの作成法は無関係です。もし「内容のわからない
部分キャッシュ」も不可になれば、「隣接…」でも無作為XORを採用するかもしれません。
＞個人的には「隣接～」方式がすでに完成されたと言っていい状態にあるようなので、
仕様はだいぶ落ち着いてきましたが、まだまだ某所にていろいろ検討中です。
ご意見お待ちしてます。
＞次世代ファイル共有はこれで決まりかな、と思ってます。
うれしい一言ですが、これは過大評価ですよw
>>866で書かれている強制アップロード案も、現時点では有効な仕様です。
どちらかが主流になるというわけではなく、両方が共存することになるのでは
ないかと思っています。
883 ：[名無し]さん(bin+cue).rar：04/01/21 03:48 ID:icwOMFei
１ノードが１ファイルをダウンロードするのにかかるコスト（転送量）は他の誰も再利用出来ない。
そうなれば考えうることは全体的な帯域不足、次期P2Pはピュアなポエム共有ソフトとなりそうですね。
超安全志向であるということなので開発を進めるのは構いませんが・・。
そうなれば考えうることは全体的な帯域不足、次期P2Pはピュアなポエム共有ソフトとなりそうですね。
超安全志向であるということなので開発を進めるのは構いませんが・・。
なかなか難しい
885 ：ひろゆき：04/01/21 21:59 ID:8XDkgkVz
だな
886 ：[名無し]さん(bin+cue).rar：04/01/21 22:07 ID:ItbtJXoH
887 ：[名無し]さん(bin+cue).rar：04/01/21 22:40 ID:D8ijN2ZY
>>886
シェアウェアにするのか？
シェアウェアにするのか？
888 ：[名無し]さん(bin+cue).rar：04/01/21 22:44 ID:562NH7Fj
対クラック技術の共同開発って意味だろ
889 ：[名無し]さん(bin+cue).rar：04/01/21 22:52 ID:cvqk4VK/
技術の共有は技術の漏洩を引き起こす
890 ：[名無し]さん(bin+cue).rar：04/01/21 23:05 ID:0AAaK3da
公開している以上クラックは避けられないし。
891 ：[名無し]さん(bin+cue).rar：04/01/21 23:51 ID:yQOYIMjN
892 ：[名無し]さん(bin+cue).rar：04/01/22 00:51 ID:Xhofngnd
893 ：[名無し]さん(bin+cue).rar：04/01/22 15:49 ID:VpRi4n+o
894 ：[名無し]さん(bin+cue).rar：04/01/22 18:14 ID:IPE7QZcA
やぱり暗号方式は楕円曲線暗号なんですか？
895 ：[名無し]さん(bin+cue).rar：04/01/22 20:28 ID:FvNcgn2t
どちらかというと、暗号強度より暗号の使い方が問題。
楕円暗号は、たぶん利用可能なライブラリがないかも知らん。
どうでもいいけど、age ないでくだしぃ
楕円暗号は、たぶん利用可能なライブラリがないかも知らん。
どうでもいいけど、age ないでくだしぃ
896 ：[名無し]さん(bin+cue).rar：04/01/22 21:17 ID:a5mMqnHK
897 ：[名無し]さん(bin+cue).rar：04/01/23 09:31 ID:zLL9sFRp
お漏らししない方式に無作為ＸＯＲを乗っけたら最強だろうなあ。
ついでに信用情報方式（改）もつけてみたいな。
非常にそそられるが暇がないので、誰か作ってくれないかなとつぶやいてみるテスト
ついでに信用情報方式（改）もつけてみたいな。
非常にそそられるが暇がないので、誰か作ってくれないかなとつぶやいてみるテスト
898 ：[名無し]さん(bin+cue).rar：04/01/23 11:10 ID:Zx3NzJQx
過去ログ読んでなくて申し訳ないけど、ここの仕様にプロバイダが帯域制限を
かけられないようなプロトコルやデータの偽装ってのは考慮されてるのかな？
かけられないようなプロトコルやデータの偽装ってのは考慮されてるのかな？
899 ：[名無し]さん(bin+cue).rar：04/01/23 11:14 ID:zLL9sFRp
>>898
スレの方ではときどき議論されてて、http(s) 偽装したらどうかとか、データフロー解析されてるから
無駄なんじゃないかとかいう話で終わってたと思う。
でも今のところ、帯域制限を回避するためのまとまった仕様というのは出てきてない。
こればっかは、運用しながら調整するしかないんじゃないかな。いたちごっこにもなりそうだし。
スレの方ではときどき議論されてて、http(s) 偽装したらどうかとか、データフロー解析されてるから
無駄なんじゃないかとかいう話で終わってたと思う。
でも今のところ、帯域制限を回避するためのまとまった仕様というのは出てきてない。
こればっかは、運用しながら調整するしかないんじゃないかな。いたちごっこにもなりそうだし。
900 ：[名無し]さん(bin+cue).rar：04/01/23 11:37 ID:us7zBG4l
>>898
メールのプロトコルを使用するってのもあったような・・・。
メールのプロトコルを使用するってのもあったような・・・。
901 ：[名無し]さん(bin+cue).rar：04/01/23 11:41 ID:zLL9sFRp
あったね、忘れてた。
いずれにせよ、プロパが使ってる制限器の仕組みがわからないから机上の空論になってしまう。
やはり運用しながら試行錯誤しかないんじゃないかと思う。
いずれにせよ、プロパが使ってる制限器の仕組みがわからないから机上の空論になってしまう。
やはり運用しながら試行錯誤しかないんじゃないかと思う。
P2P技術についてよくしらないのですが。
いずれにせよ捏造ファイルが増えてくると思います。
ここで提案なのですがプログラム内に起動したら定期的にNTPサーバーの時刻と同期するようにしておいてファイル（またはファイル名？）に制限時間を作ってみてはどうでしょうか？
制限時間を越えるキャッシュがあるととクライアントはそのキャシュを削除していきます。そして有名ファイルは誰かの手によってまたUPされていくのです。
技術的な問題もあるかもしれませんがそこは皆様の手で何とかしていただけたらなーと思います。
いずれにせよ捏造ファイルが増えてくると思います。
ここで提案なのですがプログラム内に起動したら定期的にNTPサーバーの時刻と同期するようにしておいてファイル（またはファイル名？）に制限時間を作ってみてはどうでしょうか？
制限時間を越えるキャッシュがあるととクライアントはそのキャシュを削除していきます。そして有名ファイルは誰かの手によってまたUPされていくのです。
技術的な問題もあるかもしれませんがそこは皆様の手で何とかしていただけたらなーと思います。
903 ：[名無し]さん(bin+cue).rar：04/01/23 12:14 ID:W68qKYnn
新しいファイルだけを流通させるならそれもいいかもしれないけど
古いファイルとかは拡散の効率が落ちると思うな・・・
古いファイルとかは拡散の効率が落ちると思うな・・・
904 ：[名無し]さん(bin+cue).rar：04/01/23 13:01 ID:f0C+jVUl
ここはインターネットですね。
905 ：[名無し]さん(bin+cue).rar：04/01/23 13:10 ID:Zx3NzJQx
>>989-901
最終的にはいたちごっこになる部分があるのは否定しないけど、プロバイダが利用
するモノはある程度限られてるから十分に対応できる（やたら複雑なロジックを導入
した帯域制限機構はスループットを下げるのでプロバイダは採用しない）と思うし、
たとえいたちごっこになったとしても新機構導入や改変の手間（コスト）は圧倒的
にプロバイダの方が上だからこちらが勝つよ。
ま、恐らくどこのプロバイダもCiscoのルータやFirewall-1で出来るぐらいのこと
しかやってないと思うが、ぼちぼち調べて報告するさ。
最終的にはいたちごっこになる部分があるのは否定しないけど、プロバイダが利用
するモノはある程度限られてるから十分に対応できる（やたら複雑なロジックを導入
した帯域制限機構はスループットを下げるのでプロバイダは採用しない）と思うし、
たとえいたちごっこになったとしても新機構導入や改変の手間（コスト）は圧倒的
にプロバイダの方が上だからこちらが勝つよ。
ま、恐らくどこのプロバイダもCiscoのルータやFirewall-1で出来るぐらいのこと
しかやってないと思うが、ぼちぼち調べて報告するさ。
906 ：[名無し]さん(bin+cue).rar：04/01/23 13:15 ID:fzLwT8h/
捏造とは無関係に古いファイルが消えるだけの結果に終わる気がするね
907 ：[名無し]さん(bin+cue).rar：04/01/23 14:23 ID:rWiZjk/G
908 ：[名無し]さん(bin+cue).rar：04/01/23 17:00 ID:0gOrs6/7
47氏が無事と確認されたから、お前らもう用済み
どっか逝ってくれ
どっか逝ってくれ
909 ：[名無し]さん(bin+cue).rar：04/01/23 17:55 ID:myK5q6au
>>908
ソースｷﾎﾞﾝ
ソースｷﾎﾞﾝ
910 ：[名無し]さん(bin+cue).rar：04/01/23 18:03 ID:Kw4cM7NF
>>909
公式見れ
公式見れ
911 ：[名無し]さん(bin+cue).rar：04/01/23 18:13 ID:myK5q6au
>>910
2949は一時空き地だったから誰かに借りられた可能性もあるわけで・・・まあとりあえずサンクスです
2949は一時空き地だったから誰かに借りられた可能性もあるわけで・・・まあとりあえずサンクスです
912 ：[名無し]さん(bin+cue).rar：04/01/23 18:55 ID:8B8FvN3a
信用情報はトリップに対してつけるというのはどうだろう？
913 ：[名無し]さん(bin+cue).rar：04/01/23 20:09 ID:bu8UbwH1
どうだろうと言われても…他人が偽造できない識別コードを使うのは当然だろう。
Wiki の信用情報方式案になるような方式をとってもいいし、公開鍵とか
フィンガープリントを使うのでもいい。
Wiki の信用情報方式案になるような方式をとってもいいし、公開鍵とか
フィンガープリントを使うのでもいい。
914 ：[名無し]さん(bin+cue).rar：04/01/23 21:20 ID:YGkeq2pX
誰かが、無償で電子署名のＴＴＰとかを作ればＯＫなんだろうが。
ボランティアで誰かやるか？
ボランティアで誰かやるか？
915 ：[名無し]さん(bin+cue).rar：04/01/23 22:28 ID:UyrKb+Zx
>>914
ボランティアは任せた
ボランティアは任せた
916 ：[名無し]さん(bin+cue).rar：04/01/23 23:03 ID:C5yBQZzx
>>11のテンプレにzigumoさえ入ってるのにnyBBSが省かれてるのは何故だｗ
917 ：[名無し]さん(bin+cue).rar：04/01/23 23:16 ID:untfPsfl
>>914
SSL みたく正式な身元を保証するわけじゃなくて各ノードの本人確認ができればいいだけだから、
第三者機関を設ける必要はないと思うが。各ノードが勝手にＩＤを発行する方式で何ら問題がないと思われ。
それに、特定の機能を誰かのところに集中させるのは得策じゃないと思うよ。
そいつがこっそり信用乗っ取りに走ったり、難癖つけるのが得意なＫ君に狙われたり。
SSL みたく正式な身元を保証するわけじゃなくて各ノードの本人確認ができればいいだけだから、
第三者機関を設ける必要はないと思うが。各ノードが勝手にＩＤを発行する方式で何ら問題がないと思われ。
それに、特定の機能を誰かのところに集中させるのは得策じゃないと思うよ。
そいつがこっそり信用乗っ取りに走ったり、難癖つけるのが得意なＫ君に狙われたり。
918 ：[名無し]さん(bin+cue).rar：04/01/24 15:57 ID:eMBlEuDp
これって既出？
ttp://share.zero-yen.com/
ttp://share.zero-yen.com/
919 ：[名無し]さん(bin+cue).rar：04/01/24 16:20 ID:6zHLphGY
>>918
Shareじゃん。作者が匿名性の実現を放棄した（としか漏れには思えない）共有ソフト。
MX以上ny未満。Share についてはこっちで↓
http://tmp2.2ch.net/test/read.cgi/download/1074502637/l50
Shareじゃん。作者が匿名性の実現を放棄した（としか漏れには思えない）共有ソフト。
MX以上ny未満。Share についてはこっちで↓
http://tmp2.2ch.net/test/read.cgi/download/1074502637/l50
920 ：[名無し]さん(bin+cue).rar：04/01/24 17:15 ID:KxZHVke4
>MX以上
UPを制御できず（ny）、1対1の直接UP/DL（MX）のファイル共有ソフト。
MX以下でny以下と思われます。
UPを制御できず（ny）、1対1の直接UP/DL（MX）のファイル共有ソフト。
MX以下でny以下と思われます。
921 ：[名無し]さん(bin+cue).rar：04/01/24 20:32 ID:sjfLjkY6
藻まいらそろそろ次スレの事とか考えないんですか？
ったく、相変わらず計画性ないなあ。
テンプレもそろそろ古くなってるから書き直したほうがいい気がするが。
まあ>>432とか参考にしても良いかも知れんが
そのまんまってのも芸が無いよなあ。
ったく、相変わらず計画性ないなあ。
テンプレもそろそろ古くなってるから書き直したほうがいい気がするが。
まあ>>432とか参考にしても良いかも知れんが
そのまんまってのも芸が無いよなあ。
922 ：[名無し]さん(bin+cue).rar：04/01/24 21:31 ID:Hb8viK6F
聞きたいんですけど、C#かC++で共有ソフトって作れますか？ 何年かかってもいいです。 プログラミング挑戦してみたいのですがC#ってあんまりいいと聞かないので・・・ スレ違い申し訳ないです。
923 ：[名無し]さん(bin+cue).rar：04/01/24 21:58 ID:cVyUbTjG
>>922
作れる
作れる
924 ：[名無し]さん(bin+cue).rar：04/01/24 22:25 ID:Hb8viK6F
有難うございます。
C#ってなんで評判悪いんでしょうか？
C#ってなんで評判悪いんでしょうか？
925 ：[名無し]さん(bin+cue).rar：04/01/24 22:46 ID:LDNZjAN7
926 ：[名無し]さん(bin+cue).rar：04/01/24 23:01 ID:Hb8viK6F
C++に挑戦してみます。
目標はここの人達の言ってることを理解する事で(^_^;)
有難うございました
目標はここの人達の言ってることを理解する事で(^_^;)
有難うございました
927 ：[名無し]さん(bin+cue).rar：04/01/25 02:13 ID:+ACB0i2q
>>861もテンプレに入れましょう
928 ：[名無し]さん(bin+cue).rar：04/01/25 18:22 ID:zkmker5X
>>861
中継における転送速度の低下って、どれぐらい出てくるのかよくわからんのよね。
中継における転送速度の低下って、どれぐらい出てくるのかよくわからんのよね。
さてさて、結構前に開発宣言した者です。
あれからいろいろ考えて、いくつか思ったので...
DL したらこれを再びキャッシュにして落としやすさを上げる。としたけれど、
ネットワーク全体でみたときのキャッシュ容量はどんどん膨れ上がることになり、
いつか飽和するんじゃないかと思って、結構悩んでいます。
落として一ヶ月たったキャッシュは消す、とかどうでしょうか。
あと、クラスタ化の、"キーワードが近い" ってどうやって判定するんでしょう？
あんまりシビアだとつながらないし、緩いと関係ないものがつながってきて……
ところで、UNIX 対応にしてほしい人って居ます？
いるなら GTK+ で開発しようかなどと思っています。
( だれが次スレを立てるんだろう… )
あれからいろいろ考えて、いくつか思ったので...
DL したらこれを再びキャッシュにして落としやすさを上げる。としたけれど、
ネットワーク全体でみたときのキャッシュ容量はどんどん膨れ上がることになり、
いつか飽和するんじゃないかと思って、結構悩んでいます。
落として一ヶ月たったキャッシュは消す、とかどうでしょうか。
あと、クラスタ化の、"キーワードが近い" ってどうやって判定するんでしょう？
あんまりシビアだとつながらないし、緩いと関係ないものがつながってきて……
ところで、UNIX 対応にしてほしい人って居ます？
いるなら GTK+ で開発しようかなどと思っています。
( だれが次スレを立てるんだろう… )
930 ：[名無し]さん(bin+cue).rar：04/01/25 19:20 ID:iVDYpfKO
> ネットワーク全体でみたときのキャッシュ容量はどんどん膨れ上がることになり、
> いつか飽和するんじゃないかと思って、結構悩んでいます。
> 落として一ヶ月たったキャッシュは消す、とかどうでしょうか。
一ヶ月でも十分容量が膨れそうな気がする。ユーザが上限を決められるのがいいな。
キャッシュが多いほど落としやすい仕組みが理想だけど、オープンソースだと難しいかなあ・・・。
いずれにせよ、勝手に容量を圧迫する＆キャッシュを持っていてもメリットがないという条件が揃うと
キャッシュ全消し厨が増える予感。
> あと、クラスタ化の、"キーワードが近い" ってどうやって判定するんでしょう？
> あんまりシビアだとつながらないし、緩いと関係ないものがつながってきて……
nyは部分一致チェックもしてたみたいだけど、個人的には完全一致でもいいような気がする。
ユーザがちゃんと大分類・中分類・小分類といった感じで入れるなら問題ないかと。
部分一致で行くのなら、アルゴリズムの検討を手伝いたいと思うのでレスください。
> ところで、UNIX 対応にしてほしい人って居ます？
> いるなら GTK+ で開発しようかなどと思っています。
個人的には UNIX 対応欲しいけど、それ以上に Win に入れるときに別なものインスコするのが面倒い。
> ( だれが次スレを立てるんだろう… )
950踏んだ人。
> いつか飽和するんじゃないかと思って、結構悩んでいます。
> 落として一ヶ月たったキャッシュは消す、とかどうでしょうか。
一ヶ月でも十分容量が膨れそうな気がする。ユーザが上限を決められるのがいいな。
キャッシュが多いほど落としやすい仕組みが理想だけど、オープンソースだと難しいかなあ・・・。
いずれにせよ、勝手に容量を圧迫する＆キャッシュを持っていてもメリットがないという条件が揃うと
キャッシュ全消し厨が増える予感。
> あと、クラスタ化の、"キーワードが近い" ってどうやって判定するんでしょう？
> あんまりシビアだとつながらないし、緩いと関係ないものがつながってきて……
nyは部分一致チェックもしてたみたいだけど、個人的には完全一致でもいいような気がする。
ユーザがちゃんと大分類・中分類・小分類といった感じで入れるなら問題ないかと。
部分一致で行くのなら、アルゴリズムの検討を手伝いたいと思うのでレスください。
> ところで、UNIX 対応にしてほしい人って居ます？
> いるなら GTK+ で開発しようかなどと思っています。
個人的には UNIX 対応欲しいけど、それ以上に Win に入れるときに別なものインスコするのが面倒い。
> ( だれが次スレを立てるんだろう… )
950踏んだ人。
931 ：[名無し]さん(bin+cue).rar：04/01/25 19:32 ID:TM6r45AN
>>929
> DL したらこれを再びキャッシュにして落としやすさを上げる。
これが良く分からないんですが、具体的にはどう落としやすくなるんでしょうか？
XOR方式ならキャッシュしないでそのまま転送した方が効率がいい気がするんですが…
> DL したらこれを再びキャッシュにして落としやすさを上げる。
これが良く分からないんですが、具体的にはどう落としやすくなるんでしょうか？
XOR方式ならキャッシュしないでそのまま転送した方が効率がいい気がするんですが…
932 ：[名無し]さん(bin+cue).rar：04/01/25 19:42 ID:bpunUF60
>>932
あぁ、いやそういうことではなくてXOR分割したファイルをそのままコピーしただけじゃダメなんですか？
という意味です。
キャッシュという別のファイルに変換をするのかと思ったもので
言葉足らずですみません
あぁ、いやそういうことではなくてXOR分割したファイルをそのままコピーしただけじゃダメなんですか？
という意味です。
キャッシュという別のファイルに変換をするのかと思ったもので
言葉足らずですみません
>>930
> 一ヶ月でも十分容量が膨れそうな気がする。ユーザが上限を決められるのがいいな。
なるほど、上限は自分で決めれるようにしたほうがよさそうですね。
キャッシュのサイズとかでも指定できればなおよさそうですね。
> キャッシュが多いほど落としやすい仕組みが理想だけど、オープンソースだと難しいかなあ・・・。
逆にキャッシュが少ないと損をする仕組みの方が考えやすいかも…
クライアントの自己申告はあてに出来ないので、たとえば
クライアントA がリクエスト送信、クライアントB はそれをもっているとして、
B は流れてるキーから適当にハッシュを何個か集めてそれを逆に
A に向けてリクエスト。双方向ともいくつか中継した上で交換にしてやれば、
キャッシュ拡散にもなっていいかなぁ…とか。今度は偽造が増えるか…
> nyは部分一致チェックもしてたみたいだけど、個人的には完全一致でもいいような気がする。
> ユーザがちゃんと大分類・中分類・小分類といった感じで入れるなら問題ないかと。
> 部分一致で行くのなら、アルゴリズムの検討を手伝いたいと思うのでレスください。
完全一致だと、"【合法】" というキーワードと "『合法』" が別になってしまいますし、
揺らぐのは括弧だけとも限らないので、よさそうなアルゴリズムを探しています。
完全一致にして、ユーザー側でどうにかしてもらおうというのもアリでしょうけどね。
> 個人的には UNIX 対応欲しいけど、それ以上に Win に入れるときに別なものインスコするのが面倒い。
GTK+ は LGPL なので、コンパイル済みWin32バイナリを同梱するのは可能だったと思います。
記憶違いだったらすいません…
>>931-933
１つの生データを生成するために二つのキャッシュファイルが必要になるため、
"片方しか手に入らない" という事態も充分にありうるので、生データをもう一回
今度は別の無作為データで XOR 化します。
ただ、あんまり種類が増えすぎても問題なので、乱数で確率的にやろうと。
もしくは「落としやすさを上げるためにUPしなおしますか？」とか聞いてみるとか。
> 一ヶ月でも十分容量が膨れそうな気がする。ユーザが上限を決められるのがいいな。
なるほど、上限は自分で決めれるようにしたほうがよさそうですね。
キャッシュのサイズとかでも指定できればなおよさそうですね。
> キャッシュが多いほど落としやすい仕組みが理想だけど、オープンソースだと難しいかなあ・・・。
逆にキャッシュが少ないと損をする仕組みの方が考えやすいかも…
クライアントの自己申告はあてに出来ないので、たとえば
クライアントA がリクエスト送信、クライアントB はそれをもっているとして、
B は流れてるキーから適当にハッシュを何個か集めてそれを逆に
A に向けてリクエスト。双方向ともいくつか中継した上で交換にしてやれば、
キャッシュ拡散にもなっていいかなぁ…とか。今度は偽造が増えるか…
> nyは部分一致チェックもしてたみたいだけど、個人的には完全一致でもいいような気がする。
> ユーザがちゃんと大分類・中分類・小分類といった感じで入れるなら問題ないかと。
> 部分一致で行くのなら、アルゴリズムの検討を手伝いたいと思うのでレスください。
完全一致だと、"【合法】" というキーワードと "『合法』" が別になってしまいますし、
揺らぐのは括弧だけとも限らないので、よさそうなアルゴリズムを探しています。
完全一致にして、ユーザー側でどうにかしてもらおうというのもアリでしょうけどね。
> 個人的には UNIX 対応欲しいけど、それ以上に Win に入れるときに別なものインスコするのが面倒い。
GTK+ は LGPL なので、コンパイル済みWin32バイナリを同梱するのは可能だったと思います。
記憶違いだったらすいません…
>>931-933
１つの生データを生成するために二つのキャッシュファイルが必要になるため、
"片方しか手に入らない" という事態も充分にありうるので、生データをもう一回
今度は別の無作為データで XOR 化します。
ただ、あんまり種類が増えすぎても問題なので、乱数で確率的にやろうと。
もしくは「落としやすさを上げるためにUPしなおしますか？」とか聞いてみるとか。
>>934
なるほど、nyで言う完全キャッシュと部分キャッシュの関係と少し似てますね。(部分キャッシュは正確には違いますけど)
ただ、nyとの差別化を図るためにも完全に部分キャッシュでやる方法はないものかなとか思ってしまいます…。
完全キャッシュがあるとXORを使う意味がなくなってしまうんじゃないかなぁと
なるほど、nyで言う完全キャッシュと部分キャッシュの関係と少し似てますね。(部分キャッシュは正確には違いますけど)
ただ、nyとの差別化を図るためにも完全に部分キャッシュでやる方法はないものかなとか思ってしまいます…。
完全キャッシュがあるとXORを使う意味がなくなってしまうんじゃないかなぁと
>>934
> 完全一致だと、"【合法】" というキーワードと "『合法』" が別になってしまいますし、
> 揺らぐのは括弧だけとも限らないので、よさそうなアルゴリズムを探しています。
ny はむかしクラスタワードがファイル名とも比較されるようになっていたので、
括弧が使われているのはその名残りでしょう。個人的にはユーザ側が合わせればいいと思います。
いちおう、部分一致チェックの方法を提案しておきます。こんなのはいかがでしょう。
まずクラスタワードを前処理して、連続文字リストを作ります。
クラスタワードは16bit文字(wchar)配列 cluster_word[] に格納されているとして、
typedef pair<wchar,wchar> wpair;
set<wpair> list;
for(wchar *pt=cluster_word; pt[1]!='\0'; ++pt) {
list.insert( wpair(pt[0],pt[1]) );
}
この連続文字リスト同士を比較して、優先度 point を算出します。
int point=0;
for(set<wpair>::iterator itr=list1.begin(); itr!=list1.end(); ++itr){
if( list2.find(*itr)!=list2.end() ) {
++point;
}
}
連続する２文字のペアのリストを作っておき、両者に含まれている連続文字の数を
数える方式です。
>GTK+ は LGPL なので、コンパイル済みWin32バイナリを同梱するのは可能だったと思います。
あ、そんなら問題ないですね。UNIX対応希望です。
> 完全一致だと、"【合法】" というキーワードと "『合法』" が別になってしまいますし、
> 揺らぐのは括弧だけとも限らないので、よさそうなアルゴリズムを探しています。
ny はむかしクラスタワードがファイル名とも比較されるようになっていたので、
括弧が使われているのはその名残りでしょう。個人的にはユーザ側が合わせればいいと思います。
いちおう、部分一致チェックの方法を提案しておきます。こんなのはいかがでしょう。
まずクラスタワードを前処理して、連続文字リストを作ります。
クラスタワードは16bit文字(wchar)配列 cluster_word[] に格納されているとして、
typedef pair<wchar,wchar> wpair;
set<wpair> list;
for(wchar *pt=cluster_word; pt[1]!='\0'; ++pt) {
list.insert( wpair(pt[0],pt[1]) );
}
この連続文字リスト同士を比較して、優先度 point を算出します。
int point=0;
for(set<wpair>::iterator itr=list1.begin(); itr!=list1.end(); ++itr){
if( list2.find(*itr)!=list2.end() ) {
++point;
}
}
連続する２文字のペアのリストを作っておき、両者に含まれている連続文字の数を
数える方式です。
>GTK+ は LGPL なので、コンパイル済みWin32バイナリを同梱するのは可能だったと思います。
あ、そんなら問題ないですね。UNIX対応希望です。
うわっ、インデントが消えてしまった。サンプルコードが見づらいのはご容赦を・・・
938 ：[名無し]さん(bin+cue).rar：04/01/25 22:17 ID:kTkz/0JM
>>934
１ヵ月後とか期間じゃなくて、ダウンロードされた回数で判断したら？
増える時はねずみ算式で倍増するから、
前の日は全然落とせなかったのに、次の日は楽々３重ダウンロードとかよくあるよ。
皆が同じファイル持ってても無駄なだけだし、
逆に回転が遅いファイルは、１ヵ月じゃ全然足りないだろうね。
でも連続ダウンロードされたらまずいから、
検索して自分以外にキャッシュが存在するのを確認した方がよいかも。
あと回線速度と接続時間も考慮してほしい。
回線速度ｘ接続時間が大きい人は、サイズの大きいファイルを残す。
回線速度ｘ接続時間が小さい人は、サイズの小さいファイルを残す。
１ヵ月後とか期間じゃなくて、ダウンロードされた回数で判断したら？
増える時はねずみ算式で倍増するから、
前の日は全然落とせなかったのに、次の日は楽々３重ダウンロードとかよくあるよ。
皆が同じファイル持ってても無駄なだけだし、
逆に回転が遅いファイルは、１ヵ月じゃ全然足りないだろうね。
でも連続ダウンロードされたらまずいから、
検索して自分以外にキャッシュが存在するのを確認した方がよいかも。
あと回線速度と接続時間も考慮してほしい。
回線速度ｘ接続時間が大きい人は、サイズの大きいファイルを残す。
回線速度ｘ接続時間が小さい人は、サイズの小さいファイルを残す。
>>935
完全キャッシュは持ちませんよ。すべてXORデータのみが流通します。
ほしい人はリストどおりのXORデータを集めて、複合化して結合します。
>>936
なるほど…そういう判定法があったのか……
どちらのキーワードを for ループにかけるかで点数が違いますね。
長いほうを for にかける、とか統一したほうがいいかもしれないですね。
そういえば文字コードはどうしよう… wchar に統一でいいかなぁ…
>>938
キャッシュファイルに参照された回数を記録すれば実現可能ですね。
日付やサイズで切るより効率が良いかもしれないと思います。
> でも連続ダウンロードされたらまずいから、
> 検索して自分以外にキャッシュが存在するのを確認した方がよいかも。
リクエストパケットから、相手がほしがっているファイルは割り出せないように
しているので、それは無理です。中継もしていることだし、毎回経路を変えれば充分かと。
> あと回線速度と接続時間も考慮してほしい。
これは 実効帯域 と 平均接続時間 と読み替えさせてもらいます。
大きいファイルを小数 or 小さいファイルを多数 といったところでしょうか。
完全キャッシュは持ちませんよ。すべてXORデータのみが流通します。
ほしい人はリストどおりのXORデータを集めて、複合化して結合します。
>>936
なるほど…そういう判定法があったのか……
どちらのキーワードを for ループにかけるかで点数が違いますね。
長いほうを for にかける、とか統一したほうがいいかもしれないですね。
そういえば文字コードはどうしよう… wchar に統一でいいかなぁ…
>>938
キャッシュファイルに参照された回数を記録すれば実現可能ですね。
日付やサイズで切るより効率が良いかもしれないと思います。
> でも連続ダウンロードされたらまずいから、
> 検索して自分以外にキャッシュが存在するのを確認した方がよいかも。
リクエストパケットから、相手がほしがっているファイルは割り出せないように
しているので、それは無理です。中継もしていることだし、毎回経路を変えれば充分かと。
> あと回線速度と接続時間も考慮してほしい。
これは 実効帯域 と 平均接続時間 と読み替えさせてもらいます。
大きいファイルを小数 or 小さいファイルを多数 といったところでしょうか。
>>939
>どちらのキーワードを for ループにかけるかで点数が違いますね。
>長いほうを for にかける、とか統一したほうがいいかもしれないですね。
そうですね、ご指摘の通りです。
上記のサンプルコードは簡易版です。ソート済みリストを使ったより効率的なアルゴリズムがあります。
こちらはどちらをループにかけるかで結果が違うような問題は出ません。
釈迦に説法になりそうですが、もし必要でしたらまとめておきます。
>どちらのキーワードを for ループにかけるかで点数が違いますね。
>長いほうを for にかける、とか統一したほうがいいかもしれないですね。
そうですね、ご指摘の通りです。
上記のサンプルコードは簡易版です。ソート済みリストを使ったより効率的なアルゴリズムがあります。
こちらはどちらをループにかけるかで結果が違うような問題は出ません。
釈迦に説法になりそうですが、もし必要でしたらまとめておきます。
>>どちらのキーワードを for ループにかけるかで点数が違いますね。
>>長いほうを for にかける、とか統一したほうがいいかもしれないですね。
>そうですね、ご指摘の通りです。
あ、ウソ、どっちをforループにかけても得点は同じになります。
いずれにせよ、実装するときはソート済みリストの方が効率いいです。
>>長いほうを for にかける、とか統一したほうがいいかもしれないですね。
>そうですね、ご指摘の通りです。
あ、ウソ、どっちをforループにかけても得点は同じになります。
いずれにせよ、実装するときはソート済みリストの方が効率いいです。
942 ：[名無し]さん(bin+cue).rar：04/01/26 00:30 ID:BX/dTlEl
どうでも良いけど、まず一通り動くのを作ってくれ。
943 ：[名無し]さん(bin+cue).rar：04/01/26 00:56 ID:8jGRRQF0
944 ：[名無し]さん(bin+cue).rar：04/01/26 13:17 ID:WyHfXQ0j
>>939
>そういえば文字コードはどうしよう… wchar に統一でいいかなぁ…
UNIX対応も考えるなら、内部は16bitで統一しちゃうのが簡単でよろし。
通信時は、文字列は固定ハフマンで圧縮して送るのがいいかな。
最初からそこまでやるのも大変なので、圧縮に対応するのは後々のバージョンアップの時で。
それはともあれ、821さん期待してますよ～
>そういえば文字コードはどうしよう… wchar に統一でいいかなぁ…
UNIX対応も考えるなら、内部は16bitで統一しちゃうのが簡単でよろし。
通信時は、文字列は固定ハフマンで圧縮して送るのがいいかな。
最初からそこまでやるのも大変なので、圧縮に対応するのは後々のバージョンアップの時で。
それはともあれ、821さん期待してますよ～
Wiki に、クラスタワード類似度評価法についてのページをアップさせていただきました。
特に誰からリクエストされたわけでもありませんが(w 説明に不足な部分が多かったこと、
他の共有ソフトの開発にも有用であると（自分的に）思われることからページを用意しました。
この方法を応用すると、簡易で高速なファイル名のあいまい検索も実現できます。
Wiki の方にも書いてありますが、クラスタワード類似度評価、およびあいまい検索のための
ライブラリを提供する意思があります。共有ソフト開発者の方、ぜひご検討ください。
特に誰からリクエストされたわけでもありませんが(w 説明に不足な部分が多かったこと、
他の共有ソフトの開発にも有用であると（自分的に）思われることからページを用意しました。
この方法を応用すると、簡易で高速なファイル名のあいまい検索も実現できます。
Wiki の方にも書いてありますが、クラスタワード類似度評価、およびあいまい検索のための
ライブラリを提供する意思があります。共有ソフト開発者の方、ぜひご検討ください。
あまりネットワークの検索法について議論されてないような気がするんだけどWinnyと同じと考えていいのかなあ？
これ素直に読めばキャッシュの暗号強度以前に検索情報がだだ漏れしてるようにしか思えないんだけど…
ttp://internet.watch.impress.co.jp/static/column/jiken/2004/01/07/index.htm
完全共有はネタとしても、検索情報を拡散しないダミーファイルシステムは一考願いたし。
これ素直に読めばキャッシュの暗号強度以前に検索情報がだだ漏れしてるようにしか思えないんだけど…
ttp://internet.watch.impress.co.jp/static/column/jiken/2004/01/07/index.htm
完全共有はネタとしても、検索情報を拡散しないダミーファイルシステムは一考願いたし。
947 ：[名無し]さん(bin+cue).rar：04/01/26 20:16 ID:4emQ+ofn
検索情報が漏れて何が悪い
948 ：[名無し]さん(bin+cue).rar：04/01/26 21:37 ID:pXjyOd6O
とーとつですが、通信をＩＰ電話の様に偽装できんもんかね？
949 ：[名無し]さん(bin+cue).rar：04/01/26 21:45 ID:L7qyQpb8
ＩＰ電話って標準のプロトコル規定されてたっけか？
それはともかく、どこのプロバイダも無料ＩＰ電話をサポートすれば、
ＩＰ電話上のアナログモデム通信で完全な匿名性が実現できるな。
それはともかく、どこのプロバイダも無料ＩＰ電話をサポートすれば、
ＩＰ電話上のアナログモデム通信で完全な匿名性が実現できるな。
950 ：[名無し]さん(bin+cue).rar：04/01/26 22:04 ID:ZLZSC+7G
IP電話は単なるUDP。
951 ：[名無し]さん(bin+cue).rar：04/01/26 22:05 ID:h7ouRFur
952 ：[名無し]さん(bin+cue).rar：04/01/26 22:06 ID:L7qyQpb8
>>950
次スレよろ。
次スレよろ。
>>944
> UNIX対応も考えるなら、内部は16bitで統一しちゃうのが簡単でよろし。
ふと思い立って、調べてみました。Win で mbstowcs() やると UTF-16BE になるのに、
FreeBSD 4.8 だとコード変換せずに wchar_t のサイズに調整されただけでした……
UNIX の時だけ libiconv を使って UTF-16BE に統一することにします。
( 微妙に実装が違うのか…組み合わせたこと無いから気づかなかったよ... )
>>945
> Wiki に、クラスタワード類似度評価法についてのページをアップさせていただきました。
おつかれさまです。とても参考になります。
> Wiki の方にも書いてありますが、クラスタワード類似度評価、およびあいまい検索のための
> ライブラリを提供する意思があります。共有ソフト開発者の方、ぜひご検討ください。
ではお願いさせてもらってよろしいでしょうか。
こちらとしてはものすごくありがたいです。よろしくお願いします。
こちらでは、Win/UNIXの細かい差異を吸収するソケットライブラリを作り始めました。
帯域制限もこのレベルに組み込もうと目論んでいます。需要があるならこの
ライブラリ単体での提供もしましょうか、などと発言してみる…
あ。書いてたら950レス超えた。次スレお願いしますねー。>>950
> UNIX対応も考えるなら、内部は16bitで統一しちゃうのが簡単でよろし。
ふと思い立って、調べてみました。Win で mbstowcs() やると UTF-16BE になるのに、
FreeBSD 4.8 だとコード変換せずに wchar_t のサイズに調整されただけでした……
UNIX の時だけ libiconv を使って UTF-16BE に統一することにします。
( 微妙に実装が違うのか…組み合わせたこと無いから気づかなかったよ... )
>>945
> Wiki に、クラスタワード類似度評価法についてのページをアップさせていただきました。
おつかれさまです。とても参考になります。
> Wiki の方にも書いてありますが、クラスタワード類似度評価、およびあいまい検索のための
> ライブラリを提供する意思があります。共有ソフト開発者の方、ぜひご検討ください。
ではお願いさせてもらってよろしいでしょうか。
こちらとしてはものすごくありがたいです。よろしくお願いします。
こちらでは、Win/UNIXの細かい差異を吸収するソケットライブラリを作り始めました。
帯域制限もこのレベルに組み込もうと目論んでいます。需要があるならこの
ライブラリ単体での提供もしましょうか、などと発言してみる…
あ。書いてたら950レス超えた。次スレお願いしますねー。>>950
ホスト規制でスレ立て出来ませんでした。
どなたかお願いします。
どなたかお願いします。
私もホスト規制で立てれなかった・・・。
>>953
> > Wiki の方にも書いてありますが、クラスタワード類似度評価、およびあいまい検索のための
> > ライブラリを提供する意思があります。共有ソフト開発者の方、ぜひご検討ください。
>ではお願いさせてもらってよろしいでしょうか。
ありがとうございます、では用意しておきますね。
日本語はSJIS前提で大丈夫でしょうか？ すでに日本語コードについては準備を進められている
ようなので、wchar を受け付ける形式の方がいいのかなと考えています。それなら EUC でもOKなので。
> こちらでは、Win/UNIXの細かい差異を吸収するソケットライブラリを作り始めました。
それは需要あるんではないでしょうか。
個人的にも欲しい・・・つっても、共有ソフト作るわけではないんですが(ぉ
>>953
> > Wiki の方にも書いてありますが、クラスタワード類似度評価、およびあいまい検索のための
> > ライブラリを提供する意思があります。共有ソフト開発者の方、ぜひご検討ください。
>ではお願いさせてもらってよろしいでしょうか。
ありがとうございます、では用意しておきますね。
日本語はSJIS前提で大丈夫でしょうか？ すでに日本語コードについては準備を進められている
ようなので、wchar を受け付ける形式の方がいいのかなと考えています。それなら EUC でもOKなので。
> こちらでは、Win/UNIXの細かい差異を吸収するソケットライブラリを作り始めました。
それは需要あるんではないでしょうか。
個人的にも欲しい・・・つっても、共有ソフト作るわけではないんですが(ぉ
956 ：[名無し]さん(bin+cue).rar：04/01/27 03:12 ID:FBhfy8x/
今の時点で、プロジェクトが具体的に動き出してるのって、
新月とShare!だけかな？
新月とShare!だけかな？
957 ：[名無し]さん(bin+cue).rar：04/01/27 06:31 ID:jUPg2UrT
このスレ出身26氏のCauserie Alphaが抜けてるってば
958 ：[名無し]さん(bin+cue).rar：04/01/27 07:30 ID:Ds22e765
>>957
alphaに低能な荒らし発生中w
alphaに低能な荒らし発生中w
959 ：[名無し]さん(bin+cue).rar：04/01/27 09:00 ID:WgIG/PVY
alphaって久しぶりにバージョンしてみたんだがラジオなんて機能がついてた。
26氏って興味が移り変わっていって迷走気味な印象を受ける。
このスレから誕生したくせに肝心のファイル共有機能を実装してないし。
荒らされるのもわかるよ。
26氏って興味が移り変わっていって迷走気味な印象を受ける。
このスレから誕生したくせに肝心のファイル共有機能を実装してないし。
荒らされるのもわかるよ。
960 ：[名無し]さん(bin+cue).rar：04/01/27 10:03 ID:5VMNzWAd
>>959
P2Pってファイル共有だけを指すんだねｗ
P2Pってファイル共有だけを指すんだねｗ
961 ：[名無し]さん(bin+cue).rar：04/01/27 10:22 ID:tgFaoTkV
962 ：[名無し]さん(bin+cue).rar：04/01/27 11:13 ID:NlHhGags
>>959
26氏って前スレで
> 26 名前：前スレ843[sage] 投稿日：03/12/06 21:05 UuWDxw0l
> 前スレの671が言っていたようなP2P掲示板を作りたくなったのだが、
> 需要ってあるか？
（後略）
と言ってたわけで、ファイル共有ソフトを作ると言って開発を始めたんじゃないしなあ。
26氏って前スレで
> 26 名前：前スレ843[sage] 投稿日：03/12/06 21:05 UuWDxw0l
> 前スレの671が言っていたようなP2P掲示板を作りたくなったのだが、
> 需要ってあるか？
（後略）
と言ってたわけで、ファイル共有ソフトを作ると言って開発を始めたんじゃないしなあ。
963 ：[名無し]さん(bin+cue).rar：04/01/27 11:52 ID:XQWyi14k
ｎｙやMXもあるし俺はむしろファイル共有付いてなくてもいいとも思ったりするし。
しかしやり方が閉鎖的過ぎるのがどうかと思うな。
掲示板に関しては雑誌厨も積極的に取り込んで行かないと成長が止まると思うんだが、
26氏はそうした理屈とは無関係の単純な嫌悪感で排除しようとしてる気がする。
しかしやり方が閉鎖的過ぎるのがどうかと思うな。
掲示板に関しては雑誌厨も積極的に取り込んで行かないと成長が止まると思うんだが、
26氏はそうした理屈とは無関係の単純な嫌悪感で排除しようとしてる気がする。
964 ：[名無し]さん(bin+cue).rar：04/01/27 14:15 ID:5VMNzWAd
965 ：[名無し]さん(bin+cue).rar：04/01/27 14:50 ID:o8zTKj1h
966 ：[名無し]さん(bin+cue).rar：04/01/27 16:20 ID:hbXH7SCW
最近接続が不安定だし、雑誌厨の投入はもう少し後がいいかな。
荒らし対策もあるしね。
荒らし対策もあるしね。
967 ：[名無し]さん(bin+cue).rar：04/01/27 20:46 ID:r49PflKx
968 ：[名無し]さん(bin+cue).rar：04/01/27 21:42 ID:z6TuwM1D
せっかくny2b6.6の逆アセソースが公開されてるんだから、winny互換にして欲しい。
ここで出た仕様をまとめたオープンソースny3を期待……
漏れがやれって？
漏れはsrc2の中身見てもサッパリだったので、あきらめますた。
ここで出た仕様をまとめたオープンソースny3を期待……
漏れがやれって？
漏れはsrc2の中身見てもサッパリだったので、あきらめますた。
969 ：[名無し]さん(bin+cue).rar：04/01/27 22:14 ID:rGHcs/uj
970 ：[名無し]さん(bin+cue).rar：04/01/27 22:18 ID:IDNOLEEm
971 ：[名無し]さん(bin+cue).rar：04/01/27 22:19 ID:yitEoRhl
今日の読売にちょっと出てたけど、
プロバイダに対するP2P通信の
隠蔽（？）の方法もよろ。。。
プロバイダに対するP2P通信の
隠蔽（？）の方法もよろ。。。
972 ：[名無し]さん(bin+cue).rar：04/01/27 22:26 ID:cpIieoSt
>>967
掲示板部分はα1から変わってないよ。
αで改善したのはラジオだけ
つーかシステム的には最初のバージョンからほとんど変わってない気がする。
根本を改良せずに、機能追加しまくったのがまずかったんだろなぁ
掲示板部分はα1から変わってないよ。
αで改善したのはラジオだけ
つーかシステム的には最初のバージョンからほとんど変わってない気がする。
根本を改良せずに、機能追加しまくったのがまずかったんだろなぁ
973 ：[名無し]さん(bin+cue).rar：04/01/27 23:19 ID:rGHcs/uj
>>970
ここで出た仕様を使うとなると難しいんじゃないか？
ここで出た仕様を使うとなると難しいんじゃないか？
974 ：[名無し]さん(bin+cue).rar：04/01/27 23:20 ID:z6TuwM1D
Winny2と接続ってのはできてもあまり意味がないような。
このスレで出てるような仕様を色々載せるとなると実用的な互換は難しくない？
そうじゃなくて、キャッシュを流用できればny1・2ユーザーを丸ごと取り込めるんじゃないかと。
(実際には丸ごとなんて無理だろうけど)
src2の中身があれば、
正確にはソースを整形してオープンソース用に見やすくすれば、可能だと思う。
このスレで出てるような仕様を色々載せるとなると実用的な互換は難しくない？
そうじゃなくて、キャッシュを流用できればny1・2ユーザーを丸ごと取り込めるんじゃないかと。
(実際には丸ごとなんて無理だろうけど)
src2の中身があれば、
正確にはソースを整形してオープンソース用に見やすくすれば、可能だと思う。
975 ：[名無し]さん(bin+cue).rar：04/01/27 23:26 ID:z6TuwM1D
あ、かぶってた。
……やっぱアレはクラッカーとコレクターにしか意味がないものなのかな。
47氏の遺志を継いで闘う、という錦の御旗になりそうなんだが。
(´-`).｡oO(実は、“winnyのソースから作られた「オープンソースP2P」”という触れ込みに惹かれてるだけかもしんない)
……やっぱアレはクラッカーとコレクターにしか意味がないものなのかな。
47氏の遺志を継いで闘う、という錦の御旗になりそうなんだが。
(´-`).｡oO(実は、“winnyのソースから作られた「オープンソースP2P」”という触れ込みに惹かれてるだけかもしんない)
Winnyと互換を取るということは最大の弱点であった｢作者がいないと何もできない｣を克服できないかと。
Winnyでオープンソースにという話は出ていて、47氏もできるならそうしたかったと言っていた。
だが現在出ているオープンソースでも可能なシステムは、どれも互換を取れそうな仕様ではないので、
ソースが出たところで参考にする以外には使い道がないのでは。
Winnyでオープンソースにという話は出ていて、47氏もできるならそうしたかったと言っていた。
だが現在出ているオープンソースでも可能なシステムは、どれも互換を取れそうな仕様ではないので、
ソースが出たところで参考にする以外には使い道がないのでは。