update docs
This commit is contained in:
35
design.md
35
design.md
@@ -1,8 +1,27 @@
|
|||||||
* A torrent should have multiple workers (seed vs download workers?).
|
The `Session` is the main object to download torrents. It manages multiple
|
||||||
* These workers work with connections, if one break they find another one.
|
threads. When a torrent is added to it, the tracker is contacted to get a
|
||||||
* The connection broker manages connections, choking/unchoking.
|
list of peers. Then, a thread is spawned for each peer, and a connection to
|
||||||
* Connection are linked to a peer & their bitfield.
|
the peer is opened.
|
||||||
* Connections need to be listened to at all times for choke/unchoke/have/timeout/interested
|
|
||||||
* A worker takes over a connection to send/receive.
|
The connections read packets and send them to the network thread via a channel.
|
||||||
* The connection broker opens news connections if none are available for
|
The network thread manages the choking and unchoking of connections and the
|
||||||
the workers
|
scheduling of fragments. Fragments are 16KiB blocks that form a
|
||||||
|
piece. For instance if a piece is of 512KiB, there are 32 fragments for that
|
||||||
|
piece. When a connection is unchoked, the network thread will schedule
|
||||||
|
fragments on this connection. When the fragment is received back, the
|
||||||
|
network thread assembles the piece from the various fragments. When a piece
|
||||||
|
is complete, it writes it to disk.
|
||||||
|
|
||||||
|
The scheduling algorithm is very simple at the moment. It tries to minimize
|
||||||
|
the number of pieces that are being downloaded. Every fragment is kept
|
||||||
|
track of. It has a status, Available (no peer connection is downloading
|
||||||
|
this fragment), Taken(a peer is downloading this fragment) or Complete (this
|
||||||
|
fragment has been received). The Taken status also has a timestamp. When
|
||||||
|
looking for a fragment to schedule, the algorithm looks for fragments that
|
||||||
|
are available or that have been taken, but ran out of time (5s). It also
|
||||||
|
takes into account the peer's bitfield to find a piece the peer has. If no
|
||||||
|
fragment matches these criterias, a new piece is fragmented.
|
||||||
|
|
||||||
|
_Note that there could be an explosion in the number of pieces that are being
|
||||||
|
downloaded if the peers have very incomplete bitfields. In the future the
|
||||||
|
algorithm will limit the number of pieces that are being downloaded._
|
||||||
|
|||||||
4
docs.md
4
docs.md
@@ -5,5 +5,7 @@
|
|||||||
* [ ] udp [spec](http://www.bittorrent.org/beps/bep_0015.html)
|
* [ ] udp [spec](http://www.bittorrent.org/beps/bep_0015.html)
|
||||||
* [x] http [spec](http://www.bittorrent.org/beps/bep_0003.html#trackers)
|
* [x] http [spec](http://www.bittorrent.org/beps/bep_0003.html#trackers)
|
||||||
* Metainfo
|
* Metainfo
|
||||||
* [ ] torrent files [spec](https://wiki.theory.org/BitTorrentSpecification#Metainfo_File_Structure)
|
* [x] torrent files [spec](https://wiki.theory.org/BitTorrentSpecification#Metainfo_File_Structure)
|
||||||
* [ ] magnet links
|
* [ ] magnet links
|
||||||
|
* [x] Peer wire protocol
|
||||||
|
* [ ] uTP
|
||||||
|
|||||||
Reference in New Issue
Block a user