Frank Hecker >> Writings >> Personal Internet Access Using SLIP or PPP

Personal Internet Access Using SLIP or PPP

How You Use It, How It Works


                            Frank Hecker
                           hecker@home.com
                        http://www.hecker.org/


                         November 21, 1994
                     (Revised December 7, 1998)
               (Updated March 10, 1999 with new URL)

I have changed Internet Service Providers since this paper was originally written, and as a consequence I have moved this document from its original location at <http://www.access.digex.net/~hecker/papers/slip-ppp.html> and have updated my email address; however since the document uses my old email address and related information as part of the examples, to avoid confusion I have left the rest of the document as is.

Copyright 1994 by Frank Hecker. You may freely distribute this document in any form provided only that you retain this copyright notice.

This document is available on the Internet at the following URLs:

http://www.hecker.org/writings/slip-ppp.txt
http://www.hecker.org/writings/slip-ppp.html

(See the last section if you don't know what a URL is and need more information on how to get an online copy of this document. Thanks go to Brett McCoy for originally converting this document to HTML, and to Chris Tengi for correcting and validating it to the HTML 2.0 standard.)

INTRODUCTION

As the Internet has been increasingly popularized in newspapers, magazines, and books, more and more people are joining or seeking to join the community of Internet users online. Some subscribe to commercial services like CompuServe and America Online that are adding Internet-related features to their existing services. Others purchase accounts on commercial services which provide Internet access as their main offering, or get 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 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 document I discuss this type of personal Internet access: both how you use it and how it works.

I assume that you have a basic understanding of the Internet and the services it supports (e.g., Telnet, FTP, electronic mail, and so on), but that you know very little about TCP/IP, SLIP, PPP, and other obscure acronyms. I also assume that you have either an IBM-compatible PC (386 or better) running Microsoft Windows or an Apple Macintosh running the Mac OS. (Much of the discussion also applies to other PC operating systems such as IBM's OS/2 Warp or Microsoft's future Windows 95.)

My goal is not to give you complete step-by-step directions on how to configure your personal computer 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 document 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 with some advice on where to go next for more information.

The original version of this document was 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.); the paper grew out of my thoughts 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; as the poet Muriel Rukeyser said of her biography of the physicist Willard Gibbs, I wrote this document 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 document; I'd also like to thank my fellow employees at Tandem Computers, Inc., for their help and comments. However the views I express herein are mine alone and do not necessarily reflect the official position of either CapAccess or Tandem.

Why Bother?

Today most people going online first encounter the Internet at one remove; they use commercial services or bulletin board systems which have gateway functions supporting Internet electronic mail and perhaps access to Usenet online conferences. Those who wish to access the Internet more directly have traditionally used a so-called "shell account" service provided by an Internet access provider. (It's called a shell account because you login to a central UNIX host and type commands into the UNIX command interpreter or "shell.") For example, I first obtained personal Internet access through a shell account with Digital Express Group, Inc., of Washington, D.C., one of a number of local internet access providers that have sprung up around the U.S. in the past few years.

You use a shell account 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): you use your personal computer (PC or Macintosh) and its modem to login to a central UNIX host, you read and compose electronic mail using a UNIX email program such as Pine or Elm, you read and post Usenet news articles using a UNIX-based newsreader like rn or trn, you retrieve files using FTP and then download them using Zmodem or Xmodem, and so on. For software you use a standard communications program with VT100 terminal emulation and Zmodem download capabilities, such as Procomm or CrossTalk on PCs or Zterm on Macintoshes.

Perhaps you have a shell account now, have learned how to use the various Internet-related UNIX commands, and are reasonably satisfied with the service. Why then might you decide to change it? Here are some possible reasons:

If any of the commments above apply to you then you should consider getting a so-called SLIP or PPP account. SLIP or Serial Line Internet Protocol is a communications protocol that supports an Internet connection (i.e., using TCP/IP) over a dialup line. There is also a common variant of SLIP called Compressed SLIP or CSLIP; it can be somewhat faster in operation than standard SLIP.

PPP or Point-to-Point Protocol is a newer protocol that does essentially the same thing as SLIP or CSLIP; 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 SLIP, CSLIP, and PPP interchangeably.

(As I note below, PPP does have some inherent advantages over SLIP and is likely to become better supported and more popular than SLIP and CSLIP in the future. However at present more software and Internet access providers support SLIP and CSLIP. If your software and Internet access provider give you a choice of SLIP or PPP, choose PPP; if not, use SLIP.)

USING SLIP OR PPP

Setting up and using SLIP or PPP can be much simpler than you might expect. I'll get to the technical details later; instead I'll begin by describing how you might actually use your SLIP or PPP service. (Some of these details may vary slightly based on the type of software you're using and the particular Internet access provider you've chosen.)

You start with your PC or Mac already running with its modem turned on and connected to a phone line. First, you invoke the SLIP or PPP application. The SLIP/PPP software asks you for your SLIP/PPP password (which goes with your SLIP/PPP userid--more on this below), and then uses a script to dial the SLIP/PPP access number at your Internet access provider. Your modem dials out, their modem answers, and then the script takes over for a few seconds until the SLIP/PPP connection is established. At that point you can forget about the SLIP/PPP application, and (depending on the software) can minimize it or even close it just to get it out of the way. (Part of it is still running "underneath," however.)

Electronic Mail

At this point you have a live connection between your personal computer and the Internet. The next thing you might typically do is to start up an Internet email program such as Eudora and ask it to check for and retrieve your electronic mail. Eudora then asks for your mail account password (which goes with your mail account userid). Note that these are a different userid and password than your SLIP/PPP userid and password; I discuss this in more detail below. Eudora then goes out and downloads your mail from your 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 you've received and how big the messages are. When downloading completes you have all your new mail messages in an email inbox on your PC or Mac.

You can then either read your mail or do something else. You might read at least a few messages that look important, and perhaps respond to a couple of them. When you respond, your messages get put in an email outbox for later delivery; they aren't sent right away.

Remote Login Using Telnet

Suppose that one of the messages is about something on another Internet-connected system (for example, the CapAccess community network system) which supports login access. You can then invoke a Telnet application such as Trumpet Telnet for Windows or NCSA Telnet for Macintosh and connect to the system using its hostname ("capaccess.org" in our example) to check things out. This brings up a 24-row by 80-column screen similar to what you'd get dialing in directly, with a prompt for the login id. You give your userid and password for the system (asssuming that you have one) and then you're logged in and can do all the standard operations supported on that system.

Note that this Telnet connection isn't going through either the Internet access provider's UNIX host system or the remote system's phone lines and modems; it's going over the Internet from your personal computer to the remote 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).

File Transfer Using FTP

Suppose that while logged in you read something that refers to an information file that you can FTP from somewhere else on the Internet. Then without closing the Telnet session you can bring up an FTP client application such as WS_FTP for Windows or Fetch for the Macintosh. WS_FTP and Fetch allow you to start a session to a public or "anonymous" FTP site, browse through the directories, and download files using FTP directly to your PC or Mac; download speeds for text and binary files are comparable to those achievable using traditional communications programs and protocols like Zmodem. (Downloading over SLIP or PPP is not always quite as fast, for various reasons too complicated to go into in this paper, but it's fast enough for me and most likely for you as well.)

After finishing the FTP session you can go back to your Telnet session and continue. TCP/IP and SLIP/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 access provider's SLIP/PPP access point.

If you use a personal computer operating system supporting "preemptive" multitasking (like OS/2 Warp or the future Windows 95, for example), you can actually have different downloads going on simultaneously while you run Telnet or other Internet applications. Unfortunately neither Windows or the Mac OS currently support preemptive multitasking, so doing an FTP transfer on those systems can severely degrade performance on a Telnet session; however it works fine to keep multiple applications open for use but otherwise idle, and you can then switch between them as desired.

Usenet News

If you're really done with your Telnet session you can log out of the remote system and close the link. You might then bring up a Usenet newsreader program such as WinVN for Windows or NewsWatcher for the Mac. WinVN or NewsWatcher connects to the Internet access provider's Usenet news server and then presents you with a list of your currently subscribed newsgroups, together with an indication of how many articles are available in each group. You double-click on a newsgroup you're interested in checking, and WinVN or NewsWatcher downloads the list of current postings in the group by subject. (NewsWatcher also knows about "message threads," so if multiple postings have the same subject it only shows me one line in the listing of articles.)

You then double-click on the line corresponding to a posting (or thread) you want to read, and WinVN or NewsWatcher downloads the text of that posting and puts it on the screen in a window. More double-clicking lets you advance through the newsgroup article by article, marking articles as having been read as you download and read them. You can also compose and post follow-up articles or new articles, which are uploaded to the Usenet news server immediately.

If you don't read all articles in a newsgroup or get through all newsgroups, you can look at them later when you next use WinVN or NewsWatcher. You can also mark articles as having been read without downloading them, in case the subject line indicates that you would likely have no interest in them.

Gopher and World Wide Web

Thus far in this example I've discussed electronic mail (Eudora), Telnet (Trumpet or NCSA Telnet), FTP (WS_FTP or Fetch), and Usenet News (WinVN or NewsWatcher). You may also have Hgopher or TurboGopher, Gopher client programs for Windows and the Macintosh respectively. HGopher and TurboGopher allow you 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: you can use a point and click graphical interface; you can save Gopher files directly to your PC or Mac (as opposed to saving them in a host UNIX directory and then downloading them); and you don't have to login to a UNIX host first.

Finally, you can use the much-heralded NCSA Mosaic program (or one of its many variants or look-alikes) to explore the World Wide Web with full access to multimedia information including formatted multi-font text, graphics, sound, movies. If you do, you will soon find that using Mosaic over a 14.4 kbps dialup line is often 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 the embedded graphics included in most WWW data. (You can tell Mosaic not to download the graphics images, but then what's the point?) Thus using Mosaic over a 14.4 Kbps 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 (or "browser") like Mosaic.

Finishing Up

While you've been doing all the things above TCP/IP and SLIP or PPP have been running quietly underneath, supporting your connection on the dialup link. After a while you figure it's time to save your pennies and cut the connection. (Most Internet access providers give you a number of "free" hours per day or per month--i.e., included in your basic monthly rate--but these can go fast, especially if you're like me and you connect at least two or three times a day.) You remember you still have electronic mail messages in your Eudora outbox, so you go into Eudora and tell it to send all outgoing mail. It uploads the messages to your Internet access provider's mail server, which then will take care of sending them on to their final destination.

Having finished all your online stuff, you go back to the SLIP or PPP application and tell it to disconnect. At that point you lose all the fancy functionality like Mosaic, FTP, etc. However you can still read your electronic mail in Eudora, compose replies, and queue them for delivery the next time you connect.

What You Get with SLIP or PPP

In summary, here's what you get if you have a SLIP or PPP account:

HOW IT ALL WORKS

Having told you how you can access the Internet directly from your PC or Macintosh, I'd like to go now into more detail about what's going on "behind the scenes." My apologies for the level of technical detail; I've tried to keep it to the minimum necessary to make my points. (Although I can't resist continually returning to 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:

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 transmission over a communications link. TCP/IP is roughly analogous to protocols like Kermit or Zmodem which package up data for downloading or uploading over "normal" dialup connections (e.g., to a BBS).

However you really don't need to know the details of TCP/IP, any more than you need to understand how telephone line signaling works in order to call someone on the phone. 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:

The three elements common to both cases are thus as follows:

If it's that simple, why has connecting to the Internet using SLIP or PPP traditionally been so hard for individual users? Because doing so 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 you can connect to (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.

Fortunately this situation has improved tremendously in the past few years (and even in the past few months), and we may be well on the way to having personal Internet access be as easy to get and use as residential phone service is today.

Making Your PC or Macintosh Internet-Capable

Let's go back now and analyze what's happening in the example above of connecting your PC or Mac to the Internet using SLIP or PPP. First, let's discuss what you need to make your PC or Macintosh Internet-capable.

As noted above, you start with a PC or Macintosh system with a 14,400 (or better) bps modem. (Theoretically you can use a 9600 or even 2400 bps modem, but with SLIP or PPP a faster modem will really make a difference, especially with applications like Mosaic. Using one of the newer 28.8 Kbps modems would be best, but many Internet access providers do not yet support their use.) 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 (U.S.) or so, depending on the modem's brand, whether the modem is external or internal, and so on. For example, early in 1994 I bought a Practical Peripherals 14,400 bps external modem for $140; in 1990 I paid almost $500 for an earlier Practical Peripherals modem that supported a maximum speed of only 9600 bps.

To the modem you must add the requisite TCP/IP and SLIP/PPP software. Many such products exist for PCs; some of these products are freeware while others cost money. For example, the Chameleon Sampler from NetManage, a freeware TCP/IP and SLIP product for 386 or better PCs running Windows 3.1, is included in several Internet books now on the market. (See below for references.) Another popular TCP/IP and SLIP product for Windows is the shareware Trumpet Winsock by Peter Tattam.

In Windows 95 or "Chicago,", the major release of Windows due out in 1995, Microsoft will be including TCP/IP and PPP capability in the base operating system. At that point you'll get TCP/IP software at no extra cost if you buy a PC with Windows 95 preloaded. (You'll be able to get it for older PCs by buying Windows 95 separately as an upgrade to Windows 3.1.)

IBM has adopted a similar course of action for its just-released new version of OS/2, known as OS/2 Warp version 3 or Warp for short. Designed to be installed on 386 or better PCs running Microsoft Windows, Warp includes TCP/IP support using SLIP, as well as OS/2 client programs for Internet services such as email, Telnet, FTP, Usenet news, Gopher, and the World Wide Web. These programs are comparable to the Windows and Mac Internet programs mentioned above; if you wish you can also run Windows Internet programs under Warp as well.

TCP/IP software for Macintosh systems 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. For example, I use the free InterSLIP software from InterCon Systems Corporation; MacPPP is a comparable free product for PPP.

MacTCP itself is not freeware, but you can get it (along with InterSLIP and/or MacPPP and related stuff noted below) by buying either of the books "Internet Starter Kit for Macintosh" by Adam Engst or "The Mac Internet Tour Guide" by Michael Fraase. (See below for a list of references.) Also, Apple is including MacTCP in the new System 7.5 version of the Mac OS, so if you buy a new Macintosh you'll get TCP/IP software at no extra cost whatsoever. (You can also get MacTCP for older Macintoshes by buying the System 7.5 product as an upgrade, although if you don't need the other System 7.5 features you'll save money by buying MacTCP as part of Engst's or Fraase's books.)

I should add that the wide availability of relatively cheap TCP/IP software for Macs and PCs is a recent phenomenon. Traditionally TCP/IP software has been seen as of interest only to businesses running in-house local area networks, and TCP/IP products cost as much as $400 or $500 per PC or Macintosh. 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 dialup lines to access the Internet. Thus many commercial TCP/IP software packages have dropped in price to $200 or less, at least for the basic capabilities needed for personal Internet access using SLIP or PPP..

As noted above, over the next year or so this cost will drop further to zero for basic Internet functionality; that is, at some point TCP/IP and SLIP and/or PPP capability will be bundled with the base operating system software shipped with every new PC or Macintosh. At that point the only incremental cost to make your PC or Macintosh "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, or 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 today, and are rapidly becoming a thing of the past in the PC world (at least for people using Windows or OS/2 Warp).

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 version of MacTCP. (The recommended revision of MacTCP at the time of writing is 2.0.4.)

In the Windows world the compatibility problem has not yet been totally solved but it has been alleviated to a great degree 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.

The de facto TCP/IP standard for OS/2 is the IBM product bundled with OS/2 Warp, and all native OS/2 Internet applications should be written to its interface. OS/2 Warp also supports a Winsock interface for Windows-based Internet programs running under OS/2. (Windows 95 will also support the Winsock interface.)

Connecting to the Internet

As described above, you can make your personal computer Internet-capable by installing the proper TCP/IP and SLIP software on your modem-equipped PC or Macintosh. Your next step is to sign up with a service provider who can give you a SLIP or PPP connection to the Internet. (For example, in my case I got a so-called "Personal IP" account with the D.C.-area company Digital Express Group, Inc.).

Your Internet access provider will supply you with at least three things (actually more, but we'll get to that): a dialup SLIP/PPP access phone number to have your modem connect to, a personal "SLIP/PPP userid," and a personal password to go with the SLIP/PPP userid. The SLIP/PPP userid is typically some arbitrary string like "xx537", and the password is like a standard login password for a UNIX system or BBS.

Let's assume that you've configured your SLIP/PPP software with the dialup SLIP/PPP access phone number and your SLIP/PPP userid, as well as the other information we discuss here and below. (The exact details of how to do this configuration vary depending on your TCP/IP software and your Internet access provider; see the references below to sources of information for particular packages.) You now direct the software to call up the SLIP/PPP phone number using your 14,400 bps (or other) modem.

The call is answered by a corresponding modem at the other end (like the ones used by BBSs). That modem is typically connected in turn to a SLIP- or PPP-capable "terminal server," a black box that takes the data coming from your PC or Macintosh over the dialup line and retransmits it to your 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 dialup modems over a LAN into the actual UNIX host system they login to. The main difference is that the SLIP- or PPP-capable terminal servers (more generally known as "remote access servers") have an extra capability which lets them pass "raw" TCP/IP data through from your PC or Macintosh to the Internet.

In fact, when you first connect to your Internet access provider's modem and remote access server, it can look very much like logging in to a remote UNIX system, particularly if you're using SLIP. (That's if you were looking at the conversation, which typically you don't--login is normally handled by an automated script). One of the first things you would see would be a prompt for a userid, at which point you (or the script) would enter the special SLIP/PPP userid. You would then see a password prompt, in response to which you (or the script) would enter the SLIP/PPP password. (The SLIP or PPP software on your PC or Macintosh would typically 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 remote access 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 dialup 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 tells you that the connection has been made and then shuts up.

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.

Second, you might ask why you need a userid and password if you're not actually logging in to anything? Because your Internet access provider wants to be able to bill you for the time you spend connected to the Internet through their remote access server, and to do this they need an id of some sort to know that it's you connecting. You in turn need a password so that no one else can connect to your SLIP/PPP remote access server and bill time to your account. You can think of this userid/password combination as your "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 remote access server check your SLIP/PPP userid and password and then account for your connect time? The answer is that it either checks your userid and password against an internal database held in non-volatile memory on the remote access 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 some modern remote access servers this can be done using the "Kerberos" authentication protocol invented at MIT; Kerberos has the advantage that your password is sent over the network in an encrypted form, which decreases the likelihood that someone might intercept it and use it to gain unauthorized SLIP/PPP access.)

If the SLIP/PPP userid checks out, the remote access 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 remote access 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 you always made the connection from the same phone, then your Internet access provider could theoretically use Caller ID or similar mechanisms to know that it was you calling, just as you don't have to enter a calling card number to dial long distance from your home phone. However, just as you might make long distance calls while on the road, you might connect your modem to different phones, for example if you have a laptop; having a separate SLIP/PPP userid and password is necessary to handle this case.

There's another crucial piece I've left out so far: the IP address, your "Internet phone number." For example, my Internet access provider assigns me my very own IP address (mine is 164.109.211.201, in case you're curious); an IP address is the fourth piece of initial information you may be given when you sign up, along with the three I've already mentioned: SLIP/PPP dialup access number, SLIP/PPP userid, and SLIP/PPP password.

Many remote access 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 (discussed 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 remote access server, so the Internet access provider really doesn't need to supply any more IP addresses than it has dialup 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 you might get a given IP address at one point, and after you disconnect from the service someone else could get the same address a few minutes later.

Finally, sometimes the dialup connection will be lost during an Internet session (for example, because of line noise). Because of the nature of the TCP/IP protocols, if you have a fixed IP address you can often recover the session simply by reestablishing the dialup SLIP or PPP link; this is not possible if your IP address changes each time you connect.

To summarize: after you sign up with an Internet access provider and connect to their SLIP/PPP terminal server you will be directly "on the Internet" (or have "Internet dial tone" if you will), having fulfilled the three conditions we discussed above:

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 hood." 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.

Electronic Mail

At the end of the last section we'd gotten to the point where your computer had "Internet dial tone:" it had established a TCP/IP link to the SLIP/PPP-capable remote access server of your Internet access provider, and was now ready for you to do useful work (or "make some calls," to continue our telephone analogy).

If you recall, the first action in our example session above was to check your electronic mail using Eudora, an email program available for both Windows-based PCs and Macintosh systems. In an earlier incarnation (release 1.4) Eudora is a freeware program; for example, I got a copy of Eudora 1.4 for Macintosh from Adam Engst's "Internet Starter Kit" book mentioned above. Eudora is now also available in a commercial version (release 2.1) with somewhat more functionality (like mail filters) and formal technical support; I recently bought a copy of Eudora release 2.1 for $65 from Qualcomm, the vendor that 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 are connected to the Internet 24 hours a day. When users send mail (say from "jdoe@capaccess.org" to "rroe@agency.gov") the messages are transmitted (almost) immediately over the Internet from the originating host ("capaccess.org") 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 but in the reverse direction. 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.

For example, this method is how I used to read and compose mail using my Internet shell account: I would login to my Internet access provider's host system ("access.digex.net") and use the UNIX-based Pine program to read and respond to electronic mail.

However, if your computer can be linked to the Internet more directly then you would probably prefer to read and compose mail on your PC or Mac itself and then send mail or receive it over your Internet connection. As I mentioned above, when connected to the Internet using SLIP or PPP, your PC or Mac will have its own Internet address and may even have its own hostname. (For example, when connected my Mac has the Internet address "164.109.211.201" and the Internet host name "ion.digex.net". I'll discuss how Internet hostnames work in more detail below when I talk about FTP.) Unfortunately, though, you typically can't use the traditional SMTP mail protocol, at least to receive mail.

Why not? Because mail sent using SMTP is sent directly to the recipient host, which in this case would be your PC or Macintosh, and your PC or 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 you are connected to the Internet using an intermittent dialup SLIP/PPP connection, there's no guarantee that your PC or Mac would be online at the exact time the sending host wanted to send the message, and thus you could end up not receiving messages sent to you.

(The sending host will in fact periodically retry sending mail messages if it cannot connect to your computer the first time. However the sending host does not retry forever, and if it cannot connect successfully within a given time period, say three days, then it will give up on delivering the mail. If your computer is connected to the Internet only for brief periods during those three days then it is quite possible that the sending host will never be able to connect to it.)

The problem is even worse if your PC or Mac does not have a permanently-assigned Internet address, but instead is assigned one "on the fly" when you connect to your Internet access provider; typically in this case your PC or Mac does not have a permanently assigned hostname either, and thus someone attempting to connect to your PC or Mac using SMTP would not know which hostname or address to use.

Going back to our telephone example, sending Internet electronic mail to you in the traditional manner (i.e., using SMTP end-to-end) is somewhat like leaving a message for you on your personal answering machine: people can call your phone number 24 hours a day and count on the fact that your answering machine will almost always be turned on and ready to record messages.

But in the case of SLIP or PPP your "Internet phone number" (IP address) will be active only part of the time (when you're connected to your Internet access provider via SLIP or PPP and have "Internet dial tone") and your "answering machine" (your computer) won't always be turned on and ready to receive your messages. If in addition your PC or Mac is assigned an Internet address only upon connection then you don't even have a permanent "phone number" by which others can contact you.

The solution to this problem is very simple: have another Internet-connected system (a "mail server") receive your email messages for you, and then when you're connected to the Internet download your mail messages from that system to your PC or Mac. Continuing the answering machine analogy, this arrangement is similar to what many U.S. 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.

For example, 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 for short. In particular Eudora and my provider's "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.

As noted in the original example of an Internet session, you also have to supply Eudora with a "mail userid" and associated password; Eudora then passes on this userid and password 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, in my particular case the system "access.digex.net" that acts as a POP3 mail server happens to be the same system that supports users logging in to shell accounts; this is true for many other Internet access providers as well. If your access provider does this then your mail userid and associated password would be the exact same ones you would use when logging in to the provider's system itself as a user of an Internet shell account. (In my case this single userid is "hecker".)

If you are upgrading to SLIP or PPP from a shell account then this makes for a smooth transition from the old way of doing things (e.g., using Pine or Elm with your shell account) to the new way (e.g., using Eudora over SLIP or PPP); your electronic mail address will remain the same (in my case "hecker@access.digex.net" or userid "hecker" on host "access.digex.net") and you don't have to choose a new password for use with Eudora if you don't want to.

Also, with many providers if you ever want or need to you can still dial up your provider's host in the old way (i.e., using a VT100-compatible communications program instead of SLIP or PPP) and login and read your mail using a UNIX-based mail program like Pine or Elm. This is possible because the mailbox format used by the host-based POP server is the same standard UNIX mailbox format used by almost all UNIX host-based mail programs. (Unfortunately some providers make it harder for you to do this because they consider shell accounts and SLIP/PPP accounts totally separate services and require you to pay full price for both if you want to use them interchangeably.)

However, your mail userid and password are not necessarily the same as the SLIP/PPP userid and password that I've previously mentioned; that's because these are associated with 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 remote access 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 may well receive an email (POP) userid and password separate from and in addition to your SLIP/PPP userid and password.

There are exceptions to this. Some smaller Internet access providers do not have separate remote access 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. (This host-based software may be either traditional SLIP or PPP software or SLIP-derived software like the new product The Internet Adaptor; see below for more information about TIA.) In this case a user--or more correctly, their SLIP or PPP 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 command to convert the session into a SLIP or PPP connection. Eudora or other POP3 mail programs would then use this same userid and password to download mail.

Some providers may also wish to provide users with the convenience of having a single password for all services. In this case they could simply arrange that the SLIP/PPP userid and password used by the remote access server be the same as the userid and password used by the POP3 mail server. For example, the national Internet access provider Netcom does this for their NetCruiser service.

Suppose that you had a full-time hard-wired Internet connection in your home (for example, like those promised to be provided by some cable companies in the U.S.). You could then have "Internet dial tone" all the time and you wouldn't need a dialup protocol like SLIP or PPP to connect. You 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 you might still want the cable company to store your incoming electronic mail messages for you, perhaps because you don't want to keep your computer turned on all the time. In this case you could use Eudora and POP to connect to a remote mail server, just as as you would over SLIP or PPP, and you would still have to have a mail userid and password supplied to you 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 and similar services 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 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 your incoming email messages to your PC or Mac you can then read them at your leisure; you don't need to maintain the Internet SLIP connection to do this. What about sending messages? Here again you don't need to be connected in order to compose messages, but (it almost goes without saying) you 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 (your PC or Mac) typically connects directly to the receiving host (say "whitehouse.gov", if you're sending a message to Bill Clinton or Al Gore). However the receiving host might be down or unreachable due to some Internet problem, so that Eudora would not be able to send the message and would have to postpone its transmission to a later time, say a few hours later.

However Eudora typically doesn't make this connection on its own (although there is a way to configure this in some cases); you simply reestablish the SLIP or PPP connection at a later time and then command Eudora to send out any messages in its outbox. This is rather inefficient; why should you have to go to all the trouble of remembering to reconnect periodically to your Internet access provider? (Even if Eudora were to reconnect automatically, you'd still need to leave your PC or Mac turned on and plugged into the phone line.)

Instead what typically happens is that Eudora uses the SMTP protocol to send your message to your Internet access provider's 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 you can disconnect your PC or Mac and not worry any further 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 you in any way when you use Eudora (or another POP client program) to send mail via this method; instead you 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 my 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 you need to change your password to "k00l/d00d".)

There are well-known ways to solve this problem, but they haven't been implemented because they depend on encryption and related technologies and their 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 technologies that are available worldwide and that are 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 issues can eventually come to affect all of us.)

Usenet News

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 several 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 typical Usenet host system stores only the last few days worth of articles.

If you want Usenet access from your personal computer there are at least three possible ways to get it. First, you could have your PC or Mac be a full-fledged Usenet host and receive all conferences; this is pretty much out of the question for most people, given that the daily flow of traffic runs to multiple megabytes and you'd need a lot of connect time each day to receive all the articles. (In fact, at 14,400 bps and lower speeds you might not even have time to download all the day's traffic by the end of the day.)

Second, you could have your 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 downloading every article in every newsgroup you chose to receive, even articles of little or no interest to you.

The third alternative is the most common (and is what I use): connect to a remote Internet host acting as a "news server;" this host ("news.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 you have an Internet SLIP/PPP connection active, you then have your Usenet newsreader application (e.g., WinVN or NewsWatcher) connect to the news server over the Internet and download the list of articles (i.e., by subject line) in each newsgroup. You then pick which articles you want to read and have WinVN or NewsWatcher download only those articles; the rest are left unread (at least by you) 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 WinVN or NewsWatcher and the news server use to talk to each other.

However you don't typically have to supply a userid or password when reading and posting news. You do have to tell WinVN or NewsWatcher your email address ("hecker@access.digex.net" in my case) because this is used to mark articles you post as coming from you; the email address is also needed when you send mail to someone in lieu of posting a reply to the newsgroup. However this information is not used to authenticate you to the news server in any way.

You might ask, can anyone on the Internet then use WinVN or NewsWatcher (or other NNTP client programs) to read and post articles from and to your 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, by 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 typically your 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. For example, since my Mac has an IP address and Internet hostname assigned by the Internet access provider when I signed up, my 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. (Some news servers do authenticate users using a userid and password as well.)

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 many other services for which you need only a basic Internet connection. The first example is using anonymous FTP to download information files or shareware. FTP programs such as WS_FTP or Fetch will ask you for the name of the host I wish to connect to. Some magic then happens to convert the hostname to an IP address (analogous to looking up a phone number) and the connection is made, after which you can download files. The FTP site doesn't ask for an individual password, and doesn't really care who you are.

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 WS_FTP and Fetch can be configured to send your email address (e.g., "hecker@access.digex.net" in my case) 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 Internet address from which you're connecting (i.e., the IP address of your PC or Mac) 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.

Hostnames and DNS

This is probably as good a place as any for a brief digression on Internet hostnames. As implied earlier, Internet hostnames (like "capaccess.org") 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 corresponding to a given hostname and vice versa.

This automated service is referred to as Domain Name Service or DNS, and is silently invoked by your Internet-capable PC or Mac every time you give it an Internet hostname to connect to. The lookup is done by querying a special Internet host called a DNS name server; typically this server is maintained by your Internet access provider, and its IP address is yet another of the pieces of configuration information you will get when you sign up for SLIP or PPP service.

Besides letting you (or more properly, your computer) look up IP addresses automatically, my Internet access provider's DNS name server will also maintain entries listing the Internet hostname and IP address of your computer. (At least if you have a permanently-assigned IP address; if your PC or Mac is assigned a temporary IP address when connecting then that IP address will typically have a corresponding temporary hostname.) This lets remote systems like anonymous FTP sites do the sort of checks I briefly mentioned above. Other than that your computer's hostname (for example, "ion.digex.net" in my case) isn't used for much, as email for you will typically be sent to the mail server's hostname (e.g., "access.digex.net") instead.

Like directory assistance, DNS name service is essential but fundamentally uninteresting and taken for granted (unless you need to use it and it's not working). As noted above, 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, and thus have an email address like "hecker@my-company.com".)

Continuing on, Telnet from your PC or Mac works similar to FTP: you tell your Telnet application (e.g., Trumpet Telnet or NCSA Telnet) the hostname you wish to connect to, it does the silent DNS lookup to find the IP address, and then connects you 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 dialup 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, if you're a particularly enthusiastic MUD fan).

The Gopher and World Wide Web services are a little more complicated in the way they work. When you start up a Gopher client program (e.g., HGopher or TurboGopher) or a Web browser (e.g., NCSA Mosaic) they typically attempt to connect initially to a preset "known host" system (or systems, if alternates have been set up); for example, for HGopher and TurboGopher these host systems are at the University of Minnesota and for NCSA Mosaic they are at the National Center for Supercomputing Applications at the University of Illinois Urbana-Champaign. (Almost all Gopher client programs and Web browsers can be changed to connect to other initial host systems, or even to not connect to a host system at all.)

Once connected to an initial host system, Gopher programs and Web browsers operate in a "client/server" fashion: the client (i.e., the program running on the PC or Mac) sends a request over the Internet to the server (the Gopher or Web program running on the remote host), which in turn sends back a response. This happens invisibly underneath using a special-purpose communications protocol (Gopher+ for Gopher and HTTP or HyperText Transport Protocol for the World Wide Web); all you see on the screen is a graphical "point and click" interface like that characteristic of other Windows- or Mac-based programs.

If you pick an item from a Gopher menu or choose to follow a hypertext link in the World Wide Web then one of three things may happen: you may invoke a menu ("page" in WWW jargon) on the same system, you may invoke 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, the Gopher program or Web browser automatically reconnects to the new system and sends the proper low-level commands to retrieve the menu (page) being invoked. As you browse through the Gopher menu hierarchy (or the WWW hypertext tree) the programs automatically switch from system to system as needed, so there is no single system to which the Gopher program or Web browser remain "connected" in the traditional sense.

In the third case, when you invoke a menu item or click on a hypertext link some special action may be performed. One very common action is to initiate automatic downloading of some file. This is often implemented by having FTP-like functionality built into the Gopher program or Web browser, so that by invoking a Gopher or WWW item you can fetch any file retrievable via anonymous FTP. If the file is of a special type then the Gopher program or Web browser can do also something special with it besides just downloading it. For example, if the file were a graphics image in GIF format then after downloading is complete the Gopher program or Web browser might try to invoke a GIF viewer to show you the file. (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 the World Wide Web; 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 the World Wide Web except the Internet connection itself and the proper client programs.

Our Story Thus Far

It's been a long and tangled path to get to this point, and thank you for sticking with it. Here's a quick summary of the basics of accessing the Internet using SLIP and PPP:

Beyond Basic SLIP and PPP

So far we've discussed using SLIP and PPP over a standard dialup telephone line (often called a "POTS" line, for "plain old telephone service") using a standard analog modem with a maximum speed of 14,400 or 28,800 bps. Unfortunately even when using SLIP or PPP over a 28.8 Kbps modem many common Internet applications can be slow and unresponsive. For example, downloading a World Wide Web page with 100 KB of embedded graphics (not an uncommon occurence) would take almost a minute even at 28.8 Kbps.

One increasingly available way to speed up SLIP/PPP-based Internet access is to use a more advanced ISDN phone line. (In actual practice ISDN is used with PPP, mainly because there is a well-defined standard for PPP over ISDN.) ISDN provides a direct digital connection to the phone network (hence the name, "Integrated Services Digital Network") and offers the promise of both higher transmission speeds (64 or 128 Kbps vs. 14.4 Kbps or 28.8 Kbps for a standard dialup line) and faster call setup times (i.e., the time between dialing the number and establishing the connection).

Using ISDN not only requires getting a new phone line, it also requires the use of special hardware to connect your PC or Mac to ISDN; ordinary phone lines and modems cannot be used directly with an ISDN line. For connecting a PC, for example, this hardware could be in the form of a special I/O board to which the ISDN line would connect (e.g., using a modular jack similar to your modem's modular jack); this board would replace your existing internal or external modem.

Like a standard phone line, ISDN is a dialup (or "switched") service; your TCP/IP software would still need to dial a phone number corresponding to your Internet access provider's remote access server(s). (However the phone number would be for an ISDN line, and your access provider's remote access server would have to support incoming ISDN calls.) The Internet applications (Telnet, FTP, email, etc.) would still work as described above for a standard SLIP/PPP connection

An alternative to dialup connections is a high-speed dedicated Internet connection; while this has traditionally been done using expensive "leased lines" provided by phone companies, at least two cable TV companies (in Massachusetts and California) have announced relatively low-cost Internet access over the existing cable network.

As with ISDN, with "cable Internet" your PC or Mac would not use a standard modem but rather something like an Ethernet controller board, which typically runs about $100 to $200 U.S. on up; this board in turn would hook up to something like a "cable Ethernet" connection located on your set-top box. (For technical reasons your PC or Mac may also be connected to a special modem dedicated to sending outgoing traffic back to the cable company; the higher-speed connection may be used only for incoming traffic.)

Note that 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.

As with ISDN, Internet access would work essentially 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 Internet application.)

I should add that (for reasons alluded to above) typical "cable Internet" 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 and the World Wide Web, 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 commands going in the other direction back to the World Wide Web servers.

Because of their advantages in speed, ISDN and "cable Internet" may be the next frontier for power users currently enjoying the benefits of standard SLIP and PPP dialup access.

WHERE TO GO FROM HERE

After reading this paper I hope you now have a good feel for how Internet access using SLIP or PPP works, and as a result you may be interested in finding out more about SLIP and PPP and possibly even acquiring your own SLIP or PPP connection. This section covers three possible avenues you might explore:

Each option has its pros and cons; no one has yet come up with a single best and complete "A to Z" solution for personal Internet access that supports everything you might want to do, provides everything you'll need and answers every question you might have.

In evaluating which route to take, it may help to ask yourself the following questions:

The range of available information, software, services, and support for Internet access for SLIP/PPP 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 SLIP or PPP 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:

Here are some commercial products that support standard TCP/IP and SLIP/PPP operation (as described above) for Windows-based PCs or Macintosh systems; the products are listed in alphabetical order by product name:

Internet Book/Software Bundles

If you do not want to pay the higher price (up to $200 U.S.) 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:

Online Information and Software

If you already have Internet access and aren't yet ready to spend the money for a book or for a commercial product, you may wish to explore the information and software already available online. Here are some good places to start:

URLS AND INSTRUCTIONS FOR ONLINE RETRIEVAL

Note that these instructions are badly out of date; see the beginning of the paper for the URL at which this paper is currently located.

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. Others with "gopher:" at the front refer to Gopher servers accessible via TurboGopher and other Gopher client programs. The URL for this document itself is of the form

ftp://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.


Frank Hecker || Personal Information || Interests || Writings