-(20% of all the files are larger than 512 KB ). This dictionary would
-have the download location, a list of the piece sizes, and a list of the
-piece hashes (bittorrent uses a single string of length 20*#pieces, but
-for general non-sha1 case a list is needed).
-
-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.
-
-Alternatively, the peers could 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, and a lookup of that hash in the DHT would give the
-torrent-like string. (A 100 MB file would result in 200 hashes, which
-would create a bencoded dictionary larger than 6000 bytes.)
+(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.