oreilly.comSafari Books Online.Conferences.
Articles Radar Books  

P2P Profiles

Allcast: New Life for Live Content


Streaming broadcasts, such as radio programs, place extremely high stress on Internet servers and require the purchase of large amounts of bandwidth. Allcast has found a way to make broadcasting more feasible through an unusual peer-to-peer model. It bears some resemblance conceptually to Napster, but deals with real-time media rather than files and makes the most of real-time connections between users. It can also be compared to bucket-brigade P2P protocols (where each site passes content on to the next site) but everything happens in real-time; there is no element of store-and-forward.

AllCast is useful when many people -- hundreds or even thousands -- want to tune in simultaneously to some live event on the Internet. I think, for instance, of Sun Microsystems's JXTA announcement that I'm sure was viewed by many readers of this article all at the same time.

AllCast Architecture and Basic Operation

The main technical idea behind AllCast is that content fans out from the central site: while the first few users to connect get their content from the originating server, they then send the content to the next set who request it, and these in turn send it to the next set.


Also in P2P Profiles:

Tadaaa! It's Thinkstream

OpenCola: Swarming Folders

Jibe: Building distributed databases that standardize product searches

XDegrees tackles name service and file caching

Porivo: Load Testing with P2P

Each user starts by visiting a central server; typically, the company offering the content will provide a Web site where the user starts. The user needs an AllCast plug-in, which takes up only 120Kb. Once the user indicates he or she wants to join the broadcast, AllCast's software kicks in. It determines the speed of the user's connection and searches for another user who has recently started to view the content and has a connection with a similar or greater speed.

If there is no one suitable online, the central site transmits content from its own server in the traditional fashion. If a suitable user is found, the central site makes it a sender and connects the new user to it as a recipient.

Marc Steatham, chief marketing officer of AllCast, notes that the live content never goes to any user's hard disk; it simply is read from the network into RAM and then sent out again over the network to the next users. This makes it efficient and responsive. The overhead introduced by AllCast introduces no delay into a broadcast.

The problems AllCast had to solve were:

  • Matching recipients to senders with comparable bandwidth, so each user can make the most of his or her Internet connection without overloading anyone. AllCast matches users with other users who can meet their bandwidth needs. The content owner indicates the minimum bandwidth needed to join the broadcast.
  • Dealing with senders who disconnect unexpectedly, and routing recipients to new senders. Whenever a sender disconnects, AllCast can either return its recipients to the central site or automatically send the recipient to another sender without introducing a hiatus or delay.

The instant reconnection in the second point illustrates one of the clever uses of peer-to-peer thinking in AllCast. How can a streaming broadcast be resumed transparently, without the user noticing, in case of a disconnection? The solution lies in storing information in each peer.

Suppose that users A and B get their content directly from the central site, as shown in the figure. User C comes along and is automatically connected to A by the central site. User H then joins and is connected to C; then user K joins and connects to H. K knows not only the IP address of H, but of C and A. If H disconnects, K can try C, then A, then the central site. In other words, users can manage their own connections to a large extent and burden the central site only as a last resort.

AllCast's Marc Steatham will take part in a panel on distributed streaming at the O'Reilly P2P & Web Services Conference, Sept. 18-20 in Washington, DC.

One naturally asks about security when independent parties are passing along content. AllCast uses encryption to protect the content from tampering (exchanging the secret key as part of the initial connection to the central site), but in any case, Steatham does not believe malicious interference is a major risk with this kind of application. Between the encryption, the continuously changing content and the unpredictable connections made between peers, there is only a tiny window for any attempt to intercept and change content.

Servers Come in All Sizes

I asked Steatham whether the value of AllCast was limited to large sites. Not many sites have hundreds and thousands of simultaneous viewers. And even if AllCast should succeed financially by supporting a new industry of big broadcasters, that business model has little interest to me. I wanted to know whether there's anything in AllCast for the little guy.

Yes, said Steatham emphatically. As proof, he pointed to DJCentral.com, an AllCast beta partner. DJCentral.com offers a service to small-time or home DJs who may have only three or four listeners at any one time. Someone with a home computer and a modest 56K connection could play the music he likes to as many listeners as care to tune in.

In this case, DJCentral.com is licensing AllCast on the behalf of its clients. Technically, an individual home DJ could just as well choose to license AllCast directly. (The reason for using DJCentral.com involves the non-technical issues of exposure and advertising. It's hard for new listeners to find individual Web sites for home DJs, DJCentral.com provides a portal for them.) Licenses are based on the number of simultaneous users a client wants to support; once the license is obtained, the client can offer as many events as it wants. This pricing structure is convenient for both home DJs and major broadcasters.

AllCast has a number of Beta partners and received the first order for its final product on April 25.


I am intrigued by the possibility that AllCast could give a new impetus to streaming media on the Internet, which currently suffer from quality-of-service and bandwidth problems. It's interesting to note, however, that AllCast is peer-to-peer in its architecture rather than its social organization. There is a one-way stream from a central broadcaster to multiple consumers, which is why Steatham likes to call their technology "peer-to-multipeer." But like the Web, AllCast software could lower the barriers to entry for low-budget sites.

If AllCast allows lots of people to offer radio and video online without requiring enormous servers and T1 lines, it could lead to an explosion of new stations, like the long-hoped-for microradio (low-power radio) movement that was recently stifled legislatively.

Another hurdle AllCast has to overcome is user impatience. The desire to listen to a broadcast is often made on impulse, and people don't want to take the trouble to install yet another plug-in for access to just one more medium, even though the plug-in is free. (Thanks to Jon Orwant for this observation.) But if they make this effort just once, the plug-in is present for all future AllCast sessions.

Andy Oram is an editor for O'Reilly Media, specializing in Linux and free software books, and a member of Computer Professionals for Social Responsibility. His web site is www.praxagora.com/andyo.

Return to OpenP2P.com


P2P Weblogs

Richard Koman Richard Koman's Weblog
Supreme Court Decides Unanimously Against Grokster
Updating as we go. Supremes have ruled 9-0 in favor of the studios in MGM v Grokster. But does the decision have wider import? Is it a death knell for tech? It's starting to look like the answer is no. (Jun 27, 2005)

> More from O'Reilly Developer Weblogs

More Weblogs
FolderShare remote computer search: better privacy than Google Desktop? [Sid Steward]

Data Condoms: Solutions for Private, Remote Search Indexes [Sid Steward]

Behold! Google the darknet/p2p search engine! [Sid Steward]

Open Source & The Fallacy Of Composition [Spencer Critchley]