SPECIAL FOCUS:
CONFERENCING

From the June 2006  issue of Communications News

Nine keys of online collaboration

In a client-centric conference architecture, users can interact more easily.

by Nigel Spicer

Until recently, online conferencing has fallen short in its collaborative capabilities. In the most familiar examples, online meetings consist mainly of prerecorded material streamed at high band­width from a central server. Aside from text questions, the audience cannot participate.

The limitations most users of conferencing products face result from the fact these solutions are server-centric, rather than client-centric. In server-centric, the server is responsible for streaming content–both presenter content and shared audience feedback. This tends to limit conference participation, since streaming servers are usually expensive and do not scale well.

Streaming software also is complex, requiring specialists to operate it. That limits the ability to hold meetings on the fly, as does the need to have all “canned” content (like slides or video) ready to go before the meeting starts. Because partici­pants will not know until after the meeting starts what additional content they might need, they will not know before the meeting starts everything they should host on the server.

Nor do clients usually have the option to push their own rich media (including live voice or video) directly to other clients. Live client-to-client exchange is often precluded because clients do not know about each other–just about the server–and the server does not support client-to-client sharing because it sees the world as server-centric.

In client-centric conference architectures, each client engages in a shared information exchange with every other client participating in the conference. A server may be involved (usually to supply additional bandwidth) but does not have to be. What distin­guishes client-centric conferencing is not the presence or absence of servers–it is that clients do know about each other and can set up and conduct meetings with each other on the fly and without a server–meetings that include application sharing, rich media exchange, live voice and video chat, and even control of remote users’ desktops, if permitted.

A secure client-centric architecture requires the solution of key problems that previously limited the role of clients in a conferencing application:

Clients find each other. Clients cannot set up and engage in meetings with other clients if they do not know where those other clients are. In a server-centric model, clients only have to find the server, which has a fixed address, not other clients, which often do not. Many clients sit behind corporate proxies that hide their real IP addresses from the Internet.

IP addresses may also change depending on location inside an organization, or may be reassigned from time to time as a matter of corporate policy. Clients outside a company may also change their IP addresses, and will change them every time they connect to the Internet if they employ the dynamic host configuration protocol.

To overcome this type of problem, clients find Web sites by referencing a domain naming service (DNS). When a Web site changes servers, clients still find it because the DNS table is updated. Client-centric conferencing architecture would use the same concept. When one client wants to engage another, it goes to a private or public Web-based service and finds the right address. The naming service would know about that address because every time a client comes online, it would automatically tell the naming service about its current address.

Clients cooperate with each other. Awareness by clients about other clients means more than just knowing where to find each other. It also means having knowledge of other clients’ attributes–knowledge that could enhance the level of collaboration between them. Which remote clients support voice over IP, video, chat, application sharing, shared desktop, for example, and for those that do, at what bandwidths?

Pushing the wrong kind of content to clients who cannot or will not use it is an obvious waste of resources. Selectively and securely pushing the right content, however, means participants can make the most of the resources available to them, whether that resource is content on their hard drives or the bandwidth of their respective Internet connections.

Clients can use a server. In a client-centric architecture, every desktop is both a client and a server to every other client. So why not bring a “real” server into the mix, a machine with greater processing power and a bigger pipe to the Internet? Effectively, the many-to-many connections of the client-centric architecture would be virtualized, with those connections still existing logically even if they are physically routed through what is essentially a single “super client.”

The only difference would be the physical machine running this particular client and the resulting performance boost. There would be no need to change that client’s code base, since it would limit the ability to plug and play the same client on different machines.

Clients optimize data compression. A way to increase efficient collabo­ra­tion is with improved data compression, especially on the low-bandwidth links many clients use. Data compression both expands the number of users who can join the meeting and expands the number of different ways users can participate once they do join.

Not all data-compression technologies are equal, however. Most applications that employ data compression use commodity data compression so hetero­geneous applications can talk to each other in a common language. Where all participants coexist within a private client-centric meeting and the clients all run the same code, the data compression can be optimized for this particular application.

An architecture that allows users to set up meetings, conduct meetings, virtualize the architecture, and also negotiate mutually agreeable bandwidths and conferencing capa­bilities does not make sense without clients that actually do those things. In this architecture, clients do not have to be simply passive receivers of server-based streams. They can be active session participants, with equally functional user interfaces.

They can also be adaptable, meaning different levels of functionality tailored to different kinds of users. Someone interested in text-only chat might want a browser-based Java client. Someone else might want a robust PC-installed version.

Moving to a client-centric architecture makes either of these extremes possible, and lots of possibilities in between. How and when people collaborate becomes much more a choice of the meeting participants, which creates a richer experience before the meeting even starts.

Nigel Spicer is president and COO of 1stWorks, Norfolk, Mass.

For more information:
www.rsleads.com/606cn-250