Wie vernetzte Anwendungen bei mobilem Einsatz in Kontakt bleiben

Abbildung 1: Ende Dezember ist das Berliner Congress Center regelmäßig Treffpunkt von Vernetzten.

© © anders_hh, CC-BY

Ein eisiger Wind pfeift durch den Bahnhof Berlin Alexanderplatz. Im Dezember jedes Jahres zieht es mich nach den Feiertagen zum Chaos Communication Congress, dem Treffpunkt für Netzwerker auf technischer wie soziologischer Ebene. Ich versuche, meinen Kollegen Thomas anzurufen, denn er hat die Eintrittskarte für mich – gar nicht so einfach, an die Dinger heranzukommen, seit der veranstaltende CCC mit immer neuen Tricks versucht, das Angebot zu verknappen. Während ich mit Thomas telefoniere, stapfe ich durch den Schnee an der Urania Weltzeituhr vorbei. Obwohl ich durch den Bahnhof, eine Passage und quer über den von hohen Gebäuden gesäumten Platz laufe, bleibt die Telefonverbindung stabil.

Durchgehende Verbindungen zu realisieren war ein wichtiges Designziel der Protokolle GSM und UMTS. Das schaffen sie durch ausgeklügelte, komplizierte Schichten in ihrem Stack, von dem der normale Telefonierer oder ein Nutzer der darauf aufbauenden Datendienste nichts mitbekommt. Die Übergabe von einem Base Tranciever Station genannten Funkmast zum nächsten geschieht für die Nutzer transparent.

Zugangstechnik wählen

Im Berliner Congress Center (siehe Abbildung  1) taue ich langsam wieder auf. Der Kongress ist wie jedes Jahr ein buntes Gewimmel, auch wenn er mir aufgrund des harten Einlassregimes etwas braver als in den Vorjahren vorkommt. Dennoch sind Netze allgegenwärtig: An jeder der ungezählten Ethernetdosen an den Wänden hängt mindestens ein Notebook. Manche Besuchergruppe hat sich gleich Switches mitgebracht, die die Lockpicker, Freifunker und Debianer dann munter weiter kaskadieren.

Darüber hinaus gibt es auch noch WLAN: Zur Wahl stehen das b-, g-, a- und n-Netz mit unterschiedlichen ESSIDs, teils mit dynamischer und teils mit fester Adressvergabe, sowohl für IP als auch für IPv6. Nachdem ich Probleme mit einer Verbindung im dynamischen WLAN habe, hole ich mir im Network Operations Center (NOC) eine Wäscheklammer mit aufgemalter IP: "Das ist Peg-DHCP nach RFC  2322", ruft mir ein Helfer zu. Ich verbinde mein Notebook mit einem freien Switchport in der Nähe des im Keller untergebrachten NOCs und konfiguriere meine Netzwerkkarte mit den Angaben auf der Klammer.

Wechselnde Zieladressen

Teilnehmer in einem IP-Netz benötigen gewöhnich eine 32 Bit große IP-Adresse. Bei IPv6 gilt im Prinzip das gleiche, da sich auf dieser Ebene die Protokolle nur geringfügig unterscheiden. Die größte Abweichung ist die Länge der Adressen, die bei IPv6 128 Bit beträgt. Die Idee des TCP/IP-Stacks ist hinlänglich bekannt: Zwei Endpunkte kommunizieren miteinander. IP-Adressen repräsentieren die jeweiligen Rechner, die einzelnen Dienste oder Prozesse versinnbildlichen 16 Bit große Portnummern.

Entwickler dürfen noch zwischen zwei Transportarten wählen: Die mit UDP realisierten Datagramme verursachen etwas weniger Overhead, gehen aber gelegentlich verloren. TCP hingegen liefert dem Programm einen richtig sortierten Datenstrom, der beim Absender genauso aussieht wie beim Empfänger. Dazu kümmert sich das Betriebssystem um verlorengegangene Datenstücke. Die meiste Software verwendet TCP zum Transport. UDP setzen VoIP-Programme und vor allem das DNS ein. Beide Klassen kommen gut mit kleinen Paketen aus.

Aus dem CCC-Fahrplan erfahre ich, dass Qmail-Erfinder Daniel J. Bernstein einen Vortrag hält, versetze mein Notebook in Tiefschlaf und mache mich auf den Weg. Im übervollen Hauptsaal ist an Netzdosen nicht zu denken. Auch die vier WLAN-Accesspoints in Sichtweite sind offenkundig überfordert. Zum Glück habe ich meinen UMTS-Stick dabei, der zwar etwas stockend, dafür aber zuverlässiger reagiert. Nach wenigen Sekunden signalisiert der KDE-Network-Manager eine Netzverbindung und ich rufe die Beschreibung des Talks von der CCC-Website ab.

HTTP, ursprünglich zum Abruf von Webseiten gedacht, nutzen auch andere Anwendungen außerhalb des WWW, darunter Skype für Telefonie, Webdav zum Zugriff auf Dateiserver und Webservices mit SOAP, um entfernte Funktionen aufzurufen. Das Protokoll ist sehr einfach und lädt im Wesentlichen eine Datei beliebigen Formats von einem Server herunter, die durch eine URL angegeben ist. Dabei muss diese Datei keine Webinhalte transportieren. Ebenso denkbar sind Bild-, Ton- oder Videodaten, CSS-Stylesheets oder PDF-Dokumente. Listing  1 zeigt beispielhaft, wie ein Browser eine Homepage abholt. Neben deren HTML-Datei lädt er zusätzlich das Stylesheet »mein-style.css« und das Bild »smile.png« von dem Server.

01 <!DOCTYPE html PUBLIC
02  "-//W3C//DTD XHTML 1.0 Strict//EN"
03  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
04 <html xmlns="http://www.w3.org/1999/xhtml"
05       xml:lang="de" lang="de">
06   <head>
07     <title>Demo-Seite</title>
08     <link rel="stylesheet" type="text/css"
09           href="mein-style.css" />
10   </head>
11   <body>
12     <h1 class="ueberschrift">Hallo, Welt!</h1>
13     <img src="smile.png" />
14   </body>
15 </html>