Share(仮称)TESTER_WORKS Part 01

A75Cにしたら、IOエラー連発するのは何で？

おまえだけ

>>250
たとえば、電子メールの送受信に使われる TCP ポート 25 (SMTP), 110 (POP3), 143 (IMAP) を相手が使ってると、
これらのポートをリッスンしているウィルス・スキャナーを無意味に通過させなきゃならないのでウザイと言いたいんじゃないの？

帯域制限ソフト使ってないんでわからないけど、ひょっとして、これらのポート使うと、ウィルススキャンしているユーザーの
帯域制限ソフトのshare.exe用のフィルターをスルーできるとかするのかな？

>249
葱でShareのポートを塞げバカ
>253のカキコ参考にな。

>>253
そういうことでつ。
最近やたら、そうしたポートの接続要求が増えてて、そのたびFWが反応してて、一応ログチェックとかもしてるからウザくてかなわん。

あ、基本的に遮断してあるから実害は無いけど、ログに妙な痕跡残ってて気持ち悪いだけ。

[要望]
「条件が一致したらトリガを削除」じゃなく「ダウンロードが終了したらトリガを削除」にしてほしい。

あとDBが重い。消しても完全に消えてない気がする。それになんでシフト押してなきゃいけないの？
そんな感じ。

>>257
あほたれ。＞要望

cache.idxはキャッシュフォルダごとに作成してそのフォルダ内に保存する方がキャッシュ大量削除事故を防げると思う

雑談スレにも書いたけど、hash.dbをmarking.dbとdownloaded.dbに分割する
キーステータスのDBもMarkingとDownloadedに分ける
トリガの「DBにキー追加のみを行う」は「Markingのみを行う」に変更
DownloadedステータスはCompleteキャッシュ削除時のみ付加されるように変更
クエリのステータス抽出ボタンもDBを消してMarkingとDownloadedを追加
周囲ノードが持つキャッシュの状態によってステータスが変化しないようにも修正よろしく

回線接続時の平均UL速度が申告値に比して異常に低いとか、
不良ノードであることは自分が一番よくわかるわけで
周囲に「自分は不良ノードです」という情報をバラまいてはどうか。
ポイントとはまた別で。

機能改善要望

要望
　[ダウンロード]タブ内の、[サイズ]項目と[優先順位]項目の間に、
　[残サイズ]項目と[DL済%]を追加して欲しい。

理由
　優先順位を、残サイズの少ない順やDL済%の大きい順に設定したいため。
　
　この順に優先順位を設定できれば、単位時間内の完了DL本数を
　増やすことが期待できるので。

>>262
[残りサイズ]はサイズから計算できる範囲
[DL済み%]はプラグインで対応できるかもよ




と思っただけ

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

>>264
その通りでございます。

＞でも、以下のプラグインで似たようなことが出来るかもな。
情報さんくす!
ちょっくら見てきます。

776 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：05/01/08(土) 01:15:36 ID:e01l7WNz
（；゜◇゜） そんちょって要望に答えた事あるの？

782 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：05/01/08(土) 01:22:06 ID:J9qNVCKv
>>776
実は結構ある

863 名前：天[] 投稿日：05/01/08(土) 22:12:37 ID:J9qNVCKv
ｷﾃﾀｷﾃﾀｷﾃﾀｷﾃﾀ━━━(ﾟ∀ﾟ≡(ﾟ∀ﾟ≡ﾟ∀ﾟ)≡ﾟ∀ﾟ)━━━━ｷﾃﾀｷﾃﾀｷﾃﾀｷﾃﾀ



　　　　ﾒﾄﾞｩｰｻ�W　ｷﾃﾀ━━━(･∀･)━━━!!!! ｳﾌﾌﾌﾌﾌ

という訳でｻｸｰｼｬﾀﾝ 漏れはこれから読むので忙しい！ﾊﾞｰｼﾞｮﾝ数日は出さなくて良いzo！


……はあ！？

新機能をテストするために最新ﾊﾞｰｼﾞｮﾝと同じﾊﾞｰｼﾞｮﾝ番号を持ったRev2やrev3をリリースするのはいかが？
ﾊﾞｰｼﾞｮﾝ番号変えると警告が出て騒ぎになってしまうので趣味テスターのみ適用推奨と言う形で
安定した段階でﾊﾞｰｼﾞｮﾝ番号上げて活動限界発動させれば移行もスムースに進むと思われる

>>267
村長が全角が嫌いらしいからAって表示しているだけ
αﾊﾞｰｼﾞｮﾝなのに安定ﾊﾞｰｼﾞｮﾝを求めてる自体おかしい
安定ﾊﾞｰｼﾞｮﾝがほしいならいつになるかわからんが正式ﾊﾞｰｼﾞｮﾝが出るまで使うなってことだよ
知ったかで言われてもな
ﾌﾟﾛｸﾞﾗﾑの工程の勉強でもして来い

プログラム云々はさておき、
自分もα版で安定バージョンを求めるのはちとおかしな話だと思ふ。
いや、気持ちは分かるんだけど。
というか、もしかして、現段階ではまだα版だという認識が普及してないんかな？

そもそもは、いつ�dでもないバグに見舞われてもおかしくない、
そんな発展途上のShareの挙動を生温かく見守る人柱、
それがﾃｽﾀｰであり仕様村村民だったのだが…。

バージョンが来れば速攻アップ、エラーが出れば動作報告
例えバグでキャッシュが消えてもぶつぶつ言いながら再拡散
最近落とした物と言えばShare本体とプラグインだけ
そんなおいらは仕様村の村民さ

>>269
そうだな。
まあ工作員も入り込んで、煽ってるだけのﾔｼもいるようだけど
前はもっとﾃｽﾀｰの質が良かったように思う。
>>270
俺が尊重ならおまいに村民栄誉賞を与えるよ
･ﾟ･(ﾉД`)ヽ(ﾟДﾟ )

つーか、テスターでさえない。
PC関連の板だと、不具合報告するにしても環境を書くのが常識化してる
のに、ここはただ「・・・できない」ってそればっか。全然、テスターじゃないよ。

動作報告スレは別にあるけど…。
で、こっちは後発の、>>1にもあるけど
要望や使用状況等をﾏﾀｰﾘ語るスレ。

というか、昔の本スレのふいんき（←何故かへｎ（ｒｙ だな、ここは。
ぃょぅスレと足して二で割れば、もうカンペキに。ｗ

>>273
shereスレって前スレはAAだけだったから、もう見てなかったんだけど
今見てきたら本ｽﾚとあんまかわんないふいんきになっててﾋﾞｸｰﾘした

俺も新版来たら速攻上書きしてきたけど、アルファテストといいながら修正や変更ばかり
そんなのでバージョン上げましたなんて言って欲しくないわけよ
唯一ポイントシステムは結果はどうあれ面白かったね
現実に増加するDL厨をコントロールする手段として提案してみたけど真性テスター様にはお気に召さなかったみたいね
俺的には仮想ネットテストでプロトコル変えまくるとか密告対策でキャッシュ管理方法変えてキャッシュ消えまくりとか
熱すぎるバージョン待ってるぜ、作者様よ

>>272
動作報告は専用スレにしてるよ

>>275
そうだね
バージョンアップなら新機能追加とかでして欲しいな
修正版なら日付が変わってもバージョン番号まで変える必要は無いと思う

>>275
真性ﾃｽﾀｰじゃなくてﾃｽﾀｰという皮をかぶったｷｬｯｼｭ即消し厨のDOM野郎が文句を言ってただけ

ポイントは、歯抜け問題に対して村長が打ってくれたひとつの奇策だった訳で、
自分も割と好感が持てたんだけど、とうとう完全廃止の方向も見えてきてちと残念。

でも、ポイント反対派＝即消し厨とは限らないんでないかな。
匿名性に対する認識とか危機意識も、人それぞれ物差しが違うし。

>>275の提案というのは>>267です。念のため
やはり過去ﾊﾞｰｼﾞｮﾝに干渉しない新機能追加時のみﾊﾞｰｼﾞｮﾝageるのが理想的ですね

バージョンまだー？

ここが本すれでいいのか？

作者さぁん〜〜〜　ソース非公開のプラグインでいいから

Winny のキャッシュフォルダとShare のキャッシュフォルダとをバイパスできるようなの出してくれたら
放流しまくるのに
ny キャッシュフォルダ内の完全キャッシュ→トリップそのまま自動でShare　放流

やっぱり職人さんのトリップそのままで流してあげたいよね

無意味だな

そうでもない。
単純に、Shareのキャッシュが増える。
意味はある。しかもかなりおっきな意味が。

でもそれはキャッシュの暗号化を無駄にすることになるから、作者自らやらないでしょう。
lark氏が気が向いたらやってくれるかも…。どうかな。

キャッシュ削除しかトラブル対策がない場合もあるみたいだから現状全てを責めることは出来ないわけだが、
やはり拡散キャッシュの保持サイズに応じてShareDown枠を調整するべきではないだろうか？
作者が無事な限り調整ができるからとりあえず2から始めて10GBで1増えるくらいが適当か
その次は25GBでその次は45GBでと必要拡散キャッシュ容量を増やしていく。ドラクエ等におけるLVUP方式だな
あの手のゲームと違うところはキャッシュ削除して容量が閾値を下回るとダウン枠が下がってしまう所。無料ソフトだから我慢我慢
さらにUL帯域絞りを捕捉して拡散UP先から外すようにすればキャッシュ流通が少しは良くなるかと
これは50すら提供しないノードが対象なのでDSLいじめにはなりませんので予めご了承を

全体の平均拡散キャッシュサイズを増加させる方法とUL帯域絞り対策をαの内にいろいろ実験しておくべし

製品じゃないんだから、αのうちにとか関係ないでそ。
何なら一生αでもいいわけだし。

nyで捏造が蔓延した原因のひとつに、
キャッシュ保持量をdownにおける有利性に結びつけたことが
関係しているだろうということを考えると、
キャッシュ総保持量＝down枠は諸刃の剣だね…

でも、もう結構捏造も増えてるし、どうあってもこういった形の
P2Pにおける宿命なんだろうから、今さら関係ないかな('A`)

Share本体以外でのキャッシュ削除にペナルティつけるなりして
勝手にキャッシュ削除→ダウソに不利になるようにすりゃ
ちったぁ状況良くなるかも・・・

まぁShareのキャッシュ管理が今以上に洗練されないと逆効果っぽいけど。

>>288
Nyでは中継して作られたキャッシュとダウン指定して作られたキャッシュの区別がなかったよね
そのため全キャッシュ容量で計算するしかなかったと思う
Shareでは拡散ダウンで作成されたキャッシュは内部で区別されているので別に合計サイズを計算可能
どこの誰だかわからない人の為に捏造ファイルを拡散させるボランティア精神溢れるDL厨ばかりでなければ大丈夫かと

ULキャッシュたくさん抱えてる身にすれば、
拡散キャッシュなんて邪魔でしかないんだよなぁ。
しかし、周りのノードが拡散キャッシュ抱えてくれなきゃ
それはそれで効率悪いし。

あぁなるほそ、あくまで「拡散」キャッシュの総保持量のみを反映させるということか。
それだと、Shareに割り当てている80Gのキャッシュ容量のうち、
60G近くが自upファイルだったりする自分も>>291と同じくツラいかな(;´Д｀)

ただ、キャッシュ保持量をdownの有利性に反映するには一番いい方法だとも思う。
Shareの強みのひとつとして、自分でupするのはｶﾞｸﾌﾞﾙだという消極的参加者でも、
拡散キャッシュのみを多量に保持してもらう事で、当人が罪に問われることは
まずない状態でネットワークに貢献してもらうことができる、というのがあるし、
そもそもキャッシュ割り当て量は、やる気次第でいくらでも増やすことは可能な訳だし…

完全キャッシュ保持量　＜　沢山持っているよ
拡散キャッシュ受け取り保持量　＜　ちゃんと受け取って貢献してるぜぇ
Request 数　＜　オレのはこんなにも需要があるんだぜ
送信データ数　＆　Diffuse接続承認数　＜　放流っ放流っ　撥ねられずにうｐうｐ

これらを複合的に絡めてダウン枠や速度上限調整すれば
落としてキャッシュすぐ消すバカ共以外からの文句って出にくいと思うんだけどなぁ

>>285
おフロ入りながら考えてみたけど、暗号化に関しての無駄は杞憂じゃないかな？
だって同一ソースとトリップ作成用文字列でWinnyとShareの完全キャッシュは作れるから
比較だけならかなり前からできますもん。

だからWinnyのキャッシュフォルダから完全キャッシュだけをバイパスして
Share形式キャッシュで(拡散)ＵＰ、他の周りのノードでしかコンプリートできない。
流す本人はnyで完全ファイルは入手できるので問題無い。

現状でも（密）輸入人は複数（結構沢山）いるからみ返りを望んでやってるわけでもないしね
まぁ　開発者さんにはキャッシュ消えの抜本的対策やってくんないと
輸入する面白みも無いわけで

たぶんハッシュとキャッシュを勘違いしてるんだな。

キャッシュはnyもshareも独自に暗号化してるよ。
復号キーがわからなきゃ、誰も復号できないぞ。

ハッシュはどっちもMD5ハッシュだべ。
これはRFCで公開されてる仕様だからな。
手順どおりやれば誰でも取れる。

WinnyのハッシュはMD5
ShareのハッシュはSHA1
じゃないの？

あ、そうだった。
MD5より衝突少ないの宣伝してる奴がいたっけ。
極小確立なのに。

>>295-291
Winny の完全キャッシュからの複合は　Winny cacheinfo を含めて逆汗など
ソースも出回ってるから問題無い、
Share へのコンバートは今の所 Share 開発者さんでないと出来ない
ハッシュ値はもちろんSHA1に変わるけど、オリジナルが誰のか判りやすくて良いと思うんだけど
手分けして皆でやれば流通量は増えるが、キャッシュが消えていく速度が速過ぎ

いっそnyのダウンロード機能もプラグインとして持ってMD5ハッシュによるリクエスト受付も
ゲートウェイ分散でやったらすごいことになる
（Winny Network データ乗っ取り？　いやいや　サルベージですよ）

ny内のゴミファイルもそのまま垂れ流しって状態にはならんかな？

本体作者にnyネットワーク侵入機能を期待するのはかなり厳しそう
Shareが使えるならnyは問題なく併用可能だし。できる人がプラグインとして作るのは特に問題ないと思う