*ACHTUNG*		!VERALTET!			*ACHTUNG*

Definition eines Protokolls fr asynchronen Filetransfer im Internet und
                     Referenzimplementierung fr Unix









Ulli Horlacher





Allmandring 30

Rechenzentrum Universitt Stuttgart



framstag@rus.uni-stuttgart.de







5. Mrz 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 
Empfngersystem einzuloggen. Als Referenzimplementation wurden ein sendfile-Client (ver-
schickt Dateien), ein sendmsg-Client (verschickt einzeilige Nachrichten), ein receive-Client 
(empfngt Dateien aus dem sendfile-spool) und ein sendfiled-Server (empfngt Dateien und 
Nachrichten und verteilt sie weiter) geschrieben.

INHALT

1	Definition des asynchronen Dateitransfers und Abgrenzung 
gegenber 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	Begrndung des Protokolldesigns	12

2	sendfile: eine SAFT Referenzimplementation fr 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 
gegenber existierenden Diensten

Bei einem asynchronen Filetransfer werden Dateien von einem Sender an einen Empfn-
ger geschickt, ohne da letzterer aktiv an der bertragung teilnehmen mu. E-mail ist z.B. 
ein asynchroner Dienst, whrend 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 Mglichkeiten:

	ftp [13] zum Empfngeraccount 		
Dazu mu das Pawort des Empfngeraccounts 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-Pckchen 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. Whrend die Datei auf dem anonymous ftp Ser-
ver liegt, kann sie aber praktisch von jedermann gelesen, gelscht oder verndert 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 beschrnkt, 
wenn man nicht die zu verschickende Datei entsprechend kodiert, so da sie nur noch 
NVT-ASCII Zeichen enthlt. Als Kodierung bieten sich an: uuencode oder MIME 
[16]. Beide sind aber umstndlich zu handhaben, untersttzen nicht alle Dateiattribute 
und vergrern zwangslufig die zu bertragende Datenmenge. Zudem sind die real 
existierenden Mailsysteme nicht in der Lage, mit greren 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 Funktionalitt wesentlich erweitert wurde.

Tatschlich basieren smtliche Bitnetdienste auf asynchronen Filetransfers.

Bitnet erlaubt aufgrund von IBM-internen Restriktionen nur Dateinamen mit 8 Byte 
und 8 Byte Extension, Zeilenlngen 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 fr das Internet beschreibt. Dieses Protokoll hat den ,Experi-
mental" Status und enthlt noch einige Fehler bzw. Inkonsistenzen. Auerdem ist es 
stark an IBMs VM Betriebssystem angelehnt, da es ausschliesslich dessen Dateitypen 
untersttzt. 

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 mglich war. SIFT/UFT weist folgende 
Mngel auf:

	der Zeichensatz des Protokolls ist nicht spezifiziert

	als Dateitypen sind nur propritre VM-Files vorgesehen

	das Datumformat ist nicht spezifiziert

	die Zeichenstze der Dateien sind nicht spezifiziert

	Designfehler in der DATA-Anweisung: ein String ,EOF" in der zu bertragenden 
Datei fhrt 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 mglich und es 
mute ein eigenes Protokoll entwickelt werden.

1.3  Das SAFT Protokoll

Als Grundlage fr den asynchronen Filetransfer wurde das SAFT-Protokoll entwik-
kelt:

	Simple Asynchronous File Transfer

Wesentliche Merkmale sind:

	Betriebssystemunabhngigkeit	
SAFT soll auf mglichst allen Computersystemen im Internet verfgbar sein.

	Einfachheit 	
,keep it simple": ein berschaubares Protokoll auf ASCII-Basis, so da es leicht mit 
telnet auf den Serverport zu debuggen ist.

	Erweiterbarkeit		
sptere Erweiterungen sollen keine knstlichen Grenzen behindern. Als abschrecken-
des Beispiel sei die 7 Bit Beschrnkung 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 Empfngers 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 untersttzt folgende Dateiattribute:

	Dateiname in Unicode [19] mit beliebiger Lnge

	Zeitstempel		
Spezifikation nach ISO-8601 [7] (UTC full date & time)

	BINARY	
unstrukturierter Bytestrom

	SOURCE		
Datei besteht aus einzelnen Zeilen jeweils beliebiger Lnge mit CR/LF als EOL Mar-
kierung

	TEXT		
wie Source, nur da zustzlich das Attribut CHARSET (siehe unten) ausgewertet wird

	Name des Zeichensatzes		
Spezifikation nach RFC 1345 [14]

	Betriebssystemspezifische Attribute		
Diese knnen bei der ersten SAFT-Implementation fr das jeweilige Betriebssystem 
vom Autor beliebig verwendet werden. Kompatibilitt ist dabei aus prinzipiellen 
Grnden nur zwischen Client und Server desselben Betriebssystems gewhrleistet.

SAFT kann Dateien mittels gzip Algorithmus komprimiert bertragen. Dieses stellt kein 
Dateiattribut sondern ein bertragungsmerkmal dar. Fr den Sender und Empfnger 
geschieht dies vllig transparent. Diese Komprimierung wurde eingefhrt, um Netzband-
breite zu schonen. Der Flaschenhals eines Filetransfers stellt in der Regel das Netz dar 
und nicht die Leistungsfhigkeit 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 
zulssig, sollte aber vermieden werden.

Ein Kommando vom Client besteht aus einer Zeile, die ein Befehlswort und je nach 
Bedarf ein oder mehrere Parameter enthlt, getrennt durch Whitespace. Ein White-
space ist eine nicht-Null Zeichenfolge aus SPACE (ASCII 32) oder HT (ASCII 9) in 
beliebiger Reihenfolge. Nach Mglichkeit sollte immer ein einzelnes SPACE als 
Whitespace verwendet werden.

Als Kommandos sind definiert:

	FROM <sender> [<real name>]
Absender Loginname und optional echter Name und pgp Signatur.

	TO <recipient>		
Empfnger Loginname

	FILE <name>	
Name der zu bertragenden Datei

	DATE <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>	
Name des Zeichensatzes einer Textdatei nach RFC 1345 (&charset Eintrag) . Ali-
ase sind nicht erlaubt. Wenn mglich sollte ISO_8859-1:1987 verwendet werden.

	ATTR <attribute-string>	
Betriebssystemspezifische Dateiattributerweiterung, implementationsabhngig.

	MSG <message>		
Einzeilige Nachricht, die direkt auf das Terminal des Empfngers ausgegeben 
werden soll.

	DEL		
Datei, die zuvor bertragen wurde, wird gelscht.

	RESEND		
Die Datei soll nach vorhergehenden bertragungsabbruch erneut geschickt werden. 
Die Serverantwort enthlt als erster String die Anzahl der bereits bertragenen Bytes: 
<transmitted> 

	SIZE <size> <size uncompressed>	
Gre der zu bertragenden Datei in Bytes: die erste Zahl stellt die tatschlich zu 
bertragenden Bytes dar, die zweite die Gre der Datei nach der Dekomprimierung.

	DATA		
Ab hier folgen <size> - <transmitted> Bytes der Datei als aufeinanderfolgender 
Strom von 8-bit Bytes.

	QUIT		
Ende der Verbindung

Die Befehlswrter knnen in Gro- oder Kleinbuchstaben oder sogar gemischt geschrie-
ben werden. FROM, from oder FrOm sind gleichbedeutend. Nach Mglichkeit sollten 
alle Befehlswrter aber einheitlich in Grobuchstaben geschrieben werden.

<sender>, <real name>, <recipient>, <name> und <message> sind UTF-7 [20] kodierte 
Strings. Nach Mglichkeit sollten hier nur NVT-ASCII oder ISO Latin-1 Zeichen [14] 
enthalten sein.

Zur bertragung einer Datei mssen 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 mssen)):

	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 folgendermaen 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	=	<Zeichen aus NVT-ASCII Zeichensatz>

 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 fr: korrekte Kommandodurchfhrung

	3 steht fr: weitere Daten/Informationen werden bentigt

	4 steht fr: fataler Fehler mit anschliessendem Verbindungsabbruch

	5 steht fr: 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 <help-text>

	220 <hostname> SAFT server (sendfiled <version> on <OS>) ready.

	221 Goodbye.

	230 <number> 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 kn-
nen beliebig verndert 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 <sender> [<real name>] [<pgp signature>]

214-  TO <recipient>

214-  FILE <name>

214-  SIZE <size to transfer> <size uncompressed>

214-  TYPE BINARY|SOURCE|TEXT [COMPRESSED]

214-  DATE <ISO-8601 date string>

214-  CHARSET <RFC-1345 character set name>

214-  ATTR TAR|EXE|NONE

214-  MSG <message>

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 bertrgt 
eine Zeile mit CR LF als EOL-Markierung. Diese Bytes zhlen natrlich mit.

1.3.2  Begrndung 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. Auerdem 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 
gegenber 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 fr 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 Einfhrung von MIME noch keinen brauchbaren 
freien MUA fr Unix oder VMS gibt.

Als groe Probleme stellten sich die Wahl des Zeichensatzes fr Textdateien und das For-
mat der Dateinamen heraus. Fr beide liessen sich keine gemeinsame Basis finden, die 
allen Betriebssystemen im Internet gerecht werden wrde.

Der einzige Zeichensatz, der eine echte Obermenge aller anderen Zeichenstze 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 berlt die korrekte 
Konvertierung der Empfngerseite. 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 fhrend 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 Lnge. Der Client 
kann aber nicht sicher sein, da der Dateiname auf dem Empfngersystem verarbeitet 
werden kann. Deshalb sollten bei Unkenntnis der Mglichkeiten des Empfngersy-
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 ausgewhlt, weil es

	lizenzfrei ist (GNU Copyleft)

	sehr gute Kompressionsraten liefert

	auf praktisch allen Betriebssystemen verfgbar ist

	einen Quasistandard im Internet darstellt

Viele Betriebssysteme bieten weitere Dateiattribute, als die von SAFT abgedeckten 
an. Diese Attribute sind aber Filesystem-proprietr und nicht zwischen verschiedenen 
Betriebssystemen konvertierbar. VMS/RMS kann z.B. nichts mit dem Hidden-bit von 
DOS/FAT anfangen, whrend wiederum auf allen anderen Betriebssystemen die FDL 
von VMS/RMS keinen Sinn macht.

Deshalb wurde das ATTR Kommando eingefhrt, welches nur fr das jeweilige 
Betriebssystem von Relevanz ist. Jeder Autor einer neuen SAFT Implementation kann 
das ATTR Kommando fr sein Betriebssystem erweitern, indem er neue Parameter 
einfhrt (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 wnschenswert ist.

2  sendfile: eine SAFT Referenzimplementation fr Unix

Das sendfile Paket ist eine Umsetzung des SAFT Protokolls fr Unix-Systeme und umfat 
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: rumt alte Files aus dem Spool

	Dokumentation:

- man-pages: Hilfetexte im Standard-Unix-Format

- LIESMICHe bzw. READMEs: Kurze Hilfetext fr 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 
Empfnger mit einer Nachricht, die direkt auf sein Terminal geschrieben wird. Der Emp-
fnger kann sich dann die Dateien mittels des receive-Clients in sein Directory kopieren, 
wobei das Original im Spool gelscht wird. Der sendmsg-Client ist ein Userprogramm, 
das einzeilige Textnachrichten an den sendfiled verschickt, welcher sie dann direkt auf das 
Terminal des Empfngers 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 luft dann ohne 
weitere direkte Benutzeraktion, da er automatisch vom inetd gestartet wird. Er verhlt sich 
damit analog zu einem ftpd.

sendfiled legt ankommende Dateien im Spool-Directory des Empfngers ab und gibt 
ankommende Nachrichten (messages) auf den tty des Empfngers 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 gehren zwei Konfigurationsdateien: nosendfile und sendfile.cf, die 
normalerweise in /usr/local/etc/ liegen. 

In nosendfile knnen 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 aufgefhrten Benutzer Dateien oder Nachrichten empfangen knnen.

In sendfile.cf stehen Optionen, die das genau Verhalten des sendfiled steuern und die 
jederzeit gendert werden knnen. Die Bezeichnungen sind im wesentlichen Selbster-
klrend. 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 beschrnkt die maximale Anzahl an belegten MBs im Spool (total), wrend 
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 gelscht 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 knnen 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 eingefhrt. 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 ausfhrbares 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, knnen auch diese erweiterte Attribute berneh-
men, sollte fr diese Systeme eine SAFT-Implementation realisiert werden.

2.1.2  sendfile

Der sendfile-Client ist ein Userprogramm, das Dateien an den Empfnger 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 binr, d.h. ohne jede Vernderung, und komprimiert 
(Falls es sich um eine komprimierbare Datei handelt).. Die Anzahl der bertragenen 
Bytes wird immer angezeigt. Es knnen aber auch die folgenden Optionen angegeben 
werden:

-s	behandelt die zu verschickende Datei als Programm Sourcecode. Dies ist nur 
notwendig, wenn das Empfngersystem 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 Empfngersystem kein Unix ist.

-u	verschickt unkomprimiert. Default ist komprimierte bertragung. Dies sollte 
nur dann verwendet werden, wenn sich Sender und Empfnger 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 Verzeichnisbume als ein Archiv. Das 
erste Argument nach -a gibt den Namen des Archivs an. Diese Option ist nur gl-
tig, wenn das Empfngersystem ebenfalls ein Unix ist.

-d	lscht eine vorher verschickte Datei auf dem Serversystem, vorausgesetzt, es 
befindet sich dort noch im Spool.

Die Optionen -s -t, -d und -a schlieen 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 Empfngers 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 Empfngers ausgegeben. Wird der Empfnger 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 Empfnger kann sich die Dateien mittels des receive-Clients in sein Directory kopie-
ren, wobei das Original im Spool gelscht 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 lscht sie aus dem Spool.

Weitere Optionen sind:

-d	lscht die Datei ohne sie vorher zu kopieren

-n	anstelle des Dateinamens wird seine Spoolnummer verwendet

-a	alle Dateien abholen bzw. lschen

-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 dafr zu sorgen, da die Shell die Metazeichen * 
und ? nicht vorher selber interpretiert.

Enthlt eine Datei besondere Zeichen, wie Unicodezeichen, Controlcodes oder Shell-
metazeichen, so frgt 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 gelscht worden sind, besteht trotzdem noch eine 
Mglichkeit herauszubekommen, wer was geschickt hatte. Mit 

more /var/spool/sendfile/$LOGNAME/log 

lt sich die sendfile-Protokolldatei anschauen.

2.2  Benutzerkonfigurationsdateien

Sowohl sendfile als auch sendmsg greifen auf diverse benutzerspezifische Konfigurations-
dateien zurck, 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 knnen 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 abgekrzt wer-
den knnen. 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 mchte. Das Format ist:

	user@host [mfb]

Dabei steht m fr Message, f fr File und b fr 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 erklren, wrden bei weitem den 
Rahmen der  Dokumentation sprengen.

1.	Pfade anpassen:

Bei Bedarf knnen in config.h (und NUR da!) Default-Werte fr bestimmte Pfade 
gendert 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 spteren Zeitpunkt gendert werden, falls Bedarf besteht.



3.	alles compilieren: 

	make 

Es drfen keine Fehlermeldungen auftreten. Auf manchen Systemen mit fehlerhaf-
ten System-Include-Files kann es zu Warnings kommen, die aber ignoriert werden 
knnen. 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 <pid des inetd>

	/usr/sbin/inetd #(oder wo auch immer der inetd liegt)

 

- Userbeschrnkung 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 schnes gif zugeschickt. :-)

8.	Es gibt eine Mailingliste, die ich von Hand fhre und in der Ankndigungen zu 
updates und bugfixes geposted werden. Wer da aufgenommen werden mchte, 
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 fr 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 Pascalhnliche 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 Empfngers

destination: parsen von elm-aliasen und hostname-Daten.

	config.h - Verschiedene Preprozessordefinitionen.

	bsd.h - Das blde AIX hat keine eigenen include-Files fr sockets.

	genmake - Shellscript zur Bestimmung des Betriebsystems und zur Generierung 
des Makefiles.

	check_sendfile - Shellscript um zu berprfen, ob Dateien im Spool vorliegen. 
Sollte von /etc/profile aufgerufen werden.

	sf_cleanup - Shellscript zum lschen 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 fr sendmsg.

	sendfile.1 - Man-page fr sendfile.

	receive.1 - Man-page fr receive.

	doku.ps - Diese Dokumentation hier.

	doc.ps - this documentation

2.4.1  Aufrufdiagramm

Modulbersicht 

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 Lngeninformationen (von Pascal abgeleitet).

Die pstrings sind notwendig, um Unicode-Strings zu verarbeiten, welche 
ASCII(0) Zeichen enthalten knnen. Die normalen C-Strings vom Typ char* 
behandeln ASCII(0) als Ende des Strings und sind somit fr Unicode unbrauchbar.

In Anlehnung an Pascal wurden die pstrings implementiert, deren Lnge nicht 
durch ein Terminalzeichen definiert wird, sondern ber extra Struktureintrge.

Die pstrings haben folgende Struktur:





struct {

	int size;	/* absolute Lnge */

	int length;	/* belegte string-Lnge */

	char *string;	/* der String selber ohne Terminierungssymbol */

}



size ist dabei die Speicherkapazitt des pstrings, whrend length die tatsch-
lich belegte Lnge 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 Lngenange-
ben rechnen zu knnen.

In string.c sind die pstring-Funktionen definiert, die im Zusammenhang mit den 
Unicode-Strings im sendfile-Paket bentigt 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 aufwrts 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 Originalgre der Datei ohne Kompression.

csize ist die Gre der Datei, wie sie (komprimiert) bertragen wird.

tsize ist die tatschlich Anzahl der bertragenen Bytes.

flags sind die Dateiattribute fr 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 dazugehrige filelist.

*next ist der Zeiger auf das nchste Listenelement.



Die senderlist und filelists ergeben also zusammen folgende Struktur::

Diese Datenstruktur wird jedesmal neu erzeugt, wenn Informationen ber Spoolfi-
les bentigt werden. Diese verketteten Listen knnen in einem C Programm 
wesentlich einfacher ausgewertet werden, als da fr jede Information das betref-
fende Spoolheaderfile explizit ausgelesen wird



Der Spool selber wird in /var/spool/sendfile angelegt, wo jeder Empfn-
ger bei Bedarf, d.h. wenn zum ersten mal eine Datei fr ihn empfangen wird, auto-
matisch ein eigenes Spoolverzeichnis bekommt (im Source als userspool 
bezeichnet).

Im userspool befinden sich fr 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 - fr Featurewnsche und Betatesting

	Thomas Beisel - fr C Beratung, Postscripthexerei  und Betatesting

	Uwe Berger - fr Grundsatzdiskussion und Designhilfen

	Beate Herrmann - fr grundlegende Ideen, psychologische Betreuung und Betatesting

	Andreas Ley - fr jede Menge Hilfe bei obskuren C Problemen und fr die peername 
Funktion

	Shannon Miller - for his corrections to my english documentation

	Uwe Obermller - fr viele Vorschlge und Betatesting

	Bernd Onasch - fr C Beratung

	Ingo Wilken - fr die simplematch Funktion

ohne deren Hilfe die Realisation dieses Projekts unmglich gewesen wre.

4  Informationsverzeichnis

[1] Andrew Tanenbaum: Computer Networks

[2] Bettina Reimer, Paul Mller: Kommunikationssysteme auf der Basis des ISO-
Referenzmodells

[3] Kernighan, Ritchie: Programmieren in C

[4] Jrgen 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 Vorgnger zum Internet.

	DOS - Diskette Operating System		
Primitiver Diskettenmonitor und Interrupthandler fr i8088 PCs

	EBCDIC - Extended Binary Coded Decimals Interchange Code	
IBMs Zeichensatz fr ihre Grorechner.

	EOL - End Of Line

	FAT - File Availibility Table		
Filesystem fr DOS.

	FDL - File Definition Languange		
Filesystembeschreibungssprache fr 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 Verfgung zu stel-
len.

	MIME - Multipurpose Internet Mail Extensions		
Multimediaerweiterungen fr 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 :-)