1 | A client that understands extended messages should set the 5th |
---|
2 | bit of the 6th byte of the reserved area in the handshake. For |
---|
3 | example: reserved[5] = 0x10 |
---|
4 | |
---|
5 | If the above bit is set in both peers' handshakes then they may |
---|
6 | exchange extended messages, which use id 20. The first byte of an |
---|
7 | extended message (after the 4-byte length and 1-byte id, of course) is |
---|
8 | the extended message id. The first extended message that should be |
---|
9 | sent is a handshake message, which always has an extended id of 0. |
---|
10 | |
---|
11 | The handshake message informs the peer which extended messages are |
---|
12 | supported and what their extended id will be. The message payload is |
---|
13 | a bencoded dictionary which may have some of the following keys: |
---|
14 | v |
---|
15 | string, client name and version. eg: Transmission 0.7 |
---|
16 | p |
---|
17 | int, tcp port for incoming peer connections |
---|
18 | m |
---|
19 | dict containing supported extended messages and the extended id used |
---|
20 | |
---|
21 | A peer may re-send the handshake message at any time to add new |
---|
22 | extended message, or to disable previous messages by sending 0 as |
---|
23 | their extended id. |
---|
24 | |
---|
25 | µTorrent peer exchange messages use the key ut_pex in the m |
---|
26 | dictionary. Peer exchanges messages should be sent approximately once |
---|
27 | every minute. The payload of a peer exchange message is a bencoded |
---|
28 | dictionary with the following keys: |
---|
29 | added |
---|
30 | string, contains peers in the compact tracker format |
---|
31 | (ie: 6 bytes for IPv4 address and port in network byte order) |
---|
32 | added since the last peer exchange message |
---|
33 | added.f |
---|
34 | string, one byte of flags for each peer in the above added string |
---|
35 | dropped |
---|
36 | same format as added, contains peers dropped since last peer exchange |
---|