47氏発言集(手抜き版)

1 名前:  投稿日:02/04/01 05:35 ID:WTyTkgT/ main/1017590243.dat: 47
暇なんでfreenetみたいだけど2chネラー向きのファイル共有ソフトつーのを
作ってみるわ。もちろんWindowsネイティブな。少しまちなー。

2 名前:47 投稿日:02/04/01 23:14 ID:7XMU++Uj main/1017590243.html#56
暇つぶしにぬぼーと新しいファイル交換ソフトを設計中。

現状では、Freenetと似た転送方式だけどあれと同じだと重そうなんで
ファイル検索部はFreenetと同じだけど、データダウン部分はファイルを
持ってる一つ前のサーバー部で中継してもらう方式を予定。
一度親に落としてもらってから子に転送するのでProxyとしても働く。
netstatでソケットの接続見ても無関係の親と子が見えるだけ。
もちろん親でキャッシュファイルを吐いてるのか串動作なのかは子からはわからん。
回線が細い人は子を0にしてやり取りを親との一対一に固定。
子を0より大きくすれば大域制限無しで動作する。

あとファイル名もファイル内容も初めから全て暗号化して扱って、
キャッシュは単なる数字のファイルという形式になる予定。
んで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
ねむー。明日仕事だつーのに(w
とりあえず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と似た親子の区別ができると思われます。
子供の数を0にすれば自分の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待ちなどの部分(リクエストのキュー部分)は
まだ設計自体が出来上がってないです。
ファイル転送部と中継部作ってそのあとだね。

とりあえず現状で完成度3割ってところで、次はメインとなるキーの検索部を作る予定。
基本的なファイルダウン部やレジューム部も作ってないからここもこれからだね。
簡単さからするとこっちが先かな。ここまでできればシステムの基本部分は7割完成かと。


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に頼ってしまうのが一番良いのでは
ないかと思っとったりします(w
チャット機能に2ch使うの推奨。

11 名前:47 投稿日:02/04/03 08:07 ID:+p+BRZqV main/1017590243.html#153
身元特定の可能性が上がることを考えてわざとトリップ付けないよん(w
騙りたい人は面白いからどうぞ。もしかすると面倒なことになる可能性はある。

そういえば、トリップで使われているようなハッシュ関数を用いることで、
ダウンするまでアップ側にまったくそれが何なのか気がつかせないシステムにできます。
今回のシステムの肝もこの辺になると思われ。

一度ファイル名をハッシュに変換してそれでファイルを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
もちろん、必死に暗号アタックすれば、キャッシュや公のサーバーにおいてある
ファイルの名前や中身がわかる可能性はいつまでも残るわけですが、
この状態でやばい物を持っていて、尚且つ持ち主が暗号解読不可能な状態なら、
それを公開している人が著作権侵害に当たるのか?わいせつ物陳列になるのか?
→問題その1

もしくは、システム側で完全に匿名にできたとしたら、そのシステムを作った人に
責任を押し付ける可能性は?という問題が無くもないわけでし


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になってます(w

16 名前:47 投稿日:02/04/04 06:15 ID:1Z/IrTWf main/1017590243.html#216
今WinNXで検索したらこんなものが(w

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
夜中に実装して昼間仕事だからここんとこぜんぜん寝てねー(w

とりあえず隣のクライアントへのファイル検索機能まではできた。
次、一番面倒な分散通信部の実装やね。

まだ実装が完成してないんで最終的にどうなるかはわかんないけど、
今の予想設計だとファイルを落とし始まった時点での接続は
(おっと、検索時はノードをのんびりと渡り歩くんで別よ)

検索者 <-----> 中継ノード <------> ファイル提供者

か、

検索者 <---> 中継ノード1 <------> 中継ノード2 <------>ファイル提供者

のどちらかになると思われ。もちろんこう見えるだけで実は

検索者 <---------> 串のキャッシュを送ってるように見えるファイル提供者

こうなってる可能性も発生する
(これは実際にはそれほど発生しないはず。上流に来易い
高速回線経由のクライアント間ほどこれが発生するかなー)

どっちにしろ、だれが検索者でだれが最終的なファイル提供者か
ネットワークの一部分を見ているだけではわからない。

暗号化も入るしMXよりはかなり安全なはず。
(もちろん249氏が言うように鍵知ってたら暗号も
解析できちゃうんだけで完全じゃないけど
串動作と組み合わせれば解析が非常に困難になる)
そうそう、通信の暗号化とファイル名&ファイルの暗号化は
別の暗号になるから、検索キーが公開されてても、
通信の中身はリバースエンジニアリングしないと解析できないよん。

基本的にプログラムのソースや通信プロトコルを公開する気はないし、
完全オリジナルのプロトコルで、通信全部を
暗号化(&エラー検出を兼ねる)の予定だから、
怪しい接続は問答無用で弾けるはず。

基本はMX+Freenetだけど、暗号化や認証、データ圧縮補正系の
技術てんこ盛り+串動作で解析不能にするわけやね。

もちろん手抜きしてるだけあってFreenetの匿名性には負けそうだし、
MXよりは不便でダウンが遅いだろうけど、目標は
MXの利便性・高速性とFreenetの匿名性を兼ね備えたシステムか。
もしどちらも実現できなかったら失敗ということで(w


18 名前:47 投稿日:02/04/04 14:43 ID:hr5Nfj19 main/1017590243.html#263
開き直って職場から書き込み(w
そろそろ4台以上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
本物と思われる人です(w。ついに偽者が出るようでうれしい。
間違ったことややばいこと書いたら偽者のせいにするのでよろしくね〜ん。

さて、今悩んでるのは検索時のネットワークルーティングでしょうか。
Freenetと同じでもいいんですが、遅そうなんで独自の方式を考え出しました。
具体的内容は秘密ですが、それなりに高速で、今回の転送方式との相性が良いはず。

もちろんどの程度のパフォーマンスが出せるかは実際に動かしてみないとわかりませし。
検証用のトラフィックシミュレーターでも作ってモデル検証してみようかとも思いましたが、
とりあえず実際に作ってしまった方が早そうなんで今夜にでも作ってしまいましょう。

予想では、mp3のような小さいファイルがたくさんとか、遅い回線使用者ばかり
ですとパフォーマンスが悪いですが、比較的大きなファイルが主流で
高速回線使用率が高いとMX並みの速度が出せるはずです。
匿名性最重視で小さいファイルメインならFreenetでいいわけですので、
今回のではMXの後継位置を目指して、それ向きな方式を選択していきましょう。

なお、Freenetの技術的なことはこの辺りが参考になりました
ttp://www.sfc.wide.ad.jp/~egichan/mlecture/netsec2000f/kadai3.html

あと要望に応じてソース一部提出(w
ちゃんと作ってますよん。

/*
* 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
テスト版完成が今月中ごろで最終チェックに1、2週間かけると思われ。
公開は一月ほど待たれよ。まだ開発初めて4日目で開発率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
気がついたらキーボード抱えて爆睡しとりました(w
今日は職場でのんびり作業しますわ。本職の方暇だし。
ちなみにプログラミング暦なら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の疑問に対する予想を書くと、

1.回線が早いと問答無用で親に繰り上がっていって常にUP状態となります。
  だからといって設定を工夫して親になりにくくすると今度は自分のダウン速度が
  上がりません。

2.各ホストのネットワーク構成(親子方向)は転送履歴とその速度を見て動的に変化していきます。
  網の目のように各ホストはつながりますが、データの流れ的にはツリー構造に近くなって行きます。

3.回線が早いと自動的に神状態(大量のダウン要求がくるけど勝手に持ってけ状態)に
  なっていきますが、ダウン速度はHDDが大量にあればそれほど下がらないはず
  (キャッシュが効くから)
  よって、回線が早く上流の位置にあたるホストは、無条件でキャッシュに
  人気のあるお約束ファイルが溜まっていきます。
  高速回線でHDDに余裕がある方は、暇なときに回線に繋ぎっぱなしにしておいて、
  暇なときに自分のキャッシュに検索かけるとさくさくファイルが見つかる可能性が
  高いです。

4.回線が早いのにHDDが無い(キャッシュを小さく設定)でもかまいませんが、
  昔一度読んだデータでもまた他からダウンしにいくので、ダウン速度が下がります。
  よって基本は、太い回線者ほどキャッシュフォルダを大きくとったほうがいいです。

5.回線が細い人はDOWN専用になってまず転送に加担しませんが、
  貴重なファイルを持っていると高確率で吸い出されて行きます。
  ここの部分はまだ設計が完全ではないですが、貴重なファイルを
  持っているほど検索速度やダウン効率が高くなるようになると思います。

6.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
ある程度できたら本体はこのシステムで提供するから
捕まったら自業自得(w

32 名前:47 投稿日:02/04/05 23:08 ID:bBRp+Hyf main/1017590243.html#441
>>439
気がついていると思いますが一応書いておくと、
自分のキャッシュ内にあっても検索をヒットさせないと
それがなんだかわかりません(w



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は頑張って貴重なファイルを提供してくれるに違いない。

・・・・といいなぁ(w

35 名前:47 投稿日:02/04/05 23:41 ID:77Xrl5cl main/1017590243.html#450
> 回線が細いDOMは頑張って貴重なファイルを提供してくれるに違いない。

こりゃDOMじゃないね。修正。

回線が細いDOMは何も落とせない(w


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対1の交換only状態になります。




38 名前:47 投稿日:02/04/05 23:52 ID:77Xrl5cl main/1017590243.html#457
律儀に答えてみるテスト

>>452
だからここでやってたり(w

>>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見てもソースあるだけで怪しいデータやり取りしてるのは
他の人の責任だし、後の可能性を考えると開発も匿名の方がいいだろうって判断で
最後まで名前隠します。ウイルスみたいなもんですね。
まぁ、開発理由は単なる暇つぶしです(w。正確に言えば、Freenetを面白いと思ったのと、
まだ使い物にならんなーどうにかならんかなと思ったのがその理由ですね。


41 名前:47 投稿日:02/04/06 01:07 ID:M5Lc7MaX main/1017590243.html#471
>>464
ご意見どうもです

> 複数起動して自分のファイルを自分で検索&ダウソして優先度を押し上げるとか…

あーなるほど、それありそうですね。できるだけ禁止するようにしときますが、
複数のマシン使って回線詐称されると痛いかもしれず。
実際にデータ量測ってても、これならごまかすことはできますし。

ただこの辺は単に接続相手の選択にかかわることなんで、高速回線の人とは繋がりたくない
って場合にのみ意味のある技かな。複数起動したら結果的に低速扱いになるんで
それで転送を頼まれる率は下がりますが、接続相手も低速回線の人が増えて行きます。
この辺は基本的に同じ程度の速度の人同士で繋がるようにする工夫なだけですし、
回線が細くてこれやったらDOM可能でも時間がかかりすぎて途中で切られるでしょう。

> 一時的にログを取得中

とりあえず平気でしょう。開発途中のソフトの話しただけで捕まるはずないし、公開しても
作者の逮捕は無理かと。ファイル交換ソフト作成で逮捕された例なんてないはずだし、
公開後に個人情報を特定されるだけなら痛くも痒くもないなー。
逆に売名行為になっていいかも(w


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上でひっそりやって目立ってきたら
自分で作ったワールド内に逃げればいいと思われ。

広まるほどの完成度に達すれば逃げられるし、
達しなければ捕まることも無いという二重の安全策(w

あとMXでの公開の方が絶対危険だよね。
あれ珍しいファイルだと提供者のIPが一発でばれるし。

44 名前:47 投稿日:02/04/06 14:39 ID:AKIOBPTK main/1017590243.html#538
あー、今日は休みなんですげーよく寝た(w

とりあえず昨日の夜はファイル本体の転送部作ってました。
ファイルのヘッダを転送する部分は既にできてるので検索かけると
他のノードのファイルがだーと出てくるところまでは動いてましたが、
そのファイルをダブルクリックするとMXのようにファイル本体の
転送が始まるようにしてるわけです。

んでここの転送部も昨日(今朝)組み終わりましたが
まだちゃんと動作しないんでデバッグ中です。
二つのマシン上のデバッガで通信内容を追跡中。

あと、レジューム機能はもちろん付けますんで、
それように準備はしてありますが、実装はまだです。
普通にファイル転送できないと意味ないし
この辺は今日のんびりやりましょう。

とりあえずバグ取れてファイル転送部ができれば、完成度50%ってところです。
あと残った作業は次の通り。

・検索部の接続形体がまだ静的なんで状況に応じて親子関係や接続を切り替わるように
・今だとファイルの持ち主と受け取り主が直接ファイルのやり取りしてるんでプロクシ機能の実装
・まだ暗号化を組み込んでないんでファイルと通信それぞれに暗号化(関連ルーチンは既にできてる)
・インターフェイスなどの細かいチューニング
・例外処理のチューニング(これが使い物になるかどうかに関して最重要)


45 名前:47 投稿日:02/04/06 14:58 ID:AKIOBPTK main/1017590243.html#559
個別に答えとく

>>477
できます。ないと使い物にならんので強力にします。
あと、キャッシュ内のファイルには元のファイルの大きさなど
含まれるので、尻切れかどうかわかります。というか、尻切れだとzipのように
Downloadフォルダに持っていけません。

>>479
容量制限についてはまだ考えてません。基本的には変な制限かけないで
ユーザーさん任せが良いのかと思ってます。

>>485
ファイルが壊れているのは検出しますけど、冗長な情報を入れて修復させることは
しないと思います。TCPしか使わないんで転送時のエラーはほぼ起きないはずですし、
それは他のソフトでやればいいかと。ただ、転送にはRC4で暗号かけるんで、
途中、1バイトでも化けると以降のすべての通信内容が壊れます。
もしできてからどうしても問題があるようでしたら、エラー検出だけでなく、
エラー補正も入れるようにしますよ。

>>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直叩きやってるんだからこの程度は出てくれないと。

さーて、基本的な部分はできつつありますけど細かい部分はこれからなんで
のんびり作りませう。特に通信周りはエラー処理がめんどうで、あわてて作って
バグ入ると取るの大変つーのを痛感(w


50 名前:47 投稿日:02/04/07 15:10 ID:PTiKNkGt main/1017590243.html#669
現在、システムの主幹部分となる通信中継部や検索部分をチューニング中。
ホスト間の通信部は既に完成(のはず)なんで、あとは比較的楽で
プロトコルのコマンド増やして動作を複雑にしていってるわけですが、
まれに怪しい動作するんでそのたびに何が起きてるのか
デバッガで追跡して悩んでるという状況です。

あとマルチランゲージ関連ですけど、基本的に日本語onlyで
英語版やリソース切り替えで対応はやらん予定です。

もし海外のリソースが欲しければ他に好きなだけ選択肢あるし、
日本人が欲しがる海外のリソースは、それと判断できる人が
他のシステムで拾ってきて日本語のファイルにして
こっちにUPしなおしたほうがいいだろうという判断です。

MXでも日本語以外のファイルあまりやり取りしなかったし
何が面倒ってドキュメント書きだったりするんで単なる手抜き(w
システムが安定して暇になったらやるかもしれないけど。

あとファイルのサイズは悩んだ結果4Gまでの制限となりました。
このシステムの場合、細かいファイルも超巨大なファイルも
自分でアーカイバで扱いやすい大きさに調節すること推奨です。

分割や圧縮などはシステム側ではまったく考えませんがこれは
ユーザー任せのほうが現実的だろうという判断です。
シンプルにできるところはシンプルにした方が
応用が利く使いやすいシステムになるはずですので。

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フォルダ内のファイルを管理し必要に応じて相互変換するファイルマネージャ
・ 検索やファイルの管理にハッシュ機能の追加(ダブったキーを検出して排除しないとだめなんで)
・ 大きいファイルや大量の転送に耐えられるように、各動作を平行して走らせるためのタスクマネージャ

こんなんですな。とりあえずこの辺も全部できたんで、レジュームや暗号変換部は簡単に作れるはず。
これで基本的なところは全てできたんで、

1. 検索かけると周辺ノードでヒットしたファイルが出てくる
2. 検索結果からファイル選んでダブルクリックすると、だーと転送が始まってキャッシュに落ちてくる。
3. キャッシュファイルをダブルクリックするとキャッシュが変換されてDownフォルダにファイルが落ちる。
4. UPフォルダ内のファイルをダブルクリックするとキャッシュ内にコンバート
   (これは予備動作で別にキャッシュ内になくてもUPフォルダから直接UP可能)。
5. UPフォルダやキャッシュフォルダの内のファイルは検索&ダウンの対象として処理される

と、まだ隣としかファイルの交換ができないのを除けばファイル転送ソフトとしての
基本的な部分は全てできました。これで半分は完成でしょうか。
後は分散システムの管理部分と、暗号やプロクシ動作などのセキュリティ絡みの部分、
細かいUI&性能チューニングですね。


53 名前:47 投稿日:02/04/08 03:57 ID:N2vA41p7 main/1017590243.html#748
今のところインターフェイス周りは必要最低限しかないです。
この辺は最後残り3割の内の実装内容になるでしょう。



54 名前:47 投稿日:02/04/08 03:58 ID:N2vA41p7 main/1017590243.html#749
まだタスクトレイに常駐できないし右メニューも無いし(w

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行ったら、
ここでその2スレ作ればいいと思います。本来MXの次に関して語るスレ
なのに占領してしまっていて申し訳ありませんけど。

別にIPとられてもかまわんし、2chと言えども警察にはIP出すでしょうから
どこでやっても同じでしょうし。

あと、あらしは困るといえば困りますが見てる人がいる証拠ということで
2chでは必要悪ということで、不必要に上げないという今の方針でいいと思います。


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
完成度は6割ってとこなんで、現状でどういうことになってるのか詳細をば。

まず今のバージョンでの基本モードは次の6つ。
「ホスト」「公開ファイル」「ファイル検索」「タスク状況」「設定」「ログ情報」

ホストは他のホスト情報で接続状況などが表示されます。現状では接続されている
IPとポート番号が直接表示されていますけど、後でID表示にするのではないかと。

「公開ファイル」はUPフォルダの指定で、最近複数指定可能です。
ここでMXと違うのは、フォルダ毎に「キャッシュ変換用暗号キー」
というのがテキストエディットコントロールで指示できること。

「ファイル検索」では、MX同様の検索キーワード以外に検索用の
暗号化ワードを指示します。暗号化ワードは、提供側と検索側で
完全一致させないとファイル名が崩れてファイル検索自体できません。
一応暗号化ワードの省略も可能です。



62 名前:47 投稿日:02/04/10 07:49 ID:TRw4MUOl main/1017590243.html#876
「タスク状況」はファイル転送やUPなどの各種タスク状況をまとめて
表示するもので、まだMXのようなバー表示にはなってないです。
現状ではそれぞれのタスクの進行状況に応じて数が上がっていくだけです。

ファイル検索からファイル選択してダブルクリックすると、
ダウンロード初めてここの画面に自動的に切り替わったりなど、
基本動作はMXと似てます。なお、まだキューの概念が無く、
要求は無条件で全部受けてしまいます。

「設定」は各種設定で、今だとキャッシュホルダ、ダウンホルダ、
待ち受けるポート番号と回線速度の設定があります。
ここはもちろんもっと増えます。そういえば各種のタイムアウト処理が
ついたからこれ用の設定もいりますねぇ。「ログ情報」はエラー表示などの
表示とバージョン情報などでバグ取りようのコンソールも兼ねてます。

こんなところでメニューも無くシンプルです。
上部に二列のボタンが並んでいて上がモード切り替えで
下列のボタンが各メニューのサブ動作(切断など)で、
下半分は多くのモードでリストコントロールってやつです。
エクスプローラで使われてるタブつきのやつですね。MXと同じです。


63 名前:47 投稿日:02/04/10 07:54 ID:DeIc0iOn main/1017590243.html#877
これだけだと動作が簡略化されたMXにすぎないので、違いの部分を説明。
まずMXと違うのがキャッシュフォルダという概念と暗号化の概念があること。

アップフォルダ、ダウンフォルダ、キャッシュフォルダがありこの間をファイルが行き来します。
既に書いたようにアップフォルダ毎に暗号化のキーワードを指定できます。

まず一番初めにファイルを公開するユーザさんは、アップフォルダに
公開したいファイルを置きます。暗号キーはこのときに指示します。

この状態で外部からファイル検索要求が来ると、必要に応じてファイル名に暗号化かけて
検索元に送ります。もし向こうが暗号のキーを知っていればファイル名を元に戻せます。
そしてこれの本体に対してダウン要求がかかると次の動作が起きます。

1.UP要求を受けた方では、UPフォルダ内のファイルに暗号化を施してキャッシュ
ファイル作成動作が行われます。もし既に作成済みならこの動作は省略されます。
キャッシュフォルダ内のファイルは名前も内容も暗号化されて意味不明です。

2.できたキャッシュファイルが要求側のキャッシュフォルダに転送されます。
ここで、1の動作は子の動作は平行して進行するので、ファイル要求側から見ると、
キャッシュを送っているのかUPフォルダ内のファイルをコンバートしながら
送っているのかは見分けが付きません。また、同一ファイルに対して
他のサーバーからのダウン動作と同時にUP動作が可能なので、
結果的に3ホストにまたがる転送動作となる場合もあります
(実際にはこうなることが多く、これで串動作にもなる)



64 名前:47 投稿日:02/04/10 07:54 ID:DeIc0iOn main/1017590243.html#878
最後

3.要求側のキャッシュフォルダ内にキャッシュ転送が終わると
自動的にキャッシュファイルの暗号を解いてDOWNフォルダに展開します。
検索側は暗号のキー知っているはずなので問題なく展開できます。
今だと名前の暗号化と本体の暗号化は同じキーなので検索できれば展開できます。

4.ファイルUP側とDOWN側には暗号化されたキャッシュが残りますが、
これはそのままで、次の要求が着たら暗号化の作業は省略してキャッシュがその
まま転送されて行きます。また、本体と別に暗号化されたファイル名情報だけ
ネット上に独立に流れていくので、これにダウン要求かけるとめぐりめぐって
キャッシュを持っている人のところにたどり着いた時点でそれが再送されます。
UPした人のところまでまたダウン要求が来ることはあまり無いはずです。

ちとわかり難いけどこういう動作になります。ファイルダウンすると、
UP側ではUP動作と同時に暗号化作業が行われ、DOWN側では
DOWN後に暗号化解凍作業が行われるのがMXとの違いとなります。

またキャッシュレベルで転送が行われるので外部から見ると
何が起こっているのかわかりにくいです。とりあえずここまでの動作は
既にできてて、並列にいろいろ動作してますね。
各転送作業や変換作業が同時に走るのが見ていて面白いっす。


65 名前:47 投稿日:02/04/10 08:09 ID:DeIc0iOn main/1017590243.html#880
>>858
>ルーター通してもWinnyが使えるように設計

一応考えてます。今だとUPとDOWNそれぞれにTCPポートを一つだけ
使います。ポートは任意なんで80番もいけます。接続時にリターン用の
ポート情報を送って、逆に接続し返すようになっているので、
自分のPCのポートはどれ使っても大丈夫になってます。
あと、基本的に垂れ流しでリターン必要ないプロトコルになってるんで
早いし片方向しかパケットが流れない状況でも動きますが、
いまのバージョンだとわけわかんない動作になりそうですねぇ。

66 名前:47 投稿日:02/04/10 16:14 ID:jGxK3m3o main/1017590243.html#886
>>884
>キャッシュに溜まるファイルは、
>
>1.自分でアップロードフォルダに突っ込み、
>  かつ、外部からダウンロード要求を受けたファイル
>2.外部に対してダウンロード要求を行ったファイル
>
>以上の2種類だけのように見うけられます。

その理解であってますが、「3. たまたま中継したファイル」というのも加わります。

このシステムではファイルのヘッダ情報とボディを分離して扱い、ヘッダ情報(キー)は
単独でシェアされて行きます。そして、外部的にはこのヘッダ情報を持っているだけで
ファイル本体を持っているとみなしダウンロード要求が可能です。

ファイルの存在を知っていれば、そのファイルを持っていることと同じなわけです。

もちろん本体を持っているとは限りませんので、要求がきて本体が無ければ
そのとき改めて本体をダウンしに行きます。これにより中継動作が発生し、
だれが実際にファイルを持っているのかを隠すわけです。

今はこの中継部の実装が半端で芋づる式にしか転送できませんが、
今後の実装はこの辺りが中心になるでしょう。

基本的に親方向にキー情報が流れていくため上流にいるほどキーが溜まって
検索の必要がなくなります。結果的に上流ノードほど検索ヒットを受けるので、
ファイル本体をキャッシュする率が高くなり、下流に行くほど検索&ダウン要求する
率が高くなることになります。上流にいるほどDOMりやすいですが、セキュリティ
的には下流にいるほど安全です。
回線の早いDOM屋さんを身代わりの中継サーバーに使うことになります。

また、

> 足が付かない様にするため、DLしてはキャッシュをクリアする、
> という輩が生まれ出すような気もします。

これはその通りで足を付かなくするには、誰かがキャッシュを持っていったら
すぐそのキャッシュを消すと確実です。完全に中継するだけの動作になります。

もちろんこれをやると転送分帯域が無駄ですし、みんながみんなこれをやってしまうとヘッダだけ
出回ってデータ本体が見つからないという状況になります。最終的にUPフォルダに
持っている人のところにダウン要求が集まってくるという状況になるでしょう。
遅いだけで、それはそれで問題ないです。最終的に誰がUPしているのかは隠せます。

このキャッシュクリアはまだ実装されていませんがもちろん標準でつける予定で
キャッシュフォルダの大きさを指定することで行われるでしょう。もしキャッシュ容量が0に
指定されてると、キャッシュができるそばから消されていくという動作になると思います。



67 名前:47 投稿日:02/04/10 19:53 ID:dUzHP7x5 main/1017590243.html#920
仕事を1日で片付けてあと5日趣味に使って1日休むという状況なんで
さすがに仕事が辛くなってきた(w明日締め切りの仕事を今から片付けなくては。

暗号についてですが、どういうルールにするかは使う方の成り行きに
任せるという方針で特に考えてません。スペック的には、暗号のキーとして
使えるのが半角128文字までで全角を使っても問題なしです。

一つの例ですが、ユーザーIDを暗号にすると、そのユーザーIDのファイルのみが
検索対象になります。

これは別に暗号を使わないでも、ファイル名の一部にユーザーID情報をつけるという手で
実現できますが、このやり方ですと無条件でユーザーIDがばれてしまうという問題があります。

暗号使った方式ならば、特定の人のサーバーから得られるというのではなく、
ネット上に散ったキー情報から結果的に情報が出てくるというのがポイントです。
試行錯誤的に検索してみないと欲しい情報が見つかりません。

あとファイル名暗号化の規則ですが、ファイルがキャッシュに入った時点で
キーを指定して暗号化、検索時は、ユーザが検索キーワードと暗号化キーを
セットで指定して、暗号化ファイルされた暗号ファイル名を複号化、
これに部分検索をかけることになります。

検索キーワードが空で暗号キーが指定されていれば、その暗号で複号可能な
ファイル全てが見つかり、暗号キーが空なら暗号化されません。なお、暗号化の
際には簡単なチェック機構が入っていますので、暗号キーがあってないと
そのファイルは見えなくなるようになってます。暗号に関しては部分検索という
概念がなく、一致するかしないかとなります。

秘密鍵による暗号化でしたら暗号キーを知らないとまったく意味不明になるので
いろいろ応用が利きます。通常と発想を逆にして、暗号キーをファイル名にするという
方法もありでしょう。これですとクリティカルなファイル名を知らないと検索にかかりません。
複雑なファイル名にするのと違い、一部検索に引っかかって見ず知らずの人に
発見される恐れはありません。

あと既に書いたように、フォルダ毎に暗号キーは指定できるようになっているので、
いろんな応用があると思います。一般公開向けのお約束なキーのファイル置き場から、
やばい一部向けの教えてもらわないと絶対わからないような
暗号キーのファイル置き場まで自動で作れます。


68 名前:47 投稿日:02/04/10 19:56 ID:dUzHP7x5 main/1017590243.html#924
>>896
> 中継した分は復号キーがわからず復号できない場合がありうるわけですね?

そうです。検索対象としては自分のキャッシュ内も対象になります。
キャッシュ内に何があるかは暗号キーを当ててみないとファイル名も内容も
わかりません。

暗号キーをどうやり取りするのかに関しては、このシステムでは関知しないということで、
どこぞのBBSなりIMなりに任せることになります。ファイルやり取りがキー情報の
やり取りにすげ変わるだけで、本システムはファイル共有に特化です。

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
ユーザーIDどうするかは実はまだ確定してません。暗号キーと連動というのは
設計当初は考えてなかったんでもう少し練って見ます。

あと前の方で既に指摘されている方がいましたが、
複雑な暗号化すると出所が逆に確定されるというのはその通りで、
このシステム側で出所が特定されないでも、そのキー情報を
書いたところで身分ばれて逆に個人の行いが特定されそうですね。

キー情報をどうするかは個人向けにメールするなり、IMで送るなり
BBSで公にするなりFreenetで共有する(wなり、
このシステムの暗号化システムをどうにか応用するなり
いろいろありうるのではないかと。



71 名前:47 投稿日:02/04/10 20:22 ID:dUzHP7x5 main/1017590243.html#936
せっかくどなたかが作ってくれたんで

MXの次はなんなんだ?2
ttp://tmp.2ch.net/test/read.cgi/download/1018434705/

これでいいんでは?荒れるようなら早めにつぶしてその3行きましょう。
適度に荒れてないとまじめな意見が書きにくいです。

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
よーし、仕事の方終わった。しかしそろそろ怒られそうな気もしてきたなぁ(w

>>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処理みたいな暗号でして、
二回処理すると元に戻る暗号です。

A → B (Cという鍵で暗号化)なら
B → A Cという鍵で複号化できます。



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
うー、むちゃくちゃ眠い・・・
これから打ち合わせなのに途中で意識失いそうだ(w

とりあえず、他P2Pプロジェクトの状況を見てると公開後に安定動作するのは奇跡みたいだし、
そういえばシミュレーターで動作検証しないとなーと思ってたのをzigumo見て
思い出したのでWinnyのP2P部動作シミュレータを実際に作って見ました。

こういうのを作らないで、暫定的なα版を試しに公開してしまって実際にどういう動きするのか
確認してから再設計しなおすというのもありですが、これやってるといつまでたっても設計が
固まらなくて無駄な実装に追われそうですし、公開直後に罵倒されてやる気がなくなりそうなんで(w
面倒でも動作検証シミュレーター作った方が、トータルで早く完成するだろうとの判断です。

まだ接続部のみのシミュレーターで検索やファイル転送時にどのぐらいの量の
データ転送が発生するかは調べられませんが、各ホストが連動するとどのように
動作するのかはこれで予備検証できます。実際に公開して動かないとか
動作重いと文句言われるのもあれなんで、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程度、これで子供のリンク数限界を5程度で接続シミュレーションすると、
光は上流の接続相手が光のみ、下流に光1に高速ADSL・ケーブルが4人程度、
高速ADSL・ケーブルは上流がほぼ光のみで、下流は高速ADSL・ケーブルが一人、低速ADSLやISDNが2、3人
低速ADSLやISDNは上流が高速ADSL・ケーブルで下流無しという状態で接続状況が直ぐに落ち着きます。
これは回線分布によるんでホスト数も関係なくこうなります。

今の接続シークエンスの設計は、基本的に検索開始は上流の光ノードから始まって
接続に余裕がなければ順に下流を紹介してもらうというものですが、
一つ下がると高速ADSL・ケーブル群になりここは人数が多いために
接続はあらかたここで終了します。

そして各自で切断・再接続を繰り返していると、光間の接続と高速ADSL・ケーブル群間の接続、
高速ADSL・ケーブル群と光間の接続、高速ADSL・ケーブルと低速ホスト間の接続と、
ホストも接続網も綺麗に4つのレイヤに分かれていきます。

低速ADSLやISDNはほぼフルスピードでダウン可能ですし、高速ADSLも8割のダウン、
光も8割のダウンと全体で非常に効率よくデータが流れていきます(それもキャッシュ無し条件で)。
キャッシュが入れば子の転送によるDOWN帯域の減少が必ず減りますし、
うまく設計すれば1対1基本しかできない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氏のシステムってアップロードしたら、誰にも削除権が無くなってしまうの?

今の設計ですと一度だれかがDOWNして出回ってしまうとそれを消せません。
人気がなければ勝手に消えますんでそれに任せることになります。

>>133
逆の申告(ISDNが光申請)すると高速回線側にぶら下がりやすくなりますが、
光ユーザーさんからすると貴重な待ちポートを一つ減らされたのと同じことになります。
上流にいる方のところは空きができると直ぐに他の高速回線の方が繋いでくる
(そしてもし低速回線なら子供を紹介して繋がないから)んで、
光の方は常に他の光の方を探している状況なんで迷惑といえば迷惑ですね。
申告を無条件で信じるか、ある程度の測定入れるかはまだ確定してないんですけど、
これのせいでやはり後者(回線速度推測はシステム側で行う)になりそうな気がしてます。

>>138
既に回線速度測定可能なように作ってあるんですけど、どうするかはシミュレーターで検証中ですね。

>>139
上下の帯域制御は今はできないです。上下の区別どころか帯域制御がまだ付いてないし。
基本的に帯域制御は自動になると思いますが・・・・

あとメールチェックもできなくなるのはネットワーク負荷というより、CPU消費しすぎだから
なんではないかという気がしています。前は複数のファイル転送(LAN上で)かけたら
マシンが固まったような挙動していましたが、通信負荷が上がってもCPUタイムを
取り過ぎないように調節したので効率よく動くようになってます。どちらにせよ、
何らかの帯域制御は入れるでしょう。

>>140
今は回線種別でなくて回線速度による申請になってます。将来的にどうなるのかは不明。

>>144
どこかに画像UP可能なところがあればシミュレータ画面とかαの画面上げてもいいですけど。

>>145
シミュレーションといっても、まだ接続のネゴとその際にどの程度のデータが流れるか
の検証しかできなくてファイル検索と転送の検証はこれからになります。
できたら検証してみます。

>>147
前書いたのはあくまで当初の設計でまだ実装してない部分なので、
検証してから実際にどうするかはこれからです。基本的に帯域制限無しでは
うまく動かないと思うので、何らかのメカニズムを入れるとは思いますし、
前に書いたとおり(UPとDOWN帯域が同じになるように調節が基本)
となるとは思いますが・・・・

>>157
暗号化無しの場合は管理責任が発生すると思います。
鍵無しなら転送時にもそれがなんなのか気が付きますので
見て見ぬふりはできないのではないかと。
暗号化されてればキャッシュ内に何があるかは転送中、気が付きようがないです。
基本的にキー無しはpublicのものという前提で特殊用途向けになるでしょうね。

>>159
できるだけ使えるレベルにもっていってから公開することにします。
とりあえずβ1まではいくと思いますんでそれで公開してある程度意味がありそうだ
となったら地道にVerUPしていくんではないですかね?

88 名前:47 投稿日:02/04/13 03:40 ID:dq5qZuyN main/1018434705.html#205
とりあえずシミュレータの方で分散環境下でのファイル検索部検証やってました。

ここんところの方式でいくつか案があったんですが、当初考えてた
一番シンプルなので問題なく動きそうなのでこれを採用決定。
(1万ノードレベルでも問題なく動くようだけど、ノードが極端に増えてくると検索失敗する
ファイルが出てきますなぁ、これはパフォーマンスとの兼ね合いで仕方ないかなぁ・・)

まー、ネットワーク分散で処理するのは接続処理部分とこの検索部分なので、面倒な
分散絡みの設計はこれで完成かなー。ファイル転送部分はFreenetと違って、キャッシュ
持っているホストに直接コネクションかけますんでそんな複雑なことにはなりませんし。

とりあえず隣との通信関連は既にプログラム出来上がってて、これを分散対応にするのは
簡単だし、設計が一番面倒な分散検索部分の詳細設計終わったんで、今回設計したところを
実装すれば7割方完成でしょうか。今は6割5部ってところです。

あとまだファイル転送部のところのシミュレーションはやってないんですけど、
ここは実際にプログラム仕上げちゃった方が早そうです。複数のマシンで
実際に動かして問題なく動けば、あとは怪しそうな部分だけシミュレーションで
検討しつつ、細かい部分仕上げれば出来上がりとなるでしょう。

分散環境でのファイル転送周りはまだ最後まで作ってない(レジュームもまだ)
んで例の帯域制限がどうなるかまだ確定してませんが、ここは次考えるということで。


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がぶら下がるという形態になります。

基本的に4層なんでNTT交換網に近い形になりますね。もちろん、協調動作の結果
こうなるという点で違いはありますが。

とりあえず、この結果を元にネットワーク接続部分の実装は終わりました。
ただ、PC数台ではテストのしようがないのでポート変えて一台のPCで
クライアントたくさん起動できるようにテスト実装中です。
次はネットワーク検索部分の実装やる予定です。

92 名前:47 投稿日:02/04/13 18:55 ID:9kOCetaX main/1018434705.html#260
ノートンちゃんと買ったよー。
MXで違法なことはしてません(と言っておく(w)

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
本職の方で残ってた作業があったので先ほど仕上げてました〜。
とりあえず終わった終わった(4時間しか仕事してねー(w

画面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
あー、よく寝た。昼頃から今まで寝てました(w

現状ですが、前の実装では1PC1クライアントが基本でポート変えても同じホストとみなされて
そのクライアント間でやり取りできなかったんですが、これはバグの一種だったので
直して1PCでWinnyプログラム複数起動とその間で接続できるようにしました。

これで数十クライアントの接続実験できるようになったので、テストコード入れて速度設定など
自動で変わるようにして、ちゃんとシミュレーター通りに動くことを確認しました。
接続部分はこれでノード増えても問題ないでしょう。実際に複数クライアントで動作することを
確認しないと怖いんで、あとでPC数台使って100ノード以上のテストもやってみましょう。

で、シミュレーターの方では完成していた分散検索部分も実装してWinnyの方に組み込みました。
検索クエリーがネットワーク上を渡り歩いて自分のところに戻ってくるのは確認してるのですが
検索結果が全部戻ってこないで見えないファイルが発生するバグで現在悩んでます。
今から直します。

とりあえず、やっと二つ以上先のノードのファイルが見えるようになりました。
バグ直してファイルダウン部分を修正すれば分散処理部分も完成になります。
これで完成度8割でしょうか。今だと7割ぐらいですね。


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(キー情報のみ)
続く

となっている場合、ダウン要求はノード3に対してかかり、ノード3がノード2のキャッシュを
ダウンしつつ、これをファイル要求してどこかの人に渡すという風にしようと思っているので、
ノード3の人が今度はキャッシュを持つことになります。

次に同じ要求するとノード4が3から転送するんで
こうして人気があるファイルはキャッシュが広まっていくはずであると。


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

> そうなると、よく流通するようなファイルを持っていて
> 上位ノードにいる人が、尚且つマイナーなファイルを
> 持っている場合などは当然検索ヒットしやすくなる&
> DLしやすくなると考えてよいのですね?

そうです。
(今必死にバグ取り中ですが(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
あー、やっと分散対応のファイル検索部分動くようになりました。
まだ大規模テストしてないけどシミュレーターと同じ動作だから
かなりのノード数でも絶えられるはず。

とりあえず、どこからも見える初期ノードが2こで各ノード接続可能なノード数が
上流下流とも3というそれなりにタイトな条件で20ノード近くが相互接続し、
それぞれが持ってるファイルがどのノードからも検索可能というところまではできました。

ただ、通信周りのプログラムが激烈に複雑化しててまたバグ出たときに
修復不可能だと思われるんで、もう少しシンプルに書き直す予定。

でも全部にタイムアウト処理と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
遠隔ノードからのダウンロード機能も実装できました。
これは、もし直接接続されていなければ、コネクション張りなおして後は
隣からのダウンと同じ動作になるので作るのは簡単でした。
これで遠隔ノードのファイルを検索してダウンするという
ファイル共有ソフトの必要最低限の部分は作れたことになります。

ただ、まだファイルを持っているノードに直接ファイルを取りにいって転送動作にならないし、
そもそも動作がいろいろと怪しいんで山のようなバグ取り作業が残っています。

とりあえずこれで基本部分は出来上がるので、あとは細かい機能の追加とチューニング作業となります。
テストまで入れるとまだ工程の半分というところだと思いますが、ここの部分を乗り切ったことで
完成する確立は50%以上となったでしょう。チューニング作業でどうやってもここがボトルネック
になるというような問題が出ない限りβまで到達できると思われます。

気長にお待ちください。



116 名前:47 投稿日:02/04/16 15:14 ID:mPL0z40j main/1018434705.html#552
ここんとこ深夜プログラミング漬けでねむー。

とりあえずこのソフトはFreenetがJavaで書かれてて嫌だけど基本的な考えは
面白いから参考にして自分で新しいの作っちゃえという1プログラマの暇つぶし企画です。
当分はネタとして楽しんでください。

出来上がるのにどうせまだ二週間はかかるんで、理想のファイル交換ソフトはこれだーと
いうのがありましたらここで討論しましょう。本来そのためのスレですし。

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
>つまり、キャッシュ用のディレクトリを指定しとくと、ヘッダ付の暗号化ファイルがどんどん
>そこに増えていくってことでしょうか?
そうです

> キャッシュしたい容量の上限てどうやって制限するんでしょうか?
まだ作ってませんが、設定でキャッシュフォルダの上限を指定しておいて、
これを超えたら古いファイルから消していくという動作になる予定です。

> てことは、クォータで管理?
クォータ使うのは自由ですがそれを仮定してるわけではないです

> 9x系OSは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フォルダ内からキャッシュフォルダへの変換が
始まった時点で、暗号化と同時に全体ハッシュを生成します。これをキャッシュヘッダに
付けておき、転送時、もしくはダウン時にハッシュを求めて、全体ハッシュと合うかどうか
調べ壊れているファイルを検出します。

この方式ですと、検索時では一部分を偽造したファイルをはじけませんが、
ダウン時には全体の1バイトでも変更するとそれを検出できます。

実はレジュームの実装が遅れているのはここらへんの設計の辛みなんですが、
ブロック単位でハッシュを求めて変な部分が出たらそこだけ切り離して他から
部分読みできるようにしようかと思ってます。ファイルはブロック化しないけど
ハッシュはブロック化するということです。


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ですが、クライアント10個程度の同時稼動でも
問題なく動いてますよ。

まー、まだ作っている最中なんでバグっていてパケットの無限ループが発生すると
がりがりとメモリ確保初めてマシンが固まったりしますけど(^^;これはバグなんで
公開版では発生しないはず。

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
> 「転送数が多くなったときの転送効率」が気になります。

これはそもそも1ノード内では同時転送数が多くならない方向で制御するかと思います。
ネットワーク上のノード全体の協力で帯域を使い切る方向性になるでしょう。

よって、相手が接続不能な場合、お互いに協力して他のノードを紹介しあうという動作になります。
既に現時点の実装で、接続の最適化のために周辺ノード状況を他のノードに伝達しています。

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
どうにかダウンロード部分の挙動がバグ取れて落ち着いてきたので、
ハッシュ周りを作り直しました。

あまり細かいことを書きだすと解析され易くなるだけなので詳細は省略しますが、
キャッシュ内部的には適当な大きさでブロックに分割してそれぞれにハッシュを持たせて、
ファイルのどこの1ビットでもエラーがあるとブロック単位でそれを検出できるようにしてあります。

ブロック単位でのエラー検出だけで、冗長な情報入れてエラー補正まではしませんが、
ブロック単位でエラー検出さえできればそこだけ再ダウンすればいいだけなので、
一部分だけ壊れていてもその部分だけ自動的に修復できます。

レジューム機能はこれからですが、システムの扱いとしてはレジュームというより
単に後ろ半分が壊れてるファイルを修復するだけとなります。

ハッシュ機構とはまた別にキャッシュファイル全個所暗号化されていますし、
通信時はそれにまた暗号化かかりますんですんごいことになってます。
そのわりにはそれほど速度も落ちないですんでますし。

実は、リソースロック絡みでデッドロック避けられなさそうなのと、効率悪そうって理由で
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を受けたキャッシュファイルの優先度が上がっていく)
になりますが、二つのマシンで地道にやり取りしていれば
ごみファイルでも優先度が上がっていきます。

実はこのようなモデルは2chではお馴染み。例のage, sageシステムと
同じだったりします。人気が無いつまらないファイルは優先順位が下がって
いって自動的に消えると言うわけです。ある程度の嵐にはこれだけで
耐えられますが、だからといって自作自演はありうるわけで、
単独犯ならキーで防げますが、複数犯による犯行だと防御が難しいです。

複数犯も結局は数で勝負で、2chでもまともな議論している人が大多数であれば
自動的に厨房は消える同様のメカニズムで防げますが、厨房ばかりになると板丸ごと
腐ってしまうのもお約束。なんでも自由と言うのはその制御が難しいです。

あと作者の法的責任に関しては、情報公開を要請されるとか公開停止程度の
勧告はありえますが、逮捕というのはまずありえないだろうと考えています。

それに別に商売でやるわけではないですし、ソフトだけでサーバー込みの
サービスではないのでフリーソフトとして公開して奇跡的にそれがうまく
動いてしまうと作者が止めようと思っても止められなくなる可能性もあります。
基本アイデアはここで公開してしまっているので、
私以外の人が実装でもいいわけですし。


138 名前:47 投稿日:02/04/19 14:02 ID:o6XsurCM main/1018434705.html#856
打ち合わせの多い今日この頃であった。

>>847
うう、話が良くわかんない(^^;

とりあえず、ハッシュ値指定で検索無しでの直接ダウン
(もちろんどこから落とすかはシステム任せですが)
というのはあったほうが良いかもしれません。

2chなんかでこんなファイル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の見直しなどの、
このスレで話に出ていたような細かい部分のみです。

プログラムソース的な完成度で言うと8割程度の完成度と思われますが、
基本部分はそろそろ完成なので、Winnyもついにαバージョンに突入です。

ネットワーク負荷がどうなるかなどのチェックがまだなんで、シミュレーターの方を強化して
大規模になるとどうなるか検証とか、処理負荷が上がってきてもトラブらないかとか、
回線速度が極端に速い場合と逆に回線が遅い場合に問題にならないかとか、
パフォーマンスは充分か、それぞれ最適にチューニングなど、やることはまだまだ
たくさんあります。勝手にキャッシュが消された、書き換わったとか、通信がカットされた
などの例外処理関連でも山のように怪しい部分があるでしょう。

あとユーザインターフェイス周りがほったらかしだったので、こちらも作りこまないとだめだし。

とりあえずチューニングとテスト段階に入ったんで全体工程の残り1/3ってところです。
一般公開可能なβ版があがるまではまだ1,2週間程度はかかると思いますので
気長にお待ちください。


144 名前:47 投稿日:02/04/22 00:07 ID:TqoqJECp main/1019230372.html#182
一部質問に答えてなかったので意味がありそうなものに答えます。
その3にはなさそうなんで全部前スレです。

>>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
> 自分で持ってるファイルがUPされる場合、一旦自身のキャッシュに
> (暗号化後)格納されてから出ていくと理解してますが、

その理解であってます

> 両方手元にあると暗号をクラックする側にとっては助かるのではないでしょうか?
楽ですが、私だったらキャッシュの直接解析は諦めてプログラムの方をデバッガで
追いかけて暗号化ルーチンだけ抜き出します。こっちのが絶対楽ですし、
暗号それ自身はそんな簡単に破られるものでもないです。

exeは必ず公開されるわけで、暗号・復号ルーチンが必ず含まれますし。
それを見越してこちらも対策取りますが、完全に防御するのは正直無理でしょうねぇ。

Windows以前のゲームで良くやったように自己書き換えまでやれば
かなり解析が面倒な嫌がらせになりますが、あまり凝るとバグの元や
パフォーマンス低下になるし、その前にバグを取りきらんと。

> あと、新しいPCを買ったとかいう際に、キャッシュコピーで優先度も
> 引継がれたりするのでしょうか?

引き継がれます。始めは認証ファイルでも作ってそちらに優先度など
入れようかと思いましたが、キャッシュがそれなりに暗号化されてるし
偽造が困難(キャッシュファイルの容量それ自身が不正コピー防止になる)んで
優先度はキャッシュからのみ決定することにしました。

だから、キャッシュを丸ごとコピーすればノードの優先度も引き継がれます。


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
> キャッシュに1G確保している状態で1Gのファイルにキューが来ると
> その前に溜めてきたキャッシュファイルが全て消失してしましませんか?

しますね。だから転送時のファイル最大値の設定がいると思います。

> あと確保しているキャッシュをオーバーしたファイルを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フォルダは10個までで
それぞれに暗号化のキーワードw指定。サブフォルダは無視って仕様ですけど、
この辺を作り変えるのは簡単です。
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
あとフォルダですが、今現在で、ダウンフォルダが一つに固定、
キャッシュフォルダも一つに固定、アップフォルダが10個までです。

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自体はもうできてます。
本体とここへのリンクだけだったりするんで簡単(w
HPは昔確保したところかどこかになると思いますが。

あと開発スケジュールですが、他の用事を全て無視して
こればっかりやっていれば今月中に上げられるかもしれませんが、
GWまではそういうわけにもいかんでしょうからβ1リリースは
来月でしょう。

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
つーことで、初期のネゴの所の認証をチェック厳しくして
問答無用で切断して無視するようにしときましたけど、
デバッガで追えば一発でばれるんだよなぁっと(w

173 名前:47 投稿日:02/04/25 14:56 ID:aCbyvOS8 main/1019230372.html#397
うー、ますます眠い。
職場の人たちは、やつは仕事そっちのけで
何やってるんだと思っていることであろう(w

とりあえず、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している最中です。1ブロック転送が終わるとそのブロック単位で評価が上がります。



178 名前:47 投稿日:02/04/26 16:09 ID:Zctv5nV6 main/1019230372.html#437
>>417
>この時に暗号キーも付加すると考えていいのかな?
そうですね。UPフォルダ単位で暗号化キーを設定します。

>>423
> DOWNが終わってない(未完成の)キャッシュファイルを他のPCへコピー
> した場合、コピー先ではDOWNを再開してくれるのでしょうか?
できます。そのために大きなファイルとしてではなく個別ファイルとして
キャッシュを作っているところもあります。キャッシュファイルそのものを
やり取りするというのもありだと思います。

あと、掲示板はやらんです。掲示板は他にお任せですしファイル共有ソフトと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
1対1で直でやると必ず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に近い)
なんでここはよく検証しないとまずし。

シミュレータを高速化して1万ノード超まで計算してみたので、
規模が増えてくると何が起こるかは把握できているつもりですが、
今使っている方式では規模が大きくなっても検索速度は落ちない
(シミュレーション結果でも10ノード以上遠くまでクエリが飛ぶことが無い)
代わりに、流通する全ファイルの数が問題になったり。

ヘッダだけとはいえ、さすがにネットワーク上にある全てのファイル情報が
一箇所に集まるとまずいから、上流ノードでキーが集まりすぎないように
新しいメカニズム入れないと。

あとファイルキャッシュの流通状況のシミュをやらんとまずいけど、
こちらは利用者の振る舞いにより挙動が正確にはじき出せないんで
今のシミュとは別に作って効率良い評価関数とか接続方式の検証します。
あとまだ実際のテストでは100ノード超えたことないから検証しないと。
一般公開は遠い・・・・

188 名前:47 投稿日:02/04/27 21:53 ID:T4lfczSI main/1019230372.html#540
sage忘れた・・・

BBSとの連動ですが、単なるファイル共有とP2PによるBBSでは技術的な難易度に
違いがあります。真面目にやるとBBSの方が作るの難しいです。

シンプルなファイル共有で良いのならバージョン管理の必要が無い
(内容書き換わったら同じ名前でも別ファイル扱いしてしまえばいいけど、
BBSではそうはいかず分散環境下でのバージョン管理と衝突回避が必須)

高度なファイル管理システム作ってその上にBBS作るというのは正攻法ですが、
それに耐えられる分散ファイル管理部を作るのは非常に難しいでしょう。
もちろん匿名化対策とかクラック対策しないでいいんなら作れそうですが・・・

そんなわけで私には片手間では作れそうにないし、
匿名BBSに関しては2chで困ってないんで関わる気はないです。
警察のお世話になるような書き込みしないし(w

ダウン時の帯域に関してですが、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氏の発言の(2)になってます。
ハッシュによる重複チェックにより、キャッシュ内のデータは無視されて、
UPフォルダ内のファイルを暗号化しながら相手に送られることになります。

選択されるキーの内部的な優先度が、前の実装では
仮想キー(他ノード) < UPフォルダ内 < キャッシュ内 だったのが
仮想キー(他ノード) < キャッシュ内 < UPフォルダ内 になったということです。

もちろん外部から見たらどこから転送しているのかは見分けがつきません。
一応、UPファイル→キャッシュへの変換機能はそのまま残っているので
前に書いたように、キャッシュに変換後にUPフォルダから消せば匿名性はより高くなります。

ただ、普通に使っていれば、UPフォルダ内とキャッシュでダブルことはありません。
DOWNフォルダに移動させるときにはもちろんキャッシュから消さないので
DOWNフォルダ内のファイルをそのままUPフォルダに持っていけばダブりますが
ハッシュによりこの場合は検出できます。

今だと検出だけで無駄なキャッシュを消してませんが、自動で消しちゃってもいいんでしょう。
壊れてるキャッシュは今でも自動的に消してますし、キャッシュファイルかそうでないかは
ヘッダでチェックしてるんでキャッシュフォルダに関係ないフォルダ指定しても
間違ってファイル消すこともないはずだし。

とりあえず前ので問題になったのは、凄く大きなファイルそれぞれに連続でQが入って
キャッシュ変換が連続で始まった場合で、前の実装ですとこれのせいでキャッシュ内容が
消えてしまうんでこうしました。今だと要求があったらファイル全体をまとめて変換ではなく、
ブロック単位で変換なわけですが、それなら直接変換したほうが早いという判断です。

優先度周りの実装が複雑になるんですが、こうでないと巨大なファイルが扱いにくくなるので仕方なし。


200 名前:47 投稿日:02/04/30 03:21 ID:NBgAq2LW main/1019230372.html#767
>>658
> 概算でどれぐらいのユーザー数でも大丈夫なんでしょうか?
今ですと同時使用は1万人程度程度で算出してます。

> 最大設定容量はHDDの容量になってしまうのですよね。(NT系は除く)
98系ですとキャッシュはそうなりますね。今だとUPフォルダは任意個数で
好きなだけ取れてキャッシュからは消すようになってるんで、
できるだけ発掘してUPフォルダに移すほうがいいでしょう。

>>660
> もしかしたら、ダウンロード完了ファイルのサイズでどのファイルかは
> 2ちゃんねるの報告を調べれば、分かりますか?
元のファイルの大きさは検索をヒットさせないと見れないし、
キャッシュと元のファイルは大きさが違うんで困難です。
それに同じファイルだとわかっても暗号とかないと中身見れないし。

> すいません、日本人以外にも使ってほしいので、英語表記の
> インストーラとインターフェイスをお願いします〜

いや



201 名前:47 投稿日:02/04/30 04:03 ID:kkSf5bWG main/1019230372.html#770
細かい実装も同時に進んでまして転送レートなども見れるようになりました。
(もっかの悩みは転送レートが思ったほど上がらないことだったり)

そういえば、前に話にでた初期ノードの暗号化対応作業も終わってます。
初期ノードファイル全体のバイナリ化ではなく、ファイル名の暗号化と
同じ方式なので、バイナリ化されていないノード名と混ぜて使えます。

なお、設定ファイルの方は常設ノードと可変ノードの二つに分かれていて、
可変ノード設定ファイルの方はそれまでの接続状況により自動的に書き換わります。

どちらの設定ファイルでも暗号化されたノードrefを使えますが、
暗号化されていても一行に1ノード書いた単なるテキスト(@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
よーし、とりあえず仕事終了(w

今日は職場に顔出さんとダメだけど
今週はWinnyの開発に時間消費してもどうにかなるかなぁ。

ただGW後半からは次の仕事しないとまずそうだ。

204 名前:47 投稿日:02/04/30 21:47 ID:ExHEmZC0 main/1019230372.html#834
とりあえずネムー。
顔色悪いぞと心配されつつも、職場でPCかき集めてテスト中。
といっても4台しか集められませんでしたが(w

1PC10ノード程度でやってますんでまだ40ノード程度の
のんびりしたネットワークですが、一応当初の予定通りの動作はしてます。

前のバージョンだとファイルダウンがタイミングによっては始まらないで
首を捻る事もありましたが、例の設計変更でここは安定しました。
検索部はもともと調子いいし、既にそれなりに使えます。

ただ、しつこく各ノードで全切断&再接続してると極まれにクラッシュするというバグが
残ってます。デバッガで見ても関係ないところで落ちてるんで、
どこぞでメモリの不正アクセスしとりますなぁ。そんなわけでのんびりと対処中。

あとは、巨大なファイルでのテストとか低速回線でのテストとかもしないとなぁ。


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はやめれ)と思ったのと、一月丸々かければ実際に作ってそれを
実証できそうだけど4月1日時点で暇だったというところですかね。

まぁ、そろそろ匿名性を実現できるファイル共有ソフトが出てきて現在の著作権に関する概念を
変えざるを得なくなるはず、あとは純粋に技術力の問題であって何れ誰かがその流れをブレイクさせる
だろうとは思ってたんで、だったら試しに自分でその流れを後押ししてみようってところでしょうか。

純粋に暇つぶしの腕試しです。

私なんてたいしたこと無くて、この程度作れる人は日本人でもかなりいるはずですが、実際に表に
ブツを出す人少ないんで、こういう方面でも日本人にがんばって欲しいというのもあります。


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
ちなみに本職はプログラマじゃなかったりするとか言ってみるテスト(w

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
> クライアントのメモリの持って行きかたはどんな感じですすんでますか??
上記の検索方式のためメモリ周りはちと心配していた部分でもあったんですが、
1万以上キーを保持していてもアプリが確保しているメモリ総量は10Mぐらいです。
そんなにメモリを馬鹿食いするアプリじゃないです。あとメモリ周りはメモリーリークが
怖いんでできるだけメモリアロケーションさせないで動的配列使う方針で組んであります。

ただ、ファイル転送が始まると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数台でも100ノードレベルのテストはできるから
良く実験してから出すことにします。


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
偽者が数名いるようですが、実害無いので問題ないかな〜。

今はβ1公開に向けて細かい部分の調節しています。メモリーリークのチェックとかGUI部の変更とかとか。

新機能追加してバグってもなんだし、あまり内部を隠すとトラぶったときに逆に理由がわからないので、
β1使用者はメカニズムを把握できている人だという前提で、タスクを隠さずにキュー機能無しで
内部が比較的見えるもの(つまりは今手元にあるもの)で、ヤバイ情報(接続相手の直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
再接続を繰り返しているとクラッシュすることがあるという
致命的な問題が残っていたんでデバッガで追っかけていたら、
メモリ確保周りで致命的な問題点があるのを見つけました。
情けないんで詳細は書かない・・・(w

今日一日かけて修正しましたのでどうにか直せましたが、
いつものように関係ない部分で影響出てなんか転送で
引っかかる挙動を起こすようになってるなぁ。
とりあえずまたチェックしますが、いつになったら終わるのやら。

そんなわけでGW中にβが上がるかどうか微妙なところでもありますが、
出るぞ出るぞ言って引っ張り続けてもなんなのでもうすぐだという証拠に
β1直前でのテスト画面出しときます。

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
今見ると転送リンクの上下方向表示が逆なような・・・まぁ見なかったことに(w
80ポートのキーヘッダは本体どこなんだとかヤバヤバ。

>>246
初期ノードですが、現状の仕様では初期接続に二つのファイルを用いまして、
固定ノードと可変ノード用にファイルが分かれてます。
それぞれ一行毎に1ノードのIPもしくはDNSアドレスとport番号を書きます。

固定ノードファイルの方は完全にユーザさん任せで起動時に読むだけですが、
可変ノードファイルの方はプログラム終了時に自動的に保存されて
最近の接続履歴で内容が置き換わります。

保存の形式ですが、プレーンと暗号化方式のどちらか選べまして、
固定も可変ファイルも読み込みに関しては両形式いけます
が、可変の方の自動保存は必ず暗号化されて記録されます。

暗号形式はバイナリファイルではなく、1ホスト毎に@675412faのような文字列ですので
テキストエディタで追加できます。あとここの前スレの要望に従いDNSもひけるようになってます。
(実はこの辺の並列処理でいろいろ面倒だったんですよー)

当分はここなどでDDNSかIP直に晒して接続実験になるんじゃないかということで
こういう仕様になってます。一応暗号化されてるんで、2chでテストサーバの
ip晒しても固定ノードでなければそんなに痛くもないのではないかと。

そんなわけでβ専用の機能としてホスト名暗号化の変換ダイアログがついてます。
ここはザルに作ってあるんでデバッガで追いかけてバイナリ数バイト書き換えるだけで
暗号解読可能だったりしますが、どうせ隠してもどこに接続に行っているかは
分かる人には一発で分かるので、初期実験用ですね。
最終的にどうなるかはテストの様子見て決めます。

あ、ちなみに全てのノードで他のノード紹介機能があって初期コネクション
時にネゴして接続は適当に割り振りられます。前の画面で接続切れているのに
ノードの速度情報をしっていたりするのはこの辺のネゴの結果です。
どのノードも上下4接続程度でそれ以上は受け付けません。

これでも、シミュレーション結果だと、固定ノードは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
とりあえず昨日のメモリ管理関連の変更で生じた不祥事は
どうにか直って普通に転送されるようになりました。また再テストしないと。

こんどは負荷かけても落ちないし、転送その他も問題なく動いてますが、
たまーに転送失敗することがありますねぇ。特に最後のブロック・・・
もう少し見直しますが、致命的だと公開が延びます。

当初の予定では致命的なバグはそろそろないだろうから細かい部分を
作りこもうと思ってましたが、結局GW前半はバグ取りについやしてしまったので、
β版というより、基本機能テスト用のαですね。

そんなわけで公開しないほうがいいかもしれないけど、無い機能は、
自動で再ダウンロードかけるなどの、基本部分がトラぶっていると
それを悪化させる機能ばかりなので、テスト版としては今のでいいかもしれず。
ファイル交換ソフトとしての基本的な部分はちゃんと動いています。

とりあえず突発的に近日中に公開する可能性あります。


226 名前:47 投稿日:02/05/04 22:53 ID:hD7cR1Vc main/1020264992.html#328
今のですと、ダウン対象の選択(どのノードから落としてどう転送させるか)は
完全に自動で、各ノードの接続状況やポートの空き具合によって決まりますが、
ダウンが失敗(相手の接続カットやタイムアウト)しても、新しい相手を見つけにいきません。

一度再検索かけるとまた最適化されますんで、対象ファイルをまたダブルクリックすることになります。
連続ダウンや自動ダウンができませんが、β1はこんなもんでどうでしょう。

ちなみに、

仮想ファイルをダブルクリック
→自ノードに転送して正常に転送できれば自動的にダウンフォルダに展開

キャッシュをダブルクリック
→キャッシュが完全であればダウンフォルダに展開
→キャッシュが不完全であれば残りの部分を自動的に他から落としてきて以下同様

UPファイルをダブルクリック
→キャッシュに変換(ただし、UPファイルはそのままで、キャッシュより優先なので変換した
だけでは意味ないです。手動でUPファイルを消すとキャッシュが見えるようになります)

このような操作系です。現状では起動すると勝手に接続に行きますので、
検索部で検索して見つかったファイルをダブルクリックするだけという
シンプルなインターフェイスです。あとUPフォルダ指定するぐらい。

227 名前:47 投稿日:02/05/04 23:01 ID:hD7cR1Vc main/1020264992.html#333
えーと、ネットワークを壊す機能ですが、
正式版が上がるまではβ毎にプロトコルヘッダが変わると思うんで、
違うバージョン毎に独立したネットワークになります。
そもそも繋がりません。なので自動的に人がいなくなって消えるのではないかと。

>>268
>eDonkeyみたいにバーの色でファイルの各部位の進行状況を見れるようにはなってないんですね
なってまして、正常に読み込めたブロック別に色分けされますが、
あの画面キャプチャした時点ではダウン時の画面再書き換えしないバグが(w
今では直ってます。

> ed2k://〜の様に直接ファイルにリンクを貼れるような機能
これは後回しですね。直接ハッシュからファイルをダウンしに行く機能も
まだだし、思ったより基本部分のバグ取りに手間取っていてここで出たような
周辺の実装をしている余裕がなかったりします。





228 名前:47 投稿日:02/05/04 23:09 ID:hD7cR1Vc main/1020264992.html#340
>>335
今試しにアーカイブ作ってみたら170Kbyteでした。
exeと必要最低限の設定ファイルだけでヘルプ一切無しとなると思います。
即効でデリられる可能性もあるんで一応公開場所は二箇所確保してありますが、
転載は自由ですのでMXなりFreenetでなり適当にしてください。


229 名前:47 投稿日:02/05/04 23:12 ID:hD7cR1Vc main/1020264992.html#341
どちらにせよ、連休中職場に忍び込んで複数台PCでのんびりテストする
予定(家にはPCが二つ+ノートが一つしかない)ので公開は早くても月曜です。


230 名前:47 投稿日:02/05/05 16:28 ID:vcRbUCGh main/1020264992.html#425
とりあえずLANでのテストではほぼ問題なく動くようになりました。
ファイルをプチプチダブルクリックしていくとどんどんコピーされていくので
全ノードで直ぐに全て同じキャッシュ内容になります。

昨日の時点で動作が変だったのは、昔のシーケンシャルにファイル
読み込んでたときのコードが残っていて悪さしていたからのようです。
この辺を整理したのでプログラムがかなりシンプルになりました。

ただ、しーつこくファイルの転送を繰り返していると、
ファイルがロックされたまま(OS側でのロックではなく、作業中にキーが
どこかに行ってしまうとまずいんで行っている自前でのロック機構)
になって、プログラムを再起動しないとそのファイルが操作不能になるという
バグが残ってます。これは致命的ではないですが、たまに再起動する必要が
あるのは辛いのでまた見直します。単にどこかでのロック、アンロックし忘れでしょう。

あと、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
βとなってますけど、実質α1ですのでよろしく。
昨日の時点でできてたんですけど、DebugじゃなくてReleaseにすると
変な動作する部分があって悩んでました。そんな感じでテスト不足かもしれない。
WANで動くかどうかはともかく、現状のバージョンではポート変えれば
一つのPCで複数のクライアントが動かせるのでどういう挙動するのかテストしてみてください。

233 名前:47 投稿日:02/05/06 15:54 ID:9nmsmZMp main/1020264992.html#673
ちなみに初期ノードが無いんで、WANで接続テストするにはだれかがポート
さらさんとだめです。

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
接続はどうにかなるようなので
誰か少しだけファイルをUPしてここで教えてください


238 名前:47 投稿日:02/05/06 16:15 ID:9nmsmZMp main/1020264992.html#732
あとプライベートIPな人(頭が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
うーん、特定の部分でとまるのはブロック単位で転送してるからだと思います。
LANとWANではレイテンシ違うんで何か見落としていた問題でもあるのかもしれない。

とりあえず、UPフォルダにあるよりキャッシュ内のほうが安定しているんで、
UPフォルダ内のファイルは自分で検索してダブルクリックしてキャッシュにしたあとに
UP公開止めたほうがいいかもしれない。

243 名前:47 投稿日:02/05/06 16:50 ID:9nmsmZMp main/1020264992.html#869
えーとですね。まだチェックし切れなかった部分があったようなので手動での
対処ですが、回線申告をわざと低めにすれば負荷は下がるはずです。
その代わりファイルが見つかりにくくなるので、何も出てこないという方は
少し上げてみると良いのではないかと。

んで、PCが耐えられないとバッファがあふれます。

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
先頭ブロックだけ読み込めてその後データが来ないのは次のようなことだと思います。

まず、転送先のホストに接続に行きますが、これは検索リンクを追いかけていけば
見つかる、今現在生きている可能性が高いホストなので大体繋がります。

次、このホストが本体を落としに行きますが、既に落ちてたり、UPフォルダから
消したなどの理由で繋がらないとまずそのままタイムアウトします。

もしこの転送依頼されたホストがやっとデータもらえたとしても、あまり手間取っていると
そのころには依頼したほうがタイムアウトなりなんなりで切断となります。

転送の二番目のフェーズ(転送ノードがデータを落とせなかった)で失敗すると
先頭ブロックだけ来たように見えるということだと思います。
ほとんの場合、中身は空でしょう。

キャッシュが十分広まっていけば多少落とせるようにはなると思いますけど。

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
バージョンが古いうんぬんは時間見てるだけなんで
2000年問題じゃないですかね?OSなんでしょう


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
さすがにレジュームは実装済みです。
ただ、ダウンが失敗しやすい(バグというよりネットワーク上のキャッシュがほぼ0だから)
から低確率x低確率でほとんど無理なだけだと思う。


253 名前:47 投稿日:02/05/06 19:37 ID:atzJUrlH main/1020673454.html#343
なんとなくですが、せっかくユーザーさんが申請したのに、それとは違うポートに接続に
いっているためにダウンが失敗する率が高いということであってますか?

FW無くてポート晒していて、DNS設定を入れてない人のところにしか
繋がってないのかもしれない。

254 名前:47 投稿日:02/05/06 19:48 ID:atzJUrlH main/1020673454.html#380
あー、バグってる理由が分かりました。
いつもLANでテストしてるんで気が付かなかったけど、
ホスト名んところの解釈がバグってると思います。

なのでGW越えの人はファイル転送のダウンを受け付けられてないんだと思います。
検索側は自分で接続にいくんで問題ないということでしょう。

修正しますのでしばらくお待ちを。ホスト名のところは設定しないで使ってください。
ダウンだけなら問題なくできると思います。

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
あとノードリストの切断ですけど、それは検索用のリンクなんで、2、3個
なのが正解です。4を超えても自分で切りに行きます。今ですとUPリンクが
2を超えたら接続動作はしなくなります。

ファイルダウンの時は別にコネクションにいくので接続数が少なくても
問題ないです。

257 名前:47 投稿日:02/05/06 19:57 ID:atzJUrlH main/1020673454.html#401
>>399
切断ノードの削除は10分ぐらいになってたと思うけどもっと早いほうがいいかも

258 名前:47 投稿日:02/05/06 20:33 ID:RHIpJpsI main/1020673454.html#481
うーん、基本的に今のでも繋がるはずだなぁ。
とりあえず表記が悪くてすいませんが、設定のホスト名のところはDDNS使ってる
人以外は設定する必要ないです。書いてあると、再接続の時に繋がりやすく
なるだけです。

とりあえず今ここのところに何か書いてある人は消して再起動しといてください。
あともちろん、ルータ使っている人はポート80にアクセスするとWinnyが動いている
PCに繋がる必要があります。この辺は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使っていると、検索リンクで二つ以上離れているノード間は
どう設定してもそのDOWN接続を受けられません。隣からは落とせますので、
極まれに落とせるのはそういう事情のようです。

そんなわけで、今現在はNAT使っている(ルータ使っている人は全員)
外部からの接続不可能ボタンを押しといてください。
とりあえずルータ内の人のファイルでも吸い出されていくはずです。

262 名前:47 投稿日:02/05/06 22:39 ID:mZAKE17s main/1020673454.html#812
β2上げました。
ttp://www.geocities.co.jp/SiliconValley/2949/

変更部ですが、致命的なものと直すのが簡単な部分です。

致命的なものとして、WANとLANでアドレスが違う場合に、
WANのアドレスとすてLANのアドレスを渡しているという致命的な問題がありましたので、
NATもどきの機能をWinny側にも入れて、接続時と申請されたIPで違っている場合、
自動的に内部でIPを変換するようにしました。

なお、プロトコルが変わったのでβ1との互換がありません。設定ファイルはそのまま
使えますのでexeを取り替えるだけですが、β2とβ1では接続不可能です。

あと細かいところとして、接続不能なホストが消えるのを少し早くしたのと、
検索で見れる結果数を少なくしました。本来は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はプロトコルの違うバージョン間で出るメッセージです
実害無いので皆がβ2に移行するまで待ちましょう。

ところでβ1よりβ2のがファイル落ちますか?ルータ入れてる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
β3です。
例のポート番号の上下がひっくり返っているとの報告でしたので直しました。

acceptとconnect両方ひっくり返ってたのでうまく動いてるように見えていただけのようで。

今回はプロトコルが変わっていませんのでβ2とは繋がりますが、
ダウン率を上げるために皆さん変更お願いします。

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
>47様
動作報告
フレ1.5Mbps
K6-2 500MHz
memory 64MB
ルータはずし、火壁OFF
で50MB 転送できた ポト80でwebもOK
じゃ寝ます


275 名前:47 投稿日:02/05/07 02:10 ID:TflXya6r main/1020694396.html#476
とりあえずの問題点は重過ぎることらしい(特に上流)ということで、
対策とっておきました。プロトコルはβ2,3と同じです。

あまりキーの転送をしないようになってますけど、
今度はキーが見つからない病気がでる可能性があります。
とりあえずどちらの方がいいかということでβ4は比較版です。

あと、中身が空のキャッシュは起動時やリフレッシュ時に自動的に消すように
しときました。


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
β4で軽くなるのは検索リンクで一つ上の人なんで、
自分の下流の人が前のバージョンだとやはり重いはず。
プロトコルが共通なんで周りの人がどちらだか
分かりにくいと思いますが適当にテストしてみてください。

278 名前:47 投稿日:02/05/07 13:08 ID:RrbR/4SR main/1020694396.html#940
職場からです。連休篭ってずっとプログラミングしてたんで眠い。

とりあえず今週からは忙しいので、こればかり相手にしてられませんが、
皆さんのおかげでWANでの挙動が把握できたので順次対応していきます。
最悪、接続や検索部でトラぶって何も見えない可能性も高いと思ってたので
こちらとしては50点です。
低確率でもファイルダウンさえ可能ならこの後のテストができます。

できれば本当はもっと小さな規模でテストしたかったんですが、
いきなり本テストになってしまった感じでキー処理の負荷が予想以上に凄いです。
何もしていないのに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で起動してテストできる方がいらっしゃいましたら、
そちらでローカルで変な動作をする理由を探っていただけると助かります。

キャッシュ周りはどうも一つずつ消していくというバグがあるみたいですね。

あと、β4はあまりに動作が重いのでそれに対応してキー転送を
あまり行わないバージョンですので、ローカルでテストするのならβ3がお勧めです。
WANテストでも負荷が高くならなければβ3の方が動作が確実だと思います。

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に要求する、という事ですね。

あまりばらすのも何ですが、現状の検索と接続相手を決定するメカニズムは

1.ノードが検索リンクで接続するとUPフォルダやキャッシュ内のキーが上流ノードに流れる
2.下流から来たキーでもし手持ちに内容の同じUPファイルやキャッシュがあったら上書き
3.そのまま上流にキーが流れていってループにぶつかったら終了
4.下流からファイル検索要求があったらそちらに該当するキーを流す
5.検索結果が下流に流れていく間に同じ内容のキャッシュを持っていたら上書き
6.検索相手に到達

こうなりますので、中継を起こす相手は、UPする側とDOWNする側を
検索リンクで上流に遡っていってぶつかったところになります。
DOWN側がUP側のキーを発見するのがこのクロスポイントで、
中継ノードでそのキーのIPはUP側のIP、
ダウン側からそのキーのIPを見ると、中継ノードのIPとなっています。

この状態でダウン側のノードがダウン要求を出すと、ダウンフォルダ内の
キーのIPを見て中継ノードに到達し、中継ノードは要求のあったファイルが
仮想ファイルであるので、これにダウン要求をかけUPノードにダウン接続をかけます。
あとは、転送ノードにデータがくるたびにダウンノードにファイル受信パケットを転送してきます。



283 名前:47 投稿日:02/05/08 02:17 ID:RKRBWjxb main/1020745832.html#499
そろそろ眠いんでβ5です。以下修正点。
なお、プロトコルがまた新しくなったので前のとは繋がりません。

・キー転送量の削減と切断されたホストのキーを殺すことによるキーヒット率向上
・表示でのチラツキを抑えた
・Port0で検索に失敗するのを修正
・負荷が重い状態のときに終了すると飛ぶのを修正
・ダウン開始時に128kだけ落とせたように見えるのを修正
・ダウン中にダウン率が後退しているように見えるのを修正
・キャッシュサイズを表示。あとロックされているキャッシュは無視。
・切断して時間の経過したノードを隠すようにした
・転送率メーターの変化率を落とした
・キャッシュの容量の計算ミス(破損キャッシュの残りの部分も入っていた)を修正


284 名前:47 投稿日:02/05/08 02:44 ID:RKRBWjxb main/1020745832.html#531
β3までは無駄なキー情報まで送っていたのでファイル転送量が多すぎてトラぶっていましたし

β4は逆でしたが、β5では本体が無くなったキーを検出して落とせないキーを極力
消えるようにして、あと無駄なキーの転送を極力抑えてます。

ノードが増えてくるとまた重いかもしれませんが、キーの転送量はまだまだ減らせますので
様子見てやります。ゴミキーが消えやすいことで結果的にヒット率が
上がってくれるとうれしいですね。


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の次はなんなんだ?バグ報告専用β1」
とかいうスレッドをたててそこに集中させるか、
ttp://node.s12.xrea.com/bbs/treebbs.cgi
こことかしませんか?
ほんとはこのスレッドがバグ報告スレッドのはずなんですが、
雑談や質問なんかにまみれて
バグ報告だけを見つけるのは大変だと思います。
(実際100件に2,3件しかバグ報告ないし)
前にあっちこっちにスレッドとかページ作んのは
やめてくれとかいう人がいましたが
そうゆう人はバグ報告なんかほとんど見る
必要はないんだから、問題ないのでわ?
(というかバグを把握する47氏の視点にたってないし)
ここにバグ報告があったとしても、気づいた人がバグ報告用のスレッドにコピペしたら
もっと分かりやすくなると思います。
こんな提案どうでしょう?

>>833
ほしい

287 名前:47 投稿日:02/05/08 23:15 ID:OZr+AG2q main/1020852482.html#101
β6です。プロトコルは実はβ5と同じなのですが、一緒に使うと
とんでもない転送量が発生する可能性があるので繋がらないようになってます。
ちなみに、まだキャッシュ消去周りの挙動は直してないのでβ5.1と同じです。

修正は以下

・設定関連のインターフェイスを変更
・システム情報表示を追加
・ダウン対象決定の際にキーの消去タイマーを考慮することでダウンヒット率向上
・ダウンできない無効キーの消える率を向上
・キーリスト送信を抑えてキー転送量を削減
・プロトコルヘッダチェックでコネクション毎のチェックになっていなかったのを修正
・各バッファのメモリ確保を高速化
・接続ボタンのステート表示を逆にした
・UPフォルダスキャン中にリフレッシュすると落ちるバグを修正
・フォルダ追加でパスが空だと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はヒット率上げるために念のため入れておいた一行が悪さして
無限クエリを作ることがあるようです。すいません危険ですので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
なぜかポート番号とキャッシュ関連の容量とダウンフォルダ位置の設定が飛ぶようです。
これらの値は起動時にしか書き換えないんでどこか不正アクセスですな。
変なところにアクセスに行くのはこれのせいか・・・

とりあえず原因を探りますが、この現象が出たらプログラム再起動しかないです。

あと、何か上流側で検索を当てない限り上方のキーは0です。
昔は検索にかからないのも転送してたんで重かったんですが、
β6では無駄なものは一切転送しないようになってます。


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
ここのところ暇が無くて2chは見てなかったので気が付きませんでした。
チェックしてみます。

295 名前:47 投稿日:02/05/09 01:27 ID:U9fy9lkd main/1020852482.html#316
上流ノードだと、上流からきても下方キーになる可能性もあります。
そこだけ見ていてもどこからキーが来たのかわかんないです。
検索のときに消しても良いかどうかの判断なんで私以外に意味わかんないと思うし。
どちらにせよそのうちそこは上下足しちゃうか消すと思う。

しかし家の環境ではIP先頭が1になる現象がみれん。うーん・・・

296 名前:47 投稿日:02/05/09 01:49 ID:U9fy9lkd main/1020852482.html#345
うーん、思った通り今度はダウンはできるけど見えないという問題がでますか。
そのために入れた対処のせいでβ6みたいなことになったし、
面倒だけどクエリパケットもう一種類作んないとだめですねぇ。
これの対処は面倒なんで少しお待ちを。


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絡みは、どう設定したらいいか作者も把握できてませんが、
これ絡みでやっていることを書くと次のようになってます。

1.まず、適当なノードに検索リンクでコネクションに行きます。
この時に使うIPとポートはNoderefに書いてある例の暗号です。

2.検索リンクで接続すると、接続された方は相手のグローバルIPが分かりますので、
これをノードのグローバルIPとして記録しておきます。
この時点で接続してきた相手のポート情報は分かりません
(表示の上では0になってます)

3.検索リンク間でお互いのノード情報を交換します。
交換する情報は、回線速度と接続に用いるポート番号と例のDDNS情報と
自己申告のIPアドレスです。これは接続してきたノードが自分のノードの
IPを取得した値(つまりローカルIP)です。
あと、外部からの接続か可能かどうかもここで申告します。

4.もし相手の申告してきたIPとAccept時に取得したIPが違っていたら
そのノードはNAT経由とみなしてNAT野郎フラグ付けときます。

5.もし他のノードから他のノード情報を要求された場合、DDNS名が空でないノードなら
DDNS名とポート番号を知らせます。ネゴの結果、DDNS名が空のノード情報の場合、
グローバルIPとポート番号を知らせます。

6.他のノードとキーのやり取りをする場合ですが、キーには本体の位置がIPとポートの
形式で書いてあります。ここで、もしNATフラグがついているノードから来たキーの場合、
そこに書いてあるIPと相手が申告してきた自分のIPとを比較します。
もし同じならそれはキャッシュかUPファイルなわけですが、それはローカルIPなんで
グローバルIPに書き換えます。逆に、もしそのノードにキーを渡す必要が出て、
そのキーが相手のグローバルIPなら相手のローカルに変えて渡します。

あと、もしキーを送ってきたノードがPort0申告しているノードだったら、そこから来たキーの
IPは全て自分のノードのIPに書き換えて他に送ります
(変換は渡すときだけ、手持ちのキーのIPはPort0申請ノードのまま、そうでないと転送動作にならない)。
これにより、Port0への転送リンク接続はかからず、自分のノードのところに来るようになります。
port0設定で動作が変わるのはここだけです。

6.キーに対してダウン要求がかかったら、キーに書いてあるIPとポート番号のノードに
転送コネクションをかけます。これは常にグローバルIPです。ただし、本体が
そこにあるかどうかは分かりません(違ってたら向こうのノードで同じことが起きて転送になる)

相手がルータ越しの場合、検索リンクで繋がっているノードから見たIPアドレス+
ファイル本体を持っているノードが申告したポートのところに繋がることになります。

もしPort0申告していたら、隣のノードが身代わりしてくれてるはずなんで
そちらに繋がります。

7.ここまででDDNS名はまったく使っていませんが、もしこれを受け取っていたら、
終了時にNoderefTemp.txtファイルにIPの代わりにこれを書いときます。
次に検索コネクションをかけるときに、もしDDNS名が空でなければgethostbyname(相当)
のAPIでIPを調べて、そこに接続にいくことになります。

以上、こんな感じになってますので、どう動作するかは各自の判断でお願いします。



299 名前:47 投稿日:02/05/09 02:42 ID:U9fy9lkd main/1020852482.html#393
修正

6の
> もし同じならそれはキャッシュかUPファイルなわけですが

これ間違いました。キーのIPと相手のIPが同じでも中身が仮想キーの可能性があります。
相手の下流にPort0野郎がいてもそうなりますし、相手のノードが比較的
UP側に空きがあって転送動作してもいいよというときにも同じになります。

300 名前:47 投稿日:02/05/09 02:49 ID:U9fy9lkd main/1020852482.html#397
なんでDDNSにグローバルIP書くとファイルが
落ちやすくなるのか良く分からなかったりする作者であった(w

301 名前:47 投稿日:02/05/09 03:11 ID:U9fy9lkd main/1020852482.html#423
上流にいるほうがダウンに成功しやすいはず
(下流のノード間ほど転送動作が発生しやすい)だけど
現状では上流ではクラッシュもしやすいという諸刃の険・・・

えーかげん怪しい部分を直さないとキャッシュ広まらなくて
その真価が見えてこないですねぇ。

検索ヒット率もダウン速度も全てキャッシュヒット率にかかっていて、
前に書いたようにキャッシュさえ十分に広まればパフォーマンス的に
MXを超えることも可能なはず(MXでは相手が選べないけど
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
一度も転送されたことが無い人は単に外部から申請したポートにコネクションできなくて
周りに迷惑かけているだけの可能性が高いです。試しに外部からの接続OFF入れてみて
ください。このオプションはUP動作が変わるだけでダウンは変わりません。

あと表示ですが、

DDNS:設定で名前指定してあるノード
NAT:ローカルとグローバルでIPが違うノード
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
簡単に言えば、現状で重くなる理由は単に出回っているファイルが多すぎるという
その一点だけなので、これを制限すればもっと軽くなるはずです。
何も考えずにMXのフォルダを指定している人は制限していただけると助かります。


314 名前:47 投稿日:02/05/10 03:38 ID:xIt6XkCC main/1020956839.html#330
キーの管理は実はMXと似た方式になってるんではないかと思ってます。
鯖と親と子があって親が子の面倒見てファイル名をストックしてこれを鯖が
管理しますけど(一部推測)、Winnyでは、似たようなレイヤが結果的に
出来上がるだけで基本的には同じです。

大規模になると、上下階層の深さはそのままで、横方向に大きくなっていきます。
問題点は、遠くのファイル(上層ノードが異なるノードのファイル)が
見つかりにくくなっていくことです。

だから大規模になってもどうにかなるとは思いますが、
今ですと高速回線申請すると多くのノードがキーを送りつけてきて
メモリがあふれてしまいます。早い回線=メモリ豊富とは
限らないので、上層ヘビーではなく、中層ヘビーに調節しないと
だめなんだろうなぁと。

315 名前:47 投稿日:02/05/10 04:11 ID:SVtHh5Na main/1020956839.html#345
寝ないとまずいけど今日の午前中寝てたんであんまり眠くない(w
>>333

キーの管理だけどβそれぞれでいろいろでしてどれがいいか探っているところです。

細かいところ忘れちゃってるけど、β1は333氏が書いてるのに近かったはず。
下流に流れていく間に同じものがあったら上書きされていきますけど、
それは途中のノードでは展開しません。クエリ出したノードまで全部行きます。
ここはβ全部で同じかな。

今のβ7はβ1に戻ってきている部分があって、違うのはキーに寿命があって
時間が立つと消えることと、消える時間に合わせて下から上にキーを全部
送っていることです。これのせいで重い。あと、転送先の決定がかなり
複雑になってます。キーの寿命見て新しいほど本体にあたる率が高いということで
そちらを優先します。

確か、β1や2ではキーに寿命が無くてノード切断に合わせてキーが
消えることを期待したけど、結局キーがたらい回しされて消えないで、
本体の位置をロストしてファイルは見えるけどさっぱり落とせない状況に。

β3や4辺りではキー寿命が入ったせいで本体ロスト率が減ったけど、
キーが消えていくんでいちいち送り直す必要があって遅いし、
結局本体はロストするんで重くなっただけ。

β5あたりでキー寿命考慮して選択対象選ぶようにしたんで
落とせるようになってきて、β6.1で検索を下にも飛ばして、
キーを単純に上に流すのをやめることで、負荷を下げて、
キーと本体の距離を短めにしてダウン率を向上。

でもこれやると見えないファイルが出るんで、
β5(キー寿命考慮しての検索)とβ6(ダウン率向上)を合わせて
いいところどりできないかと試してみたのがβ7だったりします。

こんどは中層ヘビー(三階層を考慮してキーは中層に集めて上から支持する)
にしてみようかと思ってたりしますけど、完全に試行錯誤ですねぇ。


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
キー数が予想より多くて、単純な階層構造のネットワークでは
キーの保持だけで上流側のPCがあふれてしまうみたいなんで、
当初の設計である、

上層→キーの保持、中層→キャッシュ保持、下層→ファイル提供

ではなく、

上層→コネクションの受け付けと中層への接続割り振り
中層→キーの分散保持とキャッシュ保持
下層→ファイルとキャッシュ提供

の方向性に持っていこうかと思ってきました。

既に上流の方ではメモリぎりぎりでキーを受け持ってる状態なんで、
下層のファイルをMXと同じで1000個程度限界と仮定し、
中層ノードにこれらを10程度ぶら下げて担当下層ノードのキーを全て
持たせる(キー数1万ぐらい)で、各所から出てくるクエリは
中層ノード網でクエリを一周させて結果を下流に流す。

上層はアドレスが変わりにくいだろうということで、
キーの相手は一切しないで中層ノードの管理に徹してもらって、
コネクションを裁いてもらうのが良いのではないかと。
MXみたいですけど、役割が動的に決まるんで
グヌテラとナプを混ぜたみたいになりますね。

ここまでできてればプログラム的には結構簡単に対応できます
んでキー管理周りはそういう方向性に持っていこうかと思います。


318 名前:47 投稿日:02/05/10 13:44 ID:yzBDBm21 main/1020956839.html#389
キー管理をどういう方針に持っていくかでつらつら考えていたんですが、
図にしてみるとこんな感じになります。

ttp://www.geocities.co.jp/SiliconValley/2949/Key.gif

当初の予定では高速回線の人を上に持ってきてキー管理を集中させようと思ってましたけど、
上流ほどキーが集中するんでメモリ消費とCPU負荷が凄くなって、皆が上流を避ける。
この状況で遠くのファイルも見えるようにキーを垂れ流すと全ノードが重い(β7)

キーを遠方ノードに広めようとしなければ比較的軽くなりますが、
やり取りがローカルな部分に制約されてしまい落とせるファイルが
たまたま隣接したノードのものに限られてしまいます(β6.1)

そんなわけで、うまくクラスタ化されれば良いだけだとも思われますので、
一つの案として、今現在の性能申告以外にもう一つ、好きな分野もユーザさんに
申告してもらって、今の速度による接続決定と同様にジャンルでも接続を調節して
上流ノードは円状に分布してもらうというのが良いのではないかと思います。

ジャンルは一つの実数で示しますがこれはサイクリックなのでモデルとしては図のような
円柱モデルになります。各ノードやは速度とジャンルの二つのパラメータで
円柱表面のどこかに位置することになり、キーは上の円上に分布します。

ノードは得意な分野の下にぶら下がりファイル提供。キーはやはり上流に貯めておいて、
クエリはこの円上を左右に流す(実際はショートカットが生じますので網ですけど)となります。
キーは真上方向と左右少しだけにのみ流れるので各ノードの負荷は比較的軽いですし、
指定した分野のファイルはほぼ見えることになります。ノードが増えてきたら、
分野をより細かくしてノードの分担を特化させて対応することになります。
回線の早い人は上流というよりは、人気があって多数のクライアントをぶら下げる必要のある
負荷の高い領域の上流側を担当してもらうことになります。

これですと反対側のジャンルのファイルがまったく見えませんが、あまり困らないと思いますし
必要に応じて一度落ちてノードの位置を変えることになります。
匿名性とキー検索速度とパフォーマンスを両立させる代わりに、
検索で全部のファイルが見えるのを諦めることになります。

と、この方針で実際にコード書き換え初めてますけど、増えるのは検索に分野の指定がつくこと、
ノードにも好みの分野の設定があるということです。あとフォルダ単位での分野範囲がつきます。
検索分野の指定は自分の位置と逆方向だと何も出てこないの無くても良いかもしれませんが・・・

あとここで言っている分野ですが、内部的には0から1の実数で円柱における円周方向です。
0から1では分かり難いので今では表示させるときに24倍して、時刻に見えるようにしてます。
ので、現状ではジャンルは1時とか12時とかの時刻指定になってます。

どの辺が実際に何のジャンルになるかは、どれとどれが隣接分野になるかを考慮して
使用者の間で適時決めてくださいということで。ジャンルは連続しているので中間領域もありです。

と、こんなもんでどうでしょう?


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,1.2,1.3に分けて以下同様などです。

323 名前:47 投稿日:02/05/10 14:33 ID:TTFUeNL0 main/1020956839.html#422
ある程度分布が分かれてくれないと意味がないんで、
分野分けは二極化もしくは三極以上の多極化されると助かります。

サイクリックになているのはそういう事情で、
常に12時近辺にデータが流れていたのではそちら側があふれます。

0時と12時に一番のピークがあって綺麗に分かれるなどが望ましいです。

324 名前:47 投稿日:02/05/10 14:37 ID:TTFUeNL0 main/1020956839.html#428
あと時間にしているのは一番身近だからであって、
24でないとだめということは無いです。内部では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
> 逆に該当ジャンルの仕分けや1ジャンルあたりのノード数が少なくなる可能性はありませんか?

いや、明確にこのジャンルというわけではなく、この辺担当って決められればそれでいいんで。

> 隣接ジャンルも検索されればありがたいとおもふ

まさにこれをやるためにジャンルを実数にしてたりするわけです。

今ですと検索も全個所でやる必要があり、キーも全部流す必要がありますが、
ジャンルが特定できれば、検索パケットの展開は目的ジャンル担当の
のノード近辺だけでやればいいし、他に流すキーも取捨選択できます。


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時間離れたところまでキーは届くようにするつもりでしょうか

届くけど、クエリが戻ってくるころにはダウン不可能なキーばかりになってるんではないかと。
というか、無意味なんで切りそうです。ネットワーク規模が大きくなるほど、離れた分野の
ファイルは見えなくなりそうです。これの問題は、それより匿名性の低下ですかね。

あと、二つ検索したければ二つリンク張るだけなんで問題ないと思われます。
問題は、二つの分野のキャッシュを担当したいという場合ですが、
これはPC分けないと無理になりそうです。

> RecvBuffer is overflow
これはそのまんまで、通信用のバッファあふれです。
キー転送かクエリの転送量が多すぎるんでしょう。


334 名前:47 投稿日:02/05/10 15:23 ID:TTFUeNL0 main/1020956839.html#467
>>464
動的な移動はまずいかなぁ・・・今の速度と似た扱いですので。
今の速度と合わせた二次元情報でノードを分類してやろうという扱いになります。

とりあえず、再起動時にキャッシュやUPファイル内容見てその
トータルの評価値でじわじわと動いていくといいかもしれません。
これならジャンル知らないでも勝手に自分の好きなところに移動しそうだし。

っと、そろそろこっちやってるとまずいんで抜けます。

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個以上、ノード数1万以上と言う過程が現実的だと
思われますので、扱うキー数が数十万レベルではなく数千から億に達するとの過程で
上流側の接続形態を見直し中です。とりあえずシミュレータ書き直してますけど、
接続形態はこんな感じになるんじゃないかと。

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がベースになるはずだから
早めにつぶしておいた方がいいんだろうけど
バグ取りつまんないので現実逃避に新設計したくなる罠(w

無駄なキー転送落として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
β7使う人がいなくなるまで重いと思うんでよろしく

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
うーん、わけわからん。こちらではLAN上でのテストか
デバッグバージョンで起動して繋いで見る程度のことしか
できんので何が起きているかさっぱりわからんです。
最低限グローバルIPが二つ使える環境でデバッグしないとダメだけど家も職場もだめだしなぁ。

テストできる人いたら、Port0設定していたらどういう動作してる
(どこのポートを突付きに行ってる)とかNAT経由でどうなるか見てもらえると助かりますけど、
動作推測してその理由がわかる人じゃないと意味のある意見聞けないだろうし

早めにこちらのテスト環境を作んないとだめだな


350 名前:47 投稿日:02/05/11 00:08 ID:Oxw247oX main/1020956839.html#763
うーん、プライベートアドレスがもれるということは
逆NATんところが変なんだろうから
もう一度よく考え直すかぁ・・・



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
情報どうもです。一応動いているみたいですが、動かない環境では何が悪いのやら・・・
転送ですかねぇ。

> *なぜ回線申告50をしているマシンB.がマシンAにて回線速度10に見えるのだろうか・・・

これは、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
うーん、ダウンロードができるかどうかというのは接続を受けた相手
がちゃんと受け付けられるかどうかの要素が大きいんで報告されても
アップ側の様子がわかるとなんで失敗するか分かります。

ファイルが転送されて無さそうなのにUPリンクが限界まで張られてたりしますか?
それならこれが原因ですけど。

358 名前:47 投稿日:02/05/11 01:24 ID:Oxw247oX main/1020956839.html#815
とりあえず疲れたんで、またLANで地道に動作見直します

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はDOWN側が悪いんですかね。
β7なら落とせるとかあります?

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
いまLANで見直してたんだけど、β7.1では転送動作時に
少しでもウェイトかけると転送が始まらずに転送側もダウン側も
固まる現象を発見。あと、UPとダウンがひっくり返るのは致命的
なんで見直します。心当たりがあります。少しお待ちを。

363 名前:47 投稿日:02/05/11 02:39 ID:Oxw247oX main/1020956839.html#871
わーかったー。Port0対応やったときに上下速度の比率調べる部分で
整数から実数へのキャストが取れて整数/整数になってる。これじゃ
下流側の計算が変だわ。グローバル3つ所有 さんサンキューです。

チェックして問題なさそうなら上げます。

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
つ、疲れた。とりあえず何でもいいから最低限の転送できるようになってくれー。
LANじゃ快調なんだけど、そういうのに限ってなぜかWANじゃ調子悪いし
頭いたい。

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のタイムアウトを5秒と短くしてみたので、こちらに
切り替えてみてください。プロトコルは同じなのでどちらでも問題はないですけど。

369 名前:47 投稿日:02/05/11 10:06 ID:SbQWv1d4 main/1021057195.html#76
都合によりβ7.4です。
7.3はUP側に問題が残っていたので修正しました。細かいパラメータ調節程度で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
うーむ。重要なことに気が付いてしまった。
この検索方式だと検索かければかけるほど
キーが荒れていって本体に届く率が悪くなるような・・・・

みんなが静かにしていると仮想キーが寿命で死んでいって
寿命無限のキャッシュやUPファイルだけが残るんで、
その状態で検索かけると検索クエリが本体まで
まっすぐ到達して素直に落とせるような気がする。対処どうしよう。

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
ちょっと分かりにくかったかな。

今回、上方キーと下方キーではなく、検索キーと転送キーになってますが
現状での検索と転送のメカニズムは次のようになってます。

まず検索ボタンが押されると、検索パケットを上流と下流に投げます。
上方向と下方向にしか行かないので、上流ノードが異なる別のノード
までは検索に行きませんが、上下リンクが複数なので、鼠算式に
パケットが飛ぶんで、わざとクエリの複製は行わないようになってます。
これやると以前のようなものすごい通信負荷が発生します。

で、検索が戻ってくるわけですが、下流から上流に行く場合、
キャッシュやUPファイルのみが検索にかかり、これを転送キーとして
上方に伝播させます。これは上流まで行きます。
検索パケットが下流に行く間に、UP回線が空いてるノードから優先的に
転送キーを検索パケットにプッシュします。このときキーのリンク元を自分に書き換えます。

この検索パケットが検索をかけたノードまでいって展開されて、
これが検索キーとして表示されることになります。

こんな感じで、検索パケットが上まで行って下に折り返してくる間に、
自動的に転送相手が決まることになります。

378 名前:47 投稿日:02/05/11 22:57 ID:USdxWxLD main/1021057195.html#450
検索キーはポインタのポインタですけど、
転送キーは単なるポインタの可能性が高い(そこにキャッシュかUPファイルがある)
んで、転送キーのが落とせるはずです。無意味に他ノードに転送開始させたいときは
検索キー選んでください。kろえ匿名性に問題があるんですけど、βだから区別して出してます。
後で消して自動判別にします。

つーか、両方見えたらバグなはずだなぁ(^^;;
私も繋いで見るか。

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
自分のキャッシュが一番優先度高いんで消さないと他のノードのファイルは見えません。
UPファイルが一番優先度高いんで、UPファイルにあれば他は全て上書きされます。

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
β8落としなおしてください

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と繋がります。これ以上ダウン率がよくなることはないはず(転送率0)なんで、
これでダウンができないとなると別の理由です。

転送より先にNAT対策などになるでしょう。


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環境といってもいろいろなんで対応が面倒ですが・・・

とりあえずβ8で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ファイルそのままの位置を表していますので、
動作的にはMXと同じです。提供しているのが、検索リンクで近傍の人の可能性が高いので
キーの下と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
ああ、でもキーのIP=UP相手と表示されるのは全員β8.1の場合なんで
β8と混ぜて使えば匿名性はありますね(w

ダウンテストにならんですけど・・・・

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の匿名性はMXと同じか少し上ぐらいかと(w

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
DLできなければそもそも接続もできないので、
接続失敗するのはほとんどUP側の問題のはずです。
もちろんほとんどはWinnyβのバグなんですけど。

そんなわけで後はよろしこ。


402 名前:47 投稿日:02/05/12 03:21 ID:UR5S16Xz main/1021057195.html#726
ノード管理が変になっているようだったので修正しときました。β8.2です。
エラー10038が出る時点で気が付くべきでしたが・・・

あと、バッファ溢れが出るのはキーを多数抱えているノードに
zipなどの拡張子検索などのヒットしすぎる状態で
クエリが大きくなりすぎるのが根本的な問題のようですので、
1クエリで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
今は接続率を上げるのに注力してるんでメモリ消費量やCPU負荷低下は
もう少しあとのバージョンで期待してください。

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
二日に一度寝れば耐えられる体質なんで、
あと12時間ぐらいは起きてると思いますよん(w

さて、今週分の仕事でもしようかな。


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
一行レス野郎装おうと思ったら名前入れたままだった(w

このシステムだと名前同じでも中身が一文字でも違うと
別キーになるんで掲示板は無理ですけど、
回覧版というアイデアは面白いすね。
キャッシュに入れている人がいる限り
昔のを消せないという問題はありますが。

とりあえず、8.3は接続テストに最適なはずなんで
一日程度このままでどういう理由で落とせないのか
理由をさぐる予定です。今のうちにキャッシュ育てといてください。

あとポート0が出るのは、エラー対処の際にリンク切り忘れた
らしいです。対処終わってますけどこれだけのために上げますか?



410 名前:47 投稿日:02/05/12 09:59 ID:jdCoJU22 main/1021057195.html#915
β8.3をこっそり一箇所書き換えてポート0リンク残りに対応しました。
気になる人はダウンし直しといてください。動作は問題ないはずです。

隠れバージョン作るなよというのはあるでしょうけど
このぐらいならいいっしょということで。


411 名前:47 投稿日:02/05/12 10:08 ID:jdCoJU22 main/1021057195.html#919
っと思ったら0リンク残り直ってないや(^^;
すいません。また後で見直します。

ちなみに誰かWinny本体をWinnyで上げておくと、
回覧版のように変更がばればれになって面白いかもしれません。

>>916

ポート番号が0なのはまだネゴが終わってなくて、
ポート番号などが伝わる前に何らかの理由でFailしたリンクのはずです。

ここはタイムアウト処理入れてないんでタイミングによっては
残っちゃうんでしょう。ここは変にいじると危険そうなんで後回しにします。

>>917

今不安なのはNAT周りの動作でしょうか。
ネゴの時にノードにgethostbynameで取得したローカルアドレス申請してもらって、
隣のホストがローカルからグローバルに変換してるけどこれでいいのかとか、
ファイルダブルクリックするとそこに書いてあるIpとポートに接続に行きますけど、
これが食い違ってないかとか、キーに書いてあるIPやポートがちゃんと
あってるかとかとか・・・

独自にネットワーク組まないとわかんないと思いますけど。


412 名前:47 投稿日:02/05/12 22:58 ID:AbMuX6A3 main/1021170898.html#275
今まで寝てた・・明日の夕方は眠そうだ

UP状態が見れないのは既に書いたようにダウンタスクはファイル単位で
やっているのに対してアップタスクはブロック単位だからです。

ここの動作詳細ですが

1.ファイルダブルクリックでダウンタスクが生成される。同時に転送リンク接続。
2.対応するキャッシュがあるか調べて、あれば破損個所を先頭から探す
3.数ブロック分(ブロック数は速度設定により可変)の転送要求を送る
4.UP側はブロック転送UP用のタスクを生成
5.送られてきたハッシュファイルの該当ブロック部を返送
6.受信側が送られてきたデータをキャッシュにくっつける
7.受信側が全ブロックそろった時点で転送リンクを切断してキャッシュ変換タスク起動
8.送信側は相手が転送リンク切るまでリンク切らない

こうなってます。受信側は、このファイルのここのブロックから何ブロック送れという
指示に従って送っているだけなので、一瞬UPタスクが生成されてタスク表示のところに
出ますけど、ファイル内容を通信用バッファに詰め込み終わればタスクが終了してしまうので
一瞬でタスクが終了します。通信部は送信、受信ともキャッシングされていて、
送信・受信可能になったらキャッシュの内容を順次送受信するようになっているのでこうなります。

ちなみに、ファイル要求は上で書いたようにブロック単位になっていますので、
前半分だけ無かったり、一部分だけ破損していてもそこだけレジュームできます。

キャッシュ変換でエラーになっても諦めないで、もう一度ダウンしてみれば、
破損部分だけ修復できる可能性高いので破損キャッシュでも消さないほうがいいです。

特に、レジュームのつなぎ目のところで壊れたブロックが発生しやすいようです。
あと、ブロック破損のチェックは比較的重い処理なので、受信時にはやらないで、
キャッシュ変換時にやっています。だから完全キャッシュに見えても、キャッシュ変換
で破損キャッシュになる可能性があります。この場合、そのキャッシュを検索かけて
見てみると破損部分だけ青くなります。

バイナリエディタでわざとキャッシュの一部分を壊してみるとその動作が良く分かります。


413 名前:47 投稿日:02/05/12 23:13 ID:mE4zpmn7 main/1021170898.html#284
とりあえずβ9候補はできてるんですけど、動作が怪しいんで検証中です。

予定では、転送機能の復活と、ダウン率の向上です。

β8.3ではキーに直接本体に位置が書いてあるため、ダウン率が高いですが、
匿名性に問題があります。といって、匿名性を上げるために転送動作を入れると、
ダウン成功率が極端に低下します。もしリンク張ってダウンするという一連の
動作の成功率が10%なら、一度転送でその成功率は掛け算になるので1%の成功率。
もし、直接ダウンの成功率が1%なら、転送での成功率は0.01%になってしまいます。

ここで、ダウンが失敗しやすいのは、主にUP側でポート設定が変だったりして
コネクションを受け付けられないというのが理由のなずです。

ですので、β9では、転送の相手を、本体を持つ一つ上のノードに決め付ける予定でやってます。
検索リンクで一つ上のノードということは、既に検索リンクでコネクションが張られている
はずですので、検索リンクを転送リンクとして利用すれば新たにコネクションを張る
必要がありません。ここはPort0設定されていることと同じですので、一つ下の
ノードとのやりとりはかならず相手をPort0とみなすことになります。

これですと、ポート接続不可能なのにそれを申告していないノードのファイルも
外部にUP可能になりますし、人気があるファイルは自動的に上流にキャッシュが
広まっていくことになります。一番初めに考えた通りの動作になります。

これで、本来の予定通りの、匿名性を実現した上で、うまくいけば
今以上のダウン成功率にできるのではないかと。

あと、この辺見直してたらNAT周りの動作が変な理由が分かった気がするんで
合わせて対処中です。しばらくお待ちください。


414 名前:47 投稿日:02/05/12 23:21 ID:mE4zpmn7 main/1021170898.html#288
β8.1以前の人がいるのかな?
転送は他ノードとの兼ね合いで発生する
(キー転送中にそのIPを自分に書き換えると転送になる)

でも、違うファイルが送られてくるというバグもあるようなので
単にバグってるだけだろうなぁ(^^;;


415 名前:47 投稿日:02/05/12 23:30 ID:mE4zpmn7 main/1021170898.html#293
ファイルダウンの時は、手持ちのキーにロックかけて検索で消えたりしないように
したうえで、そのタスクのID(これはダウン側特有の値)とファイルのハッシュ値送って
ファイル転送してもらうんですけど、違うものが落ちてきてしまうということは、
ロック寸前のところで、キーが頻繁に書き換わっていて違うものロックして
そのファイルの転送要求がいっちゃってるんでしょう。

もしファイル名と中身が違ってたらまた別の部分のバグ(ダウンタスク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では接続後に5秒たっても
テストの転送リンクが繋がらないと検索リンクを自動切断します。

全員β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見てるだけじゃだれがUPしてるのかとかダウンしているのかとか
追いかけきれないはずです。

今現在ですと、必要最低限の転送が発生するだけなんでダウン率は
β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ノードの一つ上にノードの人)から落とすことになるんで、本来の目的であった、
UPしているのかキャッシュ送っているのか転送しているのか分からないというのは
β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がぶら下がれます。

とりあえず、プログラムクラックできたとしても得られるのは
今のβで晒している情報までですので、正式版になってこれらを隠して
しまえば極端に解析は困難になります。プロトコル的に
キャッシュかUPファイルかはどうやっても分からないので、
クラックしてもUPしている人の完全な特定は無理でしょう。

唯一、匿名性の点で穴があるとすれば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です。

タイマー入れて変な接続は強制切断するようにしました。
例の0ポートも5秒後に切断します。

あと、接続の際はコネクション攻撃で押し出されないように、
新しいコネクションを優先的に切断するようにしておきました。

んで、回線高速じゃないと接続回数制限が働かなかったけど、
今度のバージョンでは問答無用にコネクションは200回までです。

普通に使っていればそこに達するまでに他からのコネクションを
受けるようになります。接続をリセットしたいときは接続切断を押してください。


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
これでも落ちるってことは、前からあった不祥事が、再接続数増えたという理由で
表に出てきただけなんでしょう。2chは負荷テストには最適ですねぇ。あー、頭痛い・・・

とりあえずノードオブジェクトはソケット抱えててそれなりに大きいオブジェクトなんで
あまり頻繁に再生成されるとちと怖い(それも別スレッドで)


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
単に10秒以内に繋がるかどうかのチェックなんで、
相手が重いだけとか遠いだけの可能性も高し。

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の人ばかりだと検索リンク繋がんないはずだし。

(シミュレーションしたときの様子だと、上下リンク3だと輻輳起こさないけど、
末端で接続できないノードが出る。上下4だと接続あまり気味だけど、
検索パケットで輻輳起こすことがある)

これはあまりネットワークの大きさによらずこんな感じだったから
そのせいで繋がりにくくはなってると思います。まぁ、設定がまともで
繋がる人優先ということで。


442 名前:47 投稿日:02/05/13 20:18 ID:gJkkHcII main/1021170898.html#927
とりあえず寝不足なんで寝ます。
何か致命的なトラブルとか起きたらβ8にでも戻してください。


443 名前:47 投稿日:02/05/14 07:37 ID:rh93UkNj main/1021291867.html#229
β9.2です。

BadPort0判定でタイムアウトのためのタスクが止まってなくて関係ないところで
警告出ていた可能性があったので直しました。あと、相手の転送リンクが
いっぱいで蹴られているといのと区別できているのか怪しかったんで、
転送リンクフルで蹴った場合、相手の方にそれを伝えるようにしました。

前のバージョンだと単に切断になりますので、プロトコル的にはβ9と互換があります。

あと、どうしても検索リンクが変だったり、再接続したくなることが多いわけですが、
転送中だとその人がかわいそうってことで、検索リンクと転送リンクを別々に
切れるようにしておきました。検索リンク切断は検索のところにあって、
転送リンク切断はタスクのところにあるんでちと分かりにくいかもしれませんが
ご勘弁を。

あと、長時間放っておくと誰も接続に来ないような地のはてに飛ばされて
マターリしてしまうので、帯域あまっているので帯域を豪勢に転送に提供しても
良いという人向けに、一定時間で自動的に検索リンクを切る機能をつけときました。

これは、システム情報のところにあります。自分で検索して、
相手見つけたらマターリファイルのやり取りをしたい人はOFFでいいと思います。
デフォルトではOFFになってます。

そろそろこういう細かいインターフェイス周りとかのチューニングに
入ったほうがよさそうですね。一時的にβ取ってもいいかもしれません。

まぁ、今現在ですと下流方向の検索率が悪いので、ここの部分だけちとテスト
してみたいところですけど(また検索パケットが溢れる騒ぎになる可能性も)



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
IP周りはリリース版では隠すと思います。これテスト用だし。
まぁ、もしクラックされたらこの程度の情報は漏れちゃうよということで。


446 名前:47 投稿日:02/05/14 08:20 ID:rh93UkNj main/1021291867.html#252
当分はプロトコル変わるたびに接続不可能になっていくだろうから
プログラム収録してもまったく無意味だと思われ(w

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
キーの処理は、今になってみると何も考えずにクエリで引っかかったキーを
全てクエリパケットに押し込んでいたのが前のβで重かった最大の理由だったと思います。

今ですと1ノードの検索では最大100個しかパックしません。
どうせ画面で見えるのは200個ですし・・・

ただ、当初のキー周りの設計予定では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
β8が匿名性低いといってもあれでも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を晒す。
これで交換にも利用可能(w


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
今は、上流側は上れるだけ検索、下方向は一つ下のノードに検索にかかったものを
上に投げてもらうって感じですね。あと、手持ちのキーを全部送る動作は一切無しで
クエリにひっかかったものだけが上流に伝播してきます。

一つの案は、今の方式に加えて下流リンクが無いノードが手持ちキーを一つ上に
全部送ってしまう方法です。だいたい上下リンクが3層以上になることはないので、
これでかなりヒット率が向上するのは間違いないんですけど、結構重いでしょうねぇ。
昔のβ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
今の方式のままなら、ファイルがどんなに増えても負荷は
それほど上がんないと思います。

爆発的に重くなったバージョンでは、持ってるキーを全て送るという動作が
入っていましたけど、今は検索にヒットするものしか送ってません。
そして、1クエリで引っかかるキーも制限されてます。

それより問題は、人増えたらますます接続できなくなることでしょうね。

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
ある意味検索率向上を狙って(w
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の1ブロックは64kなんでとりあえず
10ブロックに切っとくとかで。

まぁ、トラブルの元なんでキャッシュに悪さするプログラムでも
出てこないかぎりやらないですけど。

あと、Upファイルの参照数はまだ未実装です。β1出すときに
付けてから発表しようかと思いましたが、どうせ当分無意味だろうと。

十分ダウン率が上がってきて、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ファイルに保存
・ リストコントロールの表示が消えることがあるのを修正
・ キーの寿命を延長
・ リンク数限界を4に戻した
・ 破損キャッシュの名前を不完全キャッシュに変更


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です。

検索率はβ9と比べると画期的に良いはずですが、問題はどの程度の負荷になるかです。
やってること的には、何もしないでもたまに検索出しているのと同じことなのでβ5
以前のようなべらぼうな負荷にはならないはずですが、多少実験的な要素がありますので
ご了承ください。

プロトコル的にはβ9との互換性がありません。

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
あと、自ノードのキー表示OFFの場合の挙動で

本当はキャッシュは完全キャッシュでも表示させるべきなのではないかと思ったのですがどうでしょう?
今ですとキャッシュかUPフォルダにあるとそのファイルが表示されないので、
転送でキャッシュ内に既にあるファイルは、せっかく何もしないでもダウンできるのに
それに気が付きません。

既に気が付いていて邪魔ならUPフォルダに移動させれば、オプションON時に出ませんし・・・


481 名前:47 投稿日:02/05/15 16:37 ID:IlIfcVaJ main/1021291867.html#914
β10とβ9.4での違いで

1.どこが変わったかわかんない
2.それほど重くなったとは思えないけど仮想キーが溜まるようになった
3.くそ重いぞゴラァ

の三通りありうると思うんで報告よろしこ

回線速度と、仮想キーがどの程度の数になっているか教えていただけると調節に使えます。


482 名前:47 投稿日:02/05/15 16:40 ID:IlIfcVaJ main/1021291867.html#918
あと、同じファイルを二回ダウンかけると自動的に
別のところを読みにいくようになってる(つまり分割DL)ですが、
細かい破損ブロックが出やすいのでレジュームかけてください。


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
ハッシュ同じで名前違うと検索の度に名前変わると思います

しかし、プロトコルぽこぽこ変えるのも考え物ですな。
速度とかが表示されないで10秒後に切れるのは主に
プロトコル違いのはずですが、これのせいでコネクション回数が凄いことに。

バージョン変わったら使うポート番号かえてもらえると助かるかも。


486 名前:47 投稿日:02/05/15 17:25 ID:IlIfcVaJ main/1021291867.html#959
一応こちらの想定範囲内の挙動してるようではありますが、2が多いとすると

2A. 仮想キー増えたけど検索率が良くなったような気はしない
2B. 多少はヒットしやすくなった気がする
2C. なぜか転送成功率が上がったような

この辺ありますがどうでし?
原理的には上流でのキーロストが減ることで転送率も上がるはずですが。


487 名前:47 投稿日:02/05/15 17:32 ID:IlIfcVaJ main/1021291867.html#967
これでそんなに重くなんないのならこのまま様子見でバグ取りに注力でいいかも。

そもそもキーに書いてある本体の位置はIPとして書いてあるんで検索リンク切れても
相手のUP変わるか回線断しないかぎりロストしないでコネクションにいけるはずなんよね。

てっきりこの辺でダウン率悪いのかと思ったら主な理由はFWだったし、
当初の設計に近いこのβ10で問題なく動けば、良いとこ取りできるはずなんですけど。


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側が漏れる理由が良く分からん。

これが出る方に質問ですが、ひょっとして20分で自動切断する
機能が入った状態でのみなりますか?


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
ああ、あとプロトコル共通です。
今のプロトコルで何か致命的な問題が出るまでとうぶんこのままではないかと。

ダウン率落ちたように見えるのは単に見えるファイルが増えたのに
ダウンできる率はそのままだからUP帯域が余ってないだけのようです。

やっと、優先度の機構を入れるべきところまで到達したのではないかと。


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
あと中継で追い越すことはないです。

先頭からブロックが存在しているかチェックして、
抜けてる部分を常に落としに行きますので、
転送が間に合わなかったらそこで待ちになります。

あと、転送で受け取ったら既にそのブロックがあった場合、
他にもどのファイルをダウンしているタスクがあると判定して
ある程度先から読み始めます。これにより、複数ダウンかけると
常に別の部分を読みに言って結果的に分割DL動作になります。

転送時には同じファイルのUP動作もしているわけですし、
実装的にはブロック単位で好きなだけ
アップやダウンできるようになってます。

500 名前:47 投稿日:02/05/15 23:27 ID:IlIfcVaJ main/1021451237.html#169
あと、転送でキーのIP書き換えるときや、他から回ってきたキーと同じキャッシュを
持っている場合、UP数が余っている場合だけ上書きしますので、
自動的に空いてるところから落としにいくはずですが、
キャッシュが広まってないと結局大本のUPファイルを持っている人のところに
全てコネクションが行きます。

小さいものなら直ぐにキャッシングされるはずですが、そうなると
落とす相手が変わりますので、一度検索かけ直してから
再試行したほうが落としやすくなるはずです。

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
転送というより、現状では他のノードにダウンかけてPC使用者が知らないうちに
キャッシュとして持たせておいて、これを後から落としているという間接的な転送に
なっているlことが多いはずです。だから転送が早い割には解析が困難なわけで。

506 名前:47 投稿日:02/05/16 03:17 ID:eCUvVMNI main/1021451237.html#309
パケットとってもそれを解析するなりプログラムクラックしないと
どのソケットにどのファイルが流れているのかわかりません。

ソケット内で流れている暗号はそう簡単にとけるものでもないと思う
(ファイルの暗号化に使ってるのと同じですが、キーが完全に動的です)
んで、やるとしたらプログラムクラックになりますが、前のIP出してたβ
程度の情報しか得られません。クラックさえすれば、
どこのPCにどのキャッシュがいったかは分かりますが、キャッシュを
中継しただけというのがどういう扱いになるかですね。


507 名前:47 投稿日:02/05/16 03:18 ID:eCUvVMNI main/1021451237.html#310
>>308
UPフォルダに置くとハッシュが同じなので自動的に消えます

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
接続が多いからといって問答無用で切っても、切られた方は
また接続かけてくるんで単純に接続切っても無意味だったりします。

だからある程度付き合ってあげて他のホストを紹介してあげる
必要があるんですけど、ここの分配は試行錯誤でして、
今までですと検索リンクが8超えなければ付き合ってあげるという
処理でしたが、これでも対応が丁寧すぎるレベルになってきていますので、
5を超えたら問答無用で全部カット。最後に残った一つのみに
他のホストを教えるという処理に今回書き換わってます。

>>746
本来、やばいものは暗号かけて使うべきなんです。
暗号が空でなければ、転送中は絶対に見れません。
私の方で解析しようとしても無理です。キーが分かりませんので。
今見えているのは、単にみんなが空キー使っているからですね。


516 名前:47 投稿日:02/05/17 17:06 ID:Gvhxc5NR main/1021451237.html#751
一応仕事中なんですけど(w

517 名前:47 投稿日:02/05/17 17:18 ID:Gvhxc5NR main/1021451237.html#759
キー数制限が今は1万だけど5千程度にしちゃおうか。
そんなに影響ないはずだし。

518 名前:47 投稿日:02/05/17 17:38 ID:Gvhxc5NR main/1021451237.html#771
うーん、設定増やすほどわけ分からん設定して周りに迷惑かける人が
増えるんでできればこういうのは自動にしたいとこ。
とりあえず次Verから5000制限に落しますわ。

メモリ上でもキーの一部分を暗号化(具体的にはIPですが)
したんでこれで少し重くなってるというのもあるでしょうけど、
1ノード内のキー数はそれほど重要でなくて上流にある程度
溜まってさえいてくれれば検索は確保できるんで、
無理してメモリとCPU負荷上げても仕方ないと思うし。
単にヒット数上げたいのなら、上流ノードの上流リンクをもう少し
工夫した方がいいはず。

しかしこうなるってことはユーザ数1000突破しとるなぁ・・・


519 名前:47 投稿日:02/05/17 18:18 ID:Gvhxc5NR main/1021451237.html#777
今のやり方でもパラメータ微妙に調節していくことで
1万ノード程度まで耐えられるはずだけど
そこまでいくと今度は検索ヒット率の低下が酷くて
キャッシュ無し状態での検索ヒット率が1%程度になっちゃうはず。

正確なところはシミュ書き直してパケットの中継回数とか統計とれるように
しないとわかんないけど、今だとリンクがそんなにプチプチ切れないという仮定で
ノード数1000、トータルキー数10万程度なら2〜3割のヒット率って
感じじゃないんですかね。上流がちゃんと網作ってくれれば飛躍的に
ヒット率上がるはずだけど切断率がすごくて上流はぜんぜん繋がってないみたいだし。

しかし4月初頭の想定よりプログラムが重くてCPUとメモリを消費するのが痛い。
初めの設計では1万ノード程度までは検索率8割キープのはずだったんですけど、
そもそもトータルキー数を一桁か二桁誤って推定しとったのが致命的。
またチューニング作業でもしますか。

どちらにせよ今の十倍の規模になったら例の明示的なクラスタリングが
必要になります。これだと今のMXと同じ規模まで耐えられると思います。
今のβテスト規模のネットワークが横に100個程度連なることに。


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
部分キャッシュは破損していてもがんばって落としていけばいつか修復できるはずです。

これの報告が多いようでしたら、キャッシュのアップロードが多少重くなりますが、
UPファイルUP時と同じようにハッシュチェック入れることにします。


522 名前:47 投稿日:02/05/17 19:51 ID:daRc0Eo8 main/1021451237.html#792
ちなみにハッシュのメカニズムですが、現状では

UPファイルのUP→オリジナルファイルのハッシュを計算してキャッシュ化してその都度送信
キャッシュファイルのUP→ハッシュ計算などはしないでそのまま送信
受信側→何もしないでキャッシュフォルダに置くだけ
キャッシュからダウンフォルダに展開時→ハッシュチェック

このようになっています。

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共通です。

たまには狙って何か落として見るかと思って自分で使ってみましたが
何度もダブルクリックしないとまず落ちないので頭にきて自動再試行つけてしまいました(w

転送がかかった場合、まずタイミング的な問題で2、3回接続かけないとだめ
なんで、標準でこの機能がついていても問題ないと判断しました。

相手が回線フルだとなんかいやってもだめなんで直ぐに試行回数を使い切ります。
ちなみに10回までです。10回使い切るとバックグラウンドで自動的にクエリかけなおして
ますので、ダウン対象が変わる可能性が高いです。どうしても落としたい場合は、
そのあとまた再試行かけてください。

あと、キー数限界が5000になってます。


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
落とすキーがすげ変わる件ですが、今回のバージョンでかなりよくなるはずです。

キーがすげ変わるのは、タイミングの問題でしかたないです。
現状、キーIDの形式でタスク持ってるんで、検索直後に直ぐにダウンかけないと
キーロックする前に他キーに入れ替わる可能性は避けられません。

特に上流でキーバッファの変更が激しい場合はそうなります。

今回のでも10回の再試行使い切った場合はかなりの確率の別のものに
なるんで、一度再検索かけたほうがいいです。10回の試行中はキーが
ロックされているんで別のものにすげ変わる可能性は低いはずです。

そんな事情もあって早めに自動再試行つけました。手動で再試行やっているかぎり
すげ変わるのは防げません。


529 名前:47 投稿日:02/05/17 23:22 ID:UZeC2zNO main/1021451237.html#853
現状、キーのハッシュじゃなくてキーのID(リストでの位置)でダウンかけるように
なってるから、無理に再試行かけても別のものが落ちてくる可能性高いってことです。


530 名前:47 投稿日:02/05/17 23:41 ID:UZeC2zNO main/1021451237.html#882
というか、どうも何を落とそうとしても落ちないみたいなので、
これで状況が悪化するかどうかで理由を探ろうというのもあります。
これで悪化しないのなら多少切れるのはお約束でWAN上で動かす上では
リトライ必須ってことで。

DOWN側もそうですが、これでUP側が悪化するかどうかのチェックもよろしくです。
所詮まだβですので、一種の実験です。


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
今の再試行時間は0秒でタスクが異常終了したら速攻で再起動しているだけですが、
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です。バグ取りだけで機能追加はありません。
あと、自動再試行は不祥事の方が大きそうなんでとってあります。

今回の修正ですが、転送部を見直していたら転送回数が任意回数になることが
あるという致命的な問題が残っていたので、できるだけ1回以下に
なるように修正しました。

実はここの転送率の制御が非常に難しくて、今度は転送がかかりすぎない
可能性もありますが、匿名性確保のためだけにあるので、
まれに起きる程度でもよいだろうと。

今回のは従来の転送部と違って、部分キャッシュが優先される傾向にありますので、
途中まで落ちたキャッシュが転送動作で勝手に補完されて完全キャッシュになっている
という動作が増えるんではないかと思います。

実は複雑すぎてわけわかんなくなったので転送周りを一度全て作り直したりしてたんですが
細かい部分の動作が怪しくてβ8のころに戻ってしまいそうだったので、結局これは廃棄して、
見つかった問題点への対策だけβ11.4に取り入れました。

なお、これのせいでプロトコルが変わってしまったのでβ11との互換性はありません。


537 名前:47 投稿日:02/05/18 22:36 ID:L6sJ3iDl main/1021653459.html#440
よく話の流れがわかんないけど、ダウン速度でMX3.1を超えることはないだろうし、
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
ちなみに現状では、UPはブロック単位ですけどDOWNはファイル単位で
転送時に途中から読むことができないんで、転送時に転送元が前の方だけのキャッシュで、
転送依頼側が後ろ側だけないキャッシュだと切断エラー出ます。

ダウン開始時にネゴして対処するか、ダウンもブロック単位にすればいいんでしょうけど、
対処が面倒なんで後回しになってます。ここはβ1完成直前でレジューム作ってて
問題になったところだし。


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
そういえば検索リンクのアタック頻度がどんな環境でも1秒に1回に
なってるからのんびり待ってないと繋がらないはずです。

前のだとネットワーク周りの耐久度が悪い環境で吹っ飛んでたみたい
(主にルータだと思われますけどOSとかNICなかもも)なんで
すこしのんびりした動作になってます。よろしく〜。


544 名前:47 投稿日:02/05/19 00:33 ID:zzLk5zLZ main/1021653459.html#517
β12.1です。β12と互換があります。

諸悪の根源はUP側タイムアウトの一つだったようで、落ちるようなので
マターリとしたダウン再試行つけときました。

ボタン場所がなかったので設定ダイアログのところに置いたので使いにくいと思いますが
使いたい人はONにしといてください。デフォではOFFです。


545 名前:47 投稿日:02/05/19 19:49 ID:5ot31yKO main/1021653459.html#825
だるくって仕事がはかどらんでだらだらしとります(w
Winnyのソース丸一日みないのってそういえば4月以来始めてかもしれず。

Port0が問題になっているようですが、これが何をやっているのかというと、

1.Port0設定がONになっていると検索リンクネゴの際にそれを隣のリンクに申請する
2.隣のノードがPort0だと分かっているノードから来たキーは、他のノードに渡す
ときにそのIPを自分のIPに全て書き換える。注意点は、相手に渡すときだけで、
手持ちのキーにはPort0の相手のIPが書かれてます
3.これでPort0へのダウン要求は全て一つ上のノードに転送かかることになります
4.Port0から他ノードへの接続は普通に転送リンクが張られます

あと、基本的にPort0は下流になりますが、Port0ノードがPort0ノードにリンクしたり
することで、Port0の下にPort0が来たりすることもあります。基本的にキーは
上流がわに流れますので、最後はPort0群を脱して正常ノードにキーが流れていきますが
検索結果以外のキーがPort0側に流れることはありません。

Port0周辺の実装はこんな感じです。

もしPort0に転送を担当させようとしたら、どうにかしてport0ノードにパケットを
到達させて逆にコネクションを張ってもらうことになりますがちと問題が多いです。
やり方その1は集中鯖を持つ他のソフトのように検索用のリンクを通して
(というよりブロードキャストに近くなる)逆リンク張らせる方法になりますが、
このパケットが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の方は基本的に転送動作しないので
そこから送られてきたキーは基本的にキャッシュかUPファイルですが、
隣のノードは相手がport0かどうか知っているので、そのPort0ノードが
持っているファイルがばれやすいです(絶対ではないですが)。
もちろんこれをやるにはプログラムクラックしないとだめですけど、
検索リンクの上流側でキーをよく監視してるとまずいかも。

Port0でもキャッシュが働くのでPort0設定でもMXよりは匿名性高いですが、
転送かからないと匿名性的には大差ないので、Port0でないと
使えない人はそもそもWinnyを使うメリット(匿名性とパフォーマンスの両立)
が薄いかもしれません。MXでも使った方がいいかも。


547 名前:47 投稿日:02/05/19 20:02 ID:5ot31yKO main/1021653459.html#831
UPファイルからの直接Upは、かなり重い動作であるハッシュ生成が
常に入るんでCPU負担が凄いです。匿名性の点からも全部キャッシュに
してしまったほうがいいですね。


548 名前:47 投稿日:02/05/20 18:27 ID:fMqRI4yC main/1021824221.html#217
忙しいんでソース書き換えてる暇は無いけど考えるだけ考えてみた例のPort0対策ですが

1.Port0の人を排除する
2.Port0の人に制限を加える
3.何らかの優先度を設ける
4.どうにかしてPort0の人も直接UP可能にする

とあって、1も非常に美味しい対策なんですが(プログラム作るほうからすると一番楽)、
Port0の人も好きでPort0やってるわけでもないでしょうし、3の優先度を設けるという手法は
優先度でよりよくできるぐらいならやってるわけで、実際は優先度が低い人に
制限を加えることで実現されるわけで2と同じだったりします。
これらはPort0の人がいなくなるだけでしょう。

ということで、最善なのは4で技術的にどうにかすればいいわけで、
Port0の人も転送に荷担可能にすれば問題解決なわけです。

問題はこれをどうやるのかですが、前にも指摘があった検索リンクの逆送は
他のノードの負担とか新たなバグ発生がいやだし、何よりも作るのが面倒(笑
なんで、今のWinnyと相性が良いと思われる方法は

1.今と同じでPort0のキーは一つ上流ノードでIP書き換えて必ず転送になるようにする
2.Port0から転送を肩代わりしたノードは、転送要求でUP回線が空いていれば今と同じ転送動作
3.もしUP回線が空いてなかったらPort0ノードにダウン依頼先を示してここに転送リンクを繋げと指令
4.Port0ノードがPort0ノードがダウン依頼のあったノードか、その一つ上に接続
5.あとは通常と同じファイル転送(ただし転送リンクの上下が逆)

これかと思います。失敗が多くなる気もしますが、やっていること的には
通常の転送と大差ないんで動作するでしょうし、作るのも一日あればどうにかなりそうです
(バグも少なくてすみそう)

これの最大の問題点は匿名性の低下(本体持ってると思われるところからコネクションが来る)
ですが、どちらにせよPort0は初めから匿名性弱いんでこれやってもやらんでもおんなじかと。

Port0の最大のペナルティは、もしプログラムクラックされて対策プログラムできたら
真っ先にタイーホになる可能性が高いということになります。
他のノードはクラックされてもUPファイルを特定されません。

とりあえず暇を見つけて実装しますので少しお待ちください。
皆さんには、これでどういうことになるか予想していただけると助かります。


549 名前:47 投稿日:02/05/20 18:31 ID:fMqRI4yC main/1021824221.html#220
補足すると、始めの転送をPort0の一つ上流のノードが必ず
受け付けるとそこのノードが不利なので、
UP回線が空いていても、適当な確率で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と行くわけですが、前に書いたのやろうとしたら
DがAに接続してAがBにC接続を依頼してBがCに接続してCがDから検索リンク経由で
転送になるけど、DがAにCのアドレスを教えることができてもBから接続を受けたCが
これをDからのダウンとして解釈するのが面倒

ってよく考えたらDがAに接続しにいったときにPort0か申告させてBもDもport0
だと分かったら今と同じことすればいいだけか。書いてたら解決しました(w


554 名前:47 投稿日:02/05/20 19:48 ID:pGxbaUun main/1021824221.html#244
A ← B

C ← D

えーと、今の案だとBがport0でDがそうでない場合、
DがBのファイルを落とそうとしたら、

1.DがAに接続
2.Aが下流方向の検索リンクを経由してBにD接続を依頼
3.BがDに接続
4.BがDにUP

で、BもDもport0の場合、
1.DがAに接続
2.AがBもDどちらもPort0と判定
3.検索リンク越しにDにファイルUP要求
4.AがBからダウンしたファイルをDに並列UP

となります。後者は今のPort0からのUPと同じ動作ですね。


555 名前:47 投稿日:02/05/20 19:50 ID:pGxbaUun main/1021824221.html#245
後半間違った

1.DがAに接続
2.AがBもDどちらもPort0と判定
3.検索リンク越しにAがBにファイルUP要求
4.AがBからダウンしたファイルをDに並列UP

こうですね。


556 名前:47 投稿日:02/05/20 20:05 ID:pGxbaUun main/1021824221.html#251
ちなみに全部がPort0で転送がかかる場合(Aが転送)は、

A ← B

C ← D

1.B→A→C→Dとキーが渡る間にBが出したキーのIPがAに書き換わる
2.DがBのキーを要求してそこに書いてあるAに接続
3.Aが自分のところのBキーに書いてあるノードBに接続してこれをダウン
4.AがBからダウンしたファイルをDに並列UP

となるので、複雑さはport0にUPさせた場合と同じです。
今の転送が動いているのであればPort0からのUPも同じ確率で動くでしょう。

>>248
なしです。たすきがけ動作(D→A→B→C→D)が必要かと思ったけど
そこまでやる必要はないでしょうと。BのファイルはDにキャッシュされるわけだし
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可能なので
キャッシュ0のDOMでもいないよりはいいですけど、
DOWN負荷かかるのと合わせて±0。


559 名前:47 投稿日:02/05/20 20:44 ID:pGxbaUun main/1021824221.html#273
キャッシュ消去対策は基本的に当初の予定通り、参照数による優先度算出でしょう。

これはport0への対策と違い、あったほうが「面白い」というメリットが
あったりするので、無いよりあったほうが良くて、
結果、自発的なUP神やキャッシュ放置な人を生み出すだろうと。

どのファイルが人気あるのかとか知れると面白いだろうし、
何か評価値あがると面白いですよね。

実はその値をWinny内部でぜんぜん使ってなくても効果があったりするはずです(w



560 名前:47 投稿日:02/05/20 20:54 ID:pGxbaUun main/1021824221.html#280
優先度は、参照されるほうになるキャッシュ参照のメカニズムは既に入っているわけで
これを参照する方の実装時となるでしょう。

んで、これが具体的に何かというとQの機能でしょうか。
MXと違って特定のノードに待ち入れるわけでなく、
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
んー、正直98系は使わない方が・・・
OSのサービス使わないプログラムならいいけど
こんだけネットワークに負荷かけるプログラムだとちと勘弁。


563 名前:47 投稿日:02/05/21 01:33 ID:1bcvcj89 main/1021824221.html#464
うー、何気に疲れ気味

優先度ですけど、前に書いたようにこれは後ろ向きな考え方なんで、
可能な限り入れないようにはしようかと思ってます。

そもそも優先度を入れるということは、優先度の低い人を犠牲にするということですので、
何からの限界がある場合に使うわけです。

ファイル共有ソフトならUP帯域は有限でDOWN側の需要にこれが
追いつかないと待ちが発生してQが生じるわけです。

ですが、一度Qが生じるという閾値を超えれば直ぐに飽和する
(待ち行列理論なんかでわかりますが)わけで、理想を言えばUP帯域を十分
確保できればいいだけだったりします。UP帯域が十分なら落とし放題なんで
Q待ちの必要がそもそもありません。

しかし、皆さんボランティアや強制でやっているわけでもないので、何らかの見返りがないと
回線を開けっ放しにはしません。そもそも他人の足場にされて回線開放で逮捕などは
論外ですので、匿名性の確保は最低限。あとは、そのソフトを起動しっぱなしにさせることが
できればいいわけですが、Winnyでは勝手にキャッシュに溜まるというのを理由にして
UP回線を開放させたままにさせるわけです。

ファイル共有ソフトは基本的にダウン者がファイル選んで落とすわけですが、
これさえも面倒なので普通は放っておいてたまに何か探りたいという
究極の面倒くさがりな人がいるわけで、これを支援する形で回線借りるわけですね。

で、このソフトではキャッシュが効きますので、UP帯域さえ保証できればある程度の
DOWN要求に耐えられることになります。

ですので、変な制限を加えるのは最後の手ということで、できるだけ
UP帯域を保証できるように起動させておくのがそれなりに面白いもの
にするというのが重要でしょう。

心理的には、乱数要素を含むと博打っぽくなるわけで面白さが増すわけで、
実は今現在の転送で何が落ちてくるのかわからないけとそれが見えるというのは
面白いと思いますので、このまま隠さなくて見せたままのほうがいいかと思いません。

あと、単に楽しむためというだけの目的でノードの評価値を出すといいかもしれません。
これを実際に使うかどうかはともかく何か評価値が出ていると、ゲーム的な要素があって
面白いんではないかと。

MXが流行ったのは単に実用的だからというより、あの駆け引きが面白くて
やっている人も多かったんではないかと思います。そんなノリですね。
偽造する人が出てくるほど格差をつけるとまずいですが、評価値が高いと
機能が増えるとかそんなもんでもいいんじゃないかと思います。

もちろん、目立つ問題点に対応できていることが前提ですけど。


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です

・ ポート0でも他ノードへUP可能とした(転送も可能)
・ ポート0でも検索ノードの上流になれるようにした
・ 単位表示で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
それはβ1からの病気で理由はよく把握してます。
検索で見つけた直後にダウンかけないと別のものを落とす確率が上がっていきます。

これはハッシュでなくて内部のキーIDで落としているからで、
キーの書き換えが激しいと別のものになってしまっているということです。

ファイル名じゃなくてハッシュでも落とせるようにすればついでに解決できる
問題ですので少しお待ちください。他と比べて致命的でないとの判断で放ってあります。


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です

かなり機能追加されてますので、バグもかなりあるのではないかと思いますので
そこのところよろしくです。様子見して今回は放置しないほうが安全でしょう。

今回、自動ダウン機能がつきました。実験的な要素も強いので
問題があるようだと消しますが、自動再試行とは違い、検索&ダウンしないでも
自動でキーワードにかかったキーにダウンをかけます。

これは検索クエリはまったく出さないで、下流から上がってきた転送キーだけ見て
動作しますので、上流ノードで使わないと意味がないです。

ファイル名に特定の文字列が含まれていたらダウン動作を起動するだけですので、
特定のファイルを落としたければ、それと特定できる文字列を入れて放置してください。
あまりヒットする単語で落とそうとしても、一度ダウンにいったファイルは次後回しに
なりますので、先頭だけのキャッシュが増えるだけです。

再試行と違い、試行回数制限は無いし、自動的にキーのIPが書き換わっても対応して
別のノードから落としに行きますので、欲しいファイルを書いて放置しておけば自動的に
いつかは落とせるはずです。

ちなみに、一つの登録でダウンするのは一つのみですので、同じ条件で
一度に複数落としたければ、同じ条件のリストを複数登録してください。
自動的にダブらないでおとしにいきます。ただ、それなりに大きな機能追加で
バグがあると思いますので様子見ながら使ってください。

ちなみに、プロトコルは変えてませんので、β13と一緒に使えます。

あとの変更点は以下


・ 自動ダウンロード機能追加
・ キャッシュ非表示ボタン追加
・ 自動再試行をダイアログ内からボタンに変更
・ 自動検索切断ボタンをノードモードに移動
・ 割り算の0割りチェック見直し
・ どこにも完全キャッシュを持っていない部分キャッシュや仮想キーが一瞬見えることがあるのを修正


574 名前:47 投稿日:02/05/23 03:16 ID:amc0y8e/ main/1022002403.html#303
ファイル名フルで入れるぐらいが正解です
既に書きましたがあまりヒットするようだと
糞キャッシュが大量にできるだけです。

これはQ機能の代わりです。
WinnyではそもそもUP可能でなければ
キーを流さないので、UP側のQという機能はありえません。
ですので自動ダウンしようとするとこのような機能になります。

ついでに自動でキャッシュを増やす機能にもなるし、上流に来やすくなるはずだし、
放置する人が増えて良いルールになるはずということで早めに実装してみました。


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
もうクラスタ化しないとまずいんですかねぇ(^^;
確かに自動ダウンまで入ったのならクラスタ化したほうが
検索やキャッシュ周りなど各所効率は良いんですけど
6月までそんなに暇ないから大改造難しいような気も。

キーのトラフィックが凄ければ、単にキーの上昇率を抑えれば
いいだけなんですが、これをやると今度はキーの検索ヒット率が下がります。

ただ、今現在キーの流通量が増えているのは検索リンクの接続がゆっくりになったのと、
速度判定の遊びを増やした(同じ程度の回線速度ならわざと遅めでも上流として接続させて
ループさせて階層ではなく網構造になる)のがきいていて比較的全ノードが
切れないでつながっているせいかとも思いますので、それならば、
各ノードのもつキー数を減らしても検索率はそれほど落ちません

ただし、パケットが遠くまで行って帰ってくるので検索時間は長くなりますし、
自動ダウンは手持ちのキーしか見てないんで自動ダウンで目的のものが
かかる率が下がりますね。この辺もクラスタ化で改善されるはずですけど。

とりあえずこの辺は様子見て調節していきます。
どうしようもなくなってきたら明示的なクラスタ化入れましょう。


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分の1です。これで検索率の低下を引き起こさずに
キーの転送トラフィックが落ちるはずですが、ノードダウン時にその情報が広まるのに
時間がかかりますので、ダウン率が多少低下するかもしれません。
ダウンのタイムアウト時間との兼ね合いで実際のところは動かしてみないとわかりませんが。


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です。

・ 自動ダウンの開始数=転送リンクUP数に制限
・ キーの参照数情報を他ノードにも送信
・ キャッシュの参照数トータル情報を表示(表示だけ)
・ CPU負荷低減

実験的な要素が大きいですが、デメリットよりメリットの方が大きいだろうとの
判断で、自動ダウンの機能に制限入れました。UPされてないと自動ダウンが開始しません。

自動ダウンは確かに便利だと思いますが、無条件で起動されると下流側への
負担が大きいですし、この機能は無くても問題はないので、報酬として利用すると
良いのではないかとの判断です。

自動ダウンにより特化させるのであれば、基本的に下流からのみくる転送キー
だけでなく、自動的に上流にクエリ投げて検索キーを拾ってくれば良いのですが、
自動ダウンで指定されているキーでのクエリを全部投げなくてはいかず、
検索側が間違いなく溢れます。今の自動ダウンなら、まったく検索クエリ出さずに
たまたまキー転送中に見つけたキーにダウンかけますので、検索のトータルの
負荷は下がります。

今回入れた自動ダウンの制限も、通常の検索は問題なく行えますし、
UPフォルダのファイルは人気があれば連続で吸い出されていきますので、
結果的に自動ダウンが自由に使えるということで報酬ということにしておきます。
単純にDOMってキャッシュ消している人にはこの機能が使えなくなります。

あと、β14はこの辺の調節しようということで、参照数のトータルが見えるように
なっていたり、他ノードの参照値を他ノードが知れるようになっています。
まだ見れるだけでこれらをどう使うかは様子見しながらですので、
何かよさげなアイデアあったら教えてください。


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
正直、忙しくってこっちやってる余裕があまりないです。
6月までこんな感じだと思う。

夜中にこれの開発やって昼間どうでもいい仕事やって後はぬぼーと寝てて(w
残った頭使う仕事を土日にまとめて片付けてる気が(^^;


592 名前:47 投稿日:02/05/25 20:03 ID:nxBNME4e main/1022321547.html#38
ポートチェック関連はβ12のころからほとんど変わっていませんので、
ネットワークが込みだしたとか忙しいノードが増えたなどの他の要因が
大きいはずです。この辺は調べるのに手間がかかるのですいませんが
後回しになっています。WANではなく、閉じた環境で試さないと
理由がわからないかもしれません。

正直、開発だけなら簡単なんですが、現状で一番困っているのがテストでして、
報告されてもこちらでは再現性がなくどうしようもないのが多くて困っているのが現状です。

ただ単に落ちたとか動かないだとか遅くなったといわれてもこちらの
モチベーションが下がるだけですので、すいませんが、これこれ
こうすると確実にこうなるという報告していただけると助かります。


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
あと帯域制限は申告落とせば同じだと思いますがだめですか?
上流だとどうやっても回線とCPU消費しますので諦めてください。

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
人気の無いファイルはどちらにせよ交換が一番で
システムがどうあれレアなものはこれ以外では無理だと思いますが、
交換だとどうしても1対1になって匿名性維持が非常に困難です。

ただ、前にも書いたように暗号化を工夫すれば匿名性維持した状態で
交換も可能だと思いますし、実装案も考えてはいて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です。単にバグ取りです。

・ノードバッファの大きさを固定(上で出ている不祥事が防げるんではないかと)
・キーのロックミス修正(リフレッシュで変な挙動したり
他のダウンでダウンロードがキャンセルされたりするのを修正)

時間が無いし、あまり慌てて他のバグ作っても問題なんですが、
(つーか、これから明日締め切りの仕事を徹夜であげないとならんのですが(^^;)
後者のバグがかなり致命的だったので早めに公開します。

例のダウン中にリフレッシュするとエラー出るということで???だったんですが、
ロック状況を表示させて確認してみたら、キーのロッキングに抜けがあったためでした。

キーのロックというのは、ダウン作業などキーを消されるとまずい場合に
これをロックして削除などできないようにしているところなんですが、
キーの上書き生成部分でこのロック確認が抜けていたので、
隣からダウン中のキーと同じキーをまた受け取ると
上書きしてロックが外れてしまうという凡ミスでした。

ダウン中に他のダウンではじかれてしまうなどもこれのせいだと思います。
他にもいろんな不祥事を起こしていたはず。

なお、プロトコルはβ14共通です。


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化して検索やキー追加操作を高速化
・ キーの指示を全てハッシュで行うようにして違うものがダウンされないようにした
・ 帯域制限を外せるようにした
・ 自動ダウンの負荷を低減
・ 表示の際の無駄な検索を省略することで、CPU負荷を低減
・ 参照数で表示をソートすると参照ブロック数でソートになっていたのを修正

今回で大きな変更は1番目のもので、キーの管理方式が根本的に変わりました。
いままで可変長配列で管理していましたが、キーが増えてくるとキー追加と
検索にかなりの時間を取られてきていたようですので、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
1万超えても耐えられるんなら今の方式で地道に動作安定させていったほうが
あとあとよさげですね。例のファイルの参照数見たら2000超えてるってことは
参加者が楽に1万いってそうなんで(キーの参照値は全体でなく、各キャッシュの最大値)、
そろそろキーの流通量を増やしていかないとロストキーが問題になり始めるはずです。

てなことで、早めに今の方式で動作安定させましょう。少しお待ちください。
とりあえず帰って寝ます(w

606 名前:47 投稿日:02/05/29 20:22 ID:eCmG9DCv main/1022321547.html#929
β14.4です。プロトコル互換です。

・ 自動ダウンにファイルサイズ制限追加
・ 検索リンクと転送リンクを同じノードに接続すると転送リンクが切断されることがあるのを修正
・ 接続にいったリンクを自分で即断してしまうことがあるのを修正
・ キーのブロック状態表示関連で飛ぶことがあるのを修正
・ 帯域制限無し時に10ブロック毎に転送指示することで転送速度向上
・ 自動ダウンの制限を緩くした(UP無しでもダウンがかかります)
・ 参照数が変なキーやハッシュが0なキーを無視するようにした
・ ホストバッファ溢れに対する処理追加
・ ヒープ領域を明示的に開放するようにした

一応新機能として、自動ダウンでのサイズ指定がありますが、
メインはバグ取りです。例のメモリ周りの修正もありますが、
今回のではダウン周辺を時間かけて再チェックしましたので、
ダウン率が上がるんじゃないかと思います。

ああ、あと自動ダウンがUP=0でもスタートするようになってます。


607 名前:47 投稿日:02/05/29 20:43 ID:eCmG9DCv main/1022321547.html#938
そろそろユーザ数1万超えみたいなんで
(バグかと思ったけどちゃんと数千ヒットのファイルがあるみたい)
例のクラスタ化考えないとまずそうだけど、
その前にいつ正式版になるんだというのはありますね。


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超えるような大きなファイルの扱いとかですかね?

それか、早めにクラスタ化の作業を開始しますか?
今だったら自動ダウンに登録された単語を利用することで、
ある程度効率的にいけそうな気もしてるんですが。

基本的に前にシミュの画面で出したような、検索リンクに上下以外に左右を加えることで
縦方向は今と同じ形態で横方向に大きく広がった、ただし下には同系統のノードのみがぶら下がる
ネットワークになると思いますが、前に出したような単純なリング状としてのトポリジだけではなく、
自動ダウンの単語を利用することで、綺麗にクラスタ化できるんじゃないかと。

既に自動ダウンで狙ったものだけ落せるようになってきているとは思いますが、
人が増えてきて遠くのノードのファイル(何度もリンクを上下に追っていかないと
たどりつかないノードにのみあるファイル)はダウンできないはずで、
検索リンクで偶然近くに繋がるのを待つしかないのが現状のはずです。
自動ダウンも下流にターゲットのファイルを持つ人が現れないと起動されません。

ですが、この機構を入れることで似た傾向の人が集まってきてノード的に近傍に
来ることになりますので、転送で同系統のファイルが転送されやすくなって、
キャッシュの無駄が減るはずですし、自分が登録している系統のファイルに限れば
見つからないファイルが極端に減って落しやすくなるはずです。

基本的に検索リンク部とクエリ部の多少の変更ですむので、
動くようにするだけだったら2週間もかからんはずですが・・・


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
そういえば

> ただし、破損検出だけで修正はしません。

これは冗長な情報もたせてエラー検出だけでエラー修正はしないという意味ですので
もちろん他のキャッシュから読みに行けば修正はできます。ただ、他のノードの
キャッシュも壊れていたりするとやはり破損が検出されますね。

今ですとUP時とキャッシュをダウンフォルダに展開するときしか
ハッシュチェックに行きませんが、転送で落とし終わったときも
チェックだけかけた方がいいかもしれません。

と、いかんと。


615 名前:47 投稿日:02/05/30 23:25 ID:pujGfO1u main/1022679290.html#189
β14.5です。互換ありです。

・ 操作系としてポップアップメニュー追加
・ ダウン中のキャッシュや部分キャッシュでも変換可能にした
・ 部分キャッシュ表示の切り替え機能追加
・ 一回のレジュームで一つの連続ブロックしか直せなかったのを修正
・ 同じキーに対する分割ダウンを同じノードに複数かけられなくした
・ 接続停止状態で再起動して接続開始した場合にポートを開いてなかったのを修正
・ ダウンリスト追加すると自動的に自動ダウンONになるようにした
・ キャッシュサイズ算出で小さいファイルばかりだと算出が変なのを修正
・ キーの寿命を少しだけ短縮
・ 表示が残る処理済タスクを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
ああ、あと見かけ上完全だけど変換すると部分キャッシュに化けることが良くあるはずです。

キャッシュヘッダにはどこのブロックが壊れているかという情報が入っていますが、
これが実際に整合しているかどうかは、ファイル全部を見に行かないとだめで、
数百Mのファイルだとこの整合性チェックだけで分単位の処理かかります。

だから、ファイルの同一性チェックにはとりあえずファイル先頭とサイズだけ使って、
全体の整合性チェックは変換作業時のみになってます。
変換作業開始することで、初めてブロックハッシュと実際のブロック内容で矛盾が見つかって
完全キャッシュのはずが部分キャッシュになるわけです。



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)にした

小変更ですが、検索リンクがプチプチ切れていると自動ダウンがハングする
ことがあるというそれなりに致命的な問題点があったのでバージョン上げときます。

あと、最近は自動ダウンのおかげで検索負荷が下がっているので、
検索でヒットできる数を上げときました。そもそも検索結果は200しか
表示しないのであまりヒットする単語での検索は無意味なのですが、
たくさん溜め込んでいるノードがあると見えない可能性もあるので変更しておきました。

自動ダウンのヒット率はゆっくり全部のキーを上流に流して別のメカニズム
なので変わらないと思います。


626 名前:47 投稿日:02/05/31 14:31 ID:SkFMp1gY main/1022679290.html#323
破損対策は暇見てやります。そんなに難しい問題ではないですので。

あと、掲示板は今はやる気がまったくありません。今の2chでいいと思ってますし、
これ以上の使い心地は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
んー、個人的には人のソース見てよりよくするほうが1から組むより
スキル要るんでソース公開して意味があるぐらいならその人がもっと
いいもの組んでくれと思っちゃいますけどね(w


628 名前:47 投稿日:02/06/01 21:05 ID:5A6UCmRW main/1022679290.html#503
昨日今日と雑用が多くて作業が進行しとらんです。
つーか、職場でこれ作ってるのばれたし(w

また仕事が一つ増えたし、ちょっと余裕ないですねぇ。
気長にお待ちを。


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です。互換があります。

・ 転送完了時にもキャッシュ整合性チェックを行うようにした
・ キャッシュ送信時にもキャッシュ整合性チェックを行うようにした
・ 分割ダウン時に同じ個所のブロック要求を出しやすいのを修正
・ 分割ダウン時にダウンするノード選択を誤ることがあるのを修正
・ クエリの結果でキーの暗号キーが判明していても表示しないように変更
・ 自動ダウン時の不正なキーのチェック強化
・ タブ幅処理を修正
・ 再試行時にタスク表示が消えることがあるのを修正
・ 自動分割ダウン機能追加

今回のは主に大きなファイルの扱い周りですが、ちと議論になりそうな機能追加もあります。

まず、基本的にキャッシュの破損がそのまま広まることが無くなるようにしました。

転送終了時にも展開動作(チェックだけ)しますし、キャッシュのアップ時にもブロック送信時に
ハッシュチェック入るので基本的に壊れたデータが送られてくることはありません。
ただ、キャッシュフォーマット変えてなくて、検索で拾ってきた暗号キーで試し解凍してるんで、
状況によってはチェック無しで送られてくる可能性があります。この場合、今までと同じ動作です。
どちらにせよ展開時にチェック入りますから三重にハッシュチェックかかります。

その他、分割ダウン周りの動作が怪しくなっていたのでまた直しましたが、
今回重要なのは最後の機能でして、暫定ですが分割ダウンを支援する機能がついてます。

使い方はダウン時に右クリックで分割支持か、タスクで既にダウンしているものに
追加で右メニューから自動分割指示です。

何をするかというと、その現在落としているキーが他ノードからも重複して落とせるのであれば、
自動的にダウンロードタスクを発行します。キャッシュの検索で黄色くなったら自動的に
ダブルクリックすると思ってください。MXで言えば、自動的に投網する機能に相当します。
ちゃんとチェック入れて同じノードに投げないようになってるんでそんなに迷惑でも
ないはずですが、一応何か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に行った
時点で破損が見つかって完全キャッシュから破損キャッシュになります。
これにより各所でUPが止まるという現象がでるんじゃないかと思います。

少し待てば見かけ上完全な破損キャッシュは消せるはずですが・・・



633 名前:47 投稿日:02/06/02 22:42 ID:+QT9WZz3 main/1022679290.html#663
回線詐称していなければ高速回線の間に低速がくることはないはずですが、
まだ基本的な部分を上げている段階なので各調節は後回しになっています。
特に低速側は最後になるでしょう。中速→高速→低速の順で出来上がっていくと
思います。今はそろそろ高速側で使う機能(今回の分割DLや自動ダウンなど)
が出来上がりつつあるところではないかと。

634 名前:47 投稿日:02/06/04 18:17 ID:gfm0Tbz8 main/1022679290.html#810
ここんとこ忙しい(締め切り有りなのが2、さっき一つ終わった、
んで、締め切りがあいまいなのが3つ、うち一つは超巨大プロジェクト)
なんで流れを追いかけきれてませんが、

今のバージョンで変なデータが流れるとしたら先頭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公開しようかとおもったんですけど
テスト不足が怖かったんでやめたんですが(w

とりあえず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に書いてあるノード情報で
ノードバッファを初期化します。んで、1秒に1ノード接続に行きます。
この接続動作は、検索リンクが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サーバントそれ自身になります。

1つのホストには複数の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はもう少し寝かせときます。

思ったより簡単な変更ですんでまして、検索に使うハッシュ値がファイル全体
(正確には全ブロックハッシュから生成したハッシュ)になるだけです。
キャッシュのフォーマットはほとんど変えなくて済みました。

この全体ハッシュ関連は、作ってる最中に面倒になって途中で妥協して
手抜きしただけ(格納する場所はちゃんとキャッシュヘッダに作ってあった)
なんで、結局全体ハッシュを求めるのが面倒でここだけ後回しにして
問題が発覚するまで放置したことになります(w
(1G近いファイルだとここの処理だけで数分かかるんで、
これを問題にならないように処理するのが面倒で手抜きしてた)

そんなわけで今度のでは、どんなに大きいファイルでもどこか一バイトでも違いがあったら
ハッシュの値が変わって検索時点でファイルの区別がつくことになります。

なお副作用で、UPファイルの参照数がちゃんと保存されるようになってます
(処理的にはUPファイルに対応するキャッシュヘッダを先回りして作っているだけなので)

あと、現状で旧ハッシュは破棄ではなく、バージョン違いという扱いになってます。
当分は同じファイルでVer0.1と0.2キャッシュが混在することになりますが、
ユーザさんの方でできるだけ0.2の方を落すということで。
小さなファイルならVer0.1キャッシュでも問題ないでしょうし。

さて、次何しましょうか?

破損問題はこれで終結するはずですが、キー周りの扱いでしょうか?
正直、クラスタ化早くやりたくて仕方ないんですけど(w


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
クラスタ化に関してですが、非常に簡単な対処法を思いつきました。

クラスタ化の基本的な考え方は、同じ傾向のファイルを持っている人を
検索リンクで近くになるようにノード配置することです。
似た傾向のノード間距離が短くなり分野ごとにノードがクラスタ化されます。

前考えていた実装法では、今の二種類のリンクの他にクラスタ間通信用のリンク入れて
この間でキーやノード情報をやり取りするというものでしたが(例の曼荼羅の図)、
よく考えて見ると、今のノード情報のやり取り機構のところが既に似たようなことをやっている
わけですので、ここを発展させてネゴの時に、クラスタ化情報を一緒に渡してあげて、
この情報で相関の高いノード間を優先して検索リンクで繋げてやれば
それで済むんではないかということに気が付きました

具体的な実装ですが、まず自動ダウンで使っている単語の先頭三つをクラスタ化のための
情報とみなし、接続のネゴ時にこれを交換しておきます。これで、速度などの情報と一緒に
クラスタ化情報が得られますので、自ノードの情報と突き合わせてノード毎に適当に
評価値を決めソートかけて優先度の高いものから順に検索リンク接続に行きます。

もしノード情報を他のノードに教える時(自分の検索リンクが限界だったり速度差がある場合に発生する)
は、依頼ノードと相関性の高いノードだけを手持ちのノードバッファから抜き出して教えます。

これにより、検索リンクで近傍にいるのは自動ダウンの単語傾向が似たノードになりますので、
転送時に興味ない分野のファイルを中継する可能性が非常に少なくなります。

また、保持されているキーも近傍ノードで同一傾向のものがクラスタ化されますので、
目的の物が見つからないということも減るはずです。分野の数も1つではなく、
検索リンクの数だけ発生しますので、重複のある分野でも問題なく扱えます。

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文字)にできるはずです。今と違い、キャッシュのファイル名は
キャッシュヘッダ内部に移ることになります。

ただ、これは実際にこうなるかまだわかりません。何か問題があってβ1で
こうしたはずなんでやってみて見落としがあったらやめます。

と、現状はこんな感じです。

現状、周りに忙しい忙しい言いつづけた結果デッドロックして、他の用事が忙しいんだろうと
思われて用事が回ってこないで実は暇と言う状態なので(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
すいません。検索リンクの切断タイマーのところがLANのテスト用の
ままだったので20秒程度でぶちぶち切れることが多いはずです。

β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
前に出ていた検索リンク数が凄くなる病気がまた再発しやすいはずですけど、
安定するまで我慢してください。無条件に切るとクラスタ化にならんので、
わざとです。様子見てパラメータ調節します。

あとクラスタ化ですが、手持ちのキー(キャッシュかUPに限る)に
できるだけヒットする汎用的な単語指定したほうがいいはずです。
そうでないと検索リンクが切れやすいはず。

ただこれやると無駄なダウンが増えるんで、
暫定的にファイル範囲で調節してください。




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通りで重複がある)と
優先度が上がります。あと、その単語で手持ちのキーに検索かけてみて
ヒットするようならやはり優先度上がります。

あとは優先度順でソートして優先度が大きいものから優先的に
検索リンク接続に行きます。ただし、接続すると1ずつ下がっていきます。

始めの構想では、横方向の検索リンク作ってここに情報を流す予定でしたが、
どうせ検索リンクはプチプチ切れるわけだし、それを見越してキーをノードにもたせて、
ノードが新しく検索リンクで繋がることで、キーを交換して媒介させるという考えです。

重要なのは、似た傾向のノードが検索リンク張ることなんでこうなってます。
検索リンクは切れてしまっても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と互換があります

・ 検索リンク切断で、そのノードのダウン情報がクリアされていたのを修正
・ まだダウンが終わってないのにダウンリストが消えることがあるのを修正
・ 別のものをダウンしているように見えることがあるのを修正
・ ノード優先度で単語間マッチしているのに評価されないことがあるバグを修正
・ キーの暗号化が解けずにそのまま表示されて文字化けすることがあるのを修正
・ ダウン終了時に変換タスクが起動されないことがあるのを修正
・ キー削除時にクラッシュすることがあるのを修正
・ キーロスト切断発生がおき難くした

昨日が徹夜だったのでいつのまにかキーボード抱えて寝てましたが(w
変更量が多いために致命的なバグがたくさんあるのは判っていたわけで
一度寝てから公開すべきでしたね。

まだたくさんバグがあるのは分かってますが、致命的なものが多いので
順次公開していきます。せっかくの新機能がそれのせいでまったく意味なくなってる
バグだらけでした。UPフォルダ周りの不祥事はこれから直します。

こういうP2Pアプリは手元のテストだけでは動作がわからないで、
公開して動かしてみないと判明しないバグがあるんでやっかいです。

とりあえず、バグはまだまだあるとは思いますが、
致命的だと思われるものを優先的に報告お願いします。



665 名前:47 投稿日:02/06/15 10:10 ID:pkXAyM13 main/1023290054.html#935
キーバッファクリアが一秒1つになってた。怖そうなんで直しときました。
すいませんが、既にβ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では運送屋さんで暴利をむさぼれるわけです(w

と、こう考えるといろいろアイデアが出るんじゃないかと思うので、
暇な方は何か面白い案考えてみてください。こちらは当分はバグ取りやってます。


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
ファイルが断片化しているのは、プログラムをシンプルにするためで、
OS任せにしてしまっても問題ないだろうとの判断なんですが、
あまりシーク動作がひどいようだと全体の動作速度が落ちるんで、
そろそろファイルアクセス周りの最適化作業に入ってもいいかもしれません。

CPU処理の方よりそろそろディスクアクセスが全体のネックになってくるはずですし。
ただ、処理が複雑になるのでバグが出やすくなります。ファイルの閉じ忘れなんかです。
とりあえず暇見て簡単なところからやりましょう。

671 名前:47 投稿日:02/06/16 16:02 ID:k6DaC6Ig main/1024117422.html#129
β15.3です。互換ありです。今回はバグ取りは無しで、実験的な要素が大きいものです。

最近のバージョンだとUPや転送は軽快なんですがダウンが遅めなんで帯域の最適化し直さんと
と思ってたんですが、よくよく考えてみるとやはり諸悪の根源は自動ダウンで、
回線詐称もこれが原因なはず。

ここで、今までの自動ダウンですと、下流からきた申告してきたキーを横取りして
落とすというメカニズム上、上流からキーに自動ダウンかけることがほとんど
なかったわけです。
(つまり、今までの自動ダウンは転送される予定のキーを先回りして落としていたのに近い)

ですが、β15で、ゆっくりですが自動ダウンで上流にクエリが行くようになりましたし、
下流からきたクエリのリターンが上流から下流に帰る時にこのキーを横取りしてやれば
上流のキーも得られるわけで、試しにこれやって、キーを上流優先ダウンさせるとどうなるのか
実験してみようかというのが今回のバージョンです。

今までですと、自動ダウンは下流にかかって、上流でUP動作かかるのは
ほとんど手動検索とそれにより発生する転送動作でしたが、
今回のでは自動DOWNは基本的に上流に対してかかりやすく、
UPが下流ノードに対して行われやすくなることになります。

Winnyの概念から言うとこちらが本来の動作なはずですが、自動ダウンが出てきたことで
いつのまにか逆になってしまっていたので、これで自動ダウンが入る前の帯域分布
状態に戻って、UPよりDOWN側のほうが帯域幅が多くなりやすいはずです。

上流のほうがリンク確保数も多いのでコネクション限界エラーも出にくくなるはずですし、
上流で回線詐称してると耐えられないはずなんで今より状況がよくなるんではないかと。

なお、設定のところで、下流キーにダウンかけられなくできますし(標準でON)
これがOFFでも、常に下流より上流側に優先的にダウンがかかります。

とりあえず転送動作の発生確率なども変わると思うんですが、
どうなるかは実際にやってみないとわからないんで、実験よろしくです。
β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
起動時に重い人は回線接続OFFにしておいて
キャッシュチェックやUPファイルチェックが終了してから
接続ONにしたほうがいいと思います。

標準でこういう動作にしたほうがいいかも。

回線申告が大きな人とキャッシュを大量に持っている人と
大きなファイルをUPしている人が特にそうですね。



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を1つしか使わないので、ネゴが終わるまで
転送リンク接続か検索リンク接続なのか判明しません。
そして検索リンクは1ノード1つですが、転送リンクは複数許されます。

で、転送リンクは始めのうちはネゴが終わってない検索リンク扱いされます。
問答無用で重複している検索リンクを切断すると転送が開始しません。
これのためにわざと重複切断を遅くしてあります。昔のバージョンで転送リンクが
プチプチ切れて転送開始しなかったのは主にこれが理由でした。


676 名前:47 投稿日:02/06/16 23:35 ID:cv1JyEFJ main/1024117422.html#199
と、下流42ということは別の理由で、クラスタ化のために限界超えた
検索リンク切断が、上で書いたのと似たような理由で遅延するので、
固定ノードなどだと人気があってそうなると思います。

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
とりあえず、上流でCPU負荷が高くなるのは、
β6以前でよく発生していたなつかしのクエリ溢れのはずですので、
対策としてクエリ発生率を落としときました。

すいませんがβ15.4落としなおしといてください。よろしくです。

そろそろ寝ます。


681 名前:47 投稿日:02/06/17 12:40 ID:xTSr85zE main/1024117422.html#258
β15.5です。単に不祥事対策版です。

極端にダウン率が下がっているようですが、調べてみると転送発生率が
凄くなっていて最悪自ノードに転送要求が戻ってきたり、複数のノードに
リンクがダブっていったりしているようです。

リンク繋がったのにカウントが0のまま止まるのは、ダウン先でも転送が発生して他への
ダウンが開始されてファイルを待っているために起きます。
これは、β15.3で実験的に入れたコード(上流キー優先にする部分)が原因です。

ということで、やはり実験的なもので無理だったかということで、
β15.4からβ15.3のこの部分を除いたのがβ15.5です。
アップ側とダウン側が取り替えないとこの不祥事が収まらないので
収束に時間がかかると思いますが順次取り替えてください。

一応上方キー優先ダウンはできますが、15.3や4と違い、強制的に
処理しないので、情報キーの数が少なくダウンがかかりにくくなると思います。
急いで落としたい場合以外はOFFにしといてください。デフォでOFFになってます。


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フォルダ周りの挙動書いときます。

1.起動するとまずキャッシュフォルダ内部の全キャッシュヘッダを読みに行く。
UPキャッシュも部分キャッシュの一種なのでここで読み込まれる。
また、先頭10ブロックしか持ってない破損キャッシュはキーとキャッシュファイルを削除
ただし、UPキャッシュだというマークがついていたらこれは行わない

2.キャッシュの読み込みが終わったら、UPフォルダ内のファイルを一度に一つ
ずつ順にチェックに行く。

3.UPファイルを読んだら、まず名前とサイズで手持ちのキーに検索をかけ、
該当するUPキャッシュキーがあったらそのUPキャッシュキーをUPキーに書き換える。
該当するUPキャッシュが無かったら新規UPファイルであるとみなして、
全ファイル内容のスキャンを行い、全ハッシュを求める。
また、UPキャッシュにかかれている更新時間よりUPファイルの更新時間が
新しい場合も、UPファイルに変更があったとみなして再スキャンをかける。

と、こうなってます。この機構は作ったばかりなのでまだどこかバグってる可能性が高いです。
特に3の部分ですね。余裕のある方は動作チェックお願いします。


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ファイルの方が優先なのは
β1公開直前に、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調節まだとやることはたくさんありますが、
そろそろ大変更項目が無くなってきたんで、7月頭までには正式版になるんじゃないかと。


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
数字入れ忘れた(w


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
なんか暇な方がいるようで本格的にβテストやってくれる方がいるようで助かりますが(w
ゴミファイル対策だけじゃなくてゴミキー対策もやらないとこれであふれてしまうようなので、
無視リストにかかった手持ちのキーも消すようにしときました。

ただ、完全に消すと負荷がすごいし違う問題もあるんで、多少はゴミキーが残ります。

結果的に無視リストに入っているとその転送も受けにくくなるはずです
(転送がかかる前にキーが消えて転送依頼先でキーロスト発生率が高くなる)

てなことで、β15.7(6/21版)となりますので、15.7落とし直しといてください。



707 名前:47 投稿日:02/06/22 01:59 ID:vwmqakWG main/1024117422.html#722
β15.8です。互換性ありです。単なる小変更です。

・ 自動ダウンのキーワード制限を半角4文字以上に変更(無効制限は2文字以上)
・ UP側タスクのタスクスライスを細かくした
・ 転送リンクタイムアウトを少し長くした
・ ノード情報のところに送信側デバッグ表示
・ ダウン中ノードの申告速度を表示


708 名前:47 投稿日:02/06/22 16:51 ID:wlTAQQeI main/1024117422.html#789
β15.9です。互換ありです。

どうも熱心なβテスターさんががんばっているようで
単純にフィルタできないようなキーを繰り出してくるので、
本来後回しにする予定だった無視ノード機能つけました。

・ 無視条件にかかるキーをたくさん送ってくるノードを無視ノードと扱い接続拒否
・ 無視条件にかかるキャッシュを空キャッシュ(再起動で削除される)にするようにした
・ 検索部での漢字コード後半での大文字小文字変換をチェック
・ 切断後、長時間たったノード表示OFFを取りやめ

無視ノード認定されるとBadPort0と似た扱いになるので、接続にいきませんし、
接続されても切りますし、他ノードにも教えません。Noderefに保存もしません。
また切断時にそこから来たキーが皆消えますので、ゴミキーの多くが消えます。
(処理負荷が高くなるので、完全には消してない)

これにより迷惑ノードは皆がフィルタすれば孤立するはずですが、
そもそも今回の機能は本来、単純な無視機能ではなく、クラスタ化の一環でして、
嫌いなファイルを持っているノードを遠ざけるという、負のクラスタ化でもあります。

ただ、負のクラスタ化の効果が強すぎて各ノードが分断される可能性もあります。
あるキー群を持っていると嫌がられて孤立することがあるということになります。
孤立しても同傾向のノードは繋がるのでクラスタ化されて別に集まるでしょうが。

とりあえず、βテスターさんの思惑にはまってる気もしますが、テストってことで。
おまけとして今回の機能を利用することで、ゴミキャッシュの整理もできます。

あと、ハッシュダウンだけにするという意見が出てますが、
キーワードで落とせるようにしているのは、ある狙いからですし、
今やってもそのバージョン使わない人がでるだけのはずなんで問題を後回しします
(昔自動ダウン制限入れたときもこうなった)

どうせこれやっても現状では狙って落とせないはずで逆効果の方が大きいはずなので、
プロトコル変わるまで少し待ってください。
それより今は新キャッシュ出回るの待ちでしょう。

どちらにせよ、ハッシュ無しでの自動ダウンは何らかの制限が加わる予定です。

あと、自動ダウンにかかる仮想キーを消さないというのも面白いですが、
試しにやってみたらキーバッファが溢れるだけ(ゴミキーのせい)だし、
そもそも後から自動ダウンに登録するのが目的であれば、
一度でもダウンに行ったキーは部分キャッシュとなってキー寿命が
無限になるのでキーが残っていて消えないはずで、部分キャッシュから
登録に行けばいいはずで既に実装済みの機能ということで、とりやめました。



709 名前:47 投稿日:02/06/22 17:13 ID:wlTAQQeI main/1024117422.html#794
>>792
キー自身は消えません(中身が0の部分キャッシュになる)ので厳密には消えませんが、
基本的にはそうです。

無視指示しておけば、転送もしないですみますし、キャッシュも消費しませんが、
その代わりその拡張子のファイルは自分でダウンもできなくなりますので、
絶対このファイルいらないというもの以外、拡張子指示はやめたほうがいいでしょう。

そもそもあまり汎用な単語を無視リストに入れていると、
他と検索リンクが繋がらなくなって孤立する可能性が高いです。


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変えてる最中に思ったんですが、回線速度速くてもPC早いとは限らんわけですし、
自動ダウンメインのいまですと検索ボタン使う人あまりいないだろうから、
開き直って検索クエリはおまけと開き直って、上流へも下流もキーのやり取りを
キー転送メインにしてしまったほうがいいかもしれません。

上流も下流も保持するキー数は1万程度に固定で上下キーのバランスが
違うだけで、クラスタ同じなら持ってるキーもほぼみな同じという設計になります。
持っているキーがゆっくり周辺に伝播していくので、
ノードで近い人は似た傾向のキーを持つと。

少し離れたノードのキーを無理やり引っ張ってくるためにやはり検索機能は残りますが、
どちらかというとキーもったまま検索リンクが繋ぎ変わることによって、
ファイル名が伝達していくという普通のファイル共有ソフトの常識から外れたもの
(ファイル検索をあきらめる)のほうがいいのかもしれません。

全部が今の中流のような動作になります。
上流と下流の差は転送依存関係程度とクエリ出したときの違い程度になります。

こうすると上流で自動ダウンによるクエリを発行する必要ありませんし、
下流でもキーが無くて困ることはありません。

簡単なんでβ16で試してみます?


717 名前:47 投稿日:02/06/25 01:49 ID:K/AvW/0y main/1024847166.html#90
β16です。互換性ありません。

・ 自動ダウンによるクエリ発行をやめた
・ キー転送で連鎖的に遡るのをやめて上下とも隣接ノードにのみ転送する方式にした
・ キー転送率の上昇、キー寿命の延長
・ UPキーが暗号化キー名で上書きされて見えなくなっていたことがあったのを修正

プログラム的には数行の変更ですが、キー管理周りの概念がβ1以来の大変更になりますので、
間違いなくトラぶります。キーが出回りすぎるか逆かのどちらかになるはずなので、
直ぐに調節かけます。

ただ、今回の方式ですと、一つの検索リンクに流れるキーの数が常に同じなので、
上流下流に限らず検索リンクで発生するトラフィックは検索リンクの数だけに依存します。
上下方向も同じです。ですので、キー伝播に関しては隣接ノードに拡散していくことに
なり、回線申請値は関係なくなります。

β16ですと、一つのリンクに流れるキーは常に1秒に1つの割合です。1キーで100〜200
バイトのはずですので、1リンクあたり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です。互換あります。

・ キー転送率を回線速度に応じて可変にした
・ 検索リンク数の上方制限を4にした

キー少なすぎてヒット率に問題がありそうなので調節しました。

とりあえず、これ以上転送率上げると下流の人がキー転送で帯域取られすぎる
はずですので、上流と下流でキー転送率を可変にしてあります。
低い方にあわせるようになってますので、詐称してなければ問題ないはずです。

あと今ですと、検索のときしかクエリパケット飛ばず、
また手動検索はあまり使わないはずで検索リンク数が多くても
それほど問題にならないはずなので、
ヒット率向上目的で上方検索リンク制限が昔と同じ上下4に戻ってます。

こんなもんで、あとはキー寿命だけでキー流通量調節すればいいかなと。



721 名前:47 投稿日:02/06/25 18:09 ID:c1a7rQvS main/1024847166.html#149
今だと、上方向のリンク増やしたのが効いてるはずです。

とりあえず4→3にすれば収まるはず。あと、忙しくてクエリ溜まってると、
クエリが処理できないのに新しい送信クエリ発行して処理が追いつかなくなる
という現象が出てるんでしょう。これもクエリ数見て制限かければいいはず。

致命的なんで直したいんですが、職場のPCのVS.NET調子悪いしちーと待ってください。


722 名前:47 投稿日:02/06/25 20:22 ID:fMlIonaS main/1024847166.html#156
微調整バージョンのβ16.2です。互換あります。

・ 検索リンク数の上方制限を3にした
・ クエリが溢れている場合、キー転送をキャンセルするようにした
・ クエリ発行率を下げた(クエリの大きさは大きくなっているのでキー伝播率は同じ)
・ キーの寿命を延長

検索ではなく、キー伝播のクエリでバッファが溢れるようですので、それに対処しました。
突然落ちたりしてたのはほとんどこれ(クエリが溜まってくると処理が重くなって悪循環)
が理由のはずです。


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キャッシュ内に複数の名前を格納できるようにすればいいのでしょうが、
ちょっと無駄ですし対処が面倒です。重複検出したらログに警告出すという
程度ならできそうですが、この辺はまたキャッシュのバージョン変えたとき
に対処になるでしょう。最低、あと1回はキャッシュバージョンが上がる予定ですし。



725 名前:47 投稿日:02/06/26 09:41 ID:qh8bgT2n main/1024847166.html#194
とりあえず、キャッシュ破損が完全に無くなってはいないとは思いますが、
そんなに頻繁に発生することはないと思いますので、
それより先に検索率向上対策をやってからその後キャッシュフォーマット変えて、
バク取りやら細かい部分作り直して正式版になるんじゃないかと思います。

あと検索部に関しては、下流は今のままでいいと思いますが、
上流側はβ15方式の方がヒット率的によかった部分もあるのではないかとも思うので、
前書いた上流でクエリがスイッチバックするのと合わせてβ17でやってみようかと思います。

今ですと放置でのんびりクラスタ化を待つことになりますが、
これが実現できれば手動検索で自分から目的のファイル持っているノードに
近づいていけるようになるはずです。

今だと比較的忙しいので直ぐにはできないと思いますが、
手直しはほんの少しですみますので暇見てやりましょう。




726 名前:47 投稿日:02/06/27 11:59 ID:N8NMR2c3 main/1024847166.html#235
致命的なものが出たら対処しますが、明日明後日と某イベント出てますし
日曜も打ち合わせの用事あったり、来週もいろいろ準備と忙しいので、
ここ数日はろくにバージョンアップできないと思います。
よろしくです。

今のうちにバグレポ溜めといてください。


727 名前:47 投稿日:02/07/02 00:14 ID:etidc9y9 main/1024847166.html#444
Winnyとはまた別に作ってるソフト関連でここんとこ
仕事が連続で入ってくるので開発速度がどんどん落ちてます(^^;
(また一つ来たけど既に三つぐらい掛け持ちなんで断るしかないか)
Winnyだけやってていいんなら楽なんですが・・・

とりあえず今日の作業で、β17候補は出来ましたが、それなりの大改造で、
まだテスト結果が不安なので公開しないでおきます。

変更内容は前に書いた、検索ヒット率向上を狙うものです。

今までのVerですと検索パケットは上か下かにまっすぐいくだけですが、
β17では上れるだけ上ったら一度下がって又上がってを繰り返します。
クエリパケットが一定数ノードを経由するか、ヒットキー数が十分になったら戻ってきます。
これにより隣接クラスタ内のほとんどのキーを検索可能になります。

また今までですと、上方の検索リンクの分、検索クエリパケットが増殖していましたが、
β17ではクエリの増殖は起きませんのでクエリを頻発しても比較的上流で
クエリ処理で重くならない(はず)ということで、β15.3あたりで試した
自動ダウン登録内容からの検索クエリ送信も復活予定です。

β16ですと下流にキーが流れるようになったのはいいんですが、
上流でも下流でもかなりヒット率が悪くなってましたが、β17では
この二つの変更により、検索と自動ダウンでのヒット率がかなり良くなります。

LANでやっているノード数十でのテストの結果では、全ノードに違うファイル持たせて、
全ノードに全ファイルダウンを自動ダウンで指示して放置で、最下流から最上流まで
回収率100%を実現できてます(全部のノードのファイルを全ノードで回収可能)。

実際のダウン率は全体の混み具合によるので、ダウン率それ自体はβ16と大差ないはずですが、
ファイルを見つけられる率と自動ダウンでのヒット数はかなり良くなるはずです。

ただ、クエリパケットの転送が複雑になった都合でどこかでクエリ転送のループか何か
発生しているらしく、ダウン終わってるのに謎の通信量増大発生したりしてまだ動作チェック中です。
明日も明後日も用事あるんでいつ公開になるかわかりません。少しお待ちください。

ここんところプログラム変更は一瞬で終わるんですが、動作テストに時間がかかりますねぇ。


728 名前:47 投稿日:02/07/05 03:07 ID:SmEKLm3H main/1024847166.html#560
β17です。互換無いです。
キー管理周りが大幅に変わっています。

・ キー検索を最上流で上下にさかのぼるスイッチバック方式に変更
・ 上流へのキー転送をβ15の最上流まで伝播する方式に戻した(下流はβ16と同じ)
・ 検索時に検索パケットが上流リンク方向で増殖するのをやめた
・ 自動ダウンでヒットキーが無い場合、上流にクエリを出すのを復活
・ 接続優先度がマイナスになっても接続を切らないようにした
・ UP転送リンクによる自動ダウン制限を復活
・ 転送リンク接続できたホストは優先度を増やすようにした
・ 転送の発生ルールを変更(Port0関連)
・ ダウン条件を2文字以上に戻した

ここにきてβ16以上の大改造なんでまたトラぶりそうですが、
ちゃんとこれでチューニングしてやればβ14〜16のいいところ取りできるはず
なんでテストお願いします。キーがどの程度の分布になるのかやってみないと
わからないので、様子見て調整します。

729 名前:47 投稿日:02/07/05 03:39 ID:SmEKLm3H main/1024847166.html#572
全体的に上流へのキー流出が少なめのようですので、
パラメータ変えときました。すいませんがβ17読み直しといてください。

今回のバージョンで狙っているのは、キーのヒット率向上です。

730 名前:47 投稿日:02/07/05 13:42 ID:SmEKLm3H main/1024847166.html#596
β17.1です。

使用条件が各自いろいろだと思うんでキー数の調節が難しいんですが、
下流方向のキー転送が少ないようなので増やしときました。

前だったらここまでキー転送量を増やすと間違いなく溢れていたので、
キー削除がかなり効いてるんだと思います。みんなでキー削除やめると
また溢れるんじゃないですかね?

あと、さっぱり転送やUPがかからないところをみると制限復活させたのが
効きすぎているようなので少し緩めてあります(+2)。


731 名前:47 投稿日:02/07/05 19:45 ID:0mwXDge3 main/1024847166.html#637
β17.2です。微調整です。

・ 上方接続リンクが制限を越えたときに無条件切断が起きるので修正
・ キー寿命延長&転送率低下により、転送リンクの通信量を減少
・ 検索クエリの到達距離を短くした(検索リンク切れで戻ってこないため)
・ 仮想キー数限界を上下10000に落とした
・ 下方のキー転送で転送されないことがあるのを修正
・ UPキーハッシュの再チェックを起き難くした

メカニズムがかなり変わっているので、動作安定するパラメータが
見つかるまで少しかかると思います。最終的には今までで一番良いところまで
もっていけると思いますので、すいませんが我慢して付き合ってください。

とりあえず今ですと、キー量はいいんですが、キー転送で発生する転送量が
多くてこれで転送リンクを圧迫している状況みたいです。
そんなわけでキーの寿命をかなり長くして対処してます。

あと、せっかくの新機能である検索部の変更も、検索リンクがプチプチ切れるんで
クエリが戻ってこなくて無意味になってることが多いようなので、微調節してあります。

まだ調節すべきところはたくさんあるのですが、とりあえずあまり変更してしまうと
何が悪いのかわからなくなりそうなんで公開しておきます。

732 名前:47 投稿日:02/07/05 22:01 ID:0mwXDge3 main/1024847166.html#647
今度はキーの下降率が高すぎ&寿命長すぎみたいです。
調節しておいたんで、すいませんがβ17.2読み直しといてください。

パラメータ以外は同じです。みなが取り替えないとだめなので
影響が目に見えるまで数時間かかると思います。

733 名前:47 投稿日:02/07/05 22:12 ID:0mwXDge3 main/1024847166.html#650
あと、なぜかコネクション限界が出やすくなってますが、
今までUPできなかった人の所にコネクションが集中してるんじゃないかと思います。
UP0周辺の動作が変わってるんで転送のかかり方とかかなり変わってるはずです。

734 名前:47 投稿日:02/07/05 22:32 ID:0mwXDge3 main/1024847166.html#655
失礼しました。変えときました。

735 名前:47 投稿日:02/07/07 04:47 ID:ZK8ZqaNw main/1024847166.html#769
やっと二つ目の仕事あがったけど、来週は丸々出張です。
とうぶんこっちはやってられませんのでよろしく。

ところでどうもβ17系の方が調子悪いようなので、破棄してβ16.3に戻しますか?

β17で調子が悪いのは、単に各バランスが悪くて処理が追いつかないで
送信が追いつかないで落ちるという可能性大ですが、これは対応が面倒です。

キーが出回っても落とせないんでは、処理負荷が上がるだけで意味ないですし、
検索パケットが戻ってこられるように検索リンクを保持していると今度は
クラスタ化が悪くなります。

ただ、β16だと検索リンクの再接続率が多いので、通信負荷に弱い環境だと
飛んだりプロバイダに迷惑かかる可能性あります(ログとかとってればだけど)
β17の方が検索リンクが保持されるので多少はましなはずです。

根本的な部分はそろそろ変えようがなくなってきているので、
もしβ16.3が今までで一番調子良かったのなら正式版をこれに戻します。

一週間ほど放置になりますし。



736 名前:47 投稿日:02/07/07 05:22 ID:h/xpfaRq main/1024847166.html#777
β17の変更をやっててport0周りの問題点(Port0を経由するとそのキーがUPされにくくなる)に
気がついたので、これだけをβ16系にフィードバックして
β16.4として基幹部はフィックスでもいいかもしれません。

β17はβ15と16のよいところを組み合わせようと思ったんですが、
ダウン率が下がっただけのようにも思えます。単に調整不足な可能性もありますが、
キー転送クエリが詰まって、調子悪くなるノードが生じるというβ15の問題点を
そのまま持っているようです。下流にキーがいくだけβ15よりは良いと思いますが、
上流で詰まり安いという問題点は上流重視のキー流通である以上どうしようもないです。

β16が調子良かったことからすると、やはりキー流通は少ない方が調子が良いらしく、
キーの流通はクラスタ化頼みで、検索リンクにあまり頼らないほうがいいのかもしれません。

検索リンク切って他ノードのキー持ったまま他と繋がってくれれば
遠距離の通信を発生しないでもキー流通ができますし、
今の自動ダウンのメカニズムにはこれはこれであってます。

とりあえず、最近は他の用事が多くてβ17系を再調節する時間と根気がありませんが(^^;
β17.2はこのまま放置しておくにはデキがあまりよろしくない気がしますし、
β16系は特に近距離ノードとしかやりとりしないので、
どんなにノード数増えても状態が変わりにくいので放置するにはこっちのがいいかなと。

そもそも、β17でクエリが遠くまで届くといっても、結局検索リンクがプツプツ切れていたら
クエリが戻ってこなくて意味が無いんで、結局、近傍から確実にキーを取ってこれる
β16のほうが結果的に検索率が良くなるのかもしれません。

そんなわけですいませんがβ17を一旦破棄して公開サイトの方を
β16.3に戻しておきます。どちらを使うかは各自の判断に任せますが、
β17系を推す方がいらしましたら報告お願いします。
一部分だけ取り入れられる可能性はあります。


737 名前:47 投稿日:02/07/07 05:30 ID:h/xpfaRq main/1024847166.html#778
よく考えてみたらβ17の検索部は問題ないわけで悪いのは
上流でキーが詰まることだけなんでβ16に戻したβ17というのもありです。

変更が簡単なんで、β17.3として実験してみましょう。
これでもβ16.3の方が良かったらこちらに戻すということで。

そんなわけで少しお待ちを。


738 名前:47 投稿日:02/07/07 06:10 ID:GRhpv2xB main/1024847166.html#781
β17.3です。互換あります。

・ β15までで採用していたキーの強制上昇をやめてβ16の拡散方式に変更
・ キー寿命やキーの伝達率などをβ16.3と同じにした

ヒット率向上目的でβ15の要素を戻したのが悪さしているように思えますので、
これをやめてβ16.3と同じキー拡散方式に戻しました。キーの検索方式はβ17と同じです。

上流でのキー数が減るのでヒット率も下がると思いますが、
キー拡散でのんびりとしたキーの広がりとなるので、
全体的に落ちついた動作になるんじゃないかと思います。

検索部は遠くまで探しにいける方式のままですし、
β17系は自動ダウンの条件で上流に検索かけるのでβ16よりは検索率良いはずです。

なお、検索切断率が低いのでクラスタ化はβ16.3より悪いままです。
検索部の変更でカバーできると考えていますが、だめなようなら
ここもβ16に戻します。

とりあえず隣が17.3かどうかでキー数変わるんで時間がたたないと
影響がわからないとは思いますが、変えてみてどうなるか実験してみてください。



739 名前:47 投稿日:02/07/07 06:13 ID:GRhpv2xB main/1024847166.html#782
β17.2と違いこれで問題になりそうなのは、低速ノードからの吸出しできない確立が
増えるということなんですが、そもそも低速ノードからの吸出しはダウン率の低下に繋がるし、
下流の人がUP取られて何もできなくなるだけなんで目をつぶるということで・・・・

それより、Port0周りの動作を見直した方がいいんでしょうけど、
これは根性いるんでまた時間があるときにやります。

740 名前:47 投稿日:02/07/08 00:32 ID:LcTU3Xtn main/1024847166.html#850
明日から出張なんでとっとと寝ますが、β17.3でもだめですか?
ならβ17系は破棄して最新版をβ16.3に戻しますが。

741 名前:47 投稿日:02/07/08 21:15 ID:zHJlvVi8 main/1024847166.html#884
一応AirH''なり人のところの回線なりでネット見れてますが、Winny動かす
ことは流石にできないので、ここ数日は何か致命的な問題でも出ない限り
放置になります。よろしくです。

今のうちに動作の怪しいところをまとめて置いてください。
β16系に戻す可能性もまだあるといえばありますが、
そろそろ基幹部はどれかにフィックスして細かいバグ取りに入る予定です。


742 名前:47 投稿日:02/07/12 01:38 ID:2Ih+h33L main/1026249951.html#156
β17.4です。互換あります。

まだ忙しいので根本的な変更はできませんが、とりあえず上流のPort0詐称が
放置できなくなってきているようですので取り急ぎこれの対処しました。

・ 自ノードより高速なPort0リンクは一定時間で強制切断(転送リンクを含む)
・ クラスタが負の際の切断動作を復活させて、クラスタ化率向上

Port0ノードは高速申請するほど接続が困難になります。繋がらないわけではありませんが、
転送リンクが切れるのでPort0で高速申請すると使い物にならなくなるはずです。
Port0の方は比較的低速気味に申請してください。

なお、相手が高速でもUP側リンクは切りませんので、Port0のUP率が減少することはないはずです。
とりあえず上流がPort0ばかりになると極端にダウン成功率が下がる可能性があるので、
これで比較的ダウン率が良くなるんじゃないかと思います。

あと、複数起動に関してはまだ対処してません。
これはプロトコル変えるときでないと意味無いですし(昔のVer起動すればいいだけ)、
そもそも複数起動を封じないと破綻するようでは他で破綻するでしょう。
とりあえずこれに関しては様子見です。


743 名前:47 投稿日:02/07/14 02:42 ID:KsOkvb3x main/1026249951.html#302
β17.5です。互換性あります。

・ Port0切断の回線速度比較がバグっていたので修正
・ キー伝達率を増やした
・ 自動ダウン開始条件をUP+2→UP+1に減少
・ 多重起動を禁止

Port0周りでバグっていたので修正しました。
あと細かい調節してあります。
残りの修正はプロトコルバージョン変えないと
直せないものばかりなのでβ18になります。


744 名前:47 投稿日:02/07/14 10:10 ID:KsOkvb3x main/1026249951.html#329
β17.6です。β17系と互換あります。ここ一週間忙しくて無視してきてた
細かいバグや要望対策です。(ここのスレで要望まとめてくださった方、お疲れ様です)

・ 自動ダウンで完全キャッシュを再ダウンすることがあったのを修正
・ ダウン転送リンク数が限界に達していたら自動ダウンの検索をかけないようにした
・ 転送リンク限界最低値を3→2にした
・ 検索モードに切り替わったときに検索エディットコントロールにフォーカス移動
・ 検索右メニューで選択項目からダイアログ出して条件登録できるようにした
・ 検索結果で部分キャッシュでも自動ダウンに登録できるようにした
・ 同じハッシュ値の自動ダウン登録を自動的に無視するようにした
・ 検索結果の複数選択処理時に処理個数10個までという制限をなくした
・ ファイルの選択で時間が経ってキーロストしていると選択が変だったのを修正
・ 起動時のキャッシュチェック速度を高速化

まだ残ってる要望がたくさんあると思いますが、
あまりやると違うバグが増えそうなんでこんなところで。

基幹部での未対策項目もまだたくさんあって、まずUPファイル名変えるとハッシュ再チェックに
なったりするのもキャッシュフォーマット変えないと対応できません。
今の設計だとキャッシュ内にファイル名が埋め込まれてますが、
一つのハッシュ値に複数のファイル名が当たることがまったく考慮されてないためです。

あと本当は暗号キー変わったら全体ハッシュ値もそれにあわせて変わらないといけないはずですが、
Ver0.2ハッシュはこうなってません。これのため、暗号キー関連が怪しい動作になってるはずですです。
本来ならば出るはずの無い全体ハッシュ整合性エラーがでるのはこれが理由
(いろんな暗号のブロックが混ざる)でしょう。

β18ではこの辺の対処のために、またキャッシュフォーマットが変わって
Ver0.3(もしくは正式キャッシュのver1.0)になる予定です。
基本的なメカニズムはβ17でいけそうなのでこのままチューニングしていって、
β18もしくはβ19の後半で正式版候補(RC)になるんではないかと思います。

あと、最後まで無視してきたキャッシュ削除もそろそろ復活させてテストする必要があるでしょうし、
タスクトレイ常駐とかもやらんとまずいですね。まだ正式版までにやることはたくさんあります。

とりあえず今回の変更でバグ増やしている可能性もありますので、変更部分の動作テストお願いします。


745 名前:47 投稿日:02/07/14 23:38 ID:4JSwZFkT main/1026249951.html#395
β17.7です。β17系と互換あります。あまり変わってません。
β17.6でキー無視のところで致命的なバグがあったのでとりあえず直しました。

> ・ 自動ダウンで完全キャッシュを再ダウンすることがあったのを修正

これですが、β17.5に戻ってます。

一つのキーで無視条件とダウン条件両方ヒットするときが問題のようです。

無視条件でキャッシュが消えるけど、ダウン条件でもヒットして
同じファイルを延々とダウンしているのか?ということで修正したのですが、
今度は無視条件がキャッシュに効かなくなったようで。以前からダウン条件で
ヒットしても無視条件に入っていたら落とさないようになってるはずなんですが・・・。

とりあえず無視条件でキャッシュが消せないのは危険なので戻しときました。

あと、全体的にキーが上流から下流方向の流れになっていて
結果的に上流がUPばかりであまり落とせない状況になっているようですので、
上流方向への転送率を下流の二倍にしておきました。

もともと上流検索リンクのほうが数が少ないので、これで同じ比率になるはずです。
基本的に上流の方がキー流通速度が速いので、上流のほうがキー数が多くなる
はずですが、あまり多くなると今度はβ17.5以前のように全体の流れが悪くなるので、
上流でキーが溜まりすぎるようでしたら教えてください。


746 名前:47 投稿日:02/07/16 18:47 ID:NYbA8Exw main/1026249951.html#527
比較的、暇になってきたんでキャッシュフォーマット変えないと直せない部分を
まとめて修正中ですが、ちょいと新機能を思いついたので、これもついでにやってます。

そんなわけでβ18は少しかかります。今週中にはあがると思いますが、しばらくお待ちください。

具体的には特定フォルダに置いたUPファイルに外部ノードから追記する機能と、
ポート経由でWinnyネットワーク内のファイルを外部プログラムから参照する機能の二つですが、
これを何に使うかはちゃんと動いたらということで。

これ、本当はVer2でやろうと思ってた機能だったんですが、参照部はもうできてるし
基本部分は今のWinnyそのまま使えるんで、あとは追記部分だけで
思ったより簡単にできそうですねぇ。


747 名前:47 投稿日:02/07/17 14:19 ID:5ew0ocIV main/1026249951.html#588
例の新機能のかなりの部分ができましたけど、キャッシュ周りの大改造と
あと今までまったくなかった機能の追加なんでバグ取りに時間がかかってます。

ここまでできていれば、ほぼ動くと思うんでネタばらししてしまいますが、
今やっているのは<掲示板機能>の追加です。

前やらんいうてたやんけ言われそうですが、そろそろ大変更でやることも無くなって来たし、
比較的簡単な実装法思いついたんでβのうちに試しにつけちゃえということで。

とりあえずWinnyだと何がいいかというと、スタンドアロンのP2PBBSと違い、
ファイル共有がメインのプログラムで基本的に起動して放置な設計なので、ファイル共有目的で
起動されているノードをBBSストレージとして間借りできるということです←ここ重要

サーバレスのP2Pですと皆がプログラム止めちゃうとデータも全てロストしてしまいますが、
Winnyネットワーク間借りすればスレがロストしにくいんでいいかと。回覧版が
未だに流通していると思いますが、あれをシステム側で支援するような感じです。

ただ、ファイル共有側同様、完全鯖無しなんで負荷には強いと思いますが、
ベースはβ17と同じなんで、2chの置き換えなどの目的にはまず無理です。
匿名性重視であまり書きかえが頻繁でない用途専用でしょう。



748 名前:47 投稿日:02/07/17 14:19 ID:5ew0ocIV main/1026249951.html#589
基本的な考え方ですが、板という概念は今のところ無いです
(ファイルの種別と同じ扱いでファイル名で工夫かと)。

1スレ=1ファイルで、対応としては、ファイル共有側の

・仮想ファイル→仮想スレッド(落として読めるスレッド)
・UPファイル→自スレッド(自分で管理してるスレッド、他ノードとの競合無しでユニーク)
・受可キャッシュ→未読部分ダウン可能で書き込み可能なスレッド
・完全キャッシュ→全部読むのが可能で落とし終わってるスレッド
 (書けるかどうかやってみないとわからない)

こんな対応になります。分散BBSでやっかいなのはファイル変更の同期部分ですが、
今のWinnyでは誰かがUPファイルを持っているとその情報が回りまわって
部分キャッシュが受可キャッシュになって、受可キャッシュキーのIPを追いかけていくと
最後には完全キャッシュかUPファイルにまでたどり着けるというメカニズムを持ちますので、
このメカニズムを利用してもしBBS書き込みを行うと最終的にそのスレッドを
作った人のところまで伝わっていって、そこのUPファイルに追記されるということになります。
一見失敗しそうですが、今の差分ダウンに追記機能がつくだけなんで
そんなにひどいことにはならないんじゃないかと。BBSはファイル小さいですし。

とりあえずスレのキャッシュは全て元UPファイルのReadOnlyキャッシュ扱いになります。
UPファイル(相当の元スレファイル)が変更されると、これがキャッシュ経由で
広まっていくことになります。変更情報はキャッシュではなくキーとして
広まるので、落とせればほぼ最新情報になるはずです。

Winnyのブロック転送メカニズムで変更部分だけ読むので、読み込みに関しては
普通のBBSよりは負荷が低くなる(標準でキャッシュが効く)はずですが、
この実装だとスレに書き込むのが難しくなります。

結局、板単位でなく、スレ単位で各自が鯖立てているのと同じことになりますので、
スレを立てた人が落ちてしまうとそのスレは読み込み専用で書けなくなります。
このやり方ですと同期の処理が簡単ですし、スレ管理が簡単でして、
削除や変更はスレ作成者に全てお任せになります。

後は、UPファイル制限と同じようなスレ立て制限(1ノードで公開できるスレ数制限)と
既にあるキー無視機能の組み合わせで嵐対策することになります。

なお、インターフェイスは、Winny側にhttdもどきの機能をつけてここに
ブラウザでアクセスになります。ここは既に作り終わっていて、
参照や書き込みは既にできるようになってます。スレ一覧も出せるので、
BBS見るだけならブラウザ上だけでできます。

と、今のところこんな感じです。キャッシュのメカニズムにより
鯖無しP2PのBBSにしては比較的さくさく動くと思いますが、
とりあえずおまけ的機能ですね。



749 名前:47 投稿日:02/07/17 23:37 ID:PhnYv4lI main/1026249951.html#674
  γ⌒⌒ヽ
  ヾ) ノノノノノハ)    / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
   ヽノソ ‘ 。‘ノ   < はずしミスは水着になりまーす
    丶_●‐●    \_____________ 
      〉  , l〉    
     (~~▼~|)
      > ) ノ 
     (_/ヽ_)  


750 名前:47 投稿日:02/07/17 23:39 ID:PhnYv4lI main/1026249951.html#680
では、1000まで大耳モナーがここを嫌々管理しておきます。
早速やる気が無くなっていますが、特に問題はありません。
                        タリー
タリー      タリー
   (\_/)          タリー
   (  ´Д)    タリー              タリー
   /   つ  (\_/)   (\_/)ノ⌒ヽ、
  (_(__つ⊂(´Д`⊂⌒`つ(´Д` )_人__) ))


751 名前:47 投稿日:02/07/17 23:40 ID:PhnYv4lI main/1026249951.html#683
681げっとぉぉおおおおおお!!!!
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄       (´´
     ∧∧   )      (´⌒(´
  ⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡
        ̄ ̄  (´⌒(´⌒;;
      ズザーーーーーッ


752 名前:47 投稿日:02/07/17 23:40 ID:PhnYv4lI main/1026249951.html#684

从‘ 。‘从<Yeah!めっちゃホリディ

753 名前:47 投稿日:02/07/17 23:41 ID:PhnYv4lI main/1026249951.html#685
从T 。T从<♪リプレイ涙色
       ♪泣いてもないても泣いても外せない
       ♪あぁB−MAXで勝負したって事したくなかったな


754 名前:47 投稿日:02/07/17 23:48 ID:4jU74HhG main/1026249951.html#693
荒れてますね。

例の新機能のかなりの部分ができましたけど、キャッシュ周りの大改造と
あと今までまったくなかった機能の追加なんでバグ取りに時間がかかってます。

ここまでできていれば、ほぼ動くと思うんでネタばらししてしまいますが、
今やっているのは<掲示板機能>の追加です。

前やらんいうてたやんけ言われそうですが、そろそろ大変更でやることも無くなって来たし、
比較的簡単な実装法思いついたんでβのうちに試しにつけちゃえということで。

とりあえずWinnyだと何がいいかというと、スタンドアロンのP2PBBSと違い、
ファイル共有がメインのプログラムで基本的に起動して放置な設計なので、ファイル共有目的で
起動されているノードをBBSストレージとして間借りできるということです←ここ重要

サーバレスのP2Pですと皆がプログラム止めちゃうとデータも全てロストしてしまいますが、
Winnyネットワーク間借りすればスレがロストしにくいんでいいかと。回覧版が
未だに流通していると思いますが、あれをシステム側で支援するような感じです。

ただ、ファイル共有側同様、完全鯖無しなんで負荷には強いと思いますが、
ベースはβ17と同じなんで、2chの置き換えなどの目的にはまず無理です。
匿名性重視であまり書きかえが頻繁でない用途専用でしょう。


755 名前:47 投稿日:02/07/17 23:56 ID:4jU74HhG main/1026249951.html#695
P2Pでの掲示板機能は、今までのインターネット自体を
覆すほど、世界で最も最先端かもしれません。

実際、SOBAというP2P型ネットワークの実践が大学の研究などを元に
こないだ実用化に一歩近づいたとか、そういうレベルで、
Winnyで掲示板機能が確立すれば、おそらく世界で初めての
実践的な掲示板機能かと。

756 名前:47 投稿日:02/07/18 00:01 ID:LCFoYpmx main/1026249951.html#698

>>696

逝って良し!


    ,,,,,---''~~::::::::::::::::::::::~'''--''',-'-'',--,_
      ~'ヽ::::::::::::::::::::::::::::::::::::::::::::::::::ヽ;;Oヽ:::ヽ;
.        ヽ;::::::::::::::::::::::::::::::;::::::;;::::;;;;,,-;;;丿::::::ヽ   ∧
       ,,-''~~::::::::::::::::;-''-;;_/ヽ- ''~    ~'ヽ;:::::ヽ,_ノ:::ヽ
.      /::::::::::::::::::::::/             .ヽ:::::::::::::::::l
     /::::::::::::::::::::::/            .,-''-, ヽ::::::::::::l
.     l::::::::::::::::::::::/             !  .' .ヽ:;;;;;::/
     l::::::::::::::::::::::l   ,,-''''-,,             .ヽ ,-ヽ
     l::::::::::::::::::::::l  .!              .i'ヽ  .ヽ/ ./
 i'''-,,___l:::::::::::::::::::::l               .ヽ l    ヽ,
  l::::::::::::::/~~~'ヽ;::::l.     i'ヽ           ~ /~V .l
.  ヽ:::::::::l    \|     ヽ l    ''''~~  __,,)     ./ヽ__,,,_
   ヽ;::::::l  '''''ヽ,       ~    _,,,,,,--'''~ ./   ./ .l --')
     ヽ::ヽ    ヽ   ,,,_i'''-  '-<''      /  ,,/''~ __-~--'
.     ヽヽ,_             ヽ,,__ ,,-',,,-''~ _,, -'
       ~''''''''--,,,,,,,,--,,,,,,,,________,,,,,,--''''''~ヽ. /
        ,----,_,,,,,-'             ヽ,
        >- _           ,    ●  l
.       ,-',,-,~   _ -''''''― 、  ●      l
.       (,,-',,- /     ヽ            l
        ~'~'''~       i          l
.                     l          l
                  l    ./し| |ノ  /
                  /    /  U  /
.               //   /  ,-/,____/-,
               l ヽ, _,ノl   〉-,,____,,,ノ__,,,_
              ノヽ,_ ~  ノ  /:::::::::::::::-':::::::::~ヽ,
             /::::::::::~''''''~:;l  l;:::::::::::::::::::::::::::::::::::::i
            /::::::::::::::::::::::/,l.  '-~'''''---;;;____::::::::;;;l
.           l:::::::::::::::::::::/./    ~~''''''--,,,,,,,---'


757 名前:47 投稿日:02/07/18 00:02 ID:LCFoYpmx main/1026249951.html#699

>>697

チンカス。


    ,,,,,---''~~::::::::::::::::::::::~'''--''',-'-'',--,_
      ~'ヽ::::::::::::::::::::::::::::::::::::::::::::::::::ヽ;;Oヽ:::ヽ;
.        ヽ;::::::::::::::::::::::::::::::;::::::;;::::;;;;,,-;;;丿::::::ヽ   ∧
       ,,-''~~::::::::::::::::;-''-;;_/ヽ- ''~    ~'ヽ;:::::ヽ,_ノ:::ヽ
.      /::::::::::::::::::::::/             .ヽ:::::::::::::::::l
     /::::::::::::::::::::::/            .,-''-, ヽ::::::::::::l
.     l::::::::::::::::::::::/             !  .' .ヽ:;;;;;::/
     l::::::::::::::::::::::l   ,,-''''-,,             .ヽ ,-ヽ
     l::::::::::::::::::::::l  .!              .i'ヽ  .ヽ/ ./
 i'''-,,___l:::::::::::::::::::::l               .ヽ l    ヽ,
  l::::::::::::::/~~~'ヽ;::::l.     i'ヽ           ~ /~V .l
.  ヽ:::::::::l    \|     ヽ l    ''''~~  __,,)     ./ヽ__,,,_
   ヽ;::::::l  '''''ヽ,       ~    _,,,,,,--'''~ ./   ./ .l --')
     ヽ::ヽ    ヽ   ,,,_i'''-  '-<''      /  ,,/''~ __-~--'
.     ヽヽ,_             ヽ,,__ ,,-',,,-''~ _,, -'
       ~''''''''--,,,,,,,,--,,,,,,,,________,,,,,,--''''''~ヽ. /
        ,----,_,,,,,-'             ヽ,
        >- _           ,    ●  l
.       ,-',,-,~   _ -''''''― 、  ●      l
.       (,,-',,- /     ヽ            l
        ~'~'''~       i          l
.                     l          l
                  l    ./し| |ノ  /
                  /    /  U  /
.               //   /  ,-/,____/-,
               l ヽ, _,ノl   〉-,,____,,,ノ__,,,_
              ノヽ,_ ~  ノ  /:::::::::::::::-':::::::::~ヽ,
             /::::::::::~''''''~:;l  l;:::::::::::::::::::::::::::::::::::::i
            /::::::::::::::::::::::/,l.  '-~'''''---;;;____::::::::;;;l
.           l:::::::::::::::::::::/./    ~~''''''--,,,,,,,---'


758 名前:47 投稿日:02/07/18 00:03 ID:LCFoYpmx main/1026249951.html#700


【ボーナス抽選確率】
     BIG確率 REG確率  合成確率
設定1 1/252.06  1/334.37   1/143.72
設定2 1/248.24  1/327.68   1/141.24
設定3 1/244.54  1/321.25   1/138.85
設定4 1/240.94  1/315.08   1/136.53
設定5 1/240.94  1/309.13   1/135.40
設定6 1/240.94  1/282.48   1/130.03

【ボーナス放出確率】

     BIG   REG   合成   機械割
設定1 1/307.3 1/407.7 1/175.2 95.5〜97.9%
設定2 1/294.2 1/388.3 1/167.4 99.0〜101.5%
設定3 1/277.8 1/365.0 1/157.7 102.7〜105.4%
設定4 1/261.2 1/341.6 1/148.0 106.1〜108.9%
設定5 1/245.0 1/314.3 1/137.7 109.8〜112.8%
設定6 1/192.7 1/225.9 1/104.0 119.9%〜


759 名前:47 投稿日:02/07/19 02:06 ID:tCSawNV2 main/1026249951.html#771
β18の実装は終わって最低限動くようになりましたが、まだバグだらけで謎な動作してます。

とりあえず全ノードからのBBS参照と書き込み可能になりましたし、キャッシュ周りの変更、
その他細かい修正(タスクバーへの常駐とか)も終わりましたが、内部がかなり複雑に
なっているのでテストとバグ修正だけでかなりかかりそうです。

キャッシュ周りの変更など、今回の作業は表に出してみんなにテストしてもらわないでも
基本部はLANでテストできるんで、のんびり調節してます。
しばらくお待ちください。この調子だと後数日かかりそうです。


760 名前:47 投稿日:02/07/22 13:26 ID:khxDZG0a main/1026249951.html#863
β18、あとは細かい見直しだけなんですが、ここ数日仕事や雑用が突発的に
入ってくるんでまとまった時間が取れてません。
明日・・・も用事あるんで暇になるの明後日かな?

とりあえず動作が怪しいとわかっているのを出しても迷惑なだけなので
当分はβ17使っててください。間違いなくβ18系の初期のほうがβ17より
トラブル多いはずですし、キャッシュがまた変わるんで
サクサクダウンの検証できるのは今のうちだと思います。

なお、β18ではver0.2キャッシュとの互換はとりますが、
Ver0.1キャッシュは使用できなくなる予定です。今のうちに消しといてください。

とりあえず現状、BBS機能の方は読み書き自体は問題ないんですけど、
何度もリロードかけないと自分の書き込みが見えなくて多重書き込みになりやすいとか、
そういう問題が残ってて検討中です。

あと、そもそもキャッシュフォーマット変える理由になった、暗号化が入ると
ファイル破損が出る問題など確認すべきところはたくさんあります。もう少しかかります。


761 名前:47 投稿日:02/07/25 15:47 ID:TQFLh9wv main/1027363209.html#105
かなりお待たせしましたが、β18です。

・ 新規にBBS機能を追加
・ キャッシュフォーマットをVer0.3に変更(暗号キーで全体ハッシュ値が変わるようになった)
・ 最小化時にタスクトレイに常駐するようにした
・ ダウン完了時に変換タスクを起動しないオプション追加
・ ノードにクライアントバージョン表示
・ 暗号関連のバグ修正(暗号キーが空でないと動作が変だった部分など)
・ 複数起動チェックでmutexチェックも追加
・ 終了時以外でもダウンリストをファイルに書き出すようにした
・ 表示のRedraw周りの修正
・ 無視条件にマッチするUPファイルがあるとハッシュ生成を繰り返すのを修正
・ クエリの転送処理バグ(上流を二つ以上見に行かなくなってた)を修正
・ クラスタ化のポイントに関係なく接続を切っている部分を修正
・ 転送タスクを見えなくした
・ UPファイル共有限界を2000にした
・ 完全キャッシュと完全UPキャッシュの区別をなくした
・ UPファイルと対応の無いUPキャッシュを表示しないようにした
・ Port0ノードでダウン先が明らかに自ノードより低速な場合接続に行かないようにした
・ 転送でも接続優先度が上がってしまうのを修正
・ 転送リンク接続を1秒に一回→2秒に一回
・ 同一IPからの転送リンク接続を一つに制限
・ キー検索で漢字処理手抜きしてたので修正
・ 時間当たりのクエリ発行数を制限
・ サイズ0のUPファイルを無視するようにした
・ ファイル名に&があるとアンダーラインになっていたのを修正
・ 検索リンク数が増えてきたら接続要求自体を無視するようにした

キャッシュ削除も復活させる予定だったんですが、
今回変更が多くて危険なため見送ってます。


762 名前:47 投稿日:02/07/25 15:47 ID:TQFLh9wv main/1027363209.html#106

今回の変更の大きな目玉はBBS機能で、

・スレッド管理はそのスレッドを作ったノードが行う
・スレッドが書き換わるとその情報がキーとして伝達していく
・スレッドに書き込みを行うと最終的にスレッドを作ったノードのUPファイルに追記される
・スレッド読み込みは、通常のWinnyファイル転送と同じメカニズムでキャッシング

このようなメカニズムになっています。
2chだと板単位で管理してますが、結局これが1スレ単位になっただけなので、
スレを管理しているノードがいなくなると書き込めなくなります。
これにより、書き込みを確認できれば発言が競合で消えたりすることはありません。
もちろん読み込みに関してはキャッシュ効きますし、
転送経路を逆送して書き込みますので、匿名性は高いです。

スレ管理者はスレッドの内容を好きなように変更できますので
この人が責任もって管理することになります。
なお、1ノードで一度に立てられるスレッドは100個までです。

あとBBSへのアクセスですが、Winny自身が一種のHTTPDとして動作しますので、
このポートへブラウザでアクセスします。
ブラウザ起動はBBSのスレッドをダブルクリックか、ブラウザ起動ボタンで行えます。
標準でexplorerが起動しますが、iniファイルを書き換えれば好きなものに変更できます。

ここで、新たにBBS用のポートというのができていますので、これの扱いは注意してください。
基本的にLANかローカルホストからのアクセス前提でWANに公開することは考えていませんので、
BBS用のポートはFWで潰しておいてください。ポートを外部に公開していると、
勝手に自分のノード経由でBBSに書き込まれる可能性があります。
一応自己スレがどれかは分からなくしてありますが、しつこくアクセスしているとばれます。

あと、キャッシュのバージョンが変わっていますが、今回の変更はハッシュ値が暗号に応じて
変わっていなかったのに対応するためなので、暗号キーがかかってないVer0.2キャッシュは、
書き込みが行われると自動的にVer0.3キャッシュに変換されます。
外部からは全てVer0.3キャッシュに見えます。キャッシュをわざわざ消す必要はありません。

また、旧UPキャッシュはハッシュ値が間違っている可能性があるので、
Ver0.2のUPキャッシュは起動時に自動的に全て消してます。
UPファイルの再チェックかかりますのが我慢してください。

あとは細かいバグ修正や、まとめで上がっていた要望に対応しての変更になります。



763 名前:47 投稿日:02/07/25 16:14 ID:UjjLsD0h main/1027363209.html#115
失礼しました(^^;

ノードの暗号化の部分はVer0.1と同じだったんで消しちゃだめでしたね。
そんなわけで修正しといたのですいませんが読み直しといてください。


764 名前:47 投稿日:02/07/25 16:26 ID:UjjLsD0h main/1027363209.html#118
>>116
それは昔からあったバグみたいです。
直しときましたが、致命的でないんで次のVerアップで公開します。

とりあえず用事あるんで外出するので数時間離れますが、
もし致命的な問題があったらスタンドアローンで動かして様子見るようにお願いします。


765 名前:47 投稿日:02/07/25 22:25 ID:RI8LjuyP main/1027363209.html#211
β18.1です。山のようにバグがあってすいません。

この手のP2Pですと実際にある程度の規模で動かしてみないと動作が分からないわけですが、
Winnyの場合完全に私一人で作っているのでテスト要員的に問題があります。

そのため、2chのダウン板の皆さんを開発要員と利用することでどうにか開発しているのが
現状ですので、バグに懲りずにテストよろしくお願いします。MSじゃないですが、
初めのデキが酷くてもしつこく改良していけばそのうち使えるソフトになります。

ってことで変更点です。

・ UpFolder.txtファイルが無い状態で起動するとBBSキャッシュの動作が怪しいのを修正
  (後からUPフォルダ追加するとそこのフォルダがBBSフォルダ扱いされるetc.)
・ 初期起動時にBBSキャッシュを全て消すようにした(ゴミBBS消し対策)
・ 設定ダイアログでrefボタン押すと他の設定がクリアされるのを修正
・ BBS書き込みで半角スペースが+になるのを修正
・ 出力されるHTMLにtitleタグを入れるようにした
・ リスト選択時にRedraw省略する挙動が外れてたので戻した
・ BBSポートの受信バッファ周りでのメモリ不正アクセス修正

別のフォルダがBBSとして流れてしまっているという致命的なバグがあったので
キャッシュをクリアする必要があり、そのためにβ18.1初期起動時に
自動的にBBSキャッシュを全て消すようになってます。

全員が同時にβ18.1に移るわけではないのでタイミング送れて
ゴミキャッシュができる可能性がありますので、もしBBS画面で
違うファイルらしきものが見えてキャッシュに残っているようでしたら、
iniファイルのClearBbsCacheを1にして再起動してください。
BBSキャッシュだけ消せます。



766 名前:47 投稿日:02/07/26 01:23 ID:TtWvunib main/1027363209.html#267
β17→β18はβ14→β15以上の大変更だったので安定するまではかなりかかりそうです。
ということでβ18.2です。

すいませんが、BBS以外のファイルが混ざるというβ18のバグは致命的なので、
これを弾くためにプロトコル変えます。β18.2としか繋がりません。

・ BBSファイルにヘッダをつけてBBSファイル以外のファイルがフォルダ内にあっても無視するようにした
・ Listにフォーカスがあるとモード切り替わっても再描画されないので修正
・ 保持スレッド一覧へのリンクを出力の下部にも追加
・ 保持しているBBSキー多いときの回避処理が働いてなかったので修正
・ 通常ファイルがBBSキーに混じっていると一覧出した時に飛ぶことがあるのを修正
・ localhost:ではなく127.0.0.1:でブラウザを開くようにした

BBS用のデータファイルは基本的に編集するものと考えているので
フォーマットチェックが意図的に甘くしてあるのですが、
さすがにどんなファイルでも指定可能にしてしまうとまずいんで、新たに、ちょっとしたヘッダを
BBSファイルに加えて最低限のチェックするようにしてあります。

なのでβ18.1以前でできたBBSファイルはBBSフォルダにあってもスレッドとして公開されないので、
もしBBSを引き継ぎたい方はすいませんがヘッダ部分を手動で変更してください。


767 名前:47 投稿日:02/07/26 01:37 ID:TtWvunib main/1027363209.html#275
>>271
まだキャッシュ消しの機構は働いてませんので、その辺は後で見直します。
初めのころのバージョンで、これ関連のバグのせいでキャッシュが全消しになる
という最悪に近いバグが出たことがあるんで、今の今まで放置してきた箇所です。

その辺は正式版公開直前にやります。


768 名前:47 投稿日:02/07/26 01:39 ID:TtWvunib main/1027363209.html#276

とりあえず、β18の間はBBS機能関連でごたごたし続けるでしょうから、
新機能のβテストに興味の無い方はβ17.7のまま使っていてください。

ポート変えればそれぞれ使い分けできるはずです。


769 名前:47 投稿日:02/07/26 02:10 ID:TtWvunib main/1027363209.html#293
とりあえずBBSのキーだけ見えるようになってきたみたいなので
少し放置して様子を見ましょう。
(思ったとおり自分のノード以外読み書きが困難ですが(^^;)

BBSは突貫で作った機能なんで謎な部分はいろいろあると思いますが、
LANで動かすなどして動作検証お願いします。

あと、β18の間は新機能検証でごたごたしそうなんで、
念のため公開ページの方で17.7にもリンク張っときました。

暇無くて新機能テストに付き合ってられないという方は、
安定するまでβ17系というのも手です。これはこれで推奨です。



770 名前:47 投稿日:02/07/26 02:13 ID:TtWvunib main/1027363209.html#296
あと、自動ダウンはBBSにも効きますが、今のうちは別個に区別して
落とすという芸当ができません。

ですので、すいませんがユーザーさんの間で適当に
名前付けのルール編み出すようによろしくお願いします。

キャッシュ効いたほうが有利なのはBBSでも同じですので、
自動ダウンで常に最新に保つとBBS機能が安定しやすいと思います。

771 名前:47 投稿日:02/07/26 02:57 ID:TtWvunib main/1027363209.html#301
そろそろ眠いんで寝ますが、動作詳細書いておかないと
検証しようがないと思うんでBBSの部分書いときます。

基本的にBBSファイルの転送は普通のファイルの転送とメカニズム同じですが、
BBSキーは通常ファイルのキーと違い、完全キャッシュ(に相当する完読スレ)
なだけでは、外部にキーが流れていきません。

他からこのスレは書けるよというパケットが回ってくるとキーのIPが書き換わります。
(ここは、部分キャッシュが読可キャッシュになるのと同じメカニズム)
そしてこのIPが自分以外に書き換わっているキー(=書けるスレキー)のみ外部に出て行きます。
転送はこのときにまれにIPを自分に書き換えて外部に流すことで発生します。
ほとんどの場合、もらったIPをそのまま流すので、キーのIPはUPノードのIP
が書かれている確立が高くなります。

これにより、基本的に書けるキーのみが見えることになります。UPノードが消えてしまうと
キーの寿命がつきて全ノードからそのBBSキーは見えなくなっていきます。

BBSへの書き込みに関してですが、ダウンのついでに行っており、
検索リンクの方はまったく用いません。

書き込みありのダウンという形でダウンをかけると、キーのIP値を追いかけて
転送リンクがノード間に張られていきます(ここは通常ファイルの転送動作と同じ)ので、
ダウンの前に転送リンクを通して書き込み要求パケットが順に飛んでいって
UPしているノードにまで届いて追記されることになります。

あとはUPファイルの変更が周りに伝達されていくことになるので、
離れていると書き換わったことになかなか気がつきません。
直接書き込んだノードは転送リンクの連鎖でUP元まで到達できるので、
順に自分の書き込みまで落ちてくるはずですが、手抜きしている
今の実装ですとかなりの確立で失敗するでしょう。
今だとうまくUPノードの隣までこないと、さくさくは書き込めないと思います。

あとファイルと違うのがハッシュ値の扱いでして、BBSハッシュ値は、
前半はファイル名から生成して後半は時刻使ってます。

ですので同じ名前のスレ名にしても同じハッシュ値にはなりません。
もちろん常に新しいハッシュ値にしていてはスレの整合性が成り立ちませんので、
同じスレには同じハッシュ値が当てられるべきです。

この役割を果たしているのが、UPファイルのUPキャッシュ(のBBS版)です。
UPキャッシュには対応するファイル名が書いてあるので、対応が取れていると
あるBBSファイルのハッシュ値をそのキャッシュに書いてあるハッシュ値とみなします。

よって、BBSファイルの方は書き換えてもハッシュ値は同じままですが、
UPキャッシュの方を削除してしまうとハッシュ値が変わって別のスレ扱いになります。
これにより、一度ハッシュ値が変わってしまうとまず元に戻せなくなります。

同様、まったく同じ内容でも名前変えてしまうと別のスレになります。


772 名前:47 投稿日:02/07/26 15:24 ID:8Tl7hvPo main/1027363209.html#351
β18.3です。BBSが動き始めたことで大量にバグを見つけましたので修正です。

できればここはこうした方がいいんだけどとりあえず面倒なんで
手抜き処理してるって部分が多いんで、後で暇見て対処します。

とりあえずちゃんと見れて書き込めないとBBSとして意味無いんで
基本的なところからフィックスして行きましょう。

・ 時間の変なBBSキーを削除するようにした
・ BBSキーでの転送発生率を低くした
・ 転送リンクの接続数制限をBBSとファイル転送で別にした
・ ダウン条件でBBSとファイルを独立に指定できるようにした
・ BBSキーをクエリにパックする部分でバグがあったので修正
・ BBSキーのダウン開始部にバグがあったので修正
・ ダウンリストファイルの再読み込みボタンをつけた

BBSに絡んで少し機能追加されてます。自動ダウンでBBSとファイルを区別して
落とせるようになりましたし、ダウンリストの再読み込み可能になってます。

あ、あとβ18.2とは互換性あります。ただし、全員β18.3にならないとBBSが
本調子にならないと思いますので、順次切り替えお願いします。



773 名前:47 投稿日:02/07/27 01:01 ID:70ukD4pl main/1027363209.html#407
β18.4です。引き続きBBS周辺のバグ取りです。
大きな変更だったので山のようにバグがあるせいで
更新が頻繁で申し訳ないです。

・ BBS書き込みが困難なのを修正(書可タグ情報の伝達バグ修正)
・ ClearBbsCacheでUPキャッシュは消さないようにした
・ 長い名前のVer0.1キャッシュがあると落ちてしまうバグを修正
・ コネクション限界時にBBSファイルの転送リンクが張られると
ファイルリンクが接続限界で切れるバグの修正
・ ハッシュ指示のダウン終了時にBBSならリストから消さないようにした

β18.3では読み込み部が直りましたがまだ書き込み部にバグが・・・
このβ18.4で直ったはずなんで、書き込み率がかなり高くなるはずです。
が、一部手抜き(転送関連)があるんであとで直さないと。


774 名前:47 投稿日:02/07/27 01:13 ID:70ukD4pl main/1027363209.html#415
書くの忘れましたがβ18.2以降と互換があります。

あと、BBS機能をソケット経由でやっているのは後々誰かが
ブラウザ作ってくれるだろうという手抜きな考えによるものです。

今ですと直接HTML吐いてますけど、内部ではBBSフォルダにあるような
BBS dat形式をそのままWinnyのファイル転送メカニズムで転送して、
受け取り側で簡単なコンバーターでHTMLに変換しているだけです。
余裕ができたらソケット経由でこのdatファイルを直接取得できるような
インターフェイスでもつけましょう。

ちなみに本当は2chのdatファイルをそのまま使おうかと思ったんですが、
面倒なんでやめました(笑

この辺はBBSの動作が安定してきてBBS機能が使い物になるようなら
また検討ということで。


775 名前:47 投稿日:02/07/27 15:44 ID:FuWoHAWv main/1027363209.html#500
β18.5です。引き続きバグ取りとBBS関連の機能拡張です。

・ BBSキャッシュの非表示をできるようにした(過去ログ非表示に相当)
・ BBSキャッシュクリアを明示的にボタンからできるようにした
・ 長文書き込み制限がバグっていたので修正(3000文字に制限)
・ 書き込み時の改行制限追加
・ BBS出力時のエラー表示強化
・ 検索リンク切断時にキーを消していたためキーがロストしやすかったのを修正
・ BBSキャッシュの1ブロック分を超えるとhtml出力のスレ番号がクリアされていたのを修正
・ httpヘッダの改行コードが変だったので修正
・ 接続数制限処理でバグっていたので修正(ファイル限界でBBSもコネクション限界)
・ BBSキーの寿命延長
・ タスクトレイ常駐時にアイコンが消えたら復帰させるようにした

新機能としては書き込めないBBSキーを非表示にしたり
キャッシュを明示的に消せるようになってます。

BBSのキャッシュは結局過去ログ扱いで、変更があると結局読み直しますし、
BBSのUPファイルを持っているノードが現れないと外に出て行きませんので、
全部消してしまってもそれほど問題になりません。
そんなわけで消せるようにしときました。

BBS周りはまだ変なことろが多くて、特にローカルでのやり取り部分は
まじめにバッファリングしてなかったりするので表示の上でデータが抜けたり
しやすいと思います(特にBBSが大きくなってきた場合)

暇見て順次直します。


776 名前:47 投稿日:02/07/27 23:35 ID:fFtA9RH2 main/1027363209.html#579
β18.6です。β18.2以降との互換ありです。
不祥事の数が半端じゃないので修正しまくりですいません。

もう少し溜めてから公開したほうがいいんでしょうけど、
致命的なものが多いので早めに公開します。

BBSキー時刻の管理が変なのでレスに反応するのが困難だとか、
UPファイルを書き換えた際に落ちたり矛盾したりするなどの修正です。
まだ変な部分は山のようにありますが、後で修正します。

・ キャッシュがあっても時間が経っていれば元スレを読みに行くようにした
・ スレを読み込んだらキー時刻を最終書き込み時間に変更するようにした
・ キャッシュにあるBBSは色が赤くなるようにした
・ ダウンエラーをおこしたBBSキーが書き込み可能なままだったのを修正
・ BBSダウン時のタイムアウトエラーが表示されていなかったので修正
・ スレッド一覧出力でも検索条件が働くようにした
・ BBSの発言数算出が変だったので修正
・ BBS作成時に全キーリフレッシュをかけないでもすむようにした
・ BBSのUPファイルが消えているとスレUP時に落ちるバグを修正
・ BBSファイルが編集されたときにキーのファイルサイズがずれるバグを修正
・ 無視条件でUPファイルキーは消せないがUPキャッシュは消せるようにした
・ キャッシュなどのフォルダスキャン中は念のため無視条件によるキー削除をしないようにした




777 名前:47 投稿日:02/07/28 15:49 ID:SIFSB8Wp main/1027363209.html#675
β18.7です。β18.2以降との互換ありです。

今度のはバグ取りではなく、ネットワーク全体のパフォーマンス調節です。

まず、どうも上流が重くなっているらしく高速申請ノードほど負荷が高くて
ファイルのUP速度が遅いという現象が出ているようなのでこれへの対応です。

まず何が起きているかですが、

・β18で新たにBBS機能が入ったためにクエリ発行率が増えている
・β17で見つけたクエリが上流を追いかけないというバグを修正したため最上流までクエリが飛ぶ
・検索リンク切断でキーを消さなくなったため全体的にキーが増えている

という三つの要素の組み合わせにより、保持キーも検索も増えて、
上流が非常に重いという状況になっているんじゃないかと思います。

β17は全体的にキーが少なすぎましたが、今回、切断時のキー消去がなくなったことで
これだけでキーの保持数は改善されるはず。となるとβ17のバグだと思っていた最上流まで
クエリ転送が行かないというのが、実はうまく全体の負荷低下&速度向上になっていたのか?
という結論になったので、今回β17のこのクエリ方式を復活させてます。

予想通りであれば、この変更により、最上流ノードの負荷が落ちて
全体の転送速度が早くなるんじゃないかと思います。
クエリパケットはどこまでも上流にではなく、主に自分のノードと同じレイヤと
その一つ上を中心に往復してスイッチバックしながら広まっていくことになります。


778 名前:47 投稿日:02/07/28 15:51 ID:SIFSB8Wp main/1027363209.html#677
あともう一つがBBS側のキー拡散速度の問題への対応です。

BBSの方は、スレッドが見えさえすれば後は比較的快適にやり取りできるように
なってきましたが、現状ではスレッドを見つけたり更新に気が付くのが困難だと思います。
これはもともとファイル共有のために設計されているキー転送部をそのまま流用しているためです。

ファイル共有側はそもそも一回の転送時間が長いですのでダウン開始できないのに、
遠方のキーを大量に持っていても負荷が重くなるだけで無駄ということで、
開き直ってクラスタ化に頼って近辺なノードにあるファイルを主に保持するという
設計になっているわけです。

しかしBBSの方はファイル共有と違い、転送は一瞬で終わるのと、一覧して見たいものだけ
見るという性質のものであるため、キーが素早く伝達されることの方が重要です。
ブロードキャストにより、更新情報が一瞬で全ノードに広まるのが理想的となります。

これを実現するのにいろいろ案はあると思いますが、状況のBBSは中継を極力抑えて
BBSキー寿命を長くすることで調子が良い書き込みが実現できているというから推測するに、
この方式に加えて、最新のスレほど転送率を上げて遠くに素早く拡散するようにして、
逆に昔のスレのキーは非常にゆっくり拡散させるのと全体でうまく動くのでは?
という結論になりましたので、今回のバージョンではこれを取り入れてみました。

具体的には、BBSキーの新鮮度により三段階に分けて、
書き込まれたばかりのBBSキーは比較的早く拡散されるようにしてあります。

やってみないとわかりませんが、この二つの調節で全体がもうすこし
うまく動くようになるんじゃないかと思います。試してみてください。

あと、html出力で<dl></dl>抜けていたので修正しましたのと、DOMを楽しむ方々が
多いようですので、仕方ないので幾つか対応しました。こちらは様子見です。


779 名前:47 投稿日:02/07/28 17:22 ID:9/WYOkKF main/1027363209.html#694
えーと、BBS表示が切れるのは単なる手抜き処理のためです。
現状、ブラウザとのやり取り部分で、ソケットお約束のバッファリングやwait処理入れないで
何にも考えずに直接send,recvしてるのでこうなります。

これは暫定実装なのと、現状でローカルとのやり取り専用だからいいかという理由です。
様子見て直します。

とりあえず現状ではスレの部分表示もないことですし、あまり巨大になったら
スレ管理人さんが減らすなり、新スレにするなりよろしくお願いします。

今日明日と、ちと仕事しないとまずくてあまり作業できないと思いますので、
この巨大になってきたスレへの対処は少しかかります。

現状では、その前段階でBBSキー回転率向上を狙っている状況ですので、
書き込まれたスレが直ぐに上がってこれるのか(自分の書き込み以外で)
というところに注意お願いします。


780 名前:47 投稿日:02/07/28 19:56 ID:zDHzsOcM main/1027363209.html#711
           _______
                _,,,、-‐''''゙゙゙゙、‐‐-、゙゙゙゙゙゙'''ー、,,_ 
              、-''゙゙    /     ヽ     ゙゙ー、_
.            /    __,,,,,,,,,,|       |_、-‐‐-、     ヽ
          / _,,、-''゙゙゙    l     ●/      ヽ    \
.        ,-‐‐-(     \   `;-‐‐-、/ ●     |      ヽ
        /     ` `‐、_  \  l    l      ./       .\
        |         `-、_.  ヽ、____ノ\__  .__/ヽ、       丶
        |\   ゙゙'''ー-、_     /      . ̄     \      丶
.       |  \_.      ゙゙'''   /      ̄ ̄ ̄ ̄ ̄  ヽ      .l
.       |    |ヽ、       /     ゙゙゙゙''''''ー‐--、,,,,,,,  丶       l
        |    |  `ー-、__  /     ゙゙゙'''ー-、_        .l     .|
.        |    |     `'''┴-、_____      ゙゙゙''''ー-     |     |
.    _、--‐┤    l            `ー‐‐---、___________.  |      l
    /     l    ヽ                    /   |     /
.   |     ヽ    \   _,,,,、-‐‐‐‐‐-、,,__      ノ    |    ノ 
    l      lヽ    \/          \    /.    /    /
.    `ー‐-t-‐'  ヽ     `-、           \/     /    /
        \   ト-、,,,___   `ー‐-、________,,,-‐'''''゙゙゙    .ノ   /
         \ `ー---、`'''‐‐---、,,,,,,_____       /   /
.     ___.   >/ ̄ ̄/゙ ゙̄ヽー--、,,,,,,,,,゙゙゙゙゙゙''''ー-、/___ /
   /     \//     |゙'''''''''゙|    \. ゙゙゙゙゙゙''''ー-、二)
  /        \|     `''''''''''゙     \       \_
 /         │l ̄ ゙゙゙゙̄''ー--、_      l         ト-─-、
 |          | |          `l     |   ____   ./     l
 |         │\        ノ    |    /゙゙゙''ー(      |
.. ヽ         /ヽ ヽ、_   ___/    ノ    / / ̄ヽ\   /
.  \.       /  \   ̄ ̄     _/    / ̄ヽ__ノ   ̄ ̄
.   \____/ー─-二‐--------‐'゙゙     `< ̄`‐、_
                ̄`ー-、__          )   l
                     `ー-、_     /    |
.                        `ーy--イ      |
                          |        ノ
                          \      丿
                           `ー---‐'''゙



781 名前:47 投稿日:02/07/29 01:03 ID:JWJd9W1a main/1027363209.html#770
β18.8です。リンク接続状況が悪くなってきていたのでこの辺りを再調節しました。

本当は前のバージョンの影響を除くためにプロトコル変えたほうがいいんでしょうけど
致命的な問題があったときに対応しきれなそうなんで様子見るために互換ありです。
順に移行してください。

・不正コネクション要求(あとで切断がかかる接続など)が大量にくると、
繋がっていた正常な検索リンクも巻き添えで切断かかるのを修正
・切断規則をリンク時間の短いものからホストの優先度の低いもの優先にするようにした
・切断試行を4秒に1回まで落とした
・回線ネゴ前にPort0からのダウン速度判定しているため新規詐称Port0をはじけないバグを修正
・Port0検出切断で無意味に20秒待っていたのを即断するようにした
・転送リンク不良切断時に接続優先度を落とすようにした
・BBSのタイムアウト時間を延長
・html出力で<dt><dd>を閉じていなかったので修正
・システム情報でのファイルとBBSの仮想キー数を別々に表示
・三日以上未来のBBSキーは無視→1時間以上未来のBBSキーは無視に変更
・発言内容でメール欄がsageでもスレを読むと上がっていたので修正
・更新のあったスレは色が変わって分かるようにした

どうもコネクションの様子を見ていると、接続が多すぎて検索リンクが全部切れてしまって
特に上流で下方リンクが安定しないという現象が出ているようなので修正しました。
あと接続だけでなく切断に関してもクラスタ化入れましたので状況が変わると思います。



782 名前:47 投稿日:02/07/29 01:11 ID:JWJd9W1a main/1027363209.html#773
明日(つーかもう今日だけど)締め切りの仕事があるんで今からやります(w
こちらの反応が遅れそうなんで、致命的な問題が発生したら昔のものを使ってください。

783 名前:47 投稿日:02/07/30 18:37 ID:d75ubbJk main/1027363209.html#925
β18.9です。互換ありです。
ファイル共有側に問題が出てるので主にそれの調整です。

一部後ろ向きな修正もありますが、この手のソフトはユーザさんの
総意で動作が変わるという自己組織化的な要素が大きいので、
作っている方も試行錯誤です。ご協力お願いします。

・ クエリ検索方式をβ18.6方式に戻した
・ 一度だけダウン機能を制限ありで復活
・ ハッシュ付ダウンリスト登録時にダウン試行をかけるようにした
・ 終了時に確認ダイアログ出すようにした
・ 自動ダウン時に無視リストにかかるかどうかのチェックでBBSキー無視条件か見てなかったのを修正
・ ダウンやタスク画面で画面書き換えが変だったので修正
・ 検索クエリ中継時に接続時間の長い検索リンクを優先にした
・ BBSキー転送率を少し抑えた
・ 外部ブラウザ側からもBBSのキーワード検索をかけられるようにした

クエリ方式ですが、β18.7,18.8の状況からすると、どうも上流が遅い理由は
詐称その他が主な理由でクエリ方式とは関係なさそうなんで、キーヒット率が高くなる
β18方式に戻しました。今現在ダウン率が悪いのはこれのせいだと思います。
β18.9ユーザが増えるまではUP,DOWN率が戻らないと思いますので早めに変更お願いします。
クエリ周りはこれでフィックスで、それより詐称対策でしょう。

現状Port0が酷い扱いになっているのも突き詰めればこれが原因で、
今現在はどうにかしてPort0脱出できるように各自で工夫お願いします。
原因を探っている現状ではPort0ノードは悪さをしているノードと見分けがつき難く
問題をはっきりさせるためにどうしても制限が強くなります。
対策取れて問題がなくなってくれば制限を緩めます。

あとの問題は一度だけダウンの扱いでして、これは昔の名残でなんとなく残っていただけの
機能でバグって妙な動作したり、クラック対象になるぐらいなら消しちゃえということで
丸ごと消したんですが、思ったより使っている人がいたようなので戻しました。
ただし、転送リンク限界以上には落とせません。

あとこれ関連で出た意見として、自動ダウンだとせっかく見つけたのに
ダウンかかるころには落とせないという意見が多いようなので、ハッシュダウン登録時に
キーを持っていれば自動的に一度だけダウンをかけるようにしました。

なお、手動ダウン指示ですと、自動ダウンと違ってUP数による制限がかかりませんが、
そこまでご苦労なことをやっていることに対する見返りということになります。

手動ダウン指示には人気のあるものを選別してダウン開始でキャッシュを広めるという
自動処理ではできない重要な役目があります。ただし、ADSL主流の現在では、
必ず全体でUP>DOWNになるはずで、無理にDOWNを増やそうとすればするほど
どこかでバランスが崩れますんでシステム全体を壊さない程度にお願いします。


784 名前:47 投稿日:02/07/30 18:37 ID:d75ubbJk main/1027363209.html#926

あと、既にBBS関連でブラウザなど作られている方がいらっしゃるようなので
少しだけ対応しておきました。

検索条件をURLで指定できるようになってます。書式は

ttp://127.0.0.1:7744/
ttp://127.0.0.1:7744/hash
ttp://127.0.0.1:7744/search/
ttp://127.0.0.1:7744/search/hash

一番上がスレ一覧、次がスレ内容出力、次が検索ありのスレ一覧、
最後のものもスレ内容出力ですが、出力されるリンクが条件ありのスレ一覧になります。
3番目の書式ではWinny側でその単語でクエリ発行します
(クエリ戻るのは不定期ですので効果が見えるのに少しかかります)

実は今回、板機能を標準でつけようかと思ったんですが、これの一番良い実現法は、
ユーザさんとスレを立てている人が自主的に工夫する方式かなと思ったんで
とりあえず検索機能を先に付けました。

自動的にスレ立て側でスレを書き換えるという面白いことやっている方もいらっしゃるようですし、
特定の条件のスレキーだけを収集して一覧を出すようなスレを誰かが作れば、
それが結局板の機能になるのではないのか?ということです。
各自[ ]で板名指示してスレを立てると、スレ収集スレでそれが見えるようになるなどです。
今回の機能はその辺を見越してのものでもあります。

あと、
ttp://127.0.0.1:7744/search/hash/-50
こういう2ch式の選択出力も付けたいのですが後回しになります。
それより手抜きによるソケット周りの不祥事を直すのが先でしょう。
これは少しだけ面倒なのでもう少しかかります。


785 名前:47 投稿日:02/07/30 18:46 ID:d75ubbJk main/1027363209.html#928
あれの数字は相対的なものなんで・・・
とりあえずβ19で回線速度周りはかなり変える予定です。お待ちください。


786 名前:47 投稿日:02/08/01 03:34 ID:zyBG88TS main/1028031811.html#123
お待たせしました
β19.0です

大きな変更点は光者を除外したことです
光者は、今すぐ、Winnyを削除してください
光者がこのスレからいなくなるまで、光者がWinnyを削除するまで
永遠に迫害します

光者はDownloadしないで下さい
光者はWinnyの大きな阻害物でしかありません

787 名前:47 投稿日:02/08/01 03:40 ID:zyBG88TS main/1028031811.html#124
今回のヴァージョンアップでは、光者にはウイルスファイルしか集まらないように変更しました
他のおおまかな更新は、光者の接続が自動的に関係各所に通報されるようにした点です

光者が接続する限り、削除しない限り、金輪際、Winnyを更新しません

光者を皆で追い出しましょう
もう、開発しません夜( ̄ー ̄)ニヤリ

788 名前:47 投稿日:02/08/02 02:14 ID:ECFRCNgH main/1028031811.html#212
β19です。互換ありません。
メジャーβアップですがそんなに変わってません。細かい修正のみです。

・ 検索と自動ダウンでAND検索対応
・ 自動ダウンで無視条件(キー消すだけ)とキャッシュ削除指示を分けた
・ BBSブラウザとの通信をノード間通信と同じルーチンで処理するようにした
・ キー寿命延長
・ 自動ダウン時のクエリ発行率を上げた
・ クエリへのキーパック数を落とした
  (ヒット数が多い検索には不利になるが珍しいキーの検索には有利になる)
・ 他ノードから無視ノード扱いされたときに分かるようにした
・ 自ノードとまったく同じ条件(速度、ポート、ダウン情報)のノードは
  自ノードが接続ループしているとみなして切断
・ BBSに半角カナで書き込むと改行が変になることがあるのを修正

本当はβ19ついでに速度詐称対策やBBSの板関連やろうかとも思ったんですが、
ここ数日忙しいのであまりこちらばかりやっているわけにもいかず
不祥事に直ぐに対応できなさそうなんで大規模な変更は後回しにしました。

とりあえず要望多かったはずなのに放置になっていた検索でのAND検索や
無視条件時の削除とダウン不可&キーを消すだけの区別を付けました。

あと、BBSブラウザとの通信部手抜きしていたのを直しました。
これで、巨大なスレッドでも全部見れるはずですし、BBSポートを外部に
公開してもちゃんとそのポート経由でBBS見れると思います。



789 名前:47 投稿日:02/08/02 02:18 ID:3obWBRJP main/1028031811.html#215
■Winnyのちくり先 ACCS不正コピー情報提供■
WEBでの通報先→ ttp://www.accsjp.or.jp/piracy.html
  
メールでの通報先→ piracy@accsjp.or.jp

       以下をコピペ推奨
------------------------------------------------------
ACCS様。初めまして。
最近、匿名性を持った悪質なP2Pソフト”Winny”を利用し
双方のPC間でACCS会員の違法なコピーソフトや未成年の性行為画像等が大量に交換されています。
現在、”Winny" を使って、違法ファイルをやりとりする人間が大量に増加しております。
どうか、取締り及び捜査をお願い致します。

Winnyは、違法ファイルの交換及び送信、受信を目的とした悪質なP2Pソフトであり
逮捕から逃れる為、開発者が故意的に匿名性を上げたソフトです。
犯罪を助長するのは自明の事であり、早急に対処願います。

★匿名性悪質P2Pソフトウェア Winny 公式ページ
ttp://www.geocities.co.jp/SiliconValley/2949/

☆匿名性悪質P2Pソフトウェア Winny Tips☆
ttp://members.tripod.co.jp/winny4646/
----------------------------------------------------------------


790 名前:47 投稿日:02/08/02 02:44 ID:ECFRCNgH main/1028031811.html#220
あとBBSの匿名性で盛り上がっているようですが、
推測通りで極端に転送率が落としてあるので、
バグってなければほぼ中継無しでノード間で直接やり取りしているはずです。
転送に関してはPort0が周辺にいると挙動変わるので絶対ではないですが、
現状ではPort0が上流にいることもほぼないでしょう。

この辺、ファイル転送におけるβ8のころと同じ状況でして、
一度極端にしてみないとどこが悪いのか分からないので
そういう設定でテスト中です。

とりあえずβテスト中なので言うまでもないと思いますが、
裁判沙汰になるようなやり取りは控えてください。

このBBSの匿名性についてはちと悩み中でして、
あまり匿名性あげると今度はキー転送量も増やさないとだめ(理由は省略しますが)なんで、
まじめに使いものになる匿名BBSにするには、
ファイル転送とBBSを切り離さないとだめだと思ってます。

ただそれだと現状ではノードが維持できないと思います。
(他のP2PBBSの多くの問題点はこれでしょう。
BBSのためだけに常時プログラムを立ち上げて
ネットにつばぎっぱなしにしてもらえるとは思えませんので)

まぁ匿名で何か言いたければ現状は2chを使えばいいわけなんで、
前にも書きましたがBBSに関しては2chの後継というのではなく、
Winnyのネットワークを借りてP2PBBS実験中という感じです。
2chレベルに耐えられるものにするには、
BBS専用で一から再設計しないとだめだと思います。

一つの考えとして匿名性をある程度捨てて、その代わりにさくっと板機能付けるというのもありで、
これだとそんなに負荷がかからない方法を思いついてますので
ファイル共有とセットでできると思います。

もう一つの考えとして、今のWinnyと同じでキー検索率の方を捨ててしまって
読み書きは運がよければいいというのにしてしまってその分匿名性を上げるというのもありです。
ただこれだとBBSとしては問題でしょう。

結局、匿名性無視していいのならP2PBBSの実現はそんなに難しくないわけで、
各自でhttpd上げてこれのIP情報をP2Pで共有すればいいだけの話です。
現状のWinnyBBSはこれに近いです。ただこれだけだと匿名性ありません。

とりあえずこの辺のバランスはまだ考え中なんで後回しということでお願いします。


791 名前:47 投稿日:02/08/02 02:45 ID:3obWBRJP main/1028031811.html#221
β19、読み直してください
致命的な欠陥が見つかりました

緊急です

792 名前:47 投稿日:02/08/02 18:11 ID:Zzd4mTA8 main/1028031811.html#281
ここは酷いインターネットですね^^

793 名前:47 投稿日:02/08/03 00:49 ID:1mRTWCqu main/1028031811.html#297
β19.1です。互換あります。
基本的にバグ取りだけです。

ここのところ他のアプリの締め切りがあるので(ってこちらも趣味ですが)
Winnyの方にあまり時間が割けません。

・ 検索リンクのクエリデータがBBSの画面に出てたことがあるので直した
・ 自動ダウン削除条件のバグ修正
・ スレ内容を見たときの時刻更新を間違えることがあるバグを修正
・ 帯域制限が入っているとBBS転送が切れるのを修正

ちなみに、自動ダウンでの無視に関してですが、
キー削除と無視に両方チェック入れないと
相手が無視ノード扱いにはなりませんので注意してください。

・ 無視にチェック
 キャッシュは消しませんが、他のダウン条件をキャンセルします。
 相当するキーは消しません。

・ 削除にチェック
 キャッシュがダウン率0の部分キャッシュにしてキーを削除します
 (キャッシュヘッダだけ残るけど次回起動時に消えます)
 他のダウン条件のキャンセルとしても働きます。
 以前のバージョンでの無視条件に相当します。

・ 両方入れる
 削除の動作+該当するキーを大量に送ってくるノードを無視ノードとみなして切断

無視だけ、削除だけ、無視+削除の順で扱いが厳しくなります。

無視だけ→既に落としたんで落としたくないものを指示
削除だけ→キャッシュ削除用
無視+削除→ゴミキャッシュ送りつけてくるノード排除用

このような利用法を想定しています。ちと分かりにくいですが使い分けてください。



794 名前:47 投稿日:02/08/05 16:24 ID:kxS+qfeq main/1028031811.html#514
ちょっとここ数日仕事の関係で出てますんで何にもできません。
2ch、一応目を通すだけは通してますが・・・

今の考えですと、キャッシュ削除は必要最低限で、HDDがあふれそうになったときだけ行う。
この機能は無くても良いぐらいだと考えてます。(との考えでずっと放置になってきていた)

もし削除復活させるとなるとその方針は基本的にアクセスタイムが最も古いもので、
サイズや参照値は考慮する必要がないというのが削除に関する私の考えです。

そもそもWinnyではキャッシュ消すことによるシステム全体でのメリットがほぼ何も無いので、
最も良い解はキャッシュを消すメカニズムをそもそもつけないことだったりします。

ですが、放置する人がHDDあふれるとまずいので、
そこのところだけは対処しないといけないなぁという程度ですね。

ですので、もしHDDあふれたらキャッシュ消すことをそもそもせずに
警告出して新規ダウンがかからないようにするというのが実は一番良いのかもしれません。

HDDの空き容量ない人は実はPort0の人と同じで、Winnyシステム全体からみると
デメリットの方が大きくなりがち(ネットワーク帯域を消費するだけ)だったりします。



795 名前:47 投稿日:02/08/05 16:26 ID:kxS+qfeq main/1028031811.html#515
それより、今はキャッシュ削除よりも先にBBSの匿名性の方の対策やってます。

単純に転送をそのまま復活させるとまたβ18.3以前のように
ダウンや書き込みできないという症状が復活するでしょうから、
今の考えでは、必ず検索リンクを解して書き込みやダウンを行う
ようにしようと思ってます。隣のノードから目的のBBSをUPしているノードに
アクセスすることになります。

読み込みの方がまだですが書き込みの方は既に実装できていてそれなりに軽快に動いているので、
これで匿名性完璧なわりに読み書きの失敗率が今とあまり変わらなくなると思います。

とりあえず問題ないレベルになったらあげますので少しお待ちください。
明日までは暇がありません。


796 名前:47 投稿日:02/08/06 16:59 ID:98zjRNHc main/1028031811.html#646
β19.2です。プロトコルの変更がありますので他バージョンとの互換性がありません。
速度詐称とBBSの匿名性、キャッシュ溢れに対するとりあえずの対処です。

・ 転送リンク数限界をUp帯域の測定値で動的に変えるようにした
・ 上方転送リンク数限界による下方転送リンク数限界を無くした
・ ADSL8Mのデフォルト値200→120
・ 通信速度測定方法を1秒間値に減衰入れる手法ではなく過去30秒間の平均値方式に変更
・ BBS書き込みを必ず隣(検索リンクで)のノード経由で行うようにした
・ 帯域制限のかかり方を緩やかにした
・ キャッシュフォルダとダウンフォルダのあるドライブの空き容量を調べて
  256Mbyte以下になったら警告出してDownを停止させるようにした
・ キャッシュ容量設定を無くして、システム情報にドライブ空き容量を出すようにした
・ キャッシュ変換時に不完全キャッシュなら_incomplete_付けるようにした

速度詐称に関してですが、本来はもっと大掛かりなもの(転送速度測定結果に応じて
動的に検索リンクも上下変更)を考えていたんですがトラブリそうですし、
ここのスレの話を見ている限り転送リンクの限界数側をちょっと工夫すれば
対処できるかもということで、試しにリンク数をUP速度依存にしてみました。
いろんな考えがあるとは思いますが、今回のはシンプルに30kB/s単位で
転送リンクを分割しているだけです。なお低速側にはボーナス付いてます。

これで回線速度設定は、帯域制限と検索リンクでの上下にしか影響がないので
詐称する意味がほとんどなくなります。これに絡んであと突発的に大きな値に
なることがあった速度計測部の修正や、帯域制限の調節などもしてあります。



797 名前:47 投稿日:02/08/06 16:59 ID:98zjRNHc main/1028031811.html#647
次にBBSの匿名性ですが、今回のでは書き込みを必ず隣のノードに依頼して
行うにしましたので発言書き込み者の方に関してはほぼ完全な匿名性が期待できます。
検索リンク経由でパケットが飛ぶので書き込み成功率もそれほど落ちないでしょう。
なお、スレッド読み込み時にはほぼ直接アクセスにいくので、スレ立て側でTCPの
接続ログ取れば怪しい接続先をピックアップできなくもないはずですが
完全な特定は無理だと思います。

あとの問題はスレを立てている方の匿名性で、こちらも同じような手法で
匿名性を上げることができなくもないのですが、ダウン成功率が落ちそうですし、
スレ立て人がスレの責任者として管理してもらうというWinnyのBBSからすると
このままでもいいかもしれないということで、暫定ですがスレ立て側の
完全な匿名性は今回見送ってます。

別の方法としてスレを他のノードに自由に立てられるようにすればスレ立て側の
匿名性も簡単に実現できるんですが、これですとスレが管理不能になります。
WinnyBBSでは1の発言=スレを立てた人とは限らないわけですし、
これはこれでいいんではないかと。

最後に例のキャッシュ溢れの問題ですが、前に書いたようにそもそも最善の手は
キャッシュを消さないことであるのは間違いないので、今回その様な対策となっています。
なお、HDDがフルになってもUPは可能です。HDD容量が足りなくなってくると
画面に警告ダイアログが出て、新規ダウンがかからなくなります。

そもそもHDDが直ぐに一杯になるほど回線が早いノードは回線速度とHDD空きとのバランスが
悪いということですので、できればHDDの空きを増やしていただけると助かります。
どんなに高速回線であっても、他から吸うだけでキャッシュを直ぐ消すノードは
全体から見てあまりよろしくありません。

Winnyの基本的な考え方として、キャッシュによって見かけの帯域を増やすというのがあり、
匿名性はこれのおまけ(プロクシと同じ考え)なので、回線の低速さに対して
HDDが十分大きいのはシステムの大前提となります。
最大級のHDD持ってきてもすぐ溢れてしまうようだと
転送側の速度向上をがんばりすぎたことになります。

もちろん、キャッシュ消すのは各自の自由ですので、手動でなり、
大きさ見て消すなり古いものから消すなり全消しするなり各自の判断でお願いします。
できればキャッシュは消して欲しくないですが、これを止める手はありません。


798 名前:47 投稿日:02/08/06 18:21 ID:lUj4VNs6 main/1028031811.html#688
唐突ですがβ19.3です(^^;

書き込み以来受けたほうが書き込み終わって応答待つ間に
タスクが待って無なくて喜んで何度も書き込みしてたようです。
LANテストでは問題なかったんですが、WANだと思わぬところで
waitが入るようで気がつきませんでした。失礼しました。

ということで直しましたが、書き込みを中継する方のバグですので、
BBSに書き込むときは隣にβ19.2が居たら危険なのでやめといてください。

あと、UPが上がりすぎるという報告があるようなので、
以前の最大値以上には上がらないようにしときました。
ただ今度は下方詐称の恐れがあります
が、これは問題になったらということで。



799 名前:47 投稿日:02/08/06 18:23 ID:lUj4VNs6 main/1028031811.html#694
すいませんがBBS管理人の方は手動で連続投稿消しといてください。
お願いします。


800 名前:47 投稿日:02/08/06 18:26 ID:lUj4VNs6 main/1028031811.html#700
やっぱりP2Pアプリの開発はこわー
実行するまで何が起きるかわかんないですね。


801 名前:47 投稿日:02/08/12 07:08 ID:XK/YompF main/1028785251.html#176
正直、開発飽きた

802 名前:47 投稿日:02/08/13 20:27 ID:h1cdHV94 main/1028785251.html#271
凶暴です

女房が凶暴化したのでWinnyは中止です


803 名前:47 投稿日:02/08/16 15:43 ID:nTqUzUep main/1028785251.html#476
現在私は盆休みで帰省中です。
なので開発は進んでません。
週末から再開しますので少々お待ちを。

804 名前:47 投稿日:02/08/16 15:54 ID:fi2joxDj main/1028785251.html#479
テスターのレベルが厨以下なので開発やめます

805 名前:47 投稿日:02/08/18 19:34 ID:TxYTQOte main/1028785251.html#687
いや、だから、テスターのほとんどが厨レベルなんで開発やめたんです。
winnyがこれ以上発展することはありません。

これまでお付き合い頂いてありがとうございました。

806 名前:47 投稿日:02/08/18 21:34 ID:C2wXQN55 main/1028785251.html#694
開発を続けてほしかったら土下座してお願いしろ
そうすれば考えてやってもいいぞ

807 名前:47 投稿日:02/08/18 23:57 ID:kodGP9G/ main/1028785251.html#716
今、Winnyの次のファイル共有ソフトを作ってる。
もちろんWindowsネイティブな。少しまちなー。

808 名前:47 投稿日:02/08/19 02:24 ID:y2sFJGj7 main/1028785251.html#725
どうもご無沙汰です。
現在BBSでいくつか修正中ですがLANテストの時点で泥沼化してしまい
ちょっと公開できる状態ではありません。
これが通ればβ20になります。
申し訳ありませんがもうしばらくお待ちください。

さて、今後の予定ですが
β20で大きな問題が無ければ後回しにしてたGUI回りを修正します。
GUI回りは自分でテストできますので公開はしない予定です。
ただ、修正項目が膨大で何を修正すべきか調べるだけで一苦労しそうです。
Tipsページ管理人さんやスレまとめ人さんには大助かりしそうです。

GUI回りの修正が終わったらベータを取ろうかと思いますが
一応最後の総チェックと言うことでβ21を出してから様子を見て
そのまま正式版にするかもしれません。

ここまでで、GUIの修正項目数や現在のLANテストにもよりますが
だいたい10月頃になりそうです。


809 名前:47 投稿日:02/08/19 02:29 ID:GEYzntqs main/1028785251.html#727
偽者が多いな・・・

810 名前:47 投稿日:02/08/19 02:34 ID:y2sFJGj7 main/1028785251.html#728
偽者ですか(w

タイミングが悪かったようですね。
とりあえずβ20に全力を注ぐことにします。


811 名前:47 投稿日:02/08/19 12:58 ID:CHuRoe63 main/1028785251.html#758
725を偽者と見抜けない人は素人。

812 名前:47 投稿日:02/08/21 02:26 ID:YwXXHpB1 main/1028785251.html#815
今年は初盆だったので忙しくてこちらが放置になってすいませんでした。

そんなわけでβ19.4です。β19.3とは互換ありです。
なお、プロトコル同じですが19.2からの接続は切るようになってます。

・ ドライブ空き容量警告の出る時間間隔を長くした
・ ウィンドウが最大化状態かどうかもiniファイルに記録するようにした
・ キャッシュ変換時に既に同じ名前のファイルがダウンフォルダにあったら名前変更
・ BBSファイルの大きさを1Mbyteまでに制限
・ タスクトレイ常駐時にシェルが落ちたら常駐解除するように修正
・ ポート警告が増えてきたら警告出して接続停止させるようにした
・ Win98系だと終了時に画面にゴミが残るのを修正
・ 検索入力や検索ボタンを横に少し長くした
・ 帯域制限の遊びを減らした

今回、GUI周りや例外処理の細かい変更だけです。
検索などで早急に修正した方がよい箇所もあるのですが、
プロトコル変更が必要なのは後でまとめてということで。

そろそろやることもなくなってきたんで
Ver1.0の準備してもいいかもしれませんね。

なお、このスレになってから書くのはこれが初めてになります。
あとは全部偽者ですのでよろしくお願いします。


813 名前:47 投稿日:02/08/22 14:17 ID:TxfzCieZ main/1028785251.html#939
>>937
ほぼそこだろうとは思っててちょうどチェック中なんですが、
自分の環境ではなかなか落ちてくれないないので確認とれなくて困ってました。

そこはノード毎に持っている受信バッファを拡張しているところです。
前から通信負荷が高くなって受信量が多くなりすぎるとそこで落ちてました。
これはβ19.4では変えてませんので昔からあった問題点のはずです。

既に対処済みのはずなんですが、うまく動かないようですのでもう一度検討してみます。

19.3→19.4変更点を全部見直してみても落ちるような要素が見当たらないのですので、
β19.4で落ちやすくなっているのは単にCPUその他の負荷に対する通信負荷の率が高くなって
受信バッファがあふれやすくなっているだけのようです(処理が終わる前に次のパケットが来てしまう)
Winnyネットワーク全体としてはうまく回ってきている証拠ではないかと思います。

とりあえず各自の対処としては、回線速度にあわせたCPUとHDD使ってくださいということで。
処理が追いつかないで通信バッファが溜まるととここで落ちます。


814 名前:47 投稿日:02/08/22 14:31 ID:q50GM9WU main/1028785251.html#943
というか、メモリが足りないとこの問題点が出るはずなんで、
ここのところで落ちる方はPCのメモリ増やしたほうがいいかも(^^;

仮想記憶でメモリ確保されても、処理速度がより遅くなって、
それでも通信パケットは次々に送られてくるんで結局メモリが確保しきれなくなって落ちます。
これの対処法としては、バッファあふれそうになったらわざと通信速度を遅くするか
コネクションを切らないとだめですね。

単に常にSafetyなやりとりでバッファあふれないように通信すればいいだけなんですが、
Winnyでは速度を確保するためにファイル転送時に10ブロック分フライングで
送信要求します。1ブロック64Kなんで、10ブロック=640kはファイル転送が始まれば
無条件に送られてきます(レイテンシがひどくてもある程度速度が出るように)。
コネクションだけ確保してもメモリに余裕がないと受信しきれずに落ちてしまいます。


815 名前:47 投稿日:02/08/25 00:10 ID:qViqDIZR main/1030002778.html#218
β19.5です。19.3,19.4と互換あります。
主にGUI周辺の変更で、要望のあったところです。

・ ダウン対象が複数ある場合、被参照量と更新時時刻、キャッシュ量から優先度を算出してダウンするようにした
・ 検索画面でダウン優先度を出すようにした
・ 検索画面でファイル参照回数でなく参照量で表示するようにした
・ ノード接続ボタンの名称変更
・ 新しいバージョンのクライアントが接続したら一度だけダイアログ通知するようにした
・ 検索入力をComboBoxに変更(ダウン条件の検索条件は無条件で追加)
・ 通信バッファがあふれそうなとき、ポート警告が増えてきたとき、ハッシュチェック時には
 プロセスウェイト値を少なくしてCPUタイムを確保するようにした
・ 多重ダウンボタンをダウンからタスクへ移動
・ ダウン設定ファイルをテキストエディタで開くボタンを追加
・ キャッシュ変換タスクは一度に一つのみ走るようにした
・ キャッシュ変換の保留ボタンを追加
・ ダウン条件で重複があると無視条件でなくても無視されることがあったので修正
・ 無駄な背景クリア描画を減らした
・ タスクの表示ソートでタスク種類も考慮してソートするようにした
・ DOWN側MAX枠を+1した(自動ダウンで-1になるので結局DOWN=UP)
・ ダウンリストでダウンしていないキーや部分キャッシュの情報も出すようにした
・ 最大化した状態で最小化して再起動すると挙動が変だったのを修正(まだ変かも)

まだ無視している要望もありますが、変更がたまったので公開しておきます。
大きめの変更としては、自動ダウン時に対象が複数あったら今までは順番に
ダウンにいってましたが、今回から適当に評価値出して評価が高いもの優先で
落とすようになってます。ダウン優先度は検索のところで見れます。

優先度の算出ですが4要素見てまして、まず更新時刻、参照ブロック数が基本になります。

人気があるファイルはUPで時刻が更新されるので、参照ブロック数を無視して
更新時刻だけ見ていても良いはずなんですが、大きいファイルですと更新が頻繁でないので
人気があるとは限らないですし、小さいファイルでも更新時刻だけだとゴミ拾いますし、
だからといって参照ブロック数だけ見ていると今度は昔から広まっているファイルが
有利になってしまうので、この二つの要素を適当に掛け合わせて
最近参照されているわりには参照数も比較的あるファイルを優先させるようになってます。
どちらかというと小さいファイルほど更新時刻優先で大きいファイルほど参照ブロック優先になります。

あと、すでにダウンしているキャッシュほど優先になります。最後に同じものを何度もダウンしにいかないように、
一度ダウンかけたものは自動的に優先度が落ちるようになってます。(この効果は画面の優先度には現れない。)

あと要望のあった(のに近い)細かい修正が大量にありますが、
説明が面倒なので省略します。適当に試してください。

b19.4で落ちる件ですが、根本的には直せてません。
これは結局、負荷が高くなったりメモリが足りなくなってくると発生するので
キャッシュ処理をシーケンシャルにしたり、落ちそうになったら
ウェイト減らすなどで対応してあります。
こんなんで自分の環境ではまったく落ちませんが、とりあえず実験お願いします。


816 名前:47 投稿日:02/08/26 18:51 ID:osa4X0Ld main/1030002778.html#434
β19.6です。19.3以降と互換あります。要望のあったところと、GUI周りの小変更、
あと低速側やあまり見かけないファイルに対する自動ダウン率向上です。

そういえば、19.5の最新バージョン報告が動作するのはこれが初めてなんで
ちゃんと動くのか心配ですが・・・

・ 自動ダウンでの検索クエリ発行頻度を大幅に向上&発行抜けが発生しないように修正
・ 検索クエリにパックするキー個数限界を減らした(キー転送側のプッシュ数はそのまま)
・ データのやり取りのないコネクションはUP接続にカウントしないようにした
 (キャッシュロストしてコネクションだけ残ってもUPカウントになることへの対策)
・ プッシュボタンの再描画されないことがあるのを修正
・ アップファイルの名前を変えるとそれ以降、常にハッシュチェックかかるのを修正
・ 検索画面での参照ブロック量表示をカンマ区切りに変更
・ 検索入力への自動的なフォーカス移動を行わないようにした
・ 検索入力のドロップダウンリストの長さを短くした
・ 暗号キー入力部を検索入力の右側に移動
・ 再描画でボタンがちらつくのを修正
・ スクロールバーが出るとリスト末尾で背景クリアされずにゴミが残るのを修正
・ ブラウザ起動や編集ボタンによる外部プログラム起動で起動完了を待たないようにした
 (これらの操作で飛びにくくなるはず)
・ 参照値の優先度オフセットを増やした
 (参照数0でも新しければ優先になりやすくなる。小さいファイルほどこの傾向強し)

変更点は要望のあったものやバグ取り中心ですが、今回ので重要なのは
「自動ダウンでの検索クエリ発行率が大幅に上がっている」ことです。
手動検索で検索ボタン連打するとキーヒット率が良くなるのは
皆さん気がついていると思いますが、
自動ダウンでもシステム標準でこれに近い挙動をするようになります。



817 名前:47 投稿日:02/08/26 18:52 ID:osa4X0Ld main/1030002778.html#435
現状、

・珍しいファイルは自動ダウンではまず落とせない(そもそもキーが見当たらない)
・人気はあるけどそれほど流通していないファイル(主に巨大なファイル)は
 コネクション限界で再接続試行している間にキーロストする
・下流ノードでは手動で検索ボタン連打しないとキーがあまり流れてこない

突き詰めればキーが見当たらないのが問題なわけですが、
自動ダウンでのクエリ発行率を一桁上げましたので
この辺の状況が多少は良くなると思います。

ちなみに、むやみに検索クエリ発行すると特に上流であふれそうなんで
これまでのバージョンですと自動クエリ発行はかなり抑えてあったんですが、
今までの修正でかなり検索周りの負荷が軽くなってますし、各所チェック入れたので
今度のは検索発行頻度高い割にはクエリあふれないと思います。

とりあえず自動ダウンでクエリが発行される条件ですが、
「各検索条件でのヒットキー数が1以下でダウン枠が余ってれば」
ダウンリストのキーワードで検索クエリを発行します。
無視や削除条件だとクエリ発行されません。

あと、現状ではハッシュ支持でのダウンでも検索にはキーワードで検索しているので
ハッシュダウンの場合でもタイトルにありそうな名前を指定したほうが良いです。

なお、自動ダウンのチェックは1秒で1つで、リストの上から順番に見ていって、
キーがあればダウン開始、なければクエリ発行になります
(そして検索発行してから実際にキーが見つかるまでにはラグがある)
ので、メカニズム理解してリストの順番を工夫すると落としやすいと思います。
ダウンリストでいまだにソート機能ないのは自分で順番制御したいからですし。
(あとクラスタキーワードのせい)



818 名前:47 投稿日:02/08/26 19:03 ID:osa4X0Ld main/1030002778.html#441
そういえば、すでにノード設定ファイルってNoderefTemp.txtしか必要ないんじゃないかと
思うんですが、ノード追加もNoderefTemp.txtの方にしてConst側はなくしちゃっても
いいんじゃないかと思ってるんですが何か問題あります?

悪戯ノード対策でConstは使わないほうがいいと思うし、
どうせ久しぶりにつないだらRef取り直さないとだめなんで
消えちゃっても問題ないし。



819 名前:47 投稿日:02/08/26 20:00 ID:osa4X0Ld main/1030002778.html#478
あー、ミラーしちゃだめです(w
19.6は封印しますのでよろしくお願いします。

どうもクエリがあふれるようなのでパラメータ修正中です。
少しお待ちください。

820 名前:47 投稿日:02/08/26 20:38 ID:osa4X0Ld main/1030002778.html#499
ということでお騒がせしてますがβ19.7です。
19.3〜19.5とは繋がりますが19.6が接続しても19.2と同じで強制切断します。

変更点ですが、クエリ発行が連続で行われると詰まる可能性が高いようですので、
適当にランダムで固まらないようにしました。あと多少発行率を落としてあります。

まだ昔のバージョンが残っている状態だと、キーがたくさんパックされるので
これがなくなればもう少し発行率上げても耐えられると思うんですが
怖いんでとりあえずこれで様子みてください。
β19.5以前と比べればかなりダウン率高くなるはずです。

ああ、あと警告をダイアログで出すと問題がでるようですので
暫定ですがタイトル部分に出るようになってます。


821 名前:47 投稿日:02/08/26 21:11 ID:osa4X0Ld main/1030002778.html#519
>>509
その動作であってます。標準ではMAX番目のUP接続が来ると数秒で切れます。

今回からUP接続あってから少し様子を見るようになってますんで、
たまに同じタイミングで接続がきて制限を超えることがありえます(前のバージョンでも極まれにありましたが)。

無条件に限界超えたUPリンクを後から切ってしまっても良いのですが、
これをやると今度はダウン側から見て、せっかく転送してるのに勝手に接続限界で切れるという動作になり
バグも怖いですし、とりあえずUP側のTransferMAXを初めから1引いておいて1遊びにするとなってます。
一度転送が開始されればUPを切ることは無いので、人気のあるノードはUPがMAXに達するはずです。

とりあえず今回のVerではDOWN=UP+1になりやすくなりますが、むやみにUP確保しても逆に
落とすほうからすると遅くなるだけなんでこれのが全体では調子良いんではないかとの判断です。

接続に余裕のある上流ノードではこの差は誤差みたいになりますので、結果的にこれで生じた
転送リンクの足りない分は上流ノードが担当することになるので上流不利な設定ですが、
下流はUPが弱いのである程度上流に面倒みてもらうのは仕方ないんではないかとの判断もあります。


822 名前:47 投稿日:02/08/26 22:28 ID:osa4X0Ld main/1030002778.html#539
そういえば書くの忘れましたが、ダウンリストの先頭三つはクラスタ化のために絶対
ヒットしないにもかかわらずたくさんヒットするキーワードが書かれている可能性が高いとみなして
暫定ですが19.7では先頭三つは検索出さないようになってます。
ですので、個別ダウンしたい対象は4っつめ以降においてください。

ある程度19.7になって状態が安定してきたらこの辺はもう一度見直します。


823 名前:47 投稿日:02/08/26 22:33 ID:osa4X0Ld main/1030002778.html#540
あと上流ほど検索パケットが飛び交いますので、
PCスペックが弱い方は下流詐称したほうが楽かもしれません。

重くなるのは、ポート警告や通信エラー、バッファあふれなどが検出されて
放置するともうすぐバッファあふれでクラッシュしそうなんで
ウェイト減らして他プロセスより優先的にCPUを奪っている状態です。

下流ほど検索通信量が減るので、下方ほど有利です。


824 名前:47 投稿日:02/08/27 15:35 ID:BvSz2oAe main/1030002778.html#628
そういえばノート忘れてきて串が回避できない(w
ついでにRef部書き換えちゃえ

ということでβ19.8です。
主にβ19.6,7で検索部のメカニズム変わったことに対するパラメータ調整です。
ちなみにさっき書き換えたばかりなので早めに19.8落とした人は落とし直しといてください。

・ 中継発生率が上がっていたので下げた
・ UP=DOWNにもどした(ただしUP側が+1になる可能性が高い)
・ ダウンリスト先頭の3条件でもクエリ発行するようにした
 (ただし先頭三つのクエリ発行率は低め)
・ ノードファイルをNoderef.txt一つだけにした

19.5と19.7ではそんなに変わってないはずだったんですが、検索により拾ったキー
重視になったせいでキーの分布状況にかなり変化があるようです。
ですのでこれに対するパラメータ微調整です。

まず遠方のキーにダウンかけるようになったせいで切断が生じやすくなって
いるようなので中継発生率を下げました
(切れ易い理由は遠方キーほど中継発生率が高くなるからでしょう)

あと、下流のUPが-1になったことの影響がかなり大きくて
これで上流ダウン優先になったはずですが、
そもそも検索キー重視になったため上流にダウンがかかりやすくなったはずなのと
合わさってコネクション限界が出やすくなっているようです。
ですのでUP側を+1しました。今度は中流がUP過多で全体の転送速度が
遅くなるんじゃないのか?という心配もあるのですがとりあえず様子見。

こんなんでバランス良くなれば良いのですが、調子悪ければまた修正しましょう。
現状、各パラメータの調節がかなり微妙で少しかえるだけで全体に影響ですので
調節が難しいところです。

ああ、あと前に書いたように今回からノードファイルを一つにしました。
Noderef.txtだけになりますので、旧バージョンのノード情報を
引き継ぐときはNoderefTemp.txtをこれに名前変えてください。

ノード追加すると今までのConst.txt同様Noderef.txtに追加になります。
で終了時にNoderef.txtに保存しますが、つながらなかったノード情報は旧Temp同様破棄します。
あと、新機能として、Noderef.txtを切断時に出力、接続時に読み込みます。
ただし保持しているノードバッファが空だと出力しません。



825 名前:47 投稿日:02/08/27 15:44 ID:BvSz2oAe main/1030002778.html#630
ちなみにUP側に19.8が多くなるまで今回の修正は
影響が見えにくいと思いますので気長にお待ちください。


826 名前:47 投稿日:02/08/29 00:59 ID:50vUb1S7 main/1030002778.html#764
β19.9です。19.4, 5, 7, 8と互換性があります。

・ 変なパケット受け取ると落ちることがあるのを修正
・ 無視条件(&削除条件でない)ならキー検索処理をスキップするようにした
・ 警告をタイトルでなくて左下に出すようにした
・ アイコン時TipsにTransfer情報を出すようにした(&警告だとアイコン赤くなる)

なかなか飛ばないんで首捻ってたんですが例の落ちる件の理由わかりました。
通信内容がおかしくなった場合の例外処理が甘くて落ちていたようです。
β1からあったバグです。指摘してくださった方ありがとうございます。

ほとんどの場合、通信内容が変になると強制接続断されて終わりのはずなんですが、
通信の変さ加減によってはWinnyプロトコルでのパケット切り分け部で落ちるようです。
(Winnyプロトコルはパケットサイズ方式ですが、このサイズの例外処理が甘かった)
とりあえず対処しましたのでそこで落ちることはなくなるはずです。

TCPコネクションは基本的にエラー保障されているはずということで
通信内容のエラー検出は手抜きしている箇所が多いんですが手抜いちゃだめみたいで。

どちらにせよ、今までので頻繁に落ちていた方はネットワーク周りが怪しいかもしれません。
接続相手が飛ぶと巻き込まれて飛ぶ可能性があったんで、自分が悪いとは限らないですが、
ファイル破損発生確率も多いはずです。ルータが飛んでるなんかがありがちかも。

あと、無視条件をたくさん設定していると検索パケットが出にくいですので、
1秒毎に行っているダウン条件チェックで、無視条件だけのものは飛ばすように
しました。

・ 無視条件→ダウンしない
・ 削除条件→キャッシュ削除
・ 無視&削除→ダウンしない&キャッシュ削除&大量にそのキー送ってくる
 ノードには無視ノード警告通達して切断

こうなってますので、無視条件だけのものをわざわざ調べなくても良いということで。

あとおまけで警告関連とアイコン表示の修正してあります。


827 名前:47 投稿日:02/08/31 00:06 ID:zDpTTdV7 main/1030678466.html#54
β19.10です。バージョンナンバーの下が10超えること考えてなかったので、
前バージョンで19.10見るとノード情報にVer0.2と出るかと思いますが無視してください。

・ β19.8→19.9で見つかったエラーの修正が完全でなかったので直した(httpでアクセスすると落ちるなど)
・ リストが選択されているとリストヘッダクリックしても再描画かからないのを修正
・ ダウンリスト編集プログラムをiniファイルのDownlistEditorで設定できるようにした
・ Winny.iniのBbsBlowser→BbsBrowser(w
・ 起動時の.iniパラメータチェック強化
・ ダウンリストの再編集機能を右メニューに付けた
・ 変換最中のファイルは名前が_incomplete_〜で、正常変換後に元の名前にリネームするようにした
・ 変換に失敗しても_incomplete_付きでファイルが残るようにした(ハッシュ不整合でも残る)
・ HDD残量警告が出てもBBSはダウン可能とした
・ ポート0ノードでは負のクラスタ化のためのリンク切断を行わないようにした

まず大きなところでは、β19.9でせっかく落ちる理由がわかったのに
修正で抜けがあって結局別のところで落ちてましたので修正しました。
確かに19.3→19.4での変更点でした。実際に落ちるところを見れば
すぐわかるんですが、自分のところでは落ちないので見落としがあったようで。
とりあえず確実に落とせるということを報告してくださった方、助かりました。

あと今回ので全体に影響がありそうなのは最後の修正です。
Port0ノードがちゃんとUpできるには長時間検索リンクで
繋がっていないとだめなんですが(Port0からのUPは、一つ上のノードに他のノードが
接続してUP要求が検索リンクを通してPort0ノードにきて、Port0から逆接続するため)
だからといってPort0優先すると特に上流でPort0ばかりになるという問題が出ます。

とりあえず、すぐ検索リンクが切れる大きな理由はクラスタ化のために
優先度が低いと切られるのが大きな理由ですので、Port0ノードはノード優先度が低くても
自分からは検索リンクを切らないようにしました。これでも接続相手からみた優先度が低ければ
切られますので、Port0ノードさんは特に相手から見た優先度高くなるように気をつけてくださいということで。

具体的にはヒットしそうな単語をクラスタ化に使うこととキャッシュに無視されそうなファイルを置かないことです。
あと、頻繁にUPするとDOWN側から見た優先度が上がりますので、できるだけUPの人気のあるものを
キャッシュに置いておくと長時間検索リンクが切られずにいられます。

とりあえずPort0ノードさんがちゃんとUPできるようになれば全体の
UP帯域が上がりますので状態がよくなるはずですが、逆にPort0の
ダウンだけが増えて帯域を減らす可能性もありえますので、様子見です。
(Downだけなら状況は変わらないと思いますので良い方向に働くと思いますが・・)

とりあえず、上流のPort0ほど切られやすいのは前と変わりませんので、
高速回線でもPort0の方は下方詐称したほうが良いのは変わりません。

あとBBSでゴミが出るというバグが残っていると思いますが、例の落ちるのの絡みで
早めにVerUPしといた方が良いと思いますのでこんなところで公開しておきます。


828 名前:47 投稿日:02/08/31 00:23 ID:zDpTTdV7 main/1030678466.html#64
そういえば今度のではBbsBrowserが省略されているとデフォルトのブラウザが起動されるようになってます。

OSによってはurl指定の起動で失敗するOSがあるようです。そのためexplorer.exeを標準に
していたんですが、ブラウザ起動でエラー出る方はBbsBrowser=exploler.exeと.iniファイル書き換えといてください。

ダウンリストの方も同じです。省略されているとデフォルトのテキストエディタが起動されるはずですが、
OSによっては失敗するかもしれません。


829 名前:47 投稿日:02/09/02 13:52 ID:+quXAxhY main/1030678466.html#368
β20です。互換性ありません。

なお今回、フォルダの初期位置やアーカイブ内容が少し変わっているので注意してください。
各設定ファイルの位置が作業フォルダでなくexeの横になってますし、
フォルダ位置もデフォルトがexeの横になってます
(なお、初期起動時にエラーが出ないように空フォルダがアーカイブに含まれている)。

・ BBS作成時にスレ名に強制的に板名を付けるようにした([BBS_何とか]が自動で追加)
・ 検索履歴のクリアボタンをつけた(& BBS検索の履歴はやめてボード一覧に変更)
・ ダウンリスト内容が変わっても検索コンボボックス内容の更新が行われないのを修正
・ 低速切断機能を追加(接続二分経過以後、ダウン速度が10KB/sを下回ったら切断、働くのはDownだけ)
・ 帯域速度の計算を1ライン30KB/sから40KB/sに変更
・ 回線速度算出を今までの30秒平均から60秒平均にした
・ 回線速度依存だったクエリバッファを常に10に制限(溢れたクエリは廃棄)
・ 自動ダウンでの検索クエリ発行頻度を少し上げた
・ 検索リンクと転送リンクの下流でport0の占める割合をリンク数の半分までに制限
・ 負のクラスタ化のための検索リンク切断でport0が不利だったのをやめた
・ 各フォルダの初期位置をexeの横位置にした
・ 各設定ファイルの位置をカレントディレクトリではなくexeの横位置にした
・ ノードリストを他ノードへ転送する際に、クラスタ化ワードも転送するようにした
・ 標準のBbsBrowserをiexplore.exeに戻した
・ 全角スペースも検索での区切り記号として扱われるようにした
・ ". "などの単語で全キーがヒットしてしまうのを修正
・ タスク表示ソートでキャッシュ変換タスクを上に持ってきた
・ 起動時のキャッシュチェック速度向上
・ キャッシュ変換タスク表示でもファイルのサイズと処理位置を表示するようにした
・ 検索画面でのキャッシュブロック表示部を高速化
・ BBSで検索に漢字を用いていると、ブラウザ起動時に検索が失敗するのを修正
・ BBSでエラー発生時にブラウザ側にゴミが表示されることがあるのを修正
・ BBS読み込み時にタイムアウトしてもBBSキーを消さなくした(再試行できるように)



830 名前:47 投稿日:02/09/02 13:53 ID:+quXAxhY main/1030678466.html#369
特に説明しないでも問題ない小さな変更ばかりですが、重要そうなのとして
BBSでスレの名前に板名を含めるのを標準フォーマットにしたというのがあります。

スレ作成時にはBoardList.txtに書いてあるワードをどれか選んでということになります。
そして板の機能は検索フィルタで行うということになります。

BBS側が放置になっていたのでどう状況になっているのか見てみたんですが、
いつの間にかブラウザができたりしてそれなりにルールができてきている
ようですので、強制的にシステム側でそれに合わせるようにしました。

とりあえずnvviewで使っていたリストを標準でついてる板リストにしておきましたが、
スペース区切りだと検索で分断されて問題がありそうなので、
BBSの板ヘッダは[BBS_板名]となります。別に名前に板ヘッダ無くても問題はないですが、
スレ数的に規則決めて板別にしないとそろそろ見難いでしょう。

ということですので、以後、スレ管理人さんは自分のところのスレ名をこの方式に変えて
おいてください。お願いします。なお、板の増設は各自で適当な名前付ければ
それで終わりで、良く使う分類が新たに発生したら各自でBoardList.txtを
書き換えるということになります。バージョンアップ時に適当にアーカイブ内容を更新します。

なおBBSに関しては、もし将来的にキー数が数千になってしまうとシステムを
ファイル共有側と分離する必要が出てくるとは思いますが、
かなり大規模になっても現状のシステムでそれなりに耐えられると思いますし、
思ったより破綻せずに普通に動いてるので基本はこんなもんでも良いのではないかと
思います。所詮おまけですし、盛り上がるようでしたらまた対処しましょう。



831 名前:47 投稿日:02/09/02 14:09 ID:+quXAxhY main/1030678466.html#378
ひょっとするとプロトコル変わったんで昔のバージョンに反応してバージョンアップ警告が出るかもしれません。
LANテストでは問題なかったですが、そういえば旧プロトコルで接続してきたときの挙動をチェックしませんでした。
とりあえず実害は無いはずですので、だとしたら次で直します。お願いします。

832 名前:47 投稿日:02/09/02 15:19 ID:oBmnM0i7 main/1030678466.html#403
ここは頭悪いインターネットでする

つまり自分の考えが通らず窮地に落ちた人間が
使用するスレがここという訳です。

Download版には必要ないのでは?という意見もあるようですが
それは間違ってます。ここでこそ真力を発揮できるので。

ある偉い方が言いました
「ここの住人を見てるのが辛い・・・あんな酷い仕打ちを
受けてまだ事を起こす事が出来るのか?私には絶対の無理だ。逃げよう」

皆さんももうお気付きでしょうが今現在あなたが見てるこのスレ
の事を言ってます。「そんなバカな!」
と思う方もいるかも知れませんが事実
最低でもあなたの限られた貴重な時間がここで削られた事は事実なんですから。

その偉い人は一呼吸置いて言葉を続けました
「仲間はずれになるのが恐い?ははは、それこそここのスレにとって最高の
ご馳走になるんですよ」

そうなにを隠そうその偉い人とは本来
あなたが進めべき場所にいる存在なんですから。


833 名前:47 投稿日:02/09/03 15:38 ID:yMK+RT3J main/1030678466.html#559
β20.1です。β20と互換性あります。バグ取りと細かい修正だけです。
新機能付けようかとも思ったんですが、あわてて作業してまた新たなバグを
増やしても仕方ないんでとりあえずバグ取りだけやっときました。

・ プロトコル違いでのバージョン警告誤動作を修正
・ BBSで「"」を「"」に置換するようにした
・ 破損キャッシュのブロック表示で幅を0にすると落ちるのを修正
・ 低速切断が働くのをDOWN接続数がMAX時のみにした
・ 履歴消去するとBBS側のスレッド一覧が消えるのを修正
・ 転送中のキーをダウンリストに追加すると落ちるのを修正
・ ポート警告による停止制限限界数を増やした(10→20)



834 名前:47 投稿日:02/09/05 15:31 ID:zVacqbSW main/1030678466.html#736
β20.2です。20, 20.1と互換あります。

・ 検索入力で勝手に補完されるのを修正
・ Redraw周り修正
・ 通信速度表示がはみ出るのを修正
・ 中継転送終了時のブロックハッシュチェックタスク表示を隠した

バグ修正だけで新機能はありません。
他の問題点は直すのが困難だったりこちらで再現できなかったり
するものばかりなのでとりあえず保留です。ほとんど変わってないですが、
入力で勝手に補完されるのは問題なので早めに公開しておきます。


835 名前:47 投稿日:02/09/05 16:14 ID:zVacqbSW main/1030678466.html#757
ひょっとしてLUNAだとなります?


836 名前:47 投稿日:02/09/05 16:33 ID:zVacqbSW main/1030678466.html#777
手持ちの環境で試してみたらVideoがGeForceだと出ませんが、
Radeonのマシンでは出るようなのでチェックしてみます。少しお待ちください。


837 名前:47 投稿日:02/09/05 17:10 ID:zVacqbSW main/1030678466.html#798
β20.21です。
変更点はその見えなくなる部分だけです。
こちらの環境ではこれで問題ないですがどうでしょう?
だめならβ20の方式に戻しますが。


838 名前:47 投稿日:02/09/05 23:16 ID:QLGoShfy main/1030678466.html#853
Winnyのキャッシュファイルにはアップした人のIPとその時間が保存されます。
これはもし違法なファイルがアップされた場合に犯人を特定するためのものです。

839 名前:47 投稿日:02/09/06 13:50 ID:5OZyCZ4l main/1030678466.html#893
β20.3です。20, 20.1.20.2と互換あります。

・ 検索入力で勝手に補完されるのを修正
・ Redraw周り修正
・ 通信速度表示がはみ出るのを修正
・ 中継転送終了時のブロックハッシュチェックタスク表示を隠した

バグ修正だけで新機能はありません。
他の問題点は直すのが困難だったりこちらで再現できなかったり
するものばかりなのでとりあえず保留です。ほとんど変わってないですが、
入力で勝手に補完されるのは問題なので早めに公開しておきます。


840 名前:47(偽物) 投稿日:02/09/06 13:55 ID:5OZyCZ4l main/1030678466.html#901

だまされる方が悪いのだ。はっはっはのは!


841 名前:47 投稿日:02/09/06 13:56 ID:vQKYhrQX main/1030678466.html#904
β20.3です。β20以降と互換性あります。

・ 無駄にUPキャッシュ情報が付いているキャッシュのUPマークを消去するようにした
・ アップ・キャッシュ・ダウンファイルのファイルオープン・クローズをできるだけ行わないようにした
・ ダウンフォルダへの変換時に先にファイル全領域確保(クラスタ分断化対策)
・ キャッシュ出力時に数ブロック単位で領域確保(クラスタ分断化対策)
・ ダウンリスト編集すると検索画面が消えるのを修正

主にHDD周りの修正です。

まず初めの修正ですが、UPフォルダスキャン後に、UPフォルダに該当するファイルのない
UPキャッシュを探し出してキャッシュのUPマークを消すようにしました。

UPファイルからできたキャッシュは中身が空でも消されないように内部的にマーク付いてますが、
匿名性の点からこのマークはできるだけ消した方が良いのではないのかということで。

これにより、キャッシュ変換したUPファイルはUPフォルダを外すと完全キャッシュになります。
UPキャッシュは部分キャッシュとなり、次回起動時に消えます。
これにより、一度UPフォルダから外してまたUPするとハッシュの再チェックがかかります。

これだと、変換したUPキャッシュと同じハッシュ値で妙な名前のキーが来ると削除条件で消えたり、
以前自分でUPしたファイルを再ダウンする可能性が生じますが、とりあえず匿名性重視で
こちらの方が良いという意見が多そうですので試してみましょう。

なお、UPフォルダとキャッシュフォルダに同じハッシュのファイルがあると、
キャッシュの方がヘッダだけ(UPマークが付く)になりますので、UPキャッシュ変換を行ったら、
次回起動までにUPファイルの方を見えなくしないとせっかく手動でUPファイルから変換した
キャッシュの中身が消えてしまいますので注意です。



842 名前:47 投稿日:02/09/06 13:56 ID:vQKYhrQX main/1030678466.html#905

他にそろそろHDD周りがパフォーマンスのネックになっているようですので
対策しましたが、良くなるかどうかは環境によると思います。
実はバグを増やしそうなだけだったんで放置していた部分なんですが・・・

まず、ダウンフォルダ側は一気にファイル作ってしまっても
問題ないだろうということで、試しに変換の初めに全域を領域確保
するようにしてみました。これで分断化がおき難いかどうかはわかりません。

あと、キャッシュの方は問答無用で領域確保すると間違いなく無駄
なので、ある程度のブロック単位で拡張するようになってます。
少しはHDDがぶつ切れになり難いかもしれません。


843 名前:47(偽物) 投稿日:02/09/06 13:58 ID:5OZyCZ4l main/1030678466.html#910
>>909

さようなら

844 名前:47 投稿日:02/09/06 14:21 ID:vQKYhrQX main/1030678466.html#920
あー、ちょっとわかり難かったですね。917さんの通りです。

ネットワーク外部から見ると、送っているのがUPかキャッシュかはわからないようにできてますが、
本気で匿名性ほしい人はHDD内を見られてもUPしてたかどうかわからなくしてほしいということで、
ここのところに抜けがあったんで修正したってことです。

そこまで匿名性気にしないのなら無視してもかまわないと思います。


845 名前:47 投稿日:02/09/06 14:33 ID:vQKYhrQX main/1030678466.html#923

被参照量は他からダウンすると0にクリアされるようになってます。

あと、外部からキーがきたらその被参照量も適当にコピーするので、
あるノードが送ってくるキーの被参照量が0だからといって
それがUPファイルからの送信とは限らんです。

同様に、UPからの送信だからといって送ってくる値が0とは限らんです。

あの値はある程度の人気を示しているだけですね。


846 名前:47 投稿日:02/09/08 14:46 ID:/8IC26+B main/1031306058.html#151
β20.4です。互換性あります。
主に部分キャッシュ中継周りの修正です。

・ レジュームの中継で途中からダウンがスタートするようにした
・ 同一ノードへの重複ダウンチェックを、アップ側だけでなくダウン側でも行うようにした
・ 下方検索リンク限界数を5にした
・ 検索履歴クリアすると検索リストが増殖するので修正
・ ハッシュありの自動ダウン追加でキーが存在しないと落ちるバグを修正
・ キャッシュ変換の際に全領域確保するのではなく適当に拡張するようにした
・ 手動検索での検索クエリ発行規制時間を長くした
・ タスクが保留されている状態で終了するとファイルを閉じていないことがあるのを修正
・ キャッシュ書き込みエラーでタスク停止させていなかったので修正
・ ダウンロード終了時にもキー時刻を更新するようにした
・ 常駐したままで警告が発生してもアイコンが赤くならなかったので修正
・ 検索コンボボックスの並び順を新しいもの順にした

全体的にリンクが切れやすいのと、ダウン率が下がっているのを修正してあります。

まず検索リンクの方ですが、本来、上流リンク数が2で下方4であれば、規模が大きくなっても
破綻しないはずですが、この設定ですと遊びがないので、
ノードが増えてくるとどうしても接続が落ち着かなくなってきます。

ですので、今回実験的に検索リンクの下方限界を5にしてみました。
これで多少は検索リンクの接続が落ち着くんではないかと思います。



847 名前:47 投稿日:02/09/08 14:48 ID:/8IC26+B main/1031306058.html#153

あとダウン率低下ですが、自動ダウンで部分キャッシュ優先ダウンするように
なったのがかなり悪影響出ているんではないかと思います。

もし中継先で、キャッシュ後半のブロックがない状態なのに
中継依頼先が後半のブロックを要求すると、中継側のダウンが間に合わなくて
キーロスト(正確にはキャッシュブロックロスト)で切断されやすくなります。

今回これ対策で、中継側でも先頭からダウンかけるのではなくて、
適当に途中から読み出すようにしました。キャッシュの分割要求がよく上がってましたが
今回の修正でこの要望に似た挙動になるはずです。

この部分キャッシュ転送周りはちょっと面倒なことが多く、効率良く処理するためには、
本来キャッシュのどこを持っているのかを各ノードで情報交換すべきなんですが、
これをやってしまうと今度は匿名性に問題が出ます。

ですので、部分キャッシュに中継が入った場合でも常に先頭からダウンかけていた
わけですが、とりあえず今回の修正で多少はましになるんじゃないかと思います。

なお、今回の修正は全体でバージョンが切り替わらないと
効果がわかりにくいはずです。少しお待ちください。


848 名前:47氏に感動した一人 投稿日:02/09/08 22:06 ID:HVe0SgjH main/1031306058.html#223
こんなアイデアよいと思うのですがいかがでしょう。
512MBのファイルがあったとする。
64MBごとに単位ブロックにする。´↓きキΝЛ┐里茲Δ法パリティつけてもよし。
(ブロックサイズは均等でなくてもよい。)
各ノードに数ブロックごとキャッシュを流させる。
ノードA ´
ノードB ´↓キΝ
ノードC Л
ノードD ´↓き
置くブロックがどの部分かはランダム。
完全キャッシュにはしない。あくまで部分ブロックで持つ事がみそ。
どのファイルのどの部分を持っているかも利用者には全くわからないような
キャッシュの仕方にする。ファイルの検索をしても自分のディスクに
そのファイルの部分ブロックがどれだけあるかということすらわからないようにする。

Aが該当ファイルを欲した場合
伝達経路としてたまたま A-B-C-D が選択されたとする。
AはきキΝЛ┐足りないのでそれらの部分ブロックが転送されていくことになる。
DからきイCに伝わり、CにはきキЛ┐キャッシュに残る。
CからきキЛ┐Bに伝わり、Bには´↓きキΝЛ┐キャッシュに残る。
BからきキΝЛ┐Aに伝わり、Aはその時点でブロックがそろい、暗号化を解除し元ファイルを得る。

この時Bはたまたま完全キャッシュが残るわけだが、B自体はそのファイルを欲していない。
そこであえてBではAに転送が終わると同時に適当にブロックを消去することにする。
消去対象ブロックもランダムに。そして歯抜けのブロックキΝГ鬟ャッシュとして保持。
Aの暗号化解除作業が終わると同時に再度Aのキャッシュも歯抜けのブロック´↓キ┐砲垢襦
Aにもいつファイルが完成するかということを通知しない。今全体の何パーセントかとか、
転送中のファイルは何であるかという情報も全くわからないようにする。
ほったらかしておいたらいつの間にかできていたという状態にする。


849 名前:47氏に感動した一人 投稿日:02/09/08 22:07 ID:HVe0SgjH main/1031306058.html#224
このアイデアを盛り込むとよいメリット
1.各ノードとしては完全なファイルを保持しているわけではないので白に近いグレーになる。
2.ランダムな部分ブロックが拡散し、どこからでも部分ブロックを入手可能なので共有思想にマッチしている。
3.転送も小さめのブロックで行えるのでなるべく別のノードから収集することで全体としての速度も上がり、匿名性もあがる。
4.やたらにキャッシュを消すと他のブロックを収集するための時間が長くなるためキャッシュのまま残す人が増える。
デメリット
1.糞ファイルのキャッシュを消せない。


メリットに対しての話。
自分がどれだけ部分キャッシュ、完全キャッシュを持っているかの情報を使用者に
知らせるというのはWinnyのまったり共有するという思想からすると不要と思います。
むしろ匿名性等の部分でのデメリットになっていると思います。
私としては今どのファイルを持っているか、またどれだけの部分キャッシュを
持っているかということは各個人で認知不要かつ認知不可能にすべきで
Winnyネットワーク全体で大きな記憶媒体になればもっと発展するのではと思います。
参加者はHDDとネットワーク帯域を提供しあうという感じです。

デメリットについての話
糞ファイル対策はまた別案を考えるということで。
現時点ではすべてが優良ファイルである必要は必ずしもないかと思っています。
玉石混淆な部分はしょうがないことかと思います。例:2ちゃん


850 名前:47氏に感動した一人 投稿日:02/09/08 22:12 ID:HVe0SgjH main/1031306058.html#229
>>225 ごめ、ブロックをわかりやすくしたかったんだ。
このスレはほぼ全員がWinマシンで見てると思うんで丸数字使っちゃいました。


851 名前:47 投稿日:02/09/09 22:53 ID:A/vYmpUC main/1031306058.html#337
β20.5です。互換性あります。主にGUI周りの修正とバグ取りです。

起動すればすぐ気が付くと思いますが、見かけ的にはβ1以降で最大の変更となります。
操作周りはまったく変わってませんが、色の使い方が黒地系から白地系に大幅に変わりました。

・ 各所の描画色にできるだけシステム標準色を用いるようにした
・ ダウン予約追加するとその後動作が不安定になって飛ぶことがあるのを修正
・ 各設定ファイルでコメントアウト処理が無意味だったので機能削除
 (設定ファイルの行先頭が#だと入力スキップしていたが書き戻してなかった)
・ キャッシュブロックが完全かどうか判定が誤ることがあるのを修正
 (高速化のために判定結果をキャッシングされているのだが多重ダウン時にバグってた)
・ BBS見ただけで時刻修正されてしまうのを修正
・ リストコントロールの表示限界を200→500にした

Winnyでの上のボタン列はモードボタンなのでこれがタブに見えるように修正していたら、
連鎖的に色を変えることになって、結局色関連が全部変わってしまいました。

個人的には黒地ベースの方が見やすいと思いますし、そちらの方が
色もカラフルに使えていいんですが(白地だと明るい黄色や緑が見えない)
今までの青系の色決め付けですと環境によっては違和感出ますし、
だからといってカスタマイズ機能付けるのは面倒なので、
システム標準色を使うように修正しました。
どういう見かけが良いかは各自意見が分かれると思いますが、とりあえず実験。

あとは細かいバグフィックスです。ダウン追加時に怪しいタスクID登録すること
があって不正アクセス起こす(いつ爆弾が爆発するかは運なバグだった)とか、
多重ダウンで完全キャッシュ判定を誤るという痛いバグがあったので
早めに取り替えた方が良いと思います。


852 名前:47 投稿日:02/09/10 00:04 ID:ag4rrnyN main/1031306058.html#462
おめーら、感謝もせずに、文句たれてんな(`Д´)
こんな金にもならねー事、オェ!つくんの辞めっぞ!
さざけんなッ!人の苦労もしらねーでぽ
ロリコン死ね!グチャグチャになって死ね!本当に死ね!クズがッッ!
自分で自分のちんこ噛み切って死にさせせせら!!!!
人類の排泄した全てのスネ毛食って吹き飛べ!


853 名前:47 投稿日:02/09/10 02:47 ID:tgALDCG5 main/1031306058.html#536
緊急ですがβ20.51です。

そうじゃないかとも思ったんですが、やはり白地はよろしくないみたいなんで、
リストコントロール部分だけ元に戻しました(w
切り替えにするという手もありますが、面倒なんで固定です。

どうも上とのマッチングが悪い感じもするんですが、
やはり白地は見難いので黒地でいきましょう。

β20.5と色以外は変わってないです。

あと、β20系統ではネットワーク周りはそれほど変わってないはずなんですが、
どんどんコネクションの余裕が無くなっていっているようですので、
各所のバランス取りが必要です。

が、コネクション限界の方がどういう状況なのか良くわかってません。

とりあえず上流下流やポート0などでどういう状況なのか
報告していただけませんか?特にコネクションの状況です。

UPは一応できているようですので、偏りがあるだけだと思うんですが。


854 名前:47 投稿日:02/09/10 17:09 ID:kL8Do5/7 main/1031306058.html#678
β20.52です。互換性あります。パラメーターの微調整です。

・ キーの上昇頻度をノード速度にそれほど依存しないようにした
・ 手動検索のキーヒット率向上

どうもコネクション限界が悪化しているようなので様子を見てみたのですが、
全体的に上流ほど不利になっていてこれが原因でコネクション限界が増えているようです。

理由ですが、β19の後半で自動ダウンでの検索率を向上させたために、
キーがどちらかというと下流に流れる傾向が強くなったため、
ダウンをかけると上流にコネクションかける率が高くなったのが理由のようです。

Winnyでのキーの受け渡しは二通りあって、一定時間毎に少しずつキーを隣に
渡す伝播によるものと、検索によるものがあります。
ここで、キーの検索は一つ下までにはかかりますが、
基本的に検索は上流にかかるので、検索に頼ると上流のキーを取得しやすくなります。

それに対して伝播の方は、上下でそれほど変わりません(上流の方が早く伝達しますが)
これにより、下流ノードより上流ノードの方がコネクションが込み合っているようです。

一つの解決策として、上流へのキー検索率を落とす(つまりβ19初期に戻す)
というのも手ですが、これをやると今度は下流でのダウンが減少しますし後ろ向きですので、
下流のUP頻度のみ上げるようにということで、
上流方向のキー伝播は回線速度によらず比較的高速に流れるようにしました。

これにより上流ノードへの集中が比較的緩和されるはずです。



855 名前:47 投稿日:02/09/10 17:10 ID:kL8Do5/7 main/1031306058.html#679
あと、自動ダウンのヒット率が上がったのはいいんですが、相対的に
手動での検索のヒット率の悪さが目立つのでここも調節しました。

検索ボタンを連打するとヒット率があがるのはわかると思いますが、
Winnyでの検索ではクエリ拡散を極力抑えているので、
一度のクエリだけで検索されるノードは極少数です。
そしてクエリのたびに検索される経路が変わるので、
クエリを連発するとヒット率が上がることになります。

これに関して、プロトコルを変えるというのも手ですが、
これは昔のβで何度も試していて現状の方式が無難だとわかっていますので、
一つの手としてクエリ連発をデフォルトの動作としてみました。
検索ボタンを押すと、内部で自動的にクエリを連発します。

もちろんこの状況で検索ボタンを連打されるとクエリで溢れてしまうので、
検索ボタンの連打制限はかなり長くなってます。
これで見かけ上の手動検索ヒット率がかなり改善されるんじゃないかと思います。


856 名前:47 投稿日:02/09/10 17:11 ID:kL8Do5/7 main/1031306058.html#680
HDDに関しては基本的にOS任せで、OSのキャッシングを信頼してます。
できるだけメモリとってください。あと、OSはできるだけまともなものを使うということでお願いします。


857 名前:47 投稿日:02/09/12 23:04 ID:qZiNsEqA main/1031801912.html#108
β20.53です。細かい変更だけです。

・ ボタン表示部でリソースリークがあったので修正
・ タスク状況のデバッグ表示を削除
・ キー保持限界を1万→2万にした
・ ログやシステム情報表示でゴミ出ていたのを修正
・ 掲示板検索のワードが順番逆になっていたので修正

ボタン表示が怪しかった(透明なボタンでリーク?)ので直しましたが、
これぐらいなら平気なんではという部分なんでランタイムエラーで落ちる
というのが直らない可能性もあります。とりあえず落ちるという方は
これで直るかどうか試してください。

かなりファイルを開きっぱなしのままになってるので落ちる理由はこちらかとも思ったんですが、
落ちるのがGUIススレッドの方なんでこれじゃないかと思いますが・・・

あと、ここんとこ忙しかったので作業できてませんが、
要望の類は暇見てやりますので少しお待ちを。
連休中は暇そうですし。


858 名前:47 投稿日:02/09/13 16:47 ID:fNcQuQiF main/1031801912.html#227
細かい変更ばかりですいませんがβ20.54です。パフォーマンスチューニングです。
機能や動作的には今回のバージョンアップで何も変わっていません。

全体的にファイルの数が増えてきているのでできればヒット率を落とさないように
上流にはキーを多めに保持していただきたいところ。
しかし重くなってだからといって制限数を戻すのは後ろ向き。

ということで、現状のボトルネックになっている箇所を高速化しました。

現状でCPU負荷が高いのはほとんどキーの検索部分で、
問題になっているのがファイル名を暗号化していることによる変換処理負荷です。

検索結果に関しては既にキャッシュ化で高速化はされていたのですが、
最近の修正でクエリ検索頻度が増えているためキャッシュミス頻度が多かった
(検索ワードが変わるとキャッシュがクリアされる)ということで、
暗号キーがほとんどNULLキーなのも考慮して暗号変換部もキャッシュ処理するようにしました。
下流から大量にクエリが送られてくると突然重くなる現象が緩和されるはずです。

あと、キーやタスクで別々に持っていた暗号バッファを共通化して
無駄なメモリ確保を減らしてあります。それなりにCPU負荷が下がると思います。


859 名前:47 投稿日:02/09/15 00:06 ID:tVaU4u5Y main/1031801912.html#361
β20.6です。互換性あります。主にPort0関連の修正です。

・ 転送リンクでもBadPort0チェックするようにした
・ 変換後、ダウン条件を削除するか選べるようにした
・ 子のPort0がいないPort0キーをクリアするようにした
・ 低速ノード警告を出さなくした
・ ダウンフォルダやキャッシュフォルダをアップフォルダに追加できないようにした

どうも人が増えているようでPort0周りの問題点が見えやすくなってきたので修正しました。

BadPort0のままでも問題なく動いてしまうことが多いようなのですが、
ポート警告を緩めるとまた誤警告での停止に悩まされる方が出ますので、
ポート警告の方はそのままで、転送リンクにBadPort0チェックをかけるようにしました。

あと現状の問題点として、ダウンタスクのタイムアウトが生じやすいというのが増えてます
ので、この原因だと思われるPort0キーで接続できないキーを再チェックしてできるだけ
外部に流さないようにしました。これでタイムアウトが減るはずです。

今回のは主にUP側の修正ですので効果が見えるのに時間がかかると思いますが、
テストよろしくお願いします。

あと要望の多いようだったダウン条件の削除選べるようにしておきました。
キャッシュ変換が切ってなければ、キャッシュ変換終了後に消すようになってます。


860 名前:47 投稿日:02/09/15 14:08 ID:SCSlinKr main/1031801912.html#452
β20.61です。互換性あります。キーに関するパラメータ微調整です。

・ キーバッファ削除速度を向上
・ 自動ダウン時にハッシュありでも検索ワードで検索していたがハッシュ値だけで検索するようにした
・ 検索クエリへのキーパック個数を減少

β20.6の修正でキーがかなり増えてきているので対処しました。

とりあえず処理しきれていてネットワークが溢れていないのであれば、
保持しているキーは多い方が検索ヒット率があがるので良いのですが、
メモリを消費しますし、あまり遠方のキーが大量に流入してくると今度は
クラスタを飛び越えてキーがくるので、クラスタ化が破綻しやすくなります。

Winnyにおける検索は、あくまで遠方にあるノードを引き寄せてくるためのもの
(ファイルやり取りすると接続優先度が上がるのでノードが近づく)であって、
クラスタ化のことを考えると、拡散により生じるクラスタ周辺ノードとのやりとりが
頻繁な方が系全体としては好ましくなります。ノードが遠方にあるまま大量にキーをやり取りしてると、
結局ダウン率が落ちてきて(転送率が増えるため)全体の効率が落ちることになります。

ということで、問題はあいまいな単語検索により生じる遠方キーの大量流入ですので、
これを避けるために、検索クエリパケットへのキーパック制限を減らして、
キーバッファの削除率を増やしました。キーの寿命は変わってません。

これでもかなりのキーを持つ事になるとは思いますが、多少はメモリ消費状況が
良くなるんじゃないかと思います。汎用的な単語での検索ヒット率が下がりますが、
個別では上がると思います。

なお、検索に関しては途中の中継ノードによりますので、
ノードの多くが新バージョンに変わらないとその効果が見えにくいはずです。


861 名前:47 投稿日:02/09/16 15:19 ID:m3PF53a2 main/1031801912.html#594
β20.7です。主にGUI周りの修正です。

・ ダウン優先度決定のパラメータをユーザ側で設定できるようにした(ファイル検索→優先度設定)
・ 検索ヒット数を表示するようにした
・ 検索ボタン押して一定時間後に画面リフレッシュするようにした
・ 検索表示で全画面クリアを減らした
・ リストからのタスク起動を一度に100個までに制限
・ 変換タスクは処理しているファイルサイズが小さいものほど優先させるようにした
・ 初期ノードボタンを一番左にもってきた
・ β20.6の修正でのPort0キー切断が調子悪いようなのでやめた
・ BBSでSJIS先頭コードのみだと生じる問題を修正

今回の新機能ですが、自動ダウンでダウン対象が複数ある場合の
優先度をユーザーの方で調節できるようにしました。

大きさ、既にダウンしたブロック数、更新日時、参照数を適当な重みで
混ぜることができます。キー検索結果での優先度が変わるので、
優先度でソートしてみて、適当に好みの順になるように調節してください。

あと、調子悪いのはβ20.6でのPort0関連の修正が主な理由のようですので、
戻しておきました。もしかするとキー数が増えているのが主原因かも
しれませんがとりあえず怪しい順に戻してみるということで。


862 名前:47 投稿日:02/09/16 20:23 ID:SxaAL5JS main/1031801912.html#634
頻繁ですいませんが、β20.71です。

・ 仮想キー保持個数を5000〜50000までユーザー側で可変とした
・ ダウンリストでのダウン状況を少し詳しく表示するようにした
・ 自動ダウンでのクエリ発行率を少し増やした
・ 接続停止時に未接続のコネクションが残ってしまうのを修正

仮想キー個数限界をユーザー側で設定できるようにしました。
これは主にPCスペックの設定となります。

このパラメータは設定が変ですと自ノードでトラブルだけ
(値が大きすぎると重すぎて飛ぶし、小さすぎるとダウン率が落ちる)
ですし極端に動作が重いノードが多くても全体で調子悪いですので、
ここはユーザー任せにしても大丈夫だろうと判断しました。
書かないでもわかると思いますが、上流ほどこの値が大きいのが理想です。

将来的にネットワーク状況やPC状況が変わってきたときに
私の方でプログラムを調整しないでも、ユーザー間の自主的な設定で
これが吸収できて系が安定するのが理想ですが、
調節するためのパラメータとしてこれなら良いだろうとの判断です。

あまり設定を増やすと系全体で調節しきれなくなる可能性があるので、
ネットワーク絡みの設定はできるだけ減らしたいのですが、
回線速度とこのパラメータの二つ程度なら調度良いのではないかと思います。
各自で調子が良くなるように設定お願いします。

あとはそれほど変わってません。


863 名前:47 投稿日:02/09/18 02:54 ID:FyWGOMvr main/1031801912.html#911
β20.72です。互換性あります。バグ取りだけで新機能はありません。

・ Port0の持つキーが検索クエリでヒットしないのを修正
・ ファイル転送リンクが限界になるとBBSファイルUP,DOWNも出来なくなるのを修正
・ BBSで表示不可能な文字はカットするようにした
・ BadPort0チェックのためにBBSでタイムアウトが多発していたのを修正
・ 同じBBSを二回読みに行った時にタイムアウトしていたのを修正

いままでの修正で大量にバグってたので修正しました。
特にファイル転送関連の変更でBBSの方に問題が出ていたので修正してあります。
あと、ファイル転送もPort0周りで変な挙動していたので修正しました。



864 名前:47 投稿日:02/09/18 08:14 ID:Ip6rzPH2 main/1031801912.html#936
β20.73です。互換性あります。Port0がUPできないことに関するバグ取りです。

・ Port0がアップするために逆接続したコネクションをBadPort0扱いして切断してしまうのを修正

そういえばPort0だと転送リンクの上下が逆(接続かけてきた方が上流)なので
Port0がアップするためにダウン側に接続したコネクションを、Port0ノード自身が
BadPort0だと勘違いしてタイムアウトで自分で切ってしまうということに気がつきました。

このPort0からのUPの場合かなりやっかいなことになってまして、

1.ダウン側がアップするPort0ノードの一つ上流ノードに接続
2.接続された一つ上のノードが、検索リンク経由でポート0ノードにダウン要求ノードへの接続を依頼
3.Port0ノードがダウン依頼ノードに転送リンク接続(ただし通常転送リンクと上流下流が逆)
4.ダウン依頼側がPort0からの転送リンク接続に気がついたら上流ノードへのリンクを切る
5.Port0ノードに接続されたコネクション経由でアップ要求を送る
6.以下、通常の転送と同じ

これに加えてポート設定が不良なノードを自動的に排除するために全リンクに関して、

1.接続があったらネゴで申告のあったポートに空接続をかける
2.Winnyプロトコルでのネゴシエーションに成功したらPortテスト成功
3.逆接続がタイムアウトしたらBadPort0判定

となってます。



865 名前:47 投稿日:02/09/18 08:15 ID:Ip6rzPH2 main/1031801912.html#938
β19のころとソース見直してPort0関連はほぼ同じなのになんで調子悪いのか首を
捻ってましたが、転送リンクとBadPort0判定の組み合わせ部分で見落としがありました。
前回直した検索関連のバグと合わせてかなり謎な挙動になっていたようです。

とりあえずまだPort0関連でバグがあるかもしれませんが、ここは修正しないと
間違いなく問題ですので早めに修正しときます。
特にPort0の方は修正してテストお願いします。

なお、なんでそんな頻繁に修正してるんだと思われるでしょうが、
この手のピュアP2Pアプリの場合テストが厄介で、動かしてみないと実際の挙動が
わからないので我慢してください。

簡単なLANテストだけで実験していて、実際の挙動は公開してみないとわからない
状況ですので、実行テストなしでいきなりプログラム公開しているような状況です。

複数修正してから公開するとどこが悪いのかわからないので
もっと頻繁にバージョンアップしたいのですが、さすがにそれはまずいでしょうし。

と、本来なら数人でテスト専用のネットワーク作ってやるべきなんでしょうけど、
皆さんのお手を借りてテストしている状況です。すいませんがよろしくお願いします。



866 名前:47 投稿日:02/09/21 03:48 ID:99e5U6c8 main/1032306607.html#372
見てられません
おまえらもっと要望減らせ

867 名前:47 投稿日:02/09/26 01:36 ID:4+ckLU93 main/1032965470.html#47
ここ数日警察通いです
タイーホ目前のようです
誰か助けて!!

868 名前:47 投稿日:02/09/27 01:51 ID:d4f70qtE main/1032965470.html#101
β20.8です。β20系統と互換性あります。

・ キーでの名前検索を逐次検索でなくてテーブル引きで行うようにした
・ 自動ダウンでのリスト処理速度を向上
・ Port0ノードがUPされにくいのを修正

ここのところ忙しくて修正が進んでなくてすいません。

とりあえず今現在で一番ネックになっていると思われる
キーの名前の検索部分高速化を行いました。これに伴い
ダウンリストの処理速度が大幅に上がってます。

ただ、メモリを消費しますし、ある程度経つと検索テーブルを
ガーベッジコレクトする必要があって、まれに固まっているように
見えるという欠点が生じます。GCはキー保持数が大きくなれば
発生頻度が減りますのでメモリに余裕があるPCでは
キー保持数を増やしてください。

検索の負荷は今回の修正でかなり下がると思いますが、
どちらが良いかは動かしてみて判断お願いします。

あとPort0周りも修正しましたが、転送依頼側のバグでしたので、
Port0の上流ノードが新バージョンにならないと効果が見えません。



869 名前:47 投稿日:02/09/27 22:08 ID:R06qgX3H main/1032965470.html#203
β20.81です。β20系統と互換性あります。

・ Port0ノードのUP率向上
・ Port0ノード間で接続することがあるのを排除

β20.5近辺でやった作業をまた繰り返しているだけな気もしますが、
気長にお付き合いください。Port0が普通にUPできるようになれば
全体として帯域に余裕が出ますし、Port0の制限も緩めることができます。

Port0用のテスト版作り直してLANテスト繰り返してみましたが、
通常ノードのもつ仮想キーがPort0ノードに入ってこれがまた戻って
を繰り返すのでわけがわからない挙動になっていました。
結果、Port0は外部から接続不能なのに、直接接続しにいってタイムアウト
もしくはキーロストという挙動になり易かったようです。

これを徹底的に排除しましたので実験お願いします。

とりあえずβ20.54系統でPort0の調子が良いのにβ20.6以降で調子が悪い
ということで理由がわからなくて悩んでいましたが、あれはバグが違うバグで
相殺されていただけでたまたま調子が良かっただけです。
β20.6でかなり変えたので作りこみが甘い部分が露呈しているだけです。
Port0周りはかなり複雑な挙動になっているので
動作が安定するまで少しお待ちください。

あと、修正を一度にやるとわけがわからなくなりますので、
他の修正はもうしばらくお待ちください。


870 名前:47 投稿日:02/10/02 19:45 ID:j8nyXCyb main/1032965470.html#881
WinnyBBS使います。

871 名前:47氏語録 投稿日:02/10/02 21:16 ID:CeFWWudP main/1032965470.html#891
438 名前: 47 投稿日: 02/04/05 23:05 ID:bBRp+Hyf

ある程度できたら本体はこのシステムで提供するから
捕まったら自業自得(w


476 名前: 47 投稿日: 02/04/06 01:17 ID:M5Lc7MaX

ソフト公開で逮捕というとFLMASKの例があるから絶対無いともいえんけど、
その前にトンズラできると思うなぁ。
初めは目立たないWEB上でひっそりやって目立ってきたら
自分で作ったワールド内に逃げればいいと思われ。

広まるほどの完成度に達すれば逃げられるし、
達しなければ捕まることも無いという二重の安全策(w

あとMXでの公開の方が絶対危険だよね。
あれ珍しいファイルだと提供者のIPが一発でばれるし。


872 名前:47 投稿日:02/10/03 00:33 ID:xB+USidv main/1032965470.html#946
バージョン上げようと思ったらデリられました。

------------------

Yahoo!ジオシティーズです。

ご存知のとおりジオシティーズでは、「Yahoo!JAPAN 利用規約」および
「Yahoo! ジオシティーズガイドライン」等に沿ったホームページ作りを
お願いしております。

ところが、以下の点で違反しているとの申告がありました。

該当URL
[ ttp://www.geocities.co.jp/SiliconValley/2949/ ]

違反項目
◎隠しページまたは隠しファイル

現在、ホームページのご利用を停止しております。

------------------

復活させるようにメール出しときましたがまた同じことになりそうなので、
実験的にWinnyの方で上げてみました。

信用できるのか?という問題はありますが、Winny10b209.zipです
ハッシュが3e4b699fb2258c7284c9cb3fc46bfa3dです。

どの程度で拡散するのか実験お願いします。



873 名前:47 投稿日:02/10/03 00:36 ID:xB+USidv main/1032965470.html#954
β20.9。互換性あり。バグ取りや微調整だけで新機能はありません。

・ Port0間のファイルやり取りにおける中継動作が行われていなかったので修正
・ UPファイルハッシュチェック時に時間と初期参照量にばらつきがでるようにした
・ リンクの切断忘れがあるのを修正
・ ダウンリスト追加時に検索ワードに','が含まれていたらスペースに置換するようにした
・ ドライブの空き容量が100Mを切ったら転送リンクを切断するようにした

ここのところ余裕がなくてここの発言にちゃんと目を通せてませんが、
覚えていた箇所や気がついた点を修正しました。

何か致命的なバグがあったらその理由を明確に主張していただければ
優先的に直しますので指摘お願いします。


874 名前:47 投稿日:02/10/03 00:57 ID:xB+USidv main/1033573554.html#63

結構早く落とせるようになりますね。Winnyで公開でも平気かな?



875 名前:47(このスレの) 投稿日:02/10/03 00:59 ID:IEvPNuSi main/1033573554.html#79
ウィルスなしです、本物でした!
共有をWinnyだけにします。光なんですぐ広げられるはずです。
申告速度1000up27です。

876 名前:47 投稿日:02/10/03 01:11 ID:xB+USidv main/1033573554.html#133
まだIP同じかテスト


877 名前:47 ◆tLZwerNc 投稿日:02/10/03 01:13 ID:xB+USidv main/1033573554.html#144
テストその2



878 名前:47 ◆tLZwerNc 投稿日:02/10/03 01:15 ID:xB+USidv main/1033573554.html#155

んでは今後これで行きます

トリップも完全じゃないと思うのでそこのところよろしくです。
ちなみに私はもうWinny落としてますがβ20.9出回ってます?



879 名前:47 ◆Gg4cC206 投稿日:02/10/03 01:16 ID:dWqo9XqA main/1033573554.html#168


880 名前:47 ◆tLZwerNc 投稿日:02/10/03 01:19 ID:xB+USidv main/1033573554.html#188
公式が復活するようならそっちに戻しますがとりあえず暫定処置ということでお願いします。
バージョン上げるときは当分このトリップでハッシュ指定して公開することにします。

なお、トリップをジェネレータで作ろうかとも思いましたが、そうすると
解析されやすくなるはずなので、こちらの覚えやすいものにしときました。
よろしくお願いします。


881 名前:47 ◆tLZwerNc 投稿日:02/10/03 01:20 ID:xB+USidv main/1033573554.html#195
後適当にミラーお願いします

882 名前:47 投稿日:02/10/03 03:21 ID:zhrUx3EI main/1033573554.html#369
トリップはかえって個人が特定されてしまうので使わないってあれほど言ったのに…
今回っている最新版は、確かに動作はするようですが、私が作成したものでは
ないので、自己責任でお願いします。

883 名前:47 ◆KbtLZwerNc 投稿日:02/10/03 13:08 ID:b0LhcVEH main/1033573554.html#479
こうなります


884 名前:47 ◆KbtLZwerNc 投稿日:02/10/03 13:10 ID:b0LhcVEH main/1033573554.html#480
FreenetとWinnyが新聞に載ったことですし、なんでこんなアプリを作っているか
少し書いておきます。一言で言えば「Freenetの時代が来るぞという啓蒙」です。

実は私は正確には47ではなく40(初発言は、MXの次はFreenetだろうとの一言)だったりしますが、
Freenetの概念(匿名性実現)は今後非常に重要になるだろうと思ってます。暗号技術と同じです。
デジタルコピーを防ぐ技術よりも匿名性を実現するシステムの方が実現が容易だということでもあります。

もちろんFreenet(の概念に基づくシステム)が使い物になるのか?という懸念はありましたので、
これを確認するため使い物になるFreenetを目指して作ったのがWinnyだったりするわけです。
WinnyではWinMXの後継という役割はおまけです。広まらないと意味無いんでMXの名を借りてるだけです。

ここで注意ですが、私はソフトウェアはタダであるべきとか、音楽その他の著作物が
全てPDSであるべき(=クリエータただ働きすべき)と考えているわけではありません。
Freenetの作者のように個人の自由な発言権利がどーのこーのいう気もありません。

言いたいことは、何でもかんでもデジタル化して遠隔地に無劣化コピーできるこの時代、
今の著作物に対する課金システムはもう古いんではないのか?ということです。



885 名前:47 ◆KbtLZwerNc 投稿日:02/10/03 13:10 ID:b0LhcVEH main/1033573554.html#481
物の流通と違い、デジタルデータに関してはこれからの時代、流通コストが限りなく
ゼロになっていきます。となると、ユーザーはクリエータに直接お金を払うべきであって
運送屋やCD屋、パッケージ屋、複製製作者などにお金を払う必要はないはずです。
流通コストがゼロにできるのであれば、それらは中間マージンであって
無くてもいいもののはずです。それら仲介でお金を取るのは搾取でしかありません。

ここで、どんなにコピーし放題でも、あたらしいコンテンツだけはクリエーターが作らない限り
生まれません。そのため、クリエーターに対して直接お金が払われるようになればソフトは
コピーフリーでかまわないはずです。ユーザーがお金を払わないのなら新しいコンテンツが
作ってもらえないだけです。つまり、ソフトコンテンツ代は前払いであるべきなのです。

具体的にどうすればいいかですが、たとえばソフトウェアの代金はパッケージソフトでも
後払いはやめて前払い基本にする、新機能要望書き込みに課金するなり、
フリーで出しといて次回作にカンパを募るなどいろんな手法があるでしょう。
カンパの手法では、人気があるフリーソフトが出せれば次回作に対する期待があつまって
お金が集まる。これは結果的に後払いと同じなので、中古システムと値崩れ現象がある現状と
変わらないと言えばかわらないのかもしれませんが・・・


886 名前:47 ◆KbtLZwerNc 投稿日:02/10/03 13:10 ID:b0LhcVEH main/1033573554.html#482
結局言いたいことは、匿名性保持技術の出現により、デジタルコンテンツ流通は必ず
パラダイムシフトせざるを得ない状況になるということです。

お上の圧力と従来の法・ユーザーのモラルに頼るのも一つの手ですが、
このやり方ではせっかくの高速ネットワーク資源が死蔵しますし、
匿名性維持技術の発展で違法行為取り締まりのコストが無視できなくなっていきます。

特に日本は家庭向け回線だけ無意味に早くなっているので、
世界で最も早くこれが問題化するでしょう。そして時間は後ろには戻りません。

とりあえずWinnyもある程度広まったことで、私の当初の目的(Freenet啓蒙)は達成できていて、
あとは匿名性などで問題出たら対処ということで基本的に放置になっていくとは思います。が、
技術面で興味のある方は今後とも時間を前に進めるのにご協力ください。
Ver1.0目指して完成はさせますし、他の人が別のものを作るのも歓迎します。

もちろん、現状で人の著作物を勝手に流通させるのは違法ですので、
βテスタの皆さんは、そこを踏み外さない範囲でβテスト参加をお願いします。
これはFreenet系P2Pが実用になるのかどうかの実験だということをお忘れなきように。



887 名前:47 ◆KbtLZwerNc 投稿日:02/10/03 13:10 ID:b0LhcVEH main/1033573554.html#483
終わり



888 名前:47 ◆KbtLZwerNc 投稿日:02/10/03 13:15 ID:b0LhcVEH main/1033573554.html#487
偽物だと思われるのもなんなので、ちょっと時間かけて総括書いてみました(w


889 名前:47 ◆KbtLZwerNc 投稿日:02/10/04 16:56 ID:mNuvODCR main/1033699379.html#37
ジオの方が無事復活したらしいのでβ20.9に変えときました。
中身はWinnyで公開したのと同じです。

以降もWinnyで配布してもいいんですが、やはりWebで公開の方が楽なので
今までどおりにいきます。ジオ側の管理者ならアーカイブ内容を変えられるので
信頼性からいうとWinnyで公開の方が上な気もしますがまぁ大丈夫でしょう。

何かあったらWinny側で公開可能なことを確認できただけでも良かったです。
ということで、このトリップも当分使うことがなくなります。

あと、旧バージョン残していると使用許諾違反になるようなので、
これからは残しません。旧バージョンが必要になることも
そうそうないとは思いますが、よろしくお願いします。


890 名前:47 投稿日:02/10/04 21:09 ID:Z51aamX3 main/1033699379.html#83
β20.91です。互換性あります。

・ キー検索テーブルガーベッジコレクト時の負荷を軽減
・ Transfer UPが制限を超えることがあるのを修正

細かい修正だけです。長時間動かしていて落ちる大きな理由が
GC開始時の負荷のようなので、ここを分割で処理するように
変更することで負荷を下げました。GC時に落ち難くなるはずです。

報告のあるランタイムエラーはこちらの環境では発生しない現象なので
首を捻ってます。こうすると出やすいなどあったら報告お願いします。


891 名前:47氏 投稿日:02/10/04 22:23 ID:BfQ4Gc+W main/1033699379.html#118
>>113
そんなこと知ったことではない

892 名前:47 投稿日:02/10/06 19:44 ID:HoMrMLQK main/1033699379.html#391
β20.92です。互換性あります。

・ 自動検索切断時に、待ち受けポートを開きなおしていたのを止めた
・ GCの発生頻度を下げた
・ メモリ確保の例外処理を強化

どこが変わったかほとんどのノードでわからないと思いますが、
不安定な環境だと違いが出るかもしれません。

基本的に動作安定を狙ってます。報告のあった箇所やランタイムエラーは
どうもメモリ確保に失敗すると生じるようでしたのでその辺を強化してあります。
ただ、今までこれが理由で飛んでたりすると、
どちらにせよ挙動が不安定なんじゃないかと思います。

特に今回、GC発生を抑えたんで逆にメモリ使用量が増えているので、
メモリが足りないPCだとポート警告が出るんじゃないかと思います。

そのときは設定でキー限界数を下げるようお願いします。
キー限界が下がるとGC開始も早くなります。


893 名前:47 ◆KbtLZwerNc 投稿日:02/10/06 19:55 ID:sMD+7zJT main/1033699379.html#399
公開直後十分以内に落とした人は再ダウンした方がいいかも(^^;


894 名前:47 投稿日:02/10/07 08:37 ID:4v6YSyRg main/1033699379.html#552
β20.93です。互換性あります。

・ Port0が送ってきたキーの整合性(転送不能キーの検出)チェックを高速化
・ 処理負荷が高く優先度を下げても問題ない内部タスクの優先度を下げて処理負荷を軽減

主にキーが増えてきたときの負荷を下げる作業です。
キーが増えてもメモリを消費するだけになります。
逆にキー数を少なく申請するとGC発生が起こりやすくなって
CPU負荷が高くなるかと思います。

メモリが少ないけどCPUが早い方はキー数を少なく、
CPUが遅いけどメモリが多い方はキー数を多く申請した方が良いんじゃないかと思います。


895 名前:47 投稿日:02/10/08 08:41 ID:+h+i6wr7 main/1033699379.html#674
β20.94です。互換性あります。バグ取りです。

・ サイズが64Kの整数倍のファイル処理が変だったのを修正

以前ハッシュチェックのときも同じことが起きましたが、
同じ問題が転送部にも残っていました。β1から残っていたバグです。
見つけた方はお疲れ様でした。

なお、上の条件に当てはまるファイルはハッシュ値が変わるので
落とし直しになります。


896 名前:47 投稿日:02/10/10 08:55 ID:hYza2Kp3 main/1034139087.html#139
で、俺はどこに降臨すればいいんだYO!

897 名前:47 ◆2ch/47HH66 投稿日:02/10/13 00:25 ID:zikgH1Lm main/1034139087.html#465
WinnyをNT専用にしたことはありません
9Xでも動作するようバグは取り除いて逝きます

898 名前:47 ◆2ch/47HH66 投稿日:02/10/13 02:54 ID:zikgH1Lm main/1034139087.html#482
ご自由にどうぞ

899 名前:47 投稿日:02/10/14 20:07 ID:FdqoCFLB main/1034139087.html#561
ここのところ忙しくてバージョンアップできなくてすいません。
年末まで忙しいので何か面白い変更点でも見つからない限り
細かいバグ取りを気が向いたときにやる程度になると思います。

で、あと残っている大きな問題は暗号キー周りなんですが、
NULLキーしか使われなくなっているのでちょい変えようかと思ってます。
β1以前の設計時にNULLキーで暗号かけるかどうかで
悩んだことがありましたが、思ったとおりになってますし。

ここでどうするかいくつか候補があるのですが、

1.ユーザー指定の暗号キーはやめて、内部でNULLキー固定(ほぼ現状はこれ)
2.暗号キー機構は今のままでバグだけ取る(UPされないのでどうせ使われなさそう)
3.NULL暗号キーを禁止(強制的に必ず何か指定させる→ウザイだけか?)
4.NULL暗号キーでは暗号化しない(わざとNULLキーの匿名性を下げる→危険なだけ)

ここまでは後ろ向きなやり方です。

で、最近思いついたのが次の方式です。

5.暗号化されるのはファイル内容だけとし、ファイル名は常にNULLキーで暗号化
6.5の修正に加えて、暗号をノード別に動的に変更して交換的な行為を可能にする
7.6を発展させて、コンテンツに課金可能なシステムに持っていく
(ファイル落とした各自から確実にお金を取れるシステム)



900 名前:47 投稿日:02/10/14 20:08 ID:FdqoCFLB main/1034139087.html#562
5ですが、これだとファイルが暗号化されていても検索とダウンは自由にできるが、
パスワードを知らないと展開が出来ないということになります。
これだと、暗号付きのZIPを共有するのとなんら変わりがありません。

ただし、暗号化したファイルでも常に検索にヒットするので、
今のように暗号化すると見えなくなって、
誰にもダウンしてもらえないということはなくなります。

面白いなと思ったのが6です。まず、キャッシュの暗号キーをノードを渡り歩く間に動的に変えます。
キャッシュの暗号キーを、UP生成者がかけたキーとノード毎に生成されるキーの二つの複合キーとして、
UP者が設定したキーは固定。もう一つのノード毎に生成されるキーは
キャッシュコピー毎に動的に変わっていきます。

キャッシュ展開キーを得るためには、UPした人に暗号キャッシュのノードキーを渡して
完全キーを生成してもらう必要があります。

ここで、検索やダウンは5と同じで自由にできます。キャッシュ変換で暗号が必要になります。

キー発行は相手を直接知っているのならメールやIMなどで行えばいいでしょうし、
匿名でなら匿名BBSにハッシュと手持ちのキーを晒して展開の見返りとなる条件
(別のものをUPさせるとか金とか)を示して、完全キーを教えてもらうということになるでしょう。

このやり方だと、暗号キーの取りを外部の人が見ていても暗号がわからず、
そのキーを使えるのは特定の人のみであって、キャッシュを展開するには、
UPした人にそのつど直接アクセスして展開キーを発行してもらう必要が出ます。
匿名BBSと組み合わせれば匿名で不特定多数と交換的な行為が可能になります。


901 名前:47 投稿日:02/10/14 20:08 ID:FdqoCFLB main/1034139087.html#563
6の応用で7のコンテンツへの課金も可能なシステムにもっていける可能性もありますが、
コンテンツの暗号を解いてもらったあと、Winnyに暗号無しでUPすることで
そのファイル中身を誰でも見えるようになってしまうので
実際には破綻してまともな商用システムにはできないでしょう。

ただ、6は交換目的であるとか、新作を一時的にレア扱いにして
無条件に開放されないようにする用途などに利用できるかと思うので
それなりに利用法はあるかとも思います。

この様な感じで暗号方式の面白い案は無いでしょうか?
できれば7まで持っていけると画期的ですが。

なお、6なら比較的簡単に実装できます(5とほとんど同じでキー発行機能を付けるだけ)。

キャッシュのバージョンが0.4になりますが、0.2→0.3同様、キャッシュの互換性は保てます。
展開できないキャッシュを勝手に落とすのも嫌でしょうから、暗号がついているファイルは
自動ダウンの対象にはならずにハッシュダウン専用になるかな?

実装して見せないと判りにくいと思いますが、この辺の技術面で興味のある方はご一考を。


902 名前:47 投稿日:02/10/15 11:35 ID:OTyje1Js main/1034139087.html#750
ネタでした。

903 名前:47(偽) 投稿日:02/10/15 14:05 ID:NUfSyZ/l main/1034139087.html#763
561,562,563に騙されちゃったのね。
貴方良い人ね・・・。次からはトリップをよく見ようね。

         ∧_∧
        ( ´∀`)
        /,   つ
       (_(_, )
         しし'


904 名前:47(偽) 投稿日:02/10/15 21:03 ID:NUfSyZ/l main/1034139087.html#774
漏れは、良い事をしたのですか・・・・・?
折角、WINNYでウイルスを流す準備をしようと思っていたのに。


905 名前:47 投稿日:02/10/15 21:10 ID:fyOCn9HG main/1034139087.html#775
β20.95です。互換性ありますがβ20.9以降としか繋がりません。
また今回チューニングだけで新機能はありません。

・ 受信バッファがあふれてくるとコマンド処理で長時間待ちが生じるのを修正
・ 受信あふれを防ぐためのWait処理をやめた(状態を悪化させるだけでダウン速度が落ちるため)
・ 受信バッファ拡張の大きさに制限を設定
・ ポート警告のチェック時間を延長
・ BBSコネクションの場合、BadPort0チェックを省略するようにした

主にPCの負荷が高くなったときの対処です。
スペックの低いPCや他に何かタスクが動いているときでも
挙動不審になり難くなるんじゃないかと思います。

あと、561からの発言は冗談や偽物ではないですので検討よろしくお願いします。

どうも今の論調ですとバグだけ取ればいいのかなという感じもしてますが、
前書いた6の機能は機能としてあっても邪魔にはならないので、
あまり使われない今の暗号キーよりは新機能として面白いかなというだけのことです。
別にこれの使用が強制で共有機能が使えなくなるわけではありません。



906 名前:47 投稿日:02/10/16 18:45 ID:AoEDRTuI main/1034697627.html#424
β20.96です。互換性あります。
また今回はβ20.95のバグつぶしです。

・ 受信あふれを防ぐためのWait処理をやめた(状態を悪化させるだけでダウン速度が落ちるため)
前バージョンで改善をしたつもりだったのですが、事実Wait処理があったほうが、
ダウン速度があがるので、β20.95の仕様に戻しました。


907 名前:47 投稿日:02/10/16 19:56 ID:LHXFC+zW main/1034697627.html#453
新暗号キー不評ですね(w

設計段階の大きな問題点として
1.交換用?暗号キー
捏造対策(キーを知らないと捏造か判断できないため)

2.コンテンツ配信(課金)
著作権保護
有料コンテンツ配信後インフラを維持できるか

があります
できるだけ前向きに発展させたいので、意見があればおねがいします。


908 名前:47(453=424) 投稿日:02/10/16 20:28 ID:AoEDRTuI main/1034697627.html#476
お前等、本当に、単純だな。


909 名前:47 投稿日:02/10/16 22:33 ID:f1yyjF60 main/1034697627.html#510
うーん、やはり匿名共有システムの方がコンテンツ保護システムより強力という結論でいいのかな?

もともとこんなこと(匿名なデータ共有システム)に私が興味を持ったのは
デジタルデータに対する課金問題が今後の情報産業で最も重要な課題になると感じたからです。

それで、デジタルデータに対するコピー対策が技術的に可能なのか?
ということでいろいろ考えてたんですが、結局、不可能なんじゃないか?
という結論に達したというのがWinny製作開始のきっかけでもありました。

注:音楽や映画が保護不可能でも広義の意味でのソフトウェアはコピー保護可能だと思ってます。
ソフトウェア=データ+プログラム+エクゼキュータ≒システムと考えれば
エクゼキュータ(PCなんか)はコピーできないから(エミュを除く)

ただ、暗号化のところ考えていて、ひょっとしてこれの応用で工夫すれば
行けたりすることもありうるのか?と思ったりしたわけです。
で皆に問うてみたわけですが、やはり完全な著作権保護システム(=課金システム)
の実現は無理というのが結論でしょうか?



910 名前:47 投稿日:02/10/16 22:33 ID:f1yyjF60 main/1034697627.html#511
逆に、完全匿名なデータ共有システムが作れるのか?
と言われれば、どうもこちらはできそうな気がするわけです。

Winnyはバランス重視で作っているので完全匿名とは言えない(でも必要最低限はあり)ですが、
Freenetか、より匿名性重視した次世代システムであれば完全匿名になりうるかもしれません。

実際問題、私の方ではユーザーの使用用途などはどうでもよく
(って使ってもらえないと意味無いので広まるようにはがんばりますが)、
興味があるのは技術的なこと。つまり、使い物になる匿名共有システムが実現可能か?
使い物になるコンテンツ保護システムが技術的に可能か?だけです。

この辺でちょい疑問に思いましたが、やはり共有システム>保護システムであるならば、
これにチャレンジしても無駄なので課金システムやそれに繋がる交換システムは
Winnyでは廃棄すべきということになりそうです。

ということで、暗号に関してはろくに使われないのがわかっていても、
前書いた2のバグとって後は放置かなと思います。
しかしそろそろバグ取りやどうでもいい所以外、やること無くなって来ましたね。



911 名前:47 投稿日:02/10/16 22:33 ID:f1yyjF60 main/1034697627.html#512
なお、要望の多いキャッシュフォルダ分割に関しては実装予定がありません。

キャッシュ管理についてですが、ユーザーでキャッシュフォルダを
クラスタ毎に細かく運用すべきであって、何も考えずに全て同じキャッシュに
入れるのはキー密度が低下してシステム全体からすると結局逆効果だと判断します。

Winnyの場合時間当たりのキー送信数が一定なので、あまりキャッシュを持っていると
今度は送信されるキャッシュキー密度(同じキーを再送する確立)が減って、結局アップされません。
といっても、キャッシュを大量に持つのが無駄というわけではありません。
大量にキャッシュを持つ場合、キャッシュフォルダをクラスタ毎に分けるべきだということです。

もちろんシステム側でこれを支援した方が良いのでしょうが、
ユーザーの意図をシステム側で汲み取るのは非常に難しいので、あまりメカニズムを複雑にせずに、
現状の様にユーザー側でキャッシュ管理方針をコントロール可能であるのが理想だと考えます。
そして単体フォルダの容量に関してはOSがどうにかすべき事柄でしょう。

よって大量にキャッシュを持つ場合、Winnyの全設定ファイルをクラスタ毎に別フォルダにして、
使い分けることを推奨するということになります。この辺はクラスタ化の基本になるかと思うので、
システムを理解しての使用をよろしくお願いします。

ああ、あと上の幾つかの書き込みは偽物です。判断はお任せします。

あと、他で出てるキャップの考え方は面白いかもしれませんのでちと考えてみます。
ということで、何か面白い論点あったら引き続きよろしくです。


912 名前:47 投稿日:02/10/16 22:40 ID:f1yyjF60 main/1034697627.html#520
前書いた理由でキャップは必要最低限しか使いません。
面白いので偽物も歓迎です(w


913 名前:47 投稿日:02/10/16 22:52 ID:f1yyjF60 main/1034697627.html#525
あとキャッシュの自動削除に関してですが、HDDが無いのなら
ファイルを落とさなければいいだけのはずです。
もしHDDが無いのならダウンしたファイルが格納できませんよね?

つまり、キャッシュを自動で消して意味があるのは、
キャッシュフォルダの空き容量をダウンフォルダに当てている場合だけです。

もし現状のダウン停止をやめて、キャッシュの自動削除が合ったら、
キャッシュフォルダ内に当てられるべきファイルの容量が
ダウンフォルダ分減る(=UP可能が減る)でWinny全体では望ましくありません。

よって、キャッシュフォルダが足りなくなったときの挙動の正解は、
ダウンを停止させてアップだけの状態にすることだと判断します。

ということで、キャッシュの削除は手動でWinny停止時に行ってください。
この判断で矛盾点あったらお願いします。



914 名前:47 投稿日:02/10/17 00:08 ID:WDg/NG9j main/1034697627.html#564
β20.96です。互換性あります。変更は一箇所だけです。

・ 多重ダウンがONだと、ダウン中のキャッシュが転送可能でも
 読可キャッシュ→部分キャッシュになって転送対象にならないのを修正

551さんの指摘で思い出しました。
これ、結構大きな影響が出るので早めになおしときます。

サイズが大きいのに人気があって拡散してないファイルの場合、
このバグのために拡散速度落ちていたはずです。

なお、キャップというかトリップはもう少し良く考えてから
実装するかどうか判断しますのでお待ちを。


915 名前:47 投稿日:02/10/17 00:09 ID:WDg/NG9j main/1034697627.html#566
550さんだった(^^;失礼

916 名前:47(偽) 投稿日:02/10/17 19:59 ID:jxKY6Pln main/1034697627.html#790
p2pでストリーミングっておもしろそうですね。
動画を64KBずつぶったぎってDL→再生を繰り返す
でなんとかならないかな?

917 名前:47 投稿日:02/10/19 19:28 ID:J04f+w4j main/1034933042.html#201


918 名前:47 投稿日:02/10/19 19:30 ID:J04f+w4j main/1034933042.html#202
この前のような事に備えて、転送アドレスを所得しました。
リンクの張替えをお願いします。
book- i.net/winny/

919 名前:47 投稿日:02/10/20 23:04 ID:gtj88mD1 main/1034933042.html#276
ここのスレには酷いインターネッターが多すぎるので
別場所へ移動しまつ^^

920 名前:47 投稿日:02/10/20 23:38 ID:8ufhx9My main/1034933042.html#279
ここは酷いインターネットでする

つまり自分の考えが通らず窮地に落ちた人間が
使用するスレがここという訳です。

Download板には必要ないのでは?という意見もあるようですが
それは間違ってます。ここでこそ真力を発揮できるので。

ある偉い方が言いました
「ここの住人を見てるのが辛い・・・あんな酷い仕打ちを
受けてまだ事を起こす事が出来るのか?私には絶対の無理だ。逃げよう」

皆さんももうお気付きでしょうが今現在あなたが見てるこのスレ
の事を言ってます。「そんなバカな!」
と思う方もいるかも知れませんが事実
最低でもあなたの限られた貴重な時間がここで削られた事は事実なんですから。

その偉い人は一呼吸置いて言葉を続けました
「仲間はずれになるのが恐い?ははは、それこそここのスレにとって最高の
ご馳走になるんですよ」

そうなにを隠そうその偉い人とは本来
あなたが進めべき場所にいる存在なんですから。

921 名前:47 投稿日:02/10/20 23:48 ID:8ufhx9My main/1034933042.html#281

韓国


922 名前:47 ◆KbtLZwerNc 投稿日:02/10/21 22:28 ID:ddn0LwYb main/1034933042.html#329
ここのところどうしたんだってぐらい用事が多くて
土日も出かけてること多いので修正できてなくてすいません。

トリップ実装だけなら非常に簡単なんでもうできてるんですが、
これやっていて気がついた別のバグが取れなくて悩んでますので
少しお待ちください。今度のではプロトコルバージョンが変わるので
ついでにいろいろ直します。

なお、トリップの挙動ですが、現在の実装では2ch互換で

#で始まる文字列が◆ABCDEFGHIJと10桁になる。
◆が含まれるファイルは◇になるという機能です。
ただ、拡張子が使えなくなるのは不便なので、
#のあとはピリオドまでとなります。

TestFile#12345.zipというファイルをUPフォルダに入れると
見えるファイルはTestFile◆ABCDEFGHIJ.zipなどとなります。
この実装で何か問題ありそうでしたら今のうちにお願いします。

そうそう、あとこのスレになってから書き込むのは
初めてですのでよろしく。


923 名前:47 ◇KbtLZwerNc 投稿日:02/10/21 22:40 ID:xCONoGVi main/1034933042.html#338
うんこしてくるよ

924 名前:47 ◆KbtLZwerNc 投稿日:02/10/22 13:51 ID:VyjGHusc main/1034933042.html#425
ファイル名以外にいろいろ案が出てますが、大別すると二つあって、

・ ファイル名に追加するか、別項目にするか?
・ ファイル単位でトリップつけるかフォルダ単位にするか?

の二つかと思うので分類すると4種類

1A. ファイル名にトリップを含めて、トリップ指定がファイル単位

メリット:検索画面やダウンリストで検索条件として指定できる
デメリット:名前の付け替えが面倒&他共有ソフトとのファイル共有が面倒

1B. ファイル名にトリップを含めて、トリップ指定がフォルダ単位

メリット:1Aのメリット+1Aのデメリット解消
デメリット:ファイル単位でのトリップ設定ができない

2A.ファイル名とは別にトリップ情報を持たせて トリップ指定がファイル単位

メリット:他共有ソフトとのファイル共有が楽
デメリット:検索画面やダウンリストで検索条件として指定できない
     (実装できなくもないがつけるの面倒)
      トリップ指定のインターフェイスが不便

2B. ファイル名とは別にトリップ情報を持たせてトリップ指定がフォルダ単位

メリット:他共有ソフトとのファイル共有が楽&インターフェイスが簡単
デメリット:検索画面やダウンリストで検索条件として指定できない
      ファイル単位でのトリップ設定ができない



925 名前:47 ◆KbtLZwerNc 投稿日:02/10/22 13:51 ID:VyjGHusc main/1034933042.html#426
作るのが一番簡単なのが1Aだったので今はこれですが、1Bも悪くないかと思います。
1Aの場合、外部ツールで支援すればいいので一番自由度は高かったりします。

2Aは操作が面倒なんであまり良いところないでしょう。

一番変更が多いという問題を除けば、最もよさそうなのは2Bで、
トリップはファイル名とは別につく、指定はキーワード同様フォルダ単位というものです。

これだとそのままだと検索できないので、検索や自動ダウンに今の暗号キー
同様のメカニズムの追加の必要があるでしょうが、よく考えたら暗号キーのところと
まったく同じインターフェイスになるので、そんなに面倒ではないですね。

それより、暗号キーとトリップの二つあるとわかりにくいので、
開き直って暗号キーを無くしてしまいたいなぁ。
そうなると、I/F的には暗号のところが全部トリップになるだけですが。

さてどうしましょう。


926 名前:47 ◆KbtLZwerNc 投稿日:02/10/24 20:19 ID:RR07TFKB main/1034933042.html#702
ここのところ土日も含めて毎日会議やら出張やらの連続でして、その準備その他で
ろくに開発の時間が取れないんですが、トリップに関しては前書いた2Bの形での
実装が終わりましたので今現在動作チェック中です。

ちなみにキャッシュがまたバージョン上がりますが、互換性は保たれます。
β21でアクセスしたキャッシュは上書きされてVer0.4になります。

他に例の再チェック連打するとアップが切れるとか、
他にプロトコロがせっかく変わるので細かい変更など加えています。
明日には公開できるんじゃないかと思いますが、忙しいので
あまり期待せずにお待ちください。

あと、やっとβ取ってもいいんじゃないのかという声が多くなってきたので
β21系統で十分バグ取り終わったらVer1になるかもしれません。

といって、今までも何度か引き伸ばしてきたので、
致命的な問題でも見つかれば対処ということでまた後回しになるでしょうけど。



927 名前:47 ◆KbtLZwerNc 投稿日:02/10/24 20:28 ID:20hJYvaZ main/1034933042.html#707

100万円は放置してます


928 名前:47 投稿日:02/10/25 21:19 ID:T9d0A2iN main/1034933042.html#789
とつられてみる。

929 名前:47 投稿日:02/10/25 21:36 ID:WeQVY/MQ main/1034933042.html#791
更新、もうしばらくお待ちを。

930 名前:47 ◆KbtLZwerNc 投稿日:02/10/25 23:49 ID:9XlkHTV1 main/1034933042.html#810
β21の実装は既に終わっていて、画面周りのちらつき修正なども新しく入れましたが、
今日も雑用で潰れてろくに動作テストできていませんし、明日からまた二日ほど出張で
これに大バグあると対処しきれないので、すいませんが公開を来週に伸ばします。
今回キャッシュ変更があるので慎重にやらないと致命的なことになりますので慎重に行きましょう。

最近の修正ですと、実装は一瞬で終わるんですが、変更の結果生じる影響に関する
考察だとか、そのテストの方で非常に時間がかかるので困りものです。
加えて最近えらく忙しいし(^^;


931 名前:47 投稿日:02/10/28 20:36 ID:AR7tXzbP main/1035632617.html#164
おまえら楽しそうなことやってんな

932 名前:47 投稿日:02/10/28 22:47 ID:xO5ln9cl main/1035632617.html#181
β21です。β20系統とはプロトコルの互換性がありませんので繋がりません。

キャッシュもv0.3→v0.4となりますが、キャッシュに関しては上位互換性がありますので、
v0.3のキャッシュもβ21で扱えます。v0.3とv0.4の違いはキャッシュヘッダの一部分だけなので、
β21でアクセスしたキャッシュは自動的にv0.4キャッシュに変換されます。

・ 暗号キー設定を無くしてフォルダ単位でのトリップ設定機能を追加
・ 表示の際にダブルバッファリングすることでチラツキを抑えた
・ Winny.exeを多重起動時にタスクが残るのを修正(&多重起動時には最小化を復帰)
・ 負荷が高くなると最小化状態から復帰することがあるのを修正
・ 最小化からの復帰を左ボタンダブルクリックからシングルクリックに変更
・ 再チェック時やUPフォルダ状況が変わったときに回線切断するようにした
・ UPフォルダ状況が変わったときに再描画が行われないのを修正
・ ファイル名、トリップ、ハッシュ情報まとめてのクリップボードコピー機能追加
・ 色設定によっては選択されていないボタンの文字が読めないことがあるのを修正

主にトリップ機能の追加で、いままでの暗号キー部分がこれに置き換わります。
2chのトリップ同様、UPする人の個人認証にも使えますが、どちらかというと、
本来一つのファイルなのに都合により複数に分かれているファイルを
同じものと識別するための機能となります。

従来の暗号キーと同じで、検索条件にトリップが追加されることになります。
なお、トリップは10桁ですが、元の文字列に#を追加する形でも検索できます。

あとは、細かい修正だけです。

ああ、あとプロトコルが違うとバージョン警告が出ませんので注意してください。
β20の方にはプロトコル違いの警告がログのところに出るだけです。


933 名前:47 投稿日:02/10/29 01:33 ID:+6wpJdwn main/1035632617.html#350
β21.01です。β21と互換性あります。
見落としていた細かいバグフィックスです。

・ 個別選択でタスク起動時に選択されたキーサイズが変になるのを修正
・ 最小化からの復帰をダウン時からアップ時に変更
・ BBSタイトル表示でのスレソートが変なのを修正
・ クリップボードコピーの改行をCR+LFに変更

あと、過去スレで指摘済みな項目が多いようですが、
正直忙しくて本スレを全部チェックし切れてないので
暇になったらまた見直しますのでしばらくお待ちください。


934 名前:47 投稿日:02/10/29 13:55 ID:Om7LQ4sV main/1035632617.html#509
文句いうなら使わなくて結構

935 名前:47 投稿日:02/10/29 22:08 ID:Oc+rRRQD main/1035632617.html#643
β21.02です。互換性あります。細かい修正です。

・ 再チェックで接続を切るのをやめた
・ 再チェック中に再チェックを開始できなくした
・ 再チェック開始直後に検索画面に行くと飛ぶことがあるのを修正
・ 再描画やリサイズ時に表示にゴミが出るのを修正
・ 終了時にメモリ開放し忘れている部分を修正

例の再チェックですが切断動作の評判が悪いようですので修正しました。

そもそもこれに関してはアップリンクが切れなければいいだけなんで、
こちらでもいろいろ試してはみたのですが、再チェック中でこの辺がかなり複雑なことに
なっているためにファイルアップ周りで致命的なバグが出ると思います。

ですので危険と判断して前のようになったのですが、今度は外部ツールなどで
問題になるようですので、とりあえず連打が効かないようにしておきました。

とりあえずこれだとどうでしょう?

936 名前:47 投稿日:02/11/03 15:48 ID:UMyz4h8L main/1036044712.html#293
β21.1です。互換性あります。
細かい修正だけですが内部的には結構書き換わってます。

・ プログラム起動中はシステムスタンバイに入らないようにした
・ リストコントロールのスクロール位置をできるだけ保持するようにした
・ 検索でヒット数が多くなると重複削除処理できていなかったのを修正
・ リストコントロール表示の高速化
・ 検索画面のブロック量でのソートがバグっていたので修正
・ ファイルアップ個数の制限を無くした
・ BBSが別ハッシュでたくさんできてしまうのを起こり難くした
・ 再チェック直後に検索画面表示部でクラッシュすることがあるのを修正
・ 他から受け取ったノード情報がすぐ消滅することがあったので修正
・ ダウンリスト削除した後にダウン予約追加すると変なところに挿入されるのを修正
・ 転送リンクのダウン枠が無いときはキー探索作業をスキップするようにした
・ ログ情報で日付も出すようにした
・ 下に出る警告の類をログの方にも残すようにした
・ 昔の名残で残ってた使ってないコマンドの類を削除

要望スレの方をろくに見ていなかったので先頭の方だけチェックしなおしました。
また暇見て修正しますのでお待ちください。

なお、今回リストの表示周りがそれなりに書き換わっているので
表示の挙動で変なところがないかチェックお願いします。
前のよりはこれの方が使いやすいと思うんですが。

あと思ったんですが、初心者スレなどで用語の類がわかりにくいという話が多いようなので、
意味不明そうな単語でこれのがいいんじゃないのかというのがあったら指摘お願いします。

これに関しては、変更簡単だし、他にお任せできるのでこちらは楽。
ただ、あまり長いと表示しきれないので、今の表示とあまり文字数
変わらないぐらいでお願いします。もちろん今のままでいいところはそのままでいいですし。


937 名前:47 投稿日:02/11/03 18:12 ID:OQOIpjXt main/1036044712.html#404
β21.11です。互換性あります。表示周りのバグとりです。

・ ダウンリスト個数が表示限界を超えると落ちるバグを修正
・ リストの表示限界を1000個にした
・ 検索結果が空だと誤動作するバグを修正

結構変えたんで何か問題でるだろうとは思いましたが
表示しきれないほどダウンリスト入れてる人がいるというのは盲点でした。
それなりに致命的なんで早めに直しときます。まだあるかもしれませんが。

とりあえず前から要望多いですし、そのうちダウンリストと削除その他と
分割しようかと思いますが、今回表示限界を増やしといたので
これで暫定対処お願いします。今ならかなりヒットしても問題ないはずですが、
検索画面で1000個だと処理が重いかもしれません。



938 名前:47 投稿日:02/11/04 22:21 ID:cwKQYWUb main/1036410015.html#86
β21.12です。互換性あります。こまかい修正だけです。

・ 再チェックボタンを押した瞬間にGC開始されて落ちやすいのを修正
・ 検索ボタンを押したときにリスト更新されていなかったので修正
・ ウインドウリサイズ時にリソースリークするバグを修正
・ キー検索テーブル生成時の無駄(不要なテーブル生成)を省いた
・ 検索表示を少し高速化
・ ログ出力メッセージを全て日本語にした

ここのところ忙しいのであまり時間が取れてませんが
画面表示関連などそれなりに致命的なので公開しておきます。

あと、エラーメッセージの類はいつもの癖で(どうせエラー出すような関数
自体が名前英語だし)英語にしてしまうのですが、わかりにくいのと、
間違ってるやんという突っ込みを避けるために日本語にしておきました。
かなーりどうでも良いところですが。



939 名前:47 投稿日:02/11/04 22:24 ID:yzRQJFm0 main/1036410015.html#92
>>91
10分ほど迷いますた。

940 名前:47 投稿日:02/11/09 17:10 ID:ibi8270D main/1036410015.html#730
β21.2です。互換性あります。

・ 自動ダウン処理と無視処理を完全に分けた
・ 検索条件で単語先頭が'-'なら否定条件にした(例:abc -def)
・ 転送ダウンリンクに空きが無くてもキー検索処理を行うようにした
・ 検索条件入力部のフォーカス処理が変だったので修正
・ GC開始数を大きくしてGC発生率を下げた(ただしメモリ消費は増える)

今回、自動ダウン周りを大幅に変えました。
ファイルダウンとキー削除の処理が独立に動作します。

これにより、無視だけや削除だけ指定ができなくなってます。

新しくできた無視部に追加すると前バージョンの無視+削除の指定と同じで、
条件にあうキャッシュ見つけたら全ブロック破棄、仮想キーならキーを破棄、
そのキーを送ってくるノードを無視、そして、無視条件にヒットするキーは
ダウン時にダウンしないとなります。

これにより今まであった、単なる無視が無くなりましたので、その代わりとして、
検索条件で否定検索できるようになってます。検索やダウン条件・無視条件で
"ab cd -e"と指示するとファイル名にabとcdが含まれてeを含まないとなります。



941 名前:47 投稿日:02/11/09 17:10 ID:ibi8270D main/1036410015.html#731
あと、ダウン条件ファイル(DownList.txt)フォーマットが変わったので
すいませんがβテスターさんの方で各自コンバートお願いします。
今回から、ダウン条件がDownload.txtで無視条件がDelete.txtに分かれます。

そのため、今回バージョンだけの機能としてDownload.txtとDelete.txt以外に
今までのDownList.txtもダウン条件・無視条件の両方として読み込んで
自動的にどちらかに分けるようになってます。

もしDownload.txtやDelete.txtがあるとDownList.txtよりそちらが優先されます。

ダウンリストの移行手段としては、以前のDownList.txtそのままで起動したあと、
ダウン条件や無視条件を適当に編集してください。
これによりDownload.txtやDelete.txtファイルが出力されるので、
後は昔のDownList.txtを消すことでダウンリストの変換終了となります。

次バージョンからはDownList.txtは読み込まなくなる予定です。


942 名前:47 投稿日:02/11/09 17:43 ID:ibi8270D main/1036410015.html#763
全部答えきれないのわかってるんで一部だけ

> あるノードが一つでも無視該当キャッシュを
> 持ってるとそれだけで無視ノード指定ってこと?

今までと同じで一つだけでは無視ノードにしません。数十個以上送ってきたら無視ノードにします。

今回の修正は、ダウンリストを二つに分けて、無視側は以前の無視+削除にしただけです。
無視ノードの処理や、ダウンの処理など基本部分は変わってません。

ただ、ダウンと無視が同時に動作するようになったので
無視にたくさん入れていた方は今回のバージョンでダウン率が上がると思います。
今までは無視にたくさん入れているとそのチェックに時間とられてダウン開始しませんでしたので。


943 名前:47 投稿日:02/11/09 21:40 ID:Jou1xOiY main/1036844636.html#23
β21.21です。互換性あります。バグ取りです。

・ 無視条件でのヒット個数をカウントしてなかったので修正
・ 条件編集しての追加や変換などでタブ切り替えを間違えるのを修正
・ ダウンリストでの処理位置を表示するようにした
・ DownList.txtが無いときのエラーを出さなくした
・ ソート条件によっては検索でダブりが生じやすいのを修正

忘れそうなので新機能周りで指摘の出た箇所を早めに直しときます。
修正が頻繁ですいません。

あと、まだ気がついてない人もいるでしょうから
DownList.txtからの変換機能は残してあります。
ファイルが無いときのエラーは出ないようになってます。


944 名前:47 投稿日:02/11/09 21:56 ID:Jou1xOiY main/1036844636.html#45
新しくついたマークは現在処理中の条件です。

自動ダウンの検索は全キーに検索かける都合でかなり重い処理なので、
今のだと1秒の間にダウンが2個、無視での削除が一つになってます。

ダウンの方では、同じタイミングでクエリ発行します
(ヒット数が1以下なら乱数で適当な比率で発行)

今後の予定ですが、流通量の少ないキーほど
拡散速度を上げることで、レアと呼ばれるファイルを
もう少し見えるようにする予定です。

今のダウン周りの修正が落ち着いたらこれをやりますので、
少しお待ちを。

945 名前:47 投稿日:02/11/10 23:57 ID:tELfq/8O main/1036844636.html#439
β21.3です。互換性あります。

・ 無視条件で、削除とリンク切断をオプション設定できるようにした
・ ダウン条件と無視条件の編集時に相互に変換できるようにした
・ 削除動作も一度だけオプション有効にした
・ 検索周りのバグ修正
・ WindowsNT4対応

無視条件周りはかなり分かり難い機能ですし、
あまりキャッシュ管理の自由度が高いと別の問題があるので
削除周りの機能を増やしたくないところではありますが、
機能ダウンだとやはり不評なようなので変更しました。

まず、無視条件にヒットするキーは常に自動ダウンの対象からは外れます。
これは無視条件で共通です。

あとはオプションで、もし削除オプションにチェックついていれば、仮想キーならキーを抹消、
キャッシュがあれば保持ブロックを全部クリアします。これにより再チェック時に消えます。

もしリンク切断オプションがONなら、そのキーにマークつけて、
これらのキーを一定数送ってくるノードとのリンクを切るということになります。

基本的に前と同じ動作ですが、否定条件検索も残ってますし
より細かく指定できることになります。


946 名前:47 投稿日:02/11/10 23:57 ID:tELfq/8O main/1036844636.html#440
あと、都合により、またまたダウンリストのフォーマットが変わりました。
ダウン側は21.2xと同じでDownload.txtですが、無視側はIgnore.txtになります。

もしDownList.txtやDelete.txtがあるとこの順で読み込まれて変換されます。
あと、今度のバージョンではDownload.txtとIgnore.txtは起動時に強制出力されます。

基本的にexe上書きでも問題ないはずですが、もしダウンや無理ファイルに大量に
書いてある方は、念のため設定ファイルのバックアップとってから起動してください。


947 名前:47 投稿日:02/11/14 08:44 ID:Gqnl4IU7 main/1037104705.html#270
β21.4です。互換性あります。ちょっとした修正ですが、重要な変更になります。

・ キー拡散時にキャッシュの広まり具合にあわせて密度を動的に変えるようにした
・ キー拡散時に送信個数にリミッタ設けて通信バッファがあふれ難くした
・ Port0ノードから低速ノードが立てたBBSが参照できないのを修正
・ 先頭が[BBS_で始まらないBBSキーを無視するようにした

今回の修正で、キーの分布が多少変わります。
どうしてもデメリットの方が目立つようだったら戻します。

修正点ですが、Winnyでは検索しないでも一定率でキーを周辺に拡散させています。
上流ノードの方が激しく流動していて、下流ではゆっくり拡散します。
これにより上流ほどキー密度が高いですが、このキーが適当に拡散した状況下で、
上流に検索クエリを流して欲しいキーだけ拾ってくることになります。

ここで、このキー拡散の際に、今まではキーを全て平等に同じ密度で流してました。

しかし実際に流れているキーの密度を調べてみると特定のキーのみが異常な密度
で広まっていて(一桁以上の差)検索リンク内を占領していることが分かります。

これは、キャッシュが十分広まっているキーに関しては元々拡散元が多く、
その結果そのファイルがダウンされてキャッシュとして広まって差がますます広がって
人気のあるファイルだけしか見えなくなっているのだと思われます。
これがそのまま現在のWinnyの状況(メジャーなものしか見えない)になっています。

検索リンクで流せるキーの数は限られているので、これらのお約束的キーで
検索リンクが占領されていて珍しいキーが見えにくいわけです。

人気があるファイルほどキャッシュが広まるのは設計通りなので問題ないですが、
それに合わせて人気の無いファイルほど検索にかからないのは問題です。


948 名前:47 投稿日:02/11/14 08:44 ID:Gqnl4IU7 main/1037104705.html#271
ということで、今回、他のノードが持っていないキー優先で
キー拡散時するように重み付けをかけました。

具体的には、参照量が十分で、なおかつ周りから何度も送られてくるキー
(キャッシュが十分広まっていると思われるキー)は送信を省略するようにしてあります。

その分、送信数を増やしてあるので(トータルの送信量は同じ)、
今まであまり送られなかった珍しいキーの送信密度が上がります。
これによりあまり拡散していないキーほど拡散で広まりやすくなります。

また、珍しいキーほど拡散速度が上がるということは、珍しいファイルほど
転送率が上がるということでもありますので、一時的に落としにくく
なるかと思いますが、キャッシュの拡散速度は大幅に上がります。
どうせ落とせないのならキャッシュが広まったほうが良いのではないかと。
直接UPしてる人は、転送での送信率が上がるわけで匿名性も上がりますし。

また、既にキャッシュが出回っているファイルに関しては逆に転送率が下がって
キャッシュを直接ダウンしにいく可能性が高くなるわけでダウン成功率が高くなります。
トータルで見るとデメリットよりメリットのほうが多いと思います。


949 名前:47 投稿日:02/11/14 08:45 ID:Gqnl4IU7 main/1037104705.html#272
広まっているファイルほど落とせるという今の状況は変わりませんが、
珍しいものも広まっているものも検索率が同じ程度になります。

ただ、調節を誤ると今まで落とせていたお約束的ファイルが見えなくなるとか、
逆に新しく入ったファイルがまったく落とせないという可能性もありえますので、
順に調節していきます。βテスタさんには検索率とダウン率の変化報告お願いします。

今の状況にあわせてパラメータ調節しておきましたが、それによりまたキーの
分布が変わりますし、ゆっくりキャッシュ分布も変わりますので、
状況が落ち着くまでは時間がかかるはずです。



950 名前:47 投稿日:02/11/14 09:40 ID:++62k6Fq main/1037104705.html#284
半分、っていうかほとんど仕事で作ってるので、とりあえず首はつながってます。

951 名前:47 投稿日:02/11/15 10:06 ID:yaqV56v0 main/1037104705.html#520
β21.41です。互換性あります。パラメーター微調整です。

・ キー流通量カウンタを一定間隔で初期化するようにした

β21.4の変更は、ほぼこちらの想像通りに動作してレアと呼ばれる
ファイルの検索ヒット率は増えたのですが、これまた予想通り、
今まで流通していたキーが見えにくくなっているようです。

そのため全体の流通キー数が減っているのだと思います。
一時的にダウンが増えた人もいるかと思いますが、
全体での転送量は減っているはずです。

ということで、β21.3とβ21.4の中間がちょうど良いようですので、
適当なタイミングで内部のカウンタクリアして調節するようにしました。

β21.4ではキーバッファがクリアされないと、よく見かけるキーの再送が
行われませんでしたが、これによりで適当な率で全キーが送られるようになります。

比率は適当に調節できますので、皆さんの報告に従って、お約束ファイルと
レアファイルのキー混合比を調節しようと思います。引き続き報告お願いします。

当分はβ21.3とβ21.4の状況を両極端としてその中間の最適点を探ることになります。


952 名前:47 投稿日:02/11/15 10:11 ID:yaqV56v0 main/1037104705.html#527
ああ、あとBBSキーの方にも副作用があるので調節しときました。
BBSキーは普通のキーと違って拡散速度がはじめから
早いので、むやみに流すと検索リンクを圧迫します。
ということで転送率落としておいたのですが、
落としすぎたようなので、こちらもβ21.3と21.4の間にしてあります。

21.41が広まった状態でもBBSキーが見当たらないようでしたら報告してください。


953 名前:47 投稿日:02/11/15 10:18 ID:yaqV56v0 main/1037104705.html#531
予想ですが、最適点はキーの保持個数が最大になる点か
その少しレア重視寄りな辺りじゃないかと思います。

発見率とダウン率が最適かどうかは分かりにくいとは思いますが、
このキーの数がどうなったかに注力すると探りやすいかと思います。

キーの発見率とダウン率は主観的なものなので
良いと思うか悪いと思うかの問題で各自の判断で
適当に報告お願いします。


954 名前:47 投稿日:02/11/15 18:25 ID:h85HmiX7 main/1037104705.html#662
β21.42です。互換性あります。パラメーター微調整です。

・ キー流通量のベース量を増やした

β21.41が広まってから変えたほうがいいんでしょうけど、
前の推測が当たっていればβ21.4→21.41で必ずキー量が増えるはず
なのに逆に減る傾向があることから、キーが少ないのは別の理由のようです。

β21.4で送信されるキー個数にリミッタ入れたのでここがバグっているのかと
思って計測やってみましたが、やはり変わっておらず、むしろβ21.3より
送信キー数は増えているのにβ21.4増加でキーが減るということは、
キーの削除に引っかかる率が高くなっているということだと思われます。

送信されているキーとそうでないキーの分布見てる、
周辺で出回ってないキーの混合率が上がっているので、
すなわちクラスタ外のキーが混じってくる率が高くなるということで、
どうも、クラスタ外のキーが無視条件でどんどん消されてるんではないかと。

ということで、物理的なキー流通のベース量をこの分考慮して増やしてみました。

今だとクラスタ化が緩くなってるんだと思うので、この傾向が進むと、
ますますクラスタ化がシビアになるかもしれません
(分類のはっきりしないクラスタ領域に行きやすくなる)

とりあえずキーは間違いなく増えるのでこれで様子見てください。
様子見て違う問題は生じるようでしたらまた調節します。

ああ、あと今回の調節は全体の調節ですので、前のバージョンに戻しても
そのノードの状況は変わりません。できるだけ早く調節終了させたかったら、
早めにバージョンアップして様子見るようお願いします。

955 名前:47 投稿日:02/11/16 10:48 ID:jLu6huui main/1037399539.html#108
一応完成してるんですが、
ここに書き込むべきか迷ってるんですよ。

956 名前:47 投稿日:02/11/16 10:56 ID:jLu6huui main/1037399539.html#123
>>120
賛成者の方が多かったらそうします。

957 名前:47 投稿日:02/11/16 17:44 ID:FG+WqPjf main/1037399539.html#379
β21.43です。互換性あります。パラメーター微調整です。

・ キー転送のベース量を21.3と同じレベルに戻した
・ キーの寿命を延長
・ BBSキーの転送率を増加
・ キー情報ペースト時にファイルサイズ情報も含むようにした

21.42でも悪くないかとは思うのですが、やはりキー転送量が増えることにより、
特に速度設定が1.5M ADSL近辺の人が検索リンクでキー転送の占める率が大きく
なってしまうので、できればこれは避けた方がということで、ベース量増加と
似た働きになるキー寿命の延長を試してみます。

これはこれで違う問題が出るはずですが、一番の問題であるキーバッファがあふれると
いうのを今なら心配しないでも大丈夫そうなので比較的良いのではないかと。

実験的な修正が続きますが、人が増えたところで大域的なパラメーターを
調節し直した方が良いでしょうということで、各所でどう状況が変化するか
報告お願いします。結果見て一番よさそうなもので固定します。

あと、BBSキーの方は通常キーの転送を利用している都合で巻きぞえで
パラメータが変更されるので当分調子悪いかと思いますが、細かい調節は
お待ちください。暫定ですが、適当に転送率上げておきました。



958 名前:47 投稿日:02/11/16 22:56 ID:Vzqw/Wa1 main/1037399539.html#580
シェアにします。

959 名前:47 投稿日:02/11/16 23:02 ID:jUZaeYBI main/1037399539.html#589
不正なキーを入れるとHD削除します。

960 名前:47 投稿日:02/11/16 23:27 ID:4iIaR/9g main/1037399539.html#606
ケッ、どいつもこいつも勝手なこと言いやがって

961 名前:47 投稿日:02/11/17 00:03 ID:TJFP6yrm main/1037399539.html#637
100万円欲しいです。

962 名前:47 投稿日:02/11/17 00:12 ID:RfksMFAN main/1037399539.html#646
β21.44です。互換性あります。パラメーター微調整です。

・ キーの寿命を短縮


21.43でも悪くないかとは思うのですが、キーの寿命が長すぎたため,キーの寿命を
少し短めにします。

実験的な修正が続きますが、人が増えたところで大域的なパラメーターを
調節し直した方が良いでしょうということで、各所でどう状況が変化するか
報告お願いします。結果見て一番よさそうなもので固定します。

963 名前:47 投稿日:02/11/17 00:17 ID:ZQa1PpuA main/1037399539.html#653
β21.44ではキーの寿命は3秒です。

964 名前:47 投稿日:02/11/17 00:24 ID:TJFP6yrm main/1037399539.html#665
頻繁ですいませんが、β21.44です。

・ キーバッファ削除速度を向上
・ 中継発生率が上がっていたので下げた
・ 自動ダウンでのクエリ発行率を少し増やした
・ 接続停止時に未接続のコネクションが残ってしまうのを修正

あとはそれほど変わってません。

965 名前:47 投稿日:02/11/17 00:40 ID:ZQa1PpuA main/1037399539.html#692
β47です。もうβ1の開発から2年が経ちました。

・ DVDから直接リッピング&UP機能の廃止。
・ DVD-R直焼き機能の廃止。
・ 自動通報機能の廃止。
・ ノード攻撃機能の廃止。

後はあまり変わっていません。


966 名前:47 投稿日:02/11/17 00:48 ID:lmO/xfpr main/1037399539.html#700
β21.48です。

・BGMをちんこ音頭からまんこ音頭に変更

967 名前:47 投稿日:02/11/17 00:55 ID:jYDektNt main/1037399539.html#710
Ω100です。

・転送速度をISDNでも100Mbps出るようにした。
・ダウンリストにファイル登録したらすぐに繋がるようにした。しかも絶対切れません。
・逮捕されないようにした。

968 名前:47 投稿日:02/11/17 00:56 ID:T9elkdKE main/1037399539.html#711
te

969 名前:47 投稿日:02/11/17 01:01 ID:ZQa1PpuA main/1037399539.html#712
お久しぶりです。やっと釈放されました。ということで、開発続行です。
今回の変更は主に逮捕対策です。

・ 緊急データ全消去機能を付けた
・ 他人のアカウントでログインする機能を付けた
・ 次の就職先を見つけた

970 名前:47 投稿日:02/11/17 01:31 ID:/vTml69h main/1037399539.html#737
β22です。β21系統とはプロトコルの互換性がありませんので繋がりません。

キャッシュもv0.3→v0.4となりますが、キャッシュに関しては上位互換性がありますので、
v0.3のキャッシュもβ21で扱えます。v0.3とv0.4の違いはキャッシュヘッダの一部分だけなので、
β22でアクセスしたキャッシュは自動的にv0.4キャッシュに変換されます。

・ 暗号キー設定を無くしてフォルダ単位でのトリップ設定機能を追加
・ 表示の際にダブルバッファリングすることでチラツキを抑えた
・ Winny.exeを多重起動時にタスクが残るのを修正(&多重起動時には最小化を復帰)
・ 負荷が高くなると最小化状態から復帰することがあるのを修正
・ 最小化からの復帰を左ボタンダブルクリックからシングルクリックに変更
・ 再チェック時やUPフォルダ状況が変わったときに回線切断するようにした
・ UPフォルダ状況が変わったときに再描画が行われないのを修正
・ ファイル名、トリップ、ハッシュ情報まとめてのクリップボードコピー機能追加
・ 色設定によっては選択されていないボタンの文字が読めないことがあるのを修正

主にトリップ機能の追加で、いままでの暗号キー部分がこれに置き換わります。
2chのトリップ同様、UPする人の個人認証にも使えますが、どちらかというと、
本来一つのファイルなのに都合により複数に分かれているファイルを
同じものと識別するための機能となります。

従来の暗号キーと同じで、検索条件にトリップが追加されることになります。
なお、トリップは10桁ですが、元の文字列に#を追加する形でも検索できます。

あとは、細かい修正だけです。

ああ、あとプロトコルが違うとバージョン警告が出ませんので注意してください。
β21の方にはプロトコル違いの警告がログのところに出るだけです。


971 名前:47 投稿日:02/11/17 01:32 ID:pjyhGVIs main/1037399539.html#739
β21.44です。互換性ありません。

・ カンパフェア化です。



972 名前:47 投稿日:02/11/17 03:43 ID:6twLlN0/ main/1037399539.html#774
ゔ〲〰
ですね。

973 名前:47 投稿日:02/11/17 08:39 ID:IfqDHHZD main/1037399539.html#817
おまいらとりあえずこのスレに書き込むときは名前欄「47」な!

974 名前:47 投稿日:02/11/17 10:51 ID:rd4qSRnk main/1037399539.html#836
ダミーです

975 名前:47 投稿日:02/11/17 10:56 ID:eSgKyj5m main/1037399539.html#842
β21.44です。互換性あります。引き続きパラメーター微調整です。

・ 上流ノード(速度1000以上)間でのキー交換率を向上
・ 離れたノード間での中継転送発生率を落とした
・ BBSキー転送率を一般キー転送率に依存しないようにした

通常キー転送の方はこんなもんでも良いんじゃないかとは思いますが、
どうもキー分布の偏りが大きくなっているようでしたので修正入れました。

もともと、拡散によるキー転送では、キーは上流に流れる率が多く、
下流に流れないのですが、この傾向がますますはっきりしてきて、
キー拡散で受け取ったキーに対してダウンをかける(つまり地引する)と
比較的下流にダウンにいって、検索でかかったキー(ハッシュ検索や
ヒット数の少ない検索で得たキー)にダウンをかけると
上流につながりやすいという状況になってるんではないかと思います。

上流は下流から積極的に地引して、下流は上流から高速に落とすということで、
キャッシュ分布的には理想的ですが、今度は上流ノードがアップばかりで
ファイル落としにくくなってるはずということで、
上流ノード間のキー交換率を上げてもう少し上流ノード間で
積極的にやり取りするようにしました。

もしかすると上流ノードでキーがあふれ易くなるかもしれませんが、
今ですとリミッタついてますので飛ぶより先にリンクが切れると思いますので、
適当に上流ノードではキー限界を上げるなり、
クラスタ外のキーを積極的に消去するようにお願いします。

どうしてもクラスタ外のキーが混ざりやすくなっていますので、
大量に受け取って大量に消すことでフィルタリングで選別するしかないでしょう。


976 名前:47 投稿日:02/11/17 10:56 ID:eSgKyj5m main/1037399539.html#844
あと、キー寿命延長でキーが遠くに届く分、中継発生率が上がっている
ようですので落としておきました。

キー寿命延長で一見ファイルが落としにくくなったように見えるかもしれませんが、
クラスタ外でもキーが見える分、クラスタ外からダウンすると
目的の対象に対する中継発生率が高くなり、結果落とせないだけです。

ダウンが途中で切られやすくなっているのは、多くの場合、途中に中継が
入っているからです。中継先のノードのキャッシュが途中で途切れるとキーロスト
(すでに中継先で中継が失敗しているとき)もしくはタイムアウト
(中継先のダウン速度が遅くてキャッシュ転送が間に合わないとき)します。

クラスタ中心に来るほどこれが生じにくくなるので、クラスタ中心ほど
ダウン成功率が上がるはずです。効率的にファイルを落としたければ、
よりクラスタを考慮した方が良いかと思います。

あと、BBSキー数がかなり困ったことになっているのでキー転送方式を変えました。
あまり転送率上げると今度は通常キーの転送を圧迫するので押さえ気味に
してありますのでもう一度調節が必要かもしれません。



977 名前:47 投稿日:02/11/17 11:02 ID:lPkOhOsK main/1037399539.html#853
47氏モツカレ〜

978 名前:47 投稿日:02/11/17 11:13 ID:lPkOhOsK main/1037399539.html#861
>857
nyユーザというか、Windowsユーザには必須と思われ

979 名前:47 投稿日:02/11/17 11:13 ID:rd4qSRnk main/1037399539.html#862
スレタイについては
>>238>>447にあるとおりです。


980 名前:47 投稿日:02/11/17 11:14 ID:87lJ5P4W main/1037399539.html#863
ややこしいからやめれ


981 名前:47 投稿日:02/11/17 11:16 ID:wxKu8td3 main/1037399539.html#864
>>862
そういうこと言うと
「じゃあ47は公式に『MXの次、で検索してください』とか書け」
とか言い出すぞ

982 名前:47 投稿日:02/11/17 11:19 ID:lPkOhOsK main/1037399539.html#865
>864
ある程度厨避けにはなってるみたいだし、現状のままでいいんじゃない?
少なくとも漏れは毎回スレタイ見るの楽しみにしてる


983 名前:47 投稿日:02/11/17 11:21 ID:lPkOhOsK main/1037399539.html#867
>866
「互換性あります」ででも検索しなさい(ワタ

984 名前:47 投稿日:02/11/17 11:26 ID:lPkOhOsK main/1037399539.html#872
>869
スレタイに「Winny」と入れるとネトラソ厨その他が入ってきて(゚д゚)マズーと
何度も議論されて今に至るわけだが…

985 名前:47 投稿日:02/11/17 11:31 ID:lPkOhOsK main/1037399539.html#879
>874
現状よりも酷くなるぞ

986 名前:47 投稿日:02/11/17 11:33 ID:wxKu8td3 main/1037399539.html#884
Winny本スレ、なんてタイトルにすると6時間で潰れると断言できる

987 名前:47 投稿日:02/11/17 11:38 ID:wxKu8td3 main/1037399539.html#889
隔離された初心者スレの方がまだ落ち着いてるってんだから笑えない

988 名前:47 投稿日:02/11/17 11:46 ID:/whoM7of main/1037399539.html#896
>>889 47騙るのやめれや


989 名前:47 投稿日:02/11/17 11:50 ID:lPkOhOsK main/1037399539.html#904
>902
あなた要らないです βテスタやめて下さい


990 名前:47 投稿日:02/11/17 11:56 ID:lPkOhOsK main/1037399539.html#917
>913
Freenetスレが落ちて久しいな…

991 名前:47 投稿日:02/11/17 11:57 ID:lPkOhOsK main/1037399539.html#921
【救世主】完全匿名のP2Pソフト「Freenet」10/28
ttp://tmp.2ch.net/test/read.cgi/download/1035888466/l50

このスレは以前のFreenetスレの継続じゃなさそうだしな

992 名前:47 投稿日:02/11/17 11:59 ID:lPkOhOsK main/1037399539.html#925
>923
漏れは密かにそれ期待してる…









なんて書くとまた誰かWinOZとか言い出すんだろうな…

993 名前:47 投稿日:02/11/17 12:03 ID:lPkOhOsK main/1037399539.html#933
オープンソースでワイワイ作るのも面白そうだけどね…
でも皆結構今のWinnyで満足してるでしょ?


994 名前:47 投稿日:02/11/17 12:05 ID:lPkOhOsK main/1037399539.html#939
(・∀・)ウィンパ!




2chねら専用ですな


995 名前:47 投稿日:02/11/17 12:08 ID:lPkOhOsK main/1037399539.html#944
>937
今のWinnyでも解析すればかなりのところまで分かるでしょ
それでも最終的にタイーホには 悪意を持ってUploadしていた ことを証明しなきゃいけないから
根拠無しじゃ令状も取れないから家宅捜索でR探し出すことも出来ないと思われ

996 名前:47 投稿日:02/11/17 12:15 ID:lPkOhOsK main/1037399539.html#950
950ズザー

997 名前:47 投稿日:02/11/17 12:35 ID:lPkOhOsK main/1037399539.html#965
âge

998 名前:47 投稿日:02/11/17 12:36 ID:XvHJFC/9 main/1037399539.html#968
     

999 名前:47 投稿日:02/11/17 12:39 ID:lPkOhOsK main/1037399539.html#974
sâge

1000 名前:47 投稿日:02/11/17 12:45 ID:lPkOhOsK main/1037399539.html#999
次スレでは1.0正式版をリリースします。


1001 名前:47 投稿日:02/11/17 11:55 ID:lPkOhOsK main/1037500935.html#12
>1モツカレ〜











#47氏トリップつけキボンヌ
#つーわけで名前欄47

1002 名前:47 投稿日:02/11/17 12:38 ID:lPkOhOsK main/1037500935.html#32
>24
実際、欲しい機能が特に無いんだよな


1003 名前:47 投稿日:02/11/17 12:39 ID:Z/lp7ReR main/1037500935.html#36
Winny1.0β21.44

1004 名前:47 投稿日:02/11/17 12:41 ID:lPkOhOsK main/1037500935.html#43
結局他の人はどうなの?
最近のnyでファイルが落ちてくる速度に不満ある?


1005 名前:47 投稿日:02/11/17 12:42 ID:lPkOhOsK main/1037500935.html#49
>41
確かにそれは比較的簡単
公開鍵暗号式で容易に解決できると思われ
ただ、そうすると 公開鍵保持が本人証明→タイーホ時の証拠となり得る


1006 名前:47 投稿日:02/11/17 12:51 ID:lPkOhOsK main/1037500935.html#65
>55
ttp://tmp.2ch.net/test/read.cgi/download/1037399539/842-844


1007 名前:47 投稿日:02/11/17 12:52 ID:lPkOhOsK main/1037500935.html#68
>63
ネトラン厨(・∀・)ハケーン

1008 名前:47 投稿日:02/11/17 12:55 ID:lPkOhOsK main/1037500935.html#73
どのソフトでもそうだけど、とにかく仕様がある程度固まらないことにはどうしようもない

つーわけで、(・∀・)ウィンパ!に欲しい機能募集
漏れとしては、
交換=MX=殺伐→(・∀・)カエレ は間違いだ! 
ttp://tmp.2ch.net/test/read.cgi/download/1036314993/l50
で議論されてる交換機能に似た機能(新作などを手早く出回らせるのを可能にする)が欲しかったり…





#>24不在中にコソーリやってみる


1009 名前:47 投稿日:02/11/17 12:57 ID:QK0qhEAb main/1037500935.html#77
お久しぶりです。こないだの任意同行→逮捕の件ですが、
ネットランナーさんんが用意してくださった100万円を保釈金として
出てくることができました。本当に感謝しています。
というわけで早速β21.45です。
今回の変更は主に逮捕対策です。

・ 中継の段数を2倍に増やした
・ 緊急データ全消去機能を付けた
・ 次の就職先を見つけた

緊急データ消去機能に関しては、タスクバー上のWinnyのアイコンを
右クリックして、「全データ消去」を選んでください。
有名どころのHDDでしたら、ローレベルフォーマットに対応しておりますので、
データの復元は不可能となります。

転送率、キー寿命のほうは21.44から変えていません。
引き続きご報告のほうよろしくお願いします。

1010 名前:47 投稿日:02/11/17 12:59 ID:lPkOhOsK main/1037500935.html#78
>75-76
ある程度上方申告すればマシになるかも

>75はあまりに下流に居るのが問題っぽい

>76は流れてくるキーの絶対量が少なそう

でも、皆が上方申告するとネットワーク効率が逆に落ちていく
このあたりを自律的に調整する機能があるとよさげ<(・∀・)ウィンパ!
本当に作るならね


1011 名前:47 投稿日:02/11/17 13:14 ID:lPkOhOsK main/1037500935.html#93
>88
ある程度参考になりそう
でもやはり基本的な流れはy = 1/x * sin(x)のグラフみたいに徐々に誤差を小さくしていって理想値に近づける感じかな

>90
うち1.5Mだけど、120K申告でかなりうまく流れてる…
中継もそこそこ入ってるし クラスタリングの影響が大きいのか…


1012 名前:47 投稿日:02/11/17 13:18 ID:lPkOhOsK main/1037500935.html#95
>92
それなら匿名BBSツールと見ていいのかな…zigmoみたいな


#MXの次ではないな・・


1013 名前:47 投稿日:02/11/17 13:30 ID:lPkOhOsK main/1037500935.html#108
>98
( ´,_ゝ`)プッ


1014 名前:47 投稿日:02/11/17 13:35 ID:lPkOhOsK main/1037500935.html#115
>114
「MXの次」Winny報告・要望スレ 2枚目
ttp://tmp.2ch.net/test/read.cgi/download/1037336109/l50


1015 名前:47 投稿日:02/11/17 13:39 ID:lPkOhOsK main/1037500935.html#119
>116
ttp://tmp.2ch.net/test/read.cgi/download/1037336109/1
> ・数レス以上に渡るつっこんだ議論は本スレで。

ここしばらくマトモな議論見たこと無いがな


1016 名前:47 投稿日:02/11/17 15:41 ID:IHKnUeBO main/1037500935.html#164
β21.45です。互換性あります。パラメーター微調整です。

変更が頻繁ですいませんが、この手のP2Pアプリですと、実際に動かして
みないと作っている方もどう変わるか分かりませんので我慢してください。

一度に変えても相互作用で何がどうなったのか分からないので
少しずつ変えて様子見てます。

・ 十分広まっていると判断されたキーの送信を単純にカットするのではなく
 確率的に送信率を落とすようにした。

今までだと十分広まっていると判断されたキーを単純に送信カットしていたので、
完全キャッシュを持っているノードに囲まれているのに自分だけ持っていないという場合、
ダウンできないことが有り得ました。
また、メジャーなものの多重ダウン確立が落ちていたはずです。

ということで、これ対策でこれらのキーも少しは転送するようにしました。

これによりβ21.3とβ21.44の間の設定になりますので、
もしかするとキーが増えすぎるかもしれませんが
その場合適当に削除条件でキーを消すようにお願いします。

1017 名前:47 投稿日:02/11/17 20:30 ID:i/3GeuRL main/1037500935.html#352
β21.46です。互換性あります。パラメータの微調節です。

・ BBSキーの転送率を落とした

変更が頻繁ですいません。トータルのBBSキー数がこちらの想像以上で転送リンクの
半分近くBBSキー転送で占めてるという致命的な状況なんで対処します。

レアキー用に確保したはずの分までBBSキーで使ってしまっているので、
BBS機能がメインでないWinnyとしてはちょっとまずいです。β21.44の時点で
キー転送の密度を倍程度まで上げられたのに、その余裕を全部BBSキー転送に使ってます。

これだけBBSの反応が良いのもそれはそれで魅力的ですが、
今回の修正後でも、多少BBSのキーロスト率が高くなる
(スレッド立て主のIPが変わった場合にそれに気がつくのに数十分かかる)
だけで見れるスレ数はそんなに変わらないはずです。

もしBBS専用バージョンでも作ることがあったら今回の経験を参考にしましょう。


1018 名前:47 投稿日:02/11/17 20:43 ID:g2eUfon4 main/1037500935.html#380


1019 名前:47 投稿日:02/11/17 20:51 ID:U4tE3BGR main/1037500935.html#391
β21.45です。プロトコル変わったので互換性ありません。

変更が頻繁ですいませんが、この手のP2Pアプリですと、実際に動かして
みないと作っている方もどう変わるか分かりませんので我慢してください。

一度に変えても相互作用で何がどうなったのか分からないので
少しずつ変えて様子見てます。

・ 十分広まっていると判断されたキーの送信を単純にカットするのではなく
 確率的に送信率を落とすようにした。

今までだと十分広まっていると判断されたキーを単純に送信カットしていたので、
完全キャッシュを持っているノードに囲まれているのに自分だけ持っていないという場合、
ダウンできないことが有り得ました。
また、メジャーなものの多重ダウン確立が落ちていたはずです。

ということで、これ対策でこれらのキーも少しは転送するようにしました。


1020 名前:47 投稿日:02/11/17 21:00 ID:U4tE3BGR main/1037500935.html#407
β21.46です。互換性あります。パラメータの微調節です。

・ BBSキーの転送率を落とした

変更が頻繁ですいません。トータルのBBSキー数がこちらの想像以上で転送リンクの
半分近くBBSキー転送で占めてるという致命的な状況なんで対処します。

レアキー用に確保したはずの分までBBSキーで使ってしまっているので、
BBS機能がメインでないWinnyとしてはちょっとまずいです。β21.44の時点で
キー転送の密度を倍程度まで上げられたのに、その余裕を全部BBSキー転送に使ってます。

これだけBBSの反応が良いのもそれはそれで魅力的ですが、
今回の修正後でも、多少BBSのキーロスト率が高くなる
(スレッド立て主のIPが変わった場合にそれに気がつくのに数十分かかる)
だけで見れるスレ数はそんなに変わらないはずです。

もしBBS専用バージョンでも作ることがあったら今回の経験を参考にしましょう。


1021 名前:47 投稿日:02/11/18 10:27 ID:FlnqepLX main/1037500935.html#710
β21.47です。互換性あります。パラメータの微調節です。

・ BBSキーの転送率を落とした
・ 中継発生率を落とした
・ メジャーキーの送信率を上げた

バランスの悪そうなところを調節しました。

キー分布的には、BBSキーがまだ多すぎますがバランスはβ21.3より
良くなってると思います。あとはファイルが落とせるかどうかですが、
こちらはキャッシュの分布によるので時間が立って落ち着かないとよく分かりません。
とりあえずまだ中継率が高いようではありますので落としてはおきました。

そろそろ落ち着くかと思いますので安定するまで気長にお待ちください。


1022 名前:47 投稿日:02/11/18 10:32 ID:gxzd+CJz main/1037500935.html#719
47スレ目あたり正式リリースができそうな予感です。
つきましては一回くらい私に47getさせてはもらえないでしょうか?

1023 名前:47 投稿日:02/11/18 15:15 ID:Qxi+Jzgp main/1037500935.html#855
もうすぐβ22だします。
もう少し待ってください。

1024 名前:47 投稿日:02/11/18 22:29 ID:gdiXFgcp main/1037614666.html#76
β21.48です。互換性あります。引き続きパラメータの微調節です。

・ メジャーキーの場合の送信率低下を止めた

いろいろ実験していてすいませんが、ちょっと疑問に思ったので試します。

流れてるキー比率を見てると、既にメジャーなキーの送信を抑制しても
そうでなくても送信量がそれほど変わらん状況です。21.47で3割くらい削減
できているはずですが、キー寿命変更の影響が大きいので誤差の範疇です。

逆にメジャーなキーの送信抑制があると、同じノードのキーばかり使って、
多重ダウンがかかりにくくなると思われます。落としにくくなってるのは
結局これなんじゃないかと(ダウンにムラができ易くなってる)。

何となくですが、検索率の調節はキー寿命でやったほうがよさそうです。

ということで、もう一つ怪しいところはありますが(上下ノードのキー分布)、
どれがどういう影響出ているのかやってみないとわからないので、
この仮説でどうなるか試してみます。


1025 名前:47 投稿日:02/11/18 22:35 ID:FBH7zBBv main/1037614666.html#85
β21.49で・・・・やっぱり止めた。

1026 名前:47 投稿日:02/11/19 15:16 ID:fwB4r7wc main/1037614666.html#369
β21.5です。互換性あります。自動ダウン周辺の調節です。

・ 自動ダウン対象選択時に既にダウン中のノード情報を考慮していなかったので修正
・ 検索クエリを発行する条件を緩やかにした(検索ヒット数が10を切ったらクエリ発行)

どうもヒット率のわりにダウン開始されないことが多いなと思って調べてみたら
いくつか問題を見つけたので修正しました。

まず、今ですと同じノードに連続ダウンかけてもダウンキャンセルする様になってるんですが
(アップ側でも、同じノードから接続要求来たら切る)
自動ダウンでキーを選ぶ際にこれを考慮していなかったので、
絶対落とせないのにしつこくダウンかけようとして自分で取りやめて
結局その他のノードにダウンしにいかないの結局落とせないということが多いことがわかりました。

ということで、ダウン中のノードを自動ダウンの対象から外すように修正しました。
ダウン依頼先にばらつきが出るので、ダウン率が上がると思います。

あと、せっかくキーを見つける率が高くても検索クエリを発行しないと
上流のキーが見えません。ので、自動ダウン周りのパラメータを調節して
自動ダウンでキーが発見しやすいようにしておきました。

ダウン枠が余ってるノードなら今回の修正でかなりダウン率が上がるんじゃないかと思います。



1027 名前:47 投稿日:02/11/19 20:20 ID:OqibrdPS main/1037614666.html#528
β21.51です。互換性あります。クエリ周りの修正です

もうすぐ忙しくなるのが分かっているので
暇とやる気があるうちに直せるだけ直してしまおうってことで
ここのところ修正多いですけどお付き合いください。

やはり余裕がないとテストコードが書く余裕がなくて
致命的なバグを見落としやすいようですので今のうちに直しましょう。

・ 下方へクエリが発行されていなかったのを修正

上流にいくほどクエリヒット率が悪いようなので調べてみたんですが、
UP検索リンクが0だと検索パケットがまったく出ておらず、下流から
流れてくるキー任せになっていました。これじゃ上流で検索率が悪くなるのは
当たり前ということで、確実に下方にもクエリ出すようにしました。

Winnyの検索パケットは基本的に上流方向にしか流れないのですが、
上流ノードが無いと一時的に下流に一つ下りてスイッチバックしていきます。
が、ここのところでのバグです。上流ノードでかなりダウン率が良くなると思います。

なお、これはクエリを発行する部分の修正なので、周辺のバージョンに関係なく
検索率が良くなるはずです。試してみてください。


1028 名前:47氏へ 投稿日:02/11/19 20:20 ID:yS7pQ+IC main/1037614666.html#529
LANでWinnyできますか?

1029 名前:47 投稿日:02/11/19 20:22 ID:hDgSE0Af main/1037614666.html#542
β21.51です。互換性あります。自動ダウン周辺の調節です。

・ 自動ダウン対象に既にダウン中のノード情報を考慮してたがパラメータを再調整


どうもヒット率のわりにダウン開始されないことが多いなと思って調べてみたら
いくつか問題を見つけたので修正しました。

まず、今ですと同じノードに連続ダウンかけてもダウンキャンセルする様になってるんですが
(アップ側でも、同じノードから接続要求来たら切る)
自動ダウンでキーを選ぶ際にこれを考慮していなかったので、
絶対落とせないのにしつこくダウンかけようとして自分で取りやめて
結局その他のノードにダウンしにいかないの結局落とせないということが多いことがわかりました。

ということで、ダウン中のノードを自動ダウンの対象から外すように修正しました。
ダウン依頼先にばらつきが出るので、ダウン率が上がると思います。

あと、せっかくキーを見つける率が高くても検索クエリを発行しないと
上流のキーが見えません。ので、自動ダウン周りのパラメータを調節して
自動ダウンでキーが発見しやすいようにしておきました。

ダウン枠が余ってるノードなら今回の修正でかなりダウン率が上がるんじゃないかと思います。

1030 名前:47 投稿日:02/11/19 20:23 ID:tPW6dDp5 main/1037614666.html#548
イヤン

1031 名前:47 投稿日:02/11/19 20:50 ID:F3p5LwTZ main/1037614666.html#587
β21.52です。互換性あります。自動ダウン周辺の調節です。

・ 自動ダウン対象に既にダウン中のノード情報を考慮してたがパラメータを再調整


どうもヒット率のわりにダウン開始されないことが多いなと思って調べてみたら
いくつか問題を見つけたので修正しました。

まず、今ですと同じノードに連続ダウンかけてもダウンキャンセルする様になってるんですが
(アップ側でも、同じノードから接続要求来たら切る)
自動ダウンでキーを選ぶ際にこれを考慮していなかったので、
絶対落とせないのにしつこくダウンかけようとして自分で取りやめて
結局その他のノードにダウンしにいかないの結局落とせないということが多いことがわかりました。

ということで、ダウン中のノードを自動ダウンの対象から外すように修正しました。
ダウン依頼先にばらつきが出るので、ダウン率が上がると思います。

あと、せっかくキーを見つける率が高くても検索クエリを発行しないと
上流のキーが見えません。ので、自動ダウン周りのパラメータを調節して
自動ダウンでキーが発見しやすいようにしておきました。

ダウン枠が余ってるノードなら今回の修正でかなりダウン率が上がるんじゃないかと思います。

1032 名前:47 投稿日:02/11/20 08:04 ID:fx+yS56y main/1037614666.html#787
β21.52です。互換性あります。引き続きパラメータの微調節です。

・ メジャーキーの場合の送信率低下を止めた

いろいろ実験していてすいませんが、ちょっと疑問に思ったので試します。

流れてるキー比率を見てると、既にメジャーなキーの送信を抑制しても
そうでなくても送信量がそれほど変わらん状況です。21.47で3割くらい削減
できているはずですが、キー寿命変更の影響が大きいので誤差の範疇です。

逆にメジャーなキーの送信抑制があると、同じノードのキーばかり使って、
多重ダウンがかかりにくくなると思われます。落としにくくなってるのは
結局これなんじゃないかと(ダウンにムラができ易くなってる)。

何となくですが、検索率の調節はキー寿命でやったほうがよさそうです。

ということで、もう一つ怪しいところはありますが(上下ノードのキー分布)、
どれがどういう影響出ているのかやってみないとわからないので、
この仮説でどうなるか試してみます。


1033 名前:47 投稿日:02/11/20 09:27 ID:H6dVpjg2 main/1037614666.html#798
β22です。相互性はありません。

今回プロトコルが変わりました。注意してください。
キャッシュもv0.4→v0.5になっています。このバージョンで変換できます。

・キーの管理をkey.txtで行うようにした
・BBS機能をなくした。

どうもキーの流通問題がうまくいかずなやんでいましたが、
これでだいぶ状況は改善されるはずです。

今までは各ノードにカウンタ等をつけてキーの均衡を図りましたが、
キー送信履歴をkey.txtで管理して一旦Winnyを切っても前回の履歴を参照して
キーの発行数を調整できるようになっています。お互いにこの情報をやり取りすることで
各ノードが全体の流通量を把握できるようになっています。

こうすることでネットワーク全体の流通量を管理できるようになっています。
検索ヒット数はβ21より上がるはずです。

BBS停止にはこのスレでも賛否両論があるようで、
ある意味このバージョン自体がテスト機のような感じです。
要望が多いようでしたら次のバージョンで復活させます。

変更が頻繁ですいませんでした、このバージョンはしばらく様子をみようと思います。

1034 名前:47 投稿日:02/11/20 16:16 ID:mye2MZC/ main/1037614666.html#909
このままバグがでなければそろそろ正式版にしてもいいかなと思います。
今月は忙しいので来月頭に正式版をリリースします。

1035 名前:47 投稿日:02/11/21 22:16 ID:j/J2nAYV main/1037779628.html#226
仕事は忙しくなってきているのですが、なんとか週末に更新する予定です。

・初期ノードの暗号化アルゴリズムの変更
・キャッシュの暗号化アルゴリズムの変更

以前の初期ノードも復号できるようにはします。
キャッシュはv0.4からv0.5となりますが、上位互換性があります。
自動的にv0.5キャッシュに変換されます。

1036 名前:47 投稿日:02/11/21 22:41 ID:wbD60Fwo main/1037779628.html#235
なお、勝手にキャッシュの解析をするのはやめて頂くようお願いします。

1037 名前:47 投稿日:02/11/22 19:03 ID:zv2WyRCr main/1037779628.html#338
β21.52です。互換性あります。クラスタ化周りの修正です

・ キーワードによるクラスタ化を強化

β21.4以降の変更でクラスタが比較的大きくなる傾向がある(キー拡散率が高くなっているため)
副作用でクラスタ化が弱くなっているようですので修正しました。

前よりキーワード重視にしてあります。

本来、ファイルを欲しい人だけ集まっていてもファイルは広まらないので、
該当するキャッシュを持つかどうかもクラスタ化の際に考慮しているのですが、
ノードが増えてきているのと、今ですと多くの方がクラスタワードを意識して
設定してるのではないかと思いますので、キーワード重視率を少し増やしました。

ちょっとバランスが変わると思いますが、キーが広まりやすい今ですと
こちらの方が調子が良くなりやすいと思いますので試してみてください。



1038 名前:47 投稿日:02/11/22 20:28 ID:IspmAA87 main/1037779628.html#412
β21.53です。互換性あります。クラスタ化周りの修正です

・ 接続優先度が高くなるように修正

接続優先度の数値に+10して表示するようにしました。

1039 名前:47 投稿日:02/11/22 21:51 ID:wJaRDeJK main/1037779628.html#496
だいぶ調子よくなってきたみたいです
これから年末にかけて少し忙しくなるんで
しばらくこのまま様子を見ようと思います。
なんとか年内には正式版を公開したいと思いますんで
不具合報告等ありましたら関連スレへ書き込み願います。
ちなみに正式公開版はシェアウェアとなる予定でおります。

1040 名前:47 投稿日:02/11/24 17:53 ID:zh7R7Y8T main/1038067252.html#355
だいぶ安定したみたいですので
次スレの47で正式版公開する予定です

1041 名前:47 投稿日:02/11/24 17:55 ID:zh7R7Y8T main/1038067252.html#357
場所あけといて下さいね。

1042 名前:47 投稿日:02/11/24 21:00 ID:7pcO1ODv main/1038067252.html#462
 スレッドタイトルに興味はないので適当にやっておいてください。
 誘導があればそっちに行きますんで。
 あ〜いまは開発する時間が欲しい・・・。

1043 名前:47 投稿日:02/11/24 21:09 ID:7pcO1ODv main/1038067252.html#468
 某所でキャッシュの暗号化が解読されてしまったので次回からは変更します。
 よって互換性はなくなります。

1044 名前:47 投稿日:02/11/24 21:13 ID:UdY3YZHl main/1038067252.html#472

既にご存じの方もおられるかと思いますが、
私、47は、来年から阪神タイガースのユニフォームに袖を通す事となりました。
栄養士になるという夢の狭間でいろいろと悩みましたが、
ピッチングコーチという大役に、
私のような弱輩を信頼し、選んでくださった星野監督の熱意に心打たれ、このような決断に至りました。
現役を退く事へ、惜しんでくださる皆様の声は、痛いほど胸に響いております。
いままで暖かい声援を送ってくださった皆様には、もはや感謝の言葉もありません。
来シーズンは阪神タイガースの一員として、
精一杯、精一杯、頑張らせて頂く所存でございます。
どうぞみなさま、これからも、私、47を、暖かくお見守りください。
どうぞ、よろしくお願いします。浦和レッズは永遠に不滅です。

1045 名前:47 投稿日:02/11/25 06:23 ID:C3zWsz9v main/1038067252.html#643
β21.6です。互換性あります。ファイルダウン率などの微調整です。

・ 中継転送発生率がキーのメジャー度に応じて動的に変わるようにした
・ 長時間動作させているとノード情報が空になってしまうのを修正

どうも21.52になってから中継発生率が上昇しているようなので理由を考えて
調べてみたんですがクラスタ内でみな同じような条件で検索をかけているので、
人気のあるキーの検索ヒット率が凄くなり、結果このキーが各所にたらい回しされて
副作用で中継発生率が非常に高くなっているようです。

ファイル転送が始まってすぐキーロストで切れやすくなっているのはこれかと。

ということで、これを防止するメカニズムを入れときました。
全体として広まってないキャッシュほど中継発生率が高くなり、
キーロスト発生率は下がるので、ダウン成功率は上がるはずです。

ただし、この修正は周りのノードのバージョンが上がらないと見えてきませんので
注意してください。

あと、下流ノードですと、検索リンクが安定してしまって
結果新しいノード情報が入ってこないでそのままノード情報が空に
なってしまうことがあるようでしたので、対処しておきました。
標準で検索リンク自動切断がかかります
(自動切断ボタン押されてなければ1時間、入っていると10分で検索リンクを切ります)

今まで同様、急いでクラスタを移動したいときに検索リンク自動ONにしてください。


1046 名前:47 投稿日:02/11/25 08:08 ID:YlebItOK main/1038067252.html#689
β21.6から実装されている、ある機能がありますが
これはβ22以降で正式に有効になります。
シェアウェア化の第一歩としての機能です。
反対意見などありましたら、ここに書き込んでください。

1047 名前:47 投稿日:02/11/25 08:16 ID:YlebItOK main/1038067252.html#697
>>694
まだ完全に決定したわけではありませんが、私としてはシェアウェア化の方向で進めています。
なにかいい課金方法があれば意見をお願いします。

1048 名前:47 投稿日:02/11/25 08:18 ID:ZK3YKyCa main/1038067252.html#698
>>697
偽者いい加減にしろ!

1049 名前:47 投稿日:02/11/25 08:21 ID:YImAz1z8 main/1038067252.html#702
>>698
オマエモナー

1050 名前:47 投稿日:02/11/25 08:40 ID:S7pfMkFO main/1038067252.html#711
すいません。1箇所バグってました。
部分キャッシュの転送が直ってませんでした。
ということで、21.61にしといてください。

あと上のは偽者。


1051 名前:47 投稿日:02/11/25 08:49 ID:YlebItOK main/1038067252.html#720
何度もすいません。また修正がありました。
これでβ21.62となります。
今UPしました。

1052 名前:47 投稿日:02/11/25 09:01 ID:zCvzwYje main/1038067252.html#733
ん?

1053 名前:47 投稿日:02/11/25 09:06 ID:zCvzwYje main/1038067252.html#740
バージョンうpは頻繁にあった方が面白いと思われ。

1054 名前:47 投稿日:02/11/25 09:30 ID:HA762miU main/1038067252.html#766
何度もすいません。また修正がありました。
これでβ21.63となります。
今UPしました。

1055 名前:47 ◆SexyQDDAsc 投稿日:02/11/25 19:47 ID:GcdT7WP9 main/1038207274.html#158
荒らしは放置の方向でおねがいします

1056 名前:47 投稿日:02/11/25 21:16 ID:9raR/cXT main/1038207274.html#196
47ですv

1057 名前:47 投稿日:02/11/27 01:42 ID:qDevRV34 main/1038207274.html#878
β21.62です。互換性あります。クラスタ化の調節です

・ ダウン成功時の優先度上昇率を上げた

クラスタ化の様子を調べてみると、やはり頻繁にアップしている人ほど
クラスタキーワードが外れている傾向があってクラスタ中心にはキャッシュを
持っていない人が多く、その結果全体的に落としにくくなっているようです。

キャッシュの影響度をまた上げても良いのですが、それよりも
ダウンできたときの優先度を上げたほうが効果が高いだろうと
いうことでそうしてみました。

今回、キャッシュによる評価はしていません。

キーワードの影響は相変わらず強いですが、お互いにダウンしあうと
これより優先度が高くなりますので、アップ率の高いノードが
クラスタの中心にきてお互いにつながりやすくなります。

他からのダウンが成功するとそのノードの優先度が上がるので、
自ノードからみると、他人にアップできれば相手からみた優先度が
高くなることになります。

優先度が高いほど再接続されやすいですし、優先度が低いほど
検索リンクが切れやすいので、お互いにやり取りしている
ノード間がより近い位置に配置されることになります。

逆にアップしないと、キーワードでクラスタには来れますが
クラスタ周辺に飛ばされやすくなります。キャッシュ内容による評価より
こちらの方が良い影響になると思うので試してみてください。



1058 名前:47 投稿日:02/11/27 06:37 ID:/kQtVDyB main/1038332518.html#52
仕事が一段落したので覗きに来ました。
今回のバージョンで全くdownが始まらない人もいるかと思われます。
これは前回のバージョンから転送の履歴を記録しているための仕様です。
つまりupがある一定の回数に達していないとdownも始まらないようになってます。
今年の更新はこれで最後になると思います。それでは。

1059 名前:47 投稿日:02/11/27 13:00 ID:vqrAq7pV main/1038332518.html#106
β21.63です。互換性あります。パラメータの微調節です

・ ノードリストにあるのに接続に行かないノードが生じるのを修正
・ BBSキー送信量を少し増やした
・ 中継転送発生率を少し落とした

ノードリストにあるのに接続に行かないという現象が生じるようなので
LANで条件いろいろ変えて調べてみました。

どうも、クラスタ情報の評価が早くて、一度接続したら優先度が下がるところ、
すぐに評価されて優先度が大きくなってしまって、再接続に行くので、
いつまでたっても接続に使われないノードが生じていたようです。

特に、接続の弾かれ易いPort0で起きやすかったようです。21.6以降で
ノードの接続関連を変えたのですが、ろくにLANテストしてなかったので
調節が甘かったようで。ということで直しておきました。

あと細かいパラメータ修正してあります。


1060 名前:47 投稿日:02/11/28 02:59 ID:ywShrCVh main/1038332518.html#459
β21.64です。互換性あります。ノード管理周りの調節です

・ ノード優先度と接続試行カウンタを分離

接続したらノード優先度を減らすという手法だと同じノードに何度も接続したり
だからといってそれを防ぐと優先度がマイナスになってリンクが切れる
など制御が難しいのでノード優先度と接続試行カウンタを分離しました。

ノード優先度は常に算出して基本的に同じ値で、
接続するたびに接続試行カウンタが増えます。
ノード優先度 - 接続試行回数でソートして大きい順に接続に行くので、
優先度の大きいほうがつながりやすくなります。
何度も接続すると自分からつなげに行く頻度が下がりますが、
接続できれば切りにくくなります。

あと、ノード優先度が大きく出た方が皆さん精神衛生上よろしい様ですし、
細かく差が出たほうがクラスタ化によろしいので比較的大きめにノード優先度が
算出されるようになってます。


1061 名前:47 投稿日:02/11/28 05:37 ID:zsEYOXfy main/1038332518.html#595
おはようございます。仕事が一段落したので覗きにきました。
たいへんなことになってますね(笑

1062 名前:47 投稿日:02/11/28 13:02 ID:5vAOFlmo main/1038332518.html#680
β21.65です。互換性あります。21.64からの小変更です。

・ 長時間優先度が0の検索リンクは他のノード情報を要求後、切断するという従来の動作をやめた
・ ダウン成功時にノード優先度が上がらないバグを修正
・ 二つのノード間でお互いに転送リンクを張り合うとリンクが切れるバグを修正

21.64で見落としていた箇所があったので修正です。

あと、負のクラスタ化のために行っていた、キーワードがまったく合わないとき(優先度=0)の
検索リンク切断動作のせいで、検索リンクが繋がりにくくなっているようなので
とりあえず止めてみました。これのせいで、キーワードにオリジナリティ溢れる単語を書いていると
検索リンクがそのうち切られてノードバッファが溢れるという動作になっていたのではないかと思います。

今度は優先度の低いノードと長時間繋がりすぎるという問題が出る可能性もありますが、
他からの検索リンクの再接続が頻繁であれば自動的に優先度の低いリンクは切られますので
普通は問題ないかと思います。

もし変なクラスタに行ってしまうときは検索自動切断で自分からリンク切ってください。


1063 名前:47 投稿日:02/11/28 22:50 ID:xTWvVzXL main/1038482725.html#86
えー今日でWinnyの開発を止めます

1064 名前:47 投稿日:02/11/28 22:51 ID:EncFLO2r main/1038482725.html#92
優先度さらに倍

1065 名前:47 投稿日:02/11/28 22:51 ID:Jc9jFvBA main/1038482725.html#97
β21.66です。互換性あります。

・ キーワードに重複があったら省いて評価するようにした

0カットをやめてもなかなか繋がらない症状がでるので調べてみましたが、
どうも三つとも同じワードにしている人だけが集まって
それ以外のノードが弾かれるという現象が生じるようなので対処しました。

三つ全部同じ方が優先度が高いので、特殊なクラスタを形成して
他のクラスタから完全に独立しているようです。ここのノードからノード情報もらっても
その様なノードばかりなので、他のノードへ移れなくなるようです。

ということで、同じキーワードを並べても一つしか書いていないのと同じにしました。

クラスタ化の点からすると、面倒くさがらずにできるだけちゃんと
関連キーワードを並べるべきかと思います。
理想的なのは、大分野、中分野、小分野でしょうか?

とりあえず、これでクラスタ間の乖離が多少は収まると思いますが、
あまり統一が取れすぎているのも困り者ですので各自工夫するようにお願いします。

今回の修正で、大分類を並べることでもクラスタの間移動できるとは思います。

分類の観点からすると、オリジナリティありすぎるのも困りますが
無さ過ぎるのも分別不能になって困ります。


1066 名前:47 投稿日:02/11/28 23:15 ID:nVt6brnn main/1038482725.html#168
[ レイプ ] [ 声優 ] [ 無修正 ] 林原めぐみが病院で無理やりいけない検査をされる.avi
50b22a08c194dad2f79109cd8271f14d

中身は知的障害者をマスクかぶせて水に顔を突っ込ませたり
フルオートのガス銃で撃ったりして暴行しているのを撮ったビデオ。
中身に期待して損した…
しかもドス黒い気持ちになるわ。これ撮った奴に同じことしてやりたい

1067 名前:47 投稿日:02/11/30 13:56 ID:Q2iMq9te main/1038482725.html#720
β21.67です。互換性あります。転送周りの調節です。

・ 転送発生率を下げた
・ 部分キーと仮想キーの転送発生率を別にした

どうも転送リンクが途中で切れる(=中継失敗)という話が多いようなので、
LANテストでいろいろ調べてみましたが、確かに転送が生じる率がかなり
高くなっているようです。特に上流が凄いことになってます。

てっきりクラスタ周りを変更したのでこれのせいかとも思ったのですが、
主原因はキーの流通量が増えているのが理由のようです。
こちらの想像以上にキーの出回る率が良くなってます。

21.5あたりから転送率が高くなっていたんだと思いますが、
ろくにテストしてなかったんで気がついてませんでした。
クラスタ変更で現象が分かりやすくなったということでしょう。

ということで、転送まわりを少し変えておきました。
もし問題が生じるとしたら匿名性の低下ですが、転送がなくなことはないので、
今と比べて状況が悪くなることはないと思います。
特に上流での転送率が下がると思いますので試してみてください。



1068 名前:47 投稿日:02/11/30 15:47 ID:AoxYUCUg main/1038482725.html#795
いまもテストしてるのですが、どうも問題があるようですね・・・。
どうも状況によっては全く転送が発生しない事があるようです。

今日はこれからでかけなければいけないので修正はできません。
しばらくの間21.67は使わないでください。

1069 名前:47 投稿日:02/11/30 15:50 ID:AoxYUCUg main/1038482725.html#802
うーん、転送の発生率をさげすぎたかなぁ・・・難しいですね。

1070 名前:47 投稿日:02/11/28 22:58 ID:sH5sXcNE main/1038482811.html#48
一応誘導しときます。本スレは↓
ttp://tmp.2ch.net/test/read.cgi/download/1038482725/

1071 名前:47 投稿日:02/12/01 11:39 ID:BdgGYNeF main/1038482811.html#350
β21.68です。互換性あります。バグ取りです。

・ 検索リンク下流にPort0がいると手持ちの仮想キーが消されることがあるバグを修正
・ 検索画面で検索ボタン連打したり再描画を繰り返すと飛ぶことがあるのを修正
・ 待ちうけポートの初期値を乱数で決定させるようにした

バグはまだ大量にあると思いますが、致命的なのをいくつか見つけたので修正しました。
特に1番目のバグが検索率やダウン率を下げているんではないかと思います。
上流が下流にクエリ出さないのを直したときに生じたバグです。

検索クエリがPort0にも行って、そこから帰ってくるときに
全てPort0のキーとみなされるためにキーが消えてました。

このバグでキャッシュが消えたりすることは無かったはずですが、
仮想キーが勝手に消えたりクエリ結果が消えたりしてたはずです。
特に上流における、中継時キーロスト率が改善されるんじゃないかと思います。

あと、標準ポートである7743ですが、初期値が一定だとあまりよろしくないようなので、
初期値をランダムにしておきました。ただし、iniファイル内にポート設定が無い場合に
使われる値であって、iniファイルの設定は引き継ぎますので、
iniファイルを消さないと違いがわかりません。

できればiniファイルを消して設定をやり直すようにお願いします。



1072 名前:47 投稿日:02/12/02 14:29 ID:ErWfoX1A main/1038750627.html#181


       ____
       |      |         / ̄ ̄ ̄ ̄\
       | (´・ω・ (    )  <  自分ファイト!
       | (   (    )   \____/
        ̄ ̄ ̄ ̄U U



1073 名前:47 投稿日:02/12/04 00:37 ID:kjeDcMLQ main/1038750627.html#565
ん、漏れ?

1074 名前:47 投稿日:02/12/05 02:37 ID:Ffv/jsJE main/1038750627.html#783
ちょっと仕事の方が忙しくてなかなか時間がとれません^^;

1075 名前:47 投稿日:02/12/05 02:41 ID:Ffv/jsJE main/1038750627.html#785
やはり、こうなってしまった以上課金していく方向しかないと思うのですが・・・
なにか他にいい方法があればお願いします。

1076 名前:47 投稿日:02/12/05 02:44 ID:Ffv/jsJE main/1038750627.html#787
( ゚д゚)、ペッ
     >>786


1077 名前:47 投稿日:02/12/07 00:31 ID:KAQZcOvg main/1039101560.html#192
               ∧             ∧
              / ・            /:::::';,
             /  ';          /::::::::::';
             /   ;______/::::::::::::::;
           /                ::::::::::::\
         / ,,__             __ __、 ::::::::\
        /´   "─`==-;_;  _;;;-ー==-─ ;`  :::::::::::|
         |    ,,ー==-=,  i.  ,,-ー==ー 、  ::::::::::::::|
        |    "ヽ.(゚。ソ)      (゚。ア) /`   ::::::::::::|  / ̄ ̄ ̄ ̄ ̄ ̄ ̄
         |       `""  ̄"  /:; `  ̄""  `    ::::::::::| < 呼んだ?
         |            ` _ ┼       ::::::::::::::/   \_______
          \       -=二三-ノ     ::::::::::::::::::/
           \                 :::::::::::::/
             ̄~`ヽ、          ,-─""′
           ___ノ          人_
     ,, --ー ̄              ::::::::::::::::: ̄ノ ̄ー-- ,,.__
    /       ー-- .,,      ..::::,, --ー "       :::::\
   /               ヾ   ソ           丶    ヽ
  /                 ヽ/                   :|
  |                                  :     |
  |      ::             ミ:              ::   ::...........:::::|
  .|     ::::|::       .       ミ::::           ::::::::i   :::::::::::::::|
  .|    :::::|:             ヾ::::          ::::::::::::|    :::::::::::|
  |     :::::|::              ミ:           :::::::::::|     :::::::::::|

1078 名前:47 投稿日:02/12/07 22:58 ID:b/o4WciR main/1039101560.html#387
検索の要は光の方々ですけど、こちらはある程度動いているようなので、
ダウンがうまくいくかどうかはADSL8Mクラスの方々がキャッシュを十分とって
ポートをちゃんと空けてあとは時間が十分立つかどうかかと思います。

ダウンがうまくいくことがあるのでしたら、バグっているというより、
システムが安定していないだけの要素が大きいのではないかと。


1079 名前:47 投稿日:02/12/07 23:47 ID:b/o4WciR main/1039101560.html#401
>>399
おまい、すげーなけっこうディープなとこから引き出したのに

1080 名前:47 投稿日:02/12/08 00:00 ID:cPsm7/cB main/1039101560.html#403
みなさん心配掛けてすいません。

いや、無性に酢昆布が食べたくなったんで、
近所のスーパーに買いに行ったんです。(イズミヤ)
そしたら、迷っちゃって、丸3日(^^;

明日には家に帰ってバージョンアップできるかと思います。
心配掛けて本当に申し訳ないです。

v21.69は酢昆布風味になると思います。

1081 名前:47 投稿日:02/12/10 00:12 ID:t8K6srFL main/1039101560.html#815
ここのところ非常に忙しいのでバージョンアップが滞っていてすいません。
β22です。β21系統とは互換性ありません。主にバグ取りです。

・ キー拡散時に隣のノードがフリーズしているとプログラムが落ちることがあるのを修正
・ ポート0のキーが拡散で送信されないことがあるのを修正
・ クラック対策を一部強化

どうもプログラム改造が話題になってますし、プロトコル変えないと
対処できない問題があったので、プロトコルバージョン上げます。

β21系統とは繋がりませんので、一度Noderef.txtを廃棄して
β22の初期ノードで接続するようお願いします。

主な修正点ですが、キー拡散時に相手の状態を見ていなかったので
相手ノードがフリーズしていているとそのうちバッファが溢れるという現象が起きるので、
キーを一定時間毎に送りつけるのではなく、一定時間毎に隣に要求を出す方式に変えました。

これで特に低スペックPCで多少は落ちにくくなるんじゃないかと思います。

あと動作的にはどうでもよいところですが、クラック対策を強化しときました。
簡単な修正ですが、それなりに解析が面倒になるのではないかと。



1082 名前:47 投稿日:02/12/10 00:14 ID:VfR1RVt+ main/1039101560.html#820
ドモ
ノ(´Д`)

1083 名前:47 投稿日:02/12/10 23:55 ID:E2fELCI3 main/1039456567.html#290
β22.1です。β22と互換性あります。ノード情報管理周辺の修正です。

・ ノード情報からDNSに検索に行く際に定期的にWait入れるようにした
・ ノード情報を他ノードに伝える際のノード個数を減らした
・ 他ノードへ送信するノードを相手から見た優先度順でソートして選別するようにした
・ ノードの優先度を常に再計算するようにした(前は優先度0でしかチェックしてなかった)
・ ノードの優先度表示でオフセット値(キーワード非依存の接続状況依存値)も表示するようにした
・ ノード情報表示変更を1秒に1回に減らした
・ ファイル書き込み時のエラーチェックが甘かった部分を修正

起動時にノード情報をDNSに問い合わせに行きますが、ここで集中的にDNS
問い合わせにいくと調子が悪くなることがあるようなので対処しました。

飛びやすいルーターを使ってるので調子が悪かった場合など、
これで多少良くなるんではないかと思います。

あと、ノード情報が溢れ難くなるように、ノード情報の送信数
(問い合わせで伝わるノード数)を減らしてあります。

ノード情報送信時にはできるだけ優先度が高くなるものを選んで送るようにしたので、
クラスタ化が悪くなることはないと思います。
(前だとそのノードからみた優先度が以外かどうかしか見てませんでしたが、
今回はソートして先頭から選んで送るようになってます)
その他、ノード情報送信関連で処理が甘かった箇所を修正してあります。

ただし、他ノードが22.1になるまではちょっと挙動が落ち着かない可能性あります。

あと、キャッシュ変換時にHDDがフルになった場合の対処などが
甘かったので修正してあります。


1084 名前:47 投稿日:02/12/13 01:34 ID:bEZeN0b5 main/1039693375.html#93
β22.2です。互換性あります。コネクション過多への対応です。

・ アップ枠に余裕が無い場合でのキーを流す条件をきつくした
・ 接続失敗時の優先度低下率を増加
・ 検索リンク接続の再試行待ち時間を長くした

最近の修正でポート警告周りは何も変えていないので、
ポート警告が増えているというのは、単にコネクション要求が多すぎて
ルーターその他が対応しきれないからだと思われます。

ということで、対処入れてみました。

まず転送リンクによるコネクション要求が増えすぎないように、
アップ枠が無いときのキー送信停止が起こりやすくしてあります。

今まではアップ限界になったらキー送信を止めてましたが、
アップリンク数がアップ限界-1になったらキー送信を止めます。

アップ要求の来る率が下がるので全体でみるとダウン率が下がる可能性もありますが、
LANでテストした限りではこちらの設定のほうが転送リンクが散って
結果全体が調子が良いように思えます。アップの偏りが少なくなります。

あと、同じノードに検索リンク要求を出し続けるというのもあるので、
接続失敗時の優先度低下率を増加させて同じノードに繰り返し接続に
行きにくくしました。

どの程度影響出るかわかりませんが、試してみてください。
アップ側の修正なので、変化が分かるのに時間はかかると思いますが、
アップ要求が来すぎてポート警告が出やすかったノードはすぐ調子が良くなると思います。



1085 名前:47 投稿日:02/12/14 00:29 ID:/x9Hyy1x main/1039693375.html#474
(=゚ω゚)ノ ぃょう

1086 名前:47 投稿日:02/12/14 00:35 ID:/x9Hyy1x main/1039693375.html#480
(=゚ω゚)ノ 今夜はver.upは無ぃょう


1087 名前:47 投稿日:02/12/14 01:24 ID:GMta2PWS main/1039693375.html#527
β22.3です。互換性あります。

・ ダウンリストのスキャン速度を落とせるようにした(高速ダウン試行ボタン)
・ 転送リンク限界だとBBSキー送信も止めてしまうバグを修正

まだポート警告出る人がいるようですが、ダウン試行回数が多いとなるらしいので、
ユーザー側の設定でダウン速度を落とせるようにしました。
高速ダウン試行ボタンがONだと1秒に2つスキャンしますが、
OFFだと、2秒に1回となります。

これですが、何か特定のものを落とすためにダウン条件が少なくて、
なおかつ人気があってほとんど落とせない対象の場合に何度もコネクションが
かかって直ぐ接続が切れますが、ネット周りでどこか処理が追いつかないと
これを繰り返しているとハングしてしまうんだと思います。

UP要求が集中しなくなってポート警告が出なくなったのはいいですが、
自分から頻繁にコネクションかけるんで同じことになっているということです。

ポート警告で悩まされている方は試しにこれをOFFにしてみてください。
ダウン率はそんなに変わらないか、条件によっては良くなると思います。

ただ、これで調子が良くなるということはルータやNICその他でどこか処理が
追いついてないんだと思いますのでそっちを見直したほうがいいと思いますが。

あと、BBSが少なくなるというバグがあったので修正しました。


1088 名前:47 投稿日:02/12/14 01:57 ID:/x9Hyy1x main/1039693375.html#585
>>584
いいえ

1089 名前:47 投稿日:02/12/15 20:15 ID:X32hBbuV main/1039877473.html#305
β22.4です。互換性あります。多重ダウン関連とBadPort0周りの修正です

・ 多重ダウン時に同じ箇所をダウンしに行きにくくした
・ 多重ダウン時のスキップ幅を大きくした
・ UP転送リンク過多の時に低速ノード優先で切るようにした
・ 高速ノードでのPort0へのアップ受付数を減らした
・ ネットワークサブシステムfail時に待ちうけポートを開きなおすようにした
・ 起動時に読み込むノード情報数を100個までに制限
・ BadPort0になる条件チェックを強化
・ ノード情報が溢れた時にBadPort0ノードなどが残るのを修正
・ リストコントロールのフォント周り修正
・ 表示周りでリソースリークしそうな箇所のチェックを強化

今まで、一つの大きなファイルにダウンが集中するというケースの
LANテストやったことなかったので試してみました。

動作自体は問題なくて、思ったより綺麗に多段転送が生じている
(ダウン中のファイルをアップしてもリンクに転送と出ませんがこれも転送の一種)
のがチェックできましたが、このテストで気がついた箇所を修正しておきました。

多少は拡散効率が良くなるんじゃないかと思います。

あと、BadPort0関連や表示周りで気がついたところを直してあります。



1090 名前:47 投稿日:02/12/15 21:24 ID:BH50I4R4 main/1039877473.html#454
β22.41です。互換性あります。表示のフォント変えられるようにしました。

ただし手抜きですので、間隔とかは変えられませんし、フォント一覧調べてません。
一覧に無いフォント名使うときはテキスト直接打ち込んでください。

あと、上下間隔は画面プロパティのアイコン依存です。
この辺は標準コントロール使ってるからなので、
そのうち全部自前処理に書き換えます。

やる気になるまでお待ちください。


1091 名前:47 投稿日:02/12/15 21:41 ID:h1EngnES main/1039877473.html#522
潜ります
もう来ませんので
ソースは女子アナ画像掲示板にて公開します

1092 名前:47 投稿日:02/12/15 22:31 ID:h1EngnES main/1039877473.html#640
ちなみに、女子アナ画像掲示板に
ソースを公表する際ZIP圧縮をかけますが、
パスワードは
私の本名ということで。

1093 名前:47 投稿日:02/12/15 22:35 ID:h1EngnES main/1039877473.html#646
>>644
一文字しか合ってませんよ

1094 名前:47 投稿日:02/12/16 01:28 ID:lAYtlMsV main/1039877473.html#800
少しは私の気持ちも考えてください。

1095 名前:47 投稿日:02/12/16 01:31 ID:h/rSVPDG main/1039877473.html#804
>>801
どこがバグだよw
眼鏡屋だっつってんだろ!ゴルァ!

1096 名前:47 投稿日:02/12/17 00:44 ID:64CjMqje main/1040016530.html#183
(=゚ω゚)ノぃょぅ

1097 名前:47 投稿日:02/12/18 00:39 ID:xvQCu+lr main/1040016530.html#443
β22.42です。互換性あります。ダウン周りの微調節です

・ UP過多時に切断する転送リンクを切断を回線速度と接続時間で決めるようにした
・ 多重ダウン時の転送ブロック位置調節
・ クエリバッファ限界を5にした
・ 初期フォントポイント数を9に固定

β22.4あたりから、人気の集中するファイルほど上流側に拡散しやすくしてあるわけですが、
下流側で転送リンク切断が頻発するので、安定した転送リンクほど切れにくくなるように調節しました。

あと、調子が悪くなりやすいタイミングを調べてみると、クエリが集中的に送られてきて
これで処理負荷が上がって固まり、その結果他の処理が滞って・・・というパターンが
多いようなので、一度に処理できるクエリ数を減らしてあります。
多少は動作が安定するんじゃないかと思います。


1098 名前:47 投稿日:02/12/18 21:02 ID:NCQYrqqM main/1040016530.html#738
β22.5です。互換性あります。

・ キャッシュがある場合、ファイルの先頭部をダンプ表示できるようにした

一応、捏造対策です。といっても、捏造かどうかというのは受け取ったほうが
<そのファイル名に対して捏造と思ったら捏造>という主観的なものでして
システム側で検出するのは無理です。

ただ、明らかに変なファイルというのは、ファイルのヘッダ部を見れば
気がつくことが多いので、強制変換しないでも見れるようにしておきました。

検索画面か、タスク画面右メニューから、ファイルの先頭部が見れます。
もちろん、キャッシュ内に先頭ブロックが無いと見れません。

慣れが必要ですが慣れればヘッダ見ただけで怪しいかどうか
分かることが多いと思いますので活用してください。

あと、ダウン周りなど調節中ですが今回、ダンプ部以外何も変わってません。
キャッシュ分布が変化する修正していますので、時間がたたないと状況が分かりません。
とりあえず非常に忙しいですし、こちらは気長に様子みててください。


1099 名前:47 投稿日:02/12/21 02:58 ID:3aX9eYXS main/1040233306.html#394
β22.51。互換性あり。バグ取りや微調整だけで新機能はありません。

・ Port0間のファイルやり取りにおける中継動作が行われていなかったので修正
・ UPファイルハッシュチェック時に時間と初期参照量にばらつきがでるようにした
・ リンクの切断忘れがあるのを修正
・ ダウンリスト追加時に検索ワードに','が含まれていたらスペースに置換するようにした
・ ドライブの空き容量が100Mを切ったら転送リンクを切断するようにした

ここのところ余裕がなくてここの発言にちゃんと目を通せてませんが、
覚えていた箇所や気がついた点を修正しました。

何か致命的なバグがあったらその理由を明確に主張していただければ
優先的に直しますので指摘お願いします。


1100 名前:47 投稿日:02/12/21 03:41 ID:dogggYG9 main/1040233306.html#410
Winny開発やめますた

1101 名前:47 投稿日:02/12/21 06:32 ID:FuLq+F8b main/1040233306.html#445
β99999999です。互換性あります。キーに関するパラメータ微調整及び
実験的に採用していた*.3dファイル(three-dimensional file)の共有テストの経過報告です。

・ キーバッファがCPU1.5Y(ヨタ)以下のロースペックPCで間に合わず溢れるエラーに対応、
 キー取得速度を選べるようにした
・ 検索クエリへのキーパック個数をこれまでより10%増やした
・ *.3dファイルダウン時に○リ・電影○女・つる○た等の同様の検索ワードで行われており
 同一3dファイルに大量にダウンロード要求が来ていて効率が落ちている模様

β99999998で3dファイル共有可にしたところキーがかなり増えてきているので対処しました。

とりあえず処理しきれていてネットワークが溢れていないのであれば、
保持しているキーは多い方が検索ヒット率があがるので良いのですが、
あまり自分の欲望を素直にあらわしすぎますと、遠方のキーまで要求を出しに行きますので今度は
自分の3dファイルに要求がかえってくるので、ハーレム化が破綻しやすくなります。

Winnyにおける検索は、あくまで遠方にあるノードを引き寄せてくるためのもの
(ファイルやり取りすると接続優先度が上がるのでノードが近づく)であって、
ハーレム化のことを考えると、拡散により生じるハーレム周辺ノードとのやりとりが
頻繁な方が系全体としては好ましくなります。ノードが遠方にあるまま大量にキーをやり取りしてると、
結局ダウン率が落ちてきて(転送率が増えるため)全体の効率が落ちることになります。

ということで、問題はあいまいな単語検索により生じる遠方キーの大量流入ですので、
これを避けるためにはみなさん細かい好み、いわゆるフェチというやつですが、を鮮明にして頂く必要があります。
たとえば、○リでしたらつる○たなのか僅かな○くらみなのか学生だっ○ら何でもいいのか、ということです。

これでもかなりのキーを持つ事になるとは思いますが、多少はメモリ消費状況が
良くなるんじゃないかと思います。汎用的な単語での検索ヒット率が下がりますが、
個別では上がると思います。

なお、検索に関しては途中の中継ノードによりますので、
ノードの多くが新バージョンに変わらないとその効果が見えにくいはずです。

1102 名前:47 投稿日:02/12/21 11:48 ID:dogggYG9 main/1040233306.html#468
これからのバージョンは世界の共通言語
ハングル語ニダ


1103 名前:47 投稿日:02/12/22 16:56 ID:Hj7CSWth main/1040233306.html#786
β22.51です。互換性あります。バグ取りです。

・ ネットワークエラー発生時の対策を強化
・ ネットワークエラー発生時の出力メッセージを詳しくした
・ 起動時にスレッド排他処理に失敗してクラッシュすることがあるのを修正
・ ヘッダダンプ表示がフォントの大きさに依存しないように修正
・ システム情報のフォントを小さくした

不安定になる理由を探ってみましたが、スレッドのロック関連と
ソケットのエラー処理周りで問題見つけたので直してあります。

あと、ダンプ表示のところが手抜きだったので修正しました。



1104 名前:47 投稿日:02/12/22 17:27 ID:55eo08r0 main/1040233306.html#823



   割   れ   房   必   死   だ   な   (   藁





1105 名前:47 投稿日:02/12/23 13:59 ID:DjU8XHcc main/1040570038.html#125
忙しいって言ってるだろ。


1106 名前:47 投稿日:02/12/24 00:36 ID:8mm1gqP6 main/1040570038.html#386
β22.52です。互換性はさらにあります。さらにバグ取りです。

・ ネットワークエラー発生時の対策をさらに強化
・ ネットワークエラー発生時の出力メッセージをさらに詳しくした
・ 起動時にスレッド排他処理に失敗してクラッシュすることがあるのをさらに修正
・ ヘッダダンプ表示がフォントの大きさに依存しないようにさらに修正
・ システム情報のフォントをさらに小さくした

1107 名前:47 投稿日:02/12/24 00:41 ID:mRz8JpdP main/1040570038.html#395
β22.52です。互換性あります。ダウン周りの微調整です。

・ 多重ダウン時に出来るだけキャッシュギャップが出来ないようにダウンするようにした

どういう方式にするとキャッシュ拡散効率が良いかというのはなかなか難しい問題ですが、
とりあえずキャッシュが散ってもキャッシュギャップが増えてリンク切断が目立つだけで
あまりメリットを感じられないようなので、できるだけキャッシュ先頭優先でキャッシュに
隙間が出来にくいようにしてみました。

アップ側のキャッシュのギャップ位置で転送リンクが切れるので、
転送リンクの切断は減ると思います(特に高速ノード間での転送)



1108 名前:47 投稿日:02/12/24 00:58 ID:/0grL5J5 main/1040570038.html#414
β22.53です。互換性あります。
性夜粉砕コードを搭載しました。おまいら彼女も共有汁。

1109 名前:47 投稿日:02/12/24 01:21 ID:8MWKi3RY main/1040570038.html#457
β22.6です。互換性あります。臨界事故対策です。

・ ダウンリストへの追加時にバケツが使えないようにした
・ 配管の亀裂を修復した
・ 健康診断の受け付けを開始した

数時間前からいくつかのノードで臨界が起こっていることがわかりました。
原因は一部のアニヲタがダウンリストへの追加にバケツを使用して大量に追加したことによ
るようです。

あと、液体ナトリウムを流している配管に亀裂が入っているものが数本あることが以前から
わかっていたのですが、隠蔽していました。申し訳ありません。

今回の臨界事故で健康に不安のある方は、お手数をおかけしますがクラスタワードに「健康
診断希望」と書いて待っていて下さい。ネットワークドクターを派遣いたします。

1110 名前:47 投稿日:02/12/24 02:13 ID:BVsxcLwy main/1040570038.html#519
β22.51です。互換性あります。バグ取りです。

・ ネットワークエラー発生時の対策を強化
・ ネットワークエラー発生時の出力メッセージを詳しくした
・ 起動時にスレッド排他処理に失敗してクラッシュすることがあるのを修正
・ ヘッダダンプ表示がフォントの大きさに依存しないように修正
・ システム情報のフォントを小さくした

不安定になる理由を探ってみましたが、スレッドのロック関連と
ソケットのエラー処理周りで問題見つけたので直してあります。

あと、ダンプ表示のところが手抜きだったので修正しました。


1111 名前:47 投稿日:02/12/24 12:06 ID:BVsxcLwy main/1040570038.html#623
β22.6です。互換性あります。バグ取りです。

・ うんこ

不安定になる理由を探ってみましたが、スレッドのロック関連と
ソケットのエラー処理周りで問題見つけたので直してあります。

あと、ダンプ表示のところが手抜きだったので修正しました。


1112 名前:47 投稿日:02/12/27 05:58 ID:IK0PJN4n main/1040763086.html#389
β22.53です。互換性あります。

・ パケットSend時に無駄なリンク切断が生じるので修正
・ 上方への検索リンク接続施行率を向上

リンクが切れやすいようなので修正しました。

どうも22.5→22.51の修正部らしいので調べてみましたが、
切断が増えそうな箇所はエラーチェックを強化した、パケットのsend部分
(のメッセージを出さないで強制切断している箇所)だけなので、
ここを22.5と同じにしてみました。

あと、下流ほど繋がりが悪いようなので、上方への検索リンクの接続率を上げてあります。

このsend部の修正は検索リンクや転送リンク両方で関係ありますし、
ノードの双方でsendするので、もしこれが原因だとしたら、自分も接続先のノードも
両方β22.53にならないと切れ易いのが直らないと思います。

とりあえず実験お願いします。


1113 名前:47 ◆KbtLZwerNc 投稿日:02/12/27 09:51 ID:NDSOtdna main/1040763086.html#439
年末年始はいつものことながら忙しいのであまり大改造もできないと思いますが、
暇を見つけて、前から予定はあったけど後回しになっていた
BBS周りの改造でもしようと思ってます。

現在の構想ですが、まず、今現在、BBSの匿名性が保たれているのが書き込み側だけなので、
スレッドを立てる側と読み込むほうに関しても匿名性を実現させようと思ってます。
あと、今現在WinnyBBSを使うには各自がWinnyを起動しないとだめですが、
これも解決させようと思います。

方式としては第4世代P2Pといっても良い新しいやり方になります。


1114 名前:47 ◆KbtLZwerNc 投稿日:02/12/27 09:52 ID:NDSOtdna main/1040763086.html#440
これの基本的な考え方ですが、第3世代P2Pですと集中鯖なしで匿名性を持っているわけですが、
よく考えると、このP2P網全体が仮想的なストレージを持った仮想システムと考えられますので、
これ全体を一つのサーバとみなして、これに対してクライアントが接続するという、
P2P網に対するクライアントサーバモデルという考え方が基本になります。

なんでこうなるかですが、まず、匿名BBSを読みたいだけなのに、
わざわざポート空けて専用サーバントプログラムを立ち上げてくれる人というのは
あまりいないだろうという前提がまずあります。

前から言っているように、P2P-BBSの最大の問題はピアをいかに確保するかでしょう。
で、この問題に関しては既存のファイル共有ソフトなどの他のP2Pサービスを
借りるのが一番良いでしょうと。

次に、BBS読み書きのためだけに専用システム起動は面倒という問題がありますが、
クライアントを普通のWEBベースのクラサバとすることで、読みだけなら普通のブラウザだけあればよく、
専用のプログラムを立ち上げる必要がなくなります。P2Pとクラサバの良いとこ取りになります。

もちろん、今のWinnyBBSと同じで好きなスレッドを自分で作るにはWinny本体を立ち上げて
外部にポートを開けないとだめですが、スレを立てたければWinnyを起動して
WinnyBBSノードとして協力してくださいということになります。

この、P2P全体をサーバとみなしてクラサバするというのは、
他にも使える概念でBBS以外にもいろいろ応用できると思います。


1115 名前:47 ◆KbtLZwerNc 投稿日:02/12/27 09:52 ID:NDSOtdna main/1040763086.html#441
ということで、実際にWinnyに追加予定の機能ですが、

今現在ではファイル共有のためのポート情報を各ノード間でやり取りしていませんが、
これを各ノードで情報交換するようにし、今のBBSへのインターフェイスと同じような形態で、
各ノードのBBSポートへのリンクを持つWebページを出力できるようにします。
アクセスポイント一覧がブラウザからリンクとして見えるので、
そこのどれかからWinnyBBSにアクセスすることになります。

あとの違いとしては、スレを読むときに基本的に自分のノードに直接アクセスしての
読み書きはできなくして、必ず他人のノードのBBSポートを利用して読み書きする
ようになることぐらいでしょうか?

改造としてはかなり簡単ですし、ファイル共有側への悪影響はほとんどないでしょう。

これにより、読み込みやスレッドを立てている人の匿名性が実現できますし、
BBSを読み書きするだけだったらWinny本体を起動する必要がありません
(適当にブックマーク入れておく必要はありますが)

もちろん、匿名BBS機能なんてそもそも要らないという人もいるでしょうから、
BBSポートを0に設定したらそのノードはBBSキーの中継に使われるだけになる予定です。

あと、これですとわざわざ検索リンク経由で書き込まなくてもある程度の匿名性が実現できますが、
匿名性高いほうが良いでしょうから、ここはそのままの予定です。



1116 名前:47 ◆KbtLZwerNc 投稿日:02/12/27 09:52 ID:NDSOtdna main/1040763086.html#442
他に、スレ立ての委譲だとか、キャッシングというもっと複雑なメカニズムを
BBS側に導入することも考えられますが、そもそもWinnyのBBSは
各自がhttpdを立ち上げて普通にBBSを作って、これをP2Pで共有して
大きなひとつのBBS群として見せているだけというシンプルなメカニズムでしかありません。

人間の心理として、自分の立てたスレは大切にしようとの考えが働くはずですので、
他から書き込まれたければできるだけWinny本体を落とさないようにするはずですし、
書き込み内容も積極的に管理してくれるんではないかということで、
今の方式がベストなんではないかと思います。この辺は普通のBBSと変わりません。

ですので、今と同じでスレを作ったノードが落ちてしまうとスレが消えて誰も読み書きできなく
なりますが、これは普通のBBSもそうなので、こちらではこれを問題とは考えません。

2chだと、板単位でホストがあったところが、スレがノード単位になってこれが集まって
巨大BBSに見えるというだけで、結局やっていることは同じで、より分散システムになるだけのことです。

とこんな感じで予定していますので、何か問題点とか思いついたらご意見よろしく。



1117 名前:47◇KbtLZwerNc 投稿日:02/12/27 18:44 ID:FvCSoo81 main/1040763086.html#672
あらしは放置でおねがいします。

1118 名前:47 投稿日:02/12/29 05:29 ID:JWDBgPBL main/1041081810.html#65


1119 名前:47 投稿日:02/12/30 16:57 ID:zZviz7Ow main/1041081810.html#248
Winny正式版です。β22系統と互換性があります。

・ バージョン表示関連を1.00に
・ BBSファイルのヘッダを1.0にした

バージョン関連以外のところは何も変わっていません。

まだ細かいバグとか直したほうがよいところがあるのはわかっていますが、
次あたりの変更(BBS周りを変える予定ですが)から安定バージョンと
実験バージョンで分離した方が良いかもしれないというのもあるので、
とりあえずβとっておきます。

といっても、今までどおりバージョンアップはしますのでご安心を。

プロトコルもヘッダだけ変えてしまおうかと思ったんですが、特に変える理由もないですし、
変更で困る人が出るだけなのでそのままにしときました。β22系統と繋がります。
v1.00と言ってもβ22.53と何も変わりませんが、
気分的に新しくしたい人だけバージョンアップしといてください。

とりあえず、2002/4/1に設計開始、5/6にβ1公開してから
正式版まだ8ヶ月もかかってしまいましたが、βテスタの方はお疲れ様でした。
これからも開発への協力お願いします。


1120 名前:47 投稿日:02/12/30 23:22 ID:StCq8bTs main/1041081810.html#611
本ソフトウェア使用の結果、何か問題が生じても責任はとりませんのでよろしくお願いします。
また、このソフトにより違法なファイルをやり取りしないようお願いします。

本ソフトウェア使用の結果、何か問題が生じても責任はとりませんのでよろしくお願いします。
また、このソフトにより違法なファイルをやり取りしないようお願いします。

本ソフトウェア使用の結果、何か問題が生じても責任はとりませんのでよろしくお願いします。
また、このソフトにより違法なファイルをやり取りしないようお願いします。


1121 名前:47 投稿日:03/01/01 12:13 ID:SooFkSYj main/1041081810.html#926
明けましておめでとうございます。
さっそくですがv2.0β0.1です。v1.0系統とは独立に動きます。
キャッシュに交換性はありません。

今回は今まで考えていたけれども運用に支障が出ないように入れられ
なかった機能を簡易版ながら色々実装しました。まだまだバギーな事を
了解していただけるβテスタの方に実験の協力をお願いします。

今回新しく入れた機能は
・ バナー広告を表示します
・ 1分ごとにレジストを促すポップアップウィンドウが出ます(未レジスト時)
・ 使用状況を常時中央サーバーでモニタして品質の管理をします(up0対策)
・ CPUパワーが余っているときはSETIの計算もします
・ UP回線が余っているときはACCSにDOS攻撃もします
・ アイコンを可愛くしました

それでは今年もよろしくお願いします。

1122 名前:47 投稿日:03/01/01 18:20 ID:95u0XYS2 main/1041081810.html#997
1000

1123 名前:47 投稿日:03/01/01 20:22 ID:KplrMEbe main/1041409718.html#31
v1.01です。v1.00と互換性があります。
ただし、βとの接続はカットするようになってます。

・ 多重起動時に最小化を解除できなくなっていたので修正
・ 最小化時のTipsに転送速度も表示するようにした
・ ダウン時にそのキーが無視条件にかかるかどうか再チェックするようにした
・ ダウン条件にヒットするキーに転送がかかるとキャッシュ変換されないことがあるのを修正

細かいバグ修正です。

正式版にした際に多重起動時の最小化解除が働くなっていたので直しました。

あと、自動ダウンでしかダウン条件や無視条件チェックしていなかったので、
転送でダウンが発生するとダウン条件に合うのに
キャッシュ変換されずに完全キャッシュのままだとか、
無視条件にヒットするのに転送でダウン開始されたのに無視されないで
そのままダウンしてしまうなどの問題を起こすので修正しました。


1124 名前:47 投稿日:03/01/03 11:05 ID:RzyI3SC6 main/1041409718.html#695
v1.01修正です。互換性あります。パラメータの微調節ですのでバージョンはそのままです。

・ ノードリストにあるのに接続に行かないノードが生じるのを修正
・ BBSキー送信量を少し増やした
・ 中継転送発生率を少し落とした

ノードリストにあるのに接続に行かないという現象が生じるようなので
LANで条件いろいろ変えて調べてみました。

どうも、クラスタ情報の評価が早くて、一度接続したら優先度が上がるところ、
すぐに評価されて優先度が大きくなってしまって、再接続に行くので、
いつのまにか接続に使われないノードが生じていたようです。

特に、接続の弾かれ易いPort0で起きやすかったようです。
正式版以降ノードの接続関連を変えたのですが、ろくにLANテストしてなかったので
調節が甘かったようで。ということで直しておきました。

あと細かいパラメータ修正してあります

1125 名前:47 投稿日:03/01/03 17:52 ID:B1vhunCu main/1041409718.html#722
v1.02です。v1.00以降と互換性あります。アップ周辺の微調整です。

・ 完全キャッシュキー送信の際にUP転送リンク限界かどうかチェックしていなかったので修正
・ UP転送リンク限界でも低確率でキーを流すようにした
・ UP転送リンク接続集中時のリンク切断方式を変更
・ 低速ノードで長時間経つと転送リンクが切れやすいのを修正
・ BBSキー送信率を少し上げた

下流にある被参照量が少ないファイルの拡散率が悪いようなので調節しました。

まず、特定のノードにしかファイルがない状態で、
このノードがUP転送リンク限界状態になると、
キーが流れなくなってしまうので、再調節が起きるように
UP転送リンクが限界でもまれにキーを流すようにしました。

あと、UP要求が集中した場合に、UPしているファイルの被参照量、
リンク接続時間、回線速度を考慮して動的に切断対象を選ぶようにしました。
被参照量が少ないファイルほど上流への転送が発生しやすくなります。

こちらのほうがキャッシュの拡散速度が速くなるはずです。

あと、UP転送リンク限界でも完全キャッシュキーを外部に流していたので、
キャッシュがあるほど接続要求を受けて負荷が高くなっていたはずですが、
修正しましたので多少はネットワーク周りの負荷が下がるかと思います。

UP側の変更なので効果が現れるには時間がかかると思いますが、
更新お願いします。



1126 名前:47 ◆KbtLZwerNc 投稿日:03/01/06 17:05 ID:LvOvppuB main/1041615168.html#824
せっかくの正月も風邪でダウンしてしまって予定の作業がぜんぜん進んでません。
他に溜まってる用事たくさんあるし、Winnyの方はちょっと進行が止まると思いますので
よろしくお願いします。三月になればかなり暇にまると思いますが。



1127 名前:47 投稿日:03/01/08 01:21 ID:H+OymokZ main/1041862164.html#184
v1.02.01です。v1.00以降と互換性あります。UP関連のパラメーター微調整です。

・ UPリンク限界時の転送リンク切断発生を減らした
・ UPリンク限界時のUPキーと完全キャッシュキー送信率を上げた
・ 転送発生率を落とした

風邪が酷くて頭が回らんのでたいした変更ではないのですが

まず転送リンクが切れやすいので修正しました。

転送リンクが集中したときに、今ですと、接続時間、UPしているファイルの参照量、
UP先の回線速度の三つのパラメーターを組み合わせて一番評価が低くなる接続を
カットしているので、転送リンクが他ノードに取られることがあるわけですが、
やはり途中で切れるのは効率が悪いので、接続時間の評価を大きくてして、
一度繋がれば比較的切れにくくしておきました。
先に繋がったノード優先なので、β21以前に近くなることになります。

あと、アップと完全キャッシュキー送信率が下がっているので、これらのキーが
多少見えにくくなって検索ヒット率が下がっているようですので、少し送信率を
上げておきました。検索がヒットし易くなるんじゃないかと思います。

あと、ダウン中のファイルに転送要求が生じたときも再ダウンタスク発行するように
したために、転送発生率が上がっているようですので、その分転送発生率を
下げてあります。

全部UP側の修正なので、効果が現れるには時間がかかると思いますが
バージョンアップよろしくお願いします。


1128 名前:47. 投稿日:03/01/08 01:38 ID:wE9Oibwq main/1041862164.html#207
47氏v.1.03です。今までの47氏と互換性あります。体調関連のパラメータ調整です。

・47氏の風邪を軽減
・47氏の仕事のノルマを落とした
・47氏の仕事の給料を上げておいた
・47氏の役職を上げておいた

47氏に負担がかかっていたようなので修正しました。

まず、最近の47氏の風邪により、Winnyだけでなく仕事のほうまで支障が
でそうだったので風邪を軽減しました。あと、仕事の方も忙しそうだったので
ノルマを減らしておきました。
あとの2つはおまけです。

まだ風邪は治りかけなので、効果が現れるには時間がかかると思いますが、
バージョンアップよろしくお願いします


1129 名前:47 投稿日:03/01/08 03:06 ID:Oqh/zjuB main/1041862164.html#236
付け加えですが、パラメータの調整が上手くいっていなかったようなので
もし、通信バッファが溢れたり、頻繁にノード接続が切断されるようでし
たら再起動してみてください。DL中でも再起動しないとキャッシュ変換の
時に余計な処理のせいで破損したりするので。

とりあえず調整してみます。
あと風邪はコンタックを飲んだら良くなりましたw



1130 名前:47 投稿日:03/01/08 03:34 ID:bqovGDBU main/1041862164.html#241
すみません。付け加えます。

ダウンの送信率が下がっているので、これらのキーが発生しやすくなるように
検索ヒット率上げて転送発生率を抑制してあります。それほど影響はないと
思います。

みなさんも風邪にはお気をつけください。


1131 名前:47 投稿日:03/01/09 19:45 ID:ZdD6zUmF main/1041862164.html#561
v1.02.02です。v1.00以降と互換性あります。DOWN関連のパラメーター微調整です。

たいした変更ではないのですが、バージョンアップよろしくお願いします。

DOWNリンク限界時の転送リンク切断発生を減らして、キャッシュの流れをよくする
ように調整しました。あと、転送発生率が安定しているようですので、その分転送発
生率をフラットな状態にしてあります。




1132 名前:47氏へ 投稿日:03/01/09 22:21 ID:kG2oWFmZ main/1041862164.html#600
BBS機能の改良おねがいします。
エラー多すぎです。

1133 名前:47 投稿日:03/01/10 18:27 ID:XDmOStgi main/1041862164.html#734
v1.02.02です。v1.00以降と互換性あります。細かい変更だけです。

・ 転送時の接続時間の評価を小さくした
・ UPキーと完全キャッシュキー送信率を少し下げた

転送リンクが他ノードに取られるので接続時間の評価を小さくしノードが
一箇所に集中しないようにしました。これにより途中でノードが切れることが
あるかもしれませんが、その分キー保持限界を3万にしてありますので
それほど影響はないと思います。

あと、検索ヒット率が安定してきたようなのでアップと完全キャッシュキー送信率
の値をv1.02.01より少し下げておきました。アップと完全キャッシュキー送信率の
値はまだ修正の余地がありますので、今後のバージョンアップでまた値を変える
ことになると思います。

大きな変更点はありませんがバージョンアップよろしくお願いします。




1134 名前:47 投稿日:03/01/11 00:28 ID:3J176Eax main/1041862164.html#801
v1.02.02です。v1.00以降と互換性あります。
身元を探られない為にハッシュのみ晒します。変更内容は同梱したドキュメントを参照して下さい。

Winny10202.zip 257,812 f5def31a9544a3a8f547e8a68a73ee03

1135 名前:47 投稿日:03/01/11 08:29 ID:VT8vQlYy main/1041862164.html#873
>872
%ハッシュで検索できます。

1136 名前:47 投稿日:03/01/12 14:13 ID:I694usS5 main/1042281073.html#134
v1.03です。v1.00以降と互換性あります。

風邪でせっかくの正月休みが潰れてしまいましたが、どうにか良くなりました。
ということで、前から予定に入っていたBBS関連の修正です。

ただし、現プロトコル内でどうにかなる範囲での修正ですので、
本格的な修正はまた後になります。
(実はプロトコル変わってますが互換取るようにしてあります)

・ BBSの匿名性強化
・ BBS読み込み時に異常終了することがあるのを修正
・ BBSのエラー処理強化
・ 多重投稿チェック追加
・ 検索結果にも無視条件を反映可能にした(無視条件の「検索にも反映」ボタン)
・ 自動タブ切り替えをカットできるようにした(システム情報の「自動タブ切替」ボタン)

今回の修正で、読み込みに関してスレ立てノード直接ではなく、
間接的に行うようにしましたので、書き込みだけでなくて、
スレ立てと読み込みに関してもある程度の匿名性が実現できます。

ただしスレ立てと読み込みの匿名性に関してはまだ完全じゃない
(読み込み時に直接接続に行く可能性が高い)です。
これに関しては、後でBBSポート経由するようにしてまた強化する予定です。


1137 名前:47 投稿日:03/01/12 14:13 ID:I694usS5 main/1042281073.html#135
今回の具体的な修正内容ですが、スレの完全キャッシュを保持している場合、
キーのIPを自IPに書き換えて流すようになってます。ですので、
スレを立てたノード以外に、BBSを読んだことのあるノードに対しても
BBSリードに行くことになります。なお、書き込み側は今までと同じです。

もし書き込みがあってスレに変更が生じると、このキー拡散と共に
完読書スレッドが順に書可スレッドとなり、
書可スレッドキーはただ単にスルーされるだけとなります。

このようなメカニズムなので、BBS読み書き共に特に成功率が落ちることなく、
匿名性だけ上がります。欠点としては、クラスタが離れていると、
新しい書き込みに気がつくのに時間がかかることです
(最悪1時間ぐらいかかる可能性もある)

これに対応するために、今回多重投稿チェック増やしてあります。
スレ立て側で同じ書き込みが続くと投稿失敗として通達します。

なお、BBS変更だけだとバージョンアップしてもらえなさそうなので
おまけで、タブ切り替えのカット選択追加と、
検索の方にも無視条件反映機能も追加してあります。
無視リストタブの「検索にも反映」ボタンにチェック入れると
無視条件にかかるキーが検索画面でも表示されなくなります。

ただしこれはこれで問題がありまして、これのチェック処理回数は
ヒットキー数x無視条件数になるので、検索にヒットするキーが多く、
なおかつ無視条件が多い場合に、処理負荷が非常に高くなります。
(自動ダウン部でも実は同じ問題があります)
このような場合はOFFにしてください。標準ではOFFになってます。


1138 名前:47 投稿日:03/01/12 15:39 ID:yKKB3XU+ main/1042281073.html#220
表示の検索結果キャッシング処理しているの忘れてました。
ということでv1.03.01です。無視条件ありの検索結果表示を直しました。

しかしこれだけ検索処理かけてると、無視条件有効での検索表示は遅そう・・・

あと、1.03からBBSキャッシュは消えなくなってますので、
これを消す場合はBBSタブのキャッシュ消去で消してください。

ただのごみキャッシュはちゃんと消えてるはずです。


1139 名前:47 投稿日:03/01/13 20:12 ID:CSSMUP4v main/1042281073.html#613
代わりに

1140 名前:47 投稿日:03/01/13 20:13 ID:25HKT7D3 main/1042281073.html#614
v1.04です。v1.00以降と互換性があります。BBSの無視機能周りの強化です。

・ 掲示板の右メニュー追加
・ BBSキーでの削除やノード切断処理で、キーIPが一致するキーをまとめて処理するようにした
・ BBS一覧のHTML出力時にも無視リストを評価するようにした
・ アップリンク集中切断時のノード速度の評価値を小さくした

BBSの無視機能周りが弱かったので強化しときました。

まず、BBSタブでも右メニュー使えるようになってます。

あと、BBSキーの削除やノード切断条件指示の際に、
条件にヒットしたキーとIPが一致する他のBBSキーも
まとめて処理するようにしました。

BBSキーは特殊で、誰も読んでないようなBBSキーは同じノードから
放出されたかどうかをほぼ特定できますので、これを利用して、
同じ出所のキーをまとめて消したり無視ノード指示できます。

ただし、人気があってよく参照されているBBSキーはこの処理対象外になります。

あと、キーロストが多いようなので、もう少し接続時間優先にしておきました。
UP側のパラメーターなので影響が見えるようには時間がかかるとは思いますが
バージョンアップしておいてください。キーロストが減ると思います。



1141 名前:47 投稿日:03/01/13 21:11 ID:SOI3F0F3 main/1042281073.html#672
>>669
ttp://tmp.2chan.net/guro-gazou/src/1042449064251.jpg

1142 名前:47 投稿日:03/01/13 21:22 ID:CyEAa1Lh main/1042281073.html#681
あー、また見落としが。ということでv1.04.01です。

書けないけどキャッシュに存在するBBSキーに無視条件がヒットすると、
書けないキー全部とアップキーも巻き込まれるようです。

ということで直しときましたのですいませんが取り替えといてください。

あと要望が多いようなのでフォルダ追加の
トリップデフォルトを空にしときました。
これはトリップ機能が広まるまでの暫定でしたし。


1143 名前:47 投稿日:03/01/14 21:17 ID:Jd18DXwz main/1042473699.html#515
v1.05です。v1.03以降と互換性があります。話題になっている箇所周辺の変更です。

・ 名前とトリップの上書き抑制(空トリップだと名前の上書きされなくした)
・ ハッシュ直接指定で無視指定されているキーを周辺ノードに通知するようにした
(周辺ノードで無視条件に入れられているキーが黄色く表示される)

今回プロトコル変わってますが、相手のバージョンを見て
プロトコルを動的に変えているのでv1.03以降とは問題なく繋がります。

今回の変更点ですが、同一ハッシュに複数の名前やトリップがある場合、
空トリップの方を名前も含めて上書きしないようにしました。

ただ、複数のノードで別のトリップを付けていると、今まで同様やはり競合します。
この場合、十分広まっているトリップありキャッシュ情報が選択されます。

話が出ている評価値のメカニズムなど面白いとは思いますが、現状で
キャッシュヘッダにそういう機構を入れる余裕がありませんし、バグや
匿名性の点などで別の問題を起こしそうなので、
とりあえずユーザーさん各自で工夫ということでお願いします。

ファイルを共有フォルダに入れる際には、
「名前を上書きされたくないときだけトリップつける」のが基本方針となります。

トリップ重複に関しては今までまじめに動作テストしたことがなくて、
空トリップでも名前上書きすることがあったという
一種のバグ持ち状態でしたのでとりあえず様子見。

わざわざファイル乗っ取ってトリップ変えようとする人はあまり
いないはずですので、この程度の対応でどうにかなると思います。


1144 名前:47 投稿日:03/01/14 21:18 ID:Jd18DXwz main/1042473699.html#516
あと新機能として、ハッシュ直指定で無視条件入れると、それがキーに
マークされて周辺ノードに情報が広まるようにしてみました。
キャッシュでなくて仮想キー含めたキーに無視マーク入れますので、
キャッシュ本体が削除されてしまっていても、
無視条件にあれば周辺にその情報が広まります。

といっても、マークされていても自動ダウンその他には何も影響を与えません。
「周辺で無視条件入れられているキーは検索画面でキーの名前が黄色表示」
されるだけです。

この辺、キーの評価に関わる話なわけですが、そもそもこちらとしては、
キーの評価値として参照量を仮定しています。もちろん、この値は
そのファイルのダウン率は表しますが、ダウン後の評価は入ってません。

ここで、ダウン後のそのファイルの評価が悪い場合、そのキーは無視リストに
入れられる可能性が高いはず。ということは、無視リストに入れられたキーの
参照量が減少していけば、キーの参照量が実際の評価値に近づくはずです。

もちろん、本当に減らすことできませんが(いたずらする人がいますし)
ただ、キーに警告が出ていれば、多少はそのキーを怪しんで、調べてみて
結果、そのキーの参照量が上がりにくくなるだろうという想定です。
無視警告出ているキーでも、ヘッダやBBSその他で調べて問題ないと判断されれば
結局ダウンされて参照量が上がるはず。

まぁ、人気があるファイルは結局全部黄色くなって無意味になるかとも思いますが
それはそれで面白いですし、とりあえず試しということでお願いします。
周辺で注目されているファイルはとりあえずわかる様になると思います。



1145 名前:47 投稿日:03/01/15 01:17 ID:sSA15jlX main/1042473699.html#790
ところで1.04より1.05のがファイル落ちますか?ルータ入れてるADSLな人など
からも落とせるようになったはずなんでダウン率がかなり変わるはずですけど。

1146 名前:47 投稿日:03/01/15 17:12 ID:0wdVNgx6 main/1042584175.html#332
v1.05.02です。v1.03以降と互換性があります。

・完全キャッシュキー送信率を徹底的に下げた
・転送リンク切断時の基準で接続時間の評価を徹底的に下げた

バージョンアップの度に「切れやすくなった」「繋がらなくなった」という報告があまりに多く、ちょっとカチンときたので、本当に切れやすく、繋がりにくくしてみました。

1147 名前:47 投稿日:03/01/15 17:52 ID:0wdVNgx6 main/1042584175.html#358
v1.05.02です。v1.03以降と互換性があります。

・完全キャッシュキー送信率を徹底的に下げた
・転送リンク切断時の基準で接続時間の評価を徹底的に下げた

バージョンアップの度に「切れやすくなった」「繋がらなくなった」という報告があまりに多く、ちょっとカチンときたので、本当に切れやすく、繋がりにくくしてみました。

1148 名前:47 投稿日:03/01/15 19:34 ID:29ilUAwW main/1042584175.html#431
v1.05.01です。v1.03以降と互換性あります。

・ ハッシュ指定+無視条件+ノード切断指定でキーが黄色くなるようにした

ちゃんと警告通知動作しているようですが、やはり無視条件だけですと
無意味に警告が出過ぎるようですので、ノード切断と組み合わさったときだけ
警告を出すように変更しました。

ハッシュ指定してノード切断入れている人は少ないと思いますので、
わざと警告出したい人の情報だけになるかと思います。


1149 名前:47 投稿日:03/01/15 19:38 ID:PF/V6vDK main/1042584175.html#439
はい?

1150 名前:47 投稿日:03/01/15 21:11 ID:BQIdW9Cf main/1042584175.html#535
v1.05.02です。v1.03以降と互換性があります。

・多言語化を実装しました。(日本語、朝鮮語、英語の切り替えが可能)

また朝鮮語についてですが、日本に住んでいる北朝鮮の工作員の方に
翻訳を依頼したので、ほぼ完璧かと思います。


1151 名前:47 投稿日:03/01/15 21:48 ID:I2D65HdK main/1042584175.html#573
v1.05.02です。v1.03以降と互換性があります。

・ 捏造警報を参照量の方に表示するようにした
・ 自動ダウンダイアログの無視指定のところを少しわかりやすくした
・ ダウンリストタブの右メニューにも先頭ブロック表示機能追加

色弱の方のことは考えとらんでした。ということでI/F、少し変えときました。
バージョンアップが頻繁ですいませんが、違いはI/F周りだけなので
気になる方は変えといてください。

1152 名前:47ゲッター 投稿日:03/01/15 22:43 ID:KIiENdMv main/1042584175.html#692
47氏↓

1153 名前:47 投稿日:03/01/16 06:37 ID:seWpD6rk main/1042658313.html#66
v1.06です。v1.05以降と互換性あります。UP関連のパラメーター微調整です。

・ UPリンク限界時の転送リンク切断発生を減らした
・ UPリンク限界時のUPキーと完全キャッシュキー送信率を上げた
・ 転送発生率を落とした

風邪が酷くて頭が回らんのでたいした変更ではないのですが

まず転送リンクが切れやすいので修正しました。

転送リンクが集中したときに、今ですと、接続時間、UPしているファイルの参照量、
UP先の回線速度の三つのパラメーターを組み合わせて一番評価が低くなる接続を
カットしているので、転送リンクが他ノードに取られることがあるわけですが、
やはり途中で切れるのは効率が悪いので、接続時間の評価を大きくてして、
一度繋がれば比較的切れにくくしておきました。
先に繋がったノード優先なので、β21以前に近くなることになります。

あと、アップと完全キャッシュキー送信率が下がっているので、これらのキーが
多少見えにくくなって検索ヒット率が下がっているようですので、少し送信率を
上げておきました。検索がヒットし易くなるんじゃないかと思います。

あと、ダウン中のファイルに転送要求が生じたときも再ダウンタスク発行するように
したために、転送発生率が上がっているようですので、その分転送発生率を
下げてあります。

全部UP側の修正なので、効果が現れるには時間がかかると思いますが
バージョンアップよろしくお願いします。

1154 名前:47 投稿日:03/01/16 06:55 ID:ZdGghwNK main/1042658313.html#83
ウィニーはシェアウェアになります

↓URL変更
ttp://winnyhakorekara.100endesu/

1155 名前:47=58=89=99=105=以下略 投稿日:03/01/16 08:15 ID:XEekOQyx main/1042658313.html#126
多重人格に翻弄されてへろへろの頭ですけど、とりあえずここんとこだけ。

>>120
>  ハッシュ指定のものは、検索画面に移動して、検索ワードを入力し、
>  表示された一覧の中からそのハッシュをもつものを選択して、
>  無視リストに追加(条件指定してダウンリストに追加ですけど)
>  しなくてはいけません。
>  もしダウンリストから直接無視できるなら、この手間が省けるので
>  ありがたいかなと。
ダウンリストから直接無視できます。
右クリ→編集→無視条件のところをチェックで
あら不思議!無視リストに移動してます。


1156 名前:47 投稿日:03/01/16 18:12 ID:seWpD6rk main/1042658313.html#344
>>343
なぜわかったんだ?

1157 名前:47 投稿日:03/01/16 23:08 ID:0I1v6GDj main/1042658313.html#637
v1.05.03です。v1.03以降と互換性があります。

・ ハッシュ指定のダウンリストで捏造警報をクリアするようにした
・ ダウンリストタブの先頭ブロック表示で対応タスクが無くても表示できるようにした
・ ダウンリストやタスク状況からキーを無視条件追加できるようにした

1.05が減っているのにほとんどのキーに警告が付いているということは、
警告が一度付くとなかなか消えていないということですので、
逆に警告を消す機構を付けました。
ハッシュ指定のダウン条件があるとそのキーの警報が消えます。

あと、先頭ブロック表示で、対応タスクが無いときに表示できていません
でしたので、名前が出ているキーの方をチェックしに行くように修正しました。
同様にダウン条件追加もできるようにしてあります。


1158 名前:47 投稿日:03/01/20 14:42 ID:fZUxPWVK main/1042961974.html#334
v1.05.04です。v1.03以降との互換性があります。

・ コネクション限界が出る条件をUPコネクション限界切断-1にした
・ キーの捏造警告で、警告無しキーが送られてきたら警告を切るようにした

ここのところ忙しいので要望を見切れてなくて申し訳ないですが、
気が付いた箇所を直しました。

まず、転送リンク接続後に直ぐキーロストで切れるのが目立つことですが、
これは、現在UPリンク限界で切れる条件が転送限界と同じ(昔は+1だった)なのに、
コネクション限界を出す箇所の判定も転送限界と同じままなので、
接続要求が多い場合に、一時的にコネクション限界チェックにかからずに繋がるけど、
UPリンク数が多すぎてすぐ切れるという動作になっていると思われます。

本来、コネクション限界で切れるところ、タイミングの問題で
一時的に繋がった後に、直ぐ切れてキーロストに見えるということです。
ということで、コネクション限界が出る条件を厳しくしておきました。

あと、捏造警告がもう少し減るようにしておきました。
今までですと警告無しのキーが送られてきても無視していたため、
誰か一人でも警告入れるとそれが拡散していましたが、今回、警告有りキーと
同じハッシュの警告無しキーが送られてきたら警告を消すようにしました。
これにより、周りの平均を取る動作に近くなりますので、警告出している人が
ある程度多くないと警告が広まらなくなります。

どちらも周りがバージョンアップしないと変化がわかり難い修正ですが、
換えておいてください。後は何も変わってません。

1159 名前:47 投稿日:03/01/20 21:34 ID:BCJOU6ME main/1042961974.html#716
うるせー馬鹿

1160 名前:47 投稿日:03/01/20 23:20 ID:P//eS6YM main/1042961974.html#799
あー、もう開発ヤメ!
どっかのスレのUP0とやらのパッチ検証の為に当てたらソーストンだ
やる気失せた

んじゃ、ま現状のままでとりあえずは問題無いやろうからしばし休憩ってことで



1161 名前:47 投稿日:03/01/20 23:21 ID:BLwu502y main/1042961974.html#800
>>799
少しまちなー。

1162 名前:47 投稿日:03/01/20 23:23 ID:0Y5BQCuu main/1042961974.html#801
ちょっと待ったー。

1163 名前:47 投稿日:03/01/20 23:24 ID:0Y5BQCuu main/1042961974.html#804
ごめんなさい。

1164 名前:47 投稿日:03/01/20 23:25 ID:nJXvx/3F main/1042961974.html#805
ちょほいと待ちなー

1165 名前:47 投稿日:03/01/20 23:26 ID:BLwu502y main/1042961974.html#806
今週末リリースのv1.06で
BBSが大変なことになります。

1166 名前:47 投稿日:03/01/23 00:32 ID:p+6xo8uR main/1043123277.html#419
v1.06です。v1.03以降と互換性があります。主にダウン時エラー処理周りの修正です。

・ ダウン試行の統計情報をシステム情報に表示するようにした
・ 接続数限界で転送リンクが切れているのにキーロストと表示することがあったのを修正
・ アップ転送リンク切断の遊びを一つ大きくした(キーロストを減らすため)
・ ダウン優先度設定によっては同じキーを繰り返しダウンに行くのを修正
・ ダウン終了時のダウン条件自動クリアで消えないことがあるのを修正
・ プログラム本体を実行時に動的に展開するようにした

キーロストが頻繁に発生していますがこんなに多いわけないので調べてみました。
結果、ダウン限界で切れているのに、先にリンク切断を検出してキーロストと
出ているのがわかったので修正しました。

あと、上の調査目的でダウン状況に関して統計取るようにしたのですが、
ユーザーさん側でもダウン状況を調べるのに使えそうなので残しておきました。
ダウン状況は落としているものにもよりますので、ダウンにいった
平均ファイルサイズと参照量も統計取るようにしてあります。

あと、こちらでこの統計情報など見ていて気が付いた箇所を修正してあります。
アップ側とダウン側共に1.06になることで、エラーの出る率が減ると思います。


1167 名前:47 投稿日:03/01/24 14:10 ID:DooAjf0O main/1043383595.html#15
おつかれー

1168 名前:47 投稿日:03/01/24 18:54 ID:SZWO0Zx3 main/1043383595.html#75
男以外は不可。

1169 名前:47 投稿日:03/01/25 08:53 ID:3+8onkTE main/1043383595.html#193
v1.06.01です。v1.06以降と互換性があります。主にパフォーマンス向上です。

・ ダウンロード・アップロードタスクで無駄な処理待ちが生じるのを修正
・ 同じノードの同じキーに連続でダウン要求を出さないようにした
・ ダウンリストでヒット対象が多い場合処理を省略するようにした
・ NAT環境で立てられたBBSキーに書き込めないことがあるバグを修正
・ ダウンリスト自動削除でリスト削除時に再読み込みをかけるようにした
・ 履歴クリアボタンを検索履歴再読み込みにしてダイアログでクリアするか選ぶようにした
・ ダウン統計からBBSキーを除くようにした

β初期のころに入れた、ダウンやアップ周辺での無駄なタスク待ちが
そのままだったので除きました。ダウン速度などの処理が早くなると思います。

ただ、ルータなどにかかる負荷が高くなる可能性ありますので、
逆にダウン率が悪くなるようでしたら高速試行をOFFにしてください。

この状況で同じノードに連続ダウンかけると相手をダウンさせる
可能性があるので、これもできるだけ避けるようにしてあります。

あと、気が付いた細かい部分を修正してあります。


1170 名前:47 投稿日:03/01/25 14:59 ID:7VJqnhlB main/1043383595.html#435
>>429
おれVMware、あんま好きちゃうねん。

1171 名前:47 投稿日:03/01/25 15:02 ID:7VJqnhlB main/1043383595.html#439
>>436
お前せっかくおれが書いたったのに>>193読んだんかボケェ!!頃すぞ!!

1172 名前:47 投稿日:03/01/25 15:07 ID:7VJqnhlB main/1043383595.html#445
>>438
朝といい今のそれといい笑われへんねん。頭沸いてんのか。

1173 名前:47 投稿日:03/01/25 15:14 ID:7VJqnhlB main/1043383595.html#454
>>451
当たり前やろ。誰やと思とんねん

1174 名前:47 投稿日:03/01/25 15:17 ID:7VJqnhlB main/1043383595.html#456
>>455
偽に決まってるやろ
やっぱり頭沸いてるな

1175 名前:47 投稿日:03/01/25 15:25 ID:7VJqnhlB main/1043383595.html#473
>>468
しばくぞお前
前スレ419読んで来い

1176 名前:47 投稿日:03/01/25 18:52 ID:x5y+fLfb main/1043383595.html#672
v1.06.02です。v1.06以降と互換性があります。メモリ確保周りの修正です。

・ キー削除速度が遅くなっていたので修正
・ キー保持ブロック情報を省略することでメモリ使用量を減らした
・ ダウン開始直後にキーロストがおきると、プログラムが落ちることがあったのを修正
・ ダウンタスクID生成を必ずユニークになるようにした

前のバージョンでキー削除周り変えたの忘れてました。
ということで、キー削除がゆっくりすぎるのを修正しました。

あと、ちょうど良い機会なのでどこでメモリを消費しているのか調べてみましたが、
一番メモリを消費しているのはキーのブロック状態保持部でしたので、
最後のブロックより後ろはメモリを確保しないようにして
できるだけメモリ消費を抑えるようにしました。
それなりに動作が軽快になると思います。

あと、どうもウェイトを外すとダウン結果が変になりやすいようなので調べてみましたが、
タスクスイッチングが頻繁になると、本来とは違うタスクが
ファイル内容を受け取ってしまうことがあるらしく、
この辺かなり怪しい設計になっていたので、確実な方式に変更しました。

キャッシュ破損状況の確認は時間がかかると思いますが、気長にお待ちください。
まれに生じていた不正ブロック位置エラーなどもこれが理由だと思います。


1177 名前:47.5 投稿日:03/01/25 20:34 ID:rJHE5Jm8 main/1043383595.html#836
47.5だけど、みんななかなか最新版にアップグレードしてくれないね。
こっまたなあ。

パンツパンツレボリューション完成まで、あと13MBなんだけどなー
全然つながらんよ。

1178 名前:47 投稿日:03/01/25 23:40 ID:yaSz+QB3 main/1043500639.html#185
バグ取れたんでちょっとまってねー
今、動作確認中

1179 名前:47 投稿日:03/01/26 00:02 ID:NiJVKLo8 main/1043500639.html#237
修正が頻繁ですいませんがv1.06.03です。v1.06以降と互換性があります。

・ ダウンタスク失敗時にダウン中のキャッシュの一部分を壊すバグを修正

どうもv1.05では問題ないので変更点を全部再チェックしてみましたが、
v1.06のダウン失敗時の変更に問題があって、ダウン中のキャッシュの一部が
壊れるという致命的なバグがありました。

これのせいで、一気にダウンした場合は問題ありませんが、
多重ダウンでまず間違いなくキャッシュ破損していたはずです。

ということで直しましたので修正お願いします。
多重ダウンの挙動が正常になります。

ダウン側のトラブルだったので直ぐに違いがわかると思います。
なお、前落とした部分での破損はどうしようもないので
申し訳ありませんがダウンし直してください。よろしくお願いします。


1180 名前:47 投稿日:03/01/26 01:12 ID:zN2Y9NR2 main/1043500639.html#416

それよりWinOZまだぁ?


1181 名前:47 投稿日:03/01/26 01:38 ID:Xlid71xb main/1043500639.html#446
キャッシュが壊された時は、レジュームすれば大丈夫ですかな?

1182 名前:47 投稿日:03/01/26 11:48 ID:179mTUii main/1043500639.html#705
v1.06.04です。v1.06以降と互換性があります。

・ ダウン条件自動削除時に落ちることがあるのを修正

すいません、単純にテスト不足でした。

最近のWinnyの修正は簡単なものばかりなので、
開発にはほとんど時間がかからないので忙しくてもどうにかなってますが、
問題は動作テストでして、本来、時間をかけていろいろ試さないといけません。

ですが、本職以外に仕事を複数抱えていて土日も仕事なため
最近はテストにあまり時間を割けません。といっても、
鯖無しP2Pアプリなため問題を放置するわけにも行きませんし、
どうしても動作テスト不足気味のまま公開となります。

すいませんが、ユーザーさんの方でも動作テストの方、協力お願いします。
問題の出る条件さえ特定できれば簡単に直せますので、
いろいろ条件を変えて使ってみてください。



1183 名前:47 投稿日:03/01/27 22:19 ID:gszv/2mV main/1043500687.html#717
47です。
新バージョンが出来たわけではないですが、なんかいろいろ言われてるようですので、
出てきました。
UKiOdRVbさんの言う事は、大体あってます。
皆さんの意見は、まったくとはいいませんが、ほとんど参考にしていないのが実情です。
UKiOdRVbさんがすでに述べたとおり、いまここで議論されている事は私もすでに考えました。
ですので皆さんはエラー報告を重点的にお願いいたします。

今日深夜か、明日にはVer.1.07をアップできそうです。
今回はおもにパフォーマンスの向上です。
詳細は、アップ時に報告します。
でわ。

1184 名前:47(本物) 投稿日:03/01/28 00:46 ID:xzlUZvot main/1043500687.html#795
47(本物)だけど、いい加減にしてください。
私ばっかり開発で苦労して、皆さんは私の悪口をはじめ、あることないこと言いたい放題なんですね。

私だって人間です。もう、開発は続けません。
Ver.1.06.04で開発は終了です。

ちなみに、Winnyにはスパイウェアが入っていますので、あなた方の個人情報はぎっしりあります。
これと、2ちゃんのログなどをKやACCSに提出しようと思います。

逮捕されたくない人は、私に500万円払いなさい。
最後に、いいことをお教えします。

47=48=ひろゆき

以上。今月いっぱいで2ちゃんねるは閉鎖いたします。
永らくのご利用、ありがとうございました。

1185 名前:47(偽物) 投稿日:03/01/28 01:00 ID:aevJXcoX main/1043500687.html#803
>795
くだらん。

1186 名前:47 投稿日:03/01/28 20:49 ID:60BWm7Hl main/1043717713.html#163
((;゚Д゚)ガクガクブルブル

1187 名前:47 投稿日:03/01/29 00:08 ID:4h1G07/i main/1043717713.html#231
v1.06.05です。v1.06以降と互換性があります。

・ データ受信直後にもブロックのハッシュチェックするようにした
・ ノード情報でbusyと出さないようにした

今まででも送信側はブロック送信時にハッシュチェックしていましたので、
キャッシュが壊れていても他に壊れたデータを送ることが無かったはずですが、
受信側は受信データをとりあえずそのままディスクに保存しておいて、
全部受信が終わってから変換時にチェックしていました。
理由は処理負荷のためです。

ただ、今現在ではこのチェック処理は他の処理(自動ダウンや無視処理、クエリ処理)
に比べればはるかに軽い処理なので、多くの場合無駄であっても
念のためダウン直後で処理入れても問題にならないだろうということで、
受信直後もブロックハッシュチェックするようにしました。

ここで破損が出るということは、通信経路のどこかでエラーが生じたか、
送信側のプログラムが変だということになります。

これにより、変換時にキャッシュ破損が生じる率がかなり下がるはずです。
もしキャッシュ変換中にブロック破損エラーが頻繁に出るとしたら、
受信時は正しかったのに変換時に壊れているということなので、HDDが怪しいです。

なお、全体ハッシュエラー(ブロック単位では合ってるけど全体のハッシュが合わない)
の発生率は変化ないはずです。


1188 名前:47 ◆KbtLZwerNc 投稿日:03/01/29 23:10 ID:Z+8vD1Tw main/1043717713.html#572

最近忙しいのでWinnyだけ相手してられないし、
Webでの公開無しでも広まるものかどうかというのも
面白いので実験的にジオでの公開やめてみます。

バージョンアップしたらWinnyの方に流すと思いますので
気長にお待ちください。

通知はこちらですると思います。


1189 名前:47 投稿日:03/01/30 01:10 ID:ci/UbYWz main/1043717713.html#832
te

1190 名前:47 投稿日:03/01/30 01:47 ID:ci/UbYWz main/1043717713.html#875
開発中止!

1191 名前:47 投稿日:03/02/01 15:16 ID:9QYnt1o8 main/1044011182.html#338
今後、最新版の発表はこのようなかたちで行います。

v1.07です。v1.06以降と互換性があります。
ファイル名 Winny 1.07.zip
ファイルサイズ 887,217
ハッシュ 59d4821df7282029f88f09a6590c4ae1
変更点 ・データ受信直後にもブロックのハッシュチェックするようにした
    ・ ノード情報でbusyと出さないようにした
    ・ダウン条件自動削除時に落ちることがあるのを修正
    ・1.06〜1.06.05で多重ダウン時にキャッシュが破損するバグ、を修正。
    ・Winny本体の配布形態が、特定のサーバーによらなくなり、Winny自体で
     配布するようにしたために、あまりサイズを意識する必要がなくなったので
     インストール時の自己解凍を中止。そのため、若干サイズが大きくなっていますが
     DLに問題はないはずです。

今まででも送信側はブロック送信時にハッシュチェックしていましたので、
キャッシュが壊れていても他に壊れたデータを送ることが無かったはずですが、
受信側は受信データをとりあえずそのままディスクに保存しておいて、
全部受信が終わってから変換時にチェックしていました。
理由は処理負荷のためです。

ただ、今現在ではこのチェック処理は他の処理(自動ダウンや無視処理、クエリ処理)
に比べればはるかに軽い処理なので、多くの場合無駄であっても
念のためダウン直後で処理入れても問題にならないだろうということで、
受信直後もブロックハッシュチェックするようにしました。

ここで破損が出るということは、通信経路のどこかでエラーが生じたか、
送信側のプログラムが変だということになります。

1192 名前:47 投稿日:03/02/01 18:15 ID:x1D66zi9 main/1044011182.html#457
テストの目的でここに告知しないで、Winnyで最新版を配布してみました。
が、どのノードもバージョンアップされないようですので告知に来ました。

v1.07.01です(v1.07はなぜか出回っているので、01をつけました)
ファイル名 Winny 1.07.01.zip
ファイルサイズ 459,658 Byte
ハッシュ 25708e3272dc437abfda82ac47b9cafb

変更点 起動されればわかりますが、外観を大きく変更。
    その他の変更点もありますが、今回から変更点に関しては同梱されている
    「読んでください」にまとめておきます。

1193 名前:47◇KbtLZwerNc 投稿日:03/02/01 18:23 ID:x1D66zi9 main/1044011182.html#466
テストの目的でここに告知しないで、Winnyで最新版を配布してみました。
が、どのノードもバージョンアップされないようですので告知に来ました。

v1.07.01です(v1.07はなぜか出回っているので、01をつけました)
ファイル名 Winny 1.07.01.zip
ファイルサイズ 459,658 Byte
ハッシュ 25708e3272dc437abfda82ac47b9cafb

変更点 起動されればわかりますが、外観を大きく変更。
    その他の変更点もありますが、今回から変更点に関しては同梱されている
    「読んでください」にまとめておきます。

1194 名前:47 ◆kbttxvfPnc 投稿日:03/02/01 19:34 ID:UuUMivD5 main/1044011182.html#517
(・∀・)

1195 名前:47■KbtLZwerNc 投稿日:03/02/01 22:29 ID:A4OP7WlL main/1044011182.html#653
テストの目的でここに告知しないで、Winnyで最新版を配布してみました。
が、どのノードもバージョンアップされないようですので告知に来ました。

v1.07.01です(v1.07はなぜか出回っているので、01をつけました)
ファイル名 Winny10701.zip
ファイルサイズ 381,563 Byte
ハッシュ e8ca9589c88f148d963adf670f6dfc2e

変更点 起動されればわかりますが、外観を大きく変更。
    その他の変更点もありますが、今回から変更点に関しては同梱されている
    「読んでください」にまとめておきます。

    ちなみに、今後は告知の際、トリップはつけません。個人が特定されやすくなる
    ためです。発言の真偽がわからない、という方もいらっしゃると思いますが、
    多少は自分でも調べてほしいというのが本音です。

1196 名前:47■KbtLZwerNc 投稿日:03/02/01 22:40 ID:A4OP7WlL main/1044011182.html#668
>>661
   ナイス!!

1197 名前:47 投稿日:03/02/02 00:45 ID:qYT6+e79 main/1044011182.html#766
Winny最終バージョンです。
今回でバージョンアップは最後になります。

自分だけ大変な思いをして、
みなさんは大変な思いをしていないのはフェアでないので、
今回はみなさんに試練を与えることにしました。

スクリーンショットを見ていただければわかると思いますが、
三つの謎のボタンを付けました。

一つのボタンを押すと、ポート0でも転送リンクが大量に増えます。
スクリーンショットはそのボタンを押した後の状態です。

二つ目のボタンを押すと、HDDの情報を全てゴミ情報で上書きして消去します。
いわゆるHDD全消去ウイルスと同じ動作をします。

最後のボタンを押すと、ISPやACCSや警視庁などへ、
貴方のホスト名と一緒にDOWNしたファイル情報などを送信します。
Winnyを使って違法なファイル共有していた場合は100%逮捕されます。
違法な行為をしていない方には心配ありません。

また、謎のボタンの機能はランダムに作成しており、どれがどのボタンかは人それぞれです。
ですからボタンに書かれている記号なども全く関係ないフェイクです。
今までのWinnyにないスリルを味わって下さい。

今までありがとうございました。

スクリーンショット
ttp://winny.info/fileboard/files/img20030202002911.jpg

1198 名前:47 ◆KbtLZwerNc 投稿日:03/02/02 19:49 ID:MtDmceYK main/1044159846.html#127
v1.06.06です。v1.06以降と互換性があります。

Winny10606.zip 225,927 2063a393a965ebc63cfeafee74186d20

・ BBSファイル編集時などに生じるBBS発言数バグを修正
・ 64KBを超えるBBSスレッドの場合にブロックの区切り処理が変なのを修正
・ 起動時の日時チェックによる使用制限を無くした

BBS周辺の修正です。
スレを立てている方はできるだけ取り替えるようにお願いします。

なお、今回から本体はWinnyでの公開になります。
他WEBなどへの転載は常識的な判断にお任せします。


1199 名前:47 投稿日:03/02/02 21:15 ID:SDnbALUJ main/1044159846.html#325
何か?

1200 名前:47 投稿日:03/02/02 22:27 ID:YsBuMl5n main/1044159846.html#559
ここも読まない奴は、切捨てでいいでしょうか?

1201 名前:47 投稿日:03/02/05 01:27 ID:TgBWRv2R main/1044202688.html#820
あーあ、もうやる気なくなってきちゃったなー。

1202 名前:47 投稿日:03/02/05 02:26 ID:PjDE4LA0 main/1044202688.html#882
ハッピーかい?

1203 名前:47 投稿日:03/02/05 03:44 ID:UFvDzlQe main/1044202688.html#998
P2Pの革命児47様が1000ゲット!

1204 名前:47 投稿日:03/02/05 04:10 ID:mdOJtORd main/1044383045.html#47
ttp://www.aiseikai.or.jp
さいたまの病院

1205 名前:47 投稿日:03/02/05 15:43 ID:76YHGVFK main/1044383045.html#207
>>205
(o^ー’)b

1206 名前:47■47/AsfC8L0x 投稿日:03/02/05 18:02 ID:IthCyvHr main/1044383045.html#347
v1.07です。v1.06以隆と互換生があります。

・ BBS関孫のバグ修征
・ 使田リソース大福ダウン

リソースを大福にダウンしたので、ダウンロードしながら
IEでBBSを売み込んでも軽決に作働するはずです。
わたしのPen650Mhz・128Mメモリのロースペックでも
軽決に作働したので、ここの万々のスペックなら門題ないと恵います。

BBS関孫のバグは、ーつのスレッドが腹数表示されてしまうことに
間する修征です。しかしまだ完金に値ったわけではないので、ご丁承ください。

Winny107.zip(a6b8f3c0l2k3j1m0z1v6) 225,827byte

1207 名前:47 ◆KbtLZ9k7/w 投稿日:03/02/05 22:53 ID:5byjax35 main/1044383045.html#704
それではこのスレ自体を放置しましょうか

1208 名前:47 投稿日:03/02/06 02:58 ID:XYq6SXtF main/1044463190.html#68
v1.06.07です。v1.06以降と互換性があります。

Winny10607.zip 222,855 5439790b64ff8d24d26d09178d4c729d

・ セキュリティホールmemoで指摘されたと思われる部分を修正

これで修正しきれているかどうかわかりませんが
取り急ぎこちら側で確認した数ヶ所を修正しました。
クロスサイトスクリプティング問題もありましたのでできるだけ
取り替えるようお願いします。

前回と同じく他WEBなどへの転載は常識的な判断にお任せします。


1209 名前:47 ◆KbtLZwerNc 投稿日:03/02/06 11:30 ID:B07t4nmS main/1044463190.html#141
v1.07です。v1.06以降と互換性があります。

Winny107.zip 228,179 6152f2fb4eb67dd2a6f7d49577321873

・ BBSをフレーム形式に変更
・ BBSリスト出力形式を変更(外部からキャッシュ状況をわからなくした)
・ 他ノードのBBSポート探索機能追加(掲示板タブの外部ポート探索ボタン)
・ BBSダウンタスクを非表示にした(外部からのBBSアクセスがわかってしまうため)
・ 保持しているBBSキャッシュ数が500を超えたら自動的にBBSキャッシュ削除するようにした
・ BBSポート情報を各ノード間で情報交換するようにした
・ 長いBBS名を制限するようにした
・ 長いクラスタワードを制限するようにした

BBS関連の修正です。左側が板一覧で右側がスレ一覧というフレーム形式に変えました。
また、他ノードのポートを経由できるようにしましたので匿名性も上がってます。
特に書き込み側は二回中継になりますので匿名性が高いです。

また、今回新しく付いた機能で大きいものは外部BBSポート探索機能ですが、
やっていることはほぼポートスキャンです。他のノードのBBSポートを探します。
これによりWinny本体を落としても他のノード経由でBBSが見れるようになります。

なお、v1.07以降であればポート番号を明示的にやり取りしてそこにアクセスに行きますが
v1.06系のノードに対してはBBSポートを7744と仮定して動作します。

とりあえず、BBSポートにアクセスされたくない人は、
BBSポート番号を0にするか、FWでBBSポートを閉じるようにしてください。


1210 名前:47 ◆KbtLZwerNc 投稿日:03/02/06 11:34 ID:B07t4nmS main/1044463190.html#146
ちなみに>>68は偽者です。今後はトリップ良く見るようにお願いします。


1211 名前:47 投稿日:03/02/12 20:38 ID:FJ59s8NS main/1044980906.html#213
v1.0701です。vイオふえfじjぽおぽいffs;;おp

マンコ画wくぃff;おっくぃいえうえふいfじぇうぇkwkねk

・上をいえおいうytryうdjhbふぃ
・うf区f3w0ぷrfんtc3うc0p;ふぉごぺ
・23画ジョイ323おpろ3いりrp3いろいrprp

画渦3p9fづrf9pれf0rf9えr0fffれfrfrf
ふぇrウィ雄wwふぅpwf里追ういういいぇkふぉpヶwfぽけをpf
kjhで江戸けkっけおきk30い0dっぺっぺえええ

jふぇr日おえdふぉえうぃfdじぇいじおj、もうだめぽ

1212 名前:47 投稿日:03/02/12 23:38 ID:rMTHVV98 main/1044980906.html#330
もうだめぽ

1213 名前:47 ◆KbtLZwerNc 投稿日:03/02/17 00:26 ID:1DuLFtnZ main/1045229450.html#640
v1.08です。v1.06以降と互換性があります。

Winny108.zip 228,685 bbcba881a44c24f501260465ba1d0adc

・ 自ノードのBBSへのアクセスIPを127.0.0.1に固定
・ タスク状況タブのタブソート機能を実装
・ タスクの終了ステータスをカウント部でなく進行状況部に出力するようにした
・ タスク状況で多重ダウンかどうか出力するようにした
・ BBSダウンタスクで進行バーだけ表示されることがあったのを修正
・ BBSの更新スレ表示色を赤から緑に変更
・ 変換済みタスクダブルクリックでダウンフォルダ内のファイル関連付けを実行するようにした
・ アップフォルダ、ダウンフォルダを開く機能をフォルダタブボタンや右メニューに追加
・ 各タブにダブルクリック処理追加
・ 通信速度算出方式を変更(サンプリングが少ないと精度が悪くなる方式にした)
・ リスト項目が選択されていると上部のステータスが書き換わらないのを修正
・ 表示スレッドのロック間隔を短く、待ち時間を長くして処理負荷を低減

主にGUI周辺の細かい修正です。

なお、暗号部やハッシュ周辺もそろそろ変え時(プロトコルもほぼβそのままですし)
なので、この辺をそのうちまとめて変える予定です。匿名性も上がります。

できるだけ互換性は残すようにしますが、昔のβテストのキャッシュ変更時の様に
新キャッシュと旧キャッシュで上位互換性が無くなるんじゃないかと思います。
ただ、当分忙しいですし慌ててやる作業でも無いので、こちらはしばらくお待ちください。


1214 名前:47 ◆KbtLZwerNc 投稿日:03/02/17 22:05 ID:3AhWzvaf main/1045417613.html#817
ハッシュ周辺とキャッシュのバージョンアップ関連の実装は終わりましたが、
キャッシュ周りなため何かバグがあるとまずいのでもう一日かけてテスト予定です。

明日にでも新ハッシュVerになると思いますので少しお待ちください。

任意単語によるキャッシュ暗号化との辛みで
Ver2キャッシュの方式のまま放置してきてしまいましたが、
暗号キーはもう使ってないわけですので、
今度のキャッシュは素直にMD5ハッシュ値そのままとなります。
ブロック単位で暗号変える方式になるので、
全体キャッシュエラーの出る率が減ると思います。

また、キャッシュ周辺の暗号化が全て変わりますので匿名性も上がります。

キャッシュVer1→2のときと同じでハッシュ値算出法が変わるので
同じファイルに二つのハッシュ値が付くことになりますが、
どちらも問題なく扱えるようになってます。
ただし、3→4の時の様にキャッシュを引き継ぐことはできません。
新しくアップされると新キャッシュ(ハッシュがMD5)になることになります。

あと、暫定ですがジオの方に1.08を公開しておきましたので、
バージョンアップはこちらから行ってください。そのうちまた閉じます。
Ver1.06系は次で繋がらなくなる可能性があります。

ttp://www.geocities.co.jp/SiliconValley/2949/


1215 名前:47 投稿日:03/02/17 22:51 ID:JQd5EqgC main/1045488709.html#49
47

1216 名前:47 ◆KbtLZwerNc 投稿日:03/02/18 12:33 ID:eq2u3KCJ main/1045488709.html#325
v1.10です。v1.07以降と互換性があります。ハッシュやキャッシュ、暗号周辺の変更です。

・ キャッシュフォーマットをver4からver5(MD5ハッシュ方式)に変更
・ キャッシュ暗号方式の変更(ヘッダ部変更を含む)
・ 初期ノード情報暗号方式の変更
・ 表示スレッドのウェイトを少し減らした

内部的にかなり変わっていますが、全箇所、Ver1.07以降との上位互換性を持たせていますので
ノード情報を消す必要ありませんし、キャッシュもクリアする必要ありません。
バージョンアップの際には普通にexeを上書きするだけでOKです。

ここで、Ver1.10ではv4とv5のファイルが見え、これをアップ・ダウンできますが、
1.08以前のバージョンではv5のファイルは見えません。
v5のファイルが検索できてダウンできるのはVer1.10以降となります。

なお、アップキャッシュの互換性は無く、Ver1.10ではアップファイルは
強制的にv5キャッシュ扱いになるため、アップフォルダ内のファイルは
全てハッシュ再チェックがかかります。

また、初期ノード情報の暗号化方式も変わっていますので、
1.10のノード情報を公開する場合はVer1.10のアドレス暗号化を用いてください。
1.10で暗号化したノード情報は1.08以前では復号化できません。

なお、v1.10では旧方式のノード情報も暗号復号化できますので、
Ver1.08のNoderef.txtそのままでも問題なく読み込めます。
書き込み時に新フォーマットに変換されます。


1217 名前:47 ◆KbtLZwerNc 投稿日:03/02/18 12:33 ID:eq2u3KCJ main/1045488709.html#326
具体的な修正内容ですが、ほぼ予告どおりです。
Ver1.10でアップファイルのハッシュチェックを行うと、Winnyハッシュ値 = MD5ハッシュ値となります。

ここで、旧バージョンのハッシュ値でも検索・ダウン・アップ・キャッシュ変換できます。
旧バージョンのキャッシュは部分キャッシュも含めて旧バージョンキャッシュとしてダウンされ、
新バージョンのキャッシュと旧バージョンのキャッシュは独立に扱われます。混ざることはありません。
結局、一つのファイルにハッシュ値が新旧二種類あることになります。

なお、新バージョン(v5)のキャッシュ方式では、キャッシュブロック単位で全て暗号キーが違うので、
同一ファイルや他のキャッシュとブロック単位で取り替えてもそこは破損キャッシュ扱いになります。
ですので、今まで全体ハッシュエラーが出るような状況でも誤った部分のみ検出されて
そこだけ破損が修復されます。全部ダウンし直しになることもなくなるはずです。

新バージョンへのキャッシュ移行はかなりかかると思いますが、
これからはできるだけ新キャッシュの方で共有するようにお願いします。


1218 名前:47 ◆KbtLZwerNc 投稿日:03/02/19 17:31 ID:Xsr2fsI3 main/1045568679.html#484
v1.10.01です。v1.07以降と互換性があります。表示周りの小変更です。

Winny11001.zip 229,232 ed484e569b52a81eae5b7ba8d515b3c4

・ 設定でキャッシュバージョンの色区別無しにできるようにした
・ v4キャッシュ表示を少し明るくした
・ 速度表示などのステータス表示部再描画頻度を落とした

当分バージョンが上げられなくなるので、今のうちに上げときます。
色が見難いはずなので、戻せるようになどしておきました。

あと、今回ノードやキャッシュ関連は変えましたが通信周辺の暗号が
そのままですので、繋がるだけだったらかなり昔のバージョンでも
未だに繋がります。最新バージョンでも警告が出るのはこれでしょう。

匿名性向上のためにこの辺もそのうち変える予定ですが、
今度はVer1.07も繋がらなくなりますので、
新バージョンが広まるのをもう少し待ってください。


1219 名前:47 投稿日:03/02/20 23:05 ID:1x+P/XO6 main/1045677567.html#354
 

1220 名前:47 投稿日:03/02/25 14:02 ID:EMIvr6Ad main/1046106020.html#118
 

1221 名前:47 投稿日:03/02/25 21:12 ID:EMIvr6Ad main/1046106020.html#209
 

1222 名前:47 投稿日:03/02/26 18:49 ID:pTiji6/s main/1046106020.html#438
.

1223 名前:47 投稿日:03/02/26 22:25 ID:6ZcKsJf4 main/1046106020.html#487
nanika?

1224 名前:47 投稿日:03/02/27 15:44 ID:M1RiNgfh main/1046106020.html#607
 

1225 名前:47 投稿日:03/02/27 22:01 ID:M1RiNgfh main/1046106020.html#657
 

1226 名前:47 投稿日:03/02/28 00:08 ID:0DpaNt2G main/1046106020.html#697
 

1227 名前:47 投稿日:03/02/28 09:11 ID:0DpaNt2G main/1046106020.html#745
 


1228 名前:47 投稿日:03/02/28 14:00 ID:0DpaNt2G main/1046106020.html#780
 

1229 名前:47 投稿日:03/02/28 19:06 ID:0DpaNt2G main/1046106020.html#820
 


1230 名前:47 投稿日:03/02/28 22:25 ID:0DpaNt2G main/1046106020.html#855
 


1231 名前:47 投稿日:03/03/01 15:22 ID:zGX+HmPL main/1046472077.html#79
 

1232 名前:47 投稿日:03/03/01 18:55 ID:zGX+HmPL main/1046472077.html#132
イタイ

1233 名前:47 投稿日:03/03/01 21:03 ID:zGX+HmPL main/1046472077.html#172
イタイ

1234 名前:47 投稿日:03/03/01 22:32 ID:zGX+HmPL main/1046472077.html#216
カユ…  ウ マ…

1235 名前:47 投稿日:03/03/01 23:07 ID:zGX+HmPL main/1046472077.html#229
カユ  …ゥ   マ

1236 名前:47 投稿日:03/03/02 01:18 ID:GG0oSSyB main/1046472077.html#275
v1.11です。以前のバージョンとは互換性がありませんが、
Ver1.08以降に対しては新Ver警告を出します。
通信暗号化周辺の変更です。

Winny111.zip 229,357 7d46f5c216f95c381441c20c34d43991

・ 検索・転送リンクにおける通信暗号方式を変更

前のバージョンでキャッシュやハッシュ・ノード暗号化方式など暗号周辺を
ほとんど変えましたが通信の暗号化だけそのままでした。
ここを変えると前のバージョンと通信できなくなってしまい、
バージョンアップに気が付かない人が出てしまうためです。

そもそもWinny各所の暗号化は匿名性のためではなく、解析を困難にさせるためのもので、
解析されても匿名性に穴ができるわけではありませんが、下手にプロトコル解析されると
クラックその他で共有効率が悪くなる可能性があります。

ということで、通信の暗号方式を変えておきました。
ですので、以前のバージョンとは繋がりません。Ver1.11とだけ通信できます。

ただし、Ver1.08以降で新プロトコルヘッダだけ検出できるようにしておきましたので、
Ver1.08以降であればVer1.11と繋がった際にバージョン警告が出るようになってます。
それより前のバージョンとは繋がってもログにプロトコル違いが出るだけになります。

初期ノード情報について破棄しないでも問題ありません。exeの上書きでOKです。

できるだけ早めに取り替えるようによろしくお願いします。


1237 名前:47 投稿日:03/03/02 01:26 ID:GG0oSSyB main/1046472077.html#292
ちなみに、今までの通信の暗号周辺はVer1になってもβ22との互換性を持たせていた
ためにβ22と基本的に同じでした。

前のバージョンでは起動時展開していなかったので解析しやすかったはずで、
結果的にプロトコルも解析しやすかったはずです。

互換性が無いと移行が進まないとは思いますが、
このまま放置しておくのも問題だと思いますので、早めに変えといてください。

1238 名前:47 投稿日:03/03/02 14:35 ID:GOoNWpLL main/1046472077.html#636
Ver.1.1101です。

Ver.1.11とのみ接続できます。
キャッシュの容量が大きくなってきたので起動時にv4キャッシュ削除するようにしました。
また、v4キャッシュはダウン、転送もしないようになりました

しばらくダウンしにくくなるかと思いますが、キャッシュが大きくなりすぎるようなので
ちょっと早めですがv4キャッシュは終わりにします


1239 名前:47 投稿日:03/03/02 15:14 ID:ArCETOmN main/1046472077.html#644
ヵュ…        ゥ マ  ・

1240 名前:47 投稿日:03/03/02 16:15 ID:ArCETOmN main/1046472077.html#654
かゆうまっ

1241 名前:47 投稿日:03/03/02 16:52 ID:zZ7MLpIM main/1046472077.html#656
>>654
偽物め!

1242 名前:47 投稿日:03/03/02 18:02 ID:ArCETOmN main/1046472077.html#675
かゆうまっ

1243 名前:47 投稿日:03/03/03 12:17 ID:bSSkMXbH main/1046472077.html#836
かゆうまですが何か。

1244 名前:47GET 投稿日:03/03/04 00:49 ID:LIhSdmkQ main/1046697679.html#47
47GET

1245 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 12:08 ID:NFDSfT6+ main/1046697679.html#148
あーやっと暇になったかも。これで4月ぐらいまでは余裕あるかな。

ということで、また何か新しく作ろうかとも思うわけですが、
何かリクエストあります?やはり分散BBS周辺の強化ですかね?



とりあえず飯食ってこよう。


1246 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 13:56 ID:2zDJj/5g main/1046697679.html#222
最近ここの発言が多くて、読んだときに気が付いたけどそのまま放置になってる要望が
結構ありますね。可能なところは順に対応しましょう。

ただ、キャッシュの削除に関する部分と、検索機能強化に関する部分、
匿名性が下がる可能性がある部分に関しては変えないと思いますのでご了承を。

気軽にキャッシュが消せるのは問題なのと、検索周辺はもっとも
Winnyで負荷かかっているところで、あと今までの経験でバグを出しやすい
部分でもあるのであんまりやりたくないという理由によります。

とりあえずインターフェイス周辺などの簡単そうな部分からやりましょう。
少しお待ちください。


1247 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 14:08 ID:2zDJj/5g main/1046697679.html#239
ああ、あと良く要望を見かけるBBSのトリップですが、
信頼性のあるトリップ機構は作るのが難しいんではないかと思います。

2chのトリップの信頼性は2ch鯖管理者を信頼しているから成り立つわけで、
スレの管理者が発言内容を自由に改竄できる状態では、管理人が
他人のトリップを簡単に偽造できてしまいます。
ハッシュによる一方向関数を使ったとしても、スレ管理者は
変換前の文字列を見れてしまうわけですし。


あと、同様の理由でファイルについているトリップ機能も強化が難しい部分です。
実はキャッシュヘッダをクラックすればトリップ文字列は自由に変えられますので、
あれは、おまけ程度の信頼性しかないと思ってください。あっても邪魔には
ならないだろうとの判断でつけたものです。


1248 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 14:29 ID:2zDJj/5g main/1046697679.html#274
V4→V5キャッシュ変換は確かにあったほうが良いとは思ったんですが、
一度全ファイル内容を再スキャンしないと新しいハッシュ値がわかりませんし、
ファイルのハッシュ値が動的に変わるということでこれを実装するとトラぶりそう。
そもそもそれはファイルを再アップするのと同じだということで、
手動なら変換後のファイルをアップフォルダに移す方が確実だと思ってつけてません。
そんな理由でこれからも付けないでしょう。

ただ、64K以下の大きさのファイルはV4でもV5でもハッシュ値が同じになるので、
こちらは強制的にV5キャッシュに変換するようにはなってます(ヘッダ書き換えるだけなので)

そもそもV4キャッシュは半年以上も利用されていたものなので、
これが無くなる事はWinnyが動いている限り無いんではないかと思ってます。
新しいファイルから順にV5になっていけば良いのではないかと。


1249 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 14:33 ID:2zDJj/5g main/1046697679.html#280
こうして見ていくと、実装すると別の問題が出そうなので放置になってるものが多いなぁ。
説面が面倒で無視してきたからだけど。


1250 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 14:37 ID:2zDJj/5g main/1046697679.html#289
タイプミスに突っ込まないで(w
やはり何も考えずに書いて送信すると危険だ

1251 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 15:07 ID:2zDJj/5g main/1046697679.html#324
BBSはもっと動作が確実になるように基本メカニズムを変えたいところなんですが、
どのノードがいつダウンするのかわからない状況では確実な動作は
なかなか実現が難しいところです。

とりあえず今現在ではBBSキーの拡散はファイルと同じメカニズムなわけで、
これ以上BBSキー拡散率を上げると今度は転送リンク内の
キー転送の大域を使い切ってしまいます。

ですので改造するとしたら、BBSキーの寿命を極端に長くして消えないようにして、
BBSキーロストが発生したらノードが落ちているとみなして
BBSキー削除パケットを拡散させるという手など。

ただ、これだとクラック時のトラブルに弱くなりますし、
キー保持個数が少なくてひたすらキーを消しているノードでは
やはりBBSキーがロストしてしまいます。

他の考えとしては、検索リンクをBBSとファイルで共有するのを
やめて、BBS使用ノード間で新しい検索リンクを張ってこちらでファイルとは
別にBBSキーのやり取りをするという設計もあるかな。

と、いろいろ考え中。BBSキー専用に別リンク張るというのは良いかなと思ってるんですけどね。


1252 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 15:22 ID:2zDJj/5g main/1046697679.html#345
>>341
BBS専用のリンクを作らないでも、現在のBBS用ポートとそこへの
アクセスがその代わりになるという考えはありますね。
BBSポートをもっと積極的に使うという設計も良いかもしれません。

多くの人がBBSポート閉じるかと思ったらそうでもなくて
比較的簡単に外部ポート経由でアクセスできますし。

とりあえずもう少し良く考えて見ましょう。

1253 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 15:34 ID:2zDJj/5g main/1046697679.html#362
BBS専用クライアント作成の予定は今のところありません。理由は使われないと思うから。
WinnyBBSの利点は唯一ファイル共有システムと一緒になっているためP2P-BBSとしては
利用ユーザーが比較的多いということでしょう。BBS独自なら他にもっと良いシステムがあると思います。

ただ、もしBBS専用のリンクを新たに設けるのであれば、
検索リンクにはBBSのキーが流れなくなるわけで、
用いる検索リンクに制限機能を設けることで、簡単にBBS専用にしたり
ファイル共有専用にできると思います。将来的にはこちらのほうが
効率が良いとは思うので今のうちにこれにしてしまうのも手かなとは思ってますが。


1254 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 15:46 ID:2zDJj/5g main/1046697679.html#373
2chクラスの大規模BBSでも数十のノードだけで維持できるわけで、
実はP2P-BBSをやりたいだけならノードは1万も要らないはずだと考えてます。
だから、BBSが切り離せたりBBS専用にできるのは問題ないと思ってますが。

ただ、ちゃんと維持してくれる人がそうそういないだろうというのもあって、
P2P-BBSはファイル共有システムとまた別の難しい問題がありますね。

ファイル共有システムはユーザーさんの協力が得やすいので分散させるのが
比較的容易ですが、BBSはそうでもなかったりしますので。

今のところ、スレを立てるにはWinnyを常時起動していないといけないので、
これを利用させてもらっているわけですが(あとスレの管理も)、
他の人のスレを善意で維持・保全するひとはあまりいないだろうなというのが問題になります。


1255 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 15:53 ID:2zDJj/5g main/1046697679.html#378
WinnyみたいなP2P-BBSが作りたいだけならGnutellaをちょっと改造
するだけですぐに作れるんじゃないかと思います。
(ああ、ちなみにWinnyは他システムのソース何も参考にしてません)

WinnyのBBSって普通のwebサーバーのスレ情報をブロードキャストで
共有してるだけだし、興味があるかたはやってみるのも良いかと。

ただ、匿名性持たせたり人を集めるには別の工夫が必要にはなりますね。
ちゃんと動くように破綻しない管理ポリシーの設計とかそちらが一番大変かな。




1256 名前:47氏・・・・・ 投稿日:03/03/04 15:57 ID:Q55r4NOB main/1046697679.html#383
310 名前:47[sage] 投稿日:02/04/04 20:06 ID:stKzX4UZ

あと要望に応じてソース一部提出(w
ちゃんと作ってますよん。

/*
* 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;
}











↑ちなみにここは他所からパクったソースだ

1257 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 15:59 ID:2zDJj/5g main/1046697679.html#386
ああ、さすがに暗号とハッシュは他を参考にしてます。
書き換えたってことね。

1258 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 16:04 ID:2zDJj/5g main/1046697679.html#393
しっかし4/4の話かぁ。絶対ネタだと思われてたよね(w

1259 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 16:08 ID:2zDJj/5g main/1046697679.html#406
>>401

ポートが外部に開いてないとアクセスしてこれないから無理かと。

他ノードにスレッドを移譲できればいいだけなんだけど
これやると複雑になるのでやりたくないし。

1260 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 16:15 ID:2zDJj/5g main/1046697679.html#419
フレンドリーっていうか、忙しいときは、あまり発言するとボロが出たり
連鎖的に対応する必要が生じて時間取られるので必要最低限になってしまうわけで。

Winnyのネックの一つは作者自身だというのは間違いないわけですしね。

ただ、比較的暇になったしそろそろBBSに関連して大規模変更で、
みんなに了解とってからやらないと危険だという判断ですかね。


1261 名前:47 ◆KbtLZwerNc 投稿日:03/03/04 16:22 ID:2zDJj/5g main/1046697679.html#439
>>432
面白くて良いいんじゃないかと思いますよん。


1262 名前:47 ◇KbtLZwerNc 投稿日:03/03/04 17:16 ID:Jbe+tBiQ main/1046697679.html#528
今晩にもインターフェイス改良版をアップできると思います。























と言うレスがあと2時間後くらいにきたらいいな。

1263 名前:47 投稿日:03/03/04 18:03 ID:b6/lmMTE main/1046697679.html#551
俺、やめるのやめるわ。

そんだけです。じゃあ。

1264 名前:47 投稿日:03/03/04 19:04 ID:So+jFKuV main/1046697679.html#582
うまかゆっ

1265 名前:47 ◇KbtLZwerNc 投稿日:03/03/04 20:50 ID:Jbe+tBiQ main/1046697679.html#627
バージョンは明日になる予感
いや、明後日か…

1266 名前:47 ◇KbtLZwerNc 投稿日:03/03/04 20:54 ID:Jbe+tBiQ main/1046697679.html#629
>>628
はいがんばります














                        本当の47氏が…   。・゚・(つД`)・゚・。

1267 名前:47 投稿日:03/03/04 22:34 ID:p5tMNh8F main/1046697679.html#692
 

1268 名前:47 ♦KbtLZwerNc 投稿日:03/03/04 22:52 ID:6PVA29pS main/1046697679.html#707
ゔ〲〰

1269 名前:47師様へ 投稿日:03/03/04 23:55 ID:iOdaLEw2 main/1046697679.html#755
 ホームユースのソフトでこんなに役立ったソフトは無い・・・感動した!

 家のパソがこんなに価値有る物と始めて知った・・・感動した!


 ny初めて二ヶ月、ポト0で、今日、初めて 「転送リンク 上流(転送)」 が出た・・・感動した!







 俺って  ・・・  ア・ホ・? ・・・

1270 名前:47 投稿日:03/03/05 00:36 ID:S+MAJMIK main/1046697679.html#772
暗殺

1271 名前:47 ◇KbtLZwerNc 投稿日:03/03/05 12:10 ID:M86daQgx main/1046697679.html#957
                \ │ /
                 / ̄\  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
               ─( ゚ ∀ ゚ )< さいたまさいたま!
                 \_/  \_________
                / │ \
                    ∩ ∧ ∧∩ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄\ ∩∧ ∧∩\( ゚∀゚)< さいたまさいたまさいたま!
.さいたま〜〜〜〜!>( ゚∀゚ )/ |    / \__________
________/ |    〈 |   |
              / /\_」 / /\」
               ̄     / /
                    ̄


1272 名前:47 投稿日:03/03/05 15:01 ID:S+MAJMIK main/1046832707.html#68
旨い。

1273 名前:47 投稿日:03/03/05 17:52 ID:S+MAJMIK main/1046832707.html#151
まぁ、そうなんだよ。


1274 名前:47 ◆KbtLZwerNc 投稿日:03/03/05 23:01 ID:MNkGQ1za main/1046832707.html#265
v1.12です。v1.11と互換性があります。

Winny112.zip 232,368 9604a4acf13d2d482b1beea2654458d8

・ ファイル名などをToolTipとして表示するようにした(設定でOFFにするのも可能)
・ キャッシュにあるキーやダウン開始されたキーの名前とトリップがロックされるようにした
・ 設定で変換保留となっているダウン済みタスクでダブルクリックor強制変換で変換タスク起動できるようにした
・ ダウンリストタブの右メニューからでも強制変換タスクを起動できるようにした
・ システム情報の保持キャッシュサイズ換算の際に、保持キャッシュブロック数からではなく、
 終端ブロック位置からサイズを算出するようにした(実際のキャッシュサイズに近くなる)
・ トータル通信速度算出で突発的に変化するのを少し抑えた
・ ダウン条件・無視条件個数をシステム情報に出力するようにした
・ ダウン条件・無視条件のサイズ指定で実数(小数点以下)が使えるように変更
・ バージョン警告で誤報が出ることがあるのを修正(チェックを強化した)
・ アイコン状態でのTipでの並び順を変更
・ ダウン条件ダイアログでクラスタ化関連の説明追加

あまり変えるとトラブルが生じた際にどこが悪いのかわからなくなるので
こんなところでバージョンを上げておきます。
目立つところではToolTipを出すようになったところでしょうか。
昨日の段階で要望があったもので比較的修正が簡単なもの中心ですが、
匿名性が下がる可能性があるもの(ログ機能やノード情報関連など)やBBS関連は今回やってません。
BBS関連はまた後でやりましょう。


1275 名前:47 投稿日:03/03/05 23:32 ID:S+MAJMIK main/1046832707.html#364
俺は家政婦じゃないぞ。メイドだ。


1276 名前:47 投稿日:03/03/06 06:12 ID:4tZXU1qr main/1046832707.html#589
腹減った。


1277 名前:47 投稿日:03/03/06 14:26 ID:4tZXU1qr main/1046832707.html#667
誰か飯クレ。


1278 名前:47 投稿日:03/03/08 08:35 ID:x7lVwX8K main/1046977430.html#274
はー眠い。昨日からずっと作ってます。
明日には公開する予定。

1279 名前:47 投稿日:03/03/13 18:42 ID:zkF5+Uxx main/1047286831.html#880
v1.12です。v1.11と互換性があります。

Winny112.zip 232,368 9604a4acf13d2d482b1beea2654458d8

・ ファイル名などをToolTipとして表示するようにした(設定でOFFにするのも可能)
・ キャッシュにあるキーやダウン開始されたキーの名前とトリップがロックされるようにした
・ 設定で変換保留となっているダウン済みタスクでダブルクリックor強制変換で変換タスク起動できるようにした
・ ダウンリストタブの右メニューからでも強制変換タスクを起動できるようにした
・ システム情報の保持キャッシュサイズ換算の際に、保持キャッシュブロック数からではなく、
 終端ブロック位置からサイズを算出するようにした(実際のキャッシュサイズに近くなる)
・ トータル通信速度算出で突発的に変化するのを少し抑えた
・ ダウン条件・無視条件個数をシステム情報に出力するようにした
・ ダウン条件・無視条件のサイズ指定で実数(小数点以下)が使えるように変更
・ バージョン警告で誤報が出ることがあるのを修正(チェックを強化した)
・ アイコン状態でのTipでの並び順を変更
・ ダウン条件ダイアログでクラスタ化関連の説明追加

あまり変えるとトラブルが生じた際にどこが悪いのかわからなくなるので
こんなところでバージョンを上げておきます。
目立つところではToolTipを出すようになったところでしょうか。
昨日の段階で要望があったもので比較的修正が簡単なもの中心ですが、
匿名性が下がる可能性があるもの(ログ機能やノード情報関連など)やBBS関連は今回やってません。
BBS関連はまた後でやりましょう。



1280 名前:47 投稿日:03/03/13 18:45 ID:zkF5+Uxx main/1047286831.html#883
あとメール欄はsageではなくhigeでお願いします。
ttp://tmp.2ch.net/test/read.cgi/bakanews/1047291576/l50

1281 名前:47 投稿日:03/03/13 18:50 ID:zkF5+Uxx main/1047286831.html#884
Winnyのなんでだろ〜♪β1.01 

 匿名性が高いのなんでだろ〜♪
      なんでだろ〜♪

 中学生って検索すると炉ばっか出てくるのなんでだろ〜♪
                なんでだろ〜♪
 
 Winnyユーザー中学生多いのなんでだろ〜♪
         なんでだろ〜♪
 


1282 名前:47 投稿日:03/03/13 19:05 ID:zkF5+Uxx main/1047286831.html#889
なんで上げたらだめなの?

1283 名前:47 投稿日:03/03/13 19:10 ID:zkF5+Uxx main/1047286831.html#891
Winnyの開発やめました。


1284 名前:47 投稿日:03/03/13 19:15 ID:zkF5+Uxx main/1047286831.html#897
仕事の都合でニューヨークに行きます。

1285 名前:47 投稿日:03/03/13 19:16 ID:XjEcPWiE main/1047286831.html#898
明日から普通の47に戻ります

1286 名前:47 投稿日:03/03/13 19:17 ID:zkF5+Uxx main/1047286831.html#901
47氏は47人います。

1287 名前:47 投稿日:03/03/13 20:22 ID:zkF5+Uxx main/1047554001.html#18
開発一時中止です。

1288 名前:47 ◇KbtLZwerNc 投稿日:03/03/14 20:35 ID:TKeG3vOw main/1047554001.html#268
なにか?

1289 名前:47 投稿日:03/03/19 09:21 ID:ofdzs8G6 main/1047556784.html#857
v1.12.01です。v1.11以降と互換性があります。転送リンク制限関連の調節です。

Winny11201.zip 232,884 e77edb18badfd7ea005d838bdeba0766

・ Port0接続制限規則を変更(アップリンク占有率制限でなく個数制限にした)
・ コネクション限界時のファイル参照量による優先度変化(参照量の小さいもの優先)をやめた

今までPort0関連の制約は、Port0への転送リンク数をアップ側接続限界の1/3に制限
というものと、申請速度が自分より高いPort0へのアップは切断するというものでした。

これは、高速申請のPort0ノードが上流に居座ってしまうという以前の問題に対処するために
導入されたものですが、Port0ノード率が上がった結果、逆に上流ノードほど
Port0に対するアップ率が上がってしまうという問題が出ているようです。

ということで、この今までのPort0への制約を廃止して、
新たに全ノードで、Port0への転送アップリンクを5以下という制約にしました。
これにより、Port0だと高速ノードからのダウン時に接続限界で切られやすくなりますので、
Port0への転送リンクは主に低速ノード側からとなります。逆に非Port0ノードは
高速ノードから落としやすくなりますので、高速ノード間のダウン率が良くなって
キャッシュ拡散率が良くなるはずです。

なお、Port0への下流検索リンクが接続2リンクまでというのは今までと変わらないので、
Port0であまり高速申請すると検索リンクが繋がり難いのはそのままです。

あと、古いキャッシュのダウン率が悪くなっているようでしたので、
コネクション限界時の新しいもの優先を取り除いて平等にしてあります。

アップ側の修正なので、高速側がバージョンアップしないと効果が見えにくいと思いますが、
変更お願いします。


1290 名前:47 投稿日:03/03/19 15:04 ID:V1w0nGLy main/1048038720.html#253
無視リストの検索にも反映をONにしても検索に反映しないことがあることがわかりました。
対処法は起動時にリスト再読をすると治ります。
次のバージョンで改良します。次バージョンは来週中には公開します。

1291 名前:47 投稿日:03/03/19 17:17 ID:V1w0nGLy main/1048038720.html#393
前に言っていたテストバージョンと安定バージョンのことなんですけど、
時間が無くて両方は作れないと思われるので、分けるのやめました。
今まで何も言わなくてすいませんですた。

1292 名前:47 投稿日:03/03/19 17:27 ID:V1w0nGLy main/1048038720.html#405
>>398
今のところそのような予定はないです。
>>400
BBSより先にキャッシュのほうを先にやります。
>>401
効率が悪くなると思われますのでだめです。


1293 名前:47 投稿日:03/03/19 17:27 ID:V1w0nGLy main/1048038720.html#406
>>404
無理ですね。

1294 名前:47 投稿日:03/03/22 22:24 ID:Cf5UgFuR main/1048253670.html#365
このごろnyに関係のない話ばかりですね。
関係のない話は雑談でしましょう。。

1295 名前:47 投稿日:03/03/23 13:19 ID:k9WM0e3l main/1048253670.html#493
Port0のことでいろいろなっているようなので重大発表をします。
実はPort0はWinnyにとってとても大切な存在です。
Port0があるので高速検索および検索ができるのです。
詳しく言うと匿名性に問題が出てくるかもしれないので言いません。


1296 名前:47 ◆KbtLZwerNc 投稿日:03/03/23 17:05 ID:YVO2xFVP main/1048253670.html#537
ここのところ遊ぶ方で忙しくて暇にもかかわらずネットの方をろくに見れてませんが・・・

1.12→1.12.01での変更結果、トータルで良くなったか悪くなったか報告お願いします。


それなりにリンク接続状況が変わったはずなので状況が良くなった人と悪くなった人が
いると思いますが、こちらでは全体が見渡せないので多くの方から報告が無いと良く分かりません。

トータルで悪くなっているようなら戻すなり修正するなりしますし、そうでなければそのままになります。

Port0の扱いに関してはもう一つ案(Port0ノードでは、保持キャッシュ量に応じてダウン条件以外の
キー(レアキーでしょう)にも自動ダウンかけるようにすることでPort0の匿名性向上しつつレアファイル拡散担当)
があるにはあるのですが、これやると系トータルでは状況が悪化するのではないか
(Port0のダウン量が増えるだけでアップは増えず、結局キャッシュ拡散率が悪くなるだけ)と推測してます。

ここで、Port0のアップ率に関しては、Port0だけ上流検索リンク数を増やせばもう少し良くできるはずですが、
これをやると今度は非Port0の下流検索リンクが増えて全体の処理負荷が上がってしまうという問題が出ます。

結局突き詰めればPort0を全部切ってしまうのが系全体で最も効率が良いのは分かりきっていることなんですが
これは排他的で良くないので、とりあえず現時点の方針である、Port0ではアップ量にあわせてダウン量も少なめにして
Port0ノードの系への影響力を極力落とすという方針が一番良いのではないかと。

ですので、もう少し調節するとしたら、現在割り当てが5になっているPort0分の増減になるかと思います。


とりあえず状況が分からないとどうしようもないので、Port0周辺の報告引き続きお願いします。
こちらで主に知りたいのは、各速度域とPort0・非Port0それぞれで状況が良くなったか悪くなったかの情報です。


1297 名前:47 投稿日:03/03/24 01:05 ID:xQXNz3Sn main/1048253670.html#788
>>783
スイスの銀行口座に振り込んでくれ。

1298 名前:47 投稿日:03/03/24 03:59 ID:/GNX+ZBz main/1048253670.html#867
v1.12.02です。v1.11以降と互換性があります。Port0関連の修正です。

Winny11202.zip 232,993 af8090aa7cbf0358e2867756144f6c6c

・ Port0の場合、警告表示を出すようにした(ノード情報表示の場合)
・ Port0の場合、ダウン側の帯域制限を強制ONにした

Port0に関しての報告が少ないということは、単に良く分かってない人にPort0が多いというだけですね。

そういえば、ポート周りを何も設定しないで起動するとポート警告過多で停止しますが、この時に自動的にPort0設定を
ONにするようになっているので、次の起動時にPort0で動作して、このまま放置の人が多いのでしょう。

ということで、一番良い解決策はPort0警告出すことでしょうから、ノード情報のところに警告出すようにしました。
メッセージとしては、Port0のため速度が遅くなっていると出しますので、初心者の方も気にするのではないかと(w
仕方なくPort0にしている人にとっては邪魔なだけですが、ノード情報の時しか出さないので我慢してください。

あと、Port0だとダウンが遅くなる傾向がありますが、よりはっきり分かるようにPort0だと強制的にダウン側に
申請速度相当の帯域制限が入るようにしてあります。アップ側はそのままです。

アップ側も速度チェックして切ろうかとも思いましたが、Port0に気が付いてできるだけポート開けてもらえればそれで良いので
このままでも良いでしょう。わざと前バージョン使うような方は今回のバージョンアップ対象外です。

そんなこんなで当分は初心者の方のPort0警告の質問が相次ぐかと思いますが、
質問スレの方でお相手よろしくお願いします。回りまわって最終的に全体の利となります。



1299 名前:47 投稿日:03/03/24 04:07 ID:/GNX+ZBz main/1048253670.html#885
良く分からないでPort0になっている人が減ればPort0枠が空いて快適になりますので、
どうしようもなくてPort0になっている方は少しお待ちを。落ち着いたらまた調節します。


1300 名前:47 投稿日:03/03/24 04:47 ID:uvfgefho main/1048447816.html#26
v1.12.02です。v1.11以降と互換性があります。転送リンク制限関連の調節です。

Winny11202.zip 232,884 e77edb18badfd7ea005d838bdeba0766

・ Port0接続制限規則を変更(アップリンク占有率制限でなく個数制限にした)
・ コネクション限界時のファイル参照量による優先度変化(参照量の小さいもの優先)をやめた

今までPort0関連の制約は、Port0への転送リンク数をアップ側接続限界の1/3に制限
というものと、申請速度が自分より高いPort0へのアップは切断するというものでした。

これは、高速申請のPort0ノードが上流に居座ってしまうという以前の問題に対処するために
導入されたものですが、Port0ノード率が上がった結果、逆に上流ノードほど
Port0に対するアップ率が上がってしまうという問題が出ているようです。

ということで、この今までのPort0への制約を廃止して、
新たに全ノードで、Port0への転送アップリンクを5以下という制約にしました。
これにより、Port0だと高速ノードからのダウン時に接続限界で切られやすくなりますので、
Port0への転送リンクは主に低速ノード側からとなります。逆に非Port0ノードは
高速ノードから落としやすくなりますので、高速ノード間のダウン率が良くなって
キャッシュ拡散率が良くなるはずです。

なお、Port0への下流検索リンクが接続2リンクまでというのは今までと変わらないので、
Port0であまり高速申請すると検索リンクが繋がり難いのはそのままです。

あと、古いキャッシュのダウン率が悪くなっているようでしたので、
コネクション限界時の新しいもの優先を取り除いて平等にしてあります。

アップ側の修正なので、高速側がバージョンアップしないと効果が見えにくいと思いますが、
変更お願いします。

1301 名前:47氏]さん(ビン+キュー).ラー 投稿日:03/03/24 09:37 ID:s0VAZyt4 main/1048447816.html#133
v1.12.03 <Port0 version>です。他のすべてと互換性がありません。

Winny11203.zip 232,884 b7ef1866d8bdea005d83adba07e77edb

・ Port0でのみ接続できるようにした

Port0厨のために作ってやったから
こっち使ってすっこんでろ

1302 名前:47 投稿日:03/03/24 18:33 ID:ISUc+1// main/1048447816.html#448
今日から5日開発停止

1303 名前:47 投稿日:03/03/24 21:33 ID:pv9gBetO main/1048447816.html#561
v1.12.03です。v1.11以降と互換性があります。引き続きPort0関連の修正です。

Winny11203.zip 232,957 d83ad32062f2525a6894d0ad54230eb2

・ 1.12.01以前のPort0ノードと繋がらないようにした(検索・転送共)
・ UPがあればPort0におけるDownの強制帯域制限を外すようにした

こういう余計な制限を設けるのはあまり好ましくありませんが、
Port0側のバージョンアップ頻度がよろしくないようなので対処入れます。

引き続き、Port0関連の状況を知りたいので、
Port0の方、非Port0の方それぞれで状況報告お願いします。

特に非Port0側で良くなっているのかどうか知りたいところです。
それほど変わらないのであれば余裕枠をPort0や低速側の人に割けるわけですし。


1304 名前:47 ◆bg5irfTuqA 投稿日:03/03/27 16:38 ID:XpQV7l2Q main/1048518135.html#141
花見行くずら

1305 名前:47 ◆DL6xKyOq9k 投稿日:03/03/28 22:40 ID:UD6P30QK main/1048518135.html#651
ファイル交換の仕組み自体は続くって。

1306 名前:47 投稿日:03/03/30 00:18 ID:DRh8karH main/1048945709.html#127
v1.13です。v1.12.02以降と互換性があります。

Winny11203.zip 233,034 487256c4c9e816de6c261f4642631b3c

・ 検索クエリ時のキープッシュ率を変更
・ クエリ部の高速化
・ サイズの大きなファイルにおけるキャッシュ消費を減らした
・ 設定ダイアログでのコントロール並びを修正

クエリ処理部などに関する細かい調節です。

まず、検索結果処理部におけるキーのプッシュ部を少し変更しました。

今までですとアップキーやキャッシュキーなら必ずクエリ結果に入れてましたが
これだと上流に完全キャッシュを持っているノードがあるとほぼ確実にそこに
ダウンに行ってしまい、同じノードからは一つしかダウンできないという制限と合わさって、
なかなかダウンされないという症状が良く発生してました。
ここを修正してダウン先が散るようにしましたので、ダウン率が良くなると思います。
キャッシュ保持量の多いキーほどプッシュ率を高くなってますので、
全体のキャッシュ拡散率も上がるはずです。
無駄な処理も見つけたので省いて高速化もしてあります。

あと、ディスクの断片化を防ぐためにある程度大きくファイルを拡張する
ようにしてあるわけですが、大きなファイル(12MB以上)にダウンかけただけで
10M超のキャッシュができてましたので、ある程度キャッシュが溜まらないと
キャッシュ拡張しないようにしておきました。キャッシュフォルダの消費が抑えられると思います。

クエリの変更はアップ側の修正ですので効果が分かるまで時間がかかるかと
思いますが、各自バージョンアップしといてください。
あと、パラメーター変更に伴い中継発生率が微妙に変化すると思いますので、
この辺の報告をお願いします。


1307 名前:47 投稿日:03/03/30 00:19 ID:DRh8karH main/1048945709.html#136
ミスった

Winny11203.zip 233,034 487256c4c9e816de6c261f4642631b3c



Winny113.zip 233,034 487256c4c9e816de6c261f4642631b3c




1308 名前:47 投稿日:03/03/30 18:41 ID:7od5zR/j main/1048945709.html#574
うそぴょーん

1309 名前:47 投稿日:03/03/30 18:42 ID:uZOEY5PH main/1048945709.html#580
v1.13.01です。v1.12.02以降と互換性があります。

Winny11301.zip 233,053 65f5af1b698937a1b0f6ccd8fb07de5f

・ 転送リンク接続が多い場合の処理負荷低減
・ アップリンクが少ない場合の転送発生率を上げた

落ちるという報告が増えているようですが、前回の修正は落ちやすくなる要素が無いので
負荷が高くなってるからだろうということで負荷測定チェックしてみました。

その結果、上流で転送リンクが何十本が発生する場合にかなり処理負荷が
高くなる部分を見つけたので、ここを修正しました。ダウン条件などにもよりますが、
上流ノードでの処理負荷がそれなりに下がると思います。

あと、前回の修正で、転送率が高くなるか低くなるかは実際にやってみないと
分からなかった部分なのですが、どうも転送率が下がっているようですので、
もう少し上げておきました。
基本的にアップリンクが限界まで行っていないノードほど転送が生じる率が高くなります。
あと、キャッシュ保持率の高いキーほど転送が生じるので、
全体のキーロスト発生率が下がっているはずです。

この辺を考慮したうえで、引き続き、中継発生率などの報告よろしくお願いします。



1310 名前:47 投稿日:03/03/31 11:37 ID:8gzBKhli main/1049038586.html#190
明日、新UI版を出します。

1311 名前:47 投稿日:03/03/31 17:50 ID:S9GQxgwT main/1049038586.html#303
次のバージョンより自動バージョンアッププログラムをWinnyに組み込んで
公式サイトを閉鎖して自動でバージョンアップするようにします。
Winnyに流すと偽者が出るためこの方法をとりました。

1312 名前:47 投稿日:03/03/31 22:26 ID:S9GQxgwT main/1049038586.html#404
今回から新バージョンを最初にnyで流し1日後に公式サイトで流します。


1313 名前:47 投稿日:03/03/31 22:28 ID:S9GQxgwT main/1049038586.html#409
さいたま!!

1314 名前:47 投稿日:03/03/31 22:30 ID:S9GQxgwT main/1049038586.html#414
さいたまんこ!

1315 名前:47 投稿日:03/03/31 22:35 ID:S9GQxgwT main/1049038586.html#422
47氏=プログラミングサークル(計20名)
ぁ!言っちゃった!

1316 名前:47 投稿日:03/03/31 22:40 ID:S9GQxgwT main/1049038586.html#433
さいたまんこ!

1317 名前:47 投稿日:03/03/31 22:41 ID:S9GQxgwT main/1049038586.html#434
ごめん上げちゃった。

1318 名前:47 投稿日:03/03/31 22:41 ID:S116u/70 main/1049038586.html#436
正直、もう飽きた。

1319 名前:47 投稿日:03/03/31 22:44 ID:8LCfgf8U main/1049038586.html#441
氏ね

1320 名前:47 投稿日:03/03/31 22:54 ID:hN9XhyIZ main/1049038586.html#449
開発停止宣言するからお楽しみにね


1321 名前:47 投稿日:03/03/31 22:57 ID:S9GQxgwT main/1049038586.html#453
ばーじょんいってんぜろごーてんいです。ぜんばーじょんとごかんせいあります。
けいじばんのとくめいせいこうじょうとえらーをすくなくするために
おおはばなかいりょうをしました。
これによりすむーず(こうそく)にかんらんおよびかきこみができるとおもわれ。
そのところのほうこくをおねがいします。

1322 名前:47 投稿日:03/03/31 22:58 ID:S9GQxgwT main/1049038586.html#454
明日は全員名前欄に必ず47と書け!

1323 名前:47 投稿日:03/03/31 22:59 ID:hN9XhyIZ main/1049038586.html#456
あと1時間ですな


1324 名前:47 投稿日:03/03/31 22:59 ID:S9GQxgwT main/1049038586.html#457
さいたまんこ!

1325 名前:47 投稿日:03/03/31 22:59 ID:S9GQxgwT main/1049038586.html#459
47氏乙

1326 名前:47 投稿日:03/03/31 23:00 ID:S116u/70 main/1049038586.html#461
全員47氏化現象

1327 名前:47 投稿日:03/04/01 00:00 ID:K7G3TRln main/1049038586.html#537
( ´Д`)

1328 名前:47 投稿日:03/04/01 00:00 ID:tQTXKyPH main/1049038586.html#539
キタ━━━━(゚∀゚)━━━━??

1329 名前:47 投稿日:03/04/01 00:00 ID:2JM0638G main/1049038586.html#541
1周年オメ。5時まで起きてられないのでフライングスマソ

1330 名前:47 投稿日:03/04/01 00:00 ID:VnbA2SRQ main/1049038586.html#543
俺が47だ

1331 名前:47 投稿日:03/04/01 00:00 ID:kgI36kx3 main/1049038586.html#546
age

1332 名前:47 投稿日:03/04/01 00:00 ID:5GcmR5vb main/1049038586.html#547
おまいらイ

1333 名前:47 投稿日:03/04/01 00:00 ID:AXEqHuBH main/1049038586.html#549
開発終了

1334 名前:47 投稿日:03/04/01 00:00 ID:5IUogtSH main/1049038586.html#550
アナルが好きなの

1335 名前:47 投稿日:03/04/01 00:00 ID:BpLsUsJn main/1049038586.html#552
1分間の黙祷

1336 名前:47 投稿日:03/04/01 00:00 ID:O2E0mgy1 main/1049038586.html#554
test

1337 名前:47 投稿日:03/04/01 00:00 ID:9GetNxDW main/1049038586.html#556
暇なんでGAみたいだけどオタ向きの糞アニメつーのを
作ってみるわ。もちろんプロコリネイティブな。少しまちなー。

1338 名前:47 投稿日:03/04/01 00:00 ID:0ki3SYZF main/1049038586.html#557
遅・・・

1339 名前:47 投稿日:03/04/01 00:00 ID:qSVYzjVx main/1049038586.html#558
ティンコが…勝手に…ぅわあああ!!!

  ガクガク ,=、  ,, , =、
     ff | }!、_、_ /   - ― -─── .─;─.────────━━━,━∴━━━ 
      ,リ/ .ノ;´Д`)      --,──.──∴─,,────────━━*━ . .; ・
.ガクガク{{ { ′   v'   y〜イ,,,ノ     __ ヽ,   、 ・,‘         .   ,ノ ; ; ; ,.
     ヾ.\.   i ,r'”イj` y'⌒Y⌒´;;`ソヾ,、r X´_,,-‐‐'´〜;..u、ル'、ソ⌒h'";,t, y・;・
     _,,二、》    ミ--‐'リ"''‐--''t){"人,;'"r~~`´ ヽ";;,,:リ、゙j"=-,1xハ:''ヘ,,jミ《' シ;`j・..∴
       / ω ‐-t"'"二==ミ ,,_'-'‐ヾ、 '"゙゙彡    '゙゙゙`⌒ヽニ三,, `,, Y.:;'
   ── / / \ ヾ    - -j―── ヾ───ソ──────━━━ゞ 〆) ・: ━━━
     / ノ  ...\ ヽ - ―─────ゝ────────━━・━━━∵,
  ─/ _,/──   丶, ヽ  ― --─── ノ─────────━━━━━━
 ─/  j'─────  .〉 ,i ‐- ―────'─────────━━━..' ━━.━━
  (__,ノ         (___j      ―─────────────━━━━


1340 名前:47 投稿日:03/04/01 00:00 ID:sF95XG9u main/1049038586.html#562


1341 名前:47 投稿日:03/04/01 00:01 ID:sjH2+/ae main/1049038586.html#566
リアル47氏、乙〜。

1342 名前:47 投稿日:03/04/01 00:02 ID:BpLsUsJn main/1049038586.html#569
暇なんでWinnidaみたいだけどネチズン向きのファイル共有ソフトつーのを
作ってみるわ。もちろん半島ネイティブな。少しまちなー。

1343 名前:47 投稿日:03/04/01 00:02 ID:ctx+tX+W main/1049038586.html#573
一周年記念カキコ

クラスタどーすんだよ?

1344 名前:47 ◇KbtLZwerNc 投稿日:03/04/01 00:03 ID:4TfQpW7r main/1049038586.html#581
はぁ

1345 名前:47 投稿日:03/04/01 00:04 ID:BpLsUsJn main/1049038586.html#583
暇なんで同性愛みたいだけどホモ向きの男共有ソフトつーのを
作ってみるわ。もちろんいい男ネイティブな。少しやらないか?

1346 名前:47 投稿日:03/04/01 00:06 ID:BpLsUsJn main/1049038586.html#593
クラスタ指定「Winny さいたま 一周忌」

1347 名前:47 投稿日:03/04/01 00:07 ID:SmvyhIRi main/1049038586.html#598
Winy2発売予定
内容は 作者のプロフィ、写真集などを添付したWiny上位互換のソフトです。
値段は2209円(税込み)を予定。ぜひ買ってください。

1348 名前:47 &diams;KbtLZwerNc 投稿日:03/04/01 00:11 ID:4TfQpW7r main/1049038586.html#606
開発しゅ〜りょ〜
またな〜

1349 名前:47 投稿日:03/04/01 00:11 ID:udBKr/yW main/1049038586.html#608
ああ、乗り遅れた…

1350 名前:47 &diams;KbtLZwerNc 投稿日:03/04/01 00:13 ID:4TfQpW7r main/1049038586.html#614
>>609
バカ、わざとだよ(;´д`)
だって、ホラ…そうそうエイプリルフールじゃん?4月バカ?





















。・゚・(つД`)・゚・。

1351 名前:47 投稿日:03/04/01 00:17 ID:43JABJpk main/1049038586.html#631
v1.13.01です。v1.12.02以降と互換性があります。

Winny11301.zip 233,053 65f5af1b698937a1b0f6ccd8fb07de5f

・ 転送リンク接続が多い場合の処理負荷低減
・ アップリンクが少ない場合の転送発生率を上げた

落ちるという報告が増えているようですが、前回の修正は落ちやすくなる要素が無いので
負荷が高くなってるからだろうということで負荷測定チェックしてみました。

その結果、上流で転送リンクが何十本が発生する場合にかなり処理負荷が
高くなる部分を見つけたので、ここを修正しました。ダウン条件などにもよりますが、
上流ノードでの処理負荷がそれなりに下がると思います。

あと、前回の修正で、転送率が高くなるか低くなるかは実際にやってみないと
分からなかった部分なのですが、どうも転送率が下がっているようですので、
もう少し上げておきました。
基本的にアップリンクが限界まで行っていないノードほど転送が生じる率が高くなります。
あと、キャッシュ保持率の高いキーほど転送が生じるので、
全体のキーロスト発生率が下がっているはずです。

この辺を考慮したうえで、引き続き、中継発生率などの報告よろしくお願いします。

1352 名前:47 &diams;KbtLZwerNc 投稿日:03/04/01 00:19 ID:4TfQpW7r main/1049038586.html#646
>>618
いまでも色々かんぐってしまい見るサイト見るサイトとりあえずソースの
チェックとCtrl+Aは実行してしまうよ。

しかしもうそんなことを知らない世代が台頭してるのかとおもうと物悲しいな

ハンドルネームやらかしちゃったおれが言うのもなんだが。
今日はこの失敗をわすれないためこのハンドルで通すか。

1353 名前:47 投稿日:03/04/01 00:20 ID:5GcmR5vb main/1049038586.html#648
キ━━━( ゚∀゚ )━( ゚∀)━(  ゚)━(  )━(´  )━(ω・` )━(´・ω・`)━━━テナイ

1354 名前:47 投稿日:03/04/01 00:22 ID:BpLsUsJn main/1049038586.html#652
開発終了しました











といってる俺は偽者だから気をつけろよ!

1355 名前:47 投稿日:03/04/01 00:23 ID:uKlLNC1c main/1049038586.html#654
>◎ テスター以外は書き込まない。

だからもう報告しないから。公式サイトでもみてなー

1356 名前:47 &diams;KbtLZwerNc 投稿日:03/04/01 00:36 ID:4TfQpW7r main/1049038586.html#670
>>665
ゆるしてくれよ


1357 名前:47 投稿日:03/04/01 00:37 ID:iwTGiHcD main/1049038586.html#672
v4.01です。v3.31以降と互換性があります。

Winny4.01.zip 233,053 65f5af1b698937a1b0f6ccd8fb07dxxx

・ 実体化する際のメモリ負担を1TBで統一
・ 大気圏突入率が少ない場合のコムサイ発生率を上げた

突入後落ちるという報告が増えているようですが、前回の修正は落ちやすくなる要素が無いので
負荷が高くなってるからだろうということで負荷測定チェックしてみました。

その結果、上流で突入リンクが何十本が発生する場合にかなり処理負荷が
高くなる部分を見つけたので、ここを修正しました。落下条件などにもよりますが、
上流ノードでの処理負荷がそれなりに下がると思います。

あと、前回の修正で、実体化率が高くなるか低くなるかは実際にやってみないと
分からなかった部分なのですが、どうも実体化が下がっているようですので、
もう少し上げておきました。
基本的にアップリンクが外宇宙まで逝っていないノードほど実体化が生じる率が高くなります。
あと、キャッシュ保持率の高いキーほど突入が生じるので、
全体のキーロスト発生率が下がっているはずです。

この辺を考慮したうえで、引き続き、実体化および外宇宙突入率などの報告よろしくお願いします。

1358 名前:47 投稿日:03/04/01 00:41 ID:LeQyJCbq main/1049038586.html#683
<コ:彡
すぽると見てたら乗り遅れた

1359 名前:47 投稿日:03/04/01 00:42 ID:LeQyJCbq main/1049038586.html#685
<コ:彡.。oO(47氏お疲れ様。これからも頑張ってネ★)

1360 名前:47 投稿日:03/04/01 00:51 ID:muXBzFQv main/1049038586.html#691
一応記念に書いておきます。

1361 名前:47 投稿日:03/04/01 00:52 ID:ozp4SqtH main/1049038586.html#693
v1.14です。v1.12.02以降と互換性があります。

Winny114.zip 233,034 e816de6c2611b3c487256c4c9f464263

・ Port0の制限をいったんはずしてみた

問題の切り分けのために、Port0に課した制限をいったんはずすことにします。
ただ、Port0の制限がはずれるのはPort0側も相手も1.14のときに限ります。

アップ側の修正ですので効果が分かるまで時間がかかるかと思いますが、
各自バージョンアップしといてください。 真性Port0の方は報告をお願いします。

また、高速ノードの方はしばらくPort0が群がる可能性もありますので、そこら
へんも報告していただけるとありがたいです。


1362 名前:47 投稿日:03/04/01 00:54 ID:YcPoMWq3 main/1049038586.html#697
仕事で出張のため開発3ヶ月間休止します。

1363 名前:47 投稿日:03/04/01 01:10 ID:1eJgLtWr main/1049038586.html#719
v1.13.02です。v1.12.02以降と互換性があります。

Winny11302.zip 233,528 f2429575fce96e7084623bcd05e08131

・ キー処理の部分でデッドロックの可能性があったのを修正
・ 暗号/復号処理の高速化

デッドロックの部分は前から気付いていたのですが、まず発生しないだろうということで
今まで放置していました。
今回キー処理の部分をいじるついでに修正しておきました。

あと、暗号/復号に無駄な処理があったので最適化しました。
さらに一部はインラインアセンブラで書き直したので、負荷はかなり軽減していると思います。

ファイル共有部分の修正ではないので、今回だけあえてWinnyで配布してみます。
4/1ですしどれくらいの人が信じて更新してくれるか、(・∀・)ニヤニヤしながら眺めるのもいいかなと。


1364 名前:47 投稿日:03/04/01 05:30 ID:jJdZJgGg main/1049038586.html#798
v1.13.02です。v1.12.02以降と互換性あります。アップ周辺の微調整です。

Winny11302.zip 233,089 28b5fa1b636637c2e0d6cad8fb07db3b

・ 完全キャッシュキー送信の際にUP転送リンク限界かどうかチェックしていなかったので修正
・ UP転送リンク限界でも低確率でキーを流すようにした
・ UP転送リンク接続集中時のリンク切断方式を変更
・ 低速ノードで長時間経つと転送リンクが切れやすいのを修正
・ BBSキー送信率を少し上げた

下流にある被参照量が少ないファイルの拡散率が悪いようなので調節しました。

まず、特定のノードにしかファイルがない状態で、
このノードがUP転送リンク限界状態になると、
キーが流れなくなってしまうので、再調節が起きるように
UP転送リンクが限界でもまれにキーを流すようにしました。

あと、UP要求が集中した場合に、UPしているファイルの被参照量、
リンク接続時間、回線速度を考慮して動的に切断対象を選ぶようにしました。
被参照量が少ないファイルほど上流への転送が発生しやすくなります。

こちらのほうがキャッシュの拡散速度が速くなるはずです。

あと、UP転送リンク限界でも完全キャッシュキーを外部に流していたので、
キャッシュがあるほど接続要求を受けて負荷が高くなっていたはずですが、
修正しましたので多少はネットワーク周りの負荷が下がるかと思います。

UP側の変更なので効果が現れるには時間がかかると思いますが、
更新お願いします。


1365 名前:47 投稿日:03/04/01 05:35 ID:0ki3SYZF main/1049038586.html#804
47氏ありがと〜

1366 名前:47 投稿日:03/04/01 05:40 ID:g9C2xEtp main/1049038586.html#825
今起きた

1367 名前:47 投稿日:03/04/01 05:42 ID:g9C2xEtp main/1049038586.html#827
完成率が半分ぐらいだと思ったから念のため4/1に書いたんだよね


1368 名前:47 投稿日:03/04/01 07:09 ID:8+eSYeUm main/1049038586.html#844
おはよう森の妖精たち

1369 名前:47 投稿日:03/04/01 07:15 ID:oy5v0+wc main/1049038586.html#845
++++++++
++++++++
++++++++
+++○●+++
+++●○+++
++++++++
++++++++
++++++++

1370 名前:47 投稿日:03/04/01 08:09 ID:Q39PpgxO main/1049038586.html#856
さいたまんこ!

1371 名前:47 投稿日:03/04/01 09:08 ID:Q39PpgxO main/1049038586.html#863
1周年記念祭りを開催だぁ!!!!!!!!!!!!!!!

1372 名前:47 投稿日:03/04/01 09:30 ID:Q39PpgxO main/1049038586.html#872
2ちゃんねるがプロバイダーはじめるんだてよ。
ttp://isp.2ch.net/
MXとかnyとかたくさん使えってことか?

1373 名前:47 投稿日:03/04/01 09:31 ID:Q39PpgxO main/1049038586.html#873
ダイヤルアップでnyやれっていうのか?

1374 名前:47 投稿日:03/04/01 09:32 ID:Q39PpgxO main/1049038586.html#875
>>872
>>873
は話の続きです。

1375 名前:47 投稿日:03/04/01 09:33 ID:Q39PpgxO main/1049038586.html#876
ソース見たら踊るアホウに見るアホウ。。。って書いてたぞ。

1376 名前:47 投稿日:03/04/01 10:53 ID:Q39PpgxO main/1049038586.html#908
v1.13.02です。v1.12.02以降と互換性があります。

Winny11302.zip      あとは秘密

エイプリルフールなので今回はnyで流しました。
同時に偽Winnyも5種類流しました。

・前回のバージョンアップの修正

前回のバージョンでDL速度が落ちることがわかったので
今回は少し修正しました。

DL速度部分の報告よろしくお願いします。

1377 名前:47 投稿日:03/04/01 10:55 ID:Q39PpgxO main/1049038586.html#911
あと偽Winnyといっても悪いことはしませんよ。。
あさってには公式サイトでも公開します。

1378 名前:47 投稿日:03/04/01 10:59 ID:Q39PpgxO main/1049038586.html#912
言い忘れましたが、1周年記念仕様になっています。。はい。。
1周年記念仕様の違いをみつけてみてください。。わかるよね?

1379 名前:47 投稿日:03/04/01 11:46 ID:Q39PpgxO main/1049038586.html#923
>>921
最新バージョンを常に使わないと恐ろしいことが怒ります。

1380 名前:47 投稿日:03/04/01 11:56 ID:Q39PpgxO main/1049038586.html#930
1周年だからWinyyの事実を公開します。
・実は暗号化なんてしてませんでした。。
・BBSは普通にサーバにアクセスしてるだけでした。
・キャッシュなんて存在しませんでした。
・実はP2Pじゃ無くてサーバを通してました。
・アドレス暗号化でまったく暗号化してませんでした。
・キャッシュフォルダにはウイルスのみが溜まる仕組みでした。

1381 名前:47 投稿日:03/04/01 12:04 ID:Q39PpgxO main/1049038586.html#935
>>932
殺人予告か?
俺のことを自殺に見せかけて殺そうとしてるのか?

1382 名前:47 投稿日:03/04/01 12:48 ID:yckhH6TE main/1049038586.html#943
誰だお前

1383 名前:47 投稿日:03/04/01 12:59 ID:Q39PpgxO main/1049038586.html#945
1000げっと!

1384 名前:47 投稿日:03/04/01 13:10 ID:Q39PpgxO main/1049038586.html#948
1000げっと!

1385 名前:47 投稿日:03/04/01 13:14 ID:/uxTof3D main/1049038586.html#949
v1.13.02です。v1.13以降と互換性があります。

Winny11302.zip 231,072 b3df87120fe07ab3b6dbf31f4fa131072

・ 完全キャッシュキーの拡散率を周囲のクラスタによって変動させるようにした
・ 全体ハッシュ不整合エラーがでる可能性があったのを修正
・ に重に登録されたダウンリスト項目の削除を行うようにした
・ ネットワーク全体での負荷効率の見直し
・ タイミングによってはmax以上の転送数が発生するのを抑えるようにした

おそくなりましたが、Winny1.13.02です。

まず、キーの拡散方法を無作為な拡散から、ある程度指向性を持った方法に変更しました。
いままでと違いキーの拡散率が双方のクラスタワードに影響されるので、非Port0ノードな
ら、こちらの方が効率がよくなるはずです。(Port0では他ノードに完全に依存します)

暇ができたのでソースをチェックしていたのですが、以前のバグが修正し切れなかった
みたいで、V5キャッシュでも全体ハッシュ不整合エラーが出ることがあったようです。
たまたま大問題にはなりませんでしたが、他スレでちらほらと報告もあったようなので
いまのうちに修正しておきました。

できれば各ノードでのUP、DOWN状況を報告してもらえると助かります。今回の変更は
すぐには反映されませんが、各速度域での送受信量など、こちらの推測だけでは計りか
ねる部分が大きいので、申告速度と共に状況等を報告してください。

1386 名前:47 投稿日:03/04/01 13:19 ID:Q39PpgxO main/1049038586.html#953
1000げっと!

1387 名前:47 投稿日:03/04/01 13:26 ID:Q39PpgxO main/1049038586.html#960
100げっと!”

1388 名前:47 投稿日:03/04/01 13:26 ID:Q39PpgxO main/1049038586.html#961
100000000000000下tttttttttttttttttttttっと!!!!!!!!!111

1389 名前:47 投稿日:03/04/01 13:27 ID:Q39PpgxO main/1049038586.html#963
きたたたったったったったったったtt
1000げっとお!

1390 名前:47 投稿日:03/04/01 13:27 ID:Q39PpgxO main/1049038586.html#964
うおおおおおおおおおおおおおおおおおおおおおおおおおおおお
1000げっつ!


1391 名前:47 投稿日:03/04/01 13:39 ID:X1cc7FxU main/1049038586.html#997
プ

1392 名前:47 投稿日:03/04/01 03:41 ID:WXL/SYo8 main/1049124224.html#39
れんしゅう

1393 名前:47 投稿日:03/04/01 03:55 ID:X1cc7FxU main/1049124224.html#42
v1.13.01です。v1.12.02以降と互換性があります。

Winny11301.zip 233,053 65f5af1b698937a1b0f6ccd8fb07de5f

・ 転送リンク接続が多い場合の処理負荷低減
・ アップリンクが少ない場合の転送発生率を上げた

落ちるという報告が増えているようですが、前回の修正は落ちやすくなる要素が無いので
負荷が高くなってるからだろうということで負荷測定チェックしてみました。

その結果、上流で転送リンクが何十本が発生する場合にかなり処理負荷が
高くなる部分を見つけたので、ここを修正しました。ダウン条件などにもよりますが、
上流ノードでの処理負荷がそれなりに下がると思います。

あと、前回の修正で、転送率が高くなるか低くなるかは実際にやってみないと
分からなかった部分なのですが、どうも転送率が下がっているようですので、
もう少し上げておきました。
基本的にアップリンクが限界まで行っていないノードほど転送が生じる率が高くなります。
あと、キャッシュ保持率の高いキーほど転送が生じるので、
全体のキーロスト発生率が下がっているはずです。

この辺を考慮したうえで、引き続き、中継発生率などの報告よろしくお願いします。

1394 名前:47 投稿日:03/04/01 04:20 ID:WXL/SYo8 main/1049124224.html#50
やっぱりこれだ

1395 名前:47 投稿日:03/04/01 04:23 ID:WXL/SYo8 main/1049124224.html#53
って、ああああぁああぁぁぁっ!!47うまってるしぃぃぃいぃっっっ!!!!!!!!!!!!

1396 名前:47 投稿日:03/04/01 04:26 ID:WXL/SYo8 main/1049124224.html#54
>>51
そういえばこのまえIDがokkuでつかれたとかなんとかいってるやついたよな

1397 名前:47 投稿日:03/04/01 04:42 ID:WXL/SYo8 main/1049124224.html#58
そんでそいつにめーるらんこみでがんばれなんてれすしたやつがいてさ

1398 名前:47 投稿日:03/04/01 05:17 ID:WXL/SYo8 main/1049124224.html#61
むしゃぶるいがとまらないとおもたらにょういだた

1399 名前:47 投稿日:03/04/01 05:23 ID:WXL/SYo8 main/1049124224.html#63
さて、なんのはなししてたっけ?

1400 名前:47 投稿日:03/04/01 05:34 ID:WXL/SYo8 main/1049124224.html#68
あ、そうそう、MXの次はどうなるかってはなしだったな

1401 名前:47 投稿日:03/04/01 05:35 ID:uKlLNC1c main/1049124224.html#72
暇なんでWindowsみたいだけど2chネラー向きのOSつーのを
作ってみるわ。少しまちなー。

1402 名前:47 投稿日:03/04/01 05:46 ID:WXL/SYo8 main/1049124224.html#79
ところでこのすれちゃんときえるんだろうな、、、、

1403 名前:47 投稿日:03/04/01 23:17 ID:1eJgLtWr main/1049124224.html#274
まる一日放置しておいたのですが、どうやら寝ている間に落ちていたようです。
まあ2MB程アップされたようなので、もし落とせた方がいましたら
幻のバージョンとして大切にしてくださいな。


1404 名前:47 投稿日:03/04/01 23:38 ID:wcV/daGw main/1049124224.html#281
v1.13.02です。v1.12.01以降と互換性があります。バグ関連の修正です。

Winny11302.zip 243,681 af9090am7cbf0358e2878056144f736c

・ タスク画面からアイコンが見えなくなる原因がわかりましたので
 修正しておきました。
・ 尚、今回からV4キャッシュを使えなくしました。
 キャッシュ部分を変更しますと混乱をまねくので触りたくなかった
 のですが、匿名性向上の為、理解願います。
・条件指定でサイズ下限も有効にした。
・低速転送切断を下流にも有効にした。
 これにより速度申請上方申請するノードと繋がらなくります。
 尚、ISDNの方は初期転送本数を1本にしましたので影響ありません。

 ということで、テスターのみなさん変更をお願いします。

1405 名前:47 投稿日:03/04/02 01:13 ID:HJzWPvbG main/1049124224.html#333
v1.13.02です。v1.12.02以降と互換性があります。

Winny11302.zip 233,057 96c225b91df0711d63ca797f57635358

・ 中継転送発生率を少し落した

判断が難しいところですが、転送が始まらない率が高くなりすぎている
(=中継発生率が高すぎる)ように思えますので再調節しました。

中継率が高いほどキャッシュが拡散するのですが、あまり上げると今度は
転送失敗率が上がるので、キャッシュ拡散率最高になる中継発生率には最適値がある
(中継発生=0がキャッシュ拡散最適ではない)と考えています。
もちろん中継発生率が高いほど匿名性は高くなりますが、
キャッシングしてる関係上、これは0でなければよかったりもします。

とりあえず中継部のアルゴリズムを変更したため、またパラメーターを
再調節しているわけですが、もう少し調節にお付き合いください。
こんなもんで最適になるんじゃないかと思います。

ということで、引き続き中継発生率やダウン成功率などの報告お願いします。


1406 名前:47 投稿日:03/04/02 01:50 ID:eB9nNZka main/1049124224.html#472
ぬるぽ

1407 名前:47 投稿日:03/04/02 01:54 ID:eB9nNZka main/1049124224.html#499
まんk

1408 名前:47 投稿日:03/04/02 01:55 ID:kUmQesdV main/1049124224.html#503
ajgfhhbasnbklflblaklmffdjbldfjbjdfjb
bkdbdjmbdkgnmgdknk
b,mlmbfmd


fldbkdflbkkdbkdkb
blkkbmlgdbd
]kbkgdkbgkkbg

1409 名前:47 投稿日:03/04/02 01:56 ID:Il0TSxn7 main/1049124224.html#506
すいません もう少し最適化したのを流しました

1410 名前:47 投稿日:03/04/02 01:58 ID:kUmQesdV main/1049124224.html#509
・クエリ処理部改良によるダウン率向上、および高速化
・サイズの大きなファイルにおけるキャッシュ消費軽減

UPがあればPort0におけるDownの強制帯域制限を外すようになりました。

・Port0の場合、警告表示を出すようにした
・Port0の場合、ダウン側の帯域制限を強制ONにした


1411 名前:47 投稿日:03/04/02 02:04 ID:FLNouihb main/1049124224.html#532
v1.13.02です。v1.12.01以降と互換性があります。バグ関連の修正です。

Winny11302.zip 243,681 af9090am7cbf0358e2878056144f736c

・ タスク画面からアイコンが見えなくなる原因がわかりましたので
 修正しておきました。
・ 尚、今回からV4キャッシュを使えなくしました。
 キャッシュ部分を変更しますと混乱をまねくので触りたくなかった
 のですが、匿名性向上の為、理解願います。
・条件指定でサイズ下限も有効にした。
・低速転送切断を下流にも有効にした。
 これにより速度申請上方申請するノードと繋がらなくります。
 尚、ISDNの方は初期転送本数を1本にしましたので影響ありません。

 ということで、テスターのみなさん変更をお願いします。


1412 名前:47 投稿日:03/04/02 02:06 ID:lC9DAFCs main/1049124224.html#545
v1.13.02です。v1.12.02以降と互換性があります。

Winny11302.zip 233,057 96c225b91df0711d63ca797f57635358

・ 中継転送発生率を少し落した

判断が難しいところですが、転送が始まらない率が高くなりすぎている
(=中継発生率が高すぎる)ように思えますので再調節しました。

中継率が高いほどキャッシュが拡散するのですが、あまり上げると今度は
転送失敗率が上がるので、キャッシュ拡散率最高になる中継発生率には最適値がある
(中継発生=0がキャッシュ拡散最適ではない)と考えています。
もちろん中継発生率が高いほど匿名性は高くなりますが、
キャッシングしてる関係上、これは0でなければよかったりもします。

とりあえず中継部のアルゴリズムを変更したため、またパラメーターを
再調節しているわけですが、もう少し調節にお付き合いください。
こんなもんで最適になるんじゃないかと思います。

ということで、引き続き中継発生率やダウン成功率などの報告お願いします。

1413 名前:47 ◆KbtLZ9k7/w 投稿日:03/04/02 02:13 ID:mNJCnhpu main/1049124224.html#559
>>552
…?

>>555
>550はやっぱり本気なのかな

1414 名前:47 投稿日:03/04/02 03:22 ID:RSLb3tbV main/1049124224.html#621
v1.13.03です。v1.12.02以降と互換性あります。

Winny11303.zip 253,342 69fa3b7f78089c06fecbdd87800965d4

・ キー交換で無駄な帯域を使っていたのを修正
・ 検索リンクが回線速度に対して繋がりすぎるのを調整

指示されていたアクティブにする際の絵画処理ですが、v1.14で対応しよう
と思います。
度重なるバージョンアップ申し訳ありませんがよろしくお願いします。


1415 名前:47 投稿日:03/04/04 00:22 ID:z+1ARup6 main/1049290850.html#382
v1.13.03です。v1.12.02以降と互換性があります。

Winny11303.zip 233,048 aadb6d46efecc86bcdaaa39f8e54b552

・ 検索クエリ時のキープッシュ率をv1.12.02時点に戻した

微調整が続いてすいませんが、どうもv1.13系列で悪化しているという
報告が多いようで、考えられる原因としては1.12.02→1.13時の変更の
これのはずなので元に戻しました。

拡散率上がるかと思ったのですが、完全キャッシュの転送率が下がるだけのようです。

ということで実験的な修正ではありますが、変更お願いします。

ダウン率などどうなるか報告お願いします。
これが原因ならv1.12.02以上に良くなるはずです。
ただし、アップ側の修正なので変化が直ぐには分かりません。


1416 名前:47さんへ 投稿日:03/04/05 07:48 ID:RH4hueNo main/1049290850.html#908
☆バグ報告用テンプレ簡略版 v2.24(゚д゚)
☆--------------------------------------------------
☆【     OS      】 Windows98SE
☆【  外部から接続  】 不可
☆【     備考      】ISDN7K
☆--------------------------------------------------
Port0環境なのですが、回線が細く切れやすいので、
帯域制限は常に有効にしています。
ところが、1.12のPort0速度制限以来、UL発生中の帯域制限が
まったく無効になってしまっています。
申告7KでUL5.5、DL4.9とか、そんな感じです。
ほっておくと過負荷のためか回線が切れていたりするので、
どうかそのへんをご確認いただけないでしょうか。
☆--------------------------------------------------

1417 名前:47 投稿日:03/04/05 19:22 ID:cDRdWazI main/1049509476.html#106
v1.14です。v1.12.02以降と互換性があります。

Winny114.zip 233,106 1268bda1ec55f4439beef1b1a0c06546

・ 破損BBSキーを他ノードへ送信することがあるのを修正
・ 接続停止時に待ちうけポートを閉じないで接続無視するようにした
・ ポートが既に使われていた場合のエラーチェック強化
・ タスク処理頻度を上げた(高速ダウン試行ボタンON時)

細かいバグ取りです。

接続停止を連打するとポート使用済みのメッセージが出た後落ちるとか、
キャッシュに残っている破損BBSキーが送信されることなどの修正です。
例の同じタイトルのスレッドができるのが直るはずですが、やってみないとわかりません。

あと、タスク処理頻度を上げておきましたので、キャッシュ変換などの処理速度がかなり上がるはずです。
ただし、CPUに余裕がなかったりHDDが遅かったりすると逆に調子が悪くなる可能性がありますので、
その場合は高速ダウン試行ボタンをOFFにしてください。前と同じになります。

BBS周辺以外は効果が直ぐにわかる修正ですが、BBS関連はアップ側の修正で
すぐには効果が見えないと思いますので、この辺に注目して報告お願いします。


1418 名前:47 投稿日:03/04/07 03:39 ID:NnqBILQi main/1049509476.html#929
公式サイトは閉鎖いたします。

1419 名前:47氏、おつかれさまでした 投稿日:03/04/07 03:47 ID:9q/GEVmW main/1049509476.html#937
      ..ミミ ̄ ̄ ̄\     .   THANK YOU 47氏   .     / ̄ ̄ ̄彡彡
        ミミ     \            and           ./     彡彡
   ゜*    ミミ     \     GOOD-BYE Winny !   ./     彡彡  +  *
        :   ミミ      \                 ./     彡彡    :
     +  .*  ミミ     \ ┏━・゚・(ノД`)・゚・━┓ /     彡   ゜*   ゜
             ミミ     (´Д⊂   WINNY  (TдT)    彡        :    ゜ 
  . .ミミ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ \ ┗━。゚(゚´Д`゚)゚。.━┛ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄彡彡
    ミミ              \ またどこかで会おうね             彡彡
      .ミミ彡彡彡彡彡彡彡.     \.   \.  ./  ./     .ミミミミミミミミミミミ    :
    *     + .      \    \ .  |  |  /    /  ゜*   +
       ( (__,,... .∫_) )    / ̄ ̄ ̄\.  ⊂⊃ / ̄ ̄ ̄\         :         ゜
       .´,.:::;;:.. . . _ ヽ ノ  \   /\ ∧_∧/\    \  オトモシマス ノ   \
       }ヾ:(;・ω・`)_ン!| ☆ | /     ( ・∀・ ) バイバイ    ⊂⊃      | ☆ |  ゜: 
    *.  }   ̄ ̄..;彡,||   ||.     ⊂ 47 つヾ   | .へ∧_∧ /\ . |    |
       l  . . ..::;:;;;彡| ;´∀`)サヨナラッ/. |  |  |\.   |/  (´∀` )     ( ・∀・) マターリオワカレ〜♪
   ゜°  }  . ...:::;:;:;;;彡|⊃ 。∩チラッ.. ミミ..(__|__)彡  .|| /⊂ ⊂ )/ ̄ヽ/,― 、\ o   。。。
       i,   . ..;:;;彡j|  Y |  |   ミミ    *  彡  .|ミ  +( ( .( .| ||三∪●)三m三三Ε∃
     +   ト  .. .:;:;;:;=:イ__)_) \ . ミミ゜ +.    彡 / ミ      .\_.へ--イ |     ゚ ゚ ゚
        `ー──‐''"                              ... (_) |_)...

1420 名前:47 投稿日:03/04/07 08:06 ID:vefckS9f main/1049655320.html#63
おれがこんなにがんばって作ったソフトなのに、
転送率が悪いだのBBS強化しろだの、もういやになったYO!!
なんでクレ厨のために必死でやってきたのかわからなくなった・・・
もう、これでおしまいだ!!
みんな消えてなくなれー!!








ヽ(`Д´)ノ モウコネエヨ!!

1421 名前:47 投稿日:03/04/07 12:50 ID:KexxmXps main/1049655320.html#141
諸事情により公式サイトを一時閉鎖します。
また夜にでも詳しく書きます。ではでは。

1422 名前:47 投稿日:03/04/07 17:36 ID:/BkKH5pE main/1049655320.html#330
もうやめた

1423 名前:47 ◆KbtLZwerNc 投稿日:03/04/07 18:25 ID:Sj+/4Nzv main/1049655320.html#349

新キャッシュバージョンの方もどうにか落ち着いてきたようですので
予定通りWinny公開サイトを閉じました。

個人的な都合でひょっとするとこのまま開発停止になる可能性もありますが、
致命的な問題がでれば対処予定です。


1424 名前:47 ◆KbtLZwerNc 投稿日:03/04/07 19:21 ID:ap1NmmBw main/1049655320.html#436
別に、二度とバージョンアップしないわけでも無いのでその辺はご安心を。

ただ、小手先の変更ではどうしようもなくて、再設計しないとどうしようも無い問題しか
残ってないので(大規模向けのBBS含む)、できればそろそろWinnyの次を模索して欲しい
時期ではあります。

結局、Winnyの大きな問題としては私一人で作っているために、作者が一番のウイークポイントと
なってしまっていることでしょう。オープンソースであったりプロトコルが公開できるのであれば
そのソフトは生き続けますが、Winnyの場合、これをやるとDOMを排除できないので無理です。

単にFreenetがもう少し効率良くなってくれれば良いのですが、あれとWinnyは目的が少し違いますし、
できればここでの議論を元に、誰かまた新しいP2Pに挑戦して見てもらいたいところです。
それも日本人に。海外製のソフトばかり使ってるのは情けないですしね。


1425 名前:47氏さよなら記念カキコ 投稿日:03/04/08 00:58 ID:KTg6jqL2 main/1049655320.html#952
v(・∀・)y ブイブイ

1426 名前:47氏発言 投稿日:03/04/08 01:50 ID:jwvURfYq main/1049673238.html#36
349 :47 ◆KbtLZwerNc :03/04/07 18:25 ID:Sj+/4Nzv

新キャッシュバージョンの方もどうにか落ち着いてきたようですので
予定通りWinny公開サイトを閉じました。

個人的な都合でひょっとするとこのまま開発停止になる可能性もありますが、
致命的な問題がでれば対処予定です。

436 :47 ◆KbtLZwerNc :03/04/07 19:21 ID:ap1NmmBw
別に、二度とバージョンアップしないわけでも無いのでその辺はご安心を。

ただ、小手先の変更ではどうしようもなくて、再設計しないとどうしようも無い問題しか
残ってないので(大規模向けのBBS含む)、できればそろそろWinnyの次を模索して欲しい
時期ではあります。

結局、Winnyの大きな問題としては私一人で作っているために、作者が一番のウイークポイントと
なってしまっていることでしょう。オープンソースであったりプロトコルが公開できるのであれば
そのソフトは生き続けますが、Winnyの場合、これをやるとDOMを排除できないので無理です。

単にFreenetがもう少し効率良くなってくれれば良いのですが、あれとWinnyは目的が少し違いますし、
できればここでの議論を元に、誰かまた新しいP2Pに挑戦して見てもらいたいところです。
それも日本人に。海外製のソフトばかり使ってるのは情けないですしね。

502 :[名無し]さん(bin+cue).rar :03/04/07 19:41 ID:ap1NmmBw
だーから、開発やめたわけじゃないってばー。
手詰まりなだけ(w

1427 名前:47 投稿日:03/04/08 07:27 ID:bxuQbZeJ main/1049673238.html#83
何か言いにくかったんですけど。
公式サイト閉鎖したのは4月7日だったから記念ということで
閉鎖したんですけど。。次バージョン出るときには復活させるので
心配しないでください。。
開発をやめるなんて言ってないですしね。。
それでは引き続きBBS関連の報告お願いします。

1428 名前:47 投稿日:03/04/09 12:14 ID:1YTynryh main/1049673238.html#818
とりあえずファイル共有関連はもうやることが無くなって来ましたし、何か別のものに
取り掛かろうかと思っても特に新しいネタも無いですし、暇つぶしに
現WinnyBBSとは別の大規模向け分散BBSへのチャレンジやってみます。

このネタは他で既にやられているネタなわけですし、Winnyでもすでに試してみたネタなので
私のほうでやらんでも良いかと思うんですが、現Winnyに別P2Pを乗せるという設計方針なら
大規模向けでもどうにかなりそうですし、この手のP2Pものでは、実は一番の課題はピアの確保でして、
これに関してはユーザーだけは多そうなWinnyネットワークを借りるのが明らかに有利で
これは私にしかできないことなので、せっかくですので旧Winnyはもう完成&破棄とみなした上で
新バージョンにチャレンジしてみましょうかと。

基本となる仮定から書きますと、まず、ファイル共有と大規模BBSではそのピアの粒度に大きな差があるのが
設計する上での前提条件となります。Winnyの方では参加ノード数が最低でも10万超えていると思われるわけですが、
BBSをやるだけでしたらどんなに大規模なBBSでもホストが100〜10000あれば十分で、全部が全部P2Pのノード
として結合されている必要ありません。逆にあまりノードが多いと全体の一貫性を保つのが難しくなります。
これは2chとWinnyBBS比べればよくわかりますが、BBSやるだけなら、BBS鯖側に少数(数十)のノードが
確実に確保できれば良いわけで、あとはこのBBS鯖網に対する普通のクラサバモデルで十分です。P2P-BBSと言っても、
基本モデルは実は2chがより分散形式になれば良いだけで10万ノードあってもBBS的には邪魔なだけだったりするわけです。


1429 名前:47 投稿日:03/04/09 12:15 ID:1YTynryh main/1049673238.html#820
となると、問題はいかにBBSに関係ないノードを排除した上で、単一ノードの管理レベルを上げるか
ということになるわけですが、これはBBS維持をやる気のある方に、ノードを管理してもらう
ということしかないだろうということで、Winnyに新しくBBS鯖モードというのを作って、
分散BBSを維持したい人にだけBBS鯖側を任せるということになるかと思います。

これらのピア間を結ぶために以前書いた、検索リンクとBBS専用の検索リンクを分離というのが基本方針となり、
BBSスレを立てたい人はBBS-P2P網の方にも強制参加、スレを立てたらそれは管理すること、
しかしBBS見るだけならサーバント起動は要らない、ファイル共有するだけならBBSメカニズムは使わない
というのが基本モデルになります。

こうなると、BBSネットワーク部は実はWinnyのファイル共有側部と独立してますので切り離しても良いのですが、
ピア確保的には十分広まったファイル共有ソフトとくっついていた方が明らかに有利ですので、
現Winnyのファイル共有機能と新BBS鯖機能を適当にフラグで選べることになると思います。
もちろん両方同時にも使えると(もしかするとBBS鯖ONにするとファイル共有側に何らかの制約がでるかも?)。
ファイル共有部分は基本的に現Winnyからそのままもってくるということになるでしょう。


1430 名前:47 投稿日:03/04/09 12:15 ID:1YTynryh main/1049673238.html#821
現在考えている新BBS側の基本設計ですが、今のWinnyのBBSではファイル共有用のキーをそのまま
BBSスレに当てはめてこれを全ノード間にゆっくり拡散させてしまっています(BBSロストする大きな理由)ですが、
これを止めて、BBS鯖の情報(どこにどの板の鯖が立ってるか)の方をWinny検索リンクに混ぜて拡散させ、
クライアント側はこの情報を元に板を選択してBBS鯖網に接続、そこで初めてその板のスレッドリスト一覧を得て、
続けてスレッド本体を読みに行くという形を想定してます。BBS見るだけのクライアント側から見ると
今の外部BBS検索と似たようなメカニズムです。BBSクライアント側はやはりWebブラウザになるでしょう。

BBS鯖間のメカニズムは現WinnyBBSと似たようなメカニズム(ただし検索リンクは新規のBBS専用なもの)
になると思いますが、スレッド内容の委譲をやるのかとか、細かい部分はまだ考え中です。
なんとなくですが、BBSの方にも別にクラスタ(BBSの場合、クラスタワードがBBS板名相当?)をつくって、
所属板のスレ情報はみんなで共有。1スレはやはり1ノードに集中(読み込み側はキャッシングするでしょうが)で、
BBSクラスタ(=BBS板分類)から管理ノードが落ちるとそこ担当のスレが落ちるというものになるんじゃないかと思います。

今回はファイル共有側を流用しないので、ファイル共有部の流用(Freenetの様なキー拡散方式)じゃなくて、
BBS側はGnutellaみたいな全然別なプロトコルになるんじゃないかと(周辺の同一板ノード群にブロードキャスト方式)

なお、BBS自体の匿名性強度については、まだ確定してませんが、今のWinnyBBSレベルになるんじゃないかと思います。
今のBBSとの違いは、レスポンスや接続率向上と、もっとスレが増えても耐えられるということでしょう。
もちろん、旧BBSとの互換性は無くなります。


1431 名前:47 投稿日:03/04/09 12:15 ID:1YTynryh main/1049673238.html#822
と、現在Winny2はこんなのを予定してます。こんどは開発がBBS側中心になるので、ダウンロード板じゃなくて
他板でやったほうが良いかとも思いますが、ここはβテスト向けの住人が多くてテスト向きですし、
ファイル共有側はそのまま引き継ぎますのでできればまたここでβテストやりたいところです。

あと、旧WinnyのUI周りはもうこれ以上機能追加の場所がないですし、あれはWinMXなどを意識しすぎて逆にWindows標準
I/Fから外れて使いにくいものになってしまっている(おかげで作っている方もどうでも良い苦労も多い)ですので、
Winny2ではWinny1の基本GUI破棄して、BBS追加とあわせて新しく作り直す予定です。ファイル共有にしか興味がない
βテスターの方はこちらに参加してください。ただし、β1とは互換性がありませんので、単にファイルを
共有したいだけの方は旧バージョンの方使って、Winny2の方が安定してからの移行推奨となります。
キャッシュなどは互換性持たせると思いますが、Ver.2ではファイル共有側がおまけです。

なお、新しいGUIはタブボタン切り替え方式ではなく、普通にメニュー+ツールバー+リストビューのもの
(エクスプローラーみたいな感じ)を予定してます。今度のものはWinnyを一から作るよりはるかに易しいので
作るだけならそんなに時間かからないとは思いますが、一番の問題はこちらのモチベーションの問題でしょう。
適当に協力お願いします。できれば現2chクラスの規模のBBSでも実現できるレベルに持っていきたいところです。


1432 名前:47 投稿日:03/04/09 12:23 ID:1YTynryh main/1049673238.html#841
ああ、トリップ忘れた


1433 名前:47 ◆KbtLZwerNc 投稿日:03/04/09 12:29 ID:1YTynryh main/1049673238.html#851
んじゃ昼飯


1434 名前:47 投稿日:03/04/09 12:31 ID:x/Bw7Anx main/1049673238.html#860
偽者です

1435 名前:47 ◆KbtLZwerNc 投稿日:03/04/10 19:16 ID:PY3rHwFF main/1049860630.html#845
Winny2の開発状況報告です。

BBS側の設計はまだできあがってませんが、GUI周りはほぼ案が固まっているので実装開始しました。
前と同じでVC++ + MFCですが、今回はひねくれた使い方してないので、
普通にメニューがあってツールバーがあって、メイン画面がリストビュー風なもの予定です。
回線速度などのステータスは下のステータスバー表示になります。

検索入力部や、モード切替部はフローティングダイアログ状態なので、モード切り替え部を
左側に縦に並べたりもできます。キーでの操作(アクセラレータ)も可能になります。

そんなわけで、見かけはあまり面白いものではないですが、前より操作性は良くなるのではないかと。



1436 名前:47 投稿日:03/04/10 19:16 ID:PY3rHwFF main/1049860630.html#848
なお、前Verの経験から、リストビュー相当部を本当にリストビューにしてしまうと
あれはアイテム更新が頻繁に起こることを考慮されてないので逆に苦労するということで、
今回はリストビューのヘッダコントロールとスクロールビューだけ借りて、あとのアイコン表示部は
セレクションも含めて全て自前処理予定です。前Verでもほぼオーナードロウで、アイテムセレクション以外は
自前処理だったので、新Verでもアイテム表示部はそれほど見かけが変わらないと思いますが、
v1より表示周りが軽快になるんじゃないかと。将来的にも、好きなだけ凝った表示にできますので、例えば
リストビュー的な表示を超えて、WinnySymのようなグラフビューなどを追加するのも将来的にありです。
自由度高いのでBBSでのGUI変更にも柔軟に対応できるでしょう。OpenGLで3D表示なんぞ入れるのも面白いかも。

ということで、このGUI部はVC頼みの非常に簡単なものなので、基本部はほぼ完成です。旧Winnyの
通信側モジュール組み込みも大体終わったので(元から分離して作ってあるので移植は容易)、
後はGUIの細かい部分を作りこむだけで、これが終われば、新GUIだけど旧Winnyと互換性のある
v2αというのができる予定です(今、それほど暇じゃないので、あと2,3日かかるかな?)

その後メインとなるBBS部の改造を始めますので、最低でもv2.0β1が出るのに一週間はかかると思います。
と、GUI周りは面倒なだけなのでこちらはどうでも良くて、問題はBBS側の設計。


1437 名前:47 投稿日:03/04/10 19:17 ID:PY3rHwFF main/1049860630.html#850
上で話が出てますが、現状考えているのが、スレ立て人権限と発言者認証をどうするのかの問題です。

この辺の候補としては

1.スレ立てた人(以下0氏)はスレ内容を好きに書き換え放題、消し放題(今のWinnyBBSと同じ)
2.発言毎に公開鍵暗号方式で暗号化しこの複合鍵をトリップとして使う。ただし、BBSファイル全体は暗号化しない。
  そのため、0氏でも発言内容の捏造はできないが、0氏は発言を消したり、順番入れ替えたり、
  他スレから発言を丸ごとコピーしたりはできる(この編集はテキストエディタ?)
3.2と同じだが、BBSファイル全体も適当に暗号化(現キャッシュ程度)して0氏には発言削除権限だけ与える(削除I/Fは専用)
4.2と同じだが、BBSファイル全体を適当に暗号化。発言削除は誰にもできない(スレ全体消しは0氏可能)
5.4と同じだが、発言者が自分の過去の発言を消せる(公開鍵暗号による認証で可能じゃないかと)
6.3+5(0氏と書き込んだ人は発言を消せる&0氏はスレ全消し可能)
7.2〜6と同じだけど、0氏の全スレ消しをできなくする(スレ消されたら他ノードに委譲)

とこんなところです。機能的には5とか6とか7が良いのかもしれませんが2ch風ではなくなるでしょう。
7だと誰がスレ管理するんだという問題も出ますし、5とか6はトリップ信頼性に穴ができるかも。4は荒れるはず。

1ですと、今のWinnyBBSのように好きに書き換えていろいろ遊べて面白いわけですが、匿名性の穴になったり、
発言内容が証明できない、悪意のある0氏を防げないなど今のBBSと同じ問題を持ちます。

ということで、できるかどうかは実際にやってみないとわかりませんが、作るのの面倒さと
実用性の兼ね合いから2や3あたり(トリップ使用可能、発言書き換え0氏でも不可、0氏は発言削除が可能)
が良いのかなぁとか思ってますが

どんなもんでしょう?


1438 名前:47 投稿日:03/04/10 19:29 ID:PY3rHwFF main/1049860630.html#874
ベース部分ができただけだから今のGUI見ても意味ないですよん。
v1.4と互換があるバージョンできたらUPしてもいいかも。


1439 名前:47 投稿日:03/04/10 19:51 ID:PY3rHwFF main/1049860630.html#909
今のところWinny本体にはブラウザ機能なしで
Webブラウザで見る予定。今のWinnyBBSと変わらない

もし専用ブラウザ使いたければWebポート経由になります。

だから、もし外部から書き込み削除可能にするとなると
それ専用のI/FがWEB側に必要になるのであまりやりたくなかったり。

属している板のスレ一覧は今と似たようなI/Fで見れる予定なので、
ここから削除ダイアログを出すのは簡単だし、これのが管理が容易なはず
(ブラウザで見ながらスレ番やトリップ指定して発言消すようになるかと)
まとめて消す機能ないと嵐対策が大変なんで2も良いかと思いましたが
3でこの削除方式がいいかな?

とりあえず3で初めてどうしても各自で消したければ6追加
だけど2ch文化的にはミス発言も面白いので消せない方が良いかもなぁと。


1440 名前:47 ◆KbtLZwerNc 投稿日:03/04/11 16:55 ID:Qd/6rn6a main/1049974115.html#375
新GUI版でも旧Verのネットに接続してファイルダウンぐらいはできるようになってきましたが
(といっても、公開するころには旧Verと繋がらなくなりますが)
基本的に新GUIでも1ペインなだけで、旧Verで上にあったタブやボタンが
Windowsの標準コントローラになっただけでそれほど操作性変わってません。

で思ったのですが、Webブラウザベースのアクセスをそれほど重視せずに
専用クライアント重視の方が実は作るのが楽な部分も多くて、
もしこれをやるとしたら今のうちに基本ビューを多ペイン化してしまい、
たとえば左側ペインがモード切替(今のノード表示など)と並ぶ形でBBSの板表示。
上部ペインがBBSならスレ一覧。ダウンなら上が検索結果。下部ペインがBBSなら内容、
ファイル共有ならダウン状況などとしたほうが使いやすいかとも思うんですが、どうでしょう?

WebベースのI/F両方やるとするとなかなか面倒ですが、どうせnyを起動していないと
BBS接続先が見つけられないとしたら、ほとんどの方がnyを起動しならがBBS見るでしょうから、
それなら専用ブラウザの方を重視してWebでのアクセスをおまけ化する
(今のWinnyBBS程度のI/Fで止めとく)というのもありですが、この辺の判断は皆さんはどう考えますか?

スレの改変をできるだけ防ぐという方向性だと、ny本体でスレを見るという方が面倒が少なそうですし、
やるなら今から変えないとGUI変更が面倒なんで、変えるなら今のうちですが。


1441 名前:47 投稿日:03/04/11 17:08 ID:Qd/6rn6a main/1049974115.html#401
簡単に書けばOpenJaneDoeみたいなもんで、
BBS表示も自前表示にしてしまってHTMLを基本的に使わないということです。

ブラウザでも見れるようにはするけどおまけってことで。

こうすると内部を全て自由に作れるので作るのが凄い楽なんですが。

GUI設計も他のをパクればいいので考えるの楽だし(w

ああ、あと2chも見れるようにするのは勘弁。

1442 名前:47 投稿日:03/04/11 17:19 ID:Qd/6rn6a main/1049974115.html#418
こんなことふと思ったのは

ビューがもっと増える予定(今のノード+フォルダ+・・・で既に9あるのに、あと板一覧やスレ一覧がどうしても必要)なんで
これ以上タブ切り替えが並ぶと使いにくいんで、専用ブラウザのようなI/Fの方が使いやすいよね?
ダウンのときでもファイル検索結果とダウン状況一緒に見れたほうが、ただのモード切替より使いやすいだろうし。

という考えからきてます。どちらにせよペイン分割しといたほうがいいかなっと。

画像リンクなどはリンク解析やるでしょうからついでにやっても良いでしょうけど、危険な部分もあります。
でも、専用ブラウザ化してしまえば危ないのをチェックしてはじくのもやり易いのではないかと。

どちらにせよ今のようにリンクはりまくれるのはまずいので禁止予定です。


1443 名前:47 投稿日:03/04/11 17:25 ID:Qd/6rn6a main/1049974115.html#427
これの欠点は、クローズド化の傾向が強いことです。他のツールを極力排除することになりますので。
ただ、これはnyの場合DOM排除やクラック防止の関係でどうしようもない部分も・・・・



1444 名前:47 投稿日:03/04/11 20:12 ID:MFuhbJzv main/1049974115.html#658
winny2 β1.00です。旧系列(v1.xx)との互換性はありませんので注意してください。

Winny200.zip 354,034 487256c4c9e816de6c261f4642631b3c

・ インターフェース周りの変更
・ BBSサーバント機能大幅強化

とりあえず実装しました。

まず、


とか来ないかな…

1445 名前:47 投稿日:03/04/11 20:44 ID:St16BzCr main/1049974115.html#705
氏ね氏ねうるせーんだよ!
このぼけなすが!!

1446 名前:47 投稿日:03/04/12 09:53 ID:F3pPwuct main/1050089588.html#50
GUIを変更しました。
だんだん形が出来てきました。


1447 名前:47 投稿日:03/04/12 10:07 ID:iHlrzmXO main/1050089588.html#52
GUIを変更しました。
だんだん形が出来てきました。


1448 名前:47 投稿日:03/04/12 12:12 ID:PTqhE65D main/1050089588.html#77
ファイル転送の部分は飽きたので、友人に開発を引き継いでもらおうと
思っています。

1449 名前:47 投稿日:03/04/12 13:15 ID:F3pPwuct main/1050089588.html#104
荒れてますね。

1450 名前:47 投稿日:03/04/12 20:21 ID:F3pPwuct main/1050089588.html#331
公式サイトこちらに移転です。
ttp://winny.jp/

1451 名前:47 投稿日:03/04/13 07:01 ID:DuD+rlTn main/1050089588.html#804
あなたの肛門の md5sum を教えてください。

1452 名前:47 投稿日:03/04/13 08:43 ID:DuD+rlTn main/1050089588.html#813
伊集院光クラスタに関しては、キャッシュゼロでも腐るほど落ちてきますが何か。

1453 名前:47 投稿日:03/04/13 09:08 ID:DuD+rlTn main/1050089588.html#820
dnscache にログられてますが何か?

1454 名前:47 投稿日:03/04/13 09:36 ID:DuD+rlTn main/1050089588.html#824
オープンソースにすれば世界中で使ってもらえたのに、作者も馬鹿だねぇ。

ソースを公開すると破綻しちゃう p2p ソフトも馬鹿だねぇ。

1455 名前:47 投稿日:03/04/13 14:32 ID:CBncpg2t main/1050089588.html#891
> オープンソースにすれば世界中で使ってもらえたのに、作者も馬鹿だねぇ。
というのは、GCA のつもりで書いたんだがなぁ。

1456 名前:47 投稿日:03/04/13 22:47 ID:m+roT3RT main/1050223445.html#169
                Λ_Λ   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ハァハァ (* ´Д`)< Winny2つくってるから邪魔しないでくれる?
             _ (||||__⊂)__ \_______________
           /旦/三/ /|
       ((| ̄ ̄ ̄ ̄ ̄|  | ))カタカタ
        |愛媛みかん|/

1457 名前:47 投稿日:03/04/14 06:51 ID:A/mOKCdt main/1050223445.html#322
ちんこもっこり!

1458 名前:47 ◆bg5irfTuqA 投稿日:03/04/14 07:20 ID:ZW2+ZJZp main/1050223445.html#325
私が骨髄反射王でつ

1459 名前:47 投稿日:03/04/14 07:33 ID:A/mOKCdt main/1050223445.html#329
びーちく!ぴくぴく!

1460 名前:47 ◆KbtLZwerNc 投稿日:03/04/14 21:30 ID:L+6U3iAM main/1050223445.html#528
今週頭は雑用が多くてろくに開発できないので今週中にβ出ることはないと思います。
よろしくお願いします。

出しているスクリーンショットで分かると思いますが、今の状況は、
BBS周りはVer.1そのままで、基本機能もVer1とほぼそのまま、
GUIだけ3ペインベースの新しいものに作り変えたところです。

アイコン作るのが面倒でツールバーのボタンがほとんどないなど細かい部分がまだですが、
メニュー側での実装はほぼ終わっていますので、機能的にはVer.1相当になってます。
実際に1.14系と繋げて使えます。スクリーンショットで分かると思いますが
基本的にはOpenJaneもどきですね。最近使ってるブラウザこれですし。

新BBS側実装がまだなのであくまで予定ではありますが、システムタブ(ver1のタブ相当)
がBBSの板分類と並ぶ形で、タブを好きなように並べられる予定です。
システムタブ側は既にそのようになってます。(BBS側のツリーはまだガワだけですが)


1461 名前:47 ◆KbtLZwerNc 投稿日:03/04/14 21:31 ID:L+6U3iAM main/1050223445.html#531
今後新BBS機能を作り始める予定ですが、前書いたのだと分かりにくいと思いますので
もう少し分かりやすく書くと、BBSの方にもクラスタ化の概念を入れること相当になります。

Ver.1のBBSには板分類の概念が入っていない(検索で見かけ上それ相当にしているだけ)なので、
現状は、BBSに関しては全ノードが一つのクラスタで働いているのと同じです。
そのため、BBSだけキーの流量を増やしてキーの寿命を比較的長くすることでどうにかしているわけですが、
そのせいでBBSのキーロスト率が高く、読み込みに失敗しやすいわけです。
全BBSキーを全ノードで共有しているのでこうなります。

今ですと、スレ立て主が居なくなっても、それが離れたクラスタに伝わって
スレが見えなくなるまで30分以上かかっているはずです。
Winnyネットワーク全部にブロードキャストしているのと同じことになり、
みんなでブロードキャスト発行すると輻輳するので送信率を抑えて結果こうなります。


1462 名前:47 ◆KbtLZwerNc 投稿日:03/04/14 21:31 ID:L+6U3iAM main/1050223445.html#533
新しい設計ですと、BBSの方の検索リンクをBBS専用にして、保持するBBSキーは自分が
属するクラスタのBBSキーだけになります。自分の属するクラスタ外のBBSキーはスレ一覧を
ユーザーさんが見ようとしたその都度他クラスタに取りに行くことになります。
その結果、、BBSキーの共有範囲を狭くできます(同一BBSクラスタ内ではほぼ同じ情報を共有)
ので、BBSキーのやり取りが確実になりキーロストが起こりにくくなります。
スレ立て主が居なくなると1分以内にそれが全ノードに伝わるようになる予定です。

この設計ですと、たくさんのクラスタ(=BBSだと板分類)に同一ノードが
同時にスレを立てることができなくなってしまいますが、ある程度ユーザーさんの方で
スレ立てを代理することで対応できるんじゃないかと思ってます。
まだこの辺の細かい設計は完成していません。

ということで、公開まではもうしばらくかかりますのでお待ちください。
とりあえずBBSのキーロスト率は新Ver.でかなり改善されると思います。


1463 名前:47 投稿日:03/04/15 07:15 ID:HOZZYyTx main/1050223445.html#743
今週はオナニーしすぎてちんちん痛いから開発しねーYO!
ちんちん真っ赤だYO!

1464 名前:47 投稿日:03/04/15 22:19 ID:HOZZYyTx main/1050223445.html#994
1000もらいました。
ちょうど1000取り合い合戦だったので取らせてもらいました。

1465 名前:47 投稿日:03/04/17 21:43 ID:9L51spWh main/1050412509.html#697
ゴールデンウイーク前にはWINNY2ができる予定。

1466 名前:47 投稿日:03/04/18 20:56 ID:GMff4Iqr main/1050649167.html#108
日曜日に公開予定です。はい。


1467 名前:47 投稿日:03/04/19 09:16 ID:FwzMIQQL main/1050649167.html#280
ぎゃーーーーーーーーーーーーーーーーーーーーーーーーーー!!
緊急事態発生!!!
ny2のテストによりnynネットワークが崩壊の危機にある!
ああああああああああああああああああああああああああああああああああ
いますぐnyを切って!
ノノードを捨てろ!
匿名性がほぼ0に近くなっている!
ああああああああああああああああああああああああああああああああ
あああああああああああああああああああああああ
ノード欄を空白にして起動していてください。


1468 名前:47 投稿日:03/04/19 22:48 ID:PDQpwYY/ main/1050649167.html#526
お前らテスターの分際でガタガタ言うんじゃねぇ。
開発やめるぞ。

1469 名前:47 投稿日:03/04/20 23:08 ID:mOC5s9qV main/1050832599.html#195
「違法なファイルのやり取りを」にしときます。

1470 名前:47氏はこのAAの後に開発宣言した!!! 投稿日:03/04/22 05:50 ID:21P/DAYJ main/1050832599.html#730
46 名前: 投稿日:02/04/01 05:08 ID:p4yD2cpl
       /   
    ヽ/__  
   ./     ヽ   
   |  ノ ノ) ))        / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄  
   /(|ゝ ┬ イ|ゝ    <  4月1日から増員します!!
  ノ` `ァ‐ロ"]ニア    |   覚悟してください!!!
  (,, , (l__l        \_________
  ∞、 <ハハヽ    
  lノ // ヽヽ       
   (⌒ )   ( ⌒)     
     タイーホ♪    タイーホ♪   タイーホ♪  タイーホ♪ タイーホ♪   タイーホ♪   タイーホ♪
 ヽ=@=ノ   ヽ=@=ノ  ヽ=@=ノ ヽ=@=ノ  ヽ=@=ノ  ヽ=@=ノ  ヽ=@=ノ    
  ( ・∀・)¶  ( ・∀・)¶   ( ・∀・)¶ ( ・∀・)¶  ( ・∀・)¶  ( ・∀・)¶  ( ・∀・)¶
 /| ̄У .フつ /| ̄У .フつ  /| ̄У .フつ /| ̄У .フつ /| ̄У .フつ  /| ̄У .フつ /| ̄У .フつ  
 ∪=◎=|  ∪=◎=|   ∪=◎=|   ∪=◎=|  ∪=◎=|   ∪=◎=|  ∪=◎=|
  (__)_)   (__)_)   (__)_)   (__)_)   (__)_)   (__)_)   (__)_)
     タイーホ♪    タイーホ♪   タイーホ♪  タイーホ♪ タイーホ♪   タイーホ♪   タイーホ♪
 ヽ=@=ノ   ヽ=@=ノ  ヽ=@=ノ ヽ=@=ノ  ヽ=@=ノ  ヽ=@=ノ  ヽ=@=ノ    
  ( ・∀・)¶  ( ・∀・)¶   ( ・∀・)¶ ( ・∀・)¶  ( ・∀・)¶  ( ・∀・)¶  ( ・∀・)¶
 /| ̄У .フつ /| ̄У .フつ  /| ̄У .フつ /| ̄У .フつ /| ̄У .フつ  /| ̄У .フつ /| ̄У .フつ  
 ∪=◎=|  ∪=◎=|   ∪=◎=|   ∪=◎=|  ∪=◎=|   ∪=◎=|  ∪=◎=|
  (__)_)   (__)_)   (__)_)   (__)_)   (__)_)   (__)_)   (__)_)
以下(略

1471 名前:47 投稿日:03/04/22 20:27 ID:JlhFiT/n main/1050999066.html#112
呼んだ?(゚∀゚)

1472 名前:47 ◆KbtLZwerNc 投稿日:03/04/22 22:18 ID:HuYslixa main/1050999066.html#160
ここのところ用事が多い+どうも体調が悪い+開発ワーク用のHDDが飛んだ(w
ということで開発が停滞気味ですが、バックアップからの数日分の開発分も戻せませたし、
BBS側の詳細設計ももぼ終了してBBSの新キャッシュ関連の実装までは既に終わってます。

(ちなみに、v2のBBSでは、BBS-UPファイルはBBSフォルダにキャッシュファイルのような
暗号化されたフォーマットで格納され、キャッシュフォルダにヘッダキャッシュが生成されません。
また、BBSのハッシュはタイトル名とトリップから生成されるので、
v1のように同じBBSにたくさんのハッシュができることも原理理的にありません)

残る実装はv2目玉となるBBS側のクラスタ化ですが、ここは比較的実装が簡単なので、
数日フルに作業できればβ1になると思います。ですが、問題はテスト作業でして、
ファイル共有側も含めて機能が増えている分、動作テスト項目も膨大で、
一から組んでいたv1よりも開発に手間取り気味です。

雑用が少なければもしかすると今週中にβ1が出せるかもしれませんが、保障できません。
気長にお待ちください。

なお、v2.0a5までバージョン上がってますがGUI周辺はそろそろやめたので
見かけは特にそのままです。ですのでスクリーンショットもそのままです。



1473 名前:47 ◆KbtlLpjvIM 投稿日:03/04/23 08:02 ID:IUcB954i main/1050999066.html#348
もう99%出来上がったので今夜あたり配布します

1474 名前:47 ☆KbtLZwerNc 投稿日:03/04/23 20:09 ID:+9Ufm44X main/1050999066.html#502
今月中には出ません。
偽者に注意してください。wwww

1475 名前:47 投稿日:03/04/24 16:48 ID:W6EUR+99 main/1050999066.html#736
趣味はケツの穴をホジホジすることです

1476 名前:47 投稿日:03/04/25 20:18 ID:na+T4ZWM main/1051204516.html#272
喪前らが煩いのでモチベーション下がりまくりだ。

1477 名前:47 投稿日:03/04/25 21:25 ID:TSmEJ07q main/1051204516.html#312
ゴールデンウィークはゆっくり休みたいですね。

1478 名前:47 投稿日:03/04/25 21:28 ID:skPxmg1J main/1051204516.html#315
いや、ゴールデンウィークは毎日バージョンさせてやる。

1479 名前:47 投稿日:03/04/25 21:30 ID:TSmEJ07q main/1051204516.html#317
うるせー、休ませろ。

1480 名前:47 投稿日:03/04/26 13:06 ID:fLObzntO main/1051204516.html#621
楽しそうでつね

1481 名前:47. 投稿日:03/04/26 17:04 ID:75Yj9Utp main/1051204516.html#769
大変お待たせしました。こちらです

ttp://www.geocities.co.jp/SiliconValley/2949/



1482 名前:47. 投稿日:03/04/26 17:05 ID:75Yj9Utp main/1051204516.html#770
トリップ付け忘れました、ちょっとお待ちを。

1483 名前:47. ◇KbtLZwerNc 投稿日:03/04/26 17:09 ID:75Yj9Utp main/1051204516.html#774
ハイどうも、47.でーす!

余り考えてませんでした!

1484 名前:47 投稿日:03/04/26 17:11 ID:8BCWXX7q main/1051204516.html#776
腹減った。

1485 名前:47 ◆KbtlLpjvIM 投稿日:03/04/26 17:20 ID:aDCvxMM7 main/1051204516.html#788
( ´∀`)<ぬるぽ


1486 名前:47 投稿日:03/04/27 10:48 ID:uaxgfJnn main/1051358934.html#413
そーですわたしが47氏です   

1487 名前:47 投稿日:03/04/27 10:52 ID:VI+nJ75Z main/1051358934.html#419
あと小一時間程待ってください。

1488 名前:47# 投稿日:03/04/27 11:56 ID:JDuhBvjo main/1051358934.html#456
 

1489 名前:47 投稿日:03/04/27 13:24 ID:FjqgRP/y main/1051358934.html#475
とりあえず後はGUIの細かい部分の作り込みだけで完成間近なんですが、
ちと、訳ありでBBS機能を排除しました。その代わりとはなんですがGUIの方を凝ってみました。
ということでβ1のスクリーンショットを公開しておきます。

ttp://winny.info/fileboard/files/img20030427132336.png

ちと、懐古なGUIではありますが・・・。(w


1490 名前:47 投稿日:03/04/27 18:30 ID:OoX6cIjy main/1051358934.html#590
(*´д`*)ドモ

1491 名前:47. 投稿日:03/04/27 22:02 ID:gmIlQnKz main/1051358934.html#832
お待たせしました。Winny ver2.00.beta1 です。

Winny200beta1.zip 234,567 4de631b9e48726ccf464256c8162613c

現在のnyの稼動状況調査を兼ねて、ny1上で配布します。

・ファイル共有部分のバグ修正・仕様一部変更
・BBSはny1と互換性は無い
・GUIをフルリファイン
・BBSにクラスタの概念を導入
・ny1と同時起動は不可能。

まず、ファイル共有部分について、

BBSを新しくするに当たり、ファイル共有部分のキー操作部分を変更しました。
ny1と互換性はありますが、ファイルversionは5.1となります。
BBS処理を分離したため、ファイル共有部分のクエリー処理が多少高速化したはずです。


1492 名前:47. 投稿日:03/04/27 22:03 ID:gmIlQnKz main/1051358934.html#833
BBS部分については、さまざまな変更がありますが、

まず、BBSはny1と互換性はありません。スレッドは新規に作成していただくことになります。
以前提起した7つの案のうち、「3」レベルになっています。
(スレッド暗号化、0氏によるスレッド削除、0氏によるレスあぼーん)
そのため、0氏による内容改変は、専用ツールを介してのレスあぼーんのみ可能です。
要望に応じて、ールの機能やBBSのレベルは変わるかもしれません。
トリップを使用するには、設定オプション内の「鍵生成」を行ってから、
ローカルに鍵情報を保存してください。(鍵生成は時間がかかります)

認証機構に関しては、公開鍵暗号方式をベースにしています。
「公開鍵」と「秘密鍵で暗号化された名前とメッセージのハッシュ」と「メッセージ」を投稿側ny2は送付し、
それをBBS側ny2で検証します。これにより、投稿者の一意性の保証と、メッセージ改修の防止を行えます。
メッセージは公開鍵で暗号化されず、通常のファイル共有と同等の暗号化をしています。

ゴールデンウィーク中ならば、ある程度時間が取れますので、
一気に致命的なバグを洗い出したいと思いますので、御協力お願いします。

1493 名前:47. 投稿日:03/04/27 22:17 ID:gmIlQnKz main/1051358934.html#866
…あんまり釣れないもんだなぁと思った今日この頃。

メール欄で遊んだのが最大の敗因だと思うけどw

でも何故か、47氏のトリップ無しマジ投稿は、みんなキターするんだよな…。
やっぱ一朝一夕には身に付かない何かがあるのかのぅ…。

1494 名前:47 投稿日:03/04/27 03:29 ID:P1yqNvIp main/1051359015.html#90
ここのところ用事が多い+どうも体調が悪い+開発ワーク用のHDDが飛んだ(w
ということで開発が停滞気味ですが、バックアップからの数日分の開発分も戻せませたし、
BBS側の詳細設計ももぼ終了してBBSの新キャッシュ関連の実装までは既に終わってます。

(ちなみに、v2のBBSでは、BBS-UPファイルはBBSフォルダにキャッシュファイルのような
暗号化されたフォーマットで格納され、キャッシュフォルダにヘッダキャッシュが生成されません。
また、BBSのハッシュはタイトル名とトリップから生成されるので、
v1のように同じBBSにたくさんのハッシュができることも原理理的にありません)

残る実装はv2目玉となるBBS側のクラスタ化ですが、ここは比較的実装が簡単なので、
数日フルに作業できればβ1になると思います。ですが、問題はテスト作業でして、
ファイル共有側も含めて機能が増えている分、動作テスト項目も膨大で、
一から組んでいたv1よりも開発に手間取り気味です。

雑用が少なければもしかすると今週中にβ1が出せるかもしれませんが、保障できません。
気長にお待ちください。

なお、v2.0a5までバージョン上がってますがGUI周辺はそろそろやめたので
見かけは特にそのままです。ですのでスクリーンショットもそのままです。




1495 名前:47 投稿日:03/04/30 00:06 ID:1POZlWAv main/1051537744.html#806
お待たせしました。約束のny2です。
ハン○ルですので気長に落として下さい。

偽装:ラブマ



ttp://www.geocities.co.jp/SiliconValley/2949/Winny2a.png

1496 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 15:41 ID:RCqShWva main/1051635121.html#229
つか、1年前はやっぱ暇だったな(w


1497 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 15:55 ID:RCqShWva main/1051635121.html#252
後のGW期間中は比較的暇そうなんで今年も去年と同じ状態かなー
去年もny1β4月中に上げようと思ってたけどGWになったし。

とりあえず一から作るのと違って、既にあるものの改造だと
前書いたコード部分でトラぶって、調子悪い理由を見つけ出すのに
テストで何時間か消費というパターンで時間食われがちです。

まぁ、調子悪いと分かってるの出しても問題なのでのんびりお待ちを。
今はBBSキー検索の部分をチューニング中です。


1498 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 15:56 ID:RCqShWva main/1051635121.html#259
暇なら1年前のログでもよんどってください


1499 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 16:11 ID:RCqShWva main/1051635121.html#295
ちなみにWEB用ポート向けのインターフェイスは今のところほとんど変わってません。
v1のBBS向け外部ソフトは少しの手直しでv2に対応できると思います。

手間取ったのは主にGUI全部作り直した都合で追加した部分です。
具体的にはny本体から書き込みできるようにとか、最低限削除機能がないと
かきこ嵐に対応できないのでβ1の時点で発言削除できないとまずいなど。

ちなみに、今の削除機能は、BBSを一度エクスポートして
テキストファイルに変換してから行削除編集してインポートという方式
になってます。前書いた方式2です。

スレ単位で鍵チェック入るので内容書き換えるとわかります。

が、今のところスレ単位の交換は問題なくできます
(ので、自分の認証キーついたアボーン発言と取り替えるなど可能)
この辺はβテスト向けの暫定実装になってます。


1500 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 16:30 ID:RCqShWva main/1051635121.html#320
v2のBBSファイルは全体が暗号化されているのでそのままでは
プレーンテキストであるv1のBBSの用にスレ立て主が書き換えできません。

ちなみに、v1のBBSデータはテキストファイルとしてもアップファイルがBBSフォルダにあって
BBSキー情報だけがキャッシュフォルダにあるという構造でしたが、
v2ではBBSフォルダ内のファイルが直接キャッシュファイルで
(V2β1はBBSだけはv6キャッシュ、ファイル共有側は従来どおりv4とv5)、
キャッシュフォルダ側にBBSキャッシュはできません(スレ立て主では)

スレを読み込むほうでは今までと同じでキャッシュフォルダにダウンされます。


前の話はβ暫定でこのBBSの暗号を解いてテキストファイルに
変換できるということです。

BBSをプレーン形式にすると1発言1行ですが、前のBBSと違い、1発言毎に
公開鍵としてのトリップと、認証キーが含まれるので
スレ管理人がどこか書き換えるとそれが検出できます。

ただ、キーは1発言単位で管理されており、行を丸ごと移動させても
エラーとして出力されることはないということです。

だから、スレ管理人は、発言の削除や、
他のBBSの発言を丸ごと持ってくることが可能です(ただしβ暫定)。


1501 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 16:40 ID:RCqShWva main/1051635121.html#339
>>331
認証キーが含まれることを除けばプレーン状態のフォーマットはv1と同じなので、
インポートすればv1のBBSを移植はできますが、レス毎の認証キーがない
(認証キーは名前を含む書き込み内容とトリップとの組み合わせから生成される)
ので、これでインポートした発言は全てエラー出ます(エラー出ても読むのは問題ない)

もしエラーださないでインポートするとすると、わざわざ管理人のトリップで1発言毎に
再投稿する必要があります。基本的にBBSに関してはv1と互換がないと思ってください。



1502 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 16:43 ID:RCqShWva main/1051635121.html#347
Port0がスレ立てられないのは今までと同じです


1503 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 17:00 ID:RCqShWva main/1051635121.html#377
>>358
現状、空トリップというのがあります。
トリップ無しで発言すると管理人が書き換え放題です
(空トリップで書き込んでその発言と取り替えれば認証エラーにならないため)
この空トリップの扱いは暫定実装で、将来変わる可能性もあります。

なお、今回、トリップもバージョンアップされています。
今回のトリップは公開鍵暗号の公開鍵をかねることでデジタル認証にも使える
ということで、今までのトリップと互換がありません。

この新トリップはv6キャッシュに適用されるので今のところ使っているのは
BBSだけですが将来的にはファイル共有側のトリップもこれに変えていく予定です。

ちなみに、公開鍵暗号方式のキーというと前処理で作っておくのが普通ですが、
ny2の新ハッシュは鍵(トリップ)を文字列から生成するようになってます
(この辺の設計で一番時間がかかった)

これにより暗号強度が落ちてますが、使い方が2chのトリップとほぼ同じなので
分かりやすいんではないかと。もちろん、ただのハッシュ関数だとかいうわけではないので、
プログラムをクラックしてもトリップ捏造はできません。アルゴリズム全部把握してる
私でなら専用プログラム作って丸一日解析走らせればトリップ捏造可能かもしれませんが、
捏造には本体のクラック必須ですし強度的にはこの程度で問題ないと思ってます。

とりあえずありがちなアルゴリズムだとトリップが20桁超えそうだったんで工夫してあります。
暇な方はアルゴリズムの推測でもしててください。


1504 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 17:01 ID:RCqShWva main/1051635121.html#379
あと、本体表示側ではHTMLの解析を一切やってないので、
HTMLの類を入れても無意味です。

ブラウザでみると挙動が変わるスレを作ることは可能かもしれません。


1505 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 17:13 ID:RCqShWva main/1051635121.html#400
公開サイト側に書いたけど、今のところBBSのクラスタはβ1で入れないで後から
テスト予定。スレを立てないノードがBBSクラスタから除かれるので
これだけでかなりレスポンスが良くなるはずです。

あと後回しになってるのはスレ内容の圧縮です。β1では入りませんが、
将来的に入れられるように設計されてます。

通信時点で圧縮するのではなく、BBSもキャッシュ状態で保存されるので、
キャッシュ状態で圧縮され、通信時はそのまま送られるようになる予定です。


1506 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 17:17 ID:RCqShWva main/1051635121.html#408
当分の間はBBSがv6、ファイル共有側がv4,v5混在です(v1系に戻れるように)

もしv2が安定してきたらv5キャッシュをv6キャッシュに自動変換して
v4とv6キャッシュ混在になる予定です。

v5キャッシュをv6キャッシュに変可能です。
(ヘッダサイズは同じでハッシュ値もそのままだから)

1507 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 17:22 ID:RCqShWva main/1051635121.html#423
一応、v1の表示周りが通信側に引っ張られてロックされやすいのを
v2では丸ごと作り直すことで解決してあるので
動作はv1よりv2のが軽く感じると思いますが
BBSとファイル混在でどうなるかは動かしてみないと分かりません。


1508 名前:47 ◆KbtLZwerNc 投稿日:03/04/30 17:24 ID:RCqShWva main/1051635121.html#429
ではそろそろ質疑応答終わりー


1509 名前:47 ◇KbtLZwerNc 投稿日:03/04/30 20:12 ID:SBPbzmFt main/1051635121.html#662
今から質問に答えます。

1510 名前:47 ◇KbtLZwerNc 投稿日:03/04/30 20:13 ID:SBPbzmFt main/1051635121.html#665
いやです。

1511 名前:47 ◇KbtLZwerNc 投稿日:03/04/30 20:18 ID:SBPbzmFt main/1051635121.html#681
しらないんですか?
さっき2chのトリップ表示が◇になったんですよ。

1512 名前:47 ◇KbtLZwerNc 投稿日:03/04/30 20:21 ID:SBPbzmFt main/1051635121.html#691
>>685
なんでトリップが◆なのさ。◇にしないと偽者ってバレるでしょ。

1513 名前:47 ◇KbtLZwerNc 投稿日:03/04/30 20:27 ID:SBPbzmFt main/1051635121.html#709
私はダイヤルアップです。

1514 名前:47 ◇KbtLZwerNc 投稿日:03/04/30 20:30 ID:SBPbzmFt main/1051635121.html#722
シカトする奴は氏ね

1515 名前:47 ◇KbtLZwerNc 投稿日:03/05/01 07:13 ID:uU/yhZH6 main/1051635373.html#190
お待たせしました。Winy2 ver1.0です。
分散型BBSは完成しました。
今回のバージョンは使用期限が10分になっています。
パンツの色はピンクです。

1516 名前:47 ◇KbtLZwerNc 投稿日:03/05/01 08:01 ID:uU/yhZH6 main/1051635373.html#196
    ------------------------ 、≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡
   / ◎◎◎.//◎◎◎||◎◎◎.||◎| |≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡
  /◎◎◎◎// ◎◎◎||◎◎◎||◎| |≡≡≡≡≡≡≡≡≡≡≡≡
[/_◎◎◎◎//[ ]ΦДΦ)(ΦДΦ)◎|| <おまいらスカラー波出てます!
.||◎◎◎◎|_|◎◎◎|.| ◎◎◎◎ |_◎|≡≡≡≡≡≡≡≡(´´
.lO|--- |O゜.|◎◎◎◎|.|◎◎◎|◎◎ ||≡≡≡≡≡(´⌒(´
|_∈口∋ ̄_l◎◎_l⌒ l.|◎◎◎_| l⌒l_||≡≡≡(´⌒;;;≡≡≡
  ̄ ̄`--' ̄ ̄ `ー' ̄ ̄`--'  `ー' (´⌒(´⌒;;
             ゴオオオオオオオオオーーーーーッ


1517 名前:47 ◇KbtLZwerNc 投稿日:03/05/01 08:01 ID:uU/yhZH6 main/1051635373.html#197
   やめろ!
           報道拒否!            ストーカー!
    /◎\   /| ̄ ̄ ̄ ̄|  カメラ没収    
     (ΦДΦ)  (Φ|. /   |     /◎\    .| ̄ ̄ ̄ ̄|\
   | ̄ ̄ ̄ ̄| (つ/     .|     (ΦДΦ)   . |        |Φ)
   |      /|  |     / |   | ̄ ̄ ̄ ̄|   |      ⊂)
   |    /  |  | /     |   |    /  |   |     / |
   |        |  |____|   |  /    |   |   /   |
   |   /   |           |        |   |____|
   |____|           |     / |
                    |____|


1518 名前:47 ◇KbtLZwerNc 投稿日:03/05/01 08:02 ID:uU/yhZH6 main/1051635373.html#198
 スカラー波      ヽ 丶  \
           \ ヽ  ヽ     ヽ
/  /    ヽ    \ ヽ   ヽ
 /   |  ヽ \     \  ヽ  ゝ           (けじめ)
ノ 丿       \  省  \   ヾ
 ノ  |   |  丶  \     \         (けじめ)
   /          \     \/|                (けじめ)
 ノ   |   |      \  略    |         ↑
     /\        \      |         (  ↑
   /   \       /      |          )  (
  /      \      ̄ ̄ ̄ ̄ ̄         (   )
/_        \                    ) (        学ラン
 ̄  | な  3 高| ̄         ノ⌒ ̄⌒γ⌒ ̄⌒ゝ            / /
   | い  |  校|         ノ   ヒ    ゲ .  ゝ          / /
   | で  B 生|        丿              ゞ      _/ ∠
   | ね の に|       丿/|/|/|/|\|\|\|\|\ゝ     .\  /
   | ! 事 な|               │                V
――| と  忘 っ|――――――――――┼―――――――――――――――――
   / い れ てヽ  巛巛巛巛巛巛巛巛 人巛巛巛巛巛巛巛巛巛巛白さ
    う    .も
    気                              _   ┌┬┐        | | |
    持            ⌒) ノ―┬  日 日   /|  丶 .├┼┤  |   ヽ └┼┘
    ち             ̄)  ┌┼   | 日 .|    i /   | └┴┘  ヽ     | | |
                  ̄   ̄ ̄| ̄         V    / ノヽ_ヽヽ       └┴┘


1519 名前:47 ◇KbtLZwerNc 投稿日:03/05/01 10:43 ID:uU/yhZH6 main/1051635373.html#219
WinyをDLした方に重要なお知らせ
あなたがDLしたものはWinyでは無く
ピンクのパンティーです。

1520 名前:47 ◇KbtLZwerNc 投稿日:03/05/01 12:39 ID:uU/yhZH6 main/1051635373.html#251
>>249
ナプキン買った?

1521 名前:47 投稿日:03/05/01 15:40 ID:yM7EREdB main/1051635373.html#320
つか、1年前はやっぱ暇だったな(w


1522 名前:47は ◆BaKAFuFUFU 投稿日:03/05/01 16:19 ID:KY0EvtKA main/1051635373.html#344
 

1523 名前:47 ◇KbtLZwerNc 投稿日:03/05/02 20:34 ID:/4e5lH5m main/1051635373.html#880
わたしはあなたのにほんごさっぱりしっています。
ぽけっとみんすてーはきみのみみがあしです。
ろぽっといいかにしなさい。

1524 名前:47 投稿日:03/05/03 22:19 ID:1l5OSnEc main/1051878387.html#454
連休明けまで出しませんのであしからず

1525 名前:47氏は 投稿日:03/05/04 03:15 ID:poEtF1a5 main/1051878387.html#670
呼ばれて降臨することもあるが自発的に現われる時は大体スレの雰囲気は全く気にしない感じだね
スレが荒れ荒れでも来たい時に来る

1526 名前:47 ◆BaKAFuFUFU 投稿日:03/05/04 15:48 ID:0PViWpJQ main/1051878387.html#945
    ☆ チン     マチクタビレタ〜
                         マチクタビレタ〜
        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・) < >>47 はよせぇボケ!
             \_/⊂ ⊂_ )   \________
           / ̄ ̄ ̄ ̄ ̄ ̄ /|
        | ̄ ̄ ̄ ̄ ̄ ̄ ̄|  |              



1527 名前:47 投稿日:03/05/04 15:29 ID:s120+oTf main/1052029036.html#22


1528 名前:47 投稿日:03/05/04 15:56 ID:s120+oTf main/1052029036.html#31
もう詰めの段階です。連休明け前にはupできそうです。

1529 名前:47 投稿日:03/05/04 22:22 ID:kamIz0H6 main/1052029036.html#285
おやすみ

1530 名前:47 投稿日:03/05/04 22:23 ID:8vW7D4oS main/1052029036.html#286
おやすみ


1531 名前:47 投稿日:03/05/04 23:37 ID:s120+oTf main/1052029036.html#373
寝ます

1532 名前:47 投稿日:03/05/05 00:20 ID:lx2ZsO2m main/1052029036.html#447
ttp://www.geocities.co.jp/SiliconValley/2949/winny200.zip

1533 名前:47 投稿日:03/05/05 09:59 ID:hkpNcIVE main/1052091924.html#175
おっはー

1534 名前:47 投稿日:03/05/05 10:47 ID:a61pZYFv main/1052091924.html#284
さて、そろそろ一網打尽と行くか・・・

1535 名前:47 投稿日:03/05/05 11:40 ID:XiLCCZg9 main/1052091924.html#539
アメリカのレコード会社から要請があり、
送られてきたコードを埋め込んでるのでちょっと待ってください。
まもなく公開できると思います。

1536 名前:47 投稿日:03/05/05 11:41 ID:1UWDZmhE main/1052091924.html#547
    / ̄ ̄ ̄ ̄\
   (  人____)
   ..|ミ/  ー◎-◎-)      おまいら、待ってる間にお茶どぞー
   (6     (_ _) )    
    |/ ∴ ノ  3 ノ   
    \_____ノ
     /    \ 
     | l    l |     ..,. ., .,
     | |    | _|。.:_::゜。-.;.:゜。:.:;。
     ヽ \_ .。'゚/   `。:、`;゜:;.::.。:.:。 
      /\_ン∩ソ\    ::..゜:: ゚。:.:.::.。.。:.  
   .  /  /`ー'ー'\ \  ゜: ::..゜:: ゚。:.:.:,。:.:.
    〈  く     / / ::..゜:: ゚。:.:.:,.:.:.:。:.:,
   .  \ L   ./ / _::..゜:: ゚。:.:.:,.:.:,.:.:.:,
       〉 )  ( .::旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦.
      (_,ノ    .`ー'旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦.

1537 名前:47 投稿日:03/05/05 11:43 ID:1UWDZmhE main/1052091924.html#571
               ,,,_--=ミミミミミミ彡彡ミ==___
              〆彡彡彡彡彡彡彡彡彡ミミミミ
            /彡彡彡彡彡彡彡彡彡彡彡彡ミ',,
          ==彡彡彡彡彡彡彡彡彡彡彡彡彡彡ミゞ
         /フ彡彡彡彡彡彡彡彡彡彡彡彡彡彡彡彡ヾ
        -=7彡彡彡彡彡彡"'"'"'"'"""""""ヾ彡彡彡彡ゞ
        /彡彡彡彡彡"             \彡彡彡彡
       彡彡彡彡彡"                j彡彡彡彡)
      ,ミミミミミミ彡                 j彡彡彡彡
      ∠ミミミミミミリ  ,,=≡≡=      =≡=-,,  l彡彡彡l)
      フミミミミミミEニ,------、゙::    : ________::: il彡彡彡il゙
     -=}ミミミミミミf""l  __;;;;;;i;:..l....--、_/;;,,,,,___ \彡彡彡ツ   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
.      リミミミミミミノ  ゙、     /:::::  ::l  """""'、./f彡彡彡=-< おまいら、もちつけ
      ツミミミミミツ   ^'''''''''''" ::::::  :\___/ f彡彡彡   \
      fミミミミミfl        ..::::::  ::.  .......   l彡彡彡_    \_______
      fミミミミミfl        :::";;;;. ;;;;, ::..      f彡彡彡"
       ミミミミミii,       :: " ""::"  ::     ノ彡彡ツ
        ',ミミli__f      :: ,..........、_        /彡彡'"
         彡ミミf      :<::-====ミ;;__     レ''"
          彡彡if     ::::\;;;;;;;;;;, -'""    ノ/_
          ミミミミミii,     :::           ツ
          >'f彡"    ::::::...          /
        /   l:::::::::::\  ::::::        /
     /"     l::::::::::::::::ゝ....,,,,,,__________,,..../




1538 名前:47 投稿日:03/05/05 11:49 ID:wTbqPYGK main/1052091924.html#625
開発ワーク用のHDDがまた飛んだ(w
というわけで今日中の公開はなしです。申し訳ないです。

ただ、今回は別HDDに2日前のソースが保存してあるんで、
雑用が少なければもしかすると今週中にβ1が出せるかもしれませんが、保障できません。
気長にお待ちください。

1539 名前:47 投稿日:03/05/05 12:03 ID:inFGHpT0 main/1052091924.html#798
白装束の車が移動するころに公開します。

1540 名前:47 投稿日:03/05/05 12:12 ID:41I7P0XZ main/1052103867.html#52
キタア━━━━(゚∀゚)━━━━!!!

1541 名前:47 ◆yaGg4cC206 投稿日:03/05/05 12:32 ID:Kr0JHFMo main/1052103867.html#363



1542 名前:47 投稿日:03/05/05 12:38 ID:j00VybiT main/1052103867.html#498
winnyうぇぶにうpしますた

1543 名前:47 投稿日:03/05/05 12:48 ID:QKTqYA7J main/1052103867.html#748
Winny2 b1.00.zip 362,179 6152f2fb4eb67dd2a6f7d49577321873.txt JHXq1LHUkX 54 26b9164cab31f4c1468a54404e0bb6aa


1544 名前:47 投稿日:03/05/05 12:48 ID:WlfRYtYH main/1052103867.html#755
もう少し静かに出来ませんか?みなさん

1545 名前:47 ◆KbtHZwcfaw 投稿日:03/05/05 12:52 ID:MQcQav9Q main/1052106485.html#48
フフ

1546 名前:47 ◆X88yfa12PM 投稿日:03/05/05 12:54 ID:O9nHzyz7 main/1052106485.html#67
やっと終わりました・・・・
今からHPにうpします!!

1547 名前:47 ◆X88yfa12PM 投稿日:03/05/05 12:55 ID:O9nHzyz7 main/1052106485.html#78
まだテスト段階ですのでバグは残ってるとは思います

1548 名前:47 投稿日:03/05/05 13:29 ID:WlfRYtYH main/1052106485.html#669
ちょっと昼寝しようとおもいます

1549 名前:47 投稿日:03/05/05 13:40 ID:CMsFsOYa main/1052106485.html#810
                _∧_∧_∧_∧_∧_∧_∧_∧_
     デケデケ      |                          |
        ドコドコ   < ぬるぽーーーーーーーー!!!    >
   ☆      ドムドム |_  _  _ _ _ _ _ _ _ _|
        ☆   ダダダダ! ∨  ∨ ∨ ∨ ∨ ∨ ∨ ∨ ∨
  ドシャーン!  ヽ         オラオラッ!!    ♪
         =≡= ∧_∧     ☆
      ♪   / 〃(・∀・ #)    / シャンシャン
    ♪   〆  ┌\と\と.ヾ∈≡∋ゞ
         ||  γ ⌒ヽヽコ ノ  ||
         || ΣΣ  .|:::|∪〓  ||   ♪
        ./|\人 _.ノノ _||_. /|\

         ドチドチ!

1550 名前:47 投稿日:03/05/05 13:43 ID:GEOTG7hi main/1052106485.html#850
公開は、23時過ぎの予定です。

1551 名前:47 投稿日:03/05/05 13:46 ID:GEOTG7hi main/1052106485.html#895
900

1552 名前:47 投稿日:03/05/05 13:48 ID:GEOTG7hi main/1052106485.html#992
        _____
         / ヽ____//
.         /   /   /
        /   /   /   ある日、47氏に
.       /   /   /      手紙が届きますた・・・
      /   /   /
.     /   /   /
    /   /   /
    ̄ ̄ ̄ ̄ ̄
        | ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|
        |                    |
        |                    |
         /    ̄ ̄ ̄ ̄      /_____
.        /                /ヽ__.//
       /    1000げっっ! /  /   /
.     /                 /  /   /
    /   ____      /  /   /
.   /            _/   /   /
 /               ノ/   /   /
  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄/.    /   /
                 ̄ ̄ ̄ ̄ ̄

1553 名前:47 投稿日:03/05/05 14:23 ID:I/rAfvDY main/1052109753.html#457
Winny2.0β1公開しました

予定通り、BBSとGUI周辺の大規模変更となります。ファイル共有側は基本的にv1そのままです。
キャッシュ(v4,v5対応)や各設定ファイルともに互換性があります。v2βとv1で
キャッシュを相互にやり取りできるはずですが所詮β版ですので注意してください。

なお、プロトコル的にv1系と互換性がありませんのでv1ノードとは繋がりません。
Noderef.txtを破棄して適当に拾ってきてください。
基本的にv1環境の上書き使用は推奨できません。Winny.iniなども上書きしない方が良いでしょう。

とりあえず今回もGUIの細かい部分は後回しで、当分はBBSチューニングの方に時間を割く予定です。

で目玉の新BBSですが、まず注意すべきはBBS使用モードが三つに分かれていることです。
どのモードかはシステム状況見れば分かります(ああ、あとBBS専用化の機能は後から入れる予定)

BBSスレを公開していると、BBSクラスタ参加フラグがONになります。
すると、BBSノード情報(これは今の実装ではファイル共有側の検索リンクから情報受け取ります)
を元に、ファイル共有側とは独立したBBS検索リンク網に参加してここからBBSキーのやり取りを行います。

BBSクラスタ参加ON状態なら常にBBS検索リンクでクラスタに繋がった状態になります。
板毎BBSクラスタ化の概念がまだ導入されていないβ1では、
BBS参加ノードはWinnyネット上の全てのBBSキーを保持することになります。


1554 名前:47 投稿日:03/05/05 14:23 ID:I/rAfvDY main/1052109753.html#469
ですのでスレを立てているノードだけで見ればv1のBBSとよく似た状況になります。
ですが、BBSスレ立てノードだけで独立してネットワークを作っているのと
BBSキーの流れがv1BBSより早いのでキーロストは大幅に起こり難くなるはずです。

次、もしスレを一つも公開していないノードの場合、BBS網に常時接続に行きませんので
BBSキーは基本的に保持しません。自動的にファイル共有専用モードになっています。
BBSノード情報だけはファイル共有側の検索リンクから自動的に流れてくるので
常に持っていますが、起動直後は未接続のままです。

ここで、BBSクラスタ参加OFF状態で、左側の板一覧からスレ一覧表示を開くと
そのときに初めてBBS網に接続に行きます(繋がっている側からはPort0ノードに見える)
この状態では、スレ一覧再取得動作毎に、BBS網側からそのBBSキーを取得してきます。
なお、スレ表示タブを全て閉じればBBS検索リンク機能がOFFになって再接続に
いかなくなります(が、一度繋がれば明示的に切らない限りBBS検索リンクはそのまま)

現時点ではこのスレ立ててない方のモードは調節不足
(スレ立て側が調節終わらないとBBSクライアント側が調節できない)ので
もし新BBSの調子が悪い場合、適当にスレ立てて実験してください。


1555 名前:47 投稿日:03/05/05 14:23 ID:I/rAfvDY main/1052109753.html#475
あとBBSの細かい動作ですが、基本的なメカニズムはv1のBBSと同じです。
書き込みはBBS検索リンクを経由して、常に隣のノードに投げることで行われます。
また、BBS完全キャッシュを自動的にBBSアップファイル相当に見せかけてキーを流しますので、
読み込みは直接BBSアップノードに行くとは限りません。こうなりますので、
v1と同じで、匿名性は書き込み側、読み込み側、スレ立てノードの順で高くなります。

なお、BBS管理側ですが、v2ではトリップを公開鍵とする認証機能がついてますので
もしどこか書き換えたらスレを見ている方で警告が出ます。また、BBSファイル本体が
v6キャッシュになっているので、そのままでは編集不可能です。
一度BBSスレ一覧の右メニューからエクスポートして編集してから再インポートしてください。
一応mail欄無しの発言ならv1のBBSからそのまま引き継げるようにはしてあります。

その他、GUI含めてかなり書き換わっているのでその都度実験してください。
説明しないとわからなそうな箇所があったら様子見てまた説明します。

βの間は当分、BBSリンクとBBSキー流通周りの調節になります。
もしかするとβ1だとBBSキーがあふれるかもしれませんし、
まだクラスタ化入れていないので、対応できるBBS数は1000以上5000以下です。
今の設計ですと全スレ数1万(BBSクラスタ参加ノード数もそのぐらい)でファイル共有側との
同時使用が耐えられなくなるはずですので、もしそこまで規模が大きくなるようでしたら、
ファイル共有側同様、BBS側にもクラスタ化を導入する予定です。


1556 名前:47 投稿日:03/05/05 14:32 ID:I/rAfvDY main/1052109753.html#653
ああ、暗号関連が全部変わってるので、前Verの初期ノード使えないと思います。
通信部とかキャッシュヘッダとかも全部変えました。

とりあえずv1β1の時と同じで初期ノード手動でどうにかしてください。

1557 名前:47 投稿日:03/05/05 14:59 ID:I/rAfvDY main/1052109753.html#939
昨日リストヘッダーをビューの外に出したの忘れてた

ってことでWinny2.0β1.01です

・ リストのソートが効かないのを修正


1558 名前:47 投稿日:03/05/05 17:00 ID:EopVe7+V main/1052114390.html#990
1000?

1559 名前:47 投稿日:03/05/05 1