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