

Reliable, fast UDP-based data transfer protocol that outperforms TCP - aux-k
http://udt.sourceforge.net/

======
josephruscio
TCP's slow-start and exponential backoff algorithms are absolute murder when
your pipe has a large bandwidth-delay product. There are a whole slew of UDP-
based implementations (and a couple TCP variants) targeted at large data
transfers over such pipes.

The underlying problem is trying to achieve fairness not only between
instances of the new protocol itself (which this implementation and many
others claim), but also fairness with instances of the legacy TCP protocol
(this protocol's claim seems to be a little weaker here).

~~~
sayrer
Successful businesses have been built in this space. Netli worked this angle
and got acquired by Akamai.

~~~
josephruscio
Yep. FastTCP is a pretty elegant algorithm that happens to covered by all
sorts of patents. Was a company behind it as well that seems to still be doing
OK (FastSoft). Unfortunately won't be turning up in Linux et al due to those
angles :-(.

~~~
huhtenberg
There is also TCP/Vegas, which is based on the same idea, as good as FastTCP
for all practical intents and purposes, comes with Linux 2.6 and unencumbered
by the patents.

------
dedalus
I played with this and its not faster than other TCP. In fact my
implementation of NetBLT (<http://www.faqs.org/rfcs/rfc998.html>) blows this
one out of water.

An enhanced TCP that we use internally stacked up as follows w.r.t Normal TCP
and FastTCP (times are for retreival of a 180KB file)

RTT Normal TCP FastTCP InternalTCP 48 548 205 180

94 984 359 232

140 1546 593 334

188 1985 797 381

UDT,for different latencies clocked as follows

48 - 3.498s 94 - 3.262s 140 -3.640s 188- 3.987s

Hope that makes it clear

~~~
bham
Crystal

------
Yrlec
It would be cool if someone intergrates this into Google's libjingle
([http://code.google.com/intl/en-
US/apis/talk/libjingle/index....](http://code.google.com/intl/en-
US/apis/talk/libjingle/index.html)) to get efficient NAT-traversal.

------
whimsy
Is this the same uDP that was in bittorrent mainline blog post recently?

~~~
m0th87
no, that's μTP. UDP is a 30-year-old protocol:
<http://tools.ietf.org/html/rfc768>

it's substantially faster than TCP because it doesn't provide any guarantees
(e.g. error checking); consequently it's more difficult to work with. this
protocol builds on top of UDP to provide all of the nice guarantees that TCP
does.

~~~
blasdel
Like most people, you've missed the point of TCP. Error-checking is trivial --
congestion control is _HARD_

~~~
m0th87
This is true, but my understanding is TCP's congestion control mechanism is
far from ideal and the root cause of its performance problems.

------
clistctrl
This is really cool, I had tried making something like this a few years ago
when I was working in a lab. Mine worked, but I never really got the time to
perfect it.

