The parallel router aborts as soon as any of the routers have completed their search. This is problematic if we first we publish and then search because publishing will store a copy of the record in our datastore during the put
If the LAN DHT is much smaller than the WAN DHT (e.g. the normal online case) or the WAN DHT is much smaller than the LAN DHT (e.g. an offline case or one using a segregated network like CJDNS) then one of the DHTs will return immediately with a single record (the one previously published) and therefore cause an abort of the other DHT query.
@wenyue Thanks for pointing this out. If you would like to address this issue, please consider submitting a pull request. Your contribution would be greatly appreciated!
The dual DHT uses the parallel router SearchValue:
https://github.com/libp2p/go-libp2p-kad-dht/blob/57a258ff447b13a34ee75c2de13911d98fa0706c/dual/dual.go#L345-L348
The parallel router aborts as soon as any of the routers have completed their search. This is problematic if we first we publish and then search because publishing will store a copy of the record in our datastore during the put
https://github.com/libp2p/go-libp2p-kad-dht/blob/57a258ff447b13a34ee75c2de13911d98fa0706c/routing.go#L62
and then when we do a search we will get that record:
https://github.com/libp2p/go-libp2p-kad-dht/blob/57a258ff447b13a34ee75c2de13911d98fa0706c/routing.go#L298
If the LAN DHT is much smaller than the WAN DHT (e.g. the normal online case) or the WAN DHT is much smaller than the LAN DHT (e.g. an offline case or one using a segregated network like CJDNS) then one of the DHTs will return immediately with a single record (the one previously published) and therefore cause an abort of the other DHT query.
@petar @Stebalien