Peer discovery regression on Windows #5146
Comments
|
Does this not happen on Linux? On a hunch... try waiting a minute first. My guess is that this is happening because:
I believe this initial IPNS republish may have acted like a DHT bootstrap, making your node findable in the DHT (usually). |
|
Try setting the following line to 0: |
|
I haven't tried this exact example on linux, but on macOS it works on 0.4.15. Our js-ipfs-api tests are passing on linux and macOS also. I have just tried leaving the example for over 10 minutes now and it's still reporting 0 peers. I have Windows Defender turned off btw. I'll try the |
|
Hm. Damn. The usual rule here is: "when in doubt, blame reuseport" but that shouldn't be the issue here. However, just to check, try running with the environment variable |
|
@Stebalien this is an mdns issue, not a DHT issue |
|
however, it looks like our mdns lib hasnt been updated in over a year. |
|
@alanshaw in your example above for 0.4.13, the two nodes your nodes are getting connections to are not eachother, its two bootstrap nodes. |
|
Looking into the js-ipfsd-ctl code, it seems that it replaces the config file uses with this one: https://github.com/ipfs/js-ipfsd-ctl/blob/master/src/defaults/config.json This explicitly does not have mdns enabled, which requires a section like: "Discovery": {
"MDNS": {
"Enabled": true,
"Interval": 10
}
},The weird bit though, is that it also doesnt have any bootstrap nodes. So i'm not sure why the 0.4.13 daemon would be connecting to them... |
|
Does go-ipfs-dep use a precompiled IPFS or does it recompile it? Our MDNS library has some memory safety issues so the version of go it's compiled with may make a difference. |
|
To address some of the comments above:
True! They do sometimes find each other though, but this can take many minutes. The other thing is that with 0.4.13 the nodes do accumulate peers over time (hundreds) after a minute:
With 0.4.15 no peers, nada, forever:
When I run this on macOS the output from the script is basically this every time:
Note: I modified the script a little, see below for updated version
Yes, but when inspecting the config using
It'll download a precompiled version if it has one for you system. Most node modules with a native aspect will do that and fallback to compiling on your system if not. I'm not sure if go-ipfs-dep does that. I'd hope so. In this case, a precompiled version IS being downloaded and used. I modified the script a little for anyone who wants to try this. Adds peer IDs and colorizes the IDs for the two nodes we're spawning in red/blue. // npm i async chalk ipfsd-ctl go-ipfs-dep
const auto = require('async/auto')
const IPFSFactory = require('ipfsd-ctl')
const chalk = require('chalk')
const factory = IPFSFactory.create()
console.log('spawning 2 nodes...')
auto({
ipfsd0: (cb) => factory.spawn(cb),
ipfsd1: (cb) => factory.spawn(cb),
id0: ['ipfsd0', ({ ipfsd0 }, cb) => ipfsd0.api.id(cb)],
id1: ['ipfsd1', ({ ipfsd1 }, cb) => ipfsd1.api.id(cb)]
}, (err, res) => {
if (err) throw err
res.ipfsd0.peerId = res.id0
res.ipfsd1.peerId = res.id1
res.ipfsd0.color = chalk.red
res.ipfsd1.color = chalk.blue
console.log(`spawned node with ID ${chalk.red(res.ipfsd0.peerId.id)}`)
console.log(`spawned node with ID ${chalk.blue(res.ipfsd1.peerId.id)}`)
waitForPeer(res.ipfsd0, res.ipfsd1)
waitForPeer(res.ipfsd1, res.ipfsd0)
})
function waitForPeer (ipfsd, otherIpfsd) {
const coloredId = (id) => {
if (id === ipfsd.peerId.id) return ipfsd.color(id)
if (id === otherIpfsd.peerId.id) return otherIpfsd.color(id)
return id
}
ipfsd.api.swarm.peers((err, peers) => {
if (err) throw err
console.log(`node ${coloredId(ipfsd.peerId.id)} has ${peers.length} peers:`)
peers.forEach((p, i) => {
console.log(` ${i + 1}. ${coloredId(p.peer.toB58String())}`)
})
const found = peers.some(p => p.peer.toB58String() === otherIpfsd.peerId.id)
if (!found) return setTimeout(() => waitForPeer(ipfsd, otherIpfsd), 1000)
ipfsd.stop()
})
} |
|
Another data point: If I run |
|
@alanshaw port zero shouldnt make a difference. The other difference i see is that ipfsd-ctl doesnt add any bootstrap nodes. No bootstrap nodes means no connections. Unless you are explicitly adding bootstrap nodes, seeing no connections is the expected behaviour. The behavior on 0.4.13 is the weird one to me |
|
I've logged out the response from 0.4.13
0.4.15
I'm going to explicitly start the nodes with those bootstrap servers just incase |
|
Explicitly adding those bootstrap addrs doesn't change anything. If I set |
|
Ok I think I have found the issue: On Windows in 0.4.14 and 0.4.15 if you set If you set
|
|
Try logging the commands on the IPFS daemon, running on both 5001 and on a different port. I'm guessing you'll see something run a command on the 5001 daemon but not the other. There's probably some test tool using the default port. |
|
That is, try the command |
|
Is there any workaround to get peers with API port different than |
|
Yes! I believe this is fixed in go-ipfs 0.4.16 🎉 With 0.4.15 you can see the behaviour on windows if you take the following steps (I'm using the git bash so it's unix like):
By default If you do the exact same steps using go-ipfs 0.4.16 it works, so I believe this is fixed. |
|
Ah. That makes more sense. It has nothing to do with the API port, right? Looks like https://github.com/libp2p/go-libp2p/blob/master/NEWS.md#dialing-and-source-addresses. Closing as that issue has been fixed. |
Version information:
Regression between 0.4.13 and 0.4.14/0.4.15
Type:
Bug
Description:
On Windows, two nodes spawned on the same machine do not discover each other in 0.4.14 or 0.4.15, but they used to in 0.4.13.
The following demonstrates this error:
Install
ipfsd-ctlandgo-ipfs0.4.13:Create file
test-peer-discovery.jsand add the following:Run:
Output:
Now install
go-ipfs0.4.14 or 0.4.15:Re-run, and output is now:
This seems to be the reason why our
js-ipfs-apitests requiring connected nodes are failing.The text was updated successfully, but these errors were encountered: