Home / Developer Center / Flash Communication Server Developer Center /

Exploring the Technical Changes to Macromedia Flash Communication Server MX 1.5

This article includes practical explanations of all these features as well as the specific technical details needed to get started using MP3 streaming and HTTP tunneling. To fully benefit from the sample code in this article you'll want to install version 1.5 of Macromedia Flash Communication Server MX and be comfortable writing ActionScript.

Flash Communication Server for Everyone

The actual cost of software involves more than just the price-other factors include your time invested learning it as well as maintaining it. The good news that not only is the Communication Server pretty easy to use (it's ActionScript after all) but you can immediately download the free developer version and get started right away. You'll be limited to 5 simultaneous connections and 250Kbps of total bandwidth, but that's plenty for learning and most production work.

As for the paid license options, the two versions (Personal and Professional) both had their maximum user limits raised significantly (to 50 and 2500 users respectively). In addition, there's a new option that gives you 90 days of no-holds-barred unlimited data and user connections-perfect for planned events requiring massive media transmission. Remember that the Communication Server is totally scalable! There are white papers as well as empirical case studies that can attest to this fact. The product page has information that shows the different options available. Realize that you can stack Personal or Professional versions on top of themselves but not each other.

If you think the licensing prices seem high, you really have to look at it from another perspective. Namely, consider the value your application can provide a client. With the free developer version and no more investment than your time, you can build a proof of concept application and accurately calculate the ROI for your client. Either your project can justify the cost or it can't. I've seen many projects that do pay for themselves, and I'm sure there are countless other project ideas just waiting to exploit this technology. In any event, there's a price point available for every need.

Serving MP3s

Macromedia Flash movies can already perform MP3 compression on embedded audio as well as play external MP3 in their native file format. However, the way it streams is called progressive download. That is, users can hear the first part of a song while the remaining part downloads. However, with progressive downloads users can't seek to different parts of a song or subscribe to a playlist where audio streams play consecutively.

Another issue with the current implementation is that playing native MP3s (which uses the Sound Object) will download the original data to the user's browser cache.

Macromedia Flash Communication Server MX 1.5 allows you to stream native MP3s the same way you can stream live or recorded video and audio. For one thing, this means nothing is saved on the user's hard drive. For those reluctant to effectively give away their MP3s, you can now stream them like conventional streaming media. In addition, you can control streaming on the server for situations where you may not want to give each client control over playback (like when or what part of a song plays). For example, this broadcast effect could let a teacher trigger sounds for all connected students to hear at one time. Naturally, you can also give individual clients control over streaming.

Ensuring a good listening experience for various connection speeds is possible only through controlled buffering. This isn't a new feature; you can individually control how many seconds must download before a stream starts playing. For video, the Communication Server can change a video stream's bandwidth needs on the fly by dropping frames. Unfortunately there's no equivalent in pure audio streams so you'll either need to use buffering or produce multiple bitrate MP3s to serve-up as needed.

Sharing MP3s and Accessing ID3s

There are a couple subtle features of streaming MP3s that are worth looking at in detail. Besides just learning the new syntax, you may also want to access an MP3's ID3 tags or share an MP3 among several different applications. ID3 tags let MP3 authors embed into music files data identifying such properties as artist, song title, and year. Apparently there are various versions of this standard and, worst yet, not all authors include the same set of data. In any event, you can access the text data that's there-but because the procedure is different than the way you currently access ID3 data in Macromedia Flash, I'll include details in the sample code below.

By default, the source MP3 file should reside inside a folder called "Streams" that in turn is inside your application's folder. (All Communication Server apps need such a folder into which data such as streams and server side scripts are saved-ideally, in a different location than your web server so clients won't have direct access.) For many situations, it will be more convenient and efficient to store MP3s in a common location so each application can have access. The folder where you store such common media needs to be set up as a virtual directory that you identify when playing the stream. A virtual directory has two parts: the actual fully-qualified folder name (such as "c:\My Music") and the name used in your Macromedia Flash movie (the alias, in the traditional sense of the word).

Virtual Directories

The way you identify an alias is by editing the "Vhost.xml" configuration file (found deep inside the "conf" folder adjacent to your installed version of the Communication Server). In the code listing below, you can see how the Streams tag includes the alias "music" which will really point to "C:\My Music":

<VirtualDirectory>
  <Streams>music;C:\My Music</Streams>
< /VirtualDirectory>

Now to play MP3s stored in C:\My Music, your Macromedia Flash movie simply needs to refer to the folder "music" (as shown in the next few examples).

Playing MP3s

In order to play MP3 streams, you use a new version of the NetStream.play() method. Assuming you've made a NetStream instance with the name my_ns, you can use the following code to play an MP3 called "my_song.mp3" stored in the virtual directory "music":

my_ns.play("mp3:music/my_song");

In the past, you could just say my_ns.play("mamma_mia") and it would look to play a stream called "mamma_mia.flv". That still works. But, now to play an MP3 you use: my_ns.play("mp3:mamma_mia"). That is, "mp3:" at the start means to look for an MP3. Finally, because the actual file is in a virtual directory we precede the filename with that directory name and a slash. So the final form is:

my_ns.play("mp3:directory/filename")

Accessing ID3 Data

Finally, let me show you how to grab the ID3 data from an MP3 stream. Currently, Macromedia Flash can read sub-properties of a Sound Object's id3 property, but it requires that the sound is fully downloaded. Because we're now dealing with streams, the task is a bit more involved. Specifically, requesting ID3 data is an asynchronous operation (Macromedia Flash continues to execute code while it waits for data to be returned).

Here's an example code block that I'll explain below:

//make a regular stream
my_ns = new NetStream(my_nc);

//make a stream for info purposes
myInfo_ns = new NetStream(my_nc);

//set up onID3 callback
myInfo_ns.onId3 = function(info) {
  for (i in info) {
    trace(i+": "+info[i]);
  }
  //display the artist name
  artist_txt.text = info.artist;
};

//play and get the id3
my_ns.play("mp3:music/my_song");
myInfo_ns.play("id3:music/my_song");

Although you may want to first get the ID3 and then play the stream, I show in the last two lines that it's convenient to have two separate streams (my_ns and myInfo_ns). It may seem weird, but when you invoke the NetStream.play() method and begin with "id3:" it only creates a stream for the purposes of reading the ID3 data-that is, it doesn't really play the song. In order to be prepared for the result, you define a callback function for the onId3 event. When onId3 is triggered, it's passed an object full of properties (shown here as info). Naturally, only MP3 files "played" with the "id3:" prefix will trigger this event. The for-in loop simply helps determine what properties are found-by displaying them all for testing. Then, for demonstration purposes, I show a text field on screen (named artist_txt) that gets populated with the artist info (provided the ID3 data includes an artist property).

Although there are a few new things to learn, the syntax is very consistent with other asynchronous operations.

HTTP Tunneling: Circumnavigating Firewalls and Proxy Servers Honorably

The new HTTP tunneling feature will surely impress any Communication Server skeptics that may remain. The issue solved by tunneling has to do with the fact that the coolest Communication Server features require that users maintain a persistent connection to the server. This is how messages can keep each client synchronized as to any changes shared by other users. For version 1.0, Macromedia developed the RTMP protocol (Real Time Messaging Protocol) over which such data travels. Although audio and video streams travel over the TCP/IP they could also be blocked before tunneling. The default port assigned (by the Internet Assigned Numbers Authority) was 1935. It turns out you've always been able to override this although you could encounter conflicts. In fact, Macromedia Flash Player would attempt to make a connection over port 443, and then 80 if 1935 failed. The problem, however, is that not only do some people have firewalls blocking 1935, they may also limit access via RTMP (say, they only allow HTTP and a few other popular protocols).

HTTP tunneling is a way that Macromedia Flash movies can now connect to the Communication Server over the standard HTTP protocol (on any port). Actually, the latest versions of Macromedia Flash Player (6,0,65,0 or later) will automatically attempt to connect over several different ports and then attempt to channel communication over HTTP whenever there's a problem connecting. Think of HTTP tunneling as "RTMP traveling over HTTP". The bottom line is even the pickiest firewall won't pose a problem because you can connect through port 80 over HTTP (a port and protocol that is surely open to anyone browsing the web).

Another improvement to the player is that proxy servers are no longer an obstacle. Because proxy servers channel all connections to outside servers (requiring everyone to specify the correct settings) connections to the Communication Server are effectively blocked unless the proxy settings are known. The new Macromedia Flash Player uses the client system's proxy settings to negotiate a connection with your application on the Communication Server.

HTTP Tunneling Details

In many cases, the automatic features in player make this a non-issue, but naturally, to take control requires a deeper understanding. Here's how it works. The Communication Server runs independent of any web server. The web server hosts the HTML and SWF files, but the Communication Server handles everything else (like multi-user communication, saved variables, audio and video streams, and so on).

Figure 1. In the past the Communication Server needed a port open for RTMP data (by default, port 1935). Figure 1 shows that the Communication Server version 1.0 data had to travel as RTMP. Although the player would automatically attempt port 1935, 443, and 80, the user's firewall both had to have one of those ports open and allow for RTMP data in order to work.

Figure 2. The current Flash player will attempt several optional ports including HTTP over port 80. In Figure 2, you can see the new default behavior. If the Flash player finds port 1935 blocked, it automatically attempts port 443, then port 80, then port 80 using HTTP (also called RTMPT, but it's really HTTP). You may infer that the server is making these different port attempts, but in fact, it's the player. Once a connection is made, data travels in both directions. Notice that this new automatic sensing feature can still easily fail if you run the Communication Server and your web server on the same box. That is, if your web server is using port 80 (which it likely is), then when the player attempts port 80 it will fail because your web server is already using that port. I'll show you two easy, automatic solutions and then one where you take control.

Figure 3. By running your web server on a separate computer, you won't have any port conflicts-but it does require another machine. As shown in Figure 3, if you simply run your web server on one computer and the Communication Server on another, then the automatic port sensing behavior will succeed when it tries 80 (RTMP or RTMPT/HTTP). Naturally, this solution affords more processor power though slightly more difficult to configure and probably a bit more money.

Figure 4. Easy solution #2 is fine except your web server won't be on the standard port 80. Another easy solution (though probably not so hot) is to run your web server over another port: say, 8080 as Figure 4 shows. You'll have to somehow direct users to include ":8080" after your domain name but this may not be an issue if no one actually types in the address by hand. Although these two easy solutions are not ideal for every situation, remember, they're easy. Notice in each case the Macromedia Flash code uses the same old connect() statement and requires almost nothing to set up-it's the player that's digging the tunnel, if you will.

Figure 5. By editing the Adaptor.xml and specifying RTMPT in the connect() statement you can pick any port over which data will travel as HTTP.

To take control, you can edit the Communication Server configuration file "adaptor.xml". Among other settings in that file, you can specify additional port numbers over which RTMPT is allowed to travel. Keep in mind this doesn't override how the player will try specific port numbers. However, you can force the player to use RTMPT (HTTP) over an explicit port number by simply changing the connect() statement. Namely, Figure 5 shows how the connect() statement hardwires "rtmpt" (instead of "rtmp") and indicates that port 8080 is to be used. Notice too, that we moved the web server back to port 80. In order for this example to work, you simply have to include 8080 in the <HostPort> tag of the adaptor.xml file (in the "conf" folder adjacent to your installed version of the Communication Server).

Editing the adaptor.xml file lets you configure the Communication Server to listen to any number of ports. Each port can handle connection requests as RTMP or RTMPT (RTMP using HTTP). However, the protocol (RTMP or RTMPT) is specified on the client side (either automatically in the way the new player will try different ports, or when your connect() statement specifies "rtmpt" explicitly). Because of this, you can use the new server side Client.protocol property so your applications can establish a connection appropriately.

Think of tunneling this way: Macromedia Flash Player now tries several ports then tries 80 using HTTP. If you'd rather direct the player to always use HTTP over a specific port you can do that too (it just takes editing the adaptor.xml and including an extra "t" in the connect() statement). Finally, the only part I left out was that HTTP tunneling could delay the initial connection time. For this reason, an advanced technique involves attempting several connections simultaneously and just keeping the one that connects fastest. Check out the code in the new Simple Connect Component for how one wizard would do this.

What Are You Waiting For?

The fact that the Communication Server now resolves the port issue and a version is available for Linux means that certain previously impossible projects are now a reality. MP3 streaming falls into the "cool" feature category. But if you didn't know, there are already some really powerful capabilities built-in. In my opinion, the Communication Server is the most exciting product in Macromedia's history.

Although the live video features get the most airtime, I think the simple way you can share variables in real time (even over slow modems) is profound. Also, because the Communication Server only notifies clients by sending the portion of data that changes, using Flash Remoting on the Communication Server results in dramatic performance improvements. If you do use audio or video you can optionally embed events into saved streams that get triggered on playback. Real-time apps are great when you get can get everyone together at once, but just like how a VCR is effectively a time machine (letting you watch shows at your convenience), Communication Server applications offer a revolutionary form of communication that's ripe for education, global business, travelers, as well as needs I can't imagine. Don't get me wrong-video chat is cool. But there are so many other killer apps just waiting to get created.

I sincerely hope that if you haven't learned the Communication Server yet that the free Developer version will get you started. I'd recommend starting with the sample applications and reading the "Developing Communication Applications" manual. You'll find the syntax is consistent with ActionScript; it's well thought out; and it's not terribly difficult to learn, although you do need to start thinking in different terms. Anyway, with the free Developer version, you really don't have any excuse not check it out. Please prove to Macromedia that their decision to offer the Developer version was a wise one by going out and building something amazing.

---

About the author

Phillip Kerman is a Macromedia Flash programmer and author of the best-selling Sams Teach Yourself Macromedia Flash MX in 24 Hours and ActionScripting in Flash MX. He also conducts Macromedia Flash training workshops around the world. Recently he used Macromedia Flash Communication Server MX and Flash Remoting to program a real-time auction for www.stampedecattle.com that sells millions of dollars worth of cattle per hour. His site www.phillipkerman.com includes several Communication Server examples.