bittorrent location-aware protocol 1_0 specification.mht

关于ＢＴ的协议文档

other=20
will wait. Again, the two peers from Madrid and Bratislava want a =
resource from=20
the Bulgarian peer. Let=E2=80=99s say the last one has 2 uploading =
slots, in other=20
words, n =3D 2. So, the other two start downloading the data. But during =
that time=20
a third peer requests the same data and he is located just two blocks =
away from=20
the Sofia peer. Now the priority queue of the uploader changes and the =
last=20
request (in time terms) goes on the top of the queue, the Madrid =
peer=E2=80=99s request=20
goes at the end and stops being served instead of the new request. </P>
<P>Here we are talking for only one resource all the time. If there are =
more=20
resources in the network (like in reality), the priority queue can be =
also=20
influenced by the level of availability of different data across the =
network.=20
</P>
<DIV class=3Deditsection style=3D"FLOAT: right; MARGIN-LEFT: 5px">[<A=20
title=3D"Edit section: Pros"=20
href=3D"http://wiki.theory.org/index.php?title=3DBitTorrent_Location-awar=
e_Protocol_1.0_Specification&amp;action=3Dedit&amp;section=3D4">edit</A>]=
</DIV><A=20
name=3DPros></A>
<H2>Pros </H2>
<P>How peer to peer systems with the implementation of the above =
technology will=20
be better? The direct impact on peers from small countries, where they =
have from=20
2 to 10 times higher limits on the inside traffic compare to the =
world-wide,=20
will be quite big. Let=E2=80=99s say there is a resource with 1000 =
seeders world-wide=20
and 5 are from the same country. If someone from that country wants this =
data=20
and the P2P system does not consider its location, the chance to have 1 =
of the 5=20
peers to share the data are small and the chances the 5 peers to upload =
it to=20
him are even slimmer. Because of this there are regional P2P systems, =
like=20
torrent trackers, that are serving one country. So, peers from that =
country=20
download resources from that torrent tracker, if available, because they =
will=20
get it much faster. This makes international trackers having fewer peers =
and=20
creates division of internet resources (in geographical terms). Because =
of=20
better inside traffic, peers form the same country could be considered =
closer=20
than they are in reality. But should this be done? If the inside traffic =
takes=20
more load, this will slowdown the expansion of international =
connections. </P>
<P>If this technology is implemented there will be no reason to use =
local P2P=20
networks, so global ones will have more seeders. Another indirect impact =
is that=20
more network resources will be freed and the price of internet services =
will=20
drop. When considering the traffic share of P2P systems and if this =
technology=20
is widely spread the price change will be noticeable. </P>
<DIV class=3Deditsection style=3D"FLOAT: right; MARGIN-LEFT: 5px">[<A=20
title=3D"Edit section: Cons"=20
href=3D"http://wiki.theory.org/index.php?title=3DBitTorrent_Location-awar=
e_Protocol_1.0_Specification&amp;action=3Dedit&amp;section=3D5">edit</A>]=
</DIV><A=20
name=3DCons></A>
<H2>Cons </H2>
<P>What are the negative sides? Let=E2=80=99s say a new data appears on =
the P2P network=20
and you want to get it, but the seeder is far away, while there are many =
peers=20
closer to him, requesting that data. In this case you will get it with a =
bigger=20
delay, but on overall more people will download it for the same time. =
</P>
<P>Considering the above scenario, more sophisticated methods could be =
developed=20
for sorting the priority queue. Let=E2=80=99s say there is a big group =
of peers at the=20
same geographical area, who want the same data, but there are no seeders =
close=20
to them. This may affect the seeders=E2=80=99 queue to move those =
requests forward,=20
although they are from remote peers. That way, after a peer from the =
cluster=20
gets a chunk from the data, he can distribute it right away to the =
others from=20
the group. </P>
<DIV class=3Deditsection style=3D"FLOAT: right; MARGIN-LEFT: 5px">[<A=20
title=3D"Edit section: Protocol Specification"=20
href=3D"http://wiki.theory.org/index.php?title=3DBitTorrent_Location-awar=
e_Protocol_1.0_Specification&amp;action=3Dedit&amp;section=3D6">edit</A>]=
</DIV><A=20
name=3DProtocol_Specification></A>
<H2>Protocol Specification </H2>
<P>How the technology should be implemented? There are plenty of =
protocols for=20
P2P sharing. Achieving backward compatibility, where possible, would =
create a=20
smoother transition. Here is presented an upgrade of the BitTorrent =
protocol=20
that will incorporate the location-aware technology. </P>
<DIV class=3Deditsection style=3D"FLOAT: right; MARGIN-LEFT: 5px">[<A=20
title=3D"Edit section: BitTorrent Location-aware Protocol 1.0"=20
href=3D"http://wiki.theory.org/index.php?title=3DBitTorrent_Location-awar=
e_Protocol_1.0_Specification&amp;action=3Dedit&amp;section=3D7">edit</A>]=
</DIV><A=20
name=3DBitTorrent_Location-aware_Protocol_1.0></A>
<H3>BitTorrent Location-aware Protocol 1.0 </H3>
<P>BitTorrent protocol specification is available at <A =
class=3D"external free"=20
title=3Dhttp://www.bittorrent.org/protocol.html=20
href=3D"http://www.bittorrent.org/protocol.html"=20
rel=3Dnofollow>http://www.bittorrent.org/protocol.html</A> and more =
extensible one=20
at <A class=3D"external free" =
title=3Dhttp://wiki.theory.org/BitTorrentSpecification=20
href=3D"http://wiki.theory.org/BitTorrentSpecification"=20
rel=3Dnofollow>http://wiki.theory.org/BitTorrentSpecification</A>. There =
are=20
already databases containing information about the physical location of =
IP=20
addresses around the world. But they are quite inaccurate. Sometimes =
they even=20
make mistake about the country of the IP address. This makes them still=20
unreliable, which leaves one way to define peer=E2=80=99s location =
=E2=80=93 the user must=20
select its own. Like country, region / state (if applicable), city / =
town. If=20
the city or town, the peer is in, is not an option to select, he should =
select=20
the closest one available or even better - to enter manually the =
latitude and=20
longitude of his position on the globe. While communicating with other =
peers or=20
the server and the peer=E2=80=99s location is required in the message, =
only the latitude=20
and longitude will be provided, not labels - like their city and =
country. This=20
allows difference between locations=E2=80=99 databases across different =
clients. The=20
tracker does not need to have such a database. Even the client side =
doesn=E2=80=99t, but=20
it will be definitely more user-friendly. </P>
<P>When leaving the location to the choice of the user, there should be =
a way to=20
prevent cheating. Let=E2=80=99s say he wants to download a file that is =
available at a=20
remote location. In order to get it faster he changes his location while =

downloading it. If such a behavior is widely spread, the whole essence =
will be=20
lost. So, the server should monitor changes of the location of every =
peer.=20
Since, there is no registration implemented in some torrent sites, the=20
identification of peers will include its IP address, but that is not =
enough,=20
since some ISPs dynamically assign IP addresses to their clients. So, =
one client=20
may have multiple IPs during a short period of time. Event worse, to =
provide=20
cheaper service ISPs have multiple clients sharing one IP address. Home =
networks=20
do this also. Together with the IP address the client side will provide =
the MAC=20
address of the network adapter the peer is using. This is not the =
perfect=20
protection, since the MAC address can be simulated or the client side to =
be=20
programmed in a way to lie about the real MAC address. There will always =
be some=20
who hacks the system, but the general public will not have the =
sufficient=20
knowledge to do it. When the tracker detects that a peer is changing his =

location too often it means he is cheating, so he may be considered to =
be far=20
away from all other peers for some period of time. </P>
<DIV class=3Deditsection style=3D"FLOAT: right; MARGIN-LEFT: 5px">[<A=20
title=3D"Edit section: Peer-tracker Handshake (Protocol Negotiation)"=20
href=3D"http://wiki.theory.org/index.php?title=3DBitTorrent_Location-awar=
e_Protocol_1.0_Specification&amp;action=3Dedit&amp;section=3D8">edit</A>]=
</DIV><A=20
name=3DPeer-tracker_Handshake_.28Protocol_Negotiation.29></A>
<H3>Peer-tracker Handshake (Protocol Negotiation) </H3>
<P>In order to make the upgrading of the BitTorrent protocol more =
scalable there=20
will be a peer-tracker handshake before the HTTP/HTTPS GET request for =
the list=20
of peers, since the set of parameters could differ in future protocols. =
The=20
first message will be an HTTP/HTTPS GET request with a parameter=20
<B>protocol</B>. It will define what protocols the peer supports. It can =
have=20
multiple values, since the client may support more than one protocol. =
Example =E2=80=93=20
<B>protocol=3DProt1.2&amp;protocol=3DProt1.1</B>. The order of the =
<B>protocol</B>=20
parameters is important. It is sorted by preference in descending order. =
The=20
protocol discussed here will have a name =E2=80=9C<B>BitTorrent =
Location-aware Protocol=20
1.0</B>=E2=80=9D. When included in the HTTP/HTTPS GET request it should =
be URL-escaped=20
of course. The server will respond just the name of the protocol as a =
string=20
(the string is in format defined by the BitTorrent protocol =
specification), that=20
it chose for the session. The connection should be kept alive after the=20
response, so the server knows what protocol chose to use and what to =
expect. If=20
none of the protocols, supported by the client, are not supported by the =
server,=20
the response will be in string format - =E2=80=9C<B>No protocol =
supported</B>=E2=80=9D and the=20
tracker will close the connection. If the tracker does not understand =
the=20
handshake it will return a <A class=3D"external text"=20
title=3Dhttp://wiki.theory.org/BitTorrentSpecification#Tracker_Response=20
href=3D"http://wiki.theory.org/BitTorrentSpecification#Tracker_Response" =

rel=3Dnofollow>failure reason</A>. The peer can than try to proceed by =
the=20
BitTorrent protocol specification. </P>
<DIV class=3Deditsection style=3D"FLOAT: right; MARGIN-LEFT: 5px">[<A=20
title=3D"Edit section: Request to the Tracker for the List of Peers"=20
href=3D"http://wiki.theory.org/index.php?title=3DBitTorrent_Location-awar=
e_Protocol_1.0_Specification&amp;action=3Dedit&amp;section=3D9">edit</A>]=
</DIV><A=20
name=3DRequest_to_the_Tracker_for_the_List_of_Peers></A>
<H3>Request to the Tracker for the List of Peers </H3>
<P>The peer-tracker handshake is followed by the HTTP/HTTPS GET request =
for the=20
peers list. Even if there is no protocol negotiation before this, the =
tracker=20
will assume to use the <A class=3D"external text"=20
title=3Dhttp://wiki.theory.org/BitTorrentSpecification=20
href=3D"http://wiki.theory.org/BitTorrentSpecification" =
rel=3Dnofollow>BitTorrent=20
protocol</A>. With the protocol returned by the server, the peer will =
know what=20
set of parameters to supply. In the case of the current protocol, =
together with=20
the parameters defined by the BitTorrent protocol specification, there =
will be=20
<B>latitude</B>, <B>longitude</B> and <B>mac_address</B>. Both, the=20
<B>latitude</B> and <B>longitude</B>, will be a decimal number in =
degrees at=20
base ten. The <B>latitude</B> south from the equator is negative and =
north from=20
it is positive. The <B>longitude</B> west from the Greenwich Meridian is =

negative and east from it is positive. This means, if we have 5=C2=B0 8' =
8"S latitude=20
and 8=C2=B0 4' 3"E longitude, the part from the query will look like=20
<B>latitude=3D-5.135556&amp;longitude=3D 8.0675</B>. The =
<B>mac_address</B>=20
parameter will be the MAC address on the client machine. It must be =
formatted as=20
a string with no dashes or dots. Example - =
<B>mac_address=3D000E2E3E3BCE</B>. It=20
is case-insensitive. </P>
<DIV class=3Deditsection style=3D"FLOAT: right; MARGIN-LEFT: 5px">[<A=20
title=3D"Edit section: Tracker List of Peers Response"=20
href=3D"http://wiki.theory.org/index.php?title=3DBitTorrent_Location-awar=
e_Protocol_1.0_Specification&amp;action=3Dedit&amp;section=3D10">edit</A>=
]</DIV><A=20
name=3DTracker_List_of_Peers_Response></A>
<H3>Tracker List of Peers Response </H3>
<P>After the above HTTP/HTTPS request, the server will return the <A=20
class=3D"external text"=20
title=3Dhttp://wiki.theory.org/BitTorrentSpecification#dictionaries=20
href=3D"http://wiki.theory.org/BitTorrentSpecification#dictionaries"=20
rel=3Dnofollow>bencoded dictionary</A> as usual, but the dictionaries in =
the <A=20
class=3D"external text"=20
title=3Dhttp://wiki.theory.org/BitTorrentSpecification#Tracker_Response=20
href=3D"http://wiki.theory.org/BitTorrentSpecification#Tracker_Response" =

rel=3Dnofollow>peers</A> list will have one more key =E2=80=93 =
<B>protocols</B>. This is a=20
<A class=3D"external text"=20
title=3Dhttp://wiki.theory.org/BitTorrentSpecification#lists=20
href=3D"http://wiki.theory.org/BitTorrentSpecification#lists"=20
rel=3Dnofollow>list</A> of <A class=3D"external text"=20
title=3Dhttp://wiki.theory.org/BitTorrentSpecification#byte_strings=20
href=3D"http://wiki.theory.org/BitTorrentSpecification#byte_strings"=20
rel=3Dnofollow>strings</A> defining the supported protocols by that =
peer. The=20
order in the list is again important. It is sorted by preference from =
the peer,=20
when he connected the tracker. Only one change =E2=80=93 the protocol =
returned from the=20
tracker in their handshake is inserted at the first position in the =
list. The=20
list will look like =E2=80=9C<B>l</B><I>&lt;protocol chosen by the=20
server&gt;&lt;referenced protocols by the peer&gt;</I><B>e</B>=E2=80=9D. =
If a peer from=20
the returned list doesn=E2=80=99t support <A class=3D"external text"=20
title=3Dhttp://wiki.theory.org/BitTorrent_Location-aware_Protocol_1.0_Spe=
cification#Peer-tracker_Handshake_.28Protocol_Negotiation.29=20
href=3D"http://wiki.theory.org/BitTorrent_Location-aware_Protocol_1.0_Spe=
cification#Peer-tracker_Handshake_.28Protocol_Negotiation.29"=20
rel=3Dnofollow>peer-tracker handshake</A>, the tracker will include this =
key value=20
pair anyway. But in this case just one item in the list, so bandwidth is =
saved.=20
Example =E2=80=93 =E2=80=9C<B>l</B><I>19:BitTorrent =
protocol</I><B>e</B>=E2=80=9D. With the=20
implementation of the protocols declaration, the peers will always find =
the best=20
protocol to communicate between each other. In cases where the chosen =
protocol=20
between the tracker and the peer is the =E2=80=9CBitTorrent =
Location-aware Protocol 1.0=E2=80=9D=20
the dictionaries in the <A class=3D"external text"=20
title=3Dhttp://wiki.theory.org/BitTorrentSpecification#Tracker_Response=20
href=3D"http://wiki.theory.org/BitTorrentSpecification#Tracker_Response" =

rel=3Dnofollow>peers</A> list will have two more keys - <B>latitude</B> =
and=20
<B>longitude</B>. They are going to define the peer=E2=80=99s location =
and will be=20