Conversation
I think we're good, actually. Go-ipfs can access what it needs by looking at the sub-DHTs directly. |
|
@willscott Do you want an additional review on this ? |
i wouldn't look too deeply at the parallel setups yet. i'll work on tests tomorrow and that'll get this code quite a bit cleaner. If you have comments on the interface / how it's interacting with the main DHT package, a glance wouldn't hurt. The main point of feedback from @Stebalien at this point is that the LAN dht shouldn't default to |
Do you mean: 1. If 2. If |
If the user has constructed the dht with an explicit |
Stebalien
left a comment
Stebalien
left a comment
There was a problem hiding this comment.
Couple of small nits but looks good otherwise.
|
|
||
| found := make(map[peer.ID]struct{}, count) | ||
| var pi peer.AddrInfo | ||
| for (zeroCount || count > 0) && (wanCh != nil || lanCh != nil) { |
There was a problem hiding this comment.
Ok, fine, this is definitely cleaner than the way I fixed this...
| if dht.activeWAN() { | ||
| return dht.WAN.Provide(ctx, key, announce) | ||
| } | ||
| return dht.LAN.Provide(ctx, key, announce) |
There was a problem hiding this comment.
@Stebalien @willscott I thought we were concerned about constantly providing/putting to people on our LANs. Did we decide that wasn't a big deal or am I missing something?
There was a problem hiding this comment.
this only does the puts/provides to the LAN-filtered DHT when there are no discovered peers in the WAN DHT routing table.
There was a problem hiding this comment.
oh right, I'm being silly didn't see the return 🤦
4 participants
address #567