Personal Internet Access Using SLIP or PPP: How You Use It, How It Works Frank Hecker hecker@access.digex.net June 30, 1994 Copyright 1994 by Frank Hecker. You may redistribute this document freely in any form provided only that you retain this copyright notice. This document is available online at the following URL: file://ftp.digex.net/pub/access/hecker/internet/slip-ppp.txt (See the last section if you don't know what a URL is and need more information on how to retrieve this document.) Introduction As the Internet has been popularized in newspapers, magazines, and books, many people are joining (or trying to join) the community of Internet users online. Some subscribe to commercial services like CompuServe and America Online that are adding some Internet-related features to their existing services. Others purchase accounts on commercial services which provide Internet access as their main offering, or are getting accounts on "Free-Nets" and other community network systems which offer Internet access as an adjunct to community information. Finally, there is a small but rapidly growing number of people who are experiencing the joys of connecting to the Internet directly from their PCs or Macintoshes, without having to login to larger systems and put up with the hassle of UNIX commands or restrictive menus. In this paper I discuss this highest level of personal Internet access, both how you use it and how it works. I assume that you have some understanding of the Internet and the services it supports (e.g., Telnet, FTP, and electronic mail), but that you know very little about TCP/IP, SLIP, PPP, and other obscure acronyms. My goal is _not_ to give you complete step-by-step directions on how you can configure your PC or Mac for connection to the Internet, but rather to provide a conceptual overview of personal Internet access without getting into too many technical details. My hope is that after you finish reading this paper you will have a good idea of how personal Internet access works, how SLIP and PPP are used in real life, and whether it makes sense for you to use them. With that end in mind I conclude the paper with some advice on where to go next for more information. This document was originally written for the Washington, D.C., area community network CapAccess (the informal name for, and a service mark of, the National Capital Area Public Access Network, Inc.); it grew out of some thinking I did about the long-term directions for community networks and what part low-cost personal Internet access might play in their evolution. At the time I could not find any non-technical high-level explanation of the concepts behind SLIP and PPP Internet connections; to paraphrase Muriel Rukeyser, I wrote this paper in part because I needed to read it. I'd like to thank the other members of the CapAccess organization for their comments on early versions of this paper; however the views I express herein are mine alone and do not necessarily reflect the official position of CapAccess. Me, My Computer, and the Internet When I first became an Internet user, I used a so-called "shell account" service provided by a local D.C.-area Internet access provider, the Digital Express Group, Inc. (It's called a shell account because you login to a central UNIX host and type UNIX commands into the UNIX command interpreter or "shell.") I used this service much as you might use a BBS, a "Free-Net," or other UNIX-based community network systems like CapAccess (albeit with a few more functions): I would use my Macintosh and its modem to login to the central UNIX host (a Sun system), read and compose electronic mail using Pine (a UNIX email program), read and post Usenet news articles using a UNIX-based newsreader, retrieve files using FTP and then download them using Zmodem, and so on. For software I used the shareware communications program Zterm, a copy of which came with the Global Village 14.4 kbps modem I have. (For those of you who have PCs, Zterm is a typical character-based communications program with VT100 terminal emulation and Zmodem download capabilities, comparable to Procomm or CrossTalk.) Recently I upgraded my service to a so-called "SLIP account." SLIP or Serial Line Internet Protocol is a communications protocol that supports an Internet connection (i.e., using TCP/IP) over a dial-up line. PPP or Point-to-Point Protocol is a newer protocol that does essentially the same thing; however it's better designed and more acceptable to the sort of people who like to standardize protocol specifications. For the rest of us it's six of one and a half dozen of the other for the most part, and I'll often use the term "SLIP/PPP" to refer to them interchangeably. (Although, as I note below, PPP is likely to become better supported and more popular in the future.) Not only was setting SLIP service up much simpler than I anticipated, it also gave me a whole new perspective on how individuals will likely use the Internet in the future. I'll get to the technical details later, but I'd like to start by describing a typical communications session: I start with my Mac booted and its modem connected to a phone line. First, I invoke the SLIP application. (In Mac terms this "application" actually consists of an extension plus a control panel; for those more familar with DOS, it is roughly comparable to a TSR or "Terminate and Stay Resident" utility). The SLIP software asks me for my SLIP password (which goes with my SLIP userid--more on this below), and then uses a script to dial the SLIP access number at my Internet access provider. My modem dials out, their modem answers, and then the script takes over for a few seconds until the SLIP connection is established. I then forget about the SLIP application, and often close it just to get it out of the way. (Part of it is still running "underneath," however.) At this point I have a live connection between my Mac and the Internet. The next thing I typically do is start up the Eudora mail program, and then ask it to check for and retrieve my electronic mail. Eudora asks for my mail account password (which goes with my mail account userid). Note that these are a different userid and password than my SLIP userid and password; I discuss this in more detail below. Eudora then goes out and downloads my mail from my mailbox on the Internet access provider's mail server. This can take from a few seconds to a few minutes, depending on how much mail I've received and how big the messages are. When downloading completes I have all my new mail messages in an inbox on the Mac. I can then either read my mail or do something else. Usually I read at least a few messages that look important, and perhaps respond to a couple of them. When I respond my messages get put in an outbox for later delivery; they aren't sent right away. Suppose one of the messages is about something on another Internet- connected system, such as the CapAccess community network system. I then invoke the NCSA Telnet application and connect to CapAccess ("cap.gwu.edu") to check things out. This brings up a VT100-like screen similar to what you'd get dialing in directly, with a prompt for the login id. I give my CapAccess userid and password, and then I'm logged in as usual and can do all the standard CapAccess operations. Note that this Telnet connection isn't going through either the Internet access provider's UNIX host system or the CapAccess phone lines and modems; it's going over the Internet from my Mac to the CapAccess Sun system (with some hops along the way through IP routers, "black boxes" which pass the traffic through the various networks and subnetworks that make up the Internet). Suppose that something I read in a CapAccess forum refers to an information file that you can FTP from someplace. Then, _without closing the Telnet session_, I can bring up the Fetch application, which is an implementation of FTP for the Mac. Fetch allows me to start a session to a public or "anonymous" FTP site, browse through the directories, and download files using FTP directly to my Mac; download speeds for text and binary files are comparable to those achievable using traditional communications programs and protocols like Zmodem. (They are not always quite as fast, for various reasons too complicated to go into in this paper, but they are fast enough for me.) After finishing the FTP session I can go back to my Telnet session and continue. TCP/IP and SLIP (or PPP) can "multiplex" several connections; that is, several connections can be open at once and can be sending and receiving data, with TCP/IP and SLIP/PPP sorting it all out and transmitting and receiving that data over the single dialup connection to the Internet acces provider's SLIP/PPP access point. If the Mac had true "preemptive" multitasking (like OS/2 or Windows NT, for example), I could actually have different downloads going on simultaneously while I ran other Internet applications. As it is though, doing an FTP transfer on my Mac will pretty much kill performance on a Telnet session; however it works fine to keep multiple applications open for use but otherwise idle, and I can then switch between them as desired. If I'm really done with my Telnet session, I'll log out of the remote system and close the link. I might then bring up NewsWatcher, a Usenet news reader for the Mac. NewsWatcher connects to the Internet access provider's Usenet news servers and then presents me with a list of my currently subscribed newsgroups, together with an indication of how many postings are available in each group. I double-click on a newsgroup I'm interested in checking, and Newswatcher downloads the list of current postings in the group, by subject. (It knows about "message threads," so if multiple postings have the same subject it only shows me one line in the listing of articles.) I then double-click on the line corresponding to a posting (or thread) I want to read, and Newswatcher downloads the text of that posting and puts it on the screen in a window. More double-clicking lets me advance through the newsgroup article by article, marking articles as having been read as I download and read them. I can also compose and post followup articles or new articles, which are uploaded to the Usenet news server immediately. If I don't read all articles in a newsgroup or get through all newsgroups, I can look at them later when I next use NewsWatcher. I can also mark articles as having been read without downloading them, in case the subject line indicates that I would likely have no interest in them. Thus far in this example I've discussed electronic mail (Eudora), Telnet (NCSA Telnet), FTP (Fetch), and Usenet News (NewsWatcher). I also have TurboGopher, a Macintosh version of a Gopher client. TurboGopher allows me to get exactly the same information accessible via a so-called "VT100" Gopher client (as found on many Internet hosts), but with the following advantages: it gives me a point and click graphical interface; files can be saved directly to my Mac (as opposed to saving them in a host UNIX directory and then downloading them); and it doesn't require me to login to a UNIX host first. Finally, I have the much-heralded NCSA Mosaic (the Macintosh version, of course), and can explore the World Wide Web with full access to multimedia information including formatted text, graphics, sound, etc. I must confess that using Mosaic over a 14.4 kbps dialup line is not nearly as exciting as the hype would suggest. Mosaic typically takes a minute or more just to bring up a single page of information, because of all the embedded graphics included in most WWW data. (You can tell Mosaic not to download the graphics images, but then what's the point?) I've accessed sound clips once or twice; it takes about five minutes of downloading just to hear my Mac talk to me for a few seconds. Overall, using Mosaic over a 14.4Kbps connection can be as frustrating as trying to eat ice cream through a straw; but it's still fun to play with, and there are many new information sources that can be accessed only through the World Wide Web and a WWW client program like Mosaic. While all this is happening TCP/IP and SLIP are still running quietly underneath it all over the dialup link. After a while I figure it's time to save my pennies and cut the connection. (I get four "free" hours per day--i.e., included in my basic monthly rate--but these can go fast, especially as I connect at least two or three times a day. My provider charges $1 per hour for each additional hour.) I remember I still have electronic mail messages in my Eudora outbox, so I go into Eudora and tell it to send all outgoing mail. It uploads the messages to my Internet access provider's mail server, which then will take care of sending them on to their final destination. Having finished all my online stuff, I go back to the SLIP application and tell it to disconnect. At that point I lose all the fancy functionality like Mosaic, FTP, etc. However I can still read my electronic mail in Eudora, compose replies, and queue them for delivery the next time I connect. In summary: * I have dialup Internet access using a special dialup number and a userid and password associated with that access. * I can run a wide variety of applications over the dialup link to implement traditional Internet services such as electronic mail, FTP, Telnet, and Usenet news, as well as newer services like Gopher and Mosaic/WWW. * Using some Internet services (e.g., electronic mail) requires that I have additional userids and passwords assigned to me by my Internet access provider. Others do not; that is, they are either inherently anonymous in nature (e.g., anonymous FTP, Gopher, Mosaic/WWW) or involve separate arrangements with other organizations (e.g., Telnet to a remote Internet host like CapAccess). * Most of these services can only be used while the dial-up Internet connection is active. However with others (really only electronic mail, for now) you can do at least some things off-line. (There's no reason in theory why some of the Usenet news reading process couldn't be done offline; however the current version of the NewsWatcher application does not implement this.) How It All Works Having told you how I access the Internet from my Mac, I'd like to now go into more detail about what's going on behind the scenes. My apologies for the level of technical detail; I'll try and keep it to the minimum necessary to make my points. (Although I can't resist running with a good extended analogy, as you'll see.) Let's start with what "being on the Internet" really means. For your PC or Macintosh to be "on the Internet" in the sense that I'm using the term, the following three things must be true: * Your PC or Mac has software which can send and receive data using the TCP/IP family of communications protocols. * Your PC or Mac has some sort of communications link to an Internet access point from which data it sends can go out over the Internet to other systems, and by which data sent from other systems on the Internet can be sent to your PC or Mac. * When connected in this way, your PC or Mac has an identifying number (called an "IP address") which other systems use in sending data to your PC or Mac, and by which your PC or Mac identifies itself when sending data to other systems. For those who really want to know, "TCP/IP" stands for Transport Control Protocol/Internet Protocol (which are really two separate protocols that work together), and is a shorthand name for a specific way of packaging up data for sending it over a comunications link. TCP/IP is analogous in many ways to protocols like Kermit or Zmodem which package up data for downloading or uploading over "normal" dial-up connections (e.g., to a BBS). But you really don't need to know that, any more than you need to understand how telephone line signalling works in order to call someone. In fact, this is a good analogy if you think about what it means to be "on the public telephone network" and use local or long-distance phone service: * You have a device (i.e., a telephone) which can send and receive data (i.e., the sound of voices) using some sort of low-level magic (which you don't really worry about). * Your phone has a communications link (phone line) to an access point (your local telephone central office) through which your phone can connect to other phones anywhere in the world (and vice versa). * When connected in this way, your phone has an identifying number (your phone number) which other phones use in connecting to your phone, and by which your phone is identified when connecting to other phones (as in Caller ID). The three elements common to both cases are thus as follows: * you have an end-user device which has the smarts to "talk" in a certain way; * you have a link to an access provider over which your device can "talk" with other devices; and * your device has an identifying number or address used when your device "talks" to other devices and vice versa. If it's that simple, why has connecting to the Internet traditionally been so hard for individual users? Because doing it has been like trying to get phone service in an environment where you have to build your own phone, you have to search far and wide to find a phone company (and may not have one at all in your area), and you have to pay a big premium for service if and when you find a service provider. Making Your Mac or PC Internet-Capable Let's go back and analyze what's happening when I use my Mac on the Internet. First, let's discuss what you need to make your PC or Mac Internet-capable, "building a phone" as it were (and we'll price it out to boot). I started with a Macintosh system with a 14.4 Kbps modem. Assuming that you already have a PC or Mac, you can add a new 14.4 Kbps modem for as little as $100 to $150 (US) or so, depending on the modem's brand, whether the modem is external or internal, and so on. For example, I recently bought a Pratical Peripherals 14.4 Kbps external modem for $140; four years ago I paid almost $500 for an earlier Practical Peripherals modem that only supported 9.6 Kbps. To that I added the requisite TCP/IP software. For Macintoshes this comes in two parts: First comes a product called MacTCP supplied by Apple; MacTCP is the standard TCP/IP product for all Macs. Then comes software to implement either the SLIP or PPP protocols that MacTCP needs to support TCP/IP over dialup links. I use the InterSLIP software from InterCon Systems Corporation; InterSLIP is freeware. MacTCP is not freeware, but you can get it (along with InterSLIP and related stuff noted below) by buying the book "Internet Starter Kit for Macintosh" by Adam Engst. (See the end of this document for a list of references.) Also, Apple will be including MacTCP in the upcoming System 7.5 operating system (to be released later this year). After its release System 7.5 will be shipped with all new Macs, so at that point you'll get TCP/IP software on new Macs at no extra cost whatsoever. (You'll be able to get it for old Macs by buying System 7.5 separately.) For 386 or better PCs running Windows 3.1 you can get a similar combination of TCP/IP software with SLIP capability by buying Engst's companion volume for Windows or similar works. (Again, see the end of the document for references.) The software in this case is a entry-level version of Chameleon from NetManage. (A shareware product, Trumpet Winsock by Peter Tattam, is also available, and many people prefer it.) In the next major release of Windows (Windows 4.0 or "Chicago") Microsoft will be including TCP/IP and PPP capability in the base operating system at no extra cost. At that point you'll get TCP/IP software at no extra cost if you buy a PC with Windows 4.0 preloaded. (You'll be able to get it for older PCs by buying Windows 4.0 separately.) I should add that the cheapness of (commercial) TCP/IP software for Macs and PCs is a very recent phenomenon. Traditionally TCP/IP software has been seen as of interest only to businesses running in-house local area networks, and it cost as much as $400 or $500 per PC or Mac. TCP/IP software is still this expensive in many cases if you need true LAN capabilities, but software vendors have woken up to the rapidly growing market for individual use of TCP/IP over dial-up lines to access the Internet. Thus many commercial TCP/IP software packages have dropped in price to less than $100, at least for basic capabilities. As noted above, within the next year or so this cost will drop further to zero; that is, at some point TCP/IP and SLIP or (more likely) PPP capability will be bundled with the base operating system software shipped with every new Windows PC and Mac. At that point the only incremental cost to make your PC or Mac "Internet-capable" will be for the modem itself, which many if not most people who buy computers will be buying anyway for other reasons--for example, to connect to BBSs or to commercial online services such as America Online, CompuServe, and Prodigy. Some final notes on software compatibility: There are a number of potential compatibility problems in configuring software "stacks" consisting of the base TCP/IP software, network drivers underneath, and Internet applications on top; this has been especially true when mixing and matching software from different sources. Fortunately these problems are not really an issue in the Macintosh world, and are rapidly becoming a thing of the past in the PC world (at least for people using Windows). As noted above, in the Macintosh world Apple is the only major supplier of the basic TCP/IP software, in the form of the MacTCP product. All Macintosh Internet applications are thus written to interface to the MacTCP software, so compatibility problems are kept to a minimum. Most of the problems that do occur are connected to the particular revision of MacTCP being used with a given application on a given Mac; almost all current Mac Internet applications work best with the current 2.0 revision of MacTCP. (The latest revision at the time of writing is 2.0.4.) In the Windows world the compatibility problem has not yet been totally solved, but has been to a great degree addressed by the development of the "Windows Sockets" or "Winsock" standard and the implementation of TCP/IP products that conform to it. The Winsock standard specifies the interface between Windows-based Internet applications (e.g., Telnet and FTP) and the TCP/IP software underneath them. Thus for example, since NCSA Mosaic is a Winsock-compliant application, you can run it over either NetManage's Chameleon TCP/IP software or Peter Tattam's Trumpet Winsock software. Both these products provide a WINSOCK.DLL run-time library that implements the Winsock interface; the WINSOCK.DLL file is different for each TCP/IP product, but the interface provided to applications running above the TCP/IP software is always the same--at least in theory. Connecting to the Internet As described above, I first made my personal computer Internet-capable ("built my phone") by installing the proper TCP/IP and SLIP software on my modem-equipped Macintosh. (I later installed comparable software on my PC as well.) Next I signed up with a service provider that could give me a connection to the Internet (in my case the D.C.-area company Digital Express Group, Inc.). My Internet access provider supplied me with at least three things (actually more, but we'll get to that): a dial-up SLIP access phone number to have my modem connect to, a personal "SLIP userid," and a personal password to go with the SLIP userid. The SLIP userid is some arbitrary string like "xx537", and the password is like a standard login password for a UNIX system or BBS. I configured the InterSLIP software with the dial-up SLIP access phone number and my SLIP userid, and now direct the software to call up the SLIP phone number using the Mac's 14.4 Kbps modem. The call is answered by a corresponding 14.4 Kbps modem at the other end (like the ones used by BBSs). That modem is connected to a SLIP-capable "terminal server," a black box that takes the data coming from my Mac over the dial-up line and retransmits it to my Internet access provider's local area network, which is in turn connected to the Internet using an "IP router" (another black box you don't have to worry about). This terminal server is similar to the ones used on many college campuses and at many Free-Nets and other community networks like CapAccess to connect users from dial-up modems over a LAN into the actual UNIX host system they login to. The main difference is that the SLIP-capable terminal servers at the Internet access provider have an extra capability which lets them pass "raw" TCP/IP data through. (Access using PPP is similar.) In fact, when you first connect to the Internet access provider's modem and terminal server, it looks very much like logging in to a remote UNIX system. (That's if you were looking at the conversation, which typically you don't--login is normally handled by an automated script). The first thing you would see is a prompt for a userid, at which point you (or the script) enter the special SLIP/PPP userid. You would then see a password prompt, in response to which you (or the script) enter the SLIP/PPP password. (The SLIP or PPP software would prompt you for your password if you hadn't supplied it with the rest of your configuration information.) On a BBS or UNIX system you'd next see the opening screen and menu (or a UNIX prompt). However with a SLIP or PPP connection your software and the terminal server now go into a special mode where they start exchanging TCP/IP data. This is somewhat reminiscent of what happens when a communications program is in download or upload mode, and if you looked at what's actually going across the dial-up line it would look pretty much like garbage with a few recognizable bits mixed in. However you don't actually see the garbage because the SLIP or PPP software doesn't bother showing it to you; it just says "connected" and that's it. A couple of important points to note: First, having made the SLIP or PPP "connection" you really aren't logged in to any host; you just have the capability to send data out over the Internet. To continue with our telephone analogy, you've plugged in your "phone" and have "Internet dial tone" but you haven't called anybody yet. You might ask, why do you need a userid and password if you're not actually logging in to anything? Because my Internet access provider wants to be able to bill me for the time I spend connected to the Internet through their terminal server, and to do this they need an id of some sort to know that it's me connecting. I in turn would like a password so that no one else can connect to their SLIP/PPP terminal server and bill time to my id. You can think of this as my "Internet calling card number" and associated Personal Identification Number or PIN. For those really into the bits and bytes, an interesting technical question is: How does the SLIP/PPP terminal server check my userid and password and then account for my connect time? The answer is that it either checks my userid and password against an internal database held in non-volatile memory on the terminal server itself, or it sends the userid and password to a real computer system to be checked against a userid/password database on disk. (For many modern terminal servers this can be done using the Kerberos authentication protocol invented at MIT.) If the SLIP/PPP userid checks out, the terminal server (if it has this capability) then sends a "start of call" record to a real computer system to be stored in a log (many terminal servers use the UNIX "syslog" protocol for this); a similar "end of call" record is sent when the modem connection ends (i.e., the user disconnects). These two records together enable the Internet access provider to compute the time and length of the SLIP or PPP session for billing purposes. Again, this is all quite similar to the way long-distance calling cards work. The analogy extends even further: if I always made the connection from the same phone, my Internet access provider could theoretically use Caller ID or similar mechanisms to know it was me calling, just as I don't have to enter a calling card number to dial long distance from my home phone. However, just as I might make long distance calls while on the road, I might connect my modem to different phones (and in fact I do, as my Mac is actually a PowerBook laptop); thus having a separate SLIP/PPP userid and password is necessary to handle this. There's another crucial piece I've left out so far: my "Internet phone number," the IP address. In my case my Internet access provider assigns me my very own IP address (mine is 164.109.211.201, in case you're curious); this is the fourth piece of initial information I was given when I signed up, along with the three I've already mentioned: SLIP/PPP dial-up access number, SLIP/PPP userid, and SLIP/PPP password. Many terminal servers also have the ability to assign callers an IP address "on the fly;" the address picked is displayed during the login sequence and the TCP/IP software on your PC or Mac then picks it up and uses it. When you dial up the next time, you might get a different IP address. This is not as confusing as you might think, as it turns out that for various reasons (touched on later) it really doesn't matter what your IP address is, as long as you have a valid connection. The theory behind doing this dynamic assignment of IP addresses is that it lets the Internet access provider use a limited-size pool of addresses to serve a much larger number of people. After all, people only need the address when they're connected to the modems and SLIP/PPP terminal server, so the Internet access provider really doesn't need to supply any more IP addresses than it has dial-up SLIP/PPP ports. However I prefer the way my Internet access provider does it. For one thing, it's much easier to understand, especially using the phone number analogy. For another, the IP address is often used by remote systems to identify who's connecting to them over the Internet, just as people use Caller ID to identify who's phoning them. (Using the IP address for authentication in this way is not totally secure and fool-proof, but then neither is Caller ID for that matter.) With "on the fly" assignment I might get a given IP address at one point, and after I disconnect from the service someone else could get the same address a few minutes later. To summarize: after signing up with an Internet access provider and connecting to their SLIP/PPP terminal server we're now "on the Internet" (or we have "Internet dial tone" if you will), having fulfilled the three conditions we discussed above: * With the help of a modem and low-cost TCP/IP software we have an "Internet-capable" PC or Macintosh. * We've established a TCP/IP over SLIP (or PPP) connection to our Internet access point. * We've got an IP address or "Internet phone number" and are ready to "make calls;" i.e., to connect to other systems and make use of Internet services. This has been a long section and we still haven't gotten to the point of doing anything really useful. But have patience; believe me, even telephone dial-tone would seem this complicated if you really looked "under the covers." In fact, just a few years ago (before "equal access") getting long-distance phone service in the U.S. through a non-AT&T carrier such as MCI was also pretty complicated; some may remember when you always had to dial a special access number and enter your personal access code before you could dial a long-distance number using a long-distance company other than AT&T. Using Core Internet Services At the end of the last section I'd gotten to the point where my computer had "Internet dial tone:" it had established a TCP/IP link to the SLIP/PPP terminal server of my Internet access provider, and was now ready for me to do useful work (or "make some calls," to continue our telephone analogy). The first thing I did in my example was to check my electronic mail, and so I started the Eudora mail program. Eudora is available for both Macs and PCs running Windows. In its first incarnation (release 1.4) it is a freeware program; I got my copy from Adam Engst's "Internet Starter Kit" book. Eudora is now also available in a commercial version (release 2.0) with somewhat more functionality (like mail filters) and official technical support; I recently bought a copy of release 2.0 for $65 from QUALCOMM, the vendor that now sells and supports it. However, before I explain how Eudora works, I have to digress for a moment and talk about Internet electronic mail. Traditionally Internet users have logged in to multi-user systems which were connected to the Internet 24 hours a day. When users send mail (say from "jdoe@cap.gwu.edu" to "rroe@agency.gov") the messages are transmitted (almost) immediately over the Internet from the originating host ("cap.gwu.edu") to the receiving host ("agency.gov") and then are put in the mailbox for the recipient ("rroe"). (Incidentally, the low-level protocol used to send messages between Internet electronic mail hosts is called SMTP, for Simple Mail Transfer Protocol.) At some later time the recipient ("rroe") logs into the receiving mail host and then reads the mail messages out of their mailbox using a mail program such as Pine or Elm. They can also compose new messages, which are then sent to the recipient's mail host as described above. Note that the user has to stay logged in to their mail host during the entire time they're reading messages and composing new ones. This method is the way I used to read and compose mail using my original Internet shell account: I would login to my Internet access provider's host system ("access.digex.net") and use the UNIX-based mail program Pine to read and respond to electronic mail. However, now that I have a computer which can be linked to the Internet more directly, I would much prefer to read and compose mail on the Mac itself and send it or receive it over the Mac's Internet connection. As in the example above, my Mac does have its own Internet address ("164.109.211.201") and even its own Internet hostname ("ion.digex.net"). (I'll discuss how Internet hostnames work in more detail below when I talk about FTP.) Unfortunately, though, I can't use the traditional SMTP mail protocol, at least to receive mail. Why? Because mail sent using SMTP is sent directly to the recipient host, which in this case would be my Macintosh ("ion.digex.net"), and my Mac would have to be on the Internet to receive it; otherwise the sending host would not be able to make an SMTP connection. But because I'm using an intermittent dial-up SLIP/PPP connection, there's no guarantee that my computer would be online at the exact time the sending host wanted to send the message, and thus I would end up never receiving messages sent to me. Going back to our telephone example, sending Internet electronic mail in the traditional manner (i.e., using SMTP end-to-end) is somewhat like leaving a message for someone on their personal answering machine: you can call their phone number 24 hours a day, and their answering machine is always turned on and ready to record messages. But in my case my "Internet phone number" (IP address) is only active part of the time (when I'm connected to my Internet access provider via SLIP or PPP and have "Internet dial tone") and my "personal answering machine" (my Mac) won't always be turned on and ready to receive my messages. The solution to this problem is very simple: I'll have another Internet-connected system (a "mail server") receive my email messages for me, and then when I'm connected to the Internet I'll download my mail messages from that system to my Mac. Continuing the answering machine analogy, this arrangement is similar to what phone companies provide via services like Bell Atlantic's Answer Call; in place of your having your own answering machine, the phone company provides a voice mailbox for you somewhere in their network, and callers to your number can leave messages in that voice mailbox. You can then periodically call a special phone number associated with the voice mailbox service, punch in your access code, and listen to your messages. In my case, rather then sending email to "hecker@ion.digex.net" (recall that "ion.digex.net" is the hostname of my Macintosh), people send email to "hecker@access.digex.net", where "access.digex.net" is the name of the mail server run by my Internet access provider; this system runs 24 hours a day and has a permanent Internet connection. Once I dial up my Internet access provider and my SLIP connection is active, I then have Eudora connect to the host "access.digex.net" over the Internet and download any messages I've received since last I connected. The specific protocol used to do this is _not_ SMTP, but is another protocol called Post Office Protocol or POP. In particular Eudora and the "access" system use POP3, the third and most recent version of this protocol. In technical jargon the system "access.digex.net" is thus a POP3 mail server. I didn't mention it above, but I also have to supply Eudora with a userid and password, which it then passes on to the mail server when connecting to it using POP. If there were no userid or password, then anyone else on the Internet could connect to my Internet access provider's mail server and download my mail. As it happens, my "mail userid" and associated password are the same ones I used to use when logging in to the "access" system itself as a user of an Internet shell account, namely "hecker" and the corresponding login password. This makes for a smooth transition from the old way of doing things (using a shell account) to the new way (using SLIP/PPP): my electronic mail address is still "hecker@access.digex.net" (userid "hecker" on host "access.digex.net") and I don't have to choose a new password if I don't want to. Also, if I ever want or need to I can still dial up the "access.digex.net" system in the old way (i.e., using a VT100-compatible communications program instead of SLIP or PPP) and login and read my mail using Pine. (The mailbox format used by POP is the same standard UNIX mailbox format used by Pine, Elm, and other host-based mail programs.) However, my mail userid and password are _not_ the same as my SLIP/PPP userid and password that I've previously mentioned; this is because we are talking about two fundamentally different services provided in two fundamentally different ways. SLIP/PPP access is a low-level communications service accessed by dialing up a SLIP/PPP-capable terminal server; POP email access is a higher-level service accessed by connecting over the Internet to a POP3-capable host system (mail server). Thus if you get a new SLIP or PPP account from an Internet access provider you'll receive an email (POP) userid and password in addition to your SLIP/PPP userid and password. (There are exceptions to this. Some smaller Internet access providers do not have separate terminal servers, but rather connect modems directly to serial lines on their UNIX host systems, and support SLIP or PPP access using software running on those systems. In this case a user--or more correctly, their SLIP software executing an automated login script--would login to the host system using a single userid and password, and would then invoke a special SLIP or PPP function to convert the session into a SLIP or PPP connection. Eudora or other POP3 mail programs would use this same userid and password to download mail.) Suppose that I had a full-time hard-wired Internet connection in my home (for example, like those starting to be provided by some cable companies). I could then have "Internet dial tone" all the time, and I wouldn't need something like SLIP or PPP to connect. I also wouldn't need the equivalent of a SLIP/PPP userid and password; as I discussed previously, their main use is for authentication and billing for Internet access, and the cable company already has a perfectly good way to bill you for cable-based services. However I might still want the cable company to store my incoming electronic mail messages for me; for example, I might not want to keep my computer turned on all the time. In this case I could use Eudora and POP to connect to a remote mail server, just as I do now over SLIP or PPP, and I would still have to have a mail userid and password supplied to me by the cable company in its role as an Internet access provider. Continuing the answering machine analogy, having an electronic mailbox accessed using POP can thus be viewed as a value-added option to a basic Internet connection, just as having a voice mailbox through Bell Atlantic's Answer Call is a value-added option to a basic phone line. This also implies that email service could be "unbundled" from basic Internet service; for example, you might have a basic Internet connection but no electronic mail service, or (more likely) you might get basic Internet service from one service provider and an electronic mailbox service from another. (As it happens, I don't know of any Internet access provider that currently unbundles POP-based email in this way. However as competition heats up in the Internet access market, some companies may choose to further break their current services down into standard and optional offerings, in order to offer the lowest entry-level price possible. There may also be a market niche for companies providing SLIP/PPP service only, with customers expected to arrange for electronic mail service on their own; some non-profit Internet cooperatives do business this way today.) Back to Eudora: As I've mentioned, once Eudora has downloaded my incoming email messages to my Mac I can then read them at my leisure; I don't need to maintain the Internet SLIP connection. What about sending messages? Here again I don't need to be connected in order to compose messages, but (it almost goes without saying) I do need to be connected in order to send them. As it turns out, for historical reasons (a fancy way of saying "that's just the way it is") the POP protocol is not used when sending electronic mail messages. Instead Eudora uses the SMTP protocol I discussed earlier, but with a twist. In "SMTP classic" the sending host (my Mac in this case) connects directly to the receiving host (say "whitehouse.gov", if I'm sending a message to Bill Clinton). However the receiving host might be down or unreachable due to some Internet problem, so that Eudora would have to postpone sending the message to a later time, say a few hours later. But why should I have to go to all the trouble of remembering to reconnect periodically to my Internet access provider? Instead what happens is that Eudora uses the SMTP protocol to send my message to my mail server. The server then uses SMTP again to send the message on to its final destination. If the mail server can't do so right away it will keep trying until it succeeds; meanwhile I can disconnect my Mac and not worry about it. You may have noticed that I didn't say anything about userids and passwords when sending mail. That's because the mail server doesn't authenticate me in any way when sending mail via SMTP; I just tell Eudora to upload the message and the email server accepts it. You might then ask, "Doesn't this mean that someone else can send fake electronic mail under your name?" For this and other reasons, the answer is yes, they certainly can. As it happens, it is almost trivially easy to send forged Internet mail, and has been ever since Internet mail began. This is why, for example, you should be very skeptical if you ever get a message purportedly from your Internet access provider telling you that they need to know your userids and passwords for some reason. There are well-known ways to solve this problem, but they haven't been implemented because they depend on encryption and related technologies, and implementation in the Internet has been held hostage to the same sort of disputes we've seen in the infamous "Clipper chip" controversy. (I don't want to rehash this whole issue here, but I do want to point out the basic underlying problem. In the "market" that is the Internet, the most successful "products" are based on technology that is available worldwide and is in the public domain or otherwise freely usable. Exporting encryption technology from the U.S. is legally restricted because of national security concerns, and "public key" encryption, the most useful type for electronic mail, is covered by a software patent in the U.S. Thus there are at least two major obstacles to creating a world-wide standard for secure Internet mail--yet another example of how once obscure policy questions can eventually come to affect all of us.) That's about it for electronic mail. The case of Usenet news (online conferences) is somewhat similar, and worth covering at this point. Again, we need to digress for a moment and talk about how Usenet news works underneath. Usenet is not a communications network per se but rather a loosely-organized collection of host systems which exchange conference articles with each other. (In this sense Usenet is analogous to FidoNet in the PC BBS world, and in fact there are gateways between Usenet and FidoNet.) When a conference article is submitted (or "posted") on one system it is then sent on to one or more other systems, which then send it on to others, and so on (rather like a chain letter), until all Usenet hosts receive it. Once an article is received at a host it is stored for people to read it. There are a few thousand Usenet conferences (or "newsgroups") and several thousand Usenet hosts around the world. Thus as you might imagine a lot of traffic flows through the system every day, so much so that a Usenet host system typically stores only the last few days worth of articles. If I want Usenet access from my personal computer I thus have at least three possible ways to get it. First, I could have my computer be a full-fledged Usenet host and receive all conferences; this is pretty much out of the question in my case, given that it's hard to fit several gigabytes of disk space in a laptop. Second, I could have my computer be a Usenet host but receive only a few newsgroups; this is a much more reasonable thing to do, and you can get software for both Macs and PCs to do it, but you'd still be receiving every article in every newsgroup you chose to receive, even articles of little or no interest to you. The third alternative is what I use with my Mac and NewsWatcher: connect to a remote Internet host acting as a "news server;" this host ("news1.digex.net" in my case) receives all Usenet newsgroups and stores all articles for as long as it can without running out of disk space. Assuming that I have an Internet SLIP/PPP connection active, I then have NewsWatcher connect to the news server over the Internet and download the list of articles (i.e., by subject line) in each newsgroup. I then pick which articles I want to read and have NewsWatcher download only those articles; the rest are left unread on the news server. Conceptually this process is quite similar to using a POP mail server as described above. As with mail there is a special protocol, NNTP (Network News Transfer Protocol), which NewsWatcher and the news server use to talk to each other. However I don't have to supply a userid or password when reading and posting news. I do have to tell NewsWatcher my email address ("hecker@access.digex.net") because this is used to mark my posted articles as coming from me, and is also needed when I send mail to someone in lieu of posting a reply to the newsgroup. However this information is not used to authenticate me to the news server in any way. You might ask, can anyone on the Internet then use NewsWatcher (or other NNTP client programs) to read and post articles from and to my Internet access provider's news server? There are some news servers on the Internet for which this is true; using these "public NNTP sites" anyone can read or (in some cases) post Usenet news articles. (And I might add, using these servers as well as through other means it is possible to send forged Usenet postings under another's name, similar to what can be done with Internet mail.) However my Internet access provider's news server will not accept requests from anywhere on the Internet; it will only accept requests from IP addresses and hostnames that it knows about, that is, those that represent valid subscribers to the provider's SLIP or PPP service. Since my Mac has an IP address and Internet hostname assigned by the Internet access provider when I signed up, the provider's news server will recognize me as a valid user. Thus IP address and hostname are again used as a useful (albeit not totally secure) means of authenticating users. The final point I want to make about Usenet news is that, like access to a mail server, access to a news server is a value-added service over and above basic SLIP or PPP Internet access and could in theory be unbundled as well, so that you might have a basic Internet connection with no mail or Usenet news service at all, an Internet connection and mail service but no Usenet news service, or Internet service, mail service, and news service from one, two, or even three providers. (Again, most present-day Internet access providers do not in fact unbundle services in this manner.) Accessing Other Internet Services With both electronic mail and Usenet news it's not enough just to have a SLIP or PPP Internet connection; you also need to have access to a special Internet host or hosts acting as mail or news servers respectively. This access is usually prearranged with some organization, typically the Internet access provider itself. However there are a wealth of other services for which you need only a basic Internet connection. The first example is using anonymous FTP to download information files or shareware. On my Mac the Fetch program (which implements FTP) simply asks me for the name of the host I wish to connect to. Some magic then happens to convert the host name to an IP address (analogous to looking up a phone number) and the connection is made, after which I can download files. The FTP site doesn't ask for an individual password, and doesn't really care who I am. Well, this is almost true. First, all FTP sites ask for some sort of password even if they don't care what it is, and for anonymous FTP sites Fetch will send your email address (e.g., "hecker@access.digex.net") as the password as a courtesy in case the FTP site is logging access for some reason and wants to record this information. Second, as a mild security measure many FTP sites will check to make sure that the IP address from which you're connecting (e.g., the IP address of my Macintosh) matches the Internet hostname associated with the IP address. In telephone terms this is like getting the phone number of a caller via Caller ID and then looking in a reverse or "criss-cross" directory to find out their name. This is probably a good place for a brief digression on Internet hostnames. As implied earlier, Internet hostnames (like "cap.gwu.edu") are to IP addresses ("128.164.140.32") as people's names are to their phone numbers, and in fact there is a "directory assistance" service to do automatic lookups of IP addresses for a given hostname and vice versa. This automated service is referred to as Domain Name Service or DNS, and is silently invoked by my Macintosh every time I give it an Internet hostname to connect to. The lookup is done by querying a special Internet host called a DNS name server; in my case this server is one maintained by my Internet access provider, and its IP address is yet another of the pieces of configuration information I get when I sign up for SLIP or PPP service. Besides letting me (or more properly, my Macintosh) look up IP addresses automatically, my Internet access provider's DNS name server also maintains entries listing the Internet hostname and IP address of my Mac. This lets remote systems like anonymous FTP sites do the sort of checks I briefly mentioned above. Other than that my Mac's hostname ("ion.digex.net") isn't used for much, as email for me is sent to the mail server's hostname ("access.digex.net") instead. Like directory assistance, DNS name service is essential but fundamentally uninteresting (unless you need to use it and it's not working). It is usually provided by the Internet access provider as a part of basic Internet service and is not really a good candidate for unbundling. (However many Internet access providers do provide an extra cost service whereby you can choose your own personal customized hostname, like "hecker@my-company.com".) Continuing on, Telnet from my Mac works similar to FTP: I tell the NCSA Telnet application the hostname I wish to connect to, it does the silent DNS lookup to find the IP address, and then connects me directly over the Internet to the remote system. The only userid and password required is whatever the remote system might ask for; some Telnet-based services use a dummy or "guest" userid and password, or even no userid or password at all. Connecting to a UNIX system via Telnet normally looks almost exactly like connecting via a dial-up line. Connecting to more exotic systems like Multi-User Dungeons or MUDs is very similar (and typically uses Telnet or a Telnet-based protocol underneath): you supply the hostname you wish to connect to, you connect, you sign on in some way, you type at the system, you get responses back, you repeat until you're done, and then you logoff and disconnect. The underlying SLIP or PPP Internet connection must be active during the entire session, which may range in time from a few minutes to several hours (or even days, in the case of particularly enthusiastic MUD fans). Gopher and Mosaic/WWW are a little more complicated in the way they work. When I start up either TurboGopher (for Gopher) or NCSA Mosaic (for World Wide Web) they attempt to connect initially to a preset "known host" (or hosts, if alternates have been set up); for Gopher this host is at the University of Minnesota and for Mosaic at the National Center for Supercomputing Applications at the University of Illinois Urbana- Champaign. (Both Gopher and Mosaic can be changed to connect to other initial hosts, or even to not connect to a host at all. However in the case of Mosaic at least it is not necessarily immediately obvious how to reconfigure the software to do this. This is a shame, as the NCSA host is now getting bogged down by all the copies of Mosaic connecting to it every time a new user invokes the program.) Once connected to the initial host, TurboGopher or NCSA Mosaic operate in a true "client/server" fashion: the client (i.e., the program running on the Mac) sends a request over the Internet to the server (the program running on the remote host), which in turn sends back a response. All this happens invisibly underneath using a special-purpose communications protocol (Gopher+ for Gopher and HTTP or HyperText Transport Protocol for Mosaic/WWW); all you see on the screen is a graphical "point and click" interface like that characteristic of other Mac- or Windows-based programs. If you pick an item from a Gopher menu or choose to follow a hypertext link in Mosaic then one of three things may happen: you may get a menu ("page" in WWW jargon) on the same system, you may get a menu (page) actually stored on another system, or you may invoke an item that does something other than just go to another menu or page. The first case is not that interesting, so we'll skip it. (It's actually a special instance of the second case.) In the second case, for menus (pages) served by another system on the Internet, TurboGopher or Mosaic automatically reconnect to the new system and send the proper low-level commands to retrieve the menu (page) being invoked. As you browse through the menu hierarchy (or the hypertext tree) the Mac programs automatically switch from system to system as needed, so there is no one system to which TurboGopher or Mosaic are "connected". In the third case, when a user invokes a menu item or clicks on a hypertext link, some special action may be performed. One very common action is to initiate automatic downloading of some file. This is implemented essentially by having FTP-like functionality built into TurboGopher and Mosaic, so that by invoking a Gopher or Mosaic item you can fetch any file retrievable via anonymous FTP. If the file is of a special type TurboGopher and Mosaic can do also something special with it. For example, if the file were a graphics image in GIF format then after downloading is complete TurboGopher or Mosaic would try to invoke a GIF viewer to show you the file. (Of course, you must already have GIF viewer software on your system, and you must have made sure that TurboGopher or Mosaic are configured to use it.) There are lots of other interesting features of Gopher and Mosaic/WWW; however, the most important thing to remember is that, unlike mail and Usenet news, you don't have to have anything to use Gopher and Mosaic/WWW except the Internet connection itself. Summary It's been a long and tangled path thus far, and thank you for sticking with it. Here are the key points I'd like you to take away from this paper: * You can take a Macintosh or a 386 or better Windows-based PC that already has a modem and for a relatively small one-time expenditure (under $50 for TCP/IP and SLIP or PPP software) make it capable of being a full-fledged Internet node. * For an expenditure of between $10 and $40 per month in the U.S. (depending on your location and the amount of competition in your market) you can sign up with an Internet access provider who will let you connect your PC or Mac to the Internet on an on-demand, dialup basis. What you get for your money is an Internet hostname and IP address (with a directory entry for your system maintained by DNS), a number to call for SLIP or PPP access, and a special SLIP/PPP userid and password to authenticate you and allow your connect time to be tracked. (Note that if your Internet access provider assigns IP addresses "on the fly" then you won't get a hostname or IP address of your own.) Your provider should also supply you with some other miscellaneous configuration information as well, most of which is pure gobbledegook and is needed only when you first configure SLIP or PPP (but is very important at that time). * With just the basic dial-up Internet SLIP/PPP service you can use FTP clients like Fetch to download files, Telnet programs like NCSA Telnet to login to remote systems, Gopher clients like TurboGopher to access Gopher servers, and WWW clients like NCSA Mosaic to access World Wide Web servers. * If your Internet access provider also runs a POP mail server (as almost all do), you can have the mail server receive mail for you and then use an email program like Eudora to download it when you're connected, for you to read and respond to offline. Your provider will supply you with a mail userid and password to do this; authentication is done by the mail server. * If your Internet access provider also runs an NNTP news server, you can use a Usenet news reader such as NewsWatcher to connect to the news server, select interesting Usenet news articles, and download them for reading. You can also post new articles or follow-ups to old articles. The news server will authenticate you (if necessary) based on your IP address and hostname. * In theory electronic mail and Usenet news services could be unbundled from basic Internet access ("Internet dial tone"). This is rarely seen today but may become more common as the market for personal Internet access evolves. Note that a higher-speed dedicated Internet connection, via cable for example, would work in a similar manner. The major difference would be in the first two items. First, for a high-speed connection your PC or Mac would not use a modem but rather something like an Ethernet controller board, which typically runs about $100 to $200 on up. (This might hook up to a "cable Ethernet" connection located on your set-top box.) Second, with a dedicated connection there would be no need for an equivalent of the SLIP/PPP userid and password, as the cable company could simply bill you monthly as it does today for cable service. Everything else would work exactly the same way, only faster; the applications software itself (e.g., Eudora, NewsWatcher, TurboGopher, NCSA Mosaic, etc.) would stay the same and would be configured the same. (Whether a TCP/IP connection uses SLIP, PPP, Ethernet, or any other network technology is essentially transparent to the user application.) I should add that typical "Internet over cable" technologies support a high "downstream" bandwidth (i.e., to the home) but a slow "upstream" bandwidth (i.e., to the cable company headend and thence to the Internet). They are thus ideally suited for applications like Mosaic, where you typically download to your PC or Mac a great deal of data in the form of graphics images, sound clips, etc., with only a few bytes of commands going the other direction back to the World Wide Web servers. As a result, "Internet via cable" may be the next frontier for power users currently enjoying the benefits of SLIP and PPP dialup access. Where to Go from Here After reading this paper I hope you now have a good feel for how SLIP and PPP Internet access work, and as a result you may be interested in finding out more and possibly even acquiring your own SLIP or PPP connection. This section covers three possible avenues you might explore: * commercial SLIP/PPP Internet packages * Internet books with bundled software * online information and freeware/shareware Each option has its pros and cons; unfortunately no one has yet come up with a single complete "A to Z" solution for personal Internet access that provides everything you'll need and answers every question you might have. However the range of available information, software, services, and support is much greater today than it was even six months to a year ago, and I expect this trend to continue and even accelerate. As a result this section will likely grow out of date very rapidly; however I hope it provides at least a starting point for you. Commercial Internet Packages You may wish to buy an commercial "all in one" solution that includes TCP/IP and PPP or SLIP software, a range of Internet applications, documentation, and (optionally) Internet service itself. Here's some of the questions you should ask yourself in evaluating the purchase of a commercial product: * Does the product provide support for both SLIP and PPP, or only for one of them (usually SLIP)? If possible you want to have the maximum flexibility in choosing the type of service you subscribe to; in particular it is good to have the option of running PPP since it will most likely overtake and replace SLIP in the coming years. * Does the product provide a full range of Internet applications? Typical products provide at least Telnet, FTP, and electronic mail programs. Many also provide a Usenet newsreader, and some include Gopher and WWW client programs as well. * Can the product's underlying TCP/IP and SLIP/PPP stack be used with Internet applications obtained from other sources (e.g., freeware and shareware)? For example, for Windows you should confirm that the product is Winsock-compliant. * Does the price of the product include capabilities you will never use? As noted previously, many commercial TCP/IP products were originally designed for business use on local area networks and cost several hundred dollars; they include many functions of little interest to the typical individual user accessing the Internet from home or on the road. * Does the product include pre-defined configurations for popular Internet access providers? Typically the most difficult point in using the software is when you first attempt to connect to your Internet access provider; it will help if the product has customized login scripts and other pre-configured information available for your particular provider. Here are some commercial products that may be of interest: * Internet Chameleon TCP/IP for Windows. This product includes TCP/IP software with both SLIP and PPP support and a set of Internet clients including email, FTP, Telnet, Gopher, and a Usenet news reader; although Internet access itself is not included, the software comes preconfigured for several Internet access providers. Internet Chameleon is from NetManage, Inc., and is essentially a customized subset of their Chameleon TCP/IP for Windows LAN product. For more information call 1-408-973-7171, fax 1-408-257-6405, or send email to sales@netmanage.com. NOTE: NetManage also has a separate product named Chameleon Sampler which should not be confused with Internet Chameleon. Chameleon Sampler is based on an older version (3.11) of Chameleon TCP/IP for Windows and is bundled with many Internet books (see below); it includes only SLIP support and does not include the full range of Internet applications found in Internet Chameleon. * Internet In A Box. This product (not yet available at the time of writing) includes a complete set of Windows-based Internet applications (including a version of Mosaic) and Winsock-compliant TCP/IP software for use over PPP connections. The software is from SPRY, Inc., a commercial supplier of Windows-based TCP/IP software, and the documentation from O'Reilly and Associates, a publisher of UNIX and Internet books (including Ed Krol's "The Whole Internet User's Guide and Catalog," which is included in the package). For more information call 800-777-9638 or send email to info@ibox.com. * TCP/Connect II. This product from InterCon Systems Corporation is available in both Macintosh and Windows versions; it includes all the standard Internet applications and both SLIP and PPP support. For more information call 1-703-709-5500 or send email to sales@intercon.com. * WinGopher Complete. This product includes a Gopher client and TCP/IP software; it apparently also includes an introductory offer from an Internet access provider. WinGopher Complete is offered by NOTIS Systems, Inc. (a subsidiary of Ameritech); the Internet access itself is provided by a group of participating providers. For more information call 1-800-55-NOTIS (1-800-556-6847), fax 1-708-866-4970, or send email to wingopher@notis.com. Finally, Peter Tattam's Trumpet Winsock package from Trumpet Software International is a shareware product comparable to the products above in functionality and reliability; it includes a TCP/IP stack with a built-in SLIP driver, as well as a variety of Internet applications. The Trumpet Winsock package is quite popular and many freeware and shareware products are written to run with it. See the online information sources listed below for information on how to obtain it. Internet Book/Software Bundles If you do not want to pay the higher price ($100 and up) for a full commercial product then you may wish to consider one of the growing number of Internet books that come with a diskette containing Internet applications software. Here's some of the questions you should ask yourself in evaluating the purchase of such a book/diskette combination: * Is the software for a real Internet connection as described above? Some books include only a communications program with async terminal emulation; others include hybrid software that looks like a graphical Internet interface but uses a different underlying protocol. (For example, some products use the UNIX UUCP protocol to do batch uploading and downloading of electronic mail and Usenet news.) * Does the diskette include the minimum needed for a personal Internet connection? You will need at least a SLIP or PPP network driver, a TCP/IP stack (e.g., MacTCP or a Winsock-compliant product) supporting Internet applications, and at least an FTP program (which you can then use to download other software). * How many Internet applications come with the book? Does it include an email program? A Usenet newsreader? A Gopher client? Some books come with a broad variety of "best of breed" programs; others have only a bare minimum. * Does the book explain how to install, configure, and use the software? With a few books the software seems to be an afterthought, with most of the book devoted to explaining older ways of accessing the Internet (e.g., by using a UNIX shell account). * Does the book come with any other special offers? Some books include introductory offers (e.g., two weeks or a month of free service) for SLIP or PPP Internet access through a particular provider. (However, this may not be that great a deal if the provider is only reachable via a long-distance telephone call.) Here are some books that (as of this writing) meet the first two criteria above; that is, they have the minimum software needed for a personal Internet connection using SLIP or PPP: * "Internet Starter Kit for Macintosh" by Adam Engst ($29.95 US, Hayden Books, ISBN 1-56830-064-6) includes MacTCP, InterSLIP, Eudora, Fetch, TurboGopher, and StuffIt Expander. To my knowledge this is the only book available at the time of writing that includes everything you need for Macintosh systems. Engst also maintains an FTP site for readers of the book, with (among other things) copies of additional Internet applications besides those included on the book's diskette. * "Internet Starter Kit for Windows" by Adam Engst, Corwin Low, and Michael Simon ($29.95 US, Hayden Books, ISBN 1-5630-094-8) includes the Chameleon Sampler, the WinVN newsreader, Eudora, and WSGopher. * "The Windows Internet Tour Guide" by Michael Fraase ($24.95 US, Ventana Press, ISBN 1-56604-081-7) includes the Chameleon Sampler. Like Engst, Fraase maintains an FTP site with additional information and software, as well as a (fee-based) electronic update service for readers of this book and others he's written. * "The PC Internet Tour Guide" by Michael Fraase ($24.95 US, Ventana Press, ISBN 1-56604-084-1) includes UMSLIP (a SLIP-capable TCP/IP stack) and Minuet (an integrated Internet application supporting email, FTP, Telnet, etc.), both developed at the University of Minnesota. To my knowledge this is the only book available at the time of writing that covers personal Internet access from DOS-only PCs. * "Navigating the Internet (Deluxe Edition)" by Richard Smith and Mark Gibbs ($29.95 US, SAMS Publishing, ISBN 0-672-30485-6) includes the Chameleon Sampler. IMPORTANT: Make sure that the book says "Deluxe Edition"; there is another "non-deluxe" edition which does not include a diskette. * "The Internet Unleashed" by various authors ($44.95 US, SAMS Publishing, ISBN 0-672-30466-X) includes the Chameleon Sampler and HGopher. Here are two other books which contain Internet applications and are worthy of note (especially since they may be confused with some of the books above): * "Internet Explorer Kit for Macintosh" by Adam Engst and William Dickson ($29.95 US, Hayden Books) is a companion volume to "Internet Starter Kit for Macintosh" and includes Anarchie, Finger, MacWAIS, MacWeather, and TurboGopher. (These are also all freely available via anonymous FTP.) * "The Mac Internet Tour Guide" by Michael Fraase ($24.95 US, Ventana Press, ISBN 1-56604-062-0) includes StuffIt Expander, Eudora, and Fetch. However it does _not_ include MacTCP or a SLIP or PPP driver, and therefore you would need to buy MacTCP separately and find a SLIP or PPP driver somewhere else. Finally, note that Bernard Aboba, compiler of the Frequently Asked Questions list for the Usenet newsgroup comp.protocols.tcp-ip.ibmpc (see below), and Britt Bassett are writing a book "The PC-Internet Connection: TCP/IP Networking for DOS and Windows", scheduled for publication in the fall of 1994. For more information see the following URL: http://www.zilker.net/users/internaut/forth.html From the looks of the table of contents the book will go into greater technical detail than most of the books above. Online Information and Software If you already have Internet access and aren't yet ready to spend the money for a book, you may wish to explore the information and software already available online. Here are some good places to start: * "Windows and TCP/IP for Internet Access" by Harry M. Kriz (hmkriz@vt.edu) is a good overview of personal Internet access using Microsoft Windows and Winsock-compliant TCP/IP software; it goes into more technical detail than this paper and contains online locations and installation instructions for popular Winsock-based freeware and shareware. The document is posted on a regular basis to the Usenet newsgroup comp.os.ms-windows.networking.tcp-ip. The URL for the current version as of this writing is file://nebula.lib.vt.edu/pub/windows/winsock/wtcpip05.zip (The number "05" will be incremented as new versions are released.) * "Winsock Application FAQ" by Craig Larsen (larsenc@lcs.com) is a fairly complete listing of Winsock programs and their respective FTP sites, with brief reviews; besides freeware and shareware it lists demo versions of commercial products. The document can be retrieved by sending an email message to info@lcs.com with a subject line of "help"; it can also be found at the following URL: http://www.ramp.com/~lcs The WWW version is particularly nice as it includes links to all the programs retrievable via FTP, so if you're using a WWW client such as Mosaic you can click to download a given package. * "comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ)" by Bernard D. Aboba (aboba@internaut.com) contains a great deal of information about PC-based TCP/IP networking under both DOS and Windows. It is especially useful if you wish to run Internet applications under both DOS and Windows, or if you are also using TCP/IP software on a local area network; if you don't care about either of these topics then I recommend that you start with one of the other documents above. The FAQ is posted monthly to the newsgroup comp.protocols.tcp-ip.ibmpc; it is also available at the following URLs: file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip http://www.zilker.net/users/internaut/current.html The latter references an experimental hypertext version of the FAQ, together with additional useful information (including a discussion of Internet access via cable TV technology). * "Features of TCP/IP Packages for DOS and Windows" by C. J. Sacksteder (cjs@psuvm.psu.edu) is an exhaustive compilation of DOS and Windows-based TCP/IP software packages and their features. Like Aboba's FAQ it may be overkill if you're just starting to learn about personal Internet access. The document is available at the following URL: file://ftp.cac.psu.edu/pub/dos/info/tcpip.packages * "comp.sys.mac.comm Frequently Asked Questions (FAQ)" by David L. Oppenheimer (davido@phoenix.princeton.edu) contains (among other things) some information about MacTCP and SLIP and PPP drivers for the Mac. The FAQ is posted monthly to the Usenet newgroup comp.sys.mac.comm, and can also be found at the following URL: file://sumex-aim.stanford.edu/info-mac/comm/info/comp-sys-mac-comm-faq.txt As noted above, there are a number of Usenet newsgroups that contain discussions of personal Internet access using SLIP or PPP. The main ones are as follows: comp.os.ms-windows.networking.tcp-ip comp.protocols.tcp-ip.ibmpc comp.sys.mac.comm Note that comp.sys.mac.comm covers all Mac-related communications protocols and software; at this time there is no separate Macintosh newsgroup just for networking or Internet access. URLs and Instructions for Online Retrieval URLs or Uniform Resource Locators are a handy and increasingly popular way of specifying the online location of Internet resources; URLs originated in the World Wide Web (WWW) project. Some URLs in this document have "http:" at the front; these are WWW home pages accessible by Mosaic or other WWW client programs. However most of the URLs in this document are of the form file://hostname/directory-path/filename This identifies a file retrievable by anonymous FTP from an Internet host "hostname"; the file is in the directory "directory-path" and has the name "filename". For example, if you are reading this document in paper form and wish to retrieve the latest version in electronic form, you can do so using one of the following methods. * If you use Mosaic or other World Web Web browsers, you can retrieve this document using the following URL: file://ftp.digex.net/pub/access/hecker/internet/slip-ppp.txt (Use the "Open URL" menu item or its equivalent.) * You can retrieve this document via anonymous FTP from the host ftp.digex.net. The file is in the directory /pub/access/hecker/internet and has the name slip-ppp.txt. * If you have only email access to the Internet, you can retrieve this document by sending an email message to ftpmail@decwrl.dec.com and including the following lines as the body of the message: connect ftp.digex.net chunksize 25000 chdir /pub/access/hecker/internet get slip-ppp.txt quit (You may use any subject line you wish.) The "chunksize" value of 25000 bytes (characters) is optional; including it directs that the document be returned to you as multiple email messages, none exceeding 25,000 bytes in size. This is in case your mail system limits the size of incoming Internet email messages to less than 32K or 64K; if your limit is less than 25,000 then change the chunksize line to an appropriate value. If you don't have a limit on message size then you can change the chunksize to 100000 to get the whole paper as one message. The instructions above will also work for any of the "file" URLs in the document; just substitute the appropriate hostname, directory, and filename.