- amoeba
205 ：[名無し]さん(bin+cue).rar[sage]：2010/09/27(月) 01:01:07 ID:H4JG/IF40 - >>201
別に汎用のデータベースライブラリでいいだろ。sqliteでもnosqlでも。
データベースなんて下手に自前で作るもんじゃない。
>>202
> 元のデータとパリティと合わせて256ブロック中128ブロック揃えば
拡散したノードの半分以上が稼働してなかったり、
キャッシュから消えたらダメってことだよね。
そんなに起きにくいとも思えないのだが。
まあそれは言っても仕方ないし、原理的にどうやっても無限でない以上は無理なわけだけど、
shareで問題なのは、もう復元できないファイルが判別できないので
そういうゴミデータがキャッシュを食い、結果的に復元可能なデータが
キャッシュから追い出されること。
キャッシュから追い出す時は、復元できないデータを優先して追い出す仕組みが
あってほしいものだ。自分が持っているキャッシュの断片それぞれについて
復元できるかどうか定期的にチェックするとか。
現状はamoebaのキャッシュは無限に増えていくようだけど、
本格的に使われだしたらそんな方法をユーザが好むはずがなく、
キャッシュのサイズを一定以下に抑える機能を求められるか、
あくまでつけなければ丸ごとキャッシュを消すようになるはず。
|
- amoeba
206 ：[名無し]さん(bin+cue).rar[sage]：2010/09/27(月) 01:07:51 ID:H4JG/IF40 - > ダウンロード終ってRateの表示が100%越えてるのが、このパリティから
なるほど。
> 沢山並んだファイルが1ブロックしか無い場合が多くて、
> 結果パリティ無しになるのでここが欠けるとダウンロードが始まらない
なんという分析。おまえ頭いいじゃんｗ
>>204
> そして、また罠exeで情報流出祭と。
そういう話でいえば、表示をファイル名と拡張子をわけてほしいな。
なんちゃらかんちゃら.zip .exe
みたいなのが嫌だから。もちろんzipの中にexeが埋め込まれている
ものはどのみち回避できないが、意外とこの最初の段階を防げば
ウィルス感染はかなり減るはず。
PDの場合は拡張子表示はないが、評価システムが結構機能しているから。
amoebaの場合、評価システムもないし、拡張子表示もないと、怖すぎ。
できればshareのように特定の拡張子はダウンロードしない機能があるといい。
まあ、ねつ造ファイル対策はまだ当分先でいいとは思うが
(評価システムを入れるなら早い方がいいけど、評価システムって匿名性の
低下なしに実装するには難しいような気がするし)。
|
- amoeba
208 ：[名無し]さん(bin+cue).rar[sage]：2010/09/27(月) 03:30:33 ID:H4JG/IF40 - >>207
いや、それは俺がなんとなくそう思ってるだけで、ほんとにそうかは知らんw
|
- amoeba
209 ：[名無し]さん(bin+cue).rar[sage]：2010/09/27(月) 03:34:54 ID:H4JG/IF40 - >>202
そのツリー構造って考えたら、トップのブロックが欠落したら、
それ以下のブロックが全部ゴミになるわけだよなぁ。
ちょっち、この作者、考えが足りないんじゃなかろうか。
キャッシュの構造もそうだけど、すべて順調なケースのみを想定してて、
アクシデントが起こることをあまり考慮してない気がする。
|
- amoeba
210 ：[名無し]さん(bin+cue).rar[sage]：2010/09/27(月) 03:38:30 ID:H4JG/IF40 - しかもそのツリー構造ってamoebaの根幹の部分だよな…
|
- amoeba
211 ：[名無し]さん(bin+cue).rar[sage]：2010/09/27(月) 04:13:40 ID:H4JG/IF40 - アップロードやダウンロードのpriorityが終了時に保存されないな。こんなパターンが多すぎ。
いまだ数値が大きいほうが優先されるのか、小さいほうが優先されるのかもわからんし
|
- amoeba
213 ：[名無し]さん(bin+cue).rar[sage]：2010/09/27(月) 06:26:42 ID:H4JG/IF40 - >>212
なるほど。そんなところにひっそり返事があったとは相変わらずシャイだなw
それはそうと、リンクを貼る処理、もう少し効率よくできないものか。
記憶しているノードリストを1個ずつ順に数秒おきにトライしているようだけど
一度に数ノードずつ試せば良いと思うのだが。
ノードリストの順番がどうなってるのか知らないけど、わざわざ接続できる
可能性の低いノードから順にトライしているように見えるのは俺だけだろうか。
なんとなくリング上になってて、一番最後にトライしたものから順に新たに
トライしている気がする。
でもそうなると、起動時には一番古いノードからトライするので、
多分そのノードは古くて繋がらない可能性が高い。
少なくとも起動直後は直前に接続出来ていたノードから順に試すべきだと思うのだが。
|
- amoeba
215 ：[名無し]さん(bin+cue).rar[sage]：2010/09/27(月) 06:45:25 ID:H4JG/IF40 - >>214
あったw
|
- amoeba
217 ：[名無し]さん(bin+cue).rar[sage]：2010/09/27(月) 08:37:48 ID:H4JG/IF40 - >>216
最初の6行は全く無意味だからスルーするとして、
> で、普通のファイルシステム同様、重要データにこそ2重3重の回復手段が
> 必要だろうとは思う。
だからそういう話を最初からしてるのだけどね。
単純に同じデータを複数もつならamoeba自慢のパリティのような構造はいらないだろうに。
amoebaがわざわざパリティを付けてるのは、単純にコピーを複数もつのではなく、
冗長性を最小限にしつつ、信頼性を維持したいわけだろ？
しかしこれまでの話だと根っこの部分は結局は全く同じデータを複数保持するしかないわけで、
それじゃあパリティ云々の仕組みに意味が無いといってる。
また、この辺の作りがどうなってるのかわからないが、DHTでルーティンつをしているってことは、
全く同じデータをもつブロック、つまり全く同じハッシュをもつブロックは、原理的に同じノードに
保持されるんじゃないの？となると単純にコピーを複数のノードに分散して保持するということができない。
まあ、このへんは俺の想像でしかないし、回避しようと思えば方法はあるだろうけど、
木に竹をつないだような形になりエレガントさに欠ける方法になると思うんだよね。
> 今の作りだと葉っぱや枝には回復手段あるのに、
> 幹が放置状態だから。
だから、なんでそうなってるか？まで考えて「amoebaの構造の原理的な欠陥だ」と
言ってるつもりなんだけどねぇ。回避は可能だがそれはamoebaのご自慢の構造を否定するものだ。
|
- amoeba
219 ：[名無し]さん(bin+cue).rar[sage]：2010/09/27(月) 09:16:51 ID:H4JG/IF40 - >>218
> だから、それに対して十分標準的な構成だ、
> 周りの作りで対処する話だろと返したんだが。
まあ、おまえが何も考えておらず、表面的な言葉を並べるだけの
人間であることはよく理解したよ、安心してくれ。
|
- amoeba
221 ：[名無し]さん(bin+cue).rar[sage]：2010/09/27(月) 11:51:23 ID:H4JG/IF40 - >>220
> はいはい、ご高説は結構だから、文句言うなら解決法の1つでも示せっての。
文句は言うだけで価値がある。逆に内容のない精神論のような擁護こそ
百害あって一利なし。まあ自分を善人だとアピールしたい人はいいかもしれないけどね。
要するにおまえみたいなのは利己的な人間なんだろうね。自分に酔ってるわけだ(笑
> パディングデータを通常00を、01,02,03とかとでも変えて、
だからそういうのが泥縄式でエレガントさに欠ける、木に竹を接ぐような方法、
と言ってるのだがねぇ。
そもそも「4つ」という値をどうやってそれが最適か決めるのさ。
4が適切なのか5が適切なのか。
作者はデータに実装に依存しない普遍的なフォーマット云々と自慢げに語ってたじゃん。
4に決めるというのは実装だ。たまたまその時、4が適当だと思ったから、それに決定するわけだ。
気が変わったらまた別の値になるはず。
> 2.ファイル情報についてるkeyはCHKじゃなくする
> バックアップのデータに異なるkeyをつければネットワーク上で
意味がよくわからないが、それでバックアップ同士が同じ
ファイルであることはどこが保証するのだ？
|
- amoeba
223 ：[名無し]さん(bin+cue).rar[sage]：2010/09/27(月) 12:05:17 ID:H4JG/IF40 - で、根本的な欠陥といってるのは、そういう泥縄的に取り繕えるか否かではなく、
基本的な考え方の完成度。
単純化して考え、3階層になっているとする。それぞれ10個のブロックを従えている。
つまり1階層目は1個のブロック、2階層目は10個のブロック、3階層目は100個のブロック。
で、作者はパリティをつけて冗長化しているから、たとえば100個のブロックのうち50個が失われても
大丈夫だと言ってるわけだ。
しかし、2階層目の10個のブロックが復元できなければ100個のブロックは意味を成さないのだから、
実際には2階層目の5個のブロックが失われれば、全体を復元できなくなる。
さらに1階層目の1個のブロックが失われたら、残りの110個のブロックが全て生きていても、
このデータは無味なゴミデータとなる。
これじゃ、100個のブロックをパリティをつけて、50個が失われても復元できるようにしても、
全体の復元性にはたいして意味が無いだろう、と。
この方法を考えるなら、最初から2階層目や1階層目は3階層目より重要度が高いのだから、
生存率が高くなるような方法を考えて置かなければならない。あとから考えるようじゃ、
考えが浅い、考えが足りないと言われてもしかたないだろう、と。
そういうことを言っている。ある意味実装上のバグや不備はあとか直せばいいこと。
しかしこういう基本的なアルゴリズムの部分をきちんと詰めずに見切り発車するのは、
ちょっとね。
|