• Wladimir J. van der Laan's avatar
    evhttpd implementation · 14e2a138
    Wladimir J. van der Laan authored
    - *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
    14e2a138
Makefile.am 9.98 KB