d4fd5e4fce
This introduces a considerable change in the way that peers handshake. Instead of sending the TMHello protocol message, the peer making the connection (client role) sends an HTTP Upgrade request along with some special headers. The peer acting in the server role sends an HTTP response completing the upgrade and transition to RTXP (Ripple Transaction Protocol, a.k.a. peer protocol). If the server has no available slots, then it sends a 503 Service Unavailable HTTP response with a JSON content-body containing IP addresses of other servers to try. The information that was previously contained in the TMHello message is now communicated in the HTTP request and HTTP response including the secure cookie to prevent man in the middle attacks. This information is documented in the overlay README.md file. To prevent disruption on the network, the handshake feature is rolled out in two parts. This is part 1, where new servents acting in the client role will send the old style TMHello handshake, and new servents acting in the server role can automatically detect and accept both the old style TMHello handshake, or the HTTP request accordingly. This detection happens in the Server module, which supports the universal port. An experimental .cfg setting allows clients to instead send HTTP handshakes when establishing peer connections. When this code has reached a significant fraction of the network, these clients will be able to establish a connection to the Ripple network using HTTP handshakes. These changes clean up the handling of the socket for peers. It fixes a long standing bug in the graceful close sequence, where remaining data such as the IP addresses of other servers to try, did not get sent. Redundant state variables for the peer are removed and the treatment of completion handlers is streamlined. The treatment of SSL short reads and secure shutdown is also fixed. Logging for the peers in the overlay module are divided into two partitions: "Peer" and "Protocol". The Peer partition records activity taking place on the socket while the Protocol partition informs about RTXP specific actions such as transaction relay, fetch packs, and consensus rounds. The severity on the log partitions may be adjusted independently to diagnose problems. Every log message for peers is prefixed with a small, unique integer id in brackets, to accurately associate log messages with peers. HTTP handshaking is the first step in implementing the Hub and Spoke feature, which transforms the network from a homogeneous network where all peers are the same, into a structured network where peers with above average capabilities in their ability to process ledgers and transactions self-assemble to form a backbone of high powered machines which in turn serve a much larger number of 'leaves' with lower capacities with a goal to improve the number of transactions that may be retired over time.
src
Some of these directories come from entire outside repositories brought in using git-subtree. This means that the source files are inserted directly into the rippled repository. They can be edited and committed just as if they were normal files.
However, if you create a commit that contains files both from a subtree, and from the ripple source tree please use care when designing the commit message, since it will appear in the subtree's individual repository when the changes are pushed back to the upstream.
When submitting pull request, make sure that any commits which include files from subtrees are isolated - i.e. do not mix files from subtrees and ripple in the same commit. This way, the commit message will make sense. We don't want to see "Fix pathfinding bug with XRP" appearing in the LevelDB or Beast commit log, for example.
About git-subtree:
https://github.com/apenwarr/git-subtree
http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
| dir | What |
|---|---|
| beast | Beast, the amazing cross-platform library. git@github.com:vinniefalco/Beast.git |
./beast
Beast, the amazing cross-platform library.
Repository
git@github.com:vinniefalco/Beast.git
Branch
master
HyperLevelDB
Ripple's fork of HyperLevelDB
Repository
git@github.com:ripple/HyperLevelDB.git
Branch
ripple-fork
LevelDB
Ripple's fork of LevelDB.
Repository
git@github.com:ripple/LevelDB.git
Branch
ripple-fork
LightningDB (a.k.a. MDB)
Ripple's fork of MDB, a fast memory-mapped key value database system.
Repository
git@github.com:ripple/LightningDB.git
Branch
ripple-fork
websocket
Ripple's fork of websocketpp has some incompatible changes and Ripple specific includes.
Repository
git@github.com:ripple/websocketpp.git
Branch
ripple-fork
protobuf
Ripple's fork of protobuf. We've changed some names in order to support the unity-style of build (a single .cpp added to the project, instead of linking to a separately built static library).
Repository
git@github.com:ripple/protobuf.git
Branch
master
NOTE Linux builds use the protobuf installed in /usr/lib. This will be fixed in a future revision.
SQLite
Not technically a subtree but included here because it is a direct copy of the official SQLite distributions available here: