9 Apr 1995
OS/2 Internet software is installed under the \TCPIP directory. Programs and CMD files go in the \TCPIP\BIN directory, and configuration files go in the \TCPIP\ETC directory.
The name "etc" and the format of most of the files stored in this directory is a convention carried over from Unix. The information has to be stored somewhere, and Unix has established the standard for Internet software. During the early stages of development, Unix systems provided the router and gateway components from which the Internet was constructed. The legacy of those days are configuration files that are much more complicated than necessary. Today, most systems provide a simple front-end that allows the workstation user to enter a few important values that are used to populate all the configuration files.
Before Warp, all Internet software assumed a LAN connection. If a system used a modem instead, it was assumed that the modem connected to a device that provided a gateway to a corporate or campus LAN. The system was therefore configured with the machines, addresses, and services of the "home" network. Warp is the first Internet package specifically designed to be used by an ordinary consumer who has established a personal account with one or more network service providers. This presents an entirely new configuration problem.
Each network has its own set of addresses. Each has its own name server, news server, mail server, and so on. If a consumer has more than one account in more than one network provider, then the configuration of all these items has to change when the user dials a different phone number.
The applications are effected as well. Network News ties together the news servers of all organizations. When an item is posed to a news group, it eventually propagates to all news servers. However, each server maintains its own database and assigns each incoming item a local identifier. A program that displays news items keeps a record of the items that have already been seen, so that they will not be redisplayed the next time the program is run. However, the list of subscribed groups and viewed items uses identifiers that apply only to a specific news server. Switch to a different news server in a different network and the items have all been renumbered, so the list of previously viewed items becomes meaningless.
The News Reader V1.07 update (available through the Retrieve Software Updates panel previously discussed) now maintains a separate set of configuration and history files for every network to which the user may connect. This can be very useful in today's two income households. He can dial into his network to read his news, and she can dial her network to read her news.
Most of the time, configuration can be accomplished using the public front end. Occasionally it is useful to understand the lower level configuration files to debug problems or handle special cases. Four topics need to be considered
The Internet developed from research sponsored by the Department of Defense. To allow computers from many different vendors running many different operating systems, the Internet provides clear standards when individual machines connect to Ethernet or another LAN. Each corporate or campus LAN is then connected to the larger network over high-speed long distance phone lines. What may be surprising is that the phone connections have not been standardized.
Instead, if a company decides to connect to the Internet, it has traditionally contracted with a Regional network to provide the connection. The Regional network establishes a phone line to the company, and places a router box at the company location. The router connects to the company LAN, as do all the local computers. Since the Regional network buys all its router boxes from the same company, it really doesn't care how the routers communicate over the phone line. When two Regional networks need to connect, they each put a router box in the same room and run a LAN between them.
Internet routing has been dominated by devices produced by the Cisco company. Most companies, universities, and networks use Cisco devices as routers. Thus much of the long distance Internet communication uses whatever protocol Cisco decided to build into their hardware. This is not really a bad thing. The process of drafting any official standard takes years, while technology is constantly changing. Too often, by the time a standard is officially published it has already become obsolete. A private company is more agile and adapts more quickly.
When it became possible to run Unix on personal workstations, a need developed to connect remote systems to a central LAN over ordinary low cost modems and standard phone lines. A simple protocol was proposed called Serial Line/IP (SLIP). SLIP was never intended to be a "standard", just a temporary quick and dirty solution that was easy to code and would suffice until something better came along.
Unfortunately, when the Internet community decided to do something better, they defined the problem very broadly. First, they wanted a standard that would work on high speed long distance leased phone lines to replace the vendor proprietary protocols supplied by Cisco. A version of the same standard would then be used on inexpensive asynchronous serial modems used by Personal Computers. They also wanted a protocol that would support not only the TCP/IP protocol used by the Internet, but also Appletalk, DECNet, Novell IPX, and everything else.
The Point-to-Point Protocol (PPP) has been developing over a period of many years. Standards are drafted and discussed by a committee of the group that manages the Internet, but there is broad participation by computer, software, and network vendors. While SLIP only provides a method of exchanging data, PPP allows the two ends of the connection to negotiate or adjust buffer sizes, data compression options, addresses, and other housekeeping. PPP even provides for the automatic exchange of Userid and Password information.
To the Warp user, PPP may provide a slightly simpler method of connection. More of the configuration information is provided automatically. Less has to be configured or extracted during a logon script. If the central site supports all the options, the user may only have to configure the phone number and everything else can be handled automatically. This is the way that Microsoft uses PPP in Windows 95 (Chicago) and Windows NT.
However, IBM currently supports PPP only as an alternative to SLIP for Internet access. IBM doesn't have a PPP server, and it doesn't support the use of PPP with other LAN protocols (Communications Manager, LAN Server, or Novell Requestor). This eliminates most of the advantages that PPP would normally have. In Warp, the difference between SLIP and PPP is more a matter of taste than technology.
The TCP/IP protocol manages the Internet. As the name suggests, the Internet is a network of networks. If you configure SLIP or PPP "honestly", then each phone line is supposed to look like a link between your "network" at home and the network at the other end of the phone. Of course, most PC users don't want to configure and administer a "network" consisting of one machine.
So most implementations of SLIP or PPP are configured somewhat dishonestly. Each remote machine is given a set of parameters that make sense, but the central network "cheats" to make the overall configuration simpler.
Remote users dial into modems connected to a Communications Controller. The Controller is then connected to a LAN by an adapter card (represented by a red circle). Elsewhere on the LAN a Gateway Router connects this LAN to the rest of the corporation or campus and eventually to the Internet and the rest of the world.
Assume there are 32 dial in modems connected to the Controller. If you configure SLIP honestly, every SLIP line is a connection to a remote network. The Gateway would then have to be programmed to regard the Controller as a device that provides an interface to the 32 different remote networks. Each remote user has to configure one of these networks. The result is a mess.
There are two reasonable lies that the Controller can tell. The most outrageous lie is that it can claim all 32 remote users are actually connected directly to the LAN. The Gateway tries to send messages directly on the LAN to each of the 32 separate workstations, but the Controller catches all these messages and sends them out the phone line. In this situation, the Controller makes itself invisible to the Gateway.
In a more modest lie, the Controller can act as if all 32 remote users are on a single separate LAN and that it provides a path between this imaginary LAN and the real LAN. In this case the Controller is visible and must have an IP address. The Gateway sends messages for any of the 32 remote users to the Controller's one address for forwarding, and the remote users send messages to the Gateway over their individual phone connection. At first, this seems to be very close to reality. The underhanded part is that the Controller is probably using the same IP address on all the connections. An "honest" TCP/IP implementation would require the Controller to have a different IP address for the LAN and for each phone line. However, since nobody is really looking, the Controller can cheat and get away with it.
Suppose that the Gateway has address 130.132.57.1. Suppose that the first dial in modem line is associated with address 130.132.57.32, and the second with .33, and so on. For the rest of this example, "*" will replace the "130.132.57" part of the address.
If the controller is invisible, then the first SLIP line will be declared to be a connection between remote address *.33 and the Gateway at *.1. The SLIP user will send all messages to the Gateway. The Gateway will believe that these machines are on the LAN. The Controller will forward messages between the remote user and the Gateway transparently.
If the Controller chooses to be visible, then it will probably have the address *.31. The first SLIP/PPP line will be treated as a connection between *.31 and *.32. The second line will be a connection between *.31 and *.33. The LAN connects the Gateway at *.1 to the Controller at *.31. In this view, the Gateway sends all traffic for any of the remote users to the Controller at *.31 so that it can be forwarded. The remote users send all traffic for everyone to the Gateway at *.31 so it can be forwarded. The same *.31 address gets used over and over again, but since the Gateway and remote users have need for a global view of network architecture, the trick is never discovered.
If the user selects the PPP protocol, the Controller configures the remote user directly. SLIP, however, has no low level housekeeping messages. The remote computer initially connects to the Controller box as a terminal. The Controller writes the configuration information in messages send to the "terminal screen." The user supplies a script to provide Userid and Password and to extract address information.
If the Controller chooses to be visible, then during the initial connection it will send out a message of the form:
Your IP address is 130.132.57.34. My IP address is 130.132.57.31.
The script anticipates this message and captures both address values. It plugs the *.34 address in as the value assigned to the remote PC, and the *.31 address is treated as a "gateway" value. If the controller chooses to be invisible, it will simply send out
Your IP address is 130.132.57.34.
The user will not be told about the *.1 gateway. The user has to know this address already. Generally, it will have been supplied by the central network administrator.
An invisible gateway would pose a minor routing problem if two remote SLIP users want to talk to each other. Since each believes that the Gateway is the route to all other machines, they would initially send it the message. However, from the Gateway point of view two machine on the same Ethernet should be able to talk directly to each other and do not need assistance. The Gateway then sends back a mild rebuke to each system to address traffic directly to each other. This is a minor issue, and in any event, remote SLIP users are not servers and are therefore unlikely to talk to each other directly.
Copyright 1995 PC Lube and Tune -- Windows on the World -- H. Gilbert
Continue
Back
PCLT