Mac OS 9 FTP Clients and Open Transport Networking

In classic Mac OS 9, FTP client software relied on Apple's Open Transport networking architecture to establish and manage file transfers over the Internet. This article examines the architectural flow between classic FTP applications—such as Fetch, Transmit, and Interarchy—and the underlying operating system. It details the role of Open Transport, the utilization of endpoint-based APIs, the mechanics of dual-channel FTP communication, and how developers managed asynchronous transfers within the constraints of Mac OS 9's cooperative multitasking environment.

The Open Transport Foundation

By the release of Mac OS 9, Apple had fully transitioned from the legacy MacTCP architecture to Open Transport. Open Transport was based on industry standards, specifically the UNIX System V Release 4 (SVR4) STREAMS environment and the X/Open Transport Interface (XTI). It provided a modular, protocol-independent networking infrastructure that exposed high-performance TCP/IP services to classic Mac applications.

While Open Transport maintained a backward-compatibility translation layer for legacy MacTCP applications, native Mac OS 9 FTP clients interacted directly with the native Open Transport C and Pascal APIs.

Endpoints and Connection Management

FTP requires two separate communication channels: a persistent control connection for issuing commands (such as USER, PASV, and RETR) and temporary data connections for directory listings and file payloads.

Under Open Transport, an FTP client did not use traditional Berkeley BSD sockets by default; instead, it manipulated networking abstractions known as "Endpoints." The client followed a distinct lifecycle to communicate with an FTP server:

  1. Configuration and Creation: The client called OTOpenEndpoint or OTAsyncOpenEndpoint, passing a configuration string such as "tcp" to load the standard TCP/IP STREAMS modules into memory.
  2. Binding: The client bound the endpoint to a local port using OTBind. For the control connection and passive data connections, ephemeral ports were typically assigned by the stack.
  3. Connection Establishment: To connect to port 21 on the remote host, the client prepared a TCall structure containing the target IP address and port, then called OTConnect.
  4. Data Transmission: Once connected, raw commands were dispatched via OTSnd, and server responses were retrieved via OTRcv.
  5. Data Connections: In Active mode (PORT), the client opened a new endpoint, bound it to a local port, listened via OTListen, and accepted the inbound connection with OTAccept. In Passive mode (PASV), the client read the remote port provided by the server and initiated an outbound OTConnect call on a separate endpoint.

Asynchronous Operations and Cooperative Multitasking

Mac OS 9 relied on cooperative multitasking, meaning a single blocked process could freeze the entire graphical user interface if not handled correctly. Because network operations introduce high latency, synchronous calls were impractical for consumer FTP clients.

To maintain a responsive UI, FTP clients operated endpoints in asynchronous mode. Developers registered a universal notification callback function using OTInstallNotifier. When network events occurred—such as incoming data (T_DATA), connection confirmation (T_CONNECT), or disconnection (T_DISCONNECT)—the Open Transport stack triggered the notifier function.

Inside this notifier, or through the client’s main event loop using the Thread Manager and WaitNextEvent, the FTP client yielded CPU time back to the operating system. This mechanism allowed progress bars, transfer rates, and user cancellation inputs to remain fluid while reading or writing blocks of data to disk via the classic File Manager.

Packet Routing Through the Stack

Once an FTP client passed data to OTSnd, Open Transport processed the payload through the TCP protocol engine within the STREAMS architecture. The TCP layer segmented the stream, appended sequence headers, and routed the packets down to the IP layer for addressing.

The IP layer queried the Mac OS 9 routing table and passed the packets to the appropriate network interface hardware driver, such as an Ethernet driver (ENET), an AirPort wireless card driver, or a dial-up modem driver managed by Remote Access via PPP (Point-to-Point Protocol). Incoming packets followed the reverse path up the STREAMS modules, triggering the endpoint notifiers to deliver payloads directly into the FTP client’s memory buffers.