modest, inexpensive desktop system that typically runs client
   software or basic server software.  Equally important, clients do not
   have to be modified to take advantage of a new resource.

3.5  Building clients

   A client simply sends the retrieval string to a server if it wants to
   retrieve a document or view the contents of a directory.  Of course,
   each host may have pointers to other hosts, resulting in a "graph"
   (not necessarily a rooted tree) of hosts.  The client software may
   save (or rather "stack") the locations that it has visited in search
   of a document.  The user could therefore back out of the current
   location by unwinding the stack.  Alternatively, a client with
   multiple-window capability might just be able to display more than
   one directory or document at the same time.

   A smart client could cache the contents of visited directories
   (rather than just the directory's item descriptor), thus avoiding
   network transactions if the information has been previously
   retrieved.

   If a client does not understand what a say, type 'B' item (not a core
   item) is, then it may simply ignore the item in the directory
   listing; the user never even has to see it.  Alternatively, the item
   could be displayed as an unknown type.

   Top-level or primary servers for a campus are likely to get more
   traffic than secondary servers, and it would be less tolerable for
   such primary servers to be down for any long time.  So it makes sense
   to "clone" such important servers and construct clients that can
   randomly choose between two such equivalent primary servers when they
   first connect (to balance server load), moving to one if the other
   seems to be down.  In fact, smart client implementations do this
   clone server and load balancing.  Alternatively, it may make sense to
   have the domain name system return one of a set of redundant of
   server's IP address to load balance betwen redundant sets of
   important servers.

3.6  Building ordinary internet Gopher servers

   The retrieval string sent to the server might be a path to a file or
   directory.  It might be the name of a script, an application or even
   a query that generates the document or directory returned.  The basic
   server uses the string it gets up to but not including a CR-LF or a
   TAB, whichever comes first.





 
RFC 1436                         Gopher                       March 1993


   All intelligence is carried by the server implementation rather than
   the protocol.  What you build into more exotic servers is up to you.
   Server implementations may grow as needs dictate and time allows.

3.7  Special purpose servers

   There are two special server types (beyond the normal Gopher server)
   also discussed below:

      1.  A server directory listing can point at a CSO nameserver (the
      server returns a type character of '2') to allow a campus
      student-staff phonebook lookup service.  This may show up on the
      user's list of choices, perhaps preceded by the icon of a phone-
      book.  If this item is selected, the client software must resort
      to a pure CSO nameserver protocol when it connects to the
      appropriate host.

      2.  A server can also point at a "search server" (returns a first
      character of '7').  Such servers may implement campus network (or
      subnet) wide searching capability.  The most common search servers
      maintain full-text indexes on the contents of text documents held
      by some subset of Gopher servers.  Such a "full-text search
      server" responds to client requests with a list of all documents
      that contain one or more words (the search criteria).  The client
      sends the server the selector string, a tab, and the search string
      (words to search for). If the selector string is empty, the client
      merely sends the search string.  The server returns the equivalent
      of a directory listing for documents matching the search criteria.
      Spaces between words are usually implied Boolean ANDs (although in
      different implementations or search types, this may not
      necessarily be true).

   The CSO addition exists for historical reasons: at time of design,
   the campus phone-book servers at the University of Minnesota used the
   CSO protocol and it seemed simplest to just engulf them.  The index-
   server is however very much a Gopher in spirit, albeit with a slight
   twist in the meaning of the selector-string.  Index servers are a
   natural place to incorperate gateways to WAIS and WHOIS services.

3.7.1  Building CSO-servers

   A CSO Nameserver implementation for UNIX and associated documentation
   is available by anonymous ftp from uxa.cso.uiuc.edu.  We do not
   anticipate implementing it on other machines.