INTERNET-DRAFT G. Hiddink Expires: October 17, 1997 april 1997 draft-hiddinkg-wwcp-part1-01.txt World Wide Conferencing Network Protocol Suite: Part 1 Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress``. To learn the current status of any Internet-Draft, please check the 1id- abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before October 1996. Distribution of this draft is unlimited, but all copyrights are reserved to G. Hiddink. The ideas contained herein are intellectual property of G. Hiddink. Abstract Online text-based conferencing is in wide use on the internet, for recreation, work or education. The most used protocol is IRC [1], which is currently in daily use by tens of thousands of users on over a dozen IRC networks. One major problem of IRC, however, is its lack of high scalability: networks tend to become unstable once more than about 30.000 users are connected. The World Wide Conferencing Protocol tries to solve this problem by focusing on scalability. It implements, amongst others, a generic multicast service on top of TCP/IP, which can also used for other purposes that require a multicast service for relatively small multicast groups (max approximately a few hundred). CONTENTS Hiddink [Page 1] Internet Draft WWCP Part 1 17 april 1997 1. Introduction ........................................ 2. Design philosophy.................................... 2.1 Scalability ........................................ 2.2 Privacy ............................................ 2.3 Freedom of information exchange .................... 2.4 Fault tolerance .................................... 2.5 User Registration .................................. 2.6 Channel Registration ............................... 2.7 Server Registration ................................ 3. Glossary ............................................ 4. Representations ..................................... 4.1 User identifier .................................... 4.2 Server identifier .................................. 4.3 Channel structure .................................. 5. Architecture 5.1 Introduction ....................................... 5.2 Client ............................................. 5.3 Conferencing Server ................................ 5.4 Channel Directory Server ........................... 5.5 User Directory Server .............................. 5.6 Protocol Architecture .............................. 6. Restricted use of the protocol none References 1. Introduction This document describes the concepts used by the World Wide Conferencing Protocol (WWCP), its design philosophy and its general architecture. The glossary is presented first, as the concepts presented there are needed in order to describe the various functions of the protocol. After that, the way different entities are identified is described. 2. Design philosophy In this section, the philosophy behind the design of the protocol is discussed. This philosophy clarifies, in part, why certain design Hiddink [Page 2] Internet Draft WWCP Part 1 17 april 1997 decisions have been taken. 2.1 Scalability As explained before, the main focus of the protocol is to provide a highly scalable conferencing environment. We believe this is important, as one of the main applications of a conferencing network is recreation, i.e. chatting. The "online chat" subculture knows many social aspects, one of which is the requirement for a large amount of people logged in simultaneously. This way, users are able to meet other users from a wide variety of continents, countries and cultures. 2.2 Privacy Experiences from IRC indicate that malicious users will disturb other users on the network. Users should be able to protect themselves from such actions, by hiding their presence and current location (the channels they are on). However, their friends should be able to locate them or check their presence. Users should also be able to ignore the actions of a user they do not like. Unlike IRC, WWCP does not implement `channel operators', as this concept turned out to introduce more social problems than solve them. Instead, we adopt the philosophy that ignoring annoying users is the best solution, and prevents escalation that may even end in a user assaulting the conferencing system in order to "gain ops" via a "riding a netsplit". Due to the lack of channel operators, it is also not possible to ban users from a channel. Instead, registered channels (see section x.x) can supply an access list. This list indicates from which hosts users must connect in order to be able to join the channel. This list is rather statical, and not suited to be modified dynamically. 2.3 Freedom of information exchange One of the main principles of the design of the protocol is the free exchange of information. This means that the protocol only provides means for transporting data. The content of the data (information) is not relevant for the functioning of the protocol, and there are no provisions for inspecting the content and/or acting upon it. The responsibility for the content is considered to be entirely of the users transmitting the content. Certain data streams can be marked "unsuitable for children below the age of 12" and "unsuitable for children below the age of 18". Using these labels, client programs can ensure that young children cannot access these data streams. 2.4 Fault Tolerance Hiddink [Page 3] Internet Draft WWCP Part 1 17 april 1997 In order to be scalable, the protocol must provide means to tolerate faults. The larger the network becomes, the higher the chances are that in a given time something goes wrong. Errors that may occur are network outages, machines that suddenly die, programming errors, or even protocol design flaws. 2.5 User Registration Protecting the privacy of users is a bit dualistic: on the one hand, the identity of a user must be protected. On the other hand, if a user Bre receives a message from a user Grit, then Bre has the right to know who is speaking to him. Otherwise, a user would be able to harass a large amount of other users without anyone being able to detect his identity and complain to his internet access provider. 2.6 Channel Registration 2.7 Server Registration 4. Representations In order to uniquely identify all kinds of things, identifiers have been defined. These will be treated below. 4.1 User identifier Users are uniquely identified with a 16 bit unsigned integer within the context of a server, so the combination (user id, server id) uniquely identifies a user throughout the entire conferencing network. The number zero is reserved and may not be assigned to a user. There are two strategies for a server to assign a user ID to a user: 1) dynamically: when the user connects to the server, or 2) statically: when the user requests to make use of the services of the conferencing system. Strategy 2 is preferred, as this will avoid any confusion between servers about the identity of a certain user ID. If a server implements strategy 1, then the server has to postpone recycling the ID as long as possible. 4.2 Node identifier A node is a process or collection of processes that users the WWCP protocol to exchange information, and is not a client process. Thus, a node can be a conferencing server, a channel directory server or a user directory server. Nodes are uniquely identified with a 32 bit unsigned integer. This identifier is assigned to a server by the Network Administration Group before the node is allowed to connect to a conferencing network. The identifier is given "for life" and will not be reused. Hiddink [Page 4] Internet Draft WWCP Part 1 17 april 1997 4.3 Channel identifier All channels, both registered and unregistered, have a symbolic (alpha- numerical) name. Only registered channels have a numerical identifier of 32 bits, as only registered channels are globalle known to all Channel Directory Servers. Assigning ID's to unregistered channels, that are created whenever a user joins them, may cause race conditions in obtaining an ID. These channels are always identified using their alphanumerical name. 5. Architecture 5.1 Introduction The World Wide Conferencing Protocol does not use a simple client-server model. There are different types of server, some of which take the role of client themselves when engaging in a communication with another type of server, and some don't. In this chapter, the client and the various types of server are explained. Section 5.7 concludes the chapter with a description of the architecture of the various protocols that together describe the communication between the various types of server. 5.2 Client A client is a program running on the computer of the user. The client may either be engaged in an interaction with the user, or operate in a more autonomous mode. The client accepts commands from the user via the keyboard or a graphical user interface, and translates it to protocol messages that are sent to the conferencing server (see next section). It stores relevant state information it gets from the conferencing server, and negotiates with it if something doesn't seem to be consistent with the client's state information. Commands the client can send include: joining a channel, saying or doing something in a channel, requesting information about the channel or other users, leaving a channel and requesting parts of the channel tree. The client is supposed to cache these parts, removing them after a timeout, when the client terminates or until the server indicates that a particular part of the tree has become `dirty' (i.e. does not contain uptodate information anymore). 5.3 Conferencing Server The conferencing server keeps a list of channels its users are on, and also keeps track of all `foreign' users (i.e. users that are connected to a different server) that are on these channels. Furthermore, it requests parts of the channel tree from the Channel Directory Service on behalf of its clients, and caches them until a timeout, the server terminates or until the Channel Directory Service tells it that the information is no Hiddink [Page 5] Internet Draft WWCP Part 1 17 april 1997 longer uptodate. The Conferencing Server also communicates with the User Directory Service about user data, and again caches this data. It also passes on userdata on behalf of its clients to the User Directory Service. The Conferencing Server interacts with its peer servers about users joining and leaving the channel, users saying and doing things on a channel and users sending (private) messages to eachother. 5.4 Channel Directory Server The Channel Directory Server keeps an exhaustive list of all channels on disk, and accesses it to read channel records. It is strongly recommended that these records are cached in main memory, although the protocol does not prescribe this. The Channel Directory Server also accesses the channel tree structure from disk to pass it to Conferencing Servers that request it. It also keeps a list of the channels its Conferencing Servers are on (i.e. the Conferencing Servers that are directly connected to it). It is expected that the capacity of disks will grow at least as fast as, and probably faster than the capacity needed to store an exhaustive list of the channel tree structure and all registered channels. The Channel Directory Server communicates with its peer servers about new channels, dying channels and new channel registrations. It also exchanges information about what servers are on the Channel Directory Server's channels, and sends this information to its Conferencing Server in order to track down differences in state information about which server is on which channels. The protocol that describes the communication between a Conferencing server and a Channel Directory Server on the one hand, and inter- Channel Directory Server traffic on the other hand, is presented in Part 5 of this protocol suite. 5.5 User Directory Server The User Directory Service is a distributed replicated database service, as it is expected that disk capacities will not be able to keep up with the size of the user database. A single copy of the database is distributed over a dynamic number of User Directory Servers. A group of servers carrying one replica is called a cluster. These servers are in close contact to relay queries to eachother. Several clusters of servers may be setup to process the queries of the Conferencing Servers. The clusters are interconnected to exchange state information updates and to relay queries. The User Directory Protocol is specified in Part 6. 5.6 Network Administration Group 5.7 Protocol Architecture Hiddink [Page 6] Internet Draft WWCP Part 1 17 april 1997 The protocol is split into three layers: the Network Interface Layer (NIL) that takes care of setting up (unicast) TCP/IP connections, keeping them alive, storing data about them and disconnecting them. This layer is specified in Part 2. It is only a thin layer, but reduces the complexity of the next layer: the Multicast layer. It takes care of setting up multicast groups, transmitting data to them and removing multicast groups. Furthermore, it takes care of maintaining routing tables and sending data for multicast groups into the appropriate directions. This layer is specified in Part 3 of this protocol suite. On top of these two layers, several application protocols are stacked: the Conferencing Protocol, the Channel Directory Service Protocol and the User Directory Service Protocol. These protocols make use of the services of both the Network Interface Layer as well as the Multicast protocol. The Conferencing Protocol takes care of servicing clients and exchanging content with peer protocol entities. 6 Restricted use of the protocol As the author and intellectual owner of the protocol that is presented in this and the following parts of this protocol suite, I hereby grant free use of it for educational, recreational and commercial use. In no event shall this protocol, parts of it or derivatives be used in any warfare system, a warfare environment or for warfare communication. In spite of rules and regulations having not much meaning during war, I still would like to ask this much of you. In the name of the thousands of hours I have spend on it (unpaid). References [1] rfc1459 Hiddink [Page 7]