Running Apache and Wowza/Flash Media Server/Red5 on port 80 at the same time

By default Wowza, Flash Media Server and Red5 run using RTMP over port 1935.  However, a lot of firewalls (especially in corporate environments) will block access to this port.  In an attempt to get around this the RTMPT protocol was developed, which basically wraps up the RTMP stream into a bunch of HTTP requests; these run over port 80 and are just normal HTTP, so even the most restrictive firewalls should allow this traffic through.

Its usually very easy to use RTMPT with the media server – for example, in Wowza you don’t have to do anything at all except connect using rtmpt:// instead of rtmp:// from your Flash application.

However, there is a potential problem; since Wowza (I will refer to Wowza from here on, but this should be applicable for all the media servers) is now running on port 80 it means that nothing else can run on port 80; and since Apache is likely to be running on port 80 that means its either Apache or Wowza, but not both.  Note that if you can get 2 IP addresses there is no problem; Apache runs on port 80 of one IP address and Wowza on port 80 of the other, and this is of course the ideal solution.  But there are cases when for technical or business reasons its simply not possible to get 2 IP addresses.

So here is the trick getting access to both Apache and Wowza on port 80 of a single IP address:

Leave Wowza running on port 1935, and Apache running on port 80 as normal.  Then:

  1. In Apache enable mod_proxy and mod_proxy_http
  2. In your <VirtualHost> configuration section of Apache add the following code.  This does not work in .htaccess
  3. # Allow FMS to act as a reverse proxy for Wowza traffic over port 80

    ProxyPass /open http://localhost:1935/open

    ProxyPassReverse /open http://localhost:1935/open

    ProxyPass /send http://localhost:1935/send

    ProxyPassReverse /send http://localhost:1935/send

    ProxyPass /idle http://localhost:1935/idle

    ProxyPassReverse /idle http://localhost:1935/idle

    ProxyPass /close http://localhost:1935/close

    ProxyPassReverse /close http://localhost:1935/close

    ProxyPass /fcs http://localhost:1935/fcs

    ProxyPassReverse /fcs http://localhost:1935/fcs

    
    

    <Proxy *:80>

        Order Allow,Deny

        Allow from all

    </Proxy>

And that’s it!  It works because RTMPT always accesses URLs at /open, /send, /close, /idle or /fcs.  mod_proxy grabs these requests and forwards them onto Wowza on port 1935.  Note that if you have Wowza running on a different IP or URL just change localhost to wherever it is located.

The only thing to remember is that you can’t serve any pages from Apache at /open, /send, /close, /idle or /fcs.

PureMVC Tutorial – Flex, PureMVC, Jabber and XIFF 3: Part 5 – Model & Proxy

Introduction
Part 1 – Frameworks
Part 2 – Directory structure
Part 3 – Application and ApplicationFacade
Part 4 – Notifications, Commands & Use Cases
Part 5 – Model & Proxy
Part 6 – The Application View & Mediator
Part 7 – The Login View & Mediator
Part 8 – The Roster View & Mediator
Part 9 – The Chat View & Mediator
Conclusion, Demo & Downloads

The model is the ‘data’ of our application and the proxy is our interface onto that data.  For our particular application the model itself is basically our Jabber connection object, so the Proxy will encapsulate that and expose an interface with the following methods:

  • connect(username:String, password:String, server:String):void
  • disconnect():void
  • sendMessage(message:Message):void
  • getRosterDataProvider():ArrayCollection

As you can see, the interface is very similar to our use case and commands, and this in no coincidence; each command is going to call the relevant method in its execute method.

Create a Proxy in the model folder called XMPPProxy.as using Add->New Proxy… (if you don’t see this menu item be sure you’ve installed the PureMVC FlashDevelop templates from PureMVC: First thoughts & FlashDevelop templates correctly).

I’m just going to include the Proxy code here without much explanation as it doesn’t really do anything overly complicated (all of the hard stuff has been done for us in the XIFF library 🙂 )  Have a read through the comments of each method and everything should be clear.

   1: /*
   2: Proxy - PureMVC
   3: */
   4: package org.davekeen.xiffer.model {
   5:     import flash.events.Event;
   6:     import flash.system.Security;
   7:     import org.davekeen.xiffer.ApplicationFacade;
   8:     import org.jivesoftware.xiff.core.JID;
   9:     import org.jivesoftware.xiff.core.XMPPSocketConnection;
  10:     import org.jivesoftware.xiff.data.Message;
  11:     import org.jivesoftware.xiff.data.Presence;
  12:     import org.jivesoftware.xiff.events.*
  13:     import org.jivesoftware.xiff.im.Roster;
  14:     import org.puremvc.as3.interfaces.IProxy;
  15:     import org.puremvc.as3.patterns.proxy.Proxy;
  16:     import mx.collections.ArrayCollection;
  17:  
  18:     /**
  19:      * Proxy to XMPP server
  20:      */
  21:     public class XMPPProxy extends Proxy implements IProxy {
  22:         
  23:         public static const NAME:String = "XMPPProxy";
  24:         
  25:         private var xmppSocketConnection:XMPPSocketConnection;
  26:         private var roster:Roster;
  27:  
  28:         public function XMPPProxy(data:Object = null) {
  29:             super(NAME, data);
  30:             
  31:             setupConnection();
  32:             configureListeners();
  33:         }
  34:         
  35:         /**
  36:          * Create the required XMPP objects and do any configuration on them that we might require
  37:          */
  38:         private function setupConnection():void {
  39:             xmppSocketConnection = new XMPPSocketConnection();
  40:             
  41:             roster = new Roster();
  42:             roster.connection = xmppSocketConnection;
  43:         }
  44:         
  45:         private function configureListeners():void {
  46:             // Add event listeners related to the connection
  47:             xmppSocketConnection.addEventListener(LoginEvent.LOGIN, onLogin);
  48:             xmppSocketConnection.addEventListener(XIFFErrorEvent.XIFF_ERROR, onXiffError);
  49:             xmppSocketConnection.addEventListener(DisconnectionEvent.DISCONNECT, onDisconnect);
  50:             
  51:             // Add event listeners related to messages
  52:             xmppSocketConnection.addEventListener(MessageEvent.MESSAGE, onMessage);
  53:             
  54:         }
  55:         
  56:         /**
  57:          * Attempt to connect to a XMPP server
  58:          * 
  59:          * @param    username
  60:          * @param    password
  61:          * @param    server
  62:          */
  63:         public function connect(username:String, password:String, server:String):void {
  64:             // Attempt to load a crossdomain permissions file
  65:             Security.loadPolicyFile(server + "/crossdomain.xml");
  66:             
  67:             // Connect using standard profile
  68:             xmppSocketConnection.username = username;
  69:             xmppSocketConnection.password = password;
  70:             xmppSocketConnection.server = server;
  71:             xmppSocketConnection.connect("standard");
  72:         }
  73:         
  74:         /**
  75:          * Disconnect from a XMPP server.  If not currently connected this will have no effect.
  76:          * 
  77:          */
  78:         public function disconnect():void {
  79:             xmppSocketConnection.disconnect();
  80:         }
  81:         
  82:         /**
  83:          * Return the roster as a data provider
  84:          * 
  85:          * @return
  86:          */
  87:         public function getRosterDataProvider():ArrayCollection {
  88:             return roster;
  89:         }
  90:         
  91:         /**
  92:          * Send a message to the server
  93:          * 
  94:          * @param    message
  95:          */
  96:         public function sendMessage(message:Message):void {
  97:             xmppSocketConnection.send(message);
  98:         }
  99:         
 100:         /**
 101:          * The user has successfully logged on to the XMPP server
 102:          * 
 103:          * @param    connectionSuccessEvent
 104:          */
 105:         private function onLogin(loginEvent:LoginEvent):void {
 106:             roster.setPresence(Presence.SHOW_CHAT, "", 0);
 107:             
 108:             sendNotification(ApplicationFacade.VALID_LOGIN);
 109:         }
 110:         
 111:         /**
 112:          * There has been a Jabber error - most likely an incorrect username/password error
 113:          * 
 114:          * @param    xiffErrorEvent
 115:          */
 116:         private function onXiffError(xiffErrorEvent:XIFFErrorEvent):void {
 117:             if (xiffErrorEvent.errorCode == 400)
 118:                 sendNotification(ApplicationFacade.INVALID_LOGIN);
 119:             
 120:         }
 121:         
 122:         /**
 123:          * The user has disconnected from the XMPP server
 124:          * 
 125:          * @param    disconnectionEvent
 126:          */
 127:         private function onDisconnect(disconnectionEvent:DisconnectionEvent):void {
 128:             sendNotification(ApplicationFacade.DISCONNECT);
 129:         }
 130:         
 131:         /**
 132:          * Received a message from the server
 133:          * 
 134:          * @param    messageEvent
 135:          */
 136:         private function onMessage(messageEvent:MessageEvent):void {
 137:             sendNotification(ApplicationFacade.RECEIVE_MESSAGE, messageEvent.data);
 138:         }
 139:         
 140:     }
 141: }

One thing you will notice is that the proxy dispatches another few notifications that we haven’t included in our ApplicationFacade:

  • VALID_LOGIN
  • INVALID_LOGIN
  • RECEIVE_MESSAGE
  • DISCONNECT

So lets go back to our ApplicationFacade and add them in:

   1: public static const VALID_LOGIN:String = "valid_login";
   2: public static const INVALID_LOGIN:String = "invalid_login";
   3: public static const DISCONNECT:String = "disconnect";
   4: public static const RECEIVE_MESSAGE:String = "receive_message";

The final thing we need to do is register our new Proxy with PureMVC.  We do this in StartupCommand.as using the registerProxy method:

   1: override public function execute(notification:INotification):void {
   2:     facade.registerProxy(new XMPPProxy());
   3: }

Its quite easy to forget to do this and end up with all kinds of strange errors, so be sure to remember to register any proxies you create.

We’ve finally got the bones of our application up and running so now its on to the views and mediators!

PureMVC Tutorial – Flex, PureMVC, Jabber and XIFF 3: Part 4 – Notifications, Commands & Use Cases

Introduction
Part 1 – Frameworks
Part 2 – Directory structure
Part 3 – Application and ApplicationFacade
Part 4 – Notifications, Commands & Use Cases
Part 5 – Model & Proxy
Part 6 – The Application View & Mediator
Part 7 – The Login View & Mediator
Part 8 – The Roster View & Mediator
Part 9 – The Chat View & Mediator
Conclusion, Demo & Downloads

Notifications are the nuts and bolts of a PureMVC application and are used to communicate between the various actors of your application. Notifications can be used for the following paths of communication:

  • Mediator -> Mediator
  • Mediator -> Command
  • Command -> Command
  • Command -> Mediator
  • Proxy -> Mediator
  • Proxy -> Command

In other words, Commands and Mediators listen out for notifications, and everything can send them. The ‘pattern’ reason for Proxies not being able to directly listen for notifications is to try and encourage the developer to use a command to do this. In other words, if a mediator wanted to effect a change on a proxy it might send a DO_SOMETHING notification, which would invoke DoSomethingCommand which would then retrieve the SomethingProxy and call doSomething() on it. This is less complicated than it sounds and there will be examples of this in the code we’ll be writing.

PureMVC also makes it possible for a mediator to directly retrieve a proxy and call methods on it that change its state, although this is often frowned upon by MVC purists. Having said that, there are some situations when it makes more sense to do this in simple cases rather than run through the Mediator->Command->Proxy chain (probably creating an extra command along the way). Always remember that MVC guidelines are just that – guidelines 🙂

Use case diagram

Use cases

Here’s the use case diagram for our user. Its useful to map these out at the start of the project as there is often a 1-1 mapping between use cases and commands. So now lets create these commands and map them to some notifications (we’ll leave them empty for the moment, but fill them in later).

To add an empty command right-click on the controller folder in the project area and select Add->New SimpleCommand… (if you don’t see this menu item be sure you’ve installed the PureMVC FlashDevelop templates from PureMVC: First thoughts & FlashDevelop templates correctly). Add these three commands:

  • LoginCommand.as
  • LogoutCommand.as
  • SendMessageCommand.as

Now we need to setup our notification. Notification names are just strings, so we need to setup static constants for each one. For larger projects with a lot of notifications its usual to create extra classes to hold the constants, but since we are only going to have a few of them we’ll put them in ApplicationFacade.as.

   1: public static const LOGIN:String = "login";
   2: public static const LOGOUT:String = "logout";
   3: public static const SEND_MESSAGE:String = "send_message";

Now we need to map these notifications to their associated commands. This means that whenever one of these notifications is sent PureMVC will automatically invoke its mapped command. To do this we call the registerCommand method in the initializeController method of ApplicationFacade (note that the STARTUP->StartupCommand notification was already setup in the FlashDevelop ApplicationFacade template).

   1: // Register commands with the controller
   2: override protected function initializeController():void {
   3:     super.initializeController();
   4:
   5:     registerCommand(STARTUP, StartupCommand);
   6:
   7:     registerCommand(LOGIN, LoginCommand);
   8:     registerCommand(LOGOUT, LogoutCommand);
   9:
  10:     registerCommand(SEND_MESSAGE, SendMessageCommand);
  11: }

Now let’s create our XMPP proxy…