Clicking on a section heading will get you back to this table
of contents.
There are several different ways to physically interconnect computers:
serial ports, parallel ports, or adapters to special media. Examples of
special media include Ethernet, Token Ring, ISDN, and a few others.
If you use a serial port, you have the choice of a direct
serial line connection using a null modem cable, or a connection using
a modem at both ends. (In the latter case, you can of course insert
a telephone line between the two modems.) There are probably
other possibilities that I haven't thought of.
Having chosen a physical medium, you still have to choose a protocol.
The protocol is a set of rules describing things like the format
of network messages. I haven't explored this subject in detail, but
I know that OS/2 includes support for several different network protocols.
You specify which one you're going to use when you install the
networking support.
Networking software is almost always implemented as a number of
separate software layers. There are at least two good reasons for
doing it this way:
- If you want to create reliable and error-free software, then
you need to break the job down into independent modules. The
person or team responsible for the low-level details shouldn't
have to worry about the high-level part, and vice versa.
Layering is one good way of breaking a complex job into
more manageable modules.
- If all the device-dependence is concentrated into the lowest
layers, the higher layers can be made "universal", in the sense
that they're independent of what sort of network is operating.
To add support for a new transport medium, or a new protocol,
you only have to modify a small part of the software, and leave
the rest unchanged.
As nearly as I can judge, OS/2 breaks the networking software into
four layers. (Four is not really enough, but I presume that there are
also internal sub-layers that we're not told about.) The layers are:
- Network layer: the device drivers, SLIP implementation, and similar
details. This is the part of the software that talks to the hardware.
- Internetwork layer: implementation of the Internet Protocol (IP),
Internet Control Message Protocol (ICMP), and Address Resolution
Protocol (ARP). The main job of this layer is to format messages
in the form expected by the network, and to decode the incoming
messages - in particular, answering the vital question "is this
message for me?".
- Transport layer: implementation of the Transmission Control Protocol
(TCP) and User Datagram Protocol (UDP). A major part of the effort
here is solving the routing problem: how do we get the message from
the source to the destination?
- Application layer: a variety of programs to give user services such
as FTP, Telnet, and so on.
The term TCP/IP refers to a network implementation where TCP is used
for the high-level part of the implementation and IP is used for the
low-level part. Because this is the best-known implementation of
networking, the OS/2 designers have chosen to use the name TCP/IP
as the "generic" name for the overall networking package. Strictly
speaking this is an abuse of terminology; but you might as well get used
to it, because that's what all the documentation refers to.
In this documentation, I'm concentrating mostly on an overview of
what's provided in OS/2 networking. Most of my experience is with
two special (but very common) cases: TCP/IP using Ethernet, and
dial-up operations using a modem and PPP. If you want more
detail, there are three good places to look:
- John Summerfield
has a lot of
information about the practical configuration details, including help on setting
up a home LAN. See also his pointer to Tony Rall - Tony is an
expert on the lesser-understood aspects of how OS/2 networking
support works.
-
John Silvia has some very useful information
about the application programs - for example, explanations of how
to get Ultimail Lite to work.
- Judging from what I've seen in newsgroups, a lot of people haven't
yet realised that Warp 4 has a lot more on-line information than Warp 3.
If you check your desktop Information folder, you'll find several
TCP/IP books; these contain a lot of valuable information.
To have a world-wide network, it is necessary to ensure that every
machine in the network has a unique address. To ensure this, there
is a central coordinating organisation (InterNIC) that hands out the addresses.
You get the address when you install your network adapter - the adapter
is configured to respond to that address, and no other. (More precisely:
the adapter hardware responds to a unique 48-bit address, and software
in your LAN handles the translation between 48-bit hardware addresses
and 32-bit IP addresses.) You don't
necessarily have to apply directly to InterNIC to get
the address. A more common arrangement is that a company, or
other large organisation, is allocated a range of IP addresses, which
can then be given to that organisation's users.
These IP addresses are 32-bit numbers. (One day, no doubt, we'll
have to switch to longer addresses - it's completely analogous to the
situation of countries which have had to introduce longer telephone
numbers - but for now 32 bits are sufficient.) For ease of reading,
it's usual to break this up into four eight-bit groups, and to write
the value of each eight-bit part as a decimal number. Some software
even expects you to type it in that way. That's why you'll see
numbers like 159.87.6.215 - it's just a convenient way of encoding
the 32-bit value.
(That's just a number I picked at random, by the way. I have no
idea who it belongs to; and I sincerely hope that nobody reading this
will be tempted to annoy that person with unsolicited messages.)
The addresses are assigned hierarchically, with the hierarchy being
defined by "subnet masks". For example, one of my computers is
connected to a LAN (Local Area Network) with a subnet mask of
255.255.254.0. This means that my 32-bit IP address is made up
of a 23-bit subnet identifier and a 9-bit local address. All machines
whose addresses match mine in the first 23 bits are part of the
same subnet. This breakup affects the treatment of certain broadcast
messages, i.e. messages that are sent to all machines in the
subnet. It's also relevant to routing decisions, because it allows the
software to know which machines are "local" machines and which ones
are more remote.
What if you dial in via a modem, and don't have a network adaptor?
In that case your Internet Service Provider (ISP), i.e. the company that
runs the dial-in server, allocates the IP address to you, from a pool
of addresses that it "owns". Most commonly the ISP doesn't own
enough IP addresses to allocate one to each registered user, so instead
it uses a system of "dynamic IP allocation". The address is assigned
when you dial in, and you won't necessarily get the same address
the next time you dial in.
A third possibility is that you have a local network that's not
connected to the rest of the world. For example, you might have
three computers at home, and you want them to be able to communicate
with one another. In such cases there's no risk of conflicting with
someone else's address, so you're free to invent your own IP addresses
in any way you like. Even in this case, it would be a good idea to
get legal addresses assigned by InterNIC, to keep your options open for
future network expansion.
A 32-bit node identifier is convenient for software, but it's not
particularly readable for humans. For the convenience of the users, we
also give each network node a name, in the form of a readable
text string.
Unlike the node number, this name is not stored in the interface
adaptor. Instead, it's encoded (usually by your local network administrator)
in a table maintained by a local nameserver. I'll get back to the topic
of nameservers in a later section.
A Local Area Network (LAN) is a network that has a small geographical
extent - perhaps just one room, perhaps a few adjacent buildings. To
qualify as a LAN, it should be a homogenous network, in the sense
that the same communications protocols are used throughout the LAN.
Typically a LAN has a very simple topology: a ring; a group of machines
on a common bus; a star network where everything is connected to a
common central node; or something equally simple. One virtue of a
simple topology is that the routing problem becomes elementary.
Any machine on a LAN can easily send a message to another machine
on the same LAN. On a ring network, for example, all that's necessary
is to send a message around the ring, until the destination machine
recognises its address in the message header and consumes the message.
Of course, you have to guard against a message that circulates forever.
That, however, is just one aspect of error recovery, and error recovery
tends to be complex no matter what sort of network you have.
A LAN can connect to another LAN. The way to do this is to have one
node, called a gateway (or sometimes a bridge), which is a member of both LANs.
The gateway machine makes some important routing decisions. By looking at the
destination node numbers of the passing messages, it can work out
which of those messages should stay on their own LAN, and which should
be transferred to another LAN. If the two LANs use different transmission
protocols, the gateway also has the responsibility of translating the
message formats.
Sometimes one of the participating networks is too big to be called
a "local area" network. In this case the terminology changes, but
the principles remain much the same.
One very common arrangement is to have a number of different LANs,
all with gateways to a common "backbone" network. This is a standard
networking arrangement for a company with many different divisions,
for example, or a university with a number of different departments.
And then, of course, the backbone network can itself have a gateway
to a larger wide area network. Continuing in this way, we end up with
a "network of networks" that spreads across the entire world.
If you want to send an e-mail to me, you can address it to
peter@ee.newcastle.edu.au. In all likelihood, you're half a world away
from me. How then does your machine work out how to find my
machine?
The first necessary step is to translate the name ee.newcastle.edu.au
into an IP node number.
- First, your software looks for an optional HOSTS file. (In Warp
4, this file normally lives in the \TCPIP\ETC directory. It won't
exist, however, unless you've created it yourself.) This contains
a list, usually short, of node numbers for "frequently accessed"
destinations.
- If this lookup fails - as it will, in most cases - your software
sends a request to a nearby machine called a nameserver.
(When you're configuring your networking software, you have to
specify the IP number of your local nameserver.) The nameserver
is a machine that maintains a big list of node names and their
node numbers.
(Remark: actually, the search order is a configuration option. You can
specify whether the HOSTS file or the nameserver is checked first.)
Of course no nameserver is likely to know about every machine in
the world. Usually its tables cover only the local machines, plus
a collection of frequently accessed remote sites. Some of those
remote sites are themselves nameservers. Any request that can't
be dealt with locally is passed on to one or more other nameservers.
Sensible network administrators name their machines according to
a hierarchical scheme. If your nameserver doesn't know about
ee.newcastle.edu.au, it does at least know that it ends with the
country code for Australia. It will therefore start its search by
contacting a nameserver that knows about .au addresses; that
machine will, in turn, know how to contact a nameserver that
knows about the .edu.au domain; and so on down the line. This
means that the chain of nameserver requests will terminate
after a very small number of iterations.
Now your software knows the node number; but it still doesn't
know what route to take to reach that node. To solve that problem,
it contacts another local machine called a router. The router
has tables covering the nodes it knows about. For the ones it
doesn't know about, it passes on a request to another router.
This might lead to a whole flurry of requests of the form
"who knows about this node?"; eventually, one of them will reach
a router that does know the answer.
This sounds like a haphazard procedure, but in practice it's quite
fast. A routing request can span the world in less time than it
takes a "Make Money Fast" scheme to collapse.
You can install support for networking at the time you install OS/2.
Alternatively, you can run the "Selective Install for Networking" program
at any later time. This program can be found in the Install/Remove folder
of the System Setup folder.
If your only network support is via a modem, the procedure is fairly
simple. Specify that you want TCP/IP installed, and then select the
"No network adapter" option. All other details can be configured later,
when you're configuring the dialler.
If you're connected to a LAN, you have to specify many more details.
In most cases the installer will auto-detect your network adapter,
so you won't have to worry about that detail. (You do, however, have
to beware of interrupt and I/O port conflicts. In my own case it took
several failed installations before I finally realised that my sound card
was using the same I/O ports as the ethernet card.) But you will
need to write down some information before you start the installation.
The information you need is:
- The type of network you're connected to. This will vary from one
case to another. You can't just arbitrarily choose one; you have
to choose an option that's compatible with the existing network.
- The IP number and node name of your network adaptor.
- The IP number of your nearest router, and the IP number of at
least one local nameserver.
- The subnet mask - a four-byte number that serves to distinguish
local IP addresses from remote ones.
All of this information should be available from your local network
administrator. (If you yourself are the network administrator, then I'm
afraid you need to know more about networks than I can cover in these
brief notes. If you do get stuck, your best option is to talk to someone
who has installed a similar network.)
This section applies only to people who wish to connect via a modem.
To use a dial-in connection, you must have an account with an Internet
Service Provider (ISP). If you choose Advantis as your ISP, you have the
option of dialling first and only then creating your account. I'd suggest,
however, that you first shop around and check the charges imposed by
the ISPs in your area. They could be higher or lower than the Advantis
charges, depending on the level of competition where you live.
To find the dialler, look in the Programs folder and then the Internet (modem)
folder. The IBM dialler is the one that connects you to the Advantis
system. It's a long time since I've tried it, but as I recall it the
instructions on what to do next are fairly explicit.
If you use an ISP other than Advantis, the IBM dialler is useless to you.
Instead, you should use the "Dial other internet providers" program.
Start this up, and click on the "Add entry" button. This opens a
four-page notebook, which you have to fill in with details like
your login name, password, etc. These details should have been supplied
to you by your ISP.
One of the choices you have to make is whether to use SLIP (Serial Line
Interchange Protocol) or PPP (Point to Point Protocol). These are
similar, with PPP being perhaps marginally superior. In many cases
your ISP will support only one of the two, and will tell you which one
you have to use.
If you have trouble configuring the dialler, fetch the file
os2ppp.zip.
This contains detailed instructions for setting up the dialler for one
particular ISP (mine, as it happens). The details for your ISP will be
different, of course, but at least you'll have a model to work from.
Most network applications use a client-server approach. The client program
is usually the one at your end. You give it commands, and it turns those
commands into requests that it sends to a server program running on some
other machine. The server responds by doing the requested operation;
typically this means returning data back to your machine.
Here is a list of the network clients that you are most likely to need.
- FTP, which stands for file transfer protocol. This allows you to
copy files from your machine to a remote machine, or vice versa.
In principle this requires you to have an account (with login name and
password) on the remote machine. In practice, a great many FTP
servers permit anonymous FTP, which is available to anyone.
To use anonymous FTP, you log in with username "anonymous",
and give your e-mail address as a password. (Naturally,
anonymous users have some restrictions on what they're allowed to do.)
- Telnet. This is a program that, in effect, makes your computer a
remote terminal to some other computer. Anonymous login is
usually not supported, so telnet is useful only on those computers
where you have a genuine user account.
- WWW browser. If you're reading this then you already know what
that is. The program at the other end is called a WWW server,
or - more accurately - an HTTP server. HTTP stands for
Hypertext Transfer Protocol.
- Gopher. A gopher server is similar in many ways to an HTTP
server. Gopher servers seem to be going out of fashion now
that HTTP is so popular, but there are still a few around.
- E-mail clients. These let you send and receive electronic mail.
- Newsreaders. These let you read the messages stored on a
news server, and also to post new messages. News servers
exchange data with neighbouring news servers; after some
time delay (anything from hours to a couple of weeks), messages
you post to your local news server end up appearing on
thousands of other news servers around the world.
- File and print clients. These let you use disks and printers on
other machines almost as if they were connected to your own
machine. For obvious reasons this is a purely local facility,
available only for machines on the same LAN. Precisely
what you get here depends on what sort of LAN you're
connected to. (In my own case, I can send files to a shared
printer but don't have any shared-file access.)
OS/2 Warp (version 3 or better) comes well supplied with network
client software. All of the programs mentioned above are available to
anyone who has installed TCP/IP support. If you don't like the
supplied versions, there are plenty of third-party alternatives - some
free, some shareware, some commercial.
Before deciding to run any network server, be sure that you have a need
for it. Servers allow remote users to access data on your machine; if
you don't know what you're doing, you can create a security hole.
In addition, the server software takes up space and processor time. The
average OS/2 user probably won't want to run any server software.
Having said that, it must be added that there are certainly some
situations where it's well worth running some server programs.
I run several myself. Among other things, this makes it easy to
copy files between my home and office computers.
To enable one or more of the built-in servers, run the program
"TCP/IP Configuration (LAN)", and go to the Autostart page.
This allows you to set up the following programs.
- inetd: this is a special case, which will be discussed below.
- telnetd: a Telnet server. If you run this, make sure that
you specify a password on the Security page.
- ftpd: an FTP server. You specify which users are allowed
access by adding entries to the TRUSERS list on the Security
page. See also the "TCP/IP Readme" in the Information/Readme
folder, for some new features which are not documented elsewhere.
- tftpd: a simpler FTP server, with fewer features. It has no
password protection, so I suggest you don't run it except in
situations where there is no physical way for untrusted users
to access the computer.
- rexecd: allows a remote user to issue REXEC (remote
execution) commands, each of which can start a program on
your machine.
- rshd: similar to rexecd, but with no password protection.
- lpd: allows users on other machines to send print jobs to
the printer on your machine.
- lprportd: the partner of lpd. Running this allows you to send
print jobs to remote printers (assuming, of course, that the
owner of the remote printer has enabled this feature).
- routed: software that allows your computer to function as
a router. Don't run this unless you really need it. Most
commonly there will be some other machine in your LAN that's
responsible for routing, and if so you don't want the overhead
of duplicating its function.
- portmap: permits clients to look up the port number of any
server service that your machine is running. This "port number"
is not the same as an I/O port. It's more like an identification
number whose function is to distinguish the different servers
from one another. Most servers are configured to use "well-known
port numbers" - e.g. FTP servers almost always listen for
incoming commands on port number 21. There's no real need
for portmap if everyone sticks to the standard port numbers.
- sendmail: functions as either a server or a client, depending
on the parameters given to it. The sendmail server listens for
incoming mail, and also sends outbound mail that has been
queued. The sendmail client is the program you call to
send a message. Most people don't need to interact with
sendmail directly; it's more common to use higher-level
e-mail software that looks after these details for you.
- talkd: the talk daemon, which permits messages to be
exchanged between a pair of computers as they are being
typed. In my experience "talk" is popular with new users,
but is often disabled by more experienced users, who prefer
not to be interrupted in the middle of a task for a message
that probably wasn't urgent anyway.
One problem with running network server software is that it consumes
processor time and memory. This is acceptable on a machine whose
primary function is to be a server, but it can be a nuisance when
the machine is also your own personal workstation. As a compromise,
you can run the "inetd super server". This is a "listener" program
whose function is to detect incoming requests, and to start up
the actual servers (for ftp, telnet, etc) as they are needed. Several
of the servers in the above list have the option of being started
from inetd. The disadvantage is a slight extra time delay for the
remote client, because the server is not started until a request
comes in for it. The advantage is that those server programs are
not consuming resources when they're not in use.
Warning: if you run any third-party servers from inetd, make sure
you keep a backup of \MPTN\ETC\INETD.LST. Every time you
run the TCP/IP configuration utility, it deletes any customizations
you've made to that file, and you have to reinsert them manually.
There's no HTTP server included with OS/2, but it's easy to
add one if you want it. There are several good (and mostly free)
HTTP servers available.
[ Part 1 | Part 2 | Part 3 ]
This information was compiled by
Peter Moylan.
Please send complaints, criticisms, praise, corrections, suggestions, etc. to
peter@ee.newcastle.edu.au
Last modified: 23 July 2004