3 Service-Design. 3.1 Dateitransfer. 3.2 Dialog

Transkript

1 29 3 Service-Design Services beruhen zumeist auf Dateitransfer, der allerdings auch im Dialog erfolgen kann. Dateien kann man mit vielen Protokollen übertragen. Sie unterscheiden sich zum Beispiel in Authentifizierung, Adressierung und Codierung. 3.1 Dateitransfer Kann man Bytes sicher übertragen, muß man sich überlegen, was man mit den Bytes anfangen will. UUCP (durch Pakete und Prüfsummen abgesicherte Übertragung auf seriellen Vrbindungen, normalerweise über Modems) hat seinerzeit vorgeführt, daß man eine Vielzahl von Leistungen schlicht auf Dateitransfer zurückführen kann: uucp Dateikopie Datei an beliebigen Punkt kopieren mail Nachricht: einer an einen Datei an Mailbox-Datei anhängen news Nachricht: einer an alle Datei in Katalog anlegen lpr drucken Datei in Drucker-Bereich anlegen; Dämon bearbeitet sie später uux Auftrag abwickeln Datei in Katalog anlegen, Dämon bearbeitet sie später Rückmeldungen können wesentlich später per mail erfolgen, also wieder per Dateitransfer. Abgesehen davon, daß die Pakete quittiert werden, ist dies halb-duplex Betrieb, kein Dialog. Problematisch sind die Zugriffsrechte auf das Dateisystem des Zielrechners (eine Universität soll sich so die UNIX-Quellen beschafft haben) und die Codierung der Datei-Inhalte. 3.2 Dialog Andersartige Leistungen ergeben sich, wenn man synchrone Auftragsabwicklung wünscht, also zum Beispiel Anfragen an die Warteschlange des Drucker-Subsystems. In diesem Fall muß man auf dem Zielsystem ein Kommando so ablaufen lassen können, daß dessen Ausgabe direkt als Antwort auf die Anfrage geschickt wird. inetd bewacht TCP- (und UDP-)Ports nach Anweisung seiner Konfigurationsdatei /etc/ inetd.conf. Kommt ein Anruf, erhält ein Kommando die Verbindung für Standard-Ein- und - Ausgabe. Plan 9 verwendet zur Konfiguration einen Katalog mit rc-skripten, abgelegt unter Port-Nummern als Dateinamen. Super-Server wie inetd dienen eigentlich dazu, die Anzahl Prozesse relativ zu den angebotenen Services zu verringern, aber man kann damit fast beliebige Kommandos als Service anbieten. Dies ist zwar voll-duplex Betrieb, aber je nach Kommando ist der Dialog gepuffert. Problematisch ist, daß inetd selbst keine Authentifizierung verlangt, sondern nur eine lokale Identität für die Ausführung eines Kommandos vorgibt. Kommandos wie fingerd lesen eine Anfragezeile als Standard-Eingabe und konstruieren daraus einen mehr oder weniger sicheren Aufruf eines lokalen Kommandos ein sehr primitives Protokoll.

2 Beispiel /etc/inetd.conf ats stream tcp nowait nobody /bin/dd dd ibs=1 obs=32 /etc/services ats 12345/tcp In diesem Fall entsteht auf TCP-Port ein Echo-Service, der aber 32 Bytes zusammenkommen läßt: # ps ax grep inetd 215?? Ss 0:00.01 inetd # kill # neu konfigurieren $ telnet localhost ats Trying Connected to localhost. Escape character is '^]'. axel was here and he liked this program axel was here and he liked this^] telnet> q Connection closed. telnet dient einfach als Brücke zwischen einem Benutzer-Terminal und einer TCP-Verbindung zum Service und kann verschieden gepuffert arbeiten: /etc/inetd.conf telnet> Effekt cat -u axel axel mode character aaxxeell dd bs=32 axel axel mode character aaxxeell vi ex/vi: Vi's standard input and output must be a terminal ed a? Abgesehen davon, daß vi und selbst ed viel zu mächtige Kommandos sind, sieht man zwei Probleme: ein Kommando kann eine TCP-Verbindung von einem Terminal unterscheiden, und telnet schickt grundsätzlich \r\n für einen Zeilentrenner, was zu Syntaxfehlern in ed führt. Letzteres kann man mit tcp.client umgehen. 30

3 3.3 Pseudo-Terminal Server wie inetd oder rshd verwenden die TCP-Verbindung mehr oder weniger direkt als Standard-Ein- und -Ausgabe von normalen Kommandos. Damit ist nur eine begrenzte Form von remote login möglich. Problematisch sind die jeweiligen Zeichensätze und die Tatsache, daß die Authentifizierung letztlich lokal auf dem Server erfolgt Paßwörter könnten abgehört werden. Server wie telnetd, rlogind und sshd verwenden server-seitig sogenannte Pseudo-Terminals, um auf der Server-Seite einer TCP-Verbindung für Kommandos wie vi einen Terminal-Treiber zu simulieren. Ein Terminal-Treiber kümmert sich vor allem um Signale und Zeilenpufferung und -editierung: 31 Hinter einer Netzverbindung wird ein Pseudo-Terminal wie eine Art bidirektionale Pipeline zwischen Netz-Server auf der Master-Seite des Pseudo-Terminals und einem Service-Prozeß auf der Slave-Seite des Pseudo-Terminals eingeschaltet: Klient und Server können dann zum Beispiel mit TCP-out-of-band-Daten Signale übertragen, die der Slave als solche zugestellt bekommt. Fragt ein Slave-Prozeß wie vi, kann er ein Pseudo-Terminal nicht unbedingt von einem echten unterscheiden. Problematisch bleibt nach wie vor die Authentifizierung, da die Netzverbindung abgehört werden kann und Slave-Kommandos dies eigentlich nicht berücksichtigen müßten. Eine Kombination wie ssh/sshd verschlüsselt die Netzverbindung und sorgt je nach Konfiguration für sicherere Authentifizierungen. Dies muß nicht unbedingt für remote login verwendet werden.

4 3.4 FTP FTP (RFC 959) ist ein sehr altes Protokoll zur Übertragung von Dateien zwischen heterogenen Systemen. Es setzt eigentlich voraus, daß sich der Benutzer bei dem Server anmelden kann allerdings gibt es eine anonyme Anmeldung mit entsprechend eingeschränktem Zugriff. 32 Das Protokoll wird über eine TELNET control-verbindung zu Port 21 abgewickelt. Zur Übertragung von Daten wird eine TCP data-verbindung mit Port 20 oder einem explizit vereinbarten Port verwendet. Zur Anpassung zwischen den Systemen können Datentypen (ASCII, IMAGE und LOCAL) und Druckformate (NONPRINT, TELNET und ASA), Dateistrukturen (FILE, RECORD und PAGE) sowie Übertragungsarten (STREAM, BLOCK und COMPRESSED) vereinbart werden, wobei bei den beiden letzteren eine Übertragung auch fortgesetzt werden kann. Praktisch spielt im UNIXund Windows-Bereich nur der Unterschied zwischen ASCII NONPRINT und IMAGE eine Rolle und übertragen wird ein FILE STREAM. Zwar ist das Protokoll dafür entworfen, daß es zwischen Programmen wie ftp/ftpd verwendet wird, aber es enthält keinen portablen Mechanismus, auf dem man die Übertragung von Hierarchien aufbauen kann. Dafür gibt es heute Alternativen wie mirror, rcp, scp und rsync. Die Authentifizierung erfolgt unverschlüsselt durch eine Benutzeridentifikation auf dem Server-System. Zur Adressierung werden Dateinamen verwendet, die der Server verstehen muß. Ein ftp- Klient sorgt normalerweise für eine gewisse Zuordnung von lokalen Namen zu Server-Namen. Prinzipiell könnte der Server Namen abbilden, um virtuelle Hierarchien vorzutäuschen.

5 33 Wesentliche Kommandos und Protokoll-Anweisungen: ftp-klient FTP-Protokoll login USER username anmelden PASS password help HELP Hilfe help command HELP command SYST Server-Identifikation status STAT Transfer-Status STAT path wie LIST, über control-verbindung dir path LIST path Kataloginhalt zeigen, ausführlich ls path NLST path Dateinamen zeigen delete path DELE path Datei löschen rename from to RNFR from-path Datei umbenennen RNTO to-path pwd PWD Arbeitskatalog zeigen cd path CWD path Katalog wechseln mkdir path MKD path Katalog erzeugen rmdir path RMD path Katalog löschen ascii TYPE A N Textübertragung (Voreinstellung) binary TYPE I Datenübertragung PORT h,h,h,h,p,p Port des Klienten für data-verbindung [proxy] PASV Server erzeugt Port für data- Verbindung get remote-path RETR path Datei zum Klienten übertragen put local-path STOR path Datei zum Server übertragen append local-path APPE path an Datei auf Server anfügen [sunique] STOU path Server konstruiert eindeutigen Namen interrupt ABOR Übertragung abbrechen quit QUIT Verbindung beenden Bei den Kommandos wird Groß- und Kleinschreibung nur in den String-Argumenten unterschieden. Die Strings beginnen nach einem Leerzeichen und reichen bis zum Zeilenende, das normalerweise aus return und linefeed besteht; im TELNET-Protokoll können andere Repräsentierungen verhandelt werden.

6 34 $ telnet localhost ftp 220 next FTP server (Version 5.1 (NeXT 1.0) Thu Nov 3, 1994) ready. help 214- The following commands are recognized (* =>'s unimplemented). USER PORT STOR MSAM* RNTO NLST MKD CDUP PASS PASV APPE MRSQ* ABOR SITE XMKD XCUP ACCT* TYPE MLFL* MRCP* DELE SYST RMD STOU SMNT* STRU MAIL* ALLO CWD STAT XRMD SIZE REIN* MODE MSND* REST XCWD HELP PWD MDTM QUIT RETR MSOM* RNFR LIST NOOP XPWD 214 Direct comments to ftp-bugs@next. syst 215 UNIX Type: L8 Version: BSD-43 stat 211- next FTP server status: Version 5.1 (NeXT 1.0) Thu Nov 3, 1994 Connected to localhost Waiting for user name TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: Stream No data connection 211 End of status type i 200 Type set to I. user ftp 331 Guest login ok, send ident as password. pass axel 230 Guest login ok, access restrictions apply. pwd 257 "/" is current directory. stat status of.: total 5 -rw-r--r wheel 379 Feb 26 07:28 README -rw-r--r wheel 0 Oct TIMESTAMP drwxr-xr-x wheel 1024 Sep bin lrwxrwxrwx wheel 3 Nov dev -> etc drwxr-xr-x wheel 1024 Nov etc drwxr-xr-x wheel 1024 Apr 12 06:35 pub drwxr-xr-x wheel 1024 Sep usr 211 End of Status pasv 227 Entering Passive Mode (127,0,0,1,10,249) retr README 150 Opening ASCII mode data connection for README (379 bytes). 226 Transfer complete. quit 221 Goodbye. Der Empfang kann in einer zweiten telnet-session erfolgen: $ telnet localhost `expr 10 \* ` / root directory of axel's ftp server bin/ support programs etc/ support files pub/ things that can be downloaded usr/ support programs

7 3.5 SMTP Im Prinzip ist elektronische Post trivial und uralt: mymail () { # to < body if [ "$1" ]; then { echo From "`whoami` `date '+%a %b %e %H:%M:%S %Y'`" cat echo } >> /var/mail/$1 else echo >&2 usage: mymail to < body return 1 fi } Diese Funktion hängt eine Kopfzeile (signifikant ist From mit einem Leerzeichen und neuerdings das Format des Datums), den Brieftext und eine Leerzeile an eine Datei an, aus der der Empfänger seine Post liest. /usr/bin/mail wird sowohl zum Lesen als auch zum lokalen Schreiben der Briefe verwendet: -r-xr-sr-x 1 root mail Aug 25 18:05 /usr/bin/mail drwxrwxr-x 4 root mail 92 Jan 9 07:05 /var/mail -rw axel mail 0 Jan 9 07:10 /var/mail/axel Das setgid-bit ist nötig, damit ein Benutzer mit mail seine leere Mailbox löschen kann. Zum Schreiben muß mail durch den Empfänger ausgeführt werden; dazu wird ein privilegierteres Programm wie sendmail oder qmail eingeschaltet, das auch zur Verteilung im Netz dient: 35 Schreiber mail Absender konstruiert Sendung, liefert per IPC an Sender. Sender sendmail root überträgt. Empfänger sendmail root übernimmt vom Netz, stellt zu oder vermittelt weiter. Zusteller mail Empfänger liefert Sendung lokal ab. Leser mail Empfänger verwaltet empfangene Sendungen. Die Zustellung ist ein Routing-Problem mit altersbedingt sehr komplizierten Adreßformaten, die in sendmail mit sehr eigenwilligen Techniken analysiert und umformuliert werden. SMTP dient nur zum Dateitransfer zwischen Sender und Empfänger, nicht zum Mail-Routing.

8 36 Wesentliche Protokoll-Anweisungen (RFC 821 und /usr/share/sendmail/helpfile): HELP topic HELO hostname MAIL FROM:<sender> RCPT TO:<empfaenger> DATA RSET QUIT VRFY <adresse> EXPN <adresse> gibt Hilfestellung beschreibt Absender definiert (einen!) Sender definiert je einen Empfänger gefolgt von Text bis Zeile mit Punkt initialisiert neu baut Verbindung ab verifiziert eine Adresse expandiert Adresse, zum Beispiel als Liste Bei den Kommandos wird Groß- und Kleinschreibung nur in den String-Argumenten unterschieden. Die Strings beginnen nach einem Leerzeichen und reichen bis zum Zeilenende, das aus return und linefeed besteht. Der mit DATA übermittelte ASCII-Text unterliegt prinzipiell keinen Regeln, kann aber nach RFC 822 aus einem Umschlag mit Systeminformationen und dem eigentlichen Text bestehen, der dann weiter codiert sein kann (RFC 2045 und folgende). Der Umschlag besteht aus einer Folge von Textzeilen am Anfang, die mit der ersten leeren Zeile abgeschlossen wird. Der Umschlag enthält mindestens Absender und Ziel. Typisch sind: Date: Sende-Datum Return-path: Route zum Absender Received: from Sender by Receiver... ; Datum From: Absender Reply-to: vorrangige Antwort-Adresse To: Ziel-Adresse Subject: Titel Zeilen können durch Einrücken fortgesetzt werden; Kommentare stehen in verschachtelten runden Klammern. SMTP kümmert sich nicht um Authentifizierung diese ist Aufgabe der verbundenen Systeme. SMTP sorgt für eine problemorientierte Adressierung die jedoch erst durch viele zusätzliche Protokolle spezifiziert wird. SMTP kümmert sich selbst nicht um Codierung der Inhalte dies ist eine wichtige Aufgabe für den Umschlag. DATA eignet sich zunächst nur zur Übertragung von Textzeilen. Dabei wird ein führender Punkt vom Klienten verdoppelt, damit der Server das Ende des Kommandos eindeutig erkennen kann.

9 3.6 POP3 Mit dem Post Office Protocol POP (RFC 1939) soll ein Klient Briefe von einem Server abholen: 37 Die Architektur geht von einem einzigen Briefkasten pro Benutzer auf dem Server aus und erlaubt nur eine synchrone Verwaltung der Briefe (abholen, löschen), die insbesondere nicht vorsieht, daß neu ankommende Briefe entdeckt werden. Ähnlich wie FTP hat das Protokoll Zustände: Es gibt folgende Kommandos: Zustand +OK -ERR USER name A,A1 A1 A wählt Briefkasten PASS password A1 T A authentifiziert APOP name string A T A wählt Briefkasten und authentifiziert STAT T T - liefert Anzahl Briefe und Anzahl Zeichen LIST T T T liefert Briefnummer und Zeichen per Brief LIST m T T T liefert Briefnummer m und Anzahl Zeichen UIDL [m] T T T ähnlich, liefert persistente unique id RETR m T T T liefert Brief m DELE m T T T markiert Brief als gelöscht (nicht mehrfach!) NOOP T T - keine Operation, unterbricht Zeitschranke RSET T T - markiert alle Briefe als ungelöscht QUIT A,A1 exit - beendet Zugriff QUIT T U,exit U,exit beendet Zugriff, löscht wenn möglich TOP m n T T T liefert Header plus n Zeilen Bei den Kommandos wird Groß- und Kleinschreibung nur in den String-Argumenten unterschieden. Die Strings beginnen nach einem Leerzeichen und reichen bis zum Zeilenende, das aus return und linefeed besteht. POP3 kümmert sich um Authentifizierung diese kann auch verschlüsselt erfolgen. POP3 realisiert benutzerfreundliche Namen für die Briefkästen und sorgt für eine triviale, eigentlich nicht persistente Adressierung der Briefe. POP3 kümmert sich wie SMTP selbst nicht um Codierung der Inhalte. RETR und andere Kommandos mit multi-line Antworten eignen sich zunächst nur zur Übertragung von Textzeilen. Dabei wird ein führender Punkt vom Server verdoppelt, damit der Klient das Ende der Antwort eine Zeile mit einem Punkt eindeutig erkennen kann. POP3 eignet sich für interaktive Leseprogramme ebenso wie für reine Modem-Transfers. Der wesentliche Haken ist die Einschränkung, daß neu ankommende Briefe nicht eingeschleust werden können und daß bei Abbruch der Verbindung mindestens 10 Minuten gewartet wird, bevor der Biefkasten erneut für POP3 zugänglich ist.

10 3.7 IMAP4rev1 Das Internet Message Access Protocol IMAP (RFC 2060) umgeht einige der Einschränkungen von POP3 und integriert gleichzeitig Zugriff auf news, ist aber ungleich komplizierter. Wie POP3 ist es zustandsorientiert mit einem weiteren Zustand für eine gewählte Mailbox und enthält Authentifizierung. Anders als POP3 stellt es Briefkästen (folder) nahezu als attributiertes Dateisystem mit persistenten Namen dar und erlaubt parallele Zugriffe, die asynchron also nicht im Dialog- Stil bearbeitet werden. Anders als bei POP3 gibt es eine ausgefeilte Kommando-Syntax, wahlweise mit temporären und persistenten Adressen und mit Strings, in denen vor Text-Daten jeweils die Anzahl Zeichen steht. Anders als bei NFS orientieren sich IMAP Kommandos an der Verarbeitung von Post und news: Kommando Zustand Antwort (vor tag OK) CAPABILITY any CAPABILITY Fähigkeiten NOOP any alive LOGOUT any BYE beenden LOGIN user password non-auth anmelden AUTHENTICATE how non-auth dialog...verschlüsselt SELECT mailbox auth FLAGS, EXISTS, RECENT öffnen EXAMINE mailbox auth FLAGS, EXISTS, RECENT...zum Lesen CREATE mailbox auth erzeugen DELETE mailbox auth löschen RENAME from to auth umbenennen SUBSCRIBE mailbox auth registrieren UNSUBSCRIBE mailbox auth...für LSUB LIST where pattern auth LIST.. existente Boxen LSUB where pattern auth LSUB.. registrierte Boxen STATUS mailbox what.. auth STATUS.. Zustand APPEND mailbox message auth Brief anfügen CHECK selected Checkpoint CLOSE selected schließen, löschen EXPUNGE selected EXPUNGE.. löschen SEARCH keys UID SEARCH keys selected SEARCH strukturiert suchen per unique id FETCH messages item.. UID FETCH messages item.. selected FETCH Brief(-teile) holen per unique id STORE messages flag value UID STORE messages flag value selected FETCH Flaggen ändern per unique id COPY messages mailbox UID COPY messages mailbox selected Briefe kopieren per unique id 38

11 Die Kommandos werden möglicherweise mit mehreren Nachrichten beantwortet: tag OK text Kommando erfolgreich abgeschlossen * OK [code] text Information tag NO text Kommando erfolglos abgeschlossen * NO [code] text Warnung tag BAD text Fehler im Kommando * BAD [code] text unerwarteter Fehler * PREAUTH [code] text Begrüßung, wenn schon authentifiziert * BYE [code] text Verbindung wird beendet * CAPABILITY IMAP4rev1.. liefert Fähigkeiten als key=value Paare * LIST (attributes) "/" path beschreiben Boxen, mit Hierarchie-Trenner und Pfad * LSUB (attributes) "/" path * STATUS mailbox (status) beschreibt Zustand der Box * SEARCH number.. liefert Nummern passender Briefe * FLAGS (flag names) liefert mögliche Flaggen * count EXISTS liefert Anzahl Briefe, auch nach Änderung * count RECENT liefert Anzahl ungelesener Briefe, auch später * number EXPUNGE liefert Nummer eines gelöschten Briefs, ändert Nummern * FETCH (item value..) liefert Attribute auch Inhalt eines Briefs + text verlangt mehr Information, z.b. für AUTHENTICATE Ein Kommando beginnt mit einem eindeutigen Etikett, das der Klient erzeugt. Die letzte Antwort verwendet das gleiche Etikett. Da Kommandos und Antworten häufig asynchron erfolgen wobei es Einschränkungen gibt kann der Server von sich aus Nachrichten einfügen. IMAP leidet wohl ein bißchen unter dem second system syndrome es versucht, Post und news zu integrieren und leistet die Arbeit mehrerer Schichten (asynchroner Transfer und Inhaltsstruktur) gleichzeitig. 39

12 Zum Vergleich: Dateisystem-Protokolle NFS und 9P Das Network File System Protokoll NFS (RFC 1813) beruht, wie sein MOUNT Protokoll, auf dem Remote Procedure Call Protokoll RPC (RFC 1057) und kann wahlweise über TCP oder UDP transportiert werden. Man kann die Prozeduren als Kommandos ansehen, die im Gegensatz zu IMAP als Prozeduraufrufe synchron sind. Mit MOUNT erhält man einen Filehandle für die Wurzel einer Dateihierarchie: MNT pfad liefert einen Filehandle für pfad und trägt in the mount-liste ein. UMNT pfad entfernt pfad aus der mount-liste. UMTALL entfernt alle Einträge des Klienten aus der mount-liste. DUMP liefert die mount-liste, die allerdings nicht stimmen muß. EXPORT zeigt, welche Kataloge für welche Klienten für MNT verfügbar sind. Mit NFS kann man dann Dateien manipulieren eine Auswahl von Kommandos: LOOKUP liefert einen Filehandle für einen Dateinamen relativ zu einem Filehandle. GETATTR liefert Information über einen Filehandle. SETATTR ändert einen Teil der Information über einen Filehandle. READ liefert eine Anzahl Bytes ab einer Position von einem Filehandle. WRITE schreibt eine Anzahl Bytes ab einer Position zu einem Filehandle. CREATE erzeugt eine neue Datei für einen Dateinamen relativ zu einem Filehandle, liefert einen Filehandle. LINK erzeugt einen Link zu einem Filehandle für einen Dateinamen relativ zu einem Filehandle. REMOVE löscht einen Dateinamen relativ zu einem Filehandle. RENAME benennt einen Dateinamen relativ zu einem Filehandle um in einen Dateinamen relativ zu einem Filehandle. SYMLINK erzeugt einen symbolischen Link mit einem Pfad für einen Dateinamen relativ zu einem Filehandle. READLINK liefert den Pfad des symbolischen Links aus einem Filehandle. MKDIR erzeugt einen neuen Katalog für einen Dateinamen relativ zu einem Filehandle, liefert einen Filehandle. RMDIR löscht einen leeren Katalog für einen Dateinamen relativ zu einem Filehandle. READDIR liefert Katalogeinträge ab einer Position von einem Filehandle. STATFS liefert Information über das Dateisystem das einen Filehandle enthält. Prinzipiell könnte man eine Mailbox als Katalog mit Katalogen für Briefe auffassen. Ein Brief (Katalog) müßte Dateien für Umschlag und Inhalt enthalten. MOUNT dient dann zur Wahl einer Mailbox und mit NFS bearbeitet man den Inhalt. 40

13 Die Betriebssysteme Plan 9 und Inferno beruhen auf zwei einander sehr ähnlichen Dateisystem-Protokollen 9P und Styx, die als Transport-Protokolle das neue Internet Link Protokoll IL oder TCP verwenden. Im Gegensatz zu IMAP erfolgt auf jede Anfrage genau eine Antwort, aber wie bei IMAP werden Anfragen und Antworten mit Etiketten verknüpft. Styx: Tnop 0xffff Rnop 0xffff Tflush tag oldtag Rflush tag Rerror tag text der Klient untersucht, ob er mit dem Server kommunizieren kann. der Klient erklärt dem Server, daß er oldtag nicht mehr beantworten soll. der Server erklärt dem Klienten, daß er tag nicht beantworten kann. Tattach tag fid uid aname Rattach tag fid qid der Klient möchte für den Benutzernamen uid auf die Wurzel aname unter der Bezeichnung fid zugreifen. Der Server ist einverstanden; qid ist seine eindeutige Bezeichnung für fid. Tclone tag fid newfid Rclone tag fid der Klient möchte, daß die Bezeichnung newfid äquivalent zu fid ist. Tclunk tag fid Rclunk tag fid Tremove tag fid Rremove tag fid der Klient möchte, daß die Bezeichnung fid ungültig ist. der Klient läßt fid entfernen; anschließend ist fid ungültig. Twalk tag fid name Rwalk tag fid qid der Klient sucht im Katalog fid nach name. Bei Erfolg hat der Server dafür die eindeutige Bezeichnung qid. Topen tag fid mode Ropen tag fid qid der Klient möchte auf fid einen durch mode beschriebenen Zugriff. Tcreate tag fid name perm mode Rcreate tag fid qid der Klient möchte im Katalog fid unter dem Namen name und mit Zugriffsschutz perm eine neue Datei erzeugen und auf sie mit mode zugreifen. Tread tag fid offset count Rread tag fid count pad data der Klient möchte aus fid ab Position offset bis zu count Bytes lesen. Für Kataloge werden Einträge im Format von Rstat mit 116 Bytes per Eintrag geliefert. Twrite tag fid offset count pad data Rwrite tag fid count der Klient möchte in die Datei fid ab Position offset (oder auch ans Ende bei append) count Bytes schreiben. Tstat tag fid Rstat tag fid name uid gid qid mode atime mtime length type dev der Klient erhält Informationen über fid. Sie ist ab name 116 Bytes lang. Twstat tag fid name uid gid qid mode atime mtime length type dev Rwstat tag fid der Klient ändert einen Teil der Informationen für fid insbesondere name und Teile von mode, aber keinesfalls uid und gid nicht immer. 41

14 3.8 HTTP Im Ansatz war das Hypertext Transfer Protokoll HTTP (RFC 2616) ein sehr vereinfachtes Protokoll zur Übertragung genau einer binären Datei, wobei es dem Empfänger überlassen blieb, den Inhalt anhand des Dateinamens zu interpretieren. Ähnlich wie bei SMTP wurde mit einem MIME-Umschlag (RFC 2045 und folgende) dann eine Inhaltsbeschreibung hinzugefügt, die anders als bei FTP auch Verhandlungen über Inhalte (Sprache, Dateiformat) zuläßt. Die Header dienen auch zur Authentifizierung. Schließlich wurden Server-seitig durch Überladen von Dateinamen Mechanismen zur dynamischen Erzeugung von Inhalten eingeführt, die von den HTML-Forms interaktiv benützt werden. HTTP hat heute den Anspruch, ein sehr allgemeines Protokoll zur Dateiübertragung zu sein. Eine Anfrage besteht aus einer Request-Zeile, einem Umschlag und gegebenenfalls auch einem Inhalt. Codiert wird ähnlich wie bei SMTP. Ein Zeilenende sollte, wie üblich, aus return und linefeed bestehen. Die Request-Zeile enthält Methode, Adresse und HTTP-Version, getrennt durch einzelne Leerzeichen: GET /index.html HTTP/1.1 Als Adresse bezieht sich * auf den Server; andere Adressen sind entweder komplette URIs mit Protokoll oder absolute Pfade mit / als Trenner. Es gibt folgende Methoden: OPTIONS liefert Fähigkeiten des Servers bezüglich einer Ressource GET liefert eine Ressource HEAD liefert die Beschreibung einer Ressource POST soll etwas zu einer Ressource hinzufügen PUT ändert eine Ressource oder speichert eine neue Ressource DELETE soll eine Ressource löschen TRACE liefert den Ablauf einer Anfrage zwecks Fehlersuche Eine Antwort besteht aus einer Status-Zeile, einem Umschlag und gegebenenfalls einem Inhalt. Die Status-Zeile enthält HTTP-Version, Status-Code im Stil von FTP, und eine Bemerkung, getrennt durch einzelne Leerzeichen: HTTP/ ok Im Umschlag können sehr viele Header sein. Besonders wesentlich sind: Accept: text/html ; q=0.8 Connection: close Content-Type: text/html Date: datum Expires: datum Host: If-Modified-Since: datum Last-Modified: datum Location: uri Range: bereich Update: SHTTP/ dient zu Verhandlungen über das Dateiformat der Antwort. Ähnliche Header verhandeln über Sprache, Zeichensatz und Codierungen. schließt die Verbindung. beschreibt den Inhalt. Ähnliche Header beschreiben Sprache, Codierung und Länge. beschreibt, wann die Antwort erzeugt wurde. beschreibt, wie lange der Inhalt gültig ist. unterscheidet mehrere virtuelle Server auf einem Rechner unterdrückt Transfer alter Dateien. (Viele ähnliche Header) beschreibt, wann der Inhalt zuletzt modifiziert wurde. erlaubt eine Umlenkung. erlaubt Übertragung von Teilen einer Ressource. erlaubt Umschaltung des Protokolls auf der Verbindung.

15 43

16 44