Fragen? Antworten! Siehe auch: Alternativlos
Aber natürlich ist es auch Ziel, mal die Klagewelle der Verwertungsindustrie abzuwenden, indem man mal einem Richter sachverständig erklärt, wie eigentlich so ein Tracker funktioniert. (NB: als Sachverständige, nicht als Beklagte) Ich will das hier mal stellvertretend versuchen, für das Verständnis unlauter abkürzend, aber nicht sinnentstellend.
Ein Tracker verteilt keine Dateien. Nehmen wir mal an, ihr wollt euch den Fnord-Jahresrückblick 2010 per Bittorrent runterladen. Das Torrent-File beinhaltet folgendes:
Ihr habt euch also die Torrent-Datei gezogen, und mit der geht euer Torrent-Client jetzt der Reihe nach zu den Trackern, die in der Datei drinstehen, und sagt denen: hallo, ich bin ein Torrent-Client, ich habe Interesse an dem Torrent mit diesem Hashwert hier (der, der in der Torrent-Datei drinsteht), und ich habe von den Nutzdaten schon folgende Blöcke hier.
Der Tracker hat jetzt eine Liste oder auch Datenbank von allen Hashes, nach denen er schon gefragt wurde, und trägt als erstes bei dem angefragten Hash die IP-Adresse des Anfragenden ein. Dann gibt er dem Client eine Teil-Liste von IPs zu dem Hash. Nicht alle IPS, sondern nur ein paar. Und man kann auch nicht einfach mehrfach fragen und kriegt dann alle oder auch nur andere IPs. Da muss man warten, bis der Tracker andere IPs rausrückt.
Mit diesen IPs geht der Client jetzt herum und fragt jeden davon, welche Blöcke er hat. Dann fängt er an, von den Clients hinter den IPs die Blöcke zu downloaden, die noch am wenigsten verbreitet sind.
Die beachtenswerten Punkte hierbei sind: der Tracker weiß gar nicht, was er da trackt. Alles, was er hat, ist ein Hashwert. Der sieht, wenn man ihn in Form einer Magnet-URL schreibt, so aus:
magnet:?xt=urn:btih:3CJATDQBXFUEQCXVXZHUUNALQK5GXCTQNehmen wir jetzt mal an, du bist ein Tracker. Und jemand kommt zu dir und fragt nach den IPs zu obigem Hash. Nicht nur bist du kein Raubkopierer, du kannst nicht mal wissen, ob es sich bei den Nutzdaten, die diesen Hash ergeben haben, um eine Raubkopie handelt oder nicht. Du kannst nicht mal wissen, ob es überhaupt Nutzdaten gibt, die diesen Hash ergeben, denn ein Troll kann natürlich einfach nach einer beliebigen Zahlenkombination fragen, zu der es am Ende gar keinen Torrent gibt.
Wenn die Content-Industrie sich also hinstellt, und dem Trackerbetreiber Beihilfe unterstellt, dann hat das von den Fakten her keinerlei Basis in der Realität. Es gibt nichts, was ein Trackerbetreiber tun könnte, um zu einem gegebenen Torrent herauszufinden, um was für Inhalte es sich handelt. Er könnte natürlich loslaufen und Suchmaschinen nach dem Hash befragen. Aber selbst dann hat er ja nur den Dateinamen und Hashes, d.h. er muss die Nutzdaten erst einmal selber runterladen, um prüfen zu können, ob es sich um eine Raubkopie handelt. Es ist also überhaupt nicht möglich für einen Trackerbetreiber, das Tracken von Raubkopien zu verhindern. Selbst wenn der Trackerbetreiber nur Hashes seiner eigenen Dateien zulässt, dann kann es theoretisch immer noch Raubkopien geben, die denselben Hashwert ergeben. Die Wahrscheinlichkeit ist zwar sehr gering, aber ausgeschlossen ist das nicht.
Nun könnte man sich vorstellen, dass die Verwertungsgesellschaften eine Liste von "verbotenen" Hashes publiziert. Und die geben sie dem Trackerbetreiber, und der blockiert die dann. Was passiert, wenn man sowas zulässt, sieht man gerade schön auf Youtube, wo regelmäßig Creative Commons-Musik runterfliegt, weil irgendeine Verwertungsgesellschaft einen "bedauerlichen Fehler" begangen hat.
Aus Sicht des CCC ist ein Tracker eine Art schwarzes Brett im Internet, auf dem IP-Nummern und Zahlenreihen draufstehen. Wir haben den Content gar nicht, um den es da geht, und daher kann man von uns nicht verlangen, dass wir da groß prüfen.
Der CCC findet, dass der Betrieb eines offenen Trackers legal ist, auch wenn Gerichte in der Vergangenheit gerne mal (in vermuteter Unkenntnis der Technik) anders entschieden haben.
Nun ist das natürlich nicht schön gelaufen, dass die Leute vom Piratebay den Tracker so schnell gefunden haben und auch noch in ihre Torrents eintragen. Dieser Tracker ist nämlich gerade nicht, wie vom ehemaligen Nachrichtenmagazin schlampig recherchiert, der "Nachfolgetracker von denis.stalker", der im Übrigen nicht mal ein Angebot des CCC war. Wenn das eine Kampagne sein soll, um unsere Argumentation in Ermangelung von Gegenargumenten per Assoziation mit der Piratenbucht zu schädigen, dann wird das scheitern.
Übrigens braucht man Tracker gar nicht mehr notwendigerweise. Es gibt inzwischen auch Verfahren, wie sich Clients ganz ohne Tracker gegenseitig finden können. Diese ganze sinnlose Fixierung auf die Tracker kommt daher, dass die Contentindustrie keinen besseren Ansatzpunkt gefunden hat, um ihr veraltetes Denkmodell von "es gibt da einen gewerbsmäßigen Hehler und lauter Konsumenten, die wir aber nicht abmahnen wollen, weil das ja unsere Kunden sind" auf Bittorrent anzuwenden, und wenn man keine Ahnung von der Materie hat, sieht so ein Tracker wie das am ehesten passende Ziel aus.
Update: Es gibt auch ein neues Blogposting dazu im Opentracker-Blog. Oh und ja, der Tracker ist absichtlich offen, da dürft ihr gerne eure Linux-ISO-Images drauf tracken, und eure Creative Commons-Musik.
Update: Wer sich für weitere Details zu Trackern interessiert, dem sei auch noch mal der 24c3-Vortrag dazu ans Herz gelegt. Den gibt es auch bei Piratebay :-)
Falls ihr mehr wissen wollt: Video saugen und gucken. Wenn aus dem Torrent nichts mehr rausfällt, kriegt ihr das Video auch auf ftp.ccc.de (Pfad müsst ihr selber raussuchen).
Heute zeige ich euch mal, wie sich ein Hacker einen perfekten Sonntagnachmittag vorstellt. Der erdgeist und ich, wir haben uns im Chat hingesetzt und wollten diesen Code hier optimieren:
for (i=0; i+1<l; ++i) {Der Code kommt aus gatling und soll feststellen, ob die bisher reingekommenen Daten schon einen fertigen HTTP-Header ergeben. erdgeist interessiert sich dafür, weil er den Opentracker hackt, der ja eh schon der mit Abstand schnellste Torrent-Tracker ist, und jetzt soll der eben auch Keep-Alive kriegen, und dafür muss er dann auch mal die Header richtig parsen. Nun ist das aus praktischen Erwägungen heraus nicht sonderlich sinnvoll, an so einer Stelle die letzten Taktzyklen heraus zu optimieren, weil der Bulk der Last eh im TCP Stack anfällt. gatling und opentracker sind I/O-bound, nicht CPU-bound. Aber hey, als zwei alte Bitfrickler haben wir uns mal hingesetzt und das optimiert.
if (c[i]=='\n' && c[i+1]=='\n')
return i+2;
if (i+3<l &&
c[i]=='\r' && c[i+1]=='\n' &&
c[i+2]=='\r' && c[i+3]=='\n')
return i+4;
}
Der offensichtliche Ansatz ist an der Stelle, dass man die Speicherzugriffe reduzieren will. Die überwiegende Mehrheit an Daten wird zwar weder CR noch LF sein, und insofern wird es auch im Normalfall nicht vorkommen, dass der alte Code zu viele unnötige Speicherzugriffe macht, aber hey, es ist Sonntag, da muss man nicht rational entscheiden. Das generelle Problem heißt String Matching und ist in der Informatik an sich gut untersucht. Das Buch der Wahl dazu habe ich vor ein paar Jahren gelesen und finde es gerade nicht wieder. Es ist jedenfalls von diesem Chilenen hier, nur sah bei meinem das Cover gelb aus. Egal. Es gibt mehrere schöne Verfahren, um einen bestimmten String schnell zu finden, aber die meisten schnelleren brauchen eine Tabelle, in der sie dann pro einkommendem Zeichen was nachgucken. Das ist zwar in der theoretischen Informatik schnell, aber in der Praxis habe ich dann sogar mehr Speicherzugriffe als ich jetzt habe. Insbesondere bei einem so kurzen Muster wie CR-LF-CR-LF. Das Verfahren, das ich einsetzen wollte, heißt Shift-Or und ist durch agrep populär gemacht worden. Auch Shift-Or braucht eine Tabelle pro Zeichen, aber dadurch dass mein Muster nur aus zwei Zeichen besteht, kann man das auch inline machen. Zur Veranschaulichung der Idee paste ich mal ein Stück Code, das ich mal für ein altes Kommerz-Projekt gehackt habe:
int detect_magic(const unsigned char c) {Kurz gesagt hat man ein Array, in dem pro Zeichen im Muster eine 0 oder 1 steht. An Position 0 steht eine 1, wenn das letzte reinkommende Zeichen das erste Zeichen im Muster ist. An Position 1 steht eine 1, wenn das letzte reinkommende Zeichen das zweite Zeichen im Muster ist und das vorige Zeichen das erste im Muster war. Pro reinkommendem Zeichen schiebt man das Array einmal durch und setzt die ausscheidenden Varianten auf 0. Das Muster ist in der Eingabe erkannt worden, wenn der letzte Eintrag im Array 1 ist. Nun ist das natürlich auch alles andere als speichereffizient, da ein Array zu verschieben pro reinkommendem Zeichen, aber wenn man sich das Verfahren mal genau anguckt, kann man auch statt eines Array einen Integer nehmen und pro Eintrag im Array ein Bit in diesem Integer. Solange das Muster höchstens so viele Zeichen wie der Integer Bits hat. Das ist dann genau das Shift-Or Verfahren, weil man pro reinkommendem Zeichen den Integer um eins shiftet und eine 1 hinten dran packt, wenn das Zeichen passt. Dann muss man jeweils mit einer von der Eingabe abhängenden Maske ANDen. In unserem Falle, wenn ein CR reinkommt, ist die Maske (1+4), weil CR in dem Muster an Position 0 und 2 vorkommt, also setzt man Bit 0 und 2 und da kommt dann eben 5 raus. Der traditionelle Shift-Or Algorithmus sieht an der Stelle wieder eine Tabelle vor, aber weil ich ja nach CR-LF-CR-LF matchen will, und da nur CR und LF vorkommen, kann ich die beiden Werte auch inline hinschreiben. Für alle Zeichen, die nicht im Muster vorkommen, ist die Maske 0, d.h. man löscht alle Bits im Integer.
#define my_magic "fnord";
static char* magic = my_magic;
static char maybe[sizeof(my_magic)];
int i;
for (i=sizeof(my_magic)-2; i>=1; --i)
maybe[i]=(maybe[i-1] && (c==magic[i]));
maybe[0] = (c==magic[0]);
return maybe[sizeof(my_magic)-2];
}
Der Code, wie ich ihn eingecheckt habe, sieht so aus:
int state=0;Euch wird auffallen, dass ich beim Newline-Fall erst 1 ORe und dann mit einem Wert ANDe, bei dem die 1 dann wieder rausfällt. Ja, stimmt, das soll so. Man könnte die 1 da jetzt rausnehmen, aber das spart keine Zyklen, also lasse ich das drinnen, damit man dem Algorithmus folgen kann.
for (i=0; i<l; ++i) {
switch (c[i]) {
case '\r':
state=((state<<1)|1)&(1+4);
break;
case '\n':
state=((state<<1)|(1+16))&(2+8+16+32);
break;
default:
state=0;
}
if (state==26 || state==48) return i+1;
So, nun wären wir keine Hacker, wenn wir uns damit zufrieden geben würden. Hier ist die Endversion:
int state;Ihr könnt ja mal gucken, ob ihr das versteht, was da vor sich geht. Wie ihr sehen könnt, shiften wir jetzt nicht mehr einen nach links sondern zwei nach rechts. Hach, ich liebe C! :-)
for (i=state=0; i<l; ++i)
if ((state = (c[i]=='\r' || c[i]=='\n') ?
(state >> 2) | (( c[i] << 6) & 0xc0 ) : 0) >= 0xa0 ||
state == 0x99)
return i+1;
Abgesehen davon: wenn ihr Rotwein mögt, probiert doch mal einen Refosco. Ich habe gestern einen 2003er Refosco bei meinem lokalen Weinhändler gekauft, und das war einer der besten Rotweine, die ich je hatte. Die Rebenart kennt keine Sau, die Flasche kostete nur knapp 7 Euro. Den Wein muss man in einen Dekanter tun und eine halbe Stunde atmen lassen. Dann zieht er einem die Schuhe aus. Oh und falls ihr Rum mögt: den Diplomatico aus Venezuela kann ich wärmstens empfehlen. Wenn der Andreas seinen Rausch ausgeschlafen hat, wird er euch das sicher bestätigen.
Update: Der eine oder andere Spezialist auf dem Gebiet wird jetzt einwenden wollen, dass wir besser einen Boyer-Moore benutzen sollen. Stimmt, ist auch trotz des kurzen Musters schneller. Aber ergibt keinen so schön eindrucksvollen Blogpost.
Sowas motiviert natürlich, und daher werden wir jetzt mal an ordentlicher Multicore-Skalierbarkeit arbeiten.
Ein tieferer Griff ins Klo geht nicht, wenn man sich anguckt, was die behaupten, das ihr Ziel sei.
Naja, selber Schuld, kann ich mit leben, wenn die Leute darauf bestehen, sich das linke Auge rauszustechen. Aber jetzt haben sie sich selber übertroffen. Jetzt haben sie jabber.ccc.de geblockt.
Ja, richtig gelesen. Wer sich mit peerguardian in den Fuss schiesst, macht sich nicht nur die vertrauenswürdigen Bittorrent-Tracker kaputt, sondern auch den einzigen halbwegs vertrauenswürdigen öffentlichen Jabber-Server, der in einem Land mit Datenschutzgesetzen betrieben wird.
Was kann man da nur sagen? Ab in die Tonne mit PeerGuardian. Und nachdem ihr das deinstalliert habt, lasst sie ruhig wissen, wie tief sie gerade ins Klo gegriffen haben. Ich persönlich setze peerguardian nicht ein und torrente auch neben den Congressvideos nicht viel, aber wenn die schon den CCC-Familientracker (inzwischen übrigens aus Lastgründen nur noch ein Forward auf die Pirate Bay Tracker) und den CCC-Jabber-Server plattmachen, dann ist davon auszugehen, dass Peerguardian-User auch www.ccc.de nicht lesen können. Daher erwähne ich das hier, bevor ich auch geblockt werde :-)
Insofern habe ich mich sehr gefreut, dass mein Kumpel eRdgEiSt seinen opentracker auf Basis von libowfat geschrieben hat. Damit haben sie dann einen fetten öffentlichen Torrent-Tracker aufgesetzt, und der hat auch kräftig Skalierbarkeit demonstriert. Wir waren alle stolz auf uns. Aber der heilige Gral war es noch nicht. Der heilige Gral ist der größte Torrent-Tracker der Welt. Und, was soll ich euch sagen, jetzt ist es offiziell: PirateBay steigt auf Opentracker um. Im Moment läuft auf vier ihrer Tracker der Opentracker (der öffentliche Torrent-Tracker meiner Kumpels läuft unter BSD, das ist halt der Vorteil eines schönen Abstraktionslayers, das würde z.B. auch unter Solaris gut laufen, und beim PirateBay läuft es unter Linux) und frühstückt da 17000 Hits pro Sekunde ab mit vier Trackern, verteilt auf sieben Rechner (die benutzen da DNS Round Robin zur Lastverteilung). Ja, das ist ein bewegender Moment für mich, und ich gratuliere eRdgEiSt zu seiner coolen Tracker-Software.
Da sollen einige lustige Details drin stehen, wie z.B. daß die Tor benutzen, damit sie überhaupt auf Piratebay klicken können, daß sie selber alle Torrents runterladen und dann die Warez gucken und sich gegenseitig kommentieren, in welchem Film in der Mitte ein Typ durchs Bild läuft. Also kurz: das sind professionelle Warez-Konsumenten. Über meine Kumpels und ihren Tracker sagen sie, das sei der, dem sie am schnellsten Fakes reindrücken konnten (vermutlich weil die anderen alle weniger effizient sind). Das lesen die bestimmt auch mit einem lachenden und einem weinenden Auge. Außerdem sollen da noch diverse IP-Ranges gelistet sein, von denen aus sie oder ihre Konkurrenz kommen. Da werden sich ja die Warez-Leute freuen :-)
Mir hat da jemand im Chat folgende Zeilen gepasted:
Can you guys please provide us with the samples, jpegs or any extras when you guys download Fantastic Four 2: Rise of the Silversurfer.
Yes, I would download this but our ips are banned for Piratebay and other sites…Thanks.
Überhaupt scheint das eine Fundgrube zu sein. Hier noch ein Paste aus dem Chat:FYI: The IPs we use for interdiction are banned on PirateBay's trackers. The only way our interdiction will work is if DHT is enabled for the torrent.