Communications Module - current state and challenges

1.4.1 Transport Layer

trait TransportLayer[F[_]] {
  def local: F[PeerNode]
  def roundTrip(peer: PeerNode, msg: Protocol, timeout: FiniteDuration): F[CommErr[Protocol]]
  def send(peer: PeerNode, msg: Protocol): F[Unit]
  def broadcast(peers: Seq[PeerNode], msg: Protocol): F[Unit]
  def receive(dispatch: Protocol => F[CommunicationResponse]): F[Unit]
  def disconnect(peer: PeerNode): F[Unit]
  def shutdown(msg: Protocol): F[Unit]
}

1. local
   

   Method local returns PeerNode representing given running node. This method should be removed and PeerNode information should be provided via `ApplicativeAsk` abstraction (see CORE-738 and CORE739 for detail).

2. disconnect
   

   Method disconnect should never be part of TransportLayer abstraction. It is TcpTransportLayer implementation detail. It will be removed from the abstraction (see CORE-835 for details).

3. shutdown
   

   Shutdown method gracefully shuts down the Transport Layer. After being called, no message can be send (via roundTrip, send, broadcast) nor received.

4. roundTrip, send, broadcast
   

   Methods roundTrip and send allow sending and receiving messages of type Protocol - object defined in routing.proto. Protocol message can be one of the following:

   message Protocol {
       Header header                           = 1;
   
       oneof message {
           google.protobuf.Any upstream        = 2;
   
           Ping                ping            = 3;
           Pong                pong            = 4;
           Lookup              lookup          = 5;
           LookupResponse      lookup_response = 6;
           Disconnect          disconnect      = 7;
       }
   }
   

   1. Ping, Pong, Loookup, LookupResponse
      

      Ping+Pong and Lookup+LookupResponse are part of the Node Discovery abstraction, so there is clear coupeling between those two abstraction. More details in CORE-836.

   2. Disconnect
      

      Disconnect is currently send by TcpTransportLayer when it shuts down (Disconnect is being broadcast). This method is NOT needed as nodes should realize that other peers disconnect regardlessly if they managed to shut down gracefully or not. This message will be removed from the Protocol object (see CORE-838 for details).

   3. Any upstream
      

      This is a placeholder for ANY possible message that is build on top Protocol. Effectively this is where messages from RChain protocol will be placed. Originally was designed to decouple TransportLayer, NodeDiscovery and RChain protocol (not successfully). This coupeling should be removed, see CORE-839 for details.

      
      

1.4.2 Node Discovery

1. Relation to Transport Layer
   

   Node discovery is using Tranport Layer to fullfil its work. It uses

   +----------------+
   |                |
   | NODE DISCOVERY |
   |                |
   +----------------+
           |
           v uses
   
   +----------------+
   |   TRANSPORT    |
   |   LAYER        |
   +----------------+
   

   This is almost true, as mentioned in previous section, TransportLayer sends messages of type Protocol (routing.proto) that are very Kademlia specific. See CORE-838 and CORE-839 to see the issue how to remove that cyclic dependency between Node Discovery and Transport Layer.

   
   

    2. How current Kademlia implementation is different from the original paper

    3. Kademlia in etherum

       Etherum also uses its own Kademlia-like protocol. Description under https://github.com/ethereum/wiki/wiki/Kademlia-Peer-Selection

1.4.3 RChain protocol

message Protocol {
    oneof message {
        Disconnect                  diconnect                     = 1;
        Hello                       hello                         = 2;
        ProtocolHandshake           protocol_handshake            = 3;
        ProtocolHandshakeResponse   protocol_handshake_response   = 4;
        Packet                      packet                        = 5;
    }
}

RChain Protocol exposes few functionalities: