|Programming Flash Communication Server|
|Home | News | Sample Chapters | Source Code | Technotes & Articles | Errata|
Chris Hock and Srinivas Manapragada provided a sneak peek of some of the features that may make it into the next major release of the Flash Communication Server. However, Chris stressed that Macromedia is not making any commitments to implementing anything and that the next release may have new features he did not mention. Giacomo Guilizzoni (a.k.a. Peldi) recorded the event in Breeze and posted a recording here:
Stefan Richter has also posted a text summary of the sneak peek session here:
What follows are my notes of what Chris and Srinivas had to say, some comments and questions of my own, and some clarifications Srinivas was kind enough to send me after the event. You'll find Srinivas's clarifications in quotes set in from the main text.
The Communication Server team is looking at ways to have applications run as separate processes "by virtual host and by application." The idea is that one application could not bring down others in the same VHost or server. This is especially important for hosting services and others that run large numbers of applications.
A natural question will be how much overhead running applications as separate processes will add to the server and if these processes are true OS-level processes? Will each process get a separate copy of the Communication Server just as a Perl script might get a separate instance of the Interpreter or will some other mechanism be used? Will one instance be able to bring down an entire application? Regardless of the implementation details, insulating applications from each other is a great idea. Here are some answers from Srinivas:
"The intent is that a server may be run in one of three process scopes - vhost/app/inst - which run each vhost/app/inst in a separate process. The inst scope will isolate one app instance from another, useful when you don't want one room to bring down another. Of course there is definitely a certain overhead when running as a process, however the site operator can make the trade off by choosing the appropriate scope. Running in inst scope further enhances the reliability, since each instance usually has a limited lifetime, avoiding cumulative errors building up over time. Also to answer another question you raised each process does not get its own server, instead all processes cooperate to appear as one server."
The development team is looking at ways to accommodate larger numbers of users and larger numbers of streams. They are looking at a "lot of different things" but a large part of the focus in the sneak peek was on distributing certain types of applications by adding an "edge server" with a smart caching feature to the mix. In the new application distribution scheme there would be two types of servers: an "origin" and multiple "edge" servers. A full-fledged Flash Communication server acts as the origin and it sounds like some other type of server acts as an edge communication server. The edge servers are capable of caching content from the origin server and passing back connection data from clients attached to the edge to the origin server.
You can do the same thing with FlashCom today, with the possible exception of smart caching, but it requires a significant level of programming. The origin/edge scheme sounds similar to having master and distribution instances of an application running on different servers except that much of the development work is done for you and you would not have to install a full FlashCom server on the edge. The bandwidth impact of splitting applications between origin and edge is that a single stream can be sent from the origin server to each edge server where it is split into separate TCP streams and sent on to each client connected to each edge server. It sounds similar to a distribution instance using a stream proxy to redistribute streams to multiple clients. But smart caching implies some sort of enhancement beyond what is available with FlashCom today. After reading this Srinivas wrote:
"I suppose the term smart caching is a little limited, I should perhaps have said 'smart proxy' or 'smart edge'. The edges will accomplish four main things:
- Connection Aggregation - reduces connection load (sockets) on origin
- Live Stream Splitting - eliminates stream duplication
- OnDemand Stream Caching - services stream 'plays' locally once cached
- Smart SharedObject Handling - handles local rejections etc.
In all of these cases the load on the origin is dramatically reduced."
It is interesting to speculate on how Macromedia Breeze might make use of the new origin/edge architecture. For example if Macromedia wanted to improve Breeze performance across the world they might want to place edge servers with a number of core Internet Service Providers. Where FlashCom developers have very large corporate accounts they might be able to place edge servers at local nodes within a large corporate WAN. The origin/edge scheme is also designed as a clustering/load balancing solution for certain types of applications. Network load-balancing appliances can be used. Macromedia seems to be looking at selling content delivery networks. I wonder if they will create their own content delivery network in partnership with some large ISPs and sell time on it? Aside from possibly supporting Breeze I can't imagine Macromedia selling affordable time on it for custom n-way applications.
Some other questions: will smart caching be available on origin/FlashCom servers as well? How far will the origin/edge scheme go in terms of supporting different types of applications? Media on demand will be supported and it sounded like broadcast trees but what about two-way live event applications were streams are forwarded from some clients attached to the edge to the origin and then redistributed back out to the edge? Will some n-way applications be able to take advantage of the origin/edge scheme? What can't an edge server do that an origin server can do? Srinivas's response sounds great:
"All kinds of applications will benefit from edge servers. Some applications like broadcast trees will become trivially easy to build."
Licensing of edge servers will require changes to the licensing scheme and Macromedia may take the opportunity to tweak licensing of FlashCom. They may end the restriction of not being able to add pro licenses on top of personal licenses.
One thing seemed certain: Macromedia has no plans to implement UDP-based streaming and multicast. Given the current state of multicast on the Internet and a desire to keep the Flash player size small that is not too surprising. However, multicast is a powerful technology that can dramatically reduce the bandwidth an edge server will need within some enterprise networks. Maybe one day... Srinivas writes:
"We did consider multicast, however we have to weigh this against other features and the available resources."
The new codec formally announced at MAX will be supported. It was not clear what level of support is involved. Will new versions of the player have additional encoding capabilities including the ability to encode at variable bit rates or will the new codec only be for playback?
The time to seek to any position in a very large FLV will be dramatically improved and will not require server-side index files. A question came up about the maximum size of an FLV and the answer appeared to be that the size limit is related to the size of a 32 bit number. I don't know if that is the number of bytes in the file or some other measure.... and here's the answer from Srinivas:
"The FLV size is constrained by two factors - timestamps and file addresses. Timestamps are 32 bit quantities that represent time in milliseconds, so an FLV cannot grow longer than 232/1000 ms, or approximately 50 days. The file address is also a 32 bit quantity, so the file size cannot go beyond 4GBytes."
W3C compliant logging may be introduced so that W3C compliant log files will be generated by the server. The contents of the log files will be configurable and can contain the bytes in/out used by each client required by billing applications.
An XML API for server administration and server monitoring may be introduced.
Macromedia may introduce server-side support for "XML sockets." Most likely this means XML.sendAndLoad like request/response support. But, if this is for persistent socket connections as in Flash's XMLSocket object it could be a very powerful tool for working with other servers and clients. If that's the case you have to love this! If not it still represents an opening of FlashCom/App server communications outside of Flash Remoting. FlashCom may also be able to directly consume Web services. Here's what Srinivas had to say about this.
"The intent is to support both persistent bidirectional xml sockets, as well as the request/response mode. Apart from this we are planning to support webservices also. All these mechanisms will be analogous to what's available in client side actions script."
I think Flash Remoting is a great technology but it is great news to hear that FlashCom applications may not have to rely on Remoting to talk to application servers.Persistent XML sockets is a wonderful surprise!
Sandboxed server-side file access - I assume to read/write log and text files within some sort of restricted file types or directory space? Will the sandboxing be on a per application or Vhost basis? If you are not running Vhosts do you still have Sandbox restrictions? Will you still need them? Can the server administrator control the sandbox restrictions? I hope so because I can imagine some administrative applications may need to access files owned by other applications.
There may be a Java and C++ API for pushing audio, video, and ActionScript data into Flashcom. This would allow the creation of non-Flash clients that could stream video that is initially encoded to WMV or some other format. The client would presumably convert it to FLV and then send it on to the server. Clients could dynamically generate stream data and push it into the server. It sounds like a company that makes specialized encoding hardware could use the libraries to send multiple variable bit-rate encoded streams to the server. We'll see if any vendors jump on the opportunity and how low Macromedia can make the activation barrier for doing so. For application servers an interesting challenge will be to see how this feature will allow an application to talk to multiple instances at one time. Will Macromedia provide examples or code that make use of multiple threads running on an app server to help manage asynchronous communications? It will be interesting to see how rich the API and sample code is and how hard it is to use. Does Macromedia do a lot of the scaffolding work for you? Regardless, it is very encouraging to hear that non Flash clients may be possible. It also opens up a lot of potential for pushing real-time data from databases and application servers into FlashCom and will be important for building larger scale applications.
There may be a third-party service integration layer in FlashCom where C++ DLLs or modules can be written that integrate with the server. One type of service might allow user definable access control policies that access LDAP or other systems using native code. The server will run the C/C++ code before passing a client connection on to an application instance. The feature may be important for pay per view stream systems and open up other revenue generating possibilities. How far the server could be extended by a service integration layer remains to be seen.
Another question at the session was regarding having the server downsample high resolution streams for clients with lower bandwidth. Chris seemed to translate the question into having the client send a multi-bitrate stream or multiple streams for a single video source to the server and said it was something he would like to see.
Another thing they are working on is record/playback of jpg and jpg streams. But it wasn't clear if the player could send individual jpg frames or a stream of them. Is it the same thing as JPEG Video? We'll have to wait and see if there is more to this than still frame display or flip-book animation.Here's more on this from Srinivas:
"Essentially you will be able to publish a video stream as a series of jpegs. This is useful when integrating with other applications that expect jpegs. You would most likely be able to playback these as a video stream."
There were questions about screen sharing being incorporated into FlashCom and Chris responded that there were good use cases for screen sharing in applications like Breeze and Web casting that Macromedia might package up but not likely for FlashCom. Through the session Chris referred to FlashCom as a streaming media server. When he talked about markets for FlashCom he referred to marketing agencies and the entertainment industry among others. The implication is that Breeze and possibly other Macromedia applications built on FlashCom that need screen sharing would have it but you won't get it by buying FlashCom. I understand that Macromedia is pushing hard into video and that they have never seen significant revenue from selling socket servers, but I'll be disappointed if they reserve a feature like screen sharing for themselves. Its been a long time since the release of Breeze Live. Screen sharing works and there are clearly FlashCom developers who want to build their own apps that incorporate it - and not just Breeze competitors. Breeze is a big powerful and expensive product. My University bought it because it would take us years to do something similarly full featured. It is a big application with a lot of developer time in it. Releasing screen sharing shows a commitment to FlashCom developers. Unless there is some third party licensing problem they aren't telling us about, Macromedia should just release it.
What will the next version of FlashCom look like? Whatever Macromedia does, the focus of the sneak peek was clearly media delivery. With the announcement of the new video codec at Max that's not a surprise. At least people can stop asking if they will see another version of FlashCom - they will. It was exciting to hear Chris and Srinivas talk about some of the things they are working on for the next release. I really enjoyed hearing about all the options for integrating FlashCom with application servers and therefore into the enterprise. I'm looking forward to seeing what the service integration layer looks like.
I wasn't able to get to Max so it was great to be able to watch a recording of the session. Peldi showed again you can do a lot with a Webcam, microphone, and Breeze. It's an interesting paradox that even though I could watch the session - so I didn't need to go to Max to see it - that I'm now considering going to Max next year.
It was great to finally hear what Macromedia is working on and I commend them for releasing some information. I enjoyed the session until the end when the subject of screen sharing came up. It was discouraging to hear that Macromedia may withhold enhancements to FlashCom and access to important features in the Flash Player. That they don't believe there are use cases for it outside of their own applications is not credible.
After posting the page above there was some discussion on the Flashcomm mailing list. To step through the thread go to:
and search on the string "Sneak Peek Summary Comments and Clarifications"
I've also had a chance to read the Oct 28/04 chat on Peldi's coding cafe where the future of FlashCom came up as did screen sharing. Pritham Shetty was in attendance and after the usual caveats made these points about screen sharing:
Pritham was asked if there could be an option for people to update their player and replied:
Of course his comments are during an informal chat. But it seems the main stumbling block to screen sharing is Macromedia deciding under what circumstances the Flash player can be extended.
November 03, 2004
Postscript added November 06/04