dorkbox/udt

UDP-based Data Transfer Protocol

Breaking the Data Transfer Bottleneck

UDT is a reliable UDP based application level data transport protocol for distributed data intensive applications over wide area high-speed networks. UDT uses UDP to transfer bulk data with its own reliability control and congestion control mechanisms. The new protocol can transfer data at a much higher speed than TCP does. UDT is also a highly configurable framework that can accommodate various congestion control algorithms.

• Presentation: PowerPoint
• Poster: PDF

TCP

TCP is slow. UDT is fast.

UDT

UDT is developed by Yunhong Gu and others at University of Illinois and Google.

UDT C++ implementation is available under BSD license

Key Features

Fast. UDT is designed for extremely high speed networks and it has been used to support global data transfer of terabyte sized data sets. UDT is the core technology in many commercial WAN acceleration products.

Fair and Friendly. Concurrent UDT flows can share the available bandwidth fairly, while UDT also leaves enough bandwidth for TCP.

Easy to Use. UDT resides completely at the application level. Users can simply download the software and start to use it. No kernel reconfiguration is needed. In addition, UDT's API is very similar to the traditional socket API so that existing applications can be easily modified.

Highly Configurable. UDT supports user defined congestion control algorithms with a simple configuration. Users may also modify UDT to suit various situations. This feature can also be used by students and researchers to investigate new control algorithms.

Firewall Friendly. UDT is completely based on UDP, which makes it easier to traverse the firewall. In addition, multiple UDT flows can share a single UDP port, thus a firewall can open only one UDP port for all UDT connections. UDT also supports rendezvous connection setup.

Supported Platforms

ARCH/OS	Linux	Mac OSX	Windows
arm-android	???
arm-rpi	???
x86/i386	YES	YES	YES
x86-64/amd64	YES	YES	YES

Current Implementation

• Updates to UDT source 4.11 to fix some misc. CPU timing bugs in Linux (via the sourceforge help forum).
• Cleaned up source for cross-compile environment in linux
• Cleaned up preprocessor symbols and removed deprecated
• Strips unneeded symbols, drastically reducing size
• Static linking to mingw libraries for windows build

udt's Issues

mismatched delete fix

change line 202 of core.cpp from
delete m_pPeerAddr;
to
(AF_INET == m_iIPversion) ? delete (sockaddr_in*)m_pPeerAddr : delete (sockaddr_in6*)m_pPeerAddr;

Modified congestion control does not work

I extend the default congestion control as follows:
public class Test extends CCC{
public Test(){
System.out.println("I am here!");
}
public void setCwnd(int win){
setCWndSize(win);
}
}

I set the customized CC for the SocketUDT instance as follows:
SocketUDT socket = new SocketUDT(TypeUDT.STREAM);
socket.setOption(OptionUDT.UDT_CC, new FactoryUDT(PCC.class));
socket.connect(new InetSocketAddress("127.0.0.1", 5555));
Object obj = socket.getOption(OptionUDT.UDT_CC);
Test test = (Test) obj;
test.setCwnd(1200);

The point is after this instant the congestion window remains fixed at 1200. I transfer huge files but the window does not change. The expected behavior here is that the default congestion control works as usual as I have not overridden any of the superclass methods. Let me know if this is a bug or I am getting something wrong here. Thank you.

connection broken error

on windows client I get connection broken after calling recvmsg after 3 to 4 minutes

timeouts not working as expected in datagram mode

OK; we've been using UDTv4 implementation for quite some time now, still to our surprise we ran into some issues when trying to tweak the performance. We've been using UDT in data-gram mode.

To our surprise, the recvmsg function waits for the entire period of UDT_RCVTIMEO even if there are tons of messages already in the buffer.. is it by design? It's very easy to reproduce (..) just set timeout to say 15000 ms (..) send a few messages 40 bytes each (..) and see the socket blocking for minutes.

That results in extremely undesired scenarios (..) we've been seeing the receiving socket seemingly 'receiving' data long long after... the sending node... went offline. As perceived by the upper layers of the software. I mean come on, the variable is called a timeout.. not a polling time or whatever.

So if we set UDT_RCVTIMEO to a small value say 100ms .. is it just the polling time for results and would big messages be retrieved in any case? or is it the time after an entire datagram was not retrieved then the function returns an error?

typo in udtCommon.h

Looks like typo

UDT/src/udtCommon.h

Line 180 in b78bf81

pthread_cond_t m_TickCond;

mb it is supposed to use udt_pthread_cond_t instead of pthread_cond_t

DTLS Support

Is there a way to however use the UDT library in combination with DTLS ?