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.
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: 17 April, 1997
