UDT Stands for UDP-based Data Transfer. It can refer to both the UDT protocol and its implementation (the UDT library). Basically, UDT is built on top of UDP by adding reliability control and congestion control.

2. Who developed UDT?

UDT is a research product of the National Center for Data Mining (NCDM) at the University of Illinois at Chicago. The project was supported in part by US National Science Foundation, US Department of Energy, and US Army.

3. Why and when do I need UDT?

The original (and major) purpose of UDT is to provide a high performance transfer interface to distributed data intensive applications over a wide area network, where TCP seldom works well for efficiency and fairness reasons. It can also be used in other situation where TCP is not suitable (e.g., multimedia streaming, firewall punching, partial reliability, etc.)

There is no explicit standard to determine when to use UDT or when not to. Generally speaking, if you are not satisfied with TCP's performance or functionality, UDT is probably what you need, especially in high speed networks where a small number of bulk sources share the abundant bandwidth.

4. My application uses UDT, can I run it over a traditional low bandwidth network, or even on the public Internet?

Yes, you can do it. But please be aware that your application may use a large amount of bandwidth and may be regarded as attack or improper use of network by ISPs and firewalls. In addition, UDT's impact on the Internet is not comprehensively tested yet.

5. Why can't I reach the announced high throughput with my Gigabit NIC?

There are many factors that can affect the throughput, especially for Gigabit NICs.

First of all, you need to test it using some other benchmark tools like IPerf. They will give you the highest performance for the current configuration. If UDT has similar performance, then it is all right, and you need to tune your network settings.

If UDT's performance is much lower than the performance obtained from the benchmark, try to modify the UDT options.

Finally, your applications affect the transfer speed. Any data intensive applications can cost substantial CPU time in computing and memory replication, which will affect UDT's performance. Try to test the throughput with the example applications in the UDT SDK.

6. Can you give me some hints in tuning the performance?

Please read the Configuration section of the UDT Tutorial for the answer. The default parameter should work fine for most cases.

7. I use UDT for file transfer, but it seems significantly slower than memory-memory transfer. Why?

Performance of file transfer is often limited by the bottleneck speed of disk IO. Besides, disk IO is often bursting and cause difficulties for the congestion control of transport protocols. UDT has been thoroughly tested for the disk-disk transfer scenario. Try to use some benchmark software to test your disk performance.

8. When I run the example applications, it prompts for missing library error. What happens?

You forget to set the system environment of library path. On Linux/BSD/UNIX, use "export" or "setenv" to configure the LD_LIBRARY_PATH environment variable so that it contains the directory having the libudt.so file. On Windows, copy udt.dll file to the same directory containing you UDT applications (this usually also works for Linux/BSD/UNIX by copying libudt.so to the current working directory).

9. Does UDT care about the byte order conversion between different platforms?

No, the application should care about the conversion itself. However, UDT does work between different platforms even with different byte orders.

10. Why can't the UDT connection be set up? Why is the listen or connect call fails?

The most likely reason is that one of the machines is behind a firewall. You can change the firewall settings if you have the privilege or do something in the UDT program to bypass the firewall. Note that UDT has same semantics as TCP and generates UDP traffic in both directions. UDT3 also provides rendezvous connection setup in order to punch firewalls.

Another reason is that at least one of the server or client sides has multiple addresses, and UDT is bound to an address different from what you use in the application. To solve the problem, explicitly set the IP address in bind call.

There can be other reasons, such as domain name lookup failure. Try to use an explicit IP address if possible.

11. Is UDT connection secure?

No. If you need a secure connection, you should add other mechanisms on the top of UDT in your application.

12. Why does my application often have packet loss even the throughput is much lower than the available bandwidth?

Packet loss can be caused by a busy receiver. For example, if there is large block memory copy, arriving packets will be dropped because the CPU does not have enough time to process them. Try to avoid large block copy during data receiving and try to use blocking receiving to alleviate the problem.

13. Is UDT TCP friendly?

TCP friendliness is an obscure concept. Please refer to UDT technical reports for detailed information on the competition between UDT flows and TCP flows.

14. What copyright and license issues shall I be aware of when using UDT?

The UDT library developed by us is copyrighted to the board of trustees of the University of Illinois at Chicago and is published as open source software under Lesser GPL (LGPL). You can find a copy of LGPL within the UDT release. If you want to use UDT in commercial products and are not comfortable with LGPL, you should contact us to discuss the license issue in a case by case basis.

15. Is UDT only suitable for bulk data?

No, UDT can transfer a data buffer from one single byte to multiple tera-bytes, as long as your system can provide enough resources. However, UDT is indeed optimized for bulk data, and it may not have any better performance for message signaling applications.

16. What's the relationship between UDT and SABUL?

UDT is the successor of SABUL. It removes the TCP connection from SABUL and enhances the congestion/flow control.

17. Where can I find help regarding to the use of UDT library?

If you cannot find answers in this documentation, please go to the UDT home at sourceforge.net and post your questions. In order to help more users easily find answers about UDT usage and help increase the activity of this project, please post all general questions to the souceforge forum or send them to the sourceforge mailing list. The mailing list and the forum is monitored by the UDT developer and your questions will be replied as soon as possible.

18. What background knowledge is necessary in order to use UDT?

Knowledge on socket programming and C++ is necessary. Knowledge on TCP is a plus.

Why UDT consumes so much memory even if I just send a small file?

Because UDT was originally designed for transferring very large dataset over high speed long distance networks, the default buffer size is set to 20MB, just enough for most bandwidth-delay product in these environments. You can, however, use "setsockopt" to set a smaller buffer size should your application works only in relatively low bandwidth (<10Mb/s) environments.

When I try to start the example application, an error of "No buffer space available" occurs, what happened?

This error usually happens on BSD systems. The default maximum socket buffer size on BSD systems is usually much smaller that the default UDT socket buffer size. To eliminate this error, either use "setsockopt" to set a smaller UDT buffer size, or change the default OS value to a larger one.