One of my ongoing weekend projects is an AIR chat application, recently rechristened “JUICE” a.k.a. “John’s Ultimate Internet Chat Experience”. I realize that may only be the case for myself, but the project has been very educational and entertaining for me.

The initial release used AIR/Flex as the front-end, ColdFusion and MySQL for the backend, and BlazeDS messaging for message transmission and “peer discovery”.  I worked on it over a couple weeks adding features like encryption, toast-style notifications, as well as a few other less notable things.

I knew the architecture was awful and would never scale beyond a couple hundred users (if that many). Here’s the basics of how it worked:

1. The user would login, ColdFusion/MySQL would send back a list of chat buddies.
2. Each logged in user would ping the messaging server every 10-30 seconds to announce “I’m still here!”
3. The pings would be broadcast to everyone logged in (and connected to the messaging server). The application would filter out the ones it was interested in based on user id.
4. Sending messages worked similarly, the user would send the message (which included information about the intended recipient), which would then be broadcast to EVERYONE.
5. Everyone would filter this information, and the recipient would know it was for him, and would display it.

You can see why this would not scale well, the amount of traffic and pinging going on.  Eventually even a user with only 1 or 2 buddies would notice a significant drop in performance as the number of total users increased.  There are some applications of “chat” for which BlazeDS messaging and polling is well suited for (like a chat room).  A chat application involving “buddies”  is much better suited for P2P.

Enter Stratus.  I discovered Stratus a few months ago but was unwilling to delve into it on account of my hectic schedule.  Fortunately one of my friends went and did all the dirty work figuring out how to get it up and running (turns out it’s pretty easy) and I was able to apply it to my chat client.

I’m very pleased with the results, though it’s still very much a work in progress.  I’ve even been able to add video and voice chat features, which is why I went through the trouble in the first place.  Here is how my peer discovery mechanism operates.  It requires only 3 calls to the server per client (which I could easily condense to 2 if I wanted).

1. The user logs in.
2. If the user successfully authenticated, he connects to Stratus and receives his peer ID.
3. The user updates his peer ID in the database (which was set to 0) and gets a list of his buddies and their peer IDs.  I also update information like whether or not I have a camera/mic.
4. The user processes his buddy.  If the peer ID is something other than 0, then I know this buddy logged in before me, so I must send him my peer ID.
5. Any buddies that have a peer ID of 0 are not logged in, I need to listen for them though since they will get my peer ID when they log in.
6. When I log out or close the application, I call the server and reset my peer ID to 0.  I also notify all of my connected peers I’m logging out.

There are a few more steps in the process, but it decreases the load on the server significantly, transferring the “burden of proof” onto the clients.

Interesting to note is the way I get the peer ID of a client who connects after me (step 4).  I don’t actually have to make a call for this, rather he simply has to start broadcasting to me on the NetStream I set up to listen for him (step 5).  When the connection is made, an event will be dispatched by the NetStream class.  In fact, 3 events will be fired, I just chose to act on one of them.

The peer ID can be obtained from the peerStreams array on the publishing NetStream.  I then use that information to set up my subscribing NetSream.

if (this.peerId == null || this.peerId == "0") {
    this.peerId = publishNetStream.peerStreams[0].farID;

    this.subscribeNetStream = new NetStream(model.netConnection, this.peerId);
    this.subscribeNetStream.client = new NetStreamClient();
    this.subscribeNetStream.play(streamName);
}

Anyway,I’m planning on doing another post to outline my video and voice handshake protocols.  They’re nothing to write home about, but I’d love some feedback if there’s a better way.  I’m also planning on releasing JUICE after I bring it’s level of functionality back up to where the original version was, so stay tuned and you should see my install badge at the bottom of my blog.