Venus: Is DHT working as expected?

[mishmosh]

Possible bug, to be verified and/or fixed:

From Slack Dec 3, 2018:

mishmosh: Why do you need to manually connect to a node before accepting/proposing deals, in addition to connecting to the test-cluster?

@frrist:
I believe this is because we lack a DHT (although I believe we plan to have one). In IPFS land we can look up the address(s) a peer is dialable on from the DHT, the peerID is a key and the values are diable addresses. Since we lack the ability to discover peer address we must connect manually. @whyrusleeping can you correct me if I am wrong here?

@whyrusleeping:
I had thought that we started using the dht

@frrist:
hhumm, looks like you are right - https://github.com/filecoin-project/go-filecoin/blob/master/node/node.go#L167

@frrist:
The need to manually connect could indicate that the peers dialable address isn't being stored in the DHT, we may need to verify this

Note: If this is no longer needed, please update the wiki's "2. Getting Started" section to remove the manual connection step (bottom of page).

[mishmosh]

Possibly related to https://github.com/filecoin-project/go-filecoin/issues/38 and https://github.com/filecoin-project/go-filecoin/issues/1440

[ZenGround0]

Description

Looking at the implementation of ProposeDeal the StorageProtocol does not require that peers be connected directly before making a deal, it only requires that the client be on the same network as the miner and that the miner has correctly advertised their address in the filecoin lookup service (implemented by dht IIRC).

Acceptance Criteria

We should confirm that the above is actually the case. If not escalate this issue to handle fixing automatic miner lookup.

Improve documentation to make it clear that this can be done automatically under the right circumstances. Improve documentation to make it clear that init --cluster-nightly automatically connects to peers as suggested by @mosh.

[phritz]

• update docs
• provide any tooling necessary to walk the DHT (or ask libp2p to provide)

[phritz]

Addl Acceptance criteria:

• have mosh try it and give the thumbs up

[ZenGround0]

Correction: the DHT is not currently working as we want. We see error: Error: failed to establish connection with the peer: routing: not found upon dialing a peer by peer id that we are not directly connected to. From vyzo on irc: "this means that the peer was not found in the DHT at all".

It appears that this issue is orthogonal to the issues addressed by adding relays to the network so removing the blocker for now.

--edit--
Flagging that this is potentially a good candidate issue to hand off to the libp2p team. A go-filecoin dev could also pair up with a libp2p dev on this one. cc @whyrusleeping @phritz

[ZenGround0]

@phritz I am currently under the impression that the output of this issue is to

1. Get the filecoin DHT in a state where discovery works automatically and clients do not need to get miner network addresses out of band and then run swarm connect.
2. Update docs to reflect this.

If I've got it wrong please post correct acceptance criteria here.

[ZenGround0]

Writing down some unexpected observations.

Running two nodes built on c4b642bea8f6b767a333c8c7dac8a673b163dc98 (relays in place but no DHT Bootstrap call). When I start up a node on a digital ocean instance and a node on my local computer (connecting both to nightly cluster) both nodes discover each other automatically and each multiaddr is in the others swarm peers almost immediately. Stranger still my local node's address as seen by DO vm is my acutal ip address (found with google) listening on port 6000 (how did it find this?!). Furthermore a storage deal proposal sent from the DO vm is immediately accepted by a miner set up on the local node.

How is this possible? As far as I know I am behind a NAT (autonat detection service always finds that local node is not publically dialable and so my node gets a relay address). Even though my local node gets relay addresses added to swarm peers by autorelay eventually these relay addresses do not show up in the swarm peers of the DO vm node so it looks as thought the DO vm isn't using the autorelay functionality to discover. AND this non relay address (which autonat thinks is NOT dialable?) seems to be used to dial my local node error free.

Is this DHT magic somehow opened up by autorelay? I haven't tried this exact scenario with pre-relay nodes but a similar automatic connection happens when I start an iptb local testbed and don't connect and I recall that this automatic connection did not happen before.

cc @vyzo @whyrusleeping any ideas how this is working and how I can start nodes that do not automatically become peers so I can test out DHT routing?

[vyzo]

The autorelay addrs should show eventually up by virtue of identify/push -- that's the push protocol for address update.
It is possible that you connected in reverse, the NATed node connected to the DO node -- is that latter NATed?

[phritz]

@ZenGround0 i'm not following but keenly interested, will track you down in a day or so to try to understand the mystery