IOException.de

Am 2. Dezember 2010 haben verschiedene große DNS Anbieter, nach dem Release der US-Botschaftsdepeschen, aufgehört die wikileaks Domains aufzulösen. Daraufhin wurde der Inhalt der WikiLeaks-Website auf knapp 2.200 Servern gespiegelt. Die Server wurden von Freiwilligen auf der ganzen Welt zur Verfügung gestellt.

Dieser Vorfall zeigt eindrucksvoll, wie die dezentralen Strukturen des Internets genutzt werden können um Zensur zu umgehen und Informationsunterdrückung zu verhindern.

Nachdem ich im vorigen Beitrag die Ausgabe des traceroute Utilities visualisiert habe wollte ich hier noch etwas weiter machen. Dieses Mal war mein Ziel die Domains der verschiedenen Mirrors herauszubekommen, diese erst zu einer IP, dann zu WGS84 aufzulösen. Die WGS84 Koordinaten kann ich dann auf einer Erdkugel abbilden.

Die Domains herauszubekommen war einfach, es gibt verschiedene Seiten die die Adressen der Spiegelserver auf einer HTML-Seite auflisten. Diese Liste lässt sich bequem parsen. Das Auflösen zu einer WGS84-Koordinate habe ich wieder über eine freie GeoIP-Datenbank vorgenommen. Von da an konnte ich große Teile des traceroute Projekts wiederverwenden um die Domains auf eine Weltkugel zu mappen.

Ganz interessant ist, dass die Server tatsächlich auf der ganzen Welt verteilt sind. Die meisten Server stehen — jetzt nicht besonders überraschend — in Mitteleuropra. Es sind wohl aber auch einige wenige in China. Natürlich geben die Ergebnisse der GeoIP Datenbank keine sicher bestimmten Standorte wieder, aber ich finde der Trend ist doch schön erkennbar.

Ich habe ein kleines Video zu der globalen Verteilung zusammengestellt:

Der Direktlink: vimeo.

Um mich näher mit Processing und OpenGL auseinanderzusetzen habe ich ein Frontend für das Unix Programm traceroute geschrieben. Die Ausgabe von traceroute ist eine Liste mit Stationen die ein Paket auf seinem Weg durch das Netzwerk passiert. Dies kann etwa für das Debuggen einer Netzwerkverbindung genutzt werden.

Technisch wird dies über das “Time-To-Live”-Feld im Header von IP-Paketen realisiert. Der TTL-Eintrag gibt an, nach wie vielen Stationen ein Paket verworfen werden soll. Jeder Router, den das Paket passiert, dekrementiert dieses Feld. Ist die TTL bei 0 angelangt wird das Paket verworfen und der Absender mittels einer ICMP-Nachricht TIME_EXCEEDED benachrichtigt.

traceroute macht sich diesen Umstand zunutze indem immer wieder Pakete an den Zielhost gesendet werden. Die TTL wird dabei schrittweise erhöht bis das Ziel erreicht ist. Die Hosts auf dem Weg werden sich nach und nach mit ICMP-Nachrichten melden, so dass wir dann Informationen über den Absender gewinnen und somit (hoffentlich) die einzelnen Stationen auf unserer Route identifizieren können. Diese Route muss hierbei nicht zwangsläufig korrekt sein. Es können sich aus verschiedenen Gründen Abweichungen ergeben, etwa durch Firewalls die aus Sicherheitsgründen ICMP gleich komplett deaktivieren.

Für die Visualisierung habe ich traceroute, wie im letzten Beitrag beschrieben, als externes Programm an Processing angebunden. Das Frontend liest dabei die Ausgabe des Kommandoaufrufs traceroute domain.org bis EOF. Jede Zeile wird geparsed, dabei werden die einzelnen Hosts der Route nach IP-Adressen aufgelöst und anschließend die Koordinate bestimmt. Die Koordinaten können anschließend mit etwas sin/cos Grübeln auf einer Erdkugel abgebildet werden. Das Auflösen nach Geolocations habe ich mittels einer GeoIP-Datenbank realisiert. GeoIP-Datenbanken stellen eine Zuordnung IP zu Koordinate dar. Natürlich nur mit einer bestimmten Wahrscheinlichkeit und auch nicht völlig exakt, aber für unsere Zwecke reicht das. Es gibt hier einige freie und natürlich jede Menge kommerzielle Anbieter. Ich habe mich dabei für die freie GeoLite City von Maxmind entschieden. Im Endeffekt löse ich so jetzt eine IP-Adresse zu einer WGS84-Koordinate auf.

Für das Frontend habe ich in Java mithilfe der Processing API eine Visualisierung geschrieben. Die Textur der Weltkugel wird mittels eines in GLSL geschriebenen Shaders weiter verändert. Bibliotheken, die ich verwendet habe: GLGraphics (OpenGL Rendering Engine für Processing), controlP5 (Button, Slider, Textfield) und toxiclibs (Interpolation & andere numerische Methoden).

Den Sourcecode habe ich unter MIT auf GitHub veröffentlicht: visual-traceroute.

Ein bisschen Eye Candy gibts in dem Video unter diesem Beitrag bzw. hier als Direktlink auf Vimeo.

Processing ist eine Programmiersprache, die entwickelt wurde um es möglichst einfach zu machen Visualisierungen zu erstellen und grafische Arbeiten am Computer erstellen zu können. Der Sprachumfang (bzw. die API) ist sehr übersichtlich und ist hier auf einer Seite zusammengefasst.

Für Processing existieren heute enorm viele Bibliotheken und die Sprache wurde u.a. nach Javascript portiert bzw. wird aktuell nach Android portiert. Somit wird Processing 2.0 auch das Ausführen im Browser und auf einem Android-Gerät unterstützen (bzw. trunk unterstützt es schon :) ).

Toll ist, dass sich die Processing-Bestandteile als externe Java Bibliotheken referenzieren lassen. Wir können also in unserem Java-Projekt sehr bequem die Processing-Möglichkeiten ausschöpfen. Wir können außerdem jede Menge Processing-Bibliotheken referenzieren, etwa für Physik, Typographie, etc..

Dieser Beitrag soll zeigen wie einfach es ist in Java mit den Processing Bibliotheken ein reines Frontend zu schreiben. Bei vielen Aufgaben bietet es sich an eine Sprache zu verwenden, die sich speziell für diese Aufgabe eignet. In manchen Fällen wollen wir also das Frontend in Processing schreiben, das Backend aber in einer anderen Sprache.

Wir haben also zwei verschiedene Programme. Wie verbinden wir die Beiden jetzt?

Unser Processing-Programm startet einen Thread der wiederum das externe Programm startet und konstant die Ausgabe des externen Programmes liest (bis EOL). Diese Ausgabe wird konstant geparset und in einem Objekt, beispielsweise einer Liste, abgelegt.

Das Hauptprogramm hat die Aufgabe unsere “Zeichenfläche” darzustellen. Processing sieht dazu eine Methode draw() vor, die entsprechend der Framerate oft aufgerufen wird. In der draw() Methode lesen wir das Objekt des Threads ein und berücksichtigen dies für unsere Darstellung.

In Processing sieht das Ganze dann so aus:

/*
 * Aufgabe des Threads:
 * Die Ausgabe unseres "Backend"-Programmes zu lesen und zu parsen.
 */
public class Stream extends Thread { 
  /* Für jede Zeile der Ausgabe erstellen wir einen Eintrag in der Liste */
  Vector <StreamEntry > entries = new Vector <StreamEntry >();

  public void run() { 
    String line; 

    try {
      Process p = Runtime.getRuntime().exec("ping uni-ulm.de");
      BufferedReader input = new BufferedReader(
         new InputStreamReader(p.getInputStream()));

      while ((line = input.readLine()) != null) 
        entries.add(new StreamEntry(line));

      input.close(); 
    } catch (Exception err) {
      err.printStackTrace();
    }
}

public class StreamEntry {
  public int time;

  public StreamEntry(String line) {
    /* Parsing action ... */
    this.time = ...;
  }
}

Unser Hauptprogramm zur Darstellung:

public class Main extends PApplet {
  /* Unser Thread, der die Ausgabe des Backends liest */
  private Stream stream;

  public void setup() {
    size(1024, 768);

    stream = new Stream();
    stream.start();
  }

  /* draw() wird entsprechend der Bildwiederholrate oft aufgerufen */
  public void draw() {
    background(BLACK);

    /* Wir geben alle Einträge der Ausgabe aus */
    for (StreamEntry s : stream.entries)
      text(s.time, 10, y+=15);
  }
}

Der zweite Thread verarbeitet also kontinuierlich die Ausgabe des Backend. Unser Hauptprogramm aktualisiert bei jedem Aufruf von draw() die Zeichenfläche und berücksichtigt hierbei die Ausgabe des Backends.