NIU Department of Mathematical Sciences
First Steps on the Internet

STUCK? SEARCH INDEX MAIN

Note: more up to date information about some of these topics is now in separate help files.

CONTENTS


Introduction

Network facilities have always been an integral part of Unix. A network protocol is a language, or a set of conventions, which two computers must understand to communicate with each other. To an Internet user, the most important protocol is TCP/IP, which is a collection of simple communication facilities used to build more complex ones. Nearly all aspects of Unix connectivity described below are based on TCP/IP. The higher-level protocols such as those used for mail (SMTP), file transfer (FTP), or World Wide Web (HTTP) follow a client/server model. That is, the connection has two assymetric ends: the client, which initiates the connection and issues requests, and the server, which tries to fulfill those requests. The Unix network mechanism makes it irrelevant whether the two run on computers located on different continents, or in the same room, or finally both on the same computer.

The often misunderstood idea of the em Internet is closely related to this. It has no precise definition; it can be best described as that collection of computers in the Universe which can communicate with each other using TCP/IP, with one of the major nodes such as the NCSA at Urbana-Champaign among them (`connected component', topologically speaking). Physical networks, e.g. our departmental Ethernet, are connected to other networks by means of devices called routers. The path from one computer to another may lead through as many as two dozen of those, each administered by a different company or institution.

Every host on the Internet is identified by a unique quadruple of numbers, each between 0 and 255; the standard notation is to separate the four numbers with dots. This is the so-called IP address of the network node. The only real `authority' on the Internet is the body which assigns ranges of such addresses to individual organizations. The number of available addresses is rapidly shrinking, and urgent efforts to expand that numbering scheme are currently under way.

For the benefit of humans most of the numeric addresses correspond to mnemonic names. This is handled by a system of computers which act as domain name servers, or DNS. For example, one of our main servers has the address 131.156.3.3, which the DNS will map to the name `clinch.math.niu.edu'. Given a properly functioning nameserver, either of these forms can be used to refer to the Sun in the Department Office. Mnemonic names usually reflect the location of the computer, with the last word (`edu') denoting a top level domain of educational institutions, the third one, `niu', representing Northern Illinois University, `math' indicating the Math Department, and finally `clinch' being a name which was assigned to this computer.

A single host may have several names: olympus.math.niu.edu and ftp.math.niu.edu refer to the same computer, being mapped by the DNS to the same IP address 131.156.3.5. Those devices which connect two or more networks (e.g. routers) may have several different IP addresses.
[back to table of contents]

Telnet

One of the main functions of the Internet in its infancy was to provide remote login facility over the network, i.e. to allow a user of host A to connect to host B as if he were sitting in front of an old-fashioned terminal attached to B. Standard terminals use serial lines which are limited in speed and distance. Telnet supplies the same functionality with a faster and more reliable TCP/IP connection.

To connect to a host with telnet, type telnet hostname. After the connection is established, the window where you started telnet will start emulating a screen attached to the remote computer: you will probably see a normal login prompt. In nearly all cases you need to have a valid account on that computer. Certain library catalogs made available to the public, or some network information services such as the `whois' database described in Section 8, allow everyone to log in without providing a username or password.

The two ends of the connection must agree on the type of terminal emulation. This usually happens automatically, but sometimes the telnet client requests a terminal type which is unknown to the telnet server. This is common in some PC telnet implementations which might ask for the `dec-vt220' terminal type, which -- for example -- the Sun telnet server doesn't recognize (the accepted name is `vt220'). After logging in with telnet to a Unix host you may try to fix this with the command set term=vt220; otherwise programs such as vi or elm will not function properly.

If the telnet session hangs, you can try pressing Control-] or a similar key combination (when telnet session opens, a message usually appears indicating which keys should be used). This should return control to the local telnet application; the prompt telnet> will appear, and you can then say close or quit to terminate the connection. If this doesn't work, you should suspend telnet with Control-Z, and then kill the telnet process as described in the document on the Unix system.

Telnet can also be given an optional port number after the hostname; this will make the telnet client connect to a non-standard ``outlet'' of the remote computer. For example, port 119 is used for Usenet news servers (which are normally accessed with news clients, not directly by humans!), and standard e-mail transactions are carried out on port 25. See Section 8 for an application of this option. You may also want to read a separate document, http://www.math.niu.edu/help/net/news.html, which describes ``Usenet News'' - the global ``bulletin board'' devoted to thousands of specialized topics.

A variation of telnet, tn3270 (or its X-Windows version, x3270) is used to connect to larger computers -- usually IBM mainframes -- which use the IBM 3270 terminal emulation. Many library catalogs, traditionally run on such systems, require this kind of a connection.
[back to table of contents]

E-mail

Like telnet, electronic mail is one of the oldest applications of network connectivity. On the Internet it is handled by the simple mail transfer protocol, or SMTP. The path that a letter takes is relatively complex, and involves several layers.

The user invokes a mail agent such as mail or elm. This program is merely a user interface, designed to help the sender compose the letter, organize his mailboxes, print messages, etc. This has nothing to do with transmitting e-mail. We discuss elm in a separate document.

When the program is instructed to send the message, it contacts the mail transfer agent. On Unix computers this is most often the arcane and sophisticated program sendmail. The transfer agent decides what to do with the letter.

If it determines that the recipient's address is local, i.e. a name of another user on the same computer, it simply appends the letter to the recipient's mailbox. If the address indicates a user of another Internet host, the mailer will attempt to establish a special direct TCP/IP connection with the other computer. During this connection the remote mailer checks whether the address is valid, and accepts or rejects the message. It may happen that the receiving host is programmed to pass letters to the given user on to yet another computer, but that is of no concern to the mailer which initiated the connection.

Finally, it may happen that the message is addressed to a destination which our computer cannot reach directly (e.g. to a network such as the now nearly-defunct Bitnet). The mail transfer agent then falls back on a nearby major relay mailer, i.e. an Internet computer which perhaps will know what to do with such a letter.

If at any point of this process the computers encounter an obvious error, e.g. an invalid user name or a non-existent name of the destination host, the message `bounces back' immediately, with some explanation of the error. If the problem is that one of the computers along the way recognizes the receiving host but cannot for some reason establish a connection (e.g. because of a network problem, or because the target computer happens to be down), the message is spooled for later delivery. Typically the attempts to resend the message will be made every 30 minutes or so, for two or three days. If the connection still cannot be made, the letter will be returned to the sender, with an error such as "Cannot send mail for 3 days".

The domain name system allows the use of addresses which do not correspond to real computers. This is done for convenience, or for security reasons. For example, mail to tarantoga@aol.com will be delivered just fine, even though there is no computer aol.com. This is done by means of mail exchanger information programmed into domain name servers. The mail exchanger for addresses of the form user@math.niu.edu is the computer named clinch. In fact, it is also defined as a mail exchanger for all of our Suns, and no other workstation within the department will respond to SMTP connectiion attempts. Thus instead of the cumbersome behr@clinch.math.niu.edu, mail can be addressed to behr@math.niu.edu, and will get delivered to clinch; similarly, a computer trying to send a message to behr@muir.math.niu.edu will contact clinch directly also.

An important limitation of SMTP has its roots in ancient history; it was originally used to transmit only simple documents consisting of ASCII text characters, which was the lowest common denominator of the types of information that disparate computer systems could be hoped to exchange. These days people want to send not only text, but graphics, sounds, and other files with more complex structure.

Two ways of dealing with this problem exist. The first one is to `manually' convert the information in question into the ASCII format. Several standards for doing so on various systems exist, the most common ones being uuencode/uudecode in the Unix and DOS worlds, and BinHex used by Macintosh devotees. Any file can be encoded using one of these into a string of plain characters (looking a bit like random garbage), and then sent by ordinary e-mail. The recipient then has to isolate the encoded fragment, and run it through an appropriate decoder, which will recreate the original file on the receiving system.

Most commercial and some non-commercial utilities (Sun's Mailtool, Mac Eudora, PC NuPOP, etc.) handle all this automatically, when told to attach a non-text document to an e-mail. The Internet community is embracing this convenience by establishing multipurpose Internet mail extensions format, or MIME, which is now recognized by many mail utilities, elm being one of them. MIME-compatible mail applications will recognize special control keywords in the text of the letter, and will try to locate and encode the indicated file automatically when the letter is being sent. Similarly, a MIME-formatted letter read in an application such as elm may trigger the decompression and viewing utilities, so a DVI file attached to a letter will automatically show up in an xdvi window. See the separate document on exchanging files by e-mail for more details.
[back to table of contents]

FTP

The file transfer protocol, or FTP, is used to ship large files between hosts efficiently. As with all original Internet applications, its user inetrface is not up to today's standards, but it still has its place in the 'Net toolbox of every user.

Perhaps the most interesting feature of FTP is that the server can be programmed to provide access to some documents not only to people with accounts on the host computer, but to everyone. This method, anonymous FTP, is widely used to distribute software, documentation, papers, even books.

Thus there are two types of FTP connections. One requires that you have a valid account on the server. As an example, you may be visiting some other institution, and you may want to access your private files on our system over the network. The other type is anonymous FTP, in which a server is configured to let anyone in.

The standard FTP application, present on all Unix computers, is called ftp. There is also a more powerful and friendlier version, ncftp. A typical session is started with ftp hostname; after the connection is establshed, the user has to log in using either a username and password corresponding to a real account (in which case he is placed in his home directory), or the username ftp and the password being his e-mail address (then the starting point will be the directory that was set up as the repository of public information). Since ncftp is designed with anonymous ftp in mind, it performs the anonymous login for you. If you want to be prompted for a real username and password, you have to specify a -u flag, as in ncftp -u ftp.math.niu.edu.

Anonymous FTP sessions

In the example that follows, we connect to a computer in Finland and download a file from it; some messages from ftp have been deleted for brevity. The username `ftp' indicates an anonymous FTP connection; most servers will accept it as equivalent to the traditional (and easily misspelled!) `anonymous'. 
behr.muir 6 % ftp nic.funet.fi
Connected to nic.funet.fi.
Name (nic.funet.fi:behr): ftp
331 Guest login ok, give your E-mail address for password.
Password: behr@
230-Guest `behr@muir.math.niu.edu' login ok.
ftp> cd /pub/sci/math
ftp> ls -l
-rw-rw-r--  1 rahola        1050 Aug  5  1994 00README
drwxrwxr-x  2 jhaataja      8192 Jun 24  1993 c++
drwxrwxr-x  2 rahola        8192 Jun 24  1993 matlab
ftp> cd matlab
ftp> ls 
00README
testmats.m
ftp> bin           
200 Type set to I.
ftp> get testmats.m
150 Opening BINARY mode data connection for
/pub/sci/math/matlab/testmats.m (85029 bytes).
226 Transfer complete.
ftp> quit
A copy of the file testmats.m is now in your local directory. Be careful -- ftp will overwrite an existing file by that name. Note that just before transfer we typed bin. This enables binary transfer mode; if this isn't done, and if the file in question contains anything other than plain text, the copy you get at your end will be garbled.

You can download several files at once using the mget (`multiple get') command and wildcards; for example, mget *.m would download all files whose names end with .m.

Note that the downloaded files will end up in the directory in which you were when the ftp command was issued. If you want to `move' elsewhere during a session, you can do that with the lcd (`local change directory') command; e.g. ftp> lcd Misc will make subsequent downloads go to your Misc subdirectory. If you get disoriented during an FTP session, you can execute Unix commands using the so-called shell escape: for instance, ftp> !ls will list the files present in the current directory on your system, rather than on the FTP server.

The put command lets you upload files from your computer (the client) to the server, provided you have the necessary permissions. Anonymous FTP servers sometimes have an area which is writeable (usually a directory called incoming) where everyone can leave things.

Regular FTP sessions

Normal (as opposed to anonymous) FTP connections are very similar, except you must log in using a valid `real' username and password. You will then gain access to the files in your home directory on the server. Since you then have a read and write permission for those files, you can download and upload files without a problem; files can also be deleted using the dele command, e.g. dele junk.

If you prefer ncftp, you must change its default behavior so it will not try to log you in as an anonymous user: for example, ncftp -u ftp.math.niu.edu will do the trick. There are many other options and commands available in both ftp and ncftp; see the on-line manual pages.
[back to table of contents]

Finding software

If you are looking for a piece of software or some document, but you don't know exactly what anonymous FTP server it's on, you will want to try archie (or its X-Windows counterpart, xarchie, which also lets you download the files located by the query). For example, archie -s plutonium will search a database on one of the Archie servers for files containing the substring `plutonium'. If any are found, you will see a list of FTP servers on which those files reside, together with pathnames.

The archie system has its limitations; the servers collect information from anonymous FTP servers periodically, and this information may be out of date by the time you run a search. Moreover, not all FTP sites participate in this process, so there is a lot of interesting software out there which will not be found using archie searches.

Archie servers in the US are often heavily loaded; if your queries time out, it may be a good idea to try another server. In xarchie this is done by selecting an alternate host from the `Settings' menu; standard archie has to be given an alternate server on the command line: archie -h archie.switch.ch gcc.tar.Z.
[back to table of contents]

Gopher

In early 1990s programmers at the University of Minnesota designed a protocol which was meant to unify to some extent many other ways of transferring information on the Internet. The result was a `distributed database' called gopher. A gopher server would store files and documents much like an FTP server would, but the main difference is that the gopher clients present that information to the user as menus that are easily navigated; moreover, the client has additional information about the type of a document being retrieved (e.g. a DVI file), and can automatically start up a suitable viewer (e.g. xdvi) and display the document.

Items in gopher menus can also be references (links) to data on other servers, in which case the client will automatically make a connection to that other server. They can also be `gateways' to ordinary anonymous FTP servers.

Two gopher clients are available on our system: gopher, which can be used during any session, and the X-Windows application xgopher, which has a nicer user interface but is less capable. Upon starting a gopher client, it should automatically connect to the departmental server. Menu items are selected using arrow keys, or -- in xgopher -- by clicking the mouse. To bypass our server and connect to another gopher directly, use the command gopher or xgopher followed by the name of the gopher host.

Although gopher is still in widespread use, it is being superseded by WWW (see Section 7). Most of the information stored on our gopher server will be migrating to the WWW server over time.
[back to table of contents]

World Wide Web

The World Wide Web, also known as WWW or W-cubed, or simply The Web, is a unified approach to distributing information on the Internet. Its two main features are: WWW is a convenient way of accessing most of the resources the Internet has to offer. It can also be easily adapted to managing local information (user guides, help documents, problem reporting). We can expect it to be the mainstream network interface for some time to come.

The Alphabet Soup

The Web uses something called HyperText Transfer Protocol, HTTP, which allows one to interpret plain text documents as fancy-looking ``Web pages'' containing graphics, icons, edit fields, and links to other network entities. Such documents are written in a HyperText Markup Language, and are commonly called ``HTML's'' for short. They are plain text files containing certain special instructions which describe formatting, links, etc. When a Web client identifies a text file as an HTML document, it interprets those instructions and makes an effort to present the document the way its author intended.

A standard method of naming such resources has been created: a Uniform Resource Locator, or URL, is a phrase such as <protocol>://<host>/<pathname>. E.g. ftp://www.math.niu.edu/pub/papers/Ammar/ is a reference to the directory /pub/papers/ammar on our ftp server; http://www.geom.umn.edu/ denotes the main HTML index document on the WWW server running at the University of Minnesota Geometry Center.

Links can also point to gopher and news servers, telnet sessions, to people's e-mail addresses, etc. Many longer HTML documents contain links to other parts of the same document, making it easy to jump back and forth between logically related but physically distant fragments of the information. Such elements, i.e. places which can be pointed to, are called anchors.

New types of links (and URLs used to describe them) are being invented all the time. The current standards are maintained primarily by the World Wide Web Consortium (which took over from the WWW pioneers at the European Nuclear Research Center, CERN), and can be accessed at http://www.w3.org/.

Accessing The Web

The two most popular WWW client applications, Mosaic from NCSA and Netscape from Netscape Communications Corp., are available in several versions for different platforms: X11 under Unix, DOS, Windows, and the Macintosh.

At the moment, Netscape is the more stable and elegant of the two, but it has its flaws also. Which one you use is a matter of personal preference. If you plan to use a WWW client on a PC or a Mac, you should be prepared to also install a variety of ``helper applications'' which are automatically invoked to handle more esoteric elements of HTMLs being viewed. For example, you need NCSA Telnet or similar to be able to successfully access telnet links; a suitable GIF viewer may be needed to display links to files containing high-quality graphics.

Under Unix, where not everyone uses a windowing system, and some users dial in with simple terminal emulation software, a text-based WWW client called lynx is also available. It cannot display various typefaces, images or icons, but does a decent job when graphics-based access is not available.

Running a WWW client is just a matter of typing its name followed by the specific URL you want to access. For example, netscape http://att.net/dir800/ or mosaic http://att.net/dir800/ will attempt to connect to the toll-free phone directory maintained by AT&T.

When a Web client is started up without the URL, it will access its default Web page. In case of Mosaic, it will be one of the pages on the main NCSA server; in case of lynx, you will be connected to a server maintained by lynx developers. This can be customized (see section 7.3), and it is recommended that you soon change the defaults to our own server.

When the clinet is already running, you can switch from the document you are looking at to another place by choosing ``Open Location...'' (or ``Open URL...'' in Mosaic) from the leftmost menu. You then have to type in the URL of the desired document or resource.

In all the clients the URL of the document being accessed is either visible at all times, or can be looked up with one of the menus. This will help prevent you from getting tangled up in the Web. You can also easily backtrack your steps -- there is a ``Go Back'' button or command in all of them. Finally, if you are curious, you can view the HTML text of the page being accessed by selecting the ``View Source'' option. This is a great help and source of inspiration when you get around to creating your own home page.

One of the downsides of the Web and HTMLs is that it is very easy and tempting to create bloated documents full of 24-bit color graphics, sound elements, and the like. Often accessing a Web page designed in this fashion requires that megabytes of data be downloaded, which takes a lot of time and contributes to the congestion of the Internet (not to mention our local network). Please avoid visiting such Web places.

Note that both Netscape and Mosaic use an interface whose details are slightly different from most X11 applications. They follow interface guidelines known as Motif, which is similar to MS Windows. Be prepared for some inconvenience while you are getting used to it.

Customizing Your Client

Unfortunately some defaults in the current versions of Unix clients cannot be customized centrally. This means that you will have to change certain settings yourself. For example, in Netscape you should pull down the ``Options'' menu, and select ``Preferences''. Under ``Mail and proxies'' set ``SMTP Host'', which in our case should be mail, and ``Organization''; then select ``Save Options''. These values are used when you invoke mail directly from Netscape.

Another setting is the ``home page location'', found under ``General Preferences''. This is the Web object that Netscape will display when it's started up without specifying a URL. Mosaic has a similar feature. You may want to enter http://www.math.niu.edu/ there.

To assure that links which invoke telnet sessions work correctly, go to the ``Applications and Directories'' submenu and type the following incantation in the ``Telnet Application'' field:
xterm -aw -ut +s -tn vt100 -j +sb -fn 9x15bold -e telnet %h %p

While you are at it, you may also want to decrease the default size of the memory cache (say 700 KB) and disk cache (1000 KB). Since Netscape tries to remember most of what you did during several past sessions, it creates a lot of cache files in your home directory; it is a good idea to use the ``Clear Disk Cache Now'' button once in a while to erase those files.

Printing from Netscape or Mosaic will be easier if you tell the system which printer you prefer to use. This is best done by putting a line setenv PRINTER m1 in your .login file (obviously not everyone should be using m1; use an appropriate name).

If you are having trouble downloading certain types of documents (compressed files, images), you may need to correct the settings under ``Helper Applications''. Let the system manager know about such problems.

One of the very useful features of all Web clients is the ability to record interesting URLs as bookmarks. They can later be accessed with just a click of a button. When you've found a Web page which you may want to access again, just select ``Add Bookmark'' from the ``Bookmarks'' menu (in Mosaic it's ``Add Current to Hotlist'' under ``Navigate''; so much for standard interface...) You can later go straight to that place by selecting it from the ``Bookmarks'' menu (or the ``Navigate/Hotlist...'' menu in Mosaic).

Creating Your Own Home Page

If you connect to our Web server, you will notice that it has links to directories of users of the system. Each user has a standard HTML document listing the office, phone, classes taught, etc. There is also a link to the user's home page.

In order to make this link useable, you have to set up some documents in your directory. First, create a subdirectory named WWW, for example with commands cd ; mkdir WWW. Make sure that it is accessible to others: chmod 755 WWW ; chmod g+s WWW (you should also make sure that files you create in there are readable -- consult the help document on Unix permissions when in doubt).

You should now create the main HTML document which will be the starting point for everyone who accesses your home page. This is a plain text file in the WWW subdirectory, whose name must be index.html. Looking at the sources of other HTMLs out there is a great help. A very basic introduction to HTML is at http://www.math.niu.edu/help/net/html.html.

When you are ready to unleash your efforts on the unsuspecting public, you should advertise it as http://www.math.niu.edu/~<username>/; for example, the URL of my page is http://www.math.niu.edu/~behr/.

Do not use absolute pathnames such as http://www.math.niu.edu/home/denali/friend/behr/; they won't work. WWW servers understand paths as being relative to certain preconfigured points on the system. The absolute path above will get translated into a directory that doesn't exist on our system. Our server will consider the path http://www.math.niu.edu/~<username>/<whatever> to mean <username's home directory>/WWW/<whatever>.

Depending on whether you think the organization of your WWW subdirectory is likely to change often or not, you should use relative paths to refer to files (e.g. href=../doc1) or absolute ones with the ``tilde-username'' gadget, e.g. href=/~behr/Junk/doc1. Think ahead to avoid major headache later.

The material you collect for your Web page resides in your home directory. Since it usually involves icons, pictures, even sounds and video, it tends to consume a lot of disk space. You should periodically check the size of your WWW directory with the command du -s ~/WWW. If you exceed a megabyte or two, please consult the system manager about ways of reorganizing things.

Other Software

Even packages such as TeX are feeling the impact of the HTML paradigm. Several efforts currently under way will most likely extend LaTeX to include HTML-like special macros, providing the ability to view -- say -- a preprint and jump around it by simply clicking on links which point to anchors such as references, sections or theorems. Some implementations even allow links from TeX documents to other resources on the local system or on the Internet -- e.g. clicking on a reference could conceivably pull an abstract of that paper from an AMS server to your workstation.

A slightly modified LaTeX format, hlatex, automatically recognizes the standard cross-referencing commands such as \ref{...} and \label{...}, and adds suitable link data in the resulting .dvi file. When that file is then viewed with the modified xhdvi viewer, the links show up underlined and you can click on them; in response, the viewer will jump to the appropriate anchor.

This software is still in experimental phase, and isn't rock-stable. But this seems to be the direction in which interchange of scientific documents on the network is evolving, so it may be worthwhile to invest some time in experimenting with it.

Post Scriptum

Once again, an appeal: please keep your HTMLs lean and easy to handle. Try to use graphics, sounds and other elements of large size only when they actually contribute something to the page design. The Web can be very useful and friendly, but it can also bring a network to its knees.
[back to table of contents]

Finding hosts and people

To verify that some computer is known to the domain name system, type arp hostname. E.g. arp uiuc.edu gives uiuc.edu (128.174.5.58), while arp kremlin.gov produces kremlin.gov: unknown host. To determine whether a computer is actually up and running (or, more precisely, whether network connections to it can be established), try ping uiuc.edu.

As we explained in Section 3, a name which is a part of an e-mail address doesn't have to correspond to a real computer; behr@math.ilstu.edu is a valid address, even though there is no host math.ilstu.edu. To see where such mail will actually go, query the domain name system as follows: dig mx math.ilstu.edu. Part of the response will look like this:

;; ANSWERS:
math.ilstu.edu. 3600 MX 10 spider.math.ilstu.edu.
math.ilstu.edu. 3600 MX 500 rs6000.cmp.ilstu.edu.

This means that spider.math.ilstu.edu is the preferred mail exchanger for math.ilstu.edu. You can now check whether the user in question really has an account there:

behr.muir 15 [spider.math.ilstu.edu]
Login name: behr In real life: Eric Behr
[...]

Sometimes finger is disabled for reasons of privacy or security. In that case it is best to inquire about a user you want to contact by writing to the address postmaster@ hostname. All Internet nodes to which e-mail can be sent ought to have an account by that name, and your question should soon reach one of the administrators of that system.

If you are not certain where to start, i.e. you can't even come up with a likely hostname where the person might have an account, you may want to connect to the `whois' database maintained by one of the companies charged with overseeing the Internet. This can be done by typing telnet rs.internic.net and following the instructions; or you can use the whois command: whois -h rs.internic.net "Maharishi International". The resulting list of major campus computers will hopefully provide a starting point for your search.

Finding people knowing just their institution and name is harder. Suppose you are looking for a person named Small who is at the UC San Diego. Of course you can try some obvious host names, such as math.ucsd.edu, but it's not always easy to find the correct username. One solution is to access the on-line version of the Combined Membership List (as an exercise, try getting to it through our gopher server). This obviously won't work if the person in question is not listed in the CML.

Another possibility is to access a gopher server at the institution where the user should have an account. Our gopher menu has an item `Mother of all gophers', which will connect you to the central server in Minnesota. There you can access the list of all major gophers, organized geographically. In 9 cases out of 10, the relevant institution or even the department will have its own gopher server, and more likely than not it will include a searchable directory of users (sometimes called a `CSO directory', or a `phonebook'). The one I tried gave me the required information:

Small, Lance W. Mathematics 534-2629 lwsmall

Finally, emerging standards for Internet-wide directory service, such as X.500, might some day become easier to use and more widely used than they are now. As a last resort, you may want to play with such experimental facilities by connecting to the Minnesota gopher server and selecting the `Phone Books' menu item.
[back to table of contents]

Troubleshooting

We will now discuss some of the problems you may encounter while using Internet applications. It is important to remember that the Internet is undergoing explosive growth, with thousands of new users getting connected every month; many new Internet sites are also maintained by relatively inexperienced people. All this creates potholes and congestion on the Infobahn.

E-mail problems

The most common cause of returned letters is a misspelled name of the target host, or incorrect username of the recipient. The Internet tradition (and the design of mail programs) dictates that -- unlike most other identifiers in the Unix world -- e-mail addresses should be case-insensitive. There is little point in trying to resend a letter using different capitalization in the address. Instead, look for unlikely addresses (math.edu or mathniu.edu). If the host name appears to be OK, but the letter comes back with a ``user unknown'' error, try some of the methods listed in Section 8; but ultimately it is often necessary (and simplest!) to pick up the phone and verify the address in this low-tech way.

If you hear complaints that the address zettl@clinch.math.niu.edu works but zettl@math.niu.edu does not, then the problem is at their end -- their mail agent does not recognize mail exchanger information. If, on the other hand, zettl@math.niu.edu is OK but zettl@eiger.math.niu.edu is not, then the individual workstation has not been added to our databases, and you should ask the system manager to correct this.

Other connection problems

If connection attempts cause a ``host unknown'' message, the name of the computer was probably misspelled, or the computer has been removed from the DNS. You should check the name for typos, or find out whether a new name has replaced the one that's no longer valid.

An error ``connection timed out'' means that the hostname is OK, but the computer in question is down, or that the network is exceptionally busy or temporarily down. If this persists, verify that connections to other off-campus sites work (e.g. with ping ucsd.edu or ping uiuc.edu). If that fails also, notify the system manager as soon as possible. Similarly, a message ``host is unreachable'' indicates that a router between `here' and `there' is acting up quite badly; this should also be investigated.

Connections which are very slow, or `jerky', are almost always caused by very heavy network traffic, or heavy load on the target computer, or both. If this is what you see no matter where and when you connect to, the problem might be with our local network, your office wiring, or your workstation. Contact the system manager if this situation persists.

Needless to say, network problems not covered above should be reported to the system manager, who might not be able to help, but will at least investigate, making sure that the problem is not at our end.

Last modified: 6/6/97 by webmaster@math.niu.edu