A BitTorrent client
Stage 4 of 12v2 · 50a45cef

Tracker request

Build percent-encoded parameters without changing infohash or peer-ID bytes.

Tracker request

Build percent-encoded parameters without changing infohash or peer-ID bytes. The implementation is cumulative and must preserve earlier operations.

Observable contract

The harness reads JSON and represents binary data as hexadecimal. Tracker and peer replies are supplied as fixtures to avoid external networking and randomness.

{
  "op": "tracker-url",
  "base": "http://tracker/announce",
  "infoHashHex": "000102",
  "peerId": "-SC0001-abcdefghijkl",
  "port": 6881,
  "left": 4
}

produces exactly:

{
  "url": "http://tracker/announce?info_hash=%00%01%02&peer_id=-SC0001-abcdefghijkl&port=6881&uploaded=0&downloaded=0&left=4&compact=1"
}

Emit compact JSON and a final newline. Invalid requests leave stdout empty, include error on stderr, and exit non-zero.

Implementation

Keep binary data as bytes: do not turn hashes, peer IDs, or pieces into text except where the protocol says so. Separate framing, peer state, scheduling, and integrity. Verify lengths and hashes before publishing a piece as complete.

Walk through the fixture by offsets and test fragmentation, duplicate messages, timeouts, and peers advertising inconsistent data. Tests do not use the Internet; connect the same logic to real sockets outside the harness.

Acceptance criteria

  • The representative case produces the exact output.
  • No unverified data reaches the final file.
  • Scheduling is deterministic for the same input.