| World Wide Conferencing Protocol | |
|---|---|
|
|
| Contents | |
IntroductionAs the Internet becomes available to the masses, the need for online conferencing systems grows. This need is fulfilled by the design of small-scale multimedia conferencing systems, but another type of system is desired: a world spanning system that allows people from around the world to meet and exchange thoughts, opinions and culture, or to cooperate for their profession or in their spare time. Such systems already exist, like IRC. However, they tend to scale bad, in bandwidth usage, CPU usage as well as memory usage. The objective of this project is to design a highly scalable protocol that can be used to setup a large system for realtime text-based conferencing. It should be easy to extend the protocol for other media, like audio and video. The principles needed to create a highly scalable distributed system shall be developed on the fly. Some of these principles can be deployed in other distributed systems as well.This work has been conducted by Gerrit Hiddink in his spare time. If you would like to sponsor this work, donate something, hire me or if you want to know more, contact me ModelThe target protocol assumes a network of nodes that keep and exchange state information, and clients that connect to nodes to make use of their service. The node contains, amongst others, a conferencing server. The connections between nodes are called links. Clients are programs that run on the computer of the user that wants to be involved in a conversation.The network connections are reliable point to point connections. Each network node has a unique address within that network. A node may have connections on different types of networks, so that information can travel from one network to another. Conversations take place in channels. A channel has a unique symbolic name, which is used to refer to it. A client can join a channel, after which all events on that channel are sent to the client by the server the client is connected to, and everything the client does on the channel is sent to all clients on the channel. An event can be a client joining or leaving a channel, or a client saying something on a channel. A client can join more than one channel at a time. A special type of channel is the newschannel, which are meant for news distribution or other one-way traffic. In these channels, senders are distinguished from receivers, in that receivers cannot cause any public event on a channel. Clients can also send private messages to eachother, invite eachother to join channels, or ignore all events from another client. Design ObjectivesScalabilityOne of the main objectives is scalability. In spite of the fact that a large part of scalability properties are caused by the way the protocol is implemented, the protocol still has to be inherently scalable. Its bandwidth consumption, as well as its processing power needs and memory consumption have to scale well with the total number of users, channels and nodes participating in the target system. All of these resources should scale linear or less to any of the mentioned parameters.RobustnessThe object protocol has to be able to cope with network outages, without a disruption of the offered service. This implies that the routing mechanisms have to be able to reroute traffic via backup routes when main routes become invalid. If, due to disconnecting links, the network of nodes becomes partitioned then the service will be disrupted. The disruption, however, will only involve users originating from a part of the network that is not connected to the client experiencing the disruption. Also, when a node (silently) crashes, causing several routes to become invalid, the disruptions in the service will only involve users from the crashing node.MaintainabilityAre there any maintainability constraints to the design of the protocol?DistributionThe protocol should be distributed, in that it runs on multiple processing units that communicate through communication links. Whenever the load of the processing units becomes too high, it should be possible to add extra units to reduce the load of individual units.Network IndependencyThe protocol should be designed such that an implementation can be made independent of the network it runs on.Design Decisionsnode is identified by a globally unique 32bit digit.Channel membershipA server that is interrested in receiving events on a certain channel (on behalf of one of its clients), requests this from the servers that also "carry" that channel. Any server that is not interrested in the channel, only knows that it exists and what its (permanent) characteristics are.RoutingInconsistent messages are bounced, so that the originating server can determine what went wrong and supply the destination server with information to make that particular part of state information consistent again.Protocol ArchitectureThe functionality of the entire conferencing protocol has been seperated into three functional units:
Protocol SpecificationSpecification MethodSeveral aspects need to be covered by a specification: the definition of the service the protocol offers, the underlying service it expects, and the behaviour of the protocol: what service primitives should occur under what conditions and with what internal state information; how is the state information changed when primitives occur. If data units are exchanged, then the syntax of this data needs to be specified too.In the following, for each protocol layer a formal specification of its service primitives are given, followed by a summary of the messages that are used by the layer. Finally, a behavioral description in English is given. Network Interface Layer
Multicast Layer
Client LayersServer LayerAlgorithmsRouting AlgorithmsRerouting algorithmsSum AlgorithmProtocol ImplementationStill to do
Why have I done all this work!?Uhm, somebody's got to do it... | |