Reliable, fast UDP-based data transfer protocol that outperforms TCP

http://udt.sourceforge.net/

by aux-k • 17 years ago

48 14 17 years ago

udt.sourceforge.net

clistctrl• 17 years ago

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.

josephruscio2• 17 years ago

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• 17 years ago

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

josephruscio2• 17 years ago

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 :-(.

herf• 17 years ago

At least HTTP keepalive helps slow-start once you've "warmed up" a connection to a particular server.

whimsy2• 17 years ago

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

m0th872• 17 years ago

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• 17 years ago

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

whimsy2• 17 years ago

Ah, yes, μTP is what I meant.

Yrlec• 17 years ago

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

dedalus• 17 years ago

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• 17 years ago

Crystal

Reliable, fast UDP-based data transfer protocol that outperforms TCP

Related Stories