Linux Certif

Toute la documentation sur la certification Linux LPI

uftpd

NAME

uftpd - UDP based ftp with multicast - receiver daemon

SYNOPSIS

uftpd [ -d ] [ -n ] [ -L logfile ] [ -T temp_dir ] [ -D dest_dir ] [ -t timeout ] [ -p port ] [ -M pub_mcast_addr [,pub_mcast_addr...] ] [ -I interface [,interface...] ]

DESCRIPTON

UFTP is a multicast file transfer program, utilizing a protocol based on Starburst MFTP. It is designed to reliably and efficiently transfer files to multiple receivers simultaneously, where either the intended receivers can be specified beforehand, or receivers can join the transfer when it is initiated. This is useful for distributing large files to a large number of receivers, and is especially useful for data distribution over a satellite link (with two way communication), where the inherent delay makes any TCP based communication terribly inefficient. UFTP is currently being using in the production process of The Wall Street Journal to send WSJ pages over satellite to their remote printing plants.

The data transfer consists of 3 main phases: The Announce/Register phase, the Transfer/NAK phase, and the Completion/Confirmation phase.

The Announce/Register phase begins by the server sending an Announcement over a public multicast address, which the clients are expected to be listening on. The server can either specify the hosts that are permitted to participate in the transfer (closed group membership), or it can allow any host that receives the announcement to participate (open group membership). The Announcement also contains information pertaining to the file to be received, such as the file name, file size, the total number of data blocks (blocks), and the number of data transfer sections (sections), which will be described in more detail later. Also in the Announcement is the private multicast address which the actual data is sent over. After the announcement, all subsequent communication from the server will be over the private address. Upon receiving the Announcement, the client sends a Registration back to the server informing it that it is ready to participate in the transfer. The server then sends a Confirmation to the client, acknowledging the registration. If the server specifies open group membership, it will wait for a period of time (based on network latency) to receive registrations from clients. For closed group membership, the server will wait a maximum period of time (again, based on network latency) for all specified clients to register. Any specified clients that do not register within that time frame will be flagged as "mute".

Once the Announce/Register phase is completed, the Transfer/NAK phase begins by starting the first pass of the data transfer. Data packets are sent continuously by the server at a rate specified by the user. Because UDP does not guarantee that packets will arrive in order, each data packet is numbered so the client can properly reassemble the file. After each data transfer section is complete, the server will then send a Done message, after which it will expect a Status message from each registered client. Since each client knows the total number blocks and sections as well as which packets were received, the client sends back the list of NAKs (negative acknowledgements) for each packet that was not received in that particular section. Once all sections have been sent, if the server has received a non zero number of NAKs from any client, the server will begin a second pass of the data, this time only sending the packets that were NAKed. The server will continue with subsequent passes of the data until all clients have either received the file or have timed out while the server was waited for a Status message.

When a client finishing receiving the entire file, it will send a special flag in the Status message for the last section alerting the server that that client has finished, thus starting the Completion/Confirmation phase. When the server receives this message from a client, it will then send a Confirmation to the client. Upon receiving the Confirmation, the client marks the file as complete and stops listening on the private multicast address for that file. This phase does not happen at the same time for all clients, but for each one as the clients receive the entire file. For example, if one client receives the whole file on the first pass of the data but another client sends back NAKs on the first pass, then the server will send a Confirmation to the first client but will then start a second pass of the data for the second client.

OPTIONS

The following options are supported:

-d

Enable debug mode. The process will run in the foreground and all output will go to stderr. If specified, the -L option is ignored.

-n

Prevents name lookups of the transmittor. Useful if name resolution takes a long time and delays sending of the registration message.

-L logfile

Specifies the log file. Defualt is /tmp/uftpd.log for UNIX systems, C:\uftpd_log.txt for Windows.

-T temp_dir

Temp directory in which files are received, then moved to dest_dir when complete. If omitted, files are received directly into dest_dir.

-D dest_dir

Destination directory for all received files. Default is /tmp for UNIX, C: emp for Windows.

-p port

The UDP port number to listen on. Default is 1044.

-t timeout

Specifies the maximum inactivity time in seconds before aborting the transfer. Valid values are 1-3600 seconds. Default value is 60 seconds.

-M pub_multicast_addr[,pub_multicast_addr...]

The list of public multicast addresses to listen on. Default is 230.4.4.1

-I interface[,interface...]

The name/address of one or more interfaces to listen to multicast traffic on. Also useful for receiving data on one interface and sending responses over another. Defaults to the interface assiciated with the client's hostname.

SEE ALSO

uftp(1)

NOTES

The latest version of UFTP can be found at http://www.tcnj.edu/~bush/uftp.html. UFTP is covered by the GNU General Public License. Commercial licences and support are available from Dennis Bush (bush@tcnj.edu).