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 has been used in the production process of The Wall Street Journal to send WSJ pages over satellite to their remote printing plants.
UFTP runs on both UNIX/Linux and Windows. There are links at the bottom of this page for the source code in both .zip and .tar format, however the actual code is the same for both. In the interest of keeping a common code base, a side effect is that the Windows version of the receiver will leave a Command Prompt open. This can be worked around by using hidedos, a free utility created by LANDesk for this purpose. This is included in the distribution, as well as instsrv and srvany (from the Windows Resource Kit) which can be used to run the client as a Windows service. See the enclosed readme file for details on using these utilities.
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.
uftp [ -U ] [ -R txrate ] [ -W txweight ] [ -m min_time ] [ -l latency_level ]
[ -t ttl ] [ -I interface ] [ -p port] [ -H host[,host...] ]
[ -L logfile ] [ -M pub_multicast_addr ] [ -P priv_multicast_addr ] file
-U-R txrate-W txweight-m min_time-t ttl-l latency_level-I interface-p port-L logfile-H host[,host...]-M pub_multicast_addr-P priv_multicast_addrfile
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...] ]
-d-n-L logfile-T temp_dir-D dest_dir-p port-t timeout-M pub_multicast_addr[,pub_multicast_addr...]-I interface[,interface...]