i suck at computers

21/12 Apple strudel, and other things that don't traverse NATs.

NAT, or Network Address Translation, is the absolute bane of my existence (next to Barbara Walters of course). It finds itself near the upper-ends of lists like "technologies that frack my network code" and "reasons IPv6 will save us from ourselves," but what many of you don't know, is that NAT was designed by giant salmon with a bad attitude. Why, if it weren't for NAT, we might not get to enjoy such wonderous atrocities like "Universal Plug and Play" (UPnP).

UPnP, oh how I hate you, let me count the ways:

• Runs over HTTPU.
  HTTPU is a silly acronym for an even sillier concept, HTTP over UDP which isn't really a standard, but an outdated (2001!) internet draft (draft-goland-http-udp-04.txt).
• Over-engineering? Is there a better modifier than "over" we can use?
  Imagine what would happen if SOAP, and some network engineers got hammered and made a bastard love-child in the back seat of a 1993 Buick Le Sabre, UPnP would be it. It exists in this weird realm of trying to cover device and service discovery and advertisement, and about 13 other things that don't need to exist but do.
• Description. C'mon, are you serious?
  After "addressing" and "discovery" in the UPnP hall of horrors, it's time for description. This part of the freak show is where "we" (as in our machine/device/etc) know about "interesting devices" but don't know much about what those do, so "we" request a "description" after which, the other device sends us 8-10 pages of XML (double spaced) telling us about the hardware, the services, and anything else we might ever care to know about (mood, mother's maiden name, etc).
• Internet Gateway Device
  This is where the NAT happiness happens, I'm pretty sure it's just as miserable as the rest of UPnP, but i'm not willing to read a couple hundred pages of documentation on why IGD sucks, but if the couple hundred pages wasn't enough to convince you, I've got a note from my mom confirming it.

"Aren't there alternatives?" I hear you quip, why of course! In the realm of NAT mapping protocols there exists another contender which I will hit on in a later posting, NAT-PMP, but other than that, UPnP is pretty widely adopted.

On the other side of the fence exists NAT hole-punching protocols, such as STUN, which helps coerse UDP packets from one side of a NAT to the other side with relatively few bumps and bruises. The downside of using a protocol like STUN, is that is is based on UDP, so unless you receive an ICMP error message your packets may just continually disappear into the ether and your application wouldn't be the wiser (unless you implement some TCP-like error-checking and packet ordering on top of UDP). For most applications that use STUN such as VoIP, this isn't a major issue. For other applications where data integrity is a major issue, UDP in general is most likely not on the table to begin with. Which leaves most folks (like me) working with something like STUNT which extends STUN's functionality to add support for TCP packets.

Nothing is fool-proof however, NAT is such an abomination that there exists a good proportion of NAT devices in the "real world" that misbehave, preventing hole-punching protocols like STUN(T) from getting through to allow clients behind the NAT to perform the actions they wish to. The situation worsens if you're behind two NAT devices (which I was in my last apartment, BLECH!), as no amount of UPnP, hole-punching, or Merry Christmas sugar cookies will allow traffic to traverse in the fashion which some applications (iChat AV for one example) need in order to function.

Did I mention that I abhor NATs? Grumble.

[tags: nat, nat-pmp, upnp, stunt, stun]

19/12 Reticulating Spines and Other Wastes of Time

I just posted a message to the monodevelop-list of the same title, but I figured since there's about 7 people on that mailing list, I'd better post to my blog to ensure maximum coverage (9 people!). The actual mailing list posting can be found here, but I'll summarize.

The splash screen loading messages in MonoDevelop are about as exciting as a 1040 tax form, so I created a patch to randomly display more interesting messages like:

• "Nerfing Pirates, Buffing Ninjas..."
• "Zesting Oranges...
• "Adjusting Radiation Levels..."
• "Locking Boxes..."
• "Burninating the Peasants..."

There's quite a few more, and it's thoroughly entertaining to watch. To get an idea of what it looks like, check out this screenshot on flickr.

The behavior is triggered by an environment variable "RETICULATE", so setting the environment variable will turn on a more exciting splash screen when you start MonoDevelop. Starting it from a build set of sources, you would call: tyler@onion:~/sources/mono-project/monodevelop> RETICULATE=1 make run

The patch: ProgressTracker.cs.diff

[tags: monodevelop, mono, burnination, reticulatingspines]

15/12 BuildFactory 1.0.12, Oops.

This morning I pushed out an update for BuildFactory v(1.0.12). This minor update fixes some minor logic errors with the pre-/post-build scripting subsystem (NSTaskDidTerminateNotification you are not my friend!). It is another procrastination release, as I still don't want to bump to 1.1 just yet, but it's certainly a bit more stable than the previous release. Changes include:

• Scripts no longer run on clean operations
• Advanced directory options properly linked
• Infinite loop, infinitely fixed

Fairly minor update, but some important fixes.

[tags: bleep, buildfactory, update, nstask]