A lot of people know that major Cable Internet Service Provider and Media Mogul Comcast  has a bad rap. Not that it isn’t undue, while they are one of the faster ISPs available in the United States (arguably the third world of Internet Access among the civilized world in terms of choice and average speed), they have a uniqueness (although when compared to the likes of EA, AT&T, HP, Ubisoft, and others… seems just par for the course) in their bad customer service and oftentimes their actual product performance.

But this isn’t a post ranting about Comcast (while tempting! and you know I love a good rant!), this is a post about a fairly new open source project aimed at simplifying the simulation of bad network conditions (hence the satirical name…) despite it being an admitted afterthought by the original creator.) in order to help to design distributed systems with better fault tolerance for connection quality that is expected in the real world.

Oh, please tell me more meme

So, what it does is very simple. Written in Go, Comcast (the project, not the ISP) is a wrapper around various tools already built into operating systems like Linux, *BSD, and MacOSX. Namely, tc, iptables, ipfw, and pf. Utilizing the QoS features like network emulation (tc), and pipes (ipfw), Comcast abstracts the configuration of these tools with an easy to use, single binary with simple command line flags. One command, can set up these advanced rules instantly, and tear them down just as fast. This enables developers who may not have much experience with the lower level networking stacks of the various operating systems they use to do more advanced simulation of less-than-catastrophic failure that isn’t often enough done to build more resilient software.

But why?

In a blog post by the original creator of the Comcast project, he goes into better detail than I can into why this is important, and why it’s in our best interest to do this sort of testing. I’d suggest giving it a read (and other stuff on his blog!).

Can I help?

Yes of course! I already have begun to leverage my own meager coding skills to help enhance and extend support for this project. If you like Go, and you want to get in on the ground level of development on a project with a small, clean codebase, I would highly suggest forking the repo, hacking and tinkering on it, and sending in your pull requests!