mirror of
https://github.com/XRPLF/rippled.git
synced 2025-11-19 10:35:50 +00:00
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.