2010-07-14 17:54:31 +02:00
|
|
|
// Copyright (c) 2010 Satoshi Nakamoto
|
2015-12-13 14:51:43 +01:00
|
|
|
// Copyright (c) 2009-2015 The Bitcoin Core developers
|
2014-10-30 03:14:08 +01:00
|
|
|
// Distributed under the MIT software license, see the accompanying
|
2012-05-18 16:02:28 +02:00
|
|
|
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
|
2010-07-14 17:54:31 +02:00
|
|
|
|
2018-04-02 00:30:17 +02:00
|
|
|
#ifndef BITCOIN_RPC_SERVER_H
|
|
|
|
#define BITCOIN_RPC_SERVER_H
|
2012-04-21 01:37:34 +02:00
|
|
|
|
2020-03-19 23:46:56 +01:00
|
|
|
#include <amount.h>
|
|
|
|
#include <rpc/protocol.h>
|
|
|
|
#include <uint256.h>
|
2013-04-13 07:13:08 +02:00
|
|
|
|
2012-06-23 00:36:42 +02:00
|
|
|
#include <list>
|
2012-04-21 01:37:34 +02:00
|
|
|
#include <map>
|
2013-04-13 07:13:08 +02:00
|
|
|
#include <stdint.h>
|
|
|
|
#include <string>
|
2012-08-21 17:03:38 +02:00
|
|
|
|
2015-09-04 16:11:34 +02:00
|
|
|
#include <univalue.h>
|
2012-04-21 01:37:34 +02:00
|
|
|
|
2014-10-19 10:46:17 +02:00
|
|
|
class CRPCCommand;
|
|
|
|
|
|
|
|
namespace RPCServer
|
|
|
|
{
|
2017-05-18 02:17:51 +02:00
|
|
|
void OnStarted(std::function<void ()> slot);
|
|
|
|
void OnStopped(std::function<void ()> slot);
|
2014-10-19 10:46:17 +02:00
|
|
|
}
|
2012-04-21 01:37:34 +02:00
|
|
|
|
2016-10-19 15:01:33 +02:00
|
|
|
class JSONRPCRequest
|
2014-06-27 06:10:53 +02:00
|
|
|
{
|
|
|
|
public:
|
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
2015-01-23 07:53:17 +01:00
|
|
|
UniValue id;
|
|
|
|
std::string strMethod;
|
|
|
|
UniValue params;
|
2016-10-19 15:01:33 +02:00
|
|
|
bool fHelp;
|
|
|
|
std::string URI;
|
|
|
|
std::string authUser;
|
2018-03-27 20:43:34 +02:00
|
|
|
std::string peerAddr;
|
2012-05-24 05:20:07 +02:00
|
|
|
|
2017-06-07 01:40:48 +02:00
|
|
|
JSONRPCRequest() : id(NullUniValue), params(NullUniValue), fHelp(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
2015-01-23 07:53:17 +01:00
|
|
|
void parse(const UniValue& valRequest);
|
2014-06-27 06:10:53 +02:00
|
|
|
};
|
|
|
|
|
2014-11-20 03:19:29 +01:00
|
|
|
/** Query whether RPC is running */
|
2012-05-13 06:43:24 +02:00
|
|
|
bool IsRPCRunning();
|
2012-04-09 21:07:25 +02:00
|
|
|
|
2015-05-31 15:36:44 +02:00
|
|
|
/**
|
2014-11-20 03:19:29 +01:00
|
|
|
* Set the RPC warmup status. When this is done, all RPC calls will error out
|
2014-10-29 18:08:31 +01:00
|
|
|
* immediately with RPC_IN_WARMUP.
|
|
|
|
*/
|
|
|
|
void SetRPCWarmupStatus(const std::string& newStatus);
|
|
|
|
/* Mark warmup as done. RPC calls will be processed from now on. */
|
|
|
|
void SetRPCWarmupFinished();
|
|
|
|
|
2014-11-26 13:51:02 +01:00
|
|
|
/* returns the current warmup state. */
|
2017-03-23 08:16:14 +01:00
|
|
|
bool RPCIsInWarmup(std::string *outStatus);
|
2012-04-09 21:07:25 +02:00
|
|
|
|
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
2015-01-23 07:53:17 +01:00
|
|
|
/** Opaque base class for timers returned by NewTimerFunc.
|
|
|
|
* This provides no methods at the moment, but makes sure that delete
|
|
|
|
* cleans up the whole state.
|
|
|
|
*/
|
|
|
|
class RPCTimerBase
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
virtual ~RPCTimerBase() {}
|
|
|
|
};
|
|
|
|
|
2014-10-30 03:14:08 +01:00
|
|
|
/**
|
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
2015-01-23 07:53:17 +01:00
|
|
|
* RPC timer "driver".
|
2014-10-30 03:14:08 +01:00
|
|
|
*/
|
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
2015-01-23 07:53:17 +01:00
|
|
|
class RPCTimerInterface
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
virtual ~RPCTimerInterface() {}
|
|
|
|
/** Implementation name */
|
|
|
|
virtual const char *Name() = 0;
|
|
|
|
/** Factory function for timers.
|
2015-08-28 16:46:20 +02:00
|
|
|
* RPC will call the function to create a timer that will call func in *millis* milliseconds.
|
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
2015-01-23 07:53:17 +01:00
|
|
|
* @note As the RPC mechanism is backend-neutral, it can use different implementations of timers.
|
|
|
|
* This is needed to cope with the case in which there is no HTTP server, but
|
|
|
|
* only GUI RPC console, and to break the dependency of pcserver on httprpc.
|
|
|
|
*/
|
2018-09-20 23:57:13 +02:00
|
|
|
virtual RPCTimerBase* NewTimer(std::function<void()>& func, int64_t millis) = 0;
|
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
2015-01-23 07:53:17 +01:00
|
|
|
};
|
|
|
|
|
2016-01-08 17:34:41 +01:00
|
|
|
/** Set the factory function for timers */
|
|
|
|
void RPCSetTimerInterface(RPCTimerInterface *iface);
|
|
|
|
/** Set the factory function for timer, but only, if unset */
|
|
|
|
void RPCSetTimerInterfaceIfUnset(RPCTimerInterface *iface);
|
|
|
|
/** Unset factory function for timers */
|
|
|
|
void RPCUnsetTimerInterface(RPCTimerInterface *iface);
|
2012-06-23 00:36:42 +02:00
|
|
|
|
2014-10-30 03:14:08 +01:00
|
|
|
/**
|
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
2015-01-23 07:53:17 +01:00
|
|
|
* Run func nSeconds from now.
|
2014-10-30 03:14:08 +01:00
|
|
|
* Overrides previous timer <name> (if any).
|
2013-05-07 16:47:00 +02:00
|
|
|
*/
|
2018-09-20 23:57:13 +02:00
|
|
|
void RPCRunLater(const std::string& name, std::function<void()> func, int64_t nSeconds);
|
2013-05-07 16:47:00 +02:00
|
|
|
|
2016-10-19 15:01:33 +02:00
|
|
|
typedef UniValue(*rpcfn_type)(const JSONRPCRequest& jsonRequest);
|
2012-04-21 01:37:34 +02:00
|
|
|
|
|
|
|
class CRPCCommand
|
|
|
|
{
|
|
|
|
public:
|
2021-11-01 12:24:34 +01:00
|
|
|
//! RPC method handler reading request and assigning result. Should return
|
|
|
|
//! true if request is fully handled, false if it should be passed on to
|
|
|
|
//! subsequent handlers.
|
|
|
|
using Actor = std::function<bool(const JSONRPCRequest& request, UniValue& result, bool last_handler)>;
|
|
|
|
|
|
|
|
//! Constructor taking Actor callback supporting multiple handlers.
|
|
|
|
CRPCCommand(std::string category, std::string name, Actor actor, std::vector<std::string> args, intptr_t unique_id)
|
|
|
|
: category(std::move(category)), name(std::move(name)), actor(std::move(actor)), argNames(std::move(args)),
|
|
|
|
unique_id(unique_id)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
//! Simplified constructor taking plain rpcfn_type function pointer.
|
|
|
|
CRPCCommand(const char* category, const char* name, rpcfn_type fn, std::initializer_list<const char*> args)
|
|
|
|
: CRPCCommand(category, name,
|
|
|
|
[fn](const JSONRPCRequest& request, UniValue& result, bool) { result = fn(request); return true; },
|
|
|
|
{args.begin(), args.end()}, intptr_t(fn))
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2014-07-15 21:38:52 +02:00
|
|
|
std::string category;
|
2012-04-21 01:37:34 +02:00
|
|
|
std::string name;
|
2021-11-01 12:24:34 +01:00
|
|
|
Actor actor;
|
2017-01-10 13:52:49 +01:00
|
|
|
std::vector<std::string> argNames;
|
2021-11-01 12:24:34 +01:00
|
|
|
intptr_t unique_id;
|
2012-04-21 01:37:34 +02:00
|
|
|
};
|
|
|
|
|
2012-04-09 21:07:25 +02:00
|
|
|
/**
|
2015-03-18 00:06:58 +01:00
|
|
|
* Dash RPC command dispatcher.
|
2012-04-09 21:07:25 +02:00
|
|
|
*/
|
2012-04-21 01:37:34 +02:00
|
|
|
class CRPCTable
|
|
|
|
{
|
|
|
|
private:
|
2021-11-01 12:24:34 +01:00
|
|
|
std::map<std::string, std::vector<const CRPCCommand*>> mapCommands;
|
2021-01-14 20:39:34 +01:00
|
|
|
std::multimap<std::string, std::vector<UniValue>> mapPlatformRestrictions;
|
2012-04-21 01:37:34 +02:00
|
|
|
public:
|
|
|
|
CRPCTable();
|
2019-01-28 17:47:36 +01:00
|
|
|
std::string help(const std::string& name, const std::string& strSubCommand, const JSONRPCRequest& helpreq) const;
|
2012-04-09 21:07:25 +02:00
|
|
|
|
2021-01-14 20:39:34 +01:00
|
|
|
void InitPlatformRestrictions();
|
|
|
|
|
2012-04-09 21:07:25 +02:00
|
|
|
/**
|
|
|
|
* Execute a method.
|
2016-10-19 15:01:33 +02:00
|
|
|
* @param request The JSONRPCRequest to execute
|
2012-04-09 21:07:25 +02:00
|
|
|
* @returns Result of the call.
|
2015-05-13 21:29:19 +02:00
|
|
|
* @throws an exception (UniValue) when an error happens.
|
2012-04-09 21:07:25 +02:00
|
|
|
*/
|
2016-10-19 15:01:33 +02:00
|
|
|
UniValue execute(const JSONRPCRequest &request) const;
|
2016-02-27 04:57:12 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns a list of registered commands
|
|
|
|
* @returns List of registered commands.
|
|
|
|
*/
|
|
|
|
std::vector<std::string> listCommands() const;
|
2016-01-20 15:15:29 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Appends a CRPCCommand to the dispatch table.
|
2018-03-19 17:17:53 +01:00
|
|
|
*
|
2016-01-20 15:15:29 +01:00
|
|
|
* Returns false if RPC server is already running (dump concurrency protection).
|
2018-03-19 17:17:53 +01:00
|
|
|
*
|
2021-11-01 12:24:34 +01:00
|
|
|
* Commands with different method names but the same unique_id will
|
2018-03-19 17:17:53 +01:00
|
|
|
* be considered aliases, and only the first registered method name will
|
|
|
|
* show up in the help text command listing. Aliased commands do not have
|
|
|
|
* to have the same behavior. Server and client code can distinguish
|
|
|
|
* between calls based on method name, and aliased commands can also
|
|
|
|
* register different names, types, and numbers of parameters.
|
2016-01-20 15:15:29 +01:00
|
|
|
*/
|
|
|
|
bool appendCommand(const std::string& name, const CRPCCommand* pcmd);
|
2021-11-01 12:24:34 +01:00
|
|
|
bool removeCommand(const std::string& name, const CRPCCommand* pcmd);
|
2012-04-21 01:37:34 +02:00
|
|
|
};
|
|
|
|
|
2017-09-27 14:38:03 +02:00
|
|
|
bool IsDeprecatedRPCEnabled(const std::string& method);
|
|
|
|
|
2016-01-20 15:15:29 +01:00
|
|
|
extern CRPCTable tableRPC;
|
2013-05-30 15:51:41 +02:00
|
|
|
|
2021-06-29 12:46:52 +02:00
|
|
|
void 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
2015-01-23 07:53:17 +01:00
|
|
|
void InterruptRPC();
|
|
|
|
void StopRPC();
|
2017-10-12 14:53:33 +02:00
|
|
|
std::string JSONRPCExecBatch(const JSONRPCRequest& jreq, const UniValue& vReq);
|
2014-12-09 02:17:57 +01:00
|
|
|
|
2018-04-02 00:30:17 +02:00
|
|
|
#endif // BITCOIN_RPC_SERVER_H
|