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

[CLOSED] Implement interested/choke semantics from BEP 3? #111

Closed
feross opened this issue Sep 21, 2014 · 4 comments
Closed

[CLOSED] Implement interested/choke semantics from BEP 3? #111

feross opened this issue Sep 21, 2014 · 4 comments

Comments

@feross
Copy link
Member

@feross feross commented Sep 21, 2014

Issue by feross
Sunday May 18, 2014 at 01:33 GMT
Originally opened as https://github.com/feross/bittorrent-client/issues/15


Choking is done for several reasons. TCP congestion control behaves very poorly when sending over many connections at once. Also, choking lets each peer use a tit-for-tat-ish algorithm to ensure that they get a consistent download rate.

The choking algorithm described below is the currently deployed one. It is very important that all new algorithms work well both in a network consisting entirely of themselves and in a network consisting mostly of this one.

There are several criteria a good choking algorithm should meet. It should cap the number of simultaneous uploads for good TCP performance. It should avoid choking and unchoking quickly, known as 'fibrillation'. It should reciprocate to peers who let it download. Finally, it should try out unused connections once in a while to find out if they might be better than the currently used ones, known as optimistic unchoking.

The currently deployed choking algorithm avoids fibrillation by only changing who's choked once every ten seconds. It does reciprocation and number of uploads capping by unchoking the four peers which it has the best download rates from and are interested. Peers which have a better upload rate but aren't interested get unchoked and if they become interested the worst uploader gets choked. If a downloader has a complete file, it uses its upload rate rather than its download rate to decide who to unchoke.

For optimistic unchoking, at any one time there is a single peer which is unchoked regardless of its upload rate (if interested, it counts as one of the four allowed downloaders.) Which peer is optimistically unchoked rotates every 30 seconds. To give them a decent chance of getting a complete piece to upload, new connections are three times as likely to start as the current optimistic unchoke as anywhere else in the rotation.

http://www.bittorrent.org/beps/bep_0003.html

@feross

This comment has been minimized.

Copy link
Member Author

@feross feross commented Sep 21, 2014

Comment by fisch0920
Sunday May 18, 2014 at 09:47 GMT


Definitely need to add optimistic unchoking.

Though this paper is a bit dated, it has the clearest description of the unchoking scenarios I've found.

@feross

This comment has been minimized.

Copy link
Member Author

@feross feross commented Sep 21, 2014

Comment by feross
Monday May 19, 2014 at 02:13 GMT


Here's another paper to look at: http://www.bittorrent.org/bittorrentecon.pdf

@feross

This comment has been minimized.

Copy link
Member Author

@feross feross commented Sep 21, 2014

Comment by fisch0920
Friday May 30, 2014 at 15:31 GMT


This issue should be fully addressed in my latest PR.

@feross

This comment has been minimized.

Copy link
Member Author

@feross feross commented Sep 21, 2014

Comment by feross
Tuesday Jun 03, 2014 at 17:23 GMT


Fixed in #20 - thanks @fisch0920 !

@lock lock bot locked as resolved and limited conversation to collaborators May 7, 2018
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.