Open Computing: ``Hands-On'': ``PC-Unix Connection'' Column: September 94

The LAN Link

A primer on the hardware and software you'll need to make an Ethernet link from
desktop to host

By Tom Yager

Last month, I wrote about using serial port links to tie PC systems to their
Unix counterparts. This month I provide the basics of making high-speed
local-area network connections between DOS or Windows and Unix.

Why not use Unix on the desktop? You could, but that would leave you out of
touch with the millions of PC and Macintosh users out there. Even Novell Inc.,
maker of Unixware, has chosen to abandon the desktop market as a target for
Unix. Novell has decided the most profitable role for Unix is as a server.

That Unix can't compete with Windows and Macintosh systems on their turf
shouldn't surprise anyone who's used Unix. It is, without a doubt, more
powerful. It cannot, however, touch commodity platforms for ease of use and
administration. Within the limits of their capabilities, Windows and Mac
systems give users exactly what they want. It'll stay that way until something
better comes along. We've already learned that ``better'' doesn't necessarily
translate to ``technically superior.'' Now Novell has learned that lesson, too.

Fans and admirers of Unix shouldn't begrudge commodity desktop systems their
success. The future of Unix lies in its ability to tie all kinds of systems
together. As a server, it's tops. And without the ``wimpy'' commodity systems,
our favorite operating system will have nothing to serve.

In the Cards

The first step in getting your systems connected is to equip the PC with a
compatible network adapter. Take your pick: Ethernet, token ring, fiber. I use
Ethernet in my network, so that's what I'll describe. In general, I've found it
easier to get the PC speaking the Unix host's topology and protocol than the
reverse. In my lab, that means Ethernet and TCP/IP.

There are dozens of Ethernet cards to choose from for the PC, and each claims
some advantage over the others. My only advice is to stay within name brands
(SMC is a favorite of mine) or those 100 percent compatible with name brands
and to use a board with at least a 16-bit bus interface. The latter comes not
from a concern over throughput-good eight-bit cards have surprisingly good
performance-but rather configurability. A 16-bit Ethernet adapter will support
a broader range of potential IRQ (interrupt request) settings than 8-bit boards
can. It may not matter in your systems, but in mine, I've been forced at times
to sacrifice printer and serial ports to free up IRQs for network cards.

Ethernet 10BaseT or 10Base2? It's purely a matter of what you're set up for.
For any new installation, 10Base2 (twisted pair) is certainly the smarter
choice. I expect that 10BaseT (coax) will eventually disappear as twisted-pair
concentrators get cheaper.

With PCs, and with portable PCs in particular, there's one other option to
consider: parallel-port adapters. The parallel I/O, or printer port, on most
PCs is able to pass data faster than standard serial ports. Several companies,
with Xircom Inc. (Calabasas, Calif.) in the lead, offer cigarette-pack-sized
boxes that have a parallel-port connector on one side and an Ethernet port
(twisted pair or coax) on the other. These adapters come with software that
masquerades as board-level drivers, so network protocol software doesn't know
the difference.

The cost of convenience is performance, but it's not that steep a price. With a
bi-directional parallel port, the speed of a good adapter approaches that of an
eight-bit internal card. It's fast enough for everything from file transfer to
X Window sessions.

TCP/IP Software

There are a lot of choices with TCP/IP software as well. A dilemma for you is:
would you rather have complete Windows point-and-click functionality or a more
Unix-like command-line interface? You can't have both, at least not now, so you
must choose one approach or the other.

If you're installing TCP/IP primarily to enable some Windows- based network
client like X Window, then you should probably choose one of the Windows-hosted
TCP/IP products. I've used Netmanage Inc.'s (Cupertino, Calif.) Chameleon, and
Walker Richer & Quinn's (Seattle) Reflection Network Series beta software just
arrived. These, and others like them, have the advantage of using comparatively
little DOS memory because most of the TCP/IP functionality is loaded under
Windows. Because Windows has virtual memory and no 640-kilobyte limit, that's
just where TCP/IP belongs.

On the other side of the DOS and Windows divide lies packages like FTP Software
Inc.'s (North Andover, Mass.) PC/TCP and Sunselect's (Mountain View, Calif.)
PC-NFS. These provide Windows clients, but they load almost entirely into DOS
memory. The advantage, especially in PC/TCP's case, is that a full set of DOS
commands are included. These mimic the behavior of same- named Unix
counterparts (rsh, rcp, ftp, and so on) and help Unix users cross over to the
PC easily. The disadvantage is that, even with some pretty fancy memory
management, the fully loaded software leaves many commercial DOS packages
without enough room to run. Or at least they don't run efficiently. I tried
running a DOS tape backup package while PC/TCP was loaded, but instead of
streaming data to tape at full speed like normal, it went haltingly and took
forever. Fortunately, DOS 6.x has support for multiple configurations. Now I
have my PC/TCP configuration and my maximum memory configuration. I reboot to
switch between them. It's an inconvenience, but nothing compared to the old
way.

Windows-hosted TCP/IP packages always include graphical versions of common
commands. The ftp utility, instead of being command-driven, becomes a
point-and-click application with graphical file selection, one-button log-ins,
and other amenities. It certainly takes the sting out of ftp transfers for
those not accustomed to Unix. But for those of us who are, it is one example of
a graphical interface that gets in the way more than it helps. As you would
expect of a power user, I want both. FTP's PC/TCP and WRQ's Reflection offer a
combination of command-line and mouse- driven versions of ftp. I'd like to see
all PC TCP/IP packages invoke similar duality for all commands. PC/TCP is the
only package I've worked with so far that manages it.

Installation of these packages requires a network driver for the adapter you've
chosen. If you follow my advice about name brands, then the TCP/IP package
probably includes a driver for your adapter. If you stray into the off-brands,
you may have to load and configure a driver by hand using software that comes
with the adapter.

DOS network drivers have, thankfully, been standardized. All commercial TCP/IP
packages now operate with these standardized drivers, which fall roughly into
three categories: NDIS, ODI, and Packet Driver. NDIS (Network Driver Interface
Specification) is the most common; I haven't yet seen a network card, even a
cheap one, that didn't include NDIS drivers. NDIS drivers have the disadvantage
of being difficult to configure by hand. All the more reason to stick with a
name-brand network adapter so the software can do the configuring for you.
Packet Drivers were previously a popular choice, particularly for PC/TCP. ODI
(Open Data-Link Interface) is an alternative that's not seeing much use just
yet.

I'll leave the subject of configuring adapters to the hardware manuals. Suffice
it to say that the vast majority of networking problems can be traced back to
erroneous IRQ, I/O port, and memory address settings. The software that comes
with your card should include some type of diagnostic software. Use these tools
to test the settings you've chosen before you install TCP/IP.

What You Get

Once your network card and drivers are installed, loading TCP/IP should be a
breeze. You need to assign an IP address for your PC. You should also load in
the IP address and name of one Unix host. Test the network link using the ping
command (or graphical equivalent), and then use ftp to copy the hosts file from
your Unix system to your PC.

Commercial TCP/IP packages vary in their functions and services. PC/TCP
delivers a rich set of BSD Unix-style TCP/IP commands, running in DOS, for
terminal emulation, remote execution, remote tape and archiving operations,
file transfer, and, through Interdrive, NFS drive mounting. Everything's
client-only except for ftp and smtp servers that you can either run standalone
under DOS or in the background under Windows. All of the PC/TCP commands
operate under Windows using DOS command windows.

Netmanage's Chameleon NFS goes far lighter on the commands but offers
Windows-hosted NFS, ftp, and other servers. There's no inbound terminal
emulation (I haven't yet seen that for DOS/Windows TCP/IP), but Chameleon's
server functions make a Windows PC behave more like an equal partner on a Unix
LAN.

The PC TCP/IP networking software isn't always the end of the road. Perhaps the
most popular add-on is X Window, which requires TCP/IP to make its host
connections. There are a lot of choices here as well: Hummingbird
Communications Ltd. (Markham, Ontario, Canada), Netmanage Inc. (Cupertino,
Calif.) and Network Computing Devices Inc. (Mountain View, Calif.), AGE Logic
Inc. (San Diego, Calif.), and WRQ are just a few of the packages I've used. A
Windows PC with a fast graphics card makes a better X terminal than most X
terminals do, and the cost is comparable, sometimes even lower.

Once you get the TCP/IP layer going, your PC takes on new capabilities that go
beyond terminals and files. Database managers, online browsers (like Mosaic),
vertical applications, and others rely on TCP/IP to make the most of shared
networks. PCs, even fast ones, are cheap and easy to use. In my own lab, I use
a Windows PC to make connections to all of my Unix hosts. I've tried other ways
but, in a mixed environment, the PC is simply the best choice for a
multipurpose front end. With the addition of TCP/IP, the DOS/Windows PC becomes
an indispensable network client.

Tom Yager is an Open Computing contributing editor. He can be reached through
the Internet at tyager@maxx.net.

-------------------------------------------------------------------------------
Copyright © 1995 The McGraw-Hill Companies, Inc. All Rights Reserved.
Edited by Becca Thomas / Online Editor / UnixWorld Online / beccat@wcmh.com

 [Go to Content]   [Search Editorial]

HTML markup by Tim Cooley
Last Modified: Wednesday, 23-Aug-95 17:25:49 PDT