What Is BEP 3: The Core BitTorrent Protocol
BitTorrent Enhancement Proposal 3 (BEP 3) is the official
specification that formalizes the original core BitTorrent peer-to-peer
file-sharing protocol. This article outlines what BEP 3 entails, breaks
down its core technical components—including Bencoding,
.torrent metadata files, tracker communication, and the
peer-to-peer wire protocol—and explains why it serves as the essential
baseline upon which all BitTorrent software and modern network
extensions operate.
What Is BEP 3?
BEP 3, titled "The BitTorrent Protocol Specification," documents the fundamental protocol originally created by Bram Cohen in 2001. In the BitTorrent ecosystem, BEPs (BitTorrent Enhancement Proposals) serve as formal design documents that describe new features, standards, or mechanisms for the protocol.
BEP 3 was created to standardize the existing core protocol mechanics, establishing a universal standard so that independent developers could build interoperable clients, trackers, and tools.
Core Technical Components Defined in BEP 3
BEP 3 standardizes four primary layers required for decentralized file distribution:
1. Bencoding
Bencoding is the lightweight data serialization format used across the BitTorrent protocol. BEP 3 defines four basic Bencoded types:
- Integers: Encoded as
i<integer>e(e.g.,i42efor 42). - Byte Strings: Encoded as
<length>:<contents>(e.g.,4:spamfor "spam"). - Lists: Encoded as
l<contents>e(e.g.,l4:spami42ee). - Dictionaries: Encoded as
d<key><value>e, where keys must be strings and sorted lexicographically.
Bencoding is robust against platform differences, endianness, and encoding errors, making it ideal for network transmission and file hashing.
2. Metainfo Files
(.torrent)
BEP 3 defines the structure of the standard .torrent
file, which contains the metadata necessary to download and verify
files:
- announce: The URL of the tracker.
- info dictionary: Includes file names, file lengths, piece length (typically 256 KB to a few megabytes), and a concatenated string of 20-byte SHA-1 hashes for every piece of the payload.
3. The Tracker Protocol
The tracker is a central server that coordinates peers without hosting the actual payload. BEP 3 defines the HTTP-based communication between clients and trackers:
- Announce Requests: Sent via HTTP GET containing
parameters such as
info_hash(the SHA-1 hash of the bencodedinfodictionary),peer_id,port,uploaded,downloaded, andleft. - Announce Responses: Returns interval times, seed/leecher counts, and a list of active peer IP addresses and ports.
4. The Peer Wire Protocol (PWP)
Once a client obtains peer addresses from the tracker, it uses the Peer Wire Protocol over TCP to exchange data directly. BEP 3 defines:
- Handshake: A fixed-format message verifying the
protocol string,
info_hash, andpeer_id. - State Management: Flags for
choked/unchoked(whether a peer is allowed to request data) andinterested/not interested. - Data Transfer Messages: Messages including
have(announcing piece availability),bitfield(sending overall availability map),request(requesting specific blocks within a piece), andpiece(transmitting payload data).
Why BEP 3 Is the Foundational Specification
BEP 3 is considered foundational for several critical reasons:
- Interoperability Baseline: Every BitTorrent client—regardless of operating system, programming language, or platform—must implement BEP 3 at a minimum to participate in a swarm.
- Built-in Integrity Verification: By mandating SHA-1 hashing on discrete pieces, BEP 3 solved the issue of data corruption and malicious tampering in peer-to-peer file transfers, allowing clients to re-download only corrupted pieces rather than the entire file.
- Foundation for Future Extensions: Subsequent innovations such as Distributed Hash Tables for trackerless transfers (BEP 5), Magnet Links (BEP 9), and Peer Exchange (BEP 11) do not replace BEP 3; instead, they build directly on top of the data framing, bencoding, and state machines established in this specification.