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:
    e
        int, 1 or 0. a flag to denote whether the peer prefers
        encrypted connections.  This is used in ut_pex's "added.f".
    m
        dict containing supported extended messages and the extended id used
    p
        int, tcp port for incoming peer connections
    v
        string, client name and version.  eg: Transmission 0.7

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.

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
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
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:

         1: encryption
         2: seed/upload_only
         4: uTP support
         8: holepunch support
        16: outgoing connection (implies peer is connectible)

    dropped
        same format as added, contains peers dropped since last peer exchange

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."