Share(仮称)TESTER_WORKS Part 01

　　 　　　 　　　　┏━━┳┓┏┳━━┳━━┳━━┓
　　 　　　 　　　　┃┏━┫┃┃┃┏┓┃┏┓┃┏━┛(仮称)
　　 　　　 　　　　┗┓┗┫┗┛┃┗┛┃┗┛┃┏━　導入安定稼動済み
　　 　　　 　　　　┏━┛┃┏┓┃┏┓┃┏┏┫┗━┓テスター用スレッド
　　 　　　 　　　　┗━━┻┛┗┻┛┗┻┛┗┗━━┛
　◆◇◆　P2P ファイル共有ソフトウェア　Share(仮称) =開発テスト中=　◆◇◆
　 　　 　　注意事項　　　最新バージョンの使用は義務です。

■関連スレッド　[Share] 又は [仮称] で検索
■関連サイト(ノード)
┣ ttp://rightp2p.s68.xrea.com/node/
┣ ttp://moejump.s6.x-beat.com/node.php
┗ ttp://www.stereoz.net/node/
■関連サイト(説明その他)
┣ ttp://phphp.s58.xrea.com/
┣ ttp://rightp2p.s68.xrea.com/
┣ ttp://www.stereoz.net/
┣ ttp://printf.jugem.jp/
┣ ttp://share.gooside.com/index.html
┣ ttp://www.ero8.com/
┗ ttp://cgi.f46.aaacafe.ne.jp/~sharedb/index.php

ここは Share(仮称) の動向／向上／技術的な視点での機能改善要望
等をテスターが真面目に議論談話する Share(仮称)導入稼動済みテスター用スレッドです。
Share(仮称)開発者がアポーン設定してそうな呼び名は使わずに『開発者さん』又は『作者さん』等を使いましょう。
機能改善のプログラムの変更は時間の掛かるものです。
要望がなかなか反映しなくても地道に議論をして開発者を誘導する事が趣旨です。

『煽り』『荒し』等やスレ違いにはスルー
　一部の者だけが得をする要望ではなくネットワーク全体の効率を考えて
　技術的な意見に批判反論は技術的な改善反論を、機能要望には内容を伴わせるのを忘れずに。
※　ﾏﾀｰﾘ sage 推奨 ( E-mail欄に半角英字で sage と入力 )

質スレに分かれた時点で、Share 本スレは本来のスレに戻ってテスターが論議して茶するハズだったのですが、
荒れたまま全く機能せず開発者も、もう観て無さそうなので、こちらで機能について談話をしましょう。
いまさら細かい説明テンプレは必要ないと思われます。
「多少真面目に内容を議論したいな」と思うまともな人を隔離しておくスレです。
AA 使う場合は大きいものはひかえましょ　プラグインの話題はプラグイン・ツール総合スレで

機能や要望を反映出来るのはShare(仮称)開発者さんだけです。
どのような新機能のテストをしてきてもαテストという事で生暖かく前向きな議論をしていこう！

テスター以外が騒ぐのは本家でやってね

おつです

早速要望など
これは捏造＆キャッシュ即消し対策になればいいなぁ程度なんですが

UPフォルダ廃止、キャッシュに変換して格納する。

○メリット
捏造とキャッシュ即消しを同時に行ってる人間に効果あり。

○デメリット
UPファイルの容量が2倍になる。
そもそも大きいファイルだと時間がかかる。

○問題点
捏造のみ行ってるもの、キャッシュ消しのみやってるものには効果が薄い。

>>4
いきなり否定で申し訳ないが・・・

俺ｷｬｯｼｭ用のﾄﾞﾗｲﾌﾞ20GBしかなくて、
別ﾄﾞﾗｲﾌﾞのUPﾌｫﾙﾀﾞ（現在100GB程度）をﾒｲﾝで共有してるんで
もし、そうなったら共有出来ないかも(；´Д｀)ﾊｱﾊｱ

>>4
いいかもしれないけど、
それによって拡散キャッシュが圧迫されたら意味ない。

俺の要望、キャッシュは古い順に消して行ってるみたいだけど、それだとせっかく拡散されたものが
消されてしまう可能性があるので、クォータ設定はデフォルトで、キャッシュのサイズが大きいものから
消えていくようにして欲しい。拡散されたキャッシュは小さいので、まず消されない

要望:ID識別を容易に

捏造警告みたいに外部に情報を送るわけでは無く、
ローカルだけでDBのように信頼情報を付けられるようにしてほしい。

例えば信頼しているIDは色を変えるとか、一目で判別出来れば便利。

それいいな

>>1

>>6
さすがにキャッシュの新陳代謝も必要であろうから、
大きさと古さを勘案して消すという具合でお願いしたいです。
もしそうなると、大きさと古さをどういった関数に入れるかが、
作者の腕の見せ所になりますね。

あと、そのキャッシュが使われたかどうかも、項目に加えるのはどうですか？
たとえば、キャッシュの生命力を設定する。
時間が経てば生命力は減っていくし、誰かに渡っても減る。
（完全キャッシュと拡散キャッシュでは設定を変えないとダメかな。）
で、生命力が低いと、キャッシュクリアにかかりやすくなる。

でも、キャッシュのコピーですぐ生命力が減ると、拡散キャッシュが駆逐されて、完全キャッシュばかりになってしまいそう？
つまりshareの特性が失われて、一つのノードからすべて落とすことが頻発しそうか？
うーん、難しいな。逆に完全ファイルが駆逐される設定もできそうな気もする。

重くなりそう…

>>10
生命力かぁ…ｗ
ポイントですでにそっち系入ってるし、もういっそ
清く正しいﾈﾄｹﾞP2Pを目指ｓ（自己却下につきｒｙ

冗談はさておき、
それだと、多段拡散がどの程度行われるかにもよるな。
小さいキャッシュはかなり多段拡散が
行われるらしいということは分かっているけど、正しい状況を知りたいなぁ。
時間があったら、TESTER_WORKSクラスタで実験してみたい…。

最近コンプできた日を、キーにぶら下げて流通させるってのはどう？既出？
クエリに出てる更新時刻ってのはコンプした日ではないですよね？

最終コンプ日からあまりに時間が経ってると、歯抜けをあきらめようと思ってくれるんじゃないかな。
古い歯抜けを捨ててもらわないと、いつまでたっても不完全なキャッシュが残るし。
あきらめきれない人は、どっかで放流依頼出して、完全なものにしようとしてくれるかもしれない。

問題なのは、キーを周りから受け取るたびに、最終コンプ日の比較と更新をしなくてはならないこと。
重いかな？ でも更新時刻ってのは、それをやってるんですよね。
他にもなんかありそうだけど、余り突っ込んで考察はしてません。重大な欠点があったりするかな？

キャッシュクリアのときの判断材料としても使えそうかも。
最近コンプが発生したから消すのか、ずっとコンプされてないから消すのかは難しいところだけど。

被害総額を計算するのが簡単になりそうなら、最終コンプ日から、一週間以内、一ヶ月以内、一ヶ月以上、くらいの大雑把なのでもいい。

長くてすまん。

ささやかな要望
DBやREMOTEボタンがクエリタブごとに違う状態を保持できるのだから、ソート順も
クエリタブごとに変えられるようにして欲しい

>>14
はげどう

使いたい人だけ使ってください用もわもわ
(´-`).｡ｏO（）
⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒

'ー'ー'ー○─'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー'ー
(´-`).｡Ｏ

現状の流通しているファイルが古いものからサクサク消えて行くのを改善させる案で
本スレに少し前に貼ったのですが、
ダウンロードフォルダとアップロードフォルダを厳密に分けずに統合しちゃダメなのか？
・キャッシュフォルダはあくまで作業領域と見なす（だってクォータで自然消滅だしHDDには酷いアクセス）
・トリップ付けのアップロードフォルダはアップ専用
・ダウンロードフォルダは完全ファイルフォルダとしてアップフォルダに含ませる
・サブフォルダを含ませる機能は既にあるので、
　トリガ条件のオプションに変換時にルールを付けれるようにして、ルールを適用してアクションを起す
・外付け倉庫用HDD のプラグアンドプレイ等リムーバブルメディアに対応する
　ドライブ文字の割り当て（ドライブパス）だけを使わず柔軟にボリュームラベルでも対応。
・キャッシュフォルダ(キャッシュプール)の容量底上げには最大受信速度の設定値で最低容量を強制する
　どうせ今でも大量にトリガ入れる人はキャッシュＨＤＤ容量に余裕がないと　0個のキャッシュ〜〜に襲われるし

ダウンしたファイルがそのまま整理されて構築できるなら繋ぎっぱなしにしないかな
　＝＝完全ファイルのネット上保有率が上がる？
[課題点]
　DB システムの更なる改良とファイルチェックの簡素化
　各完全ファイル置き場に簡易インデックス を付けて検索速度を上げる等

>13
このスレ始まったばかりなので既出は無いよ。既出でも違う視点から別論展開したら進歩さ。長くてＯＫ

>>17
>・ダウンロードフォルダは完全ファイルフォルダとしてアップフォルダに含ませる

これ意味あるのか？
ダウンフォルダは解凍したりと作業用にもなってる人もいるだろうから、
ゴミがネットワーク上に溢れかえると思うぞ。

即消し厨対策として、コンプリキャッシュは強制拡散のうえ一定期間は削除
できないようにする（フィルタにかからないようにする）

と書いてはみたものの捏造だったら困るな・・・

荒らしちゃ駄目ョ　(*^-^)-☆

Share(仮称)TESTER_WORKS Part 01
http://tmp4.2ch.net/test/read.cgi/download/1099329914/

クエリで絞るときにDBやLocalを消してRemoteだけを表示して絞るんだが、たとえDBを消してもRemoteにひっかる奴は表示される
これを表示しない機能ってのは需要ないのかな？

例えばDBが表示されているとして
・DBを押したら今までと同じくDBが表示されなくなる、ただしRemoteや他の条件で引っかかるものは表示される
（今までと同じ）
・次にDBを押すとDBのボタンがバッテンマークか何かになり、Remoteや他の条件でひっかかろうとDBが含まれるもの全てが表示されなくなる
・もう一度ボタンを押すとDB表示に戻る

わかりにくいと思いますが、どうでしょう？
個人的にはあると便利なんですが、操作が煩雑になるのかな・・・

>>21
DBボタンを切ってるときは、DB持ってるファイルは絶対に表示させない（方法も提供してくれ）
という理解でいいのかな。

これは、DBのあるなしで今まで落としたことがあるかどうか判定をする使い方をしているってことか？
俺もそういう風に使ってるときがありますね。
もしそうなら、今までに落としたかどうかをわかるようにして欲しいっていう意図を明確にしたほうが、伝わりやすいかなと。

個人的には、落としたことがあるかどうかの判定ができれば便利なので、何かしらの方法で実現されるのは大歓迎です。
その実装が、DBボタン二度押しになるかもですけど。
操作が煩雑になるってのは、そんな気がしますねぇ。

プラグインじゃ出来ないレベルのことなのかな？ よくわがんね。

それとも俺の理解不足で、もっといい使い方をするためなのか？
すみませんが、意図するところを書いてくれた方が議論しやすいので、そこのところお願いします。

>>22
その通りです、わかりにくくて申し訳ない
ファイルを落とすのにDBに登録しまくって後でじっくりクエリに登録という人もいますが
うちでは主に落としたことがあるファイルかどうかという判断基準に使っています
よって探すときにDBだけ表示させないようにしていることが多いです

しかしDBを表示させないようにしていても、RemoteでひっかかるファイルはRemoteの文字が緑色になり表示されます
なので緑色のRemoteは一度ダウンしているもの＝表示してほしくない
こういう使い方ができれば便利だと思って書き込んでみました

一度ダウンしたものの判定フラグをつけるとなると新たにデータを追加しなければならないと思うんですが
DBでひっかかるものを完全排除するモードがあれば同じことを実現でき、且つ検索の所だけの修正でいけるかなぁっと

ボタン二度押しはとりあえず考えてみて書いたのですが、基本設定からそのモードに入るのもありだと思います
しかし実装されるならちょこちょこ使いそうなので、ボタン二度押しやそのモードに入れるボタンをつけるなど
一発でできる方が楽かもしれないです
問題は需要があるかどうか・・・

>>23
>しかしDBを表示させないようにしていても、RemoteでひっかかるファイルはRemoteの文字が緑色に
>なり表示されます なので緑色のRemoteは一度ダウンしているもの＝表示してほしくない

自分は逆だなあ
緑RemoteでDLした事があるとわかるのでファイル名やハッシュが違っていても
サイズで類推できるから便利だと思ってるんだが・・・

ささやかな要望　その2
クエリワードにand検索とor検索を併記できるようにしてほしい

ささやかな要望　その3
クエリワードにnand検索とxor検索を併記できるようにしてほしい

歯抜けになるのなんとかしてぇ

>>24
そういう使い方をする時もあるから、すぐに切り替えられたら便利って書いているんじゃないかな？

>>18
>ダウンフォルダは解凍したりと作業用にもなってる人もいるだろうから、
>ゴミがネットワーク上に溢れかえると思うぞ。

DB 機能ってのがあるのでそこを機能強化したらダウンロードしてきた物のみ
ＵＰ対象って出来たらどうなのかなぁ
解凍ファイルや他のフォルダからダウンロードした（DB登録外）以外の持って来たら無視で
そうすればゴミ放流は防げると思いませんか？

DB 即消し　したらポイントリセットでダウン枠最低からやり直し orz
　とか
ダウンロードする完全ファイル保存指定フォルダにある DB 用保存ファイルを消したらそのフォルダ内に
ある全てのファイルが再登録されアップ対象になっちゃう　なんて個人的にはオモシロいかも

似たような案が関連スレで過去あったのだが補完

基本設定 アクション　でダウン関係に　□多重ダウンロードを行う　があるが
□集中ダウンロードを行う
というような物もどうだろう？

[内容]
１個づつ確実に Complete したいという意見
チェック有効：ダウンロードの始まったファイルで優先順位の上位１ファイルのみを
　見つかったキャッシュをダウンロード枠全てその１ファイルに集中多重ダウンロードする。
　他のファイルに枠を割かず浮気しない、落とせる断片が見当たらなくなれば Complete に関係なく
　次の獲物に集中して取り掛かる。

[利点]
他のファイル同時進行が多過ぎで未完キャッシュのキャッシュフォルダ圧迫を少しでも低下させる。
１つでも速く完全ファイルにしたいという欲望を(ry

>>30
優先順位上げるだけで十分そうなると思うが。
少なくともnyよりは集中度をコントロール出来る。

>落とせる断片が見当たらなくなれば
この判断は無理だな。
結局次のファイルに取りかかるなら、今の優先順位で十分役割は果たせていると思われ。

つか、トリガに少しずつ入れればいいだけの様な希ガス

疑問
ﾊｯｼｭ情報等をｺﾋﾟﾍﾟしてﾄﾘｶﾞ画面で貼り付けした場合、貼り付けたものにID付いてた場合に
同ﾊｯｼｭでID無しのものはちゃんとやってるかが疑問。
ちゃんと出来てるとは思うけどいいテスト材料が見つからないのでどうなのかなと。

指定キャッシュ保護機能ってのを作って欲しいです。
落としたものの中で気に入ったのがあれば、拡散して欲しいと思うのは人情。
でも、今のままだと勝手に消えちゃうかもしれない。

要するにone cache delete　の逆の機能ですね。

初心者なんで、もしすでにあるんならすみません。

ああ、確かにクォータからの保護機能は欲しいかも。
放流物をキャッシュ化してたら、いつの間にか消えちゃうから…

>>34
多分キャッシュホルダは、みんなのストレージって意味が強いと思うんですよ。特にshareでは。
なので、個人で、キャッシュフォルダの一部を占有し続けるのは、あまりよくないと思います。

もし、気に入ってるものがあれば、UPフォルダに入れてくれってことになると思います。
カタログで拡散をするって手もありますが。

まぁ、以上は建前です。
実際、UPに入れたり拡散するほどのものでもないけど、ちょっと保護してやりたいなと思うことはありますね。
なので、クォータにかかるのを少し耐えられるような指定ができればいいなぁ。
無茶なことはできないように、耐性アップ指定には、ポイント支払いが必要とかで。

今はクォータ削除を逃れるにはUPフォルダに入れるしか無いから、
キャッシュに保護機能付けるってのも利便性を高めるためにプラスに働くと思うが。

>>個人で、キャッシュフォルダの一部を占有し続けるのは、あまりよくないと思います。

個人のHDDなんだからどういう使い方しようが個人の勝手でしょう。

キャッシュ保護機能について、
選択式がいいかなと思いますね。
この機能導入すると起動直後HDアクセスで重くなると思うんで使いたくない人も多いはず。
Ex.
□ディスククォータ機能を使用する。
　　□Completeされてるファイルは極力保護する。

ってな具合にするとか。

たまにはあげとくよ

>>37
>個人のHDDなんだからどういう使い方しようが個人の勝手でしょう。
もっともです。
空々しいレスになるだけですが、理念や建前の話においては、拡散してみなで持ち合おうってことでしょうから、
拡散キャッシュが勝手に消えやすくなったり消されたりするのは、方針には合わないかと。

さて、キャッシュを保護することについては、多分意見が分かれると思うんですよね。
二つに分けて戦わせようってのじゃなく、プレーンに整理するってことで。

完全キャッシュを優先したい人
　　確実に歯抜けでないキャッシュを持ちたい。（他人が持っていて欲しい、増やしたい）
　　UPフォルダに入れたくない。
　　放流者の匿名性維持のためなら、拡散は始めだけで。（拡散キャッシュが長く残ってもしょうがない）
拡散キャッシュを優先したい人
　　完全キャッシュを持つのは気持ち悪い。拡散（使えない、見えない状態）で持つほうが安心。
　　拡散キャッシュが消えるのが早くなると、レアなものが集めにくいし、歯抜けも起こる。

まだ他にもあるかな？どっちの方が早く落ちるかは、難しいのでパス。
どっちも前提にしていることが違いそうなので、このへんでもう一度ポリシーの発表をしてくれないかな？>作者さま

このスレ、作者さんは参考にしてくれるんでしょうか？
そういう話があったんですか？公式か何かで。
いろいろ提案があるんで、読んでくれてるなら嬉しいな。

Editionの更新も17で止ったままで作者の声が聞こえてこない現在、せめて前向きに
議論をしているこのスレくらいは見て参考にしている　　　と期待したい

>>41 はてさてｗそれは闇の中　埋もれがちな案をまとめて作者さんが参照しやすいように
（と　今後 Share 以外の新P2P を開発する方がいれば問題点の列挙と改善案〜〜〜 (ry
プラモデルでも何でも“何か”作った事がある人なら完成っぽい物に新しく内部に手を加えるのは
いかに大変か理解出来ると思うのでマターリいきませう。
本スレ荒れてる途中までは動作報告スレ以外にだけにあった改善要望が採用されていた事実もある。
より強力なP2P に育って欲しい、今後数ヶ月ほど各スレの動向を追えばこのスレ　も　見ているかきっと判るでしょう。

↓　公式より
------------
連絡先
2chのどこか。
こちらからは、基本的に何も発言しないし名乗ることもないけど勝手にスレ読み漁って、適当にフィードバックを受けさせていただきます。
------------

1日レスなかったか・・

マジでshare離れが始まってるみたいだね…やっぱ決め手はポイント制だったのかな…

（・∀・）ﾆﾔﾆﾔ

過去、12日間位バージョンが無かった事が2回あるみたいだけど今回は長いなあ・・・

ついに仮想ネット実装か…？
…と、期待してしまいますね。

就寝前の保守

とりあえず思いついた策をいくつか‥

1.拡散うp先のクラスタを指定できるようにしてほしい
2.数回うpされた拡散キャッシュは自動クリア
4.残ったキャッシュは手動で消すかまとめて他人へ転送
5.キャッシュもう少しまとめてほしい(10ブロックぐらいに)

>>50
1. 同意。一気にUPフォルダに追加したときにも、簡単に使えるように考えてもらいたい。

2. 即時クリアは乱暴だけど、次のキャッシュクリアで消えるとかで。
あと完全キャッシュも対象にして欲しいな。ハードル高めで。
たとえば、月初めに出回る、作者の好きなアニメとか、すごい数の人が完全キャッシュ持ってるはずだし。
ある程度間引いて、スペース効率をよくしたほうがいいんじゃないかと思う。
爆速とキャッシュスペースのトレードオフになりますが。
と思って、俺は人気のものはある程度経ったら、自分で消してる。

4. 微妙。手動でキャッシュいじるの推奨したくないので、なにかしくみがあるといいな。
他ノードへの転送も、キャッシュの淘汰を考えると難しい面がありそう。
転送先クラスタも考えないと、迷子が出るか、ゴミの押し付けになりかねないし。
あと、何気なく「まとめて」って書いた？ なにか意図がある？
つか、3が欠番なのだけど、そことつながりがあるように書いてるのかな？

>>50
１はアップフォルダ毎に拡散先優先クラスタを付けられたら便利とおもう

>>52
いいねそれ

>>51
確かにゴミかどうかの判別は難しい所ですね。量が量だけにまとめて送っててしまえ!と思ったんですが混沌としそう..
あと3が抜けてました…。ｽﾏｿ

3.拡散クォータとローカルクォータを別々に設定したい
たまる拡散キャッシュと自分でなんとか集めたローカルキャッシュの割合を半々ぐらいにしたいです…

コンプリートするまで時間がかかったキャッシュを
カタログに入れてるんだけど、拡散終わって消えちゃうと
後でそのキャッシュを拡散したかどうか分からなくなる。

カタログで拡散したら履歴みたいのが残るといいなと思った。

>>55
デフォルトでOFFになってるなら問題ないかもだけど、
こういうのには、激しく噛み付くやつがいるだろうなあ。
なんであれ、UPしたファイルの履歴を残すのを嫌がる人は多かろうから。

「shareはUPした履歴が残る」ってのが、一人歩きするのが怖いので、
プラグインで実装した方がいいかなって思います。

>>56
あー言われてみればそうですね。
たしかにshare本体でこういう機能を実装するのはマズイと言うよりも
使う側が嫌がるでしょうね。
やはりプラグインで任意に機能追加するという方がいいすね。

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

質スレも本スレもスレ違いかもしれないのでここに一応書いとく
trigger.txt　ﾌｧｲﾙ名プラス

,,0,0,0,でチェックなし
,,0,0,1,で有効のみチェック
,,0,0,2,で条件が一致のみチェック
,,0,0,3で有効と条件一致をチェック
,,0,0,4,DBにキー追加のみチェック
,,0,0,5,有効とDBにキー追加をチェック
,,0,0,6,条件が一致とDBにキー追加をチェック
,,0,0,7,で全部チェック

要望を
トリガ画面に複数ファイル名があったとき、その内いくつかだけを有効にしたくて
選択しても、全て有効か無効しかないので選択した部分だけ有効or無効を右クリに入れて欲しい
お願いします

トリガーキーの貼り付けができなくなってるんですが…

age

おお〜、いつの間にやら67ｃまで出てる！

保守

>>60
トリガーやダウンロードに表示されるファイル名、左端の［］をクリックすると
チェックの有無が変化して、個々に有効か無効を指定できる
これは便利ですね。

キャッシュ延命案でつ。

1 キャッシュの冗長化（容量に応じて割合変化）
2 クォーターにかかった時、周りが多く保持しているキャッシュから削除
3 完全キャッシュは基本的に消されにくく設定。
　　ただし周りに多くの完全キャッシュがあるときは例外。
4 自分しか保持していない完全キャッシュを消す場合、
　　需要がある程度あれば（最終使用日で判断？）拡散UPを試みる。
　　やりすぎるとゴミだらけになるので、調整必要。
5 キャッシュフォルダーの容量に応じた、何がしかのメリットを与える。

すみません。
ageてしまった。orz

＞クォーターにかかった時、周りが多く保持しているキャッシュから削除

周りが連鎖し同じファイルを消してファイルあぼーん

＞完全キャッシュは基本的に消されにくく設定

完全ファイルをなくすための分散型P2Pなんじゃないの？

>>66
>5 キャッシュフォルダーの容量に応じた、何がしかのメリットを与える。
間違ってキャッシュ全消しになった人が書いてたけど
それまでダウンロード枠が８個ほどあったのに２個まで減ったって
フォルダーの容量もかどうかは判らないけどキャッシュ持ってるメリットは存在してる

本スレ荒れまくりだし、
ﾀﾞﾃﾞｨとかでてきてひどいことになってたから
Shareを真剣に考えてる人はもういなくなったのかと思ってたら
こんなところにたくさんいたじゃないか。
ﾖｶﾀｰﾖ･ﾟ･(ノД`)･ﾟ･

本スレはﾊﾞｰｼﾞｮﾝｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!!!
をやるためだけのスレになってたからな・・・

あっちはもう雑談スレということで・・・

本ｽﾚは厨と業者しかいないから、もうとっくに見てないな

67cにしたが速度がえらい不安定で
初めは爆速、そんであっとゆうまに
１ケタ台まで落ちてそこで推移orz
あと、ノードと繋がるのがすごく遅くなった。
XPsp1 Pen4 2GHz メモリ768　ケブラー

作者殿乙です。

アップロードタブ内でも有効・無効機能が使えれば便利かと思います。

ＩＭ機能』について

　もともと Winny が MX にみるそういった「うざったいやり取り」を嫌ってＨＤＤから容量を出し合って
　１個の巨大なストレージを皆で共有するというものに共感してやっているので、保有率も多いのだが、
　ＩＭ　で発言を載せる事は、その発信言動内容が殺伐とする事が安易に想像できてしまう。
　「さっさと流せや　ｺﾞﾗｧ」とか「通報しますた」等　某所からの警告文とか（汗
　発言が流れていく事で受け取り先（ファイル放流主）の匿名性が無くなると多人数に思われている。

　すこし考えを捻って　Request 表示の様に　クエリ画面表示で　ステータス/被参照量　の後にでも
　ファイル毎に近隣からの　RequestＩＭキー要求数の集計を表示させ　Download 済みDBキー保持者の所で
　放流を促すシステム設定からの文字列表示を出すようにすればどうでしょう？
　「Request要求ＩＭキー」も数種類作っておくと面白いかも　再放流依頼・？・？
　発言内容が保持者へ直接上がらないので匿名性も維持されると考えられる。
　何にでもキーをだされると迷惑なので、
　発行条件に
　　・トリガリストに登録されている事
　　・最終ブロック更新時刻から一定期間過ぎれば１ファイルに１Request要求ＩＭキーを発行でき、
　　　　かつ　完全ファイルか補完できる部分が見つかればその要求はクリアされる。

　第一放流者のみオーナー属性ファイルに対して何度でもコメント付け（返信）が出来て
　拡散ＵＰロードと同じ手法でばら撒かれる、コメントがあるかどうかはクエリ欄に[IM 更新時刻] を表示
　受け手は表示/非表示　を任意で設定できるが匿名性確保の為に流れ去ったIM の再取得はできない。仕掛け網。

　[利点]
　　クエリ画面で「Request要求ＩＭキー」の簡易集計が表示される事でそのファイルは Complete しにくい歯抜け状態で
　　放置されているとすぐ見分けられる。

>>74
ｲﾗﾈ(　ﾟдﾟ)､ﾍﾟｯ

>>69
あまり書きたくはなかったけど、うそ臭いのであえて報告。

テスト用にキャッシュスペース５G、キャッシュ量ほぼ０、ポイント０の
shareも飼ってるけど、ダウン枠は変わらないよ。
とりあえず今は、キャッシュ持ってるメリットはあまりなさそう。

現状では、枠はDOWN速度設定で決まってないか？
３００設定だと４枠、５００設定だと６枠、
１０００設定にしたら少なくとも９枠はいけた。

まあ、キャッシュを大事にしてもらおうと、ポイント制を導入したんだろうな。

みんな知ってたんでしょ？
変な工作しようとしてる？

ここは報告スレじゃない

Web 公式時代から最新Edition 17まで　ＩＭ　は搭載してくる気は変えていないと思われる。

>仕様一部紹介
>IM機能実装予定。

紹介側で予定を表明している部分の未着手？発言はＩＭだけ
仮想ネットワークは今年中の稼動は間に合わないような発言が
<!--
仮想ネットワークの作業は途中で停止している。
いきなりShareに導入することはない。
今年中に稼動できるかどうかぐらい。
-->
↑とあるので行き詰まっているのかも？

>未実装&未稼働
>IM
>UPnP
>サウンド
>お気に入りIDの設定
>仮想ネットワーク
>秘密の機能1
>秘密の機能2

↑のリストの最上位にＩＭは位置しているので
ＭＸと同様のＩＭが搭載されてきてから騒いだところで後の祭り
今のうちにインプリンディングしておいた方が賢明
（サウンドはプラグインで可能とみられる）

歯抜けキャッシュ削除案

1 キャッシュに日付を持たせる
　・キャッシュのパーツが全て確認された日付
　・上流・下流問わず確認情報のやりとりにより更新されていく。

2 日付から1〜2ヶ月程度経過したものを削除する

3 ﾌｧｲﾙの総容量が GB単位の物のみに限定するなどし
　処理対象は少なめにする


大きなﾌｧｲﾙで、歯抜けのまま流通している部分ｷｬｯｼｭは
資源の無駄なので自動的な削除が望まれる。

再放流を促進する機能をshareに組み込むっていうのはどうでしょうか
周りのトリガとダウンロードを収集して完全キャッシュに
なれそうにないやつの情報を表示できるようにするとかして
DBを利用すればIDやファイル名を壊すことなくキャッシュを延命できると思うのですが

どこかのスレで出てたけど再掲
カタログタブがアップロードタブに変わったのだからUser Catalogも変更するべきでは？

『ポート０　接続』について
　TCP で稼動させているノードを簡易接続サーバーとして http 偽装ヘッダの通信プロトコルで一旦検索接続、
　これには数秒内で済むと思うので、UDP を使ってデータをポート０ノードへ送る。
　UDP 接続に関しては技術的に既に存在しているので問題は無い。
　が、やはり仮想ネットという物が稼動していなければ不安な物である。
　真性ポト０の妨害者が最近静かであるが、こういった物のプロトコル系技術資料を出してこない以上は
　暫く無視していて良いのではないかと思える。
　良質なテスターになる事は無いだろうし、某幇助理由の１つである“誰にでも使える”になってしまうのでなんとも

規制突破接続』について

　もう少し規模が大きくなって某社が製品として商品になると判断すれば一点壁を出してくると思われる。
　　　　　ので
　Share(仮称) 接続パケットヘッダの自動可変型もやれば無敵か？
　データそのものはキャッシュをさらにアーカイブさせて送っているようだから
　リアルタイム解析によるパターンマッチング規制にはそのシステムに負荷が掛かり過ぎで現実的ではない
　現状で対策されるとしたらパケットヘッダでそのポート自体を閉じられる定番の方法ぐらいかな
　ヘッダの自動可変と上のUDP通信を取り入れれば・・・・？

UDPって、データが到着する保証がないって聞いたんですけども、
ファイル共有なんかに使えるんですか？　制御次第なんでしょうか。

>>84
受け側でパケットの破損チェック、到達順、パケロスのチェックしてやれば問題ないと思うけど
わざわざそんなことするくらいなら普通はTCP使うな。

クエリタブが多段になったので追加機能を要望
左右の移動ができるのだから上段と下段とでも移動できるようにしてほしい

増え続ける99999をなんとかしてくれよ

あんまレスないと、良スレなのに死んじゃうかもしれないから、
定期的に何か言えよ、おめーら

梅

(・∀・)

P2Pの帯域コントロールがプロバ側でが不可能となると
月の転送量が一定に達したら、思いっきり帯域絞られたり
固定+従量制みたいのが増えそう

92

93

94

95

▽845 NAME：[名無し]さん(bin+cue).rar sage TIME：04/11/20 02:53:31 ID:0Jp7ly2C
なるほど。
たしかにキャッシュ変換は要らないかも。
８２３さん失礼しました。

余談だけど、ファイルも生き物みたく自己が絶滅の危機に瀕した場合に子作りに励むように組めないかな？

▽851 NAME：[名無し]さん(bin+cue).rar sage TIME：04/11/20 04:05:01 ID:jqKC5Fuw
>>845
漏れもそれは考えてた。
自分の持っている(部分でも完全でも)キャッシュで、自分の周りにその複製がひとつもなければ、
どこかのノードにそのキャッシュの複製を作る。(拡散と同じように？)
これで常に2個以上は存在するはず。
複製が常に間に合っていれば(同時に2ノードから消えなければ)マイナーキャッシュも消えないと思う。
人気なファイルに対しては何も起こらないはず。
でも、ネットワークやディスクが飽和してしまうのかかどうかが気になる。
全員がそういうことしてるの、それぞれのノードの負担は少ないはずと思ってしまうけどどうだろう。
ぜひ実験的にでも実装してみて欲しいなぁ。
漏れはテスターとしてがんばりますのでｗ

▽853 NAME：[名無し]さん(bin+cue).rar sage TIME：04/11/20 05:00:26 ID:0Jp7ly2C
>>851
いいね。
実験する価値はあると思う。
絶対消されない共通キャッシュ領域を最初に一ファイル（その中にファイルの生存に必要な部分キャッシュ作成）をサイズ確定状態で作ってその領域サイズに応じてポイント振るのもいいかもね

あと捏造警告が許容限界値を超えた場合に捏造ファイルを自然淘汰する仕組みがあればいいよね

>>96
それ、こっちに書き込むほどいい案でもないだろよ。
本スレだからほっといたけど。

特に８５１の案は、ネットワークによくないはず。
あるノードのキャッシュが消えたり、ネットから落ちたり、クラスターが変わったりしたときに、通信が大量に発生する。
普段から、よそにキャッシュが存在するかどうか見張ってなければならないので、searchも大変、CPUも大変でしょう。
多分、キャッシュ流す→キャッシュ圧迫で消える→キャッシュ流すのスパイラルになると思います。

キャッシュが消えないというのは、全ノードのキャッシュエリア総計の限界がある以上、無理なしくみでしょう。
キャッシュは淘汰されるべきであるというのを、受け入れなければならないと思う。
その上で、歯抜け救済やレアファイルの流通を考えるべき。

それだけではなんなので、提案も。
shareのシステム上、キャッシュの消滅期には、歯抜けになってくのはしようがないとする。
だけど、どうしても欲しい人は、2chなど何らかの方法で放流依頼をするとしよう。
そのときに、もっと簡単に、UPすることが出来た方がいいんじゃないかな。
たとえば、DVDや他のフォルダからファイルを選んで、それだけを簡単に、キャッシュに変換できるとか。
そうすれば、再放流にも手軽に答えられる。
（もちろん他のプログラムやプラグインにはUPの操作をさせない方向で。キンタマやられそうなので）

つまり、歯抜けやレア対策には人の力を使うと。社会的なアプローチですね。
そういった、shareコミュニティー全体の快適運営を簡単にする実装もお願いしたい。
ユーザーも簡単なことなら、行動してくれるんじゃないかな。

>>97
> それ、こっちに書き込むほどいい案でもないだろよ。
> 本スレだからほっといたけど。
自分は詳しいことは良く分からないけど
本スレにも考えてくれてる人がいるっぽいので貼っちゃいました。

> キャッシュが消えないというのは、全ノードのキャッシュエリア総計の限界がある以上、無理なしくみでしょう。
> キャッシュは淘汰されるべきであるというのを、受け入れなければならないと思う。
やっぱりP2Pをオンラインストレージ代わりにするのは難しいんですかね。

> だけど、どうしても欲しい人は、2chなど何らかの方法で放流依頼をするとしよう。
例え放流依頼スレみたいなのがあったとしても、そのスレに来るのは主に依頼する側の人ですからねぇ。
放流依頼されているキャッシュを持ってる人がそのスレを見に来る可能性は低い訳で。
作者さんの考えてるIMってのがそれをカバーする機能にあたるのかな？

アップロードフォルダからは拡散でしか流せなくする。
登録した後7日毎位でキャッシュの歯抜け度を検索して歯抜けがあったらその部分を自動的に再拡散するようにする。
何をアップロードしているかは表示しないようにする。
私は沢山アップしていますと白状しているようなポイントは即刻廃止の方向で。

ダウンロード専用テンポラリキャッシュフォルダを採用してShareDownしたブロックは共用キャッシュには保存しないようにする。
このフォルダの中身は変換完了後削除される。もちろんキャッシュが存在する限りはUP可能。
これでメジャーファイルや巨大ファイルを落として共用キャッシュがバンバン消されることも無くなる。

一次放流者の安全性とキャッシュの多様性を維持するにはこれくらいやらないとだめだな
あと中継転送を実装し中継転送枠を独立確保してUP帯域を絞らせないようにするべし

天さん質スレでキレてませんでした？
基本的に質スレは厨だらけなんだから・・・
葱厨うｐ0厨が増えちゃうのでは

>>100
だいじょうぶキレてません葱自体は４月ぐらいにはShareスレに出てきてますので。
まだ風邪が完治してなく、ざっくばらんな対応になってしまっているだけです。
ポイント導入の失敗から再び人を呼び込む様な安直な今の仕様は
今後の○ットアークの監視やACC●によるアレとかからの流入を考えると
葱のUP自己規制はいずれ前のUP/Down 従量制にしなければネットワーク内のファイルそのものが
減衰となる事に気が付いて（いて知っててやってる者は勝手にすればいい、しょせんゴミ人格）
多少は開発者は思い知るかな？　

　旨みをちらつかせるより淡々と公正なｗ UP/Down の仕様に固執すればおのずと良質な人は増えるのにねぇ。

『ポイント制』について

[敗因その１]
　捉え所はまぁボチボチでしたけど、『共有』組は非常に他の人に情報を握られるような事は忌み嫌っています。
　他のノードが所持するポイント情報のID が例え、NIC の MAC Address 等を基にした不可逆な Code だったとしても・・・・
　何を使っているかは知りませんですが

　もし、上記の様な「NIC の MAC Address 等を基にした不可逆な Code」ならば『復元出来ないので特定は不可能』とでも
　発言されれば、騒ぐ者達は少々おとなしくなるかもしれません。

[敗因その２]
　ブロックコンプリートの嵐に見舞われファイルのダウンロードが進まない。
　ポイントの等価交換？によって一定ブロック量の転送毎にポイントチェック掛けてませんでしたか？
　それにより転送が中断してブロコンが発生・・再度繋いで・・またブロコン　　の連続で速度が出ない。

[敗因その３]
　第一放流者の行う拡散ＵＰにはポイントがつかない。
　放流だけを楽しんでいる職人はそのまま残っているが、ダウンもしたいという者は呆れて引き上げた。

[敗因その４]
　ＵＰ量だけでポイントが付いたのでオリジナルを上げられないノードがポイントを稼ぐ為に
　需要の多そうな捏造ファイルが横行した。

[一案と今後の行方]
　ポイント数の算出をＵＰ総量だけに絞らず
　要因を割合で比較参照させては？
　ポイントベースに
　　・従来のShare 起動からの Share 送信データ数−Share 受信データ数
　　・Request承認数−エラー数
　　・Share接続承認数−エラー数
　　・待機リクエスト数
　　・最大送信速度−最大受信速度
　　・キャッシュ不整合
　　・自オーナー属性のあるＵＰ／キャッシュ　ファイルの総数（量）−捏造指定数
　　・連続起動時間
　　など等
　これらを複合させて最大ダウン枠等を決定させ、美味しいファイルを沢山上げれつつリクエスト
　が来る良質ＵＰノードはいっぱい落とせると・・・
　なおかつ、いっぱい落とせる為には、
　受信速度を上げる＝キャッシュＨＤＤの容量を強制的に底上げさせる
　キャッシュ消し厨や不安定マシンは各種エラーが出るハズなのでそれだけダウン条件が低下するので消すなと。

　ポイントチェック頻度を数ブロック毎ではなくDown接続がノードと切れた所で計算させれば
　ブロコン嵐は回避できるのではないかと思える。

>>102
敗因その３はおかしい。
それこそ捏造うｐしまくりになるだろうが。

>>103
nyと同じでいいよ。
そんなにいろいろやってたらいつまで経っても次のステップに行かない。

>>103
103案が全てというわけではないが一応気になった点を

>・待機リクエスト数
吸われるファイルやキャッシュを保持していても低速の場合　不利

>・最大送信速度−最大受信速度
非対称な場合　不利

>・自オーナー属性のあるＵＰ／キャッシュ　ファイルの総数（量）
オーナー属性の書き換えが横行しないか→IDによる信頼性の低下

>・連続起動時間
ISPの総転送量による規制がある場合　不利





Shareを可能な限り起動し続けて、ダウンもするが時々は自炊物・輸入物もアップする
拡散も受けるし極端な帯域制限はしない
バージョンには即　対応する

このような人を優遇するシステムを作って欲しい＞作者殿

天さんレスありがとです。
本スレテンプレの葱のおかげで
ネットワークがマズイ方向に行ってると危惧してましたので・・・
色々お考えでの発言だったんですね。

風邪には生姜湯とかがいいみたいですよ
無理をせずあたたかくしてお休み下さいね。

どこに書くのが適当なのか分からなかったので、ここにて失礼いたします。

ポイント復活してるっぽい。キャッシュ含め、Share関連の物を削除して再インスコしたら、
ダウソ枠3で固定された様だ(以前は7〜10、ポイント42000程)。

取り敢えず、需要のありそうなキャッシュを手に入れて様子見てみます。
現在起動後2時間半、ポイント20。

>>107
多分それ、キャッシュ削除が影響してる予感。
キャッシュを削除してupするものが減った訳で、
さらにもしupファイルも0だったとしたら、拡散分割キャッシュ以外
ほぼ何もup要求されないノードになった訳で。
up枠によってdown枠が増減するのは、Shareの昔からの仕様だし。

>>108
> up枠によってdown枠が増減するのは、Shareの昔からの仕様だし。
噂だけじゃなくて実際そうでしたっけ。確認しようがないですけど。

今現在up5、down3、ポイント630。もうちょっと様子見ます。

ポイント制の一番の敗因は、ポイントというパラメータに入っている値を見せてしまった事。

>>109
正確には、
「upの実帯域（申告知でなく）によってdown枠が決まる」だった。ｺﾞﾒｿ。

かなり昔だけど、快調に多段down中、実験として
葱を使って故意にup帯域のみしぼってみたところ、
多段downがとたんにブチブチ切れていった、という報告があった筈。
ポイント制導入の際にこの仕様が切られていなければ、
今でも多分up実帯域とdown枠は、関係していると思う。

あ、何か分かりにくいかな。
その瞬間に実際使用しているup帯域が、
その時その時のdown枠を増やす一つの要素になっていると思う、
だからupするものがない場合、up帯域はほぼ使用されず、
よってdown枠は必然的に、申告値にそった最低数しか得られないのでわ、
と言いたい訳ですにょ。

と言いたい訳ですにょ。

(・∀・)

(・∀・)！

タスクバークリックでトレイ収納うぜぇなぁ
どうしてこういう余計なことするのかなぁ

>>116
ウインドウがアクティブの時にタスクバーをクリックすると、
タスクトレイではなくシステムトレイに収納されるってことなら、
設定タブの『最小化時に隠す』のチェックを外す。

これで解決なら ｽﾚ （´∀｀（　´∀｀） ﾁｶﾞｲ 。

なるほど。
どうして余計なことをデフォルトにしてるのかなぁ
に訂正しとこう。
これをわざわざプログラムする意味がわからん。

あとタスクトレイもシステムトレイも一緒だから、
揚げ足とったつもりなら残念。

>>102
そもそもポイントなどと言うものに縛られるから駄目だと思うんだが・・・ポイントウザ過ぎ
だから早く消えてくれないかと思う。Ver59以降速度に輝きがみれない、全てポイントなどと言う
腐った制度のせいだ。幾ら以前以上にUPしても稼動時間を長くしてもポイントはスグ増えるが速度は
落ち込むばかり・・Ver59以前はこんな事絶対的にありえなかったよ。確かにポイント制廃止と言われた頃
から徐々に速度はある程度戻るが以前のような爆速的キレが全くない、特にDL・・UPは1500以上で吸われるばっか

ポイントについて

ネットワークの貢献度合いを、shareUPで測るというのは、もっと評価されてもいいと思うな。
単独では設定できなくて、相手がいて落としてくれなくては点が入らないというのは、いいと思う。

ポイント導入時にちょっと考えが足らなくて、遅くなったりしたんだと思う。
きっとがんばって、相手ノードのポイントの取得時に暗号化とかしてたんだろうし。
いちいちポイントの確認なんかせずに、ポイントが０になったら、受け取る側のノードから切断してしまってもよかったのに。
その辺がクラックされる前に次の手を出せばいいのだしさ。

ただ、捏造問題と絡んでくるからめんどくさい。
といっても、ポイントと捏造の結びつきは、声がでかくて利口なDOMが仕掛けたキャンペーンでしょう.。
もともと、落としてみないと、何の絵が出てくるかわからないものなので、捏造なんてのは普通にあることだし。
捏造を作るのを面倒にするためにも、ポイント制復活の前に、ヘッダが見れるか途中変換がうまくいくようにしてほしい。

俺は、早くポイント制に戻してほしいと思ってるよ。
ネットワークに貢献したこともない、貢献するつもりもない袋小路のノードに、どんどんUPしてしまうのは嫌だ。

ただ、あの作者が、キャンペーンにやられたユーザーの意見を聞いてポイント制停止にしたとは思えないよね。
なんか、不具合があったか、行き詰まってるのかな？

ポイント制導入のアイデアはよかったと思う
ただ使う側にとってデメリットしかなかったというのが問題
足枷をつけるのではなく利点プラスだけをすれば導入に納得がいったとのではと…

>>120
ヘッダは見れるし、途中まで変換もできますが。

>>121
アイデアはよかったのに、デメリットしか無かったのか…

>>123
（自分のことだけを考えてる厨房にしてみれば）、デメリットしか（無いように見える）ってことでふぁ。

何か笑える話だよな、如何に良くとも生かしきれてないアイデアは屑なんだと早くshareの作者は
気づくべきだと思う。いい加減テスター組と実践組に分けてVerを分けて貰いたいものだよ。
新しいVerが出来たからといって強制で全員30分以内に移れとか言う態度も気に入らない。皆でより良く
広めるにはこの2つは絶対に分けるべきだと思う。安定版を実践組に、最新版をテスター組に・・とね。
それだったら最新版(テスター組)→不具合が無くなったら安定版として→(実践組)に提供する。

ココまで言えば分かると思いますが、今のVer59以降のVerは全てテスター用の不具合版だと言う事を作者さんに言いたい訳です。

>>125
あっそう、やめたらいいじゃん。
来なくていいよ。

>>125
根本的に、間違ってる。

>>120
>不具合があったか、行き詰まってるのかな

基本的に「実up速度」=「実down速度」でｲｲと思う。
デスラーでもup1Mbps出るわけで、1日稼動でDVDISO１枚以上になる。
1ヶ月で100GByte以上。
これでも足りない香具師は光引けということで。

これを時間軸で積分して「単位時間当たりのUP量」=「単位時間当たりのダウン量」
とすればポイントの考え方になるのかな？

こうすれば、何も落とすものがないときもSHAREを稼動させる動機付けになる。
→拡散キャッシュを持っている香具師が非稼動になり歯抜けになることの防止

128の続き

ただこのとき、ポイント情報を自ノードにそのまま置いておくと、
1 ポイントを記憶したファイルをバックアップ
2 ポイント使用
3 バックアップを復元→ｳﾏｰ

かといって他ノードに置くと、
（UP先ノードとしたのは1ヶ所もしくは少数だとそのノードが落ちてると終わりなので妥当な選択）
1 ポイントの確認のためセッションを多数張る必要あり。
2 非力なルーターあぼーん。
3 不具合多発

ここら辺が行き詰まりかな？

再利用不可の状態でポイント情報を自ノードに置いておく方法があればいいのだが。
（軽い認証で他ノードを使うのはありか？）

#あと、>>119をはじめ、忘れてる人が多いようだが、
#全SHAREネットワークの「総UP量」=「総DOWN量」
#自分が吸われてバッカリのときは、必ず誰かが吸っている。

周辺ノードが評価するシステムだぁな。
セッション張る必要なんかねーよ。
何のためのP2Pだい？ｗ

ﾎﾟｲﾝﾖなんていらねーよ
今でさえCPU負荷たけぇのに

UPだのDOWNだの不公平だとか言う奴はＭＸでもいけば精神的に安らかになる予感
p2pの共有思想って損だの徳だのじゃないだろうに

>>132
いやいやそれじゃ逆に持ち逃げだの絞りあいだのと余計にイライラするだろう
結局止めた方が吉

バージョンアップ下げ
作者乙

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

>>135
DoShutdownKun_001.rar と OneCacheDelete
上の2つが拡散無意味になるというのは分かる。

しかし、TaskSpeedSupervisedCut は問題ないでしょ。
というか、私が見逃してる問題は何？

拡散で受け取ったキャッシュは表示されないんだから
OneCacheDeleteも拡散無意味とは言い切れないと思うけどね

ただDoShutdownはどうかと思うぞ　作者さんよ

ささやかな要望
クエリ画面で選択したファイルはソート順を変更しても選択状態を保持してほしい

Shareは新作ファイルがすばらしいな。
ダウンロードにいれたとたん、220k/sからほとんど下がることなく落ちてくる。
当方ｱﾎｰBB　8M　という最悪の構成ですが。

DoShutdownじゃなくて、ダウンしたら、キャッシュを削除・DBも削除
みたいなのだったら結構広まったかも。

47氏本人が記す「Winnyの技術」
http://slashdot.jp/article.pl?sid=04/11/29/0447216

自分が現在ダウンしているファイルをダウン中に拡散できればいいと思う

Diffuse Downしたファイルを、自動でDiffuse UP出来てるんだから可能だと思うんだけど
自分で落としたのはCompleteしないとアップロードに追加できないのでちょっと不便

落としてるファイルがウイルスだったり捏造もあるから、プラグインであったほうがいい気もするけど

>>142
それだと、ネットワーク上にキャッシュのブロックが
全て完全には存在しない不完全なファイルが
淘汰されにくくなるという欠点があるかな。
大きいサイズの物は釣り流しも多いし。
あと、破損の判断なんかも、完走しないと難しい気が。

そこで一度不完全ファイルの淘汰をする為、久々のキャッシュ全消しバーj(ry

ただ破損ファイルの判断は難しいかな。やっぱり

保守

環境設定のパス記述をフルパス以外に相対パス（とかドライブ名）も使えると便利
USB フラッシュメモリにShare本体と設定ファイル一式入れてるしぃ
パソに抜き差しするだけで環境もっていけて便利な反面、ドライブレター合わせるのが・・・・
ヤバイ状況が発生したら引っこ抜くだけで済むし

それ相対パスで解決するのか？

バージョンは来ないが、保守はする。

機能を改善してほしい。
完全キャッシュを持っているものに対してDLのリクエストが来たら、
自動的に拡散UPになるようにしてもらいたい。

そうすれば、キャッシュの初期放流＆2次放流での匿名性の確保もできると思う。

>>149
お前馬鹿？

即消し厨対策として、完全キャッシュが出来たらその
完全キャッシュの任意のブロックを削除してそれと同時に
キャッシュの拡散をするっていうのはどう？歯抜けファイルは
増えると思うけどキャッシュの寿命は延びそうだし匿名性も向上
しそうでも効率が落ちそうだな

>151
トラフィックが上がりそうだな
完全キャッシュ（他人ＩＤ）を沢山もっててそれに対してリクエストが多数来ていて
実質ＵＰしてるとダウン効率上がれば良いようにすりゃええのに　と思わない？

>>151
それが捏造だったらどーすんのよ。
捏造の拡散促進してるだけだし。

即消し厨は放置に限る。
技術的にどうこうしても意味無し。

>>153
捏造は拡散とは別問題だと思う

キャッシュ即消しの理由として

○完全キャッシュを持つことのリスク
○ディスク容量の圧迫
○うｐによる帯域の圧迫

か？

別問題なのではなく
捏造問題と即消し問題は表裏一体なんだろう

落としたファイルが捏造であったときを考えれば
これまでキャッシュを即消しして来ただろうけど
それを出来なくさせるというのが即消し対策

捏造問題を優先する人、即消し問題を優先する人、両者は全く正反対の立場。

捏造問題は、目視判定しかない
即消し問題は、ローカルなファイル管理(share起動以外での削除等)
で、いずれもshareのシステム外の要素が大きく
余り突き詰めても仕方ない

完全キャッシュを持つことのリスクと、ディスク容量の圧迫が即消しの理由ならば
キャッシュを消しにくくすればする程、shareのクリーンインストールを増やすだけ。
即消しどころか、キャッシュフォルダ内全消しが増えることになる。

>153
もし捏造だったとしても、結局落とす人がいなくなるから淘汰
されていくんじゃない？

>>156
普通はそうだけどshareは拡散があるから暇なやつがいれば淘汰されず残ることも考えられる

('A`)ヒロシです…

一週間かけて落とした映画が捏造でした・・・・

('A`)ヒロシです…

>>156
結局、本物かどうか分からないものが流れ続け
落としてみないことには本物かどうかは分からないのだから
落とす人がいなくなるということは殆ど無い。
殆どの人は地引が基本で、本物にも警告がつく
捏造警告は信用ならんことが多いしな。

実際にShareazaに実装されてる機能なんだが、
歯抜けの動画あるじゃん、あれをさ、成分抽出して再構築して
再生できるところだけかき集めてプレビューできるのね。

歯抜けキャッシュをさ、ブロックごとに複合するI/F実装すれば
誰かが勝手にプラグイン作ると思うんだけど、どうよ？

×複合
○復号
ね。

>>160
キャッシュビューワが作れるってことはプラグインからキャッシュ読み込みは
可能なんだけど、誰も作ってないのが現状。

キャッシュは暗号化されてるだろうよ

定期

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

ほう、そんなものがあるのか・・・
しかし、歯抜けキャッシュの強制完全変換は本体側でやれば
簡単に実装できそうだがなぁ。
そうすれば、ほぼ完全なファイルのrar修復もできる、と。

>>160
>ブロックごとに複合するI/F
既に提供されてる。FFC(長いので略した) もこれを使って実装されてるんだろう

>>166
本体でやったとしても同じ I/F 使うだろうから、大して変わらんのと違うか
むしろプラグイン側で細かな動作(バッファリングなど)を設定出来たら本体の出番は無い気がする

(・∀・)y━･~~~

全然ﾊﾞｰｼﾞｮﾝ来ないわけだが･･･
ｿﾝﾁｮﾙなんか新機軸でもやってるのか？

ｿﾝﾁｮﾙは新たな魔法を考えてる

いよいよ、

仮　　想　　ネ　　ッ　　ト　　ワ　　ー　　ク　　実　　装

ですかね？
もしかしたら年内発動かなー。だとしたら楽しみだなー。
たとえそれがまたとんでもないﾊﾞｸﾞ祭りになったとしても。ｗ

ｶﾞﾝｶﾞﾚそんｔ…いぇ、開発者氏。

いや、普通にAV修正。終了

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

いいこと思いついた。
おまえら俺に仮想ﾈｯﾄの説明しろ。

>>174
仮想アドレスをかませるらしいよ
実際通信してる先をすべてみえなくする

それってPCはどれが仮想でどれが実在かわかってるの？

>>176
それが分かってしまうと、匿名性upの効果は望めないような。


通信は仮想ノードを複数挟んだ形にして行う（偽装？）するけど、
キー情報の取得に関してや保持ノードとしては完全にゴースト化、
って風にしないと、処理が重くなりそうでｲﾔﾝな感じ。

技術的なことはともかく、理屈としては実現可能なんでしょうか？

すくなくともソンチョルでは無理ですな

　　　　/＼＿＿_／ヽ
　　 ／''''''　　　'''''':::::::＼
　 . |（●）,　　　､（●）､.:|
　　|　　 ,,ﾉ(､_, )ヽ､,,　.::::| 村長って誰ですか？
. 　 |　　 ｀-=ﾆ=- '　.:::::::|
　　 ＼　　｀ﾆﾆ´　 .:::::／
　　　／｀ー‐--‐‐―´＼

　　　　/＼＿＿_／ヽ
　　 ／''''''　　　'''''':::::::＼
　 . |（●）,　　　､（●）､.:|
　　|　　 ,,ﾉ(､_, )ヽ､,,　.::::| >>180誤爆　スマソ
. 　 |　　 ｀-=ﾆ=- '　.:::::::|
　　 ＼　　｀ﾆﾆ´　 .:::::／
　　　／｀ー‐--‐‐―´＼

単純に共有専用キャッシュを1種類新たに設けるってのはどうよ。
キャッシュを消すのは膨張していくからやむなくってのが大半だろうから、仕様としては。

*通常のキャッシュシステムとは別の物である。
*ユーザーがこの新キャッシュ用の割り当てサイズを指定可能で常に一定のHDD容量しか使用しない。
*新キャッシュの内容はユーザー側には分からず、SHARE上から任意には消去できない。
*新キャッシュの内容はSHAREネットワーク内のファイル流通を分析して有用かどうかを判断し自動的に調整される。
*とりあえず有用かどうかの条件は以下のようなものと仮定する。
　・通常キャッシュでのヒット率が低い物である。
　・一定数のDL要求のある物で捏造警告の無いもの、もしくは捏造警告の割合の低い物である。
*新キャッシュには極力完全キャッシュとなった物が望ましい。
*この新キャッシュの容量によってダウン枠に影響を与える。

旬なものは今までどおりのキャッシュシステムで落ちてくるし、旬でなくなれば自動的に誰かの倉庫へと保存されるようになる。
流通を監視するから再度通常キャッシュでのヒット率が高くなってくると、倉庫のファイルを消して新たな有用ファイルをキャッシュとして保存するというように自動調整される。
SHARE本体が他の倉庫状況もある程度把握していくことによって、他の倉庫との兼ね合いも考慮して自倉庫の内容も調整されるようにして全体のバランスを取れるようにする。

まだ、考慮すべき部分はあると思うけど、一定の効果は期待できないかな。

speranzaのディスク共有を先に実装しようって事ですな。
cella氏が手こずってる様だから、難しいんじゃないでしょうかね。
まあcella氏がどの程度かよく知りませんが。

speranzaっていうのは知らないけど、難しいのかー。
周りの倉庫の内容を把握するのは、ファイルサーチで発行してるクエリに対する結果を元にすれば範囲を制限出来るし、近隣が類似クラスタの方が倉庫の有効度も上がって良いし。
どういった部分が難しいんだろう。

A70は拡散の割りあいが高くなってる気がしますね。

誰かNextP2Pの管理を引き継いでくれるボランティアはおる？

>>186
何かあったの？

完全キャッシュのファイルの優先順位を高くすると上手い具合に落ちてくる気がする。
(これやらないとブロコンばっかり)
ダウンロード-ステータスのソートは完全キャッシュを考慮してほしいYO。

Share君が完全キャッシュとDL率で適当に判定して勝手DLしてくれるとうれしい。
(不完全キャッシュを蔑ろにするのはまずそうなので１DL枠くらい)

もろに１人から吸ってるよ。IPアドレスもわかるし・・・
光のひとありがとう

提案というか要望です。

ダウンロードリストのファイルのグループ登録機能が欲しいです。
PVとかアニメだと、cedecとか一緒なのに微妙なサイズ違いとかあるから、任意ファイルをグループ化してその内のどれか一つがコンプリートされた場合にグループごとリストから削除とか出来るようにしてほしいです。

そんな違法ファイルに合わせて開発が進んだら
村長が逮捕された場合かなり危険だと思うぞ

test

>>191
例えがアレなだけで違法ファイルに合わせたものでもないと思うが。

落ちそうなんで保守

保守

ダウンロードのところに、最後にキャッシュがそろった時刻が
ほしいです。

あげ

天さんが言ってた数日前に妨害工作の１勢力が新たに判明ってなに？

Share(仮称)質問スレッド Part 20
28 ：天 ◆9Q4BlcCJvM ：04/12/24 14:37:45 ID:3hGUohJT
質問テンプレ(AA除く)以上です。
数日前に妨害工作の１勢力が新たに判明しましたが、
Share(仮称)-Networkではそんなに害は少ないので過敏にならずに放置しときましょう。
ＩＤ には注意が必要です。

↑

>>199
�dです。例の会社のことでしたか。

∩ﾟ∀ﾟ∩age

内容が同じでも異なるファイルだからDOWN、拡散の効率が上がらんのかな？
Aってファイルが欲しくて周りにはA、A'、A"があるのにDownできるのは一つのノードのみ。
だったらA＝A'＝A"としたようなファイル(A)を流したほうが効率よさそうな気がした。
被参照量のでかいものや、A'、A"をもリストに加えればいいって言われそうだな(ﾟ∀。)

意味わからん

確かにわからない

ニホンゴワカリマセーン
イミ？ワカリマセーン

(ﾟ∠ﾟ)ﾆﾎﾝｺﾞﾑｽﾞｶｽｨ

>>202
おじさん達にも分かるようにいってくれ

いや〜、使い始めて7ヶ月、初めてShare自体にキャッシュ総消しされたや。ｗ
しばらくはターボモードで頑張るか。
73bでどれだけキャッシュが消えたのか知らんが、皆、拡散がんがろうぜ。

おうよ
こちらも今ターボ中
拡散〜拡散〜

削除依頼が出来るようにならんのかな？
あぼーん拡散キボンヌ

>>208
以前にキャッシュ全消しバージョンがあったわけだが・・・

ま、何はともあれ拡散がんばろう

>>211
ん、その2回の全消しバージョン以外総消ししたことないし、
その時は確か手動削除だったっしょ？

しかし、フォルダチェック中は重かった…。でも終わったから拡散頑張る。

え・・・と
テスターとユーザーと分割した50バージョンほど前は全自動だったでしょ　　たしか・・・


自分も現在ターボ中
リクエストが溜まる溜まる
でも終わるまで待ってね

だったっけ？
ううむ、dtの時のと記憶がごっちゃになってるんかな。

キャッシュ消えたバージョン覚えてるのでコレだけある
dt40,a1,a26,a73b
今回は仕様じゃなくバグだったみたいだけど

懐かしみつつ過去スレ漁ってみたら、
キャッシュのフォーマット変更バージョンdt40とa26の2回のうち、
a26は自動削除だったみたい。ｺﾞﾒｿ。

ログの中に、「Share a25c で頑張るスレ」
とかあった。
彼等は今、どうしているんだろう…

あらa1は記憶違いだったのか･･･('A`)

同じバージョンの利用者同士しか参加できないShare上会議システムを作る
発言が全てのノードに拡散のような方式で届くようにすればリアルタイム性はないが匿名性は十分確保できるだろう
ダウン速度にしか興味が無くバージョンアップを渋る糞テスターは自動的に排除できる
発言にはハンドルとノード暗号の一部がIDとして付記されて成りすましを防ぐ
作者は乗っ取り不可能な神IDで参加すれば2chよりは意義ある意見交換ができるだろうよ
弱点は荒らすためだけに最新バージョン入れて参加する奴が出てくるであろうことだな
対処としてはメッセージ指定型あぼーんとID指定型あぼーん（期限設定つき）があればいいかな
テーマごとに部屋が作れればなおよし

MXではチャット
nyではBBS
Shareでは･･･

もちろん部屋名と発言とハンドルとIDはまとめて暗号化して下さいね

部屋は部屋名を含むメッセージを受け取った時点で自動生成でいいかな

会議システムか。いいかも

ファイル共有で使用しているIDをトリップとしてハンドルに付加できればなおよろし

相手と仮想セックスが出来ればなおよし

>>224
例のあの機械を思い出してしまったww

Share(仮称) Ver1.0 Alpha 74b ｷﾀ━━━━(ﾟ∀ﾟ)━━ ・・・・・

反応が遅いなｗ

うｐやキャッシュにある音声ファイルをストリーミング配信することはできないだろうか？

最新Verはa75

readme.txt更新部分
禁止事項

本ソフトウェアの販売。
インターネット上以外のメディアでの配布。
リバースエンジニアリング。
改造改編版の配布。
意図的なShareネットワークへの攻撃。

禁止事項に違反した場合、著作権者の了承を必要とせずに、任意の個人または団体が禁止事項についての注意勧告、
場合によっては法的措置を行えるものとします。

ポイント(停止中)

禁止事項として書くのは勝手だけどさ。
上の4つは著作権法に基づく不法行為で、著作権法は親告罪だから
著作権者が訴えないと成立しないけどなぁ。
shareネットワークへの攻撃ってのは、通常のネットワークなら威力業務妨害の適用範囲だが
司法ってのは不法(と当局がみなしている)行為を保護する様にはなってないよ。

村長がこんな法律認識しか持ってなくて大丈夫かねぇ・・・

いや、チョン馬鹿だからチョンらしくていいじゃない。
ほんっと馬鹿。ガキの書く文章だねこりゃ。

Pentium4 2.0GHz以上
って書かれてるけどP2の300以下で使ってるｗ

>>231
まるわかりの串使って投稿するよかマシだなｗ

>>234
君は何か勘違いしてると思うよ。

そうか、スマソかった。

自分の拡散したファイルがコンプリートできる状態にあるかどうか
判る機能がほしいです。

技術的なことはさっぱりですが、イメージとしては
登録したファイルを監視して一定期間発見できないブロック
があるファイルを知らせてくれる感じでしょうか。

拡散する意思があってもUPフォルダから引っ込めてしまうことで
放流主の気付かないところでコンプ不可能なファイルができてしまってる
ケースが多い様に思います。

>237
ダウンロードタブ内、キャッシュ表示をONにして、ステータスを伸ばして見てみ。
たぶん判る・・・のかも　(近所にいないだけかもだけど)

>>238
結構前のバージョンから、自分が放流主であるファイルは、
キャッシュ状態でもファイル状態でも
ダウンロードに登録できなくなってるよ。
トリガ追加までは出来るんだけど。
という訳で、>>237の機能はなにかしらの形で確かに欲しいな。
コンプキャッシュ持ってる人が近くにいると
拡散できないっぽいし、その人のキャッシュが消えれば
実は穴だらけとかだったら困るし…

>>230
ぶらふでしょ。

でもまぁ
「元気な住人が団結して某を叩くのは歓迎」
みたいな感じだあね。

会議システム/チャットルームはRingochで実装されてた記憶があるけど
GUI周りがね大変そうね。

GUIなんてDelphi使ってたら簡単だろ

設計がね。

なんだか予期しないエラーがどうとかって出るのだけど、まだ７４ｂにしといたほうが
いいのだろうか…

ここを作者が見ていると期待しつつ [要望]

今までのPDKの更新では下位互換性が無い為、プラグインが新バージョンのPDKに
対応するまで使えなくなってしまうしプラグイン作者にも過大な負担を強いる事になる
よって仕様上可能であれば下位互換性を残しつつ機能拡張をして貰えたらと思う

>>241
他のソフトではバージョンによるフィルタリングを行えないですね
あとShareを起動していないとメッセージを受け取れないので連続稼動テスター増加のきっかけにもなるかと

>>245
プラグ印関係に手をつける前にやることがあるだろう

>>247
まあ、それは毎度の事なのでぼちぼちと・・・

Wellknown Portの設定を不可（もしくは警告を表示）にしてほしい。

>>249
それくらい自分で調べやうよ・・・。

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は問題なく併用可能だし。できる人がプラグインとして作るのは特に問題ないと思う