Die Steckdose für das Internet
Grundlagen des Socket-Interface
Das Internet lebt von der Software, mit deren Hilfe Anwender über das Netz kommunizieren. Egal, ob der Dateitransfer mit FTP, die elektronische Post per EMail oder das Surfen im WWW, immer sind Programme im Einsatz, die auf der einen Seite der Verbin dung Daten bereitstellen und auf der anderen Seite wieder entgegennehmen.
Ohne Software wäre das Internet deshalb so nutzlos wie das Stromnetz ohne Steckdose. Und gerade Plattformen abseits von den dominierenden Betriebssystemen wie Linux, Mac OS und Windows haben noch genügend Nachholbedarf, bis alle der gebräuchlichen Internet-Clients verfügbar sind (man denke nur an so schicke Dinge wie RealAudio[1], CDDB[2] oder ICQ[3]). Aber nicht nur für diesen Bereich sind Kenntnisse über die Implementierung von Internet-Funktionalität nötig, sondern auch bei den herkömmlichen Anwendungen à la Datenbank, Textverarbeitung und Tabellenkalkulation (s. papyrus für Windows oder StarOffice) geht heutzutage ohne Internet-Connectivity, wohl oder übel, beinahe nichts mehr. Wer über Know-how zur Programmierung für und um das Internet verfügt, kann etwa für unsere TOS-kompatiblen Rechner die eine oder andere noch vorhandene Lücke bei den Standard-Clients schließen oder, dem Mainstream folgend, eigene Programme mit InternetFunktionalität aufwerten.
Dieses Know-how zur Software-Entwicklung für das Internet will ich Ihnen in mehreren Teilen, angefangen bei einem Streifzug durch die Techniken des Internets über die konkrete Programmierung des Socket-Interface bis zu einigen nützlichen Problemlösungen für den täglichen Gebrauch, näher bringen.
Programmierers Sicht
Lassen Sie uns aber zunächst die für TOS-kompatible Betriebssysteme vorhandenen Zugangspakete betrachten. Diese binden über PPP (Point-to-Point Protocol) oder SLIP (Serial Line Internet Protocol) den heimischen Rechner in das Internet ein und stellen jeweils die für uns interessante Schnittstelle zum Netz für Anwendungssoftware zur Verfügung.
Für TOS-Rechner gibt es mit MiNT schon seit einigen Jahren ein Betriebssystem, das Dank seiner Verwandtschaft mit UNIX von Hause aus die Funktionalität für eine Internet-Anbindung mit sich bringt. Auf allen TOS-kompatiblen Betriebssystemen kann ein Internet-Zugang mit STiK bzw. dessen Weiterentwicklung STinG realisiert werden. Und schließlich gibt es seit Sommer 97 mit IConnect eine InternetZugangssoftware, die unter den Betriebssystemen MagiC und N.AES läuft. Weitere interessante Entwicklungen sind die Softwarepakete Draconis und WenSuite.
Während der Anwender die einzelnen Internet-Pakete an der Qualität und Quantität der dafür existierenden Clients mißt, betrachtet ein Software-Entwickler die Internet-Zugangssoftware aus einer anderen Perspektive: Ihn interessiert vor allem, wie die Schnittstelle für den Zugriff auf das Internet gestaltet ist.
Eine für viele Betriebssysteme verfügbare Schnittstelle ist das sogenannte Socket-Interface. Es stellt alle notwendigen Funktionen zur Verfügung, um Verbindungen zwischen zwei Rechnern über das Internet herzustellen und Daten auszutauschen. Wie viele Standards rund um das Internet stammen die Spezifikation und die ersten Implementierungen des Socket-Interface aus dem UNIX-Bereich; der Grund, weshalb mit MiNT schon seit Jahren der Internet-Zugang realisiert werden kann, ist aber auch unter Windows oder OS/2 vorhanden. Der Vorteil eines Standards im Bereich der Internet-Anwendungsprogrammierung ist, dass die Portierung einer Anwendung aus dem UNIX-Bereich auf eine andere Plattform enorm vereinfacht wird. Und da viele Internet-Anwendungen unter UNIX bereits vorhanden sind oder auf einer anderen Plattform für diese Schnittstelle programmiert wird, kommt ein Software-Entwickler, der sich mit dem Internet beschäftigt, am Socket-Interface eigentlich nicht vorbei.
Es spricht also sehr viel für die Verwendung des Socket-Interface zur Entwicklung von Internet-Software, vorausgesetzt, es ist überhaupt für das eingesetzte Betriebssystem verfügbar. Erfreulicherweise implementieren neben MiNT die InternetZugangspakete IConnect und Draconis das Socket-Interface für die TOS-Plattform (das länger existierende STinG bzw. STiK verfügt leider nur über eine proprietäre Lösung). Spätestens nach diesen Zeilen dürften Sie nicht mehr überrascht sein, dass sich mein Beitrag zum Thema Internet-Programmierung mit dem Socket-Interface beschäftigt. In den weiteren Folgen werde ich mich auf die Implementierung der Schnittstelle von IConnect beziehen. Die Beispiele sind jedoch mit geringen Änderungen an die anderen (Socket-) Zugangspakete anzupassen.
Internet intern
Bevor wir uns nun aber ab dem nächsten Teil dieses Beitrags mit dem Socket-Interface näher beschäftigen, komme ich, wie bereits angedroht, zu den grundlegenden Techniken des Internet. Allgemein bekannt dürfte mittlerweile sein, dass das Internet aus einem Forschungsprogramm des US-Verteidigungsministeriums in den 60er Jahren hervorging. Das Ziel war, ein ausfallsicheres Netzwerk aufzubauen, das insbesondere einen nuklearen Angriff überstehen sollte. Es wurde ein System ohne zentrale Steuerung und Kontrolle vorgeschlagen, um bei Ausfällen von Knoten die Verbindungen zwischen den Rechnern sicherzustellen. Ein wichtiges Merkmal dieses Netzes sollten paketvermittelte Verbindungen sein. Dazu werden die Daten in einzelne Pakete aufgeteilt, die unabhängig voneinander ihren Weg durch das Netzwerk zum Empfänger finden und dort wieder zusammengesetzt werden. Die Übertragungssicherheit wird durch redundante Verbindungswege und durch die Möglichkeit der Wiederholung verlorengegangener oder zerstörter Pakete erhöht. Diese Überlegungen mündeten Ende der 60er Jahre in die Inbetriebnahme des ARPANET. Es verband zunächst vier Universitäten und Forschungseinrichtungen miteinander. Anläßlich der ersten öffentlichen Vorstellung des ARPANETs 1972 wurde die InterNetwork Working Group (INWG) mit dem Ziel gegründet, ein Protokoll für Verbindungen zwischen verschiedenen Netzwerken zu entwickeln. Die daraus entstandene Protokollfamilie TCP/IP wurde schließlich ab 1982 auch im ARPANET eingesetzt. Da der Zugang zum ARPANET durch das US-Verteidigungsministeriums kontrolliert und beschränkt wurde, entstand parallel in den Jahren 1979, 1983 das CSNET aus dem Bedürfnis amerikanischer Universitäten, die keinen Zugang zum ARPANET hatten, den damit verbundenen Nachteil bezüglich Forschung und Ansehen auszugleichen. Die Verbindung zwischen ARPANET und CSNET über TCP/IP war der erste große Schritt zum heutigen Internet. 1986 wurde mit dem NSFNET der National Science Foundation ein großer Backbone des Internets in den USA in Betrieb genommen, der 1990 die Rolle des aufgelösten ARPANET übernahm.
Heute stellt sich das Internet als Verbund von zehntausenden Netzen mit Millionen von angeschlossenen Rechnern dar. Die Angaben über die Zahl der Teilnehmer schwanken zum Teil erheblich, nicht zuletzt deshalb, weil das Internet keiner zentralen Steuerung unterliegt. Sicher ist nur, dass die Zahl der Internet-Nutzer in die -zig Millionen geht. Natürlich kann das Internet gänzlich ohne Standards nicht funktionieren. Für diese Aufgabe wurde die Internet Society (ISOC) gebildet. Von ihr werden unter anderem auch Protokollspezifikationen, die berüchtigten Request for Comments (RFC), für das Internet herausgeben.
Protokolle
Das Entwickeln von Internet-Anwendungen besteht dann auch größtenteils aus dem Implementieren von diversen Protokollen, wenn wir mal die Benutzerführung unberücksichtigt lassen. Die Internet-Protokolle werden als Transmission Control Protocol/Internet Protocol (TCP/IP) bezeichnet. Der Begriff umfaßt aber nicht nur die beiden Protokolle TCP und IP, sondern eine ganze Familie von Protokollen, die modular miteinander verknüpft sind und in verschiedenen Schichten aufeinander aufbauen.
Eine für Netzwerke übliche Beschreibung ist das OSI-Modell (Open System Interconnection) der ISO (International Standards Organisation). Die Protokollebenen werden durch verschiedene Schichten dargestellt. Jede Schicht erfüllt bestimmte Funktionen, die sie der nächsthöheren Schicht zur Verfügung stellt und verwendet Funktionen der nächstunteren Schicht. Da das Internet wesentlich älter als das OSI-Modell ist, passen seine Schichten nicht vollständig in das Modell. Es gibt einige Gemeinsamkeiten, aber auch viele Unterschiede: Beispielsweise sind im OSI-Modell zwischen Transport- und Anwendungsschicht noch die beiden Ebenen Kommunikation und Darstellung angesiedelt, die beim Internet in den Protokollen der Anwendungsschicht integriert sind.
Sie ahnen es wahrscheinlich schon: Die Anwendungsschicht umfaßt die Protokolle wie etwa FTP, HTTP oder Telnet, die für Ihre Internet-Software von Ihnen je nach Anwendung mit Hilfe des Socket-Interface implementiert werden müssen.
Von Bibliotheken und Sprache
Die übliche Sprache für die Programmierung des Socket-Interface ist C. Sie benötigen also für die Entwicklung von. Internet-Anwendungen einen C-Compiler und natürlich jeweils die Library nebst Bindings für die bevorzugte Socket-Implementierung. Wollen Sie unter MiNT Ihre InternetAnwendung entwickeln, sollten Sie sich eine der MiNTNet-Distributionen (z.B. KGMD) installieren. Die erforderlichen Dateien für IConnect finden Sie unter http://www.camelot.de/-gutu/, die für das Draconis-Paket unter http://dc2.uni-bielefeld.de/atari/downi.htm Darüberhinaus gibt es für den MagiC Scripter ein Plugin, das den Zugriff auf das Internet über IConnect ermöglicht. (http://www.camelot.de/-zulu/).
Die Anwendungsschicht und damit auch Ihre eigene Internet-Software nutzt für den Datenaustausch zwischen zwei Rechnern getreu dem OSI-Modell die Protokolle der Transportschicht, also TCP (Transmission Control Protocol) und UDP (User Datagram Protocol). Diese beiden werden wir im weiteren deshalb auch näher betrachten.
Transport
TCP und UDP regeln eigentlich nicht die Kommunikation zwischen zwei Rechnern, sondern zwischen den sogenannten Ports der Rechner. Das Port-Konzept lässt sich mit Durchwahlnummern einer Telefonanlage vergleichen. Die Adresse, mit der ein Rechner angesprochen wird, entspricht der Telefonnummer und der Port der Nebenstellennummer. Ein Port wird durch eine 16 Bit lange Nummer bestimmt, wobei im Bereich von 0 bis 1024 Ports für bekannte Dienste definiert sind: Die TCP-Port-Nummer für FTP ist 20 für Daten, 21 für Befehle; Telnet hat die TCP-Port-Nummer 23. Ein WWW-Server reserviert meist den TCP-Port 80.
TCP stellt sicher, dass die Daten vollständig und unbeschädigt über das Internet vom Sender-Port zum Empfänger-Port transportiert werden. Hierzu baut TCP eine Verbindung zwischen zwei Rechnern (korrekt: zwischen den Ports ...) auf, über die Datenströme gesendet werden können. Sollten Daten verlorengehen oder wegen Störungen beschädigt werden, sorgt TCP dafür, dass die fehlerhaften Teile erneut übertragen werden. Im Gegensatz zu TCP arbeitet UDP, wie der Name bereits andeutet, nicht mit Datenströmen, sondern mit Datentelegrammen und stellt daher auch nicht sicher, dass die Datentelegramme beim Empfänger ankommen. Dies muss, falls erforderlich, von der Anwendungsschicht bewerkstelligt werden. Der Vorteil von UDP ist, dass die Daten in einer wesentlich kompakteren Form übertragen werden als bei TCP. Voraussetzung ist jedoch, dass die zu übertragenden Daten volumenmäßig in ein Datentelegramm passen. TCP hingegen fragmentiert die Daten der Anwendungsschicht selbständig und sendet sie aus Sicht der Anwendungsschicht stromorientiert. TCP überträgt die Bytes also in der gleichen Reihenfolge, wie sie von der Anwendungsschicht übergeben werden. Jedes Fragment bekommt einen TCP-Header vorangestellt, der unter anderem den Senderund Empfänger-Port sowie eine Prüfsumme enthält.
UDP wird vor allem für zeitkritischen Anwendungen wie etwa die Internet-Telefone verwendet, denn mit UDP können bei einer gegebenen Bandbreite einer Verbindung mehr Nutzdaten übertragen werden als mit TCP. Die mit UDP "gesparte" Bandbreite muss allerdings von der jeweiligen Software ersetzt werden, da sie selbst dafür sorgen muss, die Pakete in die richtige Reihenfolge zu bringen (Pakete können wegen der redundanten Verbindungen unterschiedliche Wege nehmen und haben damit unterschiedliche Laufzeiten) und die Fehlerkorrektur übernehmen.
Vermittlung
UDP und TCP übergeben die Daten (-pakete) der darunterliegenden Ebene. Obwohl die Kommunikation mit IP (Internet Protocol) für Internet-Anwendungen transparent ist, dringen einige IP-Elemente bis zum SoftwareEntwickler und Anwender vor. Allen voran die Art und Weise, wie Internet-Hosts adressiert werden. Denn die allseits bekannte Vier-PunkteForm (z.B. 195.30.224.3) ist ein Konstrukt, das auf der IP-Ebene geschaffen wird, wo jeder Host (genauer jede Netzwerkschnittstelle eines ebensolchen) eine eindeutige Vier-Byte-Adresse besitzt.
IP übernimmt das sogenannte Routing, das Weiterreichen von Datenpaketen von Rechner zu Rechner. In jedem Netz ist mindestens ein Rechner für den Empfang und das Senden von Datenpaketen aus und in das RestInternet zuständig. Diese Rechner werden als Router bezeichnet, sie sind in mindestens zwei Teilnetze des Internet eingebunden (verfügen also über zwei Netzwerkschnittstellen) und können Daten von jedem der direkt erreichbaren Netze in eines der anderen direkt erreichbaren Netze umsetzen. Ein Router entscheidet für jedes Datenpaket, ob er der Zielrechner für das Paket ist oder ob das Paket über eine Netzverbindung an einen anderen Rechner weitergeleitet werden muss. Falls das Datenpaket weitergeleitet werden soll, befragt der Router seine Routing-Tabelle, über welche Netzwerkkarte das Datenpaket weitergeben werden soll. Ist kein Eintrag vorhanden, dann sendet der Router die Daten einfach an den eigenen Default-Router. Dieses Vorgang wiederholt sich solange, bis das Datenpaket an seinem Zielrechner angekommen ist. Im Gegensatz zu TCP arbeitet IP genau wie UDP verbindungslos, d.h. das IP-Protokoll schickt die IP-Pakete in das Netzwerk, ohne zunächst zu wissen, welchen Weg die Pakete nehmen, um zum Empfänger zu gelangen. Es kann auch vor
kommen, dass die Pakete unterschiedliche Wege zum Empfänger nehmen, so dass die Reihenfolge der empfangenen Pakete beim Zielrechner nicht voraussagbar ist. Damit die Daten wieder rekonstruierbar sind, werden alle Pakete im Header eindeutig numeriert. Das IP-Protokoll stellt aber nicht sicher, dass die Pakete, die es auf die Reise schickt, vollständig und fehlerfrei beim Zielrechner ankommen. Dies ist wiederum die Aufgabe von TCP oder die der Internet-Anwendung bei UDP.
Die IP-Pakete werden schließlich der Netzwerkschicht übergeben. Je nachdem, welche Netzwerkarchitektur unterhalb der IP-Schicht liegt, werden die Pakete per Ethernet, Telefonleitung oder mit einer anderen Verbindung transportiert. Auf diese werde ich aber nicht weiter eingehen, da sich das Internet gerade durch die Kommunikation zwischen verschiedensten Rechner- und Netzwerkarchitekturen unabhängig vom physikalischen Medium auszeichnet.
Adressen
Kommen wir nochmals auf die VierPunkte-Form einer Internet-Adresse zurück. Ein Anwender benutzt natürlich lieber Adressen der Form www.camelot.de als das IP-eigene Konstrukt 195.30.224.3. Die Umsetzung des Host/Domain-Namen in die numerische IP-Adresse leistet das DNS (Domgin Name System), das übrigens auf der Anwendungsebene angesiedelt ist. Das Socket-Interface umfaßt natürlich bereits entsprechende Funktionen. Grundlage ist eine hierarchisch organisierte und verteilte Datenbank. Der mögliche Namensraum wird in Domains und Sub-Domains aufgeteilt. Ausgangspunkt für die DNS-Struktur sind die sogenannten Top-Level-Domgins arts (kulturelle Angebote), com (kommerzielle Unternehmen), edu (Ausbildungseinrichtungen der USA), firm (Geschäftskunden und Firmen), gov (Einrichtungen der US-Regierung), info (Informationsangebote), mil (militärische Einrichtungen der USA), nom (persönliche bzw. fachspezifische Angebote), org (nichtkommerzielle Einrichtungen), rec (Erholungs- und Unterhaltungsangebote), store (Versandhäuser, Verkaufsangebote) und web (Aktivitäten rund um das WWW). Daneben gibt es die länderbezogenen Domains, wie etwa de für Deutschland oder n1 für die Niederlande. Unterhalb der Top-Level-Domgins werden Sub-Domains eingerichtet. Beispielsweise hat mein Provider die Domain camelot.de, die in www.camelot.de und ftp.camelot.de noch weiter unterteilt ist. Meist spiegeln diese Namen, anders als die IP-Adressen, auch die regionale und organisatorische Zugehörigkeit eines Rechners wieder. Trotzdem müssen Sub-Domains keineswegs innerhalb einer Netzklasse liegen. Die Zuordnung erfolgt einzig durch die Datenbanken der DNS-Server und ist willkürlich.
Die Ermittlung der IP-Adresse über den DNS funktioniert folgendermaßen: Der Host digit.camelot.de will mit dem Host www.kolibri.de kommunizieren. Der DNS-Server für die Sub-Domain camelot.de kann die Anfrage nicht bearbeiten, da die zugehörige IP-Adresse für www.kolibri.de nicht in seiner Datenbank vermerkt ist. Er leitet daher die Anfrage an den für die Top-Level-Domgin de zuständigen DNS-Server weiter. Dieser antwortet mit der IP-Adresse des DNS-Servers, der für die Sub-Domain kolibri.de zuständig ist. Dort erfragt der lokale DNS-Server die IP-Adresse für den ZielHost. Erstjetzt kann die Kommunikation zwischen den beiden Rechnern aufgenommen werden. Ein Host mit einer IP-Adresse kann übrigens mehrere Host-Namen haben, beispielsweise wenn er zwei unterschiedliche Dienste zur Verfügung stellt, die mit verschiedenen Clients angesprochen werden. So hat der ftpServer ftp.camelot.de dieselbe IP-Adresse wie die beiden Mail-Server pop.camelot.de und mail.camelot.de, nämlich 194.97.87.3. Welcher Dienst auf diesem Server angesprochen wird, ergibt sich aus dem jeweiligen Port.
Da so gut wie jede Internet-Anwendung mit dem DNS in Berührung kommt, werden wir uns im nächsten Teil auch gleich mit den DNS-Funktionen des Socket-Interface näher beschäftigen. Bis zur nächsten Ausgabe haben Sie Zeit, sich einmal von diesem trockenen ersten Teil zu erholen und zum anderem die Voraussetzungen für die folgenden praktischen Teile zu schaffen (s. Kasten "Von Bibliotheken und Sprachen").
[1] http://www.realaudio.com [2] http://www.cddb.com [3] http://www.icq.com
Jürgen Koneczny