What Is the BitTorrent Stopped Event?

In the BitTorrent protocol, the “stopped” event is a specific notification sent from a torrent client to a tracker when a user pauses, cancels, or stops an active transfer. This article explains how the BitTorrent announce mechanism functions, what payload data accompanies the event=stopped request, how trackers handle this notification, and why this event is vital for maintaining accurate swarm health and statistics.

How Tracker Communication Works

BitTorrent clients communicate with central coordinators known as trackers using periodic HTTP or UDP requests called “announces.” These announcements inform the tracker about the client’s current status and request an updated list of peers.

During standard operation, these requests include key parameters such as: * info_hash: The unique identifier of the torrent. * peer_id: The unique identifier of the client. * uploaded and downloaded: Total bytes transferred during the session. * left: Bytes remaining until download completion. * event: The current state change of the transfer.

Under normal downloading or seeding, the event parameter is omitted from regular interval announcements. It is only included when a transition occurs: started, completed, or stopped.

Triggers for the “Stopped” Event

A torrent client automatically dispatches an announcement containing event=stopped whenever active participation in a swarm ends. Common triggers include:

Tracker Processing of the “Stopped” Event

When a tracker receives a request with event=stopped, it executes several key cleanup actions:

  1. Peer Removal: The tracker immediately removes the client’s IP address and port from the active peer list for that specific info_hash.
  2. Swarm Metrics Update: The tracker decrements its internal counter for either seeders (if left=0) or leechers (if left>0).
  3. Stat Accounting: In private or ratio-monitored trackers, the final upload and download statistics contained in the request are credited to the user’s account before closing the session.

Importance of the “Stopped” Event

If a client terminates without sending the stopped event (such as during a crash, network loss, or forced termination), the tracker remains unaware that the peer has disconnected.

Without this notification: * The tracker continues serving the disconnected client’s IP to other peers (creating “ghost peers”). * Incoming connection attempts by other peers to that disconnected client will fail and time out, causing unnecessary network overhead. * Swarm seeder/leecher counts remain temporarily inaccurate until the tracker’s internal timeout mechanism (often 30 to 45 minutes) expires and purges the inactive peer.

By sending event=stopped, the client ensures immediate cleanup, preserving swarm efficiency and network performance for all remaining peers.