sixserv blog[nks]

Eigentlich wollte ich ja was über den BitTorrent Message-Flow schreiben, aber aus aktuellem Anlass gibt es heute einen “kleinen” Artikel über DHT.

DHT

Aus gegebenem Anlass schreibe ich nun etwas früher als geplant über DHT. Die ThePirateBay-Tracker sind nun schon etwas länger Down, es sind zwar etliche Ersatz-Tracker aus dem Boden gesprossen, aber meiner Meinung nach ist das dezentrale Tracking nun an der Reihe. Die Tracker waren bis jetzt einer der grössten Angriffs/Schwachpunkte der BitTorrent Technologie/ des BitTorrent Protokolls.
Doch das muss nicht so sein, denn es gibt ja DHT (BEP005). Ich will mich hier mal etwas näher mit DHT beschäftigen und das DHT Protokoll näher erklären.

Die Technologie hinter DHT im BitTorrent-Protokoll basiert auf Kademlia. Kademlia wurde von Petar Maymounkov und David Mazières entwickelt und “implementiert” bzw spezifiziert Distributed Hashtables in P2P-Netzen. Verschaffen wir uns erstmal einen kleinen Überblick über Kademlia.

BEP005 spezifiziert das die Daten per UDP übertragen werden. Zuerst generiert der Client eine Node ID, diese wird genauso wie der BitTorrent Infohash errechnet, bzw nutzt den selben Bit-raum (160Bit). Danach beginnt das Bootstrapping, der Client muss sich ja erstmal im DHT zurechtfinden und einen anderen Client finden dieser Teilt dann weitere IPs mit. Meist ist die erste Node “router.bittorrent.com” da ein Scannen durch die eigene IP-Range oder willkürliches suchen nach anderen Nodes nicht so erfolgversprechend ist.
Zur Indizierung von BitTorrent-Hashes wie es ein Tracker macht trägt bei DHT jeder Peer/Node bei.
Wenn wir nun einen bestimmten Hash suchen kann die Entfernung zu diesem Hash ausgerechnet werden. Dafür werden entweder Node IDs und Node IDs verglichen, oder Infohashes und Node IDs, durch den “Algorithmus” lässt sich die “nähe” der Node ID zur gesuchten ID (Infohash oder Node ID) errechnen. Die Routing Tabelle die der Client nun erstellt wird immer detaillierter je näher wir an den gesuchten ID-Wert kommen und die Node mit der gewünschten Information gefunden haben. Jede Node hat “Kontaktdaten” zu den Nodes mit “nahen” IDs.

Die Distanz zwischen 2 IDs wird per XOR berechnet:

distanz(A,B) = |A xor B|

Je kleiner das Ergebnis desto näher Liegen sich A und B.

Wenn nun eine Node (im DHT) Peers (für BitTorrent) finden will passiert folgendes:
Ich gehe davon aus das das Bootstrapping schon fertig ist, wir also ein Paar Nodes schon in unserer Routing-Tabelle haben. Unser Client nimmt nun den Infohash aus der Torrent-File. Wir nehmen Beispielsweise den Hash
362b0a1151013916896a9c98b52e0ead803c4ac3 (ubuntu-7.10-alternate-hppa.iso). Unser Client wird die Node mit dem geringstem Abstand zum Infohash nun Kontaktieren und diese Node nach Peer-Kontaktdaten Fragen. Wenn diese Node Peer-Kontaktdaten besitzt werden diese zu unserem Client übermittelt und dieser baut dann über das BitTorrent-Protokoll eine Verbindung zum Peer auf. Wenn die Node keine Peer-Kontaktdaten hat wird sie uns Kontaktdaten zu den Nodes aus ihrer Routing-Tabelle geben die am Nächsten an unserer ID liegen, und so weiter und so fort!

Die Antwort der Nodes auf die Anfrage nach Peers zu einem Infohash beinhaltet immer einen “token”. Wenn wir nun dem Node von dem wir die Peer-Kontaktdaten bekommen haben mitteilen wollen (wie beim Tracker ein sogenannter “announce”), müssen wir dem Node neben dem Announce auch den Token schicken den wir zuvor
von ihm erhalten haben.
Es liegt auf der Hand das dies eine Sicherheitsmaßnahme ist, damit nicht irgendwelche unbekannten Hosts (Bots von der MI) den DHT verseuchen. Die BEP005 spezifiziert das die Tokens alle 5 Minuten neu generiert werden, sie bestehen aus einem SHA1-Hashes auf die IP Adresse verknüpft mit einem Salt (welches alle 5 Minuten wechselt).

Routing
Kommen wir nun zum Aufbau der Routing Tabelle unseres Nodes. Die Routing Tabelle ist beinhaltet alle Bekannten Nodes die noch errechbar sind (das wird in einem Zeitraum von 15 Minuten getan) und diese Nodes dienen als Startpunkte für neue anfragen im DHT.

Die Nodes in unserer Routing Tabelle werden je nach ihrer Erreichbarkeit eingestuft. Die Erreichbarkeit jeder Node wird alle 15 Minuten überprüft. Eine Node wird als “good” eingestuft wenn sie uns eine Anfrage geschickt oder beantwortet hat innerhalb der letzten 15 Minuten. Wenn eine Node innerhalb von 15 Minuten nicht aktiv war wird sie  “questionable” also Fragwürdig eingestuft. Ein Node wird als “bad” eingestuft wenn er auf mehrere Anfragen nicht geantwortet hat. Unsere Routing-Tabelle sollte nur “good”-Einträge enthalten.

Die Routing Tabelle deckt den kompletten Raum an möglichen IDs ab (von 0 bis zu 2^160). Die Routing-Tabelle ist in “Buckets” (Eimer) unterteilt. Eine leere Routing-Tabelle enthält einen Bucket mit dem ID-Raum von 0 (min) bis 2^169 (max). Wenn wir nun eine Node mit der hypothetischen ID “A” (normal ist die ID natürlich 20byte lang wie beim Infohash) dann wird diese in einen Bucket eingefügt der min < A < max ist. Also in einem Bereich bei dem
min kleiner als A ist und A kleiner als max
In einer leeren Routing-Tabelle ist nur ein Bucket also passen in diesen Bucket alle möglichen IDs rein. Allerdings kann ein Bucket nur K verschiedene Einträge enthalten, im Moment ist K=8. Wenn der Bucket voll mit “good”-Nodes ist, werden keine Nodes mehr hinzugefügt – AUßER die eigene Node ID fällt in den Bereich, in diesem Fall wird der Bucket durch zwei neue Buckets ersetzt und die Nodes aus dem Vorherigem Bucket werden auf die zwei neuen Buckets aufgeteilt. Diese zwei Buckets könnten bei einer Routing-Tabelle mit nur einem Bucket dann jeweils die Bereiche vor und nach unserer ID abdecken (min/max werte).

Jeder Bucket sollte (das ist natürlich jedem selbst überlassen, wenn man es denn Implementiert) eine “last changed” Eigenschaft haben um die “frische” des Buckets ablesen zu können. Auch hier sollte alle 15 Minuten die Erreichbarkeit der enthaltenen Nodes überprüft werden. Laut BEP005 wird dies folgendermaßen gemacht:
Eine zufällig ausgewählte ID aus dem Bereich des Buckets (min/max) wird mit einer “find_nodes” (dazu weiter unten im Protokoll-Bereich mehr) Anfrage kontaktiert – bei Antwort ist die Node noch zu gebrauchen, wenn
nicht sollte die Node aus dem Bucket entfernt werden. Wenn eine Node Anfragen von anderen Nodes nicht beantworten kann, z.B. wegen schlechten Router-Settings, dann sollte Sie ihre Buckets öfter Auffrischen als eine Node die auf Anfragen antworten kann, den eine solche Node erhält ja eh immer wieder neue Node IDs.
Die Node sollte zudem versuchen ihr selbst nahe liegende Nodes zu finden.

BitTorrent Protokoll

Wenn unser BitTorrent-Client DHT unterstützt, wird bei den Protokoll-Flags im Handshake das letzte Byte gesetzt. Wenn nun ein anderer Peer uns beim Handshake das er DHT Supported, senden wir ihm mit der PORT-Message des BitTorrent-Protokolls unseren UDP-Port auf dem unsere DHT-Implementierung lauscht. Die DHT-Implementierung Pingt dann die neue Node und wenn eine Antwort kommt wird diese nach den oben definierten Regeln in einen Bucket eingefügt oder auch nicht (bei keiner Antwort).

Torrent File

Die Torrent-File enthält keine “announce”-URL mehr, sondern einen “nodes”-Key. Dieses Nodes Dictionary enthält die K (K=8) nähsten bekannten Nodes von dem Client der die .torrent-File erstellt hat. Oder halt eine Liste mit K bekannten “good”-Nodes. Das Nodes-Dictionary ist wie folgt aufgebaut:

nodes = [["",], ["",], ...]
nodes = [["127.0.0.1", 6881], ["your.router.node", 4804]]

Protokolle

Kademlia RPC Protololl

KRPC ist relativ schnelle und einfach erklärt. Die Einzelnen Messages sind wie bei BitTorrent üblich BEncoded. Auf einen Request kommt eine Antwort/Response. Es gibt drei Message-Typen: query, reponse und error.
Beim DHT-Protokoll sind es vier: ping, find_node, get_peers und announce_peer. Eine KPRC-Message besteht aus einem Dictionary mit zwei Keys, sowie zusätzlich je nach Message-Typ zusätzliche Felder.
Der Key “t” beinhaltet die “transaction id”, die “tansaction id” wird beim Query errechnet und dient dazu Anfragen und Antworten zuzuordnen. Sie besteht meistens nur aus 2 Buchstaben, da diese vollkommen ausreichen um eine große Anzahl von Anfragen abzudecken.
Der andere Key ist “y” und beinhaltet als Wert nur einen einzigen Buchstaben:

• q: query
• r: response
• e: error

Um die Kontaktdaten von Peers zu übertragen werden diese Kodiert. Hier kommt die selbe Kodierung wie beim Compact-Encoding bei BitTorrent zum Einsatz, ein 6-Byte String – wobei die ersten 4 Byte die IP repräsentieren und die letzten 2 den Port.
Um die Kontaktdaten von anderen Nodes zu übertragen werden diese ebenfalls Kodiert, dies geschieht jedoch mit dem “Compact Node Encoding”. Hier ist es ein 26-Byte String. Die ersten 20byte enthalten die Node ID die restlichen 6 sind die Compact-Encodierte IP und der Port wie oben.

Queries/Anfragen
Der “y” Key enthält als Wert “q” wie weiter oben schon erklärt. Zusätzlich noch die die zwei Keys “a” und “q”.

• q: enthält den Methodennamen des Queries (DHT Protokoll z.B. Ping)
• a: enthält die Argumente

Responses/Antworten
Der “y” Key enthält hier den Wert “r” für Response.
Zusätzlich enthält diese Message den Key “r”:

• r: ist ein Dictionary mit den Ergebnissen der Anfrage

Errors/Fehler
Der “y” Key enthält den Key “e” für Error.

• e: enthält eine Liste:
  • das erste Element der Liste enthält den Fehler Code
  • das zweite Element die Fehlermeldung

Mögliche Fehler und ihre Entsprechenden Messages:

Beispielhaftes Error Packet aus BEP005:

generic error = {"t":"aa", "y":"e", "e":[201, "A Generic Error Ocurred"]}
bencoded = d1:eli201e23:A Generic Error Ocurrede1:t2:aa1:y1:ee

DHT Queries

Bei den DHT Anfragen enthält jeder Query einen “id”-Dictionary als Argument, neben etwaigen anderen Argumenten, welcher die Node ID der anfragenden Node beinhaltet (20-Byte String in Network Byte
Order) die Antworten enthalten natürlich die Node ID der antwortenden Node.

Hier die Möglichen Queries:

ping
Der Key “q” für den Query-Typ beinhaltet hier den Wert “ping”. Der Key “a” für die Argumente enthält einen Dictionary mit dem Key “id” und als Wert wie oben schon erklärt die Node ID in Network Byte Order.

Example Packets aus BEP005:

ping Query = {"t":"aa", "y":"q", "q":"ping", "a":{"id":"abcdefghij0123456789"}}
bencoded = d1:ad2:id20:abcdefghij0123456789e1:q4:ping1:t2:aa1:y1:qe

Response = {"t":"aa", "y":"r", "r": {"id":"mnopqrstuvwxyz123456"}}
bencoded = d1:rd2:id20:mnopqrstuvwxyz123456e1:t2:aa1:y1:re

find_node:
Dieser Query wird benutzt um die Kontaktinformationen zu einer bestimmten Node anhand ihrer ID herauszufinden. Der “q”-Key enthält hier logischerweise “find_node”.
Die Argumente im “a”-Key enthalten wie immer die eigene Node ID und hier noch das Target-Dictionary welches folgende Keys enthält:

• “target”:  ID der gesuchten Node

Als Antwort auf einen “find_node”-Query sollte die Antwort einen Key namens “nodes” enthalten der die Compact-Encoded-Node Informationen der gesuchten Node oder 8 (K) der nähsten bekannten “good”-Nodes enthalten.

Beispiel aus BEP005:

find_node Query ={"t":"aa", "y":"q", "q":"find_node","a":{"id":"abcdefghij0123456789","target":"mnopqrstuvwxyz123456"}}
bencoded = d1:ad2:id20:abcdefghij01234567896:target20:mnopqrstuvwxyz123456e1:q9:find_node1:t2:aa1:y1:qe

Response = {"t":"aa", "y":"r", "r": {"id":"0123456789abcdefghij", "nodes": "def456..."}}
bencoded = d1:rd2:id20:0123456789abcdefghij5:nodes9:def456...e1:t2:aa1:y1:re

get_peers:
Mit diesem Query erhält man Peers für den Torrent Download. “q” entspricht hier “get_peers”. Die Argumente sind “id” mit der Node ID und “info_hash” mit dem Infohash des Torrents. Die Antwort enthält den Key “values” der eine Liste von Strings enthält die entweder Compact-Encoded IP der Peers enthält, oder wenn keine Peers bekannt sind: einen Key “nodes” der eine Liste mit 8 (K) Nodes im Compact-Encoded Format enthält. In jedem Fall wird bei der Antwort ein Key “token” übertragen (der Token wird bei einem “announce” gebraucht).

Beispiele aus BEP005:

get_peers Query = {"t":"aa", "y":"q", "q":"get_peers", "a": {"id":"abcdefghij0123456789", "info_hash":"mnopqrstuvwxyz123456"}}
bencoded = d1:ad2:id20:abcdefghij01234567899:info_hash20:mnopqrstuvwxyz123456e1:q9:get_peers1:t2:aa1:y1:qe

Response with peers = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "values": ["axje.u", "idhtnm"]}}
bencoded = d1:rd2:id20:abcdefghij01234567895:token8:aoeusnth6:valuesl6:axje.u6:idhtnmee1:t2:aa1:y1:re

Response with closest nodes = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "nodes": "def456..."}}
bencoded = d1:rd2:id20:abcdefghij01234567895:nodes9:def456...5:token8:aoeusnthe1:t2:aa1:y1:re

announce_peer:
Der “q” Key enthält logischerweise den String “announce_peer”. Dazu kommen noch 4 Argumente in “a”, die da wären:

• id: Node ID
• info_hash: Infohash des Torrents
• port: BitTorrent Client Port (zb 6881)
• token: der token der beim vorherigem query nach peers vomentsprechendem Node gesendet wurde (dem Node welches usn die Peers geschickt hat)

Beispiel aus BEP005:

announce_peers Query = {"t":"aa", "y":"q", "q":"announce_peer", "a": {"id":"abcdefghij0123456789", "info_hash":"mnopqrstuvwxyz123456", "port": 6881, "token": "aoeusnth"}}
bencoded = d1:ad2:id20:abcdefghij01234567899:info_hash20:mnopqrstuvwxyz1234564:porti6881e5:token8:aoeusnthe1:q13:announce_peer1:t2:aa1:y1:qe

Response = {"t":"aa", "y":"r", "r": {"id":"mnopqrstuvwxyz123456"}}
bencoded = d1:rd2:id20:mnopqrstuvwxyz123456e1:t2:aa1:y1:re

Ich hoffe das war ein Verständlicher “kleiner” Überblick uber DHT im BitTorrent-Protokoll. Und im naechstem teil gehts dann ueber den Message-Flow im BitTorrent-Protokoll xxD Bevor wir dann auch zu anfassbarem Code kommen, bzw einem Release

Links:

• BitTorrent Enhancement Proposal 005 / BEP005
• Wikipedia/DE zu Kademlia
• Wikipedia/DE zu DHT

Trotzallem noch tolle Ersatz-Indexer

• torrentbox Hier finde ich vor allem das Global-Search Feature ganz nettm da dort auch Torrentbox-Verified Torrents angezeigt werden
• 1337x Noch etwas kleines aber sympathisches Projekt
• h33t Die Oberfläche ist gewöhnungsbedürftig, ansonsten auch sehr nice xD

Tagged: bittorrent, Development, dht, distributed hash table, hash tale, network, Networking, p2p, Torrent

Bisher habe ich das Öffentlich Rechtliche Projekt ZDF Mediathek nahezu täglich benutzt. ZDF Mediathek benutzte bis vor wenigen Tagen Windows Media Streams, welche sich wunderbar mit mplayerplug-in oder mit der URL des streams auch super mit mplayer etc anschauen ließen, doch damit ist nun Schluss – die ZDF Mediathek benutzt nun Flash Streaming. Ich kann diesen Schritt nicht nachvollziehen, Flash Videos unter Linux
machen einfach keinen Spaß. Vollbild oder das schauen während dem surfen sind somit Vergangenheit. Mit einem einfachem “mplayer -dumpstream -playlist URL” ließen sich hervorragend Aufnahmen machen, der Digitale Videorecorder quasi.

Ich befürchte das genau dies die verantwortlichen des ZDF dazu bewegt hat auf Flash Basiertes Streaming umzustellen. Ich erwarte von den Öffentlich Rechtlichen allerdings das, wenn Sie schon keine offenen Standards nutzen, die zumindest zumutbar nutzbar unter allen System laufen sollten. Im ZDF Forum wird auch heftig diskutiert – ich stehe nicht alleine mit der Meinung das Flash Streams schlichtweg SCHEISSE sind.

Die Möglichkeit Videos mit externen Playern zu schauen war für mich einer der Gründe mich überhaupt näher mit dem ZDF Programm auseinanderzusetzen. Neben “heute” und dem “Auslandsjournal” habe ich mir gelegentlich einige andere Sendungen/Dokumentationen angesehen – damit ist nun Schluss. Ich werde die ZDF Mediathek ab sofort boykottieren.
ZDF schließt so nicht nur Besitzer leistungsschwacher Rechner aus, sondern evtl auch welche die über ihre Set-top Boxen die ZDF Mediathek benutzten – und das obwohl sie damit die Kompatibilität angeblich steigern wollen.

Ich habe noch nie einen Fernseher besessen und dies ist für mich ein weiterer Schritt weg von diesem Medium. Die TV Sender scheinen es einfach nicht verstanden zu haben. Wahrscheinlich wird Sie in nicht allzu ferner Zeit das selbe Schicksal treffen wie die Musik-Industrie – die Netz-Generation wird sich ihren Medienkonsum selbst gestalten, mit oder ohne Segen der TV Sender. Die MI hat es wenigstens eingesehen und bietet in ihren Onlineshops
DRM-Freie MP3-Files an. Das Fernsehen von Morgen ist Interaktiv und besteht nur noch zu
geringen Teilen aus redaktionellen Inhalten und Programmplänen – die Mediathek war ein Schritt in die richtige Richtung, doch nun hat das ZDF wieder einen Schritt zurück gemacht.

@ZDF: Shame on you!

Das war wirklich die falsche Entscheidung!
Ein User weniger…

Nachtrag aus dem ZDF Forum:

“Wir wollen ein Format verwenden, das auf allen Browsern und Betriebssystemen abspielbar ist – deshalb Flash. übrigens sind die WMV/H.264-Streams noch abrufbar. Dafür hat jeder Videobeitrag einen eigenen RSS-Feed, in dem die Links auf die Videos enthalten sind.”

- Redaktion ZDFonline (link)
Das überarbeitete ZDF Online Angebot hat scheinbar nicht viele Freunde wie man den ZDF Foren entnehmen kann.

Es bleibt abzuwarten wie das ZDF bzw der Intendant etc reagieren…

Falls es mich dennoch nach Dokumentationen lüstet werde ich wie bisher
auch das ARTE-Angebot ARTE Plus7 benutzen.

Update:
apoc hat nen tolles Script zum Downloaden/Abspielen der WMV-Streams geschrieben. Diese sind ja NOCH im RSS-Feed zu beziehen. Danke an apoc (ich war zu faul mir da was zu scripten )

2 .Update:
Das ZDF reagiert scheinbar auf die Kritik:

…
haben Sie bitte noch etwas Geduld mit der Mediathek. In der nächsten Version läuft diese auch wieder ohne Flash. Daran, dass die Videos nicht bei allen in der gewohnten Qualität laufen, arbeiten wir gerade.
…

- Redaktion ZDFonline (link)

3. Update:
ZDF kündigt folgendes an:

Wir nehmen auch die Kritik an der Ladezeit der Seiten und an die Berichte über die Probleme mit dem Abspielen der Videos sehr ernst. Denn natürlich wollen wir schnell und einfach erreichbar sein. Ruckelnde Videos und “Stream not found”- Meldungen sind natürlich ärgerlich. Die Ursachen können aber sehr vielfältig sein. Wir arbeiten auf Hochtouren daran. Bei den technischen Fehlern merken Sie hoffentlich schon sehr bald eine Besserung. Bei den Entwicklungsprojekten dauert es in der Tat länger – wie einige User hier im Forum schon treffend angemerkt haben. Deshalb wird es eine Mediathek ohne Flash leider nicht vor Herbst geben können.

- Redaktion ZDFonline (link)

Warten bis Herbst aber immerhin…

Tagged: fail, mediathek, Meta, zdf

Was macht ein BitTorrent-Tracker? In diesem Teil gehe ich auf die Funktion eines BitTorrent-Trackers ein. Zuerst sollte man sich den Grundsätzlichen Ablauf eines Torrent Downloads anschauen.

1. Download der .torrent-Datei

Der User sucht sich aus seiner Lieblings-Torrent-Quelle (zb TPB, Demonoid, dnbtracker.org ) einen den gewünschten Torrent heraus und lädt ihn auf Seine Festplatte oder öffnet ihn gleich mit seinem BitTorrent-Client.

2. Der Client parst die .torrent-Datei

Für die Kommunikation mit dem Tracker sind nur ein Paar Informationen aus der Metafile interessant (Metafile Infos im ersten Teil)

• der info hash
• die announce urls

3. Der Client kontaktiert den Tracker und sendet ihm den SHA Hash

Die Tracker-Kommunikation läuft über HTTP.
Der Client Schickt einen GET-Request an den Tracker.
Dieser Request besteht aus:

• announce url
• info hash – der SHA1 Hash des Info Dictionaries
• peer id
• port
• uploaded
• downloaded
• left
• compact
• event

Optional aber auch interessant ist:

• key (damit der Tracker einen Client auch nach einem reconnect mit neuer IP wiedererkennt)

Ein Request an einen Tracker könnte dann wie folgt aussehen ( der Tracker laeuft auf example.com):

• http://example.com/announceUrl+”?info_hash=”+urlencode(info)+”&peer_id=-ST-0001%29%7B%D6%40%F4%21%7B%5C%DA%05%DE&port=6881&uploaded=0&downloaded=0&left=0&compact=1&event=started”

Der Tracker erfährt damit von uns folgende Informationen:

• den Hash von der Info-Map (info_hash)
• nsere Peer-ID (peer_id) [zur ID bald mehr]
• den Port auf dem unser Client lauscht (port)
• wir haben noch 0 Pieces hochgeladen (uploaded=0)
• wir haben 0 Pieces heruntergeladen (downloaded=0)
• wir möchten eine Peer-Liste im Kompakten Format (compact=1), das ist auch üblich so. Das alte Format wird praktisch kaum noch genutzt.
• mit dem Event (event=started) teilen wir dem Tracker mit das wir gerade erst mit dem Download beginnen.

4. Tracker Antwort
Der Tracker antwortet mit einer Liste von Peers. Aus dieser Liste kann der Client entnehmen welche Peers die File besitzen. Ob Sie die ganze File besitzen oder nur Fragmente (aus dieser Information wird die obligatorische anzeige der Seeder [complete] bzw Peers [incomplete] realisiert).
Zu den Einzelnen Peers sind die Informationen die dieses bei ihrem Request an den Tracker übertragen haben enthalten, also:

• peer_id
• port
• ip

Zusätzlich teilt einem der Tracker den Intervall mit in dem man diese Informationen auffrischen sollte, bzw einen erneuten Request an den Tracker schicken sollte. Clients sollten sich daran halten um ein hämmern bzw Sinnlosen Overhead zu unterbinden.

Das war es für diesen Teil im großen und ganzen. Ein kleiner überblick auf die Tracker Kommunikation.
Ganz Informativ zu diesem Thema ist auch der Vortrag “Tracker fahrn” (@24C3 – download via http://chaosradio.ccc.de/24c3_m4v_2355.html) von Erdgeist, Denis und Cristian Yxen.

Im nächsten Teil wird es um die Kommunikation unter den Peers gehen.

Tagged: bittorrent, Development, p2p

Mal wieder was technisches. Ich geh mal ein bisschen ins Detail des BitTorrent Protokolls.
Ich werde das ganze in mehrere Teile aufteilen.

In den ersten Teilen wird es sehr Theoretisch.
In Teil 1 möchte ich auf das BEncoding eingehen und auf Metafile die euch sicherlich als “.torrent”-Datei bekannt ist.

Im nächstem Teil gehe ich dann auf grundsätzliches zur Aufgabe eines Trackers ein. Und danach wird es richtig interessant
Aber erstmal zum BEncoding und der Metafile, ohne die BitTorrent nicht funktioniert -
das BEncoding und die Metafile sind Essentiell!

Bevor ich auf das BEncoding eingehe spreche ich erstmal die MetaFile an, da dies die erste
Stelle (und auch wichtigste) ist an der das BEncoding im Protokoll vorgesehen ist.

Metafile

Die Metafile oder wie es die meisten von euch kennen die “.torrent”-Datei.
In ihr sind alle Informationen (und auch ein paar unwichtige ) die ein Client/Peer benötigt
gespeichert.
Also gehen wir mal näher auf den Inhalt der “.torrent”-Datei ein (optionale Teile sind mit *
gekennzeichnet):

• announce: Die Announce-URL des Trackers
• creation date*: Erstellungsdatum
• comment*: Platz für einen Kommentar zum Torrent oder andere Informationen
• created by*: der Name des Erstellers
• info: das info-Dictionary – der “kern” einer Metafile!(darauf gehe ich weiter unten ein)

Jetzt werden sich sicher einige denken “whuuut?! wtf? dictionary?!”
Ein Dictionary ist die Abbildunge einer Map, oder eines Arrays mit Schlüssel als Index
(ArrayList in Java) auf einen String (bzw. eine ByteFolge xD).

Das Info-Dictionary

Diese Keys enthält ein “info” Dictionary:

• piece length: Die Anzahl der Bytes pro Piece (BitTorrent-Peers tauschen die Daten in Pieces)
• pieces: Enthält die Hashes der Pieces
• info**: Das info-Dictionary für die Spezifizierung der im Torrent enthaltenen Datei/en. (wenn dieses info-Dictionary gemeint ist werde ich es mit ** markieren)

Es gibt 2 verschiedene Modi des Info-Dictionary** den Single-File und den Multifile-Mode,
dementsprechend gibt es auch
2 verschiedene Arten die Datei bzw. die Dateien näher zu Spezifizieren:

“info” im Single-File Mode

• name: Der Dateiname
• length: Länge der Datei in Bytes

“info” im Multi-File Mode

• name: Der Ordnername in dem sich die Dateien befinden
• files: Ein Dictionary das für jede Datei ein weiteres Dictionary enthält

Die Keys des “files”-Dictionaries:

• length: Die grösse der Datei in Bytes
• path: Der Pfad der Datei

Damit waren die wichtigsten Elemente des .torrent-Files erklärt und wir können uns mit de
Kodierung der entsprechenden Elemente/Einträge befassen – dem BEncoding.

BEncoding

Das BEncoding ist so genial wie einfach.

BitTorrent nutzt BEncoding für:

• Strings
• Integer
• Dictionaries
• Listen

Diese Typen werden alle nach dem selben Schema kodiert:

Strings:

:
Beispiel:
5:w00t!  (für den String "w00t!")

Integer:

ie

Beispiel:
i7e (Integer: "7")
i-1e (Integer: "-1")

Dictionaries:

de

Beispiel:
d3:nks6:gentoo4:apoc4:arche***

*** Steht für folgendes dictionary:
KEY          VALUE
[nks] = gentoo
[apoc] = arch

Listen:

le

Beispiel:
l3:nks7:torrente (entspricht den Strings "nks" und "torrent")

Ist recht simpel oder?
Trotzdem muss man bei der Implementierung aufpassen, wenn hier ein Fehler passiert kann es sein
das man manchmal hinterher lange nach dem Fehler suchen muss
Das BEncoding verfolgt einen durch das ganze Protokoll hinweg.

Tagged: bittorrent, Development, java, Networking, p2p, Torrent

Eine weitere nette Spielerei für Leute mit zu viel Ressourcen

Ich hab sie nicht aber das ganze läuft auch auf einem 700Mhz Duron flüssig.

Ihr benötigt “xscreensaver” (und auch das Paket “fireflies” falls ihr es wie auf den Screenshots haben wollt, wobei sich “pong” auch ganz gut macht) und “xwinwrap” (xwinwrap does teh magic)

nks@hydra ~ $ nice -n 15 /usr/bin/xwinwrap -ni -argb -fs -s -st -sp -b -nf -- /usr/lib/misc/xscreensaver/fireflies -window-id WID

Das ganze sieht dann so aus:

Für mehr Infos:

• http://swik.net/xwinwrap

Man kann neben xscreensaver auch Videos als Hintergrund laufen lassen

nks

Tagged: compiz, eye-candy, Linux, mplayer, opengl, xscreensaver, xwinwrap

Mir ist gestern die Fernbedienung meiner Sourround-Anlage auf den Boden gefallen – jetzt ist sie unbrauchbar. Also dachte ich mir: “Hey, mach doch den eee-pc zu deiner neuen Fernbedienung!”.

Also wenn ich im bett liege und die lautstärke regeln will, schnell per ssh auf den Rechner verbinden und alsamixer nutzen. Aber dafür is der eee ja schon bisl overkill. Dann erinnerte ich mich an meine Experimente vor einem Jahr die beiden desktop-pcs miteinander zu verbinden.

Ich hatte es auch mit synergy versucht, aber es war ziemlich buggy. Aber die neue Version läuft wesentlich stabiler. Also schnell auf allen 3 boxen synergy gemerged und ab an die config:

# nks's synergy configuration file
# eeerr0r is the synergy-server
# infected and hydra are the clients

section: screens
infected:
hydra:
eeerr0r:
end

section: links
# larry is to the right of moe and curly is above moe
infected:
right = eeerr0r
eeerr0r:
left = infected
right = hydra
hydra:
left = eeerr0r
end
section: aliases
infected:
192.168.178.30
hydra:
192.168.178.32
eeerr0r:
192.168.178.25
end

Das ganze dann auf dem System welches Tastatur und Maus bereitstellen soll unter “/etc/synergy.conf”
und dann ab in die shell:

nks@eeerr0r ~ $ synergys -f --config /etc/synergy.conf

nks@infected ~ $ synergyc -f eeerr0r

nks@hydra ~ $ synergyc -f eeerr0r

Und schon kann ich vom eee-pc aus beide Rechner kvm-style fernsteuern
das ganze funktioniert auch unter windows und mac os.

Besonders schön is das ganze in Kombination mit compiz weil man dann vom Bett/anywhere aus ranzoomen kann

Informationen & links:

• http://synergy2.sourceforge.net/
• http://de.wikipedia.org/wiki/Synergy

ps: chase & status releasen demnächst ihr neues Album, zwar ziemlich die uk-kommerz schiene, aber “hurt you” und “pieces” laufen atm ja fast in jedem set, also man kann gespannt sein (wobei “hurt you” auch auf dem neuem Album ist)

pps:Ich hatte damals auch mit xdmx ruexperimentiert, hehe.. vll. probier ich demnächst auch wieder etwas damit rum, allerdings mit compiz etwas zu lahm, in Kombination mit chromium funktioniert es vll besser.

nks

Tagged: eee, fernbedienung, geek, kvm, Linux, remote, synergy