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., i42e for 42). * Byte Strings: Encoded as <length>:<contents> (e.g., 4:spam for “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 bencoded info dictionary), peer_id, port, uploaded, downloaded, and left. * 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, and peer_id. * State Management: Flags for choked/unchoked (whether a peer is allowed to request data) and interested/not interested. * Data Transfer Messages: Messages including have (announcing piece availability), bitfield (sending overall availability map), request (requesting specific blocks within a piece), and piece (transmitting payload data).

Why BEP 3 Is the Foundational Specification

BEP 3 is considered foundational for several critical reasons: