bit torrent specification.htm

由delphi实现的bt下载器示例程序

      <LI class="tightenable top bottom"><B>name</B>: the filename of the file. 
      This is purely advisory. (string) 
      <LI class="tightenable top bottom"><B>piece length</B>: number of bytes in 
      each piece (integer) 
      <LI class="tightenable top bottom"><B>pieces</B>: string consisting of the 
      concatenation of all 20-byte SHA1 hash values, one per piece (byte string) 
      </LI></UL>
    <DT class="tightenable bottom">For the case of the <B>multi-file</B> mode, 
    the <B>info</B> dictionary contains the following structure 
    <DD class="tightenable top bottom">
    <UL>
      <LI class="tightenable top bottom">
      <P class="tightenable top bottom"><B>files</B>: a list of dictionaries, 
      one for each file. Each dictionary in this list contains the following 
      keys:</P>
      <UL>
        <LI class="tightenable top bottom"><B>length</B>: length of the file in 
        bytes (integer) 
        <LI class="tightenable top bottom"><B>md5sum</B>: (optional) a 
        32-character hexadecimal string corresponding to the MD5 sum of the 
        file. This is not used by BitTorrent at all, but it is included by some 
        programs for greater compatibility. 
        <LI class="tightenable top bottom"><B>path</B>: a list containing one or 
        more string elements that together represent the path and filename. Each 
        element in the list corresponds to either a directory name or (in the 
        case of the final element) the filename. For example, a the file 
        "dir1/dir2/file.ext" would consist of three string elements: "dir1", 
        "dir2", and "file.ext". This is encoded as a bencoded list of strings 
        such as 
        <B>l</B><I><B>4</B>:dir1</I><B>4</B><I>:dir2</I><B>8</B><I>:file.ext</I><B>e</B> 
        </LI></UL>
      <LI class="tightenable top bottom"><B>name</B>: the name of the top-most 
      directory in the structure -- the directory which contains all of the 
      files listed in the above <B>files</B> list. (character string) 
      <LI class="tightenable top bottom"><B>piece length</B>: number of bytes in 
      each piece (integer) 
      <LI class="tightenable top bottom"><B>pieces</B>: string consisting of the 
      concatenation of all 20-byte SHA1 hash values, one per piece (byte string) 
      </LI></UL></DD></DL>
  <LI class="tightenable bottom"><B>announce</B>: The announce URL of the 
  tracker (string) 
  <LI class="tightenable top bottom"><B>announce-list</B>: (optional) this is an 
  extention to the official specification, which is also backwards compatible. 
  This key is used to implement lists of backup trackers. The full specification 
  can be found at <A class=namedurl 
  href="http://home.elp.rr.com/tur/multitracker-spec.txt"><SPAN 
  style="WHITE-SPACE: nowrap"><IMG class=linkicon alt="" 
  src="Bit Torrent Specification.files/http.png" 
  border=0>http://home.elp.rr.com/tur/multitracker-spec.txt</SPAN></A> 
  <LI class="tightenable top bottom"><B>creation date</B>: (optional) the 
  creation time of the torrent, in standard Unix epoch format (integer seconds 
  since 1-Jan-1970 00:00:00 UTC) 
  <LI class="tightenable top bottom"><B>comment</B>: (optional) free-form 
  textual comments of the author (string) 
  <LI class="tightenable top"><B>created by</B>: (optional) name and version of 
  the program used to create the .torrent (string) </LI></UL>
<DL>
  <DT class="tightenable bottom">Notes 
  <DD class="tightenable top">
  <UL>
    <LI class="tightenable top bottom">The <B>piece length</B> specifies the 
    nominal piece size, and is usually a power of 2. <I>The piece size is 
    typically chosen based on the total amount of file data in the torrent, 
    constrained by the fact that piece sizes too large cause inefficiency, and 
    too small a piece size will result in a large .torrent metadata file. The 
    conventional wisdom used to be to pick the smallest piece size that results 
    in a .torrent file no greater than approx. 50 - 75 kB (presumably to ease 
    the load on the server hosting the torrent files). However, now that hosting 
    storage and bandwidth are not tightly constrained, <B>it is best to keep the 
    piece size to 512KB or less,</B> at least for torrents under 8-10GB or so, 
    even if that results in a larger torrent file, in order to have a more 
    efficient swarm for sharing files. The most common sizes are 256 kB, 512 kB, 
    and 1 MB.</I> Every piece is of equal length except for the final piece, 
    which is irregular. The number of pieces is thus determined by 'ceil( total 
    length / piece size )'. For the purposes of piece boundaries in the 
    multi-file case, consider the file data as one long continuous stream, 
    composed of the concatenation of each file in the order listed in the 
    <B>files</B> list. The number of pieces and their boundaries are then 
    determined in the same manner as the case of a single file. Pieces may 
    overlap file boundaries. 
    <LI class="tightenable top bottom">Each piece has a corresponding SHA1 hash 
    of the data contained within that piece. These hashes are concatenated to 
    form the <B>pieces</B> value in the above <B>info</B> dictionary. Note that 
    this is <B>not</B> a list but rather a single string. The length of the 
    string must be a multiple of 20 bytes. </LI></UL></DD></DL>
<H2>Tracker HTTP/HTTPS Protocol</H2>
<P class=tightenable>The tracker is an HTTP/HTTPS service which responds to HTTP 
GET requests. The requests include metrics from clients that help the tracker 
keep overall statistics about the torrent. The response includes a peer list 
that helps the client participate in the torrent. The base URL consists of the 
"announce URL" as defined in the metadata (.torrent) file. The parameters are 
then added to this URL, using standard CGI methods (i.e. a '?' after the 
announce URL, followed by 'param=value' sequences separated by '&amp;')</P>
<P class=tightenable>Note that all binary data in the URL (particularly 
info_hash and peer_id) must be properly escaped. This means any byte not in the 
set 0-9, a-z, A-Z, and $-_.+!*'(), must be encoded using the "%nn" format, where 
nn is the hexadecimal value of the byte. (See RFC1738 for details.)</P>
<P class=tightenable>The parameters used in the client-&gt;tracker GET request 
are as follows:</P>
<UL>
  <LI class="tightenable bottom"><B>info_hash</B>: 20-byte SHA1 hash of the 
  <I>value</I> of the <B>info</B> key from the Metainfo file. Note that the 
  <I>value</I> will be a bencoded dictionary, given the definition of the 
  <B>info</B> key above. Note: This string is always urlencoded, as opposed to 
  <A class=named-wiki title="" 
  href="http://wiki.theory.org/BitTorrentSpecification#peer_id">peer_id</A>, 
  which needs to be unencoded. 
  <LI class="tightenable top bottom"><B>peer_id</B>: 20-byte string used as a 
  unique ID for the client, generated by the client at startup. This is allowed 
  to be any value, and may be binary data. <I>There are currently no guidelines 
  for generating this peer ID. However, one may rightly presume that it must at 
  least be unique for your local machine, thus should probably incorporate 
  things like process ID and perhaps a timestamp recorded at startup. See <A 
  class=named-wiki title="" 
  href="http://wiki.theory.org/BitTorrentSpecification#peer_id">peer_id</A> 
  below for common client encodings of this field.</I> 
  <LI class="tightenable top bottom"><B>port</B>: The port number that the 
  client is listening on. Ports reserved for BitTorrent are typically 6881-6889. 
  Clients may choose to give up if it cannot establish a port within this range. 

  <LI class="tightenable top bottom"><B>uploaded</B>: The total amount uploaded 
  (since the client sent the 'started' event to the tracker) in base ten ASCII. 
  While not explicitly stated in the official specification, the concensus is 
  that this should be the total number of bytes uploaded. 
  <LI class="tightenable top bottom"><B>downloaded</B>: The total amount 
  downloaded (since the client sent the 'started' event to the tracker) in base 
  ten ASCII. While not explicitly stated in the official specification, the 
  consensus is that this should be the total number of bytes downloaded. 
  <LI class="tightenable top bottom"><B>left</B>: The number of bytes this 
  client still has to download, encoded in base ten ASCII. 
  <LI class="tightenable top bottom"><B>compact</B>: Indicates the client 
  accepts a compact response. The peers list is replaced by a peers string with 
  6 bytes per peer. The first four bytes are the host (in network byte order), 
  the last two bytes are the port (again in network byte order). 
  <LI class="tightenable top bottom">
  <P class="tightenable top bottom"><B>event</B>: If specified, must be one of 
  <B>started</B>, <B>completed</B>, <B>stopped</B>, (or empty which is the same 
  as not being specified). If not specified, then this request is one performed 
  at regular intervals.</P>
  <UL>
    <LI class="tightenable top bottom"><B>started</B>: The first request to the 
    tracker <B>must</B> include the event key with the <B>started</B> value. 
    <LI class="tightenable top bottom"><B>stopped</B>: Must be sent to the 
    tracker if the client is shutting down gracefully. 
    <LI class="tightenable top bottom"><B>completed</B>: Must be sent to the 
    tracker when the download completes. However, must not be sent if the 
    download was already 100% complete when the client started. Presumably, this 
    is to allow the tracker to increment the "completed downloads" metric based 
    soley on this event. </LI></UL>
  <LI class="tightenable top bottom"><B>ip</B>: Optional. The true IP address of 
  the client machine, in dotted quad format or rfc3513 defined hexed IPv6 
  address. <I>Notes: In general this parameter is not necessary as the address 
  of the client can be determined from the IP address from which the HTTP 
  request came. The parameter is only needed in the case where the IP address 
  that the request came in on is not the IP address of the client. This happens 
  if the client is communicating to the tracker through a proxy (or a 
  transparent web proxy/cache.) It also is necessary when both the client and 
  the tracker are on the same local side of a NAT gateway. The reason for this 
  is that otherwise the tracker would give out the internal (RFC1918) address of 
  the client, which is not routeable. Therefore the client must explicitly state 
  its (external, routeable) IP address to be given out to external peers. 
  Various trackers treat this parameter differently. Some only honor it only if 
  the IP address that the request came in on is in RFC1918 space. Others honor 
  it unconditionally, while others ignore it completely. In case of IPv6 address 
  (e.g.: 2001:db8:1:2::100) it indicates only that client can communicate via 
  IPv6.</I> 
  <LI class="tightenable top bottom"><B>numwant</B>: Optional. Number of peers 
  that the client would like to receive from the tracker. This value is 
  permitted to be zero. If omitted, typically defaults to 50 peers. 
  <LI class="tightenable top bottom"><B>key</B>: Optional. An additional 
  identification that is not shared with any users. It is intended to allow a 
  client to prove their identity should their IP address change. 
  <LI class="tightenable top"><B>trackerid</B>: Optional. If a previous announce 
  contained a tracker id, it should be set here. </LI></UL>
<P class=tightenable>The tracker responds with "text/plain" document consisting 
of a bencoded dictionary with the following keys:</P>
<UL>
  <LI class="tightenable bottom"><B>failure reason</B>: If present, then no 
  other keys may be present. The value is a human-readable error message as to 
  why the request failed (string). 
  <LI class="tightenable top bottom"><B>warning message</B>: (new) Similar to 
  failure reason, but the response still gets processed normally. The warning 
  message is shown just like an error. 
  <LI class="tightenable top bottom"><B>interval</B>: Interval in seconds that 
  the client should wait between sending regular requests to the tracker 
  (mandatory) 
  <LI class="tightenable top bottom"><B>min interval</B>: Minimum announce 
  interval. If present clients must not reannounce more frequently than this. 
  <LI class="tightenable top bottom"><B>tracker id</B>: A string that the client 
  should send back on its next announcements. If absent and a previous announce 
  sent a tracker id, do not discard the old value; keep using it. 
  <LI class="tightenable top bottom"><B>complete</B>: number of peers with the 
  entire file, i.e. seeders (integer) 
  <LI class="tightenable top bottom"><B>incomplete</B>: number of non-seeder