Skip to content

Latest commit

 

History

History
216 lines (126 loc) · 7.79 KB

File metadata and controls

216 lines (126 loc) · 7.79 KB

Basic Connectivity

Connection Handling

Two nodes connecting to each other should succeed

If two nodes are connecting to each other at the same time, they should be connected, so each one has exactly one connection.

Two Rust nodes shouldn't be disconnected for a while after they are connected

All connections should be tracked by the state machine

Connections that are initiated outside of the state machine (e.g. by Kademlia) should be present in the state machine.

Tests:

Number of active peers should not exceed configured maximum number

Tests:

Incoming Connections

Node should accept incoming connections

We should accept an incoming connection from an arbitrary node.

Tests:

Node shouldn't accept duplicate incoming connections

The Rust node should reject a connection from a peer if there is one with the same peer ID already.

Tests: TODO

Node shouldn't accept connection with its own peer_id

The node shouldn't accept a connection from a peer that uses the same peer id as this one. This is either a program error (see above), network setup error, or a malicious node that uses the same peer ID.

Tests:

Outgoing connections

Node should connect to other nodes

Node shouldn't try to make outgoing connection using its own peer_id

The node can obtain its address from other peers. It shouldn't use it when connecting to new peers.

Tests:

Node should connect to all available initial peers

TODO: what if the number of initial peers exceeds the max number of peers?

Node should retry connecting to unavailable initial peers

Node should be able to connect to initial peers eventually, even if initially they are not available.

If, for some reason, the node can't connect to enough peers (e.g. it is the first node in the network), it should keep retrying to those with failures (see also below).

TODO: Use cases where this is important.

Tests:

Node should have a reasonable retry rate for reconnection

We should consider different reasons why the outgoing connection failed. The Rust node shouldn't reconnect too soon to a node that dropped the connection.

Tests: TODO

Peers Discovery

Node advertises itself through Kademlia

Node should be able to perform initial peer selection (Kademlia "bootstrap")

During this stage, the node queries its existing peers for more peers, thus getting more peer addresses.

See #148.

Tests: TODO

Node should be able to select random peers for performing outgoing connections.

See #148.

To obtain a set of random peers, the Rust node performs a Kademlia query that returns a list of peers that are "close" to some random peer.

This step starts after Kademlia initialization is complete.

Node should only advertise its "real" address

This is one of the requirements of LibP2P's Kademlia implementation. E.g. the node behind NAT shouldn't advertise its address obtained using external "what-is-my-IP"-like services.

Tests: TODO

OCaml Node Interoperability

Peers Discovery

Advertising to OCaml nodes

Peer discovery via Rust node

If a Rust node is used as a seed node, OCaml nodes connected to it should be able to also discover and connect to each other.

Peer discovery using OCaml seed node

Incoming Connections

OCaml node should be able to successfully connect to a Rust node

Outgoing Connections

Rust node should be able to successfully connect to an OCaml node

General Safety

Peer Maintaining

Initial peer connection

The node should connect to as many peers as it is configured to (between min and max number).

Peer disconnection

The node should maintain a minimal number of peers in case it is disconnected from its existing peers.

Tests: TODO

Attacks Resistance

DDoS

Tests: TODO

Eclipse Attack

Tests: TODO

Sybil Attack

Tests: TODO