I was saddened by the turn of events. I thoroughly enjoyed working on Mojo. It offered a unique set of challenges. Prior to Mojo, how many other applications sported an embedded http server? And after that I got to write a xmpp framework for cocoa! But the crown jewel of Mojo was something far more difficult. Something far more complex.
Consider this:
When you stream music in Mojo, you are doing so via a direct connection to the other peer. You're not streaming it from some cloud storage facility - Mojo users don't have to upload their music to anything. You're not streaming it through some third party proxy server. You have a direct connection from A to B, even if A and B are both behind routers.
In other words, the crown jewel of Mojo was TCP NAT Traversal.
We spent years researching this. I'm fairly certain I've read every single thesis and educational paper on the topic. And when we implemented it, we added anonymous statistics gathering and traversal analysis. We collected data from millions of traversal attempts, including router types and NAT algorithms. The end result was an incredibly successful TCP traversal library.
But we didn't stop there. We wanted a 100% traversal success rate. We realized there were certain routers, or combinations of routers, that were simply too difficult for standard TCP traversal (even with our advanced techniques). But UDP traversal might be necessary. So we built a TCP over UDP solution, and then implemented a UDP traversal library. Then we released a version of Mojo that had both traversal libraries. If TCP traversal didn't work, it would try UDP traversal. Of course we had anonymous statistics gathering for this too. But after analyzing the data that came back we noticed a problem.
Most of the routers that were difficult to traverse with TCP were also difficult to traverse with the standard STUN (UDP traversal) techniques. This was because they were largely symmetric NATs.
So the research began again. We thought there would be a ton of literature on the topic, but that wasn't exactly the case. A long time ago the ICE (Interactive Connectivity Establishment) protocol was created. This is just a big fat cop out. The protocol basically says try the existing UDP traversal stuff, and if that fails then just route through a 3rd party server. After ICE many researchers came up with great ideas on traversing symmetric NATS. But the industry has seemingly ignored them! Not us. We implemented them. And the results - incredible.
After a ton of work we were able to get very high success rates. This was obviously important to our customers. But it was even more important to us. We were a tiny startup, and we simply could not afford to pay for a rack of servers, or pick up the tab on extra bandwidth.
Recently it has become more and more clear to us that we're not the only ones who could benefit from TCP NAT Traversal. In fact, better UDP traversal would also be very helpful to many organizations.
Recently we learned that Simplify Media has shutdown operations. I'm not sure what their future plans are exactly, and I don't believe they've said anything publicly. This has lead some to speculate about the reason for the change:
Simplify made it "just work" but they did so at the cost of centralizing it, meaning they were footing the bandwidth bill for all that streaming... doesn't take a genius to know that when you give something away that encourages using lots of bandwidth, and you're paying for that bandwidth, you're going to run out of money!
I'm not sure if we've seen the last of Simplify Media, but I do have to agree that footing the bandwidth bill is not the most scalable business solution.
And so today we are open sourcing Mojo to showcase our NAT traversal libraries. You can find it on its new Google Code page.
Notes:
- We have removed the ability to download files from the source because we don't like getting sued. The app is streaming only.
- The NAT traversal code is under the GPL, but a commercial license is available. We look forward to added documentation on the subject, and a dedicated project page on the Deusty website.
- If you're a private media organization or an education institution, we may be able to create a specific Mojo solution for you with downloading included. Please contact us for more details.
Happy Easter. God Bless.
3 comments:
Robbie,
I was not aware of the EMI thing but that does explain why the site is down. I'm really sorry to hear that things did not work out but I loved Mojo/Mastro and the community was awesome! I wish you luck in whatever you guys work on next! :)
thanks for the wealth of knowledge. its only a matter of time before solutions similar to the likes of mojo, and simplify media break through and change the music industry as we know it. there are so many hurdles that need to be overcome first though, which is unfortunate.
The hurdle atop of which all the other hurdles seem to stand, is one which points to a problem of precedence. while i love music, and am all for supporting the artists that create music, its unreasonable in this day and age to think people will be willing to pay $20 usd per album. think 10% of that figure. this is an amount that people today would be willing to pay for music. thats not to say the quality of music is worse than it was in the 60's, 70's, 80's, 90's etc (if anything its eons better). it just speaks to how digital audio, tcp, and the internet have leveled the playing field in a way that i cannot even being to articulate.
but, that which the music industry doesnt understand will be their downfall. while the value of music has dropped relative to the change in times, the size of the market has increased tenfold. i cant wait until the onset of (an) progressive indie labels that have (has) a business model which will blow the socks off of all the existing fat cat labels. hopefully it will be a label which will cause everyone and anyone to switch and sign over, leaving the old labels high, dry and out of business, all because they were unwilling to adapt to the change in times.
Hi Robbie,
Do you still plan on releasing your NAT Traversal code as a separate project?
Or are you keeping it as a commercially licensed project?
Post a Comment