47氏発言集(手抜き版)
- 1 名前： 投稿日：02/04/01 05:35 ID:WTyTkgT/ main/1017590243.dat: 47
- 暇なんでfreenetみたいだけど２ｃｈネラー向きのファイル共有ソフトつーのを
作ってみるわ。もちろんWindowsネイティブな。少しまちなー。
- 2 名前：47 投稿日：02/04/01 23:14 ID:7XMU++Uj main/1017590243.html#56
- 暇つぶしにぬぼーと新しいファイル交換ソフトを設計中。
現状では、Freenetと似た転送方式だけどあれと同じだと重そうなんで
ファイル検索部はFreenetと同じだけど、データダウン部分はファイルを
持ってる一つ前のサーバー部で中継してもらう方式を予定。
一度親に落としてもらってから子に転送するのでProxyとしても働く。
netstatでソケットの接続見ても無関係の親と子が見えるだけ。
もちろん親でキャッシュファイルを吐いてるのか串動作なのかは子からはわからん。
回線が細い人は子を０にしてやり取りを親との一対一に固定。
子を０より大きくすれば大域制限無しで動作する。
あとファイル名もファイル内容も初めから全て暗号化して扱って、
キャッシュは単なる数字のファイルという形式になる予定。
んでMXと違ってキャッシュにプッシュという操作が必要
（プッシュの際には次で述べる暗号化のためのキーワードを追加する必要あり）
あとファイル検索の時は検索ワード以外に暗号用の複号化のキーワードも
必要にして、ファイル検索時はサーバー側でファイルIDを複号化して
それに対して単語検索するって設計にしようかと思うんだけどどーよ？
これだとあるファイルを探すのに検索ファイル名以外に
特定のキーワードしらないとファイル見つけられないけど、
これならサーバー状態でもキャッシュファイルが意味不明だし
お約束をわかってる人しか落とせないからいいと思うんだけど。
あとeDonkyみたいにファイル分割伝送にしようかとも思ったけど
メリットなさそうなんで現在保留中。
- 3 名前：47 投稿日：02/04/01 23:31 ID:RxKUzJrJ main/1017590243.html#60
- 試しバージョン作ってみるから少し待たれよ。
もしできたら完全フリーでここで公開予定。
- 4 名前：47 投稿日：02/04/02 04:02 ID:1arBVA6r main/1017590243.html#79
- ねむー。明日仕事だつーのに（ｗ
とりあえずWinSockでの最低限の通信部分は書いた。
あとMXと違ってユーザーIDという概念は無いと思われ>>71
チャットもできないし、だれが公開したファイルかはまったく
わからなくる予定っす。ファイル一覧は見えないし、
そもそも公開フォルダも中身は暗号化したキャッシュだから
自分のPC内の公開フォルダも何があるかは検索してみないとわからない。
んで、だれかがデータダウンするとその時点で経由したPCにも
キャッシュとしてそれが残るので初めにデータアップした人が
回線切ったとしても、問題なく他の人も落とせます。
その後、他からそのデータの要求があるたびに各所のキャッシュに
コピーが増えていくと思われ。この辺はFreenetと同じか。
問題は同じキー（名前）で中身が違う場合だけど
作成日時や大きさなんぞがダウン前にみれる予定。
ファイル名の一部検索も自由だしここがFreenetと違うところやね。
使い勝手はMXに近くなると思う。
- 5 名前：47 投稿日：02/04/02 04:31 ID:1arBVA6r main/1017590243.html#83
- >>82
現在想定している設計ではUL,DLは同じキャッシュホルダです。
謎ファイル名で中身も謎のファイルがたくさんあるだけとなります。
ここから、自分のキャッシュに検索かけて
暗号化を解いて通常のファイルに戻すことになります。
回線については、MXと似た親子の区別ができると思われます。
子供の数を０にすれば自分のPC経由の中継は行われないので
軽いはずですが親のPCではその大域が子の中継にまわされるので
遅くなります。しかし親なら人気のあるファイルは自動的に
キャッシュに溜まるので後からオフラインで探ることもできます。
そんなわけで親になるのならHDDと回線は太いものが必要でしょう。
メカニズム上Freenetよりは軽いはずですけど。
- 6 名前：47 投稿日：02/04/02 22:45 ID:h8yQMxAb main/1017590243.html#134
- 荒れてますねぇ。
とりあえず暗号化の部分は作り終わったので今はキャッシュ操作その他の
インターフェイス部分作ってます。面倒なんでMXもどき採用。
あと暗号化の部分は速度重視でアルゴリズムにRC4を採用しました。
MD5のルーチンも作ったのでハッシュに使うかもしれません。
- 7 名前：47 投稿日：02/04/03 06:10 ID:N7zNXVUU main/1017590243.html#139
- ボタンやリストなんぞのインターフェイス部分はだいたいできたよ。
あとオプションで指定したUPフォルダ内のファイル情報を元に
キー一覧を生成するところまではできた。
DOWNとUP以外にキャッシュフォルダって概念が別にあるけど
基本的にMXと同じ操作系かな。チャットがないからもっとシンプルかも。
ちなみにCount待ちなどの部分（リクエストのキュー部分）は
まだ設計自体が出来上がってないです。
ファイル転送部と中継部作ってそのあとだね。
とりあえず現状で完成度３割ってところで、次はメインとなるキーの検索部を作る予定。
基本的なファイルダウン部やレジューム部も作ってないからここもこれからだね。
簡単さからするとこっちが先かな。ここまでできればシステムの基本部分は７割完成かと。
- 8 名前：47 投稿日：02/04/03 06:10 ID:N7zNXVUU main/1017590243.html#140
- 公開方法だけど今は何も考えずにそこらへんの匿名Webサーバに
ひっそりと上げたろ思ってたんだけどこれだとまずい？
このシステムだと暗号化のための鍵情報（実体はRC4の鍵だけど
適当なキーワード入力に置き換わる予定）を各利用者で打ち合わせないと、
ファイルダウンどころかファイル名も見えないから
鍵情報だけをMXでやり取りなりすれば厨房は弾けると思う。
まだ完成してないから確実じゃないけど、鍵の数だけ別の名前空間があるようなもん。
鍵無し（鍵を無記入で使用）なら今のMXに串機能ついたシステムに近くなる。
似た例では鍵無しがWPNPで鍵有りが子鯖相当ってところか。
今度のはグローバルな親いないからあれとは別もんだけどね。
- 9 名前：47 投稿日：02/04/03 06:36 ID:zQ6cSqb+ main/1017590243.html#141
- で何度も書いてるけど、転送している人（もしかするとダウンしてる本人の
可能性も低確率であるけど外部からは判別不可能）のIPだけはどうしてもばれるけど、
その先にいる実際にファイルをリクエストした人のことはアップしている方からは
IPアドレス含めて何にもわからんです。共有リストって概念ないから
何持ってるかわかんないし、そもそもユーザーにIDが無い。
もちろんこのシステムは暗号化部分切れば、串経由でMX使ってるのと同じなわけで、
今作ってるシステム本体に中継ログ機能つけて各プロバイダで示し合わせて
データの流れを追えばだれから誰にデータが流れたかわかるかもしれんけど、
全部中身暗号化しちゃってる（もちろん検索単語などのリクエストも暗号化予定、
ファイル名は一番初めにキーに変換しちゃうので検索でヒットして初めて存在がわかるし、
実際に落として複号するまでネット上では中身がわからん）んで
私が自分で解析プログラム作って監視そても流れを追いきれんはずだなぁ。
著作権含むけどそれと知らない人が単にデータを中継しただけでも
つかまるってのなら逮捕可能かもしれないけど、それってルーター使ってたら
タイーホと同じなわけで、システム使ってるだけで無条件で逮捕可能にしないと、
捕まえられんだろう。
- 10 名前：47 投稿日：02/04/03 07:25 ID:zQ6cSqb+ main/1017590243.html#146
- 実はキーなどの情報の公開は２ｃｈに頼ってしまうのが一番良いのでは
ないかと思っとったりします（ｗ
チャット機能に2ch使うの推奨。
- 11 名前：47 投稿日：02/04/03 08:07 ID:+p+BRZqV main/1017590243.html#153
- 身元特定の可能性が上がることを考えてわざとトリップ付けないよん（ｗ
騙りたい人は面白いからどうぞ。もしかすると面倒なことになる可能性はある。
そういえば、トリップで使われているようなハッシュ関数を用いることで、
ダウンするまでアップ側にまったくそれが何なのか気がつかせないシステムにできます。
今回のシステムの肝もこの辺になると思われ。
一度ファイル名をハッシュに変換してそれでファイルをUPして、ファイルを探すときは、
キーワードをハッシュ関数で変換してそれと一致するものを探すという手法をとれば、
ファイルの名前を公には伏せたままでファイルを検索できます。
これはシステムログイン時のパスワードなんかに使われる手法と同じで
アルゴリズムとしてはDESやMD5なんかが代表的ですな。
ただしこれだと完全一致でないとファイルが探せない。
- 12 名前：47 投稿日：02/04/03 08:11 ID:+p+BRZqV main/1017590243.html#154
- 続き
もう一つの考えとして、秘密鍵暗号で暗号化して、
検索ワードの一部をに暗号鍵を混ぜるとする手も考えられるわけです。
秘密鍵暗号ならその鍵で元に戻せるわけで、検索ワードの半分で暗号を解いてから
それにMXの検索同様検索をかけるということができます。
これはMXで絶対見つからないような難しい名前付けるのと同じだったりもしますが、
システム側でこれを支援するわけですな。わかってる人には簡単に
目的のぶつを探し出せるわけです。MXでは難しい名前付けても
部分検索で探せてしまいますが、フィルタがかけられるわけです。
もちろん、暗号化はデータ本体の暗号化やクエリーをパケットダンプしても
解析不能にするためでもありますが、今回のシステムの肝はここでしょう。
たとえば、キーをmp3にしてファイル名を普通に付けると、mp3というキーワードで
検索かけた人しか、そのファイル探せないわけです。そのルールさえ
知ってればファイル検索はMXと同じです。
あと同じ考えで、公開鍵方式の暗号を使ってこれをやるとどうなるのか？
というのもあるのですけど、このファイルをUPしたのは俺だと証明できる
ファイル交換ソフトになってあまり面白くないんですなこれが。
- 13 名前：47 投稿日：02/04/03 08:22 ID:+p+BRZqV main/1017590243.html#155
- もちろん、必死に暗号アタックすれば、キャッシュや公のサーバーにおいてある
ファイルの名前や中身がわかる可能性はいつまでも残るわけですが、
この状態でやばい物を持っていて、尚且つ持ち主が暗号解読不可能な状態なら、
それを公開している人が著作権侵害に当たるのか？わいせつ物陳列になるのか？
→問題その１
もしくは、システム側で完全に匿名にできたとしたら、そのシステムを作った人に
責任を押し付ける可能性は？という問題が無くもないわけでし
- 14 名前：47 投稿日：02/04/04 06:01 ID:1Z/IrTWf main/1017590243.html#213
- ネタじゃなくてちゃんと作っているのでご心配なくです。
今は検索部分作ってますけど、複数のPCで動かさないと
チェックできないのでバグ取るのがめんどくさいです。
とりあえずキーの転送部分と接続制御部はできたっす。
- 15 名前：47 投稿日：02/04/04 06:04 ID:1Z/IrTWf main/1017590243.html#214
- あと名前ですけど、今作ってるプログラムでは暫定的にWinNXになってます（ｗ
- 16 名前：47 投稿日：02/04/04 06:15 ID:1Z/IrTWf main/1017590243.html#216
- 今WinNXで検索したらこんなものが（ｗ
WinNXやろうぜ
ttp://curry.2ch.net/musicj/kako/994/994315734.html
WINNXって何？
ttp://yasai.2ch.net/win/kako/991/991328988.html
- 17 名前：47 投稿日：02/04/04 13:28 ID:Tl3/3HsG main/1017590243.html#258
- 夜中に実装して昼間仕事だからここんとこぜんぜん寝てねー（ｗ
とりあえず隣のクライアントへのファイル検索機能まではできた。
次、一番面倒な分散通信部の実装やね。
まだ実装が完成してないんで最終的にどうなるかはわかんないけど、
今の予想設計だとファイルを落とし始まった時点での接続は
（おっと、検索時はノードをのんびりと渡り歩くんで別よ）
検索者 <-----> 中継ノード <------> ファイル提供者
か、
検索者 <---> 中継ノード１ <------> 中継ノード２ <------>ファイル提供者
のどちらかになると思われ。もちろんこう見えるだけで実は
検索者 <---------> 串のキャッシュを送ってるように見えるファイル提供者
こうなってる可能性も発生する
（これは実際にはそれほど発生しないはず。上流に来易い
高速回線経由のクライアント間ほどこれが発生するかなー）
どっちにしろ、だれが検索者でだれが最終的なファイル提供者か
ネットワークの一部分を見ているだけではわからない。
暗号化も入るしMXよりはかなり安全なはず。
（もちろん249氏が言うように鍵知ってたら暗号も
解析できちゃうんだけで完全じゃないけど
串動作と組み合わせれば解析が非常に困難になる）
そうそう、通信の暗号化とファイル名＆ファイルの暗号化は
別の暗号になるから、検索キーが公開されてても、
通信の中身はリバースエンジニアリングしないと解析できないよん。
基本的にプログラムのソースや通信プロトコルを公開する気はないし、
完全オリジナルのプロトコルで、通信全部を
暗号化（＆エラー検出を兼ねる）の予定だから、
怪しい接続は問答無用で弾けるはず。
基本はMX+Freenetだけど、暗号化や認証、データ圧縮補正系の
技術てんこ盛り＋串動作で解析不能にするわけやね。
もちろん手抜きしてるだけあってFreenetの匿名性には負けそうだし、
MXよりは不便でダウンが遅いだろうけど、目標は
MXの利便性・高速性とFreenetの匿名性を兼ね備えたシステムか。
もしどちらも実現できなかったら失敗ということで（ｗ
- 18 名前：47 投稿日：02/04/04 14:43 ID:hr5Nfj19 main/1017590243.html#263
- 開き直って職場から書き込み（ｗ
そろそろ４台以上PC無いと辛いんで職場でこっそりテストするかぁ？
あと、ファイルを断片化して分散保持するのはメリット（機密性・対障害性、匿名性）より
デメリット（データロスト率が高そうだし遅そう）の方が大きそうなので却下か。
代わりにファイルレジュームを超強力にしないと使い物にならんだろう。
MXは交換が基本なので相手に全部落とすまで待ってもらえるのが
普通だけどこのシステムだと何も考えずにぶちぶち切る人が多いと思われ。
キャッシュが利くので末端の人が回線切ってもある程度は
サポートできるけど限界がある。だから、頭から途中だけ
ではなく、中間部分の保持、また大きなファイルを扱うのなら
複数ノードからの同時ダウンに対応しないとまずいだろう。
初期設計だと、ノードの上流はひとつであとは下流に
しようと思っていたけど、そんなことで既に
親複数（上流下流をあまり気にしない）に変えた。
これで面倒になるのは分散検索部だな。ここが作れれば完成できるだろうし、
だめならだめだと思われ。最悪Freenetのパクリでどうにかなるだろうが、
もっといい手法を編み出したいところだ。
- 19 名前：47 投稿日：02/04/04 14:44 ID:hr5Nfj19 main/1017590243.html#264
- あげちったい(T_T)
- 20 名前：47 投稿日：02/04/04 15:21 ID:3KXbAU7b main/1017590243.html#271
- 何かもうメンドクサイ
- 21 名前：47 投稿日：02/04/04 17:00 ID:c7MlcUUU main/1017590243.html#287
- ・・・ごめん。
もうこれしか言えない。 もう来ないけどいいよね・・？
さようなら
- 22 名前：47 投稿日：02/04/04 20:06 ID:stKzX4UZ main/1017590243.html#310
- 本物と思われる人です（ｗ。ついに偽者が出るようでうれしい。
間違ったことややばいこと書いたら偽者のせいにするのでよろしくね〜ん。
さて、今悩んでるのは検索時のネットワークルーティングでしょうか。
Freenetと同じでもいいんですが、遅そうなんで独自の方式を考え出しました。
具体的内容は秘密ですが、それなりに高速で、今回の転送方式との相性が良いはず。
もちろんどの程度のパフォーマンスが出せるかは実際に動かしてみないとわかりませし。
検証用のトラフィックシミュレーターでも作ってモデル検証してみようかとも思いましたが、
とりあえず実際に作ってしまった方が早そうなんで今夜にでも作ってしまいましょう。
予想では、mp3のような小さいファイルがたくさんとか、遅い回線使用者ばかり
ですとパフォーマンスが悪いですが、比較的大きなファイルが主流で
高速回線使用率が高いとMX並みの速度が出せるはずです。
匿名性最重視で小さいファイルメインならFreenetでいいわけですので、
今回のではMXの後継位置を目指して、それ向きな方式を選択していきましょう。
なお、Freenetの技術的なことはこの辺りが参考になりました
ttp://www.sfc.wide.ad.jp/~egichan/mlecture/netsec2000f/kadai3.html
あと要望に応じてソース一部提出（ｗ
ちゃんと作ってますよん。
/*
* Start MD5 accumulation. Set bit count to 0 and buffer to mysterious
* initialization constants.
*/
void MD5Init(MD5Context *ctx)
{
ctx->buf[0] = 0x67452301;
ctx->buf[1] = 0xefcdab89;
ctx->buf[2] = 0x98badcfe;
ctx->buf[3] = 0x10325476;
ctx->bits[0] = 0;
ctx->bits[1] = 0;
}
↑ちなみにここは他所からパクったソースだ
- 23 名前：47 投稿日：02/04/04 20:24 ID:stKzX4UZ main/1017590243.html#315
- >>313
テスト版完成が今月中ごろで最終チェックに１、２週間かけると思われ。
公開は一月ほど待たれよ。まだ開発初めて４日目で開発率30%ほど。
- 24 名前：47 投稿日：02/04/04 20:28 ID:stKzX4UZ main/1017590243.html#317
- ちなみに俺ぁネットワーク系メインのプログラムじゃないんで
この程度のプログラム作れる人ならそこら辺にごろごろしてるはずだな。
- 25 名前：47 投稿日：02/04/05 10:04 ID:5rcxH4lw main/1017590243.html#364
- 気がついたらキーボード抱えて爆睡しとりました（ｗ
今日は職場でのんびり作業しますわ。本職の方暇だし。
ちなみにプログラミング暦なら20年>>350
- 26 名前：47 投稿日：02/04/05 14:46 ID:yZ65YIiO main/1017590243.html#377
- ん〜、じゃWinnyにしますか？初めはWinNYだったけどMXの後継とは無関係に
Windows Next eXchange programって説明できていいかと思ったんで
WinNXに変えたんだったり。
全部小文字にしてI love NYな人っぽい意味合いで語呂がいいからってことでもいいかも。
あと47絡みの名前は却下っす。使うなら作者名に使いますわ。
ちなみに今作ってるプログラムInfo情報は以下の通りになっとります。
WinNX Version 1.0a1(Build ????)
Copyright 47@download.2ch
- 27 名前：47 投稿日：02/04/05 17:06 ID:yZ65YIiO main/1017590243.html#397
- 本職の方で雑用多い・・・
とりあえずWinnyが人気あるみたいなのでこれにしときませう。
もっといいのが出てきたら採用ってことで。
>>395
exeの横にini形式で作ってますよん。ご安心を。
あとプラグインはやんないと思う。
セキュリティの大穴になるし、同様、
WinSockDLL技もつぶしとくつもりです。
もちろんこれでも解析は可能ですけどね。
- 28 名前：47さんに期待sage 投稿日：02/04/05 17:29 ID:rCAdPD2S main/1017590243.html#398
- Winny （・∀・）ｲｲ!!
- 29 名前：47 投稿日：02/04/05 22:47 ID:bBRp+Hyf main/1017590243.html#432
- 実装まだだけど詳細設計はできてるので426の疑問に対する予想を書くと、
１．回線が早いと問答無用で親に繰り上がっていって常にUP状態となります。
だからといって設定を工夫して親になりにくくすると今度は自分のダウン速度が
上がりません。
２．各ホストのネットワーク構成（親子方向）は転送履歴とその速度を見て動的に変化していきます。
網の目のように各ホストはつながりますが、データの流れ的にはツリー構造に近くなって行きます。
３．回線が早いと自動的に神状態（大量のダウン要求がくるけど勝手に持ってけ状態）に
なっていきますが、ダウン速度はHDDが大量にあればそれほど下がらないはず
（キャッシュが効くから）
よって、回線が早く上流の位置にあたるホストは、無条件でキャッシュに
人気のあるお約束ファイルが溜まっていきます。
高速回線でHDDに余裕がある方は、暇なときに回線に繋ぎっぱなしにしておいて、
暇なときに自分のキャッシュに検索かけるとさくさくファイルが見つかる可能性が
高いです。
４．回線が早いのにHDDが無い（キャッシュを小さく設定）でもかまいませんが、
昔一度読んだデータでもまた他からダウンしにいくので、ダウン速度が下がります。
よって基本は、太い回線者ほどキャッシュフォルダを大きくとったほうがいいです。
５．回線が細い人はDOWN専用になってまず転送に加担しませんが、
貴重なファイルを持っていると高確率で吸い出されて行きます。
ここの部分はまだ設計が完全ではないですが、貴重なファイルを
持っているほど検索速度やダウン効率が高くなるようになると思います。
６．DOMには何も制限ありません。回線の早いところから好きなだけ
吸い出し放題です。 しかし、人気の無いファイルは落とすのに苦労しますし、
接続相手とのパイプが細い可能性が高く時間かかります。
基本は、回線太い人がよく見かけて大きいファイルを分配させる人に。
回線細い人はあまり見かけないけどリクエスト受けやすいファイルを提供する人。
に役割分担されると思います。
- 30 名前：47 投稿日：02/04/05 22:58 ID:bBRp+Hyf main/1017590243.html#436
- >>424
簡単に解説すると、ファイル検索も転送同様のメカニズムでキャッシュされるわけです。
お約束ファイル情報はそのファイルと共に上流のホストに溜まって行きます。
ファイル転送時にそれがキャッシュとして残るので、それ以上クエリを転送する必要ありません。
だからネット全体に検索しに行く必要がなく、お約束ファイル検索は高速な上流のホストから
すぐに結果が返ってきます。マイナーなファイルは回線細い人の所まで
クエリーがいくので見つかるのに時間がかかります。
今回の検索部＆転送部の肝は、ネットワーク構造なのに、
回線速度に応じて仮想的な木構造ができていくことにあります。
光使用者が上流にきて自動的に神状態になるようにするわけです。
- 31 名前：47 投稿日：02/04/05 23:05 ID:bBRp+Hyf main/1017590243.html#438
- ある程度できたら本体はこのシステムで提供するから
捕まったら自業自得（ｗ
- 32 名前：47 投稿日：02/04/05 23:08 ID:bBRp+Hyf main/1017590243.html#441
- >>439
気がついていると思いますが一応書いておくと、
自分のキャッシュ内にあっても検索をヒットさせないと
それがなんだかわかりません（ｗ
- 33 名前：47 投稿日：02/04/05 23:34 ID:77Xrl5cl main/1017590243.html#447
- そうだ、もし協力したいということでしたらこのシステムで考えられる
嫌がらせ手法を書いていただけると助かります。
すぐに思いつくのは、以下
C1. ゴミファイルを大量にUPフォルダに置く
C2. 子の間で転送が始まったら嫌がらせで切断する
C3. 人気のありそうなファイルを他から落として一部書き換えて同じ名前で置く
C4. 高率でヒットされそうな名前だけど大きくて中身がゴミなファイルを置く
C5. DOMに徹する
この程度なら弾ける予定です。理由
A1. ヒットされないファイルばかり置いておくと
優先度が下がっていくので無視されやすくなる
A2. A1と同じ理由で無視されて行きます。高速な回線ほど切断を抑えて
常時接続するほどその高速回線が生かされます。
A3. 名前とサイズが同じでも内容が違うと別ファイルとして扱われます。
ファイル全体に一度MD5アルゴリズムでハッシュかけて内容を区別する予定です。
レジュームもこれを元にかけます。もし同じ内容のファイルがたくさんある場合、
ダウン回数の多い信頼性の高いファイルが検索の上位にくるはずです。
A4. A3と同じ理由で防御できます。ただし、これはゴミ情報だというのを
どこぞで公開していただかないとおいしい名前で同じゴミをつかまされる人が
続出するでしょう。このファイルは落としてはいけない
スレが重要になるはずです。
A5. 回線とHDDが強ければDOMは簡単で何でも落とし放題
（それどころか人気のあるファイルは勝手にDOMってくれる）ですが、
細い回線の場合、ヒットされやすく、尚且つ貴重なファイルを持っていないと
DOWNが困難になります。UP速度とDOWN速度は同じ程度に調整される予定です。
- 34 名前：47 投稿日：02/04/05 23:40 ID:77Xrl5cl main/1017590243.html#449
- >>446
その問いに答えると、回線が太いDOMは落としている間は
貴重な転送さーばーとして働いてくれるんでいても無駄にならないはず。
特にいいものをDOMってくれてるととても助かる。
回線が細いDOMは頑張って貴重なファイルを提供してくれるに違いない。
・・・・といいなぁ（ｗ
- 35 名前：47 投稿日：02/04/05 23:41 ID:77Xrl5cl main/1017590243.html#450
- > 回線が細いDOMは頑張って貴重なファイルを提供してくれるに違いない。
こりゃDOMじゃないね。修正。
回線が細いDOMは何も落とせない（ｗ
- 36 名前：47 投稿日：02/04/05 23:42 ID:77Xrl5cl main/1017590243.html#451
- >>448
ぶっ壊れたファイルはハッシュのメカニズムで検出できるんで弾けるはず。
ウイルスはこっちで気をつけますよ。
- 37 名前：47 投稿日：02/04/05 23:49 ID:77Xrl5cl main/1017590243.html#454
- >>445
//たぶん個別ノード内で仮想木構造があってｴｰﾄｴｰﾄ…
大体あってます。有効グラフによるネットワーク構造でノード間は
親子構造を持ちますが、転送速度に応じてグラフの方向が反転＆
再接続がかかるので、ネットワーク内に生じた仮想的な木構造の
上位に高速でやり取り可能なノードが集まってきて、下に順に
ぶら下がって行きます。遅いと末端で1対１の交換only状態になります。
- 38 名前：47 投稿日：02/04/05 23:52 ID:77Xrl5cl main/1017590243.html#457
- 律儀に答えてみるテスト
>>452
だからここでやってたり（ｗ
>>453
そうですが、小さくても貴重なファイルを提供していただければ
十分DOMれます。回線が遅ければUPも遅いんでもっていかれる
だけということにはならないはず。
この辺の状況は今のMXとかわんないではないかと。
- 39 名前：47 投稿日：02/04/05 23:54 ID:77Xrl5cl main/1017590243.html#458
- >>455
ただ、ファイル交換するだけだから絶対その内容は実行されないですよん。
もちろん、交換したファイルにウイルスがあるかどうかなんてしったこっちゃないですが、
上に書いた理由により、皆さんの連携で弾けるはず。
> って事は誰が誰と交換してるとかは47氏からは筒抜けって事ですか？
無理っす(^^;動き出したら私にも止められないです。
- 40 名前：47 投稿日：02/04/06 00:06 ID:+KInPcrb main/1017590243.html#462
- >>460
ネットワーク全体を見張る何らかのメカニズムができない限り無理ですよ。
一度作ってしまったら昔のバージョンも残るでしょうから
後から頼まれても状況をスパイするソフトは私にも作成困難になります。
もちろん、初めからそれ目的で作っていれば筒抜けになる可能性が
ありますが、常に特定のところにデータが行くようになってたら
いずれ誰かが気がつくでしょう。もちろん警察がそんな面倒なことするわけないし。
あと私のPC見てもソースあるだけで怪しいデータやり取りしてるのは
他の人の責任だし、後の可能性を考えると開発も匿名の方がいいだろうって判断で
最後まで名前隠します。ウイルスみたいなもんですね。
まぁ、開発理由は単なる暇つぶしです（ｗ。正確に言えば、Freenetを面白いと思ったのと、
まだ使い物にならんなーどうにかならんかなと思ったのがその理由ですね。
- 41 名前：47 投稿日：02/04/06 01:07 ID:M5Lc7MaX main/1017590243.html#471
- >>464
ご意見どうもです
> 複数起動して自分のファイルを自分で検索＆ダウソして優先度を押し上げるとか…
あーなるほど、それありそうですね。できるだけ禁止するようにしときますが、
複数のマシン使って回線詐称されると痛いかもしれず。
実際にデータ量測ってても、これならごまかすことはできますし。
ただこの辺は単に接続相手の選択にかかわることなんで、高速回線の人とは繋がりたくない
って場合にのみ意味のある技かな。複数起動したら結果的に低速扱いになるんで
それで転送を頼まれる率は下がりますが、接続相手も低速回線の人が増えて行きます。
この辺は基本的に同じ程度の速度の人同士で繋がるようにする工夫なだけですし、
回線が細くてこれやったらDOM可能でも時間がかかりすぎて途中で切られるでしょう。
> 一時的にログを取得中
とりあえず平気でしょう。開発途中のソフトの話しただけで捕まるはずないし、公開しても
作者の逮捕は無理かと。ファイル交換ソフト作成で逮捕された例なんてないはずだし、
公開後に個人情報を特定されるだけなら痛くも痒くもないなー。
逆に売名行為になっていいかも（ｗ
- 42 名前：47 投稿日：02/04/06 01:11 ID:M5Lc7MaX main/1017590243.html#474
- >>470
当分はフリーのWebサイト使うと思われ
- 43 名前：47 投稿日：02/04/06 01:17 ID:M5Lc7MaX main/1017590243.html#476
- ソフト公開で逮捕というとFLMASKの例があるから絶対無いともいえんけど、
その前にトンズラできると思うなぁ。
初めは目立たないWEB上でひっそりやって目立ってきたら
自分で作ったワールド内に逃げればいいと思われ。
広まるほどの完成度に達すれば逃げられるし、
達しなければ捕まることも無いという二重の安全策（ｗ
あとMXでの公開の方が絶対危険だよね。
あれ珍しいファイルだと提供者のIPが一発でばれるし。
- 44 名前：47 投稿日：02/04/06 14:39 ID:AKIOBPTK main/1017590243.html#538
- あー、今日は休みなんですげーよく寝た（ｗ
とりあえず昨日の夜はファイル本体の転送部作ってました。
ファイルのヘッダを転送する部分は既にできてるので検索かけると
他のノードのファイルがだーと出てくるところまでは動いてましたが、
そのファイルをダブルクリックするとMXのようにファイル本体の
転送が始まるようにしてるわけです。
んでここの転送部も昨日（今朝）組み終わりましたが
まだちゃんと動作しないんでデバッグ中です。
二つのマシン上のデバッガで通信内容を追跡中。
あと、レジューム機能はもちろん付けますんで、
それように準備はしてありますが、実装はまだです。
普通にファイル転送できないと意味ないし
この辺は今日のんびりやりましょう。
とりあえずバグ取れてファイル転送部ができれば、完成度５０％ってところです。
あと残った作業は次の通り。
・検索部の接続形体がまだ静的なんで状況に応じて親子関係や接続を切り替わるように
・今だとファイルの持ち主と受け取り主が直接ファイルのやり取りしてるんでプロクシ機能の実装
・まだ暗号化を組み込んでないんでファイルと通信それぞれに暗号化（関連ルーチンは既にできてる）
・インターフェイスなどの細かいチューニング
・例外処理のチューニング（これが使い物になるかどうかに関して最重要）
- 45 名前：47 投稿日：02/04/06 14:58 ID:AKIOBPTK main/1017590243.html#559
- 個別に答えとく
>>477
できます。ないと使い物にならんので強力にします。
あと、キャッシュ内のファイルには元のファイルの大きさなど
含まれるので、尻切れかどうかわかります。というか、尻切れだとzipのように
Downloadフォルダに持っていけません。
>>479
容量制限についてはまだ考えてません。基本的には変な制限かけないで
ユーザーさん任せが良いのかと思ってます。
>>485
ファイルが壊れているのは検出しますけど、冗長な情報を入れて修復させることは
しないと思います。TCPしか使わないんで転送時のエラーはほぼ起きないはずですし、
それは他のソフトでやればいいかと。ただ、転送にはRC4で暗号かけるんで、
途中、１バイトでも化けると以降のすべての通信内容が壊れます。
もしできてからどうしても問題があるようでしたら、エラー検出だけでなく、
エラー補正も入れるようにしますよ。
>>498
どうもですー。とりあえず組み込んどきましたが暫定ですんで他の方もよろしく〜。
>>502
今のところ管理方式の都合でファイルの大きさは2G制限になってます。
これじゃまずいんでファイル周りは64ビットに後でしますが、
この辺はエラー処理が面倒かも。まぁ対応はするけど制限はしないと思う。
あと配布はWebでやってここでURL張るだけを予定してるんだけど何かまずい？
警察がプロバイダと組めば追跡できなくもないけど、広まる前の時点では
そこまでできないはずだしIP取られる危険は当初は当局より他個人だと思うんで
一番安全なのはwebかftpだと思うんだけど。もちろんfreenetなら確実だけで、
初めのころは広めるのが目的になるんでだめでしょ。前にも書いたけどMXは論外。
>>521
最初のホストは他の多くのファイル共有ソフトと同じです。一つでもホストが
みつかればいいんで、動いてそうなホスト一覧ファイルを起動時に読み込んで
接続かけます。ここのところは既にできてます。
>>529
自己満足だけど日本人が作ったソフトは少ないから意味はあると思うよ。
技術的に新しいかどうかは今回考えてないし、Freenet使いにくいって理由で作ってるんで。
- 46 名前：47 投稿日：02/04/06 15:19 ID:AKIOBPTK main/1017590243.html#564
- そうだ、今ファイル転送部やってるわけですけど、ファイルのハッシュ情報や
大きさはキャッシュ内でヘッダとして付け加わるんで、ダウン中のファイルでも
それが最後までダウンし終わる前に他にUP可能になる予定です。
分割しないeDonkyみたいな感じ。
つーか、串での転送は、実態は同じファイルをDOWNしながらUPすることになります。
これができるんで大きなファイルのやり取りもそれほど困らんはずです。
- 47 名前：47 投稿日：02/04/06 18:13 ID:tI2XpLS7 main/1017590243.html#586
- ある程度中身を理解してる人もいるようで。
確かにFreenetを超えるところは無いはずですし、
いろんなものの寄せ集めで新規な所は何も無いです。
ただ、だからこそすぐに作れるわけだし
匿名性を重視するのならFreenetを使えばいいだけだし、
交換効率重視ならMXを使い続ければいいだけ。
今回のシステムのことは見なかったことにすればいい。
だからといってFreenetやMXが完全ってわけでもないわけで、
自分としては、もっとMXに近いけどFreenetの要素を含む
新システムが欲しいから自分で作るってだけの話です。
> Freenet を C で再実装するとかいうなら理解出来るけど。
もともとはFreenetクライアントがJavaで組まれてるのにぶち切れたのが
作りはじめた大きな理由なんで、その通りではありますが、
そもそもFreenetのアーキテクチャは匿名性ばかり重視して
しまっていて無駄が多いと思うんでFreenetプロトコルには準じない
（Freenetクライアントにはしない）で全部自分でやるって方針です。
- 48 名前：47 投稿日：02/04/06 18:17 ID:tI2XpLS7 main/1017590243.html#588
- >>578
チャンクに分割するのは普通の人が考える以上にアクセス負荷が高くなります。
メモリでもなんでも今のハードはリニアアクセス時に最高性能出るように作られているので、
分割しないでも要求が実現できるのならやるべきではないと思いますね。
今回のシステムでは速度出るように工夫します。
といっても、OSのファイル機構が優秀なんだからできるだけそちらに頼るという
方針を採るだけのことですが。
- 49 名前：47 投稿日：02/04/07 01:20 ID:Se8QlMbF main/1017590243.html#633
- やっとファイル転送部できました。
予想外に苦労したんでレジューム機能がまだです。
通信使ったプログラムではお約束の話ですが、転送率を限界まであげたり極端に
低速な回線にしたりすると妙なところでこけたりタイミング狂うんでチェックが面倒。
とりあえずLAN上でならエクスプローラーでのネットワークファイルコピーと同じ速度出てるから
性能的には十分でしょう。この程度に耐えられないと光回線レベルでは耐えられんし、
性能重視でわざわざVC++でWinSock直叩きやってるんだからこの程度は出てくれないと。
さーて、基本的な部分はできつつありますけど細かい部分はこれからなんで
のんびり作りませう。特に通信周りはエラー処理がめんどうで、あわてて作って
バグ入ると取るの大変つーのを痛感（ｗ
- 50 名前：47 投稿日：02/04/07 15:10 ID:PTiKNkGt main/1017590243.html#669
- 現在、システムの主幹部分となる通信中継部や検索部分をチューニング中。
ホスト間の通信部は既に完成（のはず）なんで、あとは比較的楽で
プロトコルのコマンド増やして動作を複雑にしていってるわけですが、
まれに怪しい動作するんでそのたびに何が起きてるのか
デバッガで追跡して悩んでるという状況です。
あとマルチランゲージ関連ですけど、基本的に日本語onlyで
英語版やリソース切り替えで対応はやらん予定です。
もし海外のリソースが欲しければ他に好きなだけ選択肢あるし、
日本人が欲しがる海外のリソースは、それと判断できる人が
他のシステムで拾ってきて日本語のファイルにして
こっちにUPしなおしたほうがいいだろうという判断です。
MXでも日本語以外のファイルあまりやり取りしなかったし
何が面倒ってドキュメント書きだったりするんで単なる手抜き（ｗ
システムが安定して暇になったらやるかもしれないけど。
あとファイルのサイズは悩んだ結果４Gまでの制限となりました。
このシステムの場合、細かいファイルも超巨大なファイルも
自分でアーカイバで扱いやすい大きさに調節すること推奨です。
分割や圧縮などはシステム側ではまったく考えませんがこれは
ユーザー任せのほうが現実的だろうという判断です。
シンプルにできるところはシンプルにした方が
応用が利く使いやすいシステムになるはずですので。
- 51 名前：47 投稿日：02/04/07 17:53 ID:LnbtaLmN main/1017590243.html#677
- ・・・。
- 52 名前：47 投稿日：02/04/08 03:44 ID:N2vA41p7 main/1017590243.html#745
- うーん、日曜を完全につぶしたにも関わらず開発進展が遅いなぁ。
とりあえずレジュームや暗号部やるには、今までかなりえーかげんな作りになってた
ファイル管理やタスク管理周りをきちんと作りこむ必要があるなーってことで、
今日は地道にこの辺やってました。
・ UP、キャッシュ、DOWNフォルダ内のファイルを管理し必要に応じて相互変換するファイルマネージャ
・ 検索やファイルの管理にハッシュ機能の追加（ダブったキーを検出して排除しないとだめなんで）
・ 大きいファイルや大量の転送に耐えられるように、各動作を平行して走らせるためのタスクマネージャ
こんなんですな。とりあえずこの辺も全部できたんで、レジュームや暗号変換部は簡単に作れるはず。
これで基本的なところは全てできたんで、
１． 検索かけると周辺ノードでヒットしたファイルが出てくる
２． 検索結果からファイル選んでダブルクリックすると、だーと転送が始まってキャッシュに落ちてくる。
３． キャッシュファイルをダブルクリックするとキャッシュが変換されてDownフォルダにファイルが落ちる。
４． UPフォルダ内のファイルをダブルクリックするとキャッシュ内にコンバート
（これは予備動作で別にキャッシュ内になくてもUPフォルダから直接UP可能）。
５． UPフォルダやキャッシュフォルダの内のファイルは検索＆ダウンの対象として処理される
と、まだ隣としかファイルの交換ができないのを除けばファイル転送ソフトとしての
基本的な部分は全てできました。これで半分は完成でしょうか。
後は分散システムの管理部分と、暗号やプロクシ動作などのセキュリティ絡みの部分、
細かいUI＆性能チューニングですね。
- 53 名前：47 投稿日：02/04/08 03:57 ID:N2vA41p7 main/1017590243.html#748
- 今のところインターフェイス周りは必要最低限しかないです。
この辺は最後残り３割の内の実装内容になるでしょう。
- 54 名前：47 投稿日：02/04/08 03:58 ID:N2vA41p7 main/1017590243.html#749
- まだタスクトレイに常駐できないし右メニューも無いし（ｗ
- 55 名前：47 投稿日：02/04/08 13:24 ID:AQBrbH8T main/1017590243.html#769
- >>767
確かに接続情報が保存できれば便利かもしれません。
つーか、今現在ご想像どおりIPとPORT番号書いたファイルを
読ませて接続テストさせてるわけですが、いちいちテキスト修正するのが
うっとーしーんで直ぐにでも付けたほうが良いのかも。
あととりあえずファイル内容とファイル名を暗号化するところまでは
できました。今現在は接続が増えてネットワーク接続状況によって
ファイル転送が失敗することがあるんでこの辺をバグ取り中。
- 56 名前：47 投稿日：02/04/08 14:20 ID:wvtsuKfX main/1017590243.html#772
- >>704
ツリーの中での位置表示ですか？正直、このへんはまだ詳細設計がまだの
段階なんで付くかどうかわかりません。各ノードは周辺しか把握してない
（どっちが高速でどっちが低速かだけは把握してるから
場違いのクライアントがいたらそっちに再接続を誘導する）
から位置表示は無理じゃないのかなと思います。
あと、これやってしまうと匿名性で問題がでそうな気します。
もちろん周辺との接続状況は出すと思いますし、
今でも接続されてる隣のIPがそのまま表示されてます(^^;
ここはMXのようにID導入して隣のホストのIDだけは出すように
しようかなと思ってます。この辺はまだ詳細設計煮詰まってませんね。
- 57 名前：47 投稿日：02/04/08 18:01 ID:5AFK6yag main/1017590243.html#780
- ttp://www7.big.or.jp/~mb2/bbs/up/img-box/img20020408154457.zip
- 58 名前：47 投稿日：02/04/09 14:02 ID:JTt8ccYK main/1017590243.html#828
- >>826
うん、これに関してはここの板が一番理解があるでしょうから900行ったら、
ここでその２スレ作ればいいと思います。本来MXの次に関して語るスレ
なのに占領してしまっていて申し訳ありませんけど。
別にIPとられてもかまわんし、２ｃｈと言えども警察にはIP出すでしょうから
どこでやっても同じでしょうし。
あと、あらしは困るといえば困りますが見てる人がいる証拠ということで
２ｃｈでは必要悪ということで、不必要に上げないという今の方針でいいと思います。
- 59 名前：47 投稿日：02/04/09 14:08 ID:JTt8ccYK main/1017590243.html#829
- ちなみに今は複数PCでのやり取り部分をちまちま作ってます。
本職の方が少し忙しくなってきたんでこれで遊んでばかりという
わけにも行かないけど、基本的な部分はもうできたから
やることないときの暇つぶしにちょうど良いんではないかと。
今月完成を目指してのんびりやりますわ。
- 60 名前：47 投稿日：02/04/10 07:47 ID:TRw4MUOl main/1017590243.html#874
- すんげー地道に動作チェック＆バグ取りしてます。
全機能できたわけじゃないですけど、ファイル交換ソフトとして
必要最低限の機能できたんで、動作を確実にしてます。
前はよく固まってましたが、どうにか安定してきました。
今のバージョンなら大量に転送かけても比較的さくさくファイル交換してますね。
- 61 名前：47 投稿日：02/04/10 07:48 ID:TRw4MUOl main/1017590243.html#875
- 完成度は６割ってとこなんで、現状でどういうことになってるのか詳細をば。
まず今のバージョンでの基本モードは次の６つ。
「ホスト」「公開ファイル」「ファイル検索」「タスク状況」「設定」「ログ情報」
ホストは他のホスト情報で接続状況などが表示されます。現状では接続されている
ＩＰとポート番号が直接表示されていますけど、後でＩＤ表示にするのではないかと。
「公開ファイル」はＵＰフォルダの指定で、最近複数指定可能です。
ここでＭＸと違うのは、フォルダ毎に「キャッシュ変換用暗号キー」
というのがテキストエディットコントロールで指示できること。
「ファイル検索」では、ＭＸ同様の検索キーワード以外に検索用の
暗号化ワードを指示します。暗号化ワードは、提供側と検索側で
完全一致させないとファイル名が崩れてファイル検索自体できません。
一応暗号化ワードの省略も可能です。
- 62 名前：47 投稿日：02/04/10 07:49 ID:TRw4MUOl main/1017590243.html#876
- 「タスク状況」はファイル転送やＵＰなどの各種タスク状況をまとめて
表示するもので、まだＭＸのようなバー表示にはなってないです。
現状ではそれぞれのタスクの進行状況に応じて数が上がっていくだけです。
ファイル検索からファイル選択してダブルクリックすると、
ダウンロード初めてここの画面に自動的に切り替わったりなど、
基本動作はＭＸと似てます。なお、まだキューの概念が無く、
要求は無条件で全部受けてしまいます。
「設定」は各種設定で、今だとキャッシュホルダ、ダウンホルダ、
待ち受けるポート番号と回線速度の設定があります。
ここはもちろんもっと増えます。そういえば各種のタイムアウト処理が
ついたからこれ用の設定もいりますねぇ。「ログ情報」はエラー表示などの
表示とバージョン情報などでバグ取りようのコンソールも兼ねてます。
こんなところでメニューも無くシンプルです。
上部に二列のボタンが並んでいて上がモード切り替えで
下列のボタンが各メニューのサブ動作（切断など）で、
下半分は多くのモードでリストコントロールってやつです。
エクスプローラで使われてるタブつきのやつですね。ＭＸと同じです。
- 63 名前：47 投稿日：02/04/10 07:54 ID:DeIc0iOn main/1017590243.html#877
- これだけだと動作が簡略化されたＭＸにすぎないので、違いの部分を説明。
まずＭＸと違うのがキャッシュフォルダという概念と暗号化の概念があること。
アップフォルダ、ダウンフォルダ、キャッシュフォルダがありこの間をファイルが行き来します。
既に書いたようにアップフォルダ毎に暗号化のキーワードを指定できます。
まず一番初めにファイルを公開するユーザさんは、アップフォルダに
公開したいファイルを置きます。暗号キーはこのときに指示します。
この状態で外部からファイル検索要求が来ると、必要に応じてファイル名に暗号化かけて
検索元に送ります。もし向こうが暗号のキーを知っていればファイル名を元に戻せます。
そしてこれの本体に対してダウン要求がかかると次の動作が起きます。
１．ＵＰ要求を受けた方では、ＵＰフォルダ内のファイルに暗号化を施してキャッシュ
ファイル作成動作が行われます。もし既に作成済みならこの動作は省略されます。
キャッシュフォルダ内のファイルは名前も内容も暗号化されて意味不明です。
２．できたキャッシュファイルが要求側のキャッシュフォルダに転送されます。
ここで、１の動作は子の動作は平行して進行するので、ファイル要求側から見ると、
キャッシュを送っているのかＵＰフォルダ内のファイルをコンバートしながら
送っているのかは見分けが付きません。また、同一ファイルに対して
他のサーバーからのダウン動作と同時にＵＰ動作が可能なので、
結果的に３ホストにまたがる転送動作となる場合もあります
（実際にはこうなることが多く、これで串動作にもなる）
- 64 名前：47 投稿日：02/04/10 07:54 ID:DeIc0iOn main/1017590243.html#878
- 最後
３．要求側のキャッシュフォルダ内にキャッシュ転送が終わると
自動的にキャッシュファイルの暗号を解いてＤＯＷＮフォルダに展開します。
検索側は暗号のキー知っているはずなので問題なく展開できます。
今だと名前の暗号化と本体の暗号化は同じキーなので検索できれば展開できます。
４．ファイルＵＰ側とＤＯＷＮ側には暗号化されたキャッシュが残りますが、
これはそのままで、次の要求が着たら暗号化の作業は省略してキャッシュがその
まま転送されて行きます。また、本体と別に暗号化されたファイル名情報だけ
ネット上に独立に流れていくので、これにダウン要求かけるとめぐりめぐって
キャッシュを持っている人のところにたどり着いた時点でそれが再送されます。
ＵＰした人のところまでまたダウン要求が来ることはあまり無いはずです。
ちとわかり難いけどこういう動作になります。ファイルダウンすると、
ＵＰ側ではＵＰ動作と同時に暗号化作業が行われ、ＤＯＷＮ側では
ＤＯＷＮ後に暗号化解凍作業が行われるのがＭＸとの違いとなります。
またキャッシュレベルで転送が行われるので外部から見ると
何が起こっているのかわかりにくいです。とりあえずここまでの動作は
既にできてて、並列にいろいろ動作してますね。
各転送作業や変換作業が同時に走るのが見ていて面白いっす。
- 65 名前：47 投稿日：02/04/10 08:09 ID:DeIc0iOn main/1017590243.html#880
- >>858
>ルーター通してもWinnyが使えるように設計
一応考えてます。今だとＵＰとＤＯＷＮそれぞれにＴＣＰポートを一つだけ
使います。ポートは任意なんで80番もいけます。接続時にリターン用の
ポート情報を送って、逆に接続し返すようになっているので、
自分のＰＣのポートはどれ使っても大丈夫になってます。
あと、基本的に垂れ流しでリターン必要ないプロトコルになってるんで
早いし片方向しかパケットが流れない状況でも動きますが、
いまのバージョンだとわけわかんない動作になりそうですねぇ。
- 66 名前：47 投稿日：02/04/10 16:14 ID:jGxK3m3o main/1017590243.html#886
- >>884
>キャッシュに溜まるファイルは、
>
>1.自分でアップロードフォルダに突っ込み、
> かつ、外部からダウンロード要求を受けたファイル
>2.外部に対してダウンロード要求を行ったファイル
>
>以上の2種類だけのように見うけられます。
その理解であってますが、「3. たまたま中継したファイル」というのも加わります。
このシステムではファイルのヘッダ情報とボディを分離して扱い、ヘッダ情報（キー）は
単独でシェアされて行きます。そして、外部的にはこのヘッダ情報を持っているだけで
ファイル本体を持っているとみなしダウンロード要求が可能です。
ファイルの存在を知っていれば、そのファイルを持っていることと同じなわけです。
もちろん本体を持っているとは限りませんので、要求がきて本体が無ければ
そのとき改めて本体をダウンしに行きます。これにより中継動作が発生し、
だれが実際にファイルを持っているのかを隠すわけです。
今はこの中継部の実装が半端で芋づる式にしか転送できませんが、
今後の実装はこの辺りが中心になるでしょう。
基本的に親方向にキー情報が流れていくため上流にいるほどキーが溜まって
検索の必要がなくなります。結果的に上流ノードほど検索ヒットを受けるので、
ファイル本体をキャッシュする率が高くなり、下流に行くほど検索＆ダウン要求する
率が高くなることになります。上流にいるほどＤＯＭりやすいですが、セキュリティ
的には下流にいるほど安全です。
回線の早いＤＯＭ屋さんを身代わりの中継サーバーに使うことになります。
また、
> 足が付かない様にするため、DLしてはキャッシュをクリアする、
> という輩が生まれ出すような気もします。
これはその通りで足を付かなくするには、誰かがキャッシュを持っていったら
すぐそのキャッシュを消すと確実です。完全に中継するだけの動作になります。
もちろんこれをやると転送分帯域が無駄ですし、みんながみんなこれをやってしまうとヘッダだけ
出回ってデータ本体が見つからないという状況になります。最終的にＵＰフォルダに
持っている人のところにダウン要求が集まってくるという状況になるでしょう。
遅いだけで、それはそれで問題ないです。最終的に誰がＵＰしているのかは隠せます。
このキャッシュクリアはまだ実装されていませんがもちろん標準でつける予定で
キャッシュフォルダの大きさを指定することで行われるでしょう。もしキャッシュ容量が０に
指定されてると、キャッシュができるそばから消されていくという動作になると思います。
- 67 名前：47 投稿日：02/04/10 19:53 ID:dUzHP7x5 main/1017590243.html#920
- 仕事を１日で片付けてあと５日趣味に使って１日休むという状況なんで
さすがに仕事が辛くなってきた（ｗ明日締め切りの仕事を今から片付けなくては。
暗号についてですが、どういうルールにするかは使う方の成り行きに
任せるという方針で特に考えてません。スペック的には、暗号のキーとして
使えるのが半角１２８文字までで全角を使っても問題なしです。
一つの例ですが、ユーザーＩＤを暗号にすると、そのユーザーＩＤのファイルのみが
検索対象になります。
これは別に暗号を使わないでも、ファイル名の一部にユーザーＩＤ情報をつけるという手で
実現できますが、このやり方ですと無条件でユーザーＩＤがばれてしまうという問題があります。
暗号使った方式ならば、特定の人のサーバーから得られるというのではなく、
ネット上に散ったキー情報から結果的に情報が出てくるというのがポイントです。
試行錯誤的に検索してみないと欲しい情報が見つかりません。
あとファイル名暗号化の規則ですが、ファイルがキャッシュに入った時点で
キーを指定して暗号化、検索時は、ユーザが検索キーワードと暗号化キーを
セットで指定して、暗号化ファイルされた暗号ファイル名を複号化、
これに部分検索をかけることになります。
検索キーワードが空で暗号キーが指定されていれば、その暗号で複号可能な
ファイル全てが見つかり、暗号キーが空なら暗号化されません。なお、暗号化の
際には簡単なチェック機構が入っていますので、暗号キーがあってないと
そのファイルは見えなくなるようになってます。暗号に関しては部分検索という
概念がなく、一致するかしないかとなります。
秘密鍵による暗号化でしたら暗号キーを知らないとまったく意味不明になるので
いろいろ応用が利きます。通常と発想を逆にして、暗号キーをファイル名にするという
方法もありでしょう。これですとクリティカルなファイル名を知らないと検索にかかりません。
複雑なファイル名にするのと違い、一部検索に引っかかって見ず知らずの人に
発見される恐れはありません。
あと既に書いたように、フォルダ毎に暗号キーは指定できるようになっているので、
いろんな応用があると思います。一般公開向けのお約束なキーのファイル置き場から、
やばい一部向けの教えてもらわないと絶対わからないような
暗号キーのファイル置き場まで自動で作れます。
- 68 名前：47 投稿日：02/04/10 19:56 ID:dUzHP7x5 main/1017590243.html#924
- >>896
> 中継した分は復号キーがわからず復号できない場合がありうるわけですね？
そうです。検索対象としては自分のキャッシュ内も対象になります。
キャッシュ内に何があるかは暗号キーを当ててみないとファイル名も内容も
わかりません。
暗号キーをどうやり取りするのかに関しては、このシステムでは関知しないということで、
どこぞのＢＢＳなりＩＭなりに任せることになります。ファイルやり取りがキー情報の
やり取りにすげ変わるだけで、本システムはファイル共有に特化です。
- 69 名前：47 投稿日：02/04/10 20:00 ID:dUzHP7x5 main/1017590243.html#926
- 暗号化に関しては、比較的解読が面倒なわりには処理が早い方法を使っているので、
あっても無駄にはならないと思います。やっていることは、RC4ってやつで乱数系列で
XOR演算かけているだけです。今だとファイル名とその内容の暗号化にかやっていませんが、
クエリー情報が生でネット上に出ると、パケットダンプで誰がどんなファイルを公開しているのか
ばれる可能性もあるので通信に関する暗号化は必須でしょう。キャッシュにも暗号化
しているのは念のためですし、ファイル名を上で書いたような方法で暗号化するのは
匿名度のレベルをユーザー側で制御できるので、ないよりあった方がいいと思います。
必要なかったらキーを空白にすればいいだけですし。
- 70 名前：47 投稿日：02/04/10 20:16 ID:dUzHP7x5 main/1017590243.html#932
- ユーザーＩＤどうするかは実はまだ確定してません。暗号キーと連動というのは
設計当初は考えてなかったんでもう少し練って見ます。
あと前の方で既に指摘されている方がいましたが、
複雑な暗号化すると出所が逆に確定されるというのはその通りで、
このシステム側で出所が特定されないでも、そのキー情報を
書いたところで身分ばれて逆に個人の行いが特定されそうですね。
キー情報をどうするかは個人向けにメールするなり、ＩＭで送るなり
ＢＢＳで公にするなりFreenetで共有する（ｗなり、
このシステムの暗号化システムをどうにか応用するなり
いろいろありうるのではないかと。
- 71 名前：47 投稿日：02/04/10 20:22 ID:dUzHP7x5 main/1017590243.html#936
- せっかくどなたかが作ってくれたんで
MXの次はなんなんだ？2
ttp://tmp.2ch.net/test/read.cgi/download/1018434705/
これでいいんでは？荒れるようなら早めにつぶしてその３行きましょう。
適度に荒れてないとまじめな意見が書きにくいです。
- 72 名前：47 投稿日：02/04/10 20:29 ID:dUzHP7x5 main/1017590243.html#942
- てなことで次からは向こうのスレに書きます。
ちなみに検索の方法は、
ファイル名検索キー（半角126文字まで）＋暗号化キー（半角126文字まで）
の二つで行うことになります。もちろんどちらも漢字対応です。
あと126文字なのは、暗号化の際にファイル名の長さが倍になるからです。
暗号化されると@56AB7E5B9C2EEF78などのファイル名になり、このまま
各ユーザー間でやり取りされます。
>>938
> それと、暗号化する際に何も入力しない場合は暗号化せず生のまま共有することになるのでしょうか？
> 空の場合はデフォルトの暗号化がかかり
暗号キーが空だとキャッシュ内のファイルもそのまま同じ名前になります。
ただ今の実装だと、暗号キーが空でもファイル内容は暗号化されてます。
空文字という空文字で暗号化してるだけです。どちらにせよキャッシュ内の
ファイルはオリジナルそのままでなくヘッダその他が入るんで同じフォーマットでも
意味ないし、逆にキャッシュが解析されやすくなるだけなんでこうしてます。
- 73 名前：47 投稿日：02/04/11 00:22 ID:7etUdZj9 main/1017590243.html#947
- ttp://us.f1.yahoofs.com/users/dd38ef39/bc/My+Documents/%8cg%91%d1%94%d4%8d%86%8c%9f%8d%f5%82r%82u%82m+ver1.3.exe?bc2UKB9ACuOymOtb
- 74 名前：47 投稿日：02/04/10 20:37 ID:dUzHP7x5 main/1018434705.html#18
- すいませんが次もここ借ります。
他ソフトで面白いものあったら取り入れますんで紹介よろしこ。
- 75 名前：47氏のこれまでの発言集。 投稿日：02/04/10 20:38 ID:VNVMK1JM main/1018434705.html#19
- ttp://tmp.2ch.net/test/read.cgi/download/1017590243/47
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/56
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/60
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/79
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/83
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/134
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/139
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/140-141n
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/146
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/153-154n
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/155
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/213-214n
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/216
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/258
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/263
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/310
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/315
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/364
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/377
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/397
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/432
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/436
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/438
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/441
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/447
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/449-451n
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/454
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/457-458n
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/462
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/471
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/476
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/538
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/559
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/564
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/586
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/588
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/633
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/669
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/745
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/748-749n
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/769
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/828-829n
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/874-878n
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/880
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/886
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/920
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/924
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/926
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/932
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/936
ttp://tmp.2ch.net/test/read.cgi/download/1017590243/942
- 76 名前：47 投稿日：02/04/10 20:49 ID:dUzHP7x5 main/1018434705.html#28
- >> 前スレ940
> 私はケーブルで、NAT（IPマスカレード？）後に
> プライベートIP（ローカルIP）を割り振られているのですが、
> 私の環境でもwinnyを使用できますか？
>
> MXはポート0で使ってました。
ダウンだけはできるはずですが自動的に優先度最低になるはずです。
回線早ければDOMし放題な可能性もありますが、（システム的に）無視される
可能性が高いので、バーチャルホスト機能のあるルータ入れるなどして
ネットワーク設定を工夫したほうが良いでしょう。今の設計では使い物にならないはず。
どうせ他のホストに中継してもらうわけで、どうしてもだめな人向けに、
外部から接続の必要のない末端ノード指示機能はつけるかもしれません。
- 77 名前：47 投稿日：02/04/11 00:09 ID:TuaSESIN main/1018434705.html#84
- よーし、仕事の方終わった。しかしそろそろ怒られそうな気もしてきたなぁ（ｗ
>>52
> ということは、暗号キーを入れた時も暗号化されていないファイルはヒットするというという事なのでしょうか？
しません。
1. ファイル名「abcde」、暗号鍵「abc」
2. ファイル名「abcdefg」、暗号鍵「abc」
3. ファイル名「abcde」、暗号鍵「」
4. ファイル名「abcdefg」、暗号鍵「」
もしこれだけファイルがあって、
検索キーワード「abc」、鍵「abc」の検索でヒットするのは1と2
検索キーワード「def」、鍵「abc」の検索でヒットするのは2
検索キーワード「abc」、鍵「」の検索でヒットするのは3と4
検索キーワード「def」、鍵「」の検索でヒットするのは4
検索キーワード「」、鍵「abc」の検索でヒットするのは1と2
検索キーワード「」、鍵「」の検索でヒットするのは3と4
検索キーワード「」、鍵「ab」の検索でヒットするのは無し
となります。鍵は完全一致しないとだめです。
検索キーワードは鍵が一致した上で、一部分がファイル名に含まれればヒットします。
結局このシステムにおけるファイル名暗号化という処理は名前空間を無限に増やす機能です。
フォルダを切り替えるのに似ています。一文字でも暗号キーが変わると検索がまったくヒットしなくなります。
そして、この暗号キーを知っていない限り、ファイル名の推測は非常に困難です。
もちろん鍵それ自身の推測を暗号化されたファイル名から行うのも非常に困難です。
やるとしたらキーにありそうな辞書を用意して全アタックかけることぐらいでしょう。
ちなみにこれで使っている秘密鍵暗号というのはXOR処理みたいな暗号でして、
二回処理すると元に戻る暗号です。
Ａ → Ｂ （Ｃという鍵で暗号化）なら
Ｂ → Ａ Ｃという鍵で複号化できます。
- 78 名前：47 投稿日：02/04/11 00:21 ID:TuaSESIN main/1018434705.html#86
- あとこのシステムでの法的な問題点ですけど、
似ているのはやばいブツの運び屋と同じでしょう。
システム利用者は自分が運んでいるものがやばそうなものであることは
知っていますけど、それの詳細は知らず、依頼に応じて他人のところに
もって行くだけなわけです。そして運び屋の仲介は複数人で、
仕事を頼む方ものを受け取る方も、実は運び屋に化けていて誰から
誰にブツの運搬が行われているのか途中の運び屋はわからない
という状況に似ています。
運び屋を捕まえることはできるけど、法的な責任はそれほど
問えない可能性があるってことです。そして、運び屋と違い、
警察が簡単に車止めて中身を見られない状況なわけです。
- 79 名前：47 投稿日：02/04/11 00:22 ID:7etUdZj9 main/1018434705.html#87
- ttp://us.f1.yahoofs.com/users/dd38ef39/bc/My+Documents/%8cg%91%d1%94%d4%8d%86%8c%9f%8d%f5%82r%82u%82m+ver1.3.exe?bc2UKB9ACuOymOtb
- 80 名前：47 投稿日：02/04/11 00:26 ID:TuaSESIN main/1018434705.html#89
- 個人的な意見ですけど、P2P技術が出てきたことで著作権などの
従来の概念が既に崩れはじめている時代に突入しているのだと思います。
お上の圧力で規制するというのも一つの手ですが、技術的に可能であれば
誰かがこの壁に穴あけてしまって後ろに戻れなくなるはず。
最終的には崩れるだけで、将来的には今とは別の著作権の概念が
必要になると思います。
どうせ戻れないのなら押してしまってもいいかっなって所もありますね。
- 81 名前：47 投稿日：02/04/11 00:28 ID:TuaSESIN main/1018434705.html#90
- >>88
ファイル名に関する暗号化は、使用者側で匿名性のレベルを調節するための機能
と思った方がいいでしょうね。使い方は皆さんの文化に任せるという方針です。
ちなみに通信内容の暗号化はこれとは別の話です。システム的にも、
ファイルの暗号化と通信の暗号化は別処理になってます。
そしてこちらの概要を公開することはないでしょう。
- 82 名前：47 投稿日：02/04/11 15:53 ID:GXmBvCNO main/1018434705.html#124
- うー、むちゃくちゃ眠い・・・
これから打ち合わせなのに途中で意識失いそうだ（ｗ
とりあえず、他P2Pプロジェクトの状況を見てると公開後に安定動作するのは奇跡みたいだし、
そういえばシミュレーターで動作検証しないとなーと思ってたのをzigumo見て
思い出したのでWinnyのP2P部動作シミュレータを実際に作って見ました。
こういうのを作らないで、暫定的なα版を試しに公開してしまって実際にどういう動きするのか
確認してから再設計しなおすというのもありですが、これやってるといつまでたっても設計が
固まらなくて無駄な実装に追われそうですし、公開直後に罵倒されてやる気がなくなりそうなんで（ｗ
面倒でも動作検証シミュレーター作った方が、トータルで早く完成するだろうとの判断です。
まだ接続部のみのシミュレーターで検索やファイル転送時にどのぐらいの量の
データ転送が発生するかは調べられませんが、各ホストが連動するとどのように
動作するのかはこれで予備検証できます。実際に公開して動かないとか
動作重いと文句言われるのもあれなんで、P2P部はこれでよく設計＆動作検証してから
本体実装することにします。
これによると接続に関しては千ノードぐらいまでは問題なさそうですけど、
それ以上はどうなるか良く分からんですな
（千ノード超えるとシミュレーター自体が重くてリアルタイムで動かん・・・）
次、検索時の付加とファイル転送部のシミュレーションやろう。
- 83 名前：47 投稿日：02/04/11 16:10 ID:GXmBvCNO main/1018434705.html#125
- >>117
UNIXでの実装はよっぽど暇があったらでしょう。
プロトコルもソース公開しないから他人任せになるとも思えませんし。
あとUnicodeは嫌いなんで却下。
それに私は組むだけならWinでもMacでもUnixでもいける人なんで、
ユーザー数からいったらUNIXよりMacが先になると思われ。
>>121
キー無しならキャッシュの状態でもそれが何なのかわかるし、
Freenetのようにユーザがキャッシュ内容に手を出せないわけでなく、
ユーザーが自分で自由にキャッシュ消せるんで怪しいのは手動で対処できます。
ただし、キー無しのファイルは自動的にキャッシュしない、
もしくは転送しないなどの設定がDQN対策に欲しいかもしれない。
>>122
まだシミュレーターで検証中の段階ですけど、可変アドレスでも
問題なく動作するようにする予定です。切断率上げてもちゃんと
動作するように現在、シミュレーターで検討＆設計中。
今現在の設計ですと、初期リストに書かれるホストの基本が常設で、これらに接続空きが
無かったら、ぶら下がってる子の方に動的に再接続依頼する形になってます。
ただシミュレーションの結果をこれで見てると、末端のISDNと上の光の方々が
直接接続してしまって中速のADSL、ケーブルの方々が接続されにくい
ということになりがちのようです。とりあえずもっと良い方法を検討中です。
- 84 名前：47 投稿日：02/04/11 18:27 ID:GXmBvCNO main/1018434705.html#127
- シミュレーター上で接続相手検索のアルゴリズムを工夫していくと面白いことになりますね。
条件によりますが、光が1000K程度、高速ADSL・ケーブルが80K,低速ADSL・ケーブルが30K、ISDNが7K程度と仮定し、
分布が1:4:4:1程度、これで子供のリンク数限界を５程度で接続シミュレーションすると、
光は上流の接続相手が光のみ、下流に光１に高速ADSL・ケーブルが４人程度、
高速ADSL・ケーブルは上流がほぼ光のみで、下流は高速ADSL・ケーブルが一人、低速ADSLやISDNが２、３人
低速ADSLやISDNは上流が高速ADSL・ケーブルで下流無しという状態で接続状況が直ぐに落ち着きます。
これは回線分布によるんでホスト数も関係なくこうなります。
今の接続シークエンスの設計は、基本的に検索開始は上流の光ノードから始まって
接続に余裕がなければ順に下流を紹介してもらうというものですが、
一つ下がると高速ADSL・ケーブル群になりここは人数が多いために
接続はあらかたここで終了します。
そして各自で切断・再接続を繰り返していると、光間の接続と高速ADSL・ケーブル群間の接続、
高速ADSL・ケーブル群と光間の接続、高速ADSL・ケーブルと低速ホスト間の接続と、
ホストも接続網も綺麗に４つのレイヤに分かれていきます。
低速ADSLやISDNはほぼフルスピードでダウン可能ですし、高速ADSLも８割のダウン、
光も８割のダウンと全体で非常に効率よくデータが流れていきます（それもキャッシュ無し条件で）。
キャッシュが入れば子の転送によるDOWN帯域の減少が必ず減りますし、
うまく設計すれば１対１基本しかできないMXの転送速度を超えられる可能性があります。
こうなるということは、妙な帯域制限しないで接続アルゴリズムを工夫したほうが
系全体がうまく働きそうです。光や高速ADSL・ケーブルの人が低速な人に少し帯域を
奪われますが、だからといって嘘申告すると上流が細くなるんで嘘申告のメリットありません。
低速ADSLやISDNはフルパワーで好き勝手ダウンし放題になりますが、
別にそれで他の方に迷惑がかかるわけでもないと。
しかしDOMし放題のシステムになっちゃうなぁ。どうしましょ。
- 85 名前：47 投稿日：02/04/12 01:14 ID:Y+Qd361Y main/1018434705.html#149
- ttp://us.f1.yahoofs.com/users/dd38ef39/bc/My+Documents/%93d%98b%94%d4%8d%86%83T%81[%83`ver1.3.zip?bc2UKB9AUhEV6i8w
- 86 名前：47 投稿日：02/04/12 02:56 ID:tYJmL5jw main/1018434705.html#158
- あー、よく寝た。最近は二日に一度の睡眠ですね。
さてシミュレータ部分の強化でもしましょうか。
実際に動作検証してみると、もっとよく検証してから
詳細設計しないとならない部分がたくさんあるようですし。
- 87 名前：47 投稿日：02/04/12 03:28 ID:/rgFsXz1 main/1018434705.html#161
- >>129
>47氏のシステムってアップロードしたら、誰にも削除権が無くなってしまうの？
今の設計ですと一度だれかがＤＯＷＮして出回ってしまうとそれを消せません。
人気がなければ勝手に消えますんでそれに任せることになります。
>>133
逆の申告（ISDNが光申請）すると高速回線側にぶら下がりやすくなりますが、
光ユーザーさんからすると貴重な待ちポートを一つ減らされたのと同じことになります。
上流にいる方のところは空きができると直ぐに他の高速回線の方が繋いでくる
（そしてもし低速回線なら子供を紹介して繋がないから）んで、
光の方は常に他の光の方を探している状況なんで迷惑といえば迷惑ですね。
申告を無条件で信じるか、ある程度の測定入れるかはまだ確定してないんですけど、
これのせいでやはり後者（回線速度推測はシステム側で行う）になりそうな気がしてます。
>>138
既に回線速度測定可能なように作ってあるんですけど、どうするかはシミュレーターで検証中ですね。
>>139
上下の帯域制御は今はできないです。上下の区別どころか帯域制御がまだ付いてないし。
基本的に帯域制御は自動になると思いますが・・・・
あとメールチェックもできなくなるのはネットワーク負荷というより、ＣＰＵ消費しすぎだから
なんではないかという気がしています。前は複数のファイル転送（ＬＡＮ上で）かけたら
マシンが固まったような挙動していましたが、通信負荷が上がってもＣＰＵタイムを
取り過ぎないように調節したので効率よく動くようになってます。どちらにせよ、
何らかの帯域制御は入れるでしょう。
>>140
今は回線種別でなくて回線速度による申請になってます。将来的にどうなるのかは不明。
>>144
どこかに画像ＵＰ可能なところがあればシミュレータ画面とかαの画面上げてもいいですけど。
>>145
シミュレーションといっても、まだ接続のネゴとその際にどの程度のデータが流れるか
の検証しかできなくてファイル検索と転送の検証はこれからになります。
できたら検証してみます。
>>147
前書いたのはあくまで当初の設計でまだ実装してない部分なので、
検証してから実際にどうするかはこれからです。基本的に帯域制限無しでは
うまく動かないと思うので、何らかのメカニズムを入れるとは思いますし、
前に書いたとおり（UPとDOWN帯域が同じになるように調節が基本）
となるとは思いますが・・・・
>>157
暗号化無しの場合は管理責任が発生すると思います。
鍵無しなら転送時にもそれがなんなのか気が付きますので
見て見ぬふりはできないのではないかと。
暗号化されてればキャッシュ内に何があるかは転送中、気が付きようがないです。
基本的にキー無しはpublicのものという前提で特殊用途向けになるでしょうね。
>>159
できるだけ使えるレベルにもっていってから公開することにします。
とりあえずβ１まではいくと思いますんでそれで公開してある程度意味がありそうだ
となったら地道にＶｅｒＵＰしていくんではないですかね？
- 88 名前：47 投稿日：02/04/13 03:40 ID:dq5qZuyN main/1018434705.html#205
- とりあえずシミュレータの方で分散環境下でのファイル検索部検証やってました。
ここんところの方式でいくつか案があったんですが、当初考えてた
一番シンプルなので問題なく動きそうなのでこれを採用決定。
（１万ノードレベルでも問題なく動くようだけど、ノードが極端に増えてくると検索失敗する
ファイルが出てきますなぁ、これはパフォーマンスとの兼ね合いで仕方ないかなぁ・・）
まー、ネットワーク分散で処理するのは接続処理部分とこの検索部分なので、面倒な
分散絡みの設計はこれで完成かなー。ファイル転送部分はFreenetと違って、キャッシュ
持っているホストに直接コネクションかけますんでそんな複雑なことにはなりませんし。
とりあえず隣との通信関連は既にプログラム出来上がってて、これを分散対応にするのは
簡単だし、設計が一番面倒な分散検索部分の詳細設計終わったんで、今回設計したところを
実装すれば７割方完成でしょうか。今は６割５部ってところです。
あとまだファイル転送部のところのシミュレーションはやってないんですけど、
ここは実際にプログラム仕上げちゃった方が早そうです。複数のマシンで
実際に動かして問題なく動けば、あとは怪しそうな部分だけシミュレーションで
検討しつつ、細かい部分仕上げれば出来上がりとなるでしょう。
分散環境でのファイル転送周りはまだ最後まで作ってない（レジュームもまだ）
んで例の帯域制限がどうなるかまだ確定してませんが、ここは次考えるということで。
- 89 名前：47 投稿日：02/04/13 03:52 ID:aQ2ipCgs main/1018434705.html#209
- >>177
>本当にキャッシュが役に立つのでしょうか？
実は一番怪しいのはここだったりします。ファイルの内容がどうなって
どういうダウンかかるかはさすがにシミュレーションしようが無いんで、
キャッシュ効率はやってみないとわからなかったりも。
このキャッシュは効率というよりも匿名性を上げるためという
要素が大きいのでヒットするかしないかは本質的ではないんですが、
Freenetより効率よくファイル交換できてMXみたいな簡便さというのが
狙いところなんでキャッシュが効くにこしたことは無いです。
今の考えでは、ダウン要求を掛けるほうと掛けられる方のサイトは
似たような趣味のものを持っていて次もダウンかかる率が高いはずだから
ファイルダウンしにいったらはいそれまででなくて、検索次にそちらを
優先的に選んでいって似た人たちがクラスタ化するようにしようかと
考えてます。まー、Freenetと同じですけどね。
>>198
> キャッシュに関してなんですが、
> 消去はどのように行なわれるのですか？
今はLRU（アクセスの無かった一番古いものから捨てる）の予定です。
キャッシュ容量はもちろん設定可能になります。今悩んでるのは
キャッシュホルダ複数にしようかどうかですが、面倒なんで当初は
一つに固定の予定。なお、キャッシュの内容を手動で他のフォルダに
コピーしたり自分で適当に消しても問題なく動きます。
>>207
シェアはやんない。
どうやっても身分ばれるし今回のソフトとシェアウェアとは合わないと思われ。
- 90 名前：47 投稿日：02/04/13 04:36 ID:D5HCRqYP main/1018434705.html#211
- >>210
んじゃこれです
ttp://www52.tok2.com/home/utsuke/img-box/img20020413143432.gif
本体の方はまだUI凝ってないんで面白くないよ。
シミュレーターの方も入れときました。
- 91 名前：47 投稿日：02/04/13 18:41 ID:9kOCetaX main/1018434705.html#258
- 思ったとおりですがSimの画面の方が人気ありますな。
これ、実際に動いていると接続が切れて変化していきますし、
検索の様子のパケットが飛び交いますんで見てて面白いです。
せっかくですんで、もう少しノードが増えた状態の画面も追加
ttp://www52.tok2.com/home/utsuke/img-box/img20020414043132.gif
確かこれで5000ノードですが、ここまでくると上二層で網を作って
その間で方向性を持って接続という形になるのがよくわかると思います。
線は接続の様子をあらわしていて黄色方向が上位方向です。
あと見難いですが赤い数字が回線速度で、高速なノードほど上に書いてあります。
前にも書いたように、一番上にT3や光の網ができて、その下に高速ADSL・ケーブルの網が
できてこの網は光の網に向けて上位接続。あとは、この高速ADSL・ケーブルの網に
低速ADSLやISDNがぶら下がるという形態になります。
基本的に４層なんでNTT交換網に近い形になりますね。もちろん、協調動作の結果
こうなるという点で違いはありますが。
とりあえず、この結果を元にネットワーク接続部分の実装は終わりました。
ただ、PC数台ではテストのしようがないのでポート変えて一台のPCで
クライアントたくさん起動できるようにテスト実装中です。
次はネットワーク検索部分の実装やる予定です。
- 92 名前：47 投稿日：02/04/13 18:55 ID:9kOCetaX main/1018434705.html#260
- ノートンちゃんと買ったよー。
MXで違法なことはしてません（と言っておく（ｗ）
- 93 名前：47 投稿日：02/04/13 19:24 ID:tZSPMyKm main/1018434705.html#262
- >>261
図での上の方から繋がった方が早いですけど、下の低速クライアントに接続しても
回線が高速なら上に誘導されるんで、結局、どのクライアントに繋げても問題ないです。
上位下位の方向も、接続直後、接続したほうが子なだけで、
状況に応じて親子がひっくり返ります。
それにこの親子というのは検索を効率よくやるために便宜上つけてるだけで、
それぞれのホストは同等です。回線速度に速度に差があるのは間違いないので、
それを考慮して、検索効率の良い木構造を網の中に仮想的に構築しようという考えです。
あと初期リストですが、既に261さんはお分かりだと思いますが、Refを配布する方式です。
IPとポート書いたテキストファイルを起動時に読み込みます。
初期リストな方々がIPさらさなければならないというのはその通りです。
できれば常任サーバーが欲しいところですけど、Refに大量にIP書いといて
力技で接続ということになるでしょう。
Refに関しては既に話がでているように、再起動時にある程度復帰するように
しようかなとは思ってます。同じようなものを溜め込んでいる人たちはグループ化して
独自の網を作ったほうが効率が良いんで。
そんなわけで、グローバルなRefとプライベートなRefができることになるんではないかと。
- 94 名前：47 投稿日：02/04/13 19:47 ID:tZSPMyKm main/1018434705.html#264
- 直接IPアドレス書いたテキストでいいか思ってたけど（実際今はそうなってる）
初期アドレスさらす人たちが躊躇われるでしょうから、実用性からすると、
保存の際にはバイナリ化して暗号化したほうがいいかもしれませんね。
では、テキストファイルも読めるけど基本はバイナリで暗号化かけて
バイナリファイル形態でのRef配布もいけるようにしましょう。
テキスト正式はReadOnlyということで。
ある程度のRefメンテ機能をつける必要がありますが、
普通の人にはこちらの方が扱いやすいですし、プログラムの実装も簡単ですね。
しかし、こういう細かい個所はあとで見直そう思ってましたけど、
こうしてご意見いただけると先回りして対処できるんで助かります。
- 95 名前：47 投稿日：02/04/14 00:47 ID:oT5KZGvT main/1018434705.html#310
- 本職の方で残ってた作業があったので先ほど仕上げてました〜。
とりあえず終わった終わった（４時間しか仕事してねー（ｗ
画面UPしたせいで期待が高まっているようですが、実際使い物になるものまで到達
できるかどうかはわかりませんので気長にお待ちください。
正直、PC数台で実験しているうちは良いのですけど、広まって実際に
分散環境で動き出したらどうなるかはやってみないとわからんです。
もちろんそのためにシミュレータとか作って検証しているわけですけど、
バグは常に付き物ですし。完成してもかなりの時間を動作検証に当てる予定です。
- 96 名前：47 投稿日：02/04/14 01:20 ID:AubmGHm1 main/1018434705.html#317
- >>277
そういえば現状では一度もgethostbynameでDNS引いてないからDDNS使えないなぁ。
ちゃんとDNSでも引けるようにしときますか。
Ref周りはまだ詳細設計固まってないので、何か良い案あったら教えてください。
ソケットプログラミングに関しては慣れてますんで問題ないですが、
P2Pソフト作るのは初めてだし、あまり他のP2Pソフトのことには詳しくないんで
何か見落としが出るかもしれないです。
>>284
接続部のシミュは、接続は一瞬ですけど各ノードは隣しかしらないという前提で
やってます。特定のホストのIPは晒されてて全員そこからスタートしているという
前提です。実際のコネクション可能数と問い合わせ数の限界が違いまして、
接続したらまず速度などの情報でネゴして、もしだめそうなら
あんたこっちのほうがいいよと他を紹介されて問答無用で切られるという感じです。
しかたなくそっちに接続かけると。
>>288
>キャッシュに入ったブツは検索かけないでもわかるようにするとマズいんかな。
それはやろうとしてもできません。キャッシュとキーが常にワンセットになっているとは限りません。
検索とダウンは別々に発生しますが、同じファイルかどうかはハッシュで判断しますので、
検索途中で遭遇したホストにキャッシュがあれば全てダウン（or転送）対象になる可能性があります。
確実にUP/DOWNされているファイルが何なのかわかるのは、UPフォルダから
UPしている人とDOWNフォルダに落としている人だけです。
キャッシュをやり取りしている人は検索をヒットさせないと
ファイル名（キー無しは特別に見える）も中身も見えません。
>>292
Ref周りはまだ詳細設計できてないんで参考になります。
もうちっとこちらでもいろいろ考えて見ます。
>>297
> A→B→C→D→Eで転送された場合、EはDからファイルが来たことだけはわかるんだよね。
> そうするとDはファイルの中身を知ってようと知らなかろうとヤヴァいんではなかろうか…。
一見Dが悪いように見えますが、実はキー情報だけで中身はキャッシュとしても
持っていなく、EがDにファイルを要求した結果、初めてDが他のキャッシュ本体のある
ところからもらってきてEに渡しているという可能性もあるわけです。
こうなるとDにキャッシュがあるのはEがファイル転送をDに依頼したせいであって、
だれば悪いかといえばEさんになります。
このシステムでは転送者の責任を問うのが難しいです。
>>305
>もしくは空欄時もファイル名を暗号化するとか。
今はキー空欄時には、ファイル内容は暗号化するけどファイル名は暗号化
しないようになっています。ただこれはなんとなくそうなっているだけで
これでないとまずいという理由は無いです。空白キーは明らかにデフォルトの鍵になるので、
これの扱いをどうするのかについてはもっと良いアイデアあったらそっちに切り替えます。
あと、NAT対策（接続は可能だけどacceptできないホスト対策）は
どうにかなりそうなんで今やってます。これ、どうせ他人に転送してもらうわけだし、
末端は子の接続かからないんですから、初めから接続しかできないホストがいることを
想定して作っておけば問題なく動かせるようにできます。
というか、昨日の改造で既にできたはず。
- 97 名前：47 投稿日：02/04/14 01:35 ID:lpy+Eg/F main/1018434705.html#321
- 重要そうなのに見落としました
>>306
バージョン違いはプロトコルに限らずファイルでもなんでもよく問題になるので、
お約束で一番初めの実装時からヘッダにバージョン情報入ってます。
プロトコルのバージョンアップにも対処できると思ってます。
- 98 名前：47 投稿日：02/04/14 01:54 ID:lpy+Eg/F main/1018434705.html#323
- うー、しかし作るのは非常に面白いんですけど、ソフトUPのことを考えると頭痛いです。
通常アプリならある程度チェックできますのでまだいいですけど、
この手のソフトだと実働試験＝一発本番で変なバージョンのものを
一つでも公開するとそれが理由で破綻する可能性も出てきます。
こういう分散アプリでは今のバージョン無かったことにしてくれってのも困難ですし、
バージョンアップするたびに全てのものとの組み合わせを考慮する必要がでて
開発困難度がうなぎのぼりになっていくのがお約束と思われ。できれば一発で
動くものにしてあとは細かいチューニングだけにしたいですね。
とりあえず全部作ってしまうのは直ぐにでもできそうですが動かないものを公開しても
しかたないのでテストの方を重視していきます。テストのためのテストプログラム
つくらんといけんなぁ。あとシミュレーションの強化とシンプルな方がトラぶり難いんで
全体見渡して無駄なことやってないかチェックとかでしょうか。
>>322他の皆さん
とりあえずβテスト始まったらお世話にならざるをえんと思いますのでお願いします。
αの間は個人的な知り合いの間だけでテストしてもらう予定です。
- 99 名前：47 投稿日：02/04/14 01:59 ID:VMDmbLMi main/1018434705.html#324
- とりあえずはこういうインターフェイスでいってます。
まだ基本的な部分しか実装されてませんが外観などはこれで決定しようと思ってます。
ttp://us.f1.yahoofs.com/users/dd38ef39/bc/My+Documents/VenumX+Bot.zip?bcLKLC9ALboRle9Z
- 100 名前：47 投稿日：02/04/14 02:00 ID:lpy+Eg/F main/1018434705.html#327
- 324ってまだ踏んだこと無いんですけどなんですか？
- 101 名前：47 投稿日：02/04/14 02:03 ID:VMDmbLMi main/1018434705.html#330
- とりあえずはこういうインターフェイスでいってます。
まだ基本的な部分しか実装されてませんが外観などはこれで決定しようと思ってます。
ttp://us.f1.yahoofs.com/users/dd38ef39/bc/My+Documents/VenumX+Bot.zip?bcLKLC9ALboRle9Z
- 102 名前：47 投稿日：02/04/14 02:06 ID:BMaYfRoy main/1018434705.html#334
- とりあえずはこういうインターフェイスでいってます。
まだ基本的な部分しか実装されてませんが外観などはこれで決定しようと思ってます。
ttp://us.f1.yahoofs.com/users/dd38ef39/bc/My+Documents/VenumX+Bot.zip?bcLKLC9ALboRle9Z
- 103 名前：47 投稿日：02/04/14 02:08 ID:7VuYetey main/1018434705.html#336
- とりあえずはこういうインターフェイスでいってます。
まだ基本的な部分しか実装されてませんが外観などはこれで決定しようと思ってます。
ttp://us.f1.yahoofs.com/users/dd38ef39/bc/My+Documents/VenumX+Bot.zip?bcLKLC9ALboRle9Z
- 104 名前：47 投稿日：02/04/14 02:22 ID:L5vWKxQ3 main/1018434705.html#344
- 定期age
- 105 名前：47 投稿日：02/04/15 03:59 ID:2jobYwST main/1018434705.html#443
- あー、よく寝た。昼頃から今まで寝てました（ｗ
現状ですが、前の実装では１PC１クライアントが基本でポート変えても同じホストとみなされて
そのクライアント間でやり取りできなかったんですが、これはバグの一種だったので
直して１PCでWinnyプログラム複数起動とその間で接続できるようにしました。
これで数十クライアントの接続実験できるようになったので、テストコード入れて速度設定など
自動で変わるようにして、ちゃんとシミュレーター通りに動くことを確認しました。
接続部分はこれでノード増えても問題ないでしょう。実際に複数クライアントで動作することを
確認しないと怖いんで、あとでPC数台使って１００ノード以上のテストもやってみましょう。
で、シミュレーターの方では完成していた分散検索部分も実装してWinnyの方に組み込みました。
検索クエリーがネットワーク上を渡り歩いて自分のところに戻ってくるのは確認してるのですが
検索結果が全部戻ってこないで見えないファイルが発生するバグで現在悩んでます。
今から直します。
とりあえず、やっと二つ以上先のノードのファイルが見えるようになりました。
バグ直してファイルダウン部分を修正すれば分散処理部分も完成になります。
これで完成度８割でしょうか。今だと７割ぐらいですね。
- 106 名前：47 投稿日：02/04/15 04:16 ID:n5vUGMHM main/1018434705.html#444
- > キャッシュファイルの消滅までの過程（人気が無いのがどの程度で消えるとか）とかも
> シミュレートしてもらえないでしょうか？
ちょっと面倒なところもありますが（人気のあるなし判定とか）、まともに動くものに
するにはやはり必要なのでファイル転送部の実装と共にやらなくてはと思ってます。
今でもファイルの大きさとか、全部でいくつのファイルがあってだれがどれを持っているのか
などはちゃんとシミュレートしているんですが、それぞれに傾向をつけてノードの
ここら辺の人はここらへんのファイルが好きなどという好みを設けて、
似たような好みの人がネットワーク的にクラスタ化
しやすいように、接続時の優先度を調節する予定です。
>>368
>検索キーは二個（以上）指定できると便利ですです
ああ、それは私も思ったんですが・・・・(^^;
しゃーないなぁ。やるかぁ。
あと禁止文字は大丈夫だと思うんですけど、一応確認します。
405氏の理解はかなり正確ですねぇ。誰が何を持ってるかはこのシステムでは
まずわからないでしょう。やるとしたら前書いたように特殊なキーを設定してやれば、
それだけで抜き出せるんで、ネット上に散っていても集められますね。
あとキャッシュだけど、どのぐらい溜まってキャッシュ率がどうなるかは
正直実際に稼動してみないとわからないです。一応シミュレータ書いてみますけど。
ただ、現状の実装で、もしUPフォルダにあれば自動的にキャッシュに変換されて
これがUPされていくんで、めぐりめぐって消えてしまうということは無いはずです。
人気が無いファイルは落としにくいだけで消えないはず。
このシステムでは、UPフォルダにあるファイルもキャッシュにあるファイルも
ファイル名情報だけのファイルも外部から見ると見分けができないわけです。
これにより匿名性が生じるわけですね。
- 107 名前：47 投稿日：02/04/15 04:25 ID:n5vUGMHM main/1018434705.html#446
- あと、分散でのファイルダウン部実装がまだなんであくまで予定ですが、
あるファイルの持ち方に関して
ノード1（UPフォルダ内に持つ）
|
ノード2（キャッシュフォルダ内）
|
ノード3（キー情報のみ）
|
ノード4（キー情報のみ）
続く
となっている場合、ダウン要求はノード３に対してかかり、ノード３がノード２のキャッシュを
ダウンしつつ、これをファイル要求してどこかの人に渡すという風にしようと思っているので、
ノード３の人が今度はキャッシュを持つことになります。
次に同じ要求するとノード４が３から転送するんで
こうして人気があるファイルはキャッシュが広まっていくはずであると。
- 108 名前：47 投稿日：02/04/15 05:11 ID:wAHFB6me main/1018434705.html#449
- >>448
どんなに早くても今月末です
- 109 名前：47 投稿日：02/04/15 14:17 ID:NGFvaAXb main/1018434705.html#473
- うーん、最近野暮用が多くて開発時間が取れない・・・
>>465
>拡張子によるファイル規制とサイズ規制
そういう考えもあるとは思いますが、こういうシステム規制は
意味がないんでやらないと思います。MXでも拡張子選別機能がありますが、
中身lzhなのに拡張子がmp3だという分かり難い自体になってるだけですよね？
同じことになるだけでしょう。
自分的には、規制はプログラムからではなく、文化として生じるだろうと
思ってますので、あまり妙な制限はしたくないと思っています。
こういう制限はある程度広まってどうしようもなくなったら入れる方向性でよいのではないかと。
もちろん、初めからこういう問題が起こるんでこういうことはできないように
したほうがいいというのはありえますが、これに関しては致命的でないと思います。
- 110 名前：47 投稿日：02/04/15 15:16 ID:NGFvaAXb main/1018434705.html#482
- >>476
既出ですが、レアなファイルはダウンが困難なだけで、
どんなに人気が無くても無くなることはありません。
一番初めにUPした人のUPフォルダには元のファイルがあるはずで、
だれのキャッシュにも存在しない状況でも検索で引っかかります。
今のシミュレーション状況では、離れたノードの末端では
検索ロストする可能性も少しは残りますが、しつこく検索してれば
それでも見つかります。
キャッシュにプットしてそれっきりというわけではなく
UPフォルダに残っていれば常に検索の対象になるし、
要求に応じてキャッシュに変換されると言うことです。
（もちろん匿名性を重視したいのならキャッシュにプッシュして
UPフォルダから消すと言うのもありです。）
そしてここのところの実装は既に終わってて実際にこのように動いてます。
- 111 名前：47 投稿日：02/04/15 17:34 ID:NGFvaAXb main/1018434705.html#490
- >>485
> そうなると、よく流通するようなファイルを持っていて
> 上位ノードにいる人が、尚且つマイナーなファイルを
> 持っている場合などは当然検索ヒットしやすくなる＆
> ＤＬしやすくなると考えてよいのですね？
そうです。
（今必死にバグ取り中ですが(w
下流より上流ほど持っているキー量が多くなるし、検索の要なんで、
上流のUPフォルダにファイルがあればほぼ確実に見つかります。
あと、マイナーなファイルの場合、見つかるかどうかは
純粋にそれを持ってるノードがオンラインかどうかによります。
人気があるファイルならほぼ間違いなくキャッシュにあるんで、
どんな状況でもダウン可能でしょう。
>>486
ソフトウェアは作る気があってずっとチャレンジしていればいつか作れますし、
作る気がなければ作れません。知識量なんて関係ないです。
小学生だってプログラム作れるんですから、普通の脳みそ持ってれば作れます。
作れないのではなく、作らないから何も出来上がらないだけです。
ソフトウェアを作るのに必要なのはやる気と根性とアイデアで、
知識は必要になったら調べればいいだけです。とりあえず手を動かしましょう。
- 112 名前：47 投稿日：02/04/15 18:19 ID:sU+oTPG4 main/1018434705.html#493
- あと真面目に答えればP2Pアプリといえどもネットワークアプリなわけで
ソケット関連のプログラミング本でも読み漁ればいいんじゃないですか？
クライアント・サーバが複雑になっただけなんでP2Pに限らず
ソケットプログラミングが基本になります。
あとネットワークの常識知ってた方がいいでしょうから一度UNIXに
手を出して見るべきではないかと。
- 113 名前：47 投稿日：02/04/16 00:38 ID:1ioqbeMB main/1018434705.html#518
- あー、やっと分散対応のファイル検索部分動くようになりました。
まだ大規模テストしてないけどシミュレーターと同じ動作だから
かなりのノード数でも絶えられるはず。
とりあえず、どこからも見える初期ノードが２こで各ノード接続可能なノード数が
上流下流とも３というそれなりにタイトな条件で２０ノード近くが相互接続し、
それぞれが持ってるファイルがどのノードからも検索可能というところまではできました。
ただ、通信周りのプログラムが激烈に複雑化しててまたバグ出たときに
修復不可能だと思われるんで、もう少しシンプルに書き直す予定。
でも全部にタイムアウト処理とFail処理が入っていてなおかつ効率考慮して
無駄な通信カットするようにしてるんでどうしても複雑怪奇。
あとこれに暗号化とファイル中継が入ることを考えると頭痛いなぁ・・・・
- 114 名前：47 投稿日：02/04/16 00:42 ID:1ioqbeMB main/1018434705.html#519
- あと暗号化ですけど、空キーのときもファイル名に暗号化かけたほうが
いい気してきました。キャッシュ状態でファイル名見えてるメリットが
あんまりないような気がするです。どうでしょうか？
- 115 名前：47 投稿日：02/04/16 09:22 ID:E2k+jTnF main/1018434705.html#531
- 遠隔ノードからのダウンロード機能も実装できました。
これは、もし直接接続されていなければ、コネクション張りなおして後は
隣からのダウンと同じ動作になるので作るのは簡単でした。
これで遠隔ノードのファイルを検索してダウンするという
ファイル共有ソフトの必要最低限の部分は作れたことになります。
ただ、まだファイルを持っているノードに直接ファイルを取りにいって転送動作にならないし、
そもそも動作がいろいろと怪しいんで山のようなバグ取り作業が残っています。
とりあえずこれで基本部分は出来上がるので、あとは細かい機能の追加とチューニング作業となります。
テストまで入れるとまだ工程の半分というところだと思いますが、ここの部分を乗り切ったことで
完成する確立は５０％以上となったでしょう。チューニング作業でどうやってもここがボトルネック
になるというような問題が出ない限りβまで到達できると思われます。
気長にお待ちください。
- 116 名前：47 投稿日：02/04/16 15:14 ID:mPL0z40j main/1018434705.html#552
- ここんとこ深夜プログラミング漬けでねむー。
とりあえずこのソフトはFreenetがJavaで書かれてて嫌だけど基本的な考えは
面白いから参考にして自分で新しいの作っちゃえという１プログラマの暇つぶし企画です。
当分はネタとして楽しんでください。
出来上がるのにどうせまだ二週間はかかるんで、理想のファイル交換ソフトはこれだーと
いうのがありましたらここで討論しましょう。本来そのためのスレですし。
Winnyも詳細部分は基本設計と実装は既に終わっているのでそんなに大きくは
変更できませんが今なら自由に変更できますので、良いアイデアがあれば積極的に
取り入れていきます。自分としては匿名性がFreenetのように確保されてて
MX並に軽快で使いやすいのが理想なんででそれ目指して作っているだけです。
- 117 名前：47 投稿日：02/04/16 15:18 ID:mPL0z40j main/1018434705.html#553
- Winnyはぶっちゃけたこと言えば、必ず串経由でMX使って
ファイルは自分で全部暗号化してファイル名を適当なルールつけて
そのままじゃ中身が分かり難くしてやり取りするという文化が広まれば
今のMXそのまま使えばいいんですけど、そうはならんだろうから
それを目指した専用ツールを作ろうってことですね。
- 118 名前：47 投稿日：02/04/16 15:40 ID:mPL0z40j main/1018434705.html#557
- >>545
> 暗号化キャッシュに入ったファイルは消えないそうだが、
> それだとネットワークの負担は増える一方ではないかね?
逆です。DOM前提のシステムではどうやってもネットワーク
負荷が上がるのは避けられませんが、キャッシュシステムで
ネットワーク負荷をストレージ負荷に変換して対処しようと言うのが
本システムの方針です。Freenetも同じことになりますが、あれはやりすぎかと。
キャッシュを全部消したらどうなるかですが、
オリジナルファイルをUPフィルダに置いている人はいるわけですから、
今のMXで串さして使っているのと同じです。キャッシュを全部消しても元のファイルは
消えません。ただし前に書いた理由によりネットワーク帯域がパンクします。
ネットワーク負荷よりディスク負荷を選ぶ人はキャッシュを大きめにとって対処するでしょう。
あと大きなファイルの扱いですが、今の設計ではどんなに大きな
ファイルでも分割しません。大きなファイルはキャッシュでも大きな
ファイルになります。これはFreenetのようにチャンクに分割しても
ロストしやすいだけという判断で、大きなファイルはユーザーの責任で分割するのが
もっとも効率がよいとの判断です。小さなファイルについても同じでユーザーさんの判断で
流通させやすい手ごろな大きさにアーカイブ化するでしょう。MXでの現状と同じです。
あとファイルの分布のシミュレーションは余裕がなくてまだやってません。
一応公開前にやる予定です。
>>540
> てっきり、freenetみたいなキャッシュファイル内に
> 保存されてるんだと思ってた。
今の設計ですとキャッシュ内のファイルは元のファイルにヘッダ付けて
暗号化しただけなので大きなファイルは大きなキャッシュファイルになります。
Freenetのように専用のストレージメカニズムを作ることも考えましたが、
効率よく作られているOSのファイルシステムを使ったほうが効率と自由度が高いだろうとの
判断です。これならNTの豊富なファイルシステム関連の機能使えますしね。
問題になるとしたら匿名性が下がること
（暗号を解除しないでも元のファイルの大きさが推測できる）ですが、
このシステムの場合、流通するファイルは基本的にアーカイブファイルに
なり、圧縮手法により大きさが変わるので単純に大きさだけでは
その中身を推測できないだろうからファイルの大きさを偽造しても
あまり意味がないだろうとの判断でこうなってます。
>>554
まだ直してませんけど空の場合も暗号化する予定です。
しないことのメリットがいまいち思いつきませんので。
- 119 名前：47 投稿日：02/04/16 16:11 ID:mPL0z40j main/1018434705.html#559
- >>558
外にパケットが出ない検索機能というのは確かに必要そうですね。
忘れなければ付けます。こちらはそろそろToDOリストが要るかもしれず。
- 120 名前：47 投稿日：02/04/16 19:16 ID:GNkdq+pR main/1018434705.html#570
- >>560
>つまり、キャッシュ用のディレクトリを指定しとくと、ヘッダ付の暗号化ファイルがどんどん
>そこに増えていくってことでしょうか？
そうです
> キャッシュしたい容量の上限てどうやって制限するんでしょうか？
まだ作ってませんが、設定でキャッシュフォルダの上限を指定しておいて、
これを超えたら古いファイルから消していくという動作になる予定です。
> てことは、クォータで管理？
クォータ使うのは自由ですがそれを仮定してるわけではないです
> ９ｘ系ＯＳはWinny使えないのかな？
使えますが安定性の点からNT系OS推奨です。対応OSは95/98/ME/NT4/2K/XPかと。
キャッシュファイルの問題は565氏が答えてくださっているので省略。
>>564
>暗号鍵の登録・保存はできるのでしょうか？
共有フォルダの暗号の方はもちろん保存されますが
検索側はまだ保存してません。あとでそのようにしましょう。
- 121 名前：47 投稿日：02/04/16 19:16 ID:GNkdq+pR main/1018434705.html#571
- >>566
> 複数の人間が、同じキーを設定したULフォルダの中に、
> 同じ名前、同じサイズ、同じCRCという、完全に同一なファイルを入れた場合、
> それらのファイルの扱いはどのようになりますか？
実はそこは今現在設計中で動作が確定していません。
内部的にはダウン可能な全てのキーが検索で判明しているのですが、
ユーザの方に見えるキーはシステム側でダウン対象として最もよさげと判断したキーだけです。
ユーザーさんに選ばせるのも手ですが、MXと違い見れる相手の情報が少ないので、
基本的にどのファイルを落としにいくかはシステムまかせで、キャンセルすると
第二候補をダウンしにいくようにしようかと思ってます。
あと今の実装では、ファイル名は検索に使っているだけで、同じファイルかどうかの
判定は全てハッシュに頼っています。ハッシュはファイル内容から生成したキーで、
同じファイル内容なら同じハッシュ値になります。あるキャッシュがどのファイルのキャッシュ
か判断できないとまずいのでこのシステムではハッシュは必須です。アルゴリズムはMD5。
ただこの辺もいろいろ問題があって、本来でしたらファイル全部の内容から
ハッシュ値を求めるべきですが、これをやってしまうとG単位の大きさの
ファイルのハッシュを求めるのにファイル全部をサーチする必要があり
すごい時間がかかってしまうので、今は頭のほうだけ見てたりします。
どうせ暗号化する際にファイル全部にアクセスするのでハッシュ値決定のタイミングを
遅らせればよいだけですが、この辺はレジュームとの兼ね合いもあるので
詳細がまだ決定していません。
とりあえず暗号化のキーが違うと別ファイルになる（予定）です。
ファイル名が違ってハッシュが同じ場合の扱いはまだ決まってませんが、
これも別ファイル扱いにすると思います。MXでは中身が無くてファイル名だけのファイルが
意味を持ったりして、同じことが発生する可能性があるのでこうする予定です。
あと、
> 同名、同サイズでも、内容が違うファイルが、 同じ暗号キーでULされたときの扱いは、
> どうなるんでしょうか？
内容が違えばハッシュ値が別になりますので、完全に別ファイル扱いになります。
これは確定事項です。
- 122 名前：47 投稿日：02/04/16 19:21 ID:GNkdq+pR main/1018434705.html#572
- ああ、あとちゃんと答えてませんでしたが
> 複数の人間が、同じキーを設定したULフォルダの中に、
> 同じ名前、同じサイズ、同じCRCという、完全に同一なファイルを入れた場合、
> それらのファイルの扱いはどのようになりますか？
これだと全部同じファイル扱いになります。キャッシュに関してもそうです。
名前、キー、サイズ、ハッシュが全て同じなら同じファイルとみなします。
あとキャッシュファイルだとヘッダにこれらの情報の一部が含まれますが、
サイズとリアルサイズが別の場合、レジューム中扱いにする（と思う）。
- 123 名前：47 投稿日：02/04/16 19:41 ID:GNkdq+pR main/1018434705.html#575
- うん、そろそろ既出の一言で終わるようなことばかりになってきましたね。
本体の実装をとっとと終了させまでネタないでしょう。
といっても、システム出来上がる前に致命的な問題点が
指摘されれば助かるので、これやばいんでは？という意見は大歓迎です。
- 124 名前：47 投稿日：02/04/16 19:44 ID:GNkdq+pR main/1018434705.html#577
- >>574
検索画面では2つのファイルが、 同じファイルネームであるにもかかわらず、
別ファイルとして並存する、 という理解でいいですか？
そうなります。MXみたい。
> それと、ハッシュの表示は検索画面上で出てくるのでしょうか？
今は見えてます。開発途中のバージョンなんで内部的な情報など
全部だしてますんで接続ホストのIpやportまでだだもれです。
どこまで出すかわかりませんが、公開版ではハッシュ（実体は16バイトのデータ列です）は
キーのプロパティという形で見れるようにすると思います。
これないとBBSで問題のあるファイル情報が出せませんので。
- 125 名前：47 投稿日：02/04/16 19:46 ID:GNkdq+pR main/1018434705.html#578
- >>576
帯域制限は実装はできてますが、ちゃんと動作させるのがなかなか難しく
まだテスト中です。もちろんつける予定です。この辺は既出。
- 126 名前：47 投稿日：02/04/17 05:03 ID:7CggBtuR main/1018434705.html#660
- なんか盛り上がってるすね。まだちゃんと読んでないんですけど
捏造対策についてはこうなる予定です。
ハッシュが先頭部分しか見てないことに関して。これは現状こうなっているだけなんで、
最終的にはファイル全部からハッシュを生成してチェックすることになると思います。
実装詳細になってしまうのでほんとは説明したくなかったのですが、現在の案はこうなってます。
ハッシュを二つ以上（先頭などのブロックハッシュとファイル全体のハッシュ）用意し、
検索では先頭のみのハッシュで行い、UPフォルダ内からキャッシュフォルダへの変換が
始まった時点で、暗号化と同時に全体ハッシュを生成します。これをキャッシュヘッダに
付けておき、転送時、もしくはダウン時にハッシュを求めて、全体ハッシュと合うかどうか
調べ壊れているファイルを検出します。
この方式ですと、検索時では一部分を偽造したファイルをはじけませんが、
ダウン時には全体の１バイトでも変更するとそれを検出できます。
実はレジュームの実装が遅れているのはここらへんの設計の辛みなんですが、
ブロック単位でハッシュを求めて変な部分が出たらそこだけ切り離して他から
部分読みできるようにしようかと思ってます。ファイルはブロック化しないけど
ハッシュはブロック化するということです。
- 127 名前：47 投稿日：02/04/17 05:08 ID:7CggBtuR main/1018434705.html#661
- 良く考えたら、UPフォルダからキャッシュ変換時にその変換終わらないうちに
転送作業が並行で走ってしまうので、全体ハッシュはヘッダじゃなくて最後に
つくかな。ブロックハッシュはそのブロック毎につくことになるのでしょう。
- 128 名前：47 投稿日：02/04/17 05:30 ID:7CggBtuR main/1018434705.html#664
- スペックは普通のPCで問題ないと思いますが・・・
私のPCはクロック1GHzですが、クライアント１０個程度の同時稼動でも
問題なく動いてますよ。
まー、まだ作っている最中なんでバグっていてパケットの無限ループが発生すると
がりがりとメモリ確保初めてマシンが固まったりしますけど(^^;これはバグなんで
公開版では発生しないはず。
- 129 名前：47 投稿日：02/04/17 13:34 ID:hBCWcQKF main/1018434705.html#691
- 新規機能追加はひとまず置いといて基本機能が確実に動くようにバグフィックス中です。
ファイルダウンもほぼ問題なく動くようになってきましたが、まだ接続状況によっては
一部のファイル見えなくて一度再接続しないとだめだったり、ダウンが始まらなくて
タイムアウトしてたりします。暇見て地道にデバッガで追跡中。
新しいファイル共有ソフトとしての肝はこれから先の実装にあるんですが、
とりあえず基本部分がバグってるとどうしようもないんで完全にしとかないと。
- 130 名前：47 投稿日：02/04/17 14:21 ID:S2CkPUFG main/1018434705.html#693
- 微妙なところを突いてきて答えにくい質問が増えてきてますが
>>666
新規ファイルの信憑性はMXと同じで落してみないとわからないということになるでしょう。
すでにどのファイルがどの程度重複してキャッシュされているのか知ることができるように
なっていますので信憑性の指標としてはこれを表示するのも一つの手かと思っています。
>>668
> ブロック単位でハッシュ求めれるなら、マルチソースダウンロードと
> 非対称UL/DLの再考を・・・！
対応は現時点でそれほど面倒ではないのですが、今の方針では落すファイルの選択だけが
ユーザー任せで、どうやってダウンするかはシステム側でチューニングして最適だと
思われるのを自動で選ぶことになるかと思います。
だからあまりユーザー側で指示できることがなく、同時にいくつダウンしにいくかも
ユーザーの方からは制御できなくなる可能性が高いですね。
あとこの制御パラメーターにどれだけUPに貢献しているのか
などの優先度入れようかなぁとか、まぁまだこの辺は考案中です。
なんでもありにしてしまうとこのシステムの場合全体としてうまく動かないと思うし
システムがクローズ（プログラムソースもプロトコルも非公開）なのを利用して
変なことはリバースエンジニアリングしないとできないようにする方向性が
このプログラムの場合、合うだろうなぁとは考えてます。
>>681
>あと良く解んないのが、現状のwinny場合、検索して転送要求したら目的のファ
>イルが初めに見つかったノードから転送させるの？
今の予定では、キャッシュを持っている一つ上流の人が転送相手の第一候補に
なりやすいと考えていますが、回線空き状況によって他に切り替える動作などは
間違いなくやるでしょう。
上にも書きましたが、この辺はかなり自動で制御することになると思います。
ちなみに現状では、完全手動で周辺ノードでキャッシュ持っているホストが
全部見えますので好きなところからダウンできます。
>>690
> 「転送数が多くなったときの転送効率」が気になります。
これはそもそも１ノード内では同時転送数が多くならない方向で制御するかと思います。
ネットワーク上のノード全体の協力で帯域を使い切る方向性になるでしょう。
よって、相手が接続不能な場合、お互いに協力して他のノードを紹介しあうという動作になります。
既に現時点の実装で、接続の最適化のために周辺ノード状況を他のノードに伝達しています。
MXより早くなる可能性というのは、1対1で無秩序にやり取りするのではなく、
もっと早い回線者を考慮してそちらを利用して効率よくダウンできる可能性が
あるからということです。もちろんこれには地道なシステムチューニングが必要ですが、
こつこつやります。これの肝になるのは実は本体ではなくシミュレーターでしょう。
- 131 名前：47 投稿日：02/04/17 15:02 ID:CcyCRFGu main/1018434705.html#694
- 今わかっている各レイヤでの通信状況ですが、てっきり一番上の光やT3が過密で
HDDを大量に消費するかと思ってましたが、検証の結果そうはならないようです。
ファイル本体を保持してそれを末端に分配する主体は高速ADSLやケーブルの方々になります。
このレイヤは速度は遅くてもノード数が多く、トータルでは最も能力を持つのでこうなります。
ただしこれは比較的大きくてお約束のファイルに限った話であって、珍しいファイル（あまり
キャッシィングされないファイル）はレイヤに限らず広く分布することになります。
キャッシュからは直ぐに消えるので低レイヤからの直接UPで提供となるでしょう。
大きくて珍しいファイルは手に入れるのが比較的難しくなりそうです。
あとそうなると最上流のノード群（光やT3）が何をしているのかですが、
ファイル本体ではなく、検索のキーを溜め込んで検索の中心ノードとして働くことになります。
上流ノードが相互接続された網を作って主にそこでキーの検索を担当し、
その他のノードはそれに木構造でぶら下がる感じになります。二層目の
比較的高速なレイヤも網構造を持って大量のショートカット回線網を作ります。
低速ADSL以下は単にぶら下がるだけでUP回線はあまり使いません
キャッシュから消えやすいファイルの保持担当となります。
検索は基本的に最上流の網まで到達してそこでぐるぐると回って処理してもらうことになり、
比較的ありがちなファイルは高速ADSL・ケーブルからなるストレージ層から検索結果を
参照してよさげなところに接続して落してくるということになります。
ですので、光と高速ADSL/ケーブルの方々はそれなりにHDDが必要
（ただ、とんでもない容量がいるわけではない）で、光の方はCPUとメモリが
あったほうが良いということになると思います。
- 132 名前：47 投稿日：02/04/18 08:11 ID:HZiihsE7 main/1018434705.html#737
- 特定ノードに接続が集中したときにまだfailすることがあるようですが、
そろそろ次行こうということで、通信の暗号化やUIの変更などやってました。
リストコントロールでヘッダークリックしたときにソート対象が切り替わらない
などのお約束を守ってないのでこの辺とか。
あと通信の暗号化ですが、メモリ内容の暗号化ルーチンはすでにできてましたし、
通信内容は手動で受信と送信バッファに一度溜め込んでいるので
凄い簡単に作れました。
実際の通信時にはぶちぶちとパケットに分割されますし、
使っている暗号もリアルタイムで解析できるような簡単な暗号ではないので、
パケットアナライズでの解析はまず無理です。ファイル名とその内容は
キャッシュに入る際にも暗号化されているので二重に暗号化されてます。
これで解析かけるとしたら間違いなくリバースエンジニアリングしかないですが、
ソース公開しないし、各ノードで連動して動くから一部ノードだけ見張っても
何もわからんです。私にも解析プログラム作れないはず。
ソース公開していても問題ないという、匿名性実現に特化したfreenetには負けるでしょうが、
結局、法律的には、キャッシュ機能を持つプロクシと同じ扱いで、
これ以上のことをやってもパフォーマンスが落ちるだけでしょう。
さて、次はキャッシュシステム周りの管理機能強化（キャッシュ消去など）と
レジュームですか。そろそろ基本実装は終わりで細かいチューニングと
バグ取りに入ることになります。あと帯域制限などのおまけだけど重要な
機能の検討と実装でしょう。
- 133 名前：47 投稿日：02/04/18 08:23 ID:PyC3Mv/l main/1018434705.html#738
- えーと、法的な部分は詳しくないので検討は皆さんに任せですが、
扱いとしてはキャッシュ機能つきのプロクシの法的扱いと同じかと思います。
キャッシュの中身は動的に変わっていくので（しょせんキャッシュ）
無断放送というのともまた違うと思いますし。
>>704
>完成予定はいつごろになるんですかね？
全力でやれば今月中にできあがると思いますが、あまり
仕事手抜きしているのもまずいんで雑用の発生具合によりますね。
来月までは比較的暇なはずなんでどうにかなるとは思いますが。
とりあえず基本的なところは既に作り終わっていて、あとは細かい
それほど作るのが大変でない部分の作りこみと、チューニングです。
このチューニングの方が問題でちゃんと動くものにするには
シミュレータ方まで良く作りこんで検討しないとまずいです。
このスレの議論が役に立ちますが、最終的には私の判断に
なりますので時間かけて問題ないと判断したらβ公開します。
慌てるとろくなことがないので慎重にやります。
- 134 名前：47 投稿日：02/04/18 08:55 ID:lk7slWFF main/1018434705.html#739
- >>733
> キャッシュのαに対しアクセスカウントを与え、以後コレをαの評価値として保持しておくようにするんです。
これはやろうかと思っています。ただ、信頼性のあるキャッシュを増やすためですが。
> アクセスカウントの多い、つまり人気の物を優先して、帯域が空いたときにでも、
> 自分の上位ノードへと、転送するというのはどうでしょう？
これも結果的にそうなる（わざわざ転送するまでも無く、同じファイルに二度リクエストが
あると一つ上に届きやすい）と思われるので人気のあるファイルは勝手に広まっていきますが
動作として転送ということにはならないです。つまり、キャッシュは消しません。
UP側の責任はみんなで分担ということになるでしょう。
733氏はダウン側の責任を心配しているのでしょうが、このシステムでは
「ダウンかけた人に全ての責任が発生する」と思われます。
ただそれをネット内で見つけ出すのが難しいので、
怪しそうな人の自室に忍び込んで実際にダウン、解答、使用したところを
現行犯で見れて、初めてたいーほでしょう。
囮やろうとしても自分が違法行為をするだけなんで、囮捜査が禁じられた日本では
使用自身ができないし、囮捜査を許したとしても捕まえられるのは捜査員だけ。
法改正するとしたら、こういうソフトウェアの開発、公開それ自身を禁じるしかないと思います。
私がやらんでも誰か他の方がやるだろうし、そろそろデジタルデータ著作権に対する考えを
見直す時代になりつつあるということでしょうね。
- 135 名前：47 投稿日：02/04/18 21:17 ID:IH5wLXVI main/1018434705.html#782
- どうにかダウンロード部分の挙動がバグ取れて落ち着いてきたので、
ハッシュ周りを作り直しました。
あまり細かいことを書きだすと解析され易くなるだけなので詳細は省略しますが、
キャッシュ内部的には適当な大きさでブロックに分割してそれぞれにハッシュを持たせて、
ファイルのどこの１ビットでもエラーがあるとブロック単位でそれを検出できるようにしてあります。
ブロック単位でのエラー検出だけで、冗長な情報入れてエラー補正まではしませんが、
ブロック単位でエラー検出さえできればそこだけ再ダウンすればいいだけなので、
一部分だけ壊れていてもその部分だけ自動的に修復できます。
レジューム機能はこれからですが、システムの扱いとしてはレジュームというより
単に後ろ半分が壊れてるファイルを修復するだけとなります。
ハッシュ機構とはまた別にキャッシュファイル全個所暗号化されていますし、
通信時はそれにまた暗号化かかりますんですんごいことになってます。
そのわりにはそれほど速度も落ちないですんでますし。
実は、リソースロック絡みでデッドロック避けられなさそうなのと、効率悪そうって理由で
OSのスレッド機能使わずに全部自前でタスクスケジューリングしてたりもするので、
技術的にはそれなりに凄いものになりつつありますね。
- 136 名前：47 投稿日：02/04/18 21:24 ID:IH5wLXVI main/1018434705.html#783
- 法律絡みは良くわからんので省略。
>>761
うーん、よくわかんないですけどそういう特殊な機能はつけないでしょう。
拡張子は全部無視する（あっても無くても挙動はまったく変わらない）と思います。
>>762
正規表現は良いアイデアですし作るのもライブラリ拾ってくれば簡単ですが、
実装上ちょっとまずいかなぁ・・・・。理由は776がいいとこ突いているので
あまり書きませんが、やんない可能性高いのではないかと。
- 137 名前：47 投稿日：02/04/19 10:46 ID:o6XsurCM main/1018434705.html#852
- 545氏の意見は参考になるといえば参考になります。
今はまだアタックに耐えられるようにする以前なんで、
メカニズム分かっている人が慎重に使えばどうにか
ファイル交換できるかもというレベルですが、公開時には
考えられる全てのアタックに絶えられるようにしなければなりません。
もちろんそのために暗号化やキャッシュなどを採用しているわけですが、
ごみUPの問題は避けて通れません。しつこくゴミをUPは
無駄に検索を連続させて負荷を上げるのと並んで
このシステムに対する効果的な嫌がらせになります。
これに対する現状で考えている策は既に書いたように
ダウン率によってそのファイルの信頼度を表すなどの方法でして、
実装するとしたらキャッシュヘッダに参照回数を書き込んでおく
（つまり、なんどもreqを受けたキャッシュファイルの優先度が上がっていく）
になりますが、二つのマシンで地道にやり取りしていれば
ごみファイルでも優先度が上がっていきます。
実はこのようなモデルは２ｃｈではお馴染み。例のage, sageシステムと
同じだったりします。人気が無いつまらないファイルは優先順位が下がって
いって自動的に消えると言うわけです。ある程度の嵐にはこれだけで
耐えられますが、だからといって自作自演はありうるわけで、
単独犯ならキーで防げますが、複数犯による犯行だと防御が難しいです。
複数犯も結局は数で勝負で、2chでもまともな議論している人が大多数であれば
自動的に厨房は消える同様のメカニズムで防げますが、厨房ばかりになると板丸ごと
腐ってしまうのもお約束。なんでも自由と言うのはその制御が難しいです。
あと作者の法的責任に関しては、情報公開を要請されるとか公開停止程度の
勧告はありえますが、逮捕というのはまずありえないだろうと考えています。
それに別に商売でやるわけではないですし、ソフトだけでサーバー込みの
サービスではないのでフリーソフトとして公開して奇跡的にそれがうまく
動いてしまうと作者が止めようと思っても止められなくなる可能性もあります。
基本アイデアはここで公開してしまっているので、
私以外の人が実装でもいいわけですし。
- 138 名前：47 投稿日：02/04/19 14:02 ID:o6XsurCM main/1018434705.html#856
- 打ち合わせの多い今日この頃であった。
>>847
うう、話が良くわかんない(^^;
とりあえず、ハッシュ値指定で検索無しでの直接ダウン
（もちろんどこから落とすかはシステム任せですが）
というのはあったほうが良いかもしれません。
２ｃｈなんかでこんなファイルUPしたよというときに偽造を防ぐために
キーと暗号化キーで示すと言うのは意味ありますし、
作るの簡単なんでやってもいいかも。
あと、ダウンロードリストに関しては、どちらにせよMXでのローカルキューの
ようなものを作りますが、そこの追加インターフェイスを外部にもっていくのが
めんどいので起動時の引数で特定のキーファイルをダウンできるようにとかかな。
Winny.exe -k @keyほにゃらら -h @hashほにゃらら
これなら好きなスクリプト(batでもいいし)からWinny起動して落とせばいいだろうし。
>>850
> GUIとコアを分けて、コアはDLLにする。そして暗号化。
これに近くなるけどあまりモジュール化したくないんで、
上と絡めて擬似コマンドラインモードって感じですかね。
GUI切り離すのは簡単だけどどうせソース公開しないと思う。
- 139 名前：47 投稿日：02/04/19 18:05 ID:o6XsurCM main/1018434705.html#867
- >>865
今現在多重起動できるのはテスト用に擬似的にノードを増やしたいからであって、
公開版は間違いなく同時起動が不可能になります。それどころかルータの内側で
クライアントが複数起動していたらうまく動かないと思われ
（末端ノードでなければ外部からTCP接続かかる）。
あともし外部プログラムとのやりとりやるとしたらどうしますかねぇ。
ローカルキュー機能つけるだろうから、手抜きしてこれに対して
ファイルやクリップボード経由のIN・OUT機能つけるのがいちばん簡単だけど、
前出てきてたような自動ダウンの類はこれではできませんね。
基本的に変なツールに改造されるのがいやなんで、
システム的にはクローズドな方向に行くはずですが。
>>866
検索ネットワークでの親に出します。
ありかは親が見つけて転送してくれるはず。
- 140 名前：47 投稿日：02/04/19 18:18 ID:o6XsurCM main/1018434705.html#868
- ちなみにファイル名情報はファイルの検索にしか使いません。
ダウンは全てハッシュキーに対して行います。
この辺りはFreenetと同じだと思います。
ただし、ファイル名は知らないでも問題ないですが、暗号キーは知らないと、
落としてもキャッシュから元のファイルに戻せません。
- 141 名前：47 投稿日：02/04/20 01:58 ID:P6rE5sQJ main/1019230372.html#69
- いつのまにか新スレすね。
やっとレジューム機能（つーか壊れている部分のみの後読み込み）できました。
単なるレジュームじゃなくてブロック単位でハッシュの整合性取れない部分のみを
検出してそこだけ転送しますし、一つのファイルに対して同時読み可能なので
ほとんどeDonkyと同じ処理が可能です。ただ実際に複数ダウンなど
やるかどうかなどはまだ未定ですが。
というよりお約束でまだレジューム周辺のバグがとり切れてません。
レジューム機能は問題ないですがダウン中の表示周りが変です。
良く探すとバグ山盛りでしょうけど、もう眠いんで寝ます〜。
- 142 名前：47 投稿日：02/04/20 20:51 ID:HPTPz/Zd main/1019230372.html#106
- 都合により携帯の電波しか届かないところにいるので
今日明日は反応できませぬ。よろしく。
- 143 名前：47 投稿日：02/04/21 23:46 ID:aq89ZaGM main/1019230372.html#179
- 無事自宅に帰ってきました。といっても、出先にノート持っていって
暇な時に作っていたのでそれなりに開発すすんでます。
動作が怪しかったレジューム周辺も直しましたし、同時接続が増えてくると接続failする
ことがあったのも理由わかって直しましたし、転送動作も問題なく動作しますし、
どうにか基本機能が全て安定して動作するようになってきました。
後実装で残っているのは、キャッシュフォルダの容量制限とか帯域制限、
ダウンするキャッシュを決定する部分やUIの見直しなどの、
このスレで話に出ていたような細かい部分のみです。
プログラムソース的な完成度で言うと８割程度の完成度と思われますが、
基本部分はそろそろ完成なので、Winnyもついにαバージョンに突入です。
ネットワーク負荷がどうなるかなどのチェックがまだなんで、シミュレーターの方を強化して
大規模になるとどうなるか検証とか、処理負荷が上がってきてもトラブらないかとか、
回線速度が極端に速い場合と逆に回線が遅い場合に問題にならないかとか、
パフォーマンスは充分か、それぞれ最適にチューニングなど、やることはまだまだ
たくさんあります。勝手にキャッシュが消された、書き換わったとか、通信がカットされた
などの例外処理関連でも山のように怪しい部分があるでしょう。
あとユーザインターフェイス周りがほったらかしだったので、こちらも作りこまないとだめだし。
とりあえずチューニングとテスト段階に入ったんで全体工程の残り1/3ってところです。
一般公開可能なβ版があがるまではまだ１，２週間程度はかかると思いますので
気長にお待ちください。
- 144 名前：47 投稿日：02/04/22 00:07 ID:TqoqJECp main/1019230372.html#182
- 一部質問に答えてなかったので意味がありそうなものに答えます。
その３にはなさそうなんで全部前スレです。
>>872
>バグが見つかったりしたらまたバージョンを上げていくつもりですか？
そりゃそうです。バグはどうしても残るでしょうからそのつど対応します。
前書いたと思いますが、バージョン上げたくないのはプロトコルなどの
基本的な部分です。
もちろんバージョンチェックするようにはしてありますが、これをやり始めると
単に二つのプログラムを一つにしてるのと変わらなくなってバージョン間の
マッチングの方が面倒になってしまうのがお約束です。極力避けたいです。
こうなるとたいてい、前バージョン廃棄して別のアプリにしたほうが早いし。
>>875
>ポートでの振り分けは可能なんですよね？
可能です。
あと、NAT対策も既に終わってます。外部からポート接続を受けるのが無理な環境でも
問題なく使用できます。特に制限はありません。
> あと外部（親？）にアナウンスするアドレスもDNSで指定可能
> なんですよね？
既出かな。今はまだ対応してませんが対応予定です。
- 145 名前：47 投稿日：02/04/22 00:08 ID:TqoqJECp main/1019230372.html#183
- >>181
Freenetには問題が多いので、もっと良いものを目指しています。
- 146 名前：47 投稿日：02/04/22 00:59 ID:TqoqJECp main/1019230372.html#190
- >>189
ダウン部作り直して汎用的にしたので、同時ダウンは既に可能になってます。
同時UPも可能です。転送動作はダウンしながらアップしてるだけですし、
キャッシュが無かったらUPファイルをキャッシュにコンバートしながらUPすると
各動作が並列動作するのがシステムの特徴です。
ただ、実際に複数ダウンかけるかどうかは今後の調節によるので、
まだどうなるかは確定していません。
- 147 名前：47 投稿日：02/04/22 09:46 ID:Wi5epVhT main/1019230372.html#221
- 現状でのDOMやキャッシュレス対策には以下を予定しています。
まずキャッシュファイルには個別にそれがUPされた回数を記憶します。
もちろんこれには暗号化とハッシュによるプロテクトがかかってます。
人気のあるファイルほどこれのカウントが上がっていきます。
そして、ノードの貢献度の評価値として、キャッシュフォルダ内のこの
値の総和（もしくは適当な関数で変換）とします。
基本的に手元にUP要求がかかり易いキャッシュを持っているほど
ノードの優先度が上がって他からダウンしやすくなります。
これによりどのようなことになるかですが、まず回線が太い場合、
キャッシュさえ大きめにとってそれを外部に開放しておくだけで、
転送動作により自動的に人気のあるファイルがキャッシュに溜まってくるので、
放っておくだけでノードの優先度が上がって他からさくさくダウンできるようになります。
ただし、回線が太いのにキャッシュを充分確保していないと、転送によりUP以外に
DOWN帯域もつぶされてしまうので、DOWNが困難になります。
もし外部から接続不可能な設定（NATが挟まっている）にした場合、
もしくは、回線が細いと申告した場合、転送を請け負うことがありませんので、
自動的にキャッシュにファイルが溜まることはありません。
もしキャッシュにファイルが少なければ他からファイルをDOWNするのが困難になります。
特に大きなファイルほど、優先度が高い人に転送を割り込まれるので
ファイルが落ちてきません。
よって、自分で何かファイルを用意してUPフォルダに入れておくか、
他からがんばってDOMして人気のあるキャッシュファイルを盗んでくることになります。
この場合、常にネットワークの末端にいて、他で良くキャッシュされているファイルを
持っていてもダウン要求がまず来ません。
なので、珍しいけどヒットを期待できるファイルを持っている必要があります。
- 148 名前：47 投稿日：02/04/22 09:59 ID:Wi5epVhT main/1019230372.html#222
- ちなみに、NATかましていてポート接続不可能な状況でも
ファイルを他にUPできます。このシステムの場合、必ず他のノードが
挟まるので、他からDOWN接続可能なノードに親になってもらうだけです。
外部から接続不可能なノードのファイルは、隣のノードを中継して
外部に出て行きます。できないのは、中継動作だけとなります。
- 149 名前：47 投稿日：02/04/22 10:18 ID:Wi5epVhT main/1019230372.html#223
- >>214
ハッシュは MD5 みたいにビット数が多いやつです。
キャッシュファイルはブロック単位のハッシュとファイル全体のハッシュを持ってます。
- 150 名前：47 投稿日：02/04/22 13:12 ID:x1evc6ZD main/1019230372.html#225
- 常時アドレスでもDHCP経由でもらったIPでも、特に違いは無くて、
違いが出るのは初期接続が楽かどうかだと思いますが、
長時間接続の方が接続が綺麗に自己組織化されるので、
キャッシュに興味の無いゴミが溜まる率が減ると思います。
ファイル要求をかけたり受けたりすると、検索ネットの方にも
その影響が残るので次もそのお互いに興味が持っている
ファイル間のホストでの直接やり取りする率が増えますが、
いちいちIP変わってたらそれがクリアされてやり直しになってしまいます。
- 151 名前：47 投稿日：02/04/22 13:18 ID:x1evc6ZD main/1019230372.html#226
- 現状で頭痛いのはプログラムクラック対策でしょうか。
キャッシュが暗号化されていてもさすがにプログラム内では復号して扱うわけで
デバッガでメモリ追跡してワーク領域を直接書き換えれば、
キャッシュの優先度などを不正に書き換えるのもそんなに難しくないです。
一応対策取りますけど完全には防げないでしょう。
- 152 名前：47 投稿日：02/04/22 15:46 ID:j1LjiuL3 main/1019230372.html#234
- とりあえず、キャッシュに優先度の機能がつきました。
面倒な部分は終わっているのでこの程度なら作るの簡単です。
次はキャッシュヘッダ変更のついでにキャッシュ削除機能でもやるかな。
あと、アイコンはどうしますかね？何でもいいんですけど。
>>228
>DDNSなどでこれを回避するようにできますか？
今は回避できませんが、できるようにしましょう。
接続したときにポート番号や回線速度などのホスト情報が
流れますが、ここにDNSでホスト名流すだけなんで対応は簡単です。
>>229
>MP3でのビットレートの表示
これはやらないです。拡張子も無視しますし転送されるファイルの種類は全て無視です。
ユーザー各位でファイル名工夫するなり暗号キーを応用するなりとなります。
> (ユーザーのリストを見ることができれば)フルパスでの表示
ユーザーのリストは見えません。どうするか悩みましたが、最終的に
ホスト情報の類はまったく参照不能になると思います。
もちろんTCPで繋いでいる関係で、隣のホストのIPはnetstatで見れちゃいますが、
これはFreenetでも同じだし。
あとUPフォルダの位置でしたら標準でフルパス指示です。
ただしMXと違い、UPフォルダ内部のフォルダは無視されます。
> 中途半端なファイルの本来のファイルサイズとか、
> ダウンロードを再開するために必要な情報を見れると便利ではないかと
ファイルはダウン最中や未ダウンのファイルでも全て本来のサイズのファイルとして扱われます。
実際のサイズとしては、どの程度のブロックがダウン終わったか程度の情報しか見れません。
キャッシュに入ってるといろいろ情報が増えてるんで本来のファイルと大きさ違いますし。
あとダウンロード再開は基本的に自動でレジュームの類は必要に応じて必要なところから
自動的に処理されます。レジュームに限らずダウンロードも自動です。
ユーザが指示できるのはダウンするリスト一覧だけになります。落とし方はシステム任せです。
UPの方は、そもそも何がUPされているのかもわかりません。
今はファイル単位ではなく、それを分割したチャンクとして転送されていくので
表示しても意味不明ですし、そもそも暗号化されているのでなんだかわかりません。
UP側で表示される情報は転送レートぐらいになると思います。
>>232
>ということはポート接続ができないとダウンアップはできるが、キャッシュは溜まらないということでしょうか？
自分のUPフォルダ内から変換されたファイルや、自分で他からダウンしたファイルのキャッシュは
残ります。転送依頼を受けつけないので、結果的に自動でキャッシュが変更されることはないです。
- 153 名前：47 投稿日：02/04/22 15:50 ID:j1LjiuL3 main/1019230372.html#235
- ちとわかり難かったですね。
>>232
結局、NAT経由でも問題なくUP/DOWNが可能です。
正し、ポート開放している人よりダウンしにくくなるでしょう。
- 154 名前：47 投稿日：02/04/22 18:37 ID:PFA6vWNI main/1019230372.html#253
- キャッシュの容量制限できましたー。
あとDNSも普通に引くようにしときました。この辺はすげー簡単。
実装が残っているので大物はあとダウンファイルの選択部ぐらいですが、
これはシミュレーターを大幅にバージョンアップさせないとだめですねぇ。
こんどはこっちをやろう。
- 155 名前：47 投稿日：02/04/22 19:07 ID:PFA6vWNI main/1019230372.html#258
- >>255
> 自分で持ってるファイルがＵＰされる場合、一旦自身のキャッシュに
> (暗号化後)格納されてから出ていくと理解してますが、
その理解であってます
> 両方手元にあると暗号をクラックする側にとっては助かるのではないでしょうか？
楽ですが、私だったらキャッシュの直接解析は諦めてプログラムの方をデバッガで
追いかけて暗号化ルーチンだけ抜き出します。こっちのが絶対楽ですし、
暗号それ自身はそんな簡単に破られるものでもないです。
exeは必ず公開されるわけで、暗号・復号ルーチンが必ず含まれますし。
それを見越してこちらも対策取りますが、完全に防御するのは正直無理でしょうねぇ。
Windows以前のゲームで良くやったように自己書き換えまでやれば
かなり解析が面倒な嫌がらせになりますが、あまり凝るとバグの元や
パフォーマンス低下になるし、その前にバグを取りきらんと。
> あと、新しいＰＣを買ったとかいう際に、キャッシュコピーで優先度も
> 引継がれたりするのでしょうか？
引き継がれます。始めは認証ファイルでも作ってそちらに優先度など
入れようかと思いましたが、キャッシュがそれなりに暗号化されてるし
偽造が困難（キャッシュファイルの容量それ自身が不正コピー防止になる）んで
優先度はキャッシュからのみ決定することにしました。
だから、キャッシュを丸ごとコピーすればノードの優先度も引き継がれます。
- 156 名前：47 投稿日：02/04/22 19:09 ID:PFA6vWNI main/1019230372.html#259
- >>257
任意のTCPポートを一つだけです。今は80使ってます。
- 157 名前：47 投稿日：02/04/23 00:15 ID:/SazaYog main/1019230372.html#271
- コードセクションは書き込み禁止だから普通にやったら書き換えできないですな。
>>262
> キャッシュの優先度って、ファイル単位なんですか？
ファイルの大きさも考慮すると思いますが、細かい部分はまだわかんないです。
適当な評価関数挟むでしょうから、後々この辺がバージョンアップの対象に
なりやすいのではないかと。
あと、ホスト特有の情報は偽造しやすいので優先度判定には
極力使わないんじゃないかと思ってます。優先度かせぎのための
キャッシュファイルが出回るというのはありそうですが、
それはそれで文化として面白いのではないかと。
>>263
> キャッシュに１G確保している状態で１Gのファイルにキューが来ると
> その前に溜めてきたキャッシュファイルが全て消失してしましませんか？
しますね。だから転送時のファイル最大値の設定がいると思います。
> あと確保しているキャッシュをオーバーしたファイルをUPする場合は
> どうなるんでしょうか。
今の実装だとキャッシュ設定を超えて大きなファイルができてしまいます。
自動的にキャッシュ使わないで転送するだけにすべきでしょうねぇ。
- 158 名前：47 投稿日：02/04/23 14:01 ID:m9msySxe main/1019230372.html#281
- >>273
> キャッシュって、ユーザー側から見たら一個のでかいファイルなんですよね？
違います。
Freenetのように大きなファイルを一つ作ってその中に詰め込むのではなく、
元のファイルにヘッダなどを追加したキャッシュファイルがファイルの数だけ
あることになります。こちらの方が効率や使い勝手がいいだろうとの判断です。
キャッシュは好き勝手に消したりコピーしても大丈夫です。
> 自分の貢献度って自分で見れますか？UP回数/UP容量などを。
自分の優先度を表す値が実際に見えるようになると思います。
一つのノードに接続が複数入った場合、どれを優先させて接続させるかを
決める必要がありますが、ノードの優先度はこの判断に使用します。
ただし、検索用の接続はこれとは関係なく、ダウン用の接続判断のみです。
この値が低いとダウンが蹴られ易くなるので、ユーザさんはこの値を
上げるように各自工夫することになります。具体的にはUPフォルダに
ファイルを置くなり、ポートを開放して転送に参加するなどとなります。
ただ、DOWN側と違って検索ネットの方は優先度などの不平等を廃して
回線速度などから自然にうまく繋がるように工夫しようとしているわけですので、
ダウン側もキャッシュ方式などを工夫して、できるだけDOMでもファイルを
落とせるようにするつもりです。
ダウンしようと思ってもできないのは単なるシステムの設計ミス
（人気があるのに十分にキャッシングされていないであるとか、
回線の太さを考慮した接続形態になっておらず転送にボトルネックがあるなど）
あるいは、故意の妨害行為を防げていないという理由のはずなので、
優先度を設けるのはシステムを円滑に働かせるための補助要素です。
キャッシュ詐称やシステム妨害などの変なことをしていなければ
普通に欲しいファイルが落とせるようになるはずです。
- 159 名前：47 投稿日：02/04/23 14:01 ID:m9msySxe main/1019230372.html#282
- >>274
> 基本的に元のファイルサイズに対してプレミアつけて、
> 実際の転送量に乗じて評価してやるとイイのでは？？
当初はそうやろうと思っていたのですが、実際の転送量というのを
どうやって測るのか？その情報をどこでどうやって保持するのか
どうプロテクトするのか（レジストリやファイルではその情報が安易に
他ノードにコピーできてしまうし、確実にホスト認証するのはほぼ不可能）
という点で良い案が浮かばなかったので、現在は転送の結果生じる
キャッシュの方で評価しようかなという案になっています。
転送以外にUP実績の方も評価しないといけませんし。
ただ、今の実装だと、ブロック転送可能になった都合で
ちと問題があって、ファイルの最終ブロックを転送するとその時点で
その最終カウンタが上がるんで、キャッシュの最後の部分をわざと
壊して自分自身で再読み込みすると点が上がるという問題があったり。
そもそも小さなファイルと大きなファイルで評価が同じなのは問題なので、
ブロックUP数で評価しようかとも考えてます。キャッシュヘッダにUPされた
ブロック数を記録することにしようかなどとまだ構想中です。
この辺の評価システムは今現在検討中なので、何かいい案ありましたら
教えてください。システムがうまく動くかどうかの要はこの辺だと思いますし。
- 160 名前：47 投稿日：02/04/23 14:07 ID:m9msySxe main/1019230372.html#283
- >>279
受注でのソフト開発やパッケージソフトの開発したことがあります。
ドメインはacだったりgoだったりcoだったりいろいろ。
- 161 名前：47 投稿日：02/04/23 19:09 ID:qovcgpcx main/1019230372.html#301
- 各種の変更でまた動作が不安定になったので地道にバグ取り中(^^;
>>290
> DNS使用時に、Winnyに入力されたアドレスが不正だった場合の例外処理は、
> どんなのを予定していますか？
現状では無視です。警告は無意味だと思うのでやりません。実際の稼動時には
ほとんどのホストが接続不可能だろうから警告の類はうざいと思います。
>>293
> UPフォルダからの転送は暗号化しながら直接相手へ送りつける。
うーむ。それできなくは無いですけどそうするとUPファイルの評価値
格納する部分作るのが面倒かもしれず。
転送されるファイルがG単位ですと確かにそうあって欲しいですけど
やるとしても後のバージョンでの実装ですかね。
>>299
>本当に今月中にはできるんですか？
バグっていて、簡単にシステムダウンして良いのなら今の時点でも
最低限のファイル交換できますが、変なα版公開しても叩かれるだけだろうし。
まぁ、あと一週間で公開可能版（β）まで持っていくのは難しいと思うんで、
最終調節は連休中にやってるんじゃないですかね。
- 162 名前：47 投稿日：02/04/24 00:53 ID:8Cub6S/U main/1019230372.html#319
- じみちーにバグ取り中。プロトコル変えるたびに動作不安定になってるけど、
最終に近いと思われるプロトコルでやっと安定動作してきました。
あと、初期リスト周りを見直して前話題になった接続復旧を可能にしときました。
>>303
えーと、自ホストのDNS登録間違えていると、相手が再接続したときに
こけますけど、これは初期リスト内ホストのサーバダウンと同じなんで
これをアタックと考え出すと防ぎようがないです。
それにこのDNS登録は相手の再起動のときだけ使う情報で、
内部的にはIPアドレスで処理してるんで間違っていても
そんなに問題にならんはずです。こちらから繋いだり、他から紹介してもらった
ノードなら、向こうからの要求も問題なく届きます。
一応、自前で調べて自ノードのIPとDNSの結果を比べて違ってたら
警告だすようにしときましたけど、まともに動作してても警告でるかも。
ということで、これで異常終了するようには現在なってません。
>>305
>できれば共有するフォルダの一覧を書き込んだテキストファイルを読み込むような仕様にして
これは簡単にできますけどそうしますかぁ？今だとUPフォルダは１０個までで
それぞれに暗号化のキーワードｗ指定。サブフォルダは無視って仕様ですけど、
この辺を作り変えるのは簡単です。
iniファイル直接書き換えればいいだけだから今のでも問題ないと思いますけどね。
あと、ショートカット技はだめです。UNIXと違ってWindowsのショートカットは
プログラムで対応しないとだめで、これがまたいろいろと面倒。COM使いまくり。
>>306
> 使うかどうかは別にして串は使えるんでしょうか。
使えるんじゃないですかね。
>>307
>Freenetの様にでかい共有ストレージにアップするのではなく、リクエストが有って始めて
>アップされる
その理解であってます。UPフォルダ内のファイルもキャッシュフォルダ内のファイルも
外部から見ると暗号化されたキーファイルで、UPフォルダ内のファイルに要求が
かかるとそのとき初めてファイル本体に暗号化や全体ハッシュ処理がかかって
キャッシュファイルに変換されます。
- 163 名前：47 投稿日：02/04/24 00:56 ID:8Cub6S/U main/1019230372.html#320
- あれ？そういえばUPファイルを変換しながらキャッシュをUPしてるときって
全体ハッシュが変なはずなのにハッシュエラー出てないなぁ。見直さんと。
- 164 名前：47 投稿日：02/04/24 01:00 ID:8Cub6S/U main/1019230372.html#322
- あとフォルダですが、今現在で、ダウンフォルダが一つに固定、
キャッシュフォルダも一つに固定、アップフォルダが１０個までです。
UPフォルダにあるファイルが必要に応じてキャッシュフォルダに移動して、
他ノードとやり取りされるのは全てキャッシュフォルダ内のファイル。
で、ダウン指示するとキャッシュ内のファイルがダウンフォルダに入ります。
中のファイルに関しては、キャッシュ内は全て暗号化されていて
UPとDOWNフォルダは暗号化されてません。キャッシュ内では
ファイル名も全て暗号化されてます。
- 165 名前：47 投稿日：02/04/24 01:09 ID:8Cub6S/U main/1019230372.html#324
- フォルダをリカーシブに追跡するとか、UPフォルダにショートカット置いたら
その先のフォルダも追跡するとか、そういう風に作るのはそれほど
面倒でないですけどやります？
問題は暗号化キーワードどうやって指示するのかとか、
UPフォルダ内のファイルを直接選んでキャッシュ送りにしたりするんで
この辺をどういうインターフェイスにするのかってことかな。
シンプルなのはフォルダ名と暗号化キーのセットを一行にして書いたファイルを
読み込んで、手動でキャッシュに変換するときは、UPフォルダ内部かどうか
無視してファイルオープンダイアログで指示かなぁ。
- 166 名前：47 投稿日：02/04/24 03:42 ID:GNHS8Luu main/1019230372.html#330
- とりあえずUPフォルダは専用の設定ファイルから読むように変更して
個数は制限無しにしました。まだI/Fが完全で無いしサブフォルダ追跡しないけど
簡単なんでやっときます。あとショートカット追跡は比較的面倒なんでやらないと思われ。
- 167 名前：47 投稿日：02/04/24 04:04 ID:zbSidQtO main/1019230372.html#331
- サブフォルダ追跡も完了。さーて寝よう。
- 168 名前：47 投稿日：02/04/24 10:36 ID:7Ake+Zch main/1019230372.html#340
- 眠い・・・
>>325
>キャッシュに溜まっているデータが物理的に壊れたりした場合
>他のノードのキャッシュに影響が出ないのですか?
ハッシュで検出できます。実装はまだですが変なファイル送ってくる
ノードは検索ネットから切り離す予定です。
>>326
ダメです
>>335
UPを取りやめた場合ですが、(2)に近いですが(3)です。
UPフォルダの公開を止めてもキャッシュに入っていれば吸い出されていきます。
どのキャッシュファイルがどのUPファイルかはユーザからはわかりませんので、
一度アップしてしまうと公開停止は困難です。そもそも、他人にどのファイルを
UPしているのかをUP側は知ることができません。
自分のところからのUPをやめたいのなら、UPフォルダ外してキャッシュを
全て消せば確実に止まりますが、他ノードにもキャッシュが残っているはずなので
他の人はそちらから落とせてしまうでしょう。
- 169 名前：47 投稿日：02/04/24 19:01 ID:uuoZJZD4 main/1019230372.html#367
- UPフォルダ関連も変わったしってことで、ほったらかしだったインターフェイス周りの
作りこみやってます。とりあえずファイルダウン中に予測時間やダウン状況の
バーを書くようにしないとだめだけど、リストコントロールはあまり使い込んだこと
ないんで試行錯誤中。
公開する予定のHPですが、場所の準備やhtml自体はもうできてます。
本体とここへのリンクだけだったりするんで簡単（ｗ
HPは昔確保したところかどこかになると思いますが。
あと開発スケジュールですが、他の用事を全て無視して
こればっかりやっていれば今月中に上げられるかもしれませんが、
GWまではそういうわけにもいかんでしょうからβ１リリースは
来月でしょう。
- 170 名前：47 投稿日：02/04/24 23:22 ID:4cHXQvZx main/1019230372.html#374
- ここで以前話に上がったような細かい部分（昔入れたキーを保存しておいて
ドロップリストから選べるようにするとか）を仕上げてます。
今まで手抜きインターフェイスでチェックが甘かったり、作者しかわからないような
デバッグ情報がだだもれでしたが、普通の人向けのツールになりつつあります。
あと、キー種類一覧やノード情報などの各種の設定はiniじゃなくてテキストファイルとして
できるだけ別に分離しておきました。いざとなったらテキストいじってくださいということで。
そろそろ、小規模LAN上で悪意の無いユーザばかりであれば使える感じになってきましたが、
一般公開するとなると各種のクラック対策などがちゃんと動作するのか、
トラぶらないかチェック要りますしやることはまだまだたくさんあります。
大きな実装としてダウンファイル自動選択部分がまだだし。
- 171 名前：47 投稿日：02/04/24 23:45 ID:bGZZbcOW main/1019230372.html#375
- >>368
>accsjp.or.jp:80 とか、いうのを入れて稼動させた場合、
>こちらのサイトで、Winny使用者のログが取れたりしますか？
プロトコルヘッダ部分を解析してやればWinny接続がきたというログを取ることも可能でしょうけど、
最初のネゴの時点でタイムアウトしてWinny側で直ぐに接続を切ってしまいます。
ただ、さすがに初期リストに入っているポートは何回か再接続しにいってしまいますねぇ。
これはしかたないような・・・
> DNSとIPのチェックで、エラーが出た場合は、
> 必ずIPのほうで接続し、URLのほうは外に出さないようにしたほうが良いかと。
これは大丈夫です。
認証がそれなりに複雑（一番初めの認証段階から暗号化してる）なので
Winny本体をリバースエンジニアリングしないと通信内容はわかりません。
IPはプロトコルとしてではなく、acceptの結果として取っているので
netstatで見れば同じですし、URLは認証を突破できないと送信されません。
それに解析したとしてもわかるのは隣とのやり取りだけなんで、
それだけわかってもネット全体やファイルのやり取り状況はわかりません。
URL情報をやり取りするのは直接接続したホスト間だけで、
検索やダウンの時にはネットワーク上に出ません。
>>370
>Winnyのプロトコルが「最初に接続する対象が挨拶メッセージを返すようなプロトコル」だとしたら
さすがに一番初めにお互いに認証しますので変な接続ははじきます。
一番初めの認証部分を突破できても、最初から全部暗号化されているので
擬似的に対応動作するようなダミープログラム作るのは困難なはずです。
ちなみにWinnyでは妙なロックを避けるために、できるだけ待ちが発生しないような
プロトコルになってますが、この初期ネゴのときと、ファイルの転送中はさすがに
待ち動作が発生します（そうでないとお互いのバッファがあふれちゃうんで）。
検索なんかでは相手を待ったりすることはないプロトコルになってます。
タイムアウトがありません。
>>371
完全独自プロトコルです
- 172 名前：47 投稿日：02/04/25 00:18 ID:nVH07U8U main/1019230372.html#378
- つーことで、初期のネゴの所の認証をチェック厳しくして
問答無用で切断して無視するようにしときましたけど、
デバッガで追えば一発でばれるんだよなぁっと（ｗ
- 173 名前：47 投稿日：02/04/25 14:56 ID:aCbyvOS8 main/1019230372.html#397
- うー、ますます眠い。
職場の人たちは、やつは仕事そっちのけで
何やってるんだと思っていることであろう（ｗ
とりあえず、GUI操作によっては通信がスリープしてしまうことがあったので、
GUIのところだけマルチスレッド化しました。これで通信負荷が上がっても
さくさく動くようになりましたが、ロック絡みのバグが怖し。
あとCPU負荷が上がってるんで対処せんと。
>>379
>ファイルのヘッダで、このファイルはダメかどうかをある程度確認できるようにしたらどうだろ
既にある程度はやってます。ブロック毎に持ってるハッシュの比較結果が
キャッシュヘッダに書かれてますので、半端なキャッシュは起動時に全て検出します。
レジュームは後半が欠損したキャッシュファイルの修復処理扱いになってるだけなので、
どこの欠損でも後からそこだけ再読み込み可能です。
これにより隣のノードに壊れたブロックが渡る事は無いはずです。
ただ、通信時にブロックに全チェックかけるかどうかはまだ保留中です。
暗号化で使っているRC4の方は軽い処理なんで通信の全個所に入ってますが、
MD5ハッシュはそれなりに処理が重いんで、ハッシュチェックに関しては
今はキャッシュIN、OUT時のみの処理になってます。
最終パフォーマンスによってはブロックチェックの方はMD5ハッシュじゃなくて
別のアルゴリズムに変えるかもしれません。
- 174 名前：47 投稿日：02/04/25 14:56 ID:aCbyvOS8 main/1019230372.html#398
- >>391
>改竄対策というか自動バージョンアップの方法なんだけど、なんか考えてます？
あまりばらしたくなかったんですが、それ関連で今しかけてあるのは基本的な
時限トラップ（ある日付超えたら動かなくなる）だけですねぇ。
変なことやるとそれのせいでバグりそうだし。
そもそもexe本体のハッシュ求めてもその比較部分書き換えられたら意味無い
ので基本的に本体改ざんは防げないと考えてまして、ハックされても
致命的なことにならないように、プロトコルの方で対処しているつもりです。
UPしている人のことはプロトコル的にも知ることができないようになってます。
Freenetより匿名性が落ちるでしょうが、あれはやりすぎでパフォーマンス低下を
引き起こしていると思います。匿名性はこれで必要十分だと思います。
そしてファイルダウンのときは三つ以上のノードを経由しないはずだし、
プロトコル的に回線速度を考慮しているのでパフォーマンスも比較的良いはずです。
この辺はまた検証しなおします。
>> 396
>Winnyは全部落とせてないとデコードできないんじゃないのか?
そうですね
- 175 名前：47 投稿日：02/04/25 15:03 ID:aCbyvOS8 main/1019230372.html#399
- そういえば、今だとファイルが全部落ちてないと展開できませんが、
エラー出たらダウンフォルダからゴミ消しているだけなんで、
頭だけのファイルでも展開自体は可能です。
頭だけでも展開できるようにしときますか？
AVIファイルのことを考えるとこれできた方がいいし、。
ムービーなら途中壊れていてもそれほど困らないし。
- 176 名前：47 投稿日：02/04/25 15:20 ID:aCbyvOS8 main/1019230372.html#401
- レジュームするか展開するか選ぶだけなんで、では、付けときましょう。
- 177 名前：47 投稿日：02/04/26 16:09 ID:Zctv5nV6 main/1019230372.html#436
- 連休になれば集中して作業できるはず（って今でも暇なときはこればかりやってますが）
とりあえず今も引き続きインターフェイス周りを強化中です。
リストコントロールを全てオーナードロウで自前で書くようにしたので
状況に応じて色が変わったりダウン時のバーやキャッシュの
バッドブロック状況が表示されるようになりました。なんかeDonkeyみたいですが。
>>403
>外観のカスタマイズは可能になる予定ですか？
なりません。それなりに見栄えの良いものにして固定にすると思います。
要望が多かったら後でやります。
>>407
メリットが良くわからないかも
>>409
> がいしゅつかもしれないんですけどジャンル分けってできないんですか？
暗号キーがジャンル分けに使われることになると思います。
あとMXと同じで名前を工夫することになるでしょう。
キャッシュのジャンル分けに関しては、お互いにダウンするものが
似ているものどうしが接続近くなって自己組織化でクラスタ化していくので
それなりに無駄にならないはずです。ここはまだ検証中です。
>>415
> Freenetのようにユーザーに常時接続と非常時接続を選択させるのはやめて下さい。
これはやらないです。Freenetと違って非常時接続メインで考えられてます。
ダウンするために接続している人のUP回線を借りるという感覚なのでeDonkyに近いかも。
>>416
> 誰かにUPするとキャッシュファイルに記録される
> んですよね（評価として）？そのタイミングはいつなんでしょう？
今だとUPしている最中です。１ブロック転送が終わるとそのブロック単位で評価が上がります。
- 178 名前：47 投稿日：02/04/26 16:09 ID:Zctv5nV6 main/1019230372.html#437
- >>417
>この時に暗号キーも付加すると考えていいのかな？
そうですね。UPフォルダ単位で暗号化キーを設定します。
>>423
> ＤＯＷＮが終わってない(未完成の)キャッシュファイルを他のＰＣへコピー
> した場合、コピー先ではＤＯＷＮを再開してくれるのでしょうか？
できます。そのために大きなファイルとしてではなく個別ファイルとして
キャッシュを作っているところもあります。キャッシュファイルそのものを
やり取りするというのもありだと思います。
あと、掲示板はやらんです。掲示板は他にお任せですしファイル共有ソフトとBBS
に求められるものはその性質が違うので個別にやったほうがいいと思います。
>>430
鍵はUPフォルダからキャッシュに変換されるときに勝手につきます。
既出ですがUPフォルダにキーを設定します。
>>432
>「交換」をメインにしたプロジェクトもどこかですすんでるのでしょうか？
アイデアだけですが、今の共有鍵方式ではなく、公開鍵方式の暗号を
応用すれば、身分を隠したままで交換（相手の内容を確認した上でやりとりする）
というのも可能だと思ってます。
今のWinnyの設計ですと共有専門で、相手を特定して個別交換するには
複雑な名前の暗号キーやり取りを別のところでこっそりやらないとだめですが、
もし共有がうまく行われないようだったら、公開鍵のメカニズムも入れて、
交換も可能なシステムにしようかとも思っています。
公開鍵を使ったシステムにありがちな、共有鍵システムをベースとした
公開鍵システムになるでしょう。
- 179 名前：47 投稿日：02/04/26 16:16 ID:Zctv5nV6 main/1019230372.html#439
- 公開鍵方式の暗号というのを知らない人がいるかもしれませんが、
暗号化と復号化（暗号を戻すこと）の鍵が別になる暗号方式です。
これですと、キーのどちらかを公開して、暗号化できるけど展開できないとか、
展開できないけど暗号化できるなどということが可能です。
これで相手にしか展開できないようにしてその人にだけ送るとか、
逆も可能になるのではないかと。
そしてこの公開鍵暗号は処理が重いので、通常の共有鍵方式
（暗号化と復号化の鍵が同じ暗号方式）と組み合わされて使うのが普通です。
Winnyでしたら、暗号キーはシステム側で複雑なものを自動生成して、
このキー生成を面倒見るシステムを今のシステムの上に作ることになるでしょう。
今作っているものもそのまま使えるので無駄にならんはずです。
- 180 名前：47 投稿日：02/04/26 16:26 ID:Zctv5nV6 main/1019230372.html#442
- というか、将来的には交換システムにすること前提でシステム作ったほうが
良い気もしてきました。
直接相手とコネクション張らないMXで、やりとりは今のMXと同じにすると。
共産主義がうまく働くことはまれですけど、物々交換ならうまく働くことが多いし。
- 181 名前：47 投稿日：02/04/26 16:31 ID:Zctv5nV6 main/1019230372.html#447
- １対１で直でやると必ずTCPポートの接続状況で接続相手がばれてしまいますから、
匿名性と高速性がトレードオフになるのは仕方ないかも。
- 182 名前：47 投稿日：02/04/26 16:32 ID:Zctv5nV6 main/1019230372.html#448
- >>446
そうです
- 183 名前：47 投稿日：02/04/26 16:35 ID:Zctv5nV6 main/1019230372.html#450
- >>449
串を使う理由と同じです
- 184 名前：47 投稿日：02/04/26 18:09 ID:+71+QC/c main/1019230372.html#455
- 当面は高速なFrrenetという方向性でいくでしょうけど、
目指すは匿名性の保証されたMXであるわけで、
共有機能だけではどうしても対処しきれないとなったら、
交換（認証した相手でないと暗号復号を不可能にする）を
支援する機能がついていくでしょう。これを見越してVer1を作ります。
まだ公開前なのになんですが、Ver1はシステム破綻する可能性が残ります。
考えられる対策はとっているつもりですが、何が起きるかは広まってみないとわかりません。
キャッシュを消す人ばかりになるもしくはキャッシュヒット率が悪くてネットワーク帯域があふれるか、
使用ルールが厨房対策で複雑化していって（暗号キーの複雑化）実用的なものでなくなって
何も落とせなくなってしまうか、クラック版が混じってシステムが破綻する、もしくは
何か致命的な穴が見つかって匿名性が守られないとかいろいろ可能性はありますが、
どこの世界にも推奨された使い方を守らない人はでるわけで、先を読んで対処するしかないでしょう。
初めからこの交換支援機能がないと破綻すると判断したら、
現バージョンはまだ途中とみなして公開を先送りする可能性もありえます。
今の設計ですとキャッシュに頼った設計になっていますけど、より暗号技術に頼る設計になるでしょう。
どちらにせよ今の実装は無駄にはならないはずなので完成させますけど、公開は慎重に行います。
- 185 名前：47 投稿日：02/04/26 18:35 ID:au0a7xnK main/1019230372.html#458
- >>452
交換鍵方式の暗号ならWinnyでも標準で使えますけど、検索できれば展開可能という設計なので、
他のツールで暗号化というのもありえます。もし個別に暗号化始めるようでしたら、
転送システム側で標準装備すべきでしょう。
そもそもWinnyの考えは、Qの取り合いになるのは帯域が充分でないからなんだから、
充分キャッシュをとって見かけの転送帯域を増やしてあげればQの蹴りあいが必要
無くなる。だから交換じゃなくて共有でいいという考えです。
そのついでに匿名性を確保しているわけですが、
帯域に余裕ができたからもう落とさないというのは善人の考えで、
帯域に余裕ができればその分別のものを落とすというのが普通の考えです。
だからどうしてもなんらかの制限をいれるわけですが、どうしてもこの方針ではだめなら、
Qの蹴りあいならぬ、暗号キーの出し渋りによって無駄なダウンを減らして帯域を減らすという
MXの世界に逆戻りさせるしかないでしょうね。
- 186 名前：47 投稿日：02/04/26 20:13 ID:eNrINJ97 main/1019230372.html#463
- ここまでできてるんなら、よく考えてみたら、Ver2と言わず
直ぐに認証機構作れる気がしてきました。
今だとボディの暗号化とヘッダの暗号化に同じキーワード使ってますが、
別にすればいいだけのような。
ちょっと実装してみますか・・・
- 187 名前：47 投稿日：02/04/27 21:37 ID:BRupXO8A main/1019230372.html#539
- 引き続きバグ取り＆細かい修正中です。
一部マルチスレッド化したんでどうも不安定でしたがどうにか安定。
あとUI周辺も調節中ですけどリストビュー周りの仕上げはそろそろ完成。
まだタスク制御部周りのUIが内部タスクそのまま見えてて意味不明なんで、
ここを普通の人向けに見やすくしてQ管理部分として作り直しして
あと帯域制限仕上げればひとまずβかな。
んで今は全体のパフォーマンス検証のためにシミュレータの方を作り変えてます。
そもそもこれは接続と検索部検証のために作った検索部作る前に作ったものなので、
出来上がった実装とシミュレータの検索方式が違ってる
（シミュレータでは検索の親が常に一つだったけど、変な親がいるとそこで引っかかって
検索がFailするんで、本実装では上下の区別は完全動的で親は複数）
そのため大規模時に検索がうまく動作するか不安でしたけど、
方式合わせたシミュレータによるとこっちでも問題ないみたいです。
検索方式が従来のP2Pとは違い完全独自な方式
（ルーティングアルゴリズムとしてはe-mailに近い）
なんでここはよく検証しないとまずし。
シミュレータを高速化して１万ノード超まで計算してみたので、
規模が増えてくると何が起こるかは把握できているつもりですが、
今使っている方式では規模が大きくなっても検索速度は落ちない
（シミュレーション結果でも１０ノード以上遠くまでクエリが飛ぶことが無い）
代わりに、流通する全ファイルの数が問題になったり。
ヘッダだけとはいえ、さすがにネットワーク上にある全てのファイル情報が
一箇所に集まるとまずいから、上流ノードでキーが集まりすぎないように
新しいメカニズム入れないと。
あとファイルキャッシュの流通状況のシミュをやらんとまずいけど、
こちらは利用者の振る舞いにより挙動が正確にはじき出せないんで
今のシミュとは別に作って効率良い評価関数とか接続方式の検証します。
あとまだ実際のテストでは１００ノード超えたことないから検証しないと。
一般公開は遠い・・・・
- 188 名前：47 投稿日：02/04/27 21:53 ID:T4lfczSI main/1019230372.html#540
- sage忘れた・・・
BBSとの連動ですが、単なるファイル共有とP2PによるBBSでは技術的な難易度に
違いがあります。真面目にやるとBBSの方が作るの難しいです。
シンプルなファイル共有で良いのならバージョン管理の必要が無い
（内容書き換わったら同じ名前でも別ファイル扱いしてしまえばいいけど、
BBSではそうはいかず分散環境下でのバージョン管理と衝突回避が必須）
高度なファイル管理システム作ってその上にBBS作るというのは正攻法ですが、
それに耐えられる分散ファイル管理部を作るのは非常に難しいでしょう。
もちろん匿名化対策とかクラック対策しないでいいんなら作れそうですが・・・
そんなわけで私には片手間では作れそうにないし、
匿名BBSに関しては2chで困ってないんで関わる気はないです。
警察のお世話になるような書き込みしないし（ｗ
ダウン時の帯域に関してですが、Winnyでの対策は536氏の考えそのままです。
良くあるコネクション数などの設定は完全自動でユーザからは調節不可能です。
欲しいものが落とし終わったら切断な人対策ですが、このQが制限されている
（そもそも帯域が制限されてるわけで、遅い人が間に挟まらなければネットワーク帯域が
そのまま制約になるはず）んで、522氏が書いたようにQをたくさん入れてほうっておく
ということになるはずなんで、この人のUP回線とHDDを借りるということになります。
あと、優先度が上がるタイミングをわかりやすくしてMXのように相手のダウンを
待つ（自分のために）とします。
実はWinnyに一番近いのはFreenetというよりeDonkyかもしれず。
- 189 名前：47 投稿日：02/04/27 22:15 ID:0cajXf9Z main/1019230372.html#542
- >>538
>そーいう漏れはでかい動画でも暗号キーなし
>もしくわルールにそう暗号キーで共有するYO！
実は今の暗号部（公開共有鍵専用）そのままで公開すると、
こういう人ばかりで、標準キー（NULLキー）による暗号しか
使われなくなると思ってたりします。そうなると暗号の意味無いんで
今現在対策を考慮中。
暗号キーを自分で指示することもできるけど、ユーザIDを用いた
認証も可能としたいところです。
例えばユーザIDを暗号に使うと、そのユーザIDをキーとして検索することで
その人が公開したファイル一覧を抜き出せますが
（情報としては分散してるんで匿名性は保持される）、
ボディ暗号がまた別になっていれば知ることができるのはファイル名だけです。
で、あとからボディ側の暗号キーのみやりとりして
相手とネゴしないとファイルダウンしても展開できなくする
という利用法が考えられます。これで共有以外に交換も可能にしようかと。
この辺はまだ設計を考えてる段階ですけど。
>>541
基本的にブロックUP毎に優先度上がるけど、ファイル全部送ったらより高得点にして、
そのタイミングが見れるようにする予定。何送ってるかはわからないけど、MXのように
相手のダウンを待ってあげることができるようにします。なお、UPファイルからの
吸出しの場合のみ何を送っているのかユーザからもわかり、これが一番優先度が上がります。
- 190 名前：47 投稿日：02/04/27 23:11 ID:/0QRI9IQ main/1019230372.html#549
- 暗号かけないと自分のキャッシュに検索かけただけでそれが何か大体わかってしまって
MX上でQ大放出と代わらない（それどころか他人に踏み台にされるのを防げない）という理由で
NULLキーでのキャッシュは推奨されなくなっていく可能性もありますが、
暗号ワードの管理が面倒であることは確かなんで、暗号キーを簡単にネゴできる何らかの
メカニズムはあったほうが良いとは思ってます。
とりあえず、NULLキーかどうかはシステム側で簡単に判定できるんで、
NULLキーキャッシュ転送をはじく機能だけは付けといたほうがいいでしょう。
ただ、暗号キーの管理の部分は今のWinnyに＋他ツールで対策取れるんで、
当分は暗号部は任意のキーワード指示可能で自由度だけ高くしておいて、
ある程度の使用ルールが固まってきてBBSやツールだけでのやり取りでは
面倒という事体になってきたらそのとき次Verの公開ということになると思ってます。
心配しすぎてブツが表に出てこないとそのうち忘れられちゃうだろうし。
そんなわけで、一応先の展開の予測だけはしておいて
システムが破綻さえしなければ良いのではないかと。
あと、今ですとNULL検索可能（全ファイル問い合わせ）ですが、これやられると
検索部がほぼ確実に破綻しますし、NULLキー暗号の管理責任問題が出ますので、
検索ワードは比較的長めでないとだめにすると思います。半角二文字以上ですかね。
- 191 名前：47 投稿日：02/04/27 23:16 ID:/0QRI9IQ main/1019230372.html#551
- >>548
そんな感じを予定していますが、そこ実はまだ作ってないんです(^^;
ダウン側のシミュレータと同時にやってβ完成予定です。
その前に基本部分がちゃんと動かんといかんし
GUI作りこんでおこうという段階ですね。
- 192 名前：47 投稿日：02/04/27 23:17 ID:/0QRI9IQ main/1019230372.html#552
- >>550
現状ではファイル名と同じで126文字
- 193 名前：47 投稿日：02/04/28 11:42 ID:LQTYxDqn main/1019230372.html#570
- うー、気が付いてみるといつのまにかキャッシュ周りがバグだらけだった。
ブロック転送対応にした際にテストが甘かったらしい。たまにファイル管理周りで
妙なことすると思ったらこれだった。このバグ取るだけでかなりの時間をかけてしまった。
>>554
> Winny終了時にUPフォルダの設定をクリアするオプションをキボンヌします
本気でヤバイものを上げるときは、まず見当つかないような暗号キーかけて
UPフォルダ内からキャッシュファイルに手動で変換したあとに
UPファイル内の元ファイルを消せば問題ないです。
これでそのファイルの行方は誰もわからなくなります。
NATでも挟んでおいて他に何もDOWNしなければキャッシュから消えることもありませんし。
>>561
基本的に優先度はキャッシュ内にあるブロックの優先度の総和です。
だから、基本的にはキャッシュを大きくするほど優先度が大きくなります。
あと育てたキャッシュ（多くの人にUPしたキャッシュ）が多いとよりいいです。
UPフォルダに元ファイルが残っているともっといいですね。
- 194 名前：47 投稿日：02/04/28 11:50 ID:LQTYxDqn main/1019230372.html#591
- >プロクシ代わりに提供する帯域には依存しないのでしょうか？
これには答えてなかったですね。帯域は自由にユーザ側で設定できるので
これを元に優先度を決めることはできません。ただ、キャッシュフォルダを
大きく取ってもその中にキャッシュファイルがないと意味がないわけで、
このキャッシュをかき集めるのに太い回線は非常に有効です。
繋ぎっぱなしするだけです。
回線が細い人はほっといてもキャッシュが溜まりませんので、
苦労して他からDOMってくるか、自分で何か用意してUPフォルダに
入れておくことになります。
ちなみに、キャッシュファイルの方は徹底的にプロテクトがかかっているので
ここの部分でいんちきするのはかなり困難です。
キャッシュファイルを他からもらってくるのもありですが、
評価の高いファイルはそもそも大きさが大きくなるはずなので、
その容量自身がプロテクトになります。
素直にUP回線を開放して放っておくのが楽でお勧めです。
- 195 名前：47 投稿日：02/04/28 11:55 ID:LQTYxDqn main/1019230372.html#611
- あと、UPフォルダの位置が書いてあるのは、
単に独立したテキストファイルなんで、これを消したいなら、
ログアウトの時に消すなり、Winny本体の起動をスクリプトにして
終了時に自動で消すなり各自で工夫してください。
- 196 名前：47 投稿日：02/04/28 11:56 ID:LQTYxDqn main/1019230372.html#616
- さーて、嵐が来てるし寝よう。徹夜は辛し。
- 197 名前：47 投稿日：02/04/29 17:02 ID:F0kwFjw8 main/1019230372.html#723
- や、やっと困ってたバグがとれた・・・・
とりあえずテスト中ですが、何かやるたびに動作速度、通信パフォーマンス、匿名性、
クラック耐久度どれかに問題が出て、あちらを立てるとこちらが立たずで試行錯誤中。
それにシステムが複雑化してきて、残っているのは複雑な状況にならないと
発生しないような面倒なバグばかりなので、一つバグ取るのに丸々半日かかったりしてます。
とりあえず、複数のノード立ち上げて同時ダウンをかけまくってシステム全体に
負荷かける耐久テストに入ってますけど、たまに設計から見直さないと
ならないような致命的な問題が見つかって、ブロック丸々作り直しになったりもう大変。
そんなわけで副作用により、UPフォルダ内のファイルは一度キャッシュ経由ではなく、
通信部経由で直接暗号化し他にUPできるようになりました。キャッシュ経由も可能ですが、
UPフォルダに入っているファイルはキャッシュを消費しません。
とりあえずテスト期間に充分余裕取ったはずなんですが、
これは、開発期間よりテスト期間の方が時間がかかりますねぇ。
ということで、今から寝ます。
- 198 名前：47 投稿日：02/04/29 17:04 ID:F0kwFjw8 main/1019230372.html#724
- よく考えたら今月締め切りの仕事があったなぁ。これもやらんと。
- 199 名前：47 投稿日：02/04/30 03:09 ID:ONBOYPBA main/1019230372.html#766
- 今起きた(w
キャッシュ内とUPフォルダ内でファイルがダブっているときの挙動ですが、
今の実装ですと731氏の発言の（２）になってます。
ハッシュによる重複チェックにより、キャッシュ内のデータは無視されて、
UPフォルダ内のファイルを暗号化しながら相手に送られることになります。
選択されるキーの内部的な優先度が、前の実装では
仮想キー（他ノード） ＜ UPフォルダ内 ＜ キャッシュ内 だったのが
仮想キー（他ノード） ＜ キャッシュ内 ＜ UPフォルダ内 になったということです。
もちろん外部から見たらどこから転送しているのかは見分けがつきません。
一応、UPファイル→キャッシュへの変換機能はそのまま残っているので
前に書いたように、キャッシュに変換後にUPフォルダから消せば匿名性はより高くなります。
ただ、普通に使っていれば、UPフォルダ内とキャッシュでダブルことはありません。
DOWNフォルダに移動させるときにはもちろんキャッシュから消さないので
DOWNフォルダ内のファイルをそのままUPフォルダに持っていけばダブりますが
ハッシュによりこの場合は検出できます。
今だと検出だけで無駄なキャッシュを消してませんが、自動で消しちゃってもいいんでしょう。
壊れてるキャッシュは今でも自動的に消してますし、キャッシュファイルかそうでないかは
ヘッダでチェックしてるんでキャッシュフォルダに関係ないフォルダ指定しても
間違ってファイル消すこともないはずだし。
とりあえず前ので問題になったのは、凄く大きなファイルそれぞれに連続でQが入って
キャッシュ変換が連続で始まった場合で、前の実装ですとこれのせいでキャッシュ内容が
消えてしまうんでこうしました。今だと要求があったらファイル全体をまとめて変換ではなく、
ブロック単位で変換なわけですが、それなら直接変換したほうが早いという判断です。
優先度周りの実装が複雑になるんですが、こうでないと巨大なファイルが扱いにくくなるので仕方なし。
- 200 名前：47 投稿日：02/04/30 03:21 ID:NBgAq2LW main/1019230372.html#767
- >>658
> 概算でどれぐらいのユーザー数でも大丈夫なんでしょうか？
今ですと同時使用は１万人程度程度で算出してます。
> 最大設定容量はHDDの容量になってしまうのですよね。(NT系は除く)
98系ですとキャッシュはそうなりますね。今だとUPフォルダは任意個数で
好きなだけ取れてキャッシュからは消すようになってるんで、
できるだけ発掘してUPフォルダに移すほうがいいでしょう。
>>660
> もしかしたら、ダウンロード完了ファイルのサイズでどのファイルかは
> ２ちゃんねるの報告を調べれば、分かりますか？
元のファイルの大きさは検索をヒットさせないと見れないし、
キャッシュと元のファイルは大きさが違うんで困難です。
それに同じファイルだとわかっても暗号とかないと中身見れないし。
> すいません、日本人以外にも使ってほしいので、英語表記の
> インストーラとインターフェイスをお願いします〜
いや
- 201 名前：47 投稿日：02/04/30 04:03 ID:kkSf5bWG main/1019230372.html#770
- 細かい実装も同時に進んでまして転送レートなども見れるようになりました。
（もっかの悩みは転送レートが思ったほど上がらないことだったり）
そういえば、前に話にでた初期ノードの暗号化対応作業も終わってます。
初期ノードファイル全体のバイナリ化ではなく、ファイル名の暗号化と
同じ方式なので、バイナリ化されていないノード名と混ぜて使えます。
なお、設定ファイルの方は常設ノードと可変ノードの二つに分かれていて、
可変ノード設定ファイルの方はそれまでの接続状況により自動的に書き換わります。
どちらの設定ファイルでも暗号化されたノードrefを使えますが、
暗号化されていても一行に１ノード書いた単なるテキスト（@ba56f8なんちゃら）なんで、
いざとなったら暗号化されたノード情報をBBSに上げて各自でref追加という技もありかと。
- 202 名前：47 投稿日：02/04/30 04:06 ID:kkSf5bWG main/1019230372.html#771
- > 例えば、Keyが jpn だったとしてtokyo001.jpgというファイルをDLすると、
> downフォルダの下にjpnというフォルダが作成されて、その中にtokyo001.jpg
> というファイルが出来ると云う様にして( ﾟдﾟ)ﾎｽｨ･･･
ダウンフォルダ側は何も考えてませんでしたけど、確かにダウン時に使った
暗号キー毎にフォルダできたほうが便利かもしれませんね。
できるだけ取り入れることにします。
- 203 名前：47 投稿日：02/04/30 07:41 ID:AMYhkkPM main/1019230372.html#773
- よーし、とりあえず仕事終了（ｗ
今日は職場に顔出さんとダメだけど
今週はWinnyの開発に時間消費してもどうにかなるかなぁ。
ただGW後半からは次の仕事しないとまずそうだ。
- 204 名前：47 投稿日：02/04/30 21:47 ID:ExHEmZC0 main/1019230372.html#834
- とりあえずネムー。
顔色悪いぞと心配されつつも、職場でPCかき集めてテスト中。
といっても４台しか集められませんでしたが（ｗ
１PC１０ノード程度でやってますんでまだ４０ノード程度の
のんびりしたネットワークですが、一応当初の予定通りの動作はしてます。
前のバージョンだとファイルダウンがタイミングによっては始まらないで
首を捻る事もありましたが、例の設計変更でここは安定しました。
検索部はもともと調子いいし、既にそれなりに使えます。
ただ、しつこく各ノードで全切断＆再接続してると極まれにクラッシュするというバグが
残ってます。デバッガで見ても関係ないところで落ちてるんで、
どこぞでメモリの不正アクセスしとりますなぁ。そんなわけでのんびりと対処中。
あとは、巨大なファイルでのテストとか低速回線でのテストとかもしないとなぁ。
- 205 名前：47 投稿日：02/04/30 22:00 ID:ExHEmZC0 main/1019230372.html#839
- バグ取りが予想以上に面倒なんで苦労しとります。
実装急いだ分、例外処理が手抜きになってる
（というか、各所で例外処理はもちろん初めからしてるんだけど、エラッたからといって
ループ外に出ただけではほとんどのケースでダメなんで対処必要）
なんで手間取ってますね。
正直、バグ取りは作業的につまらんのでモチベーションが下がってるところもありますが、
とりあえず動くものを公開できないと何もやってないのと同じことなんで根性入れて
安定させます。
- 206 名前：47 投稿日：02/04/30 22:41 ID:ExHEmZC0 main/1019230372.html#848
- これを作り始めた理由は、Freenetの考え面白いと思ったけど、その設計じゃ使いもんにならんのでは？
もっといい設計あるんじゃないの？（つーかJavaはやめれ）と思ったのと、一月丸々かければ実際に作ってそれを
実証できそうだけど４月１日時点で暇だったというところですかね。
まぁ、そろそろ匿名性を実現できるファイル共有ソフトが出てきて現在の著作権に関する概念を
変えざるを得なくなるはず、あとは純粋に技術力の問題であって何れ誰かがその流れをブレイクさせる
だろうとは思ってたんで、だったら試しに自分でその流れを後押ししてみようってところでしょうか。
純粋に暇つぶしの腕試しです。
私なんてたいしたこと無くて、この程度作れる人は日本人でもかなりいるはずですが、実際に表に
ブツを出す人少ないんで、こういう方面でも日本人にがんばって欲しいというのもあります。
- 207 名前：47 投稿日：02/05/01 20:08 ID:FcZzSPIx main/1019230372.html#931
- 鍵の扱いについては各自の工夫に任せて独自ルールが自然に出来上がることを期待してます。
基本的に匿名性のレベル調節するための物ですので適当にどうぞ。
で現状ですが、何か問題に気がつく→修正→どこかでトラブル→修正→始めに戻る
の繰り返しです。今日だと暗号展開後でもできるだけテキスト形式を使わないプロトコルに
変更（メモリ上でテキスト形式で持ってるとデバッガで解析しやすくなるから）
で副作用で暗号化とハッシュによるエラー検出部に変更が発生（処理順番が逆になった）
とかやってますが、とりあえずバグ取りやクラック対策ばかりやっていても完成しないので
今は残った実装である転送時の接続相手を決定する部分と優先度周り仕上げてます。
前に書いたようにUPフォルダ内部のファイルはキャッシュ経由でなく直接通信部経由で
UPという方式になったんで今度はUPフォルダ内部のファイルの優先度を
どう扱うのかという問題があります。
これは基本的に履歴ファイルに記録しておくという方針ですが、これだと完全なクラック対策が
ほぼ無理なんで、他のノードと連動して評価するように対策中です。
単純にノードの優先度を自己申告性にするのでは無く、アップを依頼された
相手の方によって可変的に決めるということになります。各ノードの持ってる優先度は
単なる参考資料で絶対的なものでなくなります。
これを実現するのにいちばん簡単なのは、ダウン相手を決定する際にUPフォルダ内の
ファイルのハッシュを相手に申告して同じ傾向のファイルをもっている人を
優先的に繋ぐというもので、これやるとうまい具合に接続がクラスタ化される
（同じファイルを持つ人がグループ化されて近づいてキャッシュ内容が似てくる）
はずなんですが、これをやると今度はせっかく隠しているはずの
UPフォルダの中身がばれてしまって匿名性に致命的な穴ができてしまいます。
そんなわけでちと悩み中。
- 208 名前：47 投稿日：02/05/01 20:23 ID:FcZzSPIx main/1019230372.html#933
- あとファイルのダウンと中継相手の決定ですが、
前だとキー（ファイルのヘッダすね）にボディ本体へのリンクが直接書かれていて、
ファイルをダウンする方が複数の候補から選ぶという方式でしたが、
これだとシステムがクラックされるか暗号を解かれてしまうと、
だれが本体を持っているのかばれてしまう可能性があるんで、
今ですとキーのリレーの最中にキーが適当に上書きされていって
結果的に各ノードの協力でダウン相手と中継相手が選択されるように
なってます。ちと複雑ですが、これですと通信負荷も下がるし。
そんなわけでプログラム解析しても意味ないです。
優先度に関しても変更するからシステム解析自体が無意味になるはずだけど、
まだ見落としがあるんだろうなぁ・・・・
- 209 名前：47 投稿日：02/05/01 20:50 ID:4lSMvwVq main/1019230372.html#935
- ちなみに本職はプログラマじゃなかったりするとか言ってみるテスト（ｗ
- 210 名前：47 投稿日：02/05/02 11:02 ID:0CzdQeWy main/1020264992.html#55
- 中止しました。
- 211 名前：47 投稿日：02/05/02 12:50 ID:P4PzxQ2x main/1020264992.html#64
- よーし、どうにか致命的だと思える問題点がないのに、
動作がそれなりに安定しているバージョンまでこぎつけました。
デバッグ用のいろんな表示ついたままだしGUI周りの挙動が変だとかありますが、
数千ファイルでのテストとかGバイトクラスのファイル転送など、最低限のテストに
耐えられるようなので、小規模な環境に限ればWANでも問題なく動作する可能性高し。
クラック対策なども現状のものでどうにかなるでしょう。
そんなところですので、今後のテストでわけわからん挙動さえ出なければ、
GW中にβが出せるかもしれません。
あとやるべきは、転送時の挙動修正（そういえばレジュームの転送挙動が変だったかも）とか
例の優先度周りですが、このへんは挙動が変でもそんなに致命的でないので
とりあえず基本的な部分のWANテスト用ということで、公開してもいいかもしれません。
まー急ぐとろくなことないのでのんびりやります。
- 212 名前：47 投稿日：02/05/02 13:02 ID:P4PzxQ2x main/1020264992.html#65
- えーと、NULLキーに関してですが、これでも転送されているキャッシュやファイル名
見えなくなるので最低限は平気ですが、部分検索で簡単に当てられますので、
自分のキャッシュに適当に検索かけてそれが何かを探るのは容易です。
一応検索ワードは、半角二文字以上でないとだめにする予定なんで、
リタンキー一発でNULLキーの全ファイル名が見えるということにはならんですが
（ちなみに今は見えてる）
MXの流儀に従えばファイル名には例えば< >とか[ ]つけることが多いので
この辺で適当に検索すればジャンル問わずファイル名が見れてしまうのではないかと。
しかし暗号キーによるものでしたら、完全に一致させないとだめですし、解析も無理です。
どこかに暗号それ自身が書き込まれているわけでもないので、プログラムを解析しても
キャッシュ内のファイル名一覧を出すようなプログラムを作るのは無理で、
やるとしたらありそうなキーによる総当りになります。
- 213 名前：47 投稿日：02/05/02 13:30 ID:P4PzxQ2x main/1020264992.html#67
- >>38
> レイヤー構造を取るってのはどうでしょうか。同じレイヤー内でのみ検索が
> 有効になったり、転送中継が有効になったりする感じで。
Winnyの検索部はもともとそんな感じの設計になってます。
基本的には網接続ですが、自ノードの性能（基本的に回線速度）を申請してもらって
それで順位付けして各リンクに方向性を持たせ、順位付けありグラフとみなします。
完全平等にするのではなく、高速なノードはそれなりにひいきして
上に引っ張り上げるという方針ですね。
Winnyの検索では単純な網構造と違い上流下流がはっきりしているので、
基本的に下流方向には検索パケットが飛びません。
検索パケットは常に上方に流れていって、最も上流にいるノードや、ループ構造に達したら
そこから同じルートで戻ってきます。各ノードは常に親を探していて、同じ程度の相手なら
妥協して接続するんで、上流ノードではほぼ確実にループ構造になります。
これを見越して、検索パケットがループするのを積極的に利用する設計ですね。
ちなみに前の設計ですと親が一つでしたので擬似的な木構造でしたが、
これだと変な親の下にぶら下がっちゃうとそれより上が見えなくなるんで、
今ですと親は複数になってます。全体的に見ると、NTTの一般回線網のような
レイヤができて、高速なノードほど上流にきて横方向に網を作ることになります。
この辺は前に出したシミュレータの画面を見ると良くわかると思います。
ちなみにレイヤの横方向はキャッシュとUPフォルダ内容でクラスタ化されて
通信が頻繁なノードほどネットワーク的に近くに配置されていくので、
無駄な通信や無駄キャッシュが減る（はず）
>>40
> クライアントのメモリの持って行きかたはどんな感じですすんでますか？？
上記の検索方式のためメモリ周りはちと心配していた部分でもあったんですが、
１万以上キーを保持していてもアプリが確保しているメモリ総量は１０Mぐらいです。
そんなにメモリを馬鹿食いするアプリじゃないです。あとメモリ周りはメモリーリークが
怖いんでできるだけメモリアロケーションさせないで動的配列使う方針で組んであります。
ただ、ファイル転送が始まるとCPUをそれなりに消費します。
それは、通信と同時に暗号化をかけているからで、もしUPフォルダからのアップだと
ハッシュ計算とファイル内容の暗号化が同時にかかるんで二重の暗号化に
MD5のハッシュ計算となります。それなりに重いです。
開発に使っているPCはPen3の1GですがWindows2000でCPU負荷を見ると
今のバージョンで30%〜50%の負荷ですね。
> upフォルダにあるファイルのup回数(評価値)は、一定期間でリセット又は半減する様に
> なるんでしょうか。
ここは最終実装までいってませんが、評価値はノード内でどのファイルをノード評価対象に
選ぶかというノードローカルなものになって絶対的なものではないので、
半減とかリセットする必要ないです。
あと本気で雑誌に載ったんですかぁ？
- 214 名前：47 投稿日：02/05/02 13:42 ID:P4PzxQ2x main/1020264992.html#70
- つーか、テストのためにβ公開のはずなのにこれで公開したらいきなり
本テストになっちゃうなー。
知り合いの間でテストしてもらってもいいけど思いっきりバレルし・・・
とりあえずPC数台でも１００ノードレベルのテストはできるから
良く実験してから出すことにします。
- 215 名前：47 投稿日：02/05/02 14:14 ID:P4PzxQ2x main/1020264992.html#77
- UPフォルダ使わずにあらかじめキャッシュに変換しておけばより
低スペックCPUでも問題ないと思いますけど今度はHDD消費します。
匿名性とパフォーマンスを両方実現するのは難しいですねぇ。
とりあえず高速化はそれほど凝ってないんで、その辺も見直します。
- 216 名前：47 投稿日：02/05/02 21:07 ID:t0qz7RML main/1020264992.html#98
- 今β板テスト中です。
もう少しで皆さんにお届けぴざーら
- 217 名前：47 投稿日：02/05/02 23:58 ID:PpSOX4k8 main/1020264992.html#118
- 本当に載ってしまった様なので一応宣言しときますか。
winnyの今後一切の雑誌などの掲載をお断りします。
画像も駄目ってことでよろしく。
- 218 名前：47 投稿日：02/05/03 11:21 ID:qoAlUZHh main/1020264992.html#154
- 偽者が数名いるようですが、実害無いので問題ないかな〜。
今はβ１公開に向けて細かい部分の調節しています。メモリーリークのチェックとかGUI部の変更とかとか。
新機能追加してバグってもなんだし、あまり内部を隠すとトラぶったときに逆に理由がわからないので、
β１使用者はメカニズムを把握できている人だという前提で、タスクを隠さずにキュー機能無しで
内部が比較的見えるもの（つまりは今手元にあるもの）で、ヤバイ情報（接続相手の直IPなど）を一部
隠した程度でいいかなぁという感じです。
これだと厨房対策部分（優先度周りとか帯域制限、連Q対策など）が未実装のままですが、
正式版ではプロトコルヘッダが変わるんでどうせβ版とは別ネットワークになるし
当分はトラブル検証用なんだから好きなだけファイルダウンかけられた方がいいかもしれずと。
>>82
> 最小化の時はタスクトレイからシステムトレイにアイコンが移るようにして
他で公開しているソフトではこれやってるんで直ぐに付けられますけど
まだWinnyにはつけてません。正式版ではそうすると思います。
UNIX版に関しては、極力スレッドの使用を控えていてソケット直叩きなんで
通信部の移植は比較的簡単にできると思いますが、
インターフェイス部分をX-Window Systemに移植するのが面倒ですし、
今時Unixだけ漬かってるという人も珍しいでしょうから、
Unix版では設定はテキストだけでやって、プログラム的にはデーモンして常駐。
Unix版単体ではファイルダウンは無理で、キャッシュ転送専用にして、吸出しは
WindowsクライアントからUnix側に接続して行うというのがいいかもしれず。
これなら簡単に作れそうですし実用性が高そうです。
- 219 名前：47 投稿日：02/05/03 17:51 ID:ASkuyY5Z main/1020264992.html#186
- HDDｶﾞｸﾗｯｼｭｼﾏｼﾀ........
不正アクセスがあったみたいです。ヽ(TдT)ノ
- 220 名前：47 投稿日：02/05/04 01:42 ID:9zMUvUFi main/1020264992.html#234
- 再接続を繰り返しているとクラッシュすることがあるという
致命的な問題が残っていたんでデバッガで追っかけていたら、
メモリ確保周りで致命的な問題点があるのを見つけました。
情けないんで詳細は書かない・・・（ｗ
今日一日かけて修正しましたのでどうにか直せましたが、
いつものように関係ない部分で影響出てなんか転送で
引っかかる挙動を起こすようになってるなぁ。
とりあえずまたチェックしますが、いつになったら終わるのやら。
そんなわけでGW中にβが上がるかどうか微妙なところでもありますが、
出るぞ出るぞ言って引っ張り続けてもなんなのでもうすぐだという証拠に
β１直前でのテスト画面出しときます。
ttp://menkai.3nopage.com/img-box/img20020504014051.gif
PC上でポート別にして複数クライアント立ち上げて接続実験しているところで、
左側の三つが転送動作しているところです。見難いですが転送レートのところを
良く睨むとデータが流れているかが分かります。右側だとリンクの状態見れます。
とりあえずβ前の段階ですので詳細で変わるでしょうけど基本的にはこんな画面です。
- 221 名前：47 投稿日：02/05/04 01:43 ID:9zMUvUFi main/1020264992.html#235
- ああ、ちなみに118氏は偽者です。
雑誌への転載は禁止しても無意味でしょ。
- 222 名前：47 投稿日：02/05/04 02:49 ID:b/nYFvV4 main/1020264992.html#248
- >>245
いえいえ、今の時点ではHSPで作成しております。
- 223 名前：47 投稿日：02/05/04 02:54 ID:uXp+ON0V main/1020264992.html#250
- 今見ると転送リンクの上下方向表示が逆なような・・・まぁ見なかったことに（ｗ
80ポートのキーヘッダは本体どこなんだとかヤバヤバ。
>>246
初期ノードですが、現状の仕様では初期接続に二つのファイルを用いまして、
固定ノードと可変ノード用にファイルが分かれてます。
それぞれ一行毎に１ノードのIPもしくはDNSアドレスとport番号を書きます。
固定ノードファイルの方は完全にユーザさん任せで起動時に読むだけですが、
可変ノードファイルの方はプログラム終了時に自動的に保存されて
最近の接続履歴で内容が置き換わります。
保存の形式ですが、プレーンと暗号化方式のどちらか選べまして、
固定も可変ファイルも読み込みに関しては両形式いけます
が、可変の方の自動保存は必ず暗号化されて記録されます。
暗号形式はバイナリファイルではなく、１ホスト毎に@675412faのような文字列ですので
テキストエディタで追加できます。あとここの前スレの要望に従いDNSもひけるようになってます。
（実はこの辺の並列処理でいろいろ面倒だったんですよー）
当分はここなどでDDNSかIP直に晒して接続実験になるんじゃないかということで
こういう仕様になってます。一応暗号化されてるんで、2chでテストサーバの
ip晒しても固定ノードでなければそんなに痛くもないのではないかと。
そんなわけでβ専用の機能としてホスト名暗号化の変換ダイアログがついてます。
ここはザルに作ってあるんでデバッガで追いかけてバイナリ数バイト書き換えるだけで
暗号解読可能だったりしますが、どうせ隠してもどこに接続に行っているかは
分かる人には一発で分かるので、初期実験用ですね。
最終的にどうなるかはテストの様子見て決めます。
あ、ちなみに全てのノードで他のノード紹介機能があって初期コネクション
時にネゴして接続は適当に割り振りられます。前の画面で接続切れているのに
ノードの速度情報をしっていたりするのはこの辺のネゴの結果です。
どのノードも上下４接続程度でそれ以上は受け付けません。
これでも、シミュレーション結果だと、固定ノードは5%程度で充分で、
あとはネゴでほぼ全てのノードの接続がうまくいくことが分かっているので、
最終的には数百の固定ノード候補を書いたテキストファイルを適当に
公開することになるんではないかと思います。
- 224 名前：47 投稿日：02/05/04 03:10 ID:uXp+ON0V main/1020264992.html#254
- あと接続相手がどう決まるかですが、
基本的に自己申告した回線速度で決まります。
接続後にまずプロトコル認証が行われ、お互いに回線速度をやり取りします。
もしこれで速度がかけ離れていたり、受けたほうが既にリンク限界なら、
他のノード情報を渡して接続が切れます。その情報を元に他に接続しにいきます。
ただしこれは検索用のコネクションの話です。
Winnyでは接続リンクに検索用と転送用の二種類あり、
接続リンクは相手が決まれば繋げっぱなしで
内部では検索パケットが飛び交います
が、ファイルのダウン相手が決まったらhttpのようにその都度コネクションに行きます。
基本的に転送動作になるのでダウンかけると本体を追いかけて
コネクションが伸びていきます。この辺がFreenetとの大きな違いですね。
Freenetのように分散で広まるのはファイルヘッダだけで、
本体は必要になったときに別に落としにいくわけです。
なお、基本的に転送リンクでは回線速度情報は無視されますが、
相手は検索リンク側のコネクションで決まるので検索リンク側で
近い人のところにいくことになります。
- 225 名前：47 投稿日：02/05/04 22:45 ID:hD7cR1Vc main/1020264992.html#321
- とりあえず昨日のメモリ管理関連の変更で生じた不祥事は
どうにか直って普通に転送されるようになりました。また再テストしないと。
こんどは負荷かけても落ちないし、転送その他も問題なく動いてますが、
たまーに転送失敗することがありますねぇ。特に最後のブロック・・・
もう少し見直しますが、致命的だと公開が延びます。
当初の予定では致命的なバグはそろそろないだろうから細かい部分を
作りこもうと思ってましたが、結局ＧＷ前半はバグ取りについやしてしまったので、
β版というより、基本機能テスト用のαですね。
そんなわけで公開しないほうがいいかもしれないけど、無い機能は、
自動で再ダウンロードかけるなどの、基本部分がトラぶっていると
それを悪化させる機能ばかりなので、テスト版としては今のでいいかもしれず。
ファイル交換ソフトとしての基本的な部分はちゃんと動いています。
とりあえず突発的に近日中に公開する可能性あります。
- 226 名前：47 投稿日：02/05/04 22:53 ID:hD7cR1Vc main/1020264992.html#328
- 今のですと、ダウン対象の選択（どのノードから落としてどう転送させるか）は
完全に自動で、各ノードの接続状況やポートの空き具合によって決まりますが、
ダウンが失敗（相手の接続カットやタイムアウト）しても、新しい相手を見つけにいきません。
一度再検索かけるとまた最適化されますんで、対象ファイルをまたダブルクリックすることになります。
連続ダウンや自動ダウンができませんが、β１はこんなもんでどうでしょう。
ちなみに、
仮想ファイルをダブルクリック
→自ノードに転送して正常に転送できれば自動的にダウンフォルダに展開
キャッシュをダブルクリック
→キャッシュが完全であればダウンフォルダに展開
→キャッシュが不完全であれば残りの部分を自動的に他から落としてきて以下同様
ＵＰファイルをダブルクリック
→キャッシュに変換（ただし、ＵＰファイルはそのままで、キャッシュより優先なので変換した
だけでは意味ないです。手動でＵＰファイルを消すとキャッシュが見えるようになります）
このような操作系です。現状では起動すると勝手に接続に行きますので、
検索部で検索して見つかったファイルをダブルクリックするだけという
シンプルなインターフェイスです。あとＵＰフォルダ指定するぐらい。
- 227 名前：47 投稿日：02/05/04 23:01 ID:hD7cR1Vc main/1020264992.html#333
- えーと、ネットワークを壊す機能ですが、
正式版が上がるまではβ毎にプロトコルヘッダが変わると思うんで、
違うバージョン毎に独立したネットワークになります。
そもそも繋がりません。なので自動的に人がいなくなって消えるのではないかと。
>>268
>eDonkeyみたいにバーの色でファイルの各部位の進行状況を見れるようにはなってないんですね
なってまして、正常に読み込めたブロック別に色分けされますが、
あの画面キャプチャした時点ではダウン時の画面再書き換えしないバグが（ｗ
今では直ってます。
> ed2k://〜の様に直接ファイルにリンクを貼れるような機能
これは後回しですね。直接ハッシュからファイルをダウンしに行く機能も
まだだし、思ったより基本部分のバグ取りに手間取っていてここで出たような
周辺の実装をしている余裕がなかったりします。
- 228 名前：47 投稿日：02/05/04 23:09 ID:hD7cR1Vc main/1020264992.html#340
- >>335
今試しにアーカイブ作ってみたら170Kbyteでした。
exeと必要最低限の設定ファイルだけでヘルプ一切無しとなると思います。
即効でデリられる可能性もあるんで一応公開場所は二箇所確保してありますが、
転載は自由ですのでＭＸなりFreenetでなり適当にしてください。
- 229 名前：47 投稿日：02/05/04 23:12 ID:hD7cR1Vc main/1020264992.html#341
- どちらにせよ、連休中職場に忍び込んで複数台ＰＣでのんびりテストする
予定（家にはＰＣが二つ＋ノートが一つしかない）ので公開は早くても月曜です。
- 230 名前：47 投稿日：02/05/05 16:28 ID:vcRbUCGh main/1020264992.html#425
- とりあえずＬＡＮでのテストではほぼ問題なく動くようになりました。
ファイルをプチプチダブルクリックしていくとどんどんコピーされていくので
全ノードで直ぐに全て同じキャッシュ内容になります。
昨日の時点で動作が変だったのは、昔のシーケンシャルにファイル
読み込んでたときのコードが残っていて悪さしていたからのようです。
この辺を整理したのでプログラムがかなりシンプルになりました。
ただ、しーつこくファイルの転送を繰り返していると、
ファイルがロックされたまま（ＯＳ側でのロックではなく、作業中にキーが
どこかに行ってしまうとまずいんで行っている自前でのロック機構）
になって、プログラムを再起動しないとそのファイルが操作不能になるという
バグが残ってます。これは致命的ではないですが、たまに再起動する必要が
あるのは辛いのでまた見直します。単にどこかでのロック、アンロックし忘れでしょう。
あと、PORT0用のテストしてないんでこちらも確認しないと。
基本的に転送動作が基本なのでPORT0でも基本動作は同じですが、
キーの受け渡しが微妙に違うことになります。まだ動作確認してない。
キャッシュの容量制限は見直したけど、大規模に動き出したときに
大丈夫かなぁ。とりあえず初期テストではキャッシュは充分とるってことで。
- 231 名前：47 投稿日：02/05/06 15:49 ID:9nmsmZMp main/1020264992.html#659
- ここです
ttp://www.geocities.co.jp/SiliconValley/2949/
- 232 名前：47 投稿日：02/05/06 15:53 ID:9nmsmZMp main/1020264992.html#667
- βとなってますけど、実質α１ですのでよろしく。
昨日の時点でできてたんですけど、DebugじゃなくてReleaseにすると
変な動作する部分があって悩んでました。そんな感じでテスト不足かもしれない。
ＷＡＮで動くかどうかはともかく、現状のバージョンではポート変えれば
一つのＰＣで複数のクライアントが動かせるのでどういう挙動するのかテストしてみてください。
- 233 名前：47 投稿日：02/05/06 15:54 ID:9nmsmZMp main/1020264992.html#673
- ちなみに初期ノードが無いんで、ＷＡＮで接続テストするにはだれかがポート
さらさんとだめです。
- 234 名前：47 投稿日：02/05/06 16:00 ID:9nmsmZMp main/1020264992.html#685
- >>679
今確認します
- 235 名前：47 投稿日：02/05/06 16:05 ID:9nmsmZMp main/1020264992.html#695
- Downフォルダなんかの設定ですけど、変更ボタン押さないとだめですのでよろしく〜
- 236 名前：47 投稿日：02/05/06 16:08 ID:9nmsmZMp main/1020264992.html#708
- 人柱になるなら、適当なDNSもしくはポートアドレスを用意して
192.168.1.1:80などと書く。
設定モードのところにIPの暗号化の機能があるからそこで変換すると
@〜になりますのでこれを晒してください。
使うほうは接続のノード追加でその文字列を追加すればいいです。
- 237 名前：47 投稿日：02/05/06 16:13 ID:9nmsmZMp main/1020264992.html#728
- 接続はどうにかなるようなので
誰か少しだけファイルをＵＰしてここで教えてください
- 238 名前：47 投稿日：02/05/06 16:15 ID:9nmsmZMp main/1020264992.html#732
- あとプライベートＩＰな人(頭が192.168な人)はグローバルIPを
設定のところでホスト名にかかないとだめです。
- 239 名前：47 投稿日：02/05/06 16:21 ID:9nmsmZMp main/1020264992.html#752
- 何か落とせた人いますか？
- 240 名前：47 投稿日：02/05/06 16:22 ID:9nmsmZMp main/1020264992.html#763
- とりあえず拡張子で検索かけると出やすいと思います。
- 241 名前：47 投稿日：02/05/06 16:23 ID:9nmsmZMp main/1020264992.html#766
- あー、あとISDNの人は、ポート公開してるADSLの人でないと蹴られると思う。
- 242 名前：47 投稿日：02/05/06 16:43 ID:9nmsmZMp main/1020264992.html#844
- うーん、特定の部分でとまるのはブロック単位で転送してるからだと思います。
ＬＡＮとＷＡＮではレイテンシ違うんで何か見落としていた問題でもあるのかもしれない。
とりあえず、ＵＰフォルダにあるよりキャッシュ内のほうが安定しているんで、
ＵＰフォルダ内のファイルは自分で検索してダブルクリックしてキャッシュにしたあとに
ＵＰ公開止めたほうがいいかもしれない。
- 243 名前：47 投稿日：02/05/06 16:50 ID:9nmsmZMp main/1020264992.html#869
- えーとですね。まだチェックし切れなかった部分があったようなので手動での
対処ですが、回線申告をわざと低めにすれば負荷は下がるはずです。
その代わりファイルが見つかりにくくなるので、何も出てこないという方は
少し上げてみると良いのではないかと。
んで、ＰＣが耐えられないとバッファがあふれます。
- 244 名前：47 投稿日：02/05/06 17:20 ID:9nmsmZMp main/1020264992.html#944
- とりあえず挙動はとんでもなく変ですけど
接続はどうにか動いてるしキーも少しは出回ってるし（ここが一番怪しかった）
落とせる人もいる見たいだし（ここはダウンさせる側の問題が多いんでなんともいえず）
最低限は動いてるみたいです。けどさすがαって感じですねぇ(^^;
一番下に変な文字が出るのはどこかメモリリークか不正アクセスしとりますな。
- 245 名前：47 投稿日：02/05/06 17:29 ID:9nmsmZMp main/1020673454.html#15
- えーと、上流側の方が負荷がかかって飛びやすいと思うんで、
飛んだ方は回線設定を何にしてたか書いていただけると助かります。
- 246 名前：47 投稿日：02/05/06 17:44 ID:9nmsmZMp main/1020673454.html#48
- 先頭ブロックだけ読み込めてその後データが来ないのは次のようなことだと思います。
まず、転送先のホストに接続に行きますが、これは検索リンクを追いかけていけば
見つかる、今現在生きている可能性が高いホストなので大体繋がります。
次、このホストが本体を落としに行きますが、既に落ちてたり、ＵＰフォルダから
消したなどの理由で繋がらないとまずそのままタイムアウトします。
もしこの転送依頼されたホストがやっとデータもらえたとしても、あまり手間取っていると
そのころには依頼したほうがタイムアウトなりなんなりで切断となります。
転送の二番目のフェーズ（転送ノードがデータを落とせなかった）で失敗すると
先頭ブロックだけ来たように見えるということだと思います。
ほとんの場合、中身は空でしょう。
キャッシュが十分広まっていけば多少落とせるようにはなると思いますけど。
- 247 名前：47 投稿日：02/05/06 17:55 ID:9nmsmZMp main/1020673454.html#76
- 検索の要は光の方々ですけど、こちらはある程度動いているようなので、
ダウンがうまくいくかどうかはADSL8Mクラスの方々がキャッシュを十分とって
ポートをちゃんと空けてあとは時間が十分立つかどうかかと思います。
ダウンがうまくいくことがあるのでしたら、バグっているというより、
システムが安定していないだけの要素が大きいのではないかと。
- 248 名前：47 投稿日：02/05/06 18:16 ID:9nmsmZMp main/1020673454.html#140
- しばらく放っておく人が増えてくれば安定してくるはずなんですが
（そのまえにプログラムが落ちてしまうというオチが(^^;;;）
とりあえずWindows98系の人は参加しないほうが良いような気がします。
キーだけ流されて直ぐ落ちてしまうとロストキーばかりになって
ダウンが失敗しやすくなります。
- 249 名前：47 投稿日：02/05/06 18:34 ID:9nmsmZMp main/1020673454.html#194
- バージョンが古いうんぬんは時間見てるだけなんで
２０００年問題じゃないですかね？ＯＳなんでしょう
- 250 名前：47 投稿日：02/05/06 18:37 ID:9nmsmZMp main/1020673454.html#200
- 初期ノードが繋がらないのなら、誰かが
NoderefTemp.txtの中身を晒してくれると確実。
- 251 名前：47 投稿日：02/05/06 18:58 ID:atzJUrlH main/1020673454.html#248
- >>245
わけわかんなくなったら検索のところにあるリフレッシュ押してください。
あと、破損キャッシュというのはダウンする相手がいないキャッシュです。
検索押して受可キャッシュとして黄色くなるまで落とせません。
- 252 名前：47 投稿日：02/05/06 19:24 ID:atzJUrlH main/1020673454.html#304
- さすがにレジュームは実装済みです。
ただ、ダウンが失敗しやすい（バグというよりネットワーク上のキャッシュがほぼ０だから）
から低確率ｘ低確率でほとんど無理なだけだと思う。
- 253 名前：47 投稿日：02/05/06 19:37 ID:atzJUrlH main/1020673454.html#343
- なんとなくですが、せっかくユーザーさんが申請したのに、それとは違うポートに接続に
いっているためにダウンが失敗する率が高いということであってますか？
ＦＷ無くてポート晒していて、ＤＮＳ設定を入れてない人のところにしか
繋がってないのかもしれない。
- 254 名前：47 投稿日：02/05/06 19:48 ID:atzJUrlH main/1020673454.html#380
- あー、バグってる理由が分かりました。
いつもＬＡＮでテストしてるんで気が付かなかったけど、
ホスト名んところの解釈がバグってると思います。
なのでＧＷ越えの人はファイル転送のダウンを受け付けられてないんだと思います。
検索側は自分で接続にいくんで問題ないということでしょう。
修正しますのでしばらくお待ちを。ホスト名のところは設定しないで使ってください。
ダウンだけなら問題なくできると思います。
- 255 名前：47 投稿日：02/05/06 19:54 ID:atzJUrlH main/1020673454.html#395
- とりあえず現状で怪しいのはIPとPORT絡みだと思われますので、
詳しく見れる人は実験してまずい部分を報告していただけると助かります。
- 256 名前：47 投稿日：02/05/06 19:56 ID:atzJUrlH main/1020673454.html#400
- あとノードリストの切断ですけど、それは検索用のリンクなんで、２、３個
なのが正解です。４を超えても自分で切りに行きます。今ですとＵＰリンクが
２を超えたら接続動作はしなくなります。
ファイルダウンの時は別にコネクションにいくので接続数が少なくても
問題ないです。
- 257 名前：47 投稿日：02/05/06 19:57 ID:atzJUrlH main/1020673454.html#401
- >>399
切断ノードの削除は１０分ぐらいになってたと思うけどもっと早いほうがいいかも
- 258 名前：47 投稿日：02/05/06 20:33 ID:RHIpJpsI main/1020673454.html#481
- うーん、基本的に今のでも繋がるはずだなぁ。
とりあえず表記が悪くてすいませんが、設定のホスト名のところはDDNS使ってる
人以外は設定する必要ないです。書いてあると、再接続の時に繋がりやすく
なるだけです。
とりあえず今ここのところに何か書いてある人は消して再起動しといてください。
あともちろん、ルータ使っている人はポート８０にアクセスするとWinnyが動いている
ＰＣに繋がる必要があります。この辺はMXと同じですが、向こうとはデフォのポートが
違うんでよろしく〜。
- 259 名前：47 投稿日：02/05/06 20:47 ID:RHIpJpsI main/1020673454.html#520
- うーん、とりあえず現状の問題はルータの内部にいる人の場合に、
グローバルじゃなくてローカルでアドレスが行っちゃってるからだったりしますね。
ルータの設定で転送するようになっていてもこれじゃだめですわ。
対処しますので少しお待ちを。
- 260 名前：47氏へ 投稿日：02/05/06 21:01 ID:IlrCYOWZ main/1020673454.html#560
- winnyの使い方のホームページ作っていいですか？
- 261 名前：47 投稿日：02/05/06 21:06 ID:E47CKkfZ main/1020673454.html#575
- とりあえず現状では、ＮＡＴ使っていると、検索リンクで二つ以上離れているノード間は
どう設定してもそのＤＯＷＮ接続を受けられません。隣からは落とせますので、
極まれに落とせるのはそういう事情のようです。
そんなわけで、今現在はNAT使っている（ルータ使っている人は全員）
外部からの接続不可能ボタンを押しといてください。
とりあえずルータ内の人のファイルでも吸い出されていくはずです。
- 262 名前：47 投稿日：02/05/06 22:39 ID:mZAKE17s main/1020673454.html#812
- β２上げました。
ttp://www.geocities.co.jp/SiliconValley/2949/
変更部ですが、致命的なものと直すのが簡単な部分です。
致命的なものとして、ＷＡＮとＬＡＮでアドレスが違う場合に、
ＷＡＮのアドレスとすてＬＡＮのアドレスを渡しているという致命的な問題がありましたので、
ＮＡＴもどきの機能をWinny側にも入れて、接続時と申請されたIPで違っている場合、
自動的に内部でIPを変換するようにしました。
なお、プロトコルが変わったのでβ１との互換がありません。設定ファイルはそのまま
使えますのでexeを取り替えるだけですが、β２とβ１では接続不可能です。
あと細かいところとして、接続不能なホストが消えるのを少し早くしたのと、
検索で見れる結果数を少なくしました。本来はI/F周りを直すべきですが、
時間がなくて後回しになったのでとりあえず暫定です。
- 263 名前：47 投稿日：02/05/06 22:41 ID:mZAKE17s main/1020673454.html#817
- ああ、あと、ファイル転送用のUPリンク数制限にバグがあったのも直しました。
- 264 名前：47 投稿日：02/05/06 22:45 ID:mZAKE17s main/1020673454.html#835
- ああ、ホスト名とか暗号周りはそのままです。
プロトコルヘッダチェックで跳ねるてるんでバージョン違うと接続即断されます。
- 265 名前：47 投稿日：02/05/06 22:55 ID:mZAKE17s main/1020673454.html#867
- 基本的にDDNSんとこは書かないでください。WANからアクセス可能な
ポートさえ設定されていればいいです。
- 266 名前：47 投稿日：02/05/06 22:59 ID:mZAKE17s main/1020673454.html#878
- ああ、あと名前が＠のファイルは暗号化が解けなかったファイルです。
- 267 名前：47 投稿日：02/05/06 23:10 ID:mZAKE17s main/1020673454.html#918
- Unavailable cliant was connectedはプロトコルの違うバージョン間で出るメッセージです
実害無いので皆がβ２に移行するまで待ちましょう。
ところでβ１よりβ２のがファイル落ちますか？ルータ入れてるADSLな人など
からも落とせるようになったはずなんでダウン率がかなり変わるはずですけど。
- 268 名前：47 投稿日：02/05/06 23:28 ID:mZAKE17s main/1020673454.html#981
- >>979
理由がわからんのです
- 269 名前：47 投稿日：02/05/06 23:38 ID:mZAKE17s main/1020694396.html#80
- >>63
やってみます
- 270 名前：47 投稿日：02/05/06 23:55 ID:lH2oixOP main/1020694396.html#122
- β３です。
例のポート番号の上下がひっくり返っているとの報告でしたので直しました。
acceptとconnect両方ひっくり返ってたのでうまく動いてるように見えていただけのようで。
今回はプロトコルが変わっていませんのでβ２とは繋がりますが、
ダウン率を上げるために皆さん変更お願いします。
- 271 名前：47 投稿日：02/05/06 23:56 ID:lH2oixOP main/1020694396.html#133
- ああ、そういえば表示でのバージョン上げるの忘れた。
どうせまた直ぐ上がるから気にせんでください。
- 272 名前：47 投稿日：02/05/06 23:59 ID:lH2oixOP main/1020694396.html#139
- こっそり表示変更
- 273 名前：47 投稿日：02/05/07 00:04 ID:DDflrOcp main/1020694396.html#155
- バージョン表示はこっそり直ってます
- 274 名前：47は神 投稿日：02/05/07 01:16 ID:qL79aqwn main/1020694396.html#366
- ＞４７様
動作報告
フレ1.5Mbps
K6-2 500MHz
memory 64MB
ルータはずし、火壁OFF
で５０MB 転送できた ポト80でwebもOK
じゃ寝ます
- 275 名前：47 投稿日：02/05/07 02:10 ID:TflXya6r main/1020694396.html#476
- とりあえずの問題点は重過ぎることらしい（特に上流）ということで、
対策とっておきました。プロトコルはβ２，３と同じです。
あまりキーの転送をしないようになってますけど、
今度はキーが見つからない病気がでる可能性があります。
とりあえずどちらの方がいいかということでβ４は比較版です。
あと、中身が空のキャッシュは起動時やリフレッシュ時に自動的に消すように
しときました。
- 276 名前：47 投稿日：02/05/07 02:10 ID:TflXya6r main/1020694396.html#477
- んでは明日は仕事なんで寝ます
- 277 名前：47 投稿日：02/05/07 02:15 ID:TflXya6r main/1020694396.html#484
- β４で軽くなるのは検索リンクで一つ上の人なんで、
自分の下流の人が前のバージョンだとやはり重いはず。
プロトコルが共通なんで周りの人がどちらだか
分かりにくいと思いますが適当にテストしてみてください。
- 278 名前：47 投稿日：02/05/07 13:08 ID:RrbR/4SR main/1020694396.html#940
- 職場からです。連休篭ってずっとプログラミングしてたんで眠い。
とりあえず今週からは忙しいので、こればかり相手にしてられませんが、
皆さんのおかげでWANでの挙動が把握できたので順次対応していきます。
最悪、接続や検索部でトラぶって何も見えない可能性も高いと思ってたので
こちらとしては５０点です。
低確率でもファイルダウンさえ可能ならこの後のテストができます。
できれば本当はもっと小さな規模でテストしたかったんですが、
いきなり本テストになってしまった感じでキー処理の負荷が予想以上に凄いです。
何もしていないのにUP/DOWN転送レートが上がるのはファイル本体ではなく、
キー（ファイル名やその大きさの情報）転送だけで帯域を消費しているということです。
実際に動かしてみた人は分かると思いますが、このシステムでは検索は
ファイルのヘッダ情報だけを各ノードで行き来させてある程度共有させて
その転送にフィルタかけて見ているだけだったりします。
ですので、検索ボタンを押さないでも実はファイルが見えますが、
これは検索をかけまくっているわけではなく、キー管理上の仕様です。
ユーザ数が多いだけならそんなに問題にならないのですが、ファイル数が多いと
現システムでは不祥事が発生しやすい（無駄なキーの転送を減らすメカニズムが
まだろくに導入されていないのとノードのクラスタ化も甘い）んで、
多数のファイルをUPされるとどうしても変な動作します。
とりあえず動いてさえいればテストできますのでどうにか動作を安定させていく予定ですが、
しばらくかかると思いますので気長にお待ちください。
あと、やはりIF周りが後回しになったので使い難いとは思いますが、
ファイルが落とせないファイル共有ソフトは意味がないと思いますので、
基本エンジン部のチューニングを先にやると思います。よろしくお願いします。
一番初めに対処しないとなと思っているのは例の128k病（131072）でして、
Winnyでは処理の基本ブロックが0x10000（64k）ですがなぜかWANではこれの
二つ分で止まってしまうことが多いようです。
基本的に前に書いたように、転送相手には繋がったけど転送相手が
ファイル本体を落とせないという症状だと思いますので、対処しますが、
根本的な問題は、本体が既にロストしているのにキーヘッダだけが
延々と出回って消えないために、見かけ上落とせないファイルが
たくさん出来てしまっているということだと思います。
とりあえずダウン開始の部分は今まで何も解析していなかった見落とし部分なので
シミュレータ作って動作検証してみます。
- 279 名前：47 投稿日：02/05/07 13:32 ID:RrbR/4SR main/1020694396.html#959
- >>951
正直ここ二日の書き込みを把握しきれてないんで
気が付いてなくて申し訳ないです。
キャッシュの変換部分はWAN周りとは関係ないんで
十分テストしたつもりでしたが、手動でのキャッシュ変換は
途中からおまけ扱いになったのでテスト不足かもしれません。
こうすると確実に変だというのに気が付いたら教えていただけると
助かります。あと、確かに使っていると正常ダウンできたはずの
キャッシュが消えていることがあるようなのでこちらもテストします。
- 280 名前：47 投稿日：02/05/07 15:11 ID:RrbR/4SR main/1020745832.html#61
- 今暇が無い（＆気力も無い）んで個別に対応できませんが、
各自で接続しての報告ですとどこが悪いのか分かりませんので、
もし複数PCで起動してテストできる方がいらっしゃいましたら、
そちらでローカルで変な動作をする理由を探っていただけると助かります。
キャッシュ周りはどうも一つずつ消していくというバグがあるみたいですね。
あと、β４はあまりに動作が重いのでそれに対応してキー転送を
あまり行わないバージョンですので、ローカルでテストするのならβ３がお勧めです。
WANテストでも負荷が高くならなければβ３の方が動作が確実だと思います。
- 281 名前：47 投稿日：02/05/07 15:26 ID:RrbR/4SR main/1020745832.html#75
- うー、全部読みきれないけど、重要な質問に答えましょう。
キーにボディの位置が書かれているのかという質問ですが、
条件によります。
今のバージョンだとIPの下二桁とポート番号が出ていますので
ローカルで実験すると分かると思いますが、
本体の位置＝キーに書いてあるIPの場合もありますが
そうでない場合もあります。
そうでない場合、キーに書いてあるIPの先のホストの中の同じハッシュのキーが
示しているホストに本体があります（正確にはある可能性が高い）
この辺はキー転送の結果として実現されているので、
バグっているとポインタ先がループしていたりロストしている可能性も
ありますが、混雑していなければ、手持ちの仮想ファイルの
示す位置にある仮想ノードが指す位置にキャッシュファイルか
UPファイルがあるはずとなります。
ダウンに失敗する理由の一つがこの辺にもあると
思いますので暇な方は動作を確認されてください。
- 282 名前：47 投稿日：02/05/07 16:08 ID:aSpcbCx0 main/1020745832.html#93
- >>78
> つまり、キーに書いてあるIPが本体を持たない中継ホストだった場合は、
> 中継ホストがまたキーを見て書いてあるIPに要求する、という事ですね。
あまりばらすのも何ですが、現状の検索と接続相手を決定するメカニズムは
１．ノードが検索リンクで接続するとＵＰフォルダやキャッシュ内のキーが上流ノードに流れる
２．下流から来たキーでもし手持ちに内容の同じＵＰファイルやキャッシュがあったら上書き
３．そのまま上流にキーが流れていってループにぶつかったら終了
４．下流からファイル検索要求があったらそちらに該当するキーを流す
５．検索結果が下流に流れていく間に同じ内容のキャッシュを持っていたら上書き
６．検索相手に到達
こうなりますので、中継を起こす相手は、ＵＰする側とＤＯＷＮする側を
検索リンクで上流に遡っていってぶつかったところになります。
ＤＯＷＮ側がＵＰ側のキーを発見するのがこのクロスポイントで、
中継ノードでそのキーのＩＰはＵＰ側のＩＰ、
ダウン側からそのキーのＩＰを見ると、中継ノードのＩＰとなっています。
この状態でダウン側のノードがダウン要求を出すと、ダウンフォルダ内の
キーのＩＰを見て中継ノードに到達し、中継ノードは要求のあったファイルが
仮想ファイルであるので、これにダウン要求をかけＵＰノードにダウン接続をかけます。
あとは、転送ノードにデータがくるたびにダウンノードにファイル受信パケットを転送してきます。
- 283 名前：47 投稿日：02/05/08 02:17 ID:RKRBWjxb main/1020745832.html#499
- そろそろ眠いんでβ５です。以下修正点。
なお、プロトコルがまた新しくなったので前のとは繋がりません。
・キー転送量の削減と切断されたホストのキーを殺すことによるキーヒット率向上
・表示でのチラツキを抑えた
・Port0で検索に失敗するのを修正
・負荷が重い状態のときに終了すると飛ぶのを修正
・ダウン開始時に128kだけ落とせたように見えるのを修正
・ダウン中にダウン率が後退しているように見えるのを修正
・キャッシュサイズを表示。あとロックされているキャッシュは無視。
・切断して時間の経過したノードを隠すようにした
・転送率メーターの変化率を落とした
・キャッシュの容量の計算ミス（破損キャッシュの残りの部分も入っていた）を修正
- 284 名前：47 投稿日：02/05/08 02:44 ID:RKRBWjxb main/1020745832.html#531
- β３までは無駄なキー情報まで送っていたのでファイル転送量が多すぎてトラぶっていましたし
β４は逆でしたが、β５では本体が無くなったキーを検出して落とせないキーを極力
消えるようにして、あと無駄なキーの転送を極力抑えてます。
ノードが増えてくるとまた重いかもしれませんが、キーの転送量はまだまだ減らせますので
様子見てやります。ゴミキーが消えやすいことで結果的にヒット率が
上がってくれるとうれしいですね。
- 285 名前：47 投稿日：02/05/08 03:36 ID:RKRBWjxb main/1020745832.html#584
- 後ろ向きな対応ですが、キャッシュが働かないのは
ダウンできないゴミキーが出回る理由にもなって
致命的なので暫定的にこの機能を外したものも上げておきました。
- 286 名前：47氏を応援しよう 投稿日：02/05/08 16:18 ID:+eRiu0Rh main/1020745832.html#839
- 話に関係なくて申し訳ないんですが
バグ報告は別に
「MXの次はなんなんだ？バグ報告専用β１」
とかいうスレッドをたててそこに集中させるか、
ttp://node.s12.xrea.com/bbs/treebbs.cgi
こことかしませんか？
ほんとはこのスレッドがバグ報告スレッドのはずなんですが、
雑談や質問なんかにまみれて
バグ報告だけを見つけるのは大変だと思います。
（実際１００件に２，３件しかバグ報告ないし）
前にあっちこっちにスレッドとかページ作んのは
やめてくれとかいう人がいましたが
そうゆう人はバグ報告なんかほとんど見る
必要はないんだから、問題ないのでわ？
（というかバグを把握する４７氏の視点にたってないし）
ここにバグ報告があったとしても、気づいた人がバグ報告用のスレッドにコピペしたら
もっと分かりやすくなると思います。
こんな提案どうでしょう？
>>833
ほしい
- 287 名前：47 投稿日：02/05/08 23:15 ID:OZr+AG2q main/1020852482.html#101
- β６です。プロトコルは実はβ５と同じなのですが、一緒に使うと
とんでもない転送量が発生する可能性があるので繋がらないようになってます。
ちなみに、まだキャッシュ消去周りの挙動は直してないのでβ5.1と同じです。
修正は以下
・設定関連のインターフェイスを変更
・システム情報表示を追加
・ダウン対象決定の際にキーの消去タイマーを考慮することでダウンヒット率向上
・ダウンできない無効キーの消える率を向上
・キーリスト送信を抑えてキー転送量を削減
・プロトコルヘッダチェックでコネクション毎のチェックになっていなかったのを修正
・各バッファのメモリ確保を高速化
・接続ボタンのステート表示を逆にした
・ＵＰフォルダスキャン中にリフレッシュすると落ちるバグを修正
・フォルダ追加でパスが空だとc:\以下を全て公開してしまうのを修正
- 288 名前：47 投稿日：02/05/08 23:54 ID:OZr+AG2q main/1020852482.html#142
- あー、やばいかも。クエリがあふれてるような気がする。
- 289 名前：47 投稿日：02/05/09 00:20 ID:U9fy9lkd main/1020852482.html#201
- すいません。β６はヒット率上げるために念のため入れておいた一行が悪さして
無限クエリを作ることがあるようです。すいません危険ですので6.1にしといてください。
- 290 名前：47 投稿日：02/05/09 00:37 ID:U9fy9lkd main/1020852482.html#232
- うーむ、いつのまにかDown側の検索リンク制限が効かなくなってる気がしますね
- 291 名前：47 投稿日：02/05/09 00:40 ID:U9fy9lkd main/1020852482.html#239
- こりゃユーザ数が増えすぎて初期ノードに近い人のところにコネクション集まりすぎて
ノードリスト転送が追いついてないかもしれず。とりあえずこちらは時間が立てば
収まると思いますので、新しくついたシステム情報のところで変な理由を探ってください。
キーに関しては、上流から来たキーが上方仮想キーで、
下流から来たのが下方です。
これ見てるとシステムがばれてしまっていやなんですけど・・・・
- 292 名前：47 投稿日：02/05/09 00:49 ID:U9fy9lkd main/1020852482.html#254
- なぜかポート番号とキャッシュ関連の容量とダウンフォルダ位置の設定が飛ぶようです。
これらの値は起動時にしか書き換えないんでどこか不正アクセスですな。
変なところにアクセスに行くのはこれのせいか・・・
とりあえず原因を探りますが、この現象が出たらプログラム再起動しかないです。
あと、何か上流側で検索を当てない限り上方のキーは０です。
昔は検索にかからないのも転送してたんで重かったんですが、
β６では無駄なものは一切転送しないようになってます。
- 293 名前：47 投稿日：02/05/09 00:58 ID:U9fy9lkd main/1020852482.html#269
- 前のバージョンだとキーがなかなか消えなかったんで、見かけ上ファイルがあるように
見えただけで実際はほとんどがロストキーでした。今だとキーは直ぐに消えていくので
検索できさえすれば、その直後にダウンかければ落ちる可能性高いはずです。
- 294 名前：47 投稿日：02/05/09 01:11 ID:U9fy9lkd main/1020852482.html#293
- >>288
ここのところ暇が無くて２ｃｈは見てなかったので気が付きませんでした。
チェックしてみます。
- 295 名前：47 投稿日：02/05/09 01:27 ID:U9fy9lkd main/1020852482.html#316
- 上流ノードだと、上流からきても下方キーになる可能性もあります。
そこだけ見ていてもどこからキーが来たのかわかんないです。
検索のときに消しても良いかどうかの判断なんで私以外に意味わかんないと思うし。
どちらにせよそのうちそこは上下足しちゃうか消すと思う。
しかし家の環境ではＩＰ先頭が１になる現象がみれん。うーん・・・
- 296 名前：47 投稿日：02/05/09 01:49 ID:U9fy9lkd main/1020852482.html#345
- うーん、思った通り今度はダウンはできるけど見えないという問題がでますか。
そのために入れた対処のせいでβ６みたいなことになったし、
面倒だけどクエリパケットもう一種類作んないとだめですねぇ。
これの対処は面倒なんで少しお待ちを。
- 297 名前：47 投稿日：02/05/09 01:58 ID:U9fy9lkd main/1020852482.html#354
- ファイル本体はそのままでキーの部分だけFreenetのようにノード間をたらい回しして、
ダウン要求があったらそのとき初めてリンク追っかけて本体を垂れ流ししてもらうというのが、
Winnnyの基本的な考え方ですけど、あまりキーをたらい回ししてると
今度は本体がどこか行ってしまってロストするという罠(^^;
今だとロストしにくいように検索でキー集めてきて関係ないキーは死んでいくようになってますけど、
今度は遠くのノードが自分のところまでリンク切れしないで届く可能性が低いという・・・
- 298 名前：47 投稿日：02/05/09 02:36 ID:U9fy9lkd main/1020852482.html#386
- 正直、NATやDDNS絡みは、どう設定したらいいか作者も把握できてませんが、
これ絡みでやっていることを書くと次のようになってます。
１．まず、適当なノードに検索リンクでコネクションに行きます。
この時に使うIPとポートはNoderefに書いてある例の暗号です。
２．検索リンクで接続すると、接続された方は相手のグローバルIPが分かりますので、
これをノードのグローバルIPとして記録しておきます。
この時点で接続してきた相手のポート情報は分かりません
（表示の上では０になってます）
３．検索リンク間でお互いのノード情報を交換します。
交換する情報は、回線速度と接続に用いるポート番号と例のDDNS情報と
自己申告のIPアドレスです。これは接続してきたノードが自分のノードの
IPを取得した値（つまりローカルＩＰ）です。
あと、外部からの接続か可能かどうかもここで申告します。
４．もし相手の申告してきたIPとAccept時に取得したIPが違っていたら
そのノードはNAT経由とみなしてNAT野郎フラグ付けときます。
５．もし他のノードから他のノード情報を要求された場合、DDNS名が空でないノードなら
DDNS名とポート番号を知らせます。ネゴの結果、DDNS名が空のノード情報の場合、
グローバルIPとポート番号を知らせます。
６．他のノードとキーのやり取りをする場合ですが、キーには本体の位置がＩＰとポートの
形式で書いてあります。ここで、もしNATフラグがついているノードから来たキーの場合、
そこに書いてあるＩＰと相手が申告してきた自分のＩＰとを比較します。
もし同じならそれはキャッシュかＵＰファイルなわけですが、それはローカルＩＰなんで
グローバルＩＰに書き換えます。逆に、もしそのノードにキーを渡す必要が出て、
そのキーが相手のグローバルＩＰなら相手のローカルに変えて渡します。
あと、もしキーを送ってきたノードがPort0申告しているノードだったら、そこから来たキーの
ＩＰは全て自分のノードのＩＰに書き換えて他に送ります
（変換は渡すときだけ、手持ちのキーのＩＰはPort0申請ノードのまま、そうでないと転送動作にならない）。
これにより、Port0への転送リンク接続はかからず、自分のノードのところに来るようになります。
port0設定で動作が変わるのはここだけです。
６．キーに対してダウン要求がかかったら、キーに書いてあるIPとポート番号のノードに
転送コネクションをかけます。これは常にグローバルＩＰです。ただし、本体が
そこにあるかどうかは分かりません（違ってたら向こうのノードで同じことが起きて転送になる）
相手がルータ越しの場合、検索リンクで繋がっているノードから見たIPアドレス＋
ファイル本体を持っているノードが申告したポートのところに繋がることになります。
もしPort0申告していたら、隣のノードが身代わりしてくれてるはずなんで
そちらに繋がります。
７．ここまででDDNS名はまったく使っていませんが、もしこれを受け取っていたら、
終了時にNoderefTemp.txtファイルにIPの代わりにこれを書いときます。
次に検索コネクションをかけるときに、もしDDNS名が空でなければgethostbyname（相当）
のAPIでIPを調べて、そこに接続にいくことになります。
以上、こんな感じになってますので、どう動作するかは各自の判断でお願いします。
- 299 名前：47 投稿日：02/05/09 02:42 ID:U9fy9lkd main/1020852482.html#393
- 修正
６の
> もし同じならそれはキャッシュかＵＰファイルなわけですが
これ間違いました。キーのIPと相手のIPが同じでも中身が仮想キーの可能性があります。
相手の下流にPort0野郎がいてもそうなりますし、相手のノードが比較的
ＵＰ側に空きがあって転送動作してもいいよというときにも同じになります。
- 300 名前：47 投稿日：02/05/09 02:49 ID:U9fy9lkd main/1020852482.html#397
- なんでDDNSにグローバルIP書くとファイルが
落ちやすくなるのか良く分からなかったりする作者であった（ｗ
- 301 名前：47 投稿日：02/05/09 03:11 ID:U9fy9lkd main/1020852482.html#423
- 上流にいるほうがダウンに成功しやすいはず
（下流のノード間ほど転送動作が発生しやすい）だけど
現状では上流ではクラッシュもしやすいという諸刃の険・・・
えーかげん怪しい部分を直さないとキャッシュ広まらなくて
その真価が見えてこないですねぇ。
検索ヒット率もダウン速度も全てキャッシュヒット率にかかっていて、
前に書いたようにキャッシュさえ十分に広まればパフォーマンス的に
ＭＸを超えることも可能なはず（ＭＸでは相手が選べないけど
Winnyでは基本的にダウン相手は自分より高速回線）
だけど、キャッシュが広まらないと単にファイルが落とせない
ファイル共有システムでしかなし。
とりあえず、寝よう。
- 302 名前：47 投稿日：02/05/09 04:28 ID:sxPn0vEE main/1020852482.html#461
- うーん、結局例のNAT絡みが気になって寝てない。
当分の敵はFWですなぁ。
とりあえず、例のDDNSに書くとなぜか繋がるということから、
ダウンリンクが繋がらない理由が思いついたです。
検索リンクの上下は速度で反転しますけど、グローバルIPとローカルIP両方しってるのは
接続を受けた方だけなんで、リンクの上下が反転して接続かけた方が検索リンクの上流に
なったときに接続不可能なキーが生成されてしまうということなんじゃないかと。
ちと見直してみよう。
- 303 名前：47.195 投稿日：02/05/10 00:11 ID:JsAVZ9u/ main/1020852482.html#970
- ttp://slashdot.jp/article.pl?sid=02/05/09/1115215&mode=thread
- 304 名前：47 投稿日：02/05/10 01:19 ID:xIt6XkCC main/1020956839.html#125
- β7です。主要なバグは取れたと思いますが、
大規模に書き換えましたので別の問題点や凡ミスしてる可能性あります。
あと、通信負荷的にはβ6.1より重いはず。
・タスクの再試行機能を追加
・Uploadタスクを表示（暫定処置かもしれず）
・表示で変な文字がでるのを修正
・ポート番号情報などへのメモリの不正アクセスを修正
・キーの寿命を長くすることで見えないファイルを少なくした
・ダウン対象選択はβ6.1方式、キー検索方式をβ5.1方式に変更
・ノード数が増えて接続要求が多いと下流検索リンクが切りきれないのを修正
・正常にネゴできたノードデータのみ他ノードへ転送するように修正
・正常にネゴできたノードは消えるのに時間がかかるように修正
・高速回線申請ノードだとポートスキャンしてしまいやすいのを修正
・キーワード表示を止めた
・初期ポートを7743にした
・Port0設定のノードからのUPは検索ノードを使ってデータ転送が行われるように修正
・DNS参照失敗後に1.xx.xx.xxにコネクトかけることがあるのを修正
・ファイル転送の高速化
- 305 名前：47 投稿日：02/05/10 01:21 ID:xIt6XkCC main/1020956839.html#129
- ああ、そういえば失敗したタスクをダブルクリックすると自動的に再試行するようになってます。
それとPort0申告しるノードとのファイルのダウンは全て検索リンク内部を経由するように
なってますんで、繋がらないというトラブルは出ないと思います。
- 306 名前：47 投稿日：02/05/10 01:23 ID:xIt6XkCC main/1020956839.html#133
- ああ、あとプロトコル的には6.1と繋がらないです。
- 307 名前：47 投稿日：02/05/10 01:54 ID:xIt6XkCC main/1020956839.html#187
- >> 回線速度に上流と出るのはなんですか？
表示だけなんでこっそり直しました(^^;
- 308 名前：47 投稿日：02/05/10 02:10 ID:xIt6XkCC main/1020956839.html#216
- うーん、やはり重いですか。仕方ないからキー転送部だけ6.1に戻すか・・・
- 309 名前：47 投稿日：02/05/10 02:12 ID:xIt6XkCC main/1020956839.html#222
- DOWNタスクはファイル単位で生成されますけどUPタスクはブロック単位です。
だから表示してもファイルの一部分転送なんでそうなります。
その表示は実験的なものなので直ぐに消すと思います。
- 310 名前：47 投稿日：02/05/10 02:15 ID:xIt6XkCC main/1020956839.html#232
- β6.1だと遠くが見えないんで直したけどやっぱりだめですか。
199氏のバグ直したんで検索部戻して7.1にするか・・・
- 311 名前：47 投稿日：02/05/10 02:50 ID:xIt6XkCC main/1020956839.html#294
- 一度も転送されたことが無い人は単に外部から申請したポートにコネクションできなくて
周りに迷惑かけているだけの可能性が高いです。試しに外部からの接続ＯＦＦ入れてみて
ください。このオプションはＵＰ動作が変わるだけでダウンは変わりません。
あと表示ですが、
DDNS：設定で名前指定してあるノード
NAT：ローカルとグローバルでＩＰが違うノード
Port0：設定で外部接続が不可能と申告しているノード
Raw：その他
です。
- 312 名前：47 投稿日：02/05/10 02:58 ID:xIt6XkCC main/1020956839.html#302
- 向こうのノードがどうなっているか分からないので、
失敗する正確な理由は簡単にはわかんなかったりする罠
ちゃんと通信できれば失敗の理由が転送できますけど・・・
とりあえずコンソールにダンプすればいいんでこちらの手持ちで
ある程度は分かりますが、向こう側がなぜ応答してくれないかは謎。
- 313 名前：47 投稿日：02/05/10 03:01 ID:xIt6XkCC main/1020956839.html#304
- 簡単に言えば、現状で重くなる理由は単に出回っているファイルが多すぎるという
その一点だけなので、これを制限すればもっと軽くなるはずです。
何も考えずにＭＸのフォルダを指定している人は制限していただけると助かります。
- 314 名前：47 投稿日：02/05/10 03:38 ID:xIt6XkCC main/1020956839.html#330
- キーの管理は実はＭＸと似た方式になってるんではないかと思ってます。
鯖と親と子があって親が子の面倒見てファイル名をストックしてこれを鯖が
管理しますけど（一部推測）、Winnyでは、似たようなレイヤが結果的に
出来上がるだけで基本的には同じです。
大規模になると、上下階層の深さはそのままで、横方向に大きくなっていきます。
問題点は、遠くのファイル（上層ノードが異なるノードのファイル）が
見つかりにくくなっていくことです。
だから大規模になってもどうにかなるとは思いますが、
今ですと高速回線申請すると多くのノードがキーを送りつけてきて
メモリがあふれてしまいます。早い回線＝メモリ豊富とは
限らないので、上層ヘビーではなく、中層ヘビーに調節しないと
だめなんだろうなぁと。
- 315 名前：47 投稿日：02/05/10 04:11 ID:SVtHh5Na main/1020956839.html#345
- 寝ないとまずいけど今日の午前中寝てたんであんまり眠くない（ｗ
>>333
キーの管理だけどβそれぞれでいろいろでしてどれがいいか探っているところです。
細かいところ忘れちゃってるけど、β１は333氏が書いてるのに近かったはず。
下流に流れていく間に同じものがあったら上書きされていきますけど、
それは途中のノードでは展開しません。クエリ出したノードまで全部行きます。
ここはβ全部で同じかな。
今のβ７はβ１に戻ってきている部分があって、違うのはキーに寿命があって
時間が立つと消えることと、消える時間に合わせて下から上にキーを全部
送っていることです。これのせいで重い。あと、転送先の決定がかなり
複雑になってます。キーの寿命見て新しいほど本体にあたる率が高いということで
そちらを優先します。
確か、β１や２ではキーに寿命が無くてノード切断に合わせてキーが
消えることを期待したけど、結局キーがたらい回しされて消えないで、
本体の位置をロストしてファイルは見えるけどさっぱり落とせない状況に。
β３や４辺りではキー寿命が入ったせいで本体ロスト率が減ったけど、
キーが消えていくんでいちいち送り直す必要があって遅いし、
結局本体はロストするんで重くなっただけ。
β５あたりでキー寿命考慮して選択対象選ぶようにしたんで
落とせるようになってきて、β6.1で検索を下にも飛ばして、
キーを単純に上に流すのをやめることで、負荷を下げて、
キーと本体の距離を短めにしてダウン率を向上。
でもこれやると見えないファイルが出るんで、
β5（キー寿命考慮しての検索）とβ６（ダウン率向上）を合わせて
いいところどりできないかと試してみたのがβ７だったりします。
こんどは中層ヘビー（三階層を考慮してキーは中層に集めて上から支持する）
にしてみようかと思ってたりしますけど、完全に試行錯誤ですねぇ。
- 316 名前：47 投稿日：02/05/10 04:14 ID:SVtHh5Na main/1020956839.html#346
- >>342
今現在でそんな感じです。クエリに検索要求書いて送るとクエリ内部が置き換わっていって
キーがパックされていって戻ってくると該当キーがつまっているといるので、
最後に展開するという感じです。
- 317 名前：47 投稿日：02/05/10 04:39 ID:SVtHh5Na main/1020956839.html#350
- キー数が予想より多くて、単純な階層構造のネットワークでは
キーの保持だけで上流側のＰＣがあふれてしまうみたいなんで、
当初の設計である、
上層→キーの保持、中層→キャッシュ保持、下層→ファイル提供
ではなく、
上層→コネクションの受け付けと中層への接続割り振り
中層→キーの分散保持とキャッシュ保持
下層→ファイルとキャッシュ提供
の方向性に持っていこうかと思ってきました。
既に上流の方ではメモリぎりぎりでキーを受け持ってる状態なんで、
下層のファイルをMXと同じで１０００個程度限界と仮定し、
中層ノードにこれらを１０程度ぶら下げて担当下層ノードのキーを全て
持たせる（キー数１万ぐらい）で、各所から出てくるクエリは
中層ノード網でクエリを一周させて結果を下流に流す。
上層はアドレスが変わりにくいだろうということで、
キーの相手は一切しないで中層ノードの管理に徹してもらって、
コネクションを裁いてもらうのが良いのではないかと。
ＭＸみたいですけど、役割が動的に決まるんで
グヌテラとナプを混ぜたみたいになりますね。
ここまでできてればプログラム的には結構簡単に対応できます
んでキー管理周りはそういう方向性に持っていこうかと思います。
- 318 名前：47 投稿日：02/05/10 13:44 ID:yzBDBm21 main/1020956839.html#389
- キー管理をどういう方針に持っていくかでつらつら考えていたんですが、
図にしてみるとこんな感じになります。
ttp://www.geocities.co.jp/SiliconValley/2949/Key.gif
当初の予定では高速回線の人を上に持ってきてキー管理を集中させようと思ってましたけど、
上流ほどキーが集中するんでメモリ消費とCPU負荷が凄くなって、皆が上流を避ける。
この状況で遠くのファイルも見えるようにキーを垂れ流すと全ノードが重い（β７）
キーを遠方ノードに広めようとしなければ比較的軽くなりますが、
やり取りがローカルな部分に制約されてしまい落とせるファイルが
たまたま隣接したノードのものに限られてしまいます（β6.1）
そんなわけで、うまくクラスタ化されれば良いだけだとも思われますので、
一つの案として、今現在の性能申告以外にもう一つ、好きな分野もユーザさんに
申告してもらって、今の速度による接続決定と同様にジャンルでも接続を調節して
上流ノードは円状に分布してもらうというのが良いのではないかと思います。
ジャンルは一つの実数で示しますがこれはサイクリックなのでモデルとしては図のような
円柱モデルになります。各ノードやは速度とジャンルの二つのパラメータで
円柱表面のどこかに位置することになり、キーは上の円上に分布します。
ノードは得意な分野の下にぶら下がりファイル提供。キーはやはり上流に貯めておいて、
クエリはこの円上を左右に流す（実際はショートカットが生じますので網ですけど）となります。
キーは真上方向と左右少しだけにのみ流れるので各ノードの負荷は比較的軽いですし、
指定した分野のファイルはほぼ見えることになります。ノードが増えてきたら、
分野をより細かくしてノードの分担を特化させて対応することになります。
回線の早い人は上流というよりは、人気があって多数のクライアントをぶら下げる必要のある
負荷の高い領域の上流側を担当してもらうことになります。
これですと反対側のジャンルのファイルがまったく見えませんが、あまり困らないと思いますし
必要に応じて一度落ちてノードの位置を変えることになります。
匿名性とキー検索速度とパフォーマンスを両立させる代わりに、
検索で全部のファイルが見えるのを諦めることになります。
と、この方針で実際にコード書き換え初めてますけど、増えるのは検索に分野の指定がつくこと、
ノードにも好みの分野の設定があるということです。あとフォルダ単位での分野範囲がつきます。
検索分野の指定は自分の位置と逆方向だと何も出てこないの無くても良いかもしれませんが・・・
あとここで言っている分野ですが、内部的には０から１の実数で円柱における円周方向です。
０から１では分かり難いので今では表示させるときに24倍して、時刻に見えるようにしてます。
ので、現状ではジャンルは１時とか１２時とかの時刻指定になってます。
どの辺が実際に何のジャンルになるかは、どれとどれが隣接分野になるかを考慮して
使用者の間で適時決めてくださいということで。ジャンルは連続しているので中間領域もありです。
と、こんなもんでどうでしょう？
- 319 名前：47 投稿日：02/05/10 14:05 ID:j2+W0+ef main/1020956839.html#398
- >>394
ジャンルわけできないジャンルというのを作るしか(^^;
どちらにせよ、これやらないとファイルの増加に対応できませんし。
あと複数のジャンルを公開している人は複数の円状へコネクション張ることになると思いますが、
良く考えたらノードそれ自身の好みというのは必要なくて、
フォルダの分野タグだけから決めれば良いのかな？
- 320 名前：47 投稿日：02/05/10 14:07 ID:j2+W0+ef main/1020956839.html#400
- ジャンルは今の設計では実数一つです。今だと0〜24です。
これだと意味不明なんでここら辺が何とみんなで決めることになりますね。
- 321 名前：47 投稿日：02/05/10 14:08 ID:j2+W0+ef main/1020956839.html#402
- ただし、普通の実数と違ってサイクリックなんで、領域が限られていて、
反対側に行くと元に戻ります。
身近なところでは、時刻とか、角度とか、色相なんかですかね。
- 322 名前：47 投稿日：02/05/10 14:24 ID:TTFUeNL0 main/1020956839.html#414
- 方向さえ決まればいいんで、どこにラベルがつくのは好き勝手です。
実数なんで、特定のジャンルが混んできたら細分化してやればいいです。
１のところなら1.1,1.2,1.3に分けて以下同様などです。
- 323 名前：47 投稿日：02/05/10 14:33 ID:TTFUeNL0 main/1020956839.html#422
- ある程度分布が分かれてくれないと意味がないんで、
分野分けは二極化もしくは三極以上の多極化されると助かります。
サイクリックになているのはそういう事情で、
常に１２時近辺にデータが流れていたのではそちら側があふれます。
０時と１２時に一番のピークがあって綺麗に分かれるなどが望ましいです。
- 324 名前：47 投稿日：02/05/10 14:37 ID:TTFUeNL0 main/1020956839.html#428
- あと時間にしているのは一番身近だからであって、
２４でないとだめということは無いです。内部では0〜1の実数なんで
適当にマップしてやるだけです。0〜360にして角度でもいいし、色をHSVで表して
色相なんかでもいけるでしょうし、もっといい例えがあるかもしれません。
ただし普通の数字での分類と違うのは、上で書いたように反対側という概念
があることなのでよろしくお願いします。色相や角度で分かると思いますが、
必ず反対側というものが存在します。
- 325 名前：47 投稿日：02/05/10 14:38 ID:TTFUeNL0 main/1020956839.html#429
- 選択はもちろん分野選択になると思うけど、プログラムの方には組み込まずに、
分類分けファイルを読み込むことになると思います。
0 〜
0.1 〜
1 〜
こんな感じ
- 326 名前：47 投稿日：02/05/10 14:45 ID:TTFUeNL0 main/1020956839.html#438
- >>433
それは作るの楽だなぁ(w
使うほうは意味不明そうだけど。
>>420
濃度に関しては実数だから概念的にはアレフだけど、
実装は単なるfloatなんで32ビット整数と同じ濃度ですね。
0〜1だと何通りかな？
- 327 名前：47 投稿日：02/05/10 14:51 ID:TTFUeNL0 main/1020956839.html#443
- >>439
そんなのりで並べてもらえると助かります。
- 328 名前：47 投稿日：02/05/10 14:54 ID:TTFUeNL0 main/1020956839.html#446
- 分類といってるけどこれが必要なのはどれをどっちに流せばいいかを
全体見ないでも決められるようにするのに必要というだけなんで、
値の大小さえ比較できればその意味はなんでも良かったりします。
- 329 名前：47 投稿日：02/05/10 15:01 ID:TTFUeNL0 main/1020956839.html#449
- >>441
> 逆に該当ジャンルの仕分けや１ジャンルあたりのノード数が少なくなる可能性はありませんか？
いや、明確にこのジャンルというわけではなく、この辺担当って決められればそれでいいんで。
> 隣接ジャンルも検索されればありがたいとおもふ
まさにこれをやるためにジャンルを実数にしてたりするわけです。
今ですと検索も全個所でやる必要があり、キーも全部流す必要がありますが、
ジャンルが特定できれば、検索パケットの展開は目的ジャンル担当の
のノード近辺だけでやればいいし、他に流すキーも取捨選択できます。
- 330 名前：47 投稿日：02/05/10 15:06 ID:TTFUeNL0 main/1020956839.html#456
- >>450
ジャンル毎にキー（ファイル情報）を溜め込んでいるノードができます。
これはある程度の幅を持ちますので、穴ができたら周辺ノードが代わりします。
で、特定の分野のファイルを求めるノードがそこに集まってきて優先的に
接続することになります。
あと、今と同じで集まるのはキーだけで、本体は各ノードにありますので、
転送は各ノード間で行われます。ただし、キーを保持していると
転送対象になりやすいので、申請した分野のファイルが自動的に
キャッシュに集まってくると思われます。
- 331 名前：47 投稿日：02/05/10 15:07 ID:TTFUeNL0 main/1020956839.html#457
- >>454
完璧でふ
- 332 名前：47 投稿日：02/05/10 15:10 ID:TTFUeNL0 main/1020956839.html#458
- あと、この図の円部分を拡大すると当初案みたいに網に繋がることになります。
ttp://www.geocities.co.jp/SiliconValley/2949/Key.gif
こちらの予想より網の規模が大きくなりそうなんでそれに対応するための案ですね。
- 333 名前：47 投稿日：02/05/10 15:18 ID:TTFUeNL0 main/1020956839.html#463
- >>459
>たとえば6時間離れたところまでキーは届くようにするつもりでしょうか
届くけど、クエリが戻ってくるころにはダウン不可能なキーばかりになってるんではないかと。
というか、無意味なんで切りそうです。ネットワーク規模が大きくなるほど、離れた分野の
ファイルは見えなくなりそうです。これの問題は、それより匿名性の低下ですかね。
あと、二つ検索したければ二つリンク張るだけなんで問題ないと思われます。
問題は、二つの分野のキャッシュを担当したいという場合ですが、
これはＰＣ分けないと無理になりそうです。
> RecvBuffer is overflow
これはそのまんまで、通信用のバッファあふれです。
キー転送かクエリの転送量が多すぎるんでしょう。
- 334 名前：47 投稿日：02/05/10 15:23 ID:TTFUeNL0 main/1020956839.html#467
- >>464
動的な移動はまずいかなぁ・・・今の速度と似た扱いですので。
今の速度と合わせた二次元情報でノードを分類してやろうという扱いになります。
とりあえず、再起動時にキャッシュやＵＰファイル内容見てその
トータルの評価値でじわじわと動いていくといいかもしれません。
これならジャンル知らないでも勝手に自分の好きなところに移動しそうだし。
っと、そろそろこっちやってるとまずいんで抜けます。
- 335 名前：47 投稿日：02/05/10 15:44 ID:TTFUeNL0 main/1020956839.html#484
- とりあえず、構想図置いときます
ttp://www.geocities.co.jp/SiliconValley/2949/Key2.gif
- 336 名前：47 投稿日：02/05/10 19:01 ID:kg6dEaJu main/1020956839.html#565
- そんなこんなで、各ノードでキーが1000個以上、ノード数１万以上と言う過程が現実的だと
思われますので、扱うキー数が数十万レベルではなく数千から億に達するとの過程で
上流側の接続形態を見直し中です。とりあえずシミュレータ書き直してますけど、
接続形態はこんな感じになるんじゃないかと。
ttp://www.geocities.co.jp/SiliconValley/2949/Key3.gif
この表示だと中心ほど高速回線で、中心からの角度がジャンルです。
前のを極座標にしたのに近いですけど、上下方向リンクじゃなく
円周方向のリンクがメインになります。
円周方向のリンクをジャンル的に近いリンクだけにしようかと思ってましたが、
やってみたら集中サーバが無いと隣接する接続相手を見つけるのが
難しいみたいですので、任意ショートカットありで、一種の挟み撃ち手法で
クエリを担当近辺のノードに到達させると良いんじゃないかと思ってます。
とりあえずこの考えでちゃんと動くかどうかやってみます。
- 337 名前：47 投稿日：02/05/10 19:13 ID:kg6dEaJu main/1020956839.html#570
- デスクトプの解析しないように(^^;
- 338 名前：47 投稿日：02/05/10 19:44 ID:kg6dEaJu main/1020956839.html#586
- β7は内部を大量に書き換えたから違うバグが混入してる可能性大。
次のはβ6.1ではなく7がベースになるはずだから
早めにつぶしておいた方がいいんだろうけど
バグ取りつまんないので現実逃避に新設計したくなる罠（ｗ
無駄なキー転送落として6.1に戻すというのもありですが、どうします？
ある程度の実用性無いとβテスタさんがあきちゃうだろうし。
- 339 名前：47 投稿日：02/05/10 22:21 ID:JldilGdv main/1020956839.html#672
- β7.1です。厳密にはβ6.2って感じで、プロトコル的には今までで
最も動作が軽くなるはずです。ただし、プロトコルは7と繋がるように
なっていますので、β7ユーザがいなくなるまでは上流で重いはずです
（下流のβ7がキーを垂れ流してくる）
・検索方式をβ6.1の改造版に修正
・port0設定のノードが高速なノードにダウンリンクコネクトすると
無条件で切断されてしまうバグを修正
・キャッシュフォルダ内にキャッシュファイル以外のファイル
があると消してしまうバグを修正
・エラー時の表示を追加
- 340 名前：47 投稿日：02/05/10 22:23 ID:JldilGdv main/1020956839.html#676
- ん？いつのまにか色にしようって流れですかね？
- 341 名前：47 投稿日：02/05/10 22:28 ID:JldilGdv main/1020956839.html#685
- 今のβ7.1のままでも全体が見えないのは同じですし、ユーザが工夫すれば
クラスタ化できます。良く見かけるように分野とホスト晒せば新方式で想定しているのと
同じことだったりします。だから、今公開バージョンでとりあえず正式版に持っていって
これで対処できなくなったら例の構想を取り入れればいいかなとも思っています。
そろそろRC1候補になってくれるといいんだけどなぁと。
- 342 名前：47 投稿日：02/05/10 22:29 ID:JldilGdv main/1020956839.html#688
- あっちゃー、またやったか。そういえば新構想版テストしたの忘れてた。
- 343 名前：47 投稿日：02/05/10 22:33 ID:JldilGdv main/1020956839.html#691
- 修正しました。見なかったことに。
- 344 名前：47 投稿日：02/05/10 22:46 ID:JldilGdv main/1020956839.html#703
- β７使う人がいなくなるまで重いと思うんでよろしく
- 345 名前：47 投稿日：02/05/10 22:58 ID:JldilGdv main/1020956839.html#718
- 参考資料
#define WSAEWOULDBLOCK (WSABASEERR+35)
#define WSAEINPROGRESS (WSABASEERR+36)
#define WSAEALREADY (WSABASEERR+37)
#define WSAENOTSOCK (WSABASEERR+38)
#define WSAEDESTADDRREQ (WSABASEERR+39)
#define WSAEMSGSIZE (WSABASEERR+40)
#define WSAEPROTOTYPE (WSABASEERR+41)
#define WSAENOPROTOOPT (WSABASEERR+42)
#define WSAEPROTONOSUPPORT (WSABASEERR+43)
#define WSAESOCKTNOSUPPORT (WSABASEERR+44)
#define WSAEOPNOTSUPP (WSABASEERR+45)
#define WSAEPFNOSUPPORT (WSABASEERR+46)
#define WSAEAFNOSUPPORT (WSABASEERR+47)
#define WSAEADDRINUSE (WSABASEERR+48)
#define WSAEADDRNOTAVAIL (WSABASEERR+49)
#define WSAENETDOWN (WSABASEERR+50)
#define WSAENETUNREACH (WSABASEERR+51)
#define WSAENETRESET (WSABASEERR+52)
#define WSAECONNABORTED (WSABASEERR+53)
#define WSAECONNRESET (WSABASEERR+54)
#define WSAENOBUFS (WSABASEERR+55)
#define WSAEISCONN (WSABASEERR+56)
#define WSAENOTCONN (WSABASEERR+57)
#define WSAESHUTDOWN (WSABASEERR+58)
#define WSAETOOMANYREFS (WSABASEERR+59)
#define WSAETIMEDOUT (WSABASEERR+60)
#define WSAECONNREFUSED (WSABASEERR+61)
#define WSAELOOP (WSABASEERR+62)
#define WSAENAMETOOLONG (WSABASEERR+63)
#define WSAEHOSTDOWN (WSABASEERR+64)
#define WSAEHOSTUNREACH (WSABASEERR+65)
#define WSAENOTEMPTY (WSABASEERR+66)
#define WSAEPROCLIM (WSABASEERR+67)
#define WSAEUSERS (WSABASEERR+68)
#define WSAEDQUOT (WSABASEERR+69)
#define WSAESTALE (WSABASEERR+70)
#define WSAEREMOTE (WSABASEERR+71)
- 346 名前：47 投稿日：02/05/10 23:07 ID:JldilGdv main/1020956839.html#729
- >>728
直しましたけどこっそり書き換えていいですか？(^^;
- 347 名前：47 投稿日：02/05/10 23:10 ID:JldilGdv main/1020956839.html#734
- こそーり修正
- 348 名前：47 投稿日：02/05/10 23:21 ID:JldilGdv main/1020956839.html#739
- 今見たらまだPort0動作が直ってないなこりゃ。
プライベートアドレス送ってくる人がいる。
- 349 名前：47 投稿日：02/05/11 00:02 ID:Oxw247oX main/1020956839.html#760
- うーん、わけわからん。こちらではＬＡＮ上でのテストか
デバッグバージョンで起動して繋いで見る程度のことしか
できんので何が起きているかさっぱりわからんです。
最低限グローバルＩＰが二つ使える環境でデバッグしないとダメだけど家も職場もだめだしなぁ。
テストできる人いたら、Port0設定していたらどういう動作してる
（どこのポートを突付きに行ってる）とかNAT経由でどうなるか見てもらえると助かりますけど、
動作推測してその理由がわかる人じゃないと意味のある意見聞けないだろうし
早めにこちらのテスト環境を作んないとだめだな
- 350 名前：47 投稿日：02/05/11 00:08 ID:Oxw247oX main/1020956839.html#763
- うーん、プライベートアドレスがもれるということは
逆ＮＡＴんところが変なんだろうから
もう一度よく考え直すかぁ・・・
- 351 名前：47 投稿日：02/05/11 00:18 ID:Oxw247oX main/1020956839.html#771
- >>769
うーん、いろんな理由で無理な気がする。
どこに送るのか、UDPなら直ぐだせるけどトラぶってるノードでちゃんとそれが届くのかとか、
そもそもどこに送るんじゃいとか問題が。
- 352 名前：47 投稿日：02/05/11 00:20 ID:Oxw247oX main/1020956839.html#773
- >>770
転送要求かかったけどそこのノードから他に繋がらないんで
向こうが切断してそれを処理できてないんでしょうねぇ。
既に切れてると思われます。それが各所で起きてるんで
転送成功率が悪いんでしょうけど。
うーん。
- 353 名前：47 投稿日：02/05/11 01:00 ID:Oxw247oX main/1020956839.html#797
- うーん良く分からん。NATの人もダウンできてるみたいだしどこが悪いのやら。
とりあえず、接続形態、特に自分のアドレスがプライベートかどうか、
DDNS部にグローバル書いて動作変わるかとか書いていただけると助かります。
だれが失敗しやすいのかがさっぱりわからん。
- 354 名前：47 投稿日：02/05/11 01:10 ID:Oxw247oX main/1020956839.html#803
- >>799
情報どうもです。一応動いているみたいですが、動かない環境では何が悪いのやら・・・
転送ですかねぇ。
> ＊なぜ回線申告５０をしているマシンB.がマシンAにて回線速度１０に見えるのだろうか・・・
これは、Port0設定すると自動的に速度を10にみなすようにできてるためです。
これのせいで高速なホストには繋がりません。port0にすると
ファイルが見えないというのは想定された動作で、しつこく相手を見つければ繋がります。
あとは想定どおりのようです。
- 355 名前：47 投稿日：02/05/11 01:13 ID:Oxw247oX main/1020956839.html#805
- 理由が良くわかんないから変えたところを順に戻してみますか
- 356 名前：47 投稿日：02/05/11 01:14 ID:Oxw247oX main/1020956839.html#806
- 繋がんない理由は主に接続かけるほうじゃなくて受けるほうなんで
トラブルの理由がわかんないこと多いんですよね。
繋がんない人は自覚ないし。
- 357 名前：47 投稿日：02/05/11 01:23 ID:Oxw247oX main/1020956839.html#813
- うーん、ダウンロードができるかどうかというのは接続を受けた相手
がちゃんと受け付けられるかどうかの要素が大きいんで報告されても
アップ側の様子がわかるとなんで失敗するか分かります。
ファイルが転送されて無さそうなのにＵＰリンクが限界まで張られてたりしますか？
それならこれが原因ですけど。
- 358 名前：47 投稿日：02/05/11 01:24 ID:Oxw247oX main/1020956839.html#815
- とりあえず疲れたんで、またＬＡＮで地道に動作見直します
- 359 名前：47 投稿日：02/05/11 01:36 ID:Oxw247oX main/1020956839.html#824
- >>819
NATの人もDDNSの人も普通にダウンしていって普通に動いてます(T_T)
- 360 名前：47 投稿日：02/05/11 01:38 ID:Oxw247oX main/1020956839.html#826
- ひょっとしてβ7.1はＤＯＷＮ側が悪いんですかね。
β７なら落とせるとかあります？
- 361 名前：47 投稿日：02/05/11 01:46 ID:Oxw247oX main/1020956839.html#832
- うーん、なんか条件によっては受け付けた転送リンクを問答無用で
切断しているような気が。なんじゃろ。
- 362 名前：47 投稿日：02/05/11 02:24 ID:Oxw247oX main/1020956839.html#857
- いまＬＡＮで見直してたんだけど、β7.1では転送動作時に
少しでもウェイトかけると転送が始まらずに転送側もダウン側も
固まる現象を発見。あと、ＵＰとダウンがひっくり返るのは致命的
なんで見直します。心当たりがあります。少しお待ちを。
- 363 名前：47 投稿日：02/05/11 02:39 ID:Oxw247oX main/1020956839.html#871
- わーかったー。Port0対応やったときに上下速度の比率調べる部分で
整数から実数へのキャストが取れて整数/整数になってる。これじゃ
下流側の計算が変だわ。グローバル３つ所有 さんサンキューです。
チェックして問題なさそうなら上げます。
- 364 名前：47 投稿日：02/05/11 03:08 ID:Oxw247oX main/1020956839.html#897
- β7.2です。慌てるとろくなことないんですけどβ7.1は致命的だったんで早めに。
修正点ですけど、バグ二つで、例の上下判定のバグと、転送時に
タイミングによってはフェイルするというものです。
β7.1はプロトコル的に危険なので破棄で、新プロトコルです。
- 365 名前：47 投稿日：02/05/11 03:15 ID:Oxw247oX main/1020956839.html#905
- つ、疲れた。とりあえず何でもいいから最低限の転送できるようになってくれー。
ＬＡＮじゃ快調なんだけど、そういうのに限ってなぜかＷＡＮじゃ調子悪いし
頭いたい。
- 366 名前：47 投稿日：02/05/11 03:24 ID:Oxw247oX main/1020956839.html#918
- なんかダウンで300K出てる・・・
不気味だ。
- 367 名前：47 投稿日：02/05/11 03:39 ID:Oxw247oX main/1020956839.html#937
- うーんだめですか・・・
寝よう
- 368 名前：47 投稿日：02/05/11 04:43 ID:Oxw247oX main/1021057195.html#39
- どうも、うまくは動いているんですけどUP/DOWNが高速すぎるという動作が出ているようです。
様子を見ていたら、回線設定を高く設定しているとUPLOADタスクがものすごい数起動されて、
UPLOADタスクが固まって回線切り忘れが発生しUPLOADタスクのタイムアウト時間
（60秒だった）経ったら細々と次のダウンが始まるという状況のようです。
とりあえずUPLOADのタイムアウトを５秒と短くしてみたので、こちらに
切り替えてみてください。プロトコルは同じなのでどちらでも問題はないですけど。
- 369 名前：47 投稿日：02/05/11 10:06 ID:SbQWv1d4 main/1021057195.html#76
- 都合によりβ7.4です。
7.3はＵＰ側に問題が残っていたので修正しました。細かいパラメータ調節程度で7.3と同じです。
7.2, 7.3と互換があります。UP側がこれになるとよりダウンや転送成功率があがるはずです。
修正点
・キー上昇時は上書きを控えることでダウン時に本体にヒットしやすくした
・転送を受ける可能性のあるキーは寿命を延ばすことで転送成功率向上
・キャッシュヘッダチェックを削除のときは甘くしてゴミキャッシュ消えるようにした
あと、検索リンクの上下は速度で決まりますけど、
転送リンクは速度関係なしで、接続に行ったほうが上流です>>73
- 370 名前：47 投稿日：02/05/11 10:17 ID:SbQWv1d4 main/1021057195.html#82
- あれ？上流下流直ってないかな？ちと確認しよう。
- 371 名前：47 投稿日：02/05/11 10:26 ID:SbQWv1d4 main/1021057195.html#85
- あ、そういえば、検索リンクでも値が上なら必ず上流っていうのは止めたんでした。
これですと、最も高い値を出したノードが死ぬんで、わざとループが出やすいように
少しアバウトな処理になってます。同じ程度なら接続したきた方が上流だったかな。
二つのノードでお互いに逆方向だと思っているとパケットループするんで
まずいですけどそうでなければ大丈夫です。あと、Port0の扱いなんかで
この辺は面倒なことになってますね。
- 372 名前：47 投稿日：02/05/11 10:47 ID:SbQWv1d4 main/1021057195.html#97
- うーむ。重要なことに気が付いてしまった。
この検索方式だと検索かければかけるほど
キーが荒れていって本体に届く率が悪くなるような・・・・
みんなが静かにしていると仮想キーが寿命で死んでいって
寿命無限のキャッシュやＵＰファイルだけが残るんで、
その状態で検索かけると検索クエリが本体まで
まっすぐ到達して素直に落とせるような気がする。対処どうしよう。
- 373 名前：47 投稿日：02/05/11 10:49 ID:SbQWv1d4 main/1021057195.html#98
- なんというか、釣りみたいな感じですねこれは・・・
落ち着いたところにぽちゃんと検索投げると
運がよければ大物をひぱってこれるという。
- 374 名前：47 投稿日：02/05/11 11:03 ID:SbQWv1d4 main/1021057195.html#111
- もし7.3のが調子よさそうでしたら戻してください。
悪くはならんだろうとは思ったんですけど、
正確なところは実際に動かしてみないとわかんないです。
- 375 名前：47 投稿日：02/05/11 22:41 ID:USdxWxLD main/1021057195.html#427
- β8です。
転送率が良くなるはずなのになんでβ7.3より7.4の方が落ちないのか悩んでましたけど
理由がわかりました。β7になってから、例のキー転送で重いのが理由で、
更新動作はまったく行わずに、多少の検索ロスが出るのを無視して検索動作
だけでキーの伝播を行わせているんですけど、検索パケットで受け取ったキーは
スルーして検索をかけたノードでしか展開しないので、たまたま同じファイルを
検索していてキーが転送側にもないと、時間たってキーが消えていくと
転送ファイルが無くて転送できないというアホみたいなバグでした。
途中でキー伝播の設計が変わったんで見落としてました。
手持ちのテストでは大抵全キー見えるようにしてテストしていて、
キーロストまで待たないことが多かったんで気が付きませんでした。
これでうまくいけば、いままでとは桁違いに転送動作が起動されると思います。
あ、あと変更点一覧
・ 検索結果が転送ノードに残らないバグを修正
・ Port0設定だと検索パケットの交換が行われないのを修正
・ 速度がマイナスにならないようにチェック
プロトコルは独自です。
- 376 名前：47 投稿日：02/05/11 22:43 ID:USdxWxLD main/1021057195.html#429
- あと、検索メカニズムはβ7.2以降と同じなんで重くならないはず
- 377 名前：47 投稿日：02/05/11 22:52 ID:USdxWxLD main/1021057195.html#445
- ちょっと分かりにくかったかな。
今回、上方キーと下方キーではなく、検索キーと転送キーになってますが
現状での検索と転送のメカニズムは次のようになってます。
まず検索ボタンが押されると、検索パケットを上流と下流に投げます。
上方向と下方向にしか行かないので、上流ノードが異なる別のノード
までは検索に行きませんが、上下リンクが複数なので、鼠算式に
パケットが飛ぶんで、わざとクエリの複製は行わないようになってます。
これやると以前のようなものすごい通信負荷が発生します。
で、検索が戻ってくるわけですが、下流から上流に行く場合、
キャッシュやＵＰファイルのみが検索にかかり、これを転送キーとして
上方に伝播させます。これは上流まで行きます。
検索パケットが下流に行く間に、ＵＰ回線が空いてるノードから優先的に
転送キーを検索パケットにプッシュします。このときキーのリンク元を自分に書き換えます。
この検索パケットが検索をかけたノードまでいって展開されて、
これが検索キーとして表示されることになります。
こんな感じで、検索パケットが上まで行って下に折り返してくる間に、
自動的に転送相手が決まることになります。
- 378 名前：47 投稿日：02/05/11 22:57 ID:USdxWxLD main/1021057195.html#450
- 検索キーはポインタのポインタですけど、
転送キーは単なるポインタの可能性が高い（そこにキャッシュかＵＰファイルがある）
んで、転送キーのが落とせるはずです。無意味に他ノードに転送開始させたいときは
検索キー選んでください。ｋろえ匿名性に問題があるんですけど、βだから区別して出してます。
後で消して自動判別にします。
つーか、両方見えたらバグなはずだなぁ(^^;;
私も繋いで見るか。
- 379 名前：47 投稿日：02/05/11 23:01 ID:USdxWxLD main/1021057195.html#454
- あ、検索が通過しただけでキー更新が発生するから
チラチラが復活しちゃってますね。後で直します。
とりあえず、転送がちゃんと行われるかどうかチェックお願いします。
- 380 名前：47 投稿日：02/05/11 23:08 ID:USdxWxLD main/1021057195.html#457
- ちらちら修正したけどFTP鯖が重くて書き換えられない・・・
- 381 名前：47 投稿日：02/05/11 23:12 ID:USdxWxLD main/1021057195.html#462
- 接続が安定するまでは基本的に辛いと思う。
- 382 名前：47 投稿日：02/05/11 23:24 ID:USdxWxLD main/1021057195.html#476
- ちらちら直しました
- 383 名前：47 投稿日：02/05/11 23:27 ID:USdxWxLD main/1021057195.html#478
- 自分のキャッシュが一番優先度高いんで消さないと他のノードのファイルは見えません。
ＵＰファイルが一番優先度高いんで、ＵＰファイルにあれば他は全て上書きされます。
- 384 名前：47 投稿日：02/05/11 23:33 ID:USdxWxLD main/1021057195.html#485
- 自分と相手以外のポートでの接続はしないはずですけど
うーん・・・・
- 385 名前：47 投稿日：02/05/11 23:38 ID:USdxWxLD main/1021057195.html#489
- β８落としなおしてください
- 386 名前：47 投稿日：02/05/11 23:40 ID:USdxWxLD main/1021057195.html#490
- >>487
中身が半端なキャッシュがあると自動的に検索結果のリンク先で上書きされますので
レジュームになります。検索対象がどうなるかは他ノードとの連動で決まるので
選択不能です。そして今ここのバグ取り中ですね。
- 387 名前：47 投稿日：02/05/11 23:45 ID:USdxWxLD main/1021057195.html#495
- 検索リンクは一度相手とのネゴしてから、一番よさそうなもののみを残して切ります。
ですので、少しの間は制限個数を超えます。あまりにコネクション要求が多いと
問答無用で切るようになります。今現在、ユーザ数が多くてネットワークがまともに
動いていなさそうなんで落ち着くまで待つしかないと思います。
- 388 名前：47 投稿日：02/05/12 00:07 ID:PXlYMuT0 main/1021057195.html#522
- どーも分けわかんないことになっているようなので、
基本に戻してみたんでβ8.1にしてみてください。
β8と繋がります。これ以上ダウン率がよくなることはないはず（転送率０）なんで、
これでダウンができないとなると別の理由です。
転送より先にＮＡＴ対策などになるでしょう。
- 389 名前：47 投稿日：02/05/12 00:09 ID:PXlYMuT0 main/1021057195.html#526
- 言っておきますが、β8.1は匿名性に穴があります。
違法なファイルのやり取りは行わないようにお願いします。
- 390 名前：47 投稿日：02/05/12 00:10 ID:PXlYMuT0 main/1021057195.html#527
- あとキャッシュについてですが、現状では完全なキャッシュ以外は外部に公開
しないようになってますので、大きなファイルはほとんどキャッシュとして
出回ってないはずです。
- 391 名前：47 投稿日：02/05/12 00:15 ID:PXlYMuT0 main/1021057195.html#529
- 自分のところもNAT環境なんでけど問題なくUPや転送できてるんですよねぇ。
NAT環境といってもいろいろなんで対応が面倒ですが・・・
とりあえずβ８でPort0動作が少しまともになったはずなんで、
どうしようも無い人はこっち試して欲しいです。
- 392 名前：47 投稿日：02/05/12 00:17 ID:PXlYMuT0 main/1021057195.html#533
- 表示が8のままなのは上げなおしてあります。すいません(^^;
- 393 名前：47 投稿日：02/05/12 00:25 ID:PXlYMuT0 main/1021057195.html#543
- β8.1は転送動作が発生しない（はずの）バージョンです。匿名性は最も低くなります。
キーに書いてあるIPとポートはキャッシュかUPファイルそのままの位置を表していますので、
動作的にはＭＸと同じです。提供しているのが、検索リンクで近傍の人の可能性が高いので
キーの下とNETSTAT値を比べれば誰が何を上げているのか分かってしまいます。
これの意味を良く把握された上でβテストに参加されてください。
そんなわけですので、これで落とせないのなら単に接続が変なだけです。
どういう条件下で落とせないか調べていただけると助かります。
- 394 名前：47 投稿日：02/05/12 00:26 ID:PXlYMuT0 main/1021057195.html#545
- 分割ダウンは初めからついてますけどダウン自体がうまく動かない状態でしたので(^^;
- 395 名前：47 投稿日：02/05/12 00:28 ID:PXlYMuT0 main/1021057195.html#549
- ああ、でもキーのＩＰ＝ＵＰ相手と表示されるのは全員β8.1の場合なんで
β8と混ぜて使えば匿名性はありますね（ｗ
ダウンテストにならんですけど・・・・
- 396 名前：47 投稿日：02/05/12 00:31 ID:PXlYMuT0 main/1021057195.html#553
- いや、8.1で変かどうか分かるのは、UPできないかどうかです。
DOWN側はバージョン関係ないです。
これで吸い出されそうなファイルUPしてだれも落としてくれないのなら、
そのノードはUP不可能な可能性高いです。
- 397 名前：47 投稿日：02/05/12 00:33 ID:PXlYMuT0 main/1021057195.html#558
- ちなみにβ8.1の匿名性はＭＸと同じか少し上ぐらいかと（ｗ
- 398 名前：47 投稿日：02/05/12 00:38 ID:PXlYMuT0 main/1021057195.html#574
- うーん、疲れたんで今日は休みますー。
β8.1で実験頼みます。
- 399 名前：47 投稿日：02/05/12 00:45 ID:PXlYMuT0 main/1021057195.html#589
- DOWNよりUPテストよろしくー。怪しいのは特にUP側です。
（といってもこの状態では辛いでしょうが）
- 400 名前：47 投稿日：02/05/12 00:48 ID:PXlYMuT0 main/1021057195.html#599
- このバージョンでも十分キャッシュが広まれば匿名性高いですけどね
- 401 名前：47 投稿日：02/05/12 00:49 ID:PXlYMuT0 main/1021057195.html#604
- ＤＬできなければそもそも接続もできないので、
接続失敗するのはほとんどＵＰ側の問題のはずです。
もちろんほとんどはWinnyβのバグなんですけど。
そんなわけで後はよろしこ。
- 402 名前：47 投稿日：02/05/12 03:21 ID:UR5S16Xz main/1021057195.html#726
- ノード管理が変になっているようだったので修正しときました。β8.2です。
エラー10038が出る時点で気が付くべきでしたが・・・
あと、バッファ溢れが出るのはキーを多数抱えているノードに
zipなどの拡張子検索などのヒットしすぎる状態で
クエリが大きくなりすぎるのが根本的な問題のようですので、
１クエリで1ノード200までに制限するようにしときました。
プロトコルは8〜8.1と同じです。
- 403 名前：47 投稿日：02/05/12 03:34 ID:UR5S16Xz main/1021057195.html#743
- indexファイル上げるの忘れてた。失礼。
- 404 名前：47 投稿日：02/05/12 03:55 ID:UR5S16Xz main/1021057195.html#754
- 今は接続率を上げるのに注力してるんでメモリ消費量やＣＰＵ負荷低下は
もう少しあとのバージョンで期待してください。
- 405 名前：47 投稿日：02/05/12 05:50 ID:UR5S16Xz main/1021057195.html#828
- 経験上、動作が不安定なうちに高速化作業やるとろくなことがないんで
後回しにしようと思ってましたけど、既に負荷テストになってて、
動作が重いと通信バッファが溢れて不安定要素になりかねんので、
試しに簡単な高速化作業やっときました。β8.3です。
どこでCPU消費しているのか調べてみたらやはり暗号周りでしたが、
検索が入ると名前やブロック単位の暗号化処理に結構時間が
取られていてこれの暗号初期化がそれなりに重い処理で、
ここを毎回やってるんでそれなりに重くなっていたようです。
そんなわけでここをキャッシング処理するようにしたので
それなりに軽くなったと思います。動作的には特に何も変わってないはずです。
プロトコル的にはβ8共通です。
- 406 名前：47 投稿日：02/05/12 05:53 ID:UR5S16Xz main/1021057195.html#831
- 二日に一度寝れば耐えられる体質なんで、
あと１２時間ぐらいは起きてると思いますよん（ｗ
さて、今週分の仕事でもしようかな。
- 407 名前：47 投稿日：02/05/12 09:08 ID:UR5S16Xz main/1021057195.html#891
- >>886
落とせたよ。
これ、面白いメカニズムかも。
- 408 名前：47 投稿日：02/05/12 09:09 ID:UR5S16Xz main/1021057195.html#894
- 掲示板には絶えられなくても回覧版ならいけるかな？
- 409 名前：47 投稿日：02/05/12 09:48 ID:jdCoJU22 main/1021057195.html#910
- 一行レス野郎装おうと思ったら名前入れたままだった（ｗ
このシステムだと名前同じでも中身が一文字でも違うと
別キーになるんで掲示板は無理ですけど、
回覧版というアイデアは面白いすね。
キャッシュに入れている人がいる限り
昔のを消せないという問題はありますが。
とりあえず、8.3は接続テストに最適なはずなんで
一日程度このままでどういう理由で落とせないのか
理由をさぐる予定です。今のうちにキャッシュ育てといてください。
あとポート０が出るのは、エラー対処の際にリンク切り忘れた
らしいです。対処終わってますけどこれだけのために上げますか？
- 410 名前：47 投稿日：02/05/12 09:59 ID:jdCoJU22 main/1021057195.html#915
- β8.3をこっそり一箇所書き換えてポート０リンク残りに対応しました。
気になる人はダウンし直しといてください。動作は問題ないはずです。
隠れバージョン作るなよというのはあるでしょうけど
このぐらいならいいっしょということで。
- 411 名前：47 投稿日：02/05/12 10:08 ID:jdCoJU22 main/1021057195.html#919
- っと思ったら０リンク残り直ってないや(^^;
すいません。また後で見直します。
ちなみに誰かWinny本体をWinnyで上げておくと、
回覧版のように変更がばればれになって面白いかもしれません。
>>916
ポート番号が0なのはまだネゴが終わってなくて、
ポート番号などが伝わる前に何らかの理由でFailしたリンクのはずです。
ここはタイムアウト処理入れてないんでタイミングによっては
残っちゃうんでしょう。ここは変にいじると危険そうなんで後回しにします。
>>917
今不安なのはNAT周りの動作でしょうか。
ネゴの時にノードにgethostbynameで取得したローカルアドレス申請してもらって、
隣のホストがローカルからグローバルに変換してるけどこれでいいのかとか、
ファイルダブルクリックするとそこに書いてあるIpとポートに接続に行きますけど、
これが食い違ってないかとか、キーに書いてあるIPやポートがちゃんと
あってるかとかとか・・・
独自にネットワーク組まないとわかんないと思いますけど。
- 412 名前：47 投稿日：02/05/12 22:58 ID:AbMuX6A3 main/1021170898.html#275
- 今まで寝てた・・明日の夕方は眠そうだ
UP状態が見れないのは既に書いたようにダウンタスクはファイル単位で
やっているのに対してアップタスクはブロック単位だからです。
ここの動作詳細ですが
１．ファイルダブルクリックでダウンタスクが生成される。同時に転送リンク接続。
２．対応するキャッシュがあるか調べて、あれば破損個所を先頭から探す
３．数ブロック分（ブロック数は速度設定により可変）の転送要求を送る
４．ＵＰ側はブロック転送ＵＰ用のタスクを生成
５．送られてきたハッシュファイルの該当ブロック部を返送
６．受信側が送られてきたデータをキャッシュにくっつける
７．受信側が全ブロックそろった時点で転送リンクを切断してキャッシュ変換タスク起動
８．送信側は相手が転送リンク切るまでリンク切らない
こうなってます。受信側は、このファイルのここのブロックから何ブロック送れという
指示に従って送っているだけなので、一瞬ＵＰタスクが生成されてタスク表示のところに
出ますけど、ファイル内容を通信用バッファに詰め込み終わればタスクが終了してしまうので
一瞬でタスクが終了します。通信部は送信、受信ともキャッシングされていて、
送信・受信可能になったらキャッシュの内容を順次送受信するようになっているのでこうなります。
ちなみに、ファイル要求は上で書いたようにブロック単位になっていますので、
前半分だけ無かったり、一部分だけ破損していてもそこだけレジュームできます。
キャッシュ変換でエラーになっても諦めないで、もう一度ダウンしてみれば、
破損部分だけ修復できる可能性高いので破損キャッシュでも消さないほうがいいです。
特に、レジュームのつなぎ目のところで壊れたブロックが発生しやすいようです。
あと、ブロック破損のチェックは比較的重い処理なので、受信時にはやらないで、
キャッシュ変換時にやっています。だから完全キャッシュに見えても、キャッシュ変換
で破損キャッシュになる可能性があります。この場合、そのキャッシュを検索かけて
見てみると破損部分だけ青くなります。
バイナリエディタでわざとキャッシュの一部分を壊してみるとその動作が良く分かります。
- 413 名前：47 投稿日：02/05/12 23:13 ID:mE4zpmn7 main/1021170898.html#284
- とりあえずβ９候補はできてるんですけど、動作が怪しいんで検証中です。
予定では、転送機能の復活と、ダウン率の向上です。
β8.3ではキーに直接本体に位置が書いてあるため、ダウン率が高いですが、
匿名性に問題があります。といって、匿名性を上げるために転送動作を入れると、
ダウン成功率が極端に低下します。もしリンク張ってダウンするという一連の
動作の成功率が10%なら、一度転送でその成功率は掛け算になるので1%の成功率。
もし、直接ダウンの成功率が1%なら、転送での成功率は0.01%になってしまいます。
ここで、ダウンが失敗しやすいのは、主にＵＰ側でポート設定が変だったりして
コネクションを受け付けられないというのが理由のなずです。
ですので、β9では、転送の相手を、本体を持つ一つ上のノードに決め付ける予定でやってます。
検索リンクで一つ上のノードということは、既に検索リンクでコネクションが張られている
はずですので、検索リンクを転送リンクとして利用すれば新たにコネクションを張る
必要がありません。ここはPort0設定されていることと同じですので、一つ下の
ノードとのやりとりはかならず相手をPort0とみなすことになります。
これですと、ポート接続不可能なのにそれを申告していないノードのファイルも
外部にＵＰ可能になりますし、人気があるファイルは自動的に上流にキャッシュが
広まっていくことになります。一番初めに考えた通りの動作になります。
これで、本来の予定通りの、匿名性を実現した上で、うまくいけば
今以上のダウン成功率にできるのではないかと。
あと、この辺見直してたらNAT周りの動作が変な理由が分かった気がするんで
合わせて対処中です。しばらくお待ちください。
- 414 名前：47 投稿日：02/05/12 23:21 ID:mE4zpmn7 main/1021170898.html#288
- β8.1以前の人がいるのかな？
転送は他ノードとの兼ね合いで発生する
（キー転送中にそのＩＰを自分に書き換えると転送になる）
でも、違うファイルが送られてくるというバグもあるようなので
単にバグってるだけだろうなぁ(^^;;
- 415 名前：47 投稿日：02/05/12 23:30 ID:mE4zpmn7 main/1021170898.html#293
- ファイルダウンの時は、手持ちのキーにロックかけて検索で消えたりしないように
したうえで、そのタスクのＩＤ（これはダウン側特有の値）とファイルのハッシュ値送って
ファイル転送してもらうんですけど、違うものが落ちてきてしまうということは、
ロック寸前のところで、キーが頻繁に書き換わっていて違うものロックして
そのファイルの転送要求がいっちゃってるんでしょう。
もしファイル名と中身が違ってたらまた別の部分のバグ（ダウンタスクIDが
途中で壊れてるとか）だと思います。もしそのバグが発生したら、
落ちてきたファイルの中身確認していただけると原因がわかりやすいです。
- 416 名前：47 投稿日：02/05/12 23:31 ID:mE4zpmn7 main/1021170898.html#296
- >>291
了解。
つーか、ちゃんと消してたような気もしたけど
別のトラブルでその処理やめたんだったけかな？見直しましょう。
- 417 名前：47 投稿日：02/05/12 23:40 ID:mE4zpmn7 main/1021170898.html#300
- >>297
めんどうなんでつけてないだけ。
あれ、自分でソートのコードかかないとだめなんで。
そのうちやります。
- 418 名前：47 投稿日：02/05/13 00:54 ID:1ehsV2t9 main/1021170898.html#352
- ネゴの直後にaccept側からconenct側に逆接続かけて申告されたポートに
繋がらなかったら自動的にそのノードをport0とみなすというのは
比較的簡単に作れそうですけど、β8.4としてやってみますか・・・
- 419 名前：47 投稿日：02/05/13 04:09 ID:rjrNAVBH main/1021170898.html#418
- β8.4です。前のβと互換性があります。
標準で全ノードをPort0設定と仮定して、
ネゴシエーション成立後にAcceptしたほう（検索リンク接続を受けた方）から、
受け取った情報を元に転送リンクを空接続して繋がった場合だけ他の設定
とみなします。
本来はそのままPort0でもいいんですが、これやるには相手に
繋がんないよということを教えてPort0にしてもらう必要があり、
プロトコル変えないとだめなんで、8.4では接続後に５秒たっても
テストの転送リンクが繋がらないと検索リンクを自動切断します。
全員β8.4使っていると、Port0相当なのにPort0設定になっていない
人は誰とも繋がらなくなります。
これにより、ダウン側は今までと同じですが、検索リンクの先に接続不可能な
ノードが繋がることがなくなり、不正なキー（接続不可能なキー）が流れる
ことがなくなり結果的にダウン率が上がるはずです。
- 420 名前：47 投稿日：02/05/13 04:11 ID:rjrNAVBH main/1021170898.html#420
- もちろんPort0設定になっていれば今までと同じで問題なく繋がりますし、
検索リンク経由でUPも可能です。設定間違えている人を跳ねるために機能ですね。
- 421 名前：47 投稿日：02/05/13 04:47 ID:rjrNAVBH main/1021170898.html#439
- 転送させないと匿名性的に問題があるから強制的に一つ上に転送させようかと
思ってましたが、良く考えたらPort0設定の人のファイルは強制的に
一つ上流のノードに中継されて流通していくわけで、
ネットワーク上にPort0設定の人がたくさんいるという仮定なら
今のβ8.4のままでも問題ないような気がしてきました。
今ですとPort0でも問題なく高速ノードの下にぶら下がることができますし、
Port0のノードが下流にいるだけで転送が発生する可能性があるんで、
netstat見てるだけじゃだれがＵＰしてるのかとかダウンしているのかとか
追いかけきれないはずです。
今現在ですと、必要最低限の転送が発生するだけなんでダウン率は
β8.4が最大のはずですが、これで匿名性もついでに維持できるんではないかと。
まぁ、このままですとPort0設定忘れている人が繋がらなくて初心者の人が
首捻っちゃうでしょうから、初期状態でPort0外しておいて、もしダウンリンク繋がらなくて
接続がリジェクトされたら検索リンク張っている周辺から教えてもらって
警告出すようにすればそれでいいかなと。
そんなわけで、NAT周りの動作などチェック終わったら、
ネットワーク周りのチューニングは切り上げて、
キャッシュ周りやインターフェイス周りのチューニングに入っても
いいかもしれません。これでやっと本当のβになります。
- 422 名前：47 投稿日：02/05/13 04:59 ID:rjrNAVBH main/1021170898.html#448
- >>443
それは次にプロトコル代わるときにやりますね
ちなみにPort0入っていると何がうれしくないかですが、本来別にすべきの
ファイル本体の伝送とキー伝送が一つのストリームで行われるので、
Port0ノードとその上流ノード間だけ、検索や転送が引っかかりやすくなります。
プロトコル的には、転送リンクも検索リンクも使っているプロトコルは同じですが、
単に綺麗に流れるように二種類に分けているだけです。
下流に他のノードがいなければ特にPort0でも困らないはず。
ただし、下流にノードがあってキー検索パケットが大量に流れ込んでくると
ダウンどころじゃなくなるんで、やはりPort0の人を転送の起点にするというのは
最も効率の良いアイデアかもしれません。
一見、匿名性が落ちる気もしますが、もしPort0の人のファイルを落とそうとしたら
そのファイルをUPしているのはキャッシュにもUPフォルダにも持ってなかった人
（port0ノードの一つ上にノードの人）から落とすことになるんで、本来の目的であった、
ＵＰしているのかキャッシュ送っているのか転送しているのか分からないというのは
β8.4の時点でも実現できていることになります。これで最もダウン率が高いんなら
これがベストですね。
- 423 名前：47 投稿日：02/05/13 05:00 ID:rjrNAVBH main/1021170898.html#449
- あとポート番号0のノードが残るのは忘れてました。
後で理由見つけて直します。今は理由がわかんない。
- 424 名前：47 投稿日：02/05/13 05:38 ID:rjrNAVBH main/1021170898.html#457
- >>455
どこかにPort0の人が混じっていればキーに書いてあるIP=キャッシュかUP
では無くなる可能性がありますんで、高速ノードだからとか、
近傍にPort0がいないからといってあるキーの出所が特定できるわけではないです。
ちなみに前はPort0を強制的に速度10として下のほうにぶら下げてましたけど、
今ですとこの制約が無いんで光の下でもPort0がぶら下がれます。
とりあえず、プログラムクラックできたとしても得られるのは
今のβで晒している情報までですので、正式版になってこれらを隠して
しまえば極端に解析は困難になります。プロトコル的に
キャッシュかＵＰファイルかはどうやっても分からないので、
クラックしてもＵＰしている人の完全な特定は無理でしょう。
唯一、匿名性の点で穴があるとすればPort0申告している人でして、
この人は下に誰もいないはずだから、そこから上がってくるファイル
は確実にUPファイルかキャッシュのはずで転送ではないはずです。
だから、Port0ノードの直上にいれば、netstatの結果と見比べることで
Port0の人が送っているファイルを特定できます。
とりあえずPort0の人へのペナルティは匿名性の低下と、
通信が引っかかるデメリットがあるということでどうでしょう(^^;
- 425 名前：47 投稿日：02/05/13 06:05 ID:rjrNAVBH main/1021170898.html#459
- なんか極端にダウン率が良くなったかも。
それだけポートの空いてない人が多かったってことか。
- 426 名前：47 投稿日：02/05/13 06:33 ID:rjrNAVBH main/1021170898.html#468
- 8.3→8.4で見えなくなったんなら単に今まで見えるファイルを提供していた
人の多くが設定不良だった可能性が高いと思います。そういう人の
ファイルはどうやっても落とせません。
あと今はダウンロードの優先度などの面倒なことはトラブルの
元になるんで入れてません。
ポート無しは理由が良く分からんので少しお待ちを。
- 427 名前：47 投稿日：02/05/13 09:47 ID:OYlm4ItG main/1021170898.html#502
- うーん、困ったちゃんが多いみたいで難儀ですねぇ(^^;
設定誤っていると繋がりませんので、
そういう人は
「システム情報」押して「設定変更」押して「外部からの接続不可能」にチェック入れて
「プログラム再起動してください」
よろしくお願いします。
ということで、対策取ったβ8.5です。
タイマー入れて変な接続は強制切断するようにしました。
例の０ポートも５秒後に切断します。
あと、接続の際はコネクション攻撃で押し出されないように、
新しいコネクションを優先的に切断するようにしておきました。
んで、回線高速じゃないと接続回数制限が働かなかったけど、
今度のバージョンでは問答無用にコネクションは２００回までです。
普通に使っていればそこに達するまでに他からのコネクションを
受けるようになります。接続をリセットしたいときは接続切断を押してください。
- 428 名前：47 投稿日：02/05/13 10:06 ID:dPiLfkKj main/1021170898.html#516
- ありゃ、ソートかけようとしたのがまずかったのかな？
今戻してますので少しお待ちを。
- 429 名前：47 投稿日：02/05/13 10:11 ID:dPiLfkKj main/1021170898.html#519
- すいませんが、β8.5の人は落としなおしてください。
表示周りを昔のに戻しました。
- 430 名前：47 投稿日：02/05/13 10:15 ID:dPiLfkKj main/1021170898.html#522
- うーん、警告出るようにしてβ9にすべきでしたね。
とりあえず暇ないんで対処は後になります。
- 431 名前：47 投稿日：02/05/13 10:20 ID:dPiLfkKj main/1021170898.html#526
- β8.4以降で接続が直ぐ切れてしまうのは
外部からの接続が不可能なのに、
そう設定されていない可能性が高いです。
> 「システム情報」押して「設定変更」押して「外部からの接続不可能」にチェック入れて「プログラム再起動してください」
これよろしく。
- 432 名前：47 投稿日：02/05/13 10:55 ID:zYw6qdsY main/1021170898.html#556
- 今の検索部は、クエリが多いこと前提で動作するものなので
今回の設定で一時的にはじかれた方々がいなくなったせいで
仮想キーが上まで上がってこないんだと思います。
検索周りで変わったのはリンクのMAX値だけです。
- 433 名前：47 投稿日：02/05/13 11:14 ID:zYw6qdsY main/1021170898.html#572
- 結局繋がらない最大の理由はポートをさらせている人が
あまりいなかったというオチのようで
とりあえず逆接続して受付可能かテストしてみるという考え出してくれた人、
ありがとうございました。
あと、回線高速なのに下流になるのは相手がPort0だからでは
ないかと思います。Port0はそれ以上向こうにいけないんで、
これが上流に来ると検索パケットを吸い込まれてしまいます。
そんな理由で強制的に下流にしてます。
- 434 名前：47 投稿日：02/05/13 11:31 ID:zYw6qdsY main/1021170898.html#580
- これでも落ちるってことは、前からあった不祥事が、再接続数増えたという理由で
表に出てきただけなんでしょう。２ｃｈは負荷テストには最適ですねぇ。あー、頭痛い・・・
とりあえずノードオブジェクトはソケット抱えててそれなりに大きいオブジェクトなんで
あまり頻繁に再生成されるとちと怖い（それも別スレッドで）
- 435 名前：47 投稿日：02/05/13 18:56 ID:gJkkHcII main/1021170898.html#790
- β9です。プロトコルが変わったのでβ8との互換性はありません。
・転送動作が高確率で上流側で発生するようになった
・相手がBadPort0の場合に警告が出るようになった
・Port0接続チェック時間を10秒に延長
・ポート番号が0になってる人は自動的にport0設定
・速度がまったく同じ場合に検索リンクの上下が変だったので修正
要望の多かったBadPort0が分かるようにしましたが、
試してみるとタイムアウトするだけでなるので、
単にネットワーク的にレイテンシ長い場合でも
発生することがあり、これを検出したからといって
強制終了などさせても危険なのでホスト単位で出るようになってるだけです。
あと、転送動作が復活しています。これで匿名性は最高レベルになるはずです。
基本的に上流側で発生します。転送は基本的に一回だけのはずなので、
そんなにダウン率が下がらない、というか、高くなる可能性もあります。
今の検索方式では、上流にいるとキーが見つかりにくいです。
自分の二つより下のキーは、誰かが検索かけてそのキーが上流に
上がってこないとかかりません。だから、今現在では下流にいるほうが
検索しやすいはずです。
今回のならば、上流にいるだけで自動的に転送かかって
何もしないでもそれなりに落ちてきますので、
面倒だから自動で何か落ちてきて欲しい人は上流で、
手動で何か見つけたい方は下流ということになります。
下流の人が何か見つけて落とそうとすると、他の下流から
上流ノードに一度押し付けてからそれを落とすことになります。
これにより、β8より落としやすくなる可能性があります。
当初のWinnyの構想はこれだったので、やっと目標のところまで
たどり着いたことになります。もし調子が悪いとか、転送率が
高すぎるようでしたら、Port0任せの転送であるβ8方式に戻すかもしれません。
- 436 名前：47 投稿日：02/05/13 19:07 ID:gJkkHcII main/1021170898.html#805
- BadPort0と出たら向こうが悪いです。
赤い字でポート警告と出たら警告食らってます。
単に重いだけの可能性もありますが、
あまりに出るようだったら設定不良を疑ってください。
- 437 名前：47 投稿日：02/05/13 19:13 ID:gJkkHcII main/1021170898.html#814
- 単に１０秒以内に繋がるかどうかのチェックなんで、
相手が重いだけとか遠いだけの可能性も高し。
- 438 名前：47 投稿日：02/05/13 19:14 ID:gJkkHcII main/1021170898.html#817
- 逆だ。自分が重いですね。
- 439 名前：47 投稿日：02/05/13 19:41 ID:gJkkHcII main/1021170898.html#865
- 何か、接続が多いとネゴが終わる前にコネクション数でカットされて
転送リンクなども切られてしまっているんでなないのかとの
疑いがあるので、多少無駄リンクが増えるかもしれませんが、
ネゴが終わるまでとりあえず切らないようにしてみたので、
β9.1お願いします。
- 440 名前：47 投稿日：02/05/13 19:46 ID:gJkkHcII main/1021170898.html#873
- 9.1でコネクションは安定しますか？
変でもどうせタイムアウトで切れるんで大丈夫なはずですが・・・
- 441 名前：47 投稿日：02/05/13 20:17 ID:gJkkHcII main/1021170898.html#925
- BadPort0出してる人のところの環境整備があらかた終わるまで
とりあえず様子見かな。Port0の人ばかりだと検索リンク繋がんないはずだし。
（シミュレーションしたときの様子だと、上下リンク３だと輻輳起こさないけど、
末端で接続できないノードが出る。上下４だと接続あまり気味だけど、
検索パケットで輻輳起こすことがある）
これはあまりネットワークの大きさによらずこんな感じだったから
そのせいで繋がりにくくはなってると思います。まぁ、設定がまともで
繋がる人優先ということで。
- 442 名前：47 投稿日：02/05/13 20:18 ID:gJkkHcII main/1021170898.html#927
- とりあえず寝不足なんで寝ます。
何か致命的なトラブルとか起きたらβ８にでも戻してください。
- 443 名前：47 投稿日：02/05/14 07:37 ID:rh93UkNj main/1021291867.html#229
- β9.2です。
BadPort0判定でタイムアウトのためのタスクが止まってなくて関係ないところで
警告出ていた可能性があったので直しました。あと、相手の転送リンクが
いっぱいで蹴られているといのと区別できているのか怪しかったんで、
転送リンクフルで蹴った場合、相手の方にそれを伝えるようにしました。
前のバージョンだと単に切断になりますので、プロトコル的にはβ9と互換があります。
あと、どうしても検索リンクが変だったり、再接続したくなることが多いわけですが、
転送中だとその人がかわいそうってことで、検索リンクと転送リンクを別々に
切れるようにしておきました。検索リンク切断は検索のところにあって、
転送リンク切断はタスクのところにあるんでちと分かりにくいかもしれませんが
ご勘弁を。
あと、長時間放っておくと誰も接続に来ないような地のはてに飛ばされて
マターリしてしまうので、帯域あまっているので帯域を豪勢に転送に提供しても
良いという人向けに、一定時間で自動的に検索リンクを切る機能をつけときました。
これは、システム情報のところにあります。自分で検索して、
相手見つけたらマターリファイルのやり取りをしたい人はＯＦＦでいいと思います。
デフォルトではＯＦＦになってます。
そろそろこういう細かいインターフェイス周りとかのチューニングに
入ったほうがよさそうですね。一時的にβ取ってもいいかもしれません。
まぁ、今現在ですと下流方向の検索率が悪いので、ここの部分だけちとテスト
してみたいところですけど（また検索パケットが溢れる騒ぎになる可能性も）
- 444 名前：47 投稿日：02/05/14 08:07 ID:rh93UkNj main/1021291867.html#242
- 匿名で開発していて直接文句言えない状況で転載不可って主張しても
結局は載せるほうのモラルの問題になりますねぇ。
できればもう少し安定して、厨房対策が完全になるまで勘弁して欲しいところですが。
- 445 名前：47 投稿日：02/05/14 08:09 ID:rh93UkNj main/1021291867.html#246
- >>241
ＩＰ周りはリリース版では隠すと思います。これテスト用だし。
まぁ、もしクラックされたらこの程度の情報は漏れちゃうよということで。
- 446 名前：47 投稿日：02/05/14 08:20 ID:rh93UkNj main/1021291867.html#252
- 当分はプロトコル変わるたびに接続不可能になっていくだろうから
プログラム収録してもまったく無意味だと思われ（ｗ
- 447 名前：47 投稿日：02/05/14 08:45 ID:rh93UkNj main/1021291867.html#255
- >> そろそろ自動再試行がほしいです
ダウン部が比較的安定してきたんでそろそろつけても良さそうですね。
少しお待ちください。
>>254
本来、キャッシュは元ファイルが何なのかわかってはまずいんですけど、
UPフォルダとダブっていても無駄なんで、もしUPフォルダにキャッシュと
同じものが現れたら自動的にキャッシュの方を消すというのなら可能です。
こんなんではだめですか？手動でキャッシュ消せたら
キャッシュ率が上がんないんでできればやりたくないですね。
ああ、そういえばまだキャッシュ消去機能外したままなので容量制限効いてませんβ9.2
そろそろこの辺ですね。
さーて、仕事に行くかな。
- 448 名前：47 投稿日：02/05/14 15:21 ID:1OIcgcFC main/1021291867.html#367
- なんかいろいろ盛り上がってるなぁ。
> 検索キーがポインタのポインタ、転送キーがただのポインタ、今でもそうなってたんでしたっけ？
これは致命的に匿名性が低かったβ8だけの話で、β9ではどちらもポインタのポインタです。
今の検索方式では、UPファイルやキャッシュが転送キーとして上方に拡散して、
これを検索で引っ掛けると検索キーになるという感じですので、どこで転送かかるかは
私でもわかんないです。β9が今までのバージョンで匿名性的が一番高いと思います。
ただ、検索が引っかかり難くなっているのは確かで、これの最大の理由は
上流のリンク切れです。前のβのせいで申告を落とすのが当たり前になっている
んで、だれも上流にこないんで離れ小島ばかりなのでしょう。
- 449 名前：47 投稿日：02/05/14 15:27 ID:1OIcgcFC main/1021291867.html#368
- あと直せないキャッシュですが、UPファイルからできたキャッシュではなく、
キャッシュの転送によりできたキャッシュだとそうなる可能性あります。
UPファイルからの送信の場合、暗号化しながらブロック単位でハッシュ計算
しますので送られてくるのは新鮮なキャッシュ（笑）ですが、このハッシュを
確認するのは今のでは受信時ではなく、ダウンフォルダに展開したときだけです。
キャッシュとしてやり取りされている場合、そのまま送っているだけです。
どこかでキャッシュが壊れた場合、そのまま破損に気が付かないで
出回って、最後に展開しようとしたときにエラーになります。
途中から全部真っ青になるというのなら、一部分欠損ではなく、
どこか短くなってブロックなくなってるんではないかと思います。
これだと後ろ半分が全部バッドブロックになります。
これを防ぐには、UPファイル送信時とキャッシュ解凍時だけでなく、
キャッシュの転送時と受信時にもハッシュチェック入れれば良いわけですが、
ちと処理が重いのと、何か問題があった（確か暗号化とハッシュの順番だった
と思ったけど）んで、こうなってます。頻繁に発生するようなら対処要りますね。
- 450 名前：47 投稿日：02/05/14 15:33 ID:1OIcgcFC main/1021291867.html#371
- あと、キャッシュが完全かどうかの判定は、通常はヘッダに各ブロックがまともかどうか
書いてあってこれを見てるだけです。キャッシュを解凍したときに、ファイル全部見て
ハッシュ再計算して比較して壊れているか判断します。
ハッシュの計算するにはファイルの全部を一度読み込む必要があるんで
この辺は仕方ないです。完全キャッシュだと思って変換かけてみると
一部分壊れているのがわかって破損キャッシュになることがあるのはそういう事情です。
- 451 名前：47 投稿日：02/05/14 15:41 ID:1OIcgcFC main/1021291867.html#380
- キーの処理は、今になってみると何も考えずにクエリで引っかかったキーを
全てクエリパケットに押し込んでいたのが前のβで重かった最大の理由だったと思います。
今ですと１ノードの検索では最大１００個しかパックしません。
どうせ画面で見えるのは２００個ですし・・・
ただ、当初のキー周りの設計予定ではMX（というかWPNP）のサーバレス版というのを
考えていたんで、ここのところが計画変更になってます。
当初の計画では、末尾のノードは、手持ちのキーを全て一つ上に投げて、
それより上のノード間でのみクエリをやり取りする計画でした。
ただこれが重かったんで、全キー転送はやめてクエリを下流にも出しているのが現状です。
これのせいで、誰も検索していない場合、二つ下のノードのファイルが現状見えません。
（下で検索されて上ってきた転送キーが検索にかかるんで完全に見えないわけではないですが）
そんなわけで、この辺はちとうまく動いていないのが現状です。
ただ、結局全部見えるようにしようとすると、集中サーバ入れないと辛いか、
クエリが帰ってくるのが極端に遅くなるかのどちらかなんで、今の方式を
もう少しリファインするのもいいいかと思っています。
- 452 名前：47 投稿日：02/05/14 15:54 ID:1OIcgcFC main/1021291867.html#394
- あとコネクトの切断のとこはちと悩みどころでして。
書き込み側が何か重要なデータ書いた後に問答無用にソケット切断すると
その書き込んだデータがロストして向こうに届かないことがあります。
この辺はいろいろお約束があるのですが
（ってUNIX ネットワークプログラミング家に置いてきちゃったよん）
そんなわけで今は書き込み側の確実性優先になってることが多く、回線切るのは
基本的に読み込み側になってます。書き込み側の回線切断は、切断コマンドを
送っているだけの場合が多いです。shutdownもちと統一されてない。
相手がちゃんと切ってくれるとは限らないのと、相手が切ったのをちゃんと
検出できるとも限らんので切り忘れてることあるんじゃないかと。
とりあえずLinger絡みはもう一度見直します。
- 453 名前：47 投稿日：02/05/14 15:55 ID:1OIcgcFC main/1021291867.html#395
- あと、帯域制限は単になくても致命的でないということで後回しになってます
- 454 名前：47 投稿日：02/05/14 16:10 ID:1OIcgcFC main/1021291867.html#400
- β８が匿名性低いといってもあれでもMXよりは上だったはずで、
転送が発生する今のバージョンではかなり匿名性は高いはずです。
ただ、思ったより転送が起きないみたい（これは検索が遠くまで行かないことに起因）
なんで、転送リンクの先がかなりの高確率でキャッシュかUPファイル保持でしょうねぇ。
とりあえず画面でIP出さなければ問題ないですけど、クラックされると
今のβと同じ情報までは得られるわけでして・・・
というか、今のベータは公式クラック版だったり。
- 455 名前：47 投稿日：02/05/14 16:14 ID:1OIcgcFC main/1021291867.html#403
- 転送キーが上流に拡散中にそのIPを書き換えることがあります
これで転送が発生します
- 456 名前：47 投稿日：02/05/14 16:21 ID:1OIcgcFC main/1021291867.html#407
- えーとですね。今のWinnyで
・検索率
・検索時間
・ダウン率
・匿名性
・回線負荷
・実行負荷
でどれが一番問題でしょうか？検索率だとは思いますが、
どれかを上げようとするとどうしても他に負担がかかります。
バランスの問題・・・・
- 457 名前：47 投稿日：02/05/14 16:26 ID:1OIcgcFC main/1021291867.html#410
- 接続良くなれば検索率上がるはずなんだよねぇ。
とりあえずこっちやるか・・・
- 458 名前：47 投稿日：02/05/14 16:28 ID:1OIcgcFC main/1021291867.html#413
- 検索率低いのが気になるのなら、検索リンクをプチプチ切って目当てのものが
見つかるまでさまようか、一番確実なのはここで自分のIPを晒す。
これで交換にも利用可能（ｗ
- 459 名前：47 投稿日：02/05/14 16:32 ID:1OIcgcFC main/1021291867.html#418
- 例として検索率向上を狙うとどうなるかですが、
Freenetのように全探索させる方式に変える→検索時間が長くなってダウン率が極端に低下
上流に流すキーを増やす→CPU負荷と回線負荷が上がる
WPNPのような方式に変える→鯖無しでは無理っぽい。匿名性が落ちるのではないかと。
とこうなります。
今のところCPUと回線負荷は低めなので、少し下層からのキー転送量増やしても
いいかもしれませんが、CPUと回線負荷が増えますよん。やらないほうがいい？
- 460 名前：47 投稿日：02/05/14 16:33 ID:1OIcgcFC main/1021291867.html#419
- ＞転送リンクフルで蹴った場合、相手の方にそれを伝えるようにしました。
ということですが、どこに表示されますか？
相手のノード情報にBusyと出ます。タスクの方に出ないので分かり難くてすいません。
- 461 名前：47 投稿日：02/05/14 16:39 ID:1OIcgcFC main/1021291867.html#422
- >>420
とりあえず暫定処置として、
状態タブで仮想キー優先で表示させるというのではだめですか？
そのうちUPやキャッシュ表示させないオプションつける予定ではありますが・・
- 462 名前：47 投稿日：02/05/14 16:53 ID:1OIcgcFC main/1021291867.html#433
- 今は、上流側は上れるだけ検索、下方向は一つ下のノードに検索にかかったものを
上に投げてもらうって感じですね。あと、手持ちのキーを全部送る動作は一切無しで
クエリにひっかかったものだけが上流に伝播してきます。
一つの案は、今の方式に加えて下流リンクが無いノードが手持ちキーを一つ上に
全部送ってしまう方法です。だいたい上下リンクが３層以上になることはないので、
これでかなりヒット率が向上するのは間違いないんですけど、結構重いでしょうねぇ。
昔のβ5あたりにこれに相当するのがあったはずだし。
- 463 名前：47 投稿日：02/05/14 17:02 ID:1OIcgcFC main/1021291867.html#442
- 細かい点は後回しなのでよろしくー。
基本部分で改善可能なのは検索率向上程度なんで
少し試してもいいけど、これに関しては実はユーザさんが増えてくれば
それでいいだけだと思ってたりもするんですよね。
一つだけあるファイルが全員に見えるようにするとどうしても
各所に負荷があがるけど、十分ダウン可能ならキャッシュが広まるわけで、
自動的に検索でかかる率も高くなります。
もちろんマイナーなファイルは見えませんが・・
もう、メジャーなファイル専用と開き直るのも手です。
今までのβの実験ではそんな感じ。
- 464 名前：47 投稿日：02/05/14 17:08 ID:1OIcgcFC main/1021291867.html#446
- >>444
現状での最善策はそれかもね。
上流のノードはより上流を見つけないと検索率が下がるんで、もっと相手を
探しまくってもいいけど、下流ノードにそれやられると上流ノードがウザイだけだし
下流ノードも重いだけ・・・
簡単だしやってみますか。
- 465 名前：47 投稿日：02/05/14 17:21 ID:1OIcgcFC main/1021291867.html#457
- まー、どうせ人が増えてくると検索率より他が問題になるから
それを見越して他の部分やった方がよさそうですね。特に接続部は危険そう。
てなことで接続部の変更はできましたけど帰んないとテストできないです。
- 466 名前：47 投稿日：02/05/14 17:36 ID:1OIcgcFC main/1021291867.html#463
- ダウン率良くなったことだしIP表示消して
ID0, ID1, ・・・にでもしますか？
そういえば、検索のところのホストのところってID表示で残ってた方が
いいですか？それとも完全になくしますか？
- 467 名前：47 投稿日：02/05/14 17:40 ID:1OIcgcFC main/1021291867.html#469
- 今の方式のままなら、ファイルがどんなに増えても負荷は
それほど上がんないと思います。
爆発的に重くなったバージョンでは、持ってるキーを全て送るという動作が
入っていましたけど、今は検索にヒットするものしか送ってません。
そして、１クエリで引っかかるキーも制限されてます。
それより問題は、人増えたらますます接続できなくなることでしょうね。
- 468 名前：47 投稿日：02/05/14 17:42 ID:1OIcgcFC main/1021291867.html#472
- ああ、あとジャンルわけの話は、とりあえずキー管理部の負荷は
検索率を犠牲にすることで回避できそうなんでもっと先の話ですね。
クライアント増えてくれば何れはやることになるでしょう。
- 469 名前：47 投稿日：02/05/14 18:38 ID:1OIcgcFC main/1021291867.html#498
- ある意味検索率向上を狙って（ｗ
IP表示関連やキーの種類表示などもやめました。
これで匿名性的には正式版と同じです。
あと、キャッシュやUPフォルダ内のファイルが見えなくできるようにしときました。
が、まだテストしていないので公開してません。少しお待ちを。
あと、キャッシュに関する操作は容量制限以外まったくやらない
予定ですのでよろしく〜。これはユーザにとっては邪魔以外の何者でもありませんが、
Winnyでは他へのダウン率を上げるための必要悪です。
DOMに意味を持たせる為のものですので、想定された使用法に従ってください。
- 470 名前：47 投稿日：02/05/14 18:42 ID:1OIcgcFC main/1021291867.html#500
- 分けてどうされるのでしょう？
それを消すのが目的だとしたらなおさら分けませんが。
- 471 名前：47 投稿日：02/05/14 19:15 ID:1OIcgcFC main/1021291867.html#523
- ファイルの大きさまで偽造したいのなら、適当なブロックにファイル分割して
保存しておけば簡単かな。Winnyの１ブロックは64kなんでとりあえず
10ブロックに切っとくとかで。
まぁ、トラブルの元なんでキャッシュに悪さするプログラムでも
出てこないかぎりやらないですけど。
あと、Upファイルの参照数はまだ未実装です。β１出すときに
付けてから発表しようかと思いましたが、どうせ当分無意味だろうと。
十分ダウン率が上がってきて、UPリンク過多で困ってきたら
例の優先度システム周りとあわせての実装になるでしょう。
- 472 名前：47 投稿日：02/05/14 21:21 ID:5zIyWbCC main/1021291867.html#556
- β9.3です。
細かい修正ばかりで主に各種のパラメータ関連です。
- 473 名前：47 投稿日：02/05/15 13:20 ID:oTMWhYN1 main/1021291867.html#831
- β9.4です。不都合が溜まりすぎてた操作系の修正がメインです。
・ クエリが返ってきたときのタイミングで再描画するように修正
・ 転送リンク切断を消した
・ タブの幅をiniファイルに保存するように修正
・ Windowの大きさをiniファイルに保存
・ リストコントロールの表示が消えることがあるのを修正
・ キーの寿命を延長
・ リンク数限界を４に戻した
・ 破損キャッシュの名前を不完全キャッシュに変更
- 474 名前：47 投稿日：02/05/15 13:22 ID:oTMWhYN1 main/1021291867.html#835
- > ・ 破損キャッシュの名前を不完全キャッシュに変更
修正。長いんで部分キャッシュにしたんだった
- 475 名前：47 投稿日：02/05/15 13:31 ID:oTMWhYN1 main/1021291867.html#841
- 最近はちーと用事が多いんであまりこればかりやってられないのでよろしく〜
- 476 名前：47 投稿日：02/05/15 13:57 ID:oTMWhYN1 main/1021291867.html#848
- すいません。タブ周りバグってました。直しましたんで9.4読み直しといてください。
- 477 名前：47 投稿日：02/05/15 16:05 ID:IlIfcVaJ main/1021291867.html#888
- 自動再試行試す前に最後の実験。
ということでβ10です。
検索率はβ９と比べると画期的に良いはずですが、問題はどの程度の負荷になるかです。
やってること的には、何もしないでもたまに検索出しているのと同じことなのでβ５
以前のようなべらぼうな負荷にはならないはずですが、多少実験的な要素がありますので
ご了承ください。
プロトコル的にはβ９との互換性がありません。
- 478 名前：47 投稿日：02/05/15 16:15 ID:IlIfcVaJ main/1021291867.html#895
- そういえば、「あ」さんお疲れ様です。
何かやるたびにお手数おかけしてしまいますがよろしくです。
- 479 名前：47 投稿日：02/05/15 16:18 ID:IlIfcVaJ main/1021291867.html#900
- >>897
そういえば、部分キャッシュは落とせる場合だけ表示されるようにしました。
落とせないもの表示されていてもむかつくだけでしょ。
- 480 名前：47 投稿日：02/05/15 16:28 ID:IlIfcVaJ main/1021291867.html#907
- あと、自ノードのキー表示ＯＦＦの場合の挙動で
本当はキャッシュは完全キャッシュでも表示させるべきなのではないかと思ったのですがどうでしょう？
今ですとキャッシュかＵＰフォルダにあるとそのファイルが表示されないので、
転送でキャッシュ内に既にあるファイルは、せっかく何もしないでもダウンできるのに
それに気が付きません。
既に気が付いていて邪魔ならＵＰフォルダに移動させれば、オプションＯＮ時に出ませんし・・・
- 481 名前：47 投稿日：02/05/15 16:37 ID:IlIfcVaJ main/1021291867.html#914
- β10とβ9.4での違いで
１．どこが変わったかわかんない
２．それほど重くなったとは思えないけど仮想キーが溜まるようになった
３．くそ重いぞゴラァ
の三通りありうると思うんで報告よろしこ
回線速度と、仮想キーがどの程度の数になっているか教えていただけると調節に使えます。
- 482 名前：47 投稿日：02/05/15 16:40 ID:IlIfcVaJ main/1021291867.html#918
- あと、同じファイルを二回ダウンかけると自動的に
別のところを読みにいくようになってる（つまり分割ＤＬ）ですが、
細かい破損ブロックが出やすいのでレジュームかけてください。
- 483 名前：47 投稿日：02/05/15 16:50 ID:IlIfcVaJ main/1021291867.html#932
- β9.4だと、だれも検索かけないと上流ノードでキーが空になって
検索に何もかからなくなってしまいます。
だから空検索かかるようになってるのがβ10です。
ひょっとすると上流側で糞重くなる可能性があります。
>>927
接続停止時に指定されたポートのliten止めてたかどうか怪しいですが
（確か再起動しないと止めないような）、listenしてるポートは一つだけの
はずなんで、他のものは他のアプリではないですか？
- 484 名前：47 投稿日：02/05/15 16:54 ID:IlIfcVaJ main/1021291867.html#939
- >>922
中身同じなら、UPフォルダに置けばどこからみても同じファイル扱いされます。
UPフォルダに置いたファイルは外から見たら単なる完全キャッシュです。
というのでは何か的外してますか？
ああ、あと同じものがどこかにキャッシュとしてあっても同じ扱いです。
システム側ではどれも同じものとみなして適当に選んでもっていくだけです。
ファイルの区別は、今のバージョンではファイル名は完全に無視で、
見てるのはハッシュとファイルのサイズだけです。
- 485 名前：47 投稿日：02/05/15 17:08 ID:IlIfcVaJ main/1021291867.html#947
- ハッシュ同じで名前違うと検索の度に名前変わると思います
しかし、プロトコルぽこぽこ変えるのも考え物ですな。
速度とかが表示されないで１０秒後に切れるのは主に
プロトコル違いのはずですが、これのせいでコネクション回数が凄いことに。
バージョン変わったら使うポート番号かえてもらえると助かるかも。
- 486 名前：47 投稿日：02/05/15 17:25 ID:IlIfcVaJ main/1021291867.html#959
- 一応こちらの想定範囲内の挙動してるようではありますが、２が多いとすると
2A. 仮想キー増えたけど検索率が良くなったような気はしない
2B. 多少はヒットしやすくなった気がする
2C. なぜか転送成功率が上がったような
この辺ありますがどうでし？
原理的には上流でのキーロストが減ることで転送率も上がるはずですが。
- 487 名前：47 投稿日：02/05/15 17:32 ID:IlIfcVaJ main/1021291867.html#967
- これでそんなに重くなんないのならこのまま様子見でバグ取りに注力でいいかも。
そもそもキーに書いてある本体の位置はIPとして書いてあるんで検索リンク切れても
相手のUP変わるか回線断しないかぎりロストしないでコネクションにいけるはずなんよね。
てっきりこの辺でダウン率悪いのかと思ったら主な理由はＦＷだったし、
当初の設計に近いこのβ１０で問題なく動けば、良いとこ取りできるはずなんですけど。
- 488 名前：47 投稿日：02/05/15 17:35 ID:IlIfcVaJ main/1021291867.html#984
- β10は匿名性は今までで間違いなく最高のはずなんで、
ダウン率と検索ヒット率がそこそこ確保できれば
とりあえず成功までこぎつけたと言えるんですけど
どうなんでしょうね。
- 489 名前：47 投稿日：02/05/15 17:53 ID:IlIfcVaJ main/1021451237.html#22
- 今回のは前のと違って全体のファイル数がどんなに増えてもそれほど負荷がかわらないはず
（ただしファイル数とノードが数が増えると検索ヒット率が下がっていく）なんで、
改悪にはならないですんでますか？わりと検索率が良くなってる気がしますが。
これでうまく動くようならプロトコル的にはそろそろβからフィックスかもしれません。
- 490 名前：47 投稿日：02/05/15 18:16 ID:IlIfcVaJ main/1021451237.html#39
- >>38
りょうかーい
- 491 名前：47 投稿日：02/05/15 18:47 ID:IlIfcVaJ main/1021451237.html#46
- うーむ、見直してみたけどListen側が漏れる理由が良く分からん。
これが出る方に質問ですが、ひょっとして２０分で自動切断する
機能が入った状態でのみなりますか？
- 492 名前：47 投稿日：02/05/15 19:42 ID:IlIfcVaJ main/1021451237.html#64
- β10.1です。
β9と10では接続部何も変わってませんけど挙動が違うのは
単にβ10の方が重いというだけのようです。どこも変えてないし。
で、挙動をみてると単に限界以上のコネクションかけようと
している（特に上流設定）だけみたいなんで、接続率を全部
落としてみました。これで動作が安定するんではないかと思います。
- 493 名前：47 投稿日：02/05/15 19:43 ID:IlIfcVaJ main/1021451237.html#66
- ああ、あとプロトコル同じです。
- 494 名前：47 投稿日：02/05/15 19:54 ID:IlIfcVaJ main/1021451237.html#69
- 正直、作り始めたときはちゃんと動くものになる確立が半分もないだろうと思ってたけど
最近はどうにかなるかもと思ってます。
- 495 名前：47 投稿日：02/05/15 22:56 ID:IlIfcVaJ main/1021451237.html#148
- β10.2です
・ 転送失敗時にコネクション限界かどうかをチェックして表示
・ 向こう側から切断すべきソケットなのに切断忘れになっているソケットを
無通信タイムアウトで切断するようにした
・ ダウン済みを表示しないオプションで、完全キャッシュは表示するようにした
Listenポートは、切ってもらうはずのポートが切ってもらえないで待ちに
入ってるソケットのように思えますので、無通信時間チェックして強制的に
切断するようにしときました。
あと、みょうにダウンが始まってから切れることですが、どうも転送リンク限界で
切れているようです。チェック入れてタスクの方にもこれを出すようにしました。
ただ、転送時にこのエラーを転送していないので転送先でリンク限界だと
転送切断エラーになると思います。
- 496 名前：47 投稿日：02/05/15 23:01 ID:IlIfcVaJ main/1021451237.html#152
- ああ、あとプロトコル共通です。
今のプロトコルで何か致命的な問題が出るまでとうぶんこのままではないかと。
ダウン率落ちたように見えるのは単に見えるファイルが増えたのに
ダウンできる率はそのままだからＵＰ帯域が余ってないだけのようです。
やっと、優先度の機構を入れるべきところまで到達したのではないかと。
- 497 名前：47 投稿日：02/05/15 23:07 ID:IlIfcVaJ main/1021451237.html#156
- これだと、自動再試行の前に優先度の実装だと思う。
既に帯域が溢れてるんで自動再試行つけても悪化するだけです。
今の方式だととりあえず早いもの勝ちで相手が切るまでは最後まで落とせるはずです。
- 498 名前：47 投稿日：02/05/15 23:18 ID:IlIfcVaJ main/1021451237.html#162
- コネクション接続限界が遅れる理由ですが、
相手に限界であることを教えるために、
コネクションを受けた方は問答無用で回線切らずに、
相手に限界ですよーって伝えて、それを聞いたほうが
自発的に転送リンク切ってるんです。
このやり取りに少しタイムラグが発生するわけです。
小さなものなら割り込んで落とせるかもしれません。
実はクラックすると割り込めるクライアントが作れたりも(^^;
この辺は優先度の機構入ったら丸ごと別物になると思います。
- 499 名前：47 投稿日：02/05/15 23:22 ID:IlIfcVaJ main/1021451237.html#166
- あと中継で追い越すことはないです。
先頭からブロックが存在しているかチェックして、
抜けてる部分を常に落としに行きますので、
転送が間に合わなかったらそこで待ちになります。
あと、転送で受け取ったら既にそのブロックがあった場合、
他にもどのファイルをダウンしているタスクがあると判定して
ある程度先から読み始めます。これにより、複数ダウンかけると
常に別の部分を読みに言って結果的に分割ＤＬ動作になります。
転送時には同じファイルのＵＰ動作もしているわけですし、
実装的にはブロック単位で好きなだけ
アップやダウンできるようになってます。
- 500 名前：47 投稿日：02/05/15 23:27 ID:IlIfcVaJ main/1021451237.html#169
- あと、転送でキーのＩＰ書き換えるときや、他から回ってきたキーと同じキャッシュを
持っている場合、ＵＰ数が余っている場合だけ上書きしますので、
自動的に空いてるところから落としにいくはずですが、
キャッシュが広まってないと結局大本のＵＰファイルを持っている人のところに
全てコネクションが行きます。
小さいものなら直ぐにキャッシングされるはずですが、そうなると
落とす相手が変わりますので、一度検索かけ直してから
再試行したほうが落としやすくなるはずです。
- 501 名前：47 投稿日：02/05/15 23:52 ID:IlIfcVaJ main/1021451237.html#190
- うーん、コネクションが残る問題直ってないなぁ・・・
- 502 名前：47 投稿日：02/05/16 02:42 ID:eCUvVMNI main/1021451237.html#293
- β10.3です
・ キャッシュの転送が発生しにくかったので修正
・ キーソーターのバグ取り
・ Noderefで、ポートが書いてないホストは無視
・ ソケットオプション変更
少しはダウン率と安定性良くなるはずですが、
根本的な対策になってないような気も。
とりあえず眠いんで寝ます。
- 503 名前：47 投稿日：02/05/16 02:43 ID:eCUvVMNI main/1021451237.html#294
- ああ、あとプロトコル共通です
- 504 名前：47 投稿日：02/05/16 03:00 ID:eCUvVMNI main/1021451237.html#303
- 一応UPに空きがなければ転送発生しないはずだけど、
この状況では少しでも空いてれば速攻で転送入っちゃうかもしれず。
特に上流。
- 505 名前：47 投稿日：02/05/16 03:11 ID:eCUvVMNI main/1021451237.html#306
- 転送というより、現状では他のノードにダウンかけてＰＣ使用者が知らないうちに
キャッシュとして持たせておいて、これを後から落としているという間接的な転送に
なっているｌことが多いはずです。だから転送が早い割には解析が困難なわけで。
- 506 名前：47 投稿日：02/05/16 03:17 ID:eCUvVMNI main/1021451237.html#309
- パケットとってもそれを解析するなりプログラムクラックしないと
どのソケットにどのファイルが流れているのかわかりません。
ソケット内で流れている暗号はそう簡単にとけるものでもないと思う
（ファイルの暗号化に使ってるのと同じですが、キーが完全に動的です）
んで、やるとしたらプログラムクラックになりますが、前のＩＰ出してたβ
程度の情報しか得られません。クラックさえすれば、
どこのＰＣにどのキャッシュがいったかは分かりますが、キャッシュを
中継しただけというのがどういう扱いになるかですね。
- 507 名前：47 投稿日：02/05/16 03:18 ID:eCUvVMNI main/1021451237.html#310
- >>308
ＵＰフォルダに置くとハッシュが同じなので自動的に消えます
- 508 名前：47 投稿日：02/05/17 00:10 ID:Rw0jcbSP main/1021451237.html#511
- β11です。
内容はほぼ例のソケットリーク周りです。
port0チェックのために逆コネクションかけているのが根本的な理由でしたが、
この辺はかなりいいかげんな作りになっていたので作り直しました。
おかげで手間取りましたが、動作的には安定するはずです。
ただし、これのせいでプロトコルまで変わったのでβ10との互換性がありません。
・ ソケットコネクションリーク解決（対策でコネクション数表示追加）
・ Port0テスト方式を変更（空転送リンクを作成）
・ メモリ上でノード情報を暗号化対策
・ 転送リンク限界を少し増やした
・ 他、細かいバグフィックス
- 509 名前：47 投稿日：02/05/17 12:52 ID:wBJB59Zz main/1021451237.html#673
- β11.1です。β11とプロトコル互換です。
・ 受可キャッシュも転送対象になるようにした
・ 受可キャッシュになる可能性の無い部分キャッシュが完全キャッシュ
扱いされてダウン率が低下していたのを修正
・ 分割ダウンすると破損ブロックが出るのを修正
・ ダウンロード失敗理由が誤って表示されるバグの修正
・ ハッシュが全て00のキャッシュは削除
・ 転送動作時に最終ブロック受信が失敗しやすいのを修正
・ 接続失敗時に他ノードを紹介してもらえる率を向上
・ 転送リンクコネクションの成功率を向上
・ タスクの完了のみクリアボタンをつけた
・ ListView書き換え時にRedrawOFFに
- 510 名前：47 投稿日：02/05/17 13:42 ID:Gvhxc5NR main/1021451237.html#694
- >>687
そういえばデバッグ用に外したの忘れててそのままだった。
この辺の転送やUP履歴はどうすべきなんでしょうかね。
今の予定では自分のDOWN以外全部出さない予定ですけど
（既にUPは見えない状態に戻ってます）
- 511 名前：47 投稿日：02/05/17 14:20 ID:Gvhxc5NR main/1021451237.html#704
- 転送結果が残るのはうざいんで消しときました。
すいませんが11.1落とし直しといてください。
あと、転送中も消そうかと思いましたが、
転送してるのかどうかが分からないと
βの間は困りそうなのでそのままです。
- 512 名前：47 投稿日：02/05/17 16:24 ID:Gvhxc5NR main/1021451237.html#727
- 上流側で落ちるパターンは二つあって、
キーを保持しすぎて落ちるケースと、
コネクションがかかりすぎて落ちるの二通りが典型なはずなんですけど、
どちらが多いですか？下流コネクションの出来すぎですか？
どちらかで対処法が変わってくるんで教えてください。
- 513 名前：47 投稿日：02/05/17 16:47 ID:Gvhxc5NR main/1021451237.html#738
- β11.2です。β11と互換があります。
βテスト参加人数が増えてきていて、人気があるサイトで上流側のリンクが
切りきれないことがあるので対処してあります。
あと、キーが一箇所に固まりにくくもしてあります。
キーの上昇率などは変わってないので単純にノードが増えているようだと、
キーの上昇率を落とす必要がありますので、これで様子見してください。
- 514 名前：47 投稿日：02/05/17 16:49 ID:Gvhxc5NR main/1021451237.html#743
- 修正
>人気があるサイトで上流側のリンク
これ人気のある上流サイトです。
切っているのは下流検索リンクです。
問答無用で5になるまで切りにいって最後の一人にのみ他のノードを紹介します。
- 515 名前：47 投稿日：02/05/17 17:02 ID:Gvhxc5NR main/1021451237.html#747
- 接続が多いからといって問答無用で切っても、切られた方は
また接続かけてくるんで単純に接続切っても無意味だったりします。
だからある程度付き合ってあげて他のホストを紹介してあげる
必要があるんですけど、ここの分配は試行錯誤でして、
今までですと検索リンクが８超えなければ付き合ってあげるという
処理でしたが、これでも対応が丁寧すぎるレベルになってきていますので、
５を超えたら問答無用で全部カット。最後に残った一つのみに
他のホストを教えるという処理に今回書き換わってます。
>>746
本来、やばいものは暗号かけて使うべきなんです。
暗号が空でなければ、転送中は絶対に見れません。
私の方で解析しようとしても無理です。キーが分かりませんので。
今見えているのは、単にみんなが空キー使っているからですね。
- 516 名前：47 投稿日：02/05/17 17:06 ID:Gvhxc5NR main/1021451237.html#751
- 一応仕事中なんですけど（ｗ
- 517 名前：47 投稿日：02/05/17 17:18 ID:Gvhxc5NR main/1021451237.html#759
- キー数制限が今は１万だけど５千程度にしちゃおうか。
そんなに影響ないはずだし。
- 518 名前：47 投稿日：02/05/17 17:38 ID:Gvhxc5NR main/1021451237.html#771
- うーん、設定増やすほどわけ分からん設定して周りに迷惑かける人が
増えるんでできればこういうのは自動にしたいとこ。
とりあえず次Verから5000制限に落しますわ。
メモリ上でもキーの一部分を暗号化（具体的にはIPですが）
したんでこれで少し重くなってるというのもあるでしょうけど、
１ノード内のキー数はそれほど重要でなくて上流にある程度
溜まってさえいてくれれば検索は確保できるんで、
無理してメモリとCPU負荷上げても仕方ないと思うし。
単にヒット数上げたいのなら、上流ノードの上流リンクをもう少し
工夫した方がいいはず。
しかしこうなるってことはユーザ数1000突破しとるなぁ・・・
- 519 名前：47 投稿日：02/05/17 18:18 ID:Gvhxc5NR main/1021451237.html#777
- 今のやり方でもパラメータ微妙に調節していくことで
１万ノード程度まで耐えられるはずだけど
そこまでいくと今度は検索ヒット率の低下が酷くて
キャッシュ無し状態での検索ヒット率が１％程度になっちゃうはず。
正確なところはシミュ書き直してパケットの中継回数とか統計とれるように
しないとわかんないけど、今だとリンクがそんなにプチプチ切れないという仮定で
ノード数１０００、トータルキー数１０万程度なら２〜３割のヒット率って
感じじゃないんですかね。上流がちゃんと網作ってくれれば飛躍的に
ヒット率上がるはずだけど切断率がすごくて上流はぜんぜん繋がってないみたいだし。
しかし４月初頭の想定よりプログラムが重くてCPUとメモリを消費するのが痛い。
初めの設計では１万ノード程度までは検索率８割キープのはずだったんですけど、
そもそもトータルキー数を一桁か二桁誤って推定しとったのが致命的。
またチューニング作業でもしますか。
どちらにせよ今の十倍の規模になったら例の明示的なクラスタリングが
必要になります。これだと今のMXと同じ規模まで耐えられると思います。
今のβテスト規模のネットワークが横に１００個程度連なることに。
- 520 名前：47 投稿日：02/05/17 19:10 ID:Gvhxc5NR main/1021451237.html#785
- 完了後に破損扱いになるのは783氏が書かれているように
転送もとのキャッシュが壊れていてそれをまた落しにいってるのではないかと。
ハッシュ値がぶっ壊れているのでなければ、
元ファイルか正常なキャッシュファイルを持っている人を探すことで修復可能です。
一度再検索すれば他の人から落せる可能性あるんで少し置いて落しなおすと
良いのではないかと。
- 521 名前：47 投稿日：02/05/17 19:48 ID:daRc0Eo8 main/1021451237.html#791
- 部分キャッシュは破損していてもがんばって落としていけばいつか修復できるはずです。
これの報告が多いようでしたら、キャッシュのアップロードが多少重くなりますが、
ＵＰファイルＵＰ時と同じようにハッシュチェック入れることにします。
- 522 名前：47 投稿日：02/05/17 19:51 ID:daRc0Eo8 main/1021451237.html#792
- ちなみにハッシュのメカニズムですが、現状では
ＵＰファイルのＵＰ→オリジナルファイルのハッシュを計算してキャッシュ化してその都度送信
キャッシュファイルのＵＰ→ハッシュ計算などはしないでそのまま送信
受信側→何もしないでキャッシュフォルダに置くだけ
キャッシュからダウンフォルダに展開時→ハッシュチェック
このようになっています。
- 523 名前：47 投稿日：02/05/17 19:52 ID:daRc0Eo8 main/1021451237.html#793
- >>790
β11.2では高速申請ノードに負荷が集中するのを防ぐために遊びが大きくとってあります。
バグではなく仕様ですね。
- 524 名前：47 投稿日：02/05/17 22:56 ID:UZeC2zNO main/1021451237.html#833
- β11.3です。プロトコルはβ11共通です。
たまには狙って何か落として見るかと思って自分で使ってみましたが
何度もダブルクリックしないとまず落ちないので頭にきて自動再試行つけてしまいました（ｗ
転送がかかった場合、まずタイミング的な問題で２、３回接続かけないとだめ
なんで、標準でこの機能がついていても問題ないと判断しました。
相手が回線フルだとなんかいやってもだめなんで直ぐに試行回数を使い切ります。
ちなみに１０回までです。１０回使い切るとバックグラウンドで自動的にクエリかけなおして
ますので、ダウン対象が変わる可能性が高いです。どうしても落としたい場合は、
そのあとまた再試行かけてください。
あと、キー数限界が５０００になってます。
- 525 名前：47 投稿日：02/05/17 22:59 ID:UZeC2zNO main/1021451237.html#836
- ちなみに、
「ダメなやつは何をやってもダメ」
なんで、転送時のスタート遅延対策と長時間ダウン時の自動リトライ程度に
考えといてください。
- 526 名前：47 投稿日：02/05/17 23:00 ID:UZeC2zNO main/1021451237.html#837
- ああ、あと今回、転送時も画面に出ないようになってます。
かなりRelease1に近づいているのではないかと。
- 527 名前：47 投稿日：02/05/17 23:11 ID:UZeC2zNO main/1021451237.html#843
- 現状優先度は何も無いです。早いもの勝ちです。
こんなんで優先度決めても何も落ちないはずなんで、
とりあえず強制的に他のノードに落とさせてしまって
キャッシュ広めたほうが早いんじゃないのかと。
- 528 名前：47 投稿日：02/05/17 23:19 ID:UZeC2zNO main/1021451237.html#850
- 落とすキーがすげ変わる件ですが、今回のバージョンでかなりよくなるはずです。
キーがすげ変わるのは、タイミングの問題でしかたないです。
現状、キーＩＤの形式でタスク持ってるんで、検索直後に直ぐにダウンかけないと
キーロックする前に他キーに入れ替わる可能性は避けられません。
特に上流でキーバッファの変更が激しい場合はそうなります。
今回のでも１０回の再試行使い切った場合はかなりの確率の別のものに
なるんで、一度再検索かけたほうがいいです。１０回の試行中はキーが
ロックされているんで別のものにすげ変わる可能性は低いはずです。
そんな事情もあって早めに自動再試行つけました。手動で再試行やっているかぎり
すげ変わるのは防げません。
- 529 名前：47 投稿日：02/05/17 23:22 ID:UZeC2zNO main/1021451237.html#853
- 現状、キーのハッシュじゃなくてキーのＩＤ（リストでの位置）でダウンかけるように
なってるから、無理に再試行かけても別のものが落ちてくる可能性高いってことです。
- 530 名前：47 投稿日：02/05/17 23:41 ID:UZeC2zNO main/1021451237.html#882
- というか、どうも何を落とそうとしても落ちないみたいなので、
これで状況が悪化するかどうかで理由を探ろうというのもあります。
これで悪化しないのなら多少切れるのはお約束でWAN上で動かす上では
リトライ必須ってことで。
ＤＯＷＮ側もそうですが、これでＵＰ側が悪化するかどうかのチェックもよろしくです。
所詮まだβですので、一種の実験です。
- 531 名前：47 投稿日：02/05/17 23:56 ID:UZeC2zNO main/1021451237.html#897
- キー数が5000限界のはずなのに2000で止まるのは単なるミスでしたので
直しときました。すいませんがβ11.3落とし直して置いてください。
あと、再試行が早すぎるように思えるのはそれで正解です。
やってみると分かるのですが、そうなってないと悪化させるだけで何も落とせません。
- 532 名前：47 投稿日：02/05/18 03:25 ID:bsKQ5BtD main/1021653459.html#68
- β11.4です。
β11以降の問題点として、逆に転送がかかりすぎるというのがあったようなので
直しました。見直して見ると、確実に転送がかかるので、離れていると
その間全てにキャッシュが広まる状況だったようです。ですので、
離れている分ダブルクリックして隣までキャッシュが来ないと落とせないと。
今回、それ直しましたので落としやすくなると思います。
あと、暗号キー入力でかってに補完されていたようなのでそれを直したのと、
キーの上昇率が高すぎて検索リンクの転送負荷が凄くなっていたようだったので、
これを落としました。
- 533 名前：47 投稿日：02/05/18 03:29 ID:bsKQ5BtD main/1021653459.html#73
- ああ、あとプロトコル同じです。
これに代えるだけで自分のノードの転送率は下がって軽くなるはずですが、
ダウン率は他のノードが11.4に代えていってくれないと復活しないはず。
- 534 名前：47 投稿日：02/05/18 03:31 ID:bsKQ5BtD main/1021653459.html#74
- 今の再試行時間は０秒でタスクが異常終了したら速攻で再起動しているだけですが、
ISDNでどうなるかはこちらに環境がないので分かりません。
詳しい説明していただけないと直せないと思います。
- 535 名前：47 投稿日：02/05/18 03:38 ID:bsKQ5BtD main/1021653459.html#78
- 転送表示は復活してます
- 536 名前：47 投稿日：02/05/18 22:19 ID:L6sJ3iDl main/1021653459.html#430
- β12です。バグ取りだけで機能追加はありません。
あと、自動再試行は不祥事の方が大きそうなんでとってあります。
今回の修正ですが、転送部を見直していたら転送回数が任意回数になることが
あるという致命的な問題が残っていたので、できるだけ１回以下に
なるように修正しました。
実はここの転送率の制御が非常に難しくて、今度は転送がかかりすぎない
可能性もありますが、匿名性確保のためだけにあるので、
まれに起きる程度でもよいだろうと。
今回のは従来の転送部と違って、部分キャッシュが優先される傾向にありますので、
途中まで落ちたキャッシュが転送動作で勝手に補完されて完全キャッシュになっている
という動作が増えるんではないかと思います。
実は複雑すぎてわけわかんなくなったので転送周りを一度全て作り直したりしてたんですが
細かい部分の動作が怪しくてβ８のころに戻ってしまいそうだったので、結局これは廃棄して、
見つかった問題点への対策だけβ11.4に取り入れました。
なお、これのせいでプロトコルが変わってしまったのでβ11との互換性はありません。
- 537 名前：47 投稿日：02/05/18 22:36 ID:L6sJ3iDl main/1021653459.html#440
- よく話の流れがわかんないけど、ダウン速度でＭＸ３．１を超えることはないだろうし、
Freenetの匿名性を超えることもまずないです。
Winnyは両方要望する人向けの特殊なソフトですのでそこんとこよろしく〜。
- 538 名前：47 投稿日：02/05/18 23:02 ID:L6sJ3iDl main/1021653459.html#458
- んー、ちょっと来週の火曜あたりまで他の用事が忙しくて
対応できんのでよろしくです。
- 539 名前：47 投稿日：02/05/18 23:07 ID:L6sJ3iDl main/1021653459.html#460
- ちなみに現状では、ＵＰはブロック単位ですけどＤＯＷＮはファイル単位で
転送時に途中から読むことができないんで、転送時に転送元が前の方だけのキャッシュで、
転送依頼側が後ろ側だけないキャッシュだと切断エラー出ます。
ダウン開始時にネゴして対処するか、ダウンもブロック単位にすればいいんでしょうけど、
対処が面倒なんで後回しになってます。ここはβ１完成直前でレジューム作ってて
問題になったところだし。
- 540 名前：47 投稿日：02/05/18 23:11 ID:L6sJ3iDl main/1021653459.html#464
- まずー、また何かやったか・・・・
来週の準備しないとまずいんだけど。
- 541 名前：47 投稿日：02/05/18 23:46 ID:L6sJ3iDl main/1021653459.html#493
- そーいえば、自動再試行用にダウンロードのタイムアウトが10秒にしてあったの
直すの忘れてた。この辺少し長めにしておきますか。
- 542 名前：47 投稿日：02/05/18 23:50 ID:L6sJ3iDl main/1021653459.html#498
- UP,DOWN共にタイムアウトを30秒にしておきましたので
β12落とし直してください。よろしくです。
- 543 名前：47 投稿日：02/05/18 23:54 ID:L6sJ3iDl main/1021653459.html#501
- そういえば検索リンクのアタック頻度がどんな環境でも１秒に１回に
なってるからのんびり待ってないと繋がらないはずです。
前のだとネットワーク周りの耐久度が悪い環境で吹っ飛んでたみたい
（主にルータだと思われますけどＯＳとかＮＩＣなかもも）なんで
すこしのんびりした動作になってます。よろしく〜。
- 544 名前：47 投稿日：02/05/19 00:33 ID:zzLk5zLZ main/1021653459.html#517
- β12.1です。β12と互換があります。
諸悪の根源はＵＰ側タイムアウトの一つだったようで、落ちるようなので
マターリとしたダウン再試行つけときました。
ボタン場所がなかったので設定ダイアログのところに置いたので使いにくいと思いますが
使いたい人はＯＮにしといてください。デフォではＯＦＦです。
- 545 名前：47 投稿日：02/05/19 19:49 ID:5ot31yKO main/1021653459.html#825
- だるくって仕事がはかどらんでだらだらしとります（ｗ
Winnyのソース丸一日みないのってそういえば４月以来始めてかもしれず。
Port0が問題になっているようですが、これが何をやっているのかというと、
１．Port0設定がONになっていると検索リンクネゴの際にそれを隣のリンクに申請する
２．隣のノードがPort0だと分かっているノードから来たキーは、他のノードに渡す
ときにそのIPを自分のIPに全て書き換える。注意点は、相手に渡すときだけで、
手持ちのキーにはPort0の相手のIPが書かれてます
３．これでPort0へのダウン要求は全て一つ上のノードに転送かかることになります
４．Port0から他ノードへの接続は普通に転送リンクが張られます
あと、基本的にPort0は下流になりますが、Port0ノードがPort0ノードにリンクしたり
することで、Port0の下にPort0が来たりすることもあります。基本的にキーは
上流がわに流れますので、最後はPort0群を脱して正常ノードにキーが流れていきますが
検索結果以外のキーがPort0側に流れることはありません。
Port0周辺の実装はこんな感じです。
もしPort0に転送を担当させようとしたら、どうにかしてport0ノードにパケットを
到達させて逆にコネクションを張ってもらうことになりますがちと問題が多いです。
やり方その１は集中鯖を持つ他のソフトのように検索用のリンクを通して
（というよりブロードキャストに近くなる）逆リンク張らせる方法になりますが、
このパケットがWinnyの場合届くとは限りません。Winnyではブロードキャストや、
特定のノードを目指したメッセージを検索リンクで送ることはできません。
こういう手法は集中鯖が無いと辛いと思います。
もう一つの方法は、Port0から出たキーには、検索リンクで隣接しているノードの
IPが書かれているはずだから、一度ここにコネクションかけて隣のPort0に
逆リンク以来パケットを送ってもらって、一度確立したコネクションを切って、
Port0ノードに代わりに繋げ直してもらう方法ですが、現状のコネクションが
困難な状況から推測するに、ダウン成功率が極端に低下すると思われます。
これだと転送になりませんので匿名性が最悪ですし、これで転送発生させようと
したら、Port0の隣のノードから落とさせた方がいいのではないかと。
Port0の隣のノードの判断で、そちらが転送リンクいっぱいで重いんで、
その場合port0リンクに転送を自分で行うように依頼するというのが
メカニズム的には賢そうなんでやってもいいですけど、やはり匿名性的に問題がありそうです。
だからといってそのままport0を放置というわけにも行かないみたいですので、
適当に何か考えてみます。既に出ているようになんらかの制限を加えるのが
いちばん簡単ですけど、できればあまりやりたくないですねぇ。
当分バージョン上げないから何か良い案でも考えてください。
- 546 名前：47 投稿日：02/05/19 20:00 ID:5ot31yKO main/1021653459.html#829
- ああ、そういえば上に書いた方法を取るとPort0の人だけ
転送時に直接コネクション張ってくるのがばれるんでIPばればれになるわけですが、
現状でもPort0設定の方には匿名性で穴があります。
前も書きましたが、Port0の方は基本的に転送動作しないので
そこから送られてきたキーは基本的にキャッシュかＵＰファイルですが、
隣のノードは相手がport0かどうか知っているので、そのPort0ノードが
持っているファイルがばれやすいです（絶対ではないですが）。
もちろんこれをやるにはプログラムクラックしないとだめですけど、
検索リンクの上流側でキーをよく監視してるとまずいかも。
Port0でもキャッシュが働くのでPort0設定でもＭＸよりは匿名性高いですが、
転送かからないと匿名性的には大差ないので、Port0でないと
使えない人はそもそもWinnyを使うメリット（匿名性とパフォーマンスの両立）
が薄いかもしれません。MXでも使った方がいいかも。
- 547 名前：47 投稿日：02/05/19 20:02 ID:5ot31yKO main/1021653459.html#831
- UPファイルからの直接Upは、かなり重い動作であるハッシュ生成が
常に入るんでＣＰＵ負担が凄いです。匿名性の点からも全部キャッシュに
してしまったほうがいいですね。
- 548 名前：47 投稿日：02/05/20 18:27 ID:fMqRI4yC main/1021824221.html#217
- 忙しいんでソース書き換えてる暇は無いけど考えるだけ考えてみた例のPort0対策ですが
１．Port0の人を排除する
２．Port0の人に制限を加える
３．何らかの優先度を設ける
４．どうにかしてPort0の人も直接ＵＰ可能にする
とあって、１も非常に美味しい対策なんですが（プログラム作るほうからすると一番楽）、
Port0の人も好きでPort0やってるわけでもないでしょうし、３の優先度を設けるという手法は
優先度でよりよくできるぐらいならやってるわけで、実際は優先度が低い人に
制限を加えることで実現されるわけで２と同じだったりします。
これらはPort0の人がいなくなるだけでしょう。
ということで、最善なのは４で技術的にどうにかすればいいわけで、
Port0の人も転送に荷担可能にすれば問題解決なわけです。
問題はこれをどうやるのかですが、前にも指摘があった検索リンクの逆送は
他のノードの負担とか新たなバグ発生がいやだし、何よりも作るのが面倒（笑
なんで、今のWinnyと相性が良いと思われる方法は
１．今と同じでPort0のキーは一つ上流ノードでIP書き換えて必ず転送になるようにする
２．Port0から転送を肩代わりしたノードは、転送要求でUP回線が空いていれば今と同じ転送動作
３．もしUP回線が空いてなかったらPort0ノードにダウン依頼先を示してここに転送リンクを繋げと指令
４．Port0ノードがPort0ノードがダウン依頼のあったノードか、その一つ上に接続
５．あとは通常と同じファイル転送（ただし転送リンクの上下が逆）
これかと思います。失敗が多くなる気もしますが、やっていること的には
通常の転送と大差ないんで動作するでしょうし、作るのも一日あればどうにかなりそうです
（バグも少なくてすみそう）
これの最大の問題点は匿名性の低下（本体持ってると思われるところからコネクションが来る）
ですが、どちらにせよPort0は初めから匿名性弱いんでこれやってもやらんでもおんなじかと。
Port0の最大のペナルティは、もしプログラムクラックされて対策プログラムできたら
真っ先にタイーホになる可能性が高いということになります。
他のノードはクラックされてもＵＰファイルを特定されません。
とりあえず暇を見つけて実装しますので少しお待ちください。
皆さんには、これでどういうことになるか予想していただけると助かります。
- 549 名前：47 投稿日：02/05/20 18:31 ID:fMqRI4yC main/1021824221.html#220
- 補足すると、始めの転送をPort0の一つ上流のノードが必ず
受け付けるとそこのノードが不利なので、
UP回線が空いていても、適当な確率でＵＰをPort0に押し付ける
という動作になるでしょう。
この転送可能だけど確率動作で転送しないというのは今でも入っている動作ですので、
これに準じることにします。実際には直接やり取りしていることが多いけど、
転送もそれなりの確率で発生となります。基本的に転送は匿名性維持のためにあるんで
発生する可能性さえあればいいわけですし。
- 550 名前：47 投稿日：02/05/20 18:35 ID:fMqRI4yC main/1021824221.html#222
- たーだ、これでもport0が他ノードに直接UP可能になるだけで、
port0が転送動作することはほぼ無いんですよね。
いやがらせ的にPort0にUPを可能な限り押し付けてPort0の人が嫌になるようにする
という制限程度はあったほうがいいかもしれません。
- 551 名前：47 投稿日：02/05/20 18:46 ID:fMqRI4yC main/1021824221.html#225
- >>224
Port0設定を無くして完全自動設定にするのはありですね。
自動にできるのならそれにこしたことはないです。
- 552 名前：47 投稿日：02/05/20 18:47 ID:fMqRI4yC main/1021824221.html#226
- まぁ、自動にしてもポート設定変えて外部からアクセス不可能にしてしまえば
同じなんで、Port0の人の方にできるだけUPを押し付けるようには調節します。
- 553 名前：47 投稿日：02/05/20 19:39 ID:pGxbaUun main/1021824221.html#242
- うー、簡単そうだからPort0にUP依頼試してみようかと思ったけど
Port0からPort0にダウンが行ったときの動作で頭痛くなってきたなぁ。
A ← B
C ← D
BとDがPort0でAとCが上流のPort0でないノードで、もしDからBに依頼が行った場合、
今ならA経由でB→A→Dと行くわけですが、前に書いたのやろうとしたら
ＤがＡに接続してＡがＢにＣ接続を依頼してＢがＣに接続してＣがＤから検索リンク経由で
転送になるけど、ＤがＡにＣのアドレスを教えることができてもＢから接続を受けたＣが
これをＤからのダウンとして解釈するのが面倒
ってよく考えたらＤがＡに接続しにいったときにPort0か申告させてＢもＤもport0
だと分かったら今と同じことすればいいだけか。書いてたら解決しました（ｗ
- 554 名前：47 投稿日：02/05/20 19:48 ID:pGxbaUun main/1021824221.html#244
- A ← B
C ← D
えーと、今の案だとＢがport0でＤがそうでない場合、
ＤがＢのファイルを落とそうとしたら、
１．ＤがＡに接続
２．Ａが下流方向の検索リンクを経由してＢにＤ接続を依頼
３．ＢがＤに接続
４．ＢがＤにＵＰ
で、ＢもＤもport0の場合、
１．ＤがＡに接続
２．ＡがＢもＤどちらもPort0と判定
３．検索リンク越しにＤにファイルＵＰ要求
４．ＡがＢからダウンしたファイルをＤに並列ＵＰ
となります。後者は今のPort0からのUPと同じ動作ですね。
- 555 名前：47 投稿日：02/05/20 19:50 ID:pGxbaUun main/1021824221.html#245
- 後半間違った
１．ＤがＡに接続
２．ＡがＢもＤどちらもPort0と判定
３．検索リンク越しにＡがＢにファイルＵＰ要求
４．ＡがＢからダウンしたファイルをＤに並列ＵＰ
こうですね。
- 556 名前：47 投稿日：02/05/20 20:05 ID:pGxbaUun main/1021824221.html#251
- ちなみに全部がPort0で転送がかかる場合（Ａが転送）は、
A ← B
C ← D
１．Ｂ→Ａ→Ｃ→Ｄとキーが渡る間にＢが出したキーのＩＰがＡに書き換わる
２．ＤがＢのキーを要求してそこに書いてあるＡに接続
３．Ａが自分のところのＢキーに書いてあるノードＢに接続してこれをダウン
４．ＡがＢからダウンしたファイルをＤに並列ＵＰ
となるので、複雑さはport0にUPさせた場合と同じです。
今の転送が動いているのであればPort0からのUPも同じ確率で動くでしょう。
>>248
なしです。たすきがけ動作（D→A→B→C→D）が必要かと思ったけど
そこまでやる必要はないでしょうと。BのファイルはＤにキャッシュされるわけだし
Port0はもともと匿名性が弱い（現状でもAにはBとCのやり取りがばれてる）んで
転送動作しても無意味っぽい。自動的にPort0にUP負荷が偏るのでちょうどよさげだし。
- 557 名前：47 投稿日：02/05/20 20:06 ID:pGxbaUun main/1021824221.html#252
- また間違った。上のは全部がPort0じゃない
の場合です。
- 558 名前：47 投稿日：02/05/20 20:24 ID:pGxbaUun main/1021824221.html#259
- キャッシュ消しちゃう人はどうしようもないなぁ
これはPort0に限った話ではないですけど・・・
とりあえず現状でもDown中のファイルをUp可能なので
キャッシュ０のDOMでもいないよりはいいですけど、
DOWN負荷かかるのと合わせて±0。
- 559 名前：47 投稿日：02/05/20 20:44 ID:pGxbaUun main/1021824221.html#273
- キャッシュ消去対策は基本的に当初の予定通り、参照数による優先度算出でしょう。
これはport0への対策と違い、あったほうが「面白い」というメリットが
あったりするので、無いよりあったほうが良くて、
結果、自発的なUP神やキャッシュ放置な人を生み出すだろうと。
どのファイルが人気あるのかとか知れると面白いだろうし、
何か評価値あがると面白いですよね。
実はその値をWinny内部でぜんぜん使ってなくても効果があったりするはずです（ｗ
- 560 名前：47 投稿日：02/05/20 20:54 ID:pGxbaUun main/1021824221.html#280
- 優先度は、参照されるほうになるキャッシュ参照のメカニズムは既に入っているわけで
これを参照する方の実装時となるでしょう。
んで、これが具体的に何かというとＱの機能でしょうか。
ＭＸと違って特定のノードに待ち入れるわけでなく、
MX3.1の自動機能のように放っておくと落とすというタイプになるはず
（メカニズム的にこれ以外無理）なんでこれの時に優先度として使うはずです。
Port0対策が終われば次これでしょう。
- 561 名前：47 投稿日：02/05/20 20:57 ID:pGxbaUun main/1021824221.html#284
- 現バージョンでトンでもなく重くなるとしたらメモリ不足だけかと
- 562 名前：47 投稿日：02/05/20 21:03 ID:pGxbaUun main/1021824221.html#291
- んー、正直９８系は使わない方が・・・
OSのサービス使わないプログラムならいいけど
こんだけネットワークに負荷かけるプログラムだとちと勘弁。
- 563 名前：47 投稿日：02/05/21 01:33 ID:1bcvcj89 main/1021824221.html#464
- うー、何気に疲れ気味
優先度ですけど、前に書いたようにこれは後ろ向きな考え方なんで、
可能な限り入れないようにはしようかと思ってます。
そもそも優先度を入れるということは、優先度の低い人を犠牲にするということですので、
何からの限界がある場合に使うわけです。
ファイル共有ソフトならＵＰ帯域は有限でＤＯＷＮ側の需要にこれが
追いつかないと待ちが発生してＱが生じるわけです。
ですが、一度Ｑが生じるという閾値を超えれば直ぐに飽和する
（待ち行列理論なんかでわかりますが）わけで、理想を言えばＵＰ帯域を十分
確保できればいいだけだったりします。ＵＰ帯域が十分なら落とし放題なんで
Ｑ待ちの必要がそもそもありません。
しかし、皆さんボランティアや強制でやっているわけでもないので、何らかの見返りがないと
回線を開けっ放しにはしません。そもそも他人の足場にされて回線開放で逮捕などは
論外ですので、匿名性の確保は最低限。あとは、そのソフトを起動しっぱなしにさせることが
できればいいわけですが、Winnyでは勝手にキャッシュに溜まるというのを理由にして
UP回線を開放させたままにさせるわけです。
ファイル共有ソフトは基本的にダウン者がファイル選んで落とすわけですが、
これさえも面倒なので普通は放っておいてたまに何か探りたいという
究極の面倒くさがりな人がいるわけで、これを支援する形で回線借りるわけですね。
で、このソフトではキャッシュが効きますので、UP帯域さえ保証できればある程度の
DOWN要求に耐えられることになります。
ですので、変な制限を加えるのは最後の手ということで、できるだけ
UP帯域を保証できるように起動させておくのがそれなりに面白いもの
にするというのが重要でしょう。
心理的には、乱数要素を含むと博打っぽくなるわけで面白さが増すわけで、
実は今現在の転送で何が落ちてくるのかわからないけとそれが見えるというのは
面白いと思いますので、このまま隠さなくて見せたままのほうがいいかと思いません。
あと、単に楽しむためというだけの目的でノードの評価値を出すといいかもしれません。
これを実際に使うかどうかはともかく何か評価値が出ていると、ゲーム的な要素があって
面白いんではないかと。
ＭＸが流行ったのは単に実用的だからというより、あの駆け引きが面白くて
やっている人も多かったんではないかと思います。そんなノリですね。
偽造する人が出てくるほど格差をつけるとまずいですが、評価値が高いと
機能が増えるとかそんなもんでもいいんじゃないかと思います。
もちろん、目立つ問題点に対応できていることが前提ですけど。
- 564 名前：47 投稿日：02/05/21 01:35 ID:1bcvcj89 main/1021824221.html#469
- > 面白いと思いますので、このまま隠さなくて見せたままのほうがいいかと思いません。
いいかと思いますですね。はい。
- 565 名前：47 投稿日：02/05/21 01:42 ID:1bcvcj89 main/1021824221.html#476
- port0に技術的に対応できなければPort0に何らかの制限を加えることになりますけど、
理想を言えばport0で問題が出るのは技術力不足なんで、がんばってPort0でも
他のノードと同じことができるようにすればいいだけだったりします。
とりあえずまだ作ってる最中なんでこれ以上は無理だとなるまで変な制限は
入れるべきではないでしょう。地道に問題点に対応していくしかないと思います。
- 566 名前：47 投稿日：02/05/22 00:53 ID:YEW1rOFm main/1021824221.html#875
- β13です
・ ポート０でも他ノードへＵＰ可能とした（転送も可能）
・ ポート０でも検索ノードの上流になれるようにした
・ 単位表示でkbとなっているところはkBにした
・ キーがロックされたままで同じハッシュのキーが二つできることがあるのを修正
・ 放っておくと検索リンクが繋がらなくなるのを修正
・ 受可なのにダウン不可能扱いされているキーがあるのを修正
例のPort0対策やってみました。UPも転送も問題ないはずですし、
検索リンクの上流にPort0があっても問題ないです。
これで特にPort0だからといってできないことは無くなりましたので、
Port0問題は解決のはずですが、Port0を止められるのに不精で
そのままの人が増えると無駄なコネクションが増えるので、
一応port0の人には少しだけペナルティ入れときました。
「Port0だと転送発生確率が倍になります」
この辺は何かないとまずいのでご了承を。
あと、できればPort0判定を自動化したかったところですが、
今回の改造はそれなりに大きいものであまり書き換えると
何が悪いのか判断が難しくなりそうだったので後回しにしてあります。
- 567 名前：47 投稿日：02/05/22 00:54 ID:YEW1rOFm main/1021824221.html#877
- ああ、あとプロトコルはβ12と別です。
- 568 名前：47 投稿日：02/05/22 01:04 ID:YEW1rOFm main/1021824221.html#892
- ああ、そういえば今回の改造で、Port0でも匿名性低下しないようになりました。
- 569 名前：47 投稿日：02/05/22 01:08 ID:YEW1rOFm main/1021824221.html#894
- Port0周りの実際の実装ですが、前書いた通りです。
Port0の場合、キーを上流に流れていく間にそのキーが書き換わりますので、
Port0のキーにコネクションかけると一つ上のノードに繋がります。
ここでPort0の方には他のノードに再接続要求がいって、
接続してきたほうには、再接続を待つように指示が行きます。
あとは上流下流が逆になるだけでいつもと同じです。
もしどちらもPort0の場合、前と同じでキーを流した方のPort0の
一つ上のノードが転送を担当することになります。
- 570 名前：47 投稿日：02/05/22 02:12 ID:DRD84j/E main/1021824221.html#953
- んー？ちゃんと動いてますでしょうか？
確率が逆になるとのことで今見直してみたらやっぱり二倍ですが、
そもそも転送かかるにはまず、子供が二人いないとまず発生しないという条件があって、
Port0の下に他ノードが二つぶら下がることが無いからじゃないかと思います。
Port0はコネクション受けられない（そもそも他ノードにその存在を教えない）んで
自分から繋ぐだけですが、相手の方が遅かったらPort0が検索リンクで上になります。
この条件でしかPort0の下にぶら下がらない（つまり上に割り込まれるだけ）なんで、
結果的に転送かからないんじゃないかと思います。可能な限り転送するようにするか
多少手間でも隣から転送を押し付けるようにしないとだめかもしれません。
- 571 名前：47 投稿日：02/05/22 02:18 ID:DRD84j/E main/1021824221.html#960
- >>955
それはβ１からの病気で理由はよく把握してます。
検索で見つけた直後にダウンかけないと別のものを落とす確率が上がっていきます。
これはハッシュでなくて内部のキーＩＤで落としているからで、
キーの書き換えが激しいと別のものになってしまっているということです。
ファイル名じゃなくてハッシュでも落とせるようにすればついでに解決できる
問題ですので少しお待ちください。他と比べて致命的でないとの判断で放ってあります。
- 572 名前：47 投稿日：02/05/22 02:20 ID:DRD84j/E main/1021824221.html#961
- そもそも、表示専用のキーバッファ作ればいいだけなんだけどね。
こっち先にやるかなぁ。でも時間が立つと転送側もキーをロストしていくから
キーロストが検索かけないでも分かる今の方式の方がむかつかないかもしれず。
- 573 名前：47 投稿日：02/05/23 02:44 ID:amc0y8e/ main/1022002403.html#289
- β13.1です
かなり機能追加されてますので、バグもかなりあるのではないかと思いますので
そこのところよろしくです。様子見して今回は放置しないほうが安全でしょう。
今回、自動ダウン機能がつきました。実験的な要素も強いので
問題があるようだと消しますが、自動再試行とは違い、検索＆ダウンしないでも
自動でキーワードにかかったキーにダウンをかけます。
これは検索クエリはまったく出さないで、下流から上がってきた転送キーだけ見て
動作しますので、上流ノードで使わないと意味がないです。
ファイル名に特定の文字列が含まれていたらダウン動作を起動するだけですので、
特定のファイルを落としたければ、それと特定できる文字列を入れて放置してください。
あまりヒットする単語で落とそうとしても、一度ダウンにいったファイルは次後回しに
なりますので、先頭だけのキャッシュが増えるだけです。
再試行と違い、試行回数制限は無いし、自動的にキーのＩＰが書き換わっても対応して
別のノードから落としに行きますので、欲しいファイルを書いて放置しておけば自動的に
いつかは落とせるはずです。
ちなみに、一つの登録でダウンするのは一つのみですので、同じ条件で
一度に複数落としたければ、同じ条件のリストを複数登録してください。
自動的にダブらないでおとしにいきます。ただ、それなりに大きな機能追加で
バグがあると思いますので様子見ながら使ってください。
ちなみに、プロトコルは変えてませんので、β13と一緒に使えます。
あとの変更点は以下
・ 自動ダウンロード機能追加
・ キャッシュ非表示ボタン追加
・ 自動再試行をダイアログ内からボタンに変更
・ 自動検索切断ボタンをノードモードに移動
・ 割り算の０割りチェック見直し
・ どこにも完全キャッシュを持っていない部分キャッシュや仮想キーが一瞬見えることがあるのを修正
- 574 名前：47 投稿日：02/05/23 03:16 ID:amc0y8e/ main/1022002403.html#303
- ファイル名フルで入れるぐらいが正解です
既に書きましたがあまりヒットするようだと
糞キャッシュが大量にできるだけです。
これはＱ機能の代わりです。
WinnyではそもそもＵＰ可能でなければ
キーを流さないので、ＵＰ側のＱという機能はありえません。
ですので自動ダウンしようとするとこのような機能になります。
ついでに自動でキャッシュを増やす機能にもなるし、上流に来やすくなるはずだし、
放置する人が増えて良いルールになるはずということで早めに実装してみました。
- 575 名前：47 投稿日：02/05/23 03:20 ID:amc0y8e/ main/1022002403.html#307
- タスクスキップは今実行してるタスクキャンセルさせて
次の選択をダウンさせる機能です。
タスクでのキャンセルと同じでどれか選んで実行しますが、
タスクの方と違い予約は消えませんので直ぐに他のダウンが
始まって結果スキップ動作になります。
大きなファイルダウンしにいって後回しにしたいときなどに使ってください。
- 576 名前：47 投稿日：02/05/23 03:26 ID:amc0y8e/ main/1022002403.html#317
- 部分キャッシュでもダウン可能なら自動ダウンの対象になります。
破損していても、全部読み終わって一度変換かかって、
完全キャッシュになっていなければまた落としに行きますので、
放っておくだけで完全になるはずです。
ちなみにWinnyでは、一部分が見つからないという他の分割方式に
あるような現象は起きないように設計されています。
ネット上でだれか一人でも完全キャッシュ（or UPファイル）を持っていれば、
その情報がめぐりめぐって受可キャッシュになります。
完全キャッシュを持っているのが一人だけで、この人が回線切ってしまうと
そのファイルを完全にすることはできなくなりますが、この場合、
キー寿命を書き換えられなくなって数分内に全部部分キャッシュになります
ので落とせなくなります。これにより、ダウンかけられるのであれば、
しつこくダウンかけていればいつかは全部落とせることが保証されています。
- 577 名前：47 投稿日：02/05/23 17:39 ID:5I+2IuL7 main/1022002403.html#471
- β13.2です。
特に新機能はないです。
β13.1は急いで作ったもんでやはりバグが多かったのでいくつか直しました。
特に、タスクバッファが膨れていくのは致命的だったんで、主にこれ対策です。
タスクオブジェクトは内部に処理用バッファ抱えていて一つだけで数Kあったんで
自動ダウンでタスクが放置されていくと非常にメモリ消費してましたけど、
タスクオブジェクト自身の無駄を省いて小さくしましたし、
自動ダウンで生成されたダウンタスクは終了すると自動的に一定時間で消えるようにしましたので、
これならメモリをそれほど消費しないと思います。
まだ細かいバグは残っていると思いますが、あとは帰ってからやります。
・ 自動ダウンで生じたタスクは削除タイマで消すようにした
・ タスクオブジェクトで無駄にメモリを消費していたのを修正
・ マニュアルでのファイルダウン時に失敗することがあるバグを修正
・ キャッシュ非表示時に完全キャッシュのみ見えなくなるようにした
・ UP,キャッシュ表示のON/OFFを逆にした
- 578 名前：47 投稿日：02/05/23 18:01 ID:5I+2IuL7 main/1022002403.html#475
- もうクラスタ化しないとまずいんですかねぇ(^^;
確かに自動ダウンまで入ったのならクラスタ化したほうが
検索やキャッシュ周りなど各所効率は良いんですけど
６月までそんなに暇ないから大改造難しいような気も。
キーのトラフィックが凄ければ、単にキーの上昇率を抑えれば
いいだけなんですが、これをやると今度はキーの検索ヒット率が下がります。
ただ、今現在キーの流通量が増えているのは検索リンクの接続がゆっくりになったのと、
速度判定の遊びを増やした（同じ程度の回線速度ならわざと遅めでも上流として接続させて
ループさせて階層ではなく網構造になる）のがきいていて比較的全ノードが
切れないでつながっているせいかとも思いますので、それならば、
各ノードのもつキー数を減らしても検索率はそれほど落ちません
ただし、パケットが遠くまで行って帰ってくるので検索時間は長くなりますし、
自動ダウンは手持ちのキーしか見てないんで自動ダウンで目的のものが
かかる率が下がりますね。この辺もクラスタ化で改善されるはずですけど。
とりあえずこの辺は様子見て調節していきます。
どうしようもなくなってきたら明示的なクラスタ化入れましょう。
- 579 名前：47 投稿日：02/05/24 00:31 ID:x4K5TCRp main/1022002403.html#542
- β13.3です。
機能追加はありません。主に高速化とパラメータ調節です。
高速化は、調べてみるとかなり時間を消費していた自動ダウン周りやキーの生成部で、
その代わりWaitを少し減らしておきましたのでCPU消費率はあまり変わりません。
ただし対応が素早くなりますので、13.3間なら多少はファイル転送が早くなるんではないかと。
といっても、UP側はやはり重い（ここはハッシュ生成が重いんでどうしようもない）ので、
最上流ノードはやはり辛いのではないかと。
パラメータ調節のほうは、ダウンロードのタイムアウト30→60秒や
キーの寿命が2.5倍&上昇頻度が2.5分の１です。これで検索率の低下を引き起こさずに
キーの転送トラフィックが落ちるはずですが、ノードダウン時にその情報が広まるのに
時間がかかりますので、ダウン率が多少低下するかもしれません。
ダウンのタイムアウト時間との兼ね合いで実際のところは動かしてみないとわかりませんが。
- 580 名前：47 投稿日：02/05/24 00:34 ID:x4K5TCRp main/1022002403.html#546
- そういえば、前のバージョンと混ぜて使っても平気ですが、
キー寿命が長くなっているんで、あまりバージョンが混ざったままだと
キーの上昇率がそのまま＆寿命延長で上流が溢れるかもしれません。
早めに変えといてください。
- 581 名前：47 投稿日：02/05/24 00:48 ID:x4K5TCRp main/1022002403.html#556
- そういえば自動再試行消してもいいかな？
- 582 名前：47 投稿日：02/05/24 00:51 ID:x4K5TCRp main/1022002403.html#559
- 組み合わせて使えないようにしとけばいいのかな？
- 583 名前：47 投稿日：02/05/24 01:23 ID:x4K5TCRp main/1022002403.html#575
- そういえば自動ダウンってほとんど下流の人から落とすことになるから
急ぎで落としたいものあるのなら手動で検索したほうがいいと思われまする。
- 584 名前：47 投稿日：02/05/24 01:37 ID:x4K5TCRp main/1022002403.html#580
- 当分は上流の人はほったらかしで自分のキャッシュに好みのものをマターリ蓄えていって、
下流の人は必死に検索かけて上流から拾ってくるということになると思いますが、
結局どちらもキャッシュを広める効果になります。
大きなものはまだまだで、たまたま珍しいものを持っている人が接続にくるとその人の所に
ダウン依頼が集中という状況だとは思いますが、もう少し経って大きなものでも
キャッシングされてくれば何でも落とし放題になる可能性もあります。
そうなれば今度はネットワーク側より、キャッシュが溢れて困るという状況になるはずで、
Winnyネットワークも別フェーズになります。
- 585 名前：47 投稿日：02/05/24 01:41 ID:x4K5TCRp main/1022002403.html#582
- 当分は、放置するときは飛ばない程度に申告上げておいて
何か探すときは申告下げてという使い方になりますな。
- 586 名前：47 投稿日：02/05/25 01:55 ID:nxBNME4e main/1022002403.html#789
- β13.4です。主にバグ取りで機能追加はありません。
・ キーバッファサイズを固定するなどして高速化
・ 低速ノードや忙しいノードに転送リンク接続時、
ネゴが間に合わずに無条件で切られてしまうことが多かったのを修正
・ 検索リンク切断タイミングによっては、そのノードのキーの消去処理時に
落ちてしまうことがあったのを修正
重要なのが二番目でして、どうも最近ダウン率が悪いと思って
Waitテスト（LANでWANテスト風にするために各所にWait入れる動作チェック）
していたら、転送リンクのネゴ中にタイムアウト無視して強制切断しているところを
見つけました。負荷がかかってくるとこれのせいで転送リンクが切れていた
はずなので、これでダウン率がかなり良くなるんじゃないかと思います。
ただし、両方がβ13.4使わないとだめですけど。
あと、一応β13系と互換性があります。
- 587 名前：47 投稿日：02/05/25 02:05 ID:nxBNME4e main/1022002403.html#793
- >>792
無くても平気かと思ってスレッド排他処理一箇所外したのがまずかったかもしれない。
戻したので、すいませんがβ13.4読み直してもらえますか？
- 588 名前：47 投稿日：02/05/25 19:37 ID:nxBNME4e main/1022321547.html#24
- β14です。
・ 自動ダウンの開始数＝転送リンクＵＰ数に制限
・ キーの参照数情報を他ノードにも送信
・ キャッシュの参照数トータル情報を表示（表示だけ）
・ CPU負荷低減
実験的な要素が大きいですが、デメリットよりメリットの方が大きいだろうとの
判断で、自動ダウンの機能に制限入れました。UPされてないと自動ダウンが開始しません。
自動ダウンは確かに便利だと思いますが、無条件で起動されると下流側への
負担が大きいですし、この機能は無くても問題はないので、報酬として利用すると
良いのではないかとの判断です。
自動ダウンにより特化させるのであれば、基本的に下流からのみくる転送キー
だけでなく、自動的に上流にクエリ投げて検索キーを拾ってくれば良いのですが、
自動ダウンで指定されているキーでのクエリを全部投げなくてはいかず、
検索側が間違いなく溢れます。今の自動ダウンなら、まったく検索クエリ出さずに
たまたまキー転送中に見つけたキーにダウンかけますので、検索のトータルの
負荷は下がります。
今回入れた自動ダウンの制限も、通常の検索は問題なく行えますし、
UPフォルダのファイルは人気があれば連続で吸い出されていきますので、
結果的に自動ダウンが自由に使えるということで報酬ということにしておきます。
単純にＤＯＭってキャッシュ消している人にはこの機能が使えなくなります。
あと、β１４はこの辺の調節しようということで、参照数のトータルが見えるように
なっていたり、他ノードの参照値を他ノードが知れるようになっています。
まだ見れるだけでこれらをどう使うかは様子見しながらですので、
何かよさげなアイデアあったら教えてください。
- 589 名前：47 投稿日：02/05/25 19:38 ID:nxBNME4e main/1022321547.html#25
- そうそう、参照値転送絡みでプロトコル変わったんで互換性ないです。
- 590 名前：47 投稿日：02/05/25 19:42 ID:nxBNME4e main/1022321547.html#29
- 現状では、プログラム任せで自動ダウンというのは参加者へのモチベーション下がるので、
もう少しゲーム的な要素上げて面白くする方向性で行ったほうが良いと思ってたりします。
β14系でこの辺を探れるといいんですけど・・・・
- 591 名前：47 投稿日：02/05/25 19:47 ID:nxBNME4e main/1022321547.html#31
- 正直、忙しくってこっちやってる余裕があまりないです。
６月までこんな感じだと思う。
夜中にこれの開発やって昼間どうでもいい仕事やって後はぬぼーと寝てて(w
残った頭使う仕事を土日にまとめて片付けてる気が(^^;
- 592 名前：47 投稿日：02/05/25 20:03 ID:nxBNME4e main/1022321547.html#38
- ポートチェック関連はβ１２のころからほとんど変わっていませんので、
ネットワークが込みだしたとか忙しいノードが増えたなどの他の要因が
大きいはずです。この辺は調べるのに手間がかかるのですいませんが
後回しになっています。ＷＡＮではなく、閉じた環境で試さないと
理由がわからないかもしれません。
正直、開発だけなら簡単なんですが、現状で一番困っているのがテストでして、
報告されてもこちらでは再現性がなくどうしようもないのが多くて困っているのが現状です。
ただ単に落ちたとか動かないだとか遅くなったといわれてもこちらの
モチベーションが下がるだけですので、すいませんが、これこれ
こうすると確実にこうなるという報告していただけると助かります。
- 593 名前：47 投稿日：02/05/25 23:46 ID:gdQWAYc7 main/1022321547.html#117
- とりあえずプロトコル変えても致命的な問題が生じなかったようですので、
今夜は放置します。どーも疲れてるんで(^^;変にいじるとバグを増やしそうだし
久しぶりに他の板でもごろごろして時間を無駄にしよう。
ところで現状で一番の問題点はなんでしょう？
できるだけ致命的な問題点からつぶしておかないと
後の作業（細かいバグ取りとか機能追加）が無駄になるんで、
基本機能の法を集中的にやってるんですけど、
現状では新規ファイルがあまり出てこないことなんかでしょうか？
この辺も今回の変更で少しはましになるんじゃないかと思いますが、
優先度とか入れ始まると今度は偽造対策を考えないとならんので頭痛し。
参加者全員が満足というのはどうやっても無理なんで、ある程度バランス取れていれば
いいと思うんですけど、どこがバランス悪いですかね。
- 594 名前：47 投稿日：02/05/26 00:06 ID:JlnOJIKZ main/1022321547.html#131
- リフレッシュは押さないってことで(^^;
原因は後で見直します。
- 595 名前：47 投稿日：02/05/26 00:09 ID:JlnOJIKZ main/1022321547.html#133
- あと帯域制限は申告落とせば同じだと思いますがだめですか？
上流だとどうやっても回線とＣＰＵ消費しますので諦めてください。
- 596 名前：47 投稿日：02/05/26 00:17 ID:JlnOJIKZ main/1022321547.html#143
- 匿名性無視していいんならすごーく楽ですけどねぇ。
通信中の負荷のほとんどは暗号化なんでこれ止めちゃえば
劇的に早くなるし転送しないでいいんならもっとさくさくやり取りできるし。
とりあえず、帯域制限の要望が多いようなのでこの辺考えと来ましょう。
コメントアウトされてるだけで既に実装はできてるんですけど、
ちゃんと制限するのが難しいんで放置してあるし。
- 597 名前：47 投稿日：02/05/26 00:23 ID:JlnOJIKZ main/1022321547.html#147
- 人気の無いファイルはどちらにせよ交換が一番で
システムがどうあれレアなものはこれ以外では無理だと思いますが、
交換だとどうしても１対１になって匿名性維持が非常に困難です。
ただ、前にも書いたように暗号化を工夫すれば匿名性維持した状態で
交換も可能だと思いますし、実装案も考えてはいてWinnyに乗せるのは
それほど難しくないと思うので、あまり期待せずにお待ちください。
当分はメジャーなものが匿名性維持したまま
確実に落とせるところまでいければいいと思ってます。
- 598 名前：47 投稿日：02/05/26 09:48 ID:IGHTVYA2 main/1022321547.html#298
- β14.1です。
帯域制限が動作するようになりました。帯域幅は基本的にUP=DOWNです。
ただ、UP側とDOWN側で処理が違うので、必ず帯域が設定以下になるわけではないです。
まず、UP側は検索リンクも制限かかりますが、DOWN側は転送リンクだけ制限かかります。
UP側はsend時に送信パケットの長さを調節して制限していますが、
DOWN側はファイル転送要求のタイミングを引き伸ばすことによる間接的な制限です。
ですので、DOWN側の制限は相手もβ14.1にならないとだめです。
一応プロトコル的にはβ14と互換がありますが、いかにもトラぶりそうですので、
問題あったらβ14に戻してください。副作用でβ14.1の方がダウンが安定している
可能性が高そうですが（β14.1の方がやり取りがマターリしている）
なお、帯域制限以外に新機能や変更ありませんので、UP制限がなくて困っていたかただけどうぞ。
速度設定が200を超えるとほとんど帯域制限の意味がなくなるはずです。
さーて、寝るか・・・また徹夜しちまったし。
- 599 名前：47 投稿日：02/05/26 20:32 ID:p6HLAMlu main/1022321547.html#382
- β14.2です。単にバグ取りです。
・ノードバッファの大きさを固定（上で出ている不祥事が防げるんではないかと）
・キーのロックミス修正（リフレッシュで変な挙動したり
他のダウンでダウンロードがキャンセルされたりするのを修正）
時間が無いし、あまり慌てて他のバグ作っても問題なんですが、
（つーか、これから明日締め切りの仕事を徹夜であげないとならんのですが(^^;）
後者のバグがかなり致命的だったので早めに公開します。
例のダウン中にリフレッシュするとエラー出るということで？？？だったんですが、
ロック状況を表示させて確認してみたら、キーのロッキングに抜けがあったためでした。
キーのロックというのは、ダウン作業などキーを消されるとまずい場合に
これをロックして削除などできないようにしているところなんですが、
キーの上書き生成部分でこのロック確認が抜けていたので、
隣からダウン中のキーと同じキーをまた受け取ると
上書きしてロックが外れてしまうという凡ミスでした。
ダウン中に他のダウンではじかれてしまうなどもこれのせいだと思います。
他にもいろんな不祥事を起こしていたはず。
なお、プロトコルはβ１４共通です。
- 600 名前：47 投稿日：02/05/26 21:25 ID:p6HLAMlu main/1022321547.html#399
- キー処理が重いのは無駄にキーがメモリ消費しているのが大きな理由な
はずなのでカリカリとチューニングしていけばいいだけなんですけど、
時間がなくて作業がすすんでないです。
メモリ上で小さければ各種のキャッシュヒット率が上がって処理も軽くなるはずです。
今だと一つのキーで2K程度のメモリ消費してしまっています。
これの主な理由は暗号化（名前やキャッシュ内など）のせいなんで、
これの暗号化をキーと切り離して同じ暗号キー単位でまとめればいいはずなんで、
暇になったらやってみます。少しお待ちください。
- 601 名前：47 投稿日：02/05/28 00:20 ID:CxlqbARE main/1022321547.html#625
- β14.3です。ほとんど高速化作業です。
・ キーバッファをvectorでなくmultimap化して検索やキー追加操作を高速化
・ キーの指示を全てハッシュで行うようにして違うものがダウンされないようにした
・ 帯域制限を外せるようにした
・ 自動ダウンの負荷を低減
・ 表示の際の無駄な検索を省略することで、ＣＰＵ負荷を低減
・ 参照数で表示をソートすると参照ブロック数でソートになっていたのを修正
今回で大きな変更は１番目のもので、キーの管理方式が根本的に変わりました。
いままで可変長配列で管理していましたが、キーが増えてくるとキー追加と
検索にかなりの時間を取られてきていたようですので、map使うようにしました。
あと重いのが検索が入る自動ダウンと、表示周りだったのでここを高速化しました。
キーが増えてもかなり動作が軽いと思いますが、かなり書き換わっているので
違うバグは出そうです。
なお、帯域制限が必要なのは一部の人だろうとの判断で、設定のところで
外せるようになってます。14.2で問題になったメモリーリーク周りは、
キーの管理方式が変わったのでどうなるかは長時間動作させてみないと分かりません。
以前の方式より今回のものの方がメモリを消費しないとは思うのですが。
- 602 名前：47 投稿日：02/05/28 01:14 ID:CxlqbARE main/1022321547.html#644
- 書き忘れましたがプロトコル互換です。
あと、ソケットのクローズ数が合わないと思ったら表示の方間違えていたので
修正しておきました。表示だけなんで特に変わりませんが読み直しといてください。
- 603 名前：47 投稿日：02/05/28 12:58 ID:UedDyqXN main/1022321547.html#707
- 結構な大改造だったのに時間が足りなくてテスト不足だったのが効いているようで。
とりあえず明日までは忙しくて修正している余裕がないですので、すいませんが
飛ぶ方はβ14.1あたりまで落して使ってください。よろしくです。
- 604 名前：47 投稿日：02/05/28 18:57 ID:UedDyqXN main/1022321547.html#729
- β14.3は負荷が下がる分、動作が怪しくなるのは間違いなかったんですが、
β14.2以前と比較して明らかにこちらの方が軽いですか？
それほど変わらんのでしたら、単純に配列使う方式に戻せば多くの
不祥事が直ると思うんですけど。
- 605 名前：47 投稿日：02/05/28 19:35 ID:ABwbMz1Z main/1022321547.html#740
- １万超えても耐えられるんなら今の方式で地道に動作安定させていったほうが
あとあとよさげですね。例のファイルの参照数見たら2000超えてるってことは
参加者が楽に１万いってそうなんで（キーの参照値は全体でなく、各キャッシュの最大値）、
そろそろキーの流通量を増やしていかないとロストキーが問題になり始めるはずです。
てなことで、早めに今の方式で動作安定させましょう。少しお待ちください。
とりあえず帰って寝ます（ｗ
- 606 名前：47 投稿日：02/05/29 20:22 ID:eCmG9DCv main/1022321547.html#929
- β14.4です。プロトコル互換です。
・ 自動ダウンにファイルサイズ制限追加
・ 検索リンクと転送リンクを同じノードに接続すると転送リンクが切断されることがあるのを修正
・ 接続にいったリンクを自分で即断してしまうことがあるのを修正
・ キーのブロック状態表示関連で飛ぶことがあるのを修正
・ 帯域制限無し時に１０ブロック毎に転送指示することで転送速度向上
・ 自動ダウンの制限を緩くした（UP無しでもダウンがかかります）
・ 参照数が変なキーやハッシュが0なキーを無視するようにした
・ ホストバッファ溢れに対する処理追加
・ ヒープ領域を明示的に開放するようにした
一応新機能として、自動ダウンでのサイズ指定がありますが、
メインはバグ取りです。例のメモリ周りの修正もありますが、
今回のではダウン周辺を時間かけて再チェックしましたので、
ダウン率が上がるんじゃないかと思います。
ああ、あと自動ダウンがUP=0でもスタートするようになってます。
- 607 名前：47 投稿日：02/05/29 20:43 ID:eCmG9DCv main/1022321547.html#938
- そろそろユーザ数１万超えみたいなんで
（バグかと思ったけどちゃんと数千ヒットのファイルがあるみたい）
例のクラスタ化考えないとまずそうだけど、
その前にいつ正式版になるんだというのはありますね。
- 608 名前：47 投稿日：02/05/29 20:51 ID:eCmG9DCv main/1022321547.html#941
- >>940
致命的でないとみなして次でのんびり直します。よろしく〜。
とりあえずDown側を14.4にするだけでもダウン率上がると思いますが、
これは致命的だろうというバグがあってUP側も少し変わってるんで
みんなで14.4にすると面白いことになるんではないかと。
- 609 名前：47 投稿日：02/05/29 21:32 ID:eCmG9DCv main/1022321547.html#960
- すいません。忙しくてここの報告はろくに見てなくて
自分で思いついたところだけ直してるもんで(^^;
そのうち直します。
- 610 名前：47 投稿日：02/05/29 23:34 ID:InLwR5pp main/1022679290.html#48
- ミ＼ 我が名は.”47” ／彡
へ ⊂⊃へ P2Pに真のマターリを ／ 彡゜+ ．
／ ＼∧＿∧ ） もたらすものなり ／ 彡 *
彡 ( ・∀・) ﾐ＼著作権法に異議あり！ 彡 ：
彡彡 ( つ つ ＼+゜． . ／ 彡 ゜* ． ゜
丿 ) ミ ＼ ゜： ／ 彡 ゜： ： *
＼ ＼ ／* ／ * +
ミ￣￣￣￣￣￣￣￣￣＼ ｜ ｜ ／￣￣￣￣￣￣￣￣￣彡 ゜+
ミ ＼ ⊂⊃ ／ 彡
￣￣￣￣￣￣／￣￣＼ ∧＿∧ ／￣￣＼￣￣￣￣￣￣
゜： . ／ ／￣ （ ・∀・ ）￣＼. ＼ +゜． ⊂⊃
*／ ／ ⊂ 47 ⊃ ＼ ＼ ゜+.へ∧＿∧ ／＼
／ │ ／ ｜ ｜ ｜＼ │ ＼ * ／ (´∀` ） ＼
／ ／│ ミ. （_＿|＿_）彡 │＼. ＼゜彡／⊂ ⊂ ） ＼ ミ
彡 ／゜*│ ミ 彡 │ ＼ ミ 彡 ：+ ( ( ミミ
彡／． │ ミ ゜+. 彡 │ +゜ ＼ ミ +゜．
゜+. ＼ ミ 彡 ／ * ゜： ：
＼ミ ゜* 彡／ ゜+ ゜+ * *
ｱﾘｶﾞﾀﾔ ｵｵ、47ｻﾏ ｲﾏｺｿ ﾏﾀｰﾘｦ ｳｻﾝ ｸｾｰﾖ･･･
∧＿∧ ∧＿∧ ∧＿∧ ∧＿∧ ∧＿∧ ∧＿∧ +
（ ゜∀゜）（ ゜∀゜）（ ゜∀゜） （゜∀゜ ）（゜∀゜ ）（・∀・ ；） ゜+ ゜．
（つ つ（つ つ（つ つ ⊂ ⊂ ）⊂ ⊂. ）⊂ ⊂ ） *
（￣__）__）（￣__）__）（￣__）__） （__（__￣）（__（__￣）（__（__￣）
- 611 名前：47氏への質問はここでいいの？ 投稿日：02/05/30 03:32 ID:FWMOP3Pm main/1022679290.html#80
- 47氏へ書き残し
同一プロトコルにおけるクライアントバージョンの差（β13.1、13.2等）
でPort0にしないと警告が出るという症状が以前から報告されている
のはご存じかとは思います。
当環境においてもβ13.2以降（β13系のみ）とβ14.4においてPort0に
しないと警告を受けます。β14〜β14.2では問題ないです。
通信周りでどの様な変更があったのか、またそのような原因となる
箇所に心当たりはありますか？
DNS欄にグロバ入れておけば問題ないLAN環境にしているはず
なんですが・・・
- 612 名前：47 投稿日：02/05/30 11:06 ID:2lHRW6So main/1022679290.html#90
- 昨日は久しぶりに良く寝れたです。
とりあえずまだ落ちる人いるみたいですしバグは数え切れないほどあるので
致命的なものから順に直していくしかないですが、大きな変更やるたびに
致命的なバグがでるんで、基本機能が出来上がってからでないと
細かなバグ取りは無駄です。
本質的（設計面よりでの）問題点を先につぶしたいところです。
現状であと問題になりそうなところは何でしょうか？
100M超えるような大きなファイルの扱いとかですかね？
それか、早めにクラスタ化の作業を開始しますか？
今だったら自動ダウンに登録された単語を利用することで、
ある程度効率的にいけそうな気もしてるんですが。
基本的に前にシミュの画面で出したような、検索リンクに上下以外に左右を加えることで
縦方向は今と同じ形態で横方向に大きく広がった、ただし下には同系統のノードのみがぶら下がる
ネットワークになると思いますが、前に出したような単純なリング状としてのトポリジだけではなく、
自動ダウンの単語を利用することで、綺麗にクラスタ化できるんじゃないかと。
既に自動ダウンで狙ったものだけ落せるようになってきているとは思いますが、
人が増えてきて遠くのノードのファイル（何度もリンクを上下に追っていかないと
たどりつかないノードにのみあるファイル）はダウンできないはずで、
検索リンクで偶然近くに繋がるのを待つしかないのが現状のはずです。
自動ダウンも下流にターゲットのファイルを持つ人が現れないと起動されません。
ですが、この機構を入れることで似た傾向の人が集まってきてノード的に近傍に
来ることになりますので、転送で同系統のファイルが転送されやすくなって、
キャッシュの無駄が減るはずですし、自分が登録している系統のファイルに限れば
見つからないファイルが極端に減って落しやすくなるはずです。
基本的に検索リンク部とクエリ部の多少の変更ですむので、
動くようにするだけだったら２週間もかからんはずですが・・・
- 613 名前：47 投稿日：02/05/30 17:05 ID:zxtBTvVf main/1022679290.html#151
- Winnyのキャッシュは64K単位でハッシュついてますので、
一バイトでも違っているとそこのブロックだけ破損扱いされます。
暇な方は自分でキャッシュを壊してみて実験してください。
ただし、破損検出だけで修正はしません。
あと、キャッシュヘッダにはサイズ情報も含まれていますので
サイズ違いの途中のファイルというのもありえません。
キャッシュ変換で完了と出れば、オリジナルと全バイト同じはずです。
- 614 名前：47 投稿日：02/05/30 17:10 ID:zxtBTvVf main/1022679290.html#152
- そういえば
> ただし、破損検出だけで修正はしません。
これは冗長な情報もたせてエラー検出だけでエラー修正はしないという意味ですので
もちろん他のキャッシュから読みに行けば修正はできます。ただ、他のノードの
キャッシュも壊れていたりするとやはり破損が検出されますね。
今ですとＵＰ時とキャッシュをダウンフォルダに展開するときしか
ハッシュチェックに行きませんが、転送で落とし終わったときも
チェックだけかけた方がいいかもしれません。
と、いかんと。
- 615 名前：47 投稿日：02/05/30 23:25 ID:pujGfO1u main/1022679290.html#189
- β14.5です。互換ありです。
・ 操作系としてポップアップメニュー追加
・ ダウン中のキャッシュや部分キャッシュでも変換可能にした
・ 部分キャッシュ表示の切り替え機能追加
・ 一回のレジュームで一つの連続ブロックしか直せなかったのを修正
・ 同じキーに対する分割ダウンを同じノードに複数かけられなくした
・ 接続停止状態で再起動して接続開始した場合にポートを開いてなかったのを修正
・ ダウンリスト追加すると自動的に自動ダウンＯＮになるようにした
・ キャッシュサイズ算出で小さいファイルばかりだと算出が変なのを修正
・ キーの寿命を少しだけ短縮
・ 表示が残る処理済タスクを50個に制限
主に大きなファイル対策ですがI/F周りで細かい修正が多数。
とりあえずレジューム関連の問題点や、ムービーなどでありうる
途中まででも展開できる機能など付いてます。
まだつぶしてないバグがたくさんありますけど、あまり機能追加
するとわけわからんバグが出そうなのでこんなことろで一度公開しときます。
つーか眠い。
- 616 名前：47 投稿日：02/05/30 23:34 ID:pujGfO1u main/1022679290.html#194
- レジューム周りは、帯域制限やら複数ダウン、自動ダウンやらでダウン部を
変更しているうちに入り込んだバグみたいです。前のバージョンなら問題なかったはず。
あとまだリフレッシュ周りだとかあと帯域制限も変だという話あったと思いますが
見直しとらんのでよろしく〜。
- 617 名前：47 投稿日：02/05/31 00:04 ID:5OMFYoBd main/1022679290.html#202
- >>198
14.5だと、ダウン中のファイルでも今ダウンしているノード以外に
キャッシュ持っているノードが無いと受可キャッシュになりません。
逆にいえばダウン中で黄色くなっていれば、他のノードから
分割ダウンできるということで、既に部分キャッシュからでも重複して読めるので、
機能的にはMX3.1相当のはずです。手動ですが・・・
あと別館見たらハッシュで盛り上がっているようですが、この辺は非常に
面倒なことになってます。皆さんの予想通り、検索に使っているのは
とりあえず高速に求める必要があって先頭ブロックだけから算出してますが、
64Kブロックで全部ハッシュ持ってますし、キャッシュ先頭のブロック
（いろんな管理情報が入っていてここには他のハッシュ情報も入ってる）
これ自身のハッシュもあります。そうでないと管理部分の破損が検出できませんし。
もっと面倒なのが、これに加えて暗号化がかかることで、
実は今回の変更で送信時もキャッシュのハッシュチェックしようかと思いましたが、
これのせいで断念しました。困ったことに元の暗号がわからないとハッシュチェックも
できなかったりします(^^;良く考えたらキャッシュ先頭だけ、処理順番変えればよかった
だけですが（もちろん先頭ブロックも暗号化されてます）、今からこれやると
今までのキャッシュと互換がなくなってしまいます。
とりあえずレジュームが少しはまともになったはずなんで、我慢しとってください。
- 618 名前：47 投稿日：02/05/31 00:09 ID:5OMFYoBd main/1022679290.html#204
- あと、部分キャッシュの強制変換は右メニューからしか
できなくなってます。これやると生成されるファイルが壊れてますんで
今までダウンフォルダには完全ファイルしかないというルールから外れます。
ダブルクリックで起動できると間違えて破損ファイルがダウンフォルダにできて、
これはキャッシュと違ってシステム側で補完できないので、
分かっている人だけが使う機能ということで。あと一応、部分キャッシュ
だけ見れるようになってます。ファイル種類でソートかけられるので、
この辺と組み合わせて使ってください。
- 619 名前：47 投稿日：02/05/31 00:11 ID:5OMFYoBd main/1022679290.html#208
- >>203
実は暗号化されていても他からのクエリでヒットすると暗号キーが判明してしまいます。
一度再起動すると消えるので復号不可能になりますが
（もちろんキャッシュには暗号キーは含まれてません）
とりあえずまずいんでそのうちクリアするようにはします。
- 620 名前：47 投稿日：02/05/31 00:15 ID:5OMFYoBd main/1022679290.html#211
- >>207
UPファイルを誰も持ってない状況でキャッシュだけになって
それがみんな破損していると言う状況だとどうやっても修復不可能です。
前のバージョンではレジューム接続部でほぼ確実に破損していたので
壊れているキャッシュが多いんだと思います。今のですと破損しにくい
はずなので時間が立てば自然に消えていくと思いますが、
強制的に対処するとしたらキャッシュのプロトコル変えないとダメですね。
キャッシュにもバージョンあるんで今のキャッシュを捨てないでも
対処できますが、ちとめんどうかもしれず。
- 621 名前：47 投稿日：02/05/31 00:19 ID:5OMFYoBd main/1022679290.html#214
- ああ、あと見かけ上完全だけど変換すると部分キャッシュに化けることが良くあるはずです。
キャッシュヘッダにはどこのブロックが壊れているかという情報が入っていますが、
これが実際に整合しているかどうかは、ファイル全部を見に行かないとだめで、
数百Ｍのファイルだとこの整合性チェックだけで分単位の処理かかります。
だから、ファイルの同一性チェックにはとりあえずファイル先頭とサイズだけ使って、
全体の整合性チェックは変換作業時のみになってます。
変換作業開始することで、初めてブロックハッシュと実際のブロック内容で矛盾が見つかって
完全キャッシュのはずが部分キャッシュになるわけです。
- 622 名前：47 投稿日：02/05/31 00:27 ID:5OMFYoBd main/1022679290.html#223
- 部分キャッシュ（受可キャッシュでも可）を検索で見つけ出して右メニューで変換すると
タスクで変換始まって失敗しますが、ダウンフォルダに変換できただけ残ってます。
ダウン中のファイルならタスク画面の方からでも右メニューの強制変換で
同じことになります。
・・・とりあえず寝ます
- 623 名前：47 投稿日：02/05/31 00:29 ID:5OMFYoBd main/1022679290.html#226
- 今やってみたら部分キャッシュだとだめかもしれず。
ダブルクリックで変換できなくしたときに巻き添え食らったらしいですが、
簡単なんで直しますか。少しお待ちを。
- 624 名前：47 投稿日：02/05/31 00:34 ID:5OMFYoBd main/1022679290.html#231
- 部分キャッシュだと変換始まらなかったんで、直しました。
すいませんが14.5の読み込み直しお願いします。
- 625 名前：47 投稿日：02/05/31 10:30 ID:jmzhw2Nz main/1022679290.html#259
- β14.6です。互換があります。
・自動ダウンでヒットキーがあるのに何も落とせなくなることがあったのを修正
・タブ幅変更処理が変だったのを修正
・手動検索での1ノード内ヒット数限界を倍（200）にした
小変更ですが、検索リンクがプチプチ切れていると自動ダウンがハングする
ことがあるというそれなりに致命的な問題点があったのでバージョン上げときます。
あと、最近は自動ダウンのおかげで検索負荷が下がっているので、
検索でヒットできる数を上げときました。そもそも検索結果は２００しか
表示しないのであまりヒットする単語での検索は無意味なのですが、
たくさん溜め込んでいるノードがあると見えない可能性もあるので変更しておきました。
自動ダウンのヒット率はゆっくり全部のキーを上流に流して別のメカニズム
なので変わらないと思います。
- 626 名前：47 投稿日：02/05/31 14:31 ID:SkFMp1gY main/1022679290.html#323
- 破損対策は暇見てやります。そんなに難しい問題ではないですので。
あと、掲示板は今はやる気がまったくありません。今の２ｃｈでいいと思ってますし、
これ以上の使い心地はP2Pでは実現できないと思います。
MXとFreenetの違いと同じかと。
もちろん、匿名性の点で2chが怪しくなってきたり負荷に耐えられなくなったら考えるかも
しれませんが、既に他にこれでやっている方がいるわけですので、そちらに期待ということで。
一応、今のWinnyに外部I/F付けて掲示板も使えるようにする（FreenetのFrostのように）
というのはありでしょうが、なんとなくですがシステムやプロトコル一部共用と言うより、
ファイル交換とBBSは完全に別システムにしたほうが効率がいい、
というか、これやっても今の2chレベルが実現できるか怪しいと思います。
それよりも先にもう少し大規模になっても耐えられるようにするのが
Winny的にはテーマでしょうね。
- 627 名前：47 投稿日：02/05/31 14:48 ID:SkFMp1gY main/1022679290.html#328
- んー、個人的には人のソース見てよりよくするほうが１から組むより
スキル要るんでソース公開して意味があるぐらいならその人がもっと
いいもの組んでくれと思っちゃいますけどね（ｗ
- 628 名前：47 投稿日：02/06/01 21:05 ID:5A6UCmRW main/1022679290.html#503
- 昨日今日と雑用が多くて作業が進行しとらんです。
つーか、職場でこれ作ってるのばれたし（ｗ
また仕事が一つ増えたし、ちょっと余裕ないですねぇ。
気長にお待ちを。
- 629 名前：47 投稿日：02/06/02 10:06 ID:NGw7VwGX main/1022679290.html#564
- 他のノードに渡すノード情報はネゴに成功したものだけなので、
変なアドレス書いてあっても攻撃するのはその登録した人だけでDoSアタックにはなりません。
- 630 名前：47 投稿日：02/06/02 21:14 ID:+QT9WZz3 main/1022679290.html#637
- β14.7です。互換があります。
・ 転送完了時にもキャッシュ整合性チェックを行うようにした
・ キャッシュ送信時にもキャッシュ整合性チェックを行うようにした
・ 分割ダウン時に同じ個所のブロック要求を出しやすいのを修正
・ 分割ダウン時にダウンするノード選択を誤ることがあるのを修正
・ クエリの結果でキーの暗号キーが判明していても表示しないように変更
・ 自動ダウン時の不正なキーのチェック強化
・ タブ幅処理を修正
・ 再試行時にタスク表示が消えることがあるのを修正
・ 自動分割ダウン機能追加
今回のは主に大きなファイルの扱い周りですが、ちと議論になりそうな機能追加もあります。
まず、基本的にキャッシュの破損がそのまま広まることが無くなるようにしました。
転送終了時にも展開動作（チェックだけ）しますし、キャッシュのアップ時にもブロック送信時に
ハッシュチェック入るので基本的に壊れたデータが送られてくることはありません。
ただ、キャッシュフォーマット変えてなくて、検索で拾ってきた暗号キーで試し解凍してるんで、
状況によってはチェック無しで送られてくる可能性があります。この場合、今までと同じ動作です。
どちらにせよ展開時にチェック入りますから三重にハッシュチェックかかります。
その他、分割ダウン周りの動作が怪しくなっていたのでまた直しましたが、
今回重要なのは最後の機能でして、暫定ですが分割ダウンを支援する機能がついてます。
使い方はダウン時に右クリックで分割支持か、タスクで既にダウンしているものに
追加で右メニューから自動分割指示です。
何をするかというと、その現在落としているキーが他ノードからも重複して落とせるのであれば、
自動的にダウンロードタスクを発行します。キャッシュの検索で黄色くなったら自動的に
ダブルクリックすると思ってください。ＭＸで言えば、自動的に投網する機能に相当します。
ちゃんとチェック入れて同じノードに投げないようになってるんでそんなに迷惑でも
ないはずですが、一応何かUPしてないと使えないようになってます。
複数のノードでキーがヒットしないとだめなんで、キャッシュが何処にでも転がっているような
メジャーで大きなファイルにのみ有効な機能です。
Winnyのメカニズム把握して無いとうまく使うのが難しいと思いますが、
仕掛けてから一度その目的のファイルにヒットしそうな検索を
たまに手動で書けるといいんではないかと。
この辺りは自動ダウンと同じですね。
- 631 名前：47 投稿日：02/06/02 22:10 ID:+QT9WZz3 main/1022679290.html#656
- んー、転送切れるということなんで変更点見直してみましたけど、
ひょっとして小さなファイルだと切れるかという変更点見つけたので
戻してみました。基本的に大きなファイルばかり試してたし。
すいませんが、β14.7読み直しといてください。
- 632 名前：47 投稿日：02/06/02 22:17 ID:+QT9WZz3 main/1022679290.html#659
- あと、昔からβ参加されている方ですと逝かれキャッシュを持っている可能性
高いですが、今回のバージョンではその逝かれキャッシュをUPに行った
時点で破損が見つかって完全キャッシュから破損キャッシュになります。
これにより各所でＵＰが止まるという現象がでるんじゃないかと思います。
少し待てば見かけ上完全な破損キャッシュは消せるはずですが・・・
- 633 名前：47 投稿日：02/06/02 22:42 ID:+QT9WZz3 main/1022679290.html#663
- 回線詐称していなければ高速回線の間に低速がくることはないはずですが、
まだ基本的な部分を上げている段階なので各調節は後回しになっています。
特に低速側は最後になるでしょう。中速→高速→低速の順で出来上がっていくと
思います。今はそろそろ高速側で使う機能（今回の分割ＤＬや自動ダウンなど）
が出来上がりつつあるところではないかと。
- 634 名前：47 投稿日：02/06/04 18:17 ID:gfm0Tbz8 main/1022679290.html#810
- ここんとこ忙しい（締め切り有りなのが２、さっき一つ終わった、
んで、締め切りがあいまいなのが３つ、うち一つは超巨大プロジェクト）
なんで流れを追いかけきれてませんが、
今のバージョンで変なデータが流れるとしたら先頭64K以外が別物になっている
サイズ同一ファイルをUPフォルダに上げている人がいるのではないかと思います。
破損エラー出ても破損ブロック部が0で埋まるだけでDownフォルダにファイルはできる
（ただしキャッシュの方は破損ファイルになるんで強制変換でないと変換不能になる）んで、
これをUPフォルダに持っていくと変な完全キャッシュ
（UPフォルダ内は問答無用で完全キャッシュ扱いされる）になるのではないかと。
単にキャッシュに入ったままなら破損修復されるはずですが、強制変換あたりで
無理やり変換してUPフォルダに置かれると今の方式ではお手上げです。
全体ハッシュを求めないとこれを弾けませんが外部から見てUPファイルとキャッシュを
同じに見せる都合上、ハッシュを前もって求めておくしか手がなく、これは処理が重いし
そこんとこの偽造対策が面倒だったんで、先頭ハッシュに加えてサイズ情報を含める
という対処療法で逃げてたりするわけです(^^;
とりあえず、前のバージョンで破損が広まってしまったのが大きな
理由で今のバージョンで時間がたてば目立たなくなってくるはずですが、
絶対破損しないほうがいいわけで、暇を見て直しましょう。
なお、キャッシュヘッダにもバージョン持たせてあるんで、新バージョンのキャッシュ
プロトコルになったらユーザさんからも見て旧キャッシュと分かるようになると思います。
- 635 名前：47 投稿日：02/06/05 14:12 ID:HQt9CR2R main/1022679290.html#899
- 向こう本スレと間違えた(^^;;
とりあえず質問スレの方に書いてしまいましたが、
今現在キャッシュブロックの先頭にかかれているブロック毎のハッシュ値（MD5ハッシュ）
をキャッシュヘッダに含めて、全体ハッシュをこの全ブロックハッシュのハッシュとして
求めてこのハッシュのハッシュ値を検索ハッシュとして用いようかと思ってます。
今使っているブロック先頭のブロックハッシュはキャッシュヘッダでのブロックハッシュと重複
するので無駄といえば無駄ですが、実装変えるの面倒ですし、二重にブロックハッシュ
を持っていたほうが信頼性が高いのでブロックハッシュはヘッダとブロック先頭の
二重になる予定です。
基本的にキャッシュヘッダのハッシュの方優先で、これと違ったブロックは破棄になるでしょう。
もちろん、今と同じでキャッシュヘッダそれ自身にもハッシュチェックかけるんで、
キャッシュヘッダの破損も検出して、破損ヘッダキャッシュは全体廃棄になります。
今のように後部が壊れてるのに同じハッシュ値になってオリジナルが区別不能という
こと事体は避けられますが、全ブロックハッシュが合うのに全体ハッシュが合わないと
いうことはやはりありえるので、こうなると全部廃棄して
別のファイルを全部読み直しになります。もちろん、オリジナルが壊れてるときもそうです。
この実装で問題が出そうだったら教えてください。
- 636 名前：47 投稿日：02/06/05 14:22 ID:HQt9CR2R main/1022679290.html#902
- あとWinnyではこのキャッシュ周りは暗号化との辛みが面倒でして、
今ですとハッシュ値はオリジナルファイル内容に対するハッシュ値であって、
暗号化してからの内容に対して生成したハッシュ値ではありません。
そして、キャッシュには暗号キーが含まれてませんので、
暗号が解けないとキャッシュチェックそれ自身ができませんでした。
そんな理由で、転送時にはキャッシュのハッシュチェックしてなかったりするわけです。
一つの手は、ハッシュは全部暗号化の後の内容に対するものとして、
暗号キーが変われば同じファイルでも別キーにすればいいわけですが、
何か問題があってこれやめたような記憶があります。何だったかなぁ。
と、この辺はいろいろ面倒だったりします。
- 637 名前：47 投稿日：02/06/05 14:28 ID:HQt9CR2R main/1022679290.html#903
- とりあえず、検索に用いる全体ハッシュはオリジナルに対するもので、
キャッシュ内のブロックキャッシュは暗号化後のもの。
キャッシュヘッダのブロックハッシュは暗号前のもので、
転送時にはキャッシュブロック先頭の暗号化内容のハッシュで破損をはじいて、
最終チェック時に暗号を解きつつ、キャッシュヘッダの暗号化前のハッシュと
比較して破損ブロックは廃棄ってところかなぁ？
UPファイルUP開始直後でこれやるのは無理だけど、
UPファイル処理が前処理なら可能だと思うんですけど。
- 638 名前：47 投稿日：02/06/05 14:42 ID:HQt9CR2R main/1022679290.html#904
- あと、昔のキャッシュを全部破棄というのも作るほうからすると簡単でいいんですけど、
せっかく広まったキャッシュを全部破棄というのももったいないので、
当分は両方扱えるようになると思います。
もちろん、せっかく信頼性高くなるのに旧キャッシュと混ぜてしまうと
意味無いんで、旧キャッシュから新キャッシュの変換というのは行わずに、
β15（予定）からUPしたキャッシュだけが新キャッシュとなるでしょう。
こちらでも破損ファイルがそのまま出回るのは同じですけど、
ハッシュが別になるんで区別はできます。
そして、そのまま正式版では旧キャッシュは破棄でしょうね。
どうも参照値周りのバグで変な値のキャッシュがあるようなんでちょうどよいし。
- 639 名前：47 投稿日：02/06/06 20:33 ID:Fd6qrD3Y main/1023290054.html#107
- うーん、調度この糞忙しい時に・・・
とりあえずまだβで大人数（特にメカニズム考えてない人ばかり）に耐えられるとは
思いませんので、嵐が収まるまで放置という方針でお願いします。
ちょうどキャッシュが変わる予定だし旧システムをキャッシュ含めて全部廃棄しても
良いかもしれません。とりあえず少し様子見ましょう。そんなことでよろしく〜。
ちょっと消えます。
- 640 名前：47 投稿日：02/06/08 17:23 ID:f/iFEC2w main/1023290054.html#375
- 思ったより平気みたいなので、小対策だけしときました。β14.8です。
β14系とプロトコル互換性あります。
とりあえず人が増えてくるとどうしてもマイナーなファイルが見えなくなりますが、
メジャーなファイルだけでいいのなら今のシステムでも問題ないと思います。
・ 人気のあるファイルだとキーの寿命が変で更新が正常でなかったのを修正
・ リフレッシュボタンを一時的に消した
・ キャッシュ→ダウンフォルダへの変換で、破損が見つかったらダウンフォルダから消去
・ 転送先で接続限界ならそれを転送依頼先にもリレーするようにした
・ 既にロストしているキーの転送を依頼されると転送リンクを切り忘れるのを修正
・ 先頭の方しか持っていない部分キーを転送可能キーとして流さないようにした
・ 転送不可能なキーを転送可能として扱うことがあるのを修正
・ ノード情報の保持時間を短くした
・ ダウンの各ステップでウェイト挿入
・ ダウン中のデバッグ表示ON
・ 転送発生率を少し落とした
基本的に初心者向け対策とダウン率向上、あと致命的バグがあったので修正程度で、
新機能追加はありません。例のキャッシュ機構周りの変更は動作が変だと致命的なんで
のんびりやりましょう。
あと、Winnyページの方でTipsにリンク張りました。Tips管理人さんお疲れ様です。
- 641 名前：47 投稿日：02/06/08 18:30 ID:f/iFEC2w main/1023290054.html#386
- 270は超能力者ですかい。
確かに深夜に14.8公開しようかとおもったんですけど
テスト不足が怖かったんでやめたんですが（ｗ
とりあえずUP,DOWNとも14.8になればダウン率がそれなりにあがると思うんで、
早めに取り替えてトラブル報告などあったらお願いします。
- 642 名前：47 投稿日：02/06/08 19:21 ID:f/iFEC2w main/1023290054.html#395
- 不法アクセスを禁止する一番確実な方法はNoderefConst.txtを消すことです。
このファイルに書いてあるノードは相手が変でも消えません。
Tempに残るノード情報や他ノードから来るノード情報はWinnyのネゴに
成功したものだけなので、広まったりしません。
変なアクセスするとしたら他からもらってきたノード情報だけです。
- 643 名前：47 投稿日：02/06/08 19:25 ID:f/iFEC2w main/1023290054.html#397
- というか、その感じですとWinnyを自分で立ち上げて
netstatで相手を見てWinny使用者に手当たり次第に送ってるだけではないですかね？
Winnyを使っているかどうかというのは、もちろんTCPコネクション張ってるわけで
分かります。ですが、その内部でだれが何を流しているかはわからないはずです。
- 644 名前：47 投稿日：02/06/08 19:55 ID:mYqde6NM main/1023290054.html#410
- ノード情報周りって詳しく書いたことないと思うんで書きますが
まず、初期ノード追加で追加するとNoderefConst.txtに追加されます。
起動時には、このNoderefConst.txtとNoderefTemp.txtに書いてあるノード情報で
ノードバッファを初期化します。んで、１秒に１ノード接続に行きます。
この接続動作は、検索リンクがUP側2になるまで行います。2になれば
あとは接続を受けるだけの動作で他のホストに自ノードからは接続に行きません。
で、相手に接続にいくとWinnyのプロトコルでネゴしにいって、ネゴが成功すると
ポート情報や速度情報が得られますので記録しておきます。あまり速度に差が
あると他ノード情報を教えて切断依頼を出します
（これで向こうから切ってくれなかったらタイムアウトで強制切断）
また、他ノードから接続された場合、検索ノードのDOWN側が空いていれば
そのままネゴに入りますし、空いてなければ手持ちのノードバッファ内部のノード情報のうち、
「ネゴが完了して確実にWinnyクライアントと分かっていて、
なおかつPort0でなくてポート警告が出ていないノード」
だけを教えます。
また、プログラム終了時にはこれと同じものをNoderefTemp.txtファイルに書き出して
終了します。そのため、Winnyノードでないホスト情報が含まれているとしたら
NodeRefConst.txtファイルだけとなります。
ある程度使っていればTemp側の情報だけで再接続できるようになると思いますので、
使いこんでいる人はConstファイルは消してしまっていいと思います。
- 645 名前：47 投稿日：02/06/08 20:04 ID:mYqde6NM main/1023290054.html#413
- あと、分かり難いとよく言われるノードという用語ですが、
WinnyではPCのことはホストと呼んでいて（これはIPアドレスで識別される）、
これにポート番号が付いたのがノード情報です。
ノードが何かといわれたら、Winnyサーバントそれ自身になります。
１つのホストには複数のWinnyサーバントが立ち上がっている
可能性があるのでこれをノードと呼んでいるわけです。
host:portの情報がノード情報になります。
Noderefにもこの形で書かれてます。
- 646 名前：47 投稿日：02/06/10 20:10 ID:0eH+vBsi main/1023290054.html#583
- 今現在、検索用のハッシュをファイル全体から求めるようにするのと、
キャッシュヘッダにも全ブロックのハッシュを求めておいて
ブロックの入れ替えを検出できるように変更作業中です。
前の作業は既に終わってますので暇見て後者やりますが、
プログラム全域書き換えという大変更になってますので、
それなりに手間かかってます。少しお待ちください。
- 647 名前：47 投稿日：02/06/11 13:40 ID:eJechUg6 main/1023290054.html#613
- 久しぶりに徹夜でプログラム組んでたんで眠い・・・
とりあえずキャッシュ関連の変更は出来上がって手元では既に動いてるんですが、
まだテストが不十分でバグが怖いのと、今までやってた通信周りと違い、
公開してみんなにテストしてもらわないでもキャッシュ周りは
LAN環境で十分テストできるので、β15はもう少し寝かせときます。
思ったより簡単な変更ですんでまして、検索に使うハッシュ値がファイル全体
（正確には全ブロックハッシュから生成したハッシュ）になるだけです。
キャッシュのフォーマットはほとんど変えなくて済みました。
この全体ハッシュ関連は、作ってる最中に面倒になって途中で妥協して
手抜きしただけ（格納する場所はちゃんとキャッシュヘッダに作ってあった）
なんで、結局全体ハッシュを求めるのが面倒でここだけ後回しにして
問題が発覚するまで放置したことになります（ｗ
（1G近いファイルだとここの処理だけで数分かかるんで、
これを問題にならないように処理するのが面倒で手抜きしてた）
そんなわけで今度のでは、どんなに大きいファイルでもどこか一バイトでも違いがあったら
ハッシュの値が変わって検索時点でファイルの区別がつくことになります。
なお副作用で、UPファイルの参照数がちゃんと保存されるようになってます
（処理的にはUPファイルに対応するキャッシュヘッダを先回りして作っているだけなので）
あと、現状で旧ハッシュは破棄ではなく、バージョン違いという扱いになってます。
当分は同じファイルでVer0.1と0.2キャッシュが混在することになりますが、
ユーザさんの方でできるだけ0.2の方を落すということで。
小さなファイルならVer0.1キャッシュでも問題ないでしょうし。
さて、次何しましょうか？
破損問題はこれで終結するはずですが、キー周りの扱いでしょうか？
正直、クラスタ化早くやりたくて仕方ないんですけど（ｗ
- 648 名前：47 投稿日：02/06/11 15:34 ID:eJechUg6 main/1023290054.html#623
- 普通ならP2Pソフトの肝は検索部のはずなんでしょうけど、
お約束の話が多くてあまり凝りようが無いんで
Winnyではここのところはいい加減なつくりになってます。
もとからキャッシュ重視な設計ですし。
初期の構想では、集中サーバが無くてもWPNP的に働く検索部というのを
狙ってたはずなんですが、結局、副作用的に出来た自動ダウン機能が
目新しいぐらいで、全体としてあまりうまく動いているとは言えないです。
そろそろキー管理部の出来の悪さが一番目立つようになってると思いますので
（ファイルが見つからないとか、キーが直ぐ消えて落したいファイルが落せないとか）、
この辺の補正もかねて横方向検索リンクとクラスタ化の導入検証でもはじめましょう。
それがもたらす影響の大きさの割には変更が比較的少なくてすみそうですし、
うまくいけば根本的な問題点の多くが解消できる可能性高しです。
もちろん、キャッシュ周りの修正とか細かいバグ取りは平行してやりますが・・・
とりあえず前書いたようにクラスタ化んところは自動ダウンの発展というの
考えてますけど、まだ考えてるだけの状態です。まぁ、ぼちぼちと。
- 649 名前：47 投稿日：02/06/11 15:36 ID:eJechUg6 main/1023290054.html#624
- 余裕があったら暗号キーんとこ工夫しての
交換支援（ファイル交換じゃなくて暗号キー交換する）とか、
BBS機能なんかもおもしろいんでしょうけど、こういうのは他で
やってますので、やること無くなったらでしょうね。
- 650 名前：47 投稿日：02/06/11 16:00 ID:CnqwTVeO main/1023290054.html#631
- age
- 651 名前：47 投稿日：02/06/12 09:16 ID:6+QNR4/C main/1023290054.html#666
- クラスタ化に関してですが、非常に簡単な対処法を思いつきました。
クラスタ化の基本的な考え方は、同じ傾向のファイルを持っている人を
検索リンクで近くになるようにノード配置することです。
似た傾向のノード間距離が短くなり分野ごとにノードがクラスタ化されます。
前考えていた実装法では、今の二種類のリンクの他にクラスタ間通信用のリンク入れて
この間でキーやノード情報をやり取りするというものでしたが（例の曼荼羅の図）、
よく考えて見ると、今のノード情報のやり取り機構のところが既に似たようなことをやっている
わけですので、ここを発展させてネゴの時に、クラスタ化情報を一緒に渡してあげて、
この情報で相関の高いノード間を優先して検索リンクで繋げてやれば
それで済むんではないかということに気が付きました
具体的な実装ですが、まず自動ダウンで使っている単語の先頭三つをクラスタ化のための
情報とみなし、接続のネゴ時にこれを交換しておきます。これで、速度などの情報と一緒に
クラスタ化情報が得られますので、自ノードの情報と突き合わせてノード毎に適当に
評価値を決めソートかけて優先度の高いものから順に検索リンク接続に行きます。
もしノード情報を他のノードに教える時（自分の検索リンクが限界だったり速度差がある場合に発生する）
は、依頼ノードと相関性の高いノードだけを手持ちのノードバッファから抜き出して教えます。
これにより、検索リンクで近傍にいるのは自動ダウンの単語傾向が似たノードになりますので、
転送時に興味ない分野のファイルを中継する可能性が非常に少なくなります。
また、保持されているキーも近傍ノードで同一傾向のものがクラスタ化されますので、
目的の物が見つからないということも減るはずです。分野の数も１つではなく、
検索リンクの数だけ発生しますので、重複のある分野でも問題なく扱えます。
MXの方でファイル名に分野ワードをつけるのがマナーとして一般化していて
Winnyで出回っているファイルもこれに準じている場合が多いので、
この情報をクラスタ化の情報として積極的に利用することになります。
もちろん、自動でこれを抜きだすのは難しい処理ですが、
自動ダウン用という名目で、ユーザさんにこれを最適化してもらうと。
もちろん、特に何も設定しないでもどこかのノードに分野ランダムで繋がりますので、
メカニズムが良く分かってない人でも問題なく使えます。設定的にはβ14と同じで、
明示的なクラスタ情報を設定する必要ありません。ただ、自動ダウン使わない人でも、
分野キーワード指定しておいた方が目的のものを見つけやすくなりますね。
と言う設計を思いついたんですが、
キャッシュ変更でプロトコル変わるわけだし作業も簡単なので実際にやってみるかということで、
実際に作ってみたら非常に簡単な作業だったので、実装は既に終わってます。
そんなわけで次のβ15でこの機能もお目見えすると思います。
キャッシュ変更と合わせて大変更なのでのんびりチェック中で公開はまだですが、
既にβ15というか、次バージョンのβ相当ですね。
- 652 名前：47 投稿日：02/06/12 13:44 ID:9kSGewds main/1023290054.html#678
- クラスタ化の種として暗号キーの方を使うというのも考えたんですけど、
そもそも、暗号キーの本来の使い方はプライベートな使い方するのが本来で、
分野分けに使うべきものでないと思ってます。
それにクラスタ化のキーは外部ノードに公開するものになるんで
暗号キーでクラスタ化だとまずい。
（使ってる暗号キー外に公開してたらそれ暗号にならない）
ただ、今の設計だとクラスタ化のための情報が隣接ノードにだだもれなんで、
これ自身になんらかの暗号化いるかなとは思ってますけど。
あと、分類に使う情報に、自動ダウンでの単語を流用するのではなく
独自に設定と言う手もありですが（昔の設計ではこれだった）、
完全に分野分け単語が定着してしまうと今度はノード間の
微妙な違いが消えて逆にクラスタ化できないという問題が出る気がするんで
情報量が多いと思われる自動ダウンの単語がいいんではないかと。
一応完全一致でなくて、＜一部一致で関連があるとみなします＞ので、
比較的うまく相関とれるんじゃないかと予想してます。
まぁ、単に自動ダウンの指定使うというアイデアが「面白かった」んで
一度試してみたいだけで、やっぱりだめそうならまた変えます。
確かに、自動ダウンとは分離して独自設定になるだろうという気はしてるんですけど(^^;
- 653 名前：47 投稿日：02/06/13 11:52 ID:XtW4j17j main/1023290054.html#748
- 早く新Ver出したいんですけど、基幹部を変えた結果いろいろ変わっていて
ついでだからここも変えちゃえということで大変更になっています。
β15での今までの変更リストで大きなものを上げると
・ 検索ハッシュをファイル全体から求めるように変更
・ 検索リンクにおけるクラスタリング機能導入
・ ハッシュ値での自動ダウン指定
・ 自動ダウン時に上流に検索をかけるようにした
・ 従来の自動再試行機能を削除して自動ダウンと統合
・ 従来の自動分割ダウン機能を削除して自動ダウンと統合
・ ノード情報でのソーティング機能
こうなってます。特に初めの設計時になかった自動ダウンというのが扱いが
大きくなってきたので、ダウン周りは全て自動ダウン中心に作り直しました。
上流だけでなく下流も既に自動ダウン使用前提ですね。
たとえば、検索でダブルクリックすると無条件で自動ダウンの方に登録されるように
変更されてます。画面もダブルクリックするとタスクの方でなくて自動ダウンの方に移ります。
あと、暫定でついていた補助機能である自動再施行であるとか、
分割ダウンなども全て自動ダウンの方に統合されています。
クラスタ化のところも前に書いたように自動ダウンと連動しているわけですが手持ちのキーと、
ノードから知らされたクラスタ化情報（自動ダウンの一部）との相関も取るようにしました。
これでどうなるかというと、UP側が自分の手持ちにDOWN側の望みのファイルがあることを検知すると
普通の考えと逆に、対象ファイルを持っているUP側がDOWN側につなぎに行くという動作が発生します。
DOWN側は自動ダウンかけてまっているわけですので、そこにファイル持っている
ノードが自分から接続にいくので、直ぐにダウンかかることになります。
クラスタ化の副作用ですが、これはこれで面白いんではないかと。
んで、今はまだキャッシュの変更が一部残っていてこちらの作業中です。
あと確実じゃないんですが、いまだとキャッシュファイルのファイル名を暗号化名から
生成していて、ハッシュ値無視してますが、現在ここをハッシュだけから
生成に変えようと思ってます。こうでないと同じ内容の別キャッシュができたりして
無駄になりますし、こうすればファイル名制限が今の126から制限無し
（OS側の制限と同じ254文字）にできるはずです。今と違い、キャッシュのファイル名は
キャッシュヘッダ内部に移ることになります。
ただ、これは実際にこうなるかまだわかりません。何か問題があってβ１で
こうしたはずなんでやってみて見落としがあったらやめます。
と、現状はこんな感じです。
現状、周りに忙しい忙しい言いつづけた結果デッドロックして、他の用事が忙しいんだろうと
思われて用事が回ってこないで実は暇と言う状態なので(w、
気合入れて実装上げます。少しお待ちください。
- 654 名前：47 投稿日：02/06/13 12:04 ID:XtW4j17j main/1023290054.html#751
- 話題になっている通信負荷に関しては、Winny自身の処理負荷がすごくて
捌ききれてない部分も大きいと思います。特に今はUP側の処理負荷がすごいです。
Winnyでは、相反する部分（ダウン能力と匿名性）をプログラムネイティブで書いて
力技でどうにか解決という傾向が大きいんで、手抜きして妥協すると直ぐに
どこかパフォーマンス面で問題が出ます。
もともと、暗号やハッシュのところの処理負荷が大きいんですが、
最近ですと自動ダウンが非常に重い機能で、今やってる
クラスタ化（ここでは全ノードの自動ダウン単語を先回りしてヒットするか
調べる必要と、全ノード間の相関取る必要があってそれなりに重い処理）
のところも重いはずなんで、どうしてもパフォーマンス調節は後回しに
なりがちです。
この辺は少しまってください。当初のテーマだったダウン率の問題点は
どうにか我慢できるところまできたかなと思ってますので、ダウン速度や
全体のパフォーマンス調節はこれからの作業になります。
- 655 名前：47 投稿日：02/06/13 14:05 ID:SfLh0/Ln main/1023290054.html#759
- age
- 656 名前：47 投稿日：02/06/14 19:35 ID:z+P+H+Yh main/1023290054.html#809
- お待たせしましたβ15です。もちろん互換性ありません。
できるだけポート変えた方がいいと思いますし、
今回はiniファイルも消したほうが良いのではないかと。
あと、一応旧キャッシュとの互換も取れていますが、
キャッシュを全部消して設定で旧キャッシュを無視するようにしたほうが
いいかもしれません。
・ 検索ハッシュをファイル全体から求めるように変更
・ キャッシュのファイル名を元のファイル名からではなくハッシュ値依存に変更
（ファイル名がキャッシュ内に格納されるのでファイル名長の制限が無くなった）
・ 自動ダウンワードを用いたクラスタリング機能導入
・ ハッシュ値での自動ダウン指定可能にした
・ 自動ダウン時に上流に検索をかけるようにした
・ 従来の自動再試行機能を削除
・ 従来の自動分割ダウン機能を削除して自動ダウンと統合
・ ハッシュをクリップボードへコピーする機能追加
・ ノード情報でのソーティング機能
・ Sleepを少し減らして処理を早くした
・ キー寿命を少し短くした
・ 分割ダウンでダウン終了後に変換タスクが複数起動されるのを修正
・ リストのソート条件を保存するようにした
・ ホストバッファがフルになったときにPort0などの接続不可能ノードを破棄するようにした
・ その他細かい変更多数
事実上のβ2で、根本的なところがかなり書き換わってます。
キャッシュ周りとノード管理周辺とキーの暗号化の部分、あとダウンのところと、
通信系以外全部書き換わっているので、高確率でトラブルと思われます。
特に、ノード周りの変更が危険で、ひょっとするとまったく繋がらないという可能性もありえます。
とりあえず大人数で動かしてみないとどうなるのか分かりませんので、
テストお願いします。
- 657 名前：47 投稿日：02/06/14 20:20 ID:z+P+H+Yh main/1023290054.html#823
- すいません。検索リンクの切断タイマーのところがＬＡＮのテスト用の
ままだったので２０秒程度でぶちぶち切れることが多いはずです。
β15修正しといたので落とし直しといてください。
- 658 名前：47 投稿日：02/06/14 20:23 ID:z+P+H+Yh main/1023290054.html#827
- あと自動ダウンの一部が見えてるのはテスト用で将来的には
見えなくなるはずです。
なお、ダウンリストで＊が付いてるのが他に知らされます。
あとβ15ではファイルダブルクリックすると自動的にハッシュ指定での自動ダウンになるので、
ハッシュ指示されてるのは個別とみなして外部には公開しません（匿名性的に問題だし）
- 659 名前：47 投稿日：02/06/14 21:06 ID:z+P+H+Yh main/1023290054.html#845
- 検索リンク切断頻度が想像以上に凄いんでまた修正しときました。
変更が多くて申し訳ありませんが、またβ15取り替えといてください。
- 660 名前：47 投稿日：02/06/14 21:11 ID:z+P+H+Yh main/1023290054.html#847
- 前に出ていた検索リンク数が凄くなる病気がまた再発しやすいはずですけど、
安定するまで我慢してください。無条件に切るとクラスタ化にならんので、
わざとです。様子見てパラメータ調節します。
あとクラスタ化ですが、手持ちのキー（キャッシュかＵＰに限る）に
できるだけヒットする汎用的な単語指定したほうがいいはずです。
そうでないと検索リンクが切れやすいはず。
ただこれやると無駄なダウンが増えるんで、
暫定的にファイル範囲で調節してください。
- 661 名前：47 投稿日：02/06/14 22:16 ID:z+P+H+Yh main/1023290054.html#871
- 変更点が多いので細かい不祥事は暇見て直しますが、
UPフォルダ周りの動作は次のようになってます。
まず、ハッシュを求めるためにファイル全部を全て一度読み込まないといけないので、
バッググランドで全内容を読みに行きます。同時にハッシュ生成やりますし、
表では通信などやってますので、処理にものすごく時間かかります。
β14までで検索に使うのが先頭ハッシュだけだったのはこれのせいなんで仕方ないです。
もちろん、起動のたびにそんなことやってられないので、UPファイルのハッシュ生成も
キャッシュが効くようになってます。UPと部分キャッシュ表示が両方ONになっていると
検索で見えますが、UPキャッシュというものがあって
内容はキャッシュファイルの先頭部分だけです。
ハッシュ値やファイル名が格納されていますので、次からはこちらを参照します。
全ファイル内容見に行くのはUPフォルダ追加直後だけです。ただし、
もしUPファイルが書き換わったらタイムスタンプみてハッシュの再生成かけます。
- 662 名前：47 投稿日：02/06/14 22:36 ID:z+P+H+Yh main/1023290054.html#876
- あとまだ検証段階であるクラスタ化ですが、今のだと
三単語申告してもらって、ノード間で相関がある（3x3=9通りで重複がある）と
優先度が上がります。あと、その単語で手持ちのキーに検索かけてみて
ヒットするようならやはり優先度上がります。
あとは優先度順でソートして優先度が大きいものから優先的に
検索リンク接続に行きます。ただし、接続すると１ずつ下がっていきます。
始めの構想では、横方向の検索リンク作ってここに情報を流す予定でしたが、
どうせ検索リンクはプチプチ切れるわけだし、それを見越してキーをノードにもたせて、
ノードが新しく検索リンクで繋がることで、キーを交換して媒介させるという考えです。
重要なのは、似た傾向のノードが検索リンク張ることなんでこうなってます。
検索リンクは切れてしまってもIP変わらなければ直接転送リンクは張れるんで、
特に困りません（ただ、低速ノードだとやり取りのまえに切れるんで問題あり。
後で見直します）。そんなこんなで検索リンクは優先度低いとわざと切れるようになってます。
- 663 名前：47 投稿日：02/06/14 22:43 ID:z+P+H+Yh main/1023290054.html#877
- ちなみに、相手の申告した自動ダウン単語は、
手持ちのキャッシュにヒットするので、
望み以外の分野のファイルがキャッシュにあると、
それにつられてノード傾向が異なる人が寄ってきて、
キャッシュがますますそれ傾向になります。
ゴミが多い人は一度消したほうがよいでしょう。
- 664 名前：47 投稿日：02/06/15 09:57 ID:pkXAyM13 main/1023290054.html#930
- β15.1です。β15と互換があります
・ 検索リンク切断で、そのノードのダウン情報がクリアされていたのを修正
・ まだダウンが終わってないのにダウンリストが消えることがあるのを修正
・ 別のものをダウンしているように見えることがあるのを修正
・ ノード優先度で単語間マッチしているのに評価されないことがあるバグを修正
・ キーの暗号化が解けずにそのまま表示されて文字化けすることがあるのを修正
・ ダウン終了時に変換タスクが起動されないことがあるのを修正
・ キー削除時にクラッシュすることがあるのを修正
・ キーロスト切断発生がおき難くした
昨日が徹夜だったのでいつのまにかキーボード抱えて寝てましたが（ｗ
変更量が多いために致命的なバグがたくさんあるのは判っていたわけで
一度寝てから公開すべきでしたね。
まだたくさんバグがあるのは分かってますが、致命的なものが多いので
順次公開していきます。せっかくの新機能がそれのせいでまったく意味なくなってる
バグだらけでした。ＵＰフォルダ周りの不祥事はこれから直します。
こういうP2Pアプリは手元のテストだけでは動作がわからないで、
公開して動かしてみないと判明しないバグがあるんでやっかいです。
とりあえず、バグはまだまだあるとは思いますが、
致命的だと思われるものを優先的に報告お願いします。
- 665 名前：47 投稿日：02/06/15 10:10 ID:pkXAyM13 main/1023290054.html#935
- キーバッファクリアが一秒１つになってた。怖そうなんで直しときました。
すいませんが、既にβ15.1落とした方は落としなおしといてください。
- 666 名前：47 投稿日：02/06/15 10:49 ID:pkXAyM13 main/1023290054.html#937
- >>936
それはβ15ではバグじゃなくて仕様です。
Winnyでは純粋なDOMというのが発生し難い（落としたのを当分はUPしてくれるはず）
なんでDOMそれ自身はそれほど問題でないんですけど、本当の問題はUP対策です。
新作問題ですね。
これに関して今までのように制約加えるのも手ですけど、
この手は根本的な解決にならんと思いますので、
今は優先度に似た別の概念入れようかという計画で案を練ってます。
良くファイル交換は資本主義、ファイル共有は共産主義と例えられますが、
ファイル交換は原始的な資本主義で、より発展した形態として貨幣経済というのがあります。
直接交換するのではなく、何らかの二次資本（貨幣）を導入することで、
物々交換より効率よく流通できるという、お約束の話ですが、優先度と似たような
概念としてWinnyではこれを取り入れられる可能性もあるんではないかと。
キャッシュ＝貨幣になってしまう可能性もありますが、
キャッシュの暗号を個別にしておいて、暗号化キーを貨幣代わりに使えるんじゃないかと
（貢献してる人が暗号化されてるキャッシュを展開できやすくなるとか）
まだ考え中なんで設計が固まってませんがそんなこと考えてますので、
UP対策は少しお待ちください。その前に帯域対策（効率よく回線を使う）
になると思うので、そのあとになるでしょう。それまではDOM優先ですね。
- 667 名前：47 投稿日：02/06/15 10:50 ID:pkXAyM13 main/1023290054.html#938
- ちなみにクラスタ化がうまくいくかどうかですが、
自動ダウンにでるヒット数の率が高くなっていけば成功です。
- 668 名前：47 投稿日：02/06/15 10:59 ID:pkXAyM13 main/1023290054.html#941
- たとえばファイルを資産と考えると、その流通コストが半端じゃないのが問題
（＝出回っているファイルの大きさに対して回線が遅い）ですが、
これ専門の流通業というのを考えてこの人が非常に儲かるということに
なるでしょうね。
つまり、高速回線持ってる人がWinnyでは運送屋さんで暴利をむさぼれるわけです（ｗ
と、こう考えるといろいろアイデアが出るんじゃないかと思うので、
暇な方は何か面白い案考えてみてください。こちらは当分はバグ取りやってます。
- 669 名前：47 投稿日：02/06/15 23:10 ID:piVrnYUC main/1024117422.html#62
- β15.2です。一言で言うとバグ取りで互換ありです。
まだ大量に問題点あると思いますが、こんなところで公開しておきます。
・ 自動ダウン単語での相関チェックを片方向でなくて相互チェックにした
・ タスクを自動的に生成ID順でソート表示するようにした
・ ダウンタスクが無条件で消えるようにした＆手動再試行機能の削除
・ 多重ダウンONだとコネクションが限界超える（接続待ちリンクを無視してた）のを修正
・ キー暗号化部分で高速化のためのキャッシング処理が変だったのを修正
・ タスク表示で文字化けすることがあるのを修正
・ UPフォルダスキャン状況を表示するようにした
・ UPファイルのハッシュチェックを高速化
・ UPフォルダスキャン時に落ちることがあるのを修正
・ UPキャッシュだけでUPファイル本体が無くてもキーを送信してしまうのを修正
・ UPスキャンタスク起動周りの挙動が変だったのを修正
・ 64kブロック整数倍サイズのUPファイルがあるとハッシュタスクがロックしていたのを修正
- 670 名前：47 投稿日：02/06/15 23:16 ID:piVrnYUC main/1024117422.html#65
- ファイルが断片化しているのは、プログラムをシンプルにするためで、
ＯＳ任せにしてしまっても問題ないだろうとの判断なんですが、
あまりシーク動作がひどいようだと全体の動作速度が落ちるんで、
そろそろファイルアクセス周りの最適化作業に入ってもいいかもしれません。
CPU処理の方よりそろそろディスクアクセスが全体のネックになってくるはずですし。
ただ、処理が複雑になるのでバグが出やすくなります。ファイルの閉じ忘れなんかです。
とりあえず暇見て簡単なところからやりましょう。
- 671 名前：47 投稿日：02/06/16 16:02 ID:k6DaC6Ig main/1024117422.html#129
- β15.3です。互換ありです。今回はバグ取りは無しで、実験的な要素が大きいものです。
最近のバージョンだとUPや転送は軽快なんですがダウンが遅めなんで帯域の最適化し直さんと
と思ってたんですが、よくよく考えてみるとやはり諸悪の根源は自動ダウンで、
回線詐称もこれが原因なはず。
ここで、今までの自動ダウンですと、下流からきた申告してきたキーを横取りして
落とすというメカニズム上、上流からキーに自動ダウンかけることがほとんど
なかったわけです。
（つまり、今までの自動ダウンは転送される予定のキーを先回りして落としていたのに近い）
ですが、β15で、ゆっくりですが自動ダウンで上流にクエリが行くようになりましたし、
下流からきたクエリのリターンが上流から下流に帰る時にこのキーを横取りしてやれば
上流のキーも得られるわけで、試しにこれやって、キーを上流優先ダウンさせるとどうなるのか
実験してみようかというのが今回のバージョンです。
今までですと、自動ダウンは下流にかかって、上流でＵＰ動作かかるのは
ほとんど手動検索とそれにより発生する転送動作でしたが、
今回のでは自動ＤＯＷＮは基本的に上流に対してかかりやすく、
ＵＰが下流ノードに対して行われやすくなることになります。
Winnyの概念から言うとこちらが本来の動作なはずですが、自動ダウンが出てきたことで
いつのまにか逆になってしまっていたので、これで自動ダウンが入る前の帯域分布
状態に戻って、ＵＰよりＤＯＷＮ側のほうが帯域幅が多くなりやすいはずです。
上流のほうがリンク確保数も多いのでコネクション限界エラーも出にくくなるはずですし、
上流で回線詐称してると耐えられないはずなんで今より状況がよくなるんではないかと。
なお、設定のところで、下流キーにダウンかけられなくできますし（標準でＯＮ）
これがＯＦＦでも、常に下流より上流側に優先的にダウンがかかります。
とりあえず転送動作の発生確率なども変わると思うんですが、
どうなるかは実際にやってみないとわからないんで、実験よろしくです。
β15.2とβ15.3ではこれしかかわらないのでどちらが調子良いか試してください。
- 672 名前：47 投稿日：02/06/16 18:00 ID:k6DaC6Ig main/1024117422.html#151
- β15.2のままでも他が15.3にしたら結局上流は重くなりますし、
上流でもβ15.3にすれば同じ回線速度の人から落とす確率が高くなるので
上流でもβ15.3の方が良いと思います。それに上流で回線詐称してなくて
帯域制限してなければ光間で全力転送始まって細い人が弾き出されるんじゃないかな？
上流で詐称すると重くなるだけだけど・・・
- 673 名前：47 投稿日：02/06/16 18:25 ID:k6DaC6Ig main/1024117422.html#153
- 起動時に重い人は回線接続ＯＦＦにしておいて
キャッシュチェックやＵＰファイルチェックが終了してから
接続ＯＮにしたほうがいいと思います。
標準でこういう動作にしたほうがいいかも。
回線申告が大きな人とキャッシュを大量に持っている人と
大きなファイルをＵＰしている人が特にそうですね。
- 674 名前：47 投稿日：02/06/16 22:21 ID:Wn3pB5Pk main/1024117422.html#184
- バグ取り放置して小変更ばかりですいませんがβ15.4です。互換ありです。
上流キー重視でダウンかけても上流に回線詐称ばかりなら無意味でダウンが早くなりません。
そもそも詐称の根本的な理由は下流にいると自動ダウンが使い物にならないということです。
ということで、そろそろ下流対策しないと全体に問題が出るということで
自動検索を強化しときました。β15からこの機能は付いてましたが、
あまり検索かけると今度は上流が溢れるんですごいのんびりした動作になってましたが、
今度は、自動ダウンでヒットキーが無いときだけその条件で検索かけるように
しましたので、もしヒット数が多ければキー寿命で消えるまでは検索かかりませんし、
逆に何も検索にかからないような条件であれば検索クエリが小さいので上流へ
それほど負荷がかからないはず、ということでそれほど全体で過負荷にならないのではないかと。
これで下流にいても自動ダウンが使い物になるはずです。
なお、この機能は下流でなくても働くので、全レイヤで検索ヒット率が良くなるはずです。
あとキー流通が増えて溢れそうなんでキーの上昇率を少し工夫してあります。
- 675 名前：47 投稿日：02/06/16 23:30 ID:cv1JyEFJ main/1024117422.html#197
- 同じノードに複数の検索リンク接続が発生するのは仕様です。
ノードが少ないと発生しますので、できるだけノード登録してください。
昔はこれは問答無用に切断していましたが、
遅い回線や、他の忙しい場合に転送リンクが切れるという現象がでるため、
これ対策でわざと同一ノードリンクの切断を遅くしてあります。
WinnyではTCPを１つしか使わないので、ネゴが終わるまで
転送リンク接続か検索リンク接続なのか判明しません。
そして検索リンクは１ノード１つですが、転送リンクは複数許されます。
で、転送リンクは始めのうちはネゴが終わってない検索リンク扱いされます。
問答無用で重複している検索リンクを切断すると転送が開始しません。
これのためにわざと重複切断を遅くしてあります。昔のバージョンで転送リンクが
プチプチ切れて転送開始しなかったのは主にこれが理由でした。
- 676 名前：47 投稿日：02/06/16 23:35 ID:cv1JyEFJ main/1024117422.html#199
- と、下流４２ということは別の理由で、クラスタ化のために限界超えた
検索リンク切断が、上で書いたのと似たような理由で遅延するので、
固定ノードなどだと人気があってそうなると思います。
WinnyではFreenetと違ってIP可変前提で設計されてますので、
DDNSなど使ってたら逆に切ったほうがいいかもしれません。
ただ、だれか固定ノードの人がいないと初めて参加する
人が困っちゃいますけど(^^;
- 677 名前：47 投稿日：02/06/16 23:36 ID:cv1JyEFJ main/1024117422.html#200
- ああ、あとクラスタ化の結果凄い人気があって接続集中という可能性も・・・
- 678 名前：47 投稿日：02/06/16 23:42 ID:cv1JyEFJ main/1024117422.html#202
- とりあえず、最近のバージョンでは上流有利で下流不利でしたが、
下流対策始めたことで上流が高負荷になりやすいです。
微妙な調節ですし、詐称の方々が下に戻ってくれないと
どうしようもないので少しお待ちください。
当分は申告を下げるようお願いします。
下流でもダウンはかかるので今のバージョンで上流にいるメリットは
転送が発生する率が高いのと、転送相手が同じ高速ノードに
なりやすいことぐらいなんじゃないかと思います。
- 679 名前：47 投稿日：02/06/16 23:59 ID:cv1JyEFJ main/1024117422.html#205
- あと、最上流の人は設定のところで下流ダウン禁止へのチェック外さないと
何も落ちてこない可能性ありますので注意お願いします。
当分は、昔のバージョンと同じで下方詐称して調節するしかないと思います。
高速な方は高速に申請、低速な人は低速に申請するのがもっともうまく動作するようにして
詐称などしないでも全体がうまく動くようにするのがベストなんですが、
常に回線速度に関係無くこの辺が一番いいというところができてしまうので頭が痛いところです。
- 680 名前：47 投稿日：02/06/17 00:10 ID:LkDebWd8 main/1024117422.html#207
- とりあえず、上流でＣＰＵ負荷が高くなるのは、
β６以前でよく発生していたなつかしのクエリ溢れのはずですので、
対策としてクエリ発生率を落としときました。
すいませんがβ15.4落としなおしといてください。よろしくです。
そろそろ寝ます。
- 681 名前：47 投稿日：02/06/17 12:40 ID:xTSr85zE main/1024117422.html#258
- β15.5です。単に不祥事対策版です。
極端にダウン率が下がっているようですが、調べてみると転送発生率が
凄くなっていて最悪自ノードに転送要求が戻ってきたり、複数のノードに
リンクがダブっていったりしているようです。
リンク繋がったのにカウントが０のまま止まるのは、ダウン先でも転送が発生して他への
ダウンが開始されてファイルを待っているために起きます。
これは、β15.3で実験的に入れたコード（上流キー優先にする部分）が原因です。
ということで、やはり実験的なもので無理だったかということで、
β15.4からβ15.3のこの部分を除いたのがβ15.5です。
アップ側とダウン側が取り替えないとこの不祥事が収まらないので
収束に時間がかかると思いますが順次取り替えてください。
一応上方キー優先ダウンはできますが、15.3や4と違い、強制的に
処理しないので、情報キーの数が少なくダウンがかかりにくくなると思います。
急いで落としたい場合以外はＯＦＦにしといてください。デフォでＯＦＦになってます。
- 682 名前：47 投稿日：02/06/17 22:01 ID:nTys5y3R main/1024117422.html#271
-
- 683 名前：47 投稿日：02/06/17 22:13 ID:nTys5y3R main/1024117422.html#273
- ベータ16公開しました、発想の転換でずいぶんとDL速度が上がるはずです。
- 684 名前：47 投稿日：02/06/18 13:26 ID:D0m8W2j+ main/1024117422.html#347
- 少しだけ気分的に余裕出てきたんで、放置気味のβ15のバグ取りしたいんですが、
今現在、致命的で確実に発生する不祥事って何かありますか？
細かいバグが多すぎてどれが致命的なのか良く分からなくなってますが、
大きなファイルをUPしたところなんかが一番まずいですかね？
- 685 名前：47 投稿日：02/06/18 13:37 ID:D0m8W2j+ main/1024117422.html#348
- 一番動作が怪しそうなUPフォルダ周りの挙動書いときます。
１．起動するとまずキャッシュフォルダ内部の全キャッシュヘッダを読みに行く。
UPキャッシュも部分キャッシュの一種なのでここで読み込まれる。
また、先頭１０ブロックしか持ってない破損キャッシュはキーとキャッシュファイルを削除
ただし、UPキャッシュだというマークがついていたらこれは行わない
２．キャッシュの読み込みが終わったら、UPフォルダ内のファイルを一度に一つ
ずつ順にチェックに行く。
３．UPファイルを読んだら、まず名前とサイズで手持ちのキーに検索をかけ、
該当するUPキャッシュキーがあったらそのUPキャッシュキーをUPキーに書き換える。
該当するUPキャッシュが無かったら新規UPファイルであるとみなして、
全ファイル内容のスキャンを行い、全ハッシュを求める。
また、UPキャッシュにかかれている更新時間よりUPファイルの更新時間が
新しい場合も、UPファイルに変更があったとみなして再スキャンをかける。
と、こうなってます。この機構は作ったばかりなのでまだどこかバグってる可能性が高いです。
特に３の部分ですね。余裕のある方は動作チェックお願いします。
- 686 名前：47 投稿日：02/06/18 14:04 ID:D0m8W2j+ main/1024117422.html#354
- あと、キーロスト切断が最近多発する問題ですが、これは
実際はキーロストで切れてるんではなくてファイル本体のブロックロストで
切れてることが多いと思います。
相手にダウンかけてその結果キーが既に消えてたりするとこのエラー出ますが（大抵キー寿命切れ）、
こちらの手抜きにより実際には別のエラーで生じた転送リンク切断でもこう表示されます。
なぜ転送リンクが切れたかは向こうから申告してもらわないと分からないのですが、
転送リンク切れたら理由を教えてもらえない罠ってことで。
最近これが頻発するのは、単にキャッシュが十分出回ってなくて部分キャッシュが多く、
残りの部分を落し終わる前にダウン側にUPが終わってしまい、送るファイル本体
が到着する前にタイムアウトで切れてるんではないかと思います。
ですので、これに関しては時間がたって新キャッシュが出回れば解決するはずです。
- 687 名前：47 投稿日：02/06/18 14:07 ID:D0m8W2j+ main/1024117422.html#356
- >>349
ひょっとしてファイルの更新時刻取得って
find_firstで得られた値使うと何かまずい？
- 688 名前：47 投稿日：02/06/18 14:09 ID:D0m8W2j+ main/1024117422.html#357
- >>355
どもです。正直時間がなくて全部見切れてないので助かります。
UPキャッシュだという情報がいつのまにかキャッシュヘッダから消えていると
こうなる気がするのでチェックしてみます。
- 689 名前：47 投稿日：02/06/18 15:45 ID:D0m8W2j+ main/1024117422.html#361
- チェックしなおしてみましたが、完全キャッシュとUPフォルダで重複があると問題が出ていたのは、
UPキャッシュだとキャッシュヘッダ読んでどのブロックを持っているのか再チェックしてなかったのと
変換開始時にUPキャッシュマークを消していたからでした。
そのため、リフレッシュを押すと、完全キャッシュが、ブロック全損のキャッシュとして
一時的に扱われて、ごみキャッシュチェックで一度全部消えて、
結果、キャッシュ無しのUPファイル扱いとなっていたようです。
ということで直しましたが、そもそも完全キャッシュよりUPファイルの方が優先なのは
β１公開直前に、UPファイルがキャッシュ経由しないで直接UP可能にしたためで、
本来はUPファイルより完全キャッシュの方が優先されるべきなので、そのように直しました。
これにより完全UPキャッシュと言う、分かり難いものが存在することになりますが、
同じハッシュ値のキーが重複していた場合、
仮想キー < 部分キャッシュ（UPキャッシュ） < 受可キャッシュ < UPフォルダ内 < 完全キャッシュ（完全UPキャッシュ）
という扱いになります。より優先度の高いキーが見つかると優先度の低いキーは上書きされます。
とりあえず、別のトラブルが発生しそうなんで、もう少しチェックしてから公開します。
あとそういえば、そろそろキーの個数に制限かけないとなー。
- 690 名前：47 投稿日：02/06/18 16:02 ID:D0m8W2j+ main/1024117422.html#362
- あと相変わらず問題なのが下層側がマターリしすぎという問題ですが、
これは扱いが非常にやっかいで、今だと自動ダウンの内容で
上流にクエリ出すのは60秒に一つです。β15では200秒でした。
β15.4の初期バージョンでは20秒に一つでしたが、直ぐに最上流でCPU負荷が凄く
固まるという報告があったのでここまで落してます。
今でも下流ノード個数が多い場合、一時的に固まる動作することが
あると思いますが、クエリ個数を見てみると
数十のクエリ処理が発生してるんじゃないかと思います。
これはそもそも検索部が重いのが根本的な原因なんですが、
これ以上簡略できないし（そもそも、もう少しまじめに漢字コードのチェックとか
and検索などやりたいんですけどここが一番重いところなんで頭いた）、
今でも既に検索結果のキャッシング処理してるし、どうするかなぁって所ですね。
ちともう一度考え直してみますが、多少検索ヒット率落ちてもキー数を減らすのが
有効的でしょう（クエリ処理では全キーとマッチとるんでキーが減ると早くなる）。
そうなると、キー数が少なくてもヒット率が確保できるようにすべきということで、
クラスタ化の方をもう少し見直すべきでしょうね。
- 691 名前：47 お電話はこちらまで ◆110/dN.2 投稿日：02/06/18 19:57 ID:nybUFPVY main/1024117422.html#370
- Winnyで違法なファイルのやりとりが確認されましたので、
これ以降の開発を中止致します。
皆さん、今までありがとうございました。
よいP2Pの実践になりました。
- 692 名前：47 お電話はこちらまで ◆110/dN.2 投稿日：02/06/18 21:18 ID:nybUFPVY main/1024117422.html#376
- >>373
FTPのパス忘れてしまいますた
- 693 名前：47 お電話はこちらまで ◆110/dN.2 投稿日：02/06/18 21:34 ID:nybUFPVY main/1024117422.html#383
- 本物ですが、何か？
- 694 名前：47 お電話はこちらまで ◆110/dN.2 投稿日：02/06/18 22:08 ID:nybUFPVY main/1024117422.html#386
- >>385
アンチ全ですが、何か？
- 695 名前：47 お電話はこちらまで ◆110/dN.2 投稿日：02/06/18 22:14 ID:nybUFPVY main/1024117422.html#387
- つーか、何？あの試合？
韓国塵が、頭蹴ってる。
あーいうの見ると、マジでムカツク。
韓国は、韓国らしく氏ねばいいのに…
いままでの復讐と言わんばかりにやってるのには、マジで切れそうになった。
もう、Winnyの開発やめよっと。
恨むなら、韓国代表を恨め。
- 696 名前：47 お電話はこちらまで ◆110/dN.2 投稿日：02/06/18 22:24 ID:nybUFPVY main/1024117422.html#389
- >>388
もう作るのやめますた
- 697 名前：47 投稿日：02/06/18 23:28 ID:JKc4nv3a main/1024117422.html#392
- β15.6です。互換があります。主に上流の負荷対策です。
都合により開発環境変えたのでこのあたりで公開しておきます。
下流方向のキーのみ制限しているのでダウンが高速になるわりには、
β15.3と違い特に不祥事起こさないですむんじゃないかと思います。
上流も比較的負荷が下がるんじゃないかと。
・ UPファイルより完全キャッシュの方を優先度を高くした
・ UPフォルダの完全キャッシュ変換時の不祥事対策
・ ハッシュチェック速度を高速化
・ 下流仮想キーの個数を1000個に制限
・ 一度に処理するクエリ個数を20に制限
・ 自ノードに対するリンクを明示的にカット
・ 開発環境をVisualC++.NETに変更
- 698 名前：47 投稿日：02/06/18 23:30 ID:JKc4nv3a main/1024117422.html#393
- おっと、
・ ハッシュチェック速度を高速化
これはやる予定だっただけで、作業はまだです。
次やる予定ということで。
- 699 名前：47 投稿日：02/06/18 23:31 ID:JKc4nv3a main/1024117422.html#395
- あと、キー個数制限10000でした
- 700 名前：47 投稿日：02/06/18 23:49 ID:JKc4nv3a main/1024117422.html#398
- 14.8のレベルまで戻すのが大変ですが、
後退することを恐れていては前に進めんので
多少の不祥事には目をつぶってβテストお願いします。
一歩戻って二歩進むを繰り返せるのが理想です。
キャッシュあふれに関しては、みんながこれに困るように
なってきたら対策することになりますが、今はまだ十分落とせない
状況だと考えますのでそのレベルまでもう一息です。
十分落とせるようになれば、次はごみを優先的に捨てることで
意味のあるキャッシュのみ出回らせるようにできる段階になります。
- 701 名前：47 投稿日：02/06/19 00:02 ID:ugRiwa0f main/1024117422.html#406
- MFCベースで作ってあるしライブラリもスタティックリンクしちゃってるので
.NET開発環境で作ってあっても問題なく動くと思いますが、
新環境で作ったプログラム一般公開するのは初めてなので何か問題あるかも
しれません。
コンパイルのほうはどこも変えないで一発で通って動作したんでMFCベースなら
VC++の6.0→.NETはほぼ何もかわっとらんと思うんですが・・・
とりあえず、クラスタ化の再調整とかあとキャッシュもう一度変えないとならんし
細かいバグあり、GUI調節まだとやることはたくさんありますが、
そろそろ大変更項目が無くなってきたんで、７月頭までには正式版になるんじゃないかと。
- 702 名前：47 投稿日：02/06/19 00:14 ID:ugRiwa0f main/1024117422.html#410
- 一度VC#使うとVC++使うのあほらしくなっちゃいますけどね(w
しかし、パフォーマンス重視でWin環境どこでも動くとなると
やはり選択肢が狭いです。
特にWinnyは力技で匿名性とダウン率を同時に確保しているわけで、
他の開発環境ではつらいんじゃないのかなぁ。
- 703 名前：47 投稿日：02/06/21 01:43 ID:qw9nlr+K main/1024117422.html#556
- 数字入れ忘れた（ｗ
- 704 名前：47 投稿日：02/06/21 01:49 ID:qw9nlr+K main/1024117422.html#561
- ゴミダウンさせようとするのの対処で一番簡単なのは、
自分で興味ないのを指示してはじくことだと思うんで、
適当にゴミをはじけそうな単語追加しといてください。
これで対処できるはずです。
興味ないのを弾けますので、クラスタ化にも有効でしょうし。
- 705 名前：47 投稿日：02/06/21 01:55 ID:qw9nlr+K main/1024117422.html#562
- >>559
これはあったほうが便利だし、無いと今回のような事態に対処できないので
このまま残ると思います。転送も弾けるようにするかどうかは微妙なところですが、
やらないほうがいいでしょう。これに関しては今回の対処でいいんじゃないかと。
- 706 名前：47 投稿日：02/06/21 04:19 ID:IFwh9PIX main/1024117422.html#606
- なんか暇な方がいるようで本格的にβテストやってくれる方がいるようで助かりますが（ｗ
ゴミファイル対策だけじゃなくてゴミキー対策もやらないとこれであふれてしまうようなので、
無視リストにかかった手持ちのキーも消すようにしときました。
ただ、完全に消すと負荷がすごいし違う問題もあるんで、多少はゴミキーが残ります。
結果的に無視リストに入っているとその転送も受けにくくなるはずです
（転送がかかる前にキーが消えて転送依頼先でキーロスト発生率が高くなる）
てなことで、β15.7（6/21版）となりますので、15.7落とし直しといてください。
- 707 名前：47 投稿日：02/06/22 01:59 ID:vwmqakWG main/1024117422.html#722
- β15.8です。互換性ありです。単なる小変更です。
・ 自動ダウンのキーワード制限を半角４文字以上に変更（無効制限は２文字以上）
・ ＵＰ側タスクのタスクスライスを細かくした
・ 転送リンクタイムアウトを少し長くした
・ ノード情報のところに送信側デバッグ表示
・ ダウン中ノードの申告速度を表示
- 708 名前：47 投稿日：02/06/22 16:51 ID:wlTAQQeI main/1024117422.html#789
- β15.9です。互換ありです。
どうも熱心なβテスターさんががんばっているようで
単純にフィルタできないようなキーを繰り出してくるので、
本来後回しにする予定だった無視ノード機能つけました。
・ 無視条件にかかるキーをたくさん送ってくるノードを無視ノードと扱い接続拒否
・ 無視条件にかかるキャッシュを空キャッシュ（再起動で削除される）にするようにした
・ 検索部での漢字コード後半での大文字小文字変換をチェック
・ 切断後、長時間たったノード表示ＯＦＦを取りやめ
無視ノード認定されるとBadPort0と似た扱いになるので、接続にいきませんし、
接続されても切りますし、他ノードにも教えません。Noderefに保存もしません。
また切断時にそこから来たキーが皆消えますので、ゴミキーの多くが消えます。
（処理負荷が高くなるので、完全には消してない）
これにより迷惑ノードは皆がフィルタすれば孤立するはずですが、
そもそも今回の機能は本来、単純な無視機能ではなく、クラスタ化の一環でして、
嫌いなファイルを持っているノードを遠ざけるという、負のクラスタ化でもあります。
ただ、負のクラスタ化の効果が強すぎて各ノードが分断される可能性もあります。
あるキー群を持っていると嫌がられて孤立することがあるということになります。
孤立しても同傾向のノードは繋がるのでクラスタ化されて別に集まるでしょうが。
とりあえず、βテスターさんの思惑にはまってる気もしますが、テストってことで。
おまけとして今回の機能を利用することで、ゴミキャッシュの整理もできます。
あと、ハッシュダウンだけにするという意見が出てますが、
キーワードで落とせるようにしているのは、ある狙いからですし、
今やってもそのバージョン使わない人がでるだけのはずなんで問題を後回しします
（昔自動ダウン制限入れたときもこうなった）
どうせこれやっても現状では狙って落とせないはずで逆効果の方が大きいはずなので、
プロトコル変わるまで少し待ってください。
それより今は新キャッシュ出回るの待ちでしょう。
どちらにせよ、ハッシュ無しでの自動ダウンは何らかの制限が加わる予定です。
あと、自動ダウンにかかる仮想キーを消さないというのも面白いですが、
試しにやってみたらキーバッファが溢れるだけ（ゴミキーのせい）だし、
そもそも後から自動ダウンに登録するのが目的であれば、
一度でもダウンに行ったキーは部分キャッシュとなってキー寿命が
無限になるのでキーが残っていて消えないはずで、部分キャッシュから
登録に行けばいいはずで既に実装済みの機能ということで、とりやめました。
- 709 名前：47 投稿日：02/06/22 17:13 ID:wlTAQQeI main/1024117422.html#794
- >>792
キー自身は消えません（中身が０の部分キャッシュになる）ので厳密には消えませんが、
基本的にはそうです。
無視指示しておけば、転送もしないですみますし、キャッシュも消費しませんが、
その代わりその拡張子のファイルは自分でダウンもできなくなりますので、
絶対このファイルいらないというもの以外、拡張子指示はやめたほうがいいでしょう。
そもそもあまり汎用な単語を無視リストに入れていると、
他と検索リンクが繋がらなくなって孤立する可能性が高いです。
- 710 名前：47 投稿日：02/06/22 17:19 ID:wlTAQQeI main/1024117422.html#796
- 一つや二つ無視リストにヒットしても切りませんので
ほとんどの場合大丈夫だと思いますけど、
あとは様子見ですね。
- 711 名前：47 投稿日：02/06/24 20:05 ID:XMtwCCdf main/1024847166.html#36
- β15.10です。互換があります。
・ 検索クエリ以外で、キーを検索リンク下流方向にも流すようにした
・ 検索リンク切断率を下げた
下流でキーが無くなるのが問題になっているようですし、フィルタでキーが消える
ようになったせいで全体的にキーの数が少なくなっているようですので、
検索クエリのリターン以外でも上流から下流にキーが流れるようにしてみました。
これだと検索リンクの上流下流の意味がなさそうですが、
・下流から上流へのキーは連鎖的に最上流まで流れる
・上流から下流へは一つ下にしか流れない（最下流までは時間がかかる）
・検索パケットは上流にのみ飛ぶ
・基本的に転送は検索リンク上流で起こる
ということで上流、下流方向で処理の内容が違うので、上流ほどキーが多く保持される
のは今までと変わりません。全体でのキー分布偏りが少なくなるだけです。
上流方向と違い下流へは連鎖伝達しないので負荷的にそんなに凄いことには
ならないと思いますが、とりあえず実験です。
キー分布状況がかなり変わると思います。
あと、UPキーが消えるという報告があって確かに長時間放置していると
見える数が減っていくようですが、システム情報の方では減らない
ことからすると、減っているように見えるのはキー表示周りの問題で
送信などでは処理されてるはずだと思います。
ただ、確認に時間がかかるし理由が思いつかないのでまだ対処できてません。
確認が難しいと思いますが、もう少し細かい現象を確認できるかたは報告お願いします。
- 712 名前：47 投稿日：02/06/24 20:31 ID:XMtwCCdf main/1024847166.html#40
- >>38
そのときのシステム情報でのアップファイル数とアップキー数は覚えていませんか？
UPキーで消すようなところはないので、キーのやり取りしているうちに消えるんだと思います
（例えば自分が外部に出したキーを自分自身で受け取ってとか）が、
どうもよく条件がわかりません。
- 713 名前：47 投稿日：02/06/24 20:51 ID:XMtwCCdf main/1024847166.html#44
- 中流、上流は大丈夫なのかな？
上流側が変わると下流も連鎖的に影響受けるんでどうしても下流が後回しになってましたが、
そろそろ下流側に特化したチューニングしますか。
- 714 名前：47 投稿日：02/06/24 21:28 ID:XMtwCCdf main/1024847166.html#49
- >>46
UPフォルダやキャッシュファイルの状況と、それらがどのぐらい人気がありそうか、
あとどの程度の大きさのファイルが多いか教えてもらえませんか？
もちろん具体的な話は無しで。
単に人気があって接続要求が多いだけのようにも思えますので。
- 715 名前：47 投稿日：02/06/24 22:11 ID:0ZCCMv+0 main/1024847166.html#54
- うーん、やっぱり回線速度違うと動作も変わってくるようでテストが困りますねぇ・・・
なんとなくですがその動作は、下流から自動ダウンで送られてくる検索クエリが
どこかで溜まって一度に送られてきているような気がします。
重くなった瞬間にシステム情報でクエリの数を見てみてください。
- 716 名前：47 投稿日：02/06/24 22:31 ID:0ZCCMv+0 main/1024847166.html#60
- >>58
やはり下流の自動ダウンで発生する検索クエリが上流であふれちゃってるみたいです。
β15.10変えてる最中に思ったんですが、回線速度速くてもＰＣ早いとは限らんわけですし、
自動ダウンメインのいまですと検索ボタン使う人あまりいないだろうから、
開き直って検索クエリはおまけと開き直って、上流へも下流もキーのやり取りを
キー転送メインにしてしまったほうがいいかもしれません。
上流も下流も保持するキー数は1万程度に固定で上下キーのバランスが
違うだけで、クラスタ同じなら持ってるキーもほぼみな同じという設計になります。
持っているキーがゆっくり周辺に伝播していくので、
ノードで近い人は似た傾向のキーを持つと。
少し離れたノードのキーを無理やり引っ張ってくるためにやはり検索機能は残りますが、
どちらかというとキーもったまま検索リンクが繋ぎ変わることによって、
ファイル名が伝達していくという普通のファイル共有ソフトの常識から外れたもの
（ファイル検索をあきらめる）のほうがいいのかもしれません。
全部が今の中流のような動作になります。
上流と下流の差は転送依存関係程度とクエリ出したときの違い程度になります。
こうすると上流で自動ダウンによるクエリを発行する必要ありませんし、
下流でもキーが無くて困ることはありません。
簡単なんでβ16で試してみます？
- 717 名前：47 投稿日：02/06/25 01:49 ID:K/AvW/0y main/1024847166.html#90
- β16です。互換性ありません。
・ 自動ダウンによるクエリ発行をやめた
・ キー転送で連鎖的に遡るのをやめて上下とも隣接ノードにのみ転送する方式にした
・ キー転送率の上昇、キー寿命の延長
・ UPキーが暗号化キー名で上書きされて見えなくなっていたことがあったのを修正
プログラム的には数行の変更ですが、キー管理周りの概念がβ1以来の大変更になりますので、
間違いなくトラぶります。キーが出回りすぎるか逆かのどちらかになるはずなので、
直ぐに調節かけます。
ただ、今回の方式ですと、一つの検索リンクに流れるキーの数が常に同じなので、
上流下流に限らず検索リンクで発生するトラフィックは検索リンクの数だけに依存します。
上下方向も同じです。ですので、キー伝播に関しては隣接ノードに拡散していくことに
なり、回線申請値は関係なくなります。
β16ですと、一つのリンクに流れるキーは常に１秒に１つの割合です。１キーで100〜200
バイトのはずですので、１リンクあたり0.1〜0.2kB/s程度の「はず」ですが、理論値です。
調節します。
ああ、あと、UPファイルが消えるのは、UPファイルは暗号化されてないのに、
他から同じハッシュのキーがくると上書きされて暗号名になってたという凡ミスでした。
修正しました。
- 718 名前：47 投稿日：02/06/25 02:09 ID:K/AvW/0y main/1024847166.html#95
- プロトコル変わったから当分繋がらないと思います。
あと、ノードリストが見つかるまで無視キーは外しておいたほうが良いでしょう。
- 719 名前：47 投稿日：02/06/25 03:18 ID:K/AvW/0y main/1024847166.html#100
- どちらかというとキーが少なすぎの様ですので、転送比率上げときました。
あと、上流から来たキーの制限が無くて下流のみ10000だったので、
上下あわせて20000にしてあります。
特に変えないでも平気ではありますが、順次差し替えといてください。
β16のままで、6/25版です。
- 720 名前：47 投稿日：02/06/25 08:56 ID:wUYTTER7 main/1024847166.html#123
- 更新が頻繁ですいませんが、β16.1です。互換あります。
・ キー転送率を回線速度に応じて可変にした
・ 検索リンク数の上方制限を４にした
キー少なすぎてヒット率に問題がありそうなので調節しました。
とりあえず、これ以上転送率上げると下流の人がキー転送で帯域取られすぎる
はずですので、上流と下流でキー転送率を可変にしてあります。
低い方にあわせるようになってますので、詐称してなければ問題ないはずです。
あと今ですと、検索のときしかクエリパケット飛ばず、
また手動検索はあまり使わないはずで検索リンク数が多くても
それほど問題にならないはずなので、
ヒット率向上目的で上方検索リンク制限が昔と同じ上下４に戻ってます。
こんなもんで、あとはキー寿命だけでキー流通量調節すればいいかなと。
- 721 名前：47 投稿日：02/06/25 18:09 ID:c1a7rQvS main/1024847166.html#149
- 今だと、上方向のリンク増やしたのが効いてるはずです。
とりあえず４→３にすれば収まるはず。あと、忙しくてクエリ溜まってると、
クエリが処理できないのに新しい送信クエリ発行して処理が追いつかなくなる
という現象が出てるんでしょう。これもクエリ数見て制限かければいいはず。
致命的なんで直したいんですが、職場のPCのVS.NET調子悪いしちーと待ってください。
- 722 名前：47 投稿日：02/06/25 20:22 ID:fMlIonaS main/1024847166.html#156
- 微調整バージョンのβ16.2です。互換あります。
・ 検索リンク数の上方制限を３にした
・ クエリが溢れている場合、キー転送をキャンセルするようにした
・ クエリ発行率を下げた（クエリの大きさは大きくなっているのでキー伝播率は同じ）
・ キーの寿命を延長
検索ではなく、キー伝播のクエリでバッファが溢れるようですので、それに対処しました。
突然落ちたりしてたのはほとんどこれ（クエリが溜まってくると処理が重くなって悪循環）
が理由のはずです。
- 723 名前：47 投稿日：02/06/25 21:25 ID:fMlIonaS main/1024847166.html#162
- 今のWinnyの最大の問題点は、検索が弱いということだと思います。
これは、上流側にキーを溜めておいて下流からこれに検索かけるだけで
横方向は基本的にキーがその寿命内でノード間を伝播するのに任せる
という方式だから仕方ないところもあり、上方向と下方向を追っていける範囲程度
のノード内（多くても100ぐらい？）のノードのファイルしか基本的に見えません。
といって、まじめにやるとFreenetのように各ノードをパケットが渡り歩く必要があって
遅くなりますし、まじめにパケット渡り歩かせても遠くが見えないのは同じです。
集中サーバでノード管理しないとどうしても効率的な検索が難しいわけです。
ただ、Winnyでは上流ほどキーが集まるので、上流ノード間のみ渡り歩くクエリさえ
実現できれば、集中鯖無しにしては比較的効率良く検索ヒット可能になるはずです。
クラスタ化の時にこれを入れる計画もあったんですが、結局ノード優先度という形で
クラスタ化を実現したため現状で横方向検索リンクは入ってません。
ここで、一つの案として、最上流までクエリパケットが到達して、
まだクエリパケット限界（今は200）までキーが詰まってない場合、
一つ下のノードに一度クエリを渡してまた別の上流ノードに投げてもらうということを何回かやれば、
かなりの広範囲（別クラスタ）までクエリが届きます（上流でW字状にクエリがスイッチバックしていく）
クエリが戻ってくるのに数分かかる可能性もありますし、見えるだけでまず落とせませんので、
結局自動ダウンに登録してあとはうまく近傍に来るのを待つことになってしまいますが、
遠くのノードのファイルが探せないよりは探せる方が良いので、次のメジャーβで
やっても良いかもしれません。これなら作り変えるのがそれほど面倒ではないです。
クラスタ化のところと連動して見つかったキーのノード優先度上げれば
実際に落とせる率も高くなるでしょうし。
- 724 名前：47 投稿日：02/06/26 09:39 ID:qh8bgT2n main/1024847166.html#193
- β16.3です。互換あります。
主にUPファイル周りの対処です。
・ キー名管理がUPキーだけ別扱いになっていたのを統一（常に暗号化して保持）
・ ファイル名のクリップボードコピー機能追加
・ 接続優先度が負方向に非常に大きくなったらノードを削除
・ ハッシュチェック中にリフレッシュすると変なUPキャッシュができていたのを修正
・ リフレッシュボタンを公開フォルダタブに移動
UPファイル再チェックがかかる理由の一つとして、
昔公開したためUPキャッシュだけ残っているファイルの本体を他からダウンしてくると
確実にUP再チェックにかかるというのがあったようです。この辺は直っているはずです。
全体的に処理がシンプルになったので変なファイルがキャッシュフォルダに
できるだとかの細かい不祥事はなくなるはず。
ただ、UPファイル再チェック発生は別の場合でもありうるので、
確実には防げないと思います。
可能性の一つは、内容がまったく同じでファイルがUPフォルダに
重複して別の名前で置いてあるパターンです。
今だとキャッシュは名前でなくハッシュ値から生成しているので、
同じ内容だと同じキャッシュファイルになります。
UPファイルの情報を保持しているUPキャッシュもキャッシュの一種ですので同じです。
普通のキャッシュファイルなら名前別でも自動的に同じ内容なら重複
されるので無駄にHDD消費しないで良いですが、UPキャッシュだと
同じ名前の時にハッシュ再チェックしてしなうという問題があります。
UPキャッシュ内に複数の名前を格納できるようにすればいいのでしょうが、
ちょっと無駄ですし対処が面倒です。重複検出したらログに警告出すという
程度ならできそうですが、この辺はまたキャッシュのバージョン変えたとき
に対処になるでしょう。最低、あと１回はキャッシュバージョンが上がる予定ですし。
- 725 名前：47 投稿日：02/06/26 09:41 ID:qh8bgT2n main/1024847166.html#194
- とりあえず、キャッシュ破損が完全に無くなってはいないとは思いますが、
そんなに頻繁に発生することはないと思いますので、
それより先に検索率向上対策をやってからその後キャッシュフォーマット�