Skip to content

Commit

Permalink
Revert "Add ProtocolStart and GracefulClose P2P protocol messages (XR…
Browse files Browse the repository at this point in the history
…PLF#3839)" (XRPLF#4850)

This reverts commit 8f89694.
  • Loading branch information
Bronek authored and sophiax851 committed Jun 12, 2024
1 parent 5dcb1e7 commit 2c5d9ed
Show file tree
Hide file tree
Showing 14 changed files with 140 additions and 565 deletions.
1 change: 0 additions & 1 deletion Builds/CMake/RippledCore.cmake
Original file line number Diff line number Diff line change
Expand Up @@ -637,7 +637,6 @@ target_sources (rippled PRIVATE
src/ripple/overlay/impl/Cluster.cpp
src/ripple/overlay/impl/ConnectAttempt.cpp
src/ripple/overlay/impl/Handshake.cpp
src/ripple/overlay/impl/InboundHandoff.cpp
src/ripple/overlay/impl/Message.cpp
src/ripple/overlay/impl/OverlayImpl.cpp
src/ripple/overlay/impl/PeerImp.cpp
Expand Down
17 changes: 9 additions & 8 deletions src/ripple/overlay/Message.h
Original file line number Diff line number Diff line change
Expand Up @@ -100,14 +100,6 @@ class Message : public std::enable_shared_from_this<Message>
return validatorKey_;
}

/** Get the message type from the payload header.
* First four bytes are the compression/algorithm flag and the payload size.
* Next two bytes are the message type
* @return Message type
*/
int
getType() const;

private:
std::vector<uint8_t> buffer_;
std::vector<uint8_t> bufferCompressed_;
Expand Down Expand Up @@ -137,6 +129,15 @@ class Message : public std::enable_shared_from_this<Message>
*/
void
compress();

/** Get the message type from the payload header.
* First four bytes are the compression/algorithm flag and the payload size.
* Next two bytes are the message type
* @param in Payload header pointer
* @return Message type
*/
int
getType(std::uint8_t const* in) const;
};

} // namespace ripple
Expand Down
1 change: 0 additions & 1 deletion src/ripple/overlay/Peer.h
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,6 @@ enum class ProtocolFeature {
ValidatorListPropagation,
ValidatorList2Propagation,
LedgerReplay,
StartProtocol
};

/** Represents a peer connection in the overlay. */
Expand Down
44 changes: 0 additions & 44 deletions src/ripple/overlay/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -365,50 +365,6 @@ transferred between A and B and will not be able to intelligently tamper with th
message stream between Alice and Bob, although she may be still be able to inject
delays or terminate the link.

## Peer Connection Sequence

The _PeerImp_ object can be constructed as either an outbound or an inbound peer.
The outbound peer is constructed by the _ConnectAttempt_ - the client side of
the connection. The inbound peer is constructed by the _InboundHandoff_ -
the server side of the connection. This differentiation of the peers matters only
in terms of the object construction. Once constructed, both inbound and outbound
peer play the same role.

### Outbound Peer

An outbound connection is initiated once a second by
the _OverlayImpl::Timer::on_timer()_ method. This method calls
_OverlayImpl::autoConnect()_, which in turn calls _OverlayImpl::connect()_ for
every outbound endpoint generated by _PeerFinder::autoconnect()_. _connect()_
method constructs _ConnectAttempt_ object. _ConnectAttempt_ attempts to connect
to the provided endpoint and on a successful connection executes the client side
of the handshake protocol described above. If the handshake is successful then
the outbound _PeerImp_ object is constructed and passed to the overlay manager
_OverlayImpl_, which adds the object to the list of peers and children. The latter
maintains a list of objects which might be executing an asynchronous operation
and therefore have to be stopped on shutdown. The outbound _PeerImp_ sends
_TMStartProtocol_ message on start to instruct the connected inbound peer that
the outbound peer is ready to receive the protocol messages.

### Inbound Peer

Construction of the inbound peer is more involved. A multi protocol-server,
_ServerImpl_ located in _src/ripple/server_ module, maintains multiple configured
listening ports. Each listening port allows for multiple protocols including HTTP,
HTTP/S, WebSocket, Secure WebSocket, and the Peer protocol. For simplicity this
sequence describes only the Peer protocol. _ServerImpl_ constructs
_Door_ object for each configured protocol. Each instance of the _Door_ object
accepts connections on the configured port. On a successful connection the _Door_
constructs _SSLHTTPPeer_ object since the Peer protocol always uses SSL
connection. _SSLHTTPPeer_ executes the SSL handshake. If the handshake is successful
then a server handler, _ServerHandlerImpl_ located in _src/ripple/src/impl_, hands off
the connection to the _OverlayImpl::onHandoff()_ method. _onHandoff()_ method
validates the client's HTTP handshake request described above. If the request is
valid then the _InboundHandoff_ object is constructed. _InboundHandoff_ sends
HTTP response to the connected client, constructs the inbound _PeerImp_ object,
and passes it to the overlay manager _OverlayImpl_, which adds the object to
the list of peers and children. Once the inbound _PeerImp_ receives
_TMStartProtocol_ message, it starts sending the protocol messages.

# Ripple Clustering #

Expand Down
185 changes: 0 additions & 185 deletions src/ripple/overlay/impl/InboundHandoff.cpp

This file was deleted.

102 changes: 0 additions & 102 deletions src/ripple/overlay/impl/InboundHandoff.h

This file was deleted.

Loading

0 comments on commit 2c5d9ed

Please sign in to comment.