MXの次はなんだろう？18

>134
その破損だらけのキャッシュをレジュームに次ぐレジュームで完成させて、
変換まで出来たのですが、それを再生してみると所々映像が乱れてました。

これは、レジュームが原因なのでしょうか、それとも元ファイルが壊れてる？
はたまた、その他の理由でしょうか・・・

どの段階でおかしくなったのか確かめようがありません・・・
レジュームが全て完了したからといって安心できません。

>>135
すばやい。
もつかれさまです。

自動ダウンキー100以上入れてる人ですけど、β14.4は
保持キーが増えても重くなりません。
すんばらしいです。

マジでHDDがもたねー
そろそろキャッシュ削除のアルゴリズムを組み込んでホスィ

>>136
松林作家そうなったけど、同じハッシュなのに新たな奴が引っかかるからそれを
ダウンロードすると直る。

>>136

とりあえず47氏が降臨した時に、キャッシュからファイルへの変換のアルゴリズムは
どうなっているのか確認する必要があるかもね。

>>136
変換時にエラーがでないのなら、
元から壊れているか、落としている途中で壊れたのか、
UL元の人に聞かない限り、確認する方法ないすね。

できる事といったら、念のためもう一回キャッシュから変換してみてエラーがないか調べる…とか。
うう。意味なさそう。
でも、今の所、圧縮ファイルでそういう報告ないような。
なぜか動画ばっかり。

>>141
中途キャッシュの変換機能があれば
テストも楽なんだけどな。

>>142
MX3.1でGDLを使用していると破損が多いらしいから
3.1から流れてきた動画なら結構はじめから破損している
可能性は高いかもね

3.1でGDLを使用できたのはほとんど動画だけだったみたいだし

>>142
Winnyのシステムはファイル形式を識別してないから、動画だけ壊れDLしてしまうなんて事は無いはずなんだよな・・・

(ﾟдﾟ)<動画も無圧縮でアーカイバ化しる！！
と、言ってみる試験書き込み。

>>144
MX3.1のGDLとWinnyのレジュームとはなーんも関係ないぞよ

>>146
(ﾟдﾟ)ﾊｧ?

>>144
あ、それありうるかも。

>>144
なるほどね。ＭＸから持ち込まれたものってほんとに多いからねぇ。

>82ですが、デフラグしても治りませんでした。

で、誰も持ってないかと言うと、レジュームすると何かを落としてきます。
でも、落としてないことに、なるみたいです。

ちなみに、600Ｍ位の動画で、β13の頃からレジュームを重ねたものです。
参照数見ると、それなりに落としてる人がいそうです。

Winnyのキャッシュは64K単位でハッシュついてますので、
一バイトでも違っているとそこのブロックだけ破損扱いされます。
暇な方は自分でキャッシュを壊してみて実験してください。

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

あと、キャッシュヘッダにはサイズ情報も含まれていますので
サイズ違いの途中のファイルというのもありえません。
キャッシュ変換で完了と出れば、オリジナルと全バイト同じはずです。

そういえば

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

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

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

と、いかんと。

＞47氏
レジューム時などにできるだけ破損が出にくいように、というのは、
今後対策する予定ありますか？

>>150
デフラグしても治らんと皆言うとろうが

>>153
それはレジュームする時に「末尾を削る」みたいなことを言っている？
>>152の機能があるから不要だと思うけどなー。

スレの雰囲気変わってきたな　新規者増えたか？
βテストの意味わからない人が増えそうなﾖｶｰﾝ

みんな過去ログを熟読してから参加よろしく　なかなか厳しいっすよ　ここは！

>>150
マジレスすると、デフラグではデータが壊れることはあっても、直ることはない。

>>155
そういうことです。レジュームできる機能があるとはいえ、
何度レジュームしても…みたいな報告がずいぶん多いんで、
破損出にくくできるなら、と思って。
まあ、後回しでもいいっかな。

例えば、Aという１００MBのファイルをDLし、後でそれの完全版A´（ハッシュ同じ）という１５０MBのファイルを見つけたとき、
その最初にDLしたAというファイルをレジュームしてA´にすることは出来ますか？

>>159
質問等は、こちらでどうぞ。

MXの次別館 くだ質、雑談、愚痴スレッドその2
http://tmp.2ch.net/test/read.cgi/download/1022428582/

申し訳ない、マルチポストになるけど許してくれ。

>>159

>>151に答えが無いか？

>>109 >>126
俺は109の状態。バーコード一本ごとにしか消えない・・・
接続が切れやすいとかでなく、たまたま２箇所の破損があって、
まずははじめの破損を修復していたのですが
ちょうど破損ブロックがここで終わる！ってところでDLが終わり、
そのままDL速度が0.0になって途切れる。
で、再試行すると当たり前のように繋がりなおして、2個目の破損をつぶし始めた。

どちらの破損にも１時間はかかってたけど、
途切れたのは１つめの破損箇所を終わった時だけ。

向こうに書いちまったよ。

>>476が言いたいのは例えば「_INCOMPLETE_小林作家.mpg」を全部落とした後
「完全版小林作家.mpg」のレジュームに使えるか？
ってことかと思ったんだが。

うわぁ
スレ間違え・・・
逝ってくる。

>>109
バーコード状になった受可キャッシュをダウンロードすると 一回の接続でバーコード１本しか消えない。

そうなんですよね・・・しかも1個バーコード消したら
徐々に表示されているノードの速度が落ちていって(この間は無転送)
最終的にタイムアウトになるわけですが、それまでの時間が長い！
1個しかバーコード消さないならそれは仕方ないとして、この挙動をどうにかしてほしいです・・・

ＭＳダンジョンシージってそんなに面白いのか？

>>166
そうそう。どんどん転送速度が落ちて表示されるのは
今までの平均で影響度が1/10、みたいな設定になってるからだろうけど。

もうバーコード状のファイルが出来るとため息一つついて、
そのキャッシュを消して最初ッからやり直す。
重度にバーコード化しちゃってる時は、こうやったほうが案外速くなる（ｗ

>>167
スレ違い

>>167
というか本名出すな。Winnyのためにも。

ICQはＭＸより危ないの？

>>171
いやはや、見事な厨っぷりですな。

本スレよりくだ質の方がちゃんと議論してる予感

ダウソ板でこれほどまじめに話し合い　
厨が入り込めないオーラを出すスレ郡があっただろうか？
47師を長とする　Winny軍団　感動した！　くだ質　いいぞ！

β14.3以降 落ちるようになった方いますか？
自分は落ちるようになりました。それまではWinnyが落ちるなんて他人事だったのですが・・・

-------------------------------------------------
OS/CPU/ﾒﾓﾘ：Windows XP Pro.／Pentium III 1G／512M
回線　　 　　　：ADSL　DL1.5M/UL512Kbps (J-DSL)
環境　　　　 　：ＮＡＴ・PCにグローバルＩＰ付加
待受ポート　 ：7749
DDNS入力　 ：なし
使用ｸﾗｲｱﾝﾄ ：Winny β14.4
速度申請　　 ：80
キャッシュ　　：2.3G/2.5G
症状　　　　　 ：べた14.3以降、ブラウザやMP3プレイヤなど、何かの起動や操作をきっかけに強制終了を食らう場合がある。
放置していた場合でも、気づくと終了させられている。申告速度変更は意味なし。
-------------------------------------------------

47氏いつもお疲れ様です。

>>152　
致命的ではないので実装はいつでもかまいませんので、破損キャッシュに対する
対策をいつか盛り込んでいただけたらと思います。
どのタイミングで破損のチェックをするかは議論の余地があるかもしれませんが
今のWinnyの構造からして破損のキャッシュは非常にできやすくなってますので、
巨大ファイルに関しては破損キャッシュが破損キャッシュをよんで、非常に効率が
悪くなっています。

CPU負荷の問題もありますので、どのタイミングでキャッシュのチェックをすればいいのか
いいアイデアがあれば誰か書き込んでください。
よろしくです。

>>175
漏れもそう。今までは一度も強制終了なんてなかったんだけど…。

-------------------------------------------------
OS/CPU/ﾒﾓﾘ：Windows 2000／Duron600／384M
回線　　 　　　：CABLE　DL8M/UL2M (J-COM)
環境　　　　 　：ＮＡＴ・PCにグローバルＩＰ付加
待受ポート　 ：7749
DDNS入力　 ：あり
使用ｸﾗｲｱﾝﾄ ：Winny β14.4
速度申請　　 ：100
キャッシュ　　：3.6G/10G
症状　　　　　 ：14.4から、放って置くと、
　　　　　　　　　一時間立たないうちに強制終了くらってまいます…。

-------------------------------------------------

>>176
スキャンディスクみたいにキャッシュのエラー検出を行ってくれるといいよね。
案としては、起動時か終了時がいいと思う。あとはCPU負荷が低いときにちょっとずつやっていくとか。
1回破損が出回ると、修正が厄介でこまる。

よく落ちてたけど、自動ﾀﾞｳｿ切ったら落ちなくなったよ。

>>176
そもそもいまはベータ板だから
でかいファイルは流さないようにする方向じゃなかった?

でかいファイル対策は
１ファイルの大きさの最大値の決定とか
クラスタ化してDL/UPの効率を上げてからって話だったんじゃ…

破損キャッシュの対策してくださいっていうより
ここら辺の対策を論議する方向に持っていったほうがいいのでは…
具体案が出れば，４７氏もやりやすいだろうし…

むぅ
よく見たら俺なんか見当違いな事書き込んでますな…

すいません。頭冷やしてきます

>>178
自分はファイル展開時にエラーチェックする今の仕様で良いけどなぁ・・・
殆ど自動ダウンロードだのみで使ってるけど、これって展開でエラーがでたら
エラーを潰して展開できるようになるまで自動でダウンロードしてくれるよねぇ。

Winnyが落ちると、キャッシュいかれませんか？
なんか自分のはいかれます。キャッシュ変換中に落ちると、あちこち虫食い状態に・・・（泣
でかいファイルはまだ駄目ですかね・・・やっぱ。

β14.4
キャッシュファイルの最大数は１０００だったと思いますが、
いったん６８０とかそれぐらいになったあと再起動をかけたら、
キャッシュファイル数が４００台まで減ってました。

まだキャッシュファイルの削除機能はなかったと思いますが、意図どおりの動作でしょうか？

キャッシュサイズは５８.６Ｇまで許可、現在１１.３Ｇ（５００ファイルまで持ち直した）というところです。

２４時間放置して、自動DLがひとつも働きませんでした。
（´･ω･｀）ｼｮﾎﾞｰﾝ

24時間連続稼働を喜んで下さい．．．(･_･､)

自動ダウンロードの単語の検索ですが・・・

ＵＬ０　かつ　ＤＬ０　の時　→　１単語１分ごとに検索
ＵＬ０　かつ　ＤＬ！＝０　の時　→　検索はしないダウン継続
ＵＬ＞＝１　の時　→　下流からくるキーをつかってダウンＭＡＸまでダウン開始

とすれば、検索による余分な負荷もかからないし下流ノードから止まることもないので
適当じゃないかと思ったり、思わなかったり。

>>184
リフレッシュしてみてください。今表示されてないキャッシュと入れ替わると
思います。バグなのか、仕様なのかはわかりません。

>>187
言いたい事がいまいちよくわからないけど…
>>103>>115>>123読んでみ

β14.5です。互換ありです。

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

主に大きなファイル対策ですがI/F周りで細かい修正が多数。
とりあえずレジューム関連の問題点や、ムービーなどでありうる
途中まででも展開できる機能など付いてます。

まだつぶしてないバグがたくさんありますけど、あまり機能追加
するとわけわからんバグが出そうなのでこんなことろで一度公開しときます。

つーか眠い。

β14.5ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!!!

おつかれさまです。
体の欲求には素直に従って、無理なさらずにゆっくり休めてください。

凄い・・・凄すぎます47師！全力でお疲れ様です！
＞・ 接続停止状態で再起動して接続開始した場合にポートを開いてなかったのを修正
これで例のポート警告が出る問題はばっちり解決ですね。

＞・ ダウン中のキャッシュや部分キャッシュでも変換可能にした
これは賛否両論でしたが前々から望まれてた機能ですし！

＞・ 一回のレジュームで一つの連続ブロックしか直せなかったのを修正
これに至っては今雑談スレのほうで一番の話題でした！
まさかβ14.5でこれが来るとは・・・。参りました。

ｷﾀ━━━━━━━(ﾟ∀ﾟ)━━━━━━━!!!!!
つうか。なんつう更新のはやさ。
47氏は常に我々のよそうの右斜め45度をゆく。

レジューム周りは、帯域制限やら複数ダウン、自動ダウンやらでダウン部を
変更しているうちに入り込んだバグみたいです。前のバージョンなら問題なかったはず。

あとまだリフレッシュ周りだとかあと帯域制限も変だという話あったと思いますが
見直しとらんのでよろしく〜。

>>193
妙に胴衣　

>>47師　乙カレーです
そろそろ次の段階が見えてきた感じですね
これからは間をかける必要も出てきますね

（´-`）.｡oO（中継中のファイルを強制変換したらどうなるんだろう？）

>196
ダウソしながら変換可能できますた。

しかし部分キャッシュのファイルは変換不可？

＞・ 同じキーに対する分割ダウンを同じノードに複数かけられなくした
これって、タスクにもう入ってるファイルで同じ人のだったら
受可キャッシュでなく、部分キャッシュとなるわけだよな。
今ちょっといじってみた感じとしては。
だけどちょっとすると、また受可キャッシュとなる。
ってことはこれは別の人のがひっかかったという解釈でいいのだろうか。
だとしたら、これは凄いことだと思うんだけど。
空いてる人を探せる訳じゃん？何度も繰り返して。

日本語変ですまん。

>>47師
とりあえず報告　転送レートの幅が保存できないようです　重要度最低

自動ダウンロード画面にて

前βと同じく自動DLの処理でｱｸｾｽ違反が起きます

Winny.exe の 0x0040fc5e でハンドルされていない例外が発生しました
: 0xC0000005: 場所 0xd249dd08 を読み込み中にアクセス違反が発生しました。

>>198
14.5だと、ダウン中のファイルでも今ダウンしているノード以外に
キャッシュ持っているノードが無いと受可キャッシュになりません。

逆にいえばダウン中で黄色くなっていれば、他のノードから
分割ダウンできるということで、既に部分キャッシュからでも重複して読めるので、
機能的にはMX3.1相当のはずです。手動ですが・・・

あと別館見たらハッシュで盛り上がっているようですが、この辺は非常に
面倒なことになってます。皆さんの予想通り、検索に使っているのは
とりあえず高速に求める必要があって先頭ブロックだけから算出してますが、
64Kブロックで全部ハッシュ持ってますし、キャッシュ先頭のブロック
（いろんな管理情報が入っていてここには他のハッシュ情報も入ってる）
これ自身のハッシュもあります。そうでないと管理部分の破損が検出できませんし。

もっと面倒なのが、これに加えて暗号化がかかることで、
実は今回の変更で送信時もキャッシュのハッシュチェックしようかと思いましたが、
これのせいで断念しました。困ったことに元の暗号がわからないとハッシュチェックも
できなかったりします(^^;良く考えたらキャッシュ先頭だけ、処理順番変えればよかった
だけですが（もちろん先頭ブロックも暗号化されてます）、今からこれやると
今までのキャッシュと互換がなくなってしまいます。

とりあえずレジュームが少しはまともになったはずなんで、我慢しとってください。

暗号キーの設定されている転送ファイル（＠のみのファイル）も強制変換出来てしまうのね。

内容が分かってしまうのでこれは変換できないほうがよいのでは？＞４７師

あと、部分キャッシュの強制変換は右メニューからしか
できなくなってます。これやると生成されるファイルが壊れてますんで
今までダウンフォルダには完全ファイルしかないというルールから外れます。

ダブルクリックで起動できると間違えて破損ファイルがダウンフォルダにできて、
これはキャッシュと違ってシステム側で補完できないので、
分かっている人だけが使う機能ということで。あと一応、部分キャッシュ
だけ見れるようになってます。ファイル種類でソートかけられるので、
この辺と組み合わせて使ってください。

ZoneAlarmを使いながらWinnyを使ってみていただきたい。

βなんだしキャッシュの互換性なんか無視しても良いかと思いますが・・・
互換性なくした瞬間にファイルの流通がピタっと止まったりして(ｗ

ダウソ終わって、キャッシュ変換中に破損検出・・・そしてもう一度穴埋めレジューム・・・
この繰り返し地獄からまったく抜け出せる兆しのファイルに関しての47さまの見解が聞きたいです。
お願いできませんか？？

以前47さまが書いていらした内容からすれば、その繰り返しを続ければ必ず完全キャッシュになるように思われるのですが・・・

大きいファイルを最初からやり直すのは勇気が要ります・・・

>>203
実は暗号化されていても他からのクエリでヒットすると暗号キーが判明してしまいます。
一度再起動すると消えるので復号不可能になりますが
（もちろんキャッシュには暗号キーは含まれてません）
とりあえずまずいんでそのうちクリアするようにはします。

>>208
了解。乙カレです。

>>207
俺も前バージョンの無間地獄で７００MB中、２００MBほどデータが失われましたね。
しかも、えらい細かい欠落が発生してました。
今は断片化した部分は解消でき、のこりのでかい部分も順調にレジューム中ですので、成功したら報告しましょう。

>>207
UPファイルを誰も持ってない状況でキャッシュだけになって
それがみんな破損していると言う状況だとどうやっても修復不可能です。

前のバージョンではレジューム接続部でほぼ確実に破損していたので
壊れているキャッシュが多いんだと思います。今のですと破損しにくい
はずなので時間が立てば自然に消えていくと思いますが、
強制的に対処するとしたらキャッシュのプロトコル変えないとダメですね。

キャッシュにもバージョンあるんで今のキャッシュを捨てないでも
対処できますが、ちとめんどうかもしれず。

この問題はどうなったんでせう。。
http://tmp.2ch.net/test/read.cgi/download/1022428582/500-600
ttp://isweb40.infoseek.co.jp/play/maxmam/cgi-bin/img-box/img20020530183709.gif

>>188
　検索結果ではなく、システム情報ページのキャッシュファイル数が再起動で減ってます。
キャッシュフォルダ内のファイル数も減ってますので、検索のリフレッシュ結果とは別の話

>>187　は
　転送が上下ともに完全停止なら能動的に検索に行く、ダウンのみなら最大１本しか自動ダウン開始しない。
アップ中なら４７氏の初期設定どおり下流からのキーでTransfer Maxまでダウンタスク追加
って意味です。日本語まずくてスマソ

ああ、あと見かけ上完全だけど変換すると部分キャッシュに化けることが良くあるはずです。

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

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

部分キャッシュの変換のやり方がよくわからない…

スマン全然わからん。







（・∀・）ﾃﾍ！

>>215
右

>>217
できないっすよ？
タスクの所でも検索でもどちらでも良いのではないの？

>>212
>202の中段あたりをみよう

>>206
同意

>>211
レスありがとうございます。
やっぱ気長に待つか、該当のキャッシュ消してやり直してみるのがいいですかね・・・

※キャッシュシステムの変更は早いうちにやっておいた方がいいと思います。
現行キャッシュの問題点を早めに洗い出して変更してしまったほうが、後々いいような・・・
厨房意見ｽﾏｿ

ん？変換できるのは可受キャッシュだけ？部分キャッシュは変換できんな。

部分キャッシュ（受可キャッシュでも可）を検索で見つけ出して右メニューで変換すると
タスクで変換始まって失敗しますが、ダウンフォルダに変換できただけ残ってます。

ダウン中のファイルならタスク画面の方からでも右メニューの強制変換で
同じことになります。

・・・とりあえず寝ます

一緒に使ってるんだけどべつに何も起こらないよん

>>223
あ〜い、おやすみなさいませ〜。

今やってみたら部分キャッシュだとだめかもしれず。
ダブルクリックで変換できなくしたときに巻き添え食らったらしいですが、

簡単なんで直しますか。少しお待ちを。

自動DLで、検索ワード、サイズと条件が追加されてきてるけど
捏造っぽいファイルを避けるためにも、条件にハッシュも入れて欲しいなぁ。
俺だけかもしれないけど。無理なのかもしれないけど。

まぁ47師、ゆっくりまたーりのんびり休んでください。
β14.5最高過ぎですので1週間ぐらいなら余裕で使ってられます（ｗ

>>226
って!!Σ（ﾟдﾟlll)
頑張りすぎ・・・頑張りすぎ・・・

早くもバージョンアップの予感

β14.5 快適すぎる‥‥
47さん、あんた一体何者ですか？

自動ダウン働きまくってます。
今夜はまた眠れない夜になりそう。

ただ、検索のヒット率は、少し前に比べてちょっと下がった気が
しますね。

部分キャッシュだと変換始まらなかったんで、直しました。
すいませんが14.5の読み込み直しお願いします。

>>230
>自動ダウン働きまくってます。
>今夜はまた眠れない夜になりそう。
なぜ…自動なんだから眠ればいいものを。
というわけで、おやすみなさいませ。

>>231
ＯＫです、動作確認しました。
ゆっくり休んでください・・・。ほんとに・・・。

>>213
同じ人だったのかｗ気付かなかったョ
リフレッシュについて。
例えば完全キャッシュを100持っているとすると、
リフレッシュする度に70⇔30で変わったり、1⇔99で変わったりします。
検索画面での自キャッシュの表示もリフレッシュ毎に入れ替わります。
バグだったんですね

>ＵＬ０　かつ　ＤＬ！＝０
この意味がわからなかったですよ

（´-`）.｡oO（またUP1以上じゃないと自動DLできないように戻らないかなぁ）

>212
帰ってきたら、変な人が一杯出てきたので、考えるのやめました。
４７氏もチェックされているようなので、十分かと。

しかし、快適になったとはいえ、下層にはキーが回ってこない・・・
また、回線詐称がはやりそうな予感。

>>234
自己レス これによって
自動DLで自キャッシュ内にあるファイルもDLを試みてしまう
他人からも見えなくなるとしたらキャッシュがもったいない
という問題が出てきます。

途中ファイルの変換機能の実装については個人的に反対ですが
やっぱり、可能にするって方が多数派なんでしょうか？

恥ずかしい話、ちょめちょめビデオ見て楽しんでるんですけど、
同じ内容のファイルが違う名前で出回ってしまうMXの状態はちょっと簡便してほしいのですが。

エロ系に関して言えば、個人の趣味が合って似たようなタイトルばっかり落とすんですけど
MXだとでかいファイル４００MBの４０MB版とか１３０MB版とか280MB版とか
タイトルまったく変えてアップする方がおられるので全部落としてしまうんですよね。

この機能の必要性ってなんなんでしたっけ??
もし必要なのでしたら、

仕様的に途中ファイルはキャッシュからファイルに変換できるけど、
再びキャッシュ化＆UPできないようになんか特殊な暗号いれちゃうとか・・・

どうせ、AVIとかZIPファイルその他もろもろ完全にダウンロードしないといけないファイルでも
流通していると思うので、MPGもそうしてほしいと思います。

まとまり無いぶんですいません。.

>>202 の
４７氏へ

・・・以前、正式バージョンへの移行の時にβのキャッシュとの互換性をなくしたほうがいい
と語っていたものです（汗


＞今からこれやると
今までのキャッシュと互換がなくなってしまいます。

・・・とのことですが、個人的には完全な互換は別になくてもいいと思います。
現在はテスト中で、正式版でもないことですし、全体の性能がUPするのなら
βで人数の少ない今のうちに、変更するほうが混乱も少ないかと思います。

反論派の方のために先に書いておきますが、今はβ版であり、正式なものではないので、
今までためてきたキャッシュがつかえなくなることはあってもも文句は言えません。
βテストとはそういうものです。

>238
私もそれが言いたかった…(+_+)
あと、ファイルを指定してレジュームがあれば、そういうMXなどで生まれた（ファイル名を変えた）途中ファイルは
無くなっていくと思います（少なくともWinnyからは生まれないはず）。

>>238
部分キャッシュ展開非常に便利ですけどねぇ…。
途中まで落としたものの、UL元がいなくなってしまうことだってありえますし。
もちろん、名前を変えた途中ファイルかどうかの確認にも使える訳ですし。
そんなにソフトの能力を落とすものでもないと思うので、ユーザーの自由度が高い方がいいです。

>>238
捏造対策や動画の確認などに使える機能だと思ってます。
それこそ・・・
＞MXだとでかいファイル４００MBの４０MB版とか１３０MB版とか280MB版とか
＞タイトルまったく変えてアップする方がおられるので全部落としてしまうんですよね。
を見破るのに使えるはずなので。

>>238
途中までの動画とか一つのソースに複数のバージョンが出回りかねない（と言うか必ず出る）ので私も反対です。
が、搭載された以上47氏も必要性を認めた決定事項だと思うので一つ提案
途中ファイルの変換は出力先を別ディレクトリにできないでしょうか？
で、そのディレクトリはDLディレクトリ、UPディレクトリとは重複できないように制限するとか

>>239
そういう議論を始めると47氏のことだから
実際にキャッシュバージョン変更する際にコンバータ機能作ると思われ・・・

>>243補足
重複って言うか同一ディレクトリを登録できないようにって意味

自動DLの画面で「転送レート」の部分のタブの幅を変更しても、他に移動してから戻ると幅がリセットされてしまいます。
幅の値が保存されてないのかな？

http://isweb40.infoseek.co.jp/play/maxmam/cgi-bin/img-box/img20020530183709.gif
この画像のハッシュ値がd2abd9ee〜のファイルで言うと
例えば83MのものをDL完了したら、88Mのものの受可キャッシュに
なってくれたらいいんですけどね。できるとしてもかなり面倒臭そうですが

>>245
>>199>>200

動作ＯＫ報告です。

前バージョンでバーコード化して手動でちまちまなおしていたファイルが
このバージョンで残り全部を一気に吸い上げ、完全キャッシュとなりました。

「効果的にバグを報告するには」
http://www.unixuser.org/~ueno/bugs-ja.html
一応目を通そう。

β14.5にしたら保持キー個数が3300くらいから1500前後までに減りますた

ADSL8M
回線申告速度115

接続開始後、数分で公開ファイル数が0になります。
保持キー個数も激減します。
公開フォルダを再登録すると復活しますが、時間を置くと同じ症状が出ます。

うん、確かにβ14.2では回線50で保持キーが2000〜3000
はキープしてたけど1000前後になったかなぁ。大体900代。

＜重要度低＞新しいreadme.txtを読んでみたかったり・・・

部分キャッシュ表示と完全キャッシュ表示がちゃんと動くようになってますね

>>250
寿命でキーが死んでるんじゃ…
検索するとふっかつしませんか。

検索のヒット率はかなり減った感じですね。
かなり広まっているファイルでないと拾ってくれない感じがします。

〜KB以下は検索で引っかからない機能とか欲しいなあ
今のままだと交換日記とかしか引っかからないよ。漏れがISDNだからかな？

交換機能についてちょっと考えてみた。

１．ファイル検索でファイルを探し、ポップアップメニューで交換依頼

　　　依頼者→中継者（複数？）→依頼先（どこに行くかは不定で複数もあり？）

　　この時、依頼者の保有するＵＰファイルと完全キャッシュのリストも
　　添付して送ってあげる。

２．依頼先の誰かさんにメッセージが届く、添付リスト等見て交換するか
　　あげるか、拒否するか選択した上でアクションを決める。

　　　依頼先UP→中継者（複数？）→依頼元Down

　　こんな感じで、依頼先が自発的に依頼元に送ってあげる。

　　交換の場合は

　　　依頼先（送信依頼）→中継者（複数？）→依頼元　なメッセージが送られて

　　依頼元では

　　　依頼元UP→中継者（複数？）→依頼先Down

　　な感じで交換が成立する。

誰と交換してるかわからないけど、一応交換は成り立つんじゃなかろうか
名無しさんじゃなんだって事なら、メッセージに使うニックネームだけ
設定してあげとくとある程度識別は出来るかも。

中継者を挟む事でキャッシュも溜まるし、Winnyの理念にもかなうかと

いかがなもの？

>>257
中継者が、外出するのでWinny終了
と、したら交換は成り立たないよね。

β13.3でのWinny強制終了は
β14.4,14.5では発生せずに快適に動作中。
と、報告してみるテスト

β14.6です。互換があります。

・自動ダウンでヒットキーがあるのに何も落とせなくなることがあったのを修正
・タブ幅変更処理が変だったのを修正
・手動検索での1ノード内ヒット数限界を倍（200）にした

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

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

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

β14.6ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

４７師モツカレ様です。

今日に限ってつけたまま放置で外出しちゃったよ・・・
夜中にかえるまで14.5だ。みんなすまｎ

＞・自動ダウンでヒットキーがあるのに何も落とせなくなることがあったのを修正
それだ！！！！

47さんおつー。
＞・自動ダウンでヒットキーがあるのに何も落とせなくなることがあったのを修正
俺もまさにコレを報告しようとして開いたところだ(w

中継中のファイルが終わるまでV.up保留だけど、はよ上げたい。

>>258
中継者が、外出するのでWinny終了
と、したら交換は成り立たないよね。

そうだけど、直接交換だと匿名性なしじゃない。
タイムアウト検出して、違う中継者経由で再開すればいいんじゃないかな。

正直、IMやニックネーム等の、識別させるような仕様はやめて欲しい。
ACCSから、交換依頼やIMが来たらと思うと‥‥

>>265 やばいものを交換するのが悪いｗ

>>265
IDなくても交換相手が・・・だったら意味なし。
考えるだけ無駄。

それで匿名性云々いうなら交換機能はいらない。

>>264
交換するとなるとお互いの存在、やりとりするファイル等どうやってもばれ易くなるので
Winny最大の特徴「匿名性」が低くなる。

>>266
山へ(･∀･)ｶｴﾚ!
それを言（略）

って言うか交換機能いらないよ

というか今のこの強力な状態で、わざわざリスクを背負って交換機能を
つける必要があるのか？と思うんですけど‥‥
交換だけだったら他のソフトもあるわけですし。

つうか、まだ「交換」概念捨てきれないの？
WinNYの思想に反するからやめて欲しいんだけど。


WinNYは匿名性の高い「共有」ツールです。
交換は「WinMX」でおながいします。

>>264
Winnyに交換機能は必要ない　
十分に安定した交換機能を持ったソフトは他にあるYO

特定個人が利益を得る機能は必要ないと思う
自分は交換機能が有れば得する側だが（ｗ

>>271-272
でも47氏も交換機能ほつけるとか言ってなかったっけ?

Winnyの匿名性の高さ（旧来のP2Pよりは、、）に便乗したいってのは理解出来るんだけどね
ただ現状のWinnyには不用に思う。
需要があればある程度の匿名性を持った、交換ソフトが出現するんじゃないかな？
ただどんなに工夫しても、おとり捜査には対応出来そうに無いが、、、

>>234の現象は未だ直っていない様で。
（´-`）.｡oO（勘のいい人なら悪用もできますが…）

>>250>>255
検索ヒット率が落ちたのもこのせいかなぁ

273>
　47氏はそれに似たような機能をつける「かも」しれない、とかやりように
よっては交換「っぽい」事もできる……という旨の発言は幾度かされている
ようですが、「交換機能を搭載」と明言してはいないように思われ。

　ちうか、交換機能つけたらそればかりになるのは目に見えているし、少な
くともそんな物を「共有ソフト」とはいわない罠。

　まぁ、MXの後釜として考えるならその方が正しのかもしれんが（ｗ

>>257 >>271-272
交換できる機能があれば、人は呼び込みやすいとは、おもうけど、ね．．．
というか「１〜８話、１０話を共有しました。誰か補完してください〜。」
みたいなのが、Winnyでいう交換みたいなものじゃないの？
そのレスを読んだ９割がDOM(中継専門？)でも、誰か１人UPすれば、全話コンプに貢献できると。

現状のシステムに交換の何らかの機能が追加されたとしても、交換ソフトとしてはお粗末な物？に
なるんじゃないかな？
途中のノードにキャッシングされるのと速度面は、交換原理主義者にどう映るのだろうか？

>>277
簡易掲示板機能なら欲しいね。
掲示板としてガンガン使えるのはいらない。

ファイルUPお願いとか、危険ファイル＆最新UPのお知らせが
出来る程度で十分。

んで、その掲示板発言の内容はどういう風に管理すればいいのかな?
専用のキャッシュファイルに書き込みか
完全揮発性のものにするか・・・

交換機能は公開暗号健を利用したMXとは一風変ったものになると思われ。

まだ交換房いたのか
記念物だな

b14.6
リストビューのカラムの幅の対応がおかしいです。

たとえばタスク情報画面のファイル名の幅と
自動ダウンロード画面の転送レートの幅が連動してます(笑)

>>281
過去スレ読め
47氏も交換は必要かもしれないと書いてあるから

>>279
確かに、Winny自体にもコミュニケーションがあれば、面白いね。
リアルタイムなIM機能は難しいとしても。

常時接続しなきゃダウンできないって制限じゃなく、気が付いたら、かちゅを立ち上げてたみたいな感じになって欲しいし。
ココでもスレたててもイイけど．．．２ちゃんが嫌いでもWinnyは使って欲しい。

今の回覧版みたのは論外として、クラスタ化されたら種別毎の回覧版専用キーやノードがあれば可能かな？
あとは、たしかにUPした補完依頼ファイルには、人気度以外に寿命が設定できる機能も必要かも。固定でもイイけど。
もし再依頼・UPしたい場合は、寿命更新ボタンがあって、再度大きな日付に置き換えると。
寿命設定はイロイロ応用も利きそうだけど、ちょっと問題もあるかな？
一番の問題はトラフィックが増すこととか。アル意味、P2P匿名掲示板のzigumoだし。

あと、とりあえずMXの参照機能があれば、オモシロイかも。
今は検索や自動ダウンキー設定しなきゃイケナイけど、暗号キーだけ指定すれば、どっかのランダムな場所のキャッシュが参照できると。
コレもクラスタ化されれば、特定の種類のファイルがキャッシュにたまりやすいので．．．
「お、こんなファイルも存在するのか。よし、集めてみよう!!」ってな感じに。

Winnyには「ファイル」共有だけでなく、情報やコミュニケーションの「共有」にもなって欲しい．．．
「貢献しなきゃダウンできないぞ」とかじゃなくて、繋いでると楽しいとイイな。

って、妄想なので、47氏はマターリ思うがままに作ってみてください〜。

IMも中継すれば身元がわからないよね・・・。

>>285
常設状態のノードが過半数ならともかく、
現状で中継してたら、
相手に届かない事のほうが多いんではと思ったり。

それでも､無いよりいいけど。

>>283
281じゃないが、、、
使用人数と供給ソフト数が余にも少なく、交換機能を追加する事で人員を呼べれば、、、
の意味合いに取れたが。。良く読んでいないや（旧スレは流れが早かった、、、）
現状ではどうだろう？？？

今後Winnyが度の様な方向へ逝くかわからんが、俺個人はMXのIMなどの人間臭さを排除した
う〜んそうだな、日本では蛇口を捻れば水が出てくるが、キーを叩けばソフトが（w、出てくる
そんな物があっても良いんじゃないかと。。。

>>279
>>284
要はfreenetでいうFrostの掲示板と同じものがほしいんだろ？
匿名性も問題無いし、あれと同じ仕組みでできるはずだ。
もっとも、47氏がやるかやらないかは本人次第だ

僕たちは２次配布OKなフリーソフトや音楽ばかりを共有しています！
みんなもそうですよね！

回覧板がうっとうしいのは、やたら検索に引っかかるから
だからキーを @MESSAGE とかに限定して、
また落とすと増えるから、MXの注意書きみたいに、
内容は全てファイル名に書き込むって事で、
今の機能を活かしてなんとかならない？

[連絡]β15出てます(´Д`).msg

>>289
当たり前だろうｗ

>>289
てやんでぇー、あたぼーよ。

>>285
でも、リアルタイムなIMはちょっと難しいかな。
IM専用の常設ノードがあればイイケド．．．

>>287
確かに、交換に近い機能がアレばファイルか増えるかもね．．．
交換してた誰か１人が、そろそろ流すかって感じで流してくれればイイし。

あと、そんなに、人間臭さを排除しなくてもイイかと。
というか、両立すればOKなような．．．
たとえば、フリーソフトをダウンして使うダケの人もいれば、作者にコンナ機能が欲しいですとメールする人もいるワケだから。

いわゆるDOMも中継屋さんとして役立ってくれるんだから、使いたい人が、使いたいように使えれば理想かな〜。

正直β版の今の状態が一番の理想な気がする．．．
要望もイロイロだせて、新しい機能もイロイロ実装されていって．．．一番楽しい時期かも。

>>交換してた誰か１人が、そろそろ流すかって感じで流してくれればイイし。

中継したキャッシュから勝手にひろまるのでは?

>>294
交換すんだから適当な暗号キーつけるんでない？
じゃないと交換の意味ないYO！でも糞キャッシュは溜まる。

ほかの共有ソフトみたいに、アップロード中のファイル名を表示してくれないかな。

公開フォルダ内のファイルならそのファイル名を
キャッシュフォルダ内ならキャッシュファイル名を表示してくれると、
「俺って貢献してるんだな」って張り合いになって、Winnyを起動し続けるモチベ
ーションになると思うんだけど。　（要するに、プチ神気分が味わいたいのよ）

今は検索でしか表示されないけど、公開フォルダとキャッシュフォルダのファイ
ルの参照率を統計表示してくれるタブもあるとなお（・∀・）ｲｲ！。

以上、優先度の低い要望でした。

ド素人なりに考えたのだが、回覧板は専用キャッシュ＆フォルダを用意して
一定時間ごとに他のノードから回覧板を自動DLして
古いキャッシュは自動破棄すれば成り立つのでは？

既存のフォーマットでログを作ればログリーダーも簡単に出来そう。


ただし、更新間隔が短い場合は全ユーザーのPC時計が正確じゃないと･･･

>>297
されば　WINNYにユーザー全員で共有できる　時計機能つけてみても　面白いのでは？

>>296
もし違法ファイルが流れているのが分かる仕様だと
何かあった時に言い逃れ出来ない罠。

>>296
明らかに違法な物が流通しているのを目撃したら心が痛むよ(w
転送した総量などで満足していただけませんかね？

>>295
なるほど　47師も技術的には可能だが導入は決めていない印象

Winnyがここまでﾏﾀｰﾘしてくると　実装される機能はWinny全体に
貢献できる内容でないと　違和感あるかも　利己厨はなじまない

Winnyネットの私物化？　なんじゃそりゃ＜俺

現在、上流でUP20-28ぐらいで貢献できてうれしいが
交換に伴う利己的な雰囲気が支配してくると　萎え萎えなヨカーン

>>289
んなわけねーだろ、ヴォケ（｀Д´ ）

・・・うちの子の運動会やアサガオ観察日記も共有します。

>297
指定した日数以前のキャッシュを自動削除出来れば（・∀・）ｲｲ!!

>>299-300

296は中継中のファイル名じゃなくて自分がUPしているファイル名のことを言ってるんじゃないの?

>>もし違法ファイルが流れているのが分かる

ってUPフォルダに入れているんだから自分には違法ファイルかどうか
わかっても関係ないのでは?

言葉足らずでしたか。申し訳ない。
>>304
そう。自分がUPしてるファイルのこと。（公開フォルダとキャッシュ）
中継ファイルは表示しなくていいし、中継まで取り消してしまえる「タスク
取り消し」なってボタンはさっさとなくして欲しいです。

自分で管理可能な範囲での満足感が欲しいのです。

>>296 >>304
たしかにネ。
「うぉっ！オレが作ったモノがUPされてるガンガレ!!」とか、
「オレと同じモノを集めてる同士がいる。UPフォルダに保存しておいてよかった〜」
とか、アレバ、モチベーションはあがるかな。
逆もあるかも知れないけど．．．そんな人はUPフォルダにすら入れないよね。

>>303
そうじゃなくて、漏れが提案した回覧板方式は
随時新しい日時のと更新される仕様なのだが・・・

DLを自分でするのではなく、
自分の持っている回覧板を一定間隔で自動 「更新」 する
だから、無駄なキャッシュが増えない。


問題として
ファイル作成ノードとDLするノードの時間が逆転したり

A＝12：05に作成　＞　B＝11：55にキャッシュ作成　＞　C＝12：05にキャッシュ受ける

ようにすると回覧板の最新時間が滅茶苦茶になる上に、
低速ノードにもキャッシュをUPようにすると負荷が厳しそう・・・

>>305
中継キャッシュではなく、自UPファイルの表示なら賛成。

>>304
それなら･･･ん〜見たって影響は殆ど無いかな？気になるのも確かだし。。
だがあえて。。。個人的には内部処理不可侵の原則!?とでも言いましょうか
可能な限り見えない見せないのも神秘的？で良いのかもとぉ〜？思う。。。

でもキャッシュからのUPもあるのか・・・

>>305は中継して出来たキャッシュは消してるのか

>>307追加

回覧板のキャッシュ上限を500KBとかに決めていれば
無尽蔵に増えなくなるね。

そのかわり、ログリーダー作らないとテキストエディッタなどで開いて
書き込みされて、容量がオーバーして流されても困るし、

もちろん書きこみする時には最新ログをチェックしてからじゃないと
またまたおかしなことになるし・・・

>>307
あんまり、新しすぎる方式だと、47氏の負担になっちゃうかも〜。
たしかに、自動ダウンロード機能もちょっと負荷がきびしいかな、と思う。
かつての２ちゃんみたいになったらアレだし。

あと、回覧用常設ノードがあればって言ったのは、ある意味今のキー情報の仕組みが使えるな〜と思ったもので。
あとは、幾つかの常設ノード同士で差分の動機とれれば．．．ニュースグループサーバーの用に機能するかも。
情報の寿命さえ設定できれば、溢れ返ることもないし。開発の負担も少ないかなと。

結局 >>288 がいってるようにやるか、やらないかは47氏しだいだけどネ〜。
も、アイデアを出し合うダケならイイヨネ．．．

回覧板なんて、もう必要ないんじゃないんですか・・・・？

>>311
うーん。キャッシュは@44654686465ってなファイル名のまんまなら
「内容に関しては中継ノードは関せず」の立場が守れると思うので．．．
@486646655656なら何の罪悪感も無いし、違法かどうかも分からないし。

ってことでどうでせう？

全く管理する事の出来ない（余地が無い？）掲示板を標準で搭載する事の危険性の検証も必要かな？
見ている人数から考えて影響は小さいのだろうが、、、
悪意を持った者がどう使うかは予想し難いが、、正常なファイルでも危険！菌入りや危険なファイルを
安全で便利な物と宣伝する事位は現時点でも考えられる画･･

公開フォルダのうｐが見えるのは賛成だが
転送状況まで見えると99%で切断する厨が出現する罠ｗ

>>313
まあ、回覧板に関しては
クラスタ化して負荷が分散されてからじゃないと
現状で組むと負荷がひどくなるだけだね。

>>47氏
自動DLの登録件数は多くても10〜15件くらいでいいんじゃないでしょうか?
各ノードがあちこちにDL/UP要求出しすぎて、途中で切れたりDL出来ないのは
自動DLの負荷がかかりまくっているからだと思うんですけど･･･





オープンソースじゃないのは分かってるんだけど
手伝えないのが悲しい････

>>316
もちろんその危険性も考えたが、
WinNYの仕様では人気の無いファイルはキャッシュから
自然消滅するようになっているし、
回覧板のフォーマットは基本的にはプレーンテキスト＆書き込みNo＆タブ程度で
いけると思ってるから、そんなに被害は蔓延しないと思うが･･･


ただ、ダメファイルをつかまされた人柱が書き込みしないと機能しない・・・

>>319
>WinNYの仕様では人気の無いファイルはキャッシュから
>自然消滅するようになっているし、
しますっけ?

>>320
仕様上はされるんだけど、まだ実装されていない。

>>316 あ、そうだ。そのレスをみて思い出した。
交換依頼の話に戻るわけじゃないけど、別館の方で、
破損キャッシュがいくらダウンしても破損のママで復元できないっよ〜て話がでてたんで、
補充依頼とかするのに情報交換の場が欲しいといったんだけど、スッカラカンに忘れてた。

くだ質と、47氏のレスを見ると、完全品のハッシュの整合性チェックは変換作業時のみなんで、
結構破損した自称「完全キャッシュ」がそのまま出回ってる様子。
時間がたてば自然に消えていくとという、47氏の見解だったけど．．．
待てないって人とか、本物が消えて、不完全のみが広まっちゃったて可能性もアルよネ。

コレも「情報交換」．．．いや、「情報共有」の場があれば、
「完全な完全キャッシュ」持ってる人が自分の接続ノードのリストを公開。
「不完全なキャッシュの人達」はソコに接続すれば「完全な完全キャッシュ」になる確立があがると。
Winnyが自動でやってくれるのが理想だけど．．．
コレに限らず、予期せぬ状況にも、２ちゃんねら〜以外でも皆で対応できればな〜って。

あと、危険な情報はWinnyの概念や２ちゃんのスレッドのように淘汰されていくのでは。
逆に増えるかな？(w
そろらへんの情報の危険性は２ちゃんが一番イイ検証例ダネ．．．
ウソをウソだと見抜ける人でないと．．．

破損対策は暇見てやります。そんなに難しい問題ではないですので。

あと、掲示板は今はやる気がまったくありません。今の２ｃｈでいいと思ってますし、
これ以上の使い心地はP2Pでは実現できないと思います。
MXとFreenetの違いと同じかと。

もちろん、匿名性の点で2chが怪しくなってきたり負荷に耐えられなくなったら考えるかも
しれませんが、既に他にこれでやっている方がいるわけですので、そちらに期待ということで。

一応、今のWinnyに外部I/F付けて掲示板も使えるようにする（FreenetのFrostのように）
というのはありでしょうが、なんとなくですがシステムやプロトコル一部共用と言うより、
ファイル交換とBBSは完全に別システムにしたほうが効率がいい、
というか、これやっても今の2chレベルが実現できるか怪しいと思います。

それよりも先にもう少し大規模になっても耐えられるようにするのが
Winny的にはテーマでしょうね。

>>318
たしかに、掲示板はクラスタ化が前提ダネ。
かってにイロイロ試しすぎても、今の回覧版みたいになっちゃう。
今は、とりあえず、新しい機能の可能性を議論するって感じかな。

あと、前はオープンソースって話がでるタビに前スレ読めって話になって、読み飛ばしてたんだけど、
47氏が望むなら、組める人間がオープンソースで「提供」スレばイイんでない？既出？

他の要望と同じく取り入れるか取り入れないかは47氏しだいだけど．．．
Winny本体をDLL化ではなくて、ガワの部分とかをオープンソースで提供して、
47氏に使ってもらうか、Winny本体から呼び出してもらうと。

そうすれば、見た目の問題とかのササイなこともイロイロ言えるよネ。
Excelとかタスクマネージャーのようにみえるスキンをクダサイとか。(w

そんな自分は、VB&Delphi厨．．．
C++はビジネスロジック部分くらいしか組めない．．．（´・ω・`）ｼｮﾎﾞｰﾝ

>>319
ん〜自分の公開フォルダのうぷ状態閲覧や掲示板の様な物、その他1ノードが他に影響できる全ての機能は
Winny本体には入れたくないってのが個人的感想です。

UP状態はそれが増えるのを見て喜ぶ悪意を持った者がファイル名に細工（WINDOWSの制約の254文字まで？）
をする可能性（HITしそうなワードを入れるって意味）、見れなくてもやる奴はやるかな？

何らかのメッセージを伝える機能は心理的不安を煽ったり（通報した！監視中やで！）や個人情報を流す
WEBや電話その他の攻撃依頼等に使われる？

機能が増えればやっぱセキュリティーホールの様な物が出来る可能性が増えると思うし
トラフィックを増やして通信不能に陥らすような物とかかな？

外部プログラムで実現してくれれば、それを入れないって選択肢も出来るのだけど、、、

っと書いてる間に47氏が君臨していたとは、、お疲れ様ですー

47氏乙彼様デス!!
掲示板の件、くだ質の方にレスしてくつもりが、本スレで議論が発展してしまいました。
でも、そういう見解が聞けたダケでもヨカッタデス。

＞くだ質と、47氏のレスを見ると、完全品のハッシュの整合性チェックは変換作業時
＞のみなんで、結構破損した自称「完全キャッシュ」がそのまま出回ってる様子。

まだ、仕組みが理解できていない様子。

んー、個人的には人のソース見てよりよくするほうが１から組むより
スキル要るんでソース公開して意味があるぐらいならその人がもっと
いいもの組んでくれと思っちゃいますけどね（ｗ

>>327
ｺﾞﾒｿ、じゃぁなんでオレはバーコード地獄から抜けられないの？

たまに「自動ダウンロード」画面でキーワードに関係ないファイルが
やり取りされてるように見えるんだけど俺だけ？
どうやらそのファイルは自分のキャッシュ内のファイルの様なんだけど・・・

>>328
過激なまでに胴衣

>>328 (´□｀;)ﾊｩ、またまたデシャバリスンマセン。
たしかに、自分流に一から作り直したほうがハヤイということがオオイカモ。
外側とはいえオープンで開発するとなると規約やバージョンの同期も大変ですし、
インターフェース部分も好き勝手に変更できなくなるし．．．
>>318 のように「手伝えないのが悲しい････」というのが根底にあったもので．．．
ヤッパリ漏れも過去ログちゃんとヨメ!!ってヤツでした。

>>327
う〜理解シチガエテタラスマソ．．．
たしかに、昔の「port0や回線詐称はトニカク排除しろ」とか、
「UP貢献度を設定してその分だけDownを許可」の頃っスレて、
なんかスサンでて47氏の発言前後以外読み飛ばしてたんだよナ〜。
チョット、過去に逝ってきます．．．

a

47師に激しく感謝。
自動DLのサイズ上限とか素晴らしい！　（遅っ

で、勝手な要望。。　

・交換機能をつけた場合は交換中は他の中継を一切せず、他PCを通して快適に交換。

・ある一定期間を経過するまでそのキャッシュが機能しない


交換時専用の時限式暗号みたいなもので…
新しいファイルの流通をよくするには交換派を巻き込むことは大事だし。
winny利用の交換の利点＆キャッシュの増加になると思います。


誰かがキャッシュを削除してしまうと不完全ファイルのまま…だし、
レンタルの様に一定期間をおけば
「誰かが得をすると損をした気になる」
という事も少なさそうだし…

部分キャッシュがDLできないんだけど、仕様？

>>334
他人を中継に利用しといて、自分の交換中は中継したくないなんて、
自己中すぎるぞ。
交換したい奴はMXに逝ってくれ。

>>335
くだ質ｽﾚでも馬鹿にされるくらいの厨な質問だな

MXの次別館 くだ質、雑談、愚痴スレッドその2
http://tmp.2ch.net/test/read.cgi/download/1022428582/

を１から、読み直せ

>>336
でも交換の中継に使われたノードには
交換された二つのファイルが丸ごと手に入るわけで。
クラスタ化がもし完成した後の話なら、
似た趣味のファイルだろうから、かなり(ﾟдﾟ)ｳﾏｰな筈。

まぁ自己厨的思考であるというのには同意。

ソース公開は絶対に反対。
ULだけ帯域制限かけたり、自動DLを無制限にしたりといった
自分勝手な派生バージョンを作る厨が絶対出てくる

Winnyのシステムを利用して交換したい奴は勝手にすればいいが、
交換したいからWinnyの仕様をかえてくれという奴は逝ってくれ。

>>339
反対というか、、、今の流れだと絶対オープンソースにはならないだろ。

>339
そんな事ぐらいだったら、ソースなんて無くても出来るぞ？

利点をだして、交換しかしない派をMXから招くにはこれが一番かな、、と思ったのですが…


逝ってきます。。

>>334
やっぱり　いろんなところで紹介されると　交換って言う人が現れるか
すべては47師の判断にお任せすると言う前提で
"131072"からβ14.6まで進む過程での雰囲気として交換はWinnyのコンセプトに合わないと
個人的には思います　どなたかおっしゃっていましたが

One for all,All for one が基本でしょ

MXでの殺伐とした雰囲気を嫌ってWinnyに期待している人も多いかと
自分はリソース（ファイル（２５０GB)、キャッシュ（２５０G)、回線（FTTH)、PC（常設））を
Winny環境に提供する予定ですが”新作（レア）ファイル、交換”等の
概念が広がるようであれば撤退するつもりです

どんな新作も３ヶ月後には出回るでしょ　　
メリットがないと新作流さないよって考える人は入って欲しくない
自分は何の見返りなく新作流しますよ　エンコ環境もあるので

ま、いろいろな感覚の方がいますから否定はしませんが
MXみたいに訳わからん事になるので困るな
交換実装すると撤収すると考えている者も居る（俺だけかな？）という事で

議論が深まっていく過程でまた考えて行きたいと思います　

>>343
俺にとっては交換しかしない派をいかに近づけ無い様にするか
これが大事です　交換しかしない派に共有環境も与えるのですか？

>>344
あなたはWinnyにおける神です。

>346

本当に神か?　

餌ちらつかせて議論の方向を、自己利益の為に
曲げようとしているようにみえてならない。。。

250Gがどーのと書く必要ないだろ。

念のために書くが俺は交換否定だけどね。

>>347
確かに書き方大人げなかったかな　スマソ
でも　本当よ　光同士でWinnyの事話すと大まかこんな感じ
で理解してるYO　安全にﾏﾀｰﾘ開放神が希望

実際、今　UP25　DL2　させてもらって正直うれしい
ファイルを得るより　47師のコンセプトに共感しました

リソース提供なんて47師の努力と比べれば　ゴミみたいなもんですけど

逝ってきます　スマソ

アプリ（２００M）がキャッシュから変換されるとき170から7まで落ちるんですが改善ｷﾎﾞﾝﾇ
WinXP　ver14.6

>>344
すげー。

Winny上の掲示板関連は、47師自身まだやる気無いって言ってたけど、
2chのような「掲示板」としての形ではなく、
「不特定多数に送信するIM」みたいなのは簡単に作れそうだよね。
メッセージをWinny上で書き上げて、流すようにすると
自キャッシュにIM形式を認識するための特別な属性か何かがついた、
メッセージのキャッシュが生成されて、当然の如くそのキャッシュの情報は他ノードに吸われ
あちこちに回されていく。
そして受信側は、受信したキーリストから
IM属性がついているものを取り出し、いわばメールボックスのようにIMリストを表示する。
あとは、興味あるIMだけを開いて見てみたりするわけだ。

利用方法としては
「アニメの○○をUPしました。暗号は＠＠＠です」
「捏造ファイル発見：ｼｼﾞｰのDisc2で、ハッシュは〜〜〜〜〜です。」

とか。まぁ勝手に考えてみただけ。

むー。公開暗号鍵利用の交換なんかは
初スレからすでに47氏が言及してますが。

>>347
>餌ちらつかせて議論の方向を、自己利益の為に
>曲げようとしているようにみえてならない。。。

コ?メソ。意味がわからん。光、250Gであることを言ったからといって、
>>344の利益になるとは到底思えない。
それに議論って言ったって交換はほとんどのヤシが反対だと思うけど・・・。
まぁ交換希望のヤシの意見を聞く必要もあるかもしれないけど、
どうせ流れると思う。

>>351
>>340

>>327
う〜、スマソ、過去ログから、Tipsページまで読んでみたがワカランかった。
Tipsページも47氏の開発スピードに追いつけてないみたい．．．
>>214 とかの47氏の発言を読んで、そう理解してたんダケド．．．
LAN環境で試したいけど、ちょっと今はWinny環境を２つソロエラレナイ〜
ドコがヘンだったのかヒントだけでもおしえてクレー。

>>348
う〜ん、別に共有環境を与えるダケならイイんでないと思うけど。
>>334の方式で交換の踏み台の為ダケに帯域とられるのはヤだけど。
新たにUPしないって事は、よ〜するに一般のDOM(中継屋)と同じコトでしょ？

「One for all,All for one」は触れてみてハジメテワカル事かと．．．
交換派だった人の中に１人でも、この考えに感化されれば、モノが流れ始めるワケダシ。
あ、もちろん、自ら積極的にUPする行為は尊敬します。
よって、戻ってきてくださ〜い。

>>345
良識派？だっけ？ジャイアニズム全開のあの手のを拒絶するのはシステム上不可能だけど
「共有」ってのは交換派から見た場合、手持ちファイルのインフレ？要因になるのは間違えないと思う
ここで出回った時から、良質な交換材料にはならない＝交換原理主義者はここには来ない？（甘いか、、）
俺個人としては吸いたければ吸えば〜で良いんじゃないかな？
＃交換材料としての優位性を保つ為に、一部にはWinnyネットワークを攻撃する者が現れる可能性もあるかも？

それより数年後（5年先位かな？）これが継続できれば、回線速度の向上＆ストレージの容量あぷ、ナローバンド
全廃？などで、オンデマンドで再生が出来てるのかな〜？とちょっとわくわく。
草の根的な（UGなのがちょっと、、）だけど、商用ネットﾜｰｸより出来が良かったりして。。。

「交換を中継してあげたら、交換されたファイルが丸ごと手に入る」といっても、
暗号化されていたらどうにも出来ないよ。

×暗号化されていたら
○暗号キーが掛けられていたら

(　´･д･`)・・・

え〜と、ちょっと前から破損問題が深刻になりましたよね。
47師も「どっかDown側弄ってるときになにか変になったのかも」みたいなこと
言ってますけど、β14.3あたりから分割DLっていうか
同じファイルが複数転送開始されたときに、DL開始位置をずらしてくれない様になってない？
それよりちょっと前のﾊﾞｰｼﾞｮﾝまでは、複数が開始されると、
一つの転送ははじめから。二つ目の転送は5M地点から、みたいに
開始位置をずらしてくれてたじゃん？もしかしてそれがバグで外れたのかも。
だとしたら同じ部分を重ねて落とすことになるから、そりゃその部分は破損するだろ。

分割DLﾏﾝｾｰ派の俺の経験っていうか状況だと、
分割DLする形になった所がよく破損しているので、
こんな仮説を立ててみたが、どうよ。

>>350
レス番間違いかな？
掲示板・回覧版機能は47氏も現在まったく考えてないって言うし、
その手の話は、一緒にくだ質でしましょう。

くだ質なら、どんなアホな提案しても、OKだよネ。

winny全体からみたら利益になるからいいんじゃないかな。
そのうち「One for all,All for one」に感化されるかもしれないし

>>334

>>359
すまん。
2回にわけて書くものを一緒に書いてしまった（ｗ
＞その手の話は、一緒にくだ質でしましょう。
ですね。あっちでﾏﾀｰﾘやりますか。
確かにどんなアフォな提案でも　まぁ許されるし（ｗ

ファイル検索、暗号キーなどで
半角全角小文字大文字アルファベット
AaＡａを区別しないようにして欲しいです。

小文字大文字は初めから区別してなかったかも

0x00421d18の命令が何度もメモリreadにならなかったエラーの原因になってますが
これってうち固有の問題？

アホな事書いてすいません…

>>344
でも、光がまだ普及していないということもありますし、、、
HDDには入りきらないファイル、まだ見ぬファイルがあるかもしれませんし…

・エ○ゲーのコンプリート等、
HDDに全てを保存するのは厳しいような物を集めている場合、
MXで交換相手をみつけてwinnyを利用して交換

→ファイルが手に入る
→キャッシュも広まる

という利点になるかなぁ、、と。
FTPの様に出回ってないファイルをULする事に見返り、、というか、、、
やっぱり人参があると速く走るものですし。
欲しいファイルもみつからずULし続けるのは嫌だ！
と思う人もいるかもしれませんし…


>>345
それだと
「中継のみで獲るだけ獲って交換材料に。交換で得たファイルは共有しない」
という房の現状が…

>>356
期限付きで一定期間後に解除ができれば…(でも無茶苦茶めんどくさそうだけど言うだけタダなので
勿論



回線状況が劇的に変わらない限り、winnyがより便利、豊富な共有物にする為には

・キャッシュ増加
・リソース提供を進んでする人(神)が増えるようにする

というのが大事かな…と。


HDDが足りなくて全てを共有にまわせない人達が
MX等で「交換はwinnyで。期限設定なし」
と指定すれば、キャッシュ増加もリソース提供もできて良いかな…と。

実現すればwinnyでは出し惜しみされているような物もすんなり出回る様になるかと。


低速回線で交換優先になりがちな者の戯言でした…

出し惜しみされるようなものをでwinny交換しようと思わないのでわ。

個人的に「来る者(物)は拒まず、来ない者(物)もまた拒まず」って感じが
winnyにはするんだけど、そうまでして規模拡大しないとだめなんかな

>>364
自動DLをOFFにすれば直ります

ｶﾞ━━(ﾟДﾟ;)━━━ﾝ!!!!!
外出前の書き込みの後に47氏
どうも、昨日からタイミング悪い。

自分のUPしているファイルの表示・・・賛成〜
キャッシュはキャッシュファイルの名前のままで表示。
これ（・∀・）ｲｲ!!
でも、人によるから表示がon,off出来るようにもしないといけないかな？
って、また遅レスになった・・・

>>366
その通り

>来る者(物)は拒まず、来ない者(物)もまた拒まず

この様な懐の深さがWinnyにはあるんだよ

自動ダウソが付き、UL DLの接続性もよさげになった今は
検索の広さ、安定性、軽さの向上が（・∀・）ｲｲ!! のでは。
正直、UPしているファイル表示されても・・・
自ファイルの人気の度合いは知りたいが・・・なぁ。

MX並の匿名性になってたバージョンってどれ？

破損キャッシュ絡みは今週末中に対策とられるかなぁ・・・

おいおい、４7師を休ませてやろうぜｗ

>>373

酸性！

>>373
激烈に産製

真面目に参政。
今のβ14.5だっけ。めちゃくちゃ使い勝手いいもん。
これだけで十分使える（ｗ

今日くらいはサッカーでもみようよ。

>>377
少林作家見るからいいや。
雑談ｽﾏｿ

おっと、最新はβ14.6だったか。
更新早すぎてついてけないや（ｗ

本気で自動DLのハッシュ指定が欲しい・・・
捏造ファイルつかまされちゃうじゃん。そうしないと。

>>327に指摘されてイロイロ調べたけど>>322であってるんだよね。
環境そろえて実証してみたら、確かにそうなったんだけど．．．
>>372もとりあえずは、>>322の方法で補完できないかなぁ。

ところで・さ…
やっぱ暗号キーって使い道ないよ。
中継に「@」出てくるとウザくてウザくて。
これこそwinnyの精神に反しているのでは？

>>381
>winnyの精神

いつも疑問に思うので確認しておくが、winny=共有 みたいなイメージは、
47の方針と何にも関係ないよね。

>>275
亀ﾚｽですが、理解できました。
これ使って完全キャッシュ偽装してるやつがいるってことですな・・・

またそうしたくなくてもリフレッシュ押すだけでなってしまうわけで、
ほかの人から見えるファイルが減ってしまってる


・・・直るまでリフレッシュ禁止にしてほしい

>382
うん。47氏の方針とは関係ないよ。
でもβといえどこうやって世に出た以上、
ある部分では47氏の手を離れてると思うのだが。
だから47氏の方針＝winnyの精神、ではないのよもうすでに。

>>384
んなこたぁない

>>384
激しく狂おしいほど異議　とうとうこんな人まで　（涙

47氏の精神＝winnyの精神≠共有のみ？

>>387
そうだと思う。
共有精神とか、あんまり関係ないような。
技術的におもしろいかどうか、だし。

実用的なfreenetの実現を目標にしてたんだから
共有になるのはしょうがないかと思われ

47師の最初の発言によると、「freenetみたいだけど２ｃｈネラー向きのファイル共有ソフト」らしいね

いやいや、ちょっと論点がズレたね。
共有だの交換だのはどっちでもいい。
ただみんながウマーになるのに暗号かける意味があるのかと。
MXでの「交換厨」が、winnyでは「暗号厨」になるかと。

>>391
つまり、、、何。
381の発言から読み取るに、暗号キーは要らないと？
＞中継に「@」出てくると〜〜
正式版では中継してるファイルも隠されるはずだろ。

先日，あるデパートで見かけた光景なのですが，中学1〜2年生ぐらいの女の子たちが，
店先のパソコンでWINNYを起動していました。おそらく，中継の高速回線とキャッシュ容量を確保するでしょう。
以前は，P2PなどはPCのヘビーユーザーのアイテムだと思われていましたが，
もはやそんなことはありません。信じられないなら，実際に中学生にアンケートを取ってみるといいですよ。

>>393
あったらちょっと嫌かも（w

っつーか，暗号キーは
匿名性をあげるのに使われんだろ?

ただの共有ソフトじゃなくて
使い勝手がよくなおかつ匿名性が高い共有ソフトをめざしてるんだろ?

winnyの方針に合ってるじゃねーか

(・∀・)ﾐﾀｲｨｨｨ!!

ただ、その暗号キーが、イマイチちゃんと機能しているか判断しにくい罠（w
何入れても出てくる、ファイルとかあるし。
文字列周りのバグも未だ残ったままなんで、何が悪いのか良くわからない。

>>395
そうそう、
共有＝解放＝違法
の回避策

そういや、店PC販売店も転送専門としてつかえるなぁ

>>397
まずは転送まわりの完成、暗号化の調整はあとからでいいじゃん。
　βなんだし。

　あまりにもできがいいβなんで勘違いしてない？

なるようになるだけなんだけど、精神どうのこうのの前に
Ｗｉｎｎｙ＝Ｐ２Ｐによるキャッシュ共有システムだろ、技術的には
それに多段転送発生の可能性（帯域の共有）が加わって出来上がったものと
いったところじゃないのか
ファイル変換後自動的にキャッシュ削除みたいな機能がついたとしたら
４７氏は共有を考えていないと思うが、それで成り立つのか？

共有の概念が気に入らないっていう人は、あまりＷｉｎｎｙには向いていないと
思うよ。技術的にいって

暗号キーはいると思う。ＤＬ者にとっては邪魔でしかないんだけど、転送者とＵＰ者のためには
実際のところ、ある程度認知されたもの数種ぐらいに落ち着くんじゃないか

>>393
昼間のport0には女子中学生が混じっているわけね（ｗ

>技術的にいって
この一言になんかワラタ

>>400
調整は後でいいと思うんですよ。
ただ、βの内に明らかなバグは潰しておく必要があるわけで、
例えば、今の検索は「ガード」って入れると、「ヌード」が
引っかかってきたりするので、本来出るはずの無いものが
出てきて負荷を高めている可能性もあるわけです。

最初の方の版で、必要の無いキーは送らない様にしたと、
47氏が言ってたと思うんですが、違うキーも引っかかるんであれば、
無駄なキーも送ってる可能性もあると考えられませんか？

>392
そう。要らない。
一部の人間にしか見つけられないファイルはみんなのためになるかい？
今は中継も見えてるから、自分に興味ないファイル中継してても
みんなの役に立ってる気がするのでやさしく見守ってるが、
「@」がくると「お前らだけでコソコソすんじゃねーよ」って気分。

>395
暗号キーありとなしとでどこまで匿名性が変わるのかギモン。

>>402
禿同　ちょっと皮肉っぽいところが　ステキYO
いやマジで胴衣です　<<401

>>404

暗号キーを使用すると暗号キーを知っているやつしかファイルの複合化が出来ない。
もちろん検索にも引っかからない。

全く同じファイルでも暗号キーが変わればキャッシュも別ファイルになるんだよね？

ということは同一のファイルが複数の暗号キーでUPされてると仮定する。
全て俺を経由して転送された場合、
俺のキャッシュフォルダには同一のファイルが複数存在することになる訳だよね。

仮にこのファイルが500MBで10個の暗号キー分あったとすると5GB占有されるのか・・・。

>>407

そんなことは現実的にありえない。
今は実装されていないが、キャッシュに関しては需要のないファイルから
消されていくので、個別の暗号キーを使用したファイルは早めに消えるはずだよ。

>>404
お前は燃料にもならない。帰れ。

>>408
確かに突飛過ぎたかもしれん。

でも700MB×２くらいなら起こりうる。つーか起きてる。

>>404
中継者は中継されてるファイルが暗号化されてていて、
何が中継されるかわからないからこそ、善意の第３者でいられる。
切るなら、Nullキーの中継を切る方が筋が通ってるような。

>>407
捏造ファイルに対する防御と同様に、
なるべく単一のファイルを流通させて、キャッシュ効率をあげるように行動することが、
ユーザー文化として根付くといいなあ。

>>410

なんでそんなことがわかるの？

>>407
今はソウかもしれないけど、同じファイル(ハッシュ)なら、
同じキャッシュとして扱ってくれるとイイよネ。
本体とヘッダー部分とかの分離が必要になっちゃうかもしれないけど。

あとは、たしか、ハッシュとってから暗号化してるから、
コレを逆転してもらわないとダメなのかな？

もしそうなら、コンバーターでもなければ、今のキャッシュを
捨てることになるけど、できるんならβ版のウチに．．．

>>409
イヤイヤ、どんなにアホだと思える意見でも大事だと思うヨ。
ホントにダメな意見もあるけど．．．
DOMすら役に立つ存在にした、47氏を見習おう!!

>>413
>下４行　かなり酸性
せっかくの大金星の価値を下げてるし
この発言　>>384　見て放置ｹﾃｰｲしてました

これからこんな感じのヤシ増えるのかな　ﾊｰｰｰ

一応言っておくと暗号キー肯定派なんだｗ。

ただ、同じファイルは別暗号キーでも同じキャッシュに出来れば最高かなと。

で、実現させるためにはキャッシュファイル内に暗号キー保持するのが簡単なのだが、
そうなると検索の度にファイルアクセスする羽目になる。
というわけでこの案は却下と自己解決してしまったんだけどね。

>>412
今話題のしーじーが２つある。同じハッシュ・ファイルサイズで別ファイル名。

今確認したらサイズ同じのが５種類あるぞ＞416

>>417
ん？勘違いかな？
確認したいけど今キャッシュ用ディスク整備中なんで終わったら確認してみる。待って。

円盤２はどれが本物だ？サイズ同じハッシュ違いがありすぎて、どれがオリジナルか分からん。
d88〜のをDLしてるが、何度やっても変換時に同じ場所でエラーが出る。

>>419
d88〜は円盤1だろ？
円盤２で捏造じゃないっぽくて、必ず同じ場所で破損がでる（17% 85%あたり）
というファイルは 4df〜って奴。

>420
すまん！そうだ。d88は円盤1だ。
4Df〜ファイルはレジューム20回ほどトライしたら、17%はクリアーできた。
しかし、84%の箇所は何度やってもだめだ。

4df〜
レジュ成功！→キャッシュ破損　さらに　レジュ→キャッシュ破損　も一回レジュ…
エンドレス・・・

>>418
えっと、しばらく時間がかかりそうなので次の方法で簡略化して検証しました。

１．適当なファイルを用意
２．Winnyを孤立状態で起動
２．テスト用の空フォルダをキャッシュフォルダに指定
３．１のファイルを暗号キーつけてUP
４．３のファイルをキャッシュ化
５．１のファイルを３とは別の暗号キーでUP
６．５のファイルをキャッシュ化
７．UPフォルダを外してキャッシュ化されたファイルを検索

テスト用キャッシュフォルダ見れば一目瞭然なんだけど同一ファイルで２つのキャッシュが出来上がり。

まあ、出来て当然なんだけどね・・・。

>>422
元ファイルがもう破損してたに1000ｸﾎﾞﾀﾝ。
他の円盤2は捏造じゃないけど、改竄ファイルで上手く使えないらしいし・・・。
って、こっち本スレだったね。別館でやったほうがいいね。こういうのは。

>>416-422
シジの話はくだ質でしない？　

破損対策について、今は．．．
>破損対策は暇見てやります。そんなに難しい問題ではないですので。
っていってた、47氏待ちだし。

>>425
ごめんなさい

>>425
俺もかよ！(￣Д￣;)

本スレ用ネタの一部なんだが・・・。
まあ、いい。しばらく本スレ自粛しまっす。

>>427
イヤイヤ、スマソ。
>>416は、本スレのナガレの一部だってコトは流れでワカッテたけど．．．
その後のナガレがヤッパリコウナッチャッタかって思ったもので。

>>423の検証で証明されたなら >>413みたいになるとイイヨネー

>>428
いや、誘導した形になった俺も悪かったから仕方ない。すまんかった。
雑談になりそうなんでここまでｗ。

某disc2の騒動を見てて気づいたこと
同じハッシュで違うファイル名＆ファイルサイズのキーがいくつか出来てるな
これはバグなのだろうか？
日付から始まるファイルは多分元ファイルだからそれを落としてみるといいかも知れず
でも帯域制限60kB/sの罠

あいかわらず自動ﾀﾞｳｿ開始のボタン押し忘れるなー。
3時間も気がつかなかった・・・鬱

>>430
Winnyは、「同じハッシュで同サイズ」の物のみ同じファイルと認識します。
同じハッシュで別サイズは違うファイルです。

検索用のハッシュデータはサイズが小さいため、異なるファイルでも同じハッシュ
として表示される場合があります。
ただし、転送時はブロックごとにハッシュを確認するため、最終的にはすべてオリ
ジナルの完全コピーができあがります。

転送時のハッシュと、検索に表示されるハッシュを同一視してはいけません。

>>430
ソレ、くだ質で昨日もりあがってたヨ。
47氏の情報だと．．．>>202 >>211 >>214 って感じかな。

あと、一覧のハッシュみてて思ったんだけど．．．47氏に要望です。
GUI周りなので、大変重要度は低いので、もし読んでらしたらという事で．．．
実装は簡単そうなので、後で言うよりは、と。

「ファイル検索」の「ハッシュ」と「状態」は、左詰にならないでしょうか．．．
あと出来れば、固定幅フォントだとサラニ、アリガタイデス．．．

第4回まとめです。
えーと…前回から結構消えてますね…（笑）
47氏の凄まじさが伺えますです。
---------------------------------------------------------------------------
回線詐称問題
　現在回線詐称が横行しております。このままでいくと本来MAX3の人が30を転送し
そこを通過すると速度が1/10になってしまうという現象が起こるかと思います。
原因は、主に自動DLが下流ではできないということのようです。
対策として増速申告を行ってファイルやキーの転送数が増え
速度が低下した場合自分のDLファイルを真っ先に帯域制限を
かけるようにする方法、速度の自動設定などが考えられています。
帯域制限について　17-457,17-460
速度の自動設定について　17-778-812

　　　　　　　　　　　　　　最下流対策
　最下流近辺では自動DLができません。キー寿命が下流まで廻る間に尽きる
ということもあるらしいです。
現状では上流からキーを還流させるという案や
自動再検索&再試行の案が出ていますが、それぞれキー還流では
下流の帯域量や転送に巻き込まれるかもしれない問題
自動再検索&再試行では上流の負担という問題があるようです。
個人的には上流と下流の決定にある遊びが、ユーザー数が増えたときに
下流域でのループ構造を作りなんとかしてくれそうな気もします。
16-864,16-860,16-908

　DLランダム開始
DLの開始位置をファイルを8分割にしてその８ブロックのどれから始まるかをランダ

ムにして欲しいということです。8分割の理由は詳細参照。
　キャッシュファイルのばら撒かれ方が今より効率化されるはずですので
できるだけ早く付けてもらいたい機能の一つです。詳細　16-280

　検索のところで、1byte英字の大文字小文字を同一視してる
コードが、漢字コードにも影響を与えていると思われるのを直して欲しい
という要求が出ています。トロでエロがかかるとかいう報告が出てますので。
16-520

Ｗｉｎｎｙに認識されないキャッシュがある気がする(?)
　いまいち現状が把握しづらい問題なので >>57 >>72 あたりを参照のコト


　自動DLの登録件数の最大値をつけて欲しい　>>318

貢献に対する報酬システムの実装

以下の方法が提唱され、それぞれの問題点は次のようになります。
（単純なQの優先度はβ13.1によりQ代わりに自動DLがついたので
議論することに意味がなくなりました）
16-303 (47氏)

1.1 UPフォルダ内のものを参照する方法
　　参照数、UP容量などを基準とすることができますので
　　わかりやすく、共有数を増やす意欲がわきます。
　　みてて面白いというのもポイントです。
　　キャッシュ消去対策も兼ねます。ファイルステータスをうまいこと作ると
　　捏造、危険ファイルが淘汰できたりファイルの人気が
　　わかるようになるかもしれません。
　　参照数に関しては、LAN内で高参照のファイルを作ることができ
　　捏造ファイルを置くことにも現状のステータス（容量、参照数のみ）
　　ではメリットがあるため
　　捏造ファイル流通の温床になりかねません。
　　47氏の意向はこれを含めて貢献するのが
　　『面白い』ネットワークを作ることのようです。
　　参照　15-66,15-71,15-72,15-350,15-273(47氏) 16-373-374 16-407-408 など

1.2 接続時間を参照する方法
　　クラックがしにくそうなのと常設が増えそうなのが利点の
　　優先度の付け方です。難点は光と低速の人が同じ優先度になることです。
　　キャッシュを高速なところに集めてばら撒くという考え方からすると
　　これはあまり望ましくありません。
　　参照 15-107,15-109,15-112など

1.3 起動後の総UPファイル量を参照する方法
　　次にこの方法ですが、これは実際にネットワークに貢献した量
　　を直接測れる利点があります。
　　実際にたくさん送信した人の優先度を高くするという仕組みから
　　リクを入れられるためのUPフォルダの充実、長時間の運用、高速回線が有利など
　　実際の要求とかなりマッチします。
　　ただし、ローカルに情報を保存するとクラックの危険性が増しますし
　　LAN内での廻しにも弱くなります。また、捏造ファイルのメリットも
　　客引きという意味でありますのでそこが問題となります。
　　クラックについては複数の外部ノードに保存すると耐性が強くなると思います。
　　ただ、UPファイル通過→覚えるだけにすると同じノードと繋がらない限り
　　意味がなくなります。周りのノードに評価情報を伝えるといいんでしょうが…
　　あと、匿名性の問題もあります。
　　参照　15-66,15-71,15-72,15-350,15-53,16-932,16-936など

1.4 上記以外のパラメータを持たせる
　　上記以外の可能性が無いのかどうか要議論です。
　　ゲーム性、クラック耐性、貢献度の反映のされ方などを考えていきましょう。
　　15-273(47氏),15-255,16-255など

　　　　　　　　　　　　　クラスタ化（曼荼羅）
　クラスタ化については下の画像のような区分で分けることが提唱されています。
http://isweb40.infoseek.co.jp/play/maxmam/cgi-bin/img-
　　参考　16-475 16-476,16-481,16-893,16-906

自動DLのハッシュ値での指定
　完璧に狙ったファイルをGETするためにハッシュ値を指定して
DLしたいというものです。検索からハッシュ値を直接登録できると
便利そうです。16-519,UI部の提案については17-349参照

　　　　　　　　　　　　あふれるキャッシュの削除
　自動DLが入ったことにより、洒落にならないぐらいのDL量となってきてます。
無駄なものまで大量にDLしてますんで。というわけで
キャッシュがそろそろ溢れだしてる人多数です。
そろそろ最大キャッシュ容量（最低キャッシュ容量つきが望ましい）によって
マイナーなファイルを自動で消してくれるとありがたいなと感じます。
キャッシュの削除はネットワークには悪影響なんですが
これをやっとかないと常設に支障をきたすような気がしますので…。
手動でも消せますので優先度はさして高くないです。　16-630,16-751

　　　　　　　　　　　　その他の事項

その他の要求、希望には次のようなものがあります（重要度順）

自動ダウンの優先順位＜手動ダウンの優先順位になるようにして欲しい

UPフォルダからのUPは見えるようにして欲しい　18-299-305

本体の自動更新機能
本体をFreenetのgpl.txtのような感じでバラ撒いて（鍵付などで保護）
自動更新されるようにして欲しい。
うまくすればクラック対策に使えるかも…。17-681,17-701

検索結果からファイル名をクリップボードにコピーできるようにして欲しい 16-428

他多数

2つ以上のワードでの絞込み検索が欲しい　16-111,16-166

自動検索切断を有効にした際に、
全ての検索リンクが切れる場合があるのを回避して欲しい　16-890

ファイル変換で破損が発見されたらファイルにされないオプションが欲しい　16-584

転送が開始されたらリトライカウンタを0にして欲しい　15-24,15-260,15-962

ADSL8Mのデフォルト値を200→100にして欲しい　15-323

自動DLでINCOMPLETEをNGワードにして欲しい　16-920

自動ダウン最大値の方に小さいのをいれた場合は逆転するようにして欲しい　18-32

ファイル検索にフォルダ名も含んで検索して欲しい　16-535

タスクごとにUL速度を表示して欲しい 15-725

タスクバーに入れられるようにして欲しい(パス付で)　16-839

アイコンを変更して欲しい　15-365,15-367,16-79など
　　http://www.geocities.co.jp/SiliconValley-Sunnyvale/4142/

外部ツールによるいかさま防止をして欲しい（？）16-563,17-127

>>434
あと　破損キャッシュ（不完全ではなく）が流れないようにして欲しいな

　　　捏造に関する問題

　捏造対策については色々考えられてますが、捏造を受身で防ぐ策より
積極的に捏造の意味をなくすシステムを考える方がよいと思います。
というわけで上記のご褒美システムと絡めて考えましょう（私見）。
関連　17-352
--------------------------------------------------------------------------
とりあえずまとめ終了です。あと個別に…
47氏発言更新分全て　17-382,17-399,17-625,17-644,17-707,17-729
17-740,17-929,17-938,17-941,17-960
>>90 , >>151 , >>152 , >>189
>>194 , >>202 , >>204
>>208 , >>214 , >>223
>>226 , >>231 , >>259
>>323 , >>328

重要と思われる発言(引き継ぎ)
あと、β１４はこの辺の調節しようということで、参照数のトータルが見えるように
なっていたり、他ノードの参照値を他ノードが知れるようになっています。
まだ見れるだけでこれらをどう使うかは様子見しながらですので、
何かよさげなアイデアあったら教えてください。（47氏）

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

バグ報告の心得 16-62,17-768

足りない部分や間違っている部分があると思いますんでご指摘お願いします。

ごめんなさい…sage忘れました…10周まわってきます！！

>>437
> あと　破損キャッシュ（不完全ではなく）が流れないようにして欲しいな

完全キャッシュが実は破損しているかどうかというのは、
一度復号化してみなければ分からないので、
それは難しい要求かと。

でも
>>425
かいてあるような　どうなんでしょうね？

まとめ氏、乙カレサマです。

>>440 >>441
起動時や接続切断時に、今の強制変換モドキを行ってチェックするとか行っとけば、
自称「完全キャッシュ」な「部分キャッシュ」はナクナルト思うけど．．．

転送時、受信時に64K単位のハッシュチェックを行うとかって案もあったっけ？
でも負荷が凄すぎて耐えられないかもって話だったカナ？
なにはともあれ、47氏の対応待ちですナ。

>>442
あんまり　要求して　47師が　体壊したら　大変だし…
前のレスじゃないけど　WCだし
ﾏﾀｰﾘいきましょう

タシカニ、マターリ、イキマショ。

ト、イイツツ要望は出来るだけ少なくしてマトメた方がイイヨネ．．．

>2つ以上のワードでの絞込み検索が欲しい　16-111,16-166
>自動DLでINCOMPLETEをNGワードにして欲しい　16-920
>ファイル検索にフォルダ名も含んで検索して欲しい　16-535

コレってある程度は、正規表現で可能だと思うんですけど、
結局、正規表現の話って結論はどうなったんでしたっけ？
イマイチ、ウヤムヤで議論が終わってたヨウナ．．．

>>442
強制変換モドキって、700MBファイルだと数分かかる。
それを起動時などにやるのは、ちとつらいのではないかと。

レジューム時に、ファイルの末尾を少し削ってからレジューム
するようになれば、破損はだいぶ減るんじゃないかな。

>>444
ｏｒ検索　not検索　フルパス検索・・・
ごめん　なんか　MX風
てか　前のレスにこういうこと書いてあったよね　確か

>>444
過去ログ16の
800番代後半　辺りにそんな話出てる　他にもあったと思ったけど…

はぁはぁはぁ（息切れ）

ちょっと掲示板議論のときに思ったのですが
別に近隣の人とご近所話をする分には匿名性あんまいりませんよねぇ。
直接繋がってるんだし。
わざわざWinny上でFrostみたくしなくても
ただのチャットや掲示板搭載すればそれだけで近隣の様子はわかって楽しいかと
自分の上流の人の状況聞いたり、下流の惨状聞いたり…
お隣さんがどーゆー人か知れるだけでも有益だと思ったので。
隣が悪そな人だと引越し（繋ぎ直し）そうだし。
参加者の心が色んな意味で試される案ですけどね。
testとしては面白そうじゃないですか？

47氏はあんまり乗り気ではなさそうですが（笑）

また追加で10周だぁぁぁ!!（涙）
もうしばらくは書き込みは控えます…

>>448
近隣のIP分かってるんだからIPメッセンジャー使ってみるとか・・・ｗ。

>>448
いってらっしゃい
もし隣が　ＫやＡだったら…

>>445
イヤ、確かに数分かかるという47氏の見解ダッタです。
というか、コレは自分の稚拙な案の１つと言うことですので．．．

>>446
CPU負荷をちょっとおいとけば、今あるフリーの正規表現dllとかつかって可能かなと思うんだけど．．．
検索エンジンと同じように指定できれば理想カナ．．．
正規表現ってナンデスカって質問が溢れ返る可能性もアルケド、
ググルのヘルプを見てクダサイですむし。

>>448-450
そうですね〜。
でも、２ちゃんもあるし、P2P掲示板が、現在もアル以上は
そちらにお任せシマスってのが47氏の見解デシタシ．．．

というか、掲示板みたいな機能があったらオモシロイヨネって話題は
くだ質のほうが．．．
本スレでレスしまくった本人が言うのもナンデスガ．．．

>>452
本当に正規表現分かる人は少ないかもしれないと思うから　（漏れだけ？）
搭載は後になりそな感じですなぁ

正規表現の話は終わってます。詳しくはいくつか前のスレ参照。

>>454
アリャ、ソレハ、スマソ。　DAT落ちしてたスレだっけ？
たしかに「ノードの負担が大きくなりすぎるため、採用しない」とかって
カナーリ昔に47氏が言ってたような気がするけど．．．

その後マタぶり返してて、要望にも似たようなのが載ってたので、
言ってみましたが、早計デシタネ。
マタ、チョット過去に逝ってきます．．．

漏れら極悪非道のageブラザーズ！
今日もネタもないのにageてやるからな！
￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 ∧＿∧ 　 ∧＿∧ 　　　age
　（・∀・∩）（∩・∀・）　　　　age
　（つ　　丿 （ 　　⊂）　age
　 （　ヽノ　　 ヽ/　　）　　　age
　 し（＿）　　 （＿）Ｊ

>448 >452
隣近所との会話は弊害のほうが多いと思う。
ウザイとか重いとかケンカの元になるだけで。
むしろ、ファイル単位で１行BBSのようなものが付くと面白いかと。
ノード間の転送量は少々、というかけっこう増えますが、
捏造ファイル警報や注意書きの告知のためだけにファイル名を変えるとか、
名前とエンコードが違うだけで内容が同じファイルを何度もDLするような
ムダが減ってよいのでは？

蓄積一方だとサイズが膨れ上がるので、
ノード数またはサイズを数えて一定数以上は古いものから捨てる。
ただ回覧ならともかく、大量メッセージのついた1kB以下の小物が出回るのも
なんだか馬鹿馬鹿しい気がするので、
一定数というのはファイルサイズによって段階的に変化してもよいかも。
少なくとも無駄な転送量を抑えるには、
大きいファイルほど個別に語る意味があるんじゃないかな。

出回ってるファイルが少ないぞゴラｧ！

いつになったらβテスト終わるんじゃろう？

思いつき追加ですが、
１ノードにつき１発言（同じ人の次回発言は上書き）のようにすると、
発言乱発による荒らし防止と都合の悪い（ヤバイ）過去発言の消去が
兼ねられてよいのではないかと。一時的な暗号キーの告知にも使えますね。
通常のBBS風利用法ではなくなりますが、こだわる必要があるわけでないし。

>>458
消え去る運命です

僕たち純真無垢なsageブラザーズ！
人目につかないようにsageてあげるよ！
￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　 ∧＿∧ 　　　　∧＿∧ 　　　sage
　　　（・∀・　）　　 　（　・∀・）　　　　sage
　　　/　　　 ＼　　　 /　　　＼　sage
　 ⊂（　　ヽﾉ　つ　⊂ヽ/　　） つ　　sage
　　　 し（＿）　　　　　（＿）Ｊ

最低受信速度を設定すればよいと思う

ある一定速度以下の転送しかしてくれないノードとはバイバ〜イ。
中継役は気にする必要ないので、DLするノードが、ファイルごとに設定する。

効率悪いノードは見放されていくので、結局下流となる。
んで、優先度は転送下流の接続数も考慮される、と。

>>461
(・∀・)シムラケンのヒゲダンスを思い出したYO！

描画ルーチンの更新はまだれすか？

まだβでバグも残ってる＆ダメだしの為の機能もあえて載せてるのに
現バージョンが一つの完成品として見てる輩が多いな

ちゃんとβと言うことを認識して、現状のバグ、正式リリースはどうする予定か、
そのあたりをキチンと把握してれば現時点で暗号キーがどうの中継表示がどうのと言える筈がないのだが

βの今だからこそ色々と意見は出しておくべきでしょう
細かい意見だろうと色々と出たほうがいいと思うよ。

ただ、既出のバグで「まだ直らないの？」みたいなのは、いらないと思うけど

既出のバグをバグと認識せず「これが正式版か」と思って話進める輩が多い

β14.4でOSごと固まりました。

W2kSP2+SRP、RAM256MB、ADSL2M(申請50)、ルータ使用(7743に穴空け)で
試用中でしたが、帰宅したら画面固まってた(^^;
K/B、マウスも動かなかったので、再現情報提供できずスマン。
現在、β14.6に入れ替えて様子見てます。

参考にならないと思いますが、一応報告まで。

β14.6でＯＳは大丈夫ですが、Winnyが落ちます。
すでに２回おちたので、６時間に１回ぐらいの頻度です。

※安定度的にはβ14シリーズの中ではβ14．1が一番よかった感じです。

まぁ、変更点が多いし過渡的に不安定になるのはしかたないですね。

会話やらBBS機能なんて付けたらどっかの団体の人が喜びそうだ・・・

相変わらず帯域を目いっぱい使うからとても常時起動させておくことはできないなぁ。

>>471
そーゆー場合にゃ帯域sage申告。

>>472
回線速度だっつーの。

ｽﾏﾝ、くだ質とまちがえた。。。・ﾟ･(ﾉД`)･ﾟ･｡

私は、むかしから正規表現うだうだ言ってますが。

確か却下された理由は検索キーが重くなるからって理由だったと思うのですが
私が望むのは
あるキーワードで検索してとってきたリストにローカルな範囲で
正規表現をつけてほしいです。
MXみたいに
TextBoxが２こあって上が普通の検索ワード
下が正規表現欄でお願いしたいです。

正規表現わからない人でも下の正規表現欄に
普通に文字列いれたらとりあえず正規表現的にAnd検索で絞れるし

あくまでローカルに持っているキーでリストに表示する前にフィルターかけたいだけなんですが

>>474
正規表現、過去に逝って、イロイロ見てキタケド．．．
う〜、逆順に読んでったせいかワケワカラナクなった。
ダメダシがあったとして要望に残りつづけているという事は
別の解決方法でもあるのダロウカ．．．

ローカルでの検索は、賛成ですナ。
ココラヘンの優先度は不明ですガ。GUI周りに近い気もシナクモナイシ。

でも、検索キーが重くなるって事デシタッケ？
投げるキーワード指定の増加なんて、２回も３回も検索スルヨリはマシなような．．．
むしろ、欲しい範囲が狭まるので、落としてくるリストは小さくなるような気も、
って、検索カケタ、キーリストだけ上流からダウンしてくると思い込んでたケド
ソレモ、カンチガイ？

>>474
気持ちわからんでもないが、そうするとみんな拡張子などなるべく多くヒットする検索をしておいて
ローカルで絞るような使い方がメインになるから、流通ファイルの増加に伴って検索キーの流通量が
大きく膨らんでしまいダメだと思うよ。当面は機能するとは思うけど

表示２００に収まるように、なるべく意識した検索するのが自分のためにも全体のためにも、吉かなと

正規表現でうまく絞り込めれば間違いなく通信量削減に貢献するだろうが
負荷は実際やってみないと実用にならないかどうかはわからんよなあ。
それにあまりある威力があると思うんだけど。

>>476 表示200に収まるように意識して検索
無理。せめて複数ワードでの絞り込みが出来ないと、全く実用的でない。

検索が重くなるという理屈は、漏れには理解不能。
処理は多少多めになるが、ノード間のキーの流通量と、無駄な自動DLは確実に減るはず。
帯域よりCPUパワーの方が貴重、という観点から不採用なのだろうか？

>>477
たしかにネ。　デモ全文検索モドキの機能なんで、
上流にいくほど、サーバーみたいにCPUの負荷は重くなっちゃうなぁ．．．

>>476
デモ、探しに行く人はナニしてもメチャクチャ検索カケチャウと思うけど．．．
ココらヘンは、バラバラだけど、要望にもある、コピペ機能と
ローカルキューのヨウナ機能の組み合わせでも、チョットは防げるかな？
iriaみたいにダウンローダー感覚で、リストからタスクに移動ダケしておいて、
ダウンは開始しないト。
こうすれば、検索を繰り返さなくなると思うけど。

1.5MADSLなのにULが100k/sとか表示されてます。
なんか速くなったみたいで気持ちはいいけど。

>>394
>>401
393は、CCCD(コピーコントロールCD)関連のコピペですよ。
ニュース系ホームページの記事だったかな、多分。

スレ主旨から逸脱ｽﾏｿ

（´-｀）.。oO(検索リンクの遊び、50%から100%にしてもらえないかなぁ)

あと、回線詐称の問題も含むけど、自動ダウンロード機能とかも
１つ上流、アルイは横？も受け持てないかな？
前々スレ16の593のとかが提案してたけど、そのままだったし。
指定してある、先頭100個分くらいを、接続先に投げておくと。
そうすれば、どんな物があるか検索するときダケ検索するんで、
自発的に検索しにイカナキャナラナイ回数が減ると思うんだけど．．．

それでも、サラニ検索する人がタクサンいるなら、
自動検索の肩代わり先は検索を受け付けないとかにスレバ．．．

UPに貢献シニクイヤツ、詐称ヤローは排除、強制制限シロ!!
って考えちょっとヤなんだヨネ．．．
47氏の考えミタイに、ヘンな事するウマミを無くしていけばイイだけで．．．

設定時の自動回線認識機能とか、イツカは欲しいけどネ。

>>483
読みにくい。日本語を操ってください。

OS/CPU/ﾒﾓﾘ：Windows 98se／Pentium �V 800EB／128M
回線　　 　　　：ADSL　DL1.5M/UL512Kb
環境　　　　 　：グローバルＩＰ
待受ポート　 ：7743
使用ｸﾗｲｱﾝﾄ ：Winny β14.6
速度申請　　 ：50
キャッシュ　　：10G
症状　　　　　 ：公開用フォルダが突然、認識されなくなる。
　　　　　　　　　当然、その中のファイル。

14.5の時からでした。

他にこんな症状が出た方は・・・・・いないか。

ｼﾉｳ。

>>483
て言うか何いってんのかサッパリわかんない。
誰か翻訳して下さい。翻訳する価値があったらでいいけど。

>>485
しぬな
公開フォルダを2つ登録したら認識したような。
同じフォルダでも可。

>>483
まず、寝ろ。
そしてすっきりしてから、自分のレスを見直せ。

>>485
俺も出てる。共有フォルダを増やしたり削ったりすると、共有フォルダ内のファイル数や容量が
正確に表示されたり0に表示されたりする症状。なんだろうね。
でも検索画面のUPフォルダ内表示でみるとキチンとファイルは認識されてるみたいだから、
ｼﾇ程のバグじゃない。ｲｷﾚ。

>>485
GUI周りは、優先度最低なのであえて書かなかったけど、
完全キャッシュが突然見えなくなったり、自動ダウンロードの所に
ﾀﾞｳｿしてない物が出たり、怪しい症状はいくつかでてる。

>>486
おそらく、自動ＤＬを一つ上流のノードに依頼する形にしたら、という話だと思われ。
つまり、自動ＤＬ用の検索語orハッシュを上流のノードに教えておいて、
そのファイルが通過したら教えてくださいと、頼んでおくと。

…これ、ホントに検索負荷減るの？
あと匿名性に穴がありそうな。

>>490
そうなんです。
>完全キャッシュが突然見えなくなったり
このために、自動ﾀﾞｳｿで同じモノを何度も落としに行こうとするので、参ってます。

まあ、それは自分が被ればいいんですけど、還元できないのがなんかDOM厨みたいで
ﾁｮｯﾄ嫌です。

とりあえず、自分だけじゃないみたいなので、生きることにします。

報告を頂いた方どうもでした。

>>484 >>486 >> 488
スマソ、確かにソウだと思い寝てました。
>>491 つまりは、ソウです．．．
でも、コノ程度、47氏が考えてないワケないヨネ．．．
逝ってきます．．．

>>491
翻訳ありがとう
なんか一番数が多い接続スピード(例えば50)のすぐ上流ばっかりに検索トラフィックが
集中して、はるか上流は検索トラフィックユルユルとかおこりそうな気がするなあ。
>>493
変なカタカナづかいも勘弁して欲しいのでもうちょっと寝てください。

お年寄りかな？

キャッシュについて

同じサイズ、同じハッシュであってもファイル名が違うと違うファイルとして扱っているようです。
この為、全く同一のファイルであるにもかかわらず2つのキャッシュが私のキャッシュファイルが
キャッシュフォルダに出来ていることを確認しました。

ちなみに矢不億で確認しました。

なんか再現できたので報告します。

>>485の症状（公開フォルダ＆キャッシュが認識されない）は、
検索画面で、「リフレッシュ」を押すと現れました。


他の環境の方ではいかがですか？

47氏さんの方では、なんともないのでしょうか？

>>457
ウザイ、重いって発言しても原因作ってる人=近隣の人ではないのだから
ただの愚痴になると思います。
ケンカしたりして雰囲気悪くなると切って繋ぎなおす人が多いでしょうから
回線が安定しなくて結局不利益をこうむりそうです。
安定して使うためにはいい人といいカンジでお付き合いさせていただくという
方向になると思うのですがいかがでしょうか？
マッタリ度全開で落とす環境に少しでも近づけたらいいなぁ…。

あ、それからここでやると迷惑かもしれませんので
くだ質スレの方に移動しますね〜

>>496
確かにファイル名が違うともう1つキャッシュが作られますね。
同じファイルをリネームしてキャッシュ化してみても再現しました。
まあ大きな問題とは思いませんが。
面白いのは、長いファイル名だとキャッシュも長いファイル名になる
様です。これは気付いてませんでした。破損が酷くて消したいキャッシュ
を捜す時の目安の1つになりそうです。

>>497
昨日から言ってますが>>234>>275
47氏は>>194で一応問題あるのは認識してる模様。
だから俺はもう書かくなったんだけど

あげ

ひー、スンマソン。逝って来ます。

昨日今日と雑用が多くて作業が進行しとらんです。
つーか、職場でこれ作ってるのばれたし（ｗ

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

>>503
(・∀・)お疲れさまです。

>>503
>>47師　乙カレーです
ばれたの大丈夫ですか　心配だYO

>>47氏　お疲れ様です！
会社大丈夫でしたか？ﾏﾀｰﾘ待ちますYO

>>503
会社内にACCSの方のスパイが居なかった事を祈ります（ｗ

お疲れさまです〜>>47氏
実は社内に他のβテスターが居たりして。。（w
ただ社会通念上は就業時間内にこれは･･･、私生活に悪影響が出ない範囲で十分っす。。。
待っている人は全員ﾏﾀｰﾘですから。
公式ページにお金になるバナーでもあれば、ｸﾘｸﾘしますよ〜。。ってこの位しか出来なくて
すまんす。。

くだ質スレにて反対多数で否決されました。
ほんとお騒がせしました&駄文にレスくれた人どうも〜。

>>509
いつからくだ質スレは衆議院になったんだ（ｗ

なんでsage進行なわけ？

ファイル共有ソフトはユーザ増えないと使い物にならないじゃねーの？

ＭＸも厨房多いけど
その分ユーザー多いでしょ？
使いやすさとユーザーの多さは比例するんじゃねえの？



SAGE進行のいみがわからねえよ

何でキレてるわけ？

じゃぁ使わなきゃいいじゃん

>>511
まだβ版のソフトなんだから、あたりまえ。
氏ね

>511
β開発中で　みんな真剣に議論して開発してるから
まだ闇雲に議論する人増やせないの　スムーズにやりたいから

つまり　おまえみたいなヤシを増やさないためだYO　判りやすいだろ

＞つーか、職場でこれ作ってるのばれたし（ｗ
ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!!!

>>511よ、そんなことより、
http://tmp.2ch.net/test/read.cgi/download/1021680717/221
の異名性ってなんですか。

まんこなめたいんだけどなめていい？

>511
後、皆変なものばかり共有してるし、初心者や変な奴が出てきて問題起こされても困るし、
色んな意味で今βの時にあんまり有名になりすぎて摘発されたらやばいんだよ。

正式版になれば、もう誰に求められなくなるからいいんだけど。。

>>516
47氏の匿名性が…あぁ…。

>>518
　　　　　　　　　　　　ヘ-+------+--+-----+ヽ＿
　　　　　　　　　　／:::|:::::::|:::::::::::::/::::::/::::::::::::::/:::::::/`＼＿
　　　　　　 ／￣＼::::::|:::::/:::......-―――--..........__/:::::::::::::::＼
　　　┌ー￣::::::::::::ヽ::|:::..-^￣　　　　　　　　　　　 ^ ヽ、:::::::::＼
　　　ヽ::::::::::::::::::::::::::::／　　　　　　　　　　　　　　　　　　＼::::::::ヽ
　　　 ヽ:::::::::::::::::::::::/　　　　　　　　　　　　　::::　　　　　　　＼:::::ヽ
　　　　ヽ::::::::::::::::::/　　　　　　　　　　　　　 ::::::::　　　　　　　 ＼::::|_
　　　　　）:::::::::::::::|　　　　　　　　　　　　　 ::::*:::::　　　　　　　　ヽ:|::::ヽ
　　　　 /::::::::::::::::|　　　　　　　　　　　　　　::;;;;:　　　　　　　　　　l::::::::ヽ
　　　　/::::::::::::::::::|　　　　　　　　　　　　　ﾉ::ii:ヽ::　 　　　　　　　　l::::::::::|
　　　　|::::::::::::::::::::|　　　　　　　　　　　　/::::;ﾘ:::l::::　　　　　　　　　|::::::::::::|
　　　　|:::::::::::::::::::::l　　　　　　　　　　　...l::::;ﾘ:::/::　　　　　　　　　/:::::::::::::|
　　　　.|::::::::::::::::::::::l　　　　　　　　　　. /:ア／:::　　　　　　　　／:::::::::::::::i
　　　　l:::::::::::::::::::::::::l　　　　　　　　　 ./::`^:::::　　　　　　　　／:::::::::::::::::/
　　　　ヽ::::::::::::::::::::::::l　　　　　　　　 /::::::::::　　　　　　　　／:::::::::::::::::::/
　　　　　/:::::::::::::::::::::::l　　　　　　　 /:::::::::::::　　　　　　／::::::::::::::::::::::/
　　　　　/::::::::::::::::::::::::i　_＿-ー--=;;;::::::::::::::　　....::::／:::::::::::::::::::::::／
　　　　./:::::::::::::::::::::::::::i":::::::::::::::　　ヾ─ 、／"ヽ:／::::::::::::::::::::::::::::l
　　　　　ヽ::::::::::::::::::::::丶::::::::::　　　/　　　il　　　.ヽ:::::::::::::::::::::::::::/
　　　　　　 ＼::::::::::::::::::::ヽ:::::::　　/　　　　l !　　　　ヽ:::::::::::::::::::/
　　　　　　　　　ii::::::::::::::::::` -::-/　　　　 / .i　　　　　ヽ::::::::／
　　　　　　　　　　-----￣丶/　　　　　lヽ　　　　　　　ヽ/
　　　　　　　　　　　　　　　　/　　　　　 l　^ヽ..　　　　　　ヽ
　　　　　　　　　　　　　　　 /　　　　　　ｌ　　　ヽ　　　　　　.ヽ
　　　　　　　　　　　　　　　l　　　　　　 .ｌ　　　　ヽ　　　　　　/
　　　　　　　　　　　　　　 丶　　　　　　ｌ　　　　 ヽ　　　　　 .l
　　　　　　　　　　　　　　　ヽ　　　　　 l　　　　　l　　　　　／
　　　　　　　　　　　　　　　　ヽ＿＿_../　　　　　 .ヽ---／

>>511
安定してくりゃあ
広めればいいじゃん
今もユーザ少ないからダメだな

そのうち、な

他のスレあげてこよ。

あまりにやばくなったりしたら、
BM98みたいに
開発終了→誰かが引き継ぐ→さらに発展→(ﾟДﾟ)ｳﾏｰ
って道のりを歩めばいいかも。。。

本当にどうしようもなくなたら winnyのソースを winnyで共有してほしい(w
その日がこないことを願ってはいますが(w

>>517
匿名性の漢語的表現





だったらｳﾚｼｲﾅ

>>525
>匿名性の漢語的表現
マジですか。>>511さん漏れが無知でした。

>だったらｳﾚｼｲﾅ
ハッタリかよヽ(`Д´)ﾉ ｳﾜｧｧｧﾝ!
雑談ｽﾏｿ。

>>508
>公式ページにお金になるバナーでもあれば、ｸﾘｸﾘしますよ〜。。

それいいですねー。自分もｸﾘｸﾘｸﾘｸﾘしますよー。
駄レスすまそ。

ｷﾀｰｰｰｰ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

>>528教えれ
何がだ？

くだ質は次スレに移行しました。

『MXの次』別館 くだ質、雑談、愚痴スレッドその3
http://tmp.2ch.net/test/read.cgi/download/1022942882/

>>529
あたーらしーいあーさがｷﾀｰｰｰｰ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
きぼーのあーさーが
よろこーびにむねをひーらき
あおぞーらあーおーげー

Win2kなんだけど、動きがトロくなったんで
デフラグやってみたら、キャッシュを置いてある
ディスクがえらい事になっとりましたわ。

Ver.14.4の頃から『Winny.EXEのエラー』っていうのが発生するのですが、どうし
てでしょうか？

>>533

どうしてだろうね？

待避中を共有してるバカがいるぞ！！！！
WinnyとMXの共有フォルダは変えろ！！！！
てかwinnyするならMXやめた方がいいぞ！！！！！

荒れ予防マジレス

>>533
もし98系使ってるなら、メモリ管理ソフト使って見なさいな。
あと、常駐してる他のプログラムやサービスを極力少なくしてみるとかね。
WINNY寄りのハードにしちまえ。

親切な536の言葉も厨房度120%の533には呪文のように聞こえて
まったく意味不明となってしまう罠。

なあ533よ、少なくともTipsページぐらい読んで質問の仕方ぐらい
学んでこいよ。
ttp://members.tripod.co.jp/winny4646/

もしかしたら　本スレ　偉そうとか思う人いるかもしれんが
ちょっと敷居高めでいきましょう　これから新規の人も増えるだろうし

くだ質もしっかりした運用面の検証という役割を果たすようになってる
内容によっては本スレ負けてるかも？
聞き方　答え方についても最近とても良くなってるし　もはや”くだ質”は名だけですね

Winnyスレ郡　”時には厳しく、時にはマターリ”　今後ともよろしく　<<ALL　

>>538
こーゆーやつ、ｷﾓｲんだけど

もうみんな飽きちゃったんだろ、寝ようぜ

>>538

>くだ質もしっかりした運用面の検証という役割を果たすようになってる
>内容によっては本スレ負けてるかも？
>聞き方　答え方についても最近とても良くなってるし　もはや”くだ質”は名だけですね

ここだけﾁｮﾄ同意

>>539->>541
同意

たまに自動ダウンのところに自分が今UPしてるものが表示されることあるんだけど
これは既出かな？

IPの暗号化だけど、今は自分で入力して暗号化して、それを晒すよね。
これ、問題ないかな。
今はユーザー数もほどほどだからいいとして、今後ユーザー数が爆発的に増えたときに、関係ない他人の IP:8080を暗号化して晒すやつがいたらマズいことになり
ません？　前のポートスキャン状態になるバグは修正されてるとはいえ、大勢の人の Winny,がアクセスかけたら擬似的なDoSアタックにはなりはしないかな…と。
自分で入力して変換しないとない手間を省くというより、他人の IPを晒させない意味で、自分で入力して暗号化するんじゃなく、ボタンを押すと Winny,が勝手に
自己の IPを取得して変換、暗号を表示するようにした方が良いんじゃないかと。
まぁあくまで正式版を出す前には、という優先度だけど。ふと思ったので提案だけしとく。既出っぽい気もするけど。

なにか数時間前に削除した自動ダウンロードが始まっている・・・
しかも、「自動ダウンロード」画面で見ると、全然関係ないリストの
ところにタスクが並んでいる。

Ｗｉｎｄｏｗｓ２０００SP2
Winnyβ14.6

Athlon(TB core)700Mhz / Memory 512M

ADSL 1.5M / 申告速度 50

ルータ使用、７７４３ポート解放済み、「外部からの接続」チェック無し
これまでの動作は特に異常なし、起動後20時間、不正終了も無し。

>>554
漏れは警視庁のＷｅｂサーバーのＩＰを登録してたりするよ
何も言わずにみんなアタックしてくれるしね、便利だわ

>>546
また神が…

とりあえず554に期待ｗ。

寝たいけど、554を早く読みたいよー。うぅ・・・

>>548-549
悪いね545の間違いだった
でも反モラリストのテスターも大事だと思うのよ。
正式バージョンが出た後に固定ＩＰの奴がアタック受けるのは分かってるから
こうして実際に登録してみた。
測度詐称も同じ事だよ。キャッシュを貯めたい奴は多めに申告するとかさ
βのうちにこういうのを潰していかないとリリースされたときに困る。

私は神を間違いなく見たんだ。

漏れじゃないのか(´Д｀;
…まぁ、とりあえず要修正、といふことで。

周りのみんなで修正してくれると有り難い
書き込む度に数字を間違えるからもう書いてらんない

554は漏れが取っておく

>546
難しい問題だな。。。
解決法として漏れが思いつくのは

初期ノードをコピペしたやつが winny起動
↓
自分が持っている初期ノードにまずつながる
(プロトコルが正しいかどうか)を調べる(pingみたいな感じ)
↓
正しいノードがわかる
↓
正しいノード同士でノードの交換を開始する

起動時のみ自分のリストを総なめして
正しいリストを調べて、正しいリスト同士を交換しあうしかないかな。
これだったら、自分の接続先のノードに間違ったノードを渡すことはない。

これだと、最悪でもアクセスしてしまうのは初期ノードをコピペしたやつ等だし
活発になって初期ノードcgiの登録が加速すればDoSになる確立はさらに減る。

ただ、初期ノードを使った悪戯が増えるようだったら、
アクセス禁止 ipリストを作ってフィルタリングするしかないか。
.go.jp とか accs とかを(w

とりあえずの実装して、
プロトコルが正しいかどうかしらべる ping コマンドのようなやつと、
正しいノードがわかるまでノードを交換し合わないというルーチンかな。。。

×とりあえずの実装して、
○とりあえずの実装として、

間違った。。。鬱だ。。。もう寝よう。

長時間起動したままだとノード情報画面が切断されたノード(9割がport0)で
埋まります。自動検索切断はOFF。重要度低ですが一応書いときます。

>>555
俺はノードリストはNoderefTemp.txtに追加する様にしてる。
Winnyの存在しないノードは勝手に消してくれるみたいだし。
でも、これでも接続してきた相手にノードリストを渡してるんだろうか？

速度詐称の対策も考えてみた。

速度詐称している房の特徴は回線速度が大きめのはずだけど
時間に対しての総アップロード量(Port0の場合はDownload量)が
申告した回線速度より著しくすくないやつ等なわけだから、

上位にいつづけられる条件として、
回線速度 と 時間に対する総アップロード数を見ればいいのでは?
そうすれば、こうすれば、物理的に回線を持っていない房を
上位から追い出すことができると思う。

一応、穴としては、
自分のLAN内に winny を立ててジサクジエーンすれば
時間に対する転送量はガシガシ増えるけど、
回線詐称をする房の家にそんなに PC があるとは思えないので(w

>>557
同じのを最近読んだような・・・。
なんかport0は時間が経っても消えずに残るらしい。

>>557
パケットを追いかけたわけではないので、そこまではわからないけど、
ノード情報に切断というマークがでまくるということは、
存在しないノードを相手からもらっているのではないだろうか。

ただ、
その切断と表示されたノードは最初にそのノードをチェックしたやつ等に
とっては正しいノードだったのかもしれない、という可能性もあるけど。

>>555
プロトコルバージョンチェックは当然やってるっしょ。

>>557
渡す必要ないし、渡してないと思う。
キー情報に接続成功したノードが渡ってるだけだと思う。

>>557
ごめん、よく読んでなくレスつけてしまった。
560 は脳内あぼーんしてください。

もう、マジで寝ます。。
ごみを流してごめんなさい。

ダミーマシン立ててキャッシュ満載でWinnyを動かし、
アドレス変換が自由にできるルータ(UNIXなど)で
自分から攻撃対象マシンのIPへの通信はダミーマシンにつながるようにしておく。

この状態でWinny起動すればダミーマシンのキャッシュ目当てに
外部から大量の接続が攻撃対象IPに…

とか考えてしまった。

他のノードに渡すノード情報はネゴに成功したものだけなので、
変なアドレス書いてあっても攻撃するのはその登録した人だけでDoSアタックにはなりません。

>>546
なんで、accsjp.or.jp:23 に接続しにいく
のかと思ったらこういうヴァカがいたのか。

なんとかしないとまた騒ぎになるぞ。

>>564
お疲れさまです。

>>563の方法は、自分からは攻撃対象IPでダミーマシンにつながるため
ノード情報として攻撃対象IPを転送しつづけ、
しかし他者は同じ細工ルータを通らないのでダミーマシンに到達できず、
攻撃対象マシンにむかってしまう、というシナリオです(笑)

>>563
それBadport0と認識されるんでは。

>>564
乙です。でも今のノードを晒す人(固定、DDNSばかりじゃないでしょ）、
晒し方の事を考えるとtempの方に追加する形の方がいいと思います

それと、検索リンクの上下決定の遊びを50％→100％にしてもらえませんか？
少しは詐称対策になると思います。自動DLの仕様自体を変えるつもり
でしたらそれでいいですけど。

>>567
うん。一度繋ぎに行った(攻撃完了)ノードからみるとBadPort0になるよね。
しかし後から後から違うノードから繋ぎに行くことで攻撃になるかと。

まあ大したトラフィックにはならないか。

>>569
うーん。ポート確認してないノードは他に教えないなら、
初期ノードリストに書くのと全く一緒のような。
DOS攻撃になりやすいのはプロコトルの変るバージョンアップ時ぐらいでしょうね。
普段は同時に再起動しているのは何%ぐらいなんだろ。
えーと、平均起動時間を正規分布とみなして…ややこしいなあ。

ってかport0はモデム接続より下流なのねw

ノードリストの剣
tempで接続できれば、constのリストは使わないとかはどうでしょう？
いまは、const優先なのかな？
けど、ネットワークの分断（小島化）の可能性が出てくるのだが

>571
ん？
>572
既に現状でいくつものWinnyネットワークが存在しているように思えてならない。

さっき、約600MBの動画を約200KB/sで落とし終わったところだが、
どうも、MXの時のクセでお礼がしたくなってしまった。

>574
何も言わなくてもその気持ちが大事なのだ。

そういや俺が書いた記事が出回り始めたが、URLや情報の拾いかたをまったく書かなかったせいもあってか
開発を混乱させるだけの極端な電波厨房大増殖だけはぎりぎり防げたようだ。。。。

マジで無駄かもしれないが、今後のWinny開発中の雑誌掲載の指標になればとは思う。

・開発中のURLは直リン絶対禁止
・このスレのタイトルも伏せてもらう。
・建設的でない質問厨、議論厨などの電波厨房増殖が開発に悪影響を与えるという旨だけは記事内に明記する。

47氏を筆頭にこのスレの住人の皆様方には、本当に期待しとります。
がんがってくださいまし。

>>575
(　ﾟдﾟ)ﾎﾟｶｰﾝ

>>575
>・建設的でない質問厨、議論厨などの電波厨房増殖が開発に悪影響を与えるという旨だけは記事内に明記する。

厨はそういうことに配慮するほどの頭を持っていないと思いますが？

こちらのスレッドの趣旨はバグフィックスをメインだったと思ったので、>>575については
http://tmp.2ch.net/test/read.cgi/download/1022942882/l50
『MXの次』別館 くだ質、雑談、愚痴スレッドその3
にてお願いできないかな？

と仕切り房をやってみるテスト。

>>578
禿同。

>>575

>そういや俺が書いた記事が出回り始めたが、URLや情報の拾いかたをまったく書かなかったせいもあってか
>開発を混乱させるだけの極端な電波厨房大増殖だけはぎりぎり防げたようだ。。。。

てゆかそんなやつらをβ版の時点で少しでも流入させてどうする気よ？
完成して欲しい気持ちがあるのか？

>47氏を筆頭にこのスレの住人の皆様方には、本当に期待しとります。
>がんがってくださいまし。

575にどんな考えがあったって結局自分らのメシの種という罠。

まぁ厨を認識してる奴の取る行動とは思えんな。なんか鬱になるのは俺だけだろうか？

>>580
気持ちは分かる。
ってか記事が出回った云々を今ここに書く必要があるのか・・・と思う。
が、しかしとりあえず続きは向こうでやろう。

>>577
そこを優しく噛み砕いてお子様に諭してやるのが物書きという職業だと思う。
それが出来ないようでは物書き失格。
厨がいたらどの雑誌を読んでここに来たのか尋ねて書かせるといいよ。
出版社に対する牽制になる。無論評価に値する記事は評価してさ。

>>578
と仕切り房をやってみるテスト。
と仕切り房をやってみるテスト。
と仕切り房をやってみるテスト。
と仕切り房をやってみるテスト。
と仕切り房をやってみるテスト。
と仕切り房をやってみるテスト。
と仕切り房をやってみるテスト。
と仕切り房をやってみるテスト。
と仕切り房をやってみるテスト。
と仕切り房をやってみるテスト。
と仕切り房をやってみるテスト。

コレ、絶対MXのが使えると思うんだけど･････
不安定すぎて

>>584
まだβ。氏ね。

>>584
開発中のβ版につき、不安定なのはお約束。
比較・評価するところが間違っているよ。

>>586
繋がり具合が不安定なんですが・・・・・・
みなさんはすぐ繋がってますか？

>>587
すぐ繋がります。
時々、挙動不審な点もありますが、
実用できるレベルにまでは到達してると思われます。

ついでに…sageてね。

>>587
環境が分からぬが……。
ISDNの漏れは、仮想ファイルキーの個数がゼロ収束する事と、
コネクション接続エラー>>>時間切れ>>ダウン中継エラー>DL開始出来た>>>>>>1回でDL出来た
という感じ。

>>587
まだβなんです。


★sage推奨★

>>588
というわけで、漏れにとっては、実用出来るレベルに到達、とは思えない。
参照数が二桁いっているものを選んでいるのだけどなあ。
検索結果で、1ハッシュ当たりの接続ノードを予備として2つ以上返すのはNGなのかなあ。運がよけりゃ同時DL（分割DL）になるし。

TBRファイルダウソつながったと思ったら同じところも何度もループでＤＬしてたんで切ってもうた・・・
なんじゃろこりゃ

ISDNなら帯域制限してるか？やってないとキャッシュがある程度以上行くと
吸い取られまくりだぞ

とりあえず、600MB超動画を3つｹﾞﾄ出来たので、実用的と
言ってみたのだが…
漏れの基準が低かったのか…ｽﾏｿ
逝ってきます。

>>593
してまふ。
が、それ（接続性）以上に、仮想ファイルキーのゼロ収束の為か、手元には補完できない部分キャッシュが一杯。（＝見つからない）

下流には驚くほどキーが流れていないことを実感。
低速の人も回線速度200とかにして試してみるとよくわかるよ。
もっともPCのスペックが極端に低い人にはお勧め出来ないけど。

注意：くれぐれも実験後は回線速度を元に戻してね、と。

今、11000程キーが来てるな。

47氏へ
検索画面で参照数順などにソート出来るようにしてホスィです。

>>597
出来るよ。

>>596
その分吸われるから結局DL効率はｲｸﾅｲけどね。
高速回線はsage偽証するとUPに帯域とられない。(・∀・)

>>598
スマソ、できますた。
重くて反応が鈍かっただけでした。
逝ってきます

>>596
実験済みっす。
ISDNの帯域ではキーの流通も帯域で頭打ちだと思うのだけど、それでも
Athlon1900+/512MB(DDR)で、CPU負荷率が30%を超えていてびっくり。
なので、ある程度の負荷対策（少なくとも「落ちる」の対策）が重要なのも理解してます。

「吸われている時」にDL困難なのは（諦めているので）別に構わなくて、
「吸われていない時」にDL出来ないのが悲しい。

自分のノードがプロキシのように使われたときのログは
残せませんか？すぐ消えてしまうようなので…
もし、ログが残れば、自分のキャッシュ内のファイルを変換して…

かなりどうでもいいかもしれない不具合ﾊｹｰﾝ。
自動ダウンロード画面で「転送レート」の幅を変えると、
タスク状況の「ファイル名」の幅が変わります。
逆も同じです。

>>602
匿名性(以下略)

>>604
ログといっても、キャッシュ内のファイルを実物に変換できる程度のもので
十分なのです。それでも、匿名性に関わるのでしょうか？

>>602
ﾀｲｰﾎされてください
以後くだ質で

『MXの次』別館 くだ質、雑談、愚痴スレッドその3
http://tmp.2ch.net/test/read.cgi/download/1022942882/

>>603
>>282

>>607
既出でしたか。見逃してた。ｽﾏｿ

>>555
　とりあえず、ダメドメインリスト作って、
　1.　初期ノード追加
　2.　初期ノードのＩＰアドレスをＤＮＳで逆引き検索
　3.　ダメドメインに属するアドレスなら除外
　4.　それ以外なら接続テスト→　マズー：除外　ウマー：追加
ぐらいはいれとかないとダメかもね。
あと、発信者のドメインが　go.jp co.jp あたりはwinny起動除外とかもありかな？
プロバイダのアドレスは最近たいがいne.jpだからそれでも問題ないと思うが。

>>609
わざわざ、go.jpドメインから来るﾔｼは少ないと思われ。
まぁ、念のためって事だろうけど…

>>609
つーか、「アドレス暗号化」手動でアドレスが入力できてしまうのが問題なのでは
手動入力なしに、晒すハッシュ値が取得できるようにすれば解決すると思うのだが

>>611
同意。

>>611
　たしかに、ほしい機能ではあるが、ＩＰ攻撃防止効果は少ないかと。

ダイナミックＤＮＳに嘘名入れて、ポート入れて暗号化ＩＰ取得すれば、結局同じだと思われ。
　それをも禁止するとＲＡＷ以外晒せないし。

　あ。現在の設定でＵＰになった実績が無いと暗号化ＩＰ取得できなければＯＫか。

>>613
最初の一人はどうするんでしょ

>>611
ノードのアドレスをWinny側で自動取得するって事だよね。

そうすると、プライベートアドレスでルータのポートフォワード使ってる人は、
プライベートアドレスしか取得できなくなっちゃう。
有効なアドレスを晒せる人の総数が減るという問題がある。

>> 614
　暗号化ＩＰ取得の券

RAW : 192.168.*.*とか、ローカルなＩＰとＮＧドメイン以外→すぐ作成可能
　DDNS : カレント設定でＵＰした経歴（再起動で消える）があれば作成可能
NAT : DDNSにグローバルＩＰ入れてDDNSと同じ処理
　PORT0: 作っても意味なし？

　とすれば最初の一人もＯＫかと。
　いかがざんしょ？

>>611
いわゆるブロードバンドルータとかでＮＡＴしてたら、
外の Winny(でなくてもいいけど)に頼らないと、
外から見たアドレスは取得出来ないと思う。

外部にCGI置いてそっから取得すれば？
駄目か･･････

>>618
ＣＧＩ運営者がタイーホの危機に…

ファイアウォールのドメイン拒否使えば済む話。

『MXの次』別館 くだ質、雑談、愚痴スレッドその3
http://tmp.2ch.net/test/read.cgi/download/1022942882/l50

漏れはDDNSの自動更新ソフトDICEってやつ使ってるんだが
こいつはルータの設定画面のＩＰを登録してやると
WAN側のグローバルを自動取得する。
だから不可能ではないと思うが、優先度は？だな。

分割DLが同じところをDLしてしまう

状況としては、3分割でDLしてたとして
それぞれのタスクが別々のブロックをDLしてるのだが
それぞれのブロックのDLがほぼ同時に完了したタイミングで発生する模様
どうやら、ブロックのDLが完了したときに次のブロックのDL箇所を決めるルーチンに不具合がありそう
分割DLそれぞれの速度がほぼ同じときに、この現象が頻発する
3つとも同じブロックをDLしてしまうことも多く
かなり効率が悪い状態になってます

>>622
ｶﾞｲｼｭﾂ。どっかで俺も報告したんだが流された（ｗ

>>623
そうですか、ｶﾞｲｼｭﾂでしたか
流されてしまったのなら、自分がもう一度詳しく状況を説明しておきます

言葉で説明するのが難しいのですが
あるファイルのブロックを
ABCDEF・・・・
だと仮定する

タスクDL1がAをDL
タスクDL2がBをDL
してたとする

DL1がAをDL完了、次はCをDLしようとしてまだDLが始まってないときに
DL2がBをDL完了する
そういう状況になるとDL1とDL2が共にCをDLしてしまう

というものです

>>624
でもDL1がCをDL開始すると
DL2はDをDLしようとしないかい？

>>625
いやどちらともCをDLしてしまう
DL3も同じ状況になると
3つともCをDLしてしまう
tashiroを使って計測したところ
総受信量はファイルサイズの２倍近くになってる
もちろん計測は「接続停止」を押して
検索リンクを切断してからDLのみを計測したから
ほぼ数値はあってると思います

-------------------------------------------------
OS/CPU/ﾒﾓﾘ：Windows XP／Duron 900M／384M
回線　　 　　　：DL1.5M/UL512Kbps
環境　　　　 　：NAT
待受ポート　 ：7743
DDNS入力　 ：なし
使用ｸﾗｲｱﾝﾄ ：Winny β14.6
速度申請　　 ：50
キャッシュ　　：1.9G/4.9G

症状　　　　　 ：自動ダウンロード中のファイルが、65,5360バイト（付近？）まで進んだ
ところで65,536バイトに戻され、以後永久にループする。特定のファイルでのみ起こる
が、ファイルの条件は不明。
-------------------------------------------------

>>627
うちでも同じことが起きてるよ。1.4MBくらいのファイルで・・・

外出かもしれないけど、ついにキャッシュが35GBを超えて、
ディスクフルくらったんだけど、その後もWinnyは動き続けて、
byteのキャッシュと、Downファイルが大量にできてました。

14.7

って、事は47氏が・・・

47氏が来る……

47氏お疲れ様です。

>>632
ならsageて待て・・

ごめん……マジボケしてた。
回線切って首吊ってくる……

>>635
そんな責めるつもりはなかった。ｽﾏｿ

β14.7です。互換があります。

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

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

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

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

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

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

何をするかというと、その現在落としているキーが他ノードからも重複して落とせるのであれば、
自動的にダウンロードタスクを発行します。キャッシュの検索で黄色くなったら自動的に
ダブルクリックすると思ってください。ＭＸで言えば、自動的に投網する機能に相当します。
ちゃんとチェック入れて同じノードに投げないようになってるんでそんなに迷惑でも
ないはずですが、一応何かUPしてないと使えないようになってます。

複数のノードでキーがヒットしないとだめなんで、キャッシュが何処にでも転がっているような
メジャーで大きなファイルにのみ有効な機能です。

Winnyのメカニズム把握して無いとうまく使うのが難しいと思いますが、
仕掛けてから一度その目的のファイルにヒットしそうな検索を
たまに手動で書けるといいんではないかと。
この辺りは自動ダウンと同じですね。

ｷﾀ━━━（ﾟ∀ﾟ ≡（ﾟ∀ﾟ ≡ ﾟ∀ﾟ）≡ ﾟ∀ﾟ）━━━━!!

>>637
47氏、お疲れ様です｡

KDX

47師、乙です。
出先なんで帰ったら早速入れます。

47氏久々のVerUP、乙彼〜
しかし、47氏のコメントが出る前に>>630のように速く見つける人が必ず居るね。

>>639
お疲れ様〜！
破損について色々と対策されたようで・・・。
より一層便利かつ効率化してきましたね。
「自動分割ダウン機能」今から試してみますわ。

（´-`）.｡oO（ここの所ﾏｲﾅでしかVerUPされてないのは完成してきた証かぁ）

>>642
監視ツール使って、次に来そうなﾊﾞｰｼﾞｮﾝを監視させてるんだろ。

タスクがどんどん消えていくのはオレだけ？

>645
確かに　転送確立しにくいような挙動です
上流なので　常に10-15UPしてますけど　
今のtころ　2UPです　それもデータは流れてないみたい
β14.7　もう少し様子見ですかね　全体移行しないといけないのかな

自動再思試行の挙動がおかしくて，タスクが消えてるような気がするなぁ

>>646
俺もそんな感じしなくもない。
いつもだったらキー情報の転送だけでも
UP50 DOWN50　は出てるのにβ14.7にした途端、
UP0.5 DOWN0.8とかになった・・・。気のせいかもしれないけどな。

それと
http://isweb40.infoseek.co.jp/play/maxmam/cgi-bin/img-box/img20020602214211.jpg
この問題はやっぱり対処難しいのか・・・。まぁﾏﾀｰﾘ待とう。

>648
>>>上流なので　常に10-15UPしてますけど
　　　　　　　　　　　　　　↑コネクション数です　マターリ確認続行します　

>648
それの完全版は717,167,384ﾊﾞｲﾄの物と覚えておけば…

>>645 >>646
みんな新バージョン出たので再起動中だと思うが。

>・ キャッシュ送信時にもキャッシュ整合性チェックを行うようにした
（´-｀）.。oO(ここで遅延でも発生してるのかな…時間切れが多い…)

>>651
あ、確かに。もうちょっと待ってからだな。

ちょっと転送安定してきたかも

まだ自分のUPしてるものが自動ダウンのところで見れるね。

んー、転送切れるということなんで変更点見直してみましたけど、
ひょっとして小さなファイルだと切れるかという変更点見つけたので
戻してみました。基本的に大きなファイルばかり試してたし。

すいませんが、β14.7読み直しといてください。

ジオが開かない( ´Д⊂ヽ

>>656
乙です

あと、昔からβ参加されている方ですと逝かれキャッシュを持っている可能性
高いですが、今回のバージョンではその逝かれキャッシュをUPに行った
時点で破損が見つかって完全キャッシュから破損キャッシュになります。
これにより各所でＵＰが止まるという現象がでるんじゃないかと思います。

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

時代を創ってるなぁ。お疲れです。

>>657
me, too.

逝かれキャッシュ・・・たくさんある・・・

>>659
47師へ｡
厨な質問で申し訳ないのですが低速回線とキャッシュの量の関係はどうなっているのでしょうか？
ネットワークで高速回線の間に低速回線が来ることもあるとは思いますが
正直ISDNにファイル転送量(Max値は3) DL1 UP3(中・高速回線) はきついと思うのですが...

回線詐称していなければ高速回線の間に低速がくることはないはずですが、
まだ基本的な部分を上げている段階なので各調節は後回しになっています。
特に低速側は最後になるでしょう。中速→高速→低速の順で出来上がっていくと
思います。今はそろそろ高速側で使う機能（今回の分割ＤＬや自動ダウンなど）
が出来上がりつつあるところではないかと。

>>663
おそレス申し訳ありません＆回答ありがとうございます｡
しかし低速回線のことまで考えていただいて本当にうれしいです｡
これからもPC落ちても何度でもβテストします｡

>659
なるほど　放置期間が必要という事ですな　了解！

自動ダウンonだと、高確率で落ちる気がする。。。

一応報告。
β14.7の自動分割ﾀﾞｳｿで
16分割させてDLしてみますた。
どんどん破損ブロックが出てきたので、やっぱ厳しいのかと思いきや
100%になった途端16個のタスクが今までの破損ブロックの修復に
一斉に取り掛かりだしまして、あっというまに出来上がり。
完全キャッシュです。ファイル変換も正常終了でした。
ﾏﾝｾｰ

UIの面でファイルにCRC32を使いませんか？
ファイル検索のハッシュをファイルのCRCにすれば頭だけ正常、後ろ捏造ファイルの
識別ができると思うのですが・・・。
それに自動ダウンロードの設定にファイル名+CRCでファイルをピンポイントに狙う
ことができるようになると思います。

以上、妄想。

>>668
CRCの意味わかってる？CRCだってハッシュ計算方法の一種だっつうの

>>669
文字通り妄想なんじゃない？

>47氏。

Winnyにノード除外IPを設定できるように要望したいのですがどうお考えですか？
FWにまかせるという手もありますが。

理由はくだ質スレ参照ということで。
http://tmp.2ch.net/test/read.cgi/download/1022942882/195-

帯域制限がもっと軽くて、きちんと機能するといいな
と思ってるのはあたいだけ？
UP速度遅くなりすぎて回線詐称してるとか思われたりとか
気になってもみたり。

いままでの分かりにくかったり、追いついてなかったりだったので、
前のまとめ氏のやつ元にして、１つのページにまとめてみました。
http://members.tripod.co.jp/winny4646/page/matome.htm
最近のはこれから追ってって追加します。

>673
Tip氏　乙カレーです

>>668
えーと通じてないので補足。

>あと別館見たらハッシュで盛り上がっているようですが、この辺は非常に
>面倒なことになってます。皆さんの予想通り、検索に使っているのは
>とりあえず高速に求める必要があって先頭ブロックだけから算出してますが、
>64Kブロックで全部ハッシュ持ってますし、キャッシュ先頭のブロック
>（いろんな管理情報が入っていてここには他のハッシュ情報も入ってる）
>これ自身のハッシュもあります。そうでないと管理部分の破損が検出できませんし。

64Kブロックごとに持っているハッシュの技法にどれを使っているかはよく判らないので省略。
現状だと先頭ブロックのハッシュを検索に使っているため、ファイル検索で同じ
ハッシュ(に見える)の違うファイルが出てきてます。
これを確実に別けるのとユーザーの使い勝手(DL後の正常性チェック等)を考えて
そのファイル全体のCRCをとって検索に使ってはどうかという話。
CRCでといっているのはTBTBなど算出するツールが多いからで、今採用している
ハッシュでできるならそれでも問題ないかと。

>>675
引用した内容をよく読むことをおすすめする。

>>675
>そのファイル全体のCRCをとって検索に使ってはどうかという話。
それができたら、先頭ブロックだけから算出なんてしないだろ
それとも言いたい事は違うのかな？

>>676
馬鹿のくせに脊髄反射をするのはやめてくれ、頼むから

4Gファイルなんぞあったら全部にアクセスするだけで何十分もかかるわな
送った後になら全体ハッシュ分かるけど検索用途には間に合わない罠。

>>678
(　゜д゜)ﾎﾟｶｰﾝ

公開フォルダで指定をしたフォルダを公開するのではなくて、
かならずキャッシュの形で公開するということにすればいいんじゃないか。

公開フォルダを指定
↓
その中に入っているやつをすべてスキャン、キャッシュに変換、このとき
CRCを求める。

これだったら、ファイル全体から CRC を求めても速度の低下に
ならないはず。

>>681
そうなったら俺はキャッシュにするのが時間かかりまくりだろうからUPフォルダは空にするな

>>681
昔の設計はそんなんだったような・・・

ところで、ファイル全体から求めたCRCのデータってのは32bitで足りるの？
それ以上多くなったら検索リンクが大変なことになると思うけど。

当然、それくらいわかって言ってるんだよな？

β14.7
キャッシュファイルがファイル数１０００突破。
なにごとも無いかのようにキャッシュファイル数は増量中。

ファイル数関係の制限は未実装？
とりあえず、キャッシュ内のファイルのキー一覧の格納領域が動的確保されて動く
実装になっている事を祈るよ。

なんでそういう偉そうな言い方しか出来ないのかなぁ...

>>684
おまえも良くわかってない

>>684
ﾈﾀですよね？

>>687-688
ﾑｷ━━━━━(ﾟДﾟ)━━━━━!!!!

このスレは馬鹿で溢れてるな

ﾊﾊﾊ

MD5は128bitだｳﾞｫｹが

煩悩の数は128bitでもオーバフローするな？
哲学的だな(藁

47氏が見たら泣くよ。

>694
ほんとだね　夜中に成ると言葉使いを知らないヤシが．．．
くだ質の方がよっぽどまともだね　住人変わったか？

>695
変わってはいないと思うが、割合が・・・。

住人がくだ質に誘導してる間にそのまま厨の居ない向こうに居着いたとか（ｗ


……いや、47師の事を考えると藁えんのだが。

謙遜できる奴でないとくだ質に行かないので。
また対応する側も場違いな発言にすぐキレ易い。

ノードがプチプチ切れるんだけど
原因はなんですか？

>>699
たぶんビタミンＣが足りない

>>699
不具合状況を報告する時に
最低限、判断材料となる環境くらい書けよ

>>701
書いたって答えられないくせにw

>702
答える答え無いの問題か？

>698
禿同　　>699　は検索リンク組替えの事言ってるのだろうか？
新規者→Winnyのスレだ！→的外れな質問→ゴラァ＝荒れる
優良住人は大きな問題もないので師のVerUPを静かに検証＝書き込み少なめ

さてどうしたものか　47師をお迎えできる雰囲気ではないような

>>702　ここはβ開発スレだから　基本的には誰も答えない　答えるのは47師だけ
他の人が答えられるカキコは過去ログで検討済みなのを読んで無いって事です
このスレは過去ログが非常に重要です　熟読して参加をお願いします

>>701の言い方も如何なものかと思うが　

>>699
つなぎの小麦粉が足りないと思う、十分粘りが出るまで良くねりねり。

>>702
おうよ
書いたって教えるわけないじゃん

>>704
確かに少しきつい書き方かもしれない
ただ、状況を説明できずに>>699のような書き込みをした場合
単なる愚痴にしか捕らえられない
ひょっとしたら重要な不具合であるかもしれないのに

俺は今までいくつかの不具合を報告してきて
的確に不具合を伝えるのが、いかに重要か
というのを実感してるし、くだらない質問に重要な報告が埋もれてしまってるのを
多々見てしまってるからね・・・

>>701のような少しきつい言い方になってしまったけど
厨を排除しようという気持ちは持っていないので、誤解のないように

１：＊５０をとった人が、別館への誘導をする。
２：９５０をとった人が次スレを立てる。
３：４７は、欠番。

ここは、提案や明らかなバグ報告スレってことで。

如何でしょう。昔からβテスターが誘導すれば、このスレも
もうちょっと有意義なものになると思うのだが。

>>702
おまえはｱﾌｫか?
少なくとも不具合報告する時に動作環境書くのは「　あ　た　り　ま　え　」だ

それができない奴ぁ固まるとかバグったなんて愚痴をたたくなよ。
判断材料なしにバグ取りなんてアフォらしくてできるかよ。

開発をすべてやってるのは47氏であり俺らはβテストして問題点を
洗い出すのはテスターとして当たり前の行為だ。



それともお前は47氏の開発の邪魔でもしたいのか？
あまりにもヴァカな発言は慎め！

>707
了解！　よくわかります　ちゃんと報告するのは難しいですよね
>708氏も提案してくれてるし　ちょっと流れを見ます
私も　いちβテスターですので　マターリ逝きますか

>>707
考えなしにアフォな発言をする奴は叩いたほうがいい

なんでも教えてクレクレの連中は甘やかしすぎるとろくな事が無い。
俺的にはDOM予備軍だと思ってるし、自己中な考えだから
そういう書き込み（方）をすると思ってる。

これはここのスレだけでなく、どのスレにも言えること。


あと、スレ立てた人はバグ報告についてのテンプレを入れ忘れてないか？
「ヴァカ厨」排除として、注意事項としてはっきり書いておけよ！

>>711
随分偉そうな物言いをする人でつね
是非次スレはアナタが立ててくださいませ

今書店に並んでる「日経ネットナビ」と「ヤフーインターネットガイド」に
Winnyのことが小さく掲載されてるんだけど既出かな？

まずはスレタイトルを変えるべきだと思います。

>>713
うん

>714
そうですね　MXは必要以上に新規者を呼んじゃいますかね
”次世代freenat　開発室　難しいぞ！”
”Winny初心者はこちら”　みたいな　
夜になってみんなの意見聞いてみないとイカンですな

>>712
漏れの発言が偉そうか？
47氏の立場を考えたら常識だと思うがな。
良く考えてみ？

あとな、次スレ立てろといわれても
仕事の合間にカキコしてるから950踏めるか分からんぞ。

次スレ立てる奴は広める事だけでなく、
WinNYの開発がスムーズに行くようにテンプレ作れ。





あとシージと作家落としてる奴ら、申請200で平均10Kは無いだろうが。
ホントにADSLか？

( ´_ゝ`)ﾌｰﾝ｡
どうでもいいよ

景気良くあがってますな。。
>>716
良いね。開発室・雑談・ふぁっきゅーの3分担で上手く逝きそうなんだけど。。。

>>719
俺もそんな気がする。

MXの名前がアレなら，いっそ次スレは
"次はなんだろう？ 19"
とかでいいんじゃないか．
タイトルに"次"が入ってれば検索できるし．
"次"関連ってことでくだ質も"『次』別館〜"でさ．

「次の開発に貢献するスレ」とか提案してみる

開発・雑談・質問の3本のスレがあって
3本のスレとも(特に開発用のスレは)タイトルが一目で
それ専用だと判るようにすればいいと思います。

わかったからスレタイの話とかは雑談でやってくれ
スレタイ決めるにしても夜になって人が増えてからな。

誘導は一回だけだ。この発言へのレスも向こうで頼む

http://tmp.2ch.net/test/read.cgi/download/1022942882/

「次世代P2P開発室」とか。

前スレから抜粋。
起動関連のバグ報告は
前バージョンからの入れ替えの場合
１．Winnyの再起動もできない
２．PCを再起動してもWinnyの起動ができない。
３．Winnyを再インストールしても起動できない。
ときのみってことで良いかな？

初めてWinnyを導入して起動できないって人は
MXの次別館 くだ質、雑談、愚痴スレッドへ。

それ以外のバグは
バグを確実に再現できる人のみ、その方法と一緒に報告可。
なんかアヤシイけど良くわからん、みんなはどう？
って書きこみは上のくだ質へ。

バグ報告用のテンプレがどっかにあった気がするが見つからなかった・・・

>>725
ＷＥＢページにテンプレあったと思ったが、消えていた。
前スレからコピー

-------------------------------------------------
OS/CPU/ﾒﾓﾘ：
回線　　 　　　：
環境　　　　 　：
待受ポート　 ：
DDNS入力　 ：
使用ｸﾗｲｱﾝﾄ ：
速度申請　　 ：
キャッシュ　　：
症状　　　　　 ：
-------------------------------------------------

確か、これに対して色々と議論があったように思う。
使用クライアントはβバージョンを書き込み、他は何だっけ？

TransferのMaxが3なのにupが数秒だけ4になることがあります。
「中継ノード」として転送を始めるのだがupがMaxに達しているため
転送を中断しているのでは。

ファイルをダウンロードしようとしてもすぐに自動再試行の10回分を
使い果たしてしまう原因がこのバグにあるように思われます。

無駄なトラフィックの原因にもなっているのでは？

681あたり見ていて確かに先にハッシュを計算しておいた方が
DLとか検索する側も結局楽になるんじゃないかと言ってみるテスト

P.S.
自動再試行を使い果たすまではいかなくても、なかなかダウンロードが
始まらない原因にはなっているのでは．．．．

>>726のをちと改造。

バグ報告用テンプレ v1.4? (ﾟдﾟ)
-------------------------------------------------
Winnyﾊﾞｰｼﾞｮﾝ：
OS/CPU/ﾒﾓﾘ：
使用回線：
DDNS名：
回線速度：
Acceptﾎﾟｰﾄ番号：
ﾙｰﾀ使用のため外部から接続が不可能(ON/OFF)：
保持ｷｬｯｼｭｻｲｽﾞ：
最大ｷｬｯｼｭｻｲｽﾞ：
備考：
バグ症状：
バグ発生方法：
-------------------------------------------------
※バグ発生方法は最低２度行い、確実に発生することを確認すること。

・例
-------------------------------------------------
Winnyﾊﾞｰｼﾞｮﾝ：β14.7
OS/CPU/ﾒﾓﾘ：W2k/P4-1G/512MB
使用回線：ADSL-UP512k/DL1.5M(ｸﾞﾛｰﾊﾞﾙIP)
DDNS名：DDNS使用
回線速度：100
Acceptﾎﾟｰﾄ番号：7743
ﾙｰﾀ使用のため外部から接続が不可能(ON/OFF)：OFF
保持ｷｬｯｼｭｻｲｽﾞ：15.0G
最大ｷｬｯｼｭｻｲｽﾞ：4.9G
備考：
バグ症状：リフレッシュボタンを押すと公開フォルダが認識されなくなる時がある。
バグ発生方法：公開フォルダにフォルダを追加している状態でリフレッシュボタンを押下。
-------------------------------------------------

バグ発生方法が判るまではくだ質で論議してからここにカキコの方が
良いんだろうけど無理でしょうな。

分割DLが完了した時に
それぞれのタスクが同時に完全キャッシュからの変換作業をしてしまう
という現象が出てます
5分割とかになっていると5個共が変換作業をする事もあります。
以前のバージョンから起きてる現象ですが
とりあえず、最も変換が進んでるタスクを「タスク取り消し」で順次停止するようにはしてますが
逆に最も進んでない方から停止をかけた場合ファイルが壊れてしまうのではないかな？
と思うのですがどうなんでしょうか？

winnyのファイルのどれかに　W32/Klez　ウイルスが入ってた。
みんな気をつけろ

ここ行ってみんな調べろ。

ttp://www.trendmicro.co.jp/hcall/index.asp

どれかってどれだよ

キャッシュのままでもヤバイの？

>>734
キャッシュファイルとか言うネタに47Winny

>>732
WInnyの配布されてるアーカイバって２ファイルしか入ってないよな。
もしやReadme.txtの方か？(w

なんつーアバウトさだ

バグじゃないと思うけど、検索や自動ダウソの設定まではうまくいくが、肝心のダウンロードが
全然始まらん。あとポート警告がやたらとでるのだが・・・。特におかしいことはないのかな？
-------------------------------------------------
Winnyﾊﾞｰｼﾞｮﾝ： 14.7
OS/CPU/ﾒﾓﾘ： ｗｉｎ２ｋ/ｱｽﾛﾝ1.1G/256
使用回線： adsl
DDNS名：未入力
回線速度： 50
Acceptﾎﾟｰﾄ番号： 6699
ﾙｰﾀ使用のため外部から接続が不可能(OFF)：
保持ｷｬｯｼｭｻｲｽﾞ： 124.5ＭＢ
最大ｷｬｯｼｭｻｲｽﾞ： 97.7GB

-------------------------------------------------

ノードが一気に増えると
応答なしになってしまう。

>>717
>あとシージと作家落としてる奴ら、申請200で平均10Kは無いだろうが。
>ホントにADSLか？
>>672

やっぱりバグレポート専用のスレを作ったほうがいいじゃないかな？
なんだかんだ言っても、このスレの8割は雑談と無駄な議論になっている気がする。
議論は、くだ質スレっていいながらもそれに従っている奴はほとんどいないようだし。

ADSL8Mでもリンク速度が上下640Kbpsとかしかいかない
糞なものもあったりするのだよ
申告速度を下げろと言われたらそれまでだが

↑常に平均10Kになるわけでもないが
たまになるのでねスレ汚しｽﾏｿ

>>743
bpsとB/sって単位違うっしょ？
全く意味取り違えてたらｽﾏﾝ。

だいぶ前にも書いたんだけど、Fixされないようなので再度
-------------------------------------------------
Winnyﾊﾞｰｼﾞｮﾝ：β14.7
OS/CPU/ﾒﾓﾘ：Win2k+sp2/Athron1.2G/512M
使用回線：ADSL8M
DDNS名：ddo.jp
回線速度：100
Acceptﾎﾟｰﾄ番号：7743
ﾙｰﾀ使用のため外部から接続が不可能(ON/OFF)：off
保持ｷｬｯｼｭｻｲｽﾞ：11G
最大ｷｬｯｼｭｻｲｽﾞ：5G
備考：
バグ症状：検索画面でリフレッシュをかけると完全キャッシュが表示されなくなる。
　　　　　リフレッシュを繰り返すと一部が表示されたりまた消えたりする。規則性不明。
　　　　　全て表示されない状態にするとUPが切れる為、表示が消えた完全キャッシュは
　　　　　Winny自体から認識されなくなっていると思われる。
-------------------------------------------------

>>745
単位というかADSL8Mであったとしても
ADSL1.5Mより速度がでないことがあるとか
そういうことを言いたかったと受け取っておくれ

※状況報告
-------------------------------------------------
Winnyﾊﾞｰｼﾞｮﾝ：β14.7
OS/CPU/ﾒﾓﾘ：W2K+SP2/Athlon 2100+/1024MB
使用回線：FTTH-UP45Mbps/DL65MbpsM(ｸﾞﾛｰﾊﾞﾙIP)
DDNS名：DDNS使用(DiCE)
回線速度：1000
Acceptﾎﾟｰﾄ番号：7743
ﾙｰﾀ使用のため外部から接続が不可能(ON/OFF)：OFF
保持ｷｬｯｼｭｻｲｽﾞ：52G(Winny認識　CASHフォルダ実合計　92G
最大ｷｬｯｼｭｻｲｽﾞ：250G
備考：
状況　ほぼ1日放置したが　コネクト成立率が低め
　　　　β14.6　UP15-25で推移
　　　　β14.7　UP　0-6 で推移
CASHは40Gぐらい破損してると言うことかな？　　
-------------------------------------------------

>>748
β14.7の実行モジュールは一度更新されていますが
それはDLしましたか？

ノード晒しで、accsとか警視庁の鯖にｱﾚさせるのは何とかしませんこと？
と、まぁ、ここで吠えても意味は無いだろうから、自ら率先して捏造ノードでも晒しますか
これもテスターの仕事だしね（ｗ

どのヴァージョンからだか忘れたけど検索初回時に
小さなファイルばかりになるのは当てはまるファイルの
ハッシュを計算するのに時間がかかってるからなのか？

>>750
捏造ノードはひとまずやめとけ。
クロだと断定されないから、初期ノードが監視されても問題は無いような…

>749
失礼しました　β14.7小ファイル対策済みVer　更新済みです

>>752
えええぇ、なんで？
こういう問題こそwinnyの真でないの？
アンタ、それ自らの損得で目を瞑っている発言にしか思えないよ。

>>752
捏造ノード対策は重要度高だと思われ。
　ＫやＡにサーバーアタックしたＩＰとして摘発のチャンスを与えてしまい、
　開発完了までに別件ﾀｲｰﾎでwinny開発に横槍をいれられる罠

>>752
初期ノードが監視されるんじゃなくて
捏造初期ノードをNoderefConst.txt
に登録した人が監視される危険があるんじゃないの？

>>754
接続回りのバグはあらかた出きっているんじゃないかな。
初期ノード晒しのCGIに自分以外のIPを晒すのは、
間接的なDOS攻撃とみなされてもおかしくないかと。

接続時のパケットを解析して、あえて偽パケットを返すようにして
エラー処理のテストをするのはやってみる価値はあるかも。

タイムアウトやポート警告が数回出たらそのノードの情報が
初期ノードであろうが別ファイル作って捨てるのはダメかな？
バージョンが上がらない間は生きているノード情報は縦横に流れていくから
一時的に落ちて接続できないノードが切り離されても
復帰後にその端末側から接続すればまた復帰できるわけだし。
初期ノードから捨てられた情報を集積すれば初期ノード情報からの
削除判断も容易になるし。
固定IP以外の人は常に変動の可能性があって、DDNSであろうが
次にそのIPを獲得した他人のマシンに接続テストを行いに行くこともあるのだから、
初期ノード情報の健全性の維持にはエラー情報を反映できるようにしないと。

>>758
その辺の対策はしてあるはず。

まず、初期ノードのIPを登録した時は
　自ノード　　　　　　　　　　　　　　　　　　　相手ノード
　　｜---SYN(コネクション確立要求)--->　｜
　　｜<--ACK(SYNに対する確認応答)---　｜
　　｜<---SYN(コネクション確立要求)---　｜
　　｜---ACK(SYNに対する確認応答)-->　｜
として接続可能か確認します。
普通はこれで繋がりますが相手ノードがWinnyを起動していなければ最初のSYNに対して応答が
無いので自ノードはACK応答待ちﾀｲﾑｱｳﾄで終了します。
相手ノード側からは1回接続要求が来ただけのように見えると・・・
接続できなかったのでノード情報に並ぶことも無く、手動で再接続しない限り相手ノードに再度
接続要求が飛ぶことはありません。
で、繋がっている他ノードから接続用のIP情報が飛んでくる場合だが、接続できるIP情報を
相手に渡すので、貰ったIP情報で関係の無いノードへ接続要求を飛ばすことはありません。

・結論
初期ノード晒しCGIや初期ノード追加でK殺等のIPを晒しても、最初に登録した人が1回SYNを
飛ばすだけでWinny内でそのIPや接続不能のIPが出回ることは無い。
Winnyのシステムとして１ノード繋がればそこからリンクが増えていくので晒されたIPを全部
入力する必要もないので、実際にK札にパケットを飛ばしている人は少ないのでは？

多分こんな感じ(ﾏﾃ

タスク状況で表示される「コネクション接続限界エラー」は
コネクションは不要っぽい罠

>>760
ん〜どういう事？
単に「コネクション接続限界エラー」の表示の「コネクション」って文字が不要って事？

>>761
いっぱいいっぱいのノードに繋いでも意味が無いという事だと思われ

UPファイルとキャッシュからファイルへ正常変換終了後ファイルの整合性について

今、指示Disik2で同一ハッシュのファイルを落とした後、ファイルへの変換が正常に
終了しているにもかかわらず、ファイルの破損が多数報告されています。

これについて、私は2つの可能性があると思っています。

　1.Winnyのバグで、ファイルチェックの処理がうまくいっていない。

　2.同一ファイル名、同一ハッシュ、同一サイズのファイルであっても検索用のハッシュは
　ファイルの先頭部分からしかとっていないため、ファイルの先頭部分以外を大幅に破損させた
　状態で共有することにより、正常変換可能な破損ファイルがほかのノード上に作成される。

２の可能性が高いのではないかと思いますが、何らかの対策をお願いします。

2.の対策としてファイル全体のハッシュを取るという方法も可能ではあると思いますが、パフォーマンス
の問題から見てもあんまり良くない気がしますし、何か良い対策方法があれば他の人も書き込んでください。

>>762
Connection=接続だから「接続限界エラー」だけでいいってことだと思ったが

>>762
ファイルの転送がいっぱい^2で「コネクション接続限界エラー」かどうか調べるには
相手のWinnyプロセスに聞かないと判らないからコネクションを張らないとダメでしょ。

>>764
あ〜そう言われればそうだよね（ｗ

>>763
1については、900MB越えのrarファイルをDLして正常に解凍できたので違うと思う、
くだ質で論議しているファイルは指示のファイルだけだしねぇ・・・
2が多分当たりなのかな？、論議で行き違っている話に正常変換できたファイルは
正常なファイル(正しく解凍ができる)と思っている人がいることがある。

ファイル全体のハッシュを取らないのはその通りでパフォーマンスを考えての事だと思う。
やっぱやると時間とCPUと取られちゃうのかな？
ブロックごとにハッシュを取って個々が正常なのだから全体も正常、だから全体の
ハッシュを取る必要は無しと考えたのでしょう。

前にファイル全体のCRC取って検索キーに乗せたらどう？って書いたら、煽れらたしなぁ・・・
パフォーマンスを考えないとまずいからどの時点でハッシュを取るかが問題ですねぇ。

>>764
(´-`).｡oO(なるほど…危険が危ない)

>>763>>765
何回言われても判ってないみたいだね、君たちは・・・
表示が省略されているだけで、検索でもハッシュ値は全体を参照している。

正常なアーカイブの後半を故意に破損させてからキャッシュ化させると、
検索画面では正常ファイルと同じハッシュが表示されるがちゃんと別物として扱ってるよ。

(´-`).｡oO(なるほど…頭痛が痛い)

(´-`).｡oO(なるほど…ドキがムネムネする)

>>767
ゴメン
>表示が省略されているだけで、検索でもハッシュ値は全体を参照している。
が判る書き込みがどこにあるか教えて。ホントマジで。

(´-`).｡oO(なるほど…ドキがドキドキする)

>>767
何回検索しても俺の環境では、同一ハッシュ同一サイズの指示はひとつしか出てこないん
だけど、>>767の環境では同一ハッシュ同一サイズの指示は複数出てくるの？

>>770
スマン、検索時に毎回全体を参照してるとは書いてないね。
>202　先頭ブロックの管理部分だからといって毎回全体を参照しているとは言えないな、言い過ぎた。
破損キャッシュを正常キャッシュと認識しているファイルを持っている人からは転送されてしまうね。
ただ、検索時の同ハッシュ表示されている別物が転送される事はないと思う。

しかし、14.7からは転送完了時にチェックが入るので破損キャッシュを正常キャッシュと
誤認識している人が少しずつ駆逐されて減って逝く筈。

　そもそもファイルをUPフォルダに入れた状態でキャッシュ化しない場合
後半のハッシュはいつ取ってるの？？？


未知のパワーですか？

UPフォルダを削除すると
キャッシュファイルがWinnyから認識されなくなる気がする。
転送始まっちゃったんで再現テストはできず。

>>774
さぁ？

取りあえず763で言ってる対策は施されてるから
それは自分で検証してみれば？

寝ようかと思った矢先にレスが来た・・・（´-`）

>>773
>しかし、14.7からは転送完了時にチェックが入るので破損キャッシュを正常キャッシュと
>誤認識している人が少しずつ駆逐されて減って逝く筈。
眠くてイマイチ意味がわからない・・・

>>774
勝手な予想を本スレに書いて良いのかわからんけど・・・
おそらく、ブロック毎で転送する直前にハッシュを取っているのでは？
先頭ブロックの管理部分はそのファイルをブロックごとに細切れにした時の数を
ハッシュの管理フラグとして持っているのではないかと思う。
つまり128kByteのファイルなら64kBごとに別けてブロックが2つ、フラグ[00]を管理部分に書き込んで暗号化して送信。
その後データのブロックをハッシュ演算＋暗号化しつつ送信。
受信側は先頭ブロック＋データのブロックx2を受信。
先頭ブロックの暗号化を解いてハッシュでファイルのチェック、データブロック1個目も同じようにしてチェック。
データブロックが正常なら管理部分の[00]を[10]にして残りのデータブロックを処理。
管理部分のフラグが[11]になればめでたく完全キャッシュの出来上がり。

こんな感じかと予想してる。管理部で全部のハッシュ値を持ったら結構な量になりそうだし、
先にブロックごとのハッシュ値を全部計算しておかなければならないし・・・
47氏が降臨した時に「全然ちがいます」を期待しつつ寝よう・・・

・・・って書いたけどフラグじゃ旨く管理できなさそう・・・ｳｰﾝ

「今日はWinnyをつけっぱなしにしてワールドカップを見よう」
ってことで、Winnyの起動状態を監視して異常終了してたら自動でもう一回起動するの
作ったんだけど、公開はまずいかな？
本体の機能はいじらずに起動常態を維持するためのだからよさそな気もするんだけど…
上げる場所がないからあぷろださがさにゃならんけど。

それと、こーゆーのは、くだ質？

Winny用補助ツールに関するスレ
http://jbbs.shitaraba.com/computer/bbs/read.cgi?BBS=1449&KEY=1022144584

非公式でこういうのもある
少なくとも本スレではないと思う

>>778
http://tmp.2ch.net/test/read.cgi/download/1022942882/141

下の書き込みで
14.7に対応してる。
再起動機能も付いてる。

>>776

>取りあえず763で言ってる対策は施されてるから
どんな対策なんだろう？？？

>>763の１にしても可能性は残っていると思ってる
ファイルチェック機能がちゃんと搭載されているのは知っているし、
そのコーディングに問題がなければUPファイルとDLは完全に同じもので
あるのは間違いないと思う。
ただ47氏が人間である以上はミスもするだろうし、１である可能性は残っている。


>>763の2に関しては、今のWinnyでは先頭ブロックおよびファイルサイズ
ファイル名が同一のファイルに関してはWinnyは同一ファイル扱ってしまう
ことに起因していると思っている。

これが間違ってるのあれば、それはそれで全然かまわないが>>776のような
ちゃんと分かってない奴と議論するのは面倒だしうざい。

とりあえずシジ２以外では現象出てないんでしょ？
β14.7でとりあえず破損の流出は防げる仕様になっているんだから
ﾏﾀｰﾘ様子を見ることぐらい出来ないの？
他のファイルでもあきらかにおかしくなる現象が多発してから報告すればいいんじゃないの？

>とりあえずシジ２以外では現象出てないんでしょ？
元から壊れていたのかもしれないが、他にも動画の破損は多数報告されてるし
俺の環境で2つほど解凍できない圧縮ファイルある。

>β14.7でとりあえず破損の流出は防げる仕様になっているんだから
>ﾏﾀｰﾘ様子を見ることぐらい出来ないの？
キャッシュの破損が広まる措置が取られただけでしょ。

>他のファイルでもあきらかにおかしくなる現象が多発してから報告すればいいんじゃないの？
なぜ、起こっている現象の報告を後回しにするのかがさっぱり分からない。

>>783
動画の破損なんてMXではごくあたりまえにあるわけだから
それをそのまま共有してる可能性のほうが高いのでは？
あきらかに、こうすれば現象を再現できるって言う報告が出来ない以上
原因を特定するのは難しいでしょ。
俺は複数台でテストできる環境があるが、テストしてみた限りそういう現象は出ていない
わざとプロセスを停止してみたり、バイナリエディタで一部変更してみたり
色々なパターンでテストしてみたけど
騒がれてる現象は出てこない。

もちろんテストした環境は閉じた環境でのテストですので
捏造ファイルを外部に漏らすようなことはしてません。

>>784
ちゃんとテストしたわけではないので確証はないけど、先頭ブロックおよび
ファイルサイズ、ファイル名が同一のファイルに関してはWinnyは同一ファイル
扱ってしまうために、先頭ブロックおよびファイルサイズ、ファイル名が同一の
破損ファイルがネットワーク上に存在することで正常なファイルに混じるのが
問題だといってるんだよ。

この問題が発生するかどうかは、内部構造をちゃんと分かっている人であれば
即答出来る事で>>47氏の負担になるとも思えない。
>>47氏がたいしたことないと思えば、そのまま放置することも出来るし、なぜ実際に
起こっている問題の報告に他の奴が過剰に反応するのかが理解できない。

>>783
>>151

>>783
黙ってみてたけど、もうちょっと確たる証拠と対応策(せめて発生条件)を見極
めてから本スレに持ってきた方がいいんじゃないかな？
元から壊れていた可能性が否定できないまま47氏に対応を迫っても、どうし
ようもないと思われ。
ファイル破損に関するネタはさんざん既出だから、これに関するチェックは
47氏自身、随時してると思うし。

とにかく、騒ぎすぎだからちょっと落ち着いた方がいいと思うよ。

>>785
47氏の発言をきちんと読み直してみろよ

>ファイルサイズ、ファイル名が同一のファイルに関してはWinnyは同一ファイル
>扱ってしまうために

これは君の大きな勘違い

検索画面のハッシュがまったく同じでも、それは表示上だけの問題
実際はWinny自身は別物として扱ってるんだよ。

>>788
ずっと、「君の勘違い」「その発言を教えれ」の堂々巡り。

そろそろ勘弁してください。

>>789
コメンこれで本当に最後の書き込みする。

>>788
>検索画面のハッシュがまったく同じでも、それは表示上だけの問題
>実際はWinny自身は別物として扱ってるんだよ。
その発言教えれ

>>790

>>151
>>214
を読め
それで、君の仮定に矛盾がある事に気付かなければ
読解力がないということ。

つまり、Winnyが例え間違えて途中のブロックのDLを捏造ファイルのものを
使用したとしても、変換時に部分キャッシュになるということ。
完全キャッシュになったということは、提供元と１byteも違わない

>>790
堂々巡りするなや、大人気ない
証拠、証拠ってうるさいんだよ

787　も言ってるように、お前の理論に確たる証拠を示せばいいだけだろ
他人の揚げ足ばかり取るなよ

復元されたことのないキャッシュは破損ブロックもそのままアップされ続けるのか。

指示2枚目の先頭が4df〜のファイルについて考える．

・サイズが714,122,001の奴が，今現在，うちのノードから検索に一つかかる．
・サイズ違いが他にもいくつかかかるが，ここでは考えない．
・別館を見ると，714,122,001でトラブルが出ているらしい．
・"ファイル変換正常終了"になっても，一部のデータが崩れていてrarを展開できない．
・TBTBで対処している課程を見ると，データの崩れ方はまちまちであり，
　少なくとも3種類か4種類はあるようだ．
・"ファイル変換正常終了"になったということは，大元のUP側と完全に
　等しいファイルが得られたはずである(>>151)．
・しかし，4df〜の714,122,001は現状で1つしか検索にかからない．
・ダウンロードした人間が複数居るのだから，問題の出たファイルのキャッシュが
　完全にWinny上から消えたとは考えにくい．

以上から，

・「"ファイル変換正常終了"になればUP側と完全に一致する」
　という仕様が達成されていない

可能性が高いのではないかと思うんだけど，どうだろう．
どこに問題があるかは，Winnyのキャッシュの扱いを
完全に把握できてないから，漏れにはわからない．

もちろん，

・漏れが現象を勘違いしている

可能性もあるけど．指示はうちに完全キャッシュ無いから横で見てるだけだし．

>>793
それはβ14系の途中で修正された。
790が言ってるのは、キャッシュじゃなくてUPファイルの方だろ？

>>794
とりあえず、続きは別館でやったらどうかな。

>>788
>>ファイルサイズ、ファイル名が同一のファイルに関してはWinnyは同一ファイル
>>扱ってしまうために
これに補足。＋検索用のハッシュ値(つまり先頭ブロックのハッシュ値)が同じ場合
同一ファイルの扱いになるはず。
あと、ファイル名の一致を判定しているかは判らない、過去ログにあるのかな？


>これは君の大きな勘違い

>検索画面のハッシュがまったく同じでも、それは表示上だけの問題
>実際はWinny自身は別物として扱ってるんだよ。
これがちと疑問、表示上だけの問題でWinny自身は別物として扱っているというのはどういう事？

自分はファイルサイズ＆ハッシュ値でファイルの判別をしていると思うのだが。
こちらで調べた限りファイルサイズとハッシュ値が同じで別ファイル扱いになっているものは
見つからなかった。
検索結果の表示は1つだけしか見えないけど分割DLができるような状態で、検索用のハッシュ値と
ファイルサイズは同じだが、ファイル全体のハッシュを取ると別ファイルだと判るファイルを
実はWinny内部では別物として扱っているって事なのか？

PCが3台あれば検証できるんだけど俺1台しかないし・・・

くだ質に移ろうと思ったけど
あちらはあちらで違う空気が流れてるので
もう少しこちらで

>>794
>・「"ファイル変換正常終了"になればUP側と完全に一致する」
>　という仕様が達成されていない

ハッシュ関連のプログラムを組んだ人なら解かると思うが
整合性をハッシュでチェックしている以上、プログラム側のバグで
この現象になるのは考えにくいと思うけど、どうなんだろうか？
もしバグがあるなら、「変換正常終了」になったファイルの
殆どが壊れているという現象にならなければ、納得いかないのだが・・・

（´-｀）.｡oO(UPフォルダから直接UPする時の最初に、全体の整合性チェック
　　　　　　　のためのハッシュ値を算出＆転送して ない なんてこと無いよね…)

>>796

本スレ向きの話題じゃない？

>>797

もし>>797が正しいとして，しかしそれでも
後半が異なるファイルが区別されうるとすれば……

ファイルサイズ・ファイル名・先頭ハッシュが同じ物は
ダウンロード時に同じ物として扱われるが，
最終的には最初にダウンロードしたファイルになるようダウンロードし直す，

ということになると思われる．

てことは，検索画面に今表示されているファイルが
後ろの方を変えた捏造ファイルか正しいファイルかは確認できず，
レジュームするときには相互に異なった方をレジュームしている可能性がある．
(ブロック単位では正しいが，全体から見ると正しくない)

最終的に"ファイル変換正常終了"で得られるのは，
ダウンロードを最初に開始した時(レジュームでない時)に，
それがどっちのファイルだったかに依存する，と思われる．

指示の例で言えば，714,122,001の4df〜は，実はたくさんあるが，
検索で見えているそれが，どのそれかはわからない，ということになる．

>>797が正しいかどうかが問題だが……
DL側の全体ハッシュは変換時に取るから良いとして，
UL(特にUPフォルダからの直接UL)側の全体ハッシュは
どのタイミングで取ってるんだっけ？
特にそういうファイルができてる様子もないので，
UL時に毎回取る以外にないと思うが……

>>798

同意できる．
問題は，比較する2つの全体ハッシュが
変換されるときのエラーチェックでは区別され，
・どのタイミングで
・どのノードで
計算されたか，だと思う．

b14.7でブロック単位の正しさは問題なくなったようだけれど，
それが即，全体の正しさに直結するものではないね．

　　問題は，比較する2つの全体ハッシュが
× 変換されるときのエラーチェックでは区別され，
　　・どのタイミングで

変な行が入ってた．とばして読んで……

>>791の引用を見て思ったのだが下のようなことは起きないだろうか・・・

>>151でキャッシュの構造は
ヘッダ＋・・・・＋データ64KB＋ブロックハッシュ＋データ64KB＋ブロックハッシュ＋・・・・
ととれるのだが（ハッシュとデータの順序は逆かもしれないが）

＞一バイトでも違っているとそこのブロックだけ破損扱いされます。

と言うのはｎ個目のデータ64KBとそのハッシュが一致しない場合でしょ？
例えば元データの最後1バイトが改変されてWinnyで出回ると最後の直前までは改変前のデータと一致して
最後のブロックだけ改変前データと違い、かつそれに対応する最後のハッシュは問題無しと判断されるのでは？
（改変でなくてもバグにより目的とは違うキャッシュにDLされてしまうとか
要はブロック本体＋ブロックハッシュ丸ごと入れ替わる場合）

で、改変前データと改変後データの区別だけど>>214で
＞だから、ファイルの同一性チェックにはとりあえずファイル先頭とサイズだけ使って、
＞全体の整合性チェックは変換作業時のみになってます。
とあり、
・ファイル先頭は前述の通り同じ
・サイズも改変だけで追加削除無し
で同じモノと見なされてDLされるのでは？

DL完了すると
＞変換作業開始することで、初めてブロックハッシュと実際のブロック内容で矛盾が見つかって
＞完全キャッシュのはずが部分キャッシュになるわけです。
となる筈が改変データも正規の手順でキャッシュ化されてるので
ブロックハッシュとブロック内容に矛盾無しとして最後まで変換されると思われます。

さらに改変データですが最後1バイト改変の他に、先頭部分に引っかからない中盤に改変されたものが出回ると
やはり同一ファイルと見られ、レジューム繰り返すうちに中盤DL時に中盤が改変されたキャッシュ、
後半DL時に最後1バイト改変されたキャッシュをDLすると

中盤と最後が改変された第三のキャッシュの誕生（当然ブロック本体とブロックハッシュは矛盾なし）

と改変ファイルが一つ増えるたびに爆発的に亜種が誕生すると思われます。

>>151と>>214以外で言及してる要素があれば何とも言えませんが・・・

>>802
第三のキャッシュ＝第三の改変キャッシュですね

元データのキャッシュも含めると

・オリジナル
・最後改変
・中盤改変
・中盤・最後両方改変

の四種類という意味です。

>>800
>UL(特にUPフォルダからの直接UL)側の全体ハッシュは
>どのタイミングで取ってるんだっけ？
>特にそういうファイルができてる様子もないので，
>UL時に毎回取る以外にないと思うが……
もし取っているとしたら、時間はどのくらいかかると思います？
なんか不安になって来たんですが…

>>802
>>202
>キャッシュ先頭のブロック
>（いろんな管理情報が入っていてここには他のハッシュ情報も入ってる）
らしいので、
>ヘッダ＋・・・・＋データ64KB＋ブロックハッシュ＋データ64KB＋ブロックハッシュ＋・・・・
この形（だけ）ではないのでわ。同様に、
>正規の手順でキャッシュ化
された改変キャッシュも先頭部分は異なるのでわないでしょーか

（´-｀）.｡oO(47氏がいないうちに勝手に仮定の話をするのは非効率な気もしてきた…)

>>802

正しそう．

もし整合性検査に全体ハッシュを使わないのなら，
UL側とDL側の同一性が保証できないのは当然の結果．

例えば，ULフォルダに新規に入ってきたファイルはバックグラウンドで
ゆっくりハッシュ計算して，終わってから初めてキーを流すとか，どうだろ．

いずれにしても，捏造により各ノードのキャッシュは腐りまくってると思われるので，
全体ハッシュを使うようになった後のタイミングで
キャッシュの互換性をなくした方が良いと思う．
少なくとも潜在的に腐ってる可能性があるだけで十分理由になる．

>>804
>もし取っているとしたら、時間はどのくらいかかると思います？

今ためしに600MBのファイルのCRC32をRarutyで取ってみたら，15秒ぐらいで終わった．
ハッシュのアルゴリズムにもよるけど，そう致命的な時間はかからないと思うです．
結果を保存しとけば，各ファイルにつき一度だけで良いわけだし．
が，送り始める前に取るとしたら，そのうちにタイムアウトしちゃうだろうし，
多分，取ってないような気がする……

>（´-｀）.｡oO(47氏がいないうちに勝手に仮定の話をするのは非効率な気もしてきた…)

胴衣だけど，47氏が居る時間は限られるわけだし．

>>804

なるほど〜
ブロックハッシュが先頭部分に影響与えてれば問題ないですね
スレ汚し失礼しました。

>>806

うっ．梯子を外されますた(w

>キャッシュ先頭のブロック
>（いろんな管理情報が入っていてここには他のハッシュ情報も入ってる）

の"他のハッシュ情報"が，全体のハッシュなりブロックハッシュ全部なり
全体の整合性を保証できるハッシュならいいのだけれど，
そうであるかどうかは>>202からは読みとれないから……

>>800
>レジュームするときには相互に異なった方をレジュームしている可能性がある．
>(ブロック単位では正しいが，全体から見ると正しくない)
自分もこれはありうる気がする。

>DL側の全体ハッシュは変換時に取るから良いとして，
>UL(特にUPフォルダからの直接UL)側の全体ハッシュは
>どのタイミングで取ってるんだっけ？
>特にそういうファイルができてる様子もないので，
>UL時に毎回取る以外にないと思うが……
UP,DLともファイル全体のハッシュはとってないと思う。パフォーマンス落ちるし。
これは前にも書いたけど、ここのブロックでハッシュが正常なら全体も正常という考えなのかも。

>>802
自分が考えてたことズバリだ。
これの防止策を考えてみたけどなかなか難しい・・・

もし>>202にある管理部分の情報でブロックごとのハッシュ値を全部持っていてキャッシュチェックをしているなら
キャッシュ変換後のファイルはUP元に完全一致するはず。
なんだけど、これだとキューを入れて先頭ブロックをDLした時に正常なファイルの先頭ブロックなら良いけど、
後ろの方が改変されたファイルの先頭ブロックを掴まされるかもしれない。これはキャッシュ変換するまで判らないし、
改変ファイル掴まれたので再度DLしようとしてもまた同じものをDLしてしまう可能性がある。

で、独自にちと考えて見た方法。
先頭ブロックに自身にハッシュと次のブロックのハッシュを記録、第1ブロックには自身のハッシュと次のブロックの
ハッシュを記録・・・・と、やって全部のブロックをリンクさせる。
これでも第3キャッシュが生成されてしまうことがあるかな？

>（´-｀）.｡oO(47氏がいないうちに勝手に仮定の話をするのは非効率な気もしてきた…)
あとで47氏がざくっと読んで間違いを指摘してくれればそれで良しかと・・・

自分の環境P3-600で700MBのCRC32をTBTBでとって見たけど1分半かかったよ。

>>805
あ…そういう実験しとけば良かった。手間取らせてｽﾐﾏｾﾝ

やっぱりとってないとすると…
完キャッシュになった中継ノードで始めて全体の整合性チェック用の
ハッシュをとることになるのかな。
中継ノードは基本的にUP元より高速だから、中継までに破損してしまうと
壊れたキャッシュの方が広まるスピード早くなって…問題ですねぇ。
>>807
うーん。やっぱり氏がいないとはっきりとした原因はわからないですねぃ

ここんとこ忙しい（締め切り有りなのが２、さっき一つ終わった、
んで、締め切りがあいまいなのが３つ、うち一つは超巨大プロジェクト）
なんで流れを追いかけきれてませんが、

今のバージョンで変なデータが流れるとしたら先頭64K以外が別物になっている
サイズ同一ファイルをUPフォルダに上げている人がいるのではないかと思います。

破損エラー出ても破損ブロック部が0で埋まるだけでDownフォルダにファイルはできる
（ただしキャッシュの方は破損ファイルになるんで強制変換でないと変換不能になる）んで、
これをUPフォルダに持っていくと変な完全キャッシュ
（UPフォルダ内は問答無用で完全キャッシュ扱いされる）になるのではないかと。

単にキャッシュに入ったままなら破損修復されるはずですが、強制変換あたりで
無理やり変換してUPフォルダに置かれると今の方式ではお手上げです。

全体ハッシュを求めないとこれを弾けませんが外部から見てUPファイルとキャッシュを
同じに見せる都合上、ハッシュを前もって求めておくしか手がなく、これは処理が重いし
そこんとこの偽造対策が面倒だったんで、先頭ハッシュに加えてサイズ情報を含める
という対処療法で逃げてたりするわけです(^^;

とりあえず、前のバージョンで破損が広まってしまったのが大きな
理由で今のバージョンで時間がたてば目立たなくなってくるはずですが、
絶対破損しないほうがいいわけで、暇を見て直しましょう。

なお、キャッシュヘッダにもバージョン持たせてあるんで、新バージョンのキャッシュ
プロトコルになったらユーザさんからも見て旧キャッシュと分かるようになると思います。

>810
47師　乙カレーです　

　　　　　　　　　　　　 　∧＿∧
　ｷﾀ━━━━━━━.（ ﾟ∀ﾟ　）━━━━━━━━━!!!!!!
　　　　　　　　　　　　　　_,i -ｲ、
　　　　　　　　　 　 （⌒`　　　 ⌒ヽ　　　　　∧＿∧　　　　　　
　　　　∧＿∧　　　 ヽ　 ~~⌒γ⌒） ｷﾀ━（ ﾟ∀ﾟ　）━!!!　　　
ｷﾀ━（ ﾟ∀ﾟ　）━!!! 　 ヽー―'^ー-'　　　　_,　i -ｲ、　　　　　
　　　_,　i -ｲ、　　　　　　 〉　　　 |　　　（⌒`　　　 ⌒ヽ　　
　（⌒`　　　 ⌒ヽ　　　　 /　　　　 |　 　　ヽ　 ~~⌒γ⌒）　　
　 ヽ　 ~~⌒γ⌒）　 　　{　　　　　 }　　 　　ヽー―'^ー-'　　
　 　ヽー―'^ー-'　 　　|　　　　　 |　　　 　　〉　　　 |　　　　
　 　　〉　　　 |　　　　　{　　,ｲ　　ﾉ　　　　 /　　　　 |　　　　
　　 /　　　　 |　　　　 /　　| | 　 |　　 　　{　　　　　 }　　　　
　　{　　　　　 }　　　　/　　|　|　　|　　 　　|　　　　　 |　　　　
　　|　　　　　 |　　　 /　　.|　{　　|　　 　　{　　,ｲ　　ﾉ　　　　　
　　{　　,ｲ　　ﾉ　　　/　　 |　 |　　|　 　 　/　　| | 　 |　　　　　

>>810

乙です．

やはり，全体の整合性は求めていないのですね．

>>805
>例えば，ULフォルダに新規に入ってきたファイルはバックグラウンドで
>ゆっくりハッシュ計算して，終わってから初めてキーを流すとか，どうだろ．

という提案をしてみました．
ULフォルダにあるだけではキーは流さないで，
徐々にハッシュ計算して，キーを流すようにする，という．
プライオリティを調整すれば，負荷の問題はないはずです．

DL側ではその全体ハッシュと比較して整合性チェックする，と．

それと，ダウンロード後の自動変換で破損エラーが出たときは
とりあえずDownフォルダからは当該ファイルを自動的に削除した方が
良いと思うのですが，いかがでしょうか．
破損エラーになっていることに気が付かずにWinnyを
閉じちゃう(またはWinnyが落ちる)事があると思うので．
強制変換のみで取り出せるようにした方が良いと思うのです．
破損というのは，DLは実際には完了していないわけですし．

>>813
>>例えば，ULフォルダに新規に入ってきたファイルはバックグラウンドで
>>ゆっくりハッシュ計算して，終わってから初めてキーを流すとか，どうだろ．

その方法だとハッシュを取ったあと、ファイルにロックかかる訳じゃないので
ハッシュを取ったあとに故意にファイルを破損させることも出来る。
あくまでも悪意があって破損ファイルを流通させようとした場合だが。。。

>その方法だとハッシュを取ったあと、ファイルにロックかかる訳じゃないので

ファイルにロックをかけない限りの方が正しいですね。

>>808

>なんだけど、これだとキューを入れて先頭ブロックをDLした時に正常なファイルの先頭ブロックなら良いけど、
>後ろの方が改変されたファイルの先頭ブロックを掴まされるかもしれない。これはキャッシュ変換するまで判らないし、
>改変ファイル掴まれたので再度DLしようとしてもまた同じものをDLしてしまう可能性がある。

それは正しいけど，問題はないと思う．
要は，同じ先頭ハッシュ・名前・サイズを持つファイル同士が区別できさえすれば，
あとは普通の捏造ファイルと同じ理屈だから，2chとかで捏造情報を交換するしかない．

今回の問題は，それが区別できないことによるデータ化け
(さらにはデータ化けの遺伝的増加)だから．

>先頭ブロックに自身にハッシュと次のブロックのハッシュを記録、第1ブロックには自身のハッシュと次のブロックの
>ハッシュを記録・・・・と、やって全部のブロックをリンクさせる。

漏れも一瞬それ考えたんだけど，駄目．
隣しか見ないことになるから．隣ごと攻撃者から受け取ったらアウト．
全体がリンクしないのよ．隣としかリンクしない．

前のブロックのハッシュが次のブロックのハッシュに影響するってのは，
全体ハッシュと意味的に等価なので，これも意味無し．

>>814
>その方法だとハッシュを取ったあと、ファイルにロックかかる訳じゃないので
>ハッシュを取ったあとに故意にファイルを破損させることも出来る。

そうすると，実際に送られるデータと全体ハッシュが一致しなくなるので，
DL側で正しくエラーとして扱われるよ．
もちろん，ダウンロード時には区別できないわけだけど．
でも最終的に正常変換にはならないので，他に出回ってるファイルならば
他のノードからレジュームすることで修復できる．
少なくとも壊れていることがわかるのだから，致命的な問題にはならないように思う．

>>815

多分ハッシュは永続的に保存することになるから，Winny終了時には
ロックのかけようもないし，ロックは考えなくて良いと思う．

>>816
ハッシュを取ったあとにファイルのロックをかけないと結局破損ファイルのキャッシュを
流通させることが可能であり、かといって全体のハッシュを求めるためにはファイルが
完成している必要があり、破損部分のキャッシュが流通するのを決定的にとめられない気がする。。。

>>813>>816
暗号化はどーするですか？

（´-｀）.｡oO(愚痴スレで誤字った…鬱）

>>817
>流通させることが可能であり、かといって全体のハッシュを求めるためにはファイルが
>完成している必要があり、破損部分のキャッシュが流通するのを決定的にとめられない気がする。。。

いや，決定的に止める方法は現実的には無いと思うよ．

ULフォルダからの直接ULを禁止して，強制的にキャッシュに変換する手はあるけど，
CPU/HDDに対するリソース負荷がキツすぎて駄目でしょう．

もしそれをやったとしても，キャッシュをいじればいいんだから．
ブロックハッシュごとブロック差し替えちゃうとかさ．
キャッシュをいじったかどうかの判定は全体キャッシュの計算が必要だから，
これも，負荷の点でまず対処不可能．

漏れが言いたいのは，
・現状では捏造によって破損したかどうかどうかすらわからない
・全体ハッシュを求めれば，少なくとも破損したことがわかるようになる
ということであって，破損キャッシュの根絶は目的としてないよ．
できればもちろん万々歳だけど．

>>818

全体ハッシュは暗号化データではなく，
ファイルの生データに対して求めればいいだけ．
別に暗号化データの全体ハッシュをとっても良いけど，負荷増えるだけでしょ．

あ，一個思いついた．

全体ハッシュだけじゃなくて，ブロックごとのハッシュも求めちゃう．
んで，ULフォルダからの直接UL時は，保存しておいたブロックハッシュと
ファイル本体を比較するわけだ．違ったらエラーで止める．

これで，保存しておいたファイルを単純にいじるって方法では，
崩れたキャッシュを広めることができなくなる．
確実に攻撃を防げる訳じゃないけど，ある程度めんどくさくなるわけで，
現実的には十分な対策かもしれない．

>>820
以前出てた、全体・部分ハッシュ情報を本体と分離する案？
最初の計算やUL時に負荷がかかるけど、いい方法だと思う。
今のキャッシュは全て使えなくなるかもしれないけど。

別のキーでも、本体が同じなら、同一キャッシュを共用できそうだし。
でも現状、別ファイルになるのって、キャッシュの不可視性も考えての事なのだろうか・・・

結局バグだバグだと言ってた奴がいたけど
>>810を読むかぎり、現時点での仕様じゃねえかよ
結局捏造ファイルをUPフォルダに入れなければ
現象が出ないということだろ

>>822
怒ってるの？

>>821
>以前出てた、全体・部分ハッシュ情報を本体と分離する案？

多分違うと思う．
>>820で書いたのは，単に，UPフォルダからの直接UL時に，
UPフォルダにあるファイルがいじられていないかどうかを
検査するためだけに取るブロックハッシュ．他のことには使わない．

>>822

47氏じゃなきゃどっちかわからなかったんだからしょうがないんじゃない？
実装の不具合ではないけど，仕様の不具合と言ってもいい．
どっちにせよ重大な問題だよ．

究極的にはキャッシュファイルを一つにしてその中に個々のUP用ファイルイメージ
を作るしか無いだろうね。でもそうするとチッコイファイルシステムを新たに作る
ような物だから４７氏にしてみればやってらんないでしょうなぁ。

>>822
気持ちは解からないでもない
47氏も
>>810で
>とりあえず、前のバージョンで破損が広まってしまったのが大きな
>理由で今のバージョンで時間がたてば目立たなくなってくるはずですが、
と言ってる様に
>>782の話で終わってたのを、ループさせてたからね。

まあ、ﾏﾀｰﾘ逝きましょう

>>826

全体ハッシュを取ってないからb14.7では
"破損ファイル"は防げても実際のデータ破壊の拡大が防げない，
という話をしてたのであって，全然ループしてないよ．

>>827
もうあまり議論したくはないんだが
それは>>785のことでしょ
それはβ14.7になるまでに破損キャッシュのまま出回ったのが一番の問題で
元々の捏造ファイルさえ最初にDLしなければ防げるでしょ
実際問題、捏造よりも本物の方が出回る数が多いわけだから、段々と減少してくるでしょ
MXと違ってWinnyはわざわざ捏造するメリットは今のところないのだから
そらぁ、最終的には何回もDLし直さなくて済むようになれば、それに越した事はないけどね

部分キャッシュを強制的に変換して作った、不完全なファイルをUPフォルダに入れてしまえば
それが今度は完全な形のファイルとして扱われ流通しはじめるということで、>>８２２が言ったように
根は捏造ファイル問題と同じ。キャッシュの取り扱いや全体ハッシュで解決する問題ではないと思う

仕様として、先頭ブロックのキャッシュとサイズからファイルを同定している、部分キャッシュのファイル化の際
破損部分を０で生めると言う２点が物事をややこしくしているだけ
前者は現実的に正しい割り切りと思うが、後者は破損部分は思い切って切り捨てて、ファイルサイズの一致しない
不完全なファイルにした方が混乱が起きにくいのでは？
サイズ違いの不完全ファイルがＵＰされることもあろうが、完全なものと不完全なものが同一視されるよりはましかと

とりあえず最も大きな問題だった、中継で出来た破損含みの完全キャッシュは排除されるようになったから
それが収束するまでは、この件はマターリでいいと思う

Dowフォルダを公開することで、破損ファイルが広まる？

巨大なファイルをダウンロード完了後、変換中に破損が検出されるが、
破損(破損部分は0パティングらしい)ファイルが自動的にUPされる。

これによって広まったファイルがかなりあると思うのだが。

>>828
>それは>>785のことでしょ

そうだよ．
自分としては>>785の件の流れで色々書いてたのよ．
机上でも検証した方が良いかと思ったのと，何か良い具合の解決策でも出てくればと思って．
まぁ，ループしてたというなら，それはそれでいいや．ゴメソ．

>実際問題、捏造よりも本物の方が出回る数が多いわけだから、段々と減少してくるでしょ

全体ハッシュ問題が解決されれば，それが期待できるかもね．
ただ，多くのユーザはファイル名だけを見てダウンロードするから
一度出てきた捏造が減ることはないだろうってのはさんざんガイシュツだけど．

>>829

捏造が正しく伝達されるというのと，
レジュームによって正規のファイルにも部分的に感染していくというのは，
結構違う話だと思うけど……

とりあえず先頭ハッシュが変わるようにファイルを圧縮なり
しなおせばいいわけだろ。破損が出始めた時点でUPからやり
直すのが一番だと思うけどな。

>>830
確かにDOWNフォルダの公開は、かなり深刻な混乱を生むね
システム的に禁止する必要ありかも

今でもDOWNフォルダはUPフォルダにはならないよ

ってーかそろそろ回覧板撤廃しようや…好い加減ウザくなってきた…

>>835
キャッシュ

>>834
俺のところのβ14.7は出来てしまうが？
それが事実なら安心なんだけど・・・

>>835
1KB以下のキャッシュは一度みんなで捨てて欲しいと思ったり

>>834

出来る。今確認した。β14.7

>>829
>部分キャッシュを強制的に変換して作った、不完全なファイルをUPフォルダに入れてしまえば
>それが今度は完全な形のファイルとして扱われ流通しはじめるということで、>>８２２が言ったように
>根は捏造ファイル問題と同じ。キャッシュの取り扱いや全体ハッシュで解決する問題ではないと思う

現状の仕様だと検索キーにサイズが同じで正常ファイルと正常ファイルの先頭ブロック以外を改変したファイルが
同一に扱われてしまうところが問題なのよ。
で、全体のハッシュを取れば、そのファイルを別物として扱うことが出きるということがキモで、
ユーザーは正常ファイルのファイルサイズとハッシュ値を知っていればピンポイントでDLすることが出来る。

この話は47氏が降臨してくれたのでひとまず終了かな？

>仕様として、先頭ブロックのキャッシュとサイズからファイルを同定している、部分キャッシュのファイル化の際
>破損部分を０で生めると言う２点が物事をややこしくしているだけ
>前者は現実的に正しい割り切りと思うが、後者は破損部分は思い切って切り捨てて、ファイルサイズの一致しない
>不完全なファイルにした方が混乱が起きにくいのでは？
>サイズ違いの不完全ファイルがＵＰされることもあろうが、完全なものと不完全なものが同一視されるよりはましかと

個人的には強制変換もできないで、完全なファイルしかゲットできない方が良いんだけど、ここは意見が別れる所。

>>834は「Downフォルダが指定無しでUPフォルダとして機能することはない」
という意味の，微妙にズレた発言だと思われ．

DownフォルダをUPフォルダにしようと言うのは，どういう理由による物なの？
キャッシュとDownで2重にファイルを持つのが無駄だから，
キャッシュ消して直接ULにしようという意図だけ？
であれば手動で移動する奴はいるだろうし，漏れとしては
・破損キャッシュは自動変換しないようにする (変換後に破損だったら削除)
・強制変換機能も，できることなら廃止
を提案．
壊れたmpgとかを取り出したいニーズって，そんなに大きいのだろうか．

結局、先頭ハッシュと、ファイルサイズを合わせた捏造ファイルに対しては、
起動時にULファイルの全体ハッシュを求めてしまうしか方法ないという事ですかね。

>>839
>>840
強制変換機能はぜひとも必要。
落としているものが途中で確認できないのはつらい。
かつ、破損部分切り捨てで破損ファイルがULフォルダに移動されて完全ファイルになりすます問題は解決するのだから、
強制変換機能を外す必要はないと思う。

>>840
>・破損キャッシュは自動変換しないようにする (変換後に破損だったら削除)
これってキャッシュ変換途中で破損部分を見つけて途中終了したときに、
そこまでに生成されていたファイルを削除するってことだよね？

>>841
ヘタレのおいらにはその方法しかファイルを確実に分類する方法が
思いつかない・・・

>>843
>これってキャッシュ変換途中で破損部分を見つけて途中終了したときに、
>そこまでに生成されていたファイルを削除するってことだよね？

そう．
途中終了は，しないと思うけど．ゼロで埋めて次のブロックから継続してるはず．

最近は朝起きたときにWinnyのリスト見て破損エラーになってる
ファイルを手動で削除するのが習慣になってる．
別にそれがめんどくさいから言ってる訳じゃなくて，
そもそも壊れたファイルが生成されるのはデフォルト動作としては
好ましくないんじゃないかと思うので．

>>842

途中で確認か…… それは頭になかった．
たしかに，それは，できた方が便利かもしれない．
漏れ個人はそういうことをしようとは思わないし，やる人間も少ないと思うから，
是非とも必要というほどには重要性を感じないけれど．

>>840
>・強制変換機能も，できることなら廃止
は
・強制変換は別フォルダに作成
・強制変換したファイルの先頭に『強制変換_』を付加する。
でも、いいんじゃない？　もともと要望があって付けた機能だし。

ファイルにシステム上の最大文字数がついてたら問題だけど。
今後の予約としてUPするファイルの文字数上限を設定しても問題ないと思う。

>>844
「破損ファイルは復元しない」は、まとめ氏がまとめた要望にはいってたけど、
重要度が低く認識されてるのかな？
>ファイル変換で破損が発見されたらファイルにされないオプションが欲しい　16-584

>>842
の意味がわかりません・・・
破損部分切り捨てで破損ファイルがULフォルダに移動されて完全ファイルになりすます問題
ってなんですか？？

>>847
「破損部分切り捨てにより、破損ファイルが〜」だと思うよ。

でも、破損部分は途中のみってのもあるからね・・・。微妙。
破損の場合は最後の10KBを削るとかならどうかな・・・？

>>845
おそらく、低速回線と高速回線の違いによる意識の差かと。
低速だと、動画一本に24時間以上かかるのなんてざらだから途中確認はごく普通の行動です。
一方、高速回線だと落とすファイル数が多くて、DLフォルダのどのファイルが破損しているかというチェックが煩雑になるのだと思う。

折衷案としては、強制変換時のみ破損検知ていてもファイルを削除しなくする。
というのがシンプルでいいかと。

>>846

ん，それもいいかも．INCOMPLETEみたいなものね．
MAX_PATH超えるならケツから切るぐらい優先度高くても良い．

検索時のnot式みたいなのは，やっぱり欲しくなるけれど．

>ファイル変換で破損が発見されたらファイルにされないオプションが欲しい　16-584

見落としてた……
オプションというか，ファイルにされない方をデフォルトにして欲しいな．

>>847
>>848
う、句読点が必要ですた。失礼。
現状の仕様ですでに、ファイルサイズが違えば別ファイルと認識するので、無問題かと。
あと、切捨てはブロック単位になると思われ。

>>848
ファイル名先頭に【一部破損】とか付加するのが妥当な線かと思うが。
ファイル名変更により、検索で別ファイルとして検索できる。
でも自動ダウンで、引っかかるか。

ファイルを削るより、どうせ破損で再ダウンロードなりTBTBなりが必要なら、
先頭の１バイトを変えてしまうのもよいかと。これならキャッシュで区別がつく。

>>848
では
データ（動画）としては破損しているWinny的に完全ファイルは
UPフォルダに移動できて完全ファイルに成りすますって問題ってことなら

結局データ（動画）的には破損してるファイルが出回ってしまうんだから解決してないんじゃ???
解決って???　なに??

一応強制変換　反対派です。

WinMX3.1日本語ﾊﾟｯﾁ完成




http://pc.2ch.net/test/read.cgi/software/1023198848/l50

>>852
名前変えてもWinnyが見るのはハッシュとサイズだから、ちょっと弱いと思った。

>>853
このレスは俺の案にたいしてかな？
サイズが違えば別ファイルとして認識してくれるので、その点に関しては問題ない。

>>853
｢成りすます｣というのは、Winnyが先頭とファイルサイズが同じなら同一ファイルとして扱ってしまう問題を指していったわけで、
破損ファイルが別ファイルとして流される可能性があるという問題は解決しません。

ただこっちの問題は、｢思ったものと違うものが落ちてくる｣という意味で全部が捏造されたファイルの問題と合わせて
考えた方がいいのでは。すくなくとも、Winny上で区別する事は可能なわけですから。

（´-`）.oO(強制変換推進派は、winnyコミュニティに対してのメリットを示してほしいなぁ…）

>>849
スレの流れとは関係薄だけど、参考までに。
ISDNで約735MBの十分に出回っている動画ファイルのダウンロードを実験中です。
昼間/深夜は自動DLで放置、朝夜に手動試行。
8日目に突入しますが、ようやく450MBを超えた頃です。
（7日間を平均するとDL帯域の使用率は1%程度）

中速→高速→低速の順で対策されるそなので、その日をﾏﾀｰﾘ待ち焦がれてる日々。

計算式間違えた。ビットとバイトがごちゃ混ぜ。
10%位ですね。(450*1000)/(7*24*60*60)/7=0.106

>>857
Winnyの使い勝手がよくなって、ユーザー数増加に＋…とか。
こじつけ気味(ぉ。

確かに強制変換は破損ファイルがまぎれこむ一因ですけれど、他の理由によりまぎれこむ事は防げません。
また先も言ったように、変換失敗ブロック切り捨てによってWinny上で区別できるようになりますし、
それを利用して自動DLで間違ってDLする事を防ぐ事もできます。

とまあメリットを主張する、というよりは、
メリットを残したままデメリットをほぼ減殺することができるのなら、
そっちの方がいいんでない？という主張です。

今「シージ」で検索すれば、強制変換の弊害（そればっかりじゃないけど）を体験できると思うが・・・
自分は付いてても使わないからどうでも良いや。(=´┏┓｀)

>>861
む、同名、異サイズのファイルが増殖して検索機能が低下するということですか？
それは気付かなかった…

>>862
いやいや、今は部分キャッシュもUPできてしまうですよ

>>863
うーん。起こっている事はそうですけれど、
それから派生する問題は大別すれば

１：間違って落としてしまう。
２：検索機能が低下する。

の二つにまとめられると思います。
１は>>860のように対処できるし、
２はファイル名に強制変換時に特定文字列追加＋検索に無視ワード追加で対処できるかと。
２の影響は低そうですけどね。

>>860
どう、「みんな」の使い勝手がよいのか正直わからん。
（´-`）.oO(「漏れ様」を中心にwinnyは存在してるのか･･･）