First Look: Flash Media Server 4
UDP Blocking
For all the benefits of UDP for low-latency delivery, the fact that UDP takes the "bad cop" stance when it comes to data delivery means that some corporations have chosen to block all UDP traffic.
"In order for RTMFP to work, your firewall must be configured to allow outgoing UDP traffic," Adobe states. "While this is the case with most consumer or small office/home office firewalls, many corporate firewalls block UDP traffic altogether. One solution is to configure Flash Player to use a TURN proxy (Traversal Using Relays around NAT)."
TURN is a proxy that allows particular UDP content to flow through the corporate firewall. Unfortunately, the use of TURN requires a bit of configuration work.
"Direct UDP traffic is always attempted and the TURN proxy is only used as a backup," Adobe states. "If the network administrator configures a TURN proxy that allows outgoing UDP, Flash Player can be configured by adding [a] line of code in mms.cfg." (Instructions are available in the Adobe Flash Player Administration Guide for Flash Player 10.) In addition, "When one endpoint is located behind a so-called ‘symmetric firewall,' end-to-end communications may not be possible. ... In this situation, you may use a TURN proxy to aid firewall traversal."
Shared Objects
Another implementation point to consider is the use of server-side programming, media relay and Shared Object programming models. While the Stratus beta did not support these, Adobe's Towes says implementations via FMES will carry some support.
"Many developers use Flash Media Server's Shared Object programming model as a method to store and move data over RTMP connections today," says Towes. "For Flash Media Interactive Server and the Flash Media Enterprise Servers, developers will have the same support for Shared Objects over direct server to client RTMFP connections. In FMES alone, peer-to-peer connection methods for sharing and pushing data are available with RTMFP Groups, as is posting; directed routing and object replication allow data to flow and persist between peers."
A Perfect Storm
The best scenario for the use of RTMFP in conjunction with traditional IP multicasting is a network that has been partially multicast-enabled, with another portion that lacks multicast-enabled routers.
This type of situation is often found in the corporate environment, where an acquisition or merger has taken place.
In one prerelease test, for which MediaPlatform provided code for a multicast-enabled video player, a large technology company had acquired another large technology company. IT mandated that all internal webcasts be done via IP multicast, which worked for the existing network but was not feasible for rapid rollout of corporatewide webcasts across both networks.
"We are mandated by internal IT organisations to use multicasting whenever live video content is delivered," says a spokesperson for the company, which declined to have its name used in this article. "We have been streaming live internally since 1999 and our exclusive means of delivery was via Real, until 2008, where we transitioned to using Flash for external viewers. For internal, we continue to use Real's Helix servers up until today-a load-balanced, heavy-duty Helix implementation sitting within the corporate data centre and managed in-house by the product development IT group."
The technology company was considering a switch from Real to Flash for its internal broadcasts and the acquisition pushed the decision to the forefront, as the acquired company's routers were not IP-multicast-enabled.
Adobe offered the company an opportunity to test the Fusion elements of FMS 4 during a webcast where both traditional IP multicast- and application-enabled multicast delivery would be used.
"Application multicasting was not our primary driver in agreeing to participate," the company spokesperson said. "However, in a phased approach, we see potentially greater benefits of the application multicast over the value of a pure IP multicast implementation. Mixed topology is what we're facing with our network standardisation process, and application multicasting
represents a very significant opportunity to add value rather than causing headaches."
Check out StreamingMedia.com for a more detailed case study on this particular test implementation.
Conclusion
Going back to our original analogy of a late-night infomercial offering both muscle buildup and weight loss, how does Adobe's FMES measure up, given its hefty price tag?
At first look, the answer is quite well. While the upfront cost is high, the ability to use a single server-or two, for redundancy-may be a long-term opportunity for cost reduction.
The claim that Adobe is indirectly making is one that entices enterprise users to upgrade to a server that-if it works for a particular network topology-could yield significant reductions in hardware costs for IP multicast-enabled routers, as well as potentially in the reduction of the amount of transit bandwidth.
For its part, MediaPlatform thinks the product will sell itself, if potential customers see it in action.
"Seeing is believing," said MediaPlatform's Pulier. "As a result of the testing we've done, we've decided to offer a 24/7 ongoing event that will demonstrate how to application-level multicast from within bandwidth-constrained office environments, even if the viewer is on a thin bandwidth connection."