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

Any plans for Canonical Peer Priority #1406

Open
norzak opened this issue May 29, 2018 · 3 comments
Open

Any plans for Canonical Peer Priority #1406

norzak opened this issue May 29, 2018 · 3 comments

Comments

@norzak
Copy link

@norzak norzak commented May 29, 2018

Any plans to implement new bittorrent enhancement titled "Canonical Peer Priority"? which connects to geographically closer peers?

@SilentBot1

This comment has been minimized.

Copy link
Member

@SilentBot1 SilentBot1 commented Jun 10, 2018

Hey @norzak,

Just to make it easier for others, the BEP referenced is BEP40.

This seems like it could possibly be implemented within the ._drain function of the TCPOutgoingPeer queue _queue within torrent.js, prioritising the draining order based on priority calculated via the formula outlined in BEP40.

We would also need a way to determine the clients ip address as I don't believe we currently have a way.

I would love for somebody to double check this to make sure I'm not missing something.

@norzak

This comment has been minimized.

Copy link
Author

@norzak norzak commented Jun 11, 2018

Hi @SilentBot1,

On the webtorrent.io page, during streaming video from the peers, I see some IP addresses connecting to mine in a visual animation. Where are those IPs coming from?

@SilentBot1

This comment has been minimized.

Copy link
Member

@SilentBot1 SilentBot1 commented Jun 11, 2018

Hey @norzak,

After digging into it, if the peer is added via ip:port (so not a WebRTC peer) then this is just split and added to the wire object, if the peer is added via WebRTC offer the information is pulled from the offer.

After poking into the WebRTC offers a bit, it exposes both the local and remote ip address so that would make calculating the formula quite easy. The only issue I see with WebRTC is there is no queue, offers are responded to the instant they are received unlike TCP which has a queue of peers.

As for standard TCP peers, a package like public-ip would likely need to be used to discover the servers external IP when opearting behind a NAT to allow for calculation of the formula, though this wouldn't be needed if the torrent was operating locally within a LAN.

Most of this is me just writing down my thoughts, so any second opinions would be appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.