Context Navigation

← Previous Changeset
Next Changeset →

Changeset 10759

Timestamp:

02/14/2008 12:51:44 PM (9 months ago)

Author:

dave

Message:

rstify bep 0015 from olaf. Remove references to BitTorrent?, Inc. in favor of bittorrent.org.
Update bep 0000 to refer to bep 0015.

Location:

dotorg/trunk_fixed/html

Files:

: 8 modified

beps/bep_0000.html (modified) (2 diffs)
beps/bep_0000.rst (modified) (2 diffs)
beps/bep_0012.rst (modified) (1 diff)
beps/bep_0015.rst (modified) (9 diffs)
beps/bep_1000.html (modified) (3 diffs)
beps/bep_1000.rst (modified) (1 diff)
beps/makefile (modified) (1 diff)
donate.html (modified) (2 diffs)

Legend:

: Unmodified
: Added
: Removed

dotorg/trunk_fixed/html/beps/bep_0000.html

r10595	r10759
38	38	<tr class="field"><th class="field-name">Title:</th><td class="field-body">Index of BitTorrent Enhancement Proposals</td>
39	39	</tr>
40		<tr class="field"><th class="field-name">Version:</th><td class="field-body">10~~561~~</td>
	40	<tr class="field"><th class="field-name">Version:</th><td class="field-body">10603</td>
41	41	</tr>
42		<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="https://svn.bittorrent.com/trac.cgi/browser/dotorg/trunk/html/beps/bep_0000.rst">2008-02-0~~6 10:01:00 -0800 (Wed, 06~~ Feb 2008)</a></td>
	42	<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="https://svn.bittorrent.com/trac.cgi/browser/dotorg/trunk/html/beps/bep_0000.rst">2008-02-07 17:54:09 -0800 (Thu, 07 Feb 2008)</a></td>
43	43	</tr>
44	44	<tr class="field"><th class="field-name">Author:</th><td class="field-body">David Harrison <dave at bittorrent.com></td>
…	…
110	110	<td>Extension Protocol</td>
111	111	</tr>
	112	<tr><td><span class="raw-html"><A HREF="bep_0015.html">15</A></span></td>
	113	<td>UDP Tracker Protocol</td>
	114	</tr>
	115	<tr><td><span class="raw-html"><A HREF="bep_0017.html">17</A></span></td>
	116	<td>HTTP Seeding</td>
	117	</tr>
112	118	<tr><td><span class="raw-html"><A HREF="bep_1000.html">1000</A></span></td>
113	119	<td>Pending Standards Track Documents</td>

dotorg/trunk_fixed/html/beps/bep_0000.rst

r10603	r10759
37	37	\|9\| Metadata Extension
38	38	\|10\| Extension Protocol
	39	\|15\| UDP Tracker Protocol
39	40	\|17\| HTTP Seeding
40	41	\|1000\| Pending Standards Track Documents
…	…
58	59	.. \|9\| replace:: :raw-html:`<A HREF="bep_0009.html">9</A>`
59	60	.. \|10\| replace:: :raw-html:`<A HREF="bep_0010.html">10</A>`
	61	.. \|15\| replace:: :raw-html:`<A HREF="bep_0015.html">15</A>`
	62	.. \|17\| replace:: :raw-html:`<A HREF="bep_0017.html">17</A>`
60	63	.. \|1000\| replace:: :raw-html:`<A HREF="bep_1000.html">1000</A>`

dotorg/trunk_fixed/html/beps/bep_0012.rst

r10603	r10759
8	8	Created: 07-Feb-2008
9	9	Post-History:
	10
10	11
11	12	Metadata Extension

dotorg/trunk_fixed/html/beps/bep_0015.rst

r10757	r10759
1		BEP: 1
	1	BEP: 15
2	2	Title: UDP Tracker Protocol for BitTorrent
3	3	Version: $Revision$
4	4	Last-Modified: $Date$
5	5	Author: Olaf van der Spek <olafvdspek@gmail.com>
6		Status: ~~Active~~ Draft
7		Type: ~~Process~~
	6	Status: Draft
	7	Type: Standards Track
8	8	Created: 13-Feb-2008
9	9	Post-History:
…	…
12	12	============
13	13
14		To discover other peers in a swarm a client announces it's existance to a tracker.
15		The HTTP protocol is used and a typical request contains the following parameters:
16		info_hash, key, peer_id, port, downloaded, left, uploaded and compact.
17		A response contains a list of peers (host and port) and some other information.
18		The request and response are both quite short.
19		Since TCP is used, a connection has to be opened and closed, introducing additional overhead.
	14	To discover other peers in a swarm a client announces it's existance
	15	to a tracker. The HTTP protocol is used and a typical request
	16	contains the following parameters: info_hash, key, peer_id, port,
	17	downloaded, left, uploaded and compact. A response contains a list of
	18	peers (host and port) and some other information. The request and
	19	response are both quite short. Since TCP is used, a connection has to
	20	be opened and closed, introducing additional overhead.
20	21
21	22	Overhead
22	23	========
23	24
24		Using HTTP introduces significant overhead. There's overhead at the ethernet layer (14 bytes per packet), at the IP layer (20 bytes per packet), at the TCP layer (20 bytes per packet) and at the HTTP layer.
25		About 10 packets are used for a request plus response containing 50 peers and the total number of bytes used is about 1206 [1].
26		This overhead can be reduced significantly by using a UDP based protocol. The protocol proposed here uses 4 packets and about 618 bytes, reducing traffic by 50%.
27		For a client, saving 1 kbyte every hour isn't significant, but for a tracker serving a million peers, reducing traffic by 50% matters a lot.
28		An additional advantage is that a UDP based binary protocol doesn't require a complex parser and no connection handling, reducing the complexity of tracker code and increasing it's performance.
	25	Using HTTP introduces significant overhead. There's overhead at the
	26	ethernet layer (14 bytes per packet), at the IP layer (20 bytes per
	27	packet), at the TCP layer (20 bytes per packet) and at the HTTP layer.
	28	About 10 packets are used for a request plus response containing 50
	29	peers and the total number of bytes used is about 1206 [1]. This
	30	overhead can be reduced significantly by using a UDP based
	31	protocol. The protocol proposed here uses 4 packets and about 618
	32	bytes, reducing traffic by 50%. For a client, saving 1 kbyte every
	33	hour isn't significant, but for a tracker serving a million peers,
	34	reducing traffic by 50% matters a lot. An additional advantage is
	35	that a UDP based binary protocol doesn't require a complex parser and
	36	no connection handling, reducing the complexity of tracker code and
	37	increasing it's performance.
29	38
30	39	UDP connections / spoofing
31	40	==========================
32	41
33		In the ideal case, only 2 packets would be necessary. However, it is possible to spoof the source address of a UDP packet.
34		The tracker has to ensure this doesn't occur, so it calculates a value (connection_id) and sends it to the client.
35		If the client spoofed it's source address, it won't receive this value (unless it's sniffing the network).
36		The connection_id will then be send to the tracker again in packet 3. The tracker verifies the connection_id and ignores the request if it doesn't match.
37		Connection IDs should not be guessable by the client. This is comparable to a TCP handshake and a syn cookie like approach can be used to storing the connection IDs on the tracker side.
38		A connection ID can be used for multiple requests. A client can use a connection ID until one minute after it has received it. Trackers should accept the connection ID until two minutes after it has been send.
	42	In the ideal case, only 2 packets would be necessary. However, it is
	43	possible to spoof the source address of a UDP packet. The tracker has
	44	to ensure this doesn't occur, so it calculates a value (connection_id)
	45	and sends it to the client. If the client spoofed it's source
	46	address, it won't receive this value (unless it's sniffing the
	47	network). The connection_id will then be send to the tracker again in
	48	packet 3. The tracker verifies the connection_id and ignores the
	49	request if it doesn't match. Connection IDs should not be guessable
	50	by the client. This is comparable to a TCP handshake and a syn cookie
	51	like approach can be used to storing the connection IDs on the tracker
	52	side. A connection ID can be used for multiple requests. A client can
	53	use a connection ID until one minute after it has received
	54	it. Trackers should accept the connection ID until two minutes after
	55	it has been send.
39	56
40	57	Time outs
41	58	=========
42	59
43		UDP is an 'unreliable' protocol. This means it doesn't retransmit lost packets itself. The application is responsible for this.
44		If a response is not received after 15 * 2 ^ n seconds, the client should retransmit the request, where n starts at 0 and is increased up to 8 (3840 seconds) after every retransmission.
45		Note that it is necessary to rerequest a connection ID when it has expired.
	60	UDP is an 'unreliable' protocol. This means it doesn't retransmit lost
	61	packets itself. The application is responsible for this. If a
	62	response is not received after 15 * 2 ^ n seconds, the client should
	63	retransmit the request, where n starts at 0 and is increased up to 8
	64	(3840 seconds) after every retransmission. Note that it is necessary
	65	to rerequest a connection ID when it has expired.
46	66
47	67	Examples
48	68	========
49	69
50		Normal announce:
51		t = 0: connect request
52		t = 1: connect response
53		t = 2: announce request
54		t = 3: annonce response
55
56		Connect times out:
57		t = 0: connect request
58		t = 15: connect request
59		t = 45: connect request
60		t = 105: connect request
61		etc
62
63		Announce times out:
64		t = 0:
65		t = 0: connect request
66		t = 1: connect response
67		t = 2: announce request
68		t = 17: announce request
69		t = 47: announce request
70		t = 107: connect request (because connection ID expired)
71		t = 227: connect request
72		etc
73
74		Multiple requests:
75		t = 0: connect request
76		t = 1: connect response
77		t = 2: announce request
78		t = 3: annonce response
79		t = 4: announce request
80		t = 5: annonce response
81		t = 60: announce request
82		t = 61: annonce response
83		t = 62: connect request
84		t = 63: connect response
85		t = 64: announce request
86		t = 64: scrape request
87		t = 64: scrape request
88		t = 64: announce request
89		t = 65: announce response
90		t = 66: announce response
91		t = 67: scrape response
92		t = 68: scrape response
	70	Normal announce::
	71
	72	t = 0: connect request
	73	t = 1: connect response
	74	t = 2: announce request
	75	t = 3: annonce response
	76
	77	Connect times out::
	78
	79	t = 0: connect request
	80	t = 15: connect request
	81	t = 45: connect request
	82	t = 105: connect request
	83	etc
	84
	85	Announce times out::
	86
	87	t = 0:
	88	t = 0: connect request
	89	t = 1: connect response
	90	t = 2: announce request
	91	t = 17: announce request
	92	t = 47: announce request
	93	t = 107: connect request (because connection ID expired)
	94	t = 227: connect request
	95	etc
	96
	97	Multiple requests::
	98
	99	t = 0: connect request
	100	t = 1: connect response
	101	t = 2: announce request
	102	t = 3: annonce response
	103	t = 4: announce request
	104	t = 5: annonce response
	105	t = 60: announce request
	106	t = 61: annonce response
	107	t = 62: connect request
	108	t = 63: connect response
	109	t = 64: announce request
	110	t = 64: scrape request
	111	t = 64: scrape request
	112	t = 64: announce request
	113	t = 65: announce response
	114	t = 66: announce response
	115	t = 67: scrape response
	116	t = 68: scrape response
93	117
94	118	UDP tracker protocol
95	119	====================
96	120
97		All values are send in network byte order (big endian). Do not expect packets to be exactly of a certain size. Future extensions could increase the size of packets.
	121	All values are send in network byte order (big endian). Do not expect
	122	packets to be exactly of a certain size. Future extensions could
	123	increase the size of packets.
98	124
99	125	Before announcing or scraping, you have to obtain a connection ID.
…	…
103	129	3. Send the packet.
104	130
105		connect request
106		Offset Size Name Value
107		0 64-bit integer connection_id 0x41727101980
108		8 32-bit integer action 0 // connect
109		12 32-bit integer transaction_id
110		16
	131	connect request::
	132
	133	Offset Size Name Value
	134	0 64-bit integer connection_id 0x41727101980
	135	8 32-bit integer action 0 // connect
	136	12 32-bit integer transaction_id
	137	16
111	138
112	139	1. Receive the packet.
…	…
116	143	5. Store the connection ID for future use.
117	144
118		connect response
119		Offset Size Name Value
120		0 32-bit integer action 0 // connect
121		4 32-bit integer transaction_id
122		8 64-bit integer connection_id
123		16
	145	connect response::
	146
	147	Offset Size Name Value
	148	0 32-bit integer action 0 // connect
	149	4 32-bit integer transaction_id
	150	8 64-bit integer connection_id
	151	16
124	152
125	153	1. Choose a random transaction ID.
…	…
127	155	3. Send the packet.
128	156
129		announce request
130		Offset Size Name Value
131		0 64-bit integer connection_id
132		8 32-bit integer action 1 // announce
133		12 32-bit integer transaction_id
134		16 20-byte string info_hash
135		36 20-byte string peer_id
136		56 64-bit integer downloaded
137		64 64-bit integer left
138		72 64-bit integer uploaded
139		80 32-bit integer event 0 // 0: none; 1: completed; 2: started; 3: stopped
140		84 32-bit integer IP address 0 // default
141		88 32-bit integer key
142		92 32-bit integer num_want -1 // default
143		96 16-bit integer port
144		98
	157	announce request::
	158
	159	Offset Size Name Value
	160	0 64-bit integer connection_id
	161	8 32-bit integer action 1 // announce
	162	12 32-bit integer transaction_id
	163	16 20-byte string info_hash
	164	36 20-byte string peer_id
	165	56 64-bit integer downloaded
	166	64 64-bit integer left
	167	72 64-bit integer uploaded
	168	80 32-bit integer event 0 // 0: none; 1: completed; 2: started; 3: stopped
	169	84 32-bit integer IP address 0 // default
	170	88 32-bit integer key
	171	92 32-bit integer num_want -1 // default
	172	96 16-bit integer port
	173	98
145	174
146	175	1. Receive the packet.
…	…
150	179	5. Do not announce again until interval seconds have passed or an event has occurred.
151	180
152		announce response
153		Offset Size Name Value
154		0 32-bit integer action 1 // announce
155		4 32-bit integer transaction_id
156		8 32-bit integer interval
157		12 32-bit integer leechers
158		16 32-bit integer seeders
159		20 + 6 * n 32-bit integer IP address
160		24 + 6 * n 16-bit integer TCP port
161		20 + 6 * N
	181	announce response::
	182
	183	Offset Size Name Value
	184	0 32-bit integer action 1 // announce
	185	4 32-bit integer transaction_id
	186	8 32-bit integer interval
	187	12 32-bit integer leechers
	188	16 32-bit integer seeders
	189	20 + 6 * n 32-bit integer IP address
	190	24 + 6 * n 16-bit integer TCP port
	191	20 + 6 * N
162	192
163	193	Up to about 74 torrents can be scraped at once. A full scrape can't be done with this protocol.
…	…
167	197	3. Send the packet.
168	198
169		scrape request
170		Offset Size Name Value
171		0 64-bit integer connection_id
172		8 32-bit integer action 2 // scrape
173		12 32-bit integer transaction_id
174		16 + 20 * n 20-byte string info_hash
175		16 + 20 * N
	199	scrape request::
	200
	201	Offset Size Name Value
	202	0 64-bit integer connection_id
	203	8 32-bit integer action 2 // scrape
	204	12 32-bit integer transaction_id
	205	16 + 20 * n 20-byte string info_hash
	206	16 + 20 * N
176	207
177	208	1. Receive the packet.
…	…
180	211	4. Check whether the action is scrape.
181	212
182		scrape response
183		Offset Size Name Value
184		0 32-bit integer action 2 // scrape
185		4 32-bit integer transaction_id
186		8 + 12 * n 32-bit integer seeders
187		12 + 12 * n 32-bit integer completed
188		16 + 12 * n 32-bit integer leechers
189		8 + 12 * N
	213	scrape response::
	214
	215	Offset Size Name Value
	216	0 32-bit integer action 2 // scrape
	217	4 32-bit integer transaction_id
	218	8 + 12 * n 32-bit integer seeders
	219	12 + 12 * n 32-bit integer completed
	220	16 + 12 * n 32-bit integer leechers
	221	8 + 12 * N
190	222
191	223	If the tracker encounters an error, it might send an error packet.
…	…
195	227	3. Check whether the transaction ID is equal to the one you chose.
196	228
197		error response
198		Offset Size Name Value
199		0 32-bit integer action 3 // error
200		4 32-bit integer transaction_id
201		8 string message
	229	error response::
	230
	231	Offset Size Name Value
	232	0 32-bit integer action 3 // error
	233	4 32-bit integer transaction_id
	234	8 string message
202	235
203	236	Existing implementations
204	237	========================
205		Azureus, libtorrent [2], opentracker [3], XBT Client and XBT Tracker support this protocol.
	238
	239	Azureus, libtorrent [2], opentracker [3], XBT Client and XBT Tracker
	240	support this protocol.
206	241
207	242	IPv6
208	243	====
209	244
210		IPv6 is not supported at the moment. A simple way to support IPv6 would be to increase the size of all IP addresses to 128 bits when the request is done over IPv6.
211		However, I think more experience with IPv6 and discussion is needed before including it.
	245	IPv6 is not supported at the moment. A simple way to support IPv6
	246	would be to increase the size of all IP addresses to 128 bits when the
	247	request is done over IPv6. However, I think more experience with IPv6
	248	and discussion is needed before including it.
212	249
213	250	Extensions
214	251	==========
215	252
216		Extension bits or a version field are not included. Clients and trackers should not assume packets to be of a certain size. This way, additional fields can be added without breaking compatibility.
	253	Extension bits or a version field are not included. Clients and
	254	trackers should not assume packets to be of a certain size. This way,
	255	additional fields can be added without breaking compatibility.
217	256
218	257	References and Footnotes

dotorg/trunk_fixed/html/beps/bep_1000.html

r10595	r10759
38	38	<tr class="field"><th class="field-name">Title:</th><td class="field-body">Pending Standards Track Documents</td>
39	39	</tr>
40		<tr class="field"><th class="field-name">Version:</th><td class="field-body">10~~579~~</td>
	40	<tr class="field"><th class="field-name">Version:</th><td class="field-body">10603</td>
41	41	</tr>
42		<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="https://svn.bittorrent.com/trac.cgi/browser/dotorg/trunk/html/beps/bep_1000.rst">2008-02-07 ~~02:58:4~~9 -0800 (Thu, 07 Feb 2008)</a></td>
	42	<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="https://svn.bittorrent.com/trac.cgi/browser/dotorg/trunk/html/beps/bep_1000.rst">2008-02-07 17:54:09 -0800 (Thu, 07 Feb 2008)</a></td>
43	43	</tr>
44	44	<tr class="field"><th class="field-name">Author:</th><td class="field-body">David Harrison <dave at bittorrent.com></td>
…	…
72	72	<td>Peer Exchange</td>
73	73	</tr>
74		~~<tr><td>12</td>~~
75		~~<td>Announce List</td>~~
76		~~</tr>~~
77	74	<tr><td>13</td>
78	75	<td>Protocol Encryption</td>
…	…
86	83	<tr><td>16</td>
87	84	<td>Super-seeding</td>
88		~~</tr>~~
89		~~<tr><td>17</td>~~
90		~~<td>HTTP Seeding</td>~~
91	85	</tr>
92	86	</tbody>

dotorg/trunk_fixed/html/beps/bep_1000.rst

r10603	r10759
18	18	===== =========================================
19	19	11 Peer Exchange
20		~~12 Announce List~~
21	20	13 Protocol Encryption
22	21	14 Local Service Discovery

dotorg/trunk_fixed/html/beps/makefile

r10599	r10759
12	12	bep_0009.html \
13	13	bep_0010.html \
	14	bep_0012.html \
	15	bep_0015.html \
14	16	bep_0017.html \
15	17	bep_1000.html \

dotorg/trunk_fixed/html/donate.html

r10539	r10759
28	28	<h2><strong>Give and Ye Shall Receive!</strong></h2>
29	29	<p>
30		~~BitTorrent, Inc. has set up bittorrent.ORG~~ to maintain and advance the open source protocol upon which all BitTorrent clients and servers are based. You can help support the creation of tools and resources for the BitTorrent developer community by donating here. <br>
	30	bittorrent.ORG has been set up to maintain and advance the open source protocol upon which all BitTorrent clients and servers are based. You can help support the creation of tools and resources for the BitTorrent developer community by donating here. <br>
31	31
32	32	<form id="donate" action="https://www.paypal.com/cgi-bin/webscr" method="post">
…	…
46	46	<p>
47	47	<strong>
48		~~BitTorrent, Inc.~~<br/>
	48	bittorrent.org <br/>
49	49	201 Mission St. Suite 900<br/>
50	50	San Francisco, CA 94105

Download in other formats: