Testing based on Public Domain material: https://archive.org/details/Commercials6Cereal
In-depth implementation explanation example: http://www.getright.com/seedtorrent.html
(referred to by Internet Archive)
Tixati does not support multiple files (folder-based) web seeds.
If the "url-list" URL ends in a slash, "/" the client must add the "name" from the torrent to make the full URL. This allows .torrent generators to treat this field same for single file and multi-file torrents.
If the URL is
then Tixati should add torrent's embedded name
to it to access files:
Currently Tixati tries to access
which is not compliant and returns 404. (Verified with Wireshark)
* Saving/exporting web seed torrents will break the folder seed URL:
Tixati dumps the url-list as-is, means that the next (naive) torrent client would try to append the name again and knock at the URL
The same caveat to be mitigated when importing ill-implemented url-lists of web seeded torrents.
Just probing both URL variants (with and without ...TORRENTNAME/) with a steep exponential backoff is probably simplest.
* Retry sleep after failure is very short.
In some cases Tixati will retry the web seed only after 30s after last failure. The exponential backoff should be steeper.
The same issue is seen with regular peers re-polled too often. Especially under max connection limit restrictions (on stalled/dead torrents).
* HTTP request pieces are tiny leading to slow download / increased server load
Consistently: the pieces requested by Tixati via HTTP is 64K. That's smaller than the torrent's piece size of 512K! (also Wireshark and Tixati logs)
PS: Tixati 2.72
For multi-file transfers, the URL must point to a location that contains a folder matching the transfer name. So, if a multi-file transfer is named MyFileCollection, which is mirrored at
http://example.com/public/howard/MyFileCollection, the correct web-seed URL would be
http://example.com/public/howard/ , without the name of the transfer (this is added internally.)
Apparently this is broken.