source: trunk/doc/extended-messaging.txt @ 3237

Last change on this file since 3237 was 3237, checked in by charles, 14 years ago

update ltep documentation

File size: 2.1 KB
Line 
1A client that understands extended messages should set the 5th
2bit of the 6th byte of the reserved area in the handshake.  For
3example: reserved[5] = 0x10
4
5If the above bit is set in both peers' handshakes then they may
6exchange extended messages, which use id 20.  The first byte of an
7extended message (after the 4-byte length and 1-byte id, of course) is
8the extended message id.  The first extended message that should be
9sent is a handshake message, which always has an extended id of 0.
10
11The handshake message informs the peer which extended messages are
12supported and what their extended id will be.  The message payload is
13a bencoded dictionary which may have some of the following keys:
14    e
15        int, 1 or 0. a flag to denote whether the peer prefers
16        encrypted connections.  This is used in ut_pex's "added.f".
17    m
18        dict containing supported extended messages and the extended id used
19    p
20        int, tcp port for incoming peer connections
21    v
22        string, client name and version.  eg: Transmission 0.7
23
24A peer may re-send the handshake message at any time to add new
25extended message, or to disable previous messages by sending 0 as
26their extended id.
27
28uTorrent peer exchange messages use the key "ut_pex" in the m
29dictionary.  If the uTorrent peer has pex disabled, this key
30will not be present.  Exchanges messages should be sent approximately
31once every minute.  The payload of a peer exchange message is a
32bencoded dictionary with the following keys:
33
34    added
35        string, contains peers in the compact tracker format
36        (ie: 6 bytes for IPv4 address and port in network byte order)
37        added since the last peer exchange message
38
39    added.f
40        string, one byte of flags for each peer in the above added string.
41        according to libtorrent's ut_pex.c:
42        0x01 - peer supports encryption
43        0x02 - peer is a seed
44
45    dropped
46        same format as added, contains peers dropped since last peer exchange
47
48In contrast to Azureus' maximum of 50 peers per pex burst, uTorrent will
49hold up to 200.  alus reports: "uT stores max 200 from other peers, but it
50will send everything it has."
Note: See TracBrowser for help on using the repository browser.