What Is the BitTorrent HAVE Message and When Is It Sent?

In the BitTorrent peer-to-peer protocol, the “have” message is a lightweight communication signal used to notify connected peers that a client has successfully acquired and validated a specific piece of a shared file. This article explains the structure and role of the “have” message, how it differs from initial state announcements, and the exact conditions under which a client broadcasts it across the swarm to optimize file distribution.

Understanding the “HAVE” Message

The “have” message is a core message type in the BitTorrent peer wire protocol, assigned the standard message ID of 4. Its payload consists of a single, fixed-size 4-byte (32-bit) integer representing the zero-based index of a specific file piece.

Because files in BitTorrent are split into equal-sized chunks called pieces, peers need a way to track which chunks their connected neighbors possess. The “have” message serves as an incremental update to a peer’s availability status, consuming minimal bandwidth compared to sending full-state messages.

When the “HAVE” Message Is Broadcast

A BitTorrent client broadcasts a “have” message to its connected peers under specific, sequential conditions:

1. Piece Completion: The client finishes downloading all individual blocks (sub-pieces) that constitute a single piece.
2. Cryptographic Verification: The client computes the SHA-1 hash of the newly assembled piece and compares it against the expected hash provided in the .torrent metadata.
3. Immediate Swarm Broadcast: Once the hash is verified as valid and uncorrupted, the client immediately sends a “have” message containing that piece’s index to all actively connected peers in the swarm.

If the hash verification fails, the piece is discarded, and no “have” message is generated.

Purpose and Function Within the Swarm

Broadcasting the “have” message is critical for several protocol operations:

• Dynamic State Tracking: While a client uses a bitfield message upon the initial connection handshake to announce all pieces it currently holds, sending a full bitfield repeatedly during active downloading would be inefficient. The “have” message allows peers to dynamically update their internal representation of each other’s piece availability one piece at a time.
• Informing “Rarest-First” Strategies: BitTorrent peers prioritize downloading the pieces that are least available across the swarm (the rarest-first algorithm). Receiving “have” messages allows clients to recalculate piece rarity in real time and adjust their download queues accordingly.
• Managing Choke and Interest States: When a peer receives a “have” message for a piece it still needs, it updates its status to “interested” regarding the sending peer, opening up opportunities for data requests.

Selective Broadcasting and Extensions

Under standard conditions, the message is broadcast to all connected peers. However, modified behaviors exist:

• Super-Seeding Mode: An initial seeder attempting to minimize uploaded data redundancy may selectively send “have” messages to specific peers, pretending it only has certain pieces to encourage those peers to upload to others before receiving new pieces.
• Fast Extension (HAVE ALL / HAVE NONE): The BitTorrent Fast Extension (BEP 6) introduces optimizations where a peer that has the complete file sends a single HAVE ALL message at connection time, avoiding the need to send hundreds or thousands of individual “have” messages or a massive bitfield.