کد:
http://www.tcnj.edu/~bush/uftp.html
UFTP - UDP based FTP with multicast
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, and other users have used it to send to over 1000 receivers.
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.
Upgrade Notes: As of version 2.8, the uftp server is not backward compatible. When upgrading to verison 2.8 or later, all clients should be upgraded before servers.
Protocol description
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.
Usage
The syntax for the server is as follows:
uftp [ -U ] [ -R txrate ] [ -W txweight ] [ -m min_time ]
[ -n ] [ -z ] [ -l latency_level ] [ -c client_wait ]
[ -L logfile ] [ -t ttl ] [ -I interface ] [ -p port ]
[ -H host[,host...] ] [ -B buf_size ]
[ -M pub_multicast_addr ] [ -P priv_multicast_addr ] file
-USend file unicast to a single host. This requires the -H option with a single host specified. The -t, -M, and -P options are ignored as they are all related to multicast. -R txrateThe transmission speed in Kbps. Specifying -1 for this value results in data being sent as fast as the network interface will allow. Using a value of -1 is recommended only if the network path between the server and all clients encounters is as fast as the server's local interface, and works best in a gigabit environment. Default is 1000 Kbps. -W txweightSets the maximum file transfer time, expressed as a percentage of the optimal time. If a value of -1 is given for the -R option, a speed of 100Mpbs is used for the purpose of calculating the max time. Valid values are 110%-10000%. Default value is 300%. -m min_timeSpecifies the minimum file transfer time. This value takes precedence over the maximum time, if it is greater. Valid values are 0-3600 seconds. Default value is 10 seconds. -t ttlSpecifies the time-to-live for multicast packets. Default is 1. -nPrevents name lookups of the receivers. Useful if name resolution takes a long time and delays receiving of the registration messages. If used with open group membership, names of receivers are not looked up when discovered. If used with closed group membership, does not look up names specfied with -H (only IP addresses will be accepted). In the later case, -n MUST appear before -H for this to take effect. -zTells clients to make responses small as possible. Useful for when you have a large number of clients and want to minimize the backtraffic. Clients at version 2.9.2 and earlier ignore this flag. -l latency_levelSpecifies one of several predefined network latency levels. Valid values are 1, 2, 3, and 4. Use 1 for low latency networks, such as a local LAN, and use 4 for high latency networks, such as satellite or global WAN. Default is 3. The default should be used if communicating with an older version of the client for backward compatibility. -c client_waitSpecifies the time in milliseconds that clients will wait for server responses to registrations and completions. Useful in situations where the server expects to have a large nuber of clients (>100) over a low speed link, resulting in the server taking several seconds to process and respond to them all. -I interfaceThe interface to send the data from. Can be specified either by interface name, by hostname, or by IP. If not specified, the default system interface is used. -p portThe UDP port number to send from. Default is 1044. -L logfileSpecifies the log file. Default is to write to stderr. -H host[,host...]The list of receivers for closed group membership. If not specified, then open group membership is used. -B buf_sizeThe size in bytes of the UDP receive buffer to use. Valid values are 65536-1048576100 (64KB-100MB). Defaults to 262144. -M pub_multicast_addrThe public multicast address to announce on. Default is 230.4.4.1. -P priv_multicast_addrThe private multicast address that the data is transferred to. Any combination of the second, third, and fourth octets may be replaced with the letter 'x', resulting in a random number being chosen for that octet. Default value is 230.5.5.x fileThe file to send. This field is required.
The syntax for the client is as follows:
uftpd [ -d ] [ -n ] [ -L logfile ] [ -T temp_dir ]
[ -D dest_dir ] [ -t timeout ] [ -p port ] [ -P pidfile ]
[ -B buf_size ] [ -M pub_mcast_addr[,pub_mcast_addr...] ]
[ -I interface[,interface...] ]
-dEnable debug mode. The process will run in the foreground and all output will go to stderr. If specified, the -L option is ignored. -nPrevents name lookups of the transmitter. Useful if name resolution takes a long time and delays sending of the registration message. -L logfileSpecifies the log file. Defualt is /tmp/uftpd.log for UNIX systems, C:\uftpd_log.txt for Windows. -T temp_dirTemp directory in which files are received, then moved to dest_dir when complete. If omitted, files are received directly into dest_dir. -D dest_dirDestination directory for all received files. Default is /tmp for UNIX, C:\temp for Windows. -p portThe UDP port number to listen on. Default is 1044. -P pidfileThe pidfile to write the daemon's pid to on startup. Default is no pidfile. -B buf_sizeThe size in bytes of the UDP receive buffer to use. Valid values are 65536-1048576100 (64KB-100MB). Defaults to 262144. -t timeoutSpecifies 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...]Lists one or more interfaces to listen to multicast traffic on. Interfaces can be specified either by interface name, by hostname, or by IP. When receiving a closed group membership request, the client will participate if any of these interfaces matches an IP in the announcement. The default is to listen on all active non-loopback interfaces. NOTE: Since Windows doesn't have named interfaces (not in the sense that UNIX-like systems do), only hostnames or IP addresses are accepted on Windows. ------------------------------------------------------------------------------------------------------------------------------------------------------
و نتیجهUFTP برای WiFI
کد:
http://www.aes.id.au/?page_id=12
I’ve worked with 802.11b (Wi-Fi) for a number of years, and I found myself wondering if there was a better way to transfer files between computers at home than FTP. FTP uses the TCP protocol, which does not always perform ideally when both ends of the transfer are on the same Wi-Fi network. This page lists the results of some tests I did, and my conclusion was that, yes, you can do better than FTP but there are no widely available, consumer-grade tools that you could use.
Experimental Set-up
There are three network nodes in this scenario: the access point providing the Wi-Fi coverage (call it AP), a Wi-Fi enabled source (call it node A), and a Wi-Fi enabled destination (call it node B).
Access Point (AP): My access point is a BT Voyager 2000, sourced in the U.K. It provides 802.11b (not 802.11g) signal, and I’ve had little trouble with it.
Node A: Files were transfered from a Linux laptop. It’s a Toshiba Portege 3840CT with 192MB of RAM, running Linux 2.4.25 and a Debian Sarge distribution.
Node B: Files were received by a Windows laptop. It’s a Toshiba TECRA A3 with 512MB of RAM, running Windows XP Pro SP2. Both nodes A and B were within 3m of the AP and were separated by 2m from each other.
File: The same file was sent in each test, and was a compressed Zip file of length 11,844,459 bytes (11.3 MB). It was big enough, with sufficiently random contents, to enable any network artifacts to show themselves. I guess I should’ve sent the same file multiple times to check my measurements, but when I did there weren’t any changes, so all measurements were the results of a single test.
Tests and Results
To give you an idea of the speed of my network, a simple ping test from A to B showed a consistent RTT of 3.6ms. All nodes were transmitting at the nominal maximum 802.11b rate of 11Mbps (effective speeds were lower than this of course).
FTP: The first test was to see how long it took FTP to transfer the file between A and B. B was running FileZilla Server 0.9.10beta. The Linux command line FTP tool on A reported that the transfer took
38.8s
FSP: I was pretty convinced that I wouldn’t better that time using an TCP based approach, so I next used a UDP based tool.
FSP is reasonably popular, albeit mostly within the less reputable parts of the Internet, but was designed as a way to set up file servers that could service large numbers of downloads without overwhelming a link. As a consequence, it has speed-limiting aspects which would have impacted the results. B was running FSP server 2.8.1b24 under Cygwin (no special tweaking). The “date” tool was used on Linux to measure the transfer time, which was
75s
netcat: To remove any speed-limiting, I tried the swiss-army network tool
netcat. It has a UDP mode, and allows pure transfers without any pesky additional overheads. I used netcat v1.10 but unfortunately the transfer failed to work. The network dropped most of the packets, and the received file was woefully incomplete. This disqualifies it, of course. For interest’s sake, the sending took
18s
TFTP: Another UDP-based transfer approach that’s pretty mainstream is TFTP. It’s used for low-level file transfers within networks, rather than across the Internet, and is designed for simplicity rather than speed, security or flexibility. I put the SolarWinds TFTP Server v8.27 on B, and the command line TFTP tool on A reported that the transfer took
135.5s
UFTP: Now I was beginning to doubt that I could better FTP, but then I came across
UFTP. This obscure UDP-based tool is apparently used by the
Wall Street Journal and is designed for transfers over wireless networks (primarily satellite) with long latencies. As it’s public domain, I
modified the source to (barely) compile under gcc and got it running under Windows/Cygwin and Linux. Using the “-R 3000″ option to force a 375kB/s transfer speed, it reported a successful transfer in only
31.6s
Conclusions
Well, UFTP is the winner, being 18% faster than FTP on a 802.11b network. I don’t doubt that a UDP-based tool specifically tailored to Wi-Fi file transfers wouldn’t be slightly faster still. However, UFTP isn’t for everyone, and I couldn’t find a simple consumer-grade tool that was faster than FTP.
Admittedly, I didn’t spend much time trying to tweak TFTP or FSP. It could’ve been that there were settings that would allow them to approach UFTP’s performance. Personally, I suspect not though.
TCP isn’t totally defeated though. There are many TCP options which would support better transfer speeds under Wi-Fi, but this would require widespread operating system support. In my scenario both Linux and Windows would have needed to support the same such options, which is unlikely. But, maybe one day…
Finally, if the transfer is to/from a wired node and a wireless node, then TCP performance is likely to be close to UDP. These results are dependent on the set-up being transfer between A and B, i.e. two wireless nodes on the same Wi-Fi network.
------------------------------------------------------------------------------------------------------------------------------------------------------
البته به بزرگی خودتان این حقیر را ببخشید که وقت ندارم باقی سایت ها را معرفی کنم.
LinkBack URL
About LinkBacks
