…And you learn something new every day.

Without going into too much detail about WHY I want something like this, I was recently given a project to research. This was pure research for me, because I didn’t have to buy anything, or even suggest a particular product - I just had to find out what was out there, and how much it cost (or how much it would cost to make someone else do it).

This is a rarity in my field. Like so many things in my new job at Nexon Vancouver, I’m given some specs, and then told to figure it out. Sometimes I’m also the guy pulling the trigger, and actually (gasp) ordering things (What? No purchasing department? No asset management department? It’s just… US?)

Most of you folks don’t understand, this is extremely rare for Olde Timey IT folks like m’self: I’m used to finding the thing that I think will work best for the purpose, and then being told it’s too expensive, or isn’t sold by our “Value Added Vendors,” so I have to pick it out of the list of things they DO have. Usually completely ignoring the viability of the product, or the technical know-how to run it. I often used to find myself saying “Then why’d you ask me? You obviously don’t want my answer.”

Of course, I’d mutter that under my breath, or after I hung up, or while standing on the roof of the building.

Anyway, yeah, so I’m told we’re looking for some kind of “Health Check” and “Round Trip Information” for packets traveling on the Internet, but not your usual Ping/Traceroute sorta thing, where we ask for a path from point A to point B, and then bounce packets off every stop between those two points. No, that’d be simple, and what we want is something else.

Normal traceroute will check latency (or lag) between YOU and every point on the route from A to B. What we wanted here was to know how happily Point C was communicating with Point B. There’s some deprecated information about using hosts lists for traceroute, and it seems for the most part, those sorts of requests are ignored, as it’s way too easy to request that Point C bludgeon point B with truckloads of craziness, without implicating Point A (the requestor) at all.

That sorta thing is what knocks over Ebay or Yahoo for an afternoon, once the script kiddies get ahold of it.
So I bumber around the net a little, and come up on some of the old standbys from my days as an on-site tech. VisualRoute is still out there, and will happily track from ONE place other than You, but that doesn’t tell me things like how well New York is talking to LA, or which major high-speed provider isn’t current getting along nicely with the rest of the net.

See, the net was designed to find the fastest, healthiest, least-likely-to-be-gone route across the net. Very similar to GoogleMap’s “directions” system, which will often do things let tell you to get onto major highways in order to get to the grocery store that’s six blocks away. Why? Because it’s faster, but that doesn’t mean simpler. Most routes are determined by an algorithm of local-bigger-biggest-farthest-biggest-bigger-local, sorta like sending snailmail to the guy next door to you in Vancouver, and it going to Ontario first for “sorting.”

So the net is pretty good at that, even if it’s not terribly smart about it. It’s consistent, in that the data gets there, eventually (give or take a few milliseconds), and everybody’s happy. The problem is that there NO assurance that the return path to you has anything to do with how it’s sent. It’s a boomerang, making this big circular route based on which way traffic happens to be running downhill fastest, not a yoyo, which comes back on exactly the same string it went out on.

I’ll add more to this later, but I’m writing on my Blackberry, which isn’t really conducive to long drawn-out rambles.