From 9b7f5c987415eb55c582cfaabedca79e61b600a2 Mon Sep 17 00:00:00 2001 From: Simon Bernier St-Pierre Date: Wed, 14 Dec 2016 15:12:16 -0500 Subject: [PATCH] update docs --- design.md | 35 +++++++++++++++++++++++++++-------- docs.md | 4 +++- 2 files changed, 30 insertions(+), 9 deletions(-) diff --git a/design.md b/design.md index af00e71..ba32c3e 100644 --- a/design.md +++ b/design.md @@ -1,8 +1,27 @@ -* A torrent should have multiple workers (seed vs download workers?). -* These workers work with connections, if one break they find another one. - * The connection broker manages connections, choking/unchoking. - * Connection are linked to a peer & their bitfield. - * 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 connection broker opens news connections if none are available for - the workers +The `Session` is the main object to download torrents. It manages multiple +threads. When a torrent is added to it, the tracker is contacted to get a +list of peers. Then, a thread is spawned for each peer, and a connection to +the peer is opened. + +The connections read packets and send them to the network thread via a channel. +The network thread manages the choking and unchoking of connections and the +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._ diff --git a/docs.md b/docs.md index d661028..b139f83 100644 --- a/docs.md +++ b/docs.md @@ -5,5 +5,7 @@ * [ ] udp [spec](http://www.bittorrent.org/beps/bep_0015.html) * [x] http [spec](http://www.bittorrent.org/beps/bep_0003.html#trackers) * 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 +* [x] Peer wire protocol +* [ ] uTP