Just got back from Interop where I was part of a panel that talked about cloud computing. We discussed a lots of interesting topics like migration, scaling, hybrid clouds and what not. NoSQL was definitely a discussion point since I personally believe you can’t talk about cloud without also talking about NoSQL.

The scaling part though got me thinking. The current approach for scaling any cloud app is to use your IaaS provider to just add more compute power and deal with it. I tend to think a little differently from this. xtractr on pcapr for example, uses a hybrid cloud model. You download a single binary that you use for indexing large packet captures. When you now want to search, extract, report on this, the application is delivered to your browser which then uses JSONP (until HTML5 is truly prevalent with cross-domain Ajax requests) to communicate to your instance of the xtractr. What this means is when you are busy crunching packets, the server load on pcapr is zero! Which implies infinite scaling, ‘cos the load is truly distributed across all of our users.

More »

Just read the net neutrality article on Comcast. I have mixed feelings about this and wanted to find out what you thought. There seems to be a fine line when data becomes information and directly affects corporations and fellow humans. What I don’t know when looking at packets traversing the network as little bits of information, where exactly that boundary lies.

More »

We launched pcapr over a year ago now with just a few of us working part time to build and manage the site. pcapr is powered by CouchDB, a NoSQL database written in Erlang with JavaScript as the primary query language. Frankly, this has been a disaster. We are planning on rebuilding the site with Java, Hibernate and MySQL for a number of reasons.

More »

Recently we were looking for ways to do rapid building of prototype pages during our UI development. I still remember my first web project when I built an air ticket reservation system over a decade ago. Back then, we were concatenating HTML / Javascript inside servlet code to crank out the UI. The joy of building a cool new system was quickly offset by the frustration in dealing with escape / unescape single double quotes for multiple layers of Javascript inside Java code. Over these years, things evolved a lot in trying to address this separation of logic and presentation issue. We had JSP, Strut, Velocity, FreeMarker etc. They were running toward that goal with one getting closer than the other. But logic code still mingles with HTML/CSS . If not used cautiously, they can still yield spaghetti code faster than developers can chew.

More »

What started off as a way to fully unit test xtractr, turned out to be a Gem, literally. First xtractr, then nuggets and now a gem. You follow? Seriously though, we are happy to announce a Ruby gem for xtractr which takes all the goodness of Ruby and interacts RESTfully with xtractr for oh-so-fun packet mining and troubleshooting all from within IRB.

More »

We launched xtractr earlier this week for network forensics, troubleshooting and handling support escalations involving large packet captures. Just so you know xtractr is a 4-tier app (more on that below) that combines the best of Web 2.0 with looking at packets in new light. Looking beyond the “unleash the power of packets” message, I wanted to write about what’s under the hood a little bit and how we are using CouchDB-style of Map/Reduce for uncovering all sorts of information inside large packet captures.

More »

So I was up early this morning and counting packets didn’t help. I was thinking of what we do here at Mu and how testing requirements have dramatically changed over the last few years. This blog is an ode (well it doesn’t rhyme) to the most awesomest testing product created by the Mu team.

More »

At Mu, we deal with pcaps every day. We love Wireshark. We decode packets, work with protocols, auto generate test cases (functional to fuzz) from pcaps by analyzing the contents and just have incredible amounts of fun solving major problems for our customers. Yet when it comes to replicating field issues, most of our customers struggle with large pcaps and try to get a bird’s eye view of what’s in it to pinpoint the conversation or packet that triggered a bug. This takes hours if not days. With Mu Studio, it’s super easy to load a multi-protocol transaction and use it as the basis for testing - from functional to fuzz. But how do you find the suspicious transaction or conversation from the large pcap before you can test?

More »

As we approach the 1 year anniversary of pcapr, we were looking back to see how it has evolved. As a company that tests pretty much everything under the sun that has an IP stack, we deal with pcaps for all kinds of protocols. These pcaps were being littered around in public shares, wiki attachments, emails, internal mailing lists and blogs. Turns out we were not the only ones. The broader community and our customers were having similar problems. So it really started out as a way to organize a large collection of pcaps for us and the broader community. Hence the r in pcapr, which stands for repository. But thanks to the community feedback and contribution, pcapr has become a whole lot more than just a repository.

More »

So a friend of mine installed solar in his house and he kept hearing voices in the backyard. Turns out his smart meter was using SIP to call back home and report various things. Okay, I was kidding, but there’s something to be said about this.

More »