rfc1324.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 619 行 · 第 1/2 页

Network Working Group                                         D. Reed
Request for Comments: 1324                                   May 1992


             A Discussion on Computer Network Conferencing

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This memo is intended to make more people aware of the present
   developments in the Computer Conferencing field as well as put
   forward ideas on what should be done to formalize this work so that
   there is a common standard for programmers and others who are
   involved in this field to work with.  It is also the intention of
   this memo to stimulate the computer community and generate some
   useful discussion about the merits of this field.

Introduction

   Computer network conferencing is just now starting to grow and take
   advantage of the modern technology that is available.  Although there
   are some systems which have been around for some time (BRC - Bitnet
   Relay Chat and IRC - Internet Relay Chat), there has not been any
   real move to bring them together under a single protocol. This has
   led to various protocols and different systems coming to life. As
   these different systems continue to pop up, it is becoming more
   obvious that there is need of a standard in this area for developers
   to follow without the need of worrying about protocol clashes.

   In any implementation of a conferencing program, there are likely to
   be two main components: (1) a client program or interface which users
   enter commands into (hereafter referred to as a "client") and 2) a
   server program which acts as a multiplexor for various clients which
   connect to it. There are other expectations and requirements for both
   servers and clients which are mentioned in more detail later.

Table of Contents

   1.0     Network Conferencing Today........................... 2
   1.1     Conferencing in general today........................ 2
   1.2     Talk/phone vs. conferencing.......................... 3
   1.3     Advantages of realtime network conferencing.......... 3
   2.0     Goals for what a protocol should provide............. 4



Reed                                                            [Page 1]

RFC 1324             Computer Network Conferencing              May 1992


   2.1     State Information problems........................... 4
   2.2     Network barriers..................................... 4
   2.3     User needs........................................... 4
   2.3.1   User privacy......................................... 4
   2.3.2   Realtime Expectations................................ 5
   2.4     Message Delivery..................................... 5
   2.4.1   Deficiencies in using IP only........................ 5
   2.4.2   Flexibility.......................................... 5
   2.4.3   Building a flexible transport protocol............... 5
   2.5     Network Structure.................................... 5
   2.5.1   Size................................................. 5
   3.0     Usage................................................ 6
   4.0     Setting it up........................................ 6
   4.1     Installation......................................... 6
   4.2     Controlling growth................................... 7
   5.0     Finding the *right* protocol......................... 7
   5.1     Name for protocol.................................... 7
   5.2     Responsibilities of conference servers............... 7
   5.2.1   Message passing...................................... 7
   5.2.2   Who is on?........................................... 7
   5.2.3   Who is who?.......................................... 8
   5.2.4   Conference security.................................. 8
   5.2.5   Error reporting...................................... 8
   5.2.6   Network Friendliness................................. 8
   5.2.7   To ASCII or not to ASCII............................. 8
   5.2.8   Queries or messages to a server and replies.......... 9
   5.3     Responsibilities of clients.......................... 9
   5.3.1   Providing accurate information....................... 9
   5.3.2   Client as servers.................................... 9
   5.4     How complex should the protocol be?................. 10
   5.4.1   User identification................................. 10
   5.4.2   Trees and cycles.................................... 10
   5.5     Protocol summary.................................... 10
   6.0     Security Considerations............................. 10
   7.0     Author's Address.................................... 11

1.0  NETWORK CONFERENCING TODAY

1.1  Conferencing in general today

   Conferences today are an integral part of the business world in many
   ways. A conference may be held to reassure staff about company
   problems (boost moral) or may be held by a few directors in an
   emergency situation where a carefully considered solution is needed.
   Conferences also form the cornerstone of workshops held where various
   groups of people, who attend, are to be briefed on new developments.
   In nearly all of these situations, there will be a group of 2 or
   more, where each speaks and listens to others.  There exist PABXs and



Reed                                                            [Page 2]

RFC 1324             Computer Network Conferencing              May 1992


   other features of the telephone system which provide for conferencing
   between people around the globe at a cost effective rate. The only
   place which really lacks any formal form of conferencing is the
   internet, although many unofficial conferencing systems already
   exist, spanning the globe or providing local forums.

1.2  Talk/phone vs. conferencing

   To provide instantaneous communication between two users on unix and
   other multiuser systems, interprocess communication is commonly used
   either over a network or other local methods.  The diversity of unix
   platforms has introduced as many problems as the presence of various
   operating systems on the net.  Commonly, those on Unix based machines
   are unable to talk to those on VMS or VM machines. The occasion even
   arises where two Unix hosts are unable to talk to each other due to
   different talk protocols.

1.3  Advantages of realtime computer conferencing

   By providing a standard for computer conferencing, it should
   eliminate the problem of who is using what computer. This will mean
   that someone from a VMS or VM machine can talk with one or more
   people without having to worry whether their counterpart has an
   account on a compatible machine for their choice of communication.
   Electronic mail (email) has already reached this position with most
   modern mailers on the internet being compliant with RFC822. It is
   therefore not unreasonable to expect this of realtime conferencing
   which is to talk as USENet is to email; although of those four (4),
   only email and news have been covered by RFCs.

   USENet is a vast resource and immensely useful for many people around
   the globe. It does, however suffer from a high noise to signal ratio.
   It would be unwise to expect much difference in performance from
   conferencing.

   By providing the means for realtime computer conferencing, it opens
   up a whole new area of usefulness to computers. For both students and
   staff alike, it opens up new possibilities.  In educational
   institutions where there is a high level of project work with groups
   of more than 2, it means that students can work from home or other
   remote places and discuss their project with their fellow students in
   a manner which would be similar to all students having a conventional
   meeting or conference. This same situation also applies to staff
   members.  For those who have previously relied on email between
   fellow researchers in many remote institutions, computer conferencing
   brings the world together, onto the researchers screen where they can
   trade ideas and code in real time. Traditionally to achieve these
   goals, the phone would have been used and a teleconference setup and



Reed                                                            [Page 3]

RFC 1324             Computer Network Conferencing              May 1992


   it will probably remain so for many years to come with video phones
   too. However, with phone conferencing, when people talk over each
   other, the quality of the discussion is degraded.

2.0  Goals for what a protocol should provide

   In producing a protocol for conferencing over computer networks, the
   following problems must be considered:

2.1  State Information problems

   The number of users who are a part of the conference may fluctuate
   continuously by a large amount over any given period of time.  The
   protocol should endevour to make disruptions such as these as smooth
   as possible but at the same time, keep the realtime feel in the
   conference. It is not acceptable to buffer a user who quits for any
   given time but at the same time, if a server has network problems
   with connecting to another one, it may be wise to find some way
   around the continual stream of state messages that are passed - or -
   at least a way to reduce the number.

2.2  Network barriers

   Members of a conference may be on physical networks which cannot
   directly communicate with each other, such as those used from a host
   on a commercial network talking via a bridge to someone from a
   network directly connected to a network directly accessible from
   theirs. So in this case, the users involved have no need to directly
   use the bridge (as required by unix talk) since the server on the
   gateway host provides a way for messages to be passed in and out of
   the unreachable sections.  In this case also, there is a minimum
   security risk to the network which is otherwise unreachable.

2.3  User needs

2.3.1  User privacy

   Members of a conference may wish to exchange ideas privately without
   fear of others eavesdropping or interrupting the current conference.
   To facilitate this, there should be some support by the protocol to
   pass messages from one user/client directly to another.

   It is also reasonable for a user to want to be able to hide in one
   way or another from other users, effectively making themself
   invisible to other users.






Reed                                                            [Page 4]

RFC 1324             Computer Network Conferencing              May 1992


2.3.2  Realtime Expectations

   Users will expect conferencing to be real time, giving the thereby
   demanding that the protocol supply a quick, efficient, reliable and
   accurate delivery of a message. Only when these requirements are met
   can a conference system hope to be of any use to its users.

2.4  Message Delivery

2.4.1  Deficiencies in using IP only

   In routing between conference servers, the problem of routing
   messages is an important issue. If there was a server for the
   conference at each domain, this wouldn't be an issue, one could
   simply do some sort of lookup and find the server for it. This is not
   the case and unless such a server becomes a standard item for unix
   machines, it is not reasonable to expect it to ever be so. Thus the
   need for a layer on top of TCP/IP is needed to deliver messages
   between the servers for the conference.

2.4.2  Flexibility

   The routing protocol used should not be inflexible and should allow
   for routes to change over time in much the same way as RIP does now.
   However, there is no need for a special routing protocol such as RIP
   since this is already part of IP's functionality. Routing information
   should be updated automatically when the server receives information
   via that route whether it creates or destroys a route.

2.4.3  Building a flexible transport protocol on top of existing ones

   If such a conferencing service is built upon TCP/IP, it is therefore
   possible to build an abstract routing model which has no relation to
   the TCP/IP model. However, it is not wise to ignore the presence of
   either TCP or IP since by integrating them into the protocol, it is
   easier to use their strengths.  If the protocol relies too heavily on
   TCP/IP features, it will also inherit some of its weaknesses. These
   maybe taken for granted, but it is worth keeping them in mind when
   designing a protocol to be both reliable, efficient and useful.

2.5  Network Structure

2.5.1  Size

   The potential userbase of a conferencing system using the internet
   should not be underestimated. It is therefore desirable that the
   conferencing system should be as distributed as possible, and as
   little state information kept as possible. If the IRC network is



Reed                                                            [Page 5]

RFC 1324             Computer Network Conferencing              May 1992


   taken as a guide, with 800 users on 140 servers in some 200 channels,
   the server was using over 1MB of memory. Due to the nature of
   conferencing and the server being run as a daemon, this memory was
   hardly ever swapped out. For this reason, servers should aim to only
   be authoritive about required users, channels and servers and keep up
   to date information on these.

   There is also no requirement that a global conferencing system be
   built, although it is an ideal arena to show the strengths of the
   network. It also goes without saying that it shows up a lot of its
   weaknesses too.

   Any protocol which is developed should operate equally well and
   efficiently on both a large scale network and on a small scale
   network.

3.0  Usage

   If past usage is any guide, then a network based conferencing system
   will be largely used by mostly students. This is not as unreasonable
   as it may sound since students and student accounts easily form the
   largest body on the internet. To encourage staff or other adults into
   this field, it might be prudent to reduce the amount of noise and
   interfearance a bored student (or staff member!) can generate.