Peer ID Conventions
The 20-byte *peer id* field sent in tracker requests and in the peer handshake has traditionally been used not only to identify peers but also to identify the client implementation and version.
No reviewsSpecification
:Post-History:
The 20-byte peer id field sent in tracker requests and in the peer
handshake has traditionally been used not only to identify peers but
also to identify the client implementation and version.
The mainline client sets the first character in the peer-id to M
followed by version number represented by ascii digits with major,
minor and tiny versions separated by dashes. Examples include
M4-3-6-- or M4-20-8- for versions 4.3.6 and 4.20.8. The remaining
bytes in the peer id are random. The following list was originally
derived from [#theory]_.
A number of clients begin the peer id with a dash followed by two
characters to identify the client implementation, four ascii digits to
denote version number, and a dash. As with mainline, the remaining
bytes are random. An example is -AZ2060-.
Known clients that use this encoding style are
'AG' - Ares
'A~' - Ares
'AR' - Arctic
'AV' - Avicora
'AX' - BitPump
'AZ' - Azureus
'BB' - BitBuddy
'BC' - BitComet
'BF' - Bitflu
'BG' - BTG (uses Rasterbar libtorrent)
'BR' - BitRocket
'BS' - BTSlave
'BX' - ~Bittorrent X
'CD' - Enhanced CTorrent
'CT' - CTorrent
'DE' - DelugeTorrent
'DP' - Propagate Data Client
'EB' - EBit
'ES' - electric sheep
'FT' - FoxTorrent
'FW' - FrostWire
'FX' - Freebox BitTorrent
'GS' - GSTorrent
'HL' - Halite
'HN' - Hydranode
'KG' - KGet
'KT' - KTorrent
'LH' - LH-ABC
'LP' - Lphant
'LT' - libtorrent
'lt' - libTorrent
'LW' - LimeWire
'MO' - MonoTorrent
'MP' - MooPolice
'MR' - Miro
'MT' - MoonlightTorrent
'NX' - Net Transport
'PD' - Pando
'qB' - qBittorrent
'QD' - QQDownload
'QT' - Qt 4 Torrent example
'RT' - Retriever
'S~' - Shareaza alpha/beta
'SB' - ~Swiftbit
'SS' - SwarmScope
'ST' - SymTorrent
'st' - sharktorrent
'SZ' - Shareaza
'TN' - TorrentDotNET
'TR' - Transmission
'TS' - Torrentstorm
'TT' - TuoTu
'UL' - uLeecher!
'UT' - µTorrent
'UW' - µTorrent Web
'VG' - Vagaa
'WD' - WebTorrent Desktop
'WT' - BitLet
'WW' - WebTorrent
'WY' - FireTorrent
'XL' - Xunlei
'XT' - XanTorrent
'XX' - Xtorrent
'ZT' - ZipTorrent
The following clients have been seen in the wild and need to be identified
'BD' (example: -BD0300-)
'NP' (example: -NP0201-)
'wF' (example: -wF2200-)
Shad0w with his experimental BitTorrent implementation and BitTornado
introduced peer ids that begin with a character which isT in the
case of BitTornado followed by up to five ascii characters for version
number, padded with dashes if less than 5, followed by ---. The
ascii characters denoting version are limited to the following
characters
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.-
For example: 'S58B-----'... for Shadow's 5.8.11
As with other peer id formats, the remanining bytes are random. There
are significant deviations from this explained here [#shad0w]_.
Known clients that uses this encoding style are
'A' - ABC
'O' - Osprey Permaseed
'Q' - BTQueue
'R' - Tribler
'S' - Shadow's client
'T' - BitTornado
'U' - UPnP NAT Bit Torrent
BitComet produces peer ids that consists of four ASCII characters
exbc, followed by two bytes x and y, followed by random
characters. The version number is x in decimal before the decimal
point and y as two decimal digits after the decimal point. BitLord
uses the same scheme, but adds LORD after the version bytes. An
unofficial patch for BitComet once replaced exbc with FUTB. The
encoding for BitComet Peer IDs changed to Azureus-style as of BitComet
version 0.59.
XBT Client has its own style too. Its peer_id consists of the three
uppercase characters XBT followed by three ASCII digits representing
the version number. If the client is a debug build, the seventh byte
is the lowercase character d, otherwise it is a -. Following that
is a - then random digits, uppercase and lowercase letters. Example:
XBT054d- at the beginning would indicate a debug build of version
0.5.4.
Opera 8 previews and Opera 9.x releases use the following peer_id
scheme: The first two characters are OP and the next four digits
equal the build number. All following characters are random lowercase
hexdecimal digits.
MLdonkey use the following peer_id scheme: the first characters are
-ML followed by a dotted version then a - followed by
randomness. e.g. -ML2.7.2-kgjjfkd
Bits on Wheels uses the pattern -BOWxxx-yyyyyyyyyyyy, where y is
random (uppercase letters) and x depends on the version. Version 1.0.6
has xxx = A0C.
Queen Bee uses Brams new style: Q1-0-0-- or Q1-10-0-`` followed by
random bytes.
BitTyrant is an Azureus fork and simply uses AZ2500BT + random bytes
as peer ID in its 1.1 version. Note the missing dashes.
TorrenTopia version 1.90 pretends to be or is derived from Mainline
3.4.6. Its peer ID starts with 346------.
BitSpirit has several modes for its peer ID. In one mode it reads the
ID of its peer and reconnects using the first eight bytes as a basis
for its own ID. Its real ID appears to use \\0\\3BS (C notation) as
the first four bytes for version 3.x and \\0\\2BS for version 2.x. In
all modes the ID may end in UDP0.
Rufus uses its version as decimal ASCII values for the first two
bytes. The third and fourth bytes are RS. What then follows is the
nickname of the user and some random bytes.
G3 Torrent starts its peer ID with -G3 and appends up to 9
characters of the nickname of the user.
FlashGet uses Azureus style with FG but without the trailing
-. Version 1.82.1002 still uses the version digits 0180.
AllPeers takes the sha1 hash of a user dependent string and replaces
the first few characters with "AP" + version string + "-".
References
.. [#theory] http://wiki.theory.org/BitTorrentSpecification
.. [#shad0w] http://forums.degreez.net/viewtopic.php?t=7070
Copyright
This document has been placed in the public domain.
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End:
Discussion (0 threads)
Loading discussions...