|
|
|
// 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"
|
|
|
|
|
|
|
|
#include <boost/algorithm/string/predicate.hpp>
|
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()
|
|
|
|
ParseParameters(argc, argv);
|
|
|
|
|
|
|
|
// Process help and version before taking care about datadir
|
|
|
|
if (IsArgSet("-?") || IsArgSet("-h") || IsArgSet("-help") || IsArgSet("-version"))
|
|
|
|
{
|
|
|
|
std::string strUsage = strprintf(_("%s Daemon"), _(PACKAGE_NAME)) + " " + _("version") + " " + FormatFullVersion() + "\n";
|
|
|
|
|
|
|
|
if (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", GetArg("-datadir", "").c_str());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
try
|
|
|
|
{
|
|
|
|
ReadConfigFile(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;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Command-line RPC
|
|
|
|
bool fCommandLine = false;
|
|
|
|
for (int i = 1; i < argc; i++)
|
|
|
|
if (!IsSwitchChar(argv[i][0]) && !boost::algorithm::istarts_with(argv[i], "bitcoin:"))
|
|
|
|
fCommandLine = true;
|
|
|
|
|
|
|
|
if (fCommandLine)
|
|
|
|
{
|
|
|
|
fprintf(stderr, "Error: There is no RPC client functionality in bitcoind anymore. Use the bitcoin-cli utility instead.\n");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
// -server defaults to true for bitcoind but not for the GUI so do this here
|
|
|
|
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 (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
|
|
|
|
}
|
|
|
|
|
|
|
|
fRet = AppInitMain(threadGroup, scheduler);
|
|
|
|
}
|
|
|
|
catch (const std::exception& e) {
|
|
|
|
PrintExceptionContinue(&e, "AppInit()");
|
|
|
|
} catch (...) {
|
|
|
|
PrintExceptionContinue(NULL, "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);
|
|
|
|
// threadGroup.join_all(); was left out intentionally here, because we didn't re-test all of
|
|
|
|
// the startup-failure cases to make sure they don't result in a hang due to some
|
|
|
|
// thread-blocking-waiting-for-another-thread-during-startup case
|
|
|
|
} 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);
|
|
|
|
}
|