3
3
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
5
5
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
6
<meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
6
<meta name="generator" content="Docutils 0.5: http://docutils.sourceforge.net/" />
8
8
<meta name="author" content="Arvid Norberg, arvid@rasterbar.com Ludvig Strigeus, ludde@utorrent.com" />
9
<link rel="stylesheet" type="text/css" href="css/base.css" />
10
<link rel="stylesheet" type="text/css" href="css/rst.css" />
9
<link rel="stylesheet" type="text/css" href="../../css/base.css" />
10
<link rel="stylesheet" type="text/css" href="../../css/rst.css" />
11
11
<link rel="stylesheet" href="style.css" type="text/css" />
12
12
<style type="text/css">
13
13
/* Hides from IE-mac \*/
20
20
<div id="container">
21
21
<div id="headerNav">
23
<li class="first"><a href="index.html">Home</a></li>
24
<li><a href="http://www.rasterbar.com/products.html">Products</a></li>
25
<li><a href="http://www.rasterbar.com/contact.html">Contact</a></li>
23
<li class="first"><a href="/">Home</a></li>
24
<li><a href="../../products.html">Products</a></li>
25
<li><a href="../../contact.html">Contact</a></li>
29
<h1><span>Rasterbar Software</span></h1>
30
<h2><span>Software developement and consulting</span></h2>
30
34
<table class="docinfo" frame="void" rules="none">
71
75
in this case). At the start of the payload of the message, is a single byte
72
76
message identifier. This identifier can refer to different extension messages
73
77
and only one ID is specified, 0. If the ID is 0, the message is a handshake
74
message which is described below. The layout of a general <tt class="docutils literal">extended</tt> message
78
message which is described below. The layout of a general <tt class="docutils literal"><span class="pre">extended</span></tt> message
75
79
follows (including the message headers used by the bittorrent protocol):</p>
76
80
<table border="1" class="docutils">
204
208
<tbody valign="top">
205
<tr><td><tt class="docutils literal">LT_metadata</tt></td>
209
<tr><td><tt class="docutils literal"><span class="pre">LT_metadata</span></tt></td>
208
<tr><td><tt class="docutils literal">ut_pex</tt></td>
212
<tr><td><tt class="docutils literal"><span class="pre">ut_pex</span></tt></td>
215
<tr><td><tt class="docutils literal">p</tt></td>
219
<tr><td><tt class="docutils literal"><span class="pre">p</span></tt></td>
218
<tr><td><tt class="docutils literal">v</tt></td>
222
<tr><td><tt class="docutils literal"><span class="pre">v</span></tt></td>
219
223
<td>"µTorrent 1.2"</td>
223
227
<p>and in the encoded form:</p>
224
<p><tt class="docutils literal"><span class="pre">d1:md11:LT_metadatai1e6:µT_PEXi2ee1:pi6881e1:v13:\xc2\xb5Torrent</span> 1.2e</tt></p>
228
<p><tt class="docutils literal"><span class="pre">d1:md11:LT_metadatai1e6:µT_PEXi2ee1:pi6881e1:v13:\xc2\xb5Torrent</span> <span class="pre">1.2e</span></tt></p>
225
229
<p>To make sure the extension names do not collide by mistake, they should be
226
230
prefixed with the two (or one) character code that is used to identify the
227
231
client that introduced the extension. This applies for both the names of
235
239
to ignore the subsequent handshake messages (or parts of them).</p>
236
240
<p>Subsequent handshake messages can be used to enable/disable extensions
237
241
without restarting the connection. If a peer supports changing extensions
238
at run time, it should note that the <tt class="docutils literal">m</tt> dictionary is additive.
242
at run time, it should note that the <tt class="docutils literal"><span class="pre">m</span></tt> dictionary is additive.
239
243
It's enough that it contains the actual <em>CHANGES</em> to the extension list.
240
To disable the support for <tt class="docutils literal">LT_metadata</tt> at run-time, without affecting
244
To disable the support for <tt class="docutils literal"><span class="pre">LT_metadata</span></tt> at run-time, without affecting
241
245
any other extensions, this message should be sent:
242
<tt class="docutils literal">d11:LT_metadatai0ee</tt>.
246
<tt class="docutils literal"><span class="pre">d11:LT_metadatai0ee</span></tt>.
243
247
As specified above, the value 0 is used to turn off an extension.</p>
244
248
<p>The extension IDs must be stored for every peer, becuase every peer may have
245
249
different IDs for the same extension.</p>
246
250
<p>This specification, deliberately, does not specify any extensions such as
247
251
peer-exchange or metadata exchange. This protocol is merely a transport
248
252
for the actual extensions to the bittorrent protocol and the extensions
249
named in the example above (such as <tt class="docutils literal">p</tt>) are just examples of possible
253
named in the example above (such as <tt class="docutils literal"><span class="pre">p</span></tt>) are just examples of possible
252
256
<div class="section" id="rationale">
256
260
extension messages requires unique names, which is much easier to do without
257
261
a global registry. The convention is to use a two letter prefix on the
258
262
extension message names, the prefix would identify the client first
259
implementing the extension message. e.g. <tt class="docutils literal">LT_metadata</tt> is implemented by
260
libtorrent, and hence it has the <tt class="docutils literal">LT</tt> prefix.</p>
263
implementing the extension message. e.g. <tt class="docutils literal"><span class="pre">LT_metadata</span></tt> is implemented by
264
libtorrent, and hence it has the <tt class="docutils literal"><span class="pre">LT</span></tt> prefix.</p>
261
265
<p>If the client supporting the extensions can decide which numbers the messages
262
266
it receives will have, it means they are constants within that client. i.e.
263
they can be used in <tt class="docutils literal">switch</tt> statements. It's easy for the other end to
267
they can be used in <tt class="docutils literal"><span class="pre">switch</span></tt> statements. It's easy for the other end to
264
268
store an array with the ID's we expect for each message and use that for
265
269
lookups each time it sends an extension message.</p>
266
270
<p>The reason for having a dictionary instead of having an array (using
267
271
implicitly assigned index numbers to the extensions) is that if a client
268
272
want to disable some extensions, the ID numbers would change, and it wouldn't
269
be able to use constants (and hence, not use them in a <tt class="docutils literal">switch</tt>). If the
273
be able to use constants (and hence, not use them in a <tt class="docutils literal"><span class="pre">switch</span></tt>). If the
270
274
messages IDs would map directly to bittorrent message IDs, It would also make
271
275
it possible to map extensions in the handshake to existing extensions with
272
276
fixed message IDs.</p>
added
removed
docs/extension_protocol.html
