Providing Internet Services to LAN Users Assuming you've decided to install a dedicated LAN-to-Internet connection, a number of technical and administrative issues surrounding the delivery of Internet services within your organization need to be considered. The precise nature of these issues will vary according to your motivation in installing an Internet connection. If your only purpose is to set up a server on the World Wide Web, you've got a more limited set of issues to deal with than if you want to provide all of your desktop computer users with a full range of Internet services. Connectivity Host-oriented Approaches The simplest approach to providing Internet services to a group of users is through an Internet-compatible host computer, or timesharing, system. Most mini and mainframe computer systems can be configured to support TCP/IP. And once they are set up for this, terminal users can access many Internet services, including e-mail, Telnet, FTP, UseNet News and text-oriented Web services. This system can be configured to act as an Internet host for applications such as mail, Web, FTP and Domain Name Services (DNS). Host-oriented approaches are the easiest to manage, since there's no need to administer addresses and install software on client machines. Client-oriented Approaches Although a host-oriented approach may be desirable for some sites, most will likely opt for a more client-oriented approach to Internet services. By configuring your desktop computers with a TCP/IP protocol stack and Internet application software, you can off-load processing from host systems while providing users with higher-quality graphical applications. Still, installing and maintaining this software can be both complex and time consuming, so considerable advanced planning is in order. Client Software: Selection We'll focus our discussion of client software to the Windows environment, though the same basic principles also apply to Macintosh or OS/2 systems. The first step in configuring your client machines for Internet access involves the selection of appropriate TCP/IP software for those clients. Microsoft offers a free and functional TCP/IP stack with Windows for Workgroups 3.11 and Windows95. Most users will find these stacks adequate for their needs. Alternatively, there are a number of shareware and commercial TCP/IP stacks available and most of the latter also come with a range of client applications. The most popular shareware TCP/IP stack for Windows is Trumpet WinSock, available from Trumpet Software International in Australia. This application is widely available throughout the Internet, so getting your hands on it shouldn't be too difficult. Trumpet WinSock includes support for both LAN-based and dial-up configurations, the latter via SLIP or PPP protocols, and it presents a Win dows Sockets, or WinSock interface to higher-layer applications. Complementing Trumpet WinSock is a variety of freeware or shareware Internet applications for Telnet, FTP, UseNet News and e-mail. Many of these applications are considered by analysts to be superior to commercial alternatives. On the down side, you'll have to depend on alternative channels for support, and this may be inappropriate for many organizations. The market for commercial TCP/IP stacks and applications for Windows is very competitive, with new and enhanced products entering the marketplace on a regular basis. Nearly all are mature products with sophisticated applications. Given the fact that Microsoft is now bundling a capable TCP/IP stack with their Windows operating systems, we recommend that you focus on the quality of the applications themselves and the level of support available from the vendor. If you opt for a commercial TCP/IP stack, look for a product that is implemented as a Windows virtual device driver, or VxD. Client Software: Deployment Once you have selected a product, deploying it on your client machines becomes the next challenge. Most likely, you will install the stack itself on the local hard disk of each machine, though sites that load Windows from file servers may opt for a more server-oriented approach that will significantly simplify the installation of upgrades. The applications themselves can also be loaded locally, but installation on a server will save time in the long-run. Give serious consideration to the implementation of a BOOTP or DHCP server for TCP/IP address allocation as this will simplify administration, reduce the probability of duplicate addresses and facilitate mobility for laptop users. TCP/IP Gateways A final alternative that might be worth considering is the use of a TCP/IP gateway. These systems usually run on a file server and act as translators between proprietary LAN protocols like Novell's IPX and TCP/IP. In the case of NetWare, the gateway is installed as a series of NLMs on the server and a small WinSock client interface is installed on the client to trick the applications into thinking the device is running TCP/IP. While these gateways impose additional load on your server, they reduce the complexities associated with address administration. Applications The deployment of Internet application services can be a fairly complex undertaking, though the release of newer and easier to use application servers on a variety of platforms is making this a more manageable task for those who are inexperienced with Internet technologies. By far, the three most popular Internet server applications are e-mail, FTP and Web services. You have the option of either purchasing a server preconfigured to provide these services or assembling them on your own. Electronic Mail Internet e-mail services are based upon a relatively simple technology known as the simple mail transport protocol (SMTP). While the protocol itself is fairly simple, implementing an SMTP-based e-mail environment can be quite complex. Your first and most fundamental decision will be whether to graft SMTP services onto an existing e-mail system or build a new e-mail environment exclusively around SMTP. Each approach has advantages and disadvantages. LAN-based E-Mail Systems Most commercial e-mail systems, including those from Microsoft, Lotus and Novell, are built around proprietary messaging engines. While these systems have some real advantages in a LAN environment, they also make it more challenging to support SMTP. All of these vendors provide SMTP gateways for their systems, but the implementation of these systems can be challenging. More importantly, these gateways often lack the scalability attributes important for sites that make extensive use of Internet e-mail services. While these systems may perform perfectly adequately wit h message volumes of several thousand messages per day, trying to route 50,000 or 100,000 messages per day through one of these systems can be an exercise in futility. If you're also wondering why anyone would need to support that kind of message volume, you probably haven't heard about Internet mailing lists that can swamp your network with high volumes of mail. The good news is that the increased popularity of Internet e-mail is putting pressure on these vendors to enhance their Internet mail capabilities, and all are expected to release new mail server engines in 1995 or 1996 that should do a much better job of supporting SMTP. SMTP and POP The alternative chosen by many large Internet sites is to build a mail architecture around SMTP, usually using Unix as a mail server platform. In most cases, these sites use the post office protocol (POP) to store and forward mail messages to clients. One or more POP servers house user mailboxes and accept incoming mail via SMTP. The client application uses POP to contact the mail server at periodic intervals and queries it for new mail, that is then transferred to the client, erased from the server, and stored in a local message store on the client hard disk or a LAN file server. Most Internet application suites include POP-based mail clients and Microsoft's Exchange mail client that ships with Windows95 will also have POP client support. In this sense, Microsoft is making good on its promise to provide a universal inbox. You can still use your old Microsoft Mail server for internal mail while also receiving your Internet mail from a POP server. Outgoing Internet mail is usually handled directly via SMTP capabilities built into the client application. In most cases, an SMTP server will be designated as a message relay host and all outgoing Internet mail will be sent from the client to the relay host for subsequent delivery to the destination address. Such a model simplifies the work of the client and allows for the temporary queuing of mail messages when the destination mail server is not immediately accessible. In many cases, the SMTP relay host will reside on the same machine that acts as a POP server, but this doesn't have to be the case. Dividing these functions between multiple servers is often desirable at sites with very large message volumes. While Unix is by far the most popular platform for the implementation of POP services, software is also available that allows you to use your NetWare or Windows NT server as a POP server. You can even find software that allows any Windows machine to act as a POP server, though such a system probably wouldn't scale very well. While POP and SMTP are fairly flexible and scalable protocols, they are also lacking in several respects. First, they lack the sophisticated directory services often found in LAN-based e-mail products. To provide access to a common directory requires the implementation of proprietary features of the client e-mail application and many POP-based e-mail applications have no provisions for shared directories. Second, POP is not very effective in addressing the needs of people who need to use more than one computer for e-mail, as in the example of the office worker who wishes to access mail services from a home computer system. Finally, and probably most importantly, most POP-based e-mail systems shipped with today's TCP/IP application suites simply lack many of the features and operating system integration features that users have come to expect from desktop e-mail applications. FTP Servers Implementing an FTP server has come to be one of the simpler tasks facing an organization connecting to the Internet. In the past, FTP servers were almost always implemented on high-end systems running the Unix operating system. Today, robust FTP servers capable of handling tens or hundre ds of concurrent connections are available for desktop operating systems as well as network operating systems. This development makes implementing and maintaining an FTP server a much more manageable task. WWW Servers The hottest development to hit the Internet over the past 10 years has been the advent of World Wide Web servers. By implementing a Web server, businesses can establish a presence on the Internet that is accessible to millions of people. The potential applications of this technology are quite broad, ranging from the provision of general information about a business to product advertising to electronic commerce. Still, implementing an effective Web server requires a knowledge of both technology and electronic publishing. Many organizations are having difficulty finding people who are capable of handling this task. On the technical side, there are issues of performance, scalability and overall functionality. Most Web servers in production today are implemented on Unix systems, mainly because they offer excellent performance and a number of Web server implementations are available. Unix also provides a robust environment for linking Web interaction to other applications, as might be important, for example, at sites that want to conduct commerce via their Web server. However, the most user-accessible Web publishing tools are available for desktop computers. Given the relatively primitive integration between personal computers and Unix servers, developing and maintaining Web-based information is often cumbersome since the platforms often do not share access to a common file system. The result is that much of today's Web development takes place using somewhat primitive Unix-based editing tools, and this hampers the development process. The solution is to either move Web servers to alternative platforms or enhance the integration between desktop computers and Unix-based Web servers. Tools are available to accomplish these tasks, but in many cases, significant changes in an organizationís server infrastructure are necessary. Next Return to Table of Contents November 15, 1996 Print This Page E-mail this URL