Basic NNTP Protocol


Be sure to read the "RKT couplings" below for additional information, comments, and links.

RFC977:[Previous][Up to Table of Contents] [Next]

RFC977 1. Introduction

   For many years, the ARPA-Internet community has supported the
   distribution of bulletins, information, and data in a timely fashion
   to thousands of participants.  We collectively refer to such items of
   information as "news".  Such news provides for the rapid
   dissemination of items of interest such as software bug fixes, new
   product reviews, technical tips, and programming pointers, as well as
   rapid-fire discussions of matters of concern to the working computer
   professional. News is very popular among its readers.

   There are popularly two methods of distributing such news: the
   Internet method of direct mailing, and the USENET news system.

RFC977 1.1.  Internet Mailing Lists

   The Internet community distributes news by the use of mailing lists.
   These are lists of subscriber's mailbox addresses and remailing
   sublists of all intended recipients.  These mailing lists operate by
   remailing a copy of the information to be distributed to each
   subscriber on the mailing list.  Such remailing is inefficient when a
   mailing list grows beyond a dozen or so people, since sending a
   separate copy to each of the subscribers occupies large quantities of
   network bandwidth, CPU resources, and significant amounts of disk
   storage at the destination host.  There is also a significant problem
   in maintenance of the list itself: as subscribers move from one job
   to another; as new subscribers join and old ones leave; and as hosts
   come in and out of service.


RFC977 1.2.  The USENET News System

   Clearly, a worthwhile reduction of the amount of these resources used
   can be achieved if articles are stored in a central database on the
   receiving host instead of in each subscriber's mailbox. The USENET
   news system provides a method of doing just this.  There is a central
   repository of the news articles in one place (customarily a spool
   directory of some sort), and a set of programs that allow a
   subscriber to select those items he wishes to read.  Indexing,
   cross-referencing, and expiration of aged messages are also provided.

RFC977 1.3.  Central Storage of News

   For clusters of hosts connected together by fast local area networks
   (such as Ethernet), it makes even more sense to consolidate news
   distribution onto one (or a very few) hosts, and to allow access to
   these news articles using a server and client model.  Subscribers may
   then request only the articles they wish to see, without having to
   wastefully duplicate the storage of a copy of each item on each host.

RFC977 1.4.  A Central News Server

   A way to achieve these economies is to have a central computer system
   that can provide news service to the other systems on the local area
   network.  Such a server would manage the collection of news articles
   and index files, with each person who desires to read news bulletins
   doing so over the LAN.  For a large cluster of computer systems, the
   savings in total disk space is clearly worthwhile.  Also, this allows
   workstations with limited disk storage space to participate in the
   news without incoming items consuming oppressive amounts of the
   workstation's disk storage.

   We have heard rumors of somewhat successful attempts to provide
   centralized news service using IBIS and other shared or distributed
   file systems.  While it is possible that such a distributed file
   system implementation might work well with a group of similar
   computers running nearly identical operating systems, such a scheme
   is not general enough to offer service to a wide range of client
   systems, especially when many diverse operating systems may be in use
   among a group of clients.  There are few (if any) shared or networked
   file systems that can offer the generality of service that stream
   connections using Internet TCP provide, particularly when a wide
   range of host hardware and operating systems are considered.

   NNTP specifies a protocol for the distribution, inquiry, retrieval,
   and posting of news articles using a reliable stream (such as TCP)
   server-client model. NNTP is designed so that news articles need only

   be stored on one (presumably central) host, and subscribers on other
   hosts attached to the LAN may read news articles using stream
   connections to the news host.

   NNTP is modelled upon the news article specifications in RFC 850,
   which describes the USENET news system.  However, NNTP makes few
   demands upon the structure, content, or storage of news articles, and
   thus we believe it easily can be adapted to other non-USENET news
   systems.

   Typically, the NNTP server runs as a background process on one host,
   and would accept connections from other hosts on the LAN.  This works
   well when there are a number of small computer systems (such as
   workstations, with only one or at most a few users each), and a large
   central server.

RFC977 1.5.  Intermediate News Servers

   For clusters of machines with many users (as might be the case in a
   university or large industrial environment), an intermediate server
   might be used.  This intermediate or "slave" server runs on each
   computer system, and is responsible for mediating news reading
   requests and performing local caching of recently-retrieved news
   articles.

   Typically, a client attempting to obtain news service would first
   attempt to connect to the news service port on the local machine.  If
   this attempt were unsuccessful, indicating a failed server, an
   installation might choose to either deny news access, or to permit
   connection to the central "master" news server.

   For workstations or other small systems, direct connection to the
   master server would probably be the normal manner of operation.

   This specification does not cover the operation of slave NNTP
   servers.  We merely suggest that slave servers are a logical addition
   to NNTP server usage which would enhance operation on large local
   area networks.

RFC977 1.6.  News Distribution

   NNTP has commands which provide a straightforward method of
   exchanging articles between cooperating hosts. Hosts which are well
   connected on a local area or other fast network and who wish to
   actually obtain copies of news articles for local storage might well
   find NNTP to be a more efficient way to distribute news than more
   traditional transfer methods (such as UUCP).

   In the traditional method of distributing news articles, news is
   propagated from host to host by flooding - that is, each host will
   send all its new news articles on to each host that it feeds.  These
   hosts will then in turn send these new articles on to other hosts
   that they feed.  Clearly, sending articles that a host already has
   obtained a copy of from another feed (many hosts that receive news
   are redundantly fed) again is a waste of time and communications
   resources, but for transport mechanisms that are single-transaction
   based rather than interactive (such as UUCP in the UNIX-world <1>),
   distribution time is diminished by sending all articles and having
   the receiving host simply discard the duplicates.  This is an
   especially true when communications sessions are limited to once a
   day.

   Using NNTP, hosts exchanging news articles have an interactive
   mechanism for deciding which articles are to be transmitted.  A host
   desiring new news, or which has new news to send, will typically
   contact one or more of its neighbors using NNTP.  First it will
   inquire if any new news groups have been created on the serving host
   by means of the NEWGROUPS command.  If so, and those are appropriate
   or desired (as established by local site-dependent rules), those new
   newsgroups can be created.

   The client host will then inquire as to which new articles have
   arrived in all or some of the newsgroups that it desires to receive,
   using the NEWNEWS command.  It will receive a list of new articles
   from the server, and can request transmission of those articles that
   it desires and does not already have.

   Finally, the client can advise the server of those new articles which
   the client has recently received.  The server will indicate those
   articles that it has already obtained copies of, and which articles
   should be sent to add to its collection.

   In this manner, only those articles which are not duplicates and
   which are desired are transferred.
[Source:"RFC977"] [Last Changed:February 1986]
[Copyright: 1986 Brian Kantor, Phil Lapsley]


RFC977:[Previous][Up to Table of Contents] [Next]

(Corrections, notes, and links for Usenet RKT.)
by Mib Software, INN customization and consulting


RFC850 is obsoleted by RFC1036
Overview and Related Topics
Up to: RFC977

RKT Rapid-Links:[Search] [RKT Tips] Path:For Developers / NNTProtocol / RFC977 / 0008.htm