Norwegian State TV Launches its own BitTorrent Tracker using opentracker
By taklamakan | March 8, 2009
We are proud to announce that the Norwegian State TV Launches its own BitTorrent Tracker and they are using the opentracker software!
Maybe we will get a barrel of norwegian beer some day? 
Seems like the Norwegian State TV has understood what their viewers want, to quote Torrentfreak: “NRK understands that the traditional distribution methods are changing, and that their viewers want to consume television shows wherever and whenever they want. The way people consume music and video has changed, and NRK doesn’t want to fall behind.”
Hurray for Norwegian State TV!
Topics: free speech, history | 5 Comments »
Beerware dreams
By erdgeist | January 1, 2009
The opentracker team wants to thank Berlin’s pirate party (Piratenpartei Berlin) for their encouragement in the development of opentracker which they showed in form of a 50 Liter barrel of delicious bavarian beer.
With the heroic and sacrificially help of many Congress Angels we finally managed to spend all the beer and have – to our best knowledge – not introduced any bugs due to the consumption.
So hohoho to the pirates and a happy 2009 to everyone.
Topics: Uncategorized | 1 Comment »
Still alive and kicking…
By erdgeist | December 28, 2008
For those wondering what all the silence in this blog means.
Yes, we’re still alive and kicking. Currently discussing all our proposals with client developers, which is consuming more time and energy as we thought it would. You can usually find us at IRC channel #transmission on freenode and join discussions.
We’re also preparing to introduce some real crypto into our udp protocol and trying to enforce good behaviour towards trackers. Also opentracker has been heavily refactored and will enjoy some more changes towards multi threading capabilities due in january 2009.
So stay tuned. And to all opentracker users: a happy 2009!
Topics: Uncategorized | No Comments »
auto-UDP up and running
By foobar423 | June 11, 2008
In our last post we made the advise to use some sort of auto-UDP because it would also help to lower the trackertraffic for EVERY torrent even if they have an HTTP announce URL.
We can now (a little late, but not without a little pride…) announce that Azureus has support for auto-UDP since version 3.0.5.0 (they revised it a little in 3.0.5.2). So it seems to work and we would like to suggest others to follow their steps. Every big tracker admin loves that and will be grateful.
supergrobi
Topics: Uncategorized | 3 Comments »
The UDP situation
By erdgeist | January 2, 2008
Most of the problems we have to cope with in our everyday opentracker struggle arises from operating systems having to handle several thousand tcp connection setups, reassembly and tear downs. As a mean to help ease the impact of these requests, a udp extension to the tracker protocol has been agreed upon.
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.
As always, feel free to comment on that topic at our coders mailing list.
Topics: coding, tech | 3 Comments »
The IPv6 situation
By erdgeist | December 28, 2007
If you haven’t spent the last decade behind a C64 you may have noticed a HugeNewThing™ called IPv6 is coming. There still are some issues that prevent its wide spread use. No consumer DSL has it. Most people wouldn’t even care what *IPv4* is. However, bittorrent has been designed to work with IPv6 out of the box. Many convenience extensions in the Bittorrent-Tracker protocol – compact tracker responses, for example – do not. Worse: others like the UDP-Tracker protocol do not even look like having taken IPv6 into account at all.
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″.:
Request:
| Offset | Size | Name | Value |
| 0 | 64-bit integer | connection_id | |
| 8 | 32-bit integer | action | 4 |
| 12 | 32-bit integer | transaction_id | |
| 16 | 20-byte string | info_hash | |
| 36 | 20-byte string | peer_id | |
| 56 | 64-bit integer | downloaded | |
| 64 | 64-bit integer | left | |
| 72 | 64-bit integer | uploaded | |
| 80 | 32-bit integer | event | |
| 84 | 16-byte string | IP address | |
| 100 | 32-bit integer | key | |
| 104 | 32-bit integer | num_want | -1 |
| 108 | 16-bit integer | port |
The corresponding reply looks as follows:
Response:
| Offset | Size | Name | Value |
| 0 | 32-bit integer | action | 4 |
| 4 | 32-bit integer | transaction_id | |
| 8 | 32-bit integer | interval | |
| 12 | 32-bit integer | leechers | |
| 16 | 32-bit integer | seeders | |
| 20+n*18 | 16-byte string | IPv6 address | |
| 36+n*18 | 16-bit integer | TCP port |
We consider those the most sane design decissions that do not deviate from existing protocol too much and hope to receive feedback on our proposal, from closed source implementations as well as the usual open source suspects.
Topics: coding, tech | 7 Comments »
« Previous Entries