11.21 Etwas zu Streams und TLI, Raw Socket, XTI
Um Ihnen die ganze Welt der Netzwerkprogrammierung nahe zu bringen, bedarf es schon noch ein wenig mehr als dieses eine Kapitel zur Netzwerkprogrammierung. Sie haben hier zwar gute Grundlagen kennen gelernt, doch hat diese Welt bei weitem noch mehr zu bieten. Deshalb noch ein kurzer Überblick, wonach Sie auf jeden Fall noch Ausschau halten sollten.
11.21.1 Raw Socket
Der Name sagt es schon, dass es sich hierbei um eine recht niedrige Ebene der Netzwerkprogrammierung handelt. Mit Protokollen wie dem TCP oder UDP haben Sie quasi (im Verhältnis zu C) im High-Level-Bereich der Netzwerkprogrammierung gearbeitet. Allerdings hatten Sie über TCP oder UDP nie den vollen Zugriff über den Internet Layer – sprich IP. Mit Raw Socket können Sie also eine Ebene unter dem TCP- und UDP-Protokoll programmieren. Einen Haken hat die Sache allerdings, Sie benötigen Superuser-Rechte.
Mit Raw Sockets können Sie zum Beispiel bereits definierte Protokolle implementieren (z. B. für Programmierer von Betriebssystemen interessant) oder gar ein neues Protokoll (auf der Höhe von TCP und UDP) entwickeln. Sie können außerdem beliebige IPv4/IPv6-Pakete (mit Header) erzeugen, übertragen und empfangen. Außerdem können Sie, was TCP und UDP nur intern benutzen, ICMP- und IGMP-Pakete versenden. ICMP-Pakete verwendet zum Beispiel das Programm ping. Ein Raw Socket wird wie üblich über die Funktion socket() angelegt. Allerdings wird, statt des zweiten Parameters SOCK_STREAM oder SOCK_DGRAMM, die symbolische Konstante SOCK_RAW verwendet. Die Protokollnummer (dritter Parameter) kann als Zahl angegeben werden oder als eine bereits vordefinierte Konstante wie z. B. IPPROTO_ICMP oder IPPROTO_IGMP. bind() kann verwendet werden (wobei hier die Absenderadresse gesetzt wird). Auf der IP-Ebene gibt es außerdem keine Ports. Ebenso kann connect() verwendet werden, was allerdings die Zieladresse setzt.
Daten werden bei den Raw Sockets, wie schon bei UDP, mit den Funktionen sendto() und recvfrom() auf ein Socket geschrieben. Diese Daten werden in die Payload des IP-Paketes verpackt und versendet. Alle Felder für das Paket müssen dabei in network-byte-order vorliegen.
11.21.2 TLI und XTI
TLI ist eine kurze Schreibweise und steht für Transport Level Interface. TLI präsentiert dem Programm eine einheitliche Schnittstelle für alle zur Verfügung stehenden Transportprotokolle. Damit ist eine vom verwendeten Transportprotokoll unabhängige Netzwerkprogrammierung möglich. Im Gegensatz dazu unterstützen die heute hauptsächlich benutzten BSD-Sockets nur TCP und UDP. Die TLI-Programmierung ist die unter UNIX System V empfohlene Methode der Netzwerkprogrammierung. Die TLI-Programmierung ist der Socket-Programmierung ähnlich. Für fast alle Socket-Systemaufrufe existieren entsprechende TLI-Routinen. Das Gegenstück zu einem Socket wird in der TLI-Literatur als Kommunikationsendpunkt bezeichnet. Außerdem richtet sich TLI, im Gegensatz zur BSD-Socket-Programmierung, strukturell mehr nach ISO-Vorgaben und dem OSI-Referenzmodell.
Das X/Open Transport Interface (XTI) stellt nochmals eine Verbesserung von TLI dar. XTI bietet als Transportzugriffsschnittstelle Anwendungsprogrammen (Transportsystembenutzern) in UNIX eine einheitliche, nach X/Open ausgerichtete Programmschnittstelle zu den Diensten des Transportsystems. Die Schnittstelle XTI wurde in Form einer Funktionsbibliothek realisiert, die im Anwendungsprogramm eingebunden werden kann. Es wird auch der direkte Zugang zu TCP/IP und UDP/IP erlaubt.
11.21.3 RPC (Remote Procedure Call)
Für die Entwicklung von Software verwendet man in C gewöhnlich die modulare Programmierung. Modular bedeutet, dass oft verwendete Teile in Funktionen oder Prozeduren zusammengefasst werden. So wird das Programm kürzer und auch leichter verständlich.
Der Remote Procedure Call ist, wie der Name schon sagt, eine Methode, über die es möglich ist, Prozesse, die auf einem anderen System liegen, remote aufzurufen.
Man kann sich die Funktion von RPC gut mit der Funktion eines normalen modularen Programms vorstellen. Beispielsweise befinden sich in einer Funktion my_func() folgende Funktionen:
read_text(), decrypt_text()
Hierbei wird einfach eine Textdatei entschlüsselt und gelesen. Die Funktion read_text() befindet sich auf Ihrem Rechner. Die Funktion für das Entschlüsseln der Textdatei mit decrypt() befindet sich auf einem anderen entfernten Rechner. Das ist das Prinzip von RPC, mit dem es möglich sein soll, einfach Funktionen aufzurufen, die nicht auf dem lokalen Rechner liegen, ohne dass dies auffällt.
In der Netzwerkprogrammierung gibt es immer wieder ein Problem, wenn Daten zwischen verschiedenen Rechnerarchitekturen (Big oder Little Endian) ausgetauscht werden. Daraus folgt ja, dass Zahlen von beiden Systemen anders aufgefasst werden. Für dieses Problem hat man XDR entwickelt. XDR übersetzt die Daten in ein allgemein gültiges Format. Dazu müssen die Daten jedoch in XDR beschrieben werden. Das stellt für einen C-Programmierer kein allzu großes Problem dar, da sich die Syntax ziemlich ähnelt. Ich will hier nicht auf die Details eingehen. XDR arbeitet nun so, dass die Daten kodiert, dann übers Netz geschickt und danach wieder dekodiert werden. Sind die Rechner von der gleichen Architektur, entfällt das Verschlüsseln und Entschlüsseln.
Anschließend wird das Werkzeug rpcgen verwendet, das aus einer XDR-Datei, z. B. file.x, C-Code generiert, der größtenteils unverändert übernommen werden kann. So muss der Programmierer nur noch die Prozeduren schreiben, damit das Programm weiß, was es eigentlich tun soll.
|