💾 Archived View for spam.works › mirrors › textfiles › internet › slipdoc.txt captured on 2023-06-16 at 18:51:21.

View Raw

More Information

-=-=-=-=-=-=-



               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:


and password associated with that access.


implement traditional Internet services such as electronic mail, FTP,
Telnet, and Usenet news, as well as newer services like Gopher and
Mosaic/WWW.


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).


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:


TCP/IP family of communications protocols.


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.


(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:


(i.e., the sound of voices) using some sort of low-level magic (which you
don't really worry about).


(your local telephone central office) through which your phone can
connect to other phones anywhere in the world (and vice versa).


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:


way;


with other devices; and


"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:


"Internet-capable" PC or Macintosh.


Internet access point.


"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:


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.


(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).


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.


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.


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.


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:



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:


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.


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.


Internet applications obtained from other sources (e.g., freeware and
shareware)?  For example, for Windows you should confirm that the product
is Winsock-compliant.


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.


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:


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.


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.


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.


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:


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.)


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).


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.


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).


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:


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.


Michael Simon ($29.95 US, Hayden Books, ISBN 1-5630-094-8) includes the
Chameleon Sampler, the WinVN newsreader, Eudora, and WSGopher.


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.


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.


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.


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):


($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.)


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:


(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.)


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.


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).


(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


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.


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.)


The file is in the directory /pub/access/hecker/internet and has the name
slip-ppp.txt.


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.