Re: Virtual Meetings

One premise of virtual meetings is that all participants receive broadcasts simultaneously. The nature and format of broadcast content may vary from one type of application to the next. The types of messages for slide presentations would be different from those of white boards, or chats. But they might share a common architecture for delivery.

The whole idea of broadcasting may seem counter intuitive to some Web developers. We normally think in terms of one-to-one pairing between a browser request and a server response over a single socket. A browser makes a request and gets a response; the cycle is complete.

The typical way to simulate broadcast services using browsers is to set up a continuous loop using a timer and JavaScript to fire off requests at say 1 to 5 second intervals for "new" content. However, that's inefficient and doesn't provide for participants getting simultaneous responses. A response may show up in 1 second for one participant, or 10 seconds for another, which is annoying. It also requires that posted content from one participant be stored persistently so it might be retrieved soon thereafter by others. I recently reviewed about 15 chat servers, mostly PHP, which followed that design. It's really common.

Some of us may have read about "Comet" implementations that allegedly work better.

I've been working on a new client-server architecture that takes a somewhat different approach, which is both efficient and provides for essentially simultaneous delivery of broadcast content. I've delineated the architecture along with an application that demonstrates a meeting of 4 chat participants, though I could see it scaling to thousands, even on a small IBM i server.

http://bit.ly/yVUUuQ


I'd appreciate feedback, or questions.

-Nathan