abase client application, without modification, can access a server database through any number of network protocols: AppleTalk, TCP/IP, Token Ring, or IPX.
In addition, the architecture will allow applications to take advantage of new network technologies, such as infrared and wireless PC Card adapters, when they become available. You need only add a snap-on software module to provide low-level support for a new network service.
The combined flexibility and standardized network interfaces garnered this communications architecture the name Open Transport. Initially it was available only on Power Macs equipped with a PCI bus, but the version 1.1 release, which appeared early this year, delivers the same capabilities across the entire Mac product
line.
Building a Better Black Box
Open Transport is part of Apple's plan to uncouple the Mac OS from AppleTalk. This will allow it to provide such network services as peer-to-peer file sharing, remote access, and printing services with any network-protocol stack.
The ultimate goal is to make the next-generation Macintosh OS, code-named Copland (see
"Copland: The Abstract Mac OS,"
July 1995 BYTE), completely transport-independent. Macs could then be better team players within any large network, regardless of protocol. Since Open Transport will be Copland's communications architecture, it thus serves as a bridge to help developers tackle these conversion issues now, rather than later.
Open Transport provides a set of cross-platform, standards-based APIs for network and communications protocols. Three standard APIs address the developer's needs at different implementation levels. At the highest level, applications designers use the X/Open Transport Interface (XTI)
, a Posix-compliant API, to write network-aware programs. XTI offers a set of protocol-independent functions that establish a network connection, send and receive data packets, and close a network session.
The next level serves as a foundation where developers build the network protocol stacks. This level uses a port of a Unix System V release 4.2-compatible Streams environment. The different protocol stacks operate within the framework Streams provides, as shown in the figure
"Insulating Applications from the Network"
.
Protocol stacks are written as message-passing modules. Each module is single-threaded, shares the same address space with other modules (typically the kernel space), and handles messages asynchronously. To conserve system resources, protocol stacks are loaded only on demand. On PowerPC-based Macs, the Code Fragment Manager (CFM) dynamically loads and links the protocol modules; on 680x0-based Macs, the Apple Shared Library Manager (ASLM) handles this task.
Finally, at the lowest level, Open Transport conforms to the X/Open Data Link Provider Interface (DLPI) standards. DLPI describes the format and order of the messages exchanged between the protocol modules and the device driver. Thanks to the PCI-bus interface standards, a new network card is electrically plug-and-play-compatible with a PCI Power Mac. Furthermore, through Open Firmware, Power Macs equipped with PCI slots can automatically locate, load, and configure the new driver into the appropriate level of the Open Transport environment.
The initial release of Open Transport offered revised AppleTalk and TCP/IP protocol stacks. The latest release, 1.1, adds stacks for ATM and Token Ring, and the AppleTalk and TCP/IP stacks have enhanced support for remote connections using PPP. The TCP/IP stack now implements Ethernet version 2 and IEEE 802.3 framing. This stack also sports new features, including support for DHCP for IP-address configuration, IP multicasting for use as an MBone client, and s
imultaneous TCP connections. Open Transport's DHCP has been tested against a variety of servers, including Windows NT Advanced Server, Hewlett-Packard's HP-UX, and Sun's Solaris.
A New Look
Open Transport's user interface has been revamped to support some of the new features brought about by the changes in the underlying architecture. Formerly, you used a Network Control Panel to choose an AppleTalk network interface, such as the LocalTalk port or an Ethernet card. A MacTCP Control Panel let you adjust the various TCP settings. Such settings determined which interface to use (LocalTalk, TCP, or a third-party PPP implementation), whether to get an IP address from a server, and the correct IP addresses for a gateway and domain servers. An option-al MacTCP Adminstration Panel allowed a system administrator to preconfigure the IP addresses for users.
With Open Transport, you now have two configuration applications: AppleTalk and TCP/IP. Since users expect to change settings from Co
ntrol Panels, the file types for these applications have been modified so that they appear as Control Panels in the Control Panels folder. Both AppleTalk and TCP/IP offer three different levels of network administrative control: basic, expert, and administrator. You choose the level from the User Mode selection under the Edit menu.
The basic, or novice, level offers only a minimum of choices: typically, selecting the network connection and, perhaps, how the system establishes a network address (e.g., using DHCP to obtain an IP address). An advanced, or expert, mode enables you to tinker with the majority of the protocol's configuration settings.
TCP/IP's advanced settings let you specify domain names, the name server's IP address, the HOSTS file, a subnet mask, and other TCP esoterica (
see the screen
). You can also request that the protocol stack be loaded on demand.
The administrator mode is identical to the expert mode, but it allows the system administrator to lock
specific settings. To prevent other users from tampering with these settings, entering this level requires a password.
Connection Issues
Of course, Open Transport would face marginal acceptance if existing network applications that used the old network services broke under the new architecture. To this end, Open Transport provides limited backward compatibility. A compatibility layer of 680x0 code intercepts calls made at the driver level for AppleTalk (the .ddp-driver API) and TCP (the .ipp-driver API). These driver calls are translated into equivalent Open Transport XTI calls and then routed to the corresponding protocol stack. Incoming packets undergo a reverse process.
Unfortunately, applications that use undocumented API calls or that rely on information in private data structures will break. Another problem area is performance: Applications that use the old interfaces suffer a performance hit, even though the new protocol stacks are in native code. The data packets sent
using the old interfaces must pass through a 680x0 compatibility layer, a context switch, the native protocol stack, and possibly another context switch if the device driver isn't in native code. File sharing in particular shows poor performance, because the File Sharing Extension still uses 680x0 processor code and communicates via the old AppleTalk APIs.
On the other hand, up-to-date applications that use the Open Transport APIs can benefit from the speedy native protocol stacks and drivers. Apple has measured a claimed sustained-throughput speed of 112 Mbps for standard 155-Mbps ATM cards.
The road to transport independence hasn't been glitch-free. The initial 1.0 release offered excellent AppleTalk support, but the TCP/IP stack had a number of problems, which created trouble for Internet and IP network applications that worked fine with the MacTCP implementation. In some instances, users tossed the Open Transport TCP libraries and dropped the old MacTCP Control Panel back into their System F
older. Remarkably, this trick worked and solved the worst of the TCP problems. It's a tribute to the Mac OS's design that this work-around functioned at all.
Open Transport got off to a rocky start, but by release 1.0.8, the TCP/IP stack problems were corrected, and IP applications began working reliably. In addition, a problem with obtaining an IP address from a DHCP Windows NT server was resolved. A patch to the DMA serial driver fixed most serial I/O problems. Release 1.1 fixes more bugs, and its performance tuning improves Ethernet throughput. The addition of FDDI, ATM, and Token Ring support was also welcome.
Fundamentally changing the communications infrastructure of an OS while trying to retain some backward compatibility is not easy, as Apple has learned. But it was clearly a necessary step if the Macintosh was to remain a viable part of future high-speed networks. More important, problems that are dealt with now should mean fewer problems with Copland when it ships.
illustration_link (30 Kbytes)
Several industry-standard layers implement Open Transport's network interfaces. On the Power Mac, the Streams and protocol stacks are in native code.
screen_link (28 Kbytes)
In expert mode, the TCP/IP Control Panel lets you config
ure a number of TCP settings.
Tom Thompson is a BYTE senior technical editor at large. He writes extensively on Mac-related and general computing issues. You can contact him by sending E-mail to
tom_thompson@bix.com
.
How Copland Communicates
