I briefly mentioned before that I’d started looking at Red5, the open source RTMP server, as a viable solution for a scaling a recent project I’d been developing. Essentially Red5 is the open source equivalent of Adobe’s Flash Media Server, on which the project is currently built, but the proposed migration seems to offer more benefits than just the removal of the expensive licensing overhead.
Currently we’re working with a shared hosting solution, allowing up to 500 concurrent RTMP connections, but our intent is to scale up to over double that figure – aiming to ultimately handle between 2,000 and 5,000 clients. Regardless of the licensing cost that would ensue and the requirement then of (probably multiple) dedicated servers instead, we see Red5 to present a good opportunity to upgrade the system as a whole, to strengthen it and make it far more robust, rather than just straightforwardly translating the application across to the new platform. We’ve recognised for example, that there would be more room for control, observation (and logging even) with a ground-up custom application than we’ve experienced so far with Flash Media Server – worsened of course, by the shared hosting.
So I went about looking into migrating our FMS app, reading a lot of ‘Getting Started with Red5′ type material, of which I definitely recommend Joachim Bauch‘s FCS/FMS to Red5 Migration Guide and his ‘how to’ on Creating New Applications, for anyone else looking. I began collecting helpful bookmarks (see here) and there’s plenty on the OSFlash site too, but I soon realised whilst the fundamental structure and the core concepts of the system could remain, a ‘straightforward’ migration wouldn’t be possible anyway.
Here’s the opportunity then, by developing in object oriented Java, to consider every part of system as a separate construct or component. Previously when trying to extrapolate code, I’d be pulling out methods from prototype functions where scoping problems seemingly wouldn’t allow it any other way, everything was very bespoke. Developing this way would not only promote a better coding standard, but perhaps produce reuseable components, for example, the part of the app serving a rudimentary chat system. But this stuff is like version 50, end of the roadmap, before I’d written a Hello World yet, only then I could consider more RTMP, remoting, then onto sync’ing shared objects, etc.
There’s plenty of resources around to get started with, John Grden at RockOnFlash has some good samples. Milan Toth wrote a handy article from setting up your server environment through application development, to the final Flash client that proved useful, but there were a few frustrating not-so-well documented issues I repeatedly came across.
I think a lot of the issues were with the most recent version of Red5 I was using, v0.7.0, final release as of February this year, but with the majority of tutorials predating that release with now deprecated code. Most commonly I found I was being given a 404 errors when I’d uploaded bad code, relatively straightforward, except it took an annoying amount of time to realise this when I would’ve expected perhaps a 500 error in such a case. Furthermore, I couldn’t find any ‘errors’ in my code, even those I directly copied and pasted from tutorials or recompiled from free source threw the same problems – surely then it would be a problem with my development environment.
Some tutorials compiled .jar files, some with ANT or within Eclipse, some solely used compiled class files. I found my problem to be central to logging, specifically with the log4j library, which when I removed all references to, managed at least to get a directory listing from Jetty and the application instance to appear in the admin console. Other problems I encountered later attributed to using a too-recent JRE, schoolboy.
I always find Hello World and the first initiation with any new platform or language to be a big step, this taking some time with Red5 for me, seems to have landed me in a better place to move onto shared objects, remoting, live publishing, whatever, up next.
I’ve also noticed the developer mailing list has gotten much more activity lately and with it, become far more useful. I definitely recommend subscribing to that for anyone looking to develop with Red5.
Also, the SVN repository has recently moved over to Google Code, found now at http://code.google.com/p/red5/ – I hope this results in a better exposure for Red5 and an increase in popularity – and as a choice for developers, too.