New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected Deduplication behavior. Is it supposed to work like this? #75
Comments
Are the duplicate peers not getting dropped? I see you're only tracking peer-add |
If you can post a full example, I can also try to see myself. |
@mafintosh It is testing for Here is an example to reproduce the behavior: Current Output (on my machine):
Note: That the second stream is closed all that often seems unintuitive. |
No that's supposed to happen. It doesn't know it needs dedup until it has the second dup - that's why the second stream closes after as well. with the key addressing scheme in the swarm upgrade this is a bit easier to deal with upfront thankfully so hopefully down the line we can make that simpler. |
Thank you for checking it. I am looking forward to the upgrade. |
Working on a PR for adding holepunchto/hypercore#291 to corestore-networker I noticed that on my local network two streams per local instance get opened (4 streams for 2 instances, per instance: one for peer:
<IPV4>
and one for peer::ffff:<IPV4>
). This seems like a bug but I am not sure.(Test code):
(of the two outputs
nw1-add
andnw2-add
it will output one twice and one once)Looking at the duplication logic the two streams have indeed the same id, so the second stream on both instances triggers: https://github.com/hyperswarm/hyperswarm/blob/e4c51a407fb9e0e8fdcece461fc4917c2d5b23d2/lib/queue.js#L89-L91
and particularly the second line seems strange:
cmp < 0
. This means that one of the instances always returnstrue
while the other always returnsfalse
as thelocalId
is randomly generated. This means that on one instance the second stream will be identified as "duplicate" while on the other is not.As a consequence we have two peers added on one instance while we have only one peer added on the second. Does that seem right?
The text was updated successfully, but these errors were encountered: