docs/client_test.rst

   1 ===========================
   2 client_test example program
   3 ===========================
   4
   5 Client test is a, more or less, complete bittorrent client. It lacks most
   6 settings and you can't start or stop torrents once you've started it. All
   7 the settings are hardcoded. The commandline arguments are::
   8
   9   client_test <filename1.torrent> <filename2.torrent> ...
  10
  11 You can start any number of torrent downloads/seeds via the commandline.
  12 If one argument starts with ``http://`` it is interpreted as a tracker
  13 announce url, and it expects an info-hash as the next argument. The info-hash
  14 has to be hex-encoded. For example: ``2410d4554d5ed856d69f426c38791673c59f4418``.
  15 If you pass an announce url and info-hash, a torrent-less download is started.
  16 It relies on that at least one peer on the tracker is running a libtorrent based
  17 client and has the metadata (.torrent file). The metadata extension in
  18 libtorrent will then download it from that peer (or from those peers if more
  19 than one).
  20
  21 While running, the ``client_test`` sample will look something like this:
  22
  23 .. image:: client_test.png
  24
  25 The commands available in the client are:
  26
  27 * ``q`` quits the client (there will be a delay while the client waits
  28   for tracker responses)
  29 * ``l`` toggle log. Will display the log at the bottom, informing about
  30   tracker and peer events.
  31 * ``i`` toggles torrent info. Will show the peer list for each torrent.
  32 * ``d`` toggle download info. Will show the block list for each torrent,
  33   showing downloaded and requested blocks.
  34 * ``p`` pause all torrents.
  35 * ``u`` unpause all torrents.
  36 * ``r`` force tracker reannounce for all torrents.
  37 * ``f`` toggle show file progress. Displays a list of all files and the
  38   download progress for each file.
  39
  40 The list at the bottom (shown if you press ``d``) shows which blocks has
  41 been requested from which peer. The green background means that it has been
  42 downloaded. It shows that fast peers will prefer to request whole pieces
  43 instead of dowloading parts of pieces. It may make it easier to determine
  44 which peer that sent the corrupt data if a piece fails the hash test.
  45
  46 .. image:: unicode_support.png
  47
  48 There's unicode support on linux, MacOS X and Windows.
  49
  50