|
|
|
// Copyright (c) 2009-2010 Satoshi Nakamoto
|
|
|
|
// Copyright (c) 2009-2016 The Bitcoin Core developers
|
|
|
|
// Distributed under the MIT software license, see the accompanying
|
|
|
|
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
|
|
|
|
|
|
|
|
#if defined(HAVE_CONFIG_H)
|
|
|
|
#include "config/bitcoin-config.h"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include "chainparams.h"
|
|
|
|
#include "clientversion.h"
|
|
|
|
#include "compat.h"
|
|
|
|
#include "fs.h"
|
|
|
|
#include "rpc/server.h"
|
|
|
|
#include "init.h"
|
|
|
|
#include "noui.h"
|
|
|
|
#include "scheduler.h"
|
|
|
|
#include "util.h"
|
evhttpd implementation
- *Replace usage of boost::asio with [libevent2](http://libevent.org/)*.
boost::asio is not part of C++11, so unlike other boost there is no
forwards-compatibility reason to stick with it. Together with #4738 (convert
json_spirit to UniValue), this rids Bitcoin Core of the worst offenders with
regard to compile-time slowness.
- *Replace spit-and-duct-tape http server with evhttp*. Front-end http handling
is handled by libevent, a work queue (with configurable depth and parallelism)
is used to handle application requests.
- *Wrap HTTP request in C++ class*; this makes the application code mostly
HTTP-server-neutral
- *Refactor RPC to move all http-specific code to a separate file*.
Theoreticaly this can allow building without HTTP server but with another RPC
backend, e.g. Qt's debug console (currently not implemented) or future RPC
mechanisms people may want to use.
- *HTTP dispatch mechanism*; services (e.g., RPC, REST) register which URL
paths they want to handle.
By using a proven, high-performance asynchronous networking library (also used
by Tor) and HTTP server, problems such as #5674, #5655, #344 should be avoided.
What works? bitcoind, bitcoin-cli, bitcoin-qt. Unit tests and RPC/REST tests
pass. The aim for now is everything but SSL support.
Configuration options:
- `-rpcthreads`: repurposed as "number of work handler threads". Still
defaults to 4.
- `-rpcworkqueue`: maximum depth of work queue. When this is reached, new
requests will return a 500 Internal Error.
- `-rpctimeout`: inactivity time, in seconds, after which to disconnect a
client.
- `-debug=http`: low-level http activity logging
10 years ago
|
|
|
#include "httpserver.h"
|
|
|
|
#include "httprpc.h"
|
|
|
|
#include "utilstrencodings.h"
|
|
|
|
|
Split up util.cpp/h
Split up util.cpp/h into:
- string utilities (hex, base32, base64): no internal dependencies, no dependency on boost (apart from foreach)
- money utilities (parsesmoney, formatmoney)
- time utilities (gettime*, sleep, format date):
- and the rest (logging, argument parsing, config file parsing)
The latter is basically the environment and OS handling,
and is stripped of all utility functions, so we may want to
rename it to something else than util.cpp/h for clarity (Matt suggested
osinterface).
Breaks dependency of sha256.cpp on all the things pulled in by util.
10 years ago
|
|
|
#include <boost/thread.hpp>
|
|
|
|
|
evhttpd implementation
- *Replace usage of boost::asio with [libevent2](http://libevent.org/)*.
boost::asio is not part of C++11, so unlike other boost there is no
forwards-compatibility reason to stick with it. Together with #4738 (convert
json_spirit to UniValue), this rids Bitcoin Core of the worst offenders with
regard to compile-time slowness.
- *Replace spit-and-duct-tape http server with evhttp*. Front-end http handling
is handled by libevent, a work queue (with configurable depth and parallelism)
is used to handle application requests.
- *Wrap HTTP request in C++ class*; this makes the application code mostly
HTTP-server-neutral
- *Refactor RPC to move all http-specific code to a separate file*.
Theoreticaly this can allow building without HTTP server but with another RPC
backend, e.g. Qt's debug console (currently not implemented) or future RPC
mechanisms people may want to use.
- *HTTP dispatch mechanism*; services (e.g., RPC, REST) register which URL
paths they want to handle.
By using a proven, high-performance asynchronous networking library (also used
by Tor) and HTTP server, problems such as #5674, #5655, #344 should be avoided.
What works? bitcoind, bitcoin-cli, bitcoin-qt. Unit tests and RPC/REST tests
pass. The aim for now is everything but SSL support.
Configuration options:
- `-rpcthreads`: repurposed as "number of work handler threads". Still
defaults to 4.
- `-rpcworkqueue`: maximum depth of work queue. When this is reached, new
requests will return a 500 Internal Error.
- `-rpctimeout`: inactivity time, in seconds, after which to disconnect a
client.
- `-debug=http`: low-level http activity logging
10 years ago
|
|
|
#include <stdio.h>
|
|
|
|
|
|
|
|
/* Introduction text for doxygen: */
|
|
|
|
|
|
|
|
/*! \mainpage Developer documentation
|
|
|
|
*
|
|
|
|
* \section intro_sec Introduction
|
|
|
|
*
|
|
|
|
* This is the developer documentation of the reference client for an experimental new digital currency called Bitcoin (https://www.bitcoin.org/),
|
|
|
|
* which enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate
|
|
|
|
* with no central authority: managing transactions and issuing money are carried out collectively by the network.
|
|
|
|
*
|
|
|
|
* The software is a community-driven open source project, released under the MIT license.
|
|
|
|
*
|
|
|
|
* \section Navigation
|
|
|
|
* Use the buttons <code>Namespaces</code>, <code>Classes</code> or <code>Files</code> at the top of the page to start navigating the code.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void WaitForShutdown(boost::thread_group* threadGroup)
|
|
|
|
{
|
|
|
|
bool fShutdown = ShutdownRequested();
|
|
|
|
// Tell the main threads to shutdown.
|
|
|
|
while (!fShutdown)
|
|
|
|
{
|
|
|
|
MilliSleep(200);
|
|
|
|
fShutdown = ShutdownRequested();
|
|
|
|
}
|
|
|
|
if (threadGroup)
|
|
|
|
{
|
evhttpd implementation
- *Replace usage of boost::asio with [libevent2](http://libevent.org/)*.
boost::asio is not part of C++11, so unlike other boost there is no
forwards-compatibility reason to stick with it. Together with #4738 (convert
json_spirit to UniValue), this rids Bitcoin Core of the worst offenders with
regard to compile-time slowness.
- *Replace spit-and-duct-tape http server with evhttp*. Front-end http handling
is handled by libevent, a work queue (with configurable depth and parallelism)
is used to handle application requests.
- *Wrap HTTP request in C++ class*; this makes the application code mostly
HTTP-server-neutral
- *Refactor RPC to move all http-specific code to a separate file*.
Theoreticaly this can allow building without HTTP server but with another RPC
backend, e.g. Qt's debug console (currently not implemented) or future RPC
mechanisms people may want to use.
- *HTTP dispatch mechanism*; services (e.g., RPC, REST) register which URL
paths they want to handle.
By using a proven, high-performance asynchronous networking library (also used
by Tor) and HTTP server, problems such as #5674, #5655, #344 should be avoided.
What works? bitcoind, bitcoin-cli, bitcoin-qt. Unit tests and RPC/REST tests
pass. The aim for now is everything but SSL support.
Configuration options:
- `-rpcthreads`: repurposed as "number of work handler threads". Still
defaults to 4.
- `-rpcworkqueue`: maximum depth of work queue. When this is reached, new
requests will return a 500 Internal Error.
- `-rpctimeout`: inactivity time, in seconds, after which to disconnect a
client.
- `-debug=http`: low-level http activity logging
10 years ago
|
|
|
Interrupt(*threadGroup);
|
|
|
|
threadGroup->join_all();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
|
|
|
// Start
|
|
|
|
//
|
|
|
|
bool AppInit(int argc, char* argv[])
|
|
|
|
{
|
|
|
|
boost::thread_group threadGroup;
|
|
|
|
CScheduler scheduler;
|
|
|
|
|
|
|
|
bool fRet = false;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Parameters
|
|
|
|
//
|
|
|
|
// If Qt is used, parameters/bitcoin.conf are parsed in qt/bitcoin.cpp's main()
|
|
|
|
gArgs.ParseParameters(argc, argv);
|
|
|
|
|
|
|
|
// Process help and version before taking care about datadir
|
|
|
|
if (gArgs.IsArgSet("-?") || gArgs.IsArgSet("-h") || gArgs.IsArgSet("-help") || gArgs.IsArgSet("-version"))
|
|
|
|
{
|
|
|
|
std::string strUsage = strprintf(_("%s Daemon"), _(PACKAGE_NAME)) + " " + _("version") + " " + FormatFullVersion() + "\n";
|
|
|
|
|
|
|
|
if (gArgs.IsArgSet("-version"))
|
|
|
|
{
|
|
|
|
strUsage += FormatParagraph(LicenseInfo());
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
strUsage += "\n" + _("Usage:") + "\n" +
|
|
|
|
" bitcoind [options] " + strprintf(_("Start %s Daemon"), _(PACKAGE_NAME)) + "\n";
|
|
|
|
|
|
|
|
strUsage += "\n" + HelpMessage(HMM_BITCOIND);
|
|
|
|
}
|
|
|
|
|
|
|
|
fprintf(stdout, "%s", strUsage.c_str());
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
try
|
|
|
|
{
|
|
|
|
if (!fs::is_directory(GetDataDir(false)))
|
|
|
|
{
|
|
|
|
fprintf(stderr, "Error: Specified data directory \"%s\" does not exist.\n", gArgs.GetArg("-datadir", "").c_str());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
try
|
|
|
|
{
|
|
|
|
gArgs.ReadConfigFile(gArgs.GetArg("-conf", BITCOIN_CONF_FILENAME));
|
|
|
|
} catch (const std::exception& e) {
|
|
|
|
fprintf(stderr,"Error reading configuration file: %s\n", e.what());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
// Check for -testnet or -regtest parameter (Params() calls are only valid after this clause)
|
|
|
|
try {
|
|
|
|
SelectParams(ChainNameFromCommandLine());
|
|
|
|
} catch (const std::exception& e) {
|
|
|
|
fprintf(stderr, "Error: %s\n", e.what());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Error out when loose non-argument tokens are encountered on command line
|
|
|
|
for (int i = 1; i < argc; i++) {
|
|
|
|
if (!IsSwitchChar(argv[i][0])) {
|
|
|
|
fprintf(stderr, "Error: Command line contains unexpected token '%s', see bitcoind -h for a list of options.\n", argv[i]);
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// -server defaults to true for bitcoind but not for the GUI so do this here
|
|
|
|
gArgs.SoftSetBoolArg("-server", true);
|
|
|
|
// Set this early so that parameter interactions go to console
|
|
|
|
InitLogging();
|
|
|
|
InitParameterInteraction();
|
|
|
|
if (!AppInitBasicSetup())
|
|
|
|
{
|
|
|
|
// InitError will have been called with detailed error, which ends up on console
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
if (!AppInitParameterInteraction())
|
|
|
|
{
|
|
|
|
// InitError will have been called with detailed error, which ends up on console
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
if (!AppInitSanityChecks())
|
|
|
|
{
|
|
|
|
// InitError will have been called with detailed error, which ends up on console
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
if (gArgs.GetBoolArg("-daemon", false))
|
|
|
|
{
|
|
|
|
#if HAVE_DECL_DAEMON
|
|
|
|
fprintf(stdout, "Bitcoin server starting\n");
|
|
|
|
|
|
|
|
// Daemonize
|
|
|
|
if (daemon(1, 0)) { // don't chdir (1), do close FDs (0)
|
|
|
|
fprintf(stderr, "Error: daemon() failed: %s\n", strerror(errno));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
fprintf(stderr, "Error: -daemon is not supported on this operating system\n");
|
|
|
|
return false;
|
|
|
|
#endif // HAVE_DECL_DAEMON
|
|
|
|
}
|
|
|
|
// Lock data directory after daemonization
|
|
|
|
if (!AppInitLockDataDirectory())
|
|
|
|
{
|
|
|
|
// If locking the data directory failed, exit immediately
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
fRet = AppInitMain(threadGroup, scheduler);
|
|
|
|
}
|
|
|
|
catch (const std::exception& e) {
|
|
|
|
PrintExceptionContinue(&e, "AppInit()");
|
|
|
|
} catch (...) {
|
|
|
|
PrintExceptionContinue(nullptr, "AppInit()");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!fRet)
|
|
|
|
{
|
evhttpd implementation
- *Replace usage of boost::asio with [libevent2](http://libevent.org/)*.
boost::asio is not part of C++11, so unlike other boost there is no
forwards-compatibility reason to stick with it. Together with #4738 (convert
json_spirit to UniValue), this rids Bitcoin Core of the worst offenders with
regard to compile-time slowness.
- *Replace spit-and-duct-tape http server with evhttp*. Front-end http handling
is handled by libevent, a work queue (with configurable depth and parallelism)
is used to handle application requests.
- *Wrap HTTP request in C++ class*; this makes the application code mostly
HTTP-server-neutral
- *Refactor RPC to move all http-specific code to a separate file*.
Theoreticaly this can allow building without HTTP server but with another RPC
backend, e.g. Qt's debug console (currently not implemented) or future RPC
mechanisms people may want to use.
- *HTTP dispatch mechanism*; services (e.g., RPC, REST) register which URL
paths they want to handle.
By using a proven, high-performance asynchronous networking library (also used
by Tor) and HTTP server, problems such as #5674, #5655, #344 should be avoided.
What works? bitcoind, bitcoin-cli, bitcoin-qt. Unit tests and RPC/REST tests
pass. The aim for now is everything but SSL support.
Configuration options:
- `-rpcthreads`: repurposed as "number of work handler threads". Still
defaults to 4.
- `-rpcworkqueue`: maximum depth of work queue. When this is reached, new
requests will return a 500 Internal Error.
- `-rpctimeout`: inactivity time, in seconds, after which to disconnect a
client.
- `-debug=http`: low-level http activity logging
10 years ago
|
|
|
Interrupt(threadGroup);
|
Always wait for threadGroup to exit in bitcoind shutdown
This resolves a possible-assert-on-shutdown race introduced in
1f668b646806f94acd851acdbd9939c24e0492d3 when early shutdown
occurs.
Previously this was not done to avoid any cases where the
threadGroup might not exit due to a blocking thread, but at this
point the threadGroup isn't used all that much, plus Qt already
does this, and its good to keep their init/shutdown consistent.
For those curious, the threadGroup is only used in a few places:
* Its used to run the CCheckQueues in script validation, but these
use the boost mutex/condition variable primitives, so they
respect the interrupt pretty trivially.
* Its used for the import thread, which should exit rather quickly
as mostly it just calls LoadExternalBlockFile, which has an
interruption_point right before each block loaded.
* Its used in the scheduler thread, which is only used for:
* validationinterface has an effectively-dummy reference to it.
* wallet compaction, which should not last long
* addr/banlist dumping from CConnman, which should also be fast
8 years ago
|
|
|
threadGroup.join_all();
|
|
|
|
} else {
|
|
|
|
WaitForShutdown(&threadGroup);
|
|
|
|
}
|
|
|
|
Shutdown();
|
|
|
|
|
|
|
|
return fRet;
|
|
|
|
}
|
|
|
|
|
|
|
|
int main(int argc, char* argv[])
|
|
|
|
{
|
|
|
|
SetupEnvironment();
|
|
|
|
|
|
|
|
// Connect bitcoind signal handlers
|
|
|
|
noui_connect();
|
|
|
|
|
|
|
|
return (AppInit(argc, argv) ? EXIT_SUCCESS : EXIT_FAILURE);
|
|
|
|
}
|