source: trunk/doc/azureus-protocol.txt @ 2919

Last change on this file since 2919 was 2795, checked in by joshe, 15 years ago

Doc update.

File size: 3.0 KB
1This is a somewhat incomplete description of the Azureus messaging
2protocol which is further described here:
6A client that understands the azureus messaging protocol should set
7the 8th bit of the first byte of the reserved area in the handshake.
8For example: reserved[0] = 0x80
10Like normal bittorrent messages, all azureus messages begin with the
11length of the rest of the message in bytes as a 4-byte integer in
12network byte order.  This length does not include the 4 bytes for the
13length itself.
15After that is another 4-byte network byte order integer containing the
16length of the following message id string in bytes, then the message
17id string, then a 1 byte integer containing the protocol version.  The
18current version is 1.
20The message payload format for various message IDs is below.
23payload is a bencoded dictionary:
24    identity:
25        string, 20 bytes client identity.  The identity should be
26        calculated once on startup similarly to the peer_id, except
27        than each byte should be completely random and not limited to
28        alphanumeric characters.
29    client:
30        string, client name.  eg: Transmission
31    version:
32        string, client version.  eg: 0.7
33    tcp_port: (optional)
34        int, tcp port for incoming peer connections.
35    udp_port: (optional)
36        int, udp listening port (what is this used for exactly?)
37    udp2_port: (optional)
38        int, udp non-data listening port (I don't know what this is for either)
39    handshake_type: (optional)
40        int, 0 for plain or 1 for crypto
41    messages:
42        list, each item is a dict for the supported messages and versions:
43            id:
44                string, message id
45            ver:
46                string, 1 byte version, currently 1
49these messages should be sent approximately once a minute (is this true?)
50payload is a bencoded dictionary:
51    infohash:
52        string, 20 byte info_hash for the torrent
53    added:
54        list, each item is a 6 byte string for an IP address and port
55        added since the last peer exchange message.
56    added_HST:
57        string, one byte for each item in the added list.
58        Each byte is the handshake type (0 plain, 1 crypto) for the matching
59        item in the added list.
60    added_UDP:
61        string, two bytes for each item in the added list.
62        Each pair of bytes is the UDP port (network byte order) for the
63        matching item in the added list.
64    dropped:
65        same format as added, contains peers dropped since last peer exchange
66    dropped_HST:
67        same format as added_HST
68    dropped_UDP:
69        same format as added_UDP
72zero-length payload
74The following messages all have the same payload as the corresponding
75bittorrent message, not including the bittorrent 4-byte length and
761-byte id.
78BT_CHOKE        - 0
79BT_UNCHOKE      - 1
82BT_HAVE         - 4
83BT_BITFIELD     - 5
84BT_REQUEST      - 6
85BT_PIECE        - 7
86BT_CANCEL       - 8
Note: See TracBrowser for help on using the repository browser.