I recently completed a job for the good people at ADabisc, an advertising agency in Qatar for QTel, the national telecommunications carrier. It was a lot of fun, and we all learned a lot in the process. Since I knew next to nothing about the titular acronyms before I started, and I know something about them now, I thought I would describe what they are and why they were useful to me.
LSO (Wikipedia) stands for ‘Local Shared Object’, and is a native interchange format which is integrated into flash at the very core. It’s also very old – They first appeared in Flash Player 6 / Flash MX, so they enjoy near-universal support. You create and edit them by calling
var lso:SharedObject = SharedObject.getLocal("local","/");
lso.data["message"] = "Hello, World (of Local SharedObjects!)";
The parameters here, “local” and “/” are less important than maintaining consistency. They refer to how the locally-saved SharedObject data will be stored – something we don’t really need to concern ourselves with. All we need to care about now is using this lso.data object as the container for the persistent data we want to store. If a user leaves your website or closes the flash player window, the data is still stored in the same form as it was prior to closure. It’s locally stored per-user on a machine so if the same user goes to the same window, then the flash files will have access to the same LSO. The Wikipedia article suggests that some have gripes with this, since it’s a data store that isn’t flushed along with the other private data in a browser, but as long as you’re using it for good then it’s not the end of the world. This has the upside that there is more limited room for abuse of things like number-limited offers – since nobody really knows about what LSOs are and how they work,
The other great thing about this system is that the objects are shared, so that any flash files (again, on the same domain and for the same user, to prevent misuse) will have access to the same data. So in FuelYourSenses I have about 5-6 separate .SWF files communicating with one another indirectly – told about new data through Event dispatches, and then reading the new data from these agreed-upon Shared Objects.
RTMP (Wikipedia) : Real-Time Messaging Protocol
RTMP is another one of Flash’s native tricks for multimedia streaming. It’s a proprietary protocol, which means in order to get the full functionality out of it you need to buy the Flash Media Server, but for our purposes we were happy to use the very excellent opensource version or the Media Server, Red5. It’s a Java-based implementation that apparently only contains a portion of the full Media Server functionality, but it was more than sufficient for our needs. If you’re interested in Media streaming (Audio, video, both or neither(!)) then it would be well worth your time to download Red5 and start experimenting. The Demo files show you all you need to know to start recording and rebroadcasting streams as soon as you can get a server that you have permission to run a Java application on. Once you have a video feed up, say, from a webcam or a locally stored .flv file, you just publish to the RTMP server and you’re done! I was shocked.
Amazon EC2 is a place where you can hire a (virtual) server by the hour. You have full and unfettered access to machines that run either Linux or Windows, with a number of pre-installed options for software provided by Amazon and other third parties. We were initially unsure about the level of traffic the site would attract, whether one server would be sufficient or whether we would need to scale up. Because of this, and the entirely reasonable concern that QTel had of letting a rogue developer have unfettered access to a server in their data center, we decided early on to manage the audio/video streaming with a solution we could 1. have complete control over without freaking anyone out, and 2. scale without having to divert existing servers or purchase new ones.
EC2 isn’t the easiest thing in the world to work with, but there’s a lot of good help out there. We learned a lot from this very useful Youtube tutorial. We did as the tutorial says and used ElasticFox, Amazon’s Firefox plugin, to manage the whole process – without it I think it would be just about impossible. Between that, Amazon’s documentation and our undergrad dabbling in Linux we were able to select a flavour of Linux, install Apache, Java and Red5 . The default installations are seriously minimal so you’ll have to install a lot of things that you would have expected to come built-in.
I hit an irritating stumbling block in getting a Linux instance up and communicating with my Windows desktop: if you’re using puTTY rather than a straight SSH command in OS X / Linux, you’ll need to convert the keypairs as generated by Amazon, into puTTY’s native format for handling credentials. This is done with puTTYgen. Aside from that and making sure that you have opened the appropriate ports for SSH and other traffic to the server, it was relatively straightforward.
All in all it was a fascinating project to jump into, and I’d like to thank ADabisc and QTel for the opportunity to work on it. The site went live on November 22, and after a pretty modest start it is now up to 10,000 Pageviews, and has broken 1,000 Daily views for the past 3 days! Not bad for the 16 days or so it has been up. My blog has had 1,800 pageviews in the 14 months it has been online, so it has been by far the mos-viewed piece of work I have ever created. The numbers are exciting but bring with them their own worries.