「Satoshi Client Block Exchange」を編集中
この編集を取り消せます。
下記の差分を確認して、本当に取り消していいか検証してください。よろしければ変更を保存して取り消しを完了してください。
| 最新版 | 編集中の文章 | ||
| 13行目: | 13行目: | ||
Hello! | Hello! | ||
| − | + | == バッチ継続メカニズム == | |
| + | |||
| + | ノードがブロックインベントリのバッチを送信し終えると、バッチ内の最後のブロックのハッシュが記録されます。[11]ノードがそのフルブロックに対する要求を受信すると、ノードは現在のバッチで完了したことを認識し、最新のブロックハッシュを含む1つのブロックハッシュエントリを持つ特殊な "inv"メッセージを（通常のSendMessageメカニズムを迂回して） 12]遠隔ノードがその "inv"メッセージを受信すると、それはそのブロックを持たないことがわかり、上で説明したようにそのブロックを要求するでしょう。ただし、ブロックを受信して処理する今回は、前のブロックがないことに気付くため、最新のブロックを「孤立した」ブロックとして記録し、最新のブロックからブロックの更新を要求しますギャップを埋めるために孤児[13]の前にブロックまである。これは "getblocks"リクエストとして出され、バッチプロセス全体が繰り返されます。 | ||
| + | |||
| + | しかし、ひねりがあります。次のバッチが終了すると、ブロックを送信するリモートノードは、通常のように最新のブロックハッシュを含む「inv」を送信し、ローカルノードは今回は孤立ブロックマップにこのブロックを既に持っていることに気付くので、ブロックを更新してブロックの更新を直接求める[14]このプロセスは、最新のブロックより前の最後のブロックが受信されるまで続きます。そのブロックの処理の最後に、このブロックを指している孤児が存在し、孤児ブロック（および他の孤児、再帰的に）を処理して、プロセス全体を完了することに気付くでしょう。[15] | ||
==失速の回復 == | ==失速の回復 == | ||
