Farallon and Open Transport FAQ
- What is Open Transport?
- What is the history and future of Open Transport?
- What are the features and benefits of Open Transport?
- What files and applications are added to the computer when Open Transport is installed?
- What is the Network Software Selector?
- What current Mac OS technologies, components, and products does Open Transport replace?
- Does transport independence imply that my organization can offer AppleTalk services without supporting AppleTalk protocols?
- Are all Open Transport applications transport independent?
- Will Apple port Open Transport to Windows or UNIX?
- Where can I find more information?
1. What is Open Transport?
Open Transport is the new networking and communications subsystem for the Mac operating system (Mac OS). It consists of two control panels and several shared libraries for AppleTalk and TCP/IP connections. These libraries are used by networking applications when needed.
2. What is the history and future of Open Transport ?
Open Transport 1.0 was released in June, 1995. It was part of the system software for the Macintosh 9500. In August 1995, Apple released the 7200, 7500, and the 8500 computers with the 1.0.6 update to Open Transport. These were the only computers capable of using Open Transport. During the remainder of the year, Apple upgraded Open Transport to 1.0.8.
The next version of Open Transport, version 1.1, was released in March 1996. It is part of the System 7.5 upgrade 2.0. This software will upgrade 60x30, 60x40, and PowerPC Macs using at least System 7.5 to System 7.5.3 and Finder 7.5.5. Open Transport 1.1 will support existing NuBus interface cards and SCSI-attached Ethernet adapters.
Computers using Open Transport must be running System 7.5.x. 680x0 Macs require 8 MB of total memory. For Power Macs, 12 MB of total memory is recommended.
Open Transport is compatible with the use of Virtual Memory (VM) and takes full advantage of the Power Macintosh Code Fragment Manager in which uses a much lower system RAM footprint when VM is turned on.
The dynamic link-and-load technology used by Open Transport consists of the Apple Shared Library Manager (ASLM) 2.0 for 680x0 machines and a combination of ASLM and the Code Fragment Manager for Power PCs.
Open Transport 2.0 will be released as part of the Copland operating system which is expected in late 1996 or early 1997. Support is planned for all Copland platforms, including the Common Hardware Reference Platform (CHRP).
3. What are the features and benefits of Open Transport?
Open Transport makes it easier for end users, network managers, and developers to function in a multi-protocol, multi-platform environment. Different aspects of Open Transport help each group.
Open Transport allows multiple configuration files for TCP/IP and AppleTalk. This permits the user to switch between networks with minimal problems. Open Transport also integrates online help using Apple Guide technology.
For network managers, Open Transport provides services that ease the management of AppleTalk and TCP/IP networks. AppleTalk now incorporates static AppleTalk addressing. The TCP/IP control panel incorporates the Dynamic Host Configuration Protocol (DHCP). This allows network managers to administer IP addressing and other TCP/IP configuration information from a central server.
Developers write applications according to a set of procedures and functions known as an API (Application Program Interface). The three Open Transport APIs are The POSIX compliant X/Open Transport (XTI) API used for creating network applications, UNIX STREAMs, and Data Link Provider Interface (DLPI) used to create network drivers.
The Open Transport APIs are based on cross-platform industry standards, unlike Apple's classic Ethernet drivers and applications which were written to Apple-specific APIs. Applications written to the Open Transport APIs can directly support a wide range of networking environments (serial, dial-up network, LAN, and WAN), and multiple protocols (AppleTalk, TCP/IP, serial, and others) from a common code base. Apple calls this flexibility transport independence.
Apple has created four criteria that developers must follow when creating Open Transport applications and drivers. Developers must:
- Use consistent user interface guidelines when creating Open Transport control panels. The configuration of each CDEV must be consistent across network protocols.
- Use one set of cross-platform, standards-based APIs for all networking and communications protocols. For example, applications should be able to send and receive data over an AppleTalk LAN or the TCP/IP-based Internet using the same programming interfaces.
- Use a dynamic link-and-load architecture and set of protocols that load and unload protocols on demand, thus conserving system resources and making it possible, for example, to substitute TCP (part of the TCP/IP protocol suite) for ADSP (part of the AppleTalk protocols suite) at application launch time.
- Use an addressing and naming support toolbox, for example, applications can open a communications end-point by name, like opening "seeding.apple.com" in Netscape or selecting printer16:LaserWriter in the Chooser. Open Transport automatically provides the appropriate name-to-address mapping services (DNR, NBP, and so on).
4. What files and applications are added to the computer when Open Transport is installed?
The TCP/IP and AppleTalk applications are added to the control panels in the System Folder. The Network Software Selector is added to the Apple Extras folder. The following two extensions are added to all CPUs: Ethernet (built-in) A code resource allowing access to a built-in Ethernet port. Serial (built-in) A code resource allowing access to built-in serial ports.
The System 7.5 updated installation script identifies what type of CPU is being used and installs the following extensions:
For 680x0-based Macintosh systems
- Shared Library Manager
- Open Transport Library (Open Transport code resource)
- Open Tpt AppleTalk Library (AppleTalk code resource)
- Open Tpt Internet Library (TCP/IP code resource)
For PowerPC-based Macintosh systems
- Shared Library Manager PPC
- Open Transport Library (Open Transport code resource)
- Open Tpt AppleTalk Library (AppleTalk code resource)
- Open Tpt Internet Library (TCP/IP code resource)
5. What is the Network Software Selector?
The Network Software Selector is an application which allows users to switch between Open Transport and classic networking.
It functions on all Macintosh computers except PCI Macs. PCI Macs are Open Transport only. The Network Software Selector is installed in the Apple Extras folder, not in the System folder.
6. What current Mac OS technologies, components, and products does Open Transport replace?
Open Transport replaces the current protocol implementations of AppleTalk and TCP/IP, the CDEVS network, and MacTCP/AdminTCP. Open Transport also replaces the Connection Manager and the Communications Resource Manager of the current Communications Toolbox architecture.
7. Does transport independence imply that my organization can offer AppleTalk services without supporting AppleTalk protocols?
Each service, network environment, protocol, and choice is determined by a combination of factors; transport independence is only one of them.
The client and server software of a network, such as files, print, e-mail, directory, security, back-up, and calendar, must be written to the Open Transport APIs.
The client and server must have the correct protocol stack(s) installed.
The server application must include some administration utility to allow the network manager or user to specify the protocol(s) over which the services are to be provided.
The method for selecting the server (that is, Choosing or name-binding) may vary depending on the underlying protocol. For example, AppleTalk offers a distinctive selection method using the Chooser and the underlying NBP/ZIP protocols. TCP/IP offers a substantially different model for name-to-address translation (DNS); NetWare/IPX still another (NDS).
8. Are all Open Transport applications transport independent?
No. Although Open Transport provides the necessary foundation, certain guidelines and programming practices are required for developers to create transport independent applications. For example, most protocols have many features in common, but some features are protocol-specific. In some cases it may be appropriate or desirable to develop a transport-specific application.
9. Will Apple port Open Transport to Windows or UNIX?
Apple does not plan to port Open Transport to other operating systems. Rather, Open Transport is based on Apple porting three existing, cross-platform industry standards to the Mac OS. These standards have their roots in the UNIX community and experienced UNIX network developers will find themselves "right at home" when developing for Open Transport.
10. Where can I find more information about Open Transport?
Open Transport Home Page
These pages provide developers with pointers to useful information on Open Transport technology from Apple Computer.
Open Transport 1.1: Updates and New Features
OTS- Open Transport
Instructions for configuring the TCP/IP control panel for using a PPP server. Also how to configure a PPP client.
The Open Transport Saga
Apple Open Transport Component Technologies
By Fred Widmer. This article contains a series of questions and answers on the component technologies in Apple Open Transport.
LaserMaster Third Party Support: Open Transport
Open Transport Online Documentation
This is a collection of various version release notes.
Open Transport and PPP, A How-to Guide
Open Transport Architecture
Open Transport and PPP: Questions & Answers
Configuring TCP/IP, FreePPP, and Memory
The Open Transport TCP/IP Control Panel Simplified For Beginners
This article provides a simplified explanation of the elements of the Open Transport TCP/IP control panel settings.
Configuring Open Transport for ARA
Open Transport AppleTalk
- What are the new features of Open Transport AppleTalk?
- What are the user interface changes to Open Transport AppleTalk?
- What is the difference between dynamic and static addressing?
- How are static addresses administered?
- Can dynamic and static addresses be used on the same network?
- What are multiple configuration files?
- Does parameter RAM still hold the AppleTalk address information?
- Is Open Transport/AppleTalk "AppleTalk Phase 3"?
- What is multi-homing and multi-node?
1. What are the new features of Open Transport AppleTalk?
The new features of AppleTalk include:
- Static or dynamic AppleTalk node addresses
- Changeable AppleTalk configuration information such as turning AppleTalk on or off without restarting the computer
- Capability for creating multiple AppleTalk configuration files
- Built-in multi-homing and multi-node capabilities
- Written in native code for PowerPCs
- Expanded Apple Guide support
2. What are the user interface changes to Open Transport AppleTalk?
The Network control panel has been removed and an AppleTalk control panel has been added. The AppleTalk control panel is used to configure AppleTalk networking. It also incorporates the functionality of the Network control panel (the Connect via popup is used instead of the AppleTalk ADEV to select the network interface).
The AppleTalk control panel provides three levels of functionality: Basic, Advanced, and Administration.
The Basic mode lists the connection method and the current zone.
The Advanced mode lists the node ID, the network ID, and the network range. Previously, this information was listed at the bottom of the Network control panel window. Static (also known as manual) nodes are assigned in this window via the user-defined AppleTalk address.
The Administration mode contains the basic and advanced features plus it allows the user to password-protect a configuration file.
The Info button displays basic troubleshooting information, such as the Ethernet hardware address and the versions of Open Transport and AppleTalk being used.
The Option button opens the window in which AppleTalk is made active or inactive. After pressing the appropriate radio button, save, then close the window to make the change take effect. This window overrides the similar AppleTalk information in the Chooser.
3. What is the difference between static and dynamic addressing?
Static addressing is when the computer is assigned an address that does not change at startup. The static or "manual" address is a unique and stable identifier of the node and therefore simplifies network management. Assigning a node a static AppleTalk address prevents the device from generating network traffic at boot up. Static addressing eliminates the possibility of duplicate AppleTalk addresses.
Static AppleTalk addresses support Mac OS products that use WAN datalinks where non-full-mesh topologies are important. This includes datalinks such as Frame Relay, SMDS, and ATM.
Dynamic addressing is the process in which at boot up the Mac searches the network for an available AppleTalk node address. Dynamic addressing uses the AppleTalk Address Resolution Protocol (ARP) and has been in use since 1984. The drawback of dynamic addressing is that searching the network adds traffic which can result in network slowdowns. Also, if two AppleTalk nodes are booted at the same moment, they could try to grab the same AppleTalk node number, which can cause both computers to crash.
4. How are static addresses administered?
The network manager selects a range of addresses. Each address is typed into the User Defined box in the Advanced window of the AppleTalk control panel (see the AppleTalk, Advanced mode graphic above). After saving the control panel, the address is "locked" and cannot be picked up from another node.
5. Can static and dynamic addresses be used on the same network?
Yes, but it is not recommended. Although it can be done, doing so would create the possibility of a node ID conflict. Apple anticipated this potential conflict and designed Open Transport to check for duplicate protocol address on the network. A popup window warns the user if duplicate addresses are found.
6. What are multiple configuration files?
Open Transport allows multiple configuration files for AppleTalk and TCP/IP protocols. The files contain the node and network information for each network the computer is going to be connected to. Multiple configuration files makes the process of moving the computer from site to site less cumbersome and confusing.
7. Does Parameter RAM (PRAM) still hold the AppleTalk address information?
Yes, PRAM still contains the AppleTalk on/off state, the selected network interface, (the item selected in the Connect via popup in the AppleTalk control panel), the previous network protocol address, and the previous AppleTalk zone name. However, this data is no longer automatically used at startup.
Before Open Transport reads the network information in PRAM, it checks the selected AppleTalk configuration file to determine if AppleTalk is on or off. This setting overrides the setting in PRAM. If the AppleTalk node ID is locked (a static address is used and the specific node ID is not available) AppleTalk remains off. The user will receive a dialog notification of this event.
8. Is Open Transport /AppleTalk "AppleTalk Phase 3"
No. Open Transport/AppleTalk is a new implementation of the AppleTalk Phase 2 protocol architecture.
9. What is multi-homing and multi-node?
Multi-homing is the capability to communicate through more than one network protocol address at the same time on a given network interface. This term is taken from the idea that the workstation makes its "home" on more than one network at the same time.
Multi-node is when a device has two network IDs and is using one protocol and one network Interface card. The other computers on the network will see this one device as two nodes. This has never been possible before without routing software and/or hardware.
Support for multi-homing and multi-node is built into Open Transport v1.1. Applications that require this functionality can be used on computers with Open Transport. However, the software required to configure multi-node computers does not exist.
Open Transport TCP/IP
- What are the new features of the Open Transport/TCP protocol stack?
- What are some of the user interface changes for Open Transport/TCP?
- How are multiple TCP/IP files created and accessed?
- What is the Maximum Transfer Unit (MTU)?
- What is dynamic MTU discovery?
- Does Open Transport/TCP support MacTCP dynamic addressing?
- Which DHCP servers are supported by Open Transport/TCP?
- Does Open Transport/TCP support DHCP address leases?
- Does Open Transport/TCP support MacTCP server addressing?
- Does Open Transport/TCP support a local Hosts file?
- How does the new Open Transport/TCP Domain Name Resolver work and what are implicit or explicit searches?
- What is MacIP?
What are the new features of the Open Transport/TCP protocol stack?
- Direct entry of IP addresses and subnet mask in standard dot notation
- Selection of connection method (the Connect via popup)
- Support for multiple entries for the router, name server, and explicit domain search lists
- Improved support for large AppleTalk networks when using MacIP server/gateways
- Dynamic path MTU discovery
- Dynamic Host Configuration Protocol (DHCP) for centralized IP address configuration management
- Simultaneous TCP connections limited only by installed memory and processor power
- Implicit and explicit domain name search paths for increased control of domain name resolution
- The ability to save and use multiple configuration files
- The ability to load and unload TCP/IP only when necessary
2. What are some of the user interface changes for Open Transport/TCP?
The user interface of the TCP/IP control panel is completely different than the MacTCP it replaces. The TCP/IP control panel has three levels of functionality: Basic, Advanced, and Administration.
The Basic mode lists the IP address, subnet mask, router address, name server addresses, and the connection method.
The Advanced mode has the same features of the Basic mode, plus it allows the user to select 802.3 and a Hosts file to do implicit searches of domain names. To activate a Hosts file, double-click the Select Hosts File button. This takes you to the folder where the Hosts file exists. The Hosts file is text that can created or edited with any text editor or word processor.
The Administration mode has the basic and advanced features plus it allows the user to password-protect the configuration file.
The Info button gives you basic troubleshooting information, such as the Ethernet hardware address and the versions of Open Transport and TCP/IP being used.
The Options button selects when TCP/IP will load. The purpose is to conserve memory.
3. How are multiple TCP/IP files created and accessed?
After TCP/IP information is put into the configuration file. It needs to saved and exported to the Apple Extras folder.
When a configuration file is needed, open the TCP/IP application, select Configuration from the Edit menu, then select Import. This opens the Apple Extras folder and displays the saved configuration file. Select the appropriate file. The window closes and brings the file name into the Configurations Window. Click Make Active, then click Done.
4. What is the Maximum Transfer Unit (MTU)?
The MTU is the largest size a packet can be and still transfer whole across the network. If the packet is larger than the MTU, then TCP/IP will fragment the packet and send it in pieces. The packet is reassembled at the receive end of the network.
5. What is dynamic MTU discovery?
Dynamic MTU discovery is a process in which the "don't fragment" bit in a TCP/IP packet is selected, unless the packet size is larger than the MTU size for the network. Intermediate routers are required by current RFCs to send back an "ICMP can't fragment" error when presented with a "don't fragment" packet that cannot be forwarded without fragmentation. When this occurs, Open Transport/TCP takes the packet and moves it to the next smaller MTU size for that path and re-sends with the "don't fragment" bit set. This process results in using the largest supported MTU size for the subnet traffic.
6. Does Open Transport/TCP support MacTCP dynamic addressing?
No. MacTCP dynamic addressing was based on an Apple-proprietary extension to TCP/IP protocols. It applied the address negotiation and assignment rules used by the AppleTalk protocols to TCP/IP networks, making it very easy to set-up a Macintosh only, stand-alone TCP/IP network. Use of this dynamic addressing method in other scenarios did not work very well.
The Internet Engineering Task Force (IETF) has developed a multi-vendor standard for dynamic IP address assignment, known as Dynamic Host Configuration Protocol (DHCP). Apple has adopted the industry-standard DHCP and dropped support for its dynamic addressing with Open Transport/TCP.
7. Which DHCP servers are supported by Open Transport/TCP?
Apple's implementation conforms to the current versions of the applicable specification documents (RFCs). To date, Open Transport/TCP has been tested with the following DHCP server implementations:
- Competitive Automation
- FTP Software (www.ftp.com)
- Hewlett Packard HP-UX (www.hp.com)
- Microsoft Windows NT Advanced Server
- Silicon Graphics (www.sgi.com)
- Sun Solaris and SunOS (www.sun.com)
- TGV (www.tgv.com)
8. Does Open Transport/TCP support DHCP address leases?
Open Transport/TCP fully supports DHCP address leases. When an address lease reaches its renewal interval, Open Transport/TCP will automatically attempt to renew the address. The renewal interval is half the lease's lifetime. (The renewal interval may be configured to a different value by making changes to the DHCP server). Renewal will be attempted regardless of how many times the lease has already been renewed. Should an interface's IP address lease expire, the interface will be closed down.
9. Does Open Transport/TCP support MacTCP server addressing?
Classic MacTCP server addressing is a combination of the Bootstrap Protocol (BootP) and Reverse Address Resolution Protocol (RARP) configuration methods. When server mode is selected, MacTCP uses BootP to attempt to acquire an IP address. If BootP fails to provide a valid address, RARP is used. The successful protocol is stored as a preference, and is used at the next system startup.
Open Transport/TCP does not have the server mode. A single method must be specified. The RARP or the BootP are options in the Connect via popup on the TCP/IP control panel.
10. Does Open Transport/TCP support a local Hosts file?
Yes. Open Transport/TCP supports a Hosts file, stored in the System Preferences folder. The purpose of the Hosts file is to supplement and/or customize the Domain Name Resolver's initial cache of information. This file is examined when Open Transport/TCP is initialized. As in MacTCP, the supported Hosts file features follow a subset of the Domain Name System Master File Format (RFC 1035).
11. How does the new Open Transport/TCP Domain Name Resolver (DNR) work and what are implicit or explicit searches?
When a client of the DNR requests a name-to-address mapping, the DNR checks for a "." at the end of the name. If it exists, the name is assumed to be fully qualified (RFCs 1034 and 1035), and the DNR will search for that name. If the name contains at least one "." internally but does not end with "." it is considered to be provisionally fully qualified. The DNR will begin a search for these names without further manipulation. Otherwise the name is assumed to be partially qualified. The DNR will begin a search for the name in the domain name configured in the Default Domain field. For example, an attempt to resolve the name "Joe" with a Default Domain of tech.support.apple.com would look for joe.tech.support.apple.com.
If the requested name is not found and an optional Admin Domain has been configured using either the Advanced or Administrator mode, an implicit search takes place. Continuing with the example, with a Default Domain of tech.support.apple.com and an Admin Domain of apple.com, a search for the name Joe would look for the following additional names:
Implicit searching stops when the name is resolved, or when the FQDN becomes equal to the name-to-be-resolved concatenated with the Admin Domain (using the previous example, no implicit search would be made for joe.com). Implicit searching is not attempted unless an Admin Domain is explicitly configured and the Default Domain is a subdomain of the Admin Domain (per RFC 1535).
If the name is still not found, the explicit Search Domains are searched. For each search domain the configured name server(s) are contacted in the order specified in the Name Servers field. If the name is resolved in the first search domain that answer is returned; other Search Domains will not be checked. If an authoritative answer that the "name-does-not-exist" is returned, the DNR immediately begins the search in the next configured Search Domain. The search continues through the configured Search Domains. If no match is found, the DNR will search the root domain if it makes sense to do so.
The DNR has an overall time-out of two minutes, after which it will abandon its search.
12. What is MacIP?
MacIP, also known as KIP (Kinetics Internet Protocol), is a protocol specification in which TCP/IP datagrams are encapsulated in an AppleTalk packet for transmission over a Local Talk network.
Use of MacIP requires a MacIP gateway. AppleTalk encapsulated IP packets are sent to the MacIP gateway using AppleTalk protocols (DDP). The gateway strips off the AppleTalk encapsulation and places the IP packet on the TCP/IP LAN. When packets are destined for the MacIP end-node, that gateway provides the needed encapsulation services.
MacIP gateway support is usually a service within a multi-protocol router. The gateway (router) attaches to both an AppleTalk and a TCP/IP network, acting as a middleman between the MacIP end-node and the appropriate TCP/IP-based hosts on the LAN or WAN.
Open Transport includes end-node support for MacIP. The user selects MacIP from the Connect via popup on the TCP/IP control panel. The user (or network administrator) must select which zone to look for the MacIP gateway. Once selected, TCP/IP will be encapsulated in AppleTalk and will be sent out the Connect via interface.
- What is backward compatibility?
- Is Open Transport compatible with existing applications and network extensions?
- How is backward compatibility for the AppleTalk protocols implemented?
- How is backward compatibility for MacTCP implemented?
- What about backward compatibility between the classic .enet driver and the Open Transport DLPI driver?
- Are there other known limitations to backward compatibility?
- What about MacSNMP? When will it be revised to work with Open Transport?
- Is Apple is migrating serial communications away from the Communications Toolbox ?
1. What is backward compatibility?
Open Transport supports backward compatibility services in five areas:
- Existing AppleTalk applications
- Existing MacTCP applications
- Existing Chooser devices
- Existing applications dependent on the Mac OS LAP Manager
- Existing applications dependent on the Mac OS classic network driver architecture
Open Transport also provides emulation software to transition classic NuBus network interface drivers to the new DLPI drivers.
2. Is Open Transport compatible with existing applications and network extensions?
Apple has defined three levels of interoperability with Open Transport.
Open Transport Compatible describes network applications originally developed for classic AppleTalk or MacTCP. Under Open Transport, these applications gain the benefits of the Open Transport TCP/IP and AppleTalk control panels such as multiple configuration files and static addressing. However, faster throughput does not occur with these applications because they will be emulated into the Open Transport Application interface. Also these applications are not capable of taking advantage of Open Transport's transport-independence capabilities.
Open Transport Ready describes applications that are written in the Open Transport APIs (XTI). These applications are PowerPC native and function on 680x0-based Macintosh systems. Open Transport Ready applications are very fast when running on a Power Macintosh.
Open Transport Enhanced describes dynamic configuration. In addition to using the new Open Transport APIs and being Power PC native, Open Transport Enhanced applications can be dynamically configured to support AppleTalk, TCP/IP, or serial communications. These applications use the transport-independent capabilities of Open Transport.
3. How is backward compatibility for AppleTalk protocols implemented?
Above the DDP protocol layer, the classic implementation of the AppleTalk protocols is used. The word "classic" defines non-native PowerPC and non-Open Transport APIs.
Backward compatibility is accomplished by intercepting all AppleTalk networking calls at the .ddp driver level. When the packets reach the DDP protocol layer, calls to the .ddp driver are intercepted by a shim and translated to the corresponding Open Transport XTI calls. They are then passed through the Open Transport layers.
The process is reversed for incoming packets. Open Transport receives the packet. At the .ddp layer the packet is repackaged into a classic AppleTalk code, and sent up a classic protocol stack.
An advantage of this emulation method is that the protocol stack is reliable and compatible with existing applications because emulation occurs at only one protocol level and classic implementations of ADSP, ASP, ATP, NBP, and ZIP are used. Also, the amount of RAM required for the emulation is much less than if the entire protocol stack was emulated. A drawback of this emulation method is that the emulation is time-consuming.
4. How is backward compatibility for MacTCP implemented?
The process is different than for AppleTalk in that more of the TCP/IP protocol is native Open Transport and therefore native Power PC.
Backward compatibility is accomplished by a shim that intercepts all MacTCP packets at the .ipp driver level. The shim translates the packet to the corresponding Open Transport XTI driver, and passes it to the Open Transport TCP/IP stack for processing. The process is reversed for incoming packets.
The emulation results in increased performance but does exhibit compatibility problems with existing applications and MacTCP MDEVs such as MacSLIP and MacPPP.
5. What about backward compatibility between the classic .enet driver and the Open Transport DLPI driver?
DLPI to .enet conversion
Current NuBus Macintosh computers (680x0 and DLPI) have Ethernet implementations that rely on the .enet driver architecture. Open Transport protocols can only communicate with DLPI drivers. To allow Open Transport to run on NuBus Macintosh computers (that is, to allow existing cards and drivers to be used with Open Transport), Apple has created a shim that accepts DLPI calls from the upper layer of the protocol stack and translates the calls to .enet calls.
.enet to DLPI conversion MacIPX and PATHWORKS DEC are network protocols which talk directly to the .enet driver. The shim which translates DLPI calls to .enet calls for MacTCP only works with MacIPX and DecNET when built-in Ethernet is used. This means that current versions of MacIPX or PATHWORKS cannot be used with third-party network interface cards, such as the Farallon 10/100 card. Also, the shim does not support promiscuous mode which protocol analyzers such as NetMinder and Etherpeek require.
6. Are there other known limitations to backward compatibility? Yes, Applications that rely on undocumented APIs or examine private memory data structures in the current AppleTalk or MacTCP implementations will not be fully compatible with Open Transport. Examples of this include the MacSNMP AppleTalk Agent and TCP/IP Agents, the Apple Internet Router 3.x, the Apple Remote Access MultiPort Server 2.x, the LaserWriter Bridge, and some utilities like MacTCP Watcher and MacTCP Spy. Updated versions of these software products will be required for full compatibility.
For dial-up TCP/IP access, the only version of PPP that is considered compatible with Open Transport is FreePPP.
7. When will MacSNMP be revised to work with Open Transport?
According to Apple, MacSNMP v1.5 is under development and scheduled to ship later this year. The 1.5 release will include support for MIB-II statistics from the Open Transport/TCP stack, transport of SNMP data over Open Transport/TCP, and support in the Macintosh System MIB for PCI interface cases.
8. Is Apple migrating serial communications away from the Communications Toolbox?
Partially. Apple will continue to support the Communications Toolbox (CBT) File Transfer and Terminal Managers in the Copland OS release -- although on new Open Transport/Serial underpinnings.
Over time, the CTB Connection Manager and its tools will be phased out in favor of Open Transport. In particular, while the Copland release of the Mac OS is expected to provide support for the Connection Manager APIs, at this time Apple has no plans to port the existing Connection Tools to Copland. Therefore, Apple recommends that developers plan their update to Open Transport/Serial (and away from CTB Connection Manager) to coincide with (or precede) the availability of the Copland release.
- Is Open Transport native on Power Macintosh? Does this make networking faster?
- Will existing networking applications see performance improvements with Open Transport on a Power Macintosh?
- What conditions need to be met to see a significant increase in throughput?
- Are there other factors that contribute to network speed?
- When will new or updated applications written in native Open Transport APIs become available?
1. Is Open Transport native on Power Macintosh? Does this make networking faster?
Open Transport is written in native code for the RISC processor on a PowerPC. This alone will provide higher throughput.
2. Will existing networking applications see performance improvements with Open Transport on a Power Macintosh?
If the application is written for the 680x0 processor, and uses the classic (680x0-based) networking programming interfaces, it must be emulated (translated) into Open Transport. As a result, performance does not improve.
3. What conditions need to be met to see a significant increase in throughput?
Applications that are native on the Power Macintosh and are written in the Open Transport XTI programming interface will realize the greatest performance gains. Applications written using the classic Ethernet APIs, need to be emulated (translated) into the Open Transport API. This emulation limits performance.
4. Are there other factors that contribute to network speed?
Yes. Technical issues, datagram size, network interface card (NIC) drivers, and the AppleTalk retry-acknowledgment algorithm can affect network speed. Throughput is faster with protocols such as TCP/IP because TCP/IP uses a 1500K datagram size, compared to AppleTalk which uses a fixed 512K datagram size. On high-speed datalinks (fast Ethernet, FDDI, and ATM, for example) the performance of the NIC driver code is also a significant factor. Farallon is currently testing both AppleTalk and TCP/IP performance with the latest versions of the Mac OS and Open Transport.
5. When will new or updated applications written in native Open Transport APIs become available?
New applications and updated versions of existing applications that are native and use Open Transport have been announced. Users are urged to contact the third party vendor of interest for details on specific product release plans.