swarm and whisper are doing, in their respective libraries inside that repository
@fjl I think in the implementation advice it would be a good idea to draw attention to the Maykounkov/Mazieres implementation advice section "4.1 Optimized Contact Accounting". (https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf ) That version of the paper, with those implementation details, in my opinion dramatically changes the protocol.
Also I think Recursive Lookup is a misnomer (minor nitpick). A node instance's lookup process is iterative (1. Call 3 nodes with FindNode 2. Asynchronously collate results. 3. Wait on a semaphore for any of the 3 lookups to complete. 4. Check if there are new nodes in the k-sized nearest targets list 5. Launch a new FindNode asynchronous process) From the overall network perspective, the process is recursive in the sense that an incoming FindNode may trigger a FindNode in another node, which may trigger a FindNode etc etc... which will only continue meaningfully until the original FindNode's timeout expires, or until a downstream node actually finds the target.
Hi, for information: just merged the light client protocol (LES/2) implementation of the ethereumjs-devp2p library and published as v2.5.0 on npm: https://www.npmjs.com/package/ethereumjs-devp2p
If you want to try it out, have a look at the peer-communication-les.js example in the examples folder.
Related to: Devp2p [Go]
Scope: Only using Devp2p module.
Discovery Protocol: Using a bootnode with DiscoveryV5 enabled
P2PServer Config Looks like this:
p2pServerConfig := p2p.Config {
PrivateKey: privKey,
Name: name,
MaxPeers: 3,
Protocols: []p2p.Protocol{protocol},
ListenAddr: fmt.Sprintf(":%d", port),
DiscoveryV5: true,
BootstrapNodesV5: bootstrapNodesV5,
NAT: nat.Any(),
}After stating the p2p server I am assuming my node will connect to the bootnode and query for adjacent nodes. Upon receiving the information about the adjacent nodes Devp2p will automatically (Devp2p will take care of this) connect to these nodes and I can check it with the following code:
var connected bool
for !connected {
time.Sleep(time.Millisecond * 50)
connected = server.PeerCount() > 0
}
fmt.Println("Connected to peer.")Is this assumption correct or do I have to listen for some events and connect to the nodes using AddPeer() method?
Currently my node is busy waiting in the "connected" loop forever with 0 peer count and bootnode displays:
TRACE[03-26|00:49:54] <-net.queryReq
TRACE[03-26|00:49:54] <-net.queryReq
TRACE[03-26|00:49:54] >>> findnodeHashPacket to b3ba260d465ba8a0@127.0.0.1:3000
TRACE[03-26|00:49:54] <-net.queryReq
TRACE[03-26|00:49:54] >>> findnodeHashPacket to 8a4aa4f80a51c393@127.0.0.1:3001
TRACE[03-26|00:50:19] <-net.read
TRACE[03-26|00:50:19] >>> neighborsPacket to b3ba260d465ba8a0@127.0.0.1:3000
TRACE[03-26|00:50:32] <-net.read
TRACE[03-26|00:50:32] >>> neighborsPacket to 8a4aa4f80a51c393@127.0.0.1:3001
[2018-04-04T13:51:37.091] [INFO] EthereumNode - WARN [04-04|13:51:37] Rolled back headers count=96 header=5098559->5098559 fast=0->0 block=0->0
[2018-04-04T13:51:37.094] [INFO] EthereumNode - WARN [04-04|13:51:37] Synchronisation failed, dropping peer peer=138ec659b5ec0202 err="retrieved hash chain is invalid"
@all has there been any research into how the networking side of things will look with sharding? I read https://ethresear.ch/t/a-minimal-sharding-protocol-that-may-be-worthwhile-as-a-development-target-now/1650 and the following piqued my interest:
The capability of having 100 separate shard p2p networks, and building and sending collations across those networks
Would love to get some feedback on this in case you have some spare time :)