Ntrack: The Network Tracker protocol
Spec Version: 0.1.1
Ntrack is a simplification and generalization of the bittorrent HTTP tracker protocol.
The aim is to produce a more lean and streamlined protocol that removes bittorrent specific aspects and can be used for any number of peers to associate IP:PORTs to a given key (info_hash in the case of Bittorrent).
The main goals are:
- Simple: retain the simplicity and transparency of textual data, and further simplify the data structures and URL scheme.
- Lean: as bandwidth and computationally efficient as reasonably possible.
- General: Should be useful for any task that requires a bunch of decentralized clients to publish their connection information.
- Backwards compatible: we don’t want to break (too much) existing Bittorrent clients.
Note: this effort almost completely unrelated to the new UDP bittorrent tracker protocol.
- BT: Bittorrent tracker protocol.
- NT: Ntrack tracker protocol.
- Key: An arbitrary UTF-8 string, in BT it is the info_hash.
- Track: A set of IP:PORTs associated with a key.
- Tracker: A server that collects and publishes tracks from and to clients.
- Peer: A client that connects to a tracker to publish its connection information to a given track and retrieve the connection information of other peers in the track.
Changes from BT
Proposed backwards compatible Changes from the BT tracking protocol:
- ‘info_hash’ is an arbitrary string (ie., a key).
- ‘peer_id’ is deprecated, if included it will be ignored.
- ‘ip’ is deprecated and can be ignored, always use the HTTP client’s ip. [XXX]
- ‘port’ is optional, if missing use the port of origin of the HTTP connection.
- ‘uploaded’, ‘downloaded’ and ‘left’ can be ignored.
- The semantics of ‘event’ are ambiguous and bittorrent specific enough that it can be safely ignored. [XXX]
New ntrack REST-ful interface
A ntracker serves by convention in the path
/ntrack, so only an ip or domain, and no
full url is needed to refer to a given ntracker.
An HTTP GET request from IP 220.127.116.11 and port 1234 to the URL:
Is equivalent to this request in the classic BT tracker protocol:
They are marked with [XXX] in the text of this document.
- Should the Key have a length limit?
- Some kind of generic
- Maybe we need something like ‘event’ but with better defined semantics, so peers can easily remove themselves from the list and so on.
- If we could find a way to avoid having even the key in the URL this might improve the privacy aspects a bit (many http servers log the URL and client ip/port which are enough to reconstruct the tracker’s data structures). Perhaps using HTTP POST with bencoded data rather than the querystring.
One could think of ntrack as a centralized, dynamically updated, and extremely simplified DNS system.
Ntrack is compatible with [the HTTP 0.2 subset of HTTP](<http://http02.cat-v.org).
- Online games
- Chat systems
- Distributed computing