hiero deel 1 van de WWCN Internet draft. Deel 1 beschrijft kort en
inleidend waar het allemaal over gaat. Deel 2 zal de Network Interface
Layer beschrijven, deel 3 de Multicast Layer, deel 4 de conferencing
layer, deel 5 de channel directory service en deel 6 de user directory
service. Nog een lange weg te gaan dus...
Awel, hiero de eerste versie van deel 1. Er zitten nog een paar gaten
in. Deel 2 is in de maak.
----
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.
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
1. Introduction ........................................
Hiddink [Page 1]
Internet Draft WWCP Part 1 17 april 1997
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 .........................
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
decisions have been taken.
Hiddink [Page 2]
Internet Draft WWCP Part 1 17 april 1997
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
In order to be scalable, the protocol must provide means to tolerate
faults. The larger the network becomes, the higher the chances are
Hiddink [Page 3]
Internet Draft WWCP Part 1 17 april 1997
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 Server identifier
Servers are uniquely identified with a 32 bit unsigned integer. This
identifier is assigned to a server by the Network Administration Group
before the server is allowed to connect to a conferencing network. The
identifier is given "for life" and will not be reused. The same range
of identifiers will be used for all three types of servers: conferencing,
channel directory and user directory servers.
4.3 Channel identifier
All channels, both registered and unregistered, have a symbolic (alpha-
Hiddink [Page 4]
Internet Draft WWCP Part 1 17 april 1997
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
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
Hiddink [Page 5]
Internet Draft WWCP Part 1 17 april 1997
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
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
Hiddink [Page 6]
Internet Draft WWCP Part 1 17 april 1997
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]
---------------------------------------------------------------------------
WWCN Beta Testers List wwcn-beta@wwcn.student.utwente.nl
http://wwcn.student.utwente.nl/wwcn wwcn@usa.net
To unsubscribe, send a message containing "unsubscribe" to:
wwcn-beta-request@wwcn.student.utwente.nl
---------------------------------------------------------------------------