リモートピアの生存確認とレイテンシーの計測を可能にするBIP-031

2012年5月にリリースされたBitcoin Core 0.6.1から導入されたPeer Serviceレイヤーの拡張で、リモートピアの生存確認と、レイテンシーの測定を可能にするBIP-031↓

bips/bip-0031.mediawiki at master · bitcoin/bips · GitHub

簡単に言うとよくあるping送ってその反応が来るまでの速度を計測する機能をBitcoinのP2Pメッセージにも実装しようというもの。

動機

Bitcoinのユーザーエクスペリエンスを低下するネットワーク関連の問題がいくつかある↓

一部のBitcoinクライアントは、スリープ状態になり警告なしにいつでも実行が停止されるプラットフォームで動作している。これは特に携帯やノートPCでよくある（ふたを閉めるとか）。システムが復帰するとスリープ前のTCP接続は残っているが、IPアドレスが変わっていたり、リモートピアがオフラインになっていたり、他のシステムによりタイムアウトしているなりして正しく機能する状態にないことは充分考えられる。こういう状況が発生した場合、それに気づくまでにしばらく時間がかかることがある。
Satoshiクライアントは大部分がシングルスレッドで、（ブロックチェーンデータのダウンロードなどで）負荷がかかると、ネットワークメッセージに応答するのが非常に遅くなる。これを検出する簡単な方法はなく、リモートピアからのブロードキャストを受動的に待っている場合は特に顕著になる。オーバーロードされたリモートピアを検出し回避する方法は、負荷のバランスとり、より応答性の優れたシステムを提供するのに役立つ。
ブロックチェーンのような大規模なデータ構造をダウンロードする際は、ネットワーク的に近いピアを選択する方が効率的である。現状リモートピアへのレイテンシーを測定するのは難しいので、クライアントは気にせずランダムにピアを選択している。

これら全て、下位互換性のあるプロトコルの変更によって解決することができる。

仕様

verメッセージのプロトコルバージョンが60000より大きい場合、pingメッセージにはnonceと呼ばれるuint64フィールドが含まれている必要がある。pingメッセージを送信しているピアはnonceにランダムな値を設定し、受信者は（受け取ったnonceをセットした）単一のuint64フィールドを含む新しいpongメッセージをエコーバックする。

こうすることでクライアントはpingメッセージを送りpongメッセージが返ってくるまでの時間を計測することができる。クライアントが最初のpongメッセージを受け取る前に、pingメッセージを２つ送っている場合、その応答がどちらのpingに対するものかはnonceで判断することができる。クライアントが重複してpingを送らない場合は、nonceの値は0で良い。