rfc1324.txt

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

   Realtime conferencing via computer networks is, however, a very
   attractive toy to many students. It puts them in touch with the world
   at no extra charge to them. They are able to construct their own
   character and mask or hide their real self. This is a field which has
   already been researched and is an interesting topic to pursue.

4.0  Setting it up

4.1  Installation

   The installation and setup of most network utilities/servers is not
   something that is commonly discussed. It is, however, a point worth
   considering here after observations made on the setup and
   installation of systems such as IRC. If the setup is too easy and
   requires little work, it is not unreasonable to expect students to
   "install" it in their own accounts to provide themselves and friends
   with this service. There is little that can really be done about this
   except to force servers to listen and connect only to a certain
   priveledged port(s). This need, however, requires root intervention
   or aid and it is doubtful whether a service such as this should
   require such steps.





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


   This problem is not often encountered with other network services
   since they either require large amounts of disk space to be done
   properly (news) or require the co-operation of other servers before
   they work in a full serving role (DNS and use of name servers is a
   good example of this). Of the two, the latter is a good solution if
   it can be implemented fairly and well.

4.2  Controlling growth

   Is it possible to reasonably control the growth and connectivity of a
   large realtime conferencing network? Should it be compared to other
   facilities such as USENet which is commonly available and very
   widespread with no real central control over who gets news?

5.0  Finding the *right* protocol

   This section deals with points which are central issues when deciding
   upon a protocol. There are many points to consider when developing a
   realtime protocol which is going to provide a service to many users
   simultaneously.

5.1  Name for protocol

   Although names such as IRC and ICB have been used in the past to
   describe the implementation provided, this document is aimed at
   stimulating a protocol which is much more general and useful than
   these. A better name would reflect this. Depending on what network it
   is implemented on, the Network Conferencing Protocol (NCP) or the
   Internet Conferencing Protocol (ICP) are two suitable names.

5.2  Responsibilities of conference servers

5.2.1  Message passing

   A conferencing server should pass on all messages not destined for
   itself or its users to the destination as quickly and efficiently as
   possible. To this end, the server should not be required to do
   extensive parsing of the incoming message, but rather, look at the
   header and decide from there whether to send it on in the typical
   gateway/relay fashion or parse it and pass it to one or more of its
   users.

5.2.2  Who is on?

   Any conference server should be able to supply (on request) a list of
   attached user(s). The attached user(s) should have the option of
   being able to say whether they wish to show up in such lists.




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


5.2.3  Who is who?

   All servers should provide *some* method to identify any known user
   and supply details to the person making the query based on the search
   key given.

5.2.4  Conference security

   Conference servers should not run in such a manner that they
   deliberately record the private conversation(s) of users which are
   relying on the server in some way. It might seem that encrypting the
   message before transmission to other servers in some way would solve
   this, but this is better left as an option which is implemented in
   clients and thus leaves it to the users to decide how secure they
   want their conference to be.

5.2.5  Error reporting

   All errors that the server encounters in its running life should one
   way or another be reported to the operator(s) which are responsible
   for this. This may include sending messages if an operator is online
   or logging it to an error file.

5.2.6  Network Friendliness

   It is quite easy for any network based application to "abuse" the
   network it is running on. Also in a relay situation, it is quite
   possible that a server will become bogged down trying to keep up with
   just one connection and reduces the performance on an overall scale
   to all users relying on it. It is therefore recommended that user
   connections be subject to some sort of monitoring and flood control
   to stop them dumping large amounts of spurious data and causing the
   server to slow down.

   The server should also aim to maximise the packet size of all packets
   written out to the network. Not only does this make the packet/bytes
   statistics look nice, but also increases the efficiency of the server
   by reducing the time it spends in the system state waiting/doing IO
   operations such as read/write. The cost here is a fractional decrease
   in the real-time efficiency of the server.

5.2.7  To ASCII or not to ASCII

   Given that most of the widely used Internet protocols such as SMTP,
   NNTP and FTP are all based on commands which are given via ASCII
   strings, there seems no reason why a conferencing protocol should be
   any different. The gains from going to binary are marginal and
   debugging/testing is not as easy as with ASCII. However, it is not



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


   unreasonable for some part of the protocol to be done in binary.

5.2.8  Queries or messages to a server and replies

   For implementation of server queries, it is quite acceptable to use
   ASCII messages which are made up of words. (Any string of characters
   which doesn't start with a number). Replies should be some sort of
   numeric. This is a follow on from from 5.2.7 where all of FTP, NNTP
   and SMTP work in this manner. By reserving numerics *just* for server
   replies, there can be no confusion about whether the message is going
   to or from a server.

5.3  Responsibilities of clients

   This section discusses the obligations of clients which are connected
   to a conference server.

5.3.1  Providing accurate information

   Expecting accurate information is foolish, it matters not for most of
   the internet, but those that we do wish to trace wont give such
   information. A client is expected to provide accurate and valid
   information to the server it connects to so that confusion about who
   is who is not a problem. Optionally, the server may decide to not
   trust the information from the client and use some authentication
   scheme that is open to it for such.

5.3.2  Client as servers

   If a client is acting as a server and accepting direct connections
   from other clients, the client should provide information about users
   as discussed in 5.2.3. It is not necessary that a client be able to
   handle complex methods of communication such as channels and their
   advanced forms, but they should at least provide users with being
   able to send messages to other users.

   An example of this type of program might be Xtv where one or more
   users can connect to another Xtv client program using Xtv clients.

   In the case of X windows and perhaps in other areas, one it to ask
   the destination user to run a program in a similar manner to unix
   talk.









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


5.4  How complex should the protocol be?

5.4.1  User identification

   When a user signs onto a system that has an implementation of a
   conferencing protocol, they are usually asked or given some sort of
   unique key by which they are later able to be referenced by.  In a
   large system, it may be such that any key which has meaning to the
   user(s) will not be sufficient and that collisions will occur with
   such. It is therefore suggested that a server generate an identifier
   for each new user it has. This identifier must not only be unique in
   space, but also time. It is not reasonable for the user to ever have
   to be aware of what this identifier is, it should only be known by
   servers which *need* to know. A similar system to that used by
   NNTP/SMTP is a fair implementation of such a scheme.

5.4.2  Trees and cycles

   Due to the structure of the network being cyclic or forming loops, it
   is quite natural to want to emulate this within the protocol that is
   available for users. This has several advantages over trees, mainly
   the average path between any 2 nodes being shorter. A cyclic
   structure also poses many problems in getting messages delivered and
   keeping the connected users and servers up to date.  The main problem
   with using the tree model is that a break in one part of the tree
   needs to be communicated to all other parts of the tree to keep some
   sort of realism about it.  The problem here is that such
   communications happen quite often and a lot of bandwidth is
   needlessly generated. By implementing a protocol which supports a
   cyclic graph of its connectivity, breakages are less damaging except
   when it is a leaf or branch that breaks off.

5.5  Protocol summary

   It is not expected that any protocol that meets the above demands
   will be either easy to arrive at or easy to implement.  Some of the
   above requirements may seem to be exotic, unnecessary or not worth
   the effort. After viewing previous conferencing programs and how they
   work, many short comings can be seen in taking shortcuts.

6.0  Security Considerations

   Security issues are not discussed in this memo.








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


7.0  Author's Address

   Darren Reed
   4 Pateman Street
   Watsonia, Victoria 3087
   Australia

   Email: [e-mail]











































Reed                                                           [Page 11]