「Bitcoin Core 0.11 (ch 3): Initialization and Startup」の版間の差分
細 (1版 をインポートしました) |
|||
(2人の利用者による、間の2版が非表示) | |||
1行目: | 1行目: | ||
− | + | このページでは、起動と初期化を管理するBitcoin Coreコードについて説明します。 | |
− | == | + | ==プログラムエントリポイント== |
− | + | プログラムのエントリポイントは<u> bitcoind.cpp </u>にあります。 | |
− | + | main()はコードの3行です: | |
− | * | + | * SetupEnvironment()(これはプログラムのロケールを設定します) |
− | * | + | *信号ハンドラを接続する |
− | * | + | * AppInit()(この関数はプログラムの寿命を延ばす) |
− | + | AppInit:これは<u> bitcoind.cpp </u>の近くにあります。 | |
− | * | + | *コマンドラインを解析する |
− | * | + | *データディレクトリを開きます。 |
− | * | + | *設定ファイルを読み込みます |
− | * | + | *プロセスをフォークします(デーモンとして実行している場合) |
− | * | + | *コントロールを<u> init.cpp </u>にあるAppInit2()に渡します。 |
− | == | + | ==初期化ステップ(<u> init.cpp </u>)== |
− | + | AppInit2()はビットコインシステムを初期化します。 | |
− | + | これには約800行のコードが含まれており、12段階に分かれています。 | |
− | + | 各ステップが始まる場所は、コードに文書化されています。 <u> Init.cpp </u>にはファイルの先頭にいくつかの関数がありますが、大部分はAppInit2()で構成されています。 | |
− | |||
− | |||
+ | 次の表は、手順をまとめたものです。 | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
− | ! | + | ! 初期化<br>ステップ !! 簡単な説明 !! 詳細 |
|- | |- | ||
− | | 1 || | + | | 1 || OS固有のセットアップタスク || これらの作業は特に興味深いものではありません。<br>詳細は、コードを参照してください。 |
|- | |- | ||
− | | 2 || | + | | 2 || パラメータの相互作用 || 特定のコマンドラインオプションでは、特定の方法で他のオプションを設定する必要があります。<br>たとえば、-zapwallettxesは-rescanを意味します。したがって、コードは-rescanフラグ= trueを設定します(まだ存在していない場合)。 |
|- | |- | ||
− | | 3 || | + | | 3 || 内部フラグ / <br>パラメータ健全性チェック || 特定のパラメータのグローバル変数を設定します。<br>財布については、取引料金レベルを正当性をチェックします(あなたの手数料がリレー[エラー]の資格を得るのに十分高いが、不当に高い[警告]ではないことを確認します)。 |
|- | |- | ||
− | | 4 || | + | | 4 || アプリケーション初期化。 / RPCサーバー || |
− | + | データディレクトリをロックします。 (できない場合は、エラーを出力して終了してください。)<br> | |
− | + | スクリプトチェックエンジン用のXスレッドを生成する。 (デフォルト= 0、使用可能なすべてのプロセッサを使用することを意味し、boost :: thread :: hardware_concurrency)。<br> | |
− | + | "ウォームアップ"モードでRPCサーバーを起動します。 | |
|- | |- | ||
− | | 5 || | + | | 5 || ウォレット・データベースの整合性の確認 || ウォレットが有効になっている場合は、開こうとします。<br> |
− | + | ウォレットが破損していることがわかっている場合(-salvagewallet)、パスワードの回復を試みます。 | |
|- | |- | ||
− | | 6 || | + | | 6 || ネットワーク初期化 || |
− | + | ノードは特定の信号を登録する。<br> | |
− | + | ユーザーが特定のネットワーク(ip4、ip6、tor)のピアとのみ対話したいかどうかを確認します。<br> | |
− | + | オニオンルーティング(tor)を使用するかどうかをチェックします。<br> | |
− | + | ユーザーが特定のピアをホワイトリストに登録するかどうかを確認します。<br> | |
− | + | ビットコインポートでリスンしようとします(失敗時に終了します)。<br> | |
− | + | ユーザーが接続をシードする特定のピアを指定した場合は、接続を試みます。 | |
|- | |- | ||
− | | 7 || | + | | 7 || ブロックチェーンをロードします。 || |
− | + | ブロックチェーンをメモリにロードし、UTXOキャッシュを初期化します。<br> | |
<br> | <br> | ||
− | <u> | + | <u>キャッシュサイズを計算します。</u><br> |
− | + | 3つの特定のキャッシュに分割された合計キャッシュサイズがあります。<br> | |
− | + | デフォルトの合計キャッシュサイズ= 100MB(最大:4GB、最小:4MB)。<br> | |
− | + | 1)ブロックチェーンキャッシュ:合計キャッシュの1/8ですが、2MBを超えてはいけません。<br> | |
− | + | 2)UTXOデータベース・キャッシュ:残りのキャッシュ・スペースの25〜50%。 これはLevelDBキャッシュです。<br> | |
− | + | これは、LevelDBデータの圧縮されていないブロックを格納し、LevelDBによって管理されます。[http://leveldb.googlecode.com/git-history/1.17/doc/index.html the LevelDB documentation.]<br> | |
− | + | 3)UTXOインメモリキャッシュ:残りのキャッシュスペースの半分。<br> | |
− | + | このキャッシュサイズは、cacheCoinsオブジェクト(CoinsViewCacheの保護されたメンバー)のサイズを定義します。<br> | |
− | + | TODO:このステートメントが正しいことを確認してください... <br> | |
<br> | <br> | ||
− | <u> | + | <u>ブロックチェーンをmapBlockIndexにロードします。</u><br> |
− | + | 「ブロックチェイン」とは、ブロックツリー全体(アクティブチェーン内のブロックだけでなく、すべての既知のブロック)を意味します。<br> | |
− | + | メモリにロードされるのはブロックに関するメタデータを含むCBlockIndexオブジェクトです。<br> | |
− | + | 最後の288ブロック(VerifyDB)を検証します。<br> | |
− | + | 注意:プログラムはこの時点までに起動から1秒未満を要します。 このステップには約10〜20秒かかります。<br> | |
<br> | <br> | ||
− | <u> | + | <u>UTXOセット。</u><br> |
− | + | UTXOセットはメモリにロードされません。 代わりに、コインがデータベースからアクセスされるときにキャッシュがいっぱいになります。<br> | |
− | + | 2015年5月現在、UTXOセット全体をメモリに格納するには約3.6 GBが必要です。<br> | |
− | + | 2016年1月現在、ディスク上の圧縮データは約1.2 GBです。 | |
|- | |- | ||
− | | 8 || | + | | 8 || ウォレットをロードします。 || プログラムが初めて実行された場合は、ウォレットが作成され、最初のキー(アドレス)が与えられます。 |
|- | |- | ||
− | | 9 || | + | | 9 || Datadirのメンテナンス || ユーザーがブロックプルーニングを行っている場合は、NODE_NETWORKの設定を解除し、プルーニング機能を呼び出します。 |
|- | |- | ||
− | | 10 || | + | | 10 || インポートブロック || 現在有効なチェーンとして接続されていないブロックチェーンデータベースのチェーンをスキャンします。 |
|- | |- | ||
− | | 11 || | + | | 11 || 開始ノード /<br>RPCサーバー || |
− | + | net.cppでStartNodeを呼び出します。<br> | |
− | + | これは、プログラムのメインスレッドであるThreadProcessMessageを含むネットワーキングスレッドグループを起動します(下記参照)。 <br> | |
− | + | RPCサーバーを "ウォームアップ"モードから通常モードに移行します。 | |
|- | |- | ||
− | | 12 || | + | | 12 || 終了 |
|} | |} | ||
− | + | AppInit2が終了すると、<u> bitcoind.cpp </u>のAppInit()に戻ります。 | |
− | |||
− | |||
− | + | そこで、コードのトップレベルスレッドは、WaitForShutdown()という関数で無期限にループします。 2秒間スリープ状態になり、ユーザーがctrl-Cを押したかどうかを確認します。 その場合は、<u> init.cpp </u>でShutdown()を呼び出します。 | |
− | + | シャットダウン()は、RPCサーバーをシャットダウンし、ノードを停止し、シグナルハンドラの登録を解除し、プログラムが完了します。 | |
− | + | ==キャッシュサイズ== | |
− | + | ステップ7は、キャッシュサイズを初期化した。手順7で考えられる3つのキャッシュがあります.2つはLevelDBデータベースキャッシュであり、もう1つはコインキャッシュであり、そのサイズは<u> main.cpp </u>のフラッシュコードによって管理されます。 | |
− | + | ユーザーは、-dbcacheを使用して合計キャッシュ・サイズを割り当てることができます。ユーザーは、特定の各キャッシュに割り当てるスペースを選択して選択することはできません。デフォルトの合計キャッシュサイズ= 100MB(最大:4GB、最小:4MB)。 | |
− | + | '' '1)ブロックインデックスキャッシュ' '' | |
− | + | このキャッシュには、/ block / index LevelDBデータの圧縮されていないチャンクが保存され、[http://leveldb.googlecode.com/git-history/1.17/doc/index.html LevelDBのドキュメント]に記載されているように、LevelDBによって管理されます。 br> | |
+ | ユーザーが完全なトランザクションインデックス(-txindex = 1)を有効にした場合、合計キャッシュサイズの1/8までになります。 -txindexが有効でない場合は、2 MiBだけが必要です。 | ||
− | |||
− | + | '' '2)UTXOデータベースキャッシュ' '' | |
− | + | これは、/ chainstateデータベースのLevelDBキャッシュです。 | |
+ | このキャッシュは、合計キャッシュ・サイズに応じて、残りのキャッシュ・スペースの25〜50%に割り振られます。 | ||
− | |||
− | + | '' '3)UTXOインメモリキャッシュ' '' | |
− | + | これは<u> main.cpp </u>コードで管理されるコインキャッシュです。 (FlushStateToDiskおよび関連する関数を参照) | |
− | + | 変数(nCoinsCache)は、<u> main.h </u>のexternとして宣言されています。 <u> main.cpp </u>には、5000 * 300にハードコードされています(メモリ内コインは約300バイトなので5000コインを意味します)。しかし、ステップ7で再初期化する必要があります。 | |
− | + | このキャッシュには残りのキャッシュ領域がすべて与えられます。 | |
− | = | + | このキャッシュは、初期化中にロードされるのではなく、コインがアクセスされるときに満たされます。 (これは、cachedCoinsUsage = 0を設定するCCoinsViewCacheコンストラクタによって検証できます)。 |
− | + | ==スレッド起動== | |
− | + | このコードでは、boost :: thread_groupsを使用してさまざまなスレッドを管理しています。 | |
− | + | Bitcoin Coreはマルチスレッドプログラムですが、 "参照Satoshiクライアントは主にシングルスレッドです"ということに注意してください。 [https://github.com/bitcoin/bips/blob/master/bip-0031.mediawiki BIP 31(2012)のMike Hearnによるコメント] | |
− | + | つまり、プログラムの活動の大部分がメッセージングスレッド(ThreadMessageHandler - 以下を参照)で行われるということです。 | |
− | + | ほとんどすべてのスレッドは、プログラムの起動時にスタック上に作成される単一のマスタースレッドグループの一部です(<u> bitcoind.cpp </u>を参照)。このスレッドグループはいくつかの子スレッドを生成する<u> init.cpp </u>に渡されます(いくつかのスクリプト検査スレッドを含みますが、これらはすべて別個のグループではなくマスタースレッドグループの一部です)。 | |
− | + | スレッドグループは<u> net.cpp </u>に渡され、メッセージ処理スレッドを含むネットワーキングスレッドが作成されます。 | |
− | |||
− | |||
− | + | 2つの他のスレッドグループはタスク固有です。 | |
+ | * rpcサーバースレッドグループ(<r> rpcserver.h / cpp </u>を参照) | ||
+ | * minerスレッドグループ | ||
− | + | 当然のことながら、ノードはRPCサーバーがアクティブになっている場合にのみRPCサーバースレッドグループを作成し、マイナースレッドグループがマイニングの場合にのみ作成します。両方が無効の場合、Bitcoin Coreは単一のスレッドグループしか持たない。 | |
− | + | '' '子スレッド' '' | |
− | + | 親スレッド(プログラムが動作を開始するスレッドを意味する)は、ほとんどすべてのプログラムの作業を子スレッドに委譲します。 <u> init.cpp </u>と<u> net.cpp </u>でスレッドを生成した後、親スレッドは単にシャットダウンコマンドを待ちます。スレッドグループを開き、シャットダウンを続行します。 | |
+ | 子スレッドは、作成された順にリストされています。 | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
− | ! | + | ! スレッド !! いつ / どこで作成されました !! 説明 |
|- | |- | ||
− | | | + | | スクリプトチェック || ステップ4<br>init.cpp || これはスレッドのセットで、デフォルトでは4です。<br>スクリプトチェック(署名チェックを含む)は高価なので、別のスレッドで処理されます。 |
|- | |- | ||
− | | | + | | スケジューラ || ステップ4<br>init.cpp || スケジューラスレッド。<br> (TODO: describe) |
|- | |- | ||
− | | | + | | RPCスレッド || ステップ4<br>rpcserver.cpp || RPCサーバーが有効な場合は、RPC呼び出しを処理するスレッドのグループを開始します。 |
|- | |- | ||
− | | | + | | インポート || ステップ10<br>init.cpp || ブロックをインポートします。 3つのシナリオ:<br>1)再インデックス(blk ??? datファイルからすべての既知のブロックを再スキャンする)。<br>2)ブートストラップ(bootstrap.datをネットワークからの完全なIBDの代わりに使用します)。<br>3)-loadblock(特定のblk ???。datファイルをスキャンする) - これらのどれも適用されない場合、このスレッドは何もしません。 |
|- | |- | ||
− | | | + | | DNSアドレスシード || ステップ11<br>net.cpp || dnsシードに基づいてIPアドレスのベクトルを構築しようとし、ベクトルとスレッドを終了します。<br>2014年6月のテストでは、これには約4秒かかり、158のアドレスが見つかりました。 |
|- | |- | ||
− | | | + | | プラグ&プレイ || ステップ11<br>net.cpp || UPNP(ユニバーサルプラグ&プレイ) <br>UPNPのポートマッピングを扱う。 |
|- | |- | ||
− | | SocketHandler || | + | | SocketHandler || ステップ11<br>net.cpp || <u>このスレッドはソケットをサービスします:</u><br>関連するすべてのソケットのI / Oを50msのタイムアウトで待機します。<br>リスニングソケットで新しい着信接続を処理し、新しいピアのCNodeを作成します。<br>データストリームを受信して送信します。<br>何もしなかったソケットを切断状態に設定します。 |
|- | |- | ||
− | | OpenAddedConnections || | + | | OpenAddedConnections || ステップ11<br>net.cpp || -addnodeパラメーターを使用して、ユーザーが指定したアウトバウンド接続を開始します。<br>接続できない場合、各サイクルで2分間スリープします。 |
|- | |- | ||
− | | OpenConnections || | + | | OpenConnections || ステップ11<br>net.cpp || DNSシードから他のアウトバウンド接続を開始する(失敗した場合、固定シードに基づいてノードを見つける)<br>接続できない場合、各サイクルで500ミリ秒間スリープします。 |
|- | |- | ||
− | | MessageHandler || | + | | MessageHandler || ステップ11<br>net.cpp || <u>これがプログラムの主なスレッドです。</u> <br> このスレッドはwhile(true)ループを実行し、メッセージの送受信を行います。 (参照 <u>net.cpp</u>:1049) <br>このコードでは、boost :: signals2を使用してmain.cppのProcessMessages関数とSendMessages関数を呼び出します。<br>(シグナルを導入するコードはPR 2154にあります - そのプルで最後から2番目のコミットを参照してください)。<br>ProcessMessageとSendMessageはこのスレッドで実行されます。<br>したがって、<u> main.cpp </u>のコードのほとんどはこのスレッドで実行されます。 |
|- | |- | ||
− | | | + | | ウォレットフリュッシャー || ステップ12<br>init.cpp || ウォレットが有効な場合、このスレッドは定期的にウォレットをフラッシュします。 |
|} | |} | ||
− | == | + | ==関連項目== |
− | [https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_1): | + | [https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_1):_オーバービューBitcoin Core 0.11(Ch 1):概要] |
<br> | <br> | ||
− | [https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage Bitcoin Core 0. | + | [https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage Bitcoin Core 0.11(Ch 2):データストレージ] |
<br> | <br> | ||
− | [https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_4): | + | [https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_4):P2P_Network Bitcoin Core 0.11(Ch 4):P2Pネットワーク] |
<br> | <br> | ||
− | [https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5): | + | [https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Down Bitcoin Core 0.11(Ch 5):初期ブロックダウンロード] |
<br> | <br> | ||
− | [https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_6):_The_Blockchain Bitcoin Core 0. | + | [https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_6):_The_Blockchain Bitcoin Core 0.11(Ch 6):ブロックチェーン] |
− | [[ | + | [[Category:技術]] |
− | [[ | + | [[Category:開発者]] |
2018年4月14日 (土) 16:44時点における最新版
このページでは、起動と初期化を管理するBitcoin Coreコードについて説明します。
プログラムエントリポイント[編集]
プログラムのエントリポイントは bitcoind.cpp にあります。
main()はコードの3行です:
- SetupEnvironment()(これはプログラムのロケールを設定します)
- 信号ハンドラを接続する
- AppInit()(この関数はプログラムの寿命を延ばす)
AppInit:これは bitcoind.cpp の近くにあります。
- コマンドラインを解析する
- データディレクトリを開きます。
- 設定ファイルを読み込みます
- プロセスをフォークします(デーモンとして実行している場合)
- コントロールを init.cpp にあるAppInit2()に渡します。
初期化ステップ( init.cpp )[編集]
AppInit2()はビットコインシステムを初期化します。
これには約800行のコードが含まれており、12段階に分かれています。
各ステップが始まる場所は、コードに文書化されています。 Init.cpp にはファイルの先頭にいくつかの関数がありますが、大部分はAppInit2()で構成されています。
次の表は、手順をまとめたものです。
初期化 ステップ |
簡単な説明 | 詳細 |
---|---|---|
1 | OS固有のセットアップタスク | これらの作業は特に興味深いものではありません。 詳細は、コードを参照してください。 |
2 | パラメータの相互作用 | 特定のコマンドラインオプションでは、特定の方法で他のオプションを設定する必要があります。 たとえば、-zapwallettxesは-rescanを意味します。したがって、コードは-rescanフラグ= trueを設定します(まだ存在していない場合)。 |
3 | 内部フラグ / パラメータ健全性チェック |
特定のパラメータのグローバル変数を設定します。 財布については、取引料金レベルを正当性をチェックします(あなたの手数料がリレー[エラー]の資格を得るのに十分高いが、不当に高い[警告]ではないことを確認します)。 |
4 | アプリケーション初期化。 / RPCサーバー |
データディレクトリをロックします。 (できない場合は、エラーを出力して終了してください。) |
5 | ウォレット・データベースの整合性の確認 | ウォレットが有効になっている場合は、開こうとします。 ウォレットが破損していることがわかっている場合(-salvagewallet)、パスワードの回復を試みます。 |
6 | ネットワーク初期化 |
ノードは特定の信号を登録する。 |
7 | ブロックチェーンをロードします。 |
ブロックチェーンをメモリにロードし、UTXOキャッシュを初期化します。 |
8 | ウォレットをロードします。 | プログラムが初めて実行された場合は、ウォレットが作成され、最初のキー(アドレス)が与えられます。 |
9 | Datadirのメンテナンス | ユーザーがブロックプルーニングを行っている場合は、NODE_NETWORKの設定を解除し、プルーニング機能を呼び出します。 |
10 | インポートブロック | 現在有効なチェーンとして接続されていないブロックチェーンデータベースのチェーンをスキャンします。 |
11 | 開始ノード / RPCサーバー |
net.cppでStartNodeを呼び出します。 |
12 | 終了 |
AppInit2が終了すると、 bitcoind.cpp のAppInit()に戻ります。
そこで、コードのトップレベルスレッドは、WaitForShutdown()という関数で無期限にループします。 2秒間スリープ状態になり、ユーザーがctrl-Cを押したかどうかを確認します。 その場合は、 init.cpp でShutdown()を呼び出します。
シャットダウン()は、RPCサーバーをシャットダウンし、ノードを停止し、シグナルハンドラの登録を解除し、プログラムが完了します。
キャッシュサイズ[編集]
ステップ7は、キャッシュサイズを初期化した。手順7で考えられる3つのキャッシュがあります.2つはLevelDBデータベースキャッシュであり、もう1つはコインキャッシュであり、そのサイズは main.cpp のフラッシュコードによって管理されます。
ユーザーは、-dbcacheを使用して合計キャッシュ・サイズを割り当てることができます。ユーザーは、特定の各キャッシュに割り当てるスペースを選択して選択することはできません。デフォルトの合計キャッシュサイズ= 100MB(最大:4GB、最小:4MB)。
'1)ブロックインデックスキャッシュ'
このキャッシュには、/ block / index LevelDBデータの圧縮されていないチャンクが保存され、LevelDBのドキュメントに記載されているように、LevelDBによって管理されます。 br>
ユーザーが完全なトランザクションインデックス(-txindex = 1)を有効にした場合、合計キャッシュサイズの1/8までになります。 -txindexが有効でない場合は、2 MiBだけが必要です。
'2)UTXOデータベースキャッシュ'
これは、/ chainstateデータベースのLevelDBキャッシュです。
このキャッシュは、合計キャッシュ・サイズに応じて、残りのキャッシュ・スペースの25〜50%に割り振られます。
'3)UTXOインメモリキャッシュ'
これは main.cpp コードで管理されるコインキャッシュです。 (FlushStateToDiskおよび関連する関数を参照)
変数(nCoinsCache)は、 main.h のexternとして宣言されています。 main.cpp には、5000 * 300にハードコードされています(メモリ内コインは約300バイトなので5000コインを意味します)。しかし、ステップ7で再初期化する必要があります。
このキャッシュには残りのキャッシュ領域がすべて与えられます。
このキャッシュは、初期化中にロードされるのではなく、コインがアクセスされるときに満たされます。 (これは、cachedCoinsUsage = 0を設定するCCoinsViewCacheコンストラクタによって検証できます)。
スレッド起動[編集]
このコードでは、boost :: thread_groupsを使用してさまざまなスレッドを管理しています。
Bitcoin Coreはマルチスレッドプログラムですが、 "参照Satoshiクライアントは主にシングルスレッドです"ということに注意してください。 BIP 31(2012)のMike Hearnによるコメント
つまり、プログラムの活動の大部分がメッセージングスレッド(ThreadMessageHandler - 以下を参照)で行われるということです。
ほとんどすべてのスレッドは、プログラムの起動時にスタック上に作成される単一のマスタースレッドグループの一部です( bitcoind.cpp を参照)。このスレッドグループはいくつかの子スレッドを生成する init.cpp に渡されます(いくつかのスクリプト検査スレッドを含みますが、これらはすべて別個のグループではなくマスタースレッドグループの一部です)。
スレッドグループは net.cpp に渡され、メッセージ処理スレッドを含むネットワーキングスレッドが作成されます。
2つの他のスレッドグループはタスク固有です。
- rpcサーバースレッドグループ(<r> rpcserver.h / cpp </u>を参照)
- minerスレッドグループ
当然のことながら、ノードはRPCサーバーがアクティブになっている場合にのみRPCサーバースレッドグループを作成し、マイナースレッドグループがマイニングの場合にのみ作成します。両方が無効の場合、Bitcoin Coreは単一のスレッドグループしか持たない。
'子スレッド'
親スレッド(プログラムが動作を開始するスレッドを意味する)は、ほとんどすべてのプログラムの作業を子スレッドに委譲します。 init.cpp と net.cpp でスレッドを生成した後、親スレッドは単にシャットダウンコマンドを待ちます。スレッドグループを開き、シャットダウンを続行します。
子スレッドは、作成された順にリストされています。
スレッド | いつ / どこで作成されました | 説明 |
---|---|---|
スクリプトチェック | ステップ4 init.cpp |
これはスレッドのセットで、デフォルトでは4です。 スクリプトチェック(署名チェックを含む)は高価なので、別のスレッドで処理されます。 |
スケジューラ | ステップ4 init.cpp |
スケジューラスレッド。 (TODO: describe) |
RPCスレッド | ステップ4 rpcserver.cpp |
RPCサーバーが有効な場合は、RPC呼び出しを処理するスレッドのグループを開始します。 |
インポート | ステップ10 init.cpp |
ブロックをインポートします。 3つのシナリオ: 1)再インデックス(blk ??? datファイルからすべての既知のブロックを再スキャンする)。 2)ブートストラップ(bootstrap.datをネットワークからの完全なIBDの代わりに使用します)。 3)-loadblock(特定のblk ???。datファイルをスキャンする) - これらのどれも適用されない場合、このスレッドは何もしません。 |
DNSアドレスシード | ステップ11 net.cpp |
dnsシードに基づいてIPアドレスのベクトルを構築しようとし、ベクトルとスレッドを終了します。 2014年6月のテストでは、これには約4秒かかり、158のアドレスが見つかりました。 |
プラグ&プレイ | ステップ11 net.cpp |
UPNP(ユニバーサルプラグ&プレイ) UPNPのポートマッピングを扱う。 |
SocketHandler | ステップ11 net.cpp |
このスレッドはソケットをサービスします: 関連するすべてのソケットのI / Oを50msのタイムアウトで待機します。 リスニングソケットで新しい着信接続を処理し、新しいピアのCNodeを作成します。 データストリームを受信して送信します。 何もしなかったソケットを切断状態に設定します。 |
OpenAddedConnections | ステップ11 net.cpp |
-addnodeパラメーターを使用して、ユーザーが指定したアウトバウンド接続を開始します。 接続できない場合、各サイクルで2分間スリープします。 |
OpenConnections | ステップ11 net.cpp |
DNSシードから他のアウトバウンド接続を開始する(失敗した場合、固定シードに基づいてノードを見つける) 接続できない場合、各サイクルで500ミリ秒間スリープします。 |
MessageHandler | ステップ11 net.cpp |
これがプログラムの主なスレッドです。 このスレッドはwhile(true)ループを実行し、メッセージの送受信を行います。 (参照 net.cpp:1049) このコードでは、boost :: signals2を使用してmain.cppのProcessMessages関数とSendMessages関数を呼び出します。 (シグナルを導入するコードはPR 2154にあります - そのプルで最後から2番目のコミットを参照してください)。 ProcessMessageとSendMessageはこのスレッドで実行されます。 したがって、 main.cpp のコードのほとんどはこのスレッドで実行されます。 |
ウォレットフリュッシャー | ステップ12 init.cpp |
ウォレットが有効な場合、このスレッドは定期的にウォレットをフラッシュします。 |
関連項目[編集]
Core 0.11(Ch 1):概要
Bitcoin Core 0.11(Ch 2):データストレージ
Bitcoin Core 0.11(Ch 4):P2Pネットワーク
Bitcoin Core 0.11(Ch 5):初期ブロックダウンロード
Bitcoin Core 0.11(Ch 6):ブロックチェーン