2007-03-23 08:28:01 +00:00
|
|
|
A client that understands extended messages should set the 5th
|
|
|
|
|
bit of the 6th byte of the reserved area in the handshake. For
|
|
|
|
|
example: reserved[5] = 0x10
|
|
|
|
|
|
|
|
|
|
If the above bit is set in both peers' handshakes then they may
|
|
|
|
|
exchange extended messages, which use id 20. The first byte of an
|
|
|
|
|
extended message (after the 4-byte length and 1-byte id, of course) is
|
|
|
|
|
the extended message id. The first extended message that should be
|
|
|
|
|
sent is a handshake message, which always has an extended id of 0.
|
|
|
|
|
|
|
|
|
|
The handshake message informs the peer which extended messages are
|
|
|
|
|
supported and what their extended id will be. The message payload is
|
|
|
|
|
a bencoded dictionary which may have some of the following keys:
|
2007-09-29 23:58:37 +00:00
|
|
|
e
|
|
|
|
|
int, 1 or 0. a flag to denote whether the peer prefers
|
|
|
|
|
encrypted connections. This is used in ut_pex's "added.f".
|
2007-03-23 08:28:01 +00:00
|
|
|
m
|
|
|
|
|
dict containing supported extended messages and the extended id used
|
2007-09-29 23:58:37 +00:00
|
|
|
p
|
|
|
|
|
int, tcp port for incoming peer connections
|
|
|
|
|
v
|
|
|
|
|
string, client name and version. eg: Transmission 0.7
|
2007-03-23 08:28:01 +00:00
|
|
|
|
|
|
|
|
A peer may re-send the handshake message at any time to add new
|
|
|
|
|
extended message, or to disable previous messages by sending 0 as
|
|
|
|
|
their extended id.
|
|
|
|
|
|
2007-09-29 23:58:37 +00:00
|
|
|
uTorrent peer exchange messages use the key "ut_pex" in the m
|
|
|
|
|
dictionary. If the uTorrent peer has pex disabled, this key
|
|
|
|
|
will not be present. Exchanges messages should be sent approximately
|
2008-11-30 01:15:43 +00:00
|
|
|
once every minute when peers have been added or dropped.
|
|
|
|
|
|
|
|
|
|
If peers have not been added or dropped, uTorrent does not send
|
|
|
|
|
the periodic PEX message. If uTorrent 1.8.1 recieves an "empty"
|
|
|
|
|
pex message from Transmission 1.40, it appears to interpret this
|
|
|
|
|
as an invalid message and disconnect from Transmission.
|
|
|
|
|
|
|
|
|
|
The payload of a peer exchange message is a
|
2007-09-29 23:58:37 +00:00
|
|
|
bencoded dictionary with the following keys:
|
|
|
|
|
|
2007-03-23 08:28:01 +00:00
|
|
|
added
|
|
|
|
|
string, contains peers in the compact tracker format
|
|
|
|
|
(ie: 6 bytes for IPv4 address and port in network byte order)
|
|
|
|
|
added since the last peer exchange message
|
2007-09-29 23:58:37 +00:00
|
|
|
|
2007-03-23 08:28:01 +00:00
|
|
|
added.f
|
2007-08-25 04:20:25 +00:00
|
|
|
string, one byte of flags for each peer in the above added string.
|
|
|
|
|
according to libtorrent's ut_pex.c:
|
2010-05-29 19:02:35 +00:00
|
|
|
|
|
|
|
|
1: encryption
|
|
|
|
|
2: seed/upload_only
|
|
|
|
|
4: uTP support
|
|
|
|
|
8: holepunch support
|
|
|
|
|
16: outgoing connection (implies peer is connectible)
|
2007-09-29 23:58:37 +00:00
|
|
|
|
2007-03-23 08:28:01 +00:00
|
|
|
dropped
|
|
|
|
|
same format as added, contains peers dropped since last peer exchange
|
2007-09-29 23:58:37 +00:00
|
|
|
|
|
|
|
|
In contrast to Azureus' maximum of 50 peers per pex burst, uTorrent will
|
|
|
|
|
hold up to 200. alus reports: "uT stores max 200 from other peers, but it
|
|
|
|
|
will send everything it has."
|
