Hiya. I'm one of the Copilot developers, so I thought I'd answer some questions.

The Akamai IPA thing is not "magic," and none of us think it is, but dumping a rambling technical diatribe onto Joel's blog would alienate a lot of its readership. We're talking on Hacker News now, though, so read on if you're curious what's going on and how Akamai's helping us.

There are two ways that an Internet connection can be slow: you can have insufficient bandwidth, and you can have bad lag. With Copilot, we're already doing just about all we can to minimize bandwidth with our raster-based format. We've got pretty fast compression algorithms, we dynamically pick compression levels on-the-fly, and because we're using existing VNC code under-the-hood, we do a good job sending across just the differences in your screen. Switching the protocol to be command-based (like X, or RDC) is the only real way left to improve bandwidth--and with our current developer resources, that's simply not feasible. The good news is that this discussion mostly ends up being a non-issue: relatively few customers actually have bandwidth saturation issues, and internet connection speeds are steadily increasing, so bandwidth's not generally a big concern.

That leaves lag. Most of the time, when customers complain Copilot is "slow," they're complaining about lag. Copilot gets lag in two places: on the network connection itself, and on the glorified echo-server (which we call the Reflector) that we use when none of our firewall bypass tricks work. We try really hard to ensure you connect directly, but sometimes you simply can't, so it's very important that the Reflector be very efficient.

About a year ago, I did some analysis to see how we could speed things up, and found that our Reflector introduced nearly a quarter second of lag in some circumstances--not terribly surprising, since it was literally the very first thing I wrote at Fog Creek, back when I was an intern. The design used one dedicated thread per connection with blocking I/O. On Windows, that type of design is very slow. I took a few weeks out and rewrote the Reflector to use overlapping I/O with thread pools. The resulting Relector now introduced virtually no lag, and as an ancillary benefit, used a fraction of the CPU and proved far easier to maintain. For the time being, our customers were really happy.

Unfortunately, over the last year, customers have complained that our performance is still sub-optimal. The problem's been compounded because firewalls are getting smarter, which is making our firewall bypass tricks fail more and more often. Even if the Reflector truly introduced no lag whatsoever, you're still gaining a lot of lag when you have a reflected connection, simply because your data has to make a full round-trip from you to the reflector to the other party.

That's where Akamai comes in. The main thing that Akamai's doing for us is dramatically reducing lag between our data center and our customers. That means your keystrokes get to the other side faster, the machine starts responding faster, and you get the graphical updates faster. Even though bandwidth hasn't increased, your Copilot experience suddenly becomes far more pleasant, because the machine feels much more responsive.

We're still monitoring our clients to see how much of a difference Akamai's making, but in general, what we're seeing is great. The bitrates for Akamai-enabled connections has gone way up, since the higher response rate allows our users to get more done in less time, and we've been able to pull of some stunts--like watching YouTube videos via Copilot--that were previously impossible over reflected connections.

Akamai's not a panacea, and what they're doing isn't magic, nor is it useful in all circumstances, but for a real-time application such as Copilot, it can yield a pretty dramatic improvement in exchange for very little developer time.

[EDIT: Fixed some snafus I caught when re-reading.]