premiere-libtorrent/docs/client_test.rst

48 lines
2.1 KiB
ReStructuredText
Raw Normal View History

===========================
client_test example program
===========================
.. include:: header.rst
Client test is a, more or less, complete bittorrent client. It lacks most
settings and you can't start or stop torrents once you've started it. All
the settings are hard coded. The command line arguments are::
client_test <filename1.torrent> <filename2.torrent> ...
You can start any number of torrent downloads/seeds via the command line.
If one argument starts with ``http://`` it is interpreted as a tracker
announce url, and it expects an info-hash as the next argument. The info-hash
2007-02-21 18:16:29 +01:00
has to be hex-encoded. For example: ``2410d4554d5ed856d69f426c38791673c59f4418``.
If you pass an announce url and info-hash, a torrent-less download is started.
It relies on that at least one peer on the tracker is running a libtorrent based
client and has the metadata (.torrent file). The metadata extension in
libtorrent will then download it from that peer (or from those peers if more
than one).
While running, the ``client_test`` sample will look something like this:
.. image:: client_test.png
The commands available in the client are:
2006-06-11 15:50:49 +02:00
* ``q`` quits the client (there will be a delay while the client waits
for tracker responses)
* ``l`` toggle log. Will display the log at the bottom, informing about
tracker and peer events.
* ``i`` toggles torrent info. Will show the peer list for each torrent.
* ``d`` toggle download info. Will show the block list for each torrent,
showing downloaded and requested blocks.
* ``p`` pause all torrents.
* ``u`` resume all torrents.
2006-06-11 15:50:49 +02:00
* ``r`` force tracker reannounce for all torrents.
* ``f`` toggle show file progress. Displays a list of all files and the
download progress for each file.
The list at the bottom (shown if you press ``d``) shows which blocks has
been requested from which peer. The green background means that it has been
downloaded. It shows that fast peers will prefer to request whole pieces
2018-10-19 16:49:42 +02:00
instead of downloading parts of pieces. It may make it easier to determine
which peer that sent the corrupt data if a piece fails the hash test.