As a developer, when you want to have one machine talk with another (and you want your packets delivered reliably and in-order) you open a TCP connection.  Ah, TCP, that tried and true communication mechanism that probably drives most of the Internet today.

While speeds have come a long way, packet loss and latency are two very real factors that can really eat into your TCP throughput.

Packet loss you say?  This is 2010!  Well, turns out that overloaded switches like to drop packets as a form of congestion control.  So yes, there is still packet loss in 2010.

Latency from my house is usually in the 50-100ms range.  And if you are going overseas you are looking at least 100ms…

I’m not a networking expert, but I know enough to understand this picture:

When developing programs and services that are contained in 1 data center, you are often dealing with near zero latency and packet loss.  Once you are talking mobile or multiple data centers, you are living in the short parts of that graph.

There are tricks people try, like multiple streams, so the effect of loss doesn’t impact the tcp window as much.  This is how programs like GridFTP are able to make maximum use of the network.  The theory is summed up nicely in this picture:

The TCP sawtooth is less impacted per smaller stream so the overall variation is less than putting all your eggs in 1 basket.  Interesting idea and will be available to us Java programmers when SCTP becomes more baked in Java 7. But this assumes that your problem CAN be broken into multiple streams.

Many have tried building their own solutions on UDP, but they really move the flow control and packet delivery guarantee into the Application layer.  Is this a bad thing?  Well, it is if I have to write it.  After all, I wouldn’t presume to think that I could do a better job than people who spend all their time researching this stuff.

Which brings me to a couple of years ago when I became aware of a project run by a researcher at UIC called UDT.  Among other things, it is an attempt at an alternative flow control with things like congestion avoidance in mind.  The paper is interesting and can be found here.

So the idea is to take this:

And turn it into this:

Professor Gu has a great powerpoint presentation here (which these pictures are from) that shows the highlights if the original paper is too dry a read.

The implementation, found at http://udt.sourceforge.net/ is C++, wasn’t a simple plug-in replacement for TCP in a Java application.  There were some earlier attempts a JNI wrappers, but we all know how that goes in practice.  At the time, our project didn’t have the bandwidth to write a native Java implementation so using UDT went on the shelf…

Looking recently, it seems that somebody else thought a native Java implementation drop-in was a good idea and has made the code available here.

Now I’m not suggesting that UDT should replace TCP for general use, but for some applications (large data transfers on high speed/high latent networks) it looks like a nice alternative…

Might be worth a look again…

Well, I finally broke down and created a personal blog.  While I’ll sometimes post useless information or observations to the Group Inanity Blog or to my Twitter feed, it seems that I needed a place to put things of a less inane nature.

So 14 years after signing up for the goofy.net domain (so I could have a vanity/constant email address) there is finally some content here that doesn’t look like a parked domain.

Lord help you all…

Luckily, the Internet is now so full of noise, this will most likely go largely unnoticed.