PCs will continue to dominate the desktop for some time to come. And for good reasons, too, not the least of which are the enormous base of available software and the low cost of computing power due to vendor competition in the mass market. But those benefits come with a trade-off. Current PC architectures and OS cannot deliver enterprise services, and connecting them to industrial-strength systems that do bring those services to the desktop, particularly Unix-based servers, is not a cakewalk for even the most technically adept system manager.
In previous issues, we laid a solid foundation for PC networking hardware and driver software to help you cut through many of the networking tangles, including a look at PC Ethernet cards, popular driver software, and protocol stacks for TCP/IP. We complete this introductory lesson by examining how TCP/IP software supports network applications and by looking at how you can use that new connection through ported versions of traditional workstation networking applications. TCP/IP stack configuration
Now that you have a network interface card, drivers, and an TCP/IP stack installed, there are a few configuration details to resolve. Protocol stacks differ, each requiring individual configuration attentions that only the accompanying documentation can resolve. However, there are some TCP/IP parameters suitable for most PCs and some that also help improve network performance. We focus on Microsoft Windows TSR- and VxD-based stacks; DOS-based DLLs are rapidly becoming obsolete. Also, a quick note: Wherever possible, load all TSR stacks into high (extended) memory to increase the availability of low (conventional) memory space.
Data packet fragmentation regularly occurs when sending data over a TCP/IP WAN. Normally it does not occur within a LAN. Most IP-capable machines know how to reassemble fragments; in fact, this is a requirement of IP stacks. If too much fragmentation occurs, the IP stack spends more of its time waiting for the different fragments of the packets and fragment reassembly, which reduces the efficiency of communications.
Set the maximum transfer unit (MTU) for a data frame or packet over an Ethernet, including protocol headers, to 1,500 bytes or 1,492 bytes if you use IEEE Ethernet. Fragmentation will occur if you transmit larger packets. Also, set the maximum segment size (MSS), which is the IP packet minus headers, to 1,456 bytes. If you use Serial Link Internet Protocol (SLIP), Compressed SLIP (CSLIP), or Point-to-Point Protocol (PPP) for serial IP connections, use a 256-byte MTU and 212-byte MSS maximums because of their reduced bandwidths.
The TCP "window-size" parameter is the amount of data, in packets, that can be transmitted to a remote system before requiring an acknowledgment that the packets have been received intact. It is kept to fixed-size integrals of the MTU, usually four times the MTU. For TSRs, 1,024 bytes is a common value, although some stacks can handle up to 4,096 bytes. VxDs can handle around 8,192 bytes. For SLIP, CSLIP, or PPP, limit the size to 1,024 bytes to coincide with four times 256 bytes.
Some TCP/IP stacks will allow you to allocate system memory for the number of huge (8 kilobytes), large (approximately 1,500 bytes for Ethernet), and small packets (256 or 512 bytes). TSRs should be limited to between 0 and 5 huge, 2 to 10 large, and 2 to 10 small packets. VxDs have access to larger amounts of memory, so set it up to allocate memory for 10 to 30 huge packets, 10 to 30 large, and 20 to 80 small packets. In all cases, check in your software manual for the vendor's recommendations. Start with 75 percent of the maximum of the range for 486 or better machines and 50 percent or lower with smaller machines. These values affect the speed of your computer system, and you need to adjust them according to the power of your machine.
(PC)NFS
One of the most fundamental enterprise-computing services is a distributed filing system. Among the various distributed filesystems, NFS is the most popular. There are NFS protocol implementations for PCs, which interface directly with an undocumented software interrupt within DOS to redirect file I/O over the network. Without this interrupt in much earlier versions of DOS, there was no real way to add virtual drives. With MS-DOS 3.0 and Microsoft's failed attempt at MS-NET, this undocumented feature was introduced to allow PCs to use network drives.
With virtual DOS drives, you are still limited by the DOS File Access Table, meaning that file protections, ownership, and group ownership are not directly stored with the file. The (PC)NFS software installs a "redirector" that takes any calls to this virtual drive and routes the traffic to the stack. (PC)NFS is tightly coupled with a Unix NFS server to authenticate users and groups over the network. This can be confusing.
For instance, there is no Winsock-based NFS client or server. The Winsock specification was not created for that purpose. Since NFS on PCs speaks directly to the system through the software interrupt and not through Windows API calls, it lies beyond the scope of the sockets-based library.
Winsock
The Windows Sockets (Winsock) API is a standard layer for network communications developed by Microsoft, SunSoft, Novell, and FTP Software. Originally based on the Berkeley Sockets concept available on all BSD systems, the Winsock standard also addresses inter-process communication across networks for several other protocols, currently including TCP/IP and IPX/SPX. In the future, Winsock will standardize other popular networking systems, such as ISDN, wireless networks, AppleTalk, and OSI.
The Winsock layer is the equivalent of the Presentation layer for the PC protocols. It is a generic interface for applications that shields programmers from the complexities of underlying protocol stacks. However, Winsock is not comprehensive in its current incarnation; some stack vendor-specific code is still required, leading to incompatibilities among some network applications and underlying stacks. Hence, beware the claim "Winsock-compatible."
Nonetheless, a wave of software based on the Winsock standard, but which do not rely on stack vendor-specific code, has given rise to a plethora of new network software for PCs. And with PCs' newfound connections to the networked enterprise as well as performance boosts from the new Pentium microprocessors, software once reserved primarily for Unix and other workstations has started to appear on PCs.
X Window System is a good example; it now runs on generally available, high-performance PCs without the jerkiness and slow performance that limited its use on older 486-based systems. PC X servers have yet to come close, let alone match, the performance of a dedicated X terminal (See our comparative review, "PC-based X servers: Features, no pep," August 1994). But for many installations, the performance trade-off is balanced by the PC's versatility, and PC X Window server sales are predicted to grow from $84.9 to $298.5 million in sales by 1998, according to a mid-year report of the X Business Group.
Enterprisewide e-mail software for PCs is another fundamental distributed application that is becoming increasingly important to the PC desktop. Although many vendors are attempting to enhance their products, bringing them up from the LAN to the WAN, many still fall short when it comes to handling foreign e-mail systems. Current guidelines suggest you purchase PC e-mail systems based on the Internet's Simple Mail Transfer Protocol, Post Office Protocol, Interactive Mail Access Protocol, and perhaps with Multipurpose Internet Mail Extensions standards over TCP/IP. That way, your PCs will be compatible with nearly all internetworked Unix systems, including those of the global Internet.
Speaking of the Internet, it is one of the fastest growing areas of the PC TCP/IP software development. PC implementations of telnet and ftp have been around for some time, but they just don't hack it in the GUI-based marketplace of Windows and Macintosh System 7. Recently, vendors have begun compiling PC versions of Internet Usenet newsreaders, Gopher managers, and World Wide Web browsers. A number of vendors even bundle these Internet-surfing products with their PC TCP/IP stacks.
Next: batteries included
We have only scratched the surface of PC-to-Unix connectivity topics. In the coming months, we will solve some of the knottier problems in finer detail, and we'll take a look at a selection of new products that bring the enterprise to the desktop in new and innovative ways. 
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-04-1995/asm-04-connectivity.html
Last updated: 1 April 1995