Skip to content
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

Some way to classify peers. #14

Open
spikebike opened this issue Oct 30, 2013 · 1 comment
Open

Some way to classify peers. #14

spikebike opened this issue Oct 30, 2013 · 1 comment
Labels

Comments

@spikebike
Copy link
Contributor

This DHT/BEP-0005 is a great way to find peers for any p2p program, not just torrent clients.

Of course if you aren't a bit-torrent client you likely want to find other similar peers. This would be trivial without evil peers that reply to any infohash. So you could just make an infohash from "I am p2p peer foo version 1.2.3x" and anyone else with that string could find you. Alas some peers will respond to any infohash request.

Can you think of any response from the supported commands that would help differentiate peers? Any idea how different bit-torrent clients that support unique functionality with peers running the same software detect each other? I'm trying to avoid just trying to connect to some socket because of complications for end users to forward extra ports through routers and the like.

A similar Kademlia implementation mentions families at:
https://github.com/telehash/telehash.org/blob/master/protocol.md#family-usage

Sounds ideal:

  • You can use all peers to help find someone in your family
  • Once you find family peers you reserve half off each bucket for peers in your family
  • increased resistance to malicious peers, flooding, and Sybil attacks.

I realize this may be outside the intended scope, but I figured it's worth mentioning just in case.

@nictuku
Copy link
Owner

nictuku commented Nov 10, 2013

It's an interesting idea, but it's indeed outside the scope of this library.

But I do think there are ways to do what you want - in a best effort attempt to segment your network. For example, you can agree on a certain id prefix for your nodes. Or you can agree on a certain prefix for the "token" value. Then you make your client treat others that have those ids or special tokens differently. To obscure what you're trying to do, you can use a bit of cryptography and set a token prefix that is based on a shared key and the id of the node.

Alternatively, you can add a new field in the bencoded messages that implements something similar to "family", and hope that existing clients won't break when looking a this new field.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants