| Age | Commit message (Collapse) | Author |
|---|
|
similar to secp256k1 include and compile univalue over a subtree
|
|
- *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
|
|
When no `-rpcpassword` is specified, use a special 'cookie' file for
authentication. This file is generated with random content when the
daemon starts, and deleted when it exits. Read access to this file
controls who can access through RPC. By default this file is stored in
the data directory but it be overriden with `-rpccookiefile`.
This is similar to Tor CookieAuthentication: see
https://www.torproject.org/docs/tor-manual.html.en
Alternative to #6258. Like that pull, this allows running bitcoind
without any manual configuration. However, daemons should ideally never write to
their configuration files, so I prefer this solution.
|
|
|
|
|
|
- implement find_value() function for UniValue
- replace all Array/Value/Object types with UniValues, remove JSON Spirit to UniValue wrapper
- remove JSON Spirit sources
|
|
|
|
|
|
Github-Pull: #5494
Rebased-From: 15de949bb9277e442302bdd8dee299a8d6deee60
|
|
- I saw this on http://en.cppreference.com/w/cpp/language/try_catch and
thought it would be a good idea
- also unify used format to better be able to search for exception
uses in our codebase
|
|
|
|
|
|
Start the RPC server before doing all the (expensive) startup
initialisations like loading the block index. Until the node is ready,
return all calls immediately with a new error signalling "in warmup"
with an appropriate status message (similar to the init message).
This is useful for RPC clients to know that the server is there (e. g.,
they don't have to start it) but not yet available. It is used in
Namecoin and Huntercoin already for some time, and there exists a UI
hooked onto the RPC interface that actively uses this to its advantage.
|
|
|
|
submitblock
|
|
- ensures a consistent usage in header files
- also add a blank line after the copyright header where missing
- also remove orphan new-lines at the end of some files
|
|
The size limit makes a lot of sense for the server, as it never has to
accept very large data.
The client, however, can request arbitrary amounts of data with
`listtransactions` on a large wallet.
Fixes #4604.
|
|
Split up HTTPReply into HTTPReply and HTTPReplyHeader, so that
the message data can be streamed directly.
Also removes a c_str(), which would have prevented binary
output with NUL characters in it.
|
|
After pull #4288, RPC messages indicating errors have a Content-Length unrelated
to their actual contents, rendering bitcoin-cli and curl unable to decode the
reply.
This patch sets the Content-Length field based on the actual content returned.
Additionally, pull #4288 clobbered the error descriptions provided in
ErrorReply, which bitcoin-cli relies upon; this patch moves #4288 http-error
descriptions to an HTTPError method, allowing HTTPReply to pass content on
unchanged.
|
|
Also, add parens to HTTPReply() to assist readability.
|
|
1) support varying content types
2) support only sending the header
3) properly deliver error message as content, if HTTP error
4) move AcceptedConnection class to header, for wider use
|
|
First query in the current way (intelligently determining which network
has a non-localhost interface). If this does not succeed, try plain
lookup.
Needed for testing.
Fixes #1827 by always allowing IPv6 to be used.
|
|
- Make it report the reject code and reason
- Make it possible to re-send transactions that are already in the mempool
|
|
in 2014.
contrib/devtools/fix-copyright-headers.py script to be able to perform this maintenance task with ease during the rest of the year, every year. Modifications to contrib/devtools/README.md to document what fix-copyright-headers.py does.
|
|
Currently it is only possible to use `walletpassphrase` to unlock the
wallet when bitcoin is started in server mode.
Almost everything that manipulates the wallet in the RPC console
needs the wallet to be unlocked and is thus unusable without -server.
This is pretty unintuitive to me, and I'm sure it's even more confusing
to users.
Solve this with a very minimal change: by making the GUI start a
dummy RPC thread just to handle timeouts.
|
|
Split bitcoinrpc up into
- rpcserver: bitcoind RPC server
- rpcclient: bitcoin-cli RPC client
- rpcprotocol: shared common HTTP/JSON-RPC protocol code
One step towards making bitcoin-cli independent from the rest
of the code, and thus a smaller executable that doesn't have to
be linked against leveldb.
This commit only does code movement, there are no functional changes.
|
