coosld/kubo
1
0
Fork 0
mirror of https://github.com/ipfs/kubo.git synced 2026-02-23 11:27:42 +08:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity
e017d6edc6
kubo/net/handshake
History
Juan Batiz-Benet c84a714b16 peer change: peer.Peer -> peer.ID 
this is a major refactor of the entire codebase
it changes the monolithic peer.Peer into using
a peer.ID and a peer.Peerstore.

Other changes:
- removed handshake3.
-	testutil vastly simplified peer
-	secio bugfix + debugging logs
-	testutil: RandKeyPair
-	backpressure bugfix: w.o.w.
-	peer: added hex enc/dec
-	peer: added a PeerInfo struct
  PeerInfo is a small struct used to pass around a peer with
 	a set of addresses and keys. This is not meant to be a
 	complete view of the system, but rather to model updates to
 	the peerstore. It is used by things like the routing system.
-	updated peer/queue + peerset
-	latency metrics
-	testutil: use crand for PeerID gen
 	RandPeerID generates random "valid" peer IDs. it does not
 	NEED to generate keys because it is as if we lost the key
 	right away. fine to read some randomness and hash it. to
 	generate proper keys and an ID, use:
 	  sk, pk, _ := testutil.RandKeyPair()
 	  id, _ := peer.IDFromPublicKey(pk)
 	Also added RandPeerIDFatal helper
- removed old spipe
- updated seccat
- core: cleanup initIdentity
- removed old getFromPeerList
2014-12-23 08:33:32 -08:00
..
pb peer change: peer.Peer -> peer.ID 2014-12-23 08:33:32 -08:00
doc.go copy handshake readme into a doc.go for pretty godoc results 2014-11-08 21:42:37 -08:00
handshake1_test.go handshake1 renaming 2014-10-22 04:56:18 -07:00
handshake1.go peer change: peer.Peer -> peer.ID 2014-12-23 08:33:32 -08:00
README.md minimal doc on handshake 2014-10-22 13:10:55 -07:00

README.md

IFPS Handshake

The IPFS Protocol Handshake is divided into three sequential steps

  1. Version Handshake (Hanshake1)
  2. Secure Channel (NewSecureConn)
  3. Services (Handshake3)

Currently these parts currently happen sequentially (costing an awful 5 RTT), but can be optimized to 2 RTT.

Version Handshake

The Version Handshake ensures that nodes speaking to each other can interoperate. They send each other protocol versions and ensure there is a match on the major version (semver).

Secure Channel

The second part exchanges keys and establishes a secure comm channel. This follows ECDHE TLS, but isn't TLS. (why will be written up elsewhere).

Services

The Services portion sends any additional information on nodes needed by the nodes, e.g. Listen Address (the received address could be a Dial addr), and later on can include Service listing (dht, exchange, ipns, etc).