root / dotorg / trunk / html / beps / bep_0023.rst

Revision 11117, 3.0 kB (checked in by dave, 2 weeks ago)

slight fix to reference.

Line 
1BEP: 23
2Title: Tracker Returns Compact Peer Lists
3Version: $Revision$
4Last-Modified: $Date$
5Author:  David Harrison <dave@bittorrent.com>
6Status:  Accepted
7Type:    Standards track
8Content-Type: text/x-rst
9Created: 12-May-2008
10Post-History: 
11
12
13Abstract
14========
15
16To reduce the size of tracker responses and to reduce memory and
17computational requirements in trackers, trackers may return
18peers as a packed string rather than as a bencoded list.
19
20The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
21NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
22"OPTIONAL" in this document are to be interpreted as described in
23IETF RFC 2119 [#RFC-2119]_.
24
25
26Overview
27========
28
29In BitTorrent as described in BEP 3 [#BEP-3]_, peers wishing to
30transfer a file contact a central tracker.  This tracker returns a
31list of peers that are currently transferring the file.  The list of
32peers is implemented as a list of bencoded dicts.  Each dict in the
33list contains three fields: *peer id*, *ip*, and *port*.  The *peer
34id* is 20 bytes plus 3 bytes bencoding overhead.  The *ip* is a string
35containing a domain name or an IP address, and an integer port number.
36The *ip* is variable length, but since in its longest form it is a
37domain name it cannot exceed 255 bytes [#RFC-1034]_ plus 4 bytes
38bencoding overhead.  Bencoded integers are also variable length but
39since it is a port number, it cannot be more than 7 bytes including
40bencoding overhead.  Thus,
41
42::
43
44  total peer list length in bytes < n * ( 23 + 259 + 7 ) 
45
46It is common now to use a compact format where each peer is represented
47using only 6 bytes.  The first 4 bytes contain the 32-bit ipv4 address.
48The remaining two bytes contain the port number.  Both address and port
49use network-byte order.
50
51When the client's announce URL contains *compact=1* the tracker MAY
52return the peers using compact format.  When *compact=0* or it is not
53specified then the tracker MUST return using the original format
54described in [#BEP-3]_.  For example,
55
56::
57
58  GET /announce?peer_id=aaaaaaaaaaaaaaaaaaaa&info_hash=aaaaaaaaaaaaaaaaaaaa
59  &port=6881&left=0&downloaded=100&uploaded=0&compact=1
60
61The compact format uses the same *peers* key in the bencoded tracker
62response, but the value is a bencoded string rather than a bencoded
63list.
64
65The peer id does not appear in the compact format.  The format has been
66in use for years and the lack of a peer id has posed no problems.
67
68This compact format is supported by BitTorrent mainline, Azureus,
69libtorrent, uTorrent, and probably most other clients.
70
71
72References
73==========
74
75.. [#BEP-3] BEP_0003. The BitTorrent Protocol Specification. Cohen.
76   (http://www.bittorrent.org/beps/bep_0003.html)
77
78.. [#RFC-1034] RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. Mockapetris,
79   November 1987. (http://tools.ietf.org/html/rfc1034)
80
81.. [#RFC-2119] RFC-2119. (http://www.ietf.org/rfc/rfc2119.txt)
82
83
84Copyright
85=========
86
87This document has been placed in the public domain.
88
89
90
91..
92   Local Variables:
93   mode: indented-text
94   indent-tabs-mode: nil
95   sentence-end-double-space: t
96   fill-column: 70
97   coding: utf-8
98   End:
Note: See TracBrowser for help on using the browser.