        Host computer name resolution on a Sun Machine 
	==============================================

   +----------------------------------------------------------------------+
   | If you are running Xgopher on a Sun computer system (e.g., Sun4,     |
   | Sparc, etc.) and see error messages such as:                         |
   |                                                                      |
   |   Cannot establish a network connection                              |
   |   (could not identify the remote host computer xxx.xxx.xxx.xxx)      |
   |                                                                      |
   | then read this document.                                             |
   +----------------------------------------------------------------------+


Background
----------

Gopher connects to other machines all around the internet, often
without your knowledge.  Machine names are provided as human-readable
"hostnames".  For example, harpoon.cso.uiuc.edu.  The first part of this
name is the specific host (harpoon), the rest is the "domain" name.
The long form of the name, with .cso.uiuc.edu at the end is called
the "fully qualified domain name.
Each registered name is mapped to a unique numeric IP address.  For our
purposes, we will assume that all the computers we are working with 
have properly registered names.  The example above, harpoon, has the
unique IP address of 128.174.33.160.  All numeric addresses look
something like this; 4 sets of numbers separated by dots.

Xgopher uses the built in networking software of a computer system to
make a connection to another computer.  Xgopher may supply either
the fully qualified name or the IP address of another machine.
Usually, the name is provided.  This name is converted to the address
by a process called "name resolution".  This is the seat of the problem!

In the old days, every host name and its numeric IP address were stored
together in a table in a file called /etc/hosts on a Unix system.
You will still find a small version of this file on most systems.
With MILLIONS of computers in the world, more being added every minute,
and many of them changing their addresses for various reasons, it is
IMPOSSIBLE to maintain this table in /etc/hosts anymore.

Today we use a program called a "name server" to resolve a hostname
into an IP address.

If you get errors such as the one shown at the top of this document,
then read on.

Solutions
---------
You may be able to just relink with a different library (or no library).
I have had some people say that they need to use -lresolv
on the load command to get Xgopher to work, and others that insist
that -lresolve NOT be used since then Xgopher will use the NIS
name server for resolving the address.  Whichever way you linked
Xgopher (with or without -lresolv), please try it the other way.
If this works, great!

Verify that your network does talk to the outside world, and is
reasonalby open.  For some people, especially those in commercial
or government sites, your host may be behind a "firewall" - a 
restriction to prevent unauthorized access to your network and
computing facilities.  There may also be restrictions on which ports may
be used for outside connections.  Gopher uses port 70 for most 
communication, but may use other ports.

If this isn't the problem, then it may be the use of a name server
(or lack thereof).


Name Servers
------------

Solution 1.
    Sun supplies a system called NIS, Network Information Service".  If
    you run NIS on your system it servers as the name server and Xgopher
    should work.

    This process is simple to setup and is normally handled by your system
    administrator.  Ask your local administrator for assistance if this is
    not already setup on your system. If you are the admin, you need to
    uncomment the B=-b line in your NIS Makefile and create the
    /etc/resolv.conf file.

    There are some arguments for not using NIS, but this is normally
    an site-dependent policy decision.


Solution 2.
    Another solution documented by Sun Microsystems, Inc, but not
    supported by them is to modify libc.so (the basic C language
    run-time library used by nearly every program) to include the
    subroutines gethostby* (gethostbyname, gethostbyaddr).  They
    are already supplied with your system, you just need to rebuild
    libc.so.  Every program you compile from then on will have access
    to these routines which will connect to a "nearby" name server
    (magic!).  This route isn't for everyone, but if you want to 
    try it, see the document Sunlib-rebuild in this directory.


Conclusion
----------

Your best solution is to find the Sun system's administrator for
you site and get some guidance based on the information you are now
armed with.  If you happen to be the system's administrator, then
choose one of the above methods and implement it.

If you are having these problems, your are not alone, nor is your problem
confined to Xgopher.  Any network application would provide similar grief.

This is a frequent discussion item in the news group comp.sys.sun.admin.
I recommend that if you are still experiencing problems, that you 
follow up with a question to this discussion group.


Thanks
------

So many people have written to me of this problem.  A small number have
provided the information and clues that allowed me to put together this
document.  I particularly want to thank our Sun System Support individual
on our campus, Steven Miller for really setting me straight on all of this,
suggestion the solutions, and proofreading this document.

R.Stewart(Stew) Ellis, (Humanities & Social Science,  GMI Eng.& Mgmt. Inst.,
Flint, MI 48504, ellis@nova.gmi.edu) made a coherent posting to the
comp.infosystems.gopher newsgroup providing similar information.
