*ACHTUNG* !VERALTET! *ACHTUNG* Definition eines Protokolls für asynchronen Filetransfer im Internet und Referenzimplementierung für Unix Ulli Horlacher Allmandring 30 Rechenzentrum Universität Stuttgart framstag@rus.uni-stuttgart.de 5. März 1996 : Kurzbeschreibung SAFT (Simple Asynchronous File Transfer) ist ein neues Internet-Protokoll, das es erlaubt, Dateien und Nachrichten asynchron zu verschicken, d.h. ohne daß es notwendig ist, sich beim Empfängersystem einzuloggen. Als Referenzimplementation wurden ein sendfile-Client (ver- schickt Dateien), ein sendmsg-Client (verschickt einzeilige Nachrichten), ein receive-Client (empfängt Dateien aus dem sendfile-spool) und ein sendfiled-Server (empfängt Dateien und Nachrichten und verteilt sie weiter) geschrieben. INHALT 1 Definition des asynchronen Dateitransfers und Abgrenzung gegenüber existierenden Diensten 4 1.1 Filetransfer im Bitnet 4 1.2 Das SIFT/UFT Protokoll 5 1.3 Das SAFT Protokoll 5 1.3.1 Beispiele 10 1.3.2 Begründung des Protokolldesigns 12 2 sendfile: eine SAFT Referenzimplementation für Unix 14 2.1 Programmbeschreibung 14 2.1.1 sendfiled 14 2.1.2 sendfile 16 2.1.3 sendmsg 18 2.1.4 receive 18 2.2 Benutzerkonfigurationsdateien 20 2.3 Installation 21 2.4 Sourcen 23 2.4.1 Aufrufdiagramm 26 2.4.2 Datenstrukturen 27 3 Danksagungen 30 4 Informationsverzeichnis 31 5 Glossar 32 1 Definition des asynchronen Dateitransfers und Abgrenzung gegenüber existierenden Diensten Bei einem asynchronen Filetransfer werden Dateien von einem Sender an einen Empfän- ger geschickt, ohne daß letzterer aktiv an der Übertragung teilnehmen muß. E-mail ist z.B. ein asynchroner Dienst, während ftp einen synchronen Dienst darstellt. Asynchronen Filetransfer gab es bisher im Internet nicht. Wollte ein Benutzer A einem beliebigen Benutzer B eine Datei zukommen lassen, hatte er bisher nur folgende wenig brauchbare Möglichkeiten: · ftp [13] zum Empfängeraccount Dazu muß das Paßwort des Empfängeraccounts bekannt sein. Wenn A und B nicht physisch identisch sind, ist diese Methode sicherheitstechnisch indiskutabel. Aber auch wenn es sich bei A und B um dieselbe Person handelt, so wandert doch das Paß- wort als Klartext in einem tcp-Päckchen durchs Internet. · ftp über einen anonymous ftp Server Die Datei muß von A auf den anonymous ftp Server mittels ftp übertragen werden, A muß B mit einer e-mail informieren, daß dieser die Datei abholen kann und B muß dann ebenfalls ftp aufrufen. Als Nebenbedingung muß ein ftp Server gefunden wer- den, der von beiden gut erreicht werden kann und dieser Server muß ein allgemein schreibbares Verzeichnis aufweisen. Während die Datei auf dem anonymous ftp Ser- ver liegt, kann sie aber praktisch von jedermann gelesen, gelöscht oder verändert wer- den. · verschicken via e-mail Die Datei wird von A an B als e-mail geschickt. Nach RFC 822 darf eine e-mail nur Zeichen aus dem NVT-ASCII Zeichensatz enthalten, welcher eine Untermenge von 7 bit ASCII ist. Somit ist der Dateientransfer auf englische Textdokumente beschränkt, wenn man nicht die zu verschickende Datei entsprechend kodiert, so daß sie nur noch NVT-ASCII Zeichen enthält. Als Kodierung bieten sich an: uuencode oder MIME [16]. Beide sind aber umständlich zu handhaben, unterstützen nicht alle Dateiattribute und vergrößern zwangsläufig die zu übertragende Datenmenge. Zudem sind die real existierenden Mailsysteme nicht in der Lage, mit größeren Übertragungen fertig zu werden. 1.1 Filetransfer im Bitnet Im Bitnet gibt es einen asynchronen Filetransferdienst. Dieser wurde als Vorbild genom- men und auf das Internet abgebildet, wobei die Funktionalität wesentlich erweitert wurde. Tatsächlich basieren sämtliche Bitnetdienste auf asynchronen Filetransfers. Bitnet erlaubt aufgrund von IBM-internen Restriktionen nur Dateinamen mit 8 Byte und 8 Byte Extension, Zeilenlängen von maximal 80 Byte und EBCDIC bzw. 7 bit ASCII als Zeichensatz. 1.2 Das SIFT/UFT Protokoll In der Vorbereitungsphase wurde das SIFT/UFT (Sender-Initiated/Unsolicited File Transfer) Protokoll aka RFC 1440 gefunden [15] , welches ebenfalls einen asynchro- nen Filetransferdienst für das Internet beschreibt. Dieses Protokoll hat den ,Experi- mental" Status und enthält noch einige Fehler bzw. Inkonsistenzen. Außerdem ist es stark an IBMs VM Betriebssystem angelehnt, da es ausschliesslich dessen Dateitypen unterstützt. Es wurde versucht, mit dem Author (Rick Troth, troth@compassnet.com) e-mail Kon- takt aufzunehmen. Leider lagen seine Antwortzeiten im Schnitt bei ca. 2 Wochen, so daß eine sinnvolle Diskussion mit ihm nicht möglich war. SIFT/UFT weist folgende Mängel auf: · der Zeichensatz des Protokolls ist nicht spezifiziert · als Dateitypen sind nur propritäre VM-Files vorgesehen · das Datumformat ist nicht spezifiziert · die Zeichensätze der Dateien sind nicht spezifiziert · Designfehler in der DATA-Anweisung: ein String ,EOF" in der zu übertragenden Datei führt zum Abbruch der Übertragung · die Return Codes des Servers sind nicht spezifiziert · Rick Troth ist anscheinend der einzige, der SIFT/UFT real benutzt; es ist nur ein einziger Server bekannt (ua1vm.ua.edu), der nicht mal selber RFC 1440 konform ist Somit war eine Projektrealisation auf Basis von SIFT/UFT nicht möglich und es mußte ein eigenes Protokoll entwickelt werden. 1.3 Das SAFT Protokoll Als Grundlage für den asynchronen Filetransfer wurde das SAFT-Protokoll entwik- kelt: Simple Asynchronous File Transfer Wesentliche Merkmale sind: · Betriebssystemunabhängigkeit SAFT soll auf möglichst allen Computersystemen im Internet verfügbar sein. · Einfachheit ,keep it simple": ein überschaubares Protokoll auf ASCII-Basis, so daß es leicht mit telnet auf den Serverport zu debuggen ist. · Erweiterbarkeit spätere Erweiterungen sollen keine künstlichen Grenzen behindern. Als abschrecken- des Beispiel sei die 7 Bit Beschränkung von smtp / RFC 822 genannt. Quasi als ,Abfallprodukt" wurden noch asynchrone Nachrichten (,messages") als weite- rer Internetdienst integriert. Bei solch einer Nachricht handelt es sich um einen einzeiligen Text, der normalerweise direkt auf das Terminal des Empfängers geschrieben wird. SAFT ist ein Client/Server-Protokoll. Der SAFT-Client, typischerweise ein Userpro- gramm, verschickt Dateien oder Nachrichten via Internet an den SAFT-Server, welcher sie entgegennimmt und an den lokalen Adressaten direkt ausliefert oder in einem Spoolbe- reich zwischenlagert, wo sie dann der Adressat mittels eines Receive-Clients abholen kann. Die Funktionsweise ist ähnlich wie bei normaler Internet-mail. Der Spooling-Mechanismus und der Receive-Client werden nicht von SAFT beschrieben, sondern bleiben der jeweiligen Implementation überlassen. SAFT definiert nur das reine Übertragungsprotokoll. SAFT unterstützt folgende Dateiattribute: · Dateiname in Unicode [19] mit beliebiger Länge · Zeitstempel Spezifikation nach ISO-8601 [7] (UTC full date & time) · BINARY unstrukturierter Bytestrom · SOURCE Datei besteht aus einzelnen Zeilen jeweils beliebiger Länge mit CR/LF als EOL Mar- kierung · TEXT wie Source, nur daß zusätzlich das Attribut CHARSET (siehe unten) ausgewertet wird · Name des Zeichensatzes Spezifikation nach RFC 1345 [14] · Betriebssystemspezifische Attribute Diese können bei der ersten SAFT-Implementation für das jeweilige Betriebssystem vom Autor beliebig verwendet werden. Kompatibilität ist dabei aus prinzipiellen Gründen nur zwischen Client und Server desselben Betriebssystems gewährleistet. SAFT kann Dateien mittels gzip Algorithmus komprimiert übertragen. Dieses stellt kein Dateiattribut sondern ein Übertragungsmerkmal dar. Für den Sender und Empfänger geschieht dies völlig transparent. Diese Komprimierung wurde eingeführt, um Netzband- breite zu schonen. Der Flaschenhals eines Filetransfers stellt in der Regel das Netz dar und nicht die Leistungsfähigkeit der lokalen CPU. SAFT benutzt tcp als Transportmedium und den tcp-Port 487. Der SAFT-Client stellt eine Verbindung zu diesem Port auf dem Host des SAFT-Servers her. Die Client/Server Kommunikation ist zweigeteilt, sie setzt sich aus dem eigentlichen Kommunikationsprotokoll und der zu übertragenden Datei als ,data-stream" zusam- men. Das Kommunikationsprotokoll ist NVT-konform, also 7 bit ASCII ohne Steuerzeichen und CR/LF (ASCII 13 und ASCII 10) als EOL Markierung. HT (ASCII 9) ist zwar zulässig, sollte aber vermieden werden. Ein Kommando vom Client besteht aus einer Zeile, die ein Befehlswort und je nach Bedarf ein oder mehrere Parameter enthält, getrennt durch Whitespace. Ein White- space ist eine nicht-Null Zeichenfolge aus SPACE (ASCII 32) oder HT (ASCII 9) in beliebiger Reihenfolge. Nach Möglichkeit sollte immer ein einzelnes SPACE als Whitespace verwendet werden. Als Kommandos sind definiert: · FROM [] Absender Loginname und optional echter Name und pgp Signatur. · TO Empfänger Loginname · FILE Name der zu übertragenden Datei · DATE Zeitstempel der Datei in UTC ISO-8601 Format (YYYY:MM:DD hh:mm:ss) · TYPE BINARY|SOURCE|TEXT [COMPRESSED] Typ der Datei. · CHARSET Name des Zeichensatzes einer Textdatei nach RFC 1345 (&charset Eintrag) . Ali- ase sind nicht erlaubt. Wenn möglich sollte ISO_8859-1:1987 verwendet werden. · ATTR Betriebssystemspezifische Dateiattributerweiterung, implementationsabhängig. · MSG Einzeilige Nachricht, die direkt auf das Terminal des Empfängers ausgegeben werden soll. · DEL Datei, die zuvor übertragen wurde, wird gelöscht. · RESEND Die Datei soll nach vorhergehenden Übertragungsabbruch erneut geschickt werden. Die Serverantwort enthält als erster String die Anzahl der bereits übertragenen Bytes: · SIZE Größe der zu übertragenden Datei in Bytes: die erste Zahl stellt die tatsächlich zu übertragenden Bytes dar, die zweite die Größe der Datei nach der Dekomprimierung. · DATA Ab hier folgen - Bytes der Datei als aufeinanderfolgender Strom von 8-bit Bytes. · QUIT Ende der Verbindung Die Befehlswörter können in Groß- oder Kleinbuchstaben oder sogar gemischt geschrie- ben werden. FROM, from oder FrOm sind gleichbedeutend. Nach Möglichkeit sollten alle Befehlswörter aber einheitlich in Großbuchstaben geschrieben werden. , , , und sind UTF-7 [20] kodierte Strings. Nach Möglichkeit sollten hier nur NVT-ASCII oder ISO Latin-1 Zeichen [14] enthalten sein. Zur Übertragung einer Datei müssen mindestens die Kommandos FROM, TO, FILE und SIZE angegeben werden. DATA startet dann den eigentlichen Transfer. Die anderen Kommandos sind optional. Die Reihenfolge der Kommandos spielt im Allgemeinen keine Rolle. Ausnahme sind (Format: Kommando (Kommandos, die vorhergehen müssen)): · DATA ( FROM, TO, FILE , SIZE ) · MSG ( FROM , TO ) · RESEND ( FROM, TO, FILE ) · DEL ( FROM, TO, FILE, DATE, SIZE ) Jedes dieser Kommandos wird vom Server mit einer sogenannten ,reply-message" beant- wortet, die folgendermaßen aufgebaut ist: Antwort = {reply-line} reply-end reply-line = reply-code "-" text reply-end = reply-code " " text reply-code = number number number number = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" text = char {char} CR LF char = CR ist ASCII 13, LF ist ASCII 10. Die erste Ziffer (number) des reply-code gibt Aus- kunft über die Kategorie der Antwort: · 2 steht für: korrekte Kommandodurchführung · 3 steht für: weitere Daten/Informationen werden benötigt · 4 steht für: fataler Fehler mit anschliessendem Verbindungsabbruch · 5 steht für: sonstiger Fehler, der aber durch weitere Kommandos wieder behebbar ist Definiert sind folgende ,reply-messages": · 200 Command o.k.. · 201 File has been correctly received. · 202 Command not implemented, superfluous at this site. · 205 Non-ASCII character in command line ignored. · 214 · 220 SAFT server (sendfiled on ) ready. · 221 Goodbye. · 230 Bytes already received. · 302 Header ok, send data. · 410 Spool directory does not exist. · 411 Can`t create user spool directory. · 412 Can`t write to user spool directory. · 415 TCP error: received too few data. · 421 Service not available. · 451 Requested action aborted: local error in processing. · 452 Insufficient storage space. · 453 Insufficient system resources. · 500 Syntax error, command unrecognized. · 501 Syntax error in parameters or arguments. · 502 Command not implemented. · 503 Bad sequence of commands. · 504 Command not implemented for that parameter. · 505 Missing argument. · 510 This SAFT-server can only receive messages. Send files to xx@yy · 511 This SAFT-server can only receive files. · 520 User unkown. · 521 User is not allowed to receive files or messages. · 522 User cannot receive messages. · 523 You are not allowed to send to this user. · 530 User cannot receive messages. · 531 This file has been already received. · 599 Unknown error. Nur die aus 3 Ziffern bestehende Replycodes sind fest vergeben, die Texte dahinter kön- nen beliebig verändert werden, solange sie weiterhin dem Sinn der Meldung entsprechen. Ausnahmen hiervon sind die Texte zu den Replycodes 220 und 230: bei 220 muß der String , SAFT " enthalten sein und bei 230 muß das erste Wort im Text die Anzahl der bereits übertragenen Bytes sein. 1.3.1 Beispiele Beispiele einer SAFT-Session anhand eines direkten telnet Zugriffs auf den Serverport (fett gedruckte Textteile sind Benutzereingaben): > telnet linux saft Trying 129.69.58.50... Connected to linux.rus.uni-stuttgart.de. Escape character is '^]'. 220 linux SAFT server (sendfiled 1.4 on Linux) ready. FROM gaga 200 Command ok. TO framstag 200 Command ok. FILE blubb 200 Command ok. SIZE 5 5 200 Command ok. DATA 302 Header ok, send data. ABC 201 File has been correctly received. QUIT 221 Goodbye. Connection closed by foreign host. > telnet linux saft Trying 129.69.58.50... Connected to linux.rus.uni-stuttgart.de. Escape character is '^]'. 220 linux SAFT server (sendfiled 1.4 on Linux) ready. HELP 214-The following commands are recognized: 214- FROM [] [] 214- TO 214- FILE 214- SIZE 214- TYPE BINARY|SOURCE|TEXT [COMPRESSED] 214- DATE 214- CHARSET 214- ATTR TAR|EXE|NONE 214- MSG 214- DEL 214- RESEND 214- DATA 214- QUIT 214-All argument strings have to be UTF-7 encoded. 214 You must specify at least FROM, TO, FILE, SIZE and DATA to send a file. FROM gaga 200 Command ok. TO dengibtsnicht 520 User unkown. TO framstag 200 Command ok. MSG huhu! 530 User cannot receive messages. TYPE TEXT 200 Command ok. FILE x1 200 Command ok. SIZE 6 6 200 Command ok. abcd 500 Syntax error, command unrecognized. DATA 302 Header ok, send data. abcd 201 File has been correctly received. FILE x2 200 Command ok. SIZE 3 3 200 Command ok. SIZE 5 5 200 Command ok. DATA 302 Header ok, send data. 123 201 File has been correctly received. QUIT 221 Goodbye. Connection closed by foreign host. Eine Anmerkung zur anscheinenden Diskrepanz bei SIZE und DATA: telnet überträgt eine Zeile mit CR LF als EOL-Markierung. Diese Bytes zählen natürlich mit. 1.3.2 Begründung des Protokolldesigns Die Ablehnung von SIFT/UFT wurde bereits weiter oben besprochen. Als weitere bereits existierende Alternativen wurden untersucht: · http Das Hyper Text Transfer Protocol [12] ist zu sehr spezialisiert auf Dokumente mit ,festem Platz". Es geht davon aus, daß Dateien immer unter derselben Adresse anzu- finden sind. Außerdem kann man mit der derzeitigen http Spezifikation Dateien nur holen, nicht aber verschicken. · fsp Das File Service Protocol kennt nur einen anonymous User und keine realen Benutzer als Adressaten. Zudem benutzt es udp als Transportmedium, was es zwar sehr sicher gegenüber Netzproblemen aber auch recht langsam macht. · smtp mit MIME Das Simple Mail Transport Protocol mit Multipurpose Internet Mail Extensions [11] [16] [17] ist zwar das flexibelste Transportprotokoll für Dokumente aller Art, aber lei- der auch eins der ineffektivsten was den Datendurchsatz angeht und Aufgrund der 7 bit Restriktion von smtp am schwersten zu implementieren. Dies verdeutlicht die Tat- sache, daß es selbst Jahre nach der Einführung von MIME noch keinen brauchbaren freien MUA für Unix oder VMS gibt. Als große Probleme stellten sich die Wahl des Zeichensatzes für Textdateien und das For- mat der Dateinamen heraus. Für beide liessen sich keine gemeinsame Basis finden, die allen Betriebssystemen im Internet gerecht werden würde. Der einzige Zeichensatz, der eine echte Obermenge aller anderen Zeichensätze ist, ist ISO-10646 aka Unicode [9] [10] [19]. Unicode basiert aber auf 16 bit breiten Zeichen und hat noch keine nennenswerte Verbreitung gefunden. Deshalb erlaubt SAFT die Verwen- dung eines beliebigen in RFC 1345 definierten Zeichensatzes und überläßt die korrekte Konvertierung der Empfängerseite. Empfohlen wird jedoch die Verwendung von ISO- 8859-1 aka ISO Latin 1 [14], da dies von der Anzahl der Benutzer und installierten Systeme her führend ist. Beim Format des Dateinamens stellt sich ein ähnliches Dilemma. Stellvertretend seien hier einige verbreitete Betriebssysteme bzw. Filesysteme genannt: · DOS 8+3 Zeichen; alle Zeichen bis auf . und \ · VM und MVS 8+8 Zeichen; A..Z 0..9 · VMS/RMS 39+39 Zeichen; A..Z 0..9 $ _ - ; $ - nicht am Anfang; Versionsnummern · Unix < SysV 4.0 14 Zeichen; alle Zeichen bis auf ASCII(0) und / · Unix >= SysV 4.0 und BSD 255 Zeichen; alle Zeichen bis auf ASCII(0) und / · Windows NT 255 Zeichen; alle Unicodezeichen (?) Ein kleinster gemeinsamer Nenner ließ sich hier nicht bilden. Deshalb erlaubt SAFT bei Dateinamen die Verwendung von Unicodezeichen und beliebige Länge. Der Client kann aber nicht sicher sein, daß der Dateiname auf dem Empfängersystem verarbeitet werden kann. Deshalb sollten bei Unkenntnis der Möglichkeiten des Empfängersy- stems eher konservative Werte benutzt werden. Der Flaschenhals bei praktisch jeder Kommunikation im Internet stellt die zur Verfü- gung stehende Bandbreite dar. Deshalb kann SAFT Dateien mittels gzip Algorithmus komprimiert übertragen. gzip wurde ausgewählt, weil es · lizenzfrei ist (GNU Copyleft) · sehr gute Kompressionsraten liefert · auf praktisch allen Betriebssystemen verfügbar ist · einen Quasistandard im Internet darstellt Viele Betriebssysteme bieten weitere Dateiattribute, als die von SAFT abgedeckten an. Diese Attribute sind aber Filesystem-proprietär und nicht zwischen verschiedenen Betriebssystemen konvertierbar. VMS/RMS kann z.B. nichts mit dem Hidden-bit von DOS/FAT anfangen, während wiederum auf allen anderen Betriebssystemen die FDL von VMS/RMS keinen Sinn macht. Deshalb wurde das ATTR Kommando eingeführt, welches nur für das jeweilige Betriebssystem von Relevanz ist. Jeder Autor einer neuen SAFT Implementation kann das ATTR Kommando für sein Betriebssystem erweitern, indem er neue Parameter einführt (siehe Kapitel sendfile weiter unten). Er sollte dies jedoch dokumentieren und dem Autor von SAFT zwecks Koordination melden. Die Verwendung von MIME [16] [17] zur Spezifizierung von Dateiattributen wurde verworfen, weil MIME Dokumente beschreibt, die visualisiert werden sollen. Hierbei wird der Inhalt einer Datei meist einer nicht reversiblen Transformation unterworfen, was in Hinblick auf die eigentliche Aufgabenstellung nicht wünschenswert ist. 2 sendfile: eine SAFT Referenzimplementation für Unix Das sendfile Paket ist eine Umsetzung des SAFT Protokolls für Unix-Systeme und umfaßt die Teile: · sendfiled der sendfile daemon, ein SAFT-Server · sendfile ein SAFT-Client zum Verschicken von Dateien · sendmsg ein SAFT-Client zum Verschicken von Nachrichten · receive ein Client, der bereits empfangene Dateien aus dem lokalen Spool abholt · Utilities: - check_sendfile: informiert beim login auf files im sendfile-Spool - sf_cleanup: räumt alte Files aus dem Spool · Dokumentation: - man-pages: Hilfetexte im Standard-Unix-Format - LIESMICHe bzw. READMEs: Kurze Hilfetext für schnelle Information - doku.ps bzw. doc.ps: dieses Dokument Der sendfile-Client ist ein Userprogramm, das Dateien an den sendfiled verschickt, wel- cher sich auf demselben Host befinden kann oder sonst irgendwo im Internet. Der sendfi- led nimmt die Dateien entgegen, legt sie im Spoolbereich ab und informiert den Empfänger mit einer Nachricht, die direkt auf sein Terminal geschrieben wird. Der Emp- fänger kann sich dann die Dateien mittels des receive-Clients in sein Directory kopieren, wobei das Original im Spool gelöscht wird. Der sendmsg-Client ist ein Userprogramm, das einzeilige Textnachrichten an den sendfiled verschickt, welcher sie dann direkt auf das Terminal des Empfängers schreibt. Das sendfile-Paket setzt voraus, daß die Programme gzip, tar und GNU-recode (letzteres optional) bereits installiert sind und zur Installation der gcc-Compiler vorhanden ist. Ver- wendete Programmierstandards sind ANSI-C, POSIX 1003.1 und BSD sockets. 2.1 Programmbeschreibung 2.1.1 sendfiled Der sendfiled muß nur einmal installiert werden (siehe weiter unten) und läuft dann ohne weitere direkte Benutzeraktion, da er automatisch vom inetd gestartet wird. Er verhält sich damit analog zu einem ftpd. sendfiled legt ankommende Dateien im Spool-Directory des Empfängers ab und gibt ankommende Nachrichten (messages) auf den tty des Empfängers aus, sofern dies nicht durch die Konfigurationsdateien verboten wurde (siehe weiter unten). Das Spoolverzeichnis ist normalerweise /var/spool/sendfile/username (sofoern beim installieren nicht anders spezifiziert). Zum sendfiled gehören zwei Konfigurationsdateien: nosendfile und sendfile.cf, die normalerweise in /usr/local/etc/ liegen. In nosendfile können lokale Benutzer eingetragen werden, die keine Dateien oder Nachrichten erhalten sollen, also vom SAFT-Service ausgeschlossen werden sollen. dies sind normalerweise Pseudo-User wie ftp, news, admin, root, nobody, lpd, etc. Steht in nosendfile in der ersten Zeile allow-only,bewirkt dies, daß jetzt nur noch die nachfolgend aufgeführten Benutzer Dateien oder Nachrichten empfangen können. In sendfile.cf stehen Optionen, die das genau Verhalten des sendfiled steuern und die jederzeit geändert werden können. Die Bezeichnungen sind im wesentlichen Selbster- klärend. Hier ein Beispiel: # sendfile configuration file # ring the gong when a message arrives (on/off) bell = on # maximum allowed files to receive per user maxfiles = 200 # maximum total disk space quota for spool in MB # (WARNING! Defining this option will sendfile slow down!) # maxspool = 100 # minimum free disk space for spool partition in MB minfree = 10 # accept only messages or files # acceptonly = messages # address of your generic SAFT-server (for NFS) # saftserver = saft.banana.net # notify by message, mail, both or none notification = message # keep spool files at least xx days, then delete them (0=infinity) keep = 0 # delete aborted or corrupted spool files after xx days (0=never) deljunk = 10 maxspool beschränkt die maximale Anzahl an belegten MBs im Spool (total), wärend minfree ein Minimum an freien MBs in der Spool Partition garantiert. Die Unterschei- dung ist deshalb sinnvoll, weil der Spool nicht in einer eigenen Partition sein muß, son- dern nur ein Directory-Baum innerhalb einer Partition sein kann, die auch noch anderen Zwecken dient. Die Optionen keep und deljunk werden durch den Aufruf von receive oder durch ankommende Files über sendfiled getriggert. Um sicher zu gehen, daß auch alte Files von allen Usern gelöscht werden, gibt es das Programm sf_cleanup. Dies kann bei Bedarf gestartet werden (einmal pro Woche oder so). Mit NFS tut sich sendfile etwas schwer, weil NFS keinerlei Locking-Mechanismus besitzt und es so zu Race Conditions und Datenkorruption kommen kann, wenn auf den sendfile- spool via NFS zugegriffen wird (wenn /var/spool/sendfile via NFS gemountet wird). Mit folgendem Workaround funktioniert sendfile aber auch in einer NFS-Umgebung: · Auf NFS-Clients in sendfile.cf eintragen: acceptonly = messages saftserver = nfs.server.host.name · Auf dem NFS-Server in sendfile.cf eintragen: notification = mail Wenn jetzt versucht wird, an einen NFS-Client ein File zu schicken, kommt folgende Feh- lermeldung (Beispiel): $ sendfile LIESMICH framstag@moep.bb.bawue.de %sendfile-F, server error: For sending files use: framstag@syssrv.bb.bawue.de Messages können trotzdem weiterhin verschickt werden. In beiden Konfigurationsdateien dient ein # als Kommentarzeichen, d.h. alles inklusive diesem Zeichen bis Zeilenende wird ignoriert. Als Unix-betriebssystemspezifische Erweiterung des SAFT-Protokolls wurden die Attri- but TAR und EXE eingeführt. TAR erlaubt alle Unix-Fileattribute mit zu übertragen. Hat eine Datei das tar-Attribut, so handelt es sich um ein tar-Archiv nach POSIX 1003 und diese wird vom receive-Client dann entsprechend behandelt. EXE sagt aus, daß die über- tragene Datei ein ausführbares Programm (z.B. executable oder Shell-Script) ist. Der receive-Client setzt dann die korrekte Protection. Alle POSIX kompatiblen Betriebssy- steme, wie z.B. VMS und Windows NT, können auch diese erweiterte Attribute überneh- men, sollte für diese Systeme eine SAFT-Implementation realisiert werden. 2.1.2 sendfile Der sendfile-Client ist ein Userprogramm, das Dateien an den Empfänger verschickt. Der Aufruf von sendfile -h ergibt die Ausgabe: usage: sendfile [-stuvd] file-name [...] user[@host] or: sendfile [-uva] archive-name file/directory-name [...] user[@host] -s send file(s) in source mode -t send file(s) in text mode -u send file(s) uncompressed -v verbose mode -a send file(s) as one archive -d delete previous sent file(s) ( default mode: send file(s) in binary mode and compressed ) example: sendfile rabbit.gif beate@juhu.lake.de Im einfachsten Fall reicht die Zeile (Beispiel) sendfile bdsm.txt andrea um die Datei bdsm.txt an den lokalen Benutzer andrea zu schicken. sendfile verschickt dann die Datei binär, d.h. ohne jede Veränderung, und komprimiert (Falls es sich um eine komprimierbare Datei handelt).. Die Anzahl der übertragenen Bytes wird immer angezeigt. Es können aber auch die folgenden Optionen angegeben werden: -s behandelt die zu verschickende Datei als Programm Sourcecode. Dies ist nur notwendig, wenn das Empfängersystem kein Unix ist. -t behandelt die zu verschickende Datei als Text. Beim Textmodus werden Umlaute und andere Sonderzeichen korrekt gewandelt. Dies ist nur notwendig, wenn das Empfängersystem kein Unix ist. -u verschickt unkomprimiert. Default ist komprimierte Übertragung. Dies sollte nur dann verwendet werden, wenn sich Sender und Empfänger auf dem selben Host befinden. Komprimierte Übertragung ist ein wesentliches Mittel zur Reduk- tion von Netzlast. -v gibt alle SAFT-Meldungen mit aus (verbose mode). Dies dient zur Lokalisa- tion von Protokollfehlern oder zur Befriedigung der Neugier (,Was geht denn da ab?"). -a schickt mehrere Dateien oder ganze Verzeichnisbäume als ein Archiv. Das erste Argument nach -a gibt den Namen des Archivs an. Diese Option ist nur gül- tig, wenn das Empfängersystem ebenfalls ein Unix ist. -d löscht eine vorher verschickte Datei auf dem Serversystem, vorausgesetzt, es befindet sich dort noch im Spool. Die Optionen -s -t, -d und -a schließen sich jeweils gegenseitig aus. Als user-Name darf auch ein elm-Alias verwendet werden, wenn kein sendfile-Alias (siehe weiter unten) gleichen Namens vorhanden ist und der elm-Alias auf eine echte Internet-Adresse zeigt. Weitere Beispiele: sendfile -s *.pas uranus@bigvax.inka.de sendfile -va C-Projekt sendfile doku.ps uwe 2.1.3 sendmsg Der sendmsg-Client ist ein Userprogramm, das einzeilige Textnachrichten an den sendfi- led verschickt, welcher sie dann direkt auf das Terminal des Empfängers schreibt. Der Aufruf von sendmsg -h ergibt den Output: usage: sendmsg [-v] user@host or: sendmsg [-mM] options: -v verbose mode -m receive messages only on this tty (default) -M receive messages on other ttys, too example: sendmsg orakel@main01.bb.bawue.de sendmsg verlangt nach Aufruf, die zu übertragende Nachricht einzugeben. Als user-Name darf auch ein elm-Alias verwendet werden. Beispiel: sendmsg framstag@moep.bb.bawue.de message: geiles Programm, das sendfile! Ankommende Nachrichten werden normalerweise (sofern via Konfigurationsdatei nicht anders geregelt) auf allen ttys des Empfängers ausgegeben. Wird der Empfänger selbst zum Sender, indem er sendmsg aufruft (z.B. mit sendmsg -m), so werden ab sofort Messa- ges nur noch auf diesem tty ausgegeben. 2.1.4 receive Der Empfänger kann sich die Dateien mittels des receive-Clients in sein Directory kopie- ren, wobei das Original im Spool gelöscht wird. Der Aufruf von receive -h ergibt den Output: usage: receive [-d] file-name or: receive -n [-dr] file-number or: receive [-l] [-L] or: receive -a [-dr] options: -l short list of files -L full list of files -n specify a file number -a specify all files -d delete -r rename file when receiving examples: receive -a ! receive all files receive -n 1 ! receive file with number 1 receive blubb ! receive file with name blubb Im einfachsten Fall gibt der Benutzer an (Beispiel): receive blubb.txt %receive-I, blubb.txt received Dies kopiert die Datei blubb.txt ins aktuelle Directory und löscht sie aus dem Spool. Weitere Optionen sind: -d löscht die Datei ohne sie vorher zu kopieren -n anstelle des Dateinamens wird seine Spoolnummer verwendet -a alle Dateien abholen bzw. löschen -l auflisten der Dateien -L auflisten der Dateien und Inhalt der Archive mit ausgeben -r umbenennen der Datei beim abholen Weitere Beispiele: receive -l From zrxh0370@baracke.rus.uni-stuttgart.de (Ulli Horlacher) 1) 10-Aug-1995 15:41:24 3 KB LIESMICH 2) 10-Aug-1995 15:41:37 30 KB doku.txt 3) 11-Aug-1995 16:12:09 113 KB Sourcen (archive) receive -n 1 LIESMICH already exists. Overwrite it (yYnN)? y %receive-I, LIESMICH received receive -d Sourcen %receive-I, Sourcen deleted Existiert eine Datei gleichen Namens bereits, so fragt receive nach, ob es sie über- schreiben soll. Ist die Eingabe Y oder N oder so werden bei anderen Dateien keine weiteren Fragen gestellt, sondern diese einfach überschrieben bzw. übergangen. Bei y oder n wird jedesmal neu nachgefragt. Der Dateiname darf auch * oder ? als Wildcard-Zeichen enthalten, allerdings ist durch Einschliessung in '' Quote-Zeichen dafür zu sorgen, daß die Shell die Metazeichen * und ? nicht vorher selber interpretiert. Enthält eine Datei besondere Zeichen, wie Unicodezeichen, Controlcodes oder Shell- metazeichen, so frägt receive nach, in welchem Format der Dateiname abgespeichert werden soll. Beispiel: receive 'gaga*' The next file name contains characters which may cause problems with your shell or may do strange things with your terminal. These characters have been substituted with '_'. (c)omplete file name with control code characters is not displayable (n)ormal file name: >gaga blubb< (s)hell file name: >gaga_blubb< Select one of c n s (or C N S for no more questions): n gaga blubb already exists. Overwrite it (yYnN)? y %receive-I, gaga blubb received Wenn Dateien bereits aus dem Spool gelöscht worden sind, besteht trotzdem noch eine Möglichkeit herauszubekommen, wer was geschickt hatte. Mit more /var/spool/sendfile/$LOGNAME/log läßt sich die sendfile-Protokolldatei anschauen. 2.2 Benutzerkonfigurationsdateien Sowohl sendfile als auch sendmsg greifen auf diverse benutzerspezifische Konfigurations- dateien zurück, die alle unter /var/spool/sendfile/username/config/ liegen. Diese Dateien werden per default vom sendfiled angelegt, sobald der entsprechende Benutzer zum ersten mal etwas empfangen sollen. Ihre Erzeugung kann also z.B. mit: sendmsg $LOGNAME erzwungen werden. Es handelt sich bei diesen Konfigurationsdateien um: · config Hier können die globale Konfigurationsoptionen bell und notification (aus /usr/local/ etc/sendfile.cf) überschrieben werden: bell = on # Bimmel an bell = off # Bimmel aus notification = none # keine Benachrichtigung fuer Files notification = message # Benachrichtigung via msg notification = mail # Benachrichtigung via mail notification = both # Benachrichtigung via mail und msg notification = mail blubber@blah # Benachrichtigung via mail an ... · aliases Hierbei handelt es sich um ein Aliasfile, in dem oft benutzte Adressen abgekürzt wer- den können. Das Format ist: alias address Beispiel: chief grmblfz@bigvax.somewhere.net beate beate@juhu.lake.de · restrictions Hier drin stehen Adressen, von denen man keine Dateien oder Nachrichten bekom- men möchte. Das Format ist: user@host [mfb] Dabei steht m für Message, f für File und b für both. Beispiele: gates@microsoft.com b *aol.com m · msg Hier drin steht der Name des tty auf das ankommende Nachrichten ausgegeben werden sollen. Wird automatisch von sendmsg gesetzt. 2.3 Installation Es wird vorausgesetzt, daß grundlegende Kenntnisse der Administration einer vernet- zen Unix-Workstation vorhanden sind. Diese hier zu erklären, würden bei weitem den Rahmen der Dokumentation sprengen. 1. Pfade anpassen: Bei Bedarf können in config.h (und NUR da!) Default-Werte für bestimmte Pfade geändert werden. Dies sind: #define BINDIR "/usr/local/bin" #define MANDIR "/usr/local/man/man1" #define SERVERDIR "/usr/local/sbin" #define SPOOL "/var/spool/sendfile" #define NOSENDFILE "/usr/local/etc/nosendfile" #define CONFIG "/usr/local/etc/sendfile.cf" Bei den ersten drei Werten handelt es sich Verzeichnis, in die sendfile installiert wird, bei den letzten drei um den Ort des Spool bzw. der Systemkonfigurationsda- teien. 2. Laufzeit-Konfiguration anpassen: Der sendfiled wertet zur Laufzeit die Systemkonfigurationsdatei sendfile.cf aus (wird normalerweise nach /usr/local/etc/ kopiert, siehe oben). Dies kann entweder jetzt oder zu jedem späteren Zeitpunkt geändert werden, falls Bedarf besteht. 3. alles compilieren: make Es dürfen keine Fehlermeldungen auftreten. Auf manchen Systemen mit fehlerhaf- ten System-Include-Files kann es zu Warnings kommen, die aber ignoriert werden können. Sendfile wurde bisher getestet unter AIX, BSDI, Convex-OS, Digital Unix, FreeBSD, HP-UX, IRIX, Linux, NeXTstep/Mach, OSF/1, SunOS 4, SunOS 5 (Solaris 2) und Ultrix mit gcc 2.5.8. Ultrix-ACHTUNG! Bei Ultrix muss vor ,make all" noch ,sh5 genmake" einge- geben werden (weil Ultrix-sh buggy ist)! 4. alles automatisch installieren (muss root machen!): make install oder von Hand installieren: - korrekte Fileprotection einstellen: umask 022 - sendfiled hinkopieren, wo es Sinn macht, zB /usr/local/sbin, /usr/etc : cp sendfiled /usr/local/sbin/ - spool-directory anlegen (wie in config.h angegeben!): mkdir /var/spool/sendfile chmod 755 /var/spool/sendfile - Eintragung in /etc/services (bzw mit ,niload services ." bei NeXT): saft 487/tcp # simple asychronous file transfer - Eintragung in /etc/inetd.conf: saft stream tcp nowait root /wo/auch/immer/sendfiled - inetd neu starten: kill -HUP /usr/sbin/inetd #(oder wo auch immer der inetd liegt) - Userbeschränkung aktivieren (wie in config.h angegeben!): cp nosendfile /etc - man-pages installieren: cp sendmsg.1 sendfile.1 receive.1 /usr/man/man1 - notify-script installieren: $ cp check_sendfile /usr/local/bin /usr/local/bin/check_sendfile in /etc/profile aufnehmen - Clients installieren: cp sendfile sendmsg receive /usr/local/bin 5. testen: sendfile LIESMICH $LOGNAME receive -l receive -n 1 6. Ich bin sehr an Kommentaren und Bugreports interessiert. Geschenke via Post schicken. :-) 7. Wer mir die Adresse seines neu installierten SAFT-Servers mitteilt, bekommt zur Belohnung ein schönes gif zugeschickt. :-) 8. Es gibt eine Mailingliste, die ich von Hand führe und in der Ankündigungen zu updates und bugfixes geposted werden. Wer da aufgenommen werden möchte, sende mail an mich. 2.4 Sourcen Das sendfile Paket besteht aus (Module und darin enthaltene Funktionen): · sendfile.c - Das sendfile Hauptmodul. usage : print short help usage text whereis : search for program name in PATH send_data : send file data clean_up: delete tmp-file · sendfiled.c - Das sendfiled Hauptmodul. getline : get a command line writeheader : write one line to header spool file msg2tty : write a message to all ttys of the user mail2user : send a mail to the recipient spoolid : get the next spool id number restricted : check killfile wlock_file : write-lock a file tlock_file : test the lock status of a file · sendmsg.c - Das sendmsg Hauptmodul. usage : print short help usage text · receive.c - Das receive Hauptmodul. usage : print short help usage text receive_sf : receive a spool file list : list all spool files crlf2lf : translate NVT format file to Unix text format file fcopy : copy a file spawn : spawn a subprocess and direct output to a file · spool.c spool.h - Funktionen zum lesen und schreiben von Spoolfiles out : send string conforming to NVT standard scanspool : scan the spool directory and create structure lists delete_sf : delete a spool file · reply.c reply.h - reply-codes für sendfiled. reply: send string conforming to NVT standard · string.c string.h - Erweiterte Stringfunktionen. str_trim : trim white spaces str_toupper : transform string to upper case str_tolower : transform string to lower case strins : insert one string in another simplematch : match a simple pattern · utf7.c utf7.h - UTF-7 und Unicode Kodierungsroutinen. utf2iso : UTF-7 to ISO Latin-1 decoding iso2utf : ISO Latin-1 to UTF-7 encoding iso2uni : transform ISO Latin-1 to Unicode add_char : add a char depending on its range decode_mbase64 : decode mbase64 string to Unicode encode_mbase64 : encode Unicode pstring to mbase64 · pstring.c pstring.h - Routinen zum Umgang mit Pascalähnliche Strings. pstr_create : create a pstring pstr_delete : delete a pstring pstr_addchar : add a char to a pstring pstr_assign : assign one pstring to another pstr_addstring : add a string to a pstring pstr_print : print a pstring · message.c message.h - VMS-like Informations und Fehlermeldungsroutine. message : print information, warning and error messages on stderr · peername.c peername.h - Funktion zur Erkennung des aufrufenden Host über stdin. peername : returns the peername of the connecting host on stdin · io.c io.h - Socket read und write Funktionen. readn : read n bytes from network socket writen : write n bytes to network socket · net.c net.h - Verschiedener Netzwerkkram. open_connection : open socket and connect to client sock_getline : get a line from the network socket sock_putline : send a line to the network socket getreply : get the reply on a command from the server sendheader : send a headerline and check the reply code · destination.c destination.h - Bestimmung des Empfängers destination: parsen von elm-aliasen und hostname-Daten. · config.h - Verschiedene Preprozessordefinitionen. · bsd.h - Das blöde AIX hat keine eigenen include-Files für sockets. · genmake - Shellscript zur Bestimmung des Betriebsystems und zur Generierung des Makefiles. · check_sendfile - Shellscript um zu überprüfen, ob Dateien im Spool vorliegen. Sollte von /etc/profile aufgerufen werden. · sf_cleanup - Shellscript zum löschen alter Files aus dem Spool. · install - automagic install-script · nosendfile - Liste aller Benutzer, die vom SAFT-Dienst ausgeschlossen sind. · sendfile.cf - sendfile-Systemkonfigurationsfile. · LIESMICH - Eine deutsche Installationsschnellhilfe. · LIESMICH.auch - Kurzbeschreibung von sendfile/SAFT · README - a quick installation guide · README.too - a short description of sendfile/SAFT · HISTORY - last changes · sendmsg.1 - Man-page für sendmsg. · sendfile.1 - Man-page für sendfile. · receive.1 - Man-page für receive. · doku.ps - Diese Dokumentation hier. · doc.ps - this documentation 2.4.1 Aufrufdiagramm Modulübersicht 2.4.2 Datenstrukturen Von den Programm-Datenstrukturen, die implementiert wurden, sind 3 von Interesse (bei den restlichen handelt es sich um Standard C Typen wie int, char *, etc): · pstring - Strings mit Längeninformationen (von Pascal abgeleitet). Die pstrings sind notwendig, um Unicode-Strings zu verarbeiten, welche ASCII(0) Zeichen enthalten können. Die normalen C-Strings vom Typ char* behandeln ASCII(0) als Ende des Strings und sind somit für Unicode unbrauchbar. In Anlehnung an Pascal wurden die pstrings implementiert, deren Länge nicht durch ein Terminalzeichen definiert wird, sondern über extra Struktureinträge. Die pstrings haben folgende Struktur: struct { int size; /* absolute Länge */ int length; /* belegte string-Länge */ char *string; /* der String selber ohne Terminierungssymbol */ } size ist dabei die Speicherkapazität des pstrings, während length die tatsäch- lich belegte Länge ist. In *string steht der eigentlich Textstring. Per Definition beginnt der Inhalt des pstring mit string[1] und nicht wie sonst üblich in C mit string[0]. Dies hat zwar zur Folge, daß pro pstring ein Byte ver- schwendet wird, aber es hat gleichzeitig den Vorteil, leichter mit den Längenange- ben rechnen zu können. In string.c sind die pstring-Funktionen definiert, die im Zusammenhang mit den Unicode-Strings im sendfile-Paket benötigt werden. · filelist - Eine einfach verkettete Liste zum Speichern der Dateiattribute und deren Absender. Pro Absender existiert eine Liste, pro Datei wird ein Listenelement angelegt, wobei die Liste nach dem Empfangsdatum aufwärts geordnet ist, d.h. die zuerst empfangene Datei wird als erstes Listenelement gespeichert. Ein filelist-Element hat folgende Struktur: struct filelist { int id, /* id number */ osize, /* original size */ csize, /* compressed size */ tsize, /* transfered size */ flags; /* binary,source,text,compress and tar flag */ char rdate[30], /* receiving date */ date[30], /* file date */ charset[30], /* character set name */ fname[MAXLEN]; /* UTF-7 file name */ struct filelist *next; /* next list element */ }; id ist die eindeutige Dateinummer im Spool. Siehe dazu weiter unten. osize ist die Originalgröße der Datei ohne Kompression. csize ist die Größe der Datei, wie sie (komprimiert) übertragen wird. tsize ist die tatsächlich Anzahl der übertragenen Bytes. flags sind die Dateiattribute für SOURCE, TEXT, COMPRESS und TAR. rdate ist das Empfangsdatum. date ist das Originaldatum der Datei, wie sie der Sender mit angibt. charset ist der Name des Zeichensatzattributs. fname ist der Dateiname, UTF-7 codiert. *next ist der Zeiger um die Liste zu verketten. Die Definition von filelist und den Flags befindet sich in spool.h. · senderlist - Eine einfach verkettete Liste zum Speichern der Absender und der filelists. Im Gegensatz zu den filelists existiert nur eine senderlist. Pro Absender wird ein Listenelement angelegt. Ein senderlist-Element hat folgende Struktur: struct senderlist { char from[MAXLEN], /* sender */ sig[MAXLEN]; /* authentification signature */ struct filelist *flist; /* list of files */ struct senderlist *next; /* next list element */ }; from ist der Name des Absenders, UTF-7 codiert. *flist ist der Zeiger auf die dazugehörige filelist. *next ist der Zeiger auf das nächste Listenelement. Die senderlist und filelists ergeben also zusammen folgende Struktur:: Diese Datenstruktur wird jedesmal neu erzeugt, wenn Informationen über Spoolfi- les benötigt werden. Diese verketteten Listen können in einem C Programm wesentlich einfacher ausgewertet werden, als daß für jede Information das betref- fende Spoolheaderfile explizit ausgelesen wird Der Spool selber wird in /var/spool/sendfile angelegt, wo jeder Empfän- ger bei Bedarf, d.h. wenn zum ersten mal eine Datei für ihn empfangen wird, auto- matisch ein eigenes Spoolverzeichnis bekommt (im Source als userspool bezeichnet). Im userspool befinden sich für jede empfangene Datei zwei Spoolfiles: das Spoolheaderfile und das Spooldatafile. Im Spoolheaderfile sind alle Dateiattribute eingetragen, die der Sender übermittelt hat, im Spooldatafile ist die Datei selbst als Bytestrom abgelegt, so wie sie übertragen wurde.Weiterhin befindet sich in die- sem Directory das sogenannte log-File, in dem alle Übertragungen protokolliert werden. Beispiel eines userspool: baracke:~/sendfile> ll /var/spool/sendfile/zrxh0370/ -rw------- 1 zrxh0370 system 1176 Sep 13 18:03 1.d -rw------- 1 zrxh0370 system 137 Sep 13 18:03 1.h -rw------- 1 zrxh0370 system 994 Sep 13 18:03 2.d -rw------- 1 zrxh0370 system 136 Sep 13 18:03 2.h -rw------- 1 zrxh0370 system 5178 Sep 13 18:03 log baracke:~/sendfile> cat /var/spool/sendfile/zrxh0370/1.h FROM gaga@linux.rus.uni-stuttgart.de FILE blubb.txt TYPE TEXT SIZE 5 5 DATE 1995-09-14 12:38:06 CHARSET ISO_8859-1:1987 3 Danksagungen Mein besonderer Dank geht an: · Lorenz Adena - für Featurewünsche und Betatesting · Thomas Beisel - für C Beratung, Postscripthexerei und Betatesting · Uwe Berger - für Grundsatzdiskussion und Designhilfen · Beate Herrmann - für grundlegende Ideen, psychologische Betreuung und Betatesting · Andreas Ley - für jede Menge Hilfe bei obskuren C Problemen und für die peername Funktion · Shannon Miller - for his corrections to my english documentation · Uwe Obermüller - für viele Vorschläge und Betatesting · Bernd Onasch - für C Beratung · Ingo Wilken - für die simplematch Funktion ohne deren Hilfe die Realisation dieses Projekts unmöglich gewesen wäre. 4 Informationsverzeichnis [1] Andrew Tanenbaum: Computer Networks [2] Bettina Reimer, Paul Müller: Kommunikationssysteme auf der Basis des ISO- Referenzmodells [3] Kernighan, Ritchie: Programmieren in C [4] Jürgen Gulbins: UNIX [5] W. R. Stevens: Advanced Programming in the UNIX Environment [6] W. R. Stevens: UNIX Network Programming [7] ISO-8601 - International Time and Date Representing [8] C-FAQ-list in news.answers [9] Umlaute-FAQ in de.comp.standards [10] internationalization/programming-faq in news.answers [11] mail/mime-faq in news.answers [12] http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-v10-spec-00.txt [13] RFC 859 - ftp [14] RFC 1345 - Character Mnemonics & Character Sets [15] RFC 1440 - SIFT/UFT: Sender-Initiated/Unsolicited File Transfer [16] RFC 1521 - MIME [17] RFC 1522 - MIME [18] RFC 1543 - Instructions to RFC Authors [19] RFC 1641 - Using Unicode with MIME [20] RFC 1642 - UTF-7 [21] RFC 1700 - Assigned Numbers Die RFCs sind zu finden unter ftp://ftp.uni-stuttgart.de:/pub/doc/standards/rfc/ Die FAQs sind zu finden unter ftp://ftp.uni-stuttgart.de:/pub/doc/faq/ 5 Glossar · ASCII - American Standard Code of Information Interchange 7 bit Zeichensatzkodierung der wichtigsten im amerikanischen Sprachraum vorkom- menden Zeichen. Siehe RFC 1345. · Bitnet - Because It`s Time Network Aussterbendes weltweites Forschungsnetzwerk auf IBM RSCS Technologie. In vielen Belangen der Vorgänger zum Internet. · DOS - Diskette Operating System Primitiver Diskettenmonitor und Interrupthandler für i8088 PCs · EBCDIC - Extended Binary Coded Decimals Interchange Code IBMs Zeichensatz für ihre Großrechner. · EOL - End Of Line · FAT - File Availibility Table Filesystem für DOS. · FDL - File Definition Languange Filesystembeschreibungssprache für RMS. · ftp - file transfer protocol/program Standardmethode um Dateien zu transferieren (synchron). Siehe RFC 959. · GNU - GNU`s not Unix Ein fortlaufendes Projekt der Free Software Foundation um qualitativ hochwertige und lizenzfreie Software im Sourcecode der Internetgemeinde zur Verfügung zu stel- len. · MIME - Multipurpose Internet Mail Extensions Multimediaerweiterungen für Mail. Siehe RFC 1341. · MUA - mail user agent Der Mailclient, den der Benutzer direkt verwendet. · MTA - mail transfer agent Der Mailserver (daemon), der vom MUA kontaktiert wird. · NVT - Network Virtual Terminal Remote login im Internet: telnet. Siehe RFC 854. · RFC - Request for Comment Internet Standard und Protokoll Beschreibungen. · RMS - Record Management System Das native Filesystem von VMS. · tcp/ip - transmission control protocol / internet protocol Netzwerk- und Transport-Ebene (ISO Level 3+4) des Internets. Siehe RFC 791/793. · VMS - Virtual Memory System Das beste Betriebssystem der Welt von DEC :-)