Personal computers help people be more productive in their organization. Most agree that's good. But most desktop computers now stand alone or are connected to a limited departmental server. That's not good, particularly since today's client/server, distributed-computing technologies can deliver valuable services to the desktop -- from intra-company e-mail to enterprisewide databases to the global Internet. Unix professionals know very well they have the power of the network and the means to deliver it to nearly everyone. Of course, because of the application base and because they are so prolific, most of the current activity in networking desktops as clients in the Unix distributed-computing enterprise revolves around Microsoft OS/Intel microprocessor-based PCs. That's where most of the complications lie, too. Other desktop systems like Apple Macs and Unix workstations long ago had built in what are now standard technologies for enterprisewide networking. PCs, on the other hand, are complicated by near-obsolete, oftentimes intractable hardware architectures and OS, and by a variety of competing networking hardware and software, each with its own installation rituals and interpretations of standard networking protocols. Although many of these problems are destined to be solved as vendors adopt standard, plug-and-play technologies in upcoming systems, all those legacy PC systems aren't going away soon. So roll up your sleeves and get to it.
Welcome to part two of a three-part series in this new monthly Connectivity column, connecting PCs to the Unix enterprise. Last month, we sorted out PC network interface cards (NIC) and began a discussion of network device drivers. This month, we complete device drivers and move on to a third layer of PC networking: protocols, with emphasis on TCP/IP.
NIC drivers
As we discovered last month, driver software acts to tie the underlying NIC
-- through a Media Access Control (MAC) layer -- to networking protocols
above. The currently popular drivers include Network Driver Interface
Specification (NDIS) from Microsoft (Redmond, WA), Open Datalink Interface
(ODI) from Novell (Provo, UT), and the Packet Driver Specification from NIC
manufacturer 3Com (Santa Clara, CA) and PC networking pioneer FTP Software
(North Andover, MA).
Microsoft's NDIS is available in two important versions. Version 2 is used mostly on the client side with DOS, Windows, and OS/2. NDIS 3 is Microsoft's new network interface driver for Windows NT client and server systems. It also can be used with Windows for Workgroups 3.11 and the upcoming Windows 95. Version 3 works in protected mode, which gives NDIS access to a larger memory space in the PC server than the "real mode" drivers in NDIS 2 that use the limited (conventional 640K) memory of DOS. Microsoft also provides support layers in NDIS for ODI so that applications can run with either protocol without reprogramming.
Novell's ODI provides the same functions as NDIS, although in a slightly different form. The MAC layer in ODI is called the Multiple Link Interface Driver. Novell calls its protocol multiplexer, which supports several different networking protocols, the Link Support Layer; Microsoft's protocol multiplexer is named Protman.
Packet drivers, created by 3Com and FTP Software in the mid-80s, are monolithic driver implementations. There aren't separate units for the protocol multiplexer and MAC layers. One packet driver can serve only one protocol stack, unlike NDIS and ODI. However, packet drivers remain popular because they are easily programmed and much of the public domain software uses the specification. There are ways to trick the PC system into running multiple stacks over one packet driver, such as with PKTINT and PKTMUX software, which are freely available on the Internet.
Three driver standards can cause confusion. Some applications and protocol stacks work only with one type of driver. In fact, not long ago, if you wrote a TCP/IP-based application for the PC, you also had to write all the TCP/IP networking code as well. There weren't any Unix-like sockets, for instance -- at least not until the coming of the Windows Sockets API. Today, we use "shims" (also obtained freely over the Internet) to coerce compatibility across the various driver standards by emulating and converting their APIs. For instance, the shims ODIPKT and DISPKT emulate a packet-driver interface on ODI and NDIS. And the ODINDIS shim emulates NDIS over ODI. Unfortunately, you cannot emulate ODI or NDIS over a packet driver because of the monolithic structure of packet drivers.
Protocol stacks
The next PC networking layer you have to deal with is the protocol stack.
This is the core protocol layer that creates, processes, and transports
network data. According to the standard ISO Open Systems Interconnect
definition, the Unix standard protocol TCP/IP consists of the network
(Internet Protocol, IP) and transport (Transmission Control Protocol, TCP;
or User Datagram Protocol, UDP) layers.
Of course, protocol stacks for PCs are not limited to TCP/IP. The popular NetWare protocol stack, for instance, consists of the network layer IPX (Internet Packet eXchange) with SPX (Sequenced Packet eXchange) or the improved SPX II at the transport layer. And if you have an underlying protocol multiplexer, as built into ODI or NDIS and which direct incoming and outgoing data packets along the proper networking channels, you can run several otherwise incompatible stacks at the same time, side by side. With the exception of the lower-layer network drivers and devices, the stacks run completely independently of one another. Nonetheless, we focus on TCP/IP because it is the protocol of choice for Unix systems, and it is rapidly becoming the de facto networking protocol standard for desktop systems.
The lack of formal support for networking in DOS and Windows (until Windows for Workgroups) has caused much turmoil and many headaches for developers. Today, there are three main ways of implementing a TCP/IP stack on a PC: a DOS-based Terminate and Stay Ready (TSR) program, the DOS equivalent of a Unix daemon; a Windows-based Dynamically Linked Library (DLL), a shared library containing all networking services; or a Windows-based Virtual Device Driver (VxD), a direct enhancement to the Windows system software itself. There are pros and cons for each of these TCP/IP stack implementations.
TSRs can be quite efficient and fast, and are the only way to do TCP/IP networking with DOS directly. However, all TSR implementations use a slice of conventional DOS memory and hence compete for precious memory with DOS applications. If you have to use TSRs for your DOS applications, look for ones that are loaded into extended memory and limit their use of conventional memory.
DLLs and VxDs work only in the Windows environment. DLLs contain all code for TCP/IP networking in a single library that is shared by all the network applications. DLLs are limited by the fact that they work only within the context of the application task. If the task is placed in the background and another CPU-intensive task is brought to the foreground, processing of network packets can severely slow down or even completely stop, which will result in lost packets and poor network response. DLLs also do not provide any networking support for DOS programs, even those running in a window within the Windows environment.
Originally developed as high-performance mouse, graphics, and sound device drivers, VxDs recently have been introduced as TCP/IP stack implementations. Since VxDs are integrated with the Windows OS, they are continually processed and thereby overcome the major problem associated with DLLs. And, since networking support through a VxD is available at all times -- even for a DOS program in a window within Windows, network traffic processing is smooth and fast. The only downside of VxDs is that they do not work directly in DOS.
The TCP/IP stack you select (probably VxD-based if you run Windows) should implement all the individual transport protocols of the IP family. Aside from TCP, UDP, and IP, there are also other less-popular ones like ICMP (Internet Control Messaging Protocol) that are needed for helpful applications like ping and traceroute, ARP (Address Resolution Protocol), BOOTP, and DHCP for host configuration, as well as SLIP, CSLIP, or PPP for serial and point-to-point links. Some TCP/IP implementations also go beyond the common protocols and implement higher-level services, such as RPC (Remote Procedure Calls) and NFS (Networked File System). At the highest layer of the stack, binding to applications as a library, is the Windows Sockets layer, an application and transport-neutral network communication paradigm and API.
PC TCP/IP products
The variety of commercial PC TCP/IP products are mostly protocol stacks and
the applications that run over TCP/IP. The leader in PC TCP/IP is Novell
with their LAN WorkPlace product, but several others follow close behind,
including FTP Software's PC/TCP and OnNet, PC-NFS from SunSoft (Mountain
View, CA), BW-Connect from Beame & Whiteside (Raleigh), Chameleon from
NetManage (Cupertino, CA), Air Series from Spry (Seattle), PathWay from The
Wollongong Group (Palo Alto, CA), and Acadia/IP from Ipswith (Wakefield,
MA), just to name a few.
Most of these packages come with common TCP/IP-based services, including telnet, ftp, an e-mail reader (SMTP or POP), and the distributed NFS. Several vendors include special products for Internet users in their TCP/IP package, including newsreaders, World Wide Web and Gopher browsers, and support for SLIP, CSLIP, and PPP dialup serial links. Popular bundles are Internet-in-a-Box from Spry, OnNet Explorer from FTP Software, Internet Chameleon from NetManage, and an upcoming, as-yet-unnamed package from The Wollongong Group.
Those who consider the breadth of third-party PC TCP/IP products healthy may soon be disappointed. This year we may see a significant shakeup in the market as software operating system giants Microsoft and IBM bring out bundled TCP/IP implementations and applications. Microsoft is not promising a full glory of applications, although both it and IBM's OS/2 Warp have stack and key networking applications, including a World Wide Web browser.
Top of the heap
Next month, in the final installment of this series, we will go into much
more detail about the configuration and installation of the protocol stack,
and will conclude with a discussion of the uppermost layer for PC
networking, the applications layers, with a focus on Winsock. 
About the author
Rawn Shah is a Unix and PC systems consultant with RTD Systems & Networking
of Tucson, AZ. Reach him at rawn.shah@advanced.com. He is also the author
of the PC-Mac TCP/IP & NFS FAQ.
![[Copyright 1995 Web Publishing Inc.]](/sunworldonline/icons/b-copyright95.gif){kind=icon}
If you have problems with this magazine, contact webmaster@sunworld.com
URL:
http://www.sunworld.com/asm-03-1995/asm-03-connectivity.html.
Last updated: 1 March 1995.