|
|
|
// Copyright (c) 2010 Satoshi Nakamoto
|
|
|
|
// Copyright (c) 2009-2015 The Bitcoin Core developers
|
|
|
|
// Distributed under the MIT software license, see the accompanying
|
|
|
|
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
|
|
|
|
|
|
|
|
#include "rpc/server.h"
|
|
|
|
|
|
|
|
#include "base58.h"
|
|
|
|
#include "init.h"
|
|
|
|
#include "random.h"
|
|
|
|
#include "sync.h"
|
|
|
|
#include "ui_interface.h"
|
|
|
|
#include "util.h"
|
|
|
|
#include "utilstrencodings.h"
|
|
|
|
|
|
|
|
#include <univalue.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 <boost/bind.hpp>
|
|
|
|
#include <boost/filesystem.hpp>
|
|
|
|
#include <boost/foreach.hpp>
|
|
|
|
#include <boost/iostreams/concepts.hpp>
|
|
|
|
#include <boost/iostreams/stream.hpp>
|
|
|
|
#include <boost/shared_ptr.hpp>
|
|
|
|
#include <boost/signals2/signal.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 <boost/algorithm/string/case_conv.hpp> // for to_upper()
|
|
|
|
|
|
|
|
using namespace RPCServer;
|
|
|
|
using namespace std;
|
|
|
|
|
|
|
|
static bool fRPCRunning = false;
|
|
|
|
static bool fRPCInWarmup = true;
|
|
|
|
static std::string rpcWarmupStatus("RPC server started");
|
|
|
|
static CCriticalSection cs_rpcWarmup;
|
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
|
|
|
/* Timer-creating functions */
|
|
|
|
static RPCTimerInterface* timerInterface = NULL;
|
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
|
|
|
/* Map of name to timer.
|
|
|
|
* @note Can be changed to std::unique_ptr when C++11 */
|
|
|
|
static std::map<std::string, boost::shared_ptr<RPCTimerBase> > deadlineTimers;
|
|
|
|
|
|
|
|
static struct CRPCSignals
|
|
|
|
{
|
|
|
|
boost::signals2::signal<void ()> Started;
|
|
|
|
boost::signals2::signal<void ()> Stopped;
|
|
|
|
boost::signals2::signal<void (const CRPCCommand&)> PreCommand;
|
|
|
|
boost::signals2::signal<void (const CRPCCommand&)> PostCommand;
|
|
|
|
} g_rpcSignals;
|
|
|
|
|
|
|
|
void RPCServer::OnStarted(boost::function<void ()> slot)
|
|
|
|
{
|
|
|
|
g_rpcSignals.Started.connect(slot);
|
|
|
|
}
|
|
|
|
|
|
|
|
void RPCServer::OnStopped(boost::function<void ()> slot)
|
|
|
|
{
|
|
|
|
g_rpcSignals.Stopped.connect(slot);
|
|
|
|
}
|
|
|
|
|
|
|
|
void RPCServer::OnPreCommand(boost::function<void (const CRPCCommand&)> slot)
|
|
|
|
{
|
|
|
|
g_rpcSignals.PreCommand.connect(boost::bind(slot, _1));
|
|
|
|
}
|
|
|
|
|
|
|
|
void RPCServer::OnPostCommand(boost::function<void (const CRPCCommand&)> slot)
|
|
|
|
{
|
|
|
|
g_rpcSignals.PostCommand.connect(boost::bind(slot, _1));
|
|
|
|
}
|
|
|
|
|
|
|
|
void RPCTypeCheck(const UniValue& params,
|
|
|
|
const list<UniValue::VType>& typesExpected,
|
|
|
|
bool fAllowNull)
|
|
|
|
{
|
|
|
|
unsigned int i = 0;
|
|
|
|
BOOST_FOREACH(UniValue::VType t, typesExpected)
|
|
|
|
{
|
|
|
|
if (params.size() <= i)
|
|
|
|
break;
|
|
|
|
|
|
|
|
const UniValue& v = params[i];
|
|
|
|
if (!((v.type() == t) || (fAllowNull && (v.isNull()))))
|
|
|
|
{
|
|
|
|
string err = strprintf("Expected type %s, got %s",
|
|
|
|
uvTypeName(t), uvTypeName(v.type()));
|
|
|
|
throw JSONRPCError(RPC_TYPE_ERROR, err);
|
|
|
|
}
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void RPCTypeCheckObj(const UniValue& o,
|
|
|
|
const map<string, UniValueType>& typesExpected,
|
|
|
|
bool fAllowNull,
|
|
|
|
bool fStrict)
|
|
|
|
{
|
|
|
|
for (const auto& t : typesExpected) {
|
|
|
|
const UniValue& v = find_value(o, t.first);
|
|
|
|
if (!fAllowNull && v.isNull())
|
|
|
|
throw JSONRPCError(RPC_TYPE_ERROR, strprintf("Missing %s", t.first));
|
|
|
|
|
|
|
|
if (!(t.second.typeAny || v.type() == t.second.type || (fAllowNull && v.isNull()))) {
|
|
|
|
string err = strprintf("Expected type %s for %s, got %s",
|
|
|
|
uvTypeName(t.second.type), t.first, uvTypeName(v.type()));
|
|
|
|
throw JSONRPCError(RPC_TYPE_ERROR, err);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fStrict)
|
|
|
|
{
|
|
|
|
BOOST_FOREACH(const string& k, o.getKeys())
|
|
|
|
{
|
|
|
|
if (typesExpected.count(k) == 0)
|
|
|
|
{
|
|
|
|
string err = strprintf("Unexpected key %s", k);
|
|
|
|
throw JSONRPCError(RPC_TYPE_ERROR, err);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
CAmount AmountFromValue(const UniValue& value)
|
|
|
|
{
|
|
|
|
if (!value.isNum() && !value.isStr())
|
|
|
|
throw JSONRPCError(RPC_TYPE_ERROR, "Amount is not a number or string");
|
|
|
|
CAmount amount;
|
|
|
|
if (!ParseFixedPoint(value.getValStr(), 8, &amount))
|
|
|
|
throw JSONRPCError(RPC_TYPE_ERROR, "Invalid amount");
|
|
|
|
if (!MoneyRange(amount))
|
|
|
|
throw JSONRPCError(RPC_TYPE_ERROR, "Amount out of range");
|
|
|
|
return amount;
|
|
|
|
}
|
|
|
|
|
|
|
|
UniValue ValueFromAmount(const CAmount& amount)
|
|
|
|
{
|
|
|
|
bool sign = amount < 0;
|
|
|
|
int64_t n_abs = (sign ? -amount : amount);
|
|
|
|
int64_t quotient = n_abs / COIN;
|
|
|
|
int64_t remainder = n_abs % COIN;
|
|
|
|
return UniValue(UniValue::VNUM,
|
|
|
|
strprintf("%s%d.%08d", sign ? "-" : "", quotient, remainder));
|
|
|
|
}
|
|
|
|
|
|
|
|
uint256 ParseHashV(const UniValue& v, string strName)
|
|
|
|
{
|
|
|
|
string strHex;
|
|
|
|
if (v.isStr())
|
|
|
|
strHex = v.get_str();
|
|
|
|
if (!IsHex(strHex)) // Note: IsHex("") is false
|
|
|
|
throw JSONRPCError(RPC_INVALID_PARAMETER, strName+" must be hexadecimal string (not '"+strHex+"')");
|
|
|
|
uint256 result;
|
|
|
|
result.SetHex(strHex);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
uint256 ParseHashO(const UniValue& o, string strKey)
|
|
|
|
{
|
|
|
|
return ParseHashV(find_value(o, strKey), strKey);
|
|
|
|
}
|
|
|
|
vector<unsigned char> ParseHexV(const UniValue& v, string strName)
|
|
|
|
{
|
|
|
|
string strHex;
|
|
|
|
if (v.isStr())
|
|
|
|
strHex = v.get_str();
|
|
|
|
if (!IsHex(strHex))
|
|
|
|
throw JSONRPCError(RPC_INVALID_PARAMETER, strName+" must be hexadecimal string (not '"+strHex+"')");
|
|
|
|
return ParseHex(strHex);
|
|
|
|
}
|
|
|
|
vector<unsigned char> ParseHexO(const UniValue& o, string strKey)
|
|
|
|
{
|
|
|
|
return ParseHexV(find_value(o, strKey), strKey);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Note: This interface may still be subject to change.
|
|
|
|
*/
|
|
|
|
|
|
|
|
std::string CRPCTable::help(const std::string& strCommand) const
|
|
|
|
{
|
|
|
|
string strRet;
|
|
|
|
string category;
|
|
|
|
set<rpcfn_type> setDone;
|
|
|
|
vector<pair<string, const CRPCCommand*> > vCommands;
|
|
|
|
|
|
|
|
for (map<string, const CRPCCommand*>::const_iterator mi = mapCommands.begin(); mi != mapCommands.end(); ++mi)
|
|
|
|
vCommands.push_back(make_pair(mi->second->category + mi->first, mi->second));
|
|
|
|
sort(vCommands.begin(), vCommands.end());
|
|
|
|
|
|
|
|
BOOST_FOREACH(const PAIRTYPE(string, const CRPCCommand*)& command, vCommands)
|
|
|
|
{
|
|
|
|
const CRPCCommand *pcmd = command.second;
|
|
|
|
string strMethod = pcmd->name;
|
|
|
|
// We already filter duplicates, but these deprecated screw up the sort order
|
|
|
|
if (strMethod.find("label") != string::npos)
|
|
|
|
continue;
|
|
|
|
if ((strCommand != "" || pcmd->category == "hidden") && strMethod != strCommand)
|
|
|
|
continue;
|
|
|
|
try
|
|
|
|
{
|
|
|
|
UniValue params;
|
|
|
|
rpcfn_type pfn = pcmd->actor;
|
|
|
|
if (setDone.insert(pfn).second)
|
|
|
|
(*pfn)(params, true);
|
|
|
|
}
|
|
|
|
catch (const std::exception& e)
|
|
|
|
{
|
|
|
|
// Help text is returned in an exception
|
|
|
|
string strHelp = string(e.what());
|
|
|
|
if (strCommand == "")
|
|
|
|
{
|
|
|
|
if (strHelp.find('\n') != string::npos)
|
|
|
|
strHelp = strHelp.substr(0, strHelp.find('\n'));
|
|
|
|
|
|
|
|
if (category != pcmd->category)
|
|
|
|
{
|
|
|
|
if (!category.empty())
|
|
|
|
strRet += "\n";
|
|
|
|
category = pcmd->category;
|
|
|
|
string firstLetter = category.substr(0,1);
|
|
|
|
boost::to_upper(firstLetter);
|
|
|
|
strRet += "== " + firstLetter + category.substr(1) + " ==\n";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
strRet += strHelp + "\n";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (strRet == "")
|
|
|
|
strRet = strprintf("help: unknown command: %s\n", strCommand);
|
|
|
|
strRet = strRet.substr(0,strRet.size()-1);
|
|
|
|
return strRet;
|
|
|
|
}
|
|
|
|
|
|
|
|
UniValue help(const UniValue& params, bool fHelp)
|
|
|
|
{
|
|
|
|
if (fHelp || params.size() > 1)
|
|
|
|
throw runtime_error(
|
|
|
|
"help ( \"command\" )\n"
|
|
|
|
"\nList all commands, or get help for a specified command.\n"
|
|
|
|
"\nArguments:\n"
|
|
|
|
"1. \"command\" (string, optional) The command to get help on\n"
|
|
|
|
"\nResult:\n"
|
|
|
|
"\"text\" (string) The help text\n"
|
|
|
|
);
|
|
|
|
|
|
|
|
string strCommand;
|
|
|
|
if (params.size() > 0)
|
|
|
|
strCommand = params[0].get_str();
|
|
|
|
|
|
|
|
return tableRPC.help(strCommand);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
UniValue stop(const UniValue& params, bool fHelp)
|
|
|
|
{
|
|
|
|
// Accept the deprecated and ignored 'detach' boolean argument
|
|
|
|
if (fHelp || params.size() > 1)
|
|
|
|
throw runtime_error(
|
|
|
|
"stop\n"
|
|
|
|
"\nStop Bitcoin server.");
|
|
|
|
// Event loop will exit after current HTTP requests have been handled, so
|
|
|
|
// this reply will get back to the client.
|
|
|
|
StartShutdown();
|
|
|
|
return "Bitcoin server stopping";
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Call Table
|
|
|
|
*/
|
|
|
|
static const CRPCCommand vRPCCommands[] =
|
|
|
|
{ // category name actor (function) okSafeMode
|
|
|
|
// --------------------- ------------------------ ----------------------- ----------
|
|
|
|
/* Overall control/query calls */
|
|
|
|
{ "control", "help", &help, true },
|
|
|
|
{ "control", "stop", &stop, true },
|
|
|
|
};
|
|
|
|
|
|
|
|
CRPCTable::CRPCTable()
|
|
|
|
{
|
|
|
|
unsigned int vcidx;
|
|
|
|
for (vcidx = 0; vcidx < (sizeof(vRPCCommands) / sizeof(vRPCCommands[0])); vcidx++)
|
|
|
|
{
|
|
|
|
const CRPCCommand *pcmd;
|
|
|
|
|
|
|
|
pcmd = &vRPCCommands[vcidx];
|
|
|
|
mapCommands[pcmd->name] = pcmd;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
const CRPCCommand *CRPCTable::operator[](const std::string &name) const
|
|
|
|
{
|
|
|
|
map<string, const CRPCCommand*>::const_iterator it = mapCommands.find(name);
|
|
|
|
if (it == mapCommands.end())
|
|
|
|
return NULL;
|
|
|
|
return (*it).second;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool CRPCTable::appendCommand(const std::string& name, const CRPCCommand* pcmd)
|
|
|
|
{
|
|
|
|
if (IsRPCRunning())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// don't allow overwriting for now
|
|
|
|
map<string, const CRPCCommand*>::const_iterator it = mapCommands.find(name);
|
|
|
|
if (it != mapCommands.end())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
mapCommands[name] = pcmd;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
bool StartRPC()
|
|
|
|
{
|
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
|
|
|
LogPrint("rpc", "Starting RPC\n");
|
|
|
|
fRPCRunning = true;
|
|
|
|
g_rpcSignals.Started();
|
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
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
void InterruptRPC()
|
|
|
|
{
|
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
|
|
|
LogPrint("rpc", "Interrupting RPC\n");
|
|
|
|
// Interrupt e.g. running longpolls
|
|
|
|
fRPCRunning = false;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
void StopRPC()
|
|
|
|
{
|
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
|
|
|
LogPrint("rpc", "Stopping RPC\n");
|
|
|
|
deadlineTimers.clear();
|
|
|
|
g_rpcSignals.Stopped();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool IsRPCRunning()
|
|
|
|
{
|
|
|
|
return fRPCRunning;
|
|
|
|
}
|
|
|
|
|
|
|
|
void SetRPCWarmupStatus(const std::string& newStatus)
|
|
|
|
{
|
|
|
|
LOCK(cs_rpcWarmup);
|
|
|
|
rpcWarmupStatus = newStatus;
|
|
|
|
}
|
|
|
|
|
|
|
|
void SetRPCWarmupFinished()
|
|
|
|
{
|
|
|
|
LOCK(cs_rpcWarmup);
|
|
|
|
assert(fRPCInWarmup);
|
|
|
|
fRPCInWarmup = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool RPCIsInWarmup(std::string *outStatus)
|
|
|
|
{
|
|
|
|
LOCK(cs_rpcWarmup);
|
|
|
|
if (outStatus)
|
|
|
|
*outStatus = rpcWarmupStatus;
|
|
|
|
return fRPCInWarmup;
|
|
|
|
}
|
|
|
|
|
|
|
|
void JSONRequest::parse(const UniValue& valRequest)
|
|
|
|
{
|
|
|
|
// Parse request
|
|
|
|
if (!valRequest.isObject())
|
|
|
|
throw JSONRPCError(RPC_INVALID_REQUEST, "Invalid Request object");
|
|
|
|
const UniValue& request = valRequest.get_obj();
|
|
|
|
|
|
|
|
// Parse id now so errors from here on will have the id
|
|
|
|
id = find_value(request, "id");
|
|
|
|
|
|
|
|
// Parse method
|
|
|
|
UniValue valMethod = find_value(request, "method");
|
|
|
|
if (valMethod.isNull())
|
|
|
|
throw JSONRPCError(RPC_INVALID_REQUEST, "Missing method");
|
|
|
|
if (!valMethod.isStr())
|
|
|
|
throw JSONRPCError(RPC_INVALID_REQUEST, "Method must be a string");
|
|
|
|
strMethod = valMethod.get_str();
|
|
|
|
if (strMethod != "getblocktemplate")
|
|
|
|
LogPrint("rpc", "ThreadRPCServer method=%s\n", SanitizeString(strMethod));
|
|
|
|
|
|
|
|
// Parse params
|
|
|
|
UniValue valParams = find_value(request, "params");
|
|
|
|
if (valParams.isArray())
|
|
|
|
params = valParams.get_array();
|
|
|
|
else if (valParams.isNull())
|
|
|
|
params = UniValue(UniValue::VARR);
|
|
|
|
else
|
|
|
|
throw JSONRPCError(RPC_INVALID_REQUEST, "Params must be an array");
|
|
|
|
}
|
|
|
|
|
|
|
|
static UniValue JSONRPCExecOne(const UniValue& req)
|
|
|
|
{
|
|
|
|
UniValue rpc_result(UniValue::VOBJ);
|
|
|
|
|
|
|
|
JSONRequest jreq;
|
|
|
|
try {
|
|
|
|
jreq.parse(req);
|
|
|
|
|
|
|
|
UniValue result = tableRPC.execute(jreq.strMethod, jreq.params);
|
|
|
|
rpc_result = JSONRPCReplyObj(result, NullUniValue, jreq.id);
|
|
|
|
}
|
|
|
|
catch (const UniValue& objError)
|
|
|
|
{
|
|
|
|
rpc_result = JSONRPCReplyObj(NullUniValue, objError, jreq.id);
|
|
|
|
}
|
|
|
|
catch (const std::exception& e)
|
|
|
|
{
|
|
|
|
rpc_result = JSONRPCReplyObj(NullUniValue,
|
|
|
|
JSONRPCError(RPC_PARSE_ERROR, e.what()), jreq.id);
|
|
|
|
}
|
|
|
|
|
|
|
|
return rpc_result;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
std::string JSONRPCExecBatch(const UniValue& vReq)
|
|
|
|
{
|
|
|
|
UniValue ret(UniValue::VARR);
|
|
|
|
for (unsigned int reqIdx = 0; reqIdx < vReq.size(); reqIdx++)
|
|
|
|
ret.push_back(JSONRPCExecOne(vReq[reqIdx]));
|
|
|
|
|
|
|
|
return ret.write() + "\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
UniValue CRPCTable::execute(const std::string &strMethod, const UniValue ¶ms) const
|
|
|
|
{
|
|
|
|
// Return immediately if in warmup
|
|
|
|
{
|
|
|
|
LOCK(cs_rpcWarmup);
|
|
|
|
if (fRPCInWarmup)
|
|
|
|
throw JSONRPCError(RPC_IN_WARMUP, rpcWarmupStatus);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Find method
|
|
|
|
const CRPCCommand *pcmd = tableRPC[strMethod];
|
|
|
|
if (!pcmd)
|
|
|
|
throw JSONRPCError(RPC_METHOD_NOT_FOUND, "Method not found");
|
|
|
|
|
|
|
|
g_rpcSignals.PreCommand(*pcmd);
|
|
|
|
|
|
|
|
try
|
|
|
|
{
|
|
|
|
// Execute
|
|
|
|
return pcmd->actor(params, false);
|
|
|
|
}
|
|
|
|
catch (const std::exception& e)
|
|
|
|
{
|
|
|
|
throw JSONRPCError(RPC_MISC_ERROR, e.what());
|
|
|
|
}
|
|
|
|
|
|
|
|
g_rpcSignals.PostCommand(*pcmd);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string> CRPCTable::listCommands() const
|
|
|
|
{
|
|
|
|
std::vector<std::string> commandList;
|
|
|
|
typedef std::map<std::string, const CRPCCommand*> commandMap;
|
|
|
|
|
|
|
|
std::transform( mapCommands.begin(), mapCommands.end(),
|
|
|
|
std::back_inserter(commandList),
|
|
|
|
boost::bind(&commandMap::value_type::first,_1) );
|
|
|
|
return commandList;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string HelpExampleCli(const std::string& methodname, const std::string& args)
|
|
|
|
{
|
|
|
|
return "> bitcoin-cli " + methodname + " " + args + "\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string HelpExampleRpc(const std::string& methodname, const std::string& args)
|
|
|
|
{
|
|
|
|
return "> curl --user myusername --data-binary '{\"jsonrpc\": \"1.0\", \"id\":\"curltest\", "
|
|
|
|
"\"method\": \"" + methodname + "\", \"params\": [" + args + "] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
void RPCSetTimerInterfaceIfUnset(RPCTimerInterface *iface)
|
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
|
|
|
{
|
|
|
|
if (!timerInterface)
|
|
|
|
timerInterface = iface;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
void RPCSetTimerInterface(RPCTimerInterface *iface)
|
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
|
|
|
{
|
|
|
|
timerInterface = iface;
|
|
|
|
}
|
|
|
|
|
|
|
|
void RPCUnsetTimerInterface(RPCTimerInterface *iface)
|
|
|
|
{
|
|
|
|
if (timerInterface == iface)
|
|
|
|
timerInterface = NULL;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
void RPCRunLater(const std::string& name, boost::function<void(void)> func, int64_t nSeconds)
|
|
|
|
{
|
|
|
|
if (!timerInterface)
|
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
|
|
|
throw JSONRPCError(RPC_INTERNAL_ERROR, "No timer handler registered for RPC");
|
|
|
|
deadlineTimers.erase(name);
|
|
|
|
LogPrint("rpc", "queue run of timer %s in %i seconds (using %s)\n", name, nSeconds, timerInterface->Name());
|
|
|
|
deadlineTimers.insert(std::make_pair(name, boost::shared_ptr<RPCTimerBase>(timerInterface->NewTimer(func, nSeconds*1000))));
|
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
|
|
|
}
|
|
|
|
|
|
|
|
CRPCTable tableRPC;
|