I’ve been having fun playing with node.js over the past year, but have had little, or no excuse to use it in any production work, so I thought I’d set myself a challenge and build a module. That challenge was firstly to create a simple AMF gateway for Flash remoting, and secondarily to see if an RTMP socket server was achievable in node.

If you don’t know about “node” – It’s a JavaScript runtime that allows you to write socket servers. I like it a lot – it brings asynchronous, event-driven programming to the server side and provides a truly global variable scope across all connections. I’ll blog about it in more detail later, perhaps.

At Public we do a lot of Flash work, and regularly implement Flash remoting using a PHP AMF gateway. I wasn’t necessarily looking to replace this stock approach with node, but node offers proper socket connections that PHP can’t, so I was imagining the possibilities of using node as a free, and more flexible alternative to Flash Media Server. Not for streaming media, but for real-time messaging, for example in multi-player games. If I’m honest though, I did this mostly for fun, an academic exercise and as an excuse to work with node.

node-amf

node-amf is on GitHub as a public repository: http://github.com/timwhitlock/node-amf

The first step was to write a pure JavaScript AMF implementation. i.e. a library for serializing and deserializing AMF packets. If you’re not familiar with AMF (Action Message Format) – it’s a binary serialization and messaging format invented by Adobe for passing data back and forth between Flash and a remote server. I am not the only person to implement this in JavaScript: mid-way through my project I noticed amf.js appear – just a little too late for me. This library is probably much better than my own, but mine is designed specifically for node, so I shall stick with it for now.

With a working AMF library all that remained was to create a HTTP gateway. There are many examples of AMF gateways in other languages, including PHP. The general approach is that a single request/response exchange carries one or more messages, each one calling a web service on the server and returning the result. AMF also has the ability to invoke methods in the Flash client on response – an underused feature.

Node makes it incredibly easy to implement an HTTP server, all that I had to do was decide how to expose the web services to the gateway. I decided to do this by passing a user-defined JavaScript object when initializing the server – each property of the object is a function callable by name – example AMF gateway here. This suitably sandboxes the method calls, and ensures the client cannot execute arbitrary JavaScript functions – that would be bad.

This part of the project is largely complete and working. It has not been used in production yet, so if you’re brave enough to use it, please let me know how it’s going!

node-rtmp

node-rtmp is currently under the same project as node-amf because it’s dependant upon the AMF library. This incomplete, highly unstable, and experimental work is under the node-rtmp subdirectory with examples here.

If you’re not familiar with RTMP (Real Time Messaging Protocol) it provides bi-directional streaming media and messaging over persistent socket connections. It’s the messaging I’m interested in. Flash talks to Flash Media Server over RTMP sockets and can securely call methods in both directions.

As it turns out the RTMP specification is very badly written. (The AMF specs were quite easy to read, although possibly much simpler). If I was a cynic, I may even suggest that Adobe has purposefully written them badly to avoid third party developers being able to adhere to the usage license which insists in adequate conformance to the spec. However, it doesn’t seem to have stopped numerous projects such as librtmp from gluing the pieces together.

This is the point where I realised I might be out of my depth. I am currently in the process of glueing the pieces together myself. Armed with the dodgy specification, Wireshark, and the fragmented information dotted around the Internet, I am making some slow progress. At the time of writing I have the RTMP handshake working correctly, and have just about deciphered the command messaging packets.

I may give up before this is at all useful.

librtmp and node add-ons

As you may have noticed, I’m talking about implementing all of this in pure JavaScript, and you may be thinking that’s nuts. You are probably right. As libraries, these don’t really need to be written in JavaScript. In addition to pure JavaScript modules, node supports add-ons – compiled libraries which can be built against C and C++ system libraries. A good example of this is node-memcache.

C and C++ is unfortunately outside my skill set, but I imagine it may be possible to build an RTMP node add-on using librtmp. Anyone fancy a crack at that?

I set up our simple FMS application, which merely streams video from a three-directory-deep file structure. This means our Flash front end must,
a. connect to an instance of the application, say: rtmp://mydomain.com/myApp/_definst_
b. request the stream of an FLV resource, such as:
flv:ab/cd/ef/vwxyz.

Note the explicit use of the default application instance _definst_, and also the odd reshuffling of the FLV path. This is how you’re supposed to do it [apparently] and it worked just fine. Hoorah.

After running some successful tests with a simple front end using NetConnection, I am told that our Flash front end (actually Flex) will be using a skinned FLVPlayback component. This component doesn’t ask you to split the resource into these two pieces; it takes a single, complete stream URL. The above example would mean passing in: rtmp://mydomain.com/myApp/_definst_/ab/cd/ef/vwxyz.flv
Note we still keep the instance name, and the flv extension is optional.
This worked just fine on our dev server, and when we deployed to a live server it seemed to be ok too. Hoorah x 2!

Anyhow, I’ll get to the “but”.

After gong live, we received reports of videos not playing, and were unable to replicate the problem at will. Eventually I noticed in the log files that FMS was throwing 404s. On closer inspection, the 404s were for resources prefixed with our application instance name _definst_. The successful 200 responses were requested correctly as ab/cd/ef/vwxyz, but the failures were referenced as _definst_/ab/cd/ef/vwxyz. Most alarmingly these were sometimes for the same resources, and even from the same client.

It looks like under certain [unknown] circumstances, the application and the resource are not getting correctly split out of the full URL. I do not know at what point this error creeps in. I also don’t know what FLVPlayback does internally to make the stream request from the full URL you pass in. All I know is that the error appears arbitrarily, and has proved impossible to raise on purpose. Possibly a bug in FLVPlayback, or a bug in Flash Media Server?

Solution

A real solution I have not found, so I did a very dirty hack.
As I have failed to avoid the 404s, I turned the bad paths into valid paths by sym-linking the FLV directory back to itself with the name _definst_, as follows:

cd /path/to/flvs
ln -s . _definst_

Job done, but I’m not happy about it. Anyone able to offer a real solution, please post a comment!