mirror of
https://github.com/transmission/transmission
synced 2024-12-23 08:13:27 +00:00
39 lines
1.7 KiB
Text
39 lines
1.7 KiB
Text
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:
|
|
v
|
|
string, client name and version. eg: Transmission 0.7
|
|
p
|
|
int, tcp port for incoming peer connections
|
|
m
|
|
dict containing supported extended messages and the extended id used
|
|
|
|
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.
|
|
|
|
µTorrent peer exchange messages use the key ut_pex in the m
|
|
dictionary. Peer exchanges messages should be sent approximately once
|
|
every minute. The payload of a peer exchange message is a bencoded
|
|
dictionary with the following keys:
|
|
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
|
|
added.f
|
|
string, one byte of flags for each peer in the above added string.
|
|
according to libtorrent's ut_pex.c:
|
|
0x01 - peer supports encryption
|
|
0x02 - peer is a seed
|
|
dropped
|
|
same format as added, contains peers dropped since last peer exchange
|