📄 fast extension.mht
字号:
From: <由 Microsoft Internet Explorer 5 保存>
Subject: BitTorrent.org For Developers
Date: Mon, 23 Apr 2007 11:49:18 +0800
MIME-Version: 1.0
Content-Type: multipart/related;
type="text/html";
boundary="----=_NextPart_000_0005_01C7859D.6CEAB7F0"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
This is a multi-part message in MIME format.
------=_NextPart_000_0005_01C7859D.6CEAB7F0
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Location: http://www.bittorrent.org/fast_extensions.html
=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" =
"http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML lang=3Den xml:lang=3D"en" =
xmlns=3D"http://www.w3.org/1999/xhtml"><HEAD><TITLE>BitTorrent.org For =
Developers</TITLE>
<META http-equiv=3DContent-type content=3D"text/html; =
charset=3Dutf-8"><LINK=20
media=3Dscreen href=3D"http://www.bittorrent.org/css/screen.css" =
type=3Dtext/css=20
rel=3Dstylesheet>
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR></HEAD>
<BODY id=3Dwww-bittorrent-org>
<DIV class=3Dclear id=3Dupper>
<DIV id=3Dwrap>
<DIV id=3Dheader>
<H1><A=20
href=3D"http://www.bittorrent.org/index.html">BitTorrent<SPAN>.org</SPAN>=
</A></H1></DIV>
<DIV id=3Dnav>
<UL>
<LI><A href=3D"http://www.bittorrent.org/index.html">Home</A>=20
<LI><A href=3D"http://www.bittorrent.org/introduction.html">For =
Users</A>=20
<LI><SPAN>For Developers</SPAN> <!-- <li><a =
href=3D"./blog">Blog</a></li> --><!-- <li><a =
href=3D"./donate.html">Donate!</a></li> --></LI></UL></DIV><!-- ### =
Begin Content ### -->
<DIV id=3Dsecond>
<H1>Fast Extension</H1>
<P>The Fast Extension packages several extensions: <I>Have None/Have =
All</I>,=20
<I>Reject Requests</I>, <I>Suggestions</I> and <I>Allowed Fast.</I> =
These are=20
enabled by setting the third least significant bit of the last reserved =
byte in=20
the BitTorrent handshake: </P><PRE> reserved[7] |=3D 0x04
</PRE>
<P>The extension is enabled only if both ends of the connection set this =
bit.=20
</P>
<P>The following proposed messages adhere to the syntax of messages =
found in=20
v1.0 of the BitTorrent protocol. All integers are four bytes big-endian. =
All=20
messages start with an integer message length. All messages but the =
Keep-Alive=20
follow the message length with a single byte opcode and zero or more=20
opcode-dependant arguments. </P>
<P>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =
"SHOULD",=20
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are =
to be=20
interpreted as described in IETF <A class=3Dexternal=20
title=3Dhttp://www.ietf.org/rfc/rfc2119.txt=20
href=3D"http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</A>. </P>
<TABLE class=3Dtoc id=3Dtoc>
<TBODY>
<TR>
<TD>
<DIV id=3Dtoctitle>
<H2>Contents</H2></DIV>
<UL>
<LI class=3Dtoclevel-1><A=20
=
href=3D"http://www.bittorrent.org/fast_extensions.html#Modifications_to_S=
emantics_of_Existing_Messages"><SPAN=20
class=3Dtocnumber>1</SPAN> <SPAN class=3Dtoctext>Modifications =
to Semantics=20
of Existing Messages</SPAN></A>=20
<LI class=3Dtoclevel-1><A=20
=
href=3D"http://www.bittorrent.org/fast_extensions.html#Have_All.2FHave_No=
ne"><SPAN=20
class=3Dtocnumber>2</SPAN> <SPAN class=3Dtoctext>Have All/Have=20
None</SPAN></A>=20
<LI class=3Dtoclevel-1><A=20
=
href=3D"http://www.bittorrent.org/fast_extensions.html#Suggest_Piece"><SP=
AN=20
class=3Dtocnumber>3</SPAN> <SPAN class=3Dtoctext>Suggest =
Piece</SPAN></A>=20
<LI class=3Dtoclevel-1><A=20
=
href=3D"http://www.bittorrent.org/fast_extensions.html#Reject_Request"><S=
PAN=20
class=3Dtocnumber>4</SPAN> <SPAN class=3Dtoctext>Reject =
Request</SPAN></A>=20
<LI class=3Dtoclevel-1><A=20
=
href=3D"http://www.bittorrent.org/fast_extensions.html#Allowed_Fast_Set_G=
eneration"><SPAN=20
class=3Dtocnumber>5</SPAN> <SPAN class=3Dtoctext>Allowed Fast =
Set=20
Generation</SPAN></A> </LI></UL></TD></TR></TBODY></TABLE>
<P>
<SCRIPT type=3Dtext/javascript> if (window.showTocToggle) { var =
tocShowText =3D "show"; var tocHideText =3D "hide"; showTocToggle(); } =
</SCRIPT>
</P>
<H2 id=3DModifications_to_Semantics_of_Existing_Messages>Modifications =
to=20
Semantics of Existing Messages </H2>
<P>The Fast Extension modifies the semantics of the <I>Request</I>,=20
<I>Choke</I>, <I>Unchoke</I>, and <I>Cancel</I> messages, and adds a =
<I>Reject=20
Request.</I> Now, every request is guaranteed to result in EXACTLY ONE =
response=20
which is either the corresponding reject or corresponding piece message. =
Even=20
when a request is cancelled, the peer receiving the cancel should =
respond with=20
either the corresponding reject or the corresponding piece: requests =
that are=20
being processed are allowed to complete. </P>
<P>Choke no longer implicitly rejects all pending requests, thus =
eliminating=20
some race conditions which could cause pieces to be needlessly requested =
multiple times. </P>
<P>Additionally, if a peer receives a piece that was never requested, =
the peer=20
MUST close the connection. </P>
<H2 id=3DHave_All.2FHave_None>Have All/Have None </H2><PRE> <I>Have =
All</I>: <len=3D0x0001><op=3D0x0E>
</PRE><PRE> <I>Have None</I>: <len=3D0x0001><op=3D0x0F>
</PRE>
<P><I>Have All</I> and <I>Have None</I> specify that the message sender =
has all=20
or none of the pieces respectively. When present, <I>Have All</I> or =
<I>Have=20
None</I> replace the <I>Have Bitfield.</I> Exactly one of <I>Have =
All</I>,=20
<I>Have None</I>, or <I>Have Bitfield</I> MUST appear and only =
immediately after=20
the handshake. The reason for these messages is to save bandwidth. Also =
slightly=20
to remove the idiosyncrasy of sending no message when a peer has no =
pieces. </P>
<P>When the fast extension is disabled, if a peer receives <I>Have =
All</I> or=20
<I>Have None</I> then the peer MUST close the connection. </P>
<H2 id=3DSuggest_Piece>Suggest Piece </H2><PRE> <I>Suggest Piece</I>: =
<len=3D0x0005><op=3D0x0D><index>
</PRE>
<P><I>Suggest Piece</I> is an advisory message meaning "you might like =
to=20
download this piece." The intended usage is for 'super-seeding' without=20
throughput reduction, to avoid redundant downloads, and so that a seed =
which is=20
disk I/O bound can upload continguous or identical pieces to avoid =
excessive=20
disk seeks. In all cases, the seed SHOULD operate to maintain a roughly =
equal=20
number of copies of each piece in the network. A peer MAY send more than =
one=20
<I>suggest piece</I> message at any given time. A peer receiving =
multiple=20
<I>suggest piece</I> messages MAY interpret this as meaning that all of =
the=20
suggested pieces are equally appropriate. </P>
<P>When the fast extension is disabled, if a peer receives a <I>Suggest=20
Piece</I> message, the peer MUST close the connection. </P>
<H2 id=3DReject_Request>Reject Request </H2><PRE> <I>Reject Request</I>: =
<len=3D0x000D><op=3D0x10><index><begin><offset=
>
</PRE>
<P><I>Reject Request</I> notifies a requesting peer that its request =
will not be=20
satisfied. </P>
<P>If the fast extension is disabled and a peer receives a reject =
request then=20
the peer MUST close the connection. </P>
<P>When the fast extension is enabled: </P>
<UL>
<LI>If a peer receives a reject for a request that was never sent then =
the=20
peer SHOULD close the connection.=20
<LI>If a peer sends a choke, it MUST reject all requests from the peer =
to whom=20
the choke was sent except it SHOULD NOT reject requests for pieces =
that are in=20
the <I>allowed fast set.</I> A peer SHOULD choke first and then reject =
requests so that the peer receiving the choke does not re-request the =
pieces.=20
<LI>If a peer receives a request from a peer its choking, the peer =
receiving=20
the request SHOULD send a reject unless the piece is in the <I>allowed =
fast=20
set.</I>=20
<LI>If a peer receives an excessive number of requests from a peer it =
is=20
choking, the peer receiving the requests MAY close the connection =
rather than=20
reject the request. However, consider that it can take several seconds =
for=20
buffers to drain and messages to propagate once a peer is =
choked.</LI></UL>
<H2 id=3DAllowed_Fast>Allowed Fast</H2><PRE><I> Allowed Fast: =
<len=3D0x0005><op=3D0x11><index></I></PRE>
<P>With the BitTorrent protocol specified in <A=20
href=3D"http://www.bittorrent.org/protocol.html">[1]</A>, new peers take =
several=20
minutes to ramp up before they can effectively engage in BitTorrent's=20
tit-for-tat. The reason is simple: starting peers have few pieces to =
trade.</P>
<P><I>Allowed Fast</I> is an advisory message which means "if you ask =
for this=20
piece, I'll give it to you even if you're choked." <I>Allowed Fast</I> =
thus=20
shortens the awkward stage during which the peer obtains occasional =
optimistic=20
unchokes but cannot sufficiently reciprocate to remain unchoked.</P>
<P>The pieces that can be downloaded when choked constitute a peer's =
<I>allowed=20
fast set.</I> The set is generated using a canonical algorithm that =
produces=20
piece indices unique to the message receiver so that if two peers offer =
<I>k</I>=20
pieces fast it will be the same <I>k</I>, and if one offers <I>k+1</I> =
it will=20
be the same <I>k</I> plus one more. <I>k</I> should be small enough to =
avoid=20
abuse, but large enough to ramp up tit-for-tat. We currently set =
<I>k</I> to 10,=20
but peers are free to change this number, e.g., to suit load.</P>
<P>The message sender MAY list pieces that the message sender does not =
have. The=20
receiver MUST NOT interpret an Allowed Fast message as meaning that the =
message=20
sender has the piece. This allows peers to generate and communicate =
allowed fast=20
sets at the beginning of a connection. However, a peer MAY send Allowed =
Fast=20
messages at any time.</P>
<P>A peer SHOULD send Allowed Fast messages to any starting peer unless =
the=20
local peer lacks sufficient resources. A peer MAY reject requests for =
already=20
Allowed Fast pieces if the local peer lacks sufficient resources, if the =
requested piece has already been sent to the requesting peer, or if the=20
requesting peer is not a starting peer. Our current implementation =
rejects=20
requests for Allowed Fast messages whenever the requesting peer has more =
than=20
<I>k </I>pieces.</P>
<P>When the fast extension is disabled, if a peer recieves an Allowed =
Fast=20
message then the peer MUST close the connection.</P>
<H2 id=3DAllowed_Fast_Set_Generation>Allowed Fast Set Generation </H2>
<P>The canonical algorithm for computing a peer <I>P'</I>s <I>allowed =
fast=20
set</I> follows. All integers in this pseudocode are four bytes =
represented in=20
network (big-endian) byte order. <I>[a:b]</I> denotes the sequence of=20
consecutive integers from <I>a</I> to <I>b</I> excluding <I>b</I>, i.e., =
<I>(a,=20
a+1, a+2,..., b-1)</I>. <I>x[a:b]</I> denotes a subsequence of elements =
in an=20
array <I>x</I> starting from index <I>a</I> to but not including index =
<I>b</I>.=20
</P>
<P>Let <I>ip</I> denote <I>P'</I>s IPv4 address. We currently have no =
provisions=20
for IPv6. If a peer is behind a Network Address Translator (NAT) then =
<I>ip</I>=20
should be the externally facing IP address of the NAT. Since the node =
sending=20
the <I>Allowed Fast</I> messages computes the set, the correct <I>ip</I> =
is=20
usually the <I>ip</I> address on the other end of the connection. The =
host=20
computing the set MAY use the <I>ip</I> address on the other end of the=20
connection regardless </P>
<P>Let <I>sz</I> denote the number of pieces in the torrent. </P>
<P>Let <I>a</I> denote the allowed fast set. </P>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -