+
+Store and share torrent-like strings for large files.
+
+In addition to storing the file download location (which would still be
+used for small files), a bencoded dictionary containing the peer's
+hashes of the individual pieces could be stored for the larger files
+(20% of all the files are larger than 512 KB). This dictionary would
+have the normal piece size, the hash length, and a string containing the
+piece hashes of length <hash length>*<#pieces>. These piece hashes could
+be compared ahead of time to determine which peers have the same piece
+hashes (they all should), and then used during the download to verify
+the downloaded pieces.
+
+For very large files (5 or more pieces), the torrent strings are too
+long to store in the DHT and retrieve (a single UDP packet should be
+less than 1472 bytes to avoid fragmentation). Instead, the peers should
+store the torrent-like string for large files separately, and only
+contain a reference to it in their stored value for the hash of the
+file. The reference would be a hash of the bencoded dictionary. If the
+torrent-like string is short enough to store in the DHT (i.e. less than
+1472 bytes, or about 70 pieces for the SHA1 hash), then a
+lookup of that hash in the DHT would give the torrent-like string.
+Otherwise, a request to the peer for the hash (just like files are
+downloaded), should return the bencoded torrent-like string.
+
+
+PeerManager needs to track peers' properties.
+
+The PeerManager needs to keep track of the observed properties of seen
+peers, to help determine a selection criteria for choosing peers to
+download from. Each property will give a value from 0 to 1. The relevant
+properties are:
+
+ - hash errors in last day (1 = 0, 0 = 3+)
+ - recent download speed (1 = fastest, 0 = 0)
+ - lag time from request to download (1 = 0, 0 = 15s+)
+ - number of pending requests (1 = 0, 0 = max (10))
+ - whether a connection is open (1 = yes, 0.9 = no)
+
+These should be combined (multiplied) to provide a sort order for peers
+available to download from, which can then be used to assign new
+downloads to peers. Pieces should be downloaded from the best peers
+first (i.e. piece 0 from the absolute best peer).
+
+
+When Looking Up Values, DHT Should Return Nodes and Values
+
+When a key has multiple values in the DHT, returning a stored value may not
+be sufficient, as then no more nodes can be contacted to get more stored
+values. Instead, return both the stored values and the list of closest
+nodes so that the peer doing the lookup can decide when to stop looking
+(when it has received enough values).