CollabWorx:

Home : Support : Resources : Scalability

One of the most frequent questions we hear from the potential customers is: how many users can your software concurrently support?

CollabWorx SRTC platform is the most scalable collaboration system currently available. However, as we explain below, the importance of the system scalability depends on the application domain. It is important for the users to understand what the general scalability limits of collaboration systems are, and how the basic technologies work together to provide a system with optimal scalability.

In the following, we discuss the issues of system scalability from both technical and functional point of view.

Technical limits to “scalability” of interactive Internet communication systems

Let us for a moment assume that having thousands concurrent on-line users is a good and desirable thing. Is it possible to set up a “conference call” on the Internet with thousands of participants? Are there any fundamental problems with such conferences?

Chat Applications

Consider first a simple chat application. Most of the existing systems use an architecture based on a “central server” (some advanced systems, such as very popular IRC, or the recently proposed AOL architecture for Instant Messaging can have hundreds of such servers, with special protocol allowing for setup of “channels” and forwarding of messages from one server to another). It is a relatively simple matter to build a server that will accept hundreds of connections from individual chats (technically known as “chat clients”), to receive messages from all of them, and to distribute them to all other users. Almost all such systems are based on a simple, socket-based client-server mechanism, and they almost invariably use TCP protocol.

Systems of this type can easily handle hundreds, or even thousands of users per “chat room” or “channel.” While the scalability is not infinite (especially in multi-server architectures such as IRC), it is sufficient for all practical purposes. The main reason for this is that, even if the central server introduces potential bottleneck, it also ensures that message number scales up linearly with the number of system users (i.e, with twice as many users we just use twice as much bandwidth). This is a very favorable situation, since in many other architectures the message number scales with a higher power of the number of system users. Further, the chat messages are usually compact and their frequency is limited by human reaction time, so the bandwidth requirements of such a system are minimal. Chat systems easily scale to thousands of concurrent users.

Shared Whiteboards Are Not Unlike Chats

Consider now a shared whiteboard. Even as it may seem much more complicated than a chat, from the point of view of network performance and scalablity the difference is minimal. A shared whiteboard application must define internal language (or protocol) to describe operations such as creating, moving, or changing object properties. This protocol can be cast into a form of messages and, via central server, sent to all other instances. Compared to a chat, the whiteboard may generate more traffic due to more complex messages, but if the whiteboard itself is truly concurrent (i.e., it correctly resolves all race conditions resulting from many people concurrently drawing on the canvas), its “scalability” is very good. The question is, however: do we really want thousands of users drawing on one whiteboard?

Event-sharing Systems Are Inherently Scalable

CollabWorx SRTC platform is built around similar concepts. No matter how complex the application, the instances of it always communicate via serialized messages (“events”) sent to an entity we call a “meeting engine” and , then, distributed to all other client instances. Hence, the great majority of SRTC application modules can be used with hundreds of concurrent on-line participants.

What Exactly Is An “Event-sharing” System?

Collaborative web-based event-sharing systems are a direct outgrowth of the basic client-server architecture of the Internet. Without going into the theory behind such systems, let us consider the simplest example: a shared browser.

Using traditional application sharing the person who wants to show others contents of the browser (a “presenter”) would be the only one running it. As the presenter flips through Web pages, his/her browser downloads them from the network. Next, the graphical representation of the Web page is sent via the network to all other conference participants. Even if shared display technologies compress the information, still the network traffic generated by application sharing is considerable.

In the event-sharing model, the architecture is completely different. Every user runs its instance of a browser (and the browsers can be different - Netscape or IE does not make any difference). When the instructor gets a new Web page, his/her browser simply sends the new URL to the conference engine, which, in turn, sends it to all other conference participants. Remote browsers receive the URL and simply download it from the same Web server.

The technically inclined user could now say: ah, nonsense! First, shared browser is a trivial example. Can you always synchronize application instances in such a way? Second, you have generated a lot of unnecessary network traffic by sending the same information to multiple browsers!

Such comments, while insightful, are not entirely correct. The answer to the first problem is: yes, we can always do that. CollabWorx SRTC platform supports very complex applications using the same principle, such as fully immersive 3D visualizations. The second comment requires quantitative analysis. Application sharing using display sharing technology generates an order of magnitude higher traffic. Further, in this model it is the user workstation that must send all these data streams, not a powerful Web server tuned to serve thousands of the concurrent requests. Server activity does not affect performance of the end-user machines. Next, in many network topologies such as, for instance, a classroom delivered from an instructor on the East Coast to California, the requested network bandwidth can be reduced to just one stream by simply installing a caching proxy server at the recipient's site. If all these methods don't help, CollabWorx SRTC platform supports the ultimate remedy: URL mapping. This technology allows system administrator to assign separate contents servers to groups of users, radically solving the scalability problem for data delivery.

Non-scalable applications

The scalability problem shows its ugly face when we start using two categories of applications: audio/video conferencing, and the so-called “application sharing.” These application types, while seemingly different, have very similar scalability problems.

Audio/Video Conferencing

Consider first audio/video conferencing. As opposed to a chat or a whiteboard, AV conferencing has two unpleasant features: first, it tends to create a lot of data, second, the data is delay-sensitive (especially audio). These two features make “central server” architecture a little less appealing. Central server is a re-transmitter by it's very nature, and it usually introduces additional delay to the media streams. Can we circumvent this problem?

Distributed “client-client” or Peer-to-Peer architecture

An alternative to the “central server” architecture is a fully distributed “client-client” system. A central entity is only needed to set up data flows, later all streams are being distributed strictly peer-to-peer. With many concurrent users, each client must send data streams to all other clients. Suppose now (a silly proposition, but invoked on purpose) we want a video conference with 100 concurrent users, arranged so that 100 participants can see each other. This means that, at any given time, there will be 99x99 = 9801 video streams on the net. Assuming rather low bandwidth of 20 Kbps per stream, such a conference would require ~200 Mbps on the backbone, and ~2 Mbps on the user link in each direction. This clearly may be a (financial) problem.

The overall bandwidth needed by an A/V session using fully distributed technology is only part of the problem. Another, in many cases more critical, issue is the bandwidth necessary to push the data from workstations of the conference participants. This is an important consideration: while the conference engine is usually installed in the ASP or IT data center and enjoys large available bandwidth, the user machines can be connected via a dial up. In this case, sending multiple media data streams to other conference participants is simply out of question.

Is Multicast a universal remedy?

The technology designed to circumvent such bit rate explosion is known as multicast. The principle is very simple: instead of sending 99 video streams to 99 users, we just send one stream to an address to which all other users can “tune.” This is akin to radio or TV broadcast over air or cable. There is one problem, though: multicast is poorly supported on today's Internet backbone, very reluctantly (or not at all) supported on academic or corporate networks, and virtually ignored by ISPs. For all practical purposes today, multicast is science fiction, or a very expensive custom support job.

Some users might decide to opt for multicast anyway, especially those with access to new networks such as Internet 2. There is an additional problem, though: multicast requires that media streams are sent using UDP protocol. UDP is a natural way of sending delay-sensitive media, but this protocol interacts poorly with current trends in firewall setup. UDP-based software creates a whole gamut of security-related problems. Discussion of security issues is well beyond the scope of this document, so we just ask the reader to trust us on this.

Re-transmitters—a poor man's multicast

In absence of pervasive support for multicast, and facing very poor scalability of the fully distributed architecture, many of the today's AV conferencing solutions implement “central server” architecture also for media streams. CollabWorx SRTC platform offers multicast-based AV system, but in most cases we implement a “reflector”-based solution. We don't use the standard conference engine, though. This is because the traffic patterns for chats/whiteboards are very different than traffic patterns for A/V applications. A specialized, optimized re-transmitter architecture uses TCP as transport protocol to alleviate problems with firewalls and NAT (Network Address Translation) architectures and allows to preserve real-time characteristics of the media traffic in spite of using TCP. Our A/V support easily scales to hundreds of concurrent users even without multicast. In addition, this architecture reduces the bandwidth requirements for the end-user link to the bit rate of one audio and video stream.

Not only network limits scalability!

Assume now that bandwidth is no issue. Will our giant conference call work?

Unfortunately, it is unlikely. Even the fastest of the currently available desktop machines have no sufficient resources to decode 99 digital video streams, while encoding its own outgoing stream. Most system will bog under load with (ballpark) 10 to 20 concurrent users: CollabWorx software will support ~50, but this is about it. This is important observation, since it introduces another “dimension” to the scalability problem: the CPU resources.

Shared display is an inherently non-scalable technology!

For display-sharing based “application sharing” using solutions such as MS NetMeeting, VNC, PC Anywhere etc., situation is even worse, since multicast is usually not even an option. This is because most of these solutions use TCP. Shared display solutions don't scale at all! Network performance is not as much a problem as is CPU overload and excessive memory requirements. Anybody who tried to use NetMeeting or VNC have quickly noted that performance of the workstation running the application being shared rapidly drops with the growing number of conference participants, as both CPU and memory get saturated. Screen sharing process is computationally very expensive. Actually, it is far more expensive than audio/video decoding!

Bottom line

Main technical impediments to good “scalability” of Internet conferencing solutions are:

lack of universal multicast support
for applications such as audio/video conferencing and “application sharing,” the insufficient computing power on even fastest workstations now available.

Technologies based on display replication, such as Microsoft NetMeeting, VNC, or PC Anywhere do not scale at all. It is not impossible to put together Internet “conference calls” with more than a few participants using these solutions.

The only solutions that scale to higher numbers are “event-sharing” systems, such as our CollabWorx SRTC. If our system cannot reach certain number of concurrent users, no other system will.

Software based audio/video conferencing solutions, such as popular CU-SeeMe, can support conference calls of up to 8 users. The fastest workstations manufactured today push this number to perhaps 10 or 12. The A/V module of CollabWorx SRTC running on top-of-the-line workstations will support up to 50 concurrent users. Here is the proof (click for a bigger image):

So, how many users can you concurrently support?

The exact number will obviously depend on the performance of the hardware on which our system runs, and on the type of your application. For a typical configurations available today, a CollabWorx™ Virtual Meeting not using audio/video conferencing will easily support 200-300 concurrent users. If fully symmetric audio support is necessary, this number will drop by a half. With symmetric video (everybody sees everybody) the maximal number of participants probably won't exceed 50, unless really powerful hardware is installed for both networking and digital video processing.

CollabWorx SRTC Secure Meeting used for distributed learning, where the network traffic is dominated by transmission of data from the instructor to students, may easily support classes as large as 500 participants even with active audio loop. Use of video does not change this, since SRTC Virtual classroom only permits one video stream per class or break-out group, with system always showing the speaker.

Is it a sufficient number???

Yes, it is. We guarantee that your application won't hit this limit, even if you now think it will. Here is why:

The technical scalability limits of our collaborative platform are well beyond what is feasible from the standpoint of the interactive process the application needs to support.

Now, then! A vendor won't tell us what we need!

Well, perhaps we can help. We just understand the issues pretty well. It is our bread and butter, isn't it? :-)

The users contemplating purchase of a distance learning or virtual meeting software very often have fundamental misconceptions of what kind of process they really want to support using such software. Some of our potential customers come with a vision of the Hall A of the SF's Moscone Convention Center, filled to capacity, seeking a software solution that will allow them to talk to all these people and interact with them, directly from their company's web site. This is what we call a misconception.

Interactive meeting vs. broadcast

CollabWorx SRTC platform and the derivative products such as Secure Meetings or Meeting Portal have been designed to provide extensive interactive capabilities. This means, we focus on interactive team work, or interactive learning. Bill Gates or Larry Ellison speaking in the Hall A do not interact with 10K people—they broadcast to them.

It is well known that, in real world, meetings with more than several users are not very interactive. For teaching activities, this limit moves up a little—perhaps to around 20 students. Our software has been designed to support the kind of activities usually conducted in relatively small groups: a technical project meeting, a scientific seminar, an executive brainstorming session, a company board meeting, a medical consult—or simply a typical college class. The practice of the Web-based meetings shows that the same limitation holds for on-line gatherings.

An on-line language training provided using CollabWorx SRTC-based BLT system

Technically, our products can support a number of user that is far larger than the optimal number for a particular activity. As an example, we have supported academic classes taught from a Northeast university to five colleges and several other locations in the South, with close to 100 students in the class at five different locations. The software had no problem with it—but the instructor did. It is difficult to answer questions fielded by such a large group of students, it is hard to see what they do in breakout groups, it is hard to interact.

Bottom line (again): for the activities such as interactive virtual meetings or interactive distance learning you don't really need software system supporting hundreds of concurrent users in one event!

Customer not convinced...

Well, the potential customer says, don't YOU tell ME! I KNOW we need to reach hundreds of users! My boss says so, and so does my marketing department. We need to reach thousands or my job is history!

If so, perhaps you are looking for a wrong technology?

Select the right solution for a given business goal!

Our synchronous Internet communication systems are relatively complex. If the only thing you are looking for is a multimedia broadcast with limited interactivity, you can select and deploy technologies that have no inherent scalability limits, are much simpler to deploy, and much easier to maintain. Why use an advanced and complex technology designed to do difficult things while you can achieve your objectives with something much simpler?

Take our LecCorder™ product. If your main goal is, say, to make a Web presentation of your new products, then, using LecCorder™, you can produce it in a short time and very inexpensively, publish it to the Internet in an eye blink, send mass mail to your customer base pointing them to this new resource, and have your Web server deliver your message, while you and your marketing department play golf. Audio, video, and arbitrarily complex visuals are supported, and your customers can ask questions asynchronously via e-mail sent to an account associated with the presentation.

It is simple, inexpensive, robust, reliable, and, most importantly, effective. The trick is to produce and publish the needed media material fast, and LecCorder™ does just this.

The (real) bottom line

Technical scalability of the CollabWorx SRTC platform exceeds by far the limits that are imposed on the application by the very nature of interactions between event participants. As the number of concurrent users grows, the level of interaction necessarily decreases. At certain point, the intended interactive meeting inevitably turns into a broadcast.

In certain applications, such as “discussion panels,” it may be beneficial to have a small number of interactive users and a large, passive audience. Whether the cost in human labor and computer resources associated with moving such meetings to the Web is justified is a business-related question. In any case, CollabWorx SRTC platform is ideally suited to support them.

If the main goal of a web meeting is a broadcast with limited interactivity, a different set of tools may be appropriate. New product and technology presentations are good examples of such events. Our other products, such as LecCorder™, ideally serve needs of such projects by providing a fast, inexpensive platform to produce, publish, and deliver synchronized contents over the Web.

[Home] [About Us] [Products] [Downloads] [Search]