9 Apr 1995
The Internet Connection for Warp, as the TCP/IP for OS/2 product before it, is organized into a number of layered or functional components. To diagnose problems or to do anything out of the ordinary, it is useful to understand these groups of programs and their relationship with each other.
In OS/2, applications call the operating system, database managers, or communications support through groups of subroutines packaged in Dynamic Link Libraries (DLL's). The Internet Connection API routines are provided by four modules in the \TCPIP\DLL directory:
The control blocks and buffers that represent the active connections are maintained by the TCP/IP protocol support in the kernel or in a background program. This part of the system is loaded and started by three statements in CONFIG.SYS:
DEVICE=e:\tcpip\bin\inet.sys
DEVICE=e:\tcpip\bin\ifndisnl.sys
RUN=e:\tcpip\bin\cntrl.exe
If the workstation is connected to a LAN, then the middle statement will change from IFNDISNL to IFNDIS.
INET runs as a device driver at Level 0, with full system privileges. It uses the services of IFNDIS to communicate to the LAN services of OS/2 (the part of the system based on the NDIS conventions used by IBM and Microsoft in their LAN architecture). In this example, LAN access is provided through a driver for the 3COM Etherlink III family of cards.
TCP/IP was designed to be easy to use and robust. Sometimes, however, a seemingly straightforward request runs into a problem that requires a higher level of processing than is appropriate down in device drivers. For this purpose, TCP/IP spins off a background program named CNTRL.EXE. It doesn't have a window, so the user typically doesn't see it. However, running as a regular program it can call all the system services, open datasets, and allocate memory for larger tables.
When there is no LAN connection, and only SLIP is used, then the IFNDISL stub driver is loaded. The blue boxes (Protman and ELNK3) disappear. SLIP traffic is routed through SLIP.EXE or SLIPPM.EXE which runs as an application program up. In this case, all the data goes from INET up to the SLIP programs and then out the COM port.
The primary use of the TCP/IP protocol is to connect to Internet Services. However, in PC systems it has two other uses.
TCP/IP can be used by the Redirector to communicate with file or print servers on the network. Traditionally, IBM and Microsoft Redirectors have used a smaller, simpler protocol named NETBEUI (or in other contexts, NETBIOS). NETBEUI had the advantage in Plain Old DOS of taking up the least memory, a distinct disadvantage when trying to squeeze everything into a 640K area of memory. However, NETBEUI was not designed to be routed across a large network. As the focus of PC use changed from small departmental workgroups to Enterprise-wide applications, it has become important to replace NETBEUI with a better albeit larger protocol like TCP/IP.
Release 4.0 of the IBM LAN server includes all the modules for the lower levels of the TCP/IP protocol. They are intended for use as a transport protocol for messages between the Redirector and the Server. However, they can also provide the missing components needed to connect Warp to a LAN.
At a higher level, IBM proposed several years ago a new Communications Blueprint. Its purpose was to update the earlier IBM strategy that depended entirely on SNA. As it happens, the current Microsoft strategy duplicates the IBM Blueprint except for minor differences in some of the component names.
The Blueprint reduces most of the communications issues to four layers. The lowest layer provides the physical connection used to transmit data. Some examples of the options at this level include Ethernet, Token Ring, Frame Relay, modem, ISDN, X.25, and Fiber Optic ATM. In theory, these options are all interchangeable except for speed, cost, and reliability.
The next layer up is the type of network organization. Options here include SNA, TCP/IP, and OSI. SNA provides a good choice for an internal network with high reliability but higher cost. TCP/IP is a good choice for a public or multivendor network with more informal management.
The third layer reflects the type of communication. Options include traditional sessions based on sockets, Remote Procedure Calls, or transactions based on APPC.
The Anynet/2 product for OS/2 reflects a partial implementation of the Blueprint. It also is based on the same LAN support modules incorporated into LAN Server 4.0. Assuming that some version of this code is incorporated in the forthcoming Warp LAN Client, then the LAN software will come together nicely.
However, the remote dial-up connections are not being handled very well. SLIP only provides support for TCP/IP. The LAN Client package is supposed to include the client version of IBM's LAN Distance package, which provides an alternate version of the remote LAN client. IBM has a bunch of other products (something called DIALS for the 8235, Route eXpander, the WaveRunner ISDN support). All provide some sort of dial-in alternative to the LAN, all support TCP/IP, and none interoperate with each other. To this mess, the SLIP support packaged with Warp adds an additional and now highly visible incompatible alternative. It is not clear whether and how this mess will sort itself out.
Microsoft, in contrast, has a very clear communications structure in place for Windows NT 3.5. Most of the same elements are part of the Windows 95 (Chicago) current Beta test release. The user can connect to the network with a LAN adapter, modem, or ISDN link. All protocols run over all forms of network attachment. The modem connection uses the PPP standard protocol that interoperates with standard third party communications controllers.
Copyright 1995 PC Lube and Tune -- Windows on the World -- H. Gilbert
Continue
Back
PCLT