Open Transport

Open Transport is the new communications and networking architecture that will become the standard for Macintosh networking and communications. Open Transport provides a mechanism for communications applications to operate independently from underlying networks such as AppleTalk, TCP, or IPX. Open Transport provides a code base and architecture that supports network stacks while eliminating many of the interrupt latency problems associated with AppleTalk.

Open Transport has two major aspects: the client interfaces and the environment for developing protocols and communications modules. The Open Transport client interfaces are a superset of the XTI interface from X/Open, a consortium of UNIX vendors. XTI is a superset of TLI, a UNIX standard interface. By using the Open Transport interfaces, applications (called clients) can operate independently of the transport layer.

Open Transport does not use the conventional .ENET-style drivers; instead it uses Streams-based DLPI drivers that are more appropriate for use with PCI devices. In addition to being consistent with industry standards, Streams-based DLPI drivers provide higher performance than .ENET-style drivers.

Apple Computer’s Open Transport software includes new stack implementations for AppleTalk and MacTCP. Apple expects that third parties will provide implementations of DECnet, IPX, and other network protocols.

The Open Transport implementation of TCP/IP is a replacement for MacTCP. It is designed for use under the Open Transport software interface.

Introduction

Open Transport is the networking architecture used by Apple Computer, Inc. for Macintosh computers. Whereas AppleTalk provided a proprietary networking system for Macintosh computers, the current Macintosh Operating System with Open Transport provides not only AppleTalk but also the industry-standard TCP/IP protocols and serial connections. In addition, the Open Transport architecture allows developers to add other networking systems to the Macintosh Operating System without altering the user's experience or the application programming interface (API).

The independence of the APIs from the underlying networking or transport technology is called transport independence and is one of the cardinal features of Open Transport. Whereas the APIs are independent of the networking system in use, the specific set of functions you call does depend on the nature of the protocols. For example, you use different functions for a connection-oriented protocol like AppleTalk Data Stream Protocol (ADSP) than for a connectionless protocol like Datanet Delivery Protocol (DDP) or Internet Protocol (IP).

Other important features of Open Transport are its support of multihoming and multinodes. Multihoming allows multiple Ethernet, token ring, FDDI, and other network interface controller (NIC) cards to be active on a single node at the same time. In addition to selecting the type of network connection, the user can select a particular device to be used for the network connection.

Multinode architecture is an AppleTalk feature that allows an application to acquire node IDs that are additional to the standard node ID that is assigned to the system when the node joins an AppleTalk network. Multinode architecture is provided to meet the needs of special-purpose applications that receive and process AppleTalk packets in a custom manner instead of passing them directly on to a higher-level AppleTalk protocol for processing. Multinode IDs allow the system that is running your application to appear as multiple nodes on the network. The prime example of a multinode application is Apple Remote Access (ARA).

Open Transport Architecture

Open Transport API

The Open Transport API consists of two types of functions: utility functions, which are implemented in header files and software libraries; and interface functions, which are implemented by the underlying software modules. Because the interface functions are executed by the software modules, the same function might operate somewhat differently depending on the specific module or modules that executes it. Where such dependencies exist, they are described in the chapter describing a particular protocol.

The Open Transport API is a superset of a standard API defined by the X/Open Company, Ltd. The X/Open API is called the X/Open Transport Interface, or XTI. Both XTI and Open Transport are designed to be independent of the underlying data transport provider; for example, you use the same functions to send a packet of data whether the packet is being transferred by DDP over an AppleTalk network or IP over Ethernet. Whereas XTI specifies functions only for connectionless and connection-oriented protocols, Open Transport also includes functions for transactionless and transaction-based protocols.

The set of functions you use and the sequence of functions you call depends on the operation you want to perform and whether the protocol you want to use is connectionless or connection-oriented, transactionless or transaction-based.

In accordance with XTI, the Open Transport API supports protocol options. An option is a value of interest to a specific protocol. For example, an option might enable or disable checksums or specify the priority of a datagram. The available options and their significance are defined by each implementation of each protocol. Every option has a default value, and you can almost always use the default values and not specify any options. It is important to note that, because each option is protocol dependent, specifying a nondefault value for an option decreases or eliminates the transport independence of your application. Protocol options are described throughout this book with the protocol to which they apply.

The XTI specification defines a number of asynchronous events that indicate occurrences such as the arrival of data. Open Transport includes all the standard events defined by XTI, additional asynchronous events, plus completion events that individual functions issue when they complete asynchronous execution. You can poll for asynchronous events, but you cannot poll for completion events. The preferred method for handling all Open Transport events is to write an event-handling callback function, called a notifier function.

Software Modules

The software modules are implemented as Streams modules. The Streams architecture is a UNIX standard in which protocols (and other service providers) are implemented as software modules that communicate between each other using messages. Open Transport conforms to the Transport Provider Interface (TPI) and Data Link Provider Interface (DLPI) standards, which describe the content and ordering of the messages between modules. In a Streams environment, all modules have the following attributes:

• They process messages asynchronously. One module can send a message to another module and then wait for a reply without interfering with any other system activity.
• They (that is, all the Open Transport Streams modules) share a single address space.
• They may never block; that is, if a module can't complete an operation, it must return with an error rather than indefinitely holding up processing.

Drivers and Hardware

The Open Transport Streams modules communicate with hardware drivers, which in turn control the flow of data through communications cards or built-in ports. Normally, the user selects which card or port to use through the Chooser. Your application can use the default port for a particular protocol or can configure Open Transport to use a specific port.

Open Transport supports multihoming; that is, an individual node can have more than one hardware device (ports or cards) for a given type of transport. For example, a single computer can have two Ethernet cards, and the user can select which card to use.

About the TCP/IP Protocol Family

The TCP/IP protocol family is a set of networking protocols in wide use throughout the world for government and business applications. The TCP/IP protocol family includes a basic datagram-delivery protocol, called Internet Protocol (IP); a connectionless datagram protocol called User Datagram Protocol (UDP) that segments data to handle larger datagrams than those allowed by IP; and a connection-oriented data stream protocol that provides highly reliable data delivery, called Transmission Control Protocol (TCP). In addition to these three fundamental protocols, TCP/IP includes a wide variety of protocols for specific uses, mostly at the application-protocol level.

Open Transport offers interfaces to the TCP, UDP, and IP protocols, and to the domain name resolver (DNR). Only those protocols are discussed in the rest of this chapter. Open Transport also provides implementations of the RARP, BOOTP, and DHCP protocols, but those protocols are used by Open Transport for automatic configuration of a host, and they have no application interfaces.

About TCP/IP Services

The TCP/IP services provided by Open Transport include implementations of the TCP, UDP, RARP, BOOTP, DHCP, and IP protocols, an application interface to the domain name resolver (DNR), and utility functions you can use when creating and resolving internet addresses. You can open TCP, UDP, and RawIP endpoints and DNR mappers using the interfaces described in the chapters "Endpoints" and "Mappers" in this book .

A domain name resolver translates between the character-string names used by people to identify nodes on the internet and the 32-bit internet addresses used by the network itself. In that sense, its function is similar to AppleTalk's Name-Binding Protocol (NBP). Unlike AppleTalk, however, TCP/IP protocols do not specify a way for clients to register a name on the network. Instead, the network administrator must maintain a server that stores the character-string names and internet addresses of the servers on the internet, or each individual host must keep a file of such names and addresses. The Open Transport implementation of TCP/IP includes a DNS stub name resolver; that is, a software module that can use the services of the domain name system (DNS) to resolve a name to an address.

The nodes on a TCP/IP internet are known as hosts. A host that is addressable by other hosts has a host name and one or more domain names that identify the hierarchically arranged domains, or collections of hosts, to which it belongs. For example, the Open Transport team, part of the system software group at Apple Computer, might have a server with a fully qualified domain name of "otteam.ssw.apple.com." In this case, "otteam" represents the domain of hosts belonging to the Open Transport team, "ssw" represents the domain of hosts belonging to the system software group (which includes the Open Transport team plus several other teams), and so forth. A fully qualified domain name corresponds to an internet address, also known as an IP address, which is a 32-bit number that uniquely identifies a host on a TCP/IP network. An internet address is commonly expressed in dotted-decimal notation (for example, "12.13.14.15") or hexadecimal notation (for example, "0x0c0d0e0f").

To use the application interface to Open Transport's DNR, you must first open a TCP/IP service provider. Once you have done so, you can

• resolve a domain name to one or more associated internet addresses
• look up the domain name associated with an internet address
• retrieve the character strings stored by the domain name server that describe a host's processor and operating system
• retrieve DNS information associated with any query class and type
• obtain a list of mail exchanges and mail preference values for a host to which you wish to deliver mail

A mail exchange is any host that can accept mail for another host or for a domain. A mail exchange can be a mail server, a router, or just a host configured to accept and pass on mail. A mail preference value is used by a mail application to determine to which mail exchange to deliver a message when there is more than one that can accept mail for a particular domain. The mailer sends the mail to the mail exchange with the lowest preference value first and tries the others in turn until the mail is delivered or until the mailer deems the mail undeliverable.

The Open Transport TCP/IP services also include several utility functions. You can use these functions to

• get internet addresses and subnet masks for all the TCP/IP interfaces on the local host
• fill in data structures used for internet addresses
• convert an IP address string from dotted-decimal notation or hexadecimal notation to a 32-bit IP address
• convert a 32-bit IP address into a character string in dotted-decimal notation

The subnet mask determines what portion of the IP address is dedicated to the host identifier and what portion identifies the subnet. A subnet is a portion of a network, which is in turn a portion of an internet.

New Features of Open Transport

The new features of Open Transport include

• a new API
• dynamic loading and shared code
• an optional static node number (AppleTalk)
• an optional NBP-to-catalog server (AppleTalk)
• IP multicasting (MacTCP)
• dynamic retransmission timers (MacTCP)

Compatibility

Open Transport is compatible with existing AppleTalk networks and supports existing .ENET clients such as Soft Windows and DECnet. On the PCI-based Power Macintosh computers, this .ENET compatibility is provided by a module that maps .ENET calls to the corresponding DLPI calls.

Open Transport provides compatibility with 680x0-based computers by means of the following features:

• environment options
• 680x0-based APIs and stacks
• Open Transport APIs and stacks
• API compatibility glue
• use of parameter-block APIs with Open Transport stacks for 680x0-based applications

Open Transport provides compatibility with Power Macintosh computers by means of the following features:

• environment options
• 680x0-based APIs and stacks run in emulation mode
• Open Transport APIs and stacks run in native mode
• API compatibility glue runs in mixed mode
• 680x0-based applications can use parameter-block APIs with Open Transport stacks
• 680x0-based applications can use Open Transport APIs and stacks
• native applications can use parameter block APIs with 680x0-based stacks
• native applications can use parameter block APIs with Open Transport stacks

Troubleshooting

1.0.8 and Type 11 errors

To owners of PowerMac 7200, 7500, 8500, 9500 here is a solution to those
terrible type 11 errors experienced with OpenTranport 1.0.8*.

* Some may not have any problems, and thus should ignore this FAQ.  However
if you do switch providers be aware that some providers have a terrible
time supporting OpenTranport 1.0.8, and therefore in those cases use this
FAQ.

1. Get a Dynamic IP addressing account with all the gateway domain server
information from the provider, you may want to ask for a Compressed PPP
account with RARP addressing.
2. Clean install the system using the CD and Command-Sh-k at the startup of
opening the installer software.
3. Make sure you have OpenTransport 1.0.8 from ftp://ftp.support.apple.com,
install it and reboot.
4. Delete all non-Apple INITs, or archive them away in a .CPT, .SIT, or
.SEA file (clean install your system, and then install Open Transport
1.0.8).
5. Delete or archive the TCP/IP control panel and its corresponding
preference file in the System Folder::Preferences folder.
6. Delete or archive these extensions:
Open Tpt Internet Library
OpenTptInternetLib

7. Don't touch these extensions:
Open Tpt AppleTalk Library
Open Transport Library
OpenTptAppleTalkLib
OpenTransportLib.

8. Don't touch this Control Panel:
AppleTalk

9. Install MacPPP 2.0.1 or MacPPP 2.2.0a (available in the sumex mirror
archives).
Don't forget to set your TimeOut variable to at least 90 seconds,
and to setup your Connect Script.  If you have trouble setting up your
connect script, please e-mail me at my address below.  Also be sure no
other versions of PPP, PPP Preferences, Config PPP are on your machine when
you install it.
REBOOT your machine.

10. Install MacTCP 2.0.6.
Be sure to set it for Server addressing!  Yes, this appears to work on
dynamic addressing servers that claim to use RARP.  Strange but true of my
provider.
Gateway address and Domain Nameserver address is critical.  The IP address
is set by the server.
REBOOT your machine.

This configuration appears to work fine with the following:

~ATM 3.8.2 from System CD-ROM's Adobe Acrobat 2.1
Conflict Catcher 3.0
PPPop 1.3.2
Square One 3.0
Alps Glidepoint 1.1
Netscape 2.0b6 with no additional plugins installed*
Eudora 1.5.3
Fetch 3.0
Internet Config 1.2
IceTee 1.2b1
Virex 5.6.1
QuickTime 2.1
ClickThereItIs (installed with Ze at the beginning of the filename)
Directory Assistance II (installed with Ze at the beginning of the filename)
Aaron 1.1.3 (installed with ~ at the beginning of the filename.

Hayes Accura 14.4 k bps modem.
PowerMac 7200, 24 MB of RAM, Virtual Memory off.
Server at internet service provider is a SunOS 4.1 with AT&T Teledyn 28.8 k bps
modems.

* MacroMedia Shockwave 68k and Tumbleweed plugins both have caused Type 11
and or Unimplemented trap errors.

If anyone succeeds in eliminating Type 11 errors with the above
configuration with a newer version of OpenTransport, please let me know.
Server I might add has two name server addresses it recommends putting in
MacTCP, the first of which has its radio button checked.

Standard disclaimers apply.
Hope this helps.

Sincerely,
[email protected]

Documentation

• Inside Macintosh: Open Transport
• Open Transport AppleTalk Developer Note
• Open Transport CSMA/CD Developer Note
• Open Transport LocalTalk Developer Note
• Open Transport Serial Developer Note
• Open Transport TCP/IP Developer Note
• Open Transport Client Developer Note

Downloads

• ftp://ftp.atlas.altexxa.net/software/mac/os/components/OT_1.0.8-Net_Install.sea.bin
• ftp://ftp.atlas.altexxa.net/software/mac/os/components/OT_1.1.1-Net_Install.sea.bin
• ftp://ftp.atlas.altexxa.net/software/mac/os/components/OT_1.1.2-Extras.sea.bin
• ftp://ftp.atlas.altexxa.net/software/mac/os/components/OT_1.1.2-Net_Install.sea.bin
• ftp://ftp.atlas.altexxa.net/software/mac/os/components/Open_Transport_2.7.6.smi.bin

See Also

• Farallon and Open Transport FAQ
• Apple Computer

Application Programming Interface

Name-Binding Protocol

Peripheral Component Interconnect