Share TESTER_WORKS build1.1

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

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

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

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

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

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

本スレその他、大部分のスレが機能していないので立てました。

今までに書いた要望
1.UDPバージョンに切り替える際、pは要らないのではないか。
2.推奨共通クラスタワードの再制定
理由
1.今のただ騒ぐだけの「ユーザー」が、UDP接続の地道なテストの足を引っ張る事が容易に想像できるので、
既存のShareネットワークは残して置く方が得策ではないかと思うのです。
開発者さんがそういうネットワークの存在が気持ち悪いのは分かるんですけど…。
ちょうどny1とny2の様な関係ですね。
2.クラスタ化がさらに強固になったようですので、共通クラスタワードを設定することで
解消される不満も多いのではないかと思うのですが。

>>1
shareは仮称ではありません

>>4
あらら、ｽﾐﾏｾﾝ。
やっぱり天さんに立ててもらえば良かったかなぁ。

ܷܵܶ
例に寄って例のごとく Share 使ってます

>>1
取りあえず乙。

Shareに限らず、VIPの連中がなだれ込んできてから板が全体的にグズグズだからなぁ…。

>>1
取り敢えずw　乙。
俺もUDPに切り替えるタイミングで現在のネットワークは切り離して残したほうがいいと思うなぁ。
1年かかってここまでになったのをただ捨てたんじゃ、ちょっと勿体無いと思う。

それにしても、UDPによる大規模P2Pネットワークなんて今までに無いよね？
うまくいってもいかなくても応援したいと思う。

　　　　　　､-'''"´￣￣｀"''''-､
　　　　　／ ／　;;;;;;;;;;;;; 　＼ ＼⌒⌒
　　　　/　..::;;● ;;;;;;;;;;;;;, ●;;;;;;;;;::ヽ　　^^
　　　　|. .::;;;;;;;;;;;（__人__）;;;;;;;;;;;;;;;;::.|
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　 :::::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;::::
　　　　　　 :::::::;;;;;;;;;;;;;;;;;;;;;;;;;　　　　　
　　　 　　　 ::::::::::::::::∧＿∧　　　そうやってなんでも
　　　　　　　　::::::::: (　::;;;;;;;;:)　　　　　　VIPのせいにしてりゃいいさ…
　 　 　　　　　 _..　 /⌒:::;;;;;ヽ
-― ―'ー'-''―-''/ / ::;;;;;;;;:| |―'''ー'-''――'｀'
　,, 　'''' .　　'''''　と./ゝ_;_;_ノヽつ　　　､､,　''" 　　　　　　　それがVIPクオリティ…
　　　　,,, ''　 ,,,　　　　::;;;;;;;;;:::　,,　　''''' 　,,,, 　　　　　　 http://ex7.2ch.net/news4vip

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

あら建っちゃったんですか
>>1 乙です。
今のバカな流れはVIPですか・・・・

本スレではudp不要論も出てますね
前スレを含めてudp通信を焚き付けた私ですが（汗）、
大部分の人が udp 通信によるさらなる高速化と壁突破（うまくすればポート0でもUp/Down が可能）
の可能性があることを解って無いのかなぁ？
パケット数が減る分、実データの時間量が増えるのに

>8
udp を入れるとしても TCP/IP は残しておくと予想してます。
TCP 使う方が速度が遅くてもデータ自体の伝送に信頼がもてますから、
多重ダウンロード系に udp を重点で割り当てて速度を上げて
整合性エラー等が出るデータの一部等や不安定ノードと伝送経路　だとTCP が確実でしょうし。

それと 2005/03 号 NETWORK MAGAZINE p.118 に少しだけ
「分散ハッシュ」について説明書きが載ってます。（まぁガイシュツな内容だけど）
ぶっちゃけ　Winny のクラスタ繋がりの核心(ry な参照コアでしょうね。　ﾎﾞｿｯ

UP 絞り対策として　（�@絞りノード　・　�A欲しいファイル持ってるノード）
�A→Download─→�@　
　リクエストから通常Download が開始

�A←Feedback←─�@
　ファイルなどからフィードバックデータポインタ算出
　Download DATA の一部と共に実UP回線量と転送データ値を戻す
　UP が適正値ならばそのまま�AのノードはDownload 速度を維持。
　※チェック中は回線維持、アクションを起すのは次回ポインタから

�A→Download････→�@
　Download対し�@のデータから算出したUP総枠送信量にフィードバックが異様に遅い（低品質回線とみなし）
　不適切速度なら次の算出ポインタから　
　フィードバックされてきた速度にUPloadをあわせる
　�Aは空いた帯域を他のまともな速度のノードへ集中させる。
（その集中させたノードは大きめの帯域をDownload出来る事になる）

　※�@フィードバック速度が上がれば（速度品質が上昇する）その分�Aが他と切れたとき補完する

っていう考え方も出来るよ
これなら不公平感も減るのではないかな

>>12
非対称の回線をきちんと判定できるならUPを絞る実害が明白だから
いいアイデアだと思います
あと、DL速度や枠数をUPファイル数やキャッシュ量で加減すると捏造が
蔓延するのでNGですが歯抜け対策としてUPフォルダに追加しない
コンプリキャッシュ削除や拡散キャッシュ削除に対するペナルティも
考えないといけませんね

>>13
非対称の回線(ADSLとか)だと
>12 のアイデアの
�A→Download････→�@
　Download対し�@のデータから算出したUP総枠送信量にフィードバックが異様に遅い（低品質回線とみなし）
　不適切速度なら次の算出ポインタから　
　フィードバックされてきた速度にUPloadをあわせる

で�Aで下げられた速度で�@のDownload帯域が下がるからその分他のノードへDown枠を充てる
DSLは光に比べてどうしても遅いので多重ダウンか他の物で枠が埋められるんじゃないかな
多重ダウンの時の「フィードバックデータポインタ算出」はファイル以外の要素も入れれば（通信速度など）
他とバッティングしないからUP 速度分の帯域でダウン枠が複数作れる

光でも結局枠が増えてUP絞りに対処出来ないんじゃないか？　となるというと
UP 速度と同等速度のDown 枠が大量に出来る事になるけど
現実問題として、んな大量のコネクションには機器が対応できません。
というか今って最大10枠だっけ？
光でUP絞ってる速度で10枠作られてもねぇ

�Aからみれば　�@から上がってくる速度と同等クラスの速度で�@に渡すから
自業自得と藁うか哀れみの目で眺められるんじゃないかな

だね
この考えの最大の特徴は、ダウン目的で速度制限解除のクラックが出来にくいという所
ダウン元がUP速度を制御するので自分の所をクラックしても速度は出せない。

フィードバック情報を偽装するにもダウン元も同条件で同じ算出ポインタを計算して
持っているので、同じ位置から始まるフィードバックDATAを作るのは容易ではない。

来るべきUDPに備え保守。

UDPになったらβですかね。

仮想ネット実験ぐらいでβにするのかと思ってるんだけど、どうなんだろう
まっ　それは兎も角

クラスタ繋がりの技術には「分散ハッシュ」が良いような事が某月刊誌で解説されてる
どんなものなのか、それとなく師匠に尋ねたら・・・・内容が難し過ぎて半分も判らなかったよぉ

hoshu

iSCSI の形式は簡単に書けば
IP(ｲﾝﾀｰﾈｯﾄﾌﾟﾛﾄｺﾙ) にSCSIコマンドと冗長化させたデータをカプセル化してNIC 等から伝送するというもので
数年前に仕様が確定し企業や大学のSUNに使われ始めている遠隔地を結ぶネットワークストレージと
思ってくれて良いでしょう。

データ部分はRCRでもなんでも良いのでリカバリレコードなり付けてカプセル化すれば復元率はあがるとおもわれる。
（今のShareでもデータは圧縮して送っているみたいだから大丈夫では？
　本スレで出たUDPでは破損キャッシュが溢れないかという懸念は
　転送アーカイブデータを正常に伸張できないとキャッシュファイルとして残らないので
　破損する様な回線を通る時はTCPに切り替えるか、自動でリカバリレコードを大きめに
　自動変動でとるかをすれば、どうって事ないように思える）

利点：通常は高速専用線を使うが近年の整備で普通のISPで使えるようになり運用しているようなので
　　通信パターンのマッチングで壁は今はISP レベルでの規制を掛ける事ができない。
　　やれん事は無いかもしれないが・・・・規制する側はすごい負荷だろう

iSCSIの負荷が高いと言われる所以は、開発時ファイバーチャンネルタイプの高速ストレージの伝送を
無理やりカプセル化してギガビットクラスの専用回線に流し、しかも
SCSIコマンドの処理も（SCSI H/A は専用のチップで処理をするのでCPU負荷が低い）NIC とDriver で
ソフトウェアレベルでやっていたからServer が過負荷気味になっていたということらしい。
その辺の開発系は詳しくないので興味ある人はググって下さい。

一般ISPの光WAN　でやりとりするぐらいのP2Pでは今とそんなに変わらないかも。
UDP　は TCP に比べてデータをチェックする為の往復パケット数が少ないので単位時間内の
データ量を増やせる事ができ、それはデータをやり取りする時間がより少ない（速い）事を意味する。

詳しい人がいたら補完よろ　です

・・・・仕事に戻るか　orz　　書類の〆きりが

訂正　SUN → SAN

研究室レベルとはいえ、テラビット通信の実用技術が確立され始めているので
企業インフラで高速型iSCSI 型SAN は今後増える一方で
UDPに応用とはいえパターンによるパケット遮断だけをされると
これら企業通信も遮断される可能性が大きい為うかつに壁ソフトに組み込めない

まぁ　一案でこういう物もあるよというお話でした。

UDPだと投げっ放しなんですよね。
送信側が全ブロック送信を終えたのに、受信側には全て届かなかった場合の再送要求がどうなるのかなと…。
その辺は全てアプリケーション側で決めないとならない様なので、作者さんの腕次第、ということなんでしょうか。

137氏の簡単な発言がプラグインスレであったけど、UDP でのデータ往復実験が裏で行われているっぽい
データ化けとか未到達/未リターン　なら実装しないでしょうな
今のクラックに対して新バーをすぐ出してこないとこ見る限り、検証中で動けないのだろう
実装してきたら何か手ごたえがあったのではと、

保守ついでに。

MARIEスレに神来る？
並行してテスト出来ればいいですね。

保守

転送過程を見せるから寸止めが出来てしまう。あと放流者が追加しないと再Upされないので・・・
アップロードタブをなくし、Linkキーの歯抜け状況を定期的に検索し欠落ブロックを自動的に再拡散するようにする
消すのなら、更に送ろう拡散キャッシュ・・・ｲﾏｲﾁ

捏造蔓延ソリューションで閃いた・・・
余った帯域を利用してダミー転送を発生させる。表示・ヘッダはShare,diffuseに偽装する

　

'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`'⌒`
MARIEの開発引き継ぎは確かに面白そうな試みだね…。
まぁ別な何かがメインストリームになったとしても、それぞれを上手く
使い分けるだけだから全く問題はないけど…。
個人的にはct1から村長の実験につきあっているから、Shareを優先する
けどね…。
歯抜けも使いにくさもeMuleに比べれば(ry
､＿,､＿○､＿,､＿,､＿,､＿,､＿,､＿,､＿,､＿,､＿,､＿,､＿,､＿,､＿,､＿,､＿,､＿,､
　　。 O
(´-｀).

|-`).｡oO(保守したら秒まで同時…)

　

UDPでの速度向上が伺えると。
でもUDPとTCPでの速度の違いの原理がいまいちわからないな・・・・・・・
パケット送信のルールの違いから来るの？

>31
TCPはデータが正確に届くかを確認するために、受け取ったかの確認の処理とかが入って
その分だけパケットを多く送る必要がある、もしパケットが届かなかったらリトライ等の処理をするから
速度が少し落ちる。

UDPは、データを送るだけでそれがちゃんと届いたかまでは関知しない。

なるほど。だからUDPは速度は速いが転送ファイルの完全性や安全性にTCPより疑問が残るからそれだけに依存できないわけか

UDP版はShare2にしてTCP板とは分けて平行開発したほうがいい気がする

ところで

＞歯抜けの原因は別にあるよ。
＞テストデータで実験してみたけど拡散終了直後でも歯抜けになる。
＞拡散のバグか葱によるノードの接続の分断じゃないだろうか。
＞直後でも歯抜けになるんでクオータ説には否定的な結果になった。

って書き込みを見たんだけど本当なのかな？
誰か詳しい検証きぼんぬ

>>34
そのためにDiffusionProCloneが手放せないのですよ
DiffsionPro使用不可能にするならその前に拡散UPの最適化をするべきだった
プラグイン作者の引退は大いに悔やまれる

>>35
まあ面倒になった事は事実だが、ここは一つ前向きに考えようよ

2次拡散を考慮にいれなければ短期間に連続して拡散うｐすると比較的同じノードに
キャッシュが集まってしまいそのノードがキャッシュを消す（自動or故意）若しくは
オフラインになった場合やキャッシュ保持ノードがオンラインになる日時が短い場合など
歯抜けになりやすくなる（かもしれない）
よって間を空けて拡散して様々な環境のノードに分散した方がキャッシュの寿命が
のびる（かもしれない）

と考えれば少しは納得がいくかもしれない

でもshareのファイルキャッシュが消えるのがいくらなんでも早すぎるような気がするんだよなぁ
これは歯抜け以前にshareの機能の一つ、古いキャッシュ自動的に消しちゃいますよ機能によるんだろうか・・・・・
たまにインフォに出るんだよ。未使用キャッシュ削除しましたって・・・・
それじゃ拡散の意味も薄れてしまうような気が・・・・・

うｐファイルを外して未使用削除ボタンを押すとキャッシュが消えるね
拡散で受け取って一度も参照されないファイルが未使用って事になるのかな
でも自動で消えるのは古いファイルからのはずだったと思うんだがな

『寸止め捏造 & 歯抜けファイルの一掃とクラックバージョンコロニーの有効利用』

　Colony Old Crack Version : 新しい仕様に反対する勢力の居残り　以降 Ｃ と呼称
　Present Crack Version : 最新版だが仮想現在におけるクラックされたもの　Ｐ と呼称
　Next Version : 次バージョン　Ｎ-(n) と呼称（実験を行う旨の流れに関して開発者コメントを発表）
　Destroy Version 1 : Ｎ-1以前をターゲット A25p UP0 同等タイプ　以後 Ｄ1　と呼称
　Destroy Version 2 : Ｎ-1以前をターゲット A25p UP0 IP 丸見え同等タイプ　以後 Ｄ2　と呼称

　Ｎ- ：[仕様]
　　[Key]
　　完全ファイル/キャッシュ　のみ他のノードとキーを受け渡しする事ができる。
　　初期拡散アップロード中の物はキー情報を送らない、送り終わった(Empty)時点でキー放出。

　　[Option]
　　最終拡散アップロード完了時刻が Empty になっていない物で
　　一定期間Complete しないとダウンロード登録とDB系情報 と未完全キャッシュを消すオプション追加
　　最低デフォルト設定：１週間

　　[Destroy]
　　Ｎ-1 放流日設定以前のCompleteしていない最終ブロック読み込み時刻のものでEmptyでは無いキャッシュ自動削除
　　を生存期間設定の行われていない初期起動では最低デフォルト設定の１週間以上経過している不良キャッシュを自動抹消

　　[Diffuse]
　　最終拡散アップロード完了時刻が既に Empty になっているものを２度以降拡散する場合は
　　Request がある場合に限り周りの歯抜け部分のみ補完ＵＰ　キーの拡散も行う。
　　Request が無い場合は拡散アップロードから自動除外（需要が無いかもしれんがUPフォルダに入れとけ）

　Ｎ-2以降 ：[仕様]
　　Ｎ-1　より前のバージョンへはＵＰを一切しない、 Ｃ と Ｐ の切り離し

●擬似開発終了とクラック版の存在におけるネットワーク維持が可能か？　のシュミレート
　Ｐを開発終了版と位置付け、Ｃノードを観察。
　１週間後をUP0 クラックの開発登場期間の半年という設定での加速試験で
　UP0 ダウン枠制限解除のDOM 待望　Ｄ1　を投入。

　維持できてるなら、その2週間後に、これまた待望のIP 全晒し版　Ｄ2　を投入。
　Ｃ　がどれぐらいの期間生き残るかを見る。

　維持できた場合→　少々のUP0 が作られた所でShare は生き残るという事で Ｃ は放置
　崩壊死亡消滅→　共有P2P でUP 0 や IP 駄々漏れなクラックの存在はやっぱりダメね　と認識が確定する。

というような流れも、もうつまらないので、何か新しい展開を待ってますよShare開発者さん

　そっくりそのまま A25p の時でUP0が出回ると小規模ネットワークがどうなるのか一旦答えは出ているのにくり返さないと理解できないのだろうか？

ダウンしたいだけと抗議行動で古いのにいついて群がる事や捏造流す行為は
今まで切られてるだけなんだがなぁ
まぁそれを知ってて誘い込んでいる人が暗躍してるみたいなので直接止める行動には出て無い

クエリ発行の廃止でキーの流通が悪くなったのは体感できます。
現在の詳細なキー流通の仕組みと、廃止の意図が分からないので何とも
いえませんが、以下のようにしてキー流通を促すのはどうでしょう?

既存のSearch接続を使うか新たにSearch接続を開始し
お互いのキーを出し合います。
一方は古いキーの中からリモートブロックがコンプリートしているもの。
もう一方は更新日の新しいもの。(両者で半々に混ぜてもいいけど)
キー情報を交換したら各自適当に処理。

キーブロードキャストっていうのと被る部分もあるかもしれないけど、
古いがコンプしているキーのみ残すことによって歯抜けのキーがいつまでも
ネットワークに流れ続けることを抑制できるような気がします。

とにかくキーの流れをうまく制御できれば、上で言われているように
歯抜けとかましになるのではないかと。

ﾎｽ

ﾃｽ

shareの古いキャッシュを消す機能の削除期限をもっと遅らせれば流れるのが早すぎなくなると思う。
たしかにただ単に延ばすだけだと歯抜けが飛び交うネットワークになっちゃうと思うけど・・・・・
でもそれを防止するために完全キャッシュで拡散しきってるファイルまで消えちゃうのは惜しいかなって・・・・

危ないところだった…

ないすガード

天さんは浮気中

別に良いんじゃない？こっちに縛られる理由はないし。

質スレには定期的に書き込んでます。
共有概念のP2Pを合法的に応援してるスタンスは崩してませんよ。
ここ数日は某板(ハゲスレ)で検索班に名無しで参加しています。
それなりの人数がShareスレからハゲスレに行ってそうです

ハードゲイスレ？

ﾆｭｰ速の児ポ販売公務員の祭りスレだろ

>>31
TCPは輻輳を検知すると速度を下げる譲り合いのプロトコルなので、
回線的に余裕があっても速度が出ないことは多々あります。
一応Window Sizeとかパラメータをいじれば多少パフォーマンスは上げられますね。

UDPはフィードバックなんぞかけない送りっぱなしの保証無しプロトコル。
相手にデータが届いたかなんて気にしません。
そのため音声通信など、ちょっとデータがロスしようがかまわないアプリで使われますが、
データ通信では保証機構なんてものを自前で作らないといけないのでかなり手間。
下手したらTCP以下になります。

UDPだからファイヤウォールを越えられるなんてことはないし、(越えられるのは設定がヘボ)
ACKパケットがいらないということもない(信頼性を保証するため必要)
ACKがほとんどいらない?or低信頼通信上での分散データ受信プロトコル?でも考えついたら
かなりいけるかもしれないけど、TCPの替わりに使おうなんて考えじゃ大した進歩は望めないね。

>>49
漏れ俺も初代スレから行ってる（・∀・）

起動時にShare.exeをロックしてファイルのサイズとハッシュを計算して通信パケットに内蔵させるようにする
それ以降のバージョンでは旧版のファイルサイズとハッシュを内部に保持していて、バージョンと一致しないデータを送ってくるノードはエラー扱いとする
判断するのが上位バージョンの他ノードなので根本的にクラックを無意味に出来ると思うのですがいかが？
同一バージョンでコロニーを作ることは可能ですがそれくらいは許してあげますか

test

>>54
起動時にShare.exeをオープンする部分を探して、
別ののShare.exeを開くように変更すればクラック可能のような気がするが

>>56
すげー

拡散キャッシュサイズでダウン枠が決まるようにしないと全消しは防げない

ﾎｼ

ﾆﾅﾚ

ﾅｶｯﾀ

拡散などで送り込まれたキーのDBを新設して未知のキーを見つけたら他ノードへ
積極的にブロードキャストしてキー情報の流通と検索性の向上をはかるべき

キャッシュをやりとりしたらすぐにクォータで消されてしまうのでキー情報のみの拡散も必要では?

死守

よくやった。俺がバックパスからロングシュート決めてやるから安心しろ

>>62
現状ではDBを増やすだけで、パフォーマンスが急激に落ちる。
そこが改善されなければ、キーの流通は望めないだろう。

diffusio pro cloneで合計３回拡散して漸くコンプ出来た。
diffusion pro clone なし　　13/119
diffusion pro clone １回目　　59/119
diffusion pro clone ２回目　　118/119 から　１時間後に119/119

『キャッシュ自己削除と捏造警告』

　正常ファイルを手動で消させにくくさせるには？　の1案

　・他のノードが発行している捏造警告物はこれまでの通常操作でそのまま消せる

　・捏造警告の出ていないファイル物キャッシュを自己作業で（本体やプラグイン機能から）消す場合
　　消すと同時に DB に捏造警告情報を加える（一定期間越さないと捏造警告付きDB は削除できない仕様にもする）
　　周りに捏造警告付きキー情報を送る
　　DB 捏造警告を出しているノードは対象物の断片キャッシュを少しでも所持しているノードからはダウンロード出来ない。
　　従来の「捏造警告」発行機能は条件そのまま（周りに知らせるだけ）

　[利点]
　　クラスタで固まっている他のノードから続いて落とせなくなるので消し厨への牽制
　　従来の捏造警告さえ他のノードから受け取っていれば捏造物は気にせず消せる。

　[捏造警告付きDB について]
　　わざわざ手動で完全キャッシュを消すという行為は、
　　その者には、すなわち「捏造なり不要な消すべきキャッシュである」と考えられる。
　　ならば不用なキャッシュを持っているノードはその者には不良キャッシュ保持ノードと見る事ができる為、
　　その不良ノードは隔離されるべき。

　（裏を返して半分本音）
　　消し厨ウザイ、　自己消しやって捏造警告出すなら繋がるな！
　　という事で　実際に隔離されるのは消す側

・アーカイブ類で中のファイル名やファイル情報の誤りを訂正して再度アーカイブ化すると
　ハッシュが変わるので元ファイルが不要となる場合
・偽名動画を正規名で再放流する際DBとキャッシュを削除する場合

は、いかが

diffuse upのクラスタって考慮してるのかえ？
ここが疑問。　オイラはエロ排除してるけど、エロクラスタにばら撒かれても困るだけ。

>>67君の魂の叫び声に共感

>69
クラスタ繋がりがそれなりに効いているなら保持してる有効ノードは
同好の士が集まってるだろうから　多少は効いてるのではないかい？

Linkキャッシュのネットワークでの欠落ブロックの自動アップロードを実装した上で
Completeになって変換完了したファイルを自動的にLinkキャッシュとして登録するようにする
こうすれば自動的にキャッシュが消滅して直接接続でアップすることは無くなる
要はダウンフォルダをサブフォルダ込みでアップロードフォルダにしてしまうということ

変換完了したキャッシュがおそらく消されまくっているのはHDD容量の問題とCompleteキャッシュを直接アップしてしまうからであろう
キャッシュを自動削除して拡散でのみアップするようにすれば容量も節約できるし匿名性が向上するので削除頻度が下がると思われる

Share 開発者さんへ

Share を取り巻く現状の動向で
今回のヤフーオークションの　Share(仮称) 情報と本体売り(その他モロモロ)詐欺の一件では
Share そのものを巻き込む恐れは低下したように思われます。
あってもネタ的な話題か(落札者側へのxxxxぐらい)と
『禁止事項』項目を出している事で世間へ一定のスタンスは取れている感じです。

が、今回のハゲ詐欺で『禁止事項』部分は公表時期とバージョン違いから実はあまり関係が無いし（笑

Share 内で流れている今回のサイトのミラーに入っている個人写真などは
その詐欺を行っていた当人がセキュリティも一切存在しないうえにインターネットで繋いでいた事から
「個人情報不正流出」よりも「公開情報から取得した不正を行っていた状況証拠の保全」とした立場
で扱えるでしょう。
詐欺やってた当人もそれなりの処罰なり世間様の白い目に晒されたのですし？
もうShare 的には放置で良いのでは

『個人情報保護法』全面施行前で良かったですね。
怒涛のバージョン出しを待っておきます。
見ている事を期待してカキコ