sixserv blog

JavaScript: onMouseMove Google Translation

apoc — Wed, 10 Feb 2010 15:37:13 +0000

I wanted to implement a JavaScript onMouseMove Event, that translates the word under the mouse pointer with the Google Translator. I want to share the following solution.

I split this into the following two separate problems:

First: Detect word for an onMouseMove Event

The onMouseMove Event can listen on any Element for mouse movements. To detect the word under the mouse pointers position, I utilize the W3C(DOM-2) specified Range Object.

Most modern browsers support the Range object, but the event.rangeParent Attribute seems to be only supported by Firefox. Currently I’ve no cross-browser solution for this.

/**
 * Apply offset to range and extract a single character at position.
 *
 * range -- the range object effected
 * originalOffsetStart, originalOffsetEnd -- Start offsetStart and offsetEnd
 * offset -- the relative offset to apply
 */
function getRangeCharacter(range, originalOffsetStart, originalOffsetEnd, offset) {
    var character = ' ';
    try {
        range.setStart(range.startContainer, originalOffsetStart + offset);
        range.setEnd(range.startContainer, originalOffsetEnd + offset);
        character = range.toString()[0];
        range.setStart(range.startContainer, originalOffsetStart - offset);
        range.setEnd(range.startContainer, originalOffsetEnd - offset);
    } catch (e) {}    
 
    return character;
}
 
/**
 * Returns a single word for the given event.
 */
function getEventWord(evt) {
    if (!evt.rangeParent || !document.createRange) {
        return '';
    }
 
    var range = document.createRange();
 
    range.setStart(evt.rangeParent, evt.rangeOffset);
    range.setEnd(evt.rangeParent, evt.rangeOffset);
 
    // the word ends when this characters appears
    var stop_character_pattern = /^[\W]$/m;
 
    // this "overwrites" some characters from the above pattern
    var ignore_stop_character_pattern = /^['|\-]$/;
 
    // I assume startOffset == endOffset so set 1 character selection ...
    var originalOffsetStart = range.startOffset;
    var originalOffsetEnd = range.startOffset + 1;
    try {
        // test:
        range.setStart(range.startContainer, originalOffsetStart);
        range.setEnd(range.startContainer, originalOffsetEnd);
    } catch (e) {
        // out of bounds
        originalOffsetStart -= 1;
        originalOffsetEnd -= 1;
        range.setStart(range.startContainer, originalOffsetStart);
        range.setEnd(range.startContainer, originalOffsetEnd);
    }
 
    // First Step: Find left end of word:
    var leftCharacterPos = 0;
    var iChar = '';
    for (var iOffStart = 0; iOffStart <= originalOffsetStart; iOffStart++) {
        iChar = getRangeCharacter(range, originalOffsetStart, originalOffsetEnd, -1 * iOffStart);
 
        leftCharacterPos = iOffStart;
 
        if (stop_character_pattern.test(iChar) && !ignore_stop_character_pattern.test(iChar)) {
            // remove the stop character!
            leftCharacterPos -= 1;
            break;
        }
    } leftCharacterPos = originalOffsetStart - leftCharacterPos;
 
    // Last Step: Find right end of word:
    var rightCharacterPos = 0;
    for (iOffStart = 0; true; iOffStart++) {
        iChar = getRangeCharacter(range, originalOffsetStart, originalOffsetEnd, iOffStart);
 
        if (stop_character_pattern.test(iChar) && !ignore_stop_character_pattern.test(iChar)) {
            rightCharacterPos = iOffStart - 1;
            break;
        }
    } rightCharacterPos = originalOffsetEnd + rightCharacterPos;
 
    try {
        range.setStart(range.startContainer, leftCharacterPos);
        range.setEnd(range.startContainer, rightCharacterPos);
    } catch (e1) {
        range.detach();
        return '';
    }
 
    var retWord = range.toString();
 
    range.detach();
 
    return retWord;
}

Second: Translate Text with Google Translator

This is very easy because Google provides an very easy to use Ajax API for this (attend the possible google user tracking!):

// read onMoveTranslate()
var last_word = null;
var timeout = null;
var word_cache = [];
 
/**
 * Translate text For onmousemove events.
 */
function onMoveTranslate(event) {
    // get element the translation should appear in:
    var translation = document.getElementById('translation');
 
    var word = getEventWord(event);
    if (!word || word == '') {
        return;
    }
 
    if (typeof(word_cache[word]) !== 'undefined') {
        translation.innerHTML = word_cache[word]; //+" (cached)";
        return;
    }
 
    if (word != last_word) {
        if (timeout) {
            window.clearTimeout(timeout);
        }
 
        translation.innerHTML = 'Translating ... ' + word;
        timeout = window.setTimeout(function(){
            google.language.translate(word, 'en', 'de', function(result) {
                if (!result.error) {
                    translation.innerHTML = result.translation;
                    word_cache[word] = result.translation;
                }
            });
        }, 800);
    }
    last_word = word;
}
 
google.load("language", "1");

At last I assign the onMouseMove Event to the onMoveTranslate() function:

Here is an full Example for this.

mtget: ZDF Mediathek Download/Stream

apoc — Mon, 21 Dec 2009 08:54:41 +0000

Nachdem die ZDF Mediathek nun ihr lang erwartetes relaunch ‘feiern’ kann, habe ich mich daran gemacht mtget zu überarbeiten. Die neue, für Linux Anwender besonders interessante, “HTML Version”, macht, da ohne Flash, die ZDF Mediathek nun erstmals halbwegs benutzbar. =)

Die asx-Links fürs mms streaming werden jetzt auch nicht mehr versteckt, so im großen und ganzen also ein ziemlicher Fortschritt. Für die Nerds unter euch die dennoch gern eine Shell-Lösung hätten, pflege ich mtget trotzdem weiter.
Bei der Gelegenheit habe ich mtget in Python komplett neu geschrieben. Version 0.5 kommt ohne zusätzliche Libraries aus, es müssen lediglich Python(bei mir läuft 2.6) sowie die in CMD_STREAM und CMD_DOWNLOAD eingetragenen Programme(per default: mplayer) installiert sein. In der neuen Version werden erstmals Kanäle erkannt und können im interaktiven Modus(-i) ausgewählt werden, andernfalls wird ihnen automatisch gefolgt und die Einträge abgespielt. Anders als die vorigen Versionen lädt 0.5 nur die mms-Streams. mtget.py:

mtget.py: Interaktive Auswahl der Videos und Kanäle

ZDF Mediathek Download/Streaming Skript
v0.5  http://apoc.sixserv.org/
Stand: 2009-12-20

Syntax: ./mtget.py  [OPTIONS]
                     mediathek video/kanal url oder id
  -1                         qualitaet DSL 1000
  -2                         qualitaet DSL 2000 (Standard)
  -m, --mode            download(d) oder streaming(s)
  -d, --dir       das verzeichnis wohin gespeichert werden soll(.)
  -t, --title                benutzt nicht den stream dateinamen sondern titel
  -s, --search        suche in der mediathek
  -l, --maxr            wieviele ergebnisse verarbeiten(suche/kategorie)
  -c, --ignore-channel       ignoriert kanaele
      --no-colors            deaktiviert die kursiv und fettschrift
  -i                         interaktiv, auswahl der zu spielenden videos
  -v                         erweiterte ausgabe, zu debugging zwecken
  -h, --help                 zeigt diese hilfe

Mir sind übrigens noch zwei weitere Projekte bekannt die ebenfalls Mediathek streaming bieten: mtscrape und zdfmediathk.

Für Vorschläge, Bugreports und alles andere hinterlasst mir ein Kommentar oder schreibt eine eMail an apoc@sixserv.org!

Content Extraction Algorithmen: Density/CCB

apoc — Mon, 09 Nov 2009 19:31:09 +0000

Im Artikel, “Web scraping mit Ruby/Mechanize” zeigte ich wie man Webseiten von einem Ruby Skript laden lässt und definierte Inhalte daraus extrahieren kann. Diese Verfahren, z.B.: Regular expression, XPath oder CSS Selektoren, funktionieren nur für Seiten deren Struktur während der Implementierung bekannt sind. Diesmal allerdings geht es um Algorithmen die den Hauptinhalt(z.B. den Text einer Nachricht) von jeder beliebigen Seite erkennen und extrahieren können. Diese Möglichkeit ist vor allem für Suchmaschinen/Datamining oder für Anwendungen die die Lesbarkeit erhöhen wollen, z.B. für kleine Bildschirme(Handhelds) oder Screen Reader, interessant.

Auch wenn es ein recht neues Forschungsfeld der Informatik ist, gibt es schon einige Veröffentlichungen zu dem Thema. Für den Einstieg am Interessantesten ist wohl die Dissertation von Thomas Gottron, “Content Extraction: Identifiying the Main Content in HTML Documents“, die einen Überblick über die Algorithmen gibt, eine Möglichkeit der Evaluation beschreibt und einige neue Algorithmen einführt. Das erfolgversprechendste dieser Verfahren, der CCB(Content Code Blurring) Algorithmus ist auch Thema dieses Artikels.

Einen weiteren interessanten Ansatz liefern Arias Moreno, Deschacht und Moens in Ihrem Paper “Language Independent Content Extraction from Web Pages” deren Verfahren(Density) hier auch besprochen wird.

Natürlich kann man von keinem der Algorithmen Perfektion erwarten, dafür sind die Webseiten zu unterschiedlich strukturiert. Auch will ich nicht vergessen zu erwähnen das diese Algorithmen nur auf Seiten mit klar erkennbarem Hauptinhalt(Main Content) funktionieren, Weblogs z.B. verwirren so gut wie alle Verfahren die darauf Basieren die höchste “Text Konzentration” auf einer Seite zu finden, da die Kommentare unter dem Artikel nicht selten wesentlich umfangreicher als der Hauptinhalt sind(z.B. Slashdot).

Content Code Blurring (Python Skript / Modul)

Der CCB Algorithmus von Thomas Gottron stellt ein Verfahren dar, um die Teile einer HTML-Seite zu identifizieren die aus viel Text und nur wenigen Tags besteht. Dazu wird die Seite in eine Sequenz aus Tokens oder Zeichen aufgeteilt: Die TCCB Variante teilt die Sequenz in Tokens aus Tags oder Wörtern ein, sonst werden Zeichen unterschieden die sich innerhalb(Code) oder außerhalb(Inhalt/Content) eines Tags befinden. Der so entstandene Content Code Vektor(CCV) speichert für jeden Code ein 0 und für jeden Inhalt eine 1.

Jetzt wird der CCV verwischt(Blurring) dazu wird ein Gaussian Blur Filter verwendet, der im Prinzip einer Gaussian Distribution/Normal Distribution entspricht. Anders gesagt werden die Inhalts(1)-Elemente des CCV auf ihre Nachbar-Elemente verstreut oder verwischt. Dieser Vorgang wird n-mal wiederholt oder bis sich der Prozess normalisiert hat(wobei ich es leider nicht geschafft habe das zu implementieren(kA. woran das liegt, GERNE FEEDBACK!)). Meine Beispielimplementierung kann ein Diagramm des CCV “plotten”:

Dieser Plot zeigt, dass man schon auf der richtigen Spur ist. Klar erkennbare Spitze wo der Hauptinhalt liegt.

Am Ende werden die Teile des CCV welche über einen bestimmten Schwellwert liegen mit ziemlicher Sicherheit zum Hauptinhalt der Seite gehören. (Im Diagramm sehr leicht zu erkennen.)

Der CCB Algorithmus funktioniert sehr gut und gilt als einer der besten Algorithmen für Content Extraction überhaupt. Ein Nachteil besteht darin das Teile der Seite die ebenfalls viel Text enthalten mitunter zum Hauptinhalt gezählt werden, auch wenn sich diese Bereiche weit entfernt vom eigentlichen Inhalt befinden.

Density (Ruby Beispiel)

Der Density Algorithmus von Arias Moreno, Deschacht und Moens folgt einem ähnlichen Ansatz, die HTML-Seite wird durch einen (möglichst robusten) XML-Parser geparsed. Dann wird jeder (XML-)Node des Dokuments der Text enthält an den letzten String eines Arrays angehängt. Handelt es sich bei dem Node um einen HTML-Tag der die Struktur des Dokuments verändert(z.B. p, table, br, div, h1-6, li usw.) wird das Array um einen leeren String erweitert.

Wurde dieses Array fertig erstellt, wird ein Algorithmus angewandt, der den Bereich mit der größten Textdichte im Array zu bestimmen versucht(siehe Paper). Am Ende wird das Array nur noch sortiert und das Ergebnis steht als Plaintext fest.

Density arbeitet in der Praxis sehr gut, jedoch wird das Ergebnis sehr stark von den beiden Parametern beeinflusst, die den Algorithmus zum erkennen des Bereichs einstellen(besonders wieviele Absätze am Stück erkannt werden).

Update: Ich habe eine Implementierung für Density in Ruby eingefügt, er versucht den Hauptinhalt dieses Artikels zu extrahieren

Zensursula: Teil 2 – Cleanfeed, DNS, DPI

apoc — Mon, 05 Oct 2009 15:32:52 +0000

Die mit Lügen und Erpressung der Provider gegen alle Vernunft durchgepeitschte, grundgesetzwidrige unkontrollierbare deutsche Zensurinfrastruktur wird gerade vom “zuständigen” BKA in aller Heimlichkeit geplant und wird genauso heimlich von den Providern implementiert werden. Das die erstmals angedachten DNS-Sperren vollständig wirkungslos sind, darüber sind sich wohl alle einig, genauso eindeutig ist es wohl das die DNS-Sperren nur den Einstieg hin zur Schaffung eines ausgefeilten Zensursystems mit Vorbild der Great Firewall of China sein wird. Schon jetzt vermuten einige das ein Cleanfeed Modell nach britischen Vorbild geplant ist.
Die Befristung auf 3 Jahre hilft natürlich auch nicht, entweder nach 3 Jahren stellt sich heraus, das es nur wenig gegen “Kinderpornographie” geholfen hat, dann muss noch mehr und tief greifender gesperrt werden, oder die Verbrechensstatistik (die im übrigen ohnehin vom BKA “erstellt” wird) geht zurück, dann war es ein Erfolg und muss genauso weitergeführt werden.

Cleanfeed - Bildquelle: Wikimedia Commons

Das Cleanfeed System wird von Providern in England eingesetzt um z.B.: bestimmte Wikipedia Artikel zu blockieren. Welche wahrscheinlich regimekritischen Seiten noch so alles gesperrt werden weiß man natürlich nicht, da die geheimen Listen(der IWF), natürlich nicht unabhängig kontrolliert werden. Cleanfeed filtert nach der IP und URL, was durch eine Kombination aus konventionellen IP-Filtern und Proxy-Servern ermöglicht wird. Zunächst wird der Traffic nur nach IP-Adressen gefiltert, bestimmte Verbindungen werden schon hier blockiert, andernfalls wird der fragwürdige Traffic durch ein Arsenal an transparenten Proxy-Servern geleitet(Man-in-the-middle-Angriff auf HTTP) die mit einer Blacklist ausgerüstet bestimmte URLs blockieren.

In China z.B. wird noch einen Schritt weiter gegangen, so wird jedes IP-Paket von DPI-Hardware genau untersucht, enthält es unerwünschte Suchbegriffe oder Inhalte wird von dem zensierenden Backbone TCP-RST-Pakete gesendet, die so die fragliche TCP-Verbindung sofort beendet. So implementiert die chinesische Suchmaschine Baidu dies bereits auf Server-Seite. Wer auf Baidu.com nach “Falun Gong” sucht, dessen Verbindung wird für einige Minuten gesperrt.
Beim Deep Packet Inspection wird jedes vorbeikommende Paket auseinandergenommen, so kann beispielsweise festgestellt werden ob es sich um eine HTTP Verbindung handelt und welche URL angefordert wird oder welche Daten gesendet werden. Das allein ist natürlich ein krasser verstoß gegen die Netzneutralität sowie gegen jedes noch so aufgeweichtes Fernmeldegeheimnis. Zum Vergleich, das wäre wie wenn die Post jeden Brief unbemerkt öffnet und nach bestimmten Stichworten durchsucht. Wenn es schon unbedingt DPI seien muss, dann wenigstens Open Source, dachten sich wahrscheinlich die Entwickler des OpenDPI Projektes

Im letzten Zensursula-Artikel habe ich mich mit den DNS-Filtern beschäftigt, insbesondere wie man einen eigenen DNS-Cache-Server betreibt der die Zensur über DNS verhindert. Wie erwähnt handelt es sich dabei nur um den Einstieg, die Einführung von Cleanfeed/DPI kann die Zensur wieder akut werden lassen, selbst mit eigenem DNS-Server. Wie es technisch geht hat jüngst Vodafone in ihrem UMTS Netz gezeigt, sie fangen jede Anfrage über Port 53 ab und leiten sie an ihre eigenen DNS-Server weiter.

Das Einzige wirksame Mittel gegen diese fortgeschrittenen Zensur Bemühungen, ist es den eigenen Traffic möglichst zu verschleiern, im einfacheren Fall seinen Traffic verschlüsselt über Rechner im Ausland zu leiten, bspw. über HTTP oder Socks4/5-Proxy-Server. Die Meisten Zensur-Regime sperren deshalb ebenfalls bekannte Ausländische Proxy bzw. Anonymisierungs-Dienste(Socks, VPN-Dienstleister oder Tor-Nodes) auf IP-Ebene.
Mittlerweile gibt es eine ganze Flut von VPN-Providern die bezahlte Zugänge zu Ausländischen VPN-Servern bereitstellen, Ivacy war hier auch schon Thema. Explizit erwähnen will ich hier außerdem Perfect-Privacy die zwar etwas teurer sind, aber dafür sehr schnell und Zugriff zu über 20 weltweit verteilten Servern bieten.

Auf FileShareFreak und Daten-Speicherung.de gibt es Listen von VPN-Providern. Wem es statt einer Zensur zu umgehen, um wirkliche Anonymität geht, reichen diese Anbieter nicht aus. Nur ein Onion Routing kann wirkliche Anonymität gewährleisten, z.B.: Tor oder JAP/JonDo. Diese haben natürlich den Nachteil, extrem Langsam und unzuverlässig zu sein. Daneben gibt es mit Xerobank einen Bezahl-Anbieter für schnelles Onion Routing.

Update: Auf ZDNet gibt es einen guten Artikel darüber, wie weit die DPI-Manipulationen bei den UMTS-Anbietern, wie Vodafone mittlerweile gehen. (via Netzpolitik)

implementing bittorrent – DHT (teil 3)

nks — Fri, 02 Oct 2009 16:35:16 +0000

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:

Code	Beschreibung
201	Generic Error
202	Server Error
203	Protocol Error, such as a malformed packet, invalid arguments, or bad token
204	Method Unknown

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:

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

Neues Theme

apoc — Thu, 01 Oct 2009 16:48:59 +0000

Endlich hat Sixserv ein eigenes Wordpress-Theme. Ich arbeite da schon seit einigen Wochen dran, es basiert in der Grundstruktur auf dem Standard Wordpress Theme(GPLv2), der Kommentarbereich ist aus Monochrome(GPLv3) mit einigen kleinen Änderungen übernommen. Die Kategorie-Icons entstammen hauptsächlich verschiedener Icon-Sets: Discovery(CC), Crystal Project(LGPL) und Crystal Clear(LGPL).

Fehler, Kritik, Verbesserungsvorschläge, usw. bitte in die Kommentare.

Zensursula: Teil 1 – DNS

apoc — Sat, 27 Jun 2009 20:40:41 +0000

“Sie werden sich noch wünschen wir wären Politikverdrossen” (@343max)

Ich hatte in den letzten Wochen den Eindruck, als ob die gesamte Internet-Gemeinschaft in Deutschland Sturm lief, überall gab und gibt es nur ein Thema: Die Internetzensur Bestrebungen der großen Koalition. Dabei hatte man am Ende den Eindruck gegen eine Mauer von Unkenntnis, Ignoranz aber vielleicht auch einfach blanker böswilliger Berechnung einfach nichts ausrichten zu können.
Besonders Enttäuschend empfand ich die Medien, überraschend war es freilich nicht dass sie praktisch ausschließlich Parteipropaganda nachplapperten und die Mainstream Meinung nach dem Willen der Regierung formten. Von investigativem Journalismus jedenfalls war in den Holzmedien nichts zu sehen, das überlässt man offenbar anderen.

Ein wenig Ironisch ist es schon, ist doch gerade das Internet die einzige breit zugängliche alternative Informationsquelle(wie wir eindrucksvoll sehen konnten), die mit der jetzt beschlossenen Infrastruktur möglicherweise schon bald stark eingeschränkt wird. Dabei geht es auch um die Frage ob wir der Regierung soweit vertrauen, nach der Installation einer bis dato einmaligen Infrastruktur für Zensur, bei der Sperrung von Kinderpornographischen Inhalten zu bleiben. In den letzten Jahren hat uns die große Koalition keinen Grund geliefert das zu glauben.

Die eigentliche Kluft wie häufig Thematisiert, liegt nicht zwischen den Internet-Natives und den “Internet-Ausdruckern” sondern vielmehr in dem Teil der Bevölkerung der sich unabhängig Informiert und dem Teil, der den großen Medien und Agenturen(auch im Internet) blind vertaut und als einzige Informationsquelle zur eigenen Meinungsbildung heranzieht, also den überwiegenden Teil der Gesellschaft.

Gestern nun hat die EU die Zensur in China gerügt(so Merkwürdig wie das auch immer ist), demnach vergessen wir einfach alles was die EU-Länder sonst so treiben und beschäftigen uns nun, offensichtlich im Wohlwollen der EU, um die aktiven technischen Möglichkeiten der Umgehung jedweder Zensur-Infrastruktur, außerdem kann es nicht schaden die von den Zensoren eingesetzte Technologie mal etwas genauer zu beleuchten.

In diesem ersten Teil soll es um die Zensur durch DNS Manipulationen gehen.

Es ist noch die leichteste Form der Zensur, die Einstiegsdroge der Staaten sozusagen, denn DNS Manipulationen lassen sich Kinderleicht aushebeln was wohl schnell den Wunsch nach härteren Mitteln wecken dürfte. Bei dieser Form der Zensur installieren die ISP’s die Sperrlisten in ihren DNS-Servern, ist doch zumindest anzunehmen, das die Mehrheit der Internet Nutzer die Server ihres Providers verwenden, wobei das bei leibe nicht immer der Fall ist. So war und ist es schon immer möglich seinen eigenen DNS-Server zu betreiben. Jetzt wo man allen Grund hat den DNS-Servern der Provider zu misstrauen, ist das eine sehr praktikable Möglichkeit, zumindest für diejenigen die sich mit dem Internet auskennen.
Doch der Reihe nach, im Prinzip reicht es statt eines Domain-Namens in der Adresszeile die Ip-Adresse einzugeben um diese Zensur zu umgehen, besser ist es da schon einen alternativen DNS-Server zu verwenden, vorzugsweise im Ausland, aber auch der CCC und der Foebud stellen unzensierte DNS-Server (noch) frei zur Verfügung. Listen mit freien Servern gibt es z.B. bei Wikileaks, dem CCC oder die Server des Open NIC Projektes.

DNS Caching Server

Nützlich ist auch das Einrichten eines eigenen Caching DNS-Servers der zufällig aus einer Liste, öffentliche Servern abfragt. Ich verwende dafür den pdnsd, nicht zu verwechseln mit dem vollwertigen DNS-Server, PowerDNS. Je nach Distribution sollte sich die Installation einfach gestalten, z.B. reicht ein pacman -S pdnsd um mit Arch Linux den Server zu installieren. Jetzt sollte man sich die Beispiel Konfiguration kopieren und Anpassungen vornehmen. Hier eine mögliche Beispielkonfiguration, es muss nur die server_ip angepasst werden:

global {
        perm_cache=512000; # cache groesse in KB (hier "leicht" uebertriebene 500 MB)
        cache_dir="/var/cache/pdnsd";
        run_as="nobody";
        server_ip=10.0.0.4; # ANPASSEN
        status_ctl=on;
        paranoid=on; # prevents cache poisoning
        query_method=udp_tcp;
        min_ttl=15m; # min/max TTL
        max_ttl=4w;
        timeout=15; # global timeout 15 seconds
        neg_rrs_pol=auth;
        par_queries=2; # maximale parallele abfrage von servern
}
 
server { # ein paar oeffentliche server (alle getestet)
        label = "random";
        randomize_servers = on;
        ip = 85.214.73.63, # foebud
        204.152.184.76, # ISC (USA)
        213.73.91.35, # CCC
        194.95.202.198, # DFN
        58.6.115.43, # Westnet (Australien)
        82.229.244.191, # Frankreich
        88.191.77.10, # Frankreich
	216.87.84.209, # OpenNIC
	88.191.77.10; # OpenNIC
        timeout=10; # 10 sekunden maximal
        uptest=ping;
        ping_timeout=400; #ms
        interval=30m; # uptest der server per ping
}
 
# Unveraendert aus Sample Conf:
# This section is meant for resolving from root servers.
server {
        label = "root-servers";
        root_server = on;
        randomize_servers = on; # Give every root server an equal chance
                                # of being queried.
        ip =    198.41.0.4
        ,       192.228.79.201
        ,       192.33.4.12
        ,       128.8.10.90
        ,       192.203.230.10
        ,       192.5.5.241
        ,       192.112.36.4
        ,       128.63.2.53
        ,       192.36.148.17
        ,       192.58.128.30
        ,       193.0.14.129
        ,       198.32.64.12
        ,       202.12.27.33
        ;
        timeout = 5;
        uptest = query;         # Test availability using empty DNS queries.
        interval = 30m;         # Test every half hour.
        ping_timeout = 300;     # Test should time out after 30 seconds.
        purge_cache = off;
        exclude = .localdomain;
        policy = included;
        preset = off;
}
 
# ganz praktisch, damit braucht man nur eine einzige hosts Datei im ganzen LAN zu pflegen:
source { 
        owner=localhost;
        serve_aliases=yes;
        file="/etc/hosts";
}

Ich habe alle DNS Server getestet. Eventuell die Konfiguration noch auf die eigenen Anforderungen anpassen, eine Dokumentation findet ihr hier. Die /etc/resolv.conf noch auf die lokale IP-Adresse umstellen dann den Server (neu)starten. Jetzt sollte er funktionieren, testen kann man das z.B. mit nslookup oder: dig 4poc.org [IP des DNS], dig zeigt auch wie lange er zum resolven brauchte.

Um festzustellen welche DNS-Server verwendet werden habe ich ein kleines Skript geschrieben, eigentlich passt die Thematik(siehe Anmerkung im Script) nicht direkt zum Thema aber den folgenden Artikeln sei schon mal etwas vorgegriffen: nstest.4poc.org (DNS Tester, falls jemanden einen besseren Namen dafür einfällt nur her damit.)

Kleine Ruby Logger Klasse

apoc — Sat, 13 Jun 2009 04:04:09 +0000

Normalerweise sind die Artikel hier ja ziemlich umfangreich, was ja auch gut ist schließlich geht das Sixserv Blog ja schon sehr ins technische Detail. Doch diesmal wird es eher kurz, ich möchte eine kleine Logger Klasse vorstellen die ich in Ruby geschrieben habe und seither häufiger benutze.

class Logger
  def self.init
    @logfile = LOG_FILE
    @buffer = [] # logging lines for buffering
  end
 
  def self.<< msg
    msg = format msg
 
    # append message to buffer
    @buffer << msg
 
    # flush the buffer if possible
    self.flush
  end
 
  def self.flush
    return if @buffer.empty?
 
    # try to lock the file for writing
    log = File.new(@logfile, 'a+')
 
    if log.flock(File::LOCK_EX | File::LOCK_NB) == false
      # Logfile is locked
      puts "Logfile is locked!"
      log.close
      return false
    end
 
    # ==> not locked, write buffer to logfile
    while @buffer.length > 0
      log.puts @buffer.shift
    end
 
    log.flock(File::LOCK_UN)
    log.close
  end
 
  private
  def self.format msg
    time = Time.now.strftime '%H:%M:%S - %d.%m.%Y'
    "[#{time}] #{msg}"
  end
end

Nichts großes also, es gibt z.B. keine Log-Level usw. Außerdem kann man sich, wenn man etwas mehr Features braucht, auch eine Logging Bibliothek aus dem Gems bedienen. Die Anwendung ist ganz einfach:

require '/pfad/zu/logger.rb'
Logger.init
# das kann man dann überall im Code verteilen:
Logger << "Irgendeine Nachricht!"
# hat man eine große Anwendung mit vielen Prozessen/Threads
# kann man auch an strategischen Stellen ein
Logger.flush
# einbauen :)

Hier noch eine kleine Erweiterung die einen Log-Server implementiert. Er öffnet einen TCP Port, jeder der sich verbindet(z.B. per Telnet/Netcat) kann daraufhin die Log-Nachrichten mitlesen:

class Logger
  def self.init
    ...
    @port = LOG_PORT
    @query = []
    @query_mutex = nil
    @running = false
    @server = nil
  end
 
  def self.start_server
    @query_mutex = Mutex.new
    puts "Start logging console @ #{LOG_HOST}:#{LOG_PORT}"
 
    @server = TCPServer.new(LOG_HOST, LOG_PORT)
    clients = []
    @running = true
    Thread.start do
      client = []
      while @running do
        begin
          client = @server.accept_nonblock
          clients << client if client != nil
        rescue
        end
 
        begin
          message = nil
          @query_mutex.synchronize { message = @query.pop }
          if message != nil
            clients.each do |client|
                begin
                    client.puts message
                rescue
                    clients.delete client
                end 
            end
          end
        end while not @query.empty?
        sleep LOG_SERVER_INTERVAL
      end
      clients.each { |client| client.close }
      @server.close
      @server = nil
    end
  end
 
  def self.destroy
    @running = false
    @fs.close
 
    # wait until server closed
    true while @server != nil
  end
 
  def self.<< msg
    if @query_mutex != nil
      @query_mutex.synchronize do
        @query << format(msg)
      end
    end
    puts ">>> #{msg}"
  end  
 
  def self.flush
    # just wait until everything is sent/written
    if @query.length > 0
      true while @query.length != 0
    end
  end
 
  ...
end

So das wars schon, ich hoffe das ich das mit dem Mutex richtig gemacht habe und das hier überhaupt notwendig war, ich habe auf dem Gebiet nicht viel Erfahrung und würde mich über einen entsprechenden Kommentar freuen.
// I’m not sure I used the Mutex in this example correctly, I would appreciate a comment about this.

Web scraping mit Ruby/Mechanize

apoc — Wed, 27 May 2009 12:44:13 +0000

Praktisch jede Interaktion mit einer Website oder Webapplikation kann gescriptet, d.h. automatisiert werden. Das Abgrasen von Webseiten nach bestimmten Informationen wird auch als Scraping bezeichnet(für die nicht menschlichen Besucher dieser Seite sei das erwähnt *g*) Scripte können einem eine ganze Menge Arbeit abnehmen und sogar Dinge tun, die manuell unmöglich wären. Ich beschäftige mich mit dem Thema schon seit einer ganzen Weile und möchte hier nun die von mir favorisierte Methode dafür vorstellen, die Bibliothek Mechanize für die Scriptsprache Ruby.

Mechanize hat seinen Ursprung in Perl, mittlerweile gibt es jedoch auch Implementierungen der API für Python und eben Ruby. Für PHP gibt es mit Snoopy ein ähnliches Projekt, wenn es auch bei weitem nicht so fortgeschritten ist. Mechanize bietet die Möglichkeit mit einfachen Methoden eine art Webbrowser zu simulieren. Alle Beispiele wurden mit Mechanize Version 0.9.2 und Ruby 1.8.7 getestet.

Installation / Initialisierung

Mechanize kann mit Gems(ähnlich CPAN oder PEAR) installiert werden(# gem install mechanize --remote), einige Distributionen bieten aber auch eigene Pakete an. Ein Ruby-Script kann daraufhin Mechanize inkludieren und ein Objekt erstellen:

require 'rubygems' # ist unter Umständen notwendig
require 'mechanize'
agent = WWW::Mechanize.new

Jetzt ist Mechanize einsatzbereit, die folgenden Beispiele bauen darauf auf. Außerdem können mit dem agent nun noch grundlegende Einstellungen vorgenommen werden:

agent.set_proxy('localhost', '8000')
agent.user_agent = 'Individueller User-Agent'
agent.user_agent_alias = 'Linux Mozilla'

Die Einstellung ‘user_agent_alias‘ wählt einen User-Agent String aus dem folgenden Satz von Beispielen aus: Windows IE 6, Windows IE 7, Windows Mozilla, Mac Safari, Mac FireFox, Mac Mozilla, Linux Mozilla, Linux Konqueror, iPhone und Mechanize. Die Timing Einstellungen können ebenfalls sehr wichtig sein:

agent.open_timeout = 3 # setzt timeouts
agent.read_timeout = 4
agent.keep_alive = false # default ist true

Hier folgen nun einige Beispiele, vielleicht werde ich mit der Zeit auch noch ein paar ergänzen, falls jemand Vorschläge hat, immer her damit. Ich habe auf http://apoc.sixserv.org/requestinfo ein kleines Skript am laufen das nützliche Informationen zum HTTP-Request liefert, das kann zum Experimentieren mit Mechanize sehr nützlich sein. Einige Beispiele findet man auch in den GUIDE und EXAMPLES Dateien des Mechanize Pakets.

#01 – Manuelle Get Requests

url = 'http://apoc.sixserv.org/requestinfo/'
page = agent.get url # einfacher get request
# parameter können auch als Hash mitgeliefert werden:
page = agent.get(url, {"name" => "value", "key" => "val"})

#02 – Manuelle Post Requests

url = 'http://apoc.sixserv.org/requestinfo/'
page = agent.post(url, {"name" => "value", "key" => "val"})

In diesem Fall werden die Post-Daten manuell erzeugt, häufig ist es jedoch besser das eigentliche Formular zu verwenden. z.B. ein Login oder Suchformular:

#03 – Post Requests(/Submits) aus Formular erzeugen

page = agent.get 'https://twitter.com/login'
login_form = page.form_with(:action => 'https://twitter.com/sessions')
login_form['session[username_or_email]'] = '[Username]'
login_form['session[password]'] = '[Password]'
page = agent.submit login_form

Dieses kleine Beispiel loggt sich bei Twitter ein.

#04 – Navigation über Links und der History

page = agent.get 'http://www.heise.de/'
page = agent.click(page.link_with(:text => /Telepolis/))
page = agent.click(page.link_with(:href => /artikel/))
agent.back
agent.back
puts page.body

#05 – Exceptions

Wird z.B. eine nicht vorhandene Seite aufgerufen, wirft Mechanize eine Exception, diese sollte Abgefangen werden da das Skript sonst an dieser Stelle abbricht.

begin
  page = agent.get 'http://apoc.sixserv.org/diese/seite/gibt/es/nicht/'
rescue WWW::Mechanize::ResponseCodeError
  puts "ResponseCodeError - Code: #{$!}"
end

#06 – Referer

Mechanize benutzt seine Navigations-History auch zum senden eines passenden Referers, diesen kann man allerdings auch manuell bestimmen, hier für GET und POST Requests:

page = agent.get(:url => 'http://apoc.sixserv.org/requestinfo/',
:referer => 'http://google.com/this/is/a/custom/referer')
puts page.body

#07 – Headers / HEAD / Redirect

Der Request Header kann manuell erweitert werden, bspw. den “X-Requested-With” so zu setzen um einen Ajax-Aufruf zu simulieren. Es gibt leider keine wirklich gute Möglichkeit eigene Header zu setzen, das ganze wurde in den vergangenen Versionen oft geändert, die folgende Methode funktioniert mit älteren Versionen von Mechanize nicht.

agent.pre_connect_hooks << lambda do |params|
  params[:request]['X-Requested-With'] = 'XMLHttpRequest'
end

Dies ist übrigens auch die einzig wirklich einfache Möglichkeit manuell Cookies zu setzen/ zu übertragen. Die andere Seite, also das Abfragen des Response-Headers ist trivial, hier wird z.B. per HEAD-Request die Server und evtl. der PHP-Version abgefragt:

page = agent.head 'http://sixserv.org'
server_version = page.header['server']
puts "Server: #{server_version}"
if page.header.key? 'x-powered-by'
  php_version = page.header['x-powered-by']
  puts "X-Powered-By: #{php_version}"
end

Will man einen HTTP-Redirect(302) abfragen, muss man zunächst das automatische Weiterleiten im Mechanize deaktivieren, dann kann man den Zielort abfragen ohne das Ziel zu besuchen. (Nützlich z.B. wenn man auf einen Datei-Download weitergeleitet wird)

agent.redirect_ok = false
page = agent.get 'http://www.sixserv.org/' # leitet auf http://sixserv.org weiter
puts page.header['location']

#08 – Threads

Will man ein Script etwas beschleunigen kann man mit Threads arbeiten um mehrere Inhalte gleichzeitig abzufragen. Das folgende Grundgerüst für z.B. Foren mit vielen Seiten, bearbeitet 10 Seiten gleichzeitig und kann so ein Skript erheblich beschleunigen. In diesem Fall würde man allerdings wahrscheinlich eher nicht Mechanize einsetzen sondern eine Low-Level API fürs Netzwerk-Zugriff, das wäre deutlich effektiver ich will nur das Prinzip deutlich machen.

$threads = 0
last_page = 200
max_threads = 10
for page in 1..last_page
  Thread.new(page) do |page|
    $threads += 1
    puts " [*] Create new Thread for scanning Page ##{page}"
 
    page = $agent.get "http://example.com/datalist.php?page=#{page}"
 
    # process / save received data
 
    puts " [*] Destroy Thread"
    $threads -= 1
  end
  while $threads > max_threads
  end
  puts " [*] Next Page"
end

#09 – Parsing / XPath

Hat man eine Seite empfangen und will bestimmte Inhalte herausfiltern gibt es mehrere Möglichkeiten, meistens werden mehr oder weniger umfangreiche Reguläre Ausdrücke zum parsen verwendet:

page = agent.get 'http://example.com/'
page.body.match /< h3>([^<]+)< \/h3>/
puts "Überschrift 3: #{$1}"

Wesentlich stabiler sind jedoch XPath Ausdrücke die sich direkt auf die Struktur eines XML-Dokuments beziehen. Werden nur Kleinigkeiten am HTML-Code geändert sind RegEx’s häuft aufgeschmissen und müssen mühsam angepasst werden, XPath ausdrücke dagegen funktionieren häufig auch dann noch. Eine Einführung gibt es z.B. auf w3schools.com oder der offizielle Standard der W3C. Allerdings geht das alles auch sehr einfach mit entsprechenden Werkzeugen, so gibt es z.B. eine Menge Firefox-Addons(nützlich ist z.B. der XPath Checker) die einem, zu markierten Elementen einer Seite einen passenden XPath Ausdruck anzeigt oder umgekehrt, wenn auch die nur einfachen Ausdrücke gelegentlich Nachbearbeitung erfordern.

Firebug kann einem zu beliebigen Elementen einer Seite einen passenden XPath(Rot unterstrichen) anzeigen.

Der von Mechanize verwendete HTML-Parser Nokogiri(鋸) ist sehr robust und kann auch “kaputtes” HTML parsen, was XPath zu einem auserordentlich mächtigen Werkzeug macht, um jede beliebige Information aus noch so komplexen Seiten zu extrahieren.

Mit Firebug: Ein beliebiges Element auf einer Seite markieren und im Kontextmenü, “Inspect Element” aufrufen. In der oberen Zeile von Firebug(siehe Screenshot) kann im Kontextmenü mit “Copy XPath” der XPath geholt werden. Im Beispiel wird der XPath zum Comic-Strip auf XKCD angezeigt: /html/body/div/div[2]/div/div[2]/div/div/img In Mechanize kann so der IMG-Tag extrahiert werden:

page = agent.get 'http://xkcd.com/'
img = page.search '/html/body/div/div[2]/div/div[2]/div/div/img'
puts img
# Ausgabe: < img src="http://imgs.xkcd.com/comics/designated_drivers.png" title="Calling a cab means cutting into beer money." alt="Designated Drivers" >

Das wars damit vorerst. Anmerkungen oder Fragen zu den Beispielen oder Ideen für weitere, bitte in den Kommentaren hinterlassen.

ZDF Mediathek FAIL

nks — Tue, 12 May 2009 14:47:35 +0000

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…