Alles Text Sockets à la Plan 9

Transkript

1 Alles Text Sockets à la Plan 9 Petra Gremeyer, Axel-Tobias Schreiner, Fachbereich Mathematik/Informatik, Universität Osnabrück Plan 9, das neue verteilte Betriebssystem der UNIX-Schöpfer, hat bekanntlich mit einer Reihe liebgewonnener, wenn auch vielleicht etwas obskurer, UNIX- Konventionen gebrochen. Eine wesentliche Design-Entscheidung bei Plan 9 bestand darin, zur Systemsteuerung eher auf Text als auf problematische Binär-Strukturen zu setzen dies trägt entscheidend zur Portabilität von Programmen wie ps bei. Dank Klar text kann man bei Plan 9 auch sehr leicht Netzverbindungen aufbauen. Als Werkzeuge genügen dazu die Shell rc und einfache Kommandos wie echo und cat. Datagramme UDP UDP-Datagramme sind einzelne Datenblöcke, die ungesichert von Prozeß zu Prozeß übertragen werden, das heißt, der Sender schickt ein Datagramm einmal ab, und es kann beliebig oft (und auch gar nicht) ankommen. Bei Berkeley-UNIX benötigen Sender und Empfänger je einen Socket, der mit dem Systemaufruf socket() als File-Deskriptor erzeugt wird. Der Empfänger richtet mit bind() einen Empfänger-Port ein, an den der Sender den Datenblock mit sendto() schickt. Der Empfänger erhält Daten und Absender mit recvfrom().

2 Im Transport-Layer-Interface (TLI) von System V erzeugt t_open() die Kommunikationsendpunkte als File-Deskriptoren, t_bind() richtet darauf lokale Ports ein. Der Sender verschickt die Daten mit t_sndudata(), und der Empfänger erhält sie mit t_rcvudata(). Bei fast allen diesen Systemaufrufen spielen reichlich komplizierte Adreßstrukturen eine entscheidende Rolle TCL-DP demonstriert, daß es auch unter UNIX viel einfacher gehen kann. Plan 9 bildet eine Netzschnittstelle als Dateisystem ab. Protokolle wie UDP sind durch Server realisiert, die ihrerseits ebenfalls Dateisysteme anbieten. UDP findet man normalerweise im Katalog /net/udp. Öffnet man eine Datei clone, kann man aus ihr eine Verbindungsnummer lesen, die als Unterkatalog von /net/udp dargestellt wird. In dem Katalog kann man in eine Datei ctl Steuerbefehle und in data Daten schreiben. Der Empfänger liest die Daten seinerseits aus data. Durch weitere Dateien wie local, remote und status kann man sich über den Zustand der Verbindung informieren. Abbildung 1 zeigt, mit welch primitiven Mitteln man eine UDP-Verbindung für Plan 9 aufbauen kann. % cd /net/udp % { c=`{cat} echo announce 5678 > $c/ctl cat $c/data } < clone CAT(1) CAT(1)... Abbildung 1a: Plan 9 UDP-Server, empfängt Text % cd /net/udp

3 % { c=`{cat} echo connect $ipaddr!5678 > $c/ctl cat $c/local $c/remote $c/status man cat > $c/data } < clone ! !5678 udp/1 1 Datagram Abbildung 1b: Plan 9 UDP-Klient, sendet Text Zwar wird als Shell Tomm Duffs rc verwendet, aber in diesem Zusammenhang besteht der einzige Unterschied zur Bourne-Shell darin, daß `{...} statt `...` durch die Standard-Ausgabe des eingeschlossenen Kommandos ersetzt wird. cat liest jeweils aus /net/udp/clone die Verbindungsnummer, die dann in der Variablen c gespeichert wird. Die Kommunikation erfolgt im Katalog /net/udp/$c. Der Server hinterlegt seine Port-Nummer 5678, indem er schlicht mit echo die Anweisung announce 5678 über die Datei /net/udp/$c/ctl an den Server schickt. Der Klient hinterlegt analog mit connect die gewünschte Zieladresse für sein Datagramm. Die Kommunikation erfolgt dann mit einfachen Schreib- und Lesezugriffen auf die Datei /net/udp/$c/data. Da UDP keine Verbindung einrichtet oder aufrechterhält, muß der Server explizit abgebrochen werden.

4 Name Service Die Variable ipaddr enthält die eigene Internet-Adresse im Ernstfall müßte der Sender natürlich eine fremde Adresse angeben. Mit dem Kommando ndb/query kann man aber auch von rc aus Internet-Adressen beschaffen. % ndb/query sys thor ip Diese Anfrage wird direkt aus der lokalen Datenbasis /lib/ndb beantwortet. % ndb/csquery > net!thor!echo /net/tcp/clone !7 > Diese Anfrage richtet sich an den Connection Server cs, der die Datei /net/cs befragt und eine Kombination aus Protokoll, Rechnernamen und Dienst in Internetadresse und Portnummer übersetzt. net!host!service steht dabei für ein beliebiges Protokoll, also z.b. für TCP. cs kann man von rc aus nicht direkt ansprechen, da man auf eine Datei wie /net/cs nicht zum Lesen und Schreiben gleichzeitig zugreifen kann. Da rc seine Variablen als Listen von Texten betrachtet, kann man die interessante Information aber so gewinnen (Das erste Listenelement ist der Prompt >): % l=`{echo tcp!thor!echo \ ndb/csquery} % clone=$l(2) % address=$l(3) cs ist intern auch mit dem Domain Name Service verbunden.

5 Byte-Ströme TCP Will man beliebige Folgen von Bytes so übertragen, daß sie garantiert unverändert ankommen, greift man normalerweise zu TCP. Bei Berkeley-UNIX wird einem Socket dazu mit bind() im Server wieder eine lokale Port-Nummer zugeordnet. listen() richtet den Socket so ein, daß er auf eine Verbindungsanforderung warten kann. accept() liefert eine Verbindung als Daten-Socket, über den dann Daten mit read() und write() transferiert werden. Der Klient verwendet connect(), um eine Verbindung zum Server herzustellen. Das TLI benützt ähnliche Aufrufe; man muß allerdings auch noch den Streams-Modul tirdwr einfügen, wenn man read() und write() einsetzen will. Bei Plan 9 spielt sich die Verbindung im Katalog /net/tcp ab. Auch hier liest man aus /net/tcp/clone eine Verbindungsnummer ein, die einen Unterkatalog reserviert. Dort gibt es dann eine Datei listen, die eine weitere Verbindungsnummer liefert, in deren Unterkatalog der Server dann wirklich Daten transferiert. Abbildung 2 zeigt einen TCP-Server als rc-programm unter Plan 9. % cd /net/tcp % { c=`{cat} echo announce 5678 > $c/ctl echo backlog 3 > $c/ctl { d=`{cat} cat $d/data } < $c/listen } < clone CAT(1) CAT(1)... %

6 Abbildung 2: Plan 9 TCP-Server Mit announce wird wieder die Port-Nummer hinterlegt, und backlog bestimmt, wie viele Verbindungsanforderungen in einer Warteschlange gehalten werden sollen. Der Klient unterscheidet sich effektiv nicht vom UDP-Klienten, sein Aufruf muß aber natürlich im Katalog /net/tcp erfolgen. Der gleiche Server kann in einem Katalog /net/il auch für das IL-Protokoll verwendet werden, das speziell für Plan 9 entwickelt wurde, um Datagramme sicher zu übertragen. Super-Ser ver Richtig spannend (und nützlich) ist ein Super-Server, der gleichzeitig mehrere Ports bewacht und sie erst dann mit den eigentlichen Servern verbindet, wenn Verbindungen aufgebaut werden. Das Musterbeispiel in Berkeley ist inetd, wo mit der Konfigurationsdatei /etc/inetd.conf eine Vielzahl der bekannten Internet-Services wie TELNET oder FTP eingerichtet werden. Bei Plan 9 übernimmt aux/listen die Aufgabe des Super-Servers, und die Konfiguration erfolgt durch Eintrag von rc-skripten in den Katalog /bin/service ein TCP-Anruf für Port 21 (FTP) wird dann im Skript tcp21 bearbeitet. Die Pointe von aux/listen kann man durchaus auch mit Hilfe eines rc-skripts vorführen. Abbildung 3 zeigt einen Super-Server, der das IL-Protokoll durch Slave- Server abwickeln läßt. % cd /net/il % { c = `{cat} echo announce * > $c/ctl echo backlog 2 > $c/ctl

7 while () { { d=`{cat} cat $d/remote $d/local > $d/data } < $c/listen } } < clone & Abbildung 3: Plan 9 IL-Super-Server Gibt man bei announce statt einer Port-Nummer nur * an, bewacht der Server alle Ports für das angegebene Protokoll. Die endlose while-schleife sorgt dafür, daß beim Aufbau einer Verbindung dem Klienten sein eigener Verbindungsstatus gezeigt wird. Ein geeigneter Klient wird in Abbildung 4 als rc-funktion vorgeführt. % fn client { { c = `{cat} echo connect $ipaddrˆ!ˆ$1 > $c/ctl cat $c/data } < clone } Abbildung 4: Plan 9 IL-Klient Das Funktionsargument $1 wird mit dem Verkettungsoperator ˆ zur (eigenen) Host- Adresse hinzugefügt und mit der Anweisung connect an das System übergeben. Ein Ablauf sieht vielleicht so aus: % client ! !123

8 Man sieht, daß der Super-Server aus /net/il/$d/local den angerufenen Port decodieren und die Auswahl des eigentlichen Servers von der Port-Nummer abhängig machen könnte. Die Quellen Mit der Programmierung von Netzkommunikation haben sich mehrere Artikel in der unix/mail auseinandergesetzt. In der UNIX-Sprechstunde in unix/mail 2/90 ging es um Berkeley-Sockets, in unix/mail 4/94 wurden einfache Übertragungen mit TCL-DP vorgeführt.