Skip to content
This repository was archived by the owner on Sep 6, 2022. It is now read-only.

Commit 371a34d

Browse files
Stebalienwillscott
andauthored
doc(event): document network events (#129)
Add extensive documentation to network events to explain the edge-cases. Co-authored-by: Will <will@cypherpunk.email>
1 parent ab2bf16 commit 371a34d

File tree

1 file changed

+45
-6
lines changed

1 file changed

+45
-6
lines changed

event/network.go

+45-6
Original file line numberDiff line numberDiff line change
@@ -5,12 +5,51 @@ import (
55
"github.com/libp2p/go-libp2p-core/peer"
66
)
77

8-
// EvtPeerConnectednessChanged should be emitted every time we form a connection with a peer or drop our last
9-
// connection with the peer. Essentially, it is emitted in two cases:
10-
// a) We form a/any connection with a peer.
11-
// b) We go from having a connection/s with a peer to having no connection with the peer.
12-
// It contains the Id of the remote peer and the new connectedness state.
8+
// EvtPeerConnectednessChanged should be emitted every time the "connectedness" to a
9+
// given peer changes. Specifically, this event is emitted in the following
10+
// cases:
11+
//
12+
// * Connectedness = Connected: Every time we transition from having no
13+
// connections to a peer to having at least one connection to the peer.
14+
// * Connectedness = NotConnected: Every time we transition from having at least
15+
// one connection to a peer to having no connections to the peer.
16+
//
17+
// Additional connectedness states may be added in the future. This list should
18+
// not be considered exhaustive.
19+
//
20+
// Take note:
21+
//
22+
// * It's possible to have _multiple_ connections to a given peer.
23+
// * Both libp2p and networks are asynchronous.
24+
//
25+
// This means that all of the following situations are possible:
26+
//
27+
// A connection is cut and is re-established:
28+
//
29+
// * Peer A observes a transition from Connected -> NotConnected -> Connected
30+
// * Peer B observes a transition from Connected -> NotConnected -> Connected
31+
//
32+
// Explanation: Both peers observe the connection die. This is the "nice" case.
33+
//
34+
// A connection is cut and is re-established.
35+
//
36+
// * Peer A observes a transition from Connected -> NotConnected -> Connected.
37+
// * Peer B observes no transition.
38+
//
39+
// Explanation: Peer A re-establishes the dead connection. Peer B observes the
40+
// new connection form before it observes the old connection die.
41+
//
42+
// A connection is cut:
43+
//
44+
// * Peer A observes no transition.
45+
// * Peer B observes no transition.
46+
//
47+
// Explanation: There were two connections and one was cut. This connection
48+
// might have been in active use but neither peer will observe a change in
49+
// "connectedness". Peers should always make sure to re-try network requests.
1350
type EvtPeerConnectednessChanged struct {
14-
Peer peer.ID
51+
// Peer is the remote peer who's connectedness has changed.
52+
Peer peer.ID
53+
// Connectedness is the new connectedness state.
1554
Connectedness network.Connectedness
1655
}

0 commit comments

Comments
 (0)