However that specification page does a rather poor job – besides of the obvious html layout deficiencies – when it comes to explaining what design decissions were made and why. This lead to many client writers out there wondering what the connect packet is about.

While there are sites around with a layout that at least does not try to prevent implementation, rationale for the extension completely is absent.

1. The connect packet

Now, what is the extra connect packet all about? Wasn’t the udp extension all about saving packets hammering the server? The answer is, it was designed to prevent address spoofing. While tcp inherently prevents address spoofing with its initial handshaking – you can only finish it if the recipient of SYN+ACK is the same address that sent the SYN – udp does not provide any means of ensuring that the packet really originated from the address it claims to be.

So Olaf van der Spek – designer of that protocol extension – demands that a client first uses a connect packet to acquire a uniq-ish connection_id that it later presents to the tracker to prove listening on that very address.

What way of chosing, storing and comparing connection_ids a tracker implements is up to him, one possible way would be chosing one very long global tracker secret, and then calculate a cryptographically secure checksum of this secret appended by the clients alleged ip address. This approach would not require the tracker to store anything per client for it can be calculated everytime that client comes back.

However, when writing the specification, Olaf made the mistake of not mentioning this feature and – even worse – using the term connection_id for two completely unrelated values: A connect packet contains a static protocol identifier at the same offset where on announce and scrape packets that unique connection_id is expected. Olaf even also calls that value connection_id. Hence half of the non-connect udp packets arriving at opentracker still contain 0×41727101980 as connection_id.

To be honest, opentracker is not completely innocent. Since we could freely chose which values to put there, we just left the old connection_id. This might have given the impression that the whole connection_id thing just is a sanity feature to distinguish stray udp packets arriving on that port.

Now we’re facing the problem that enforcing connection_id checking would really hurt udp announces. This is not in our interest. As a first step we changed our code to return a different value as connection_id. Now we want to encourage all client authors supporting udp to check their implementation against the way it was meant to be. In some months from now opentracker will enforce connection_id checking.

2. Auto UDP

As you may have guessed by now we do love udp announces a lot more than the tcp stuff. So introducing ways to increase the number of those more lightweight client interactions is in our own very interest.

We do know that it is hard to encourage users to add udp:// addresses to their torrents. Still most tracker responses on earth are being handled by trackers that are capable of speaking udp (and soon also udp-v6). This means that sending udp connect packets to the corresponding udp port of a http tracker url will most likely succeed.

We hereby invite all client authors to probe the corresponding udp announce address, store the result on a per-tracker base, use udp whenever feasible (i.e. for announces and [non-full-]scrapes) and revert to tcp only if udp fails.

3. IPv6

And while you are at it: you might also want to take a look at our v6 protocol extension proposal.

Still, we consider IPv6 very important and convenient. Its use could solve all NAT-dependent connectivity issues and heavily reduce complexity in clients. On the other hand we noticed that introducing IPv6 in a transitional way creates many headaches in inter-protocol communication. To remove some barriers we propose the following request for comments which will be incorporated into opentracker and thus available at tpb soon.

1. The clouds

To be frank: there will be two clouds for each torrent, one in IPv4 and one in IPv6. Clients capable of handling IPv6 connections and still interested in IPv4 peers will need to announce their torrents to trackers twice. This is a harsh decission, but in the end most IPv4 peers are not interested in IPv6 peers and there is no easy way to tell whom to return which peers.

The proposed way to identify a peer’s internet protocol version defaults to the incoming socket address and can be overridden by the ip parameter from the announce http request.

This is very much how Bram Cohen layed it out in his Tracker-Protocol. Of course, overriding only works for trackers that allow overriding ip addresses with the one passed in the query. All others have no means of obtaining the ip address for the other protocol version.

Scrapes will be answered for each cloud independently according to the requestors ip address protocol version.

2. Tracker TCP Responses

Most trackers (e.g. opentracker) have completely switched to only returning compact responses in order to save, or better: not to waste bandwidth. That compact format is just a string of multiple of six bytes that contain ip address and port for as many peers as do fit there. Filling it with or mixing in IPv6 addresses is impossible without breaking backward compatibility.

So we propose adding another “peers6″ entry in the announce response dictionary that contains a string of zero or more entries, each 16 bytes network byte order IPv6 addresses followed by 2 byte network byte order port number. The “peers6″ entry must not be present in non-compact mode.

3. Tracker UDP Responses

The UDP-protocol has not left any space for IPv6-addresses in its current form. So we need to define a new action together with its input and output block formats.

Proposed extension to the UDP Tracker format to work over IPv6, we claim a value for the action identifier of “4″.:

However, becoming so huge and being so exposed brings its risks. opentracker is written in plain C and handles strings. Strings that have been sent through the internet. So we kindly ask the community to help us make the code more secure by reviewing critical parts of it. Especially the part that parses URIs is a natural point to start looking into.

So if you are experienced in C, serious about helping to review or just need some explanation on opentrackers rougher edges, feel free to contact us at code@denis.stalker.h3q.com. We do also appreciate patches that fix bugs and warnings on operating systems we have not tested opentracker on and source packages for certain package distribution systems.

ThePirateBay plans to switch the last trackers running hypercube to our opentracker software as soon as we have all features implemented. This should be real soon now.

You might argue that a bittorrent tracker does not actually seek to kill its clients, yet the amount of fire it attracts is comparable and I always wanted to refer to “UHF” in a blog posting.

When you have to handle that many requests per seconds (I’m told, were approaching the 350 in the moment), you basically have two choices: try to figure out a complex multithreaded connection handling framework that dispatches your complex database layout or go for simplicity and try to handle request sequentially and be fast to serve them.

Before I can go into that I need to explain, what a bittorrent tracker does. In Germany there’s an institution called Mitfahrzentrale. Basically you tell them, you’re driving from one city to another at a certain date or that you would want to but lack the car. In any way, Mitfahrzentrale tells you, who also wanted to get to the same place by the same time and provides you with contact information.

With bittorrent you acquire all information you need to share a file by the .torrent file you get from bittorrent search engines. This file lists all trackers that will play Mitfahrzentrale for you plus a token to identify your ride there: a twenty bytes (160 bits) info_hash, calculated over the .torrent file.

All contact information you need to connect to another peer wanting to share the same file is its IP address and a port number its client listens on. In IPv4 thats six bytes. If you are familiar with organizing data you might by now have noticed that you just need structures to hold twenty bytes per torrent plus a pointer to a list of six byte entries for each peer.

Before I can describe, how our first important design decission evolved, you need to know about the reasons, other clients chose different designs. Bram Cohen decided to tunnel all tracker requests through HTTP (over TCP, of course) which has two draw backs. First: most requests plus its answers comfortably fit into one ethernet frame each. Having to setup a TCP connection for requests requires nine packets average instead of two, you would get when using UDP, which would even leave us with enough bandwidth for eight retries before the more reliable TCP protocol could perform better. Second: HTTP itself is an awfully complex protocol to implement. If you’re just supposed to give a simple answer to a simple question, I would argue its use is inappropriate. Considering that most firewalls let HTTP connections pass unhindered, using HTTP would be excused – if the actual data connections between peers weren’t just some binary TCP streams doomed to be filtered.

Now, when you’re using some httpd to handle the protocol for you, anyway – why bother doing the rest as a C or C++ language CGI? A typical coders reflex is to write a php-script using mysql as data backend. You learned in computer science course, that using a data base to store your data is the way to go. Right? The framework will do all the threading and forking for you, your data base ensures an appropriate locking.

Well, we thought different.

Using a kick-ass all-features-on data base? Constructing complex SQL-queries to select six byte structures from lists accessed by twenty byte indexes, that already come pre-hashed? Having a data/metadata ratio of 1:10000? Doing local data base connections, that involves setting up unix sockets again to blow up a twenty bytes request and its 50*6 bytes answer up to several kbytes overhead. No way!

All techniques to efficiently store that little data (were talking about eight MBs for 100,000 info_hashes and six MBs for 1,000,000 peers here) were around for fourty years. As already mentioned, you can use info_hash’s first bytes to address buckets, since they are already hashed. So you can easily keep sorted lists you may do binary searches in. With some minor abstractions you can sort your peers into pools you can chose to release after bittorrents peer time out.

All left to do was to find a framework to handle HTTP. Fortunally I’ve been following libowfat‘s development for a while. It is a highly scalable multi platform framework modelled after Prof. Daniel J. Bernsteins fascinating low level abstraction library, but exploiting most IO acceleration techniques like kqueue and poll. Felix von Leitner added an example httpd application that became basis for what opentracker is today. What we do is to accept, answer and close all incoming connections as fast as possible, using static buffers. This approach easily scales up to several thousand requests per second. The only reason for not having exact numbers is us being too lazy to implement stress testing software in C and all other test suites being too slow to request more than some hundred connections per second.

You can follow opentracker‘s development here.