Compared to the Bitnet there
was no asynchronous file transfer service defined in the Internet. The
existing standard file transfer, the ftp,
is a synchronous service: an interactive login on both ends of the file
transfer is mandatory for the user to set up a connection between both points.
If any user A wanted to send a file to another user B, the following (sometimes
inconvenient) choices were available:
- ftp to a recipient's account B
In this case one has to know the password of the recipient's account. If
A and B are not the identical person, severe questions of security arise and
it is not the method of choice. Even if account A and B belong to the
same person, the typed ASCII password characters for ftp access will travel
open (readable) as ordinary TCP packets through the network.
- ftp using an anonymous ftp server
The file has to be uploaded by A onto the anonymous ftp server using an ftp
session. After that A has to notify B about this using e-mail informing
this user about the fact that the file is ready for download now. B can get
the file now by doing another ftp transfer. This procedures requires a common
reachable ftp server, with an upload (write access) facility. During the
time the file resides on the anonymous ftp server it is open to anyone,
it may be readable, writeable, changeable or erasable.
- sending a file via e-mail
A is sending a file to B enclosed into an e-mail. According to
RFC 2822 a mail must contain characters from the NVT-ASCII character set, which is a subset of
the 7 bit ASCII character set. The file transfer via e-mail is limited to
English text documents or the text to be sent must be encoded properly, of
course using the NVT-ASCII character set. Encoding procedures like uuencode
or MIME are available. It is not a pleasure to
use either of them, they don't support all file ownership attributes and
they will enlarge the amount of data to be transferred by encoding. In
addition to this most of the existing MTAs are not designed to handle large amount
of data transfers.
To avoid all these disadvantages 1995 the
SAFT-protocol (Simple Asynchronous File Transfer)
was developed and the sendfile software
was created as a reference implementation for UNIX platforms.
Problems
After more than 10 years of installation on many hosts and practical usage
there have been shown several problems with SAFT/sendfile :
- the recipient needs a sendfiled installation on his host or an
interactive account on the saft-server
- the recipient's saft-server must be permamently online
- the tcp port 487 must not be blocked by any firewall or
ip-filter all the whole way from the sender to the recipient
- sender and recipient both need a local sendfile installation and
therefore a UNIX system, Windows is not supported at all
While the last point is theoretically solvable by implementing SAFT on
Windows (and other operating systems), the other points are not. They are
protocol inherent.
To overcome these problems a new protocol was introduced, completly web
based (HTTP / tcp port 80):
F*EX.
The end user only needs a web browser for access.
last updated: 2008-05-01
author:
Ulli Horlacher