UU UU II UU UU CCCCCC NN NN EEEEEEE TTTTTTTT UU UU II UU UU CCCCCCC NNN NN EEEEEEE TTTTTTTT UU UU II UU UU CC NNNN NN EE TT UU UU II UU UU CC NN NN NN EEEEE TT UU UU II UU UU CC NN NNNN EE TT UUUUUUU II UUUUUUU CCCCCCC NN NNN EEEEEEE TT UUUUU II UUUUU CCCCCC NN NN EEEEEEE TT Dec. 1992 - Jan. 1993 Vol. 6, No. 1 This is an ASCII version of the University of Illinois publication UIUCnet, a newsletter covering campus networking issues. This newsletter is also disseminated in hard copy (which is the preferred format for distribution) and will eventually be available in postscript format as well. Although the articles contained herein may make references to page numbers, figures, and/or tables, these references generally refer to items in the typeset version and do not apply to the ASCII distribution of the newsletter. Moreover, special typographical effects such as italics, boldface, underline, etc., which served to clarify or emphasize particular textual passages in the typeset version, have necessarily been lost in the ASCII conversion process. Attempts have been made to compensate for the latter shortcoming through the use of quotation marks, uppercase letters, and other special formatting effects available within the confines of the ASCII character set. This and other issues of the UIUCnet newsletter are available for download via anonymous ftp from the host: ftp.cso.uiuc.edu in the directory doc/net/uiucnet. The file naming convention vol#no#.txt is used to indicate the volume and number of a given issue. For example, vol5no1.txt contains the ASCII version of UIUCnet, volume 5, no. 1. If you would like to subscribe to and receive the typeset version of the UIUCnet newsletter, send an e-mail request to: uiucnet@uiuc.edu. Include your full name and U.S. or International mailing address (or campus address and mail code for UIUC students, faculty, and staff). Subscription requests can also be made by sending a letter or postcard with your full name and mailing address to: UIUCnet 1120 Digital Computer Laboratory 1304 W. Springfield Ave. Urbana, IL 61801 Permission to reprint all or part of UIUCnet for non-profit purposes is granted, provided full acknowledgement of the original source (publication name, vol. #, issue #, and author's name) is given. ****************************************************************** Exploring the Power ofthe Internet Gopher By now, most UIUCnet users have at least heard about gopher. The furry little rodent who burrows through gopherspace on the Internet has been featured twice in CCSO's "Updates" newsletter (vol. 3 no. 4 and vol. 3 no. 8) and once in the semi-monthly UIUC faculty/staff newspaper "Inside Illinois" (vol. 12 no. 11). National publications for computing and networking professionals and hobbyists (e.g., "MacWeek," "Network World," "Computer Shopper") have also been tracking the development of this increasingly popular and ubiquitous Internet tool. So, why another article about gopher? Well first, if you haven't yet read about or seen gopher, you should make a point of it. Gopher is the only application that truly makes navigating and using many services on the Internet as natural as choosing an entree from a dinner menu. Yet, for all its elegant simplicity, there is tremendous power behind gopher's intuitive interface. Unleashing this power is a matter of understanding a little bit about how gopher works and discovering some of its less obvious capabilities. Back to Basics -------------- For the sake of the uninitiated, let's review a little bit about the history and nature of the Internet gopher. Gopher was born at the University of Minnesota (home of the Golden Gophers) in an effort to provide the UM students and staff with a flexible Campus-Wide Information System (CWIS) for disseminating news, announcements, and other kinds of information to the university community. In order to make it easy for departmental information providers to maintain control over their own data, the gopher team sought to develop a "distributed document delivery system"--that is, a system in which the data could physically reside on multiple computers in multiple locations. Their solution was a TCP/IP- based client-server protocol and a set of applications that provided for the coordination and linking of multiple information servers across campus, while at the same time presenting that information to the end-user in a way such that it all appears to come from the same place. Over the last two years, gopher has evolved from a system primarily intended to distribute text documents to a highly customizable environment for providing access to many different types of files and popular network services. Gopher has been adopted by hundreds of sites across the Internet--including the University of Illinois--as the CWIS/information server of choice. Today, the same method that was used to link multiple servers at the University of Minnesota campus is now used to link gopher servers all over the globe. The result is a seamless network of information servers, all of which can be easily accessed through a single, menu-driven interface. Due to the superhuman efforts of co-administrators Paul Gibbs and Lynn Bilger, the University of Illinois gopher service is now internationally recognized as one of the best in gopherspace. Later on, we'll investigate some of its features in detail. But, if you haven't yet had a chance to access gopher or want to know how you can use it to distribute your own information, get a copy of the document called "Gopher at the University of Illinois," available in the rack just outside the CCSO Resource Center, 1420 DCL (you can also request a copy by sending an e-mail message with your campus mail address to uiucnet @uiuc.edu). This document provides all the information necessary to get started with gopher. It describes what gopher is, summarizes what's contained in the UIUC gopher server, outlines the numerous methods for accessing gopher, and enumerates the many options for getting information into gopher. Gopher Server(s) and Clients ---------------------------- Like so many networked applications today, gopher exploits the client-server model. The server is the machine that holds and organizes the data. To a certain extent, what you can do with gopher depends on your server. A very simple server might only hold plain text files. By linking this simple server to another gopher server, however, users have access to information and services on both the simple server and the server to which it is linked. Today most servers contain more than just text files and links to other servers. In addition to holding hundreds of text files, the main gopher server here at UIUC (a NeXT workstation) includes an engine for browsing and downloading files from popular ftp sites, gateways to the archie file archive database and the WAIS (Wide Area Information Servers) distributed-database system, direct links to several types of electronic phone books, the ability to do full-text searches on many of the documents archived on our local server and remote text databases, preconfigured telnet sessions for connecting to popular electronic library catalogs and information servers across the Internet, and, of course, links to every other gopher server in the world and all the unrestricted services they offer. The Minnesota gopher development team is constantly working on expanding the capabilities of the server software. In order to maintain a state-of-the-art gopher server, the server administrator must keep abreast of the latest server software releases and be willing to upgrade the server as necessary. Although the Unix-based server is the most powerful, it is also possible to set up a gopher server with limited capabilities on a Macintosh or PC. Such servers might be appropriate for a small department that wants to publish its own text-based information but does not have the resources to purchase and maintain a complex Unix workstation. Now let's consider the client side of gopher. The client is the computer and software that communicates with the server. It provides a friendly front-end for the end-user to view and select the services available on the server and all its links. Gopher clients have been developed for many different types of computers and operating systems and often differ in terms of "look and feel" (see the related article on page 8, "How Six Gopher Clients Stack Up"). Nevertheless, all gopher clients have several features in common. The most obvious similarity among gopher clients is that the information and services available on the server are presented to the end-user as a series of nested menus. This type of menu structure is intended to resemble a hierarchical file system, a concept already familiar to most computer users. When a user first connects to a server, he or she sees the top-level menu. This is more or less equivalent to the "root" directory of a tree- structured file system. Like a root directory, the top-level menu often contains files and other menus, which are analogous to subdirectories (or folders) in a file system. These submenus may, in turn, contain files, additional submenus, or other kinds of objects (such as telnet sessions, index searches, links to ph servers, etc.), and so on. The gopher file system metaphor is more obvious in some clients than others. For example, menu items that contain submenus in the Unix curses client terminate with a slash (/), the standard symbol for a directory in the Unix environment. TurboGopher for the Mac and NeXT Gopher 1.3 represent the menu hierarchy as folders within folders. Other clients identify menus in some consistent but less intuitive manner. All menus in the X Window System client, for instance, are preceded by a "È" symbol, and PC Gopher II for DOS uses the symbol "", which stands for directory. Another characteristic shared by gopher clients is their ability to speak and interpret the gopher client-server protocol. While this might seem self-evident, it's important to note that as new options and services are added to gopher, new terms are added to the gopher vocabulary (in fact, a full-fledged extension to the gopher protocol called Gopher+ has been proposed). An older client will not know what to do if a message from the server includes a term it doesn't understand. This won't necessarily result in something catastrophic. It just means that your client may not be able to make use of all of the services available through gopher. Additionally, even the most up-to-date client may have limited functionality due to the hardware constraints of the machine on which it is installed. For example, some gopher clients (NeXT Gopher, Xgopher 1.2, Unix curses, etc.) can actually play sound files. The CMS client on VMD can display the names of sound files and assigns the label to them, but cannot play them. PC Gopher II, on the other hand, doesn't even know about sound files. It can neither display their names nor play them. Suffice it to say, not all gopher servers and clients are created equal. A Gopher Conversation --------------------- Before leaving the topic of clients and servers, it's worth taking a few moments to consider what actually takes place during a gopher session. When you start gopher, your client opens a TCP connection with a gopher server (usually the server at the address specified in the client's configuration file). The client sends a carriage-return/line-feed to the server, which in gophertalk means, "Tell me what you've got to offer." The server responds by returning a stream of carefully formatted text about the contents of the top-level menu, after which the TCP connection is closed. Yes, closed! Even though it appears as if your client is maintaining a continuous connection with the server, client-server conversations in gopher are typically very brief. The server returns just enough information to the client so that the client can initiate another TCP connection and perform another action such as retrieving a file or opening a menu. For example, when you connect to the U of I Gopher server with the Unix curses client you see the menu: 1. Welcome to the U of Illinois Gopher. 2. Campus Announcements (12/1/92)/ 3. What's New? (12/3/92). 4. Information about Gopher/ 5. Keyword Search of Gopher Menus 6. U of Illinois Campus Information/ 7. Champaign-Urbana & Regional Information/ 8. Computer Documentation/ 9. Libraries/ 10. Newspapers, Newsletters, and Weather/ 11. Other Gopher and Information Servers/ 12. Phone Books (PH)/ 13. Internet File Server (ftp) Sites/ The client actually receives much more information about each item in the menu than is displayed on the screen. For each menu choice, the server sends five separate pieces of information: 1) the object type, 2) the specific text that should be displayed in the menu on the client, 3) a selector string for retrieving the object (usually the directory or path in which the object is located), 4) the domain name of the host on which the object resides, and 5) the telnet port number that listens for requests on that host. The raw information transmitted from server to client for item 1 in the menu above looks like this: 0Welcome to the U of Illinois Gopher 0/Welcome gopher.uiuc.edu 70 The first symbol in the text stream is the object type, in this case "0". Every item displayed in a gopher menu has an object type associated with it. It is the object type that tells the client what the specific item is. The client uses this information to determine how to display the item in the menu (for example, graphical clients typically display text documents as pieces of paper, menus as folders, ph searches as telephones, and so on) and what to do with the item, should the user decide to select it. Type 0 is a text file (see the table below for the list of object identifiers and the types they represent). Table: Gopher Object Types Normal Types: ------------ 0 Item is a file 1 Item is a directory 2 Item is a CSO (qi) phone-book server 3 Error 4 Item is a BinHexed Macintosh file 5 Item is DOS binary archive of some sort 6 Item is a UNIX uuencoded file 7 Item is an Index-Search server 8 Item points to a text-based telnet session 9 Item is a binary file T TN3270 connection Experimental Types: ------------------- s Sound type. Data stream is a mulaw sound. g GIF type. M MIME type. Item contains MIME (Multipurpose Internet Mail Extensions) data. h html type. (HyperText Markup Language used by the World Wide Web, a hypertext application for finding and accessing resources on the Internet) I Image type. i "inline" text type (used by panda, a proprietary version of gopher used at the University of Iowa) Immediately following the object type is the actual text that is displayed in the menu. The next three pieces of information tell the client how to access item 1 on the menu. If you select menu item number 1, your client would open a TCP session with the host named "gopher.uiuc.edu" at port "70." Once connected, the client would send the selector string "0/Welcome" to the server. The server would respond by sending the complete text of the welcome message back to your client. As it happens, gopher.uiuc.edu is the alias of UIUC's main gopher server, so selecting item 1 would initiate another brief interaction with our local server . But not all menu items on our local server point to objects that reside locally. For example, if you were to select the menu item called "12. Phone Books (PH)/," the following information would be displayed: 1. U of Illinois at Urbana-Champaign 2. Internet-wide e-mail address searches/ 3. Phone books at other institutions/ 4. WHOIS Searches/ 5. X.500 Gateway (experimental)/ If you then selected item number 2, the raw information sent back from the server would be: 1Internet-wide e-mail address searches /Phone Books/.other gopher.micro.umn.edu 70 Object type 1 means that the item is a menu (or directory). The domain name "gopher.micro.umn.edu" indicates that by selecting this item, you would not be opening a connection with our local server. Rather choosing this item will point your client to a menu on the server at the University of Minnesota. The menu appears as if it is on our local server, but in reality it comes from somewhere else. This is how gopher establishes transparent "links" with other servers. Why should you care about any of this? I can think of several good reasons. First, there may be an occasion when you want to know where the information in gopher actually originates, something that is not necessarily apparent from the menu entry. Many gopher clients have the ability to display the raw information that lies behind a menu choice. With the Unix curses client, you can view this information by pressing the = (equal) sign. Second, occasionally a server will identify an object incorrectly. If you try to retrieve a binary file with your client, and the server has told your client that the file is plain text, the transfer will be unsuccessful. Having access to raw server data can help diagnose problems such as this. It's also fascinating to consider how effortlessly one can hop from one server to another in gopher without thinking about a single network address. Integrated Services ------------------- Gopher's strongest selling point is its ability to integrate a variety of network services into a single application, so that users don't have to learn multiple software packages, commands, and network addresses to take advantage of them--a revolutionary step towards making the Internet accessible to the common man. However, if you've ever had experience with commercially available integrated software--the kind that combines word processing, database, spreadsheet, graphics, and telecommunications capabilities into a single package--you may have observed that the functionality and sophistication of the individual components are often sacrificed for the convenience of inter-application compatibility and ease of use. Is the same thing true for gopher's implementation of well-known Internet services such as ftp, telnet, archie, WAIS, etc.? Well, that's a difficult question to answer. For many services, the answer depends specifically on which gopher client you are using. Some services are "client intensive," and if the gopher client doesn't do it's job well, it will pale when compared to a stand-alone counterpart. But there are at least a few instances where gopher's ability to pull together multiple resources actually makes it more powerful than using a stand-alone application. Let's take a closer look at several of the services offered through gopher and determine how they measure up to alternative methods of access. Gopher as Document Delivery System ---------------------------------- From the outset, gopher was conceived as a document delivery system, and it's fair to say that this is one of the things that gopher does best. All gopher servers and clients, no matter how primitive, know how to handle text documents. Most clients can display text documents on the screen, save them to a file, and/or print them. A few clients also offer the option of mailing the document to another person on the Internet. Here at UIUC, gopher's text delivery talents are fully exploited. There is hardly a local event, announcement, or news item that doesn't make it into gopher. "Special Campus Announcements" have their own top level entry on our gopher menu. One could spend hours, if not days, browsing through the menu called "U of Illinois Campus Information." Lurking beneath this menu choice is literally everything you wanted to know about the U of I, but were afraid to ask, neatly organized into menus and submenus. The full text of several local publications including "The Daily Illini," "Inside Illinois," "the Campus Crime Bulletin," and others can be found under the "Newspapers, Newsletters, and Weather" menu. Gopher is rapidly becoming the official vehicle for disseminating important UIUC text-based information. Gopher as FTP Client -------------------- Ftp, the TCP/IP file transfer protocol, is one of the areas in which gopher shines--that is, if you have the right client. On UIUC's gopher server, the ftp option is listed on the main menu with the title "Internet File Server (ftp) Sites." Several popular ftp sites are listed by name. Additionally, most of the well-known ftp sites in the world are organized alphabetically into submenus in this same menu. For most of the sites in the alphabetical listing, a brief summary of what the site contains is provided. The same method used to move up and down through gopher's menu hierarchy (usually point and shoot or point and click) can be used to browse the directory contents of any ftp site in the list. And, if you've got the right client, you can use the same technique to transfer any file from the remote ftp server to your client machine. All gopher ftp transactions involve three computers: 1) the remote ftp host, 2) the gopher server providing access to that host, and 3) your client. Problems can occur anywhere along this pipe, but the most common problem is that many gopher clients can only display and transfer text files. So, when you are browsing an ftp site, it may look as if there are very few files available, when in fact, your client is only showing you the files types that it can actually transfer. For example, PC Gopher II cannot handle binary file transfers. When browsing ftp sites with this client, you will only see files with object type 0 (plain text). Then there are clients that will only show you the files it thinks you want to know about. The Unix curses client can transfer binary files, but it only displays files that it thinks will be of interest to a Unix user. Thus, files with the extensions .zip, .exe, .sit, etc. are not visible when browsing ftp sites with this Unix client. Finally, there are clients, such as the CMS software on VMD, that can display the names of all file types, but can only transfer ASCII files. This client is good for browsing ftp sites, but you have to exit gopher and run a separate ftp application to actually fetch the file. The only clients I know of that can successfully display and transfer all types of binary files are TurboGopher for the Mac and Xgopher 1.2. It's a good bet that most gopher clients will be able to display and transfer all file types as software development continues. But for now, gopher's ftp capabilities are definitely limited by the versatility of your client. Gopher as Archie Client ----------------------- Gopher's implementation of the archie service exemplifies how the integration of applications can improve performance. The archie service, called "Search of Most FTP Sites (archie)," can be found beneath the main menu item "Internet File Server (ftp) Sites." Archie is a searchable database of the file holdings of all major anonymous ftp sites on the Internet. You can feed archie a filename (or part of a filename) and archie will return a list of all the ftp sites that have a file matching your query. Prior to gopher, the only way to query archie was to telnet to one of several archie servers or use a stand-alone archie client. Archie would send back the desired information. Then, if you wanted to actually get the file, you would have to open an ftp connection with one of the sites listed by archie, change to the specified directory, and execute the proper ftp commands. The gopher archie gateway is integrated with its ftp engine. Thus, performing an archie query on gopher will not only provide you with a list of ftp sites and directories, but can literally take you to one of those ftp sites. And, if your gopher client knows how to transfer the file, you can grab it during the same transaction. Comparing an archie query using the Unix stand-alone client with the same query on gopher will demonstrate exactly how powerful gopher's archie service is. Suppose you wanted to locate the well know e-mail package called Eudora. Figure 1 on this page shows part of the results returned by doing an archie query on the character string "eudora" using the stand-alone archie client on one of CCSO's Unix mainframes. Once archie has listed all the ftp hosts on which a file or directory named "eudora" resides, the transaction is over. The gopher archie service can take you several steps further. Figure 2 shows the information returned by gopher on the same query. Every item followed by a double slash (//) is a directory. By selecting item 10 in the menu, you can view the entire contents of the "mac/eudora" directory on "ux1.cso.uiuc.edu" as shown in Figure 3. At this point, you have actually opened an ftp connection with ux1 and are inside the "mac/eudora" directory. From here, if your client permits, you can transfer any of the files listed in the directory to your local computer. Unfortunately, because ftp and archie are tied together on gopher, many of the same limitations that apply to ftp also apply to archie. Gopher as Telnet and Tn3270 Tool -------------------------------- Gopher has the ability to launch pre-configured telnet sessions. Many gopher servers, including our own, provide access to on-line library catalogs and other kinds of information servers. With gopher, you can easily access these systems without knowing their domain name or IP address by simply making a menu choice. However, when you select a telnet session from a gopher menu, it is important to realize that your gopher client is not actually opening the telnet session. In fact, choosing a telnet session will cause you to temporarily leave gopher. The gopher client will look for the telnet application on your client machine and pass the necessary address information off to the telnet program. Gopher will also display any special information you need to know, such as the login id and password to give the remote host. Your telnet program will then try to contact the specified host using the information provided by gopher. When you close the session, you will be returned to gopher. Whether a telnet session is successful or not depends on several factors. Most critical is making sure that your gopher client knows how to find your telnet client. The gopher clients on CCSO machines have been configured to launch telnet sessions for you. If you install a gopher client on your desktop computer, you may have to do something special so that gopher knows how to find telnet. Gopher can also launch remote login sessions with computers that require 3270 terminal emulation, such as IBM mainframes. In principle, tn3270 sessions work just like telnet sessions in gopher and are subject to the same restrictions. Thus, gopher must be able to find the tn3270 program on your client machine. Additionally, your gopher client must know about the tn3270 object type. Neither PC Gopher II nor the CMS Gopher on VMD recognize the tn3270 object type. The DOS client simply does not display tn3270 sessions in its menu system. The CMS client displays the session as type "T" but returns the message "cannot process this type." In general, the ability to open telnet and tn3270 sessions with gopher is a tremendous convenience. The gopher server at the University of North Texas, which you can find under "Other Gopher and Information Servers/Recommended Gopher Servers for Exploration/University of North Texas/," has an exhaustive menu of telnet and tn3270 sessions to reach library catalogs all over the world. Although it is not possible to open a remote login session with a host that is not listed in a gopher menu, if you would like certain libraries or information servers added to the list of libraries and terminal-based sessions on the UIUC gopher server, simply send an e-mail request to our local gopher administrator at the address gopher@uiuc.edu. Gopher as WAIS Client --------------------- Among the many services offered by gopher is a gateway to the WAIS (Wide-Area Information Servers) databases. WAIS is a collection of distributed databases, which can be searched by keyword and cover a wide variety of subjects. (A detailed description of WAIS and how it works is given in the October 1992 issue of "UIUCnet," vol. 5 no 6.) The gopher implementation of WAIS lacks many of the features found in dedicated WAIS clients. Most notably, with gopher you can only search one WAIS database at a time, and WAIS's unique search refining tool called relevance feedback is not available. However, gopher does offer one feature that most WAIS clients do not: it allows you to see the names and search all of the public WAIS databases that are available. Perhaps someday, a full-featured WAIS client will be built in to the gopher software. Gopher as Electronic Phone Book ------------------------------- Under the menu item "Phone Books (PH)" is a collection of electronic phone directories (often called white pages) that can be used to look up the e-mail address and/or other information about people on the Internet. The first item in this menu, "U of Illinois at Urbana-Champaign," provides access to our local CCSO Nameserver, also known as ph. Many other institutions have used the ph program to set up their own electronic directory services. They can be found mixed in with other types of electronic directories in the submenu "Phonebooks at other institutions." Each gopher client represents ph directories in some consistent way. Some clients use the term "CSO," which stands for CSO Nameserver. Others use an icon resembling a telephone or telephone book. In any case, ph searches comprise a specific object type in gopher and are handled somewhat uniquely. Most searches conducted in gopher are actually handled by a gopher server--that is, the client asks you to enter a search string, it then sends your search string to a gopher server, the server looks for items matching your search string, and finally the results of the search are returned to your client. Ph queries, on the other hand, involve a direct conversation between the gopher client and a ph server; a gopher server does not participate in these transactions (except to provide the address of the ph server). In order for a gopher client to conduct a ph search, it must know how to speak the ph protocol, which is something quite different than the gopher protocol. Most gopher clients today have a built-in ph client. Some are easy to use but not very powerful, others are powerful but not very intuitive, and a few simply don't work. Also, unlike many stand-alone clients, the ph clients built in to gopher do not allow a user to log in to a Nameserver to modify his or her own entry. Despite these minor shortcomings, between the many ph Nameservers and other electronic directory services (such as whois databases, the experimental X.500 directory, and the utility called netfind), gopher offers a set of comprehensive tools for finding someone on the Internet, unmatched by any other client-server application. Gopher as File Viewer/Player ---------------------------- If you are fortunate enough to have the right software and hardware, gopher can be used to view images and play sounds. Sounds and images are experimental object types in Gopher and only a few clients know what to do with them. Moreover, like the telnet function in gopher, sound and image files are not actually played or viewed by the gopher client. The client looks for another program on the client machine that knows how to process the file. For example, if the application Giffer is installed on your Mac, when you download a GIF (graphics interchange format) file, TurboGopher will ask you if you would like Giffer to display it for you. Similarly, Xgopher 1.2 will pass GIF files off to the X application called xloadimage. Finding Things in Gopher ------------------------ Well, after many words and pages, we've only begun to scratch the surface of gopher, which leads us to the last major topic in this article--with so much information on so many gopher servers all over the world, how does one actually find specific information in gopher, and once found, how can one keep track of where the information is located? Gopher actually provides several tools for locating information. There is a special object type in gopher called an index-search server. Index searches often have the word "search" as part of their menu entry and, like other object types in gopher, have a distinctive abbreviation or icon associated with them. A gopher administrator can create an index search for any large body of text contained in a gopher menu. This can help you to rapidly zero in on the documents of interest. For example, if you are searching the electronic version of the "Daily Illini" for all recent articles about the women's volleyball team, you could go to the "Daily Illini Newspaper" menu and choose the "Word Search of Latest Month" item. When asked to enter a search string, enter the word "volleyball." All "DI" articles from the last month that contain the word "volleyball" will be listed as a separate menu. But how did we find the "Daily Illini" in the first place? The UIUC main gopher server has a wonderfully useful resource on the top level menu called "Keyword Search of Gopher Menus." This item contains an index of the titles of every menu on our server. To find the Daily Illini amidst the megabytes of information and multitudes of menus on the server, do a "Keyword Search of Gopher Menus" on the string "daily illini." Or, suppose you know that there is a link to a searchable version of Roget's Thesaurus somewhere on our server, but you haven't a clue where to look. Just do a keyword search on the word "thesaurus" and you will be taken directly to the "Roget's Thesaurus" menu. VERONICA -------- The Keyword Search of Gopher Menus handles searching menus on our own gopher server, but what about the hundreds of other servers on the Internet? Let me introduce you to VERONICA. VERONICA stands for "very easy rodent-oriented net-wide index to computerized archives" and does for gopher what archie does for anonymous ftp archives (now we're all waiting for Betty, Reggie, and Jughead to appear on the Internet). VERONICA is a utility that indexes the titles of all levels of menus for most gopher sites on the Internet. VERONICA works like any other index search. You enter a word or group of words that you are looking for, and VERONICA creates a custom menu of all titles on all menus throughout gopherspace that match your query. By selecting an item in the custom menu, you are transparently connected to the gopher server on which it is located. VERONICA is a relatively new service and there are still a few problems to be worked out. First of all, VERONICA is very slow and bound to become slower as more users begin to use it. Developers are hoping to eventually distribute VERONICA searches among multiple servers, which should lessen the burden of any single VERONICA server. Secondly, many gopher servers point to popular items on other gopher servers leading to a great deal of redundancy among servers. VERONICA does not eliminate duplicate items, so a given search can result in many repetitions of the same service, document, or menu. Finally, VERONICA does not tell you where each title comes from. If your client has the ability to show the technical information behind each menu item (as described earlier in this article), then you can find out the domain name of the source, but not all clients have this capability and not all users know how to interpret this information. VERONICA can be found on our local server by doing a "Keyword Search of Gopher Menus" on the string "veronica" or by browsing the menu called "Other Gopher and Information Servers." Bookmarks --------- Navigating gopher is normally an up or down proposition. You can gradually work your way down through a series of menus and wend your way back up again, but lateral movement is generally not possible. Suppose you find a file or service in gopher that you know you'll want to access time and time again in a menu far removed from the top. Most gopher clients allow you to create and save so-called bookmarks. A bookmark keeps track of exactly where a gopher item is located, regardless of whether it resides on your local server or a remote gopher server. To go to that item again, you need only ask gopher to display your bookmarks and select the bookmark as you would any other gopher item. Creating a collection of bookmarks is like creating your own customized gopher menu. The commands for creating, viewing, and selecting bookmarks vary from client to client. In Turbo Gopher for the Mac, for instance, bookmarks are created by selecting a gopher menu item and then choosing the "Set Bookmark..." option from the Gopher menu (see Figure 4 on this page). Consult the on-line help or written documentation of your gopher client for more details on bookmarks. Gopher Broke? ------------- As we've seen, a gopher session can involve many computers and many applications. It's not uncommon, however, for things to go wrong in gopher. Occasionally a specific server function like ftp will go down, or a server can go down altogether. And, of course, certain clients simply cannot perform specific tasks. As you become well acquainted with your gopher client, you'll get a sense of what it can and cannot do. If you perform an operation regularly and suddenly it doesn't work, the problem probably lies with the server. If on the other hand, you've never had success doing something like a tn3270 session with your client, chances are that it does not support this function or is improperly configured. Hopefully the foregoing explanation of what takes place during various types of gopher transactions will help you to determine the source of any difficulties you might encounter. If you suspect that there is a problem with our local server, send an e-mail message to gopher@uiuc.edu (you can also send comments and suggestions about gopher to this address). Despite occasional problems, gopher is likely to open up the Internet to a much wider audience. Whether you are a power user or network neophyte, this rapidly evolving network tool has much to offer. In its infancy, gopher was called a distributed document delivery system. Today it is referred to as a distributed "information" delivery system. Who knows what tomorrow may bring? -Lynn Ward ****************************************************************** How Six Gopher Clients Stack Up The cover story of this issue describes how the Internet gopher can be a very powerful tool if you're using the right client software and if that client is properly configured. Over the last several months, I've had the opportunity to work with about ten different gopher clients, several of which have already been superseded by new, more powerful applications. To describe each of these clients in detail would fill a book, and for most gopher clients there is a user's guide, on-line help, and/or a man page that gives technical information and instructions for use. Below is a brief sketch of six gopher clients, each for a different computing platform. This review highlights the strengths and weaknesses of each client and, in a few cases, provides some important undocumented technical information. All of the clients discussed in this review can be downloaded from the anonymous ftp host "boombox.micro.umn.edu." They are located in subdirectories (named according to platform) under the "/pub/gopher" directory. Several clients are also available at the CCSO Resource Center, 1420 DCL. Note: The comments below refer to the specific version of the client that was reviewed. Since many developers continue to work at improving their software, some of the bugs and other peculiarities described here may have been or will be fixed in a later release. Xgopher 1.2--the Latest and Greatest ----------------------------------- One of the newest kids on the block is the latest release of Xgopher, an X Window System client written by Allan Tuchman, senior research programmer here at CCSO. Xgopher can handle just about any gopher function that's currently available. The interface is very simple to use (see Figure 1 on page 9). Most commands are available by clicking on buttons in the main window. Less commonly used commands are tucked away in a pull-down menu called Other Commands. Xgopher provides support for a variety of different file or object types including: image files (image files are displayed by xloadimage, a separate utility that can display many different types of graphics file formats), sound files (sound files can be played if Xgopher is installed on a workstation that supports sound), Unix binary files, ph queries, index searches, and telnet and tn3270 sessions. An options panel under the Other Commands menu allows you to tell Xgopher whether you want to see all files or just the file types that it knows about. If you opt to see all files, Xgopher will display unknown types with a prefix. Any file type in a gopher menu or directory, even unknown types, can be transferred to the client machine (for unknown file types, Xgopher defaults to binary transfer mode) with the copy selected item to file command. The bookmarks option is also extremely flexible in Xgopher 1.2. Xgopher can maintain multiple bookmark files, any of which may be loaded during a single session. Also, the bookmark file is compatible with the Unix curses client, so you can use the same bookmarks when dialing in from home. The ph client in Xgopher is fairly powerful, but not quite as intuitive as other implementations. The user is prompted to enter a query in the "Query name" field and results are displayed in the box below. A "Show Fields" menu displays the names of the fields available on the selected ph server and the intended contents of those fields. There is some minimal on-line help, but in order do anything more complex than a simple query on the "name" field, one must already be well acquainted with the syntax of ph commands. X Window System gurus can totally customize Xgopher by modifying the application resources file called "Xgopher." This plain text file contains all the settings for Xgopher, including the host name of the default gopher server; the name of the default bookmarks file; the prefixes used for each gopher object type; the default screen colors; the default fonts; the specific text used for all menus, buttons, and dialog boxes; the specific applications used to play sound files, display image files, and conduct telnet and tn3270 sessions, and many other parameters. Any of the default settings can be changed to suit the preferences of the end-user. Xgopher is installed on ux1, ux2, ux4, uxa, and uxh and can be accessed by anyone with an X terminal or a desktop computer running an X server application such as MacX. Questions and comments about Xgopher should be directed via e-mail to Allan Tuchman at the address a-tuchman@uiuc.edu. TurboGopher 1.0.5 for the Mac ----------------------------- Although there are several gopher clients available for the Macintosh, TurboGopher 1.0.5 stands out among the crowd. TurboGopher cannot play sound files or display raw gopher information, but it handles almost every other gopher operation with the greatest of ease and speed. The ftp function works particularly well. To transfer a file to your Mac, just double click on its icon. If the file is BinHexed, TurboGopher will un- BinHex it as it transfers the file to your local disk. This gopher client even recognizes Unix and DOS binary files and will intuitively transfer them in binary mode. When you get your copy of TurboGopher, be sure to download the helper-applications SitExpand, CptExpand, and Giffer. If these programs are installed on your Mac, TurboGopher will offer to decompress files that have been archived with the StuffIt or Compactor utilities (files with a .sit or .cpt extension) and display GIF image files immediately after such files have been downloaded. The ph client in TurboGopher is very easy to use. Unfortunately it has a major bug. You can only enter a single name when doing a search on the "name" field. If you enter a first and a last name, the client sends the query to the server improperly and you'll get the message "501: No matches to your query." Since the "name" field is the most common field for doing ph lookups, this is a big problem. In order to do a query with TurboGopher's ph client, the person you are looking for must either have a very unique last name or you must know some additional information about the person, such as his or her phone number or address. TurboGopher supports both telnet and tn3270 sessions only if the appropriate applications (NCSA Telnet and Brown's TN3270) have been installed on your hard disk. Additionally, in order to conduct a tn3270 session, a copy of your "config.tel" file must be located in your System Folder. TurboGopher is installed on all of the Macs at CCSO's computing sites and is also available at the CCSO Resource Center. The software is copyrighted by the University of Minnesota, but can be copied and distributed freely. NeXT Gopher 1.3 --------------- For those fortunate enough to have a NeXT workstation sitting on their desk, NeXT Gopher 1.3 offers a slick interface and good overall functionality. Two noticeable shortcomings are its inability to successfully display and transfer files other than plain text (supposedly, unsupported object types can be displayed by typing a special command at the terminal prompt, but this doesn't seem to work) and the absence of a bookmarks option. With the help of supporting applications, sound files can be played with exquisite clarity and GIF files can be viewed. Gopher files can also be mailed to other users with the NeXT client. One curious aspect of NeXT Gopher is that it does not have a built-in ph client. Instead it relies on a separate program, NeXT Ph, which comes bundled with the distribution. All in all, NeXT Gopher is probably the "prettiest" client around, but it still has some catching up to do in order to match the X and Mac clients. The Unix Curses Client 1.01 --------------------------- The Unix curses gopher client was designed to run on dumb terminals, so there are no fancy icons or mouse support. Navigating menus involves either moving the cursor to the desired item or entering its number and then pressing the key. But don't let this simple interface mislead you. The curses client is fairly intelligent, although sometimes uncooperative. When installed on a Unix workstation, this gopher client can display image files and play sound files. Remote users with dumb terminals or terminal emulators can use the curses client to conduct archie searches, telnet and tn3270 sessions, ph queries, and index searches. Unfortunately, although the ftp client is capable of transferring any type of binary file, it only displays the names of ASCII files, BinHexed files, and Unix binaries. This can be very misleading when browsing ftp sites. Strangely enough, other types of files such as DOS executable and archived files will be displayed if you do an archie search, and these files can be successfully ftp'd once they are displayed. Version 1.01 of the curses client doesn't do a very good job at recognizing object types. When it displays executable DOS files during an archie search, it assigns them an type, which stands for BinHex. Tn3270 sessions work, but there is no type identifier next to them. If you are new to the Unix curses client, be sure to check out the on-line help with the "?" command. It will tell you how to display technical information on an item, navigate menus, add bookmarks, and customize your gopher environment. You can change the program defaults of the curses client by executing the "O" (options) command. Within the options menu, you can specify the default pager, print command, mail command, etc. Bookmarks and your program defaults are saved in a ".gopherrc" file located in your home directory. The curses gopher client installed on CCSO Unix machines is supported by CCSO staff. If you have a question or problem, send an e-mail message to gopher@uiuc.edu or call the CCSO systems consultants at 333-6133. PC Gopher II 1.05r3 ------------------- While there are several Gopher clients available for the DOS environment, PC Gopher II is the only one that does not require the user to load a commercial TCP/IP stack such as FTP Software's PC/TCP kernel or Novell's LAN Workplace for DOS. This client uses the extended IBM character set to create a pseudo-graphical interface, complete with pull-down menus, sizable windows with scroll bars, and support for a Microsoft-compatible mouse. Let's first consider the strong points of the DOS client. PC Gopher II supports index searches, has a respectable and fully functional ph client, can display the technical information about an item, and supports bookmarks. Unfortunately, the bookmarks feature is limited to selecting menus only, not items within menus such as an index search. PC Gopher II also supports telnet sessions if it is properly configured. Be sure the "Allow Telnet Sessions" box is checked in the configuration window. Also, in order to conduct a telnet session, you must set a DOS environment variable so that gopher knows where to find your telnet application. To accomplish this, a line can be added to your "autoexec.bat" file or the batch file that starts gopher.The general syntax of the line should be: set g_tel=c:\telnet_directory\telnet_app -h c:\telnet_directory\ config.tel %%a %%p where telnet_directory is replaced by the name of the directory in which your telnet program is stored and telnet_app is the name of your telnet program's main executable file (e.g., "telbin.exe," "tn.exe," etc.). When telnet is invoked by PC Gopher II, the parameters "%a" and "%p" are replaced with the IP address and port information provided by the gopher server (if you type the set command at the DOS command prompt instead of including it in a batch file, use a single percent sign in front of the "a" and "p" parameters [e.g., "%a %p"]). When using PC Gopher II in conjunction with Clarkson and NCSA telnet, it may be necessary to surround the "%%a %%p" parameters with double quotes in order for telnet to properly recognize a port number. For example, the "g_tel" variable in my "autoexec.bat" file looks like this: set g_tel=c:\telnet\telbin.exe -h c:\telnet\ config.tel "%%a %%p" PC Gopher II is a memory hog and does not support or display tn3270 sessions, so there is no reason to use the larger application "tn3270.exe" as the telnet program file. There is still much work to be done before PC Gopher II can compete with the clients mentioned above. This client only recognizes, displays, and transfers ASCII text files. Thus, file transfers are extremely limited and archie queries produce unpredictable results. Also, occasionally binary files (such as GIF files) are misconstrued as text files and PC Gopher II tries to display them. Additionally, the memory constraints of PC Gopher II prevent it from displaying the complete text of even moderately sized files. Such files must be saved to disk and read or printed with a text editor or word processor. Hopefully, many of these problems will be ironed out in the next incarnation of this DOS client. In the meantime, if you have a Unix account, you may prefer to use the Unix curses client instead. CMS Gopher 2.2.0 ---------------- CMS Gopher 2.2.0 is quirky, to say the least. On the one hand, it recognizes and displays the names of almost all object types. However, it can only display and transfer plain text files. To save a text file, the file must first be loaded into the XEDIT editor (there is no "save" command in gopher itself). Although the client supports ph and archie searches, with a few rare exceptions index searches fail and return an error message. The most ironic shortcoming of this client developed for IBM mainframes is that, while it can launch telnet sessions and communicate clumsily with Unix hosts, it does not support tn3270 sessions with other IBM mainframes. An attempt to launch such a session will result in the error message "Can't process this file type." A new version of CMS Gopher is available, but as of this writing, has not been installed on VMD. Perhaps some of the oddities just noted are corrected in release 2.3. For More Information -------------------- For the most up-to-date information about gopher and the gopher software distribution, browse the documents and the "Gopher Software Distribution" menu under the "Information about Gopher" menu on UIUC's main gopher server. -Lynn Ward ****************************************************************** The ACN is on the Move Again Computers, like people, occasionally relocate. In the case of networked systems, this often means that the computer, again like a person, will have a new address. Such is the case for the MVS/CAS system on the Administrative Computing Network (ACN). In mid-December, the TCP/IP interface for the ACN's MVS/CAS system was moved to a router on the FDDI ring at the University of Illinois at Chicago. By connecting this computer to the FDDI ring, AISS hopes to improve the performance of the MVS/CAS system on the network and to increase the number of possible TCP/IP connections it can handle. However, the move also means that the IP address for accessing this system via ftp and telnet will already have changed by the time this article hits the streets. For this reason, AISS encourages all clients to begin using the fully-qualified domain name "UICMVSA.AISS.UIC.EDU" when accessing the MVS/CAS system rather than using its numerical IP address. And, in general, users are urged to always use the hostname as opposed to the IP address, because the IP address might change again sometime in the future, whereas the hostname for this machine will never change. If you are accustomed to accessing the ACN by typing its IP address when you invoke your TCP/IP applications (e.g., telnet, ftp, etc.), simply substitute UICMVSA.AISS.UIC.EDU for the numerical IP address when issuing commands to open a session on the MVS/CAS system. For example, if you ordinarily open a session by typing the command "tn3270 131.193.163.4", use the command "tn3270 uicmvsa.aiss.uic.edu" instead. In addition, all references to the ACN's old numerical IP address (131.193.163.4) in batch files, login scripts, telnet configuration files, and user documentation should be replaced with the host name UICMVSA.AISS.UIC.EDU. This step is especially important because, during the transition of moving the ACN's telnet server from the VM/PROFS machine to the MVS/CAS system last year, there was initially a problem accessing the latter system with the host name. Thus, many network administrators and end- users may have quite intentionally configured their software to use the IP address in order to bypass this problem. However, the domain name problems of the MVS/CAS computer have long since been resolved, and now the use of the hostname is desirable, if not imperative. The new IP address for the MVS/CAS system will be announced in January, but AISS will continue to discourage clients from using it, except in cases where there is a temporary problem with the domain name service. Finally, these changes will in no way affect ftp and outgoing telnet sessions on the VM/PROFS system. Nor will it affect the Internet or BITNET electronic mail addresses of PROFS users. -Lynn Ward ****************************************************************** CCSO Beefs Up Network Support Staff and Services UIUCnet is no longer just a tool for engineers and computer scientists. Thousands of students, faculty, and staff use the network every day for routine activities. CCSO is increasingly aware of the need to provide high-quality support services to end- users and network administrators. Two new staff members, David Ruby and Steven Hinkle, were hired this fall to augment existing support staff. David Ruby, a U of I graduate with a major in Spanish and minor in computer science, comes to CCSO from the UIUC College of Liberal Arts and Sciences, where for two years he served as the network administrator for one of the largest and most complex in-building networks on campus--the 400+ node network in Lincoln Hall. While managing the Lincoln Hall site, Dave worked extensively with PCs and Macs on Token Ring, Ethernet, and LocalTalk networks. David is now part of CCSO's User Services group and holds the title Research Programmer/Network Consultant. Currently, he is assisting Randy Cotton, network consultant for the Network Design Office, with a backlog of troubleshooting requests. Dave's responsibilities at CCSO will evolve as needs dictate. It is anticipated that he will be a primary source for the support and training of network administrators. Dave will also provide information and instruction to CCSO's full and part-time consultants in order to keep them up to date on network applications and technologies. Steven Hinkle, CCSO's other new hire, will concentrate on the end- user side of networking. Steven, now a Research Programmer/Systems Consultant for User Services, received his B.S. in computer science from the University of Buffalo in August of '92. At Buffalo, while working toward his degree, he also served as a consultant for a variety of computer systems, including PCs and Macs, IBM CMS mainframes, DEC VAX clusters running VMS, and Sun clusters running SunOS. As a newcomer to the U of I and CCSO, Steven is still in the process of acquainting himself with our network, systems, and services. His role in User Services will include offering short courses for end-users on how to use the network, writing end-user documentation, consulting on network- related problems, and supporting popular network applications for PCs and Macs such as NCSA Telnet, Eudora, NUPop, Trumpet, etc. David and Steven make a fine complement to CCSO's existing network support staff, Randy Cotton of the NDO, Declan Fleming and Leslie Rankin (manager and assistant manager of the CCSO sites), and the many CCSO staff members involved with LAN maintenance. Recently, Declan has been working with faculty to make instructional software available at CCSO's networked sites. He also started a Novell Users group, which provides a forum for Novell LAN administrators to share information and discuss specific topics of interest (for more information on the Novell Users group, send e- mail to Declan at d-fleming@uiuc.edu). CCSO systems consultants are also spreading the gospel of UIUCnet. Through a relatively new "outreach" program, consultants are providing on-site seminars to faculty and staff about the services and applications available on UIUCnet, with an eye toward offering special courses on how to use the network for teaching and research. Meanwhile, CCSO managers are taking a fresh look at how to best meet the ongoing network support needs of this campus. Their goal is to develop a flexible, well-rounded program that will maximize the effect of CCSO's support and training efforts. -Lynn Ward ****************************************************************** MacTCP 1.1.1 Available at CCSO Resource Center This fall, Apple Computer rolled out several new models of desktop and portable computer and, with them, an incremental upgrade of the Macintosh operating system. The new OS, called System 7.1, reportedly offers better font handling, improved stability and performance, improved support for new CPUs (so that system upgrades are not required when new products are introduced), and the incorporation of Apple's multimedia technology known as QuickTime. One thing that System 7.1 does not offer, however, is compatibility with MacTCP versions 1.1 and earlier. MacTCP, Apple's implementation of the TCP/IP protocol suite, provides a standard interface for developing TCP/IP-based software (e.g., NCSA Telnet, Fetch, Eudora, etc.) for the Mac. Virtually every Macintosh connected to the campus backbone has a copy of MacTCP installed in its System folder as a control panel device. To address the compatibility problem between System 7.1 and MacTCP, Apple has released MacTCP 1.1.1. MacTCP 1.1.1 is available free to University staff and students through a product site license. All UIUCnet users who have ordered or received a new Macintosh with System 7.1 pre-installed, as well as users who have upgraded an older Mac to System 7.1, should obtain and install this latest version of MacTCP. The software is available on all of the Macintoshes in the CCSO Resource Center, 1420 DCL. It is located in the AppleShare volume called "RC_MACs" in the folders "/Public/Communications/Eudora 1.3b109/Mac TCP Software" and "/Public/Communications/Network/Mac TCP/ver 1.1.1." Remember to bring your own floppy disks (double-sided, double density will do) to copy the files. According to a press release, in addition to providing compatibility with System 7.1, the new MacTCP offers "better support for extension products, such as AppleTalk Remote Access (ARA), SLIP (Serial Line IP) and PPP (Point-to-Point Protocol) drivers, as well as support for larger 'Hosts' files." Installing MacTCP 1.1.1 for the First Time ------------------------------------------ If you don't already have a copy of MacTCP on your system (as will be the case for individuals who have purchased new Macs), ask your building network administrator to assist you with the installation of the software. He or she can help you determine whether your IP address will be static or server-allocated and whether the address needs to be registered with the UIUCnet hostmaster (the person who keeps track of IP addresses and domain names for all systems attached to UIUCnet). Upgrading to MacTCP 1.1.1 ------------------------- Mac TCP 1.1.1 is downwardly compatible with earlier versions of the Macintosh operating system and can be installed on Macs running System 6.x, 7.0, and 7.0.1. Before installing the new version of MacTCP, open your existing copy of MacTCP through the Control Panel and record the current settings of the software. First, if there is a LocalTalk icon and an Ethernet icon in the MacTCP window, note which one is selected. If the LocalTalk icon is selected, record the name of the AppleTalk zone that appears beneath it (if a name appears). Then, write down the number given as the "IP Address." Click on the "More..." button and you should see a window that looks like Figure 1 on this page. Write down the information entered in the boxes labeled "Obtain Address, Routing Information," "IP Address" (class and subnet address), and "Domain Nameserver Information." All of this information must be entered in the new version of MacTCP when you install it. Once you have recorded this configuration information, you can throw the files named "MacTCP," "AdminTCP" and "MacTCP Prep" in the Trash (you may, however, want to first copy these files to a floppy disk in case your installation runs amuck). Then, copy the new "MacTCP" and "AdminTCP" files into your System folder. For Macs running System 7 or higher, place the files in the Control Panels folder within your System folder. Once the new files are in place, open MacTCP though the Control Panel and configure the software to match the settings you recorded from your previous version. If you have any problems with the installation or you install it and discover that your network applications do not work, contact your building network administrator for assistance. - Lynn Ward ****************************************************************** Customizing Telnet Sessions on a PC Although telnet, the TCP/IP remote login application, is probably one of the first pieces of software to which new UIUCnet/Internet users are introduced, very few people have the time or inclination to learn about and exercise all of the options available in the software. In fact, it's probably safe to say that most people on campus don't even have the complete documentation for the version of telnet they use. This is unfortunate. While you may not have time to read the manual from cover to cover, browsing the table of contents or index could expose you to some features that you might find very useful. This month's Net Tip focuses on customizing the telnet environment on a DOS-based PC so that you can easily connect to a specific host without having to remember its full domain name or IP address and preconfigure various session parameters with such hosts. (In the next issue of UIUCnet, we will look at the equivalent procedures for the Macintosh.) About the Config.tel File ---------------------- Normally, unless someone has carefully preconfigured your telnet software for you, when you open a remote login session with NCSA or Clarkson Telnet, you must type the name of the executable file that starts the telnet software followed by the full domain name or IP address of the remote host (e.g., "telbin ux1.cso.uiuc.edu"). Additionally, the screen colors, keyboard mappings, scrollback settings, echo mode, and other parameters will be the same for every session. You can simplify the login process and customize the parameters that govern the sessions with specific hosts by modifying the telnet configuration file called "config.tel." The config.tel file is a plain text file that contains the default settings used by the Telnet software. The format of the file is quite straightforward. Lines that contain a parameter name followed by an equal sign and a value (in the form "keyword= value") are read and used by the Telnet software (and related utilities) when opening a session and communicating with a remote host. The meaning of each parameter is described in detail in the user's manual and briefly in a comment on the same line in the config.tel file. Lines or parts of lines that begin with a pound sign (#) are comments. The beginning of the config.tel file contains important information about the network configuration of your machine and default settings for the Telnet software. Many of these parameters were probably preset by your network administrator (or whoever installed the software), and it's generally best not to fuss with them if your software is working properly. Somewhere toward the middle of the file, however, you should see groups of lines with each group headed by a line beginning with the keyword "name" (e.g., name=ux1) Each of these groups describes the parameters to be used when communicating with a specific machine on the network and the keyword "name" is used as a delimiter to separate one machine-specific entry from the next (as well as to provide a short, descriptive name for each system, which can be used in lieu of its IP address or domain name). Generally, the first "name" entry begins with the text "name=default." This entry contains the default values used for any session that doesn't have a specific "name" entry in your config.tel file and also determines the settings of parameters that are not otherwise specified in a named entry. If you are not satisfied with the default values for screen colors, the scrollback mode, the default keyboard map, etc., you can change them. Any changes you make will affect all sessions that do not have a specific entry in your config.tel file. Following the default settings for telnet, you should see several other machine-specific entries in your config.tel file. Remember, each machine-specific entry begins with the line "name=value" where value is replaced with a descriptive name for the system. The parameters following the keyword "name" may be on separate lines, or they may be on the same line, each separated from the next by a semi-colon, colon, or space. In addition to the systems already specified in your config.tel file, you can add entries for the machines you access on a regular basis. The example in Table 1 shows three machine-specific entries in a config.tel file (with comments)--one for accessing the on-line library system (beginning with "name=library"), one for accessing the CCSO Unix machine ux1 (beginning with "name=ux1") , and one for accessing the CCSO IBM mainframe VMD (beginning with name=vmd). Table 1: Machine-Specific Entries in a Sample Config.tel File name=library #descriptive name for library #system host="garcon.cso.uiuc.edu:625" #domain name and port number #of library system hostip=128.174.5.58 #IP address of library system nfcolor=WHITE #screen color settings for all #sessions with library nbcolor=blue rfcolor=red rbcolor=cyan ufcolor=black ubcolor=white scrollback=200 name=ux1 #descriptive/short name #for ux1 hostip=128.174.5.59 #IP address for ux1 erase=backspace #backspace key functions as #standard backspace copyfrom=library #borrow other parameters from #entry named library name=vmd #descriptive/short name #for VMD host=vmd.cso.uiuc.edu #domain name for VMD keymap=vmd.tbl #use custom keyboard map file #called vmd.tbl for this #session. Once you have added machine-specific entries to your config.tel file, you can access these systems by typing the name of your telnet executable file followed by the value entered for the name of the entry. For example, to open a session with the library, you could type: "telbin library". The Telnet software will look in your config.tel file for an entry with the name "library" and use the parameters specified after name=library until it encounters the next "name=value" entry in the file--in the case of our example, "name=ux1." Note that the entry for VMD only contains values for "name," "host," and "keymap." When parameters are not specified in an entry, the values defined in the entry "name=default" will prevail. Thus a machine-specific entry can be very brief, containing only values for the keywords "name" and "host" or "hostip;" or the entry can be quite extensive, containing custom values for every possible parameter. You can add as many machine specific entries to your config.tel file as you like. Most users find it convenient to add the names of systems that they access regularly via telnet or ftp. A list and description of some of the parameters that you can include in each entry are given in Table 2. The list is taken from the config.tel parameters for Clarkson Telnet (CUTCP) version 2.2D. If you use NCSA Telnet 2.3, you will notice some slight differences in the way certain parameters are handled. Consult the user's manual for the complete list of machine-specific parameters for each application. Table 2: A Partial List of Machine Specific Parameters for the Config.tel File Parameter Description --------- ----------- name=value User-assigned name for system. Replace value with a short name you can remember easily. host=fully.qualified.domain.name The domain name for the system you want to reach. Replace fully.qualified. domain.name with the actual domain name of the host you want to contact. If you want to designate a port number as well, separate it from the domain name with a colon and surround the entire value with double quotation marks (e.g., host ="garcon.cso. uiuc.edu:625"). hostip=###.###.###.### The IP address of the host you want to contact. If the IP address is not included, telnet will contact one of the nameservers listed in your config.tel file to resolve the domain name given with the host parameter. Including the IP address will generally speed up the time it takes to connect to the specified host. erase=(backspace or delete) Determines the function of the backspace key for the session. Some hosts prefer the backspace key to be delete and others prefer the backspace key to be backspace. Set this parameter to erase= backspace or erase=delete. scrollback=numeric value Determines the number of lines that can be viewed in scrollback mode. Scrollback uses 86 bytes per line saved. Set your scrollback value to a small number if you are concerned about running out of memory. The typical range is 100 to 200 (e.g., scrollback= 200). The following parameters set the screen colors for the session. Possible colors are black, green, blue, magenta, cyan, red, yellow, and white. When typed in upper case, foreground colors will appear in high-intensity and background colors will blink. nfcolor=color normal foreground color nbcolor=color normal background color rfcolor=color reverse foreground color rbcolor=color reverse background color ufcolor=color underline foreground color ubcolor=color underline background color copyfrom=name Causes the session to use the same parameters specified in another named session in the config.tel file. For example, copyfrom=ux1 would cause the current entry to use the same parameters as those specified for the session named ux1 unless alternative parameters were explicitly designated. keymap=filename.tbl Uses the custom keyboard mapping as specified by the value entered for filename.tbl. Clarkson Telnet provides the user with a default keymap for vt100 sessions and a 3270 keymap for tn3270 sessions. The user can create additional custom keyboard mappings and associate them with a particular session by using this parameter. Otherwise "default.tbl" will be used for sessions using vt100 emulation and "tn3270.tbl" for sessions using 3270 emulation. Editing the Config.tel File ------------------------ The config.tel file can be edited with a plain text editor or word processor. If you use a word processor such as WordPerfect or Microsoft Word, you must export the edited file to ASCII format when saving your changes, in order to remove any application- specific codes that may have been added to the file by your word processor. Here are some additional pointers to keep in mind when editing the file: - Before editing any line in your config.tel file, be sure to make a copy of the original file with a name like config.old or some other unique name (do not use the name config.bak because your text editor may use it as a default backup name, and you could potentially overwrite your original during the editing process). Taking this precaution will enable you to resurrect your original telnet configuration in the event that your modifications cause Telnet to malfunction. - Do not modify or delete any line in the config.tel file if you are uncertain about its function. - In the machine-specific section of the file you are likely to encounter entries with parameters such as "nameserver=#" and "gateway=#." These entries have probably been preconfigured by the person who installed your telnet software and should not be changed unless you are certain that they are incorrect. The "nameserver" entries instruct telnet to ask specific machines on the campus net to translate domain names into IP addresses. The "gateway" entry specifies the address of the machine that connects your building network to the campus backbone. - If a comment wraps around to a second or third line, be sure that each line begins with a pound sign (#). - Even if you do not have a copy of the entire Telnet user's guide, have the section pertaining to the config.tel file on hand for reference as you make your changes. - Finally, editing a config.tel file for the first time can be a little intimidating. If you are uncertain about what you are doing, your building network administrator can probably provide some assistance. Additionally, the CCSO microcomputer consultants are well-versed on Clarkson and NCSA Telnet and can be reached at 244-0608. - Lynn Ward ****************************************************************** Navigating and Using the Internet: A Hands-on Course with a Heart A new course will be offered through the Graduate School of Library and Information Science this spring: "LIS450CC, Advanced Problems in Librarianship--Telecommunications." The course combines the learning of real-world skills for navigating the Internet with a survey of the major uses of and issues related to the Internet. Professor Greg Newby will teach the course. Newby, who presented a similar course at Syracuse University, also hopes to offer LIS450CC to students at remote networked sites through UIUC's extramural program in the fall of '93. Professor Newby's course will concentrate on computer networking as a medium for human communication. Familiar forms of human communication--the telephone, postal service, and face-to-face interaction--will be compared and contrasted with networked communication. Computer networking shares qualities with traditional communications media, but also has important differences. The norms and standards of networked communication are not yet well established, and the channels of communication-- for example, ftp, mailing lists, and various information services- -are not always easy to understand and/or access. A thread that runs throughout the course is the rather gray area of what constitutes acceptable and unacceptable behavior on the Internet. For spoken communication and the printed word, there are both well-defined social rules for interaction and a body of law to deal with transgressions. In the datasphere, however, few laws exist and the norms of conduct are still being formed. A class session will be devoted to topics such as the Morris Internet Worm and the West German hacker who was caught by Cliff Stoll. These and other examples will lead to discussions about how the end-user can better recognize and be prepared to deal with situations requiring ethical judgment within a networked environment During the first seven sessions, students will spend about half of each class in a computer lab acquiring hands-on experience. The Unix operating system, electronic mail, and other basic network tools such as telnet and ftp will be covered in detail. Students will also have the opportunity to investigate more specialized applications, such as Gopher, the World-Wide Web (WWW--a hypertext application used for locating and accessing information on the Internet), WAIS, Archie, and Hytelnet (a hypertext application for facilitating telnet sessions with on-line library catalogs and information servers). Throughout, the focus is on using network-based resources to extend each student's personal and professional information resources. Students will be encouraged to identify ftp sites, databases, or mailing lists and newsgroups containing information pertinent to them. They will also be encouraged to interact with their peers or experts in various fields by using network tools, and to consider the electronic dissemination of their thoughts, findings, and papers. The balance of the course is a survey of various perspectives on computer networking. First, a foundation in human communication theory and practice will be laid, and, from there, various aspects of computer networking will be addressed. The history of networking and many types of computer networks and protocols for data transfer will be treated in detail. Corporate communication, information storage and retrieval services, and public access to networked services will also be covered. Finally, the course will address questions about the future of computer networking--e.g., how NREN (the National Research and Education Network) and an increased network presence in libraries and K-12 schools might change the users and uses of Internet. LIS450CC will meet on Mondays from 12:00Ð3:00 p.m. during the spring semester. Non-LIS grad students and auditors are invited to attend, space permitting. Many of the readings for the course as well as the syllabus may be obtained via anonymous ftp from the host "gpx.lis.uiuc.edu". These materials are located in the directory "pub/netinfo". Specific questions about the course can be directed to gbnewby@alexia.lis.uiuc.edu. - Greg Newby