Basic Networking Concepts

Although this book is intended for readers who already have some
knowledge of networking fundamentals, many people use slightly
different definitions for the same networking terms. Therefore, this section
provides definitions of networking and communications terms as used in
this book.

A network is a system of computers and other devices (such as printers

and modems) that are connected in such a way that they can exchange
data.

A networking system consists of hardware and software. Hardware on a

network includes physical devices such as Macintosh personal computer
workstations, printers, and Macintosh computers acting as file servers,
print servers, and routers; these devices are all referred to as nodes on the
network.

If the nodes are not all connected to a single physical cable, special
hardware and software devices must connect the cables in order to forward
messages to their destination addresses. A bridge is a device that connects
networking cables without examining the addresses of messages or
making decisions as to the best route for a message to take. By contrast, a
router contains addressing and routing information that lets it determine
from a message's address the most efficient route for the message. A
message can be passed from router to router several times before being
delivered must use a common set of rules defining the format of the data
and the manner in which it is to be transmitted. A protocol is a formalized
set of procedural rules for the exchange of information and for the
interactions among the network's interconnected nodes. A network
software developer implements these rules in software modules that carry
out the functions specified by the protocol.

Whereas a router can connect networks only if they use the same protocol
and address format, a gateway converts addresses and protocols to
connect dissimilar networks.

A set of networks connected by routers or gateways is called an internet.

The term Internet (note the capitalization) is often used to refer to the
largest worldwide system of networks, also called the Worldwide
Internet. The basic protocol used to implement the WorldWide Internet is
called the Internet Protocol, or IP. Because the word internet is used in
several different ways, it is important to note capitalization and context
whenever you see this word.
A networking protocol commonly uses the services of another, more
fundamental protocol to achieve its ends. For example, the AppleTalk
Data Stream Protocol (ADSP) uses the Datagram Delivery Protocol
(DDP) to encapsulate the data and deliver it over an AppleTalk network.
The protocol that uses the services of an underlying protocol is said to be a
client of the lower protocol; for example, ADSP is a client of DDP. A set
of protocols related in this fashion is called a protocol stack. Protocol
stacks are described in more detail in "Protocol Stacks and the OSI
Model" .

Note
Although it is sometimes important to distinguish between a protocol and
the software that implements the protocol, in most cases you can infer
which is meant from the context. Accordingly, this book usually uses the
term protocol rather than the more precise term protocol implementation
to refer to the Open Transport implementation of a protocol.

Types of Protocols
Networking protocols can be characterized as connectionless or
connection-oriented, and as transactionless or transaction-based.

A connectionless protocol is one in which a node that wants to

communicate with another simply sends a message without first
establishing that the receiving node is prepared to receive it. Each message
sent must include addressing information so that it can be delivered to its
destination.

A connection-oriented protocol is one in which two nodes on the

network that want to communicate must go through a connection-
establishment process called a handshake. This involves the exchange of
predetermined signals between the nodes in which each end identifies
itself to the other. Once a connection is established, the communicating
applications or processes on the nodes at either end can send and receive
data without having to add addresses to the messages or repeat the
handshake process. Connection-oriented protocols provide support for
sessions. A session is a logical (as opposed to physical) connection
between two entities on a network or internet. A session must be set up at
the beginning, maintained by the periodic exchange of information, and
broken down at the end. All of these services entail overhead compared to
a connectionless protocol, for which no connection setup or breakdown is
required and for which no session must be maintained.

A connection-oriented session is analogous to a telephone call. The party

who initiates the call knows whether the connection is made because
someone at the other end of the line either answers or not. As long as the
connection is maintained, neither party needs to dial the other telephone
number again. A connectionless protocol is analogous to mail. A person
sends a letter expecting it will be delivered to its destination. Although the
mail usually arrives safely, the sender doesn't know this unless the
recipient initiates a response affirming it. Each letter sent by either party
requires a complete address.

A transactionless protocol defines how the data is to be organized and

delivered from one node to another. A connection-oriented transactionless
protocol is used to maintain a symmetrical connection; that is, one in
which both ends have equal control over the communication. Both ends
can send and receive data and initiate or terminate the session. In this case,
the connection is referred to as full duplex. If the two sides have to take
turns transmitting and receiving, the connection is referred to as half
duplex.

A connectionless transactionless protocol sends data in discrete datagrams.

A datagram, also referred to as a packet, is a unit of data that includes a
header portion that holds the destination address (and may contain other
information, such as a checksum value) and a data portion that holds the
message text. A connection-oriented transactionless protocol can send data
as a continuous stream of data or, in some cases, as packets.

Low-level connectionless protocols such as DDP and IP usually provide

best-effort delivery of data. Best-effort delivery means that the protocol
attempts to deliver any packets that meet certain requirements, such as
containing a valid destination address, but the protocol does not inform the
sender when it is unable to deliver the data, nor does it attempt to recover
from error conditions and data loss. Higher-level protocols, on the other
hand, can provide reliable delivery of data. Reliable delivery includes
error checking and recovery from error or loss of data.

A transaction-based protocol specifies the sequence and some of the

content of messages passed between nodes. When using a transaction-
based protocol, the application on one node, known as the requester, sends
a request to the other application, known as the responder, to perform a
task. The responder completes the task and returns a response that reports
the outcome of the task. Once one node has issued a request, the receiving
node is constrained to respond in a predefined way. A transaction-based
connection is sometimes referred to as an asymmetrical connection.

Table 1-1 shows where some Open Transport protocols fit in the protocol-
type matrix. A protocol of one type can be a client of a different type. For
example, the connection-oriented transactionless AppleTalk Printer
Access Protocol (PAP) is a client of the connectionless transaction-based
AppleTalk Transaction Protocol (ATP), which is in turn a client of the
connectionless transactionless Datagram Delivery Protocol (DDP).

The Open Transport protocol matrix and some Open Transport protocols
  Connectionless   Connection-oriented
PPP Serial connection
DDP ADSP
Transactionless
IP TCP
UDP PAP
Transaction-based   ATP ASP[1]

Addressing
In order to establish a network connection or to send a message using a
connectionless protocol, you must have the address of the destination.
Each protocol uses a specific type of address, which might be the same as
that used by a lower-level protocol in the protocol stack or might be
unique to that protocol. DDP and IP, for example, use addresses sufficient
for node-to-node delivery of datagrams, through routers if necessary. The
protocols and applications that are clients of DDP are assigned socket
numbers. A socket is a piece of software that serves as an addressable
entity on a node. DDP is responsible for delivering a datagram to the
correct socket.

Similarly, IP delivers each datagram to a specific client protocol--such as

Transaction Control Protocol (TCP) or User Datagram Protocol (UDP)--
running on a specific node. The processes using the TCP/IP client
protocols are each assigned a port number; the client protocol is
responsible for delivering the datagram to the correct port number.
Whereas AppleTalk normally assigns socket numbers dynamically to a
process when it registers itself on the network, the TCP/IP port numbers
are preassigned by convention or by previous arrangement between users.

For more information about AppleTalk addresses, see the chapter

"AppleTalk Addressing" in this book. For more information about TCP/IP
addresses, see the chapter "TCP/IP Services" in this book.

Protocol Stacks and the OSI Model

Most networking systems are designed as layered architectures in which
low-level protocols provide services to higher-level protocols in the same
protocol stack. Network designers relate each protocol to a reference
model, which provides guidelines as to what sort of services should be
provided by a protocol at a certain level in the hierarchy. Because these
reference models provide a framework that makes it easier to compare the
services offered by different protocols, this book shows how each protocol
discussed relates to one or more reference models. In this section, the
Open Systems Interconnection (OSI) model is described. The OSI model
is a seven-layered standard that was published by the International
Standards Organization (ISO) in the 1970s. This is the model with which
the AppleTalk networking system architecture is most closely aligned.

It is important to note that often more than one protocol is defined and
implemented to handle the requirements of a layer in different ways. In
addition, some protocols include functions that span more than one layer
specified by a model. For example, in favor of efficiency, a network
protocol developer may elect to define a single protocol that spans two or
more layers of a reference model.

Figure 1-1 shows the layers of the OSI model and how the AppleTalk and
TCP/IP protocols provided with the Open Transport system software fit
into this model.

Figure 1-1 The OSI model and Open Transport protocols

Each layer of the OSI model has a specific purpose, as follows:

 The data-link layer and the physical layer provide for
connectivity. The communication between networked systems can
be via a physical cable made of wire or optical fiber, or it can be
via infrared or microwave transmission. In addition to these, the
hardware can include a network interface controller (NIC), if one
is used. The hardware or transport media comprise the physical
layer.

The physical hardware provides nodes on a network with a shared

data transmission medium called a data link. The data-link layer
includes both a protocol that specifies the physical aspects of the
data link, and the link-access protocol, which handles the logistics
of sending the data packet over the transport medium.

 The network layer specifies the network routing of data packets

between nodes and the communications between networks, which
is referred to as internetworking.
 The transport layer isolates some of the physical and functional
aspects of a network from the upper three layers. It provides for
end-to-end accountability, ensuring that all packets of data sent
across the network are received and in the correct order. This is the
process that is referred to as reliable delivery of data, and it
involves providing a means of identifying packet loss and
supplying a retransmission mechanism. The transport layer may
also provide connection and session management services.
 The session layer serves as an interface into the transport layer,
which is below it. The session layer allows for establishing a
session, which is the process of setting up a connection over which
a dialog between two applications or processes can occur. Some of
the functions that the session layer provides for are flow control,
establishment of synchronization points for checks and recovery
during file transfer, full-duplex and half-duplex dialogs between
processes, and aborts and restarts.
 The presentation layer assumes that an end-to-end path or
connection already exists across the network between the two
communicating parties, and it is concerned with the representation
of data values for transfer, or the transfer syntax.
 The highest layer of the OSI model is the syntax.
 The highest layer of the OSI model is the application layer. This
layer allows for the development of application software. Software
written at this layer benefits from the services of all the underlying
layers.
[1] Open Transport does not currently provide an implementation of the
AppleTalk Session Protocl (ASP).

Subtopics

Types of Protocols
Addressing
Protocol Stacks and the OSI Model

About Networking With Open

Transport
Networking on the Mac OS is implemented through the Open Transport
system software. The Open Transport software provides an API that gives
you access to the services of the various protocols. The functions you use
depend not on the specific protocol you want to use, but on whether the
protocol is connection-oriented or connectionless, and whether it is
transaction-based or transactionless.

This section describes the architecture of Open Transport and discusses

some basic Open Transport features and concepts.

Open Transport Architecture

The Open Transport system software consists of a set of application
interface and utility routines (known collectively as the Open Transport
API), a set of software modules that implement networking protocols and
other services, and hardware drivers. Below the hardware drivers are
networking and communications hardware: cards, cables, and built-in
ports. These components are illustrated in Figure 1-2 and discussed further
in the following sections.

Figure 1-2 The basic architecture of Open Transport

Open Transport API

The Open Transport API consists of two types of functions: utility

functions, which are implemented by Open Transport iself; and
intererlying software modules. Because the interface functions are
implemented by the software modules, the same function might
operate somewhat differently depending on the specific modules that
execute 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. However, whereas XTI specifies
functions only for connectionless and connection-oriented protocols,
Open Transport also includes functions for 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. Option handling is described in
"Option Management" in this book.

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. Open
Transport event handling and notifier functions are described in
detail in the chapter "Providers" in this book.

Software Modules

The software modules shown in Figure 1-2 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 receive the reply as a
message, all without interfering with any other system activity.
 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.

Figure 1-2 shows the AppleTalk implementation of the actual

STREAMS architecture.

You can write your own STREAMS modules to work with Open
Transport. The Open Transport TCP/IP software modules are based
on the UNIX STREAMS standard. This book does not cover
STREAMS or writing a STREAMS modules. For more information
about STREAMS, see UNIX System V Release 4: Programmer's Guide:
STREAMS and the Open Transport Module Devloper's SDK.

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 Open Transport control panels.
Your application can use the default port for a particular protocol or,
in some cases, you 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. In the current version, multihoming is supported
only with AppleTalk protocols.

Open Transport and Interrupt-Time Processing

Open Transport places severe limitations on functions that can be

called at hardware interrupt time and imposes some restrictions on
functions that can be called at secondary interrupt time. For a
discussion of interrupt-time processing, see "Interrupt-Time
Processing". For more detailed information, see "Programming With
Open Transport".

Providers: Endpoints, Mappers, and Services

The concept of a provider is central to an understanding of Open
Transport. A provider is a set of software modules and drivers that
provides a service to clients of Open Transport. For example, when
you open an ADSP connection, Open Transport logically links a set of
AppleTalk software modules, a communications driver, and a card or
port to create what is known as an ADSP endpoint provider. The Open
Transport includes functions for three types of providers:

 endpoint providers
 mapper providers
 service providers

You use an endpoint provider to send and receive information over a

data link. Figure 1-3 illustrates an ASP endpoint provider.

Figure 1-3 An Open Transport Provider

In order to use an endpoint provider, you must first configure and

open an endpoint. An endpoint consists of a set of data structures,
maintained by Open Transport, that specify the components of the
endpoint provider and the manner in which that provider is to
operate (blocking or nonblocking, synchronous or asynchronous, and
so forth). An endpoint also maintains state information and other
information that Open Transport needs in order to operate that
provider.

The Open Transport endpoint functions provide an application

programming interface (API) to endpoint providers. When you
configure an Open Transport endpoint, you specify which protocol or
set of protocols the provider is to use; the highest-level protocol you
specify for the endpoint provider determines whether the transport
mechanism is connectionless or connection-oriented, and whether it is
transactionless or transaction-based. For example, if you specify
ADSP as the highest-level protocol in the endpoint provider, the
transport is connection-oriented and transactionless.

See "Endpoints and Protocol Layering" for more information on the

configuration of endpoint providers.

Mapper providers implement a standard interface for dealing with

addresses. In order to receive data over a network, a process must
have a network address. Whereas an address is typically a number of
significance to the network software, it is much easier for people using
the network to refer to each addressable entity by some name.
Consequently, most networks include some naming scheme and a
facility that converts between names and addresses. For example, a
process using an AppleTalk network must register its name on the
network using the Name-Binding Protocol (NBP), which it accesses
through a mapper provider.

You use a mapper provider to relate network addresses to network

node names and to register and remove node names for networks that
support this ability. To use a mapper provider, you must configure
and open a mapper, a set of data structures that store information
about the mapper provider for use by Open Transport.

You use service providers to handle features unique to a specific type

of Open Transport service. For example, because the concept of zones
is not common to all protocol families, the AppleTalk service provider
API includes functions that deal with AppleTalk zones. Similarly, the
TCP/IP Domain Service Resolver (DNR) provides some services
specific to the TCP/IP protocol family. Consequently, the TCP/IP
service provider functions provide an interface to the DNR.

Each provider supports some subset of the standard Open Transport

functions, depending on the nature of that provider; for example, an
endpoint provider implements different functions than a mapper
provider. What's more, a connection-oriented transactionless
endpoint provider implements different functions than a
connectionless transaction-based endpoint provider.

Some Open Transport functions are common to all providers. These

allow you to open or close a provider, to determine whether a
provider executes functions synchronously or asynchronously, to issue
a command directly to a STREAMS module underlying a provider,
and so on.

When you open an endpoint, mapper, or service provider, the open

function returns a provider reference, analogous to the file reference
you get from the File Manager when you open a file. You must specify
that provider reference whenever you want to execute a function
related to that endpoint, mapper, or service. For example, to send
data, you specify the provider reference for the endpoint you want to
use.

Figure 1-4 shows the hierarchical relationship among Open Transport

providers. The C++ API provides classes that mirror this object-
oriented hierarchy.

Figure 1-4 Hierarchy of Open Transport providers

Transport Independence
In contrast to earlier Mac OS application programming interfaces
(APIs) for AppleTalk and TCP/IP, in which each protocol had a
separate and unique set of routines, Open Transport provides a single
set of functions that you can use with any protocol or protocol family.
The type of endpoint you open (connectionless or connection-oriented,
and transactionless or transaction-based) determines which functions
you call to send and receive data, independent of the specific protocol
or protocol family you use.
For example, if you open a connectionless, transactionless endpoint,
you use the OTSndUData function to send data. You use this function
whether you are using DDP, IP, or UDP. If you open a connection-
oriented, transactionless endpoint, on the other hand, you first
establish a connection using the OTConnect and OTRcvConnect
functions, and then use the OTSnd function to send data. You use these
same functions whether you are using TCP, ADSP, or any other Open
Transport connection-oriented, transactionless protocol.

Although transport independence means that you can use the same
API regardless of the protocol or communcations hardware you want
to use, it does not free you from all knowledge of the transport type.
When you open an endpoint, you must specify the highest-level
protocol in the endpoint provider, and you must call the functions
appropriate to the type of that protocol. For example, although your
application can use the same set of functions to send data through
either an ADSP or a TCP connection (that is, functions for a
connection-based transactionless protocol), you must specify which of
these protocols you want to use use when you open the endpoint.

You can customize most Open Transport protocols by the

specification of option values. Because options are both protocol
dependent and implementation dependent, the use of any option
values other than the defaults makes your code less transport
independent. Unless you have a compelling reason to change an option
value, don't specify any options. You can almost always use the
default values provided by Open Transport.

Addressing schemes are also protocol-dependent; in order to use

specific protocols, you will need to understand these schemes and to
use the appropriate protocol-dependent data structure and functions.

Endpoints and Protocol Layering

When you configure an Open Transport endpoint, you specify the
highest-level protocol to be used by that endpoint provider.
Optionally, you can specify other protocols and ports to be included in
the endpoint provider. For example, if you specify only ADSP, Open
Transport uses the default underlying protocol for ADSP, which is
DDP, over the default AppleTalk port. However, you can specify that
ADSP is to use a specific Ethernet card as the port.

Because the type of endpoint you open depends only on the highest-
level protocol in the endpoint provider, protocol layering does not
affect the transport independence of Open Transport. That is, you use
the same functions to open and maintain a connection and to send
messages whether you are using ADSP over DDP through Ethernet,
or TCP over IP through token ring.

Subtopics

Open Transport Architecture

Open Transport API
Software Modules
Drivers and Hardware
Open Transport and Interrupt-Time Processing
Providers: Endpoints, MaHREF="NetworkingWOT-
14.html#HEADING14-25">Providers: Endpoints, Mappers, and
Services
Transport Independence
Endpoints and Protocol Layering

Deciding Which Protocol to Use

Each of the networking protocols available with Open Transport
implements a different set of services. This section provides a brief
discussion of the uses of each of the protocols included with the Open
Transport system software on the Macintosh computer. If you have Open
Transport software modules provided by vendors other than Apple
Computer, Inc., you should refer to the documentation that came with that
software to determine its use.

There are instances in which the protocol to be used is dictated by the

application; for example, HTTP requires TCP. In some cases, you might
be in a position to choose the protocol yourself. If so, before you open an
endpoint, you should make your choice based on the following issues:

 general purpose or special purpose

 choice of protocol family, AppleTalk or TCP/IP
 connection-oriented or connectionless
 transaction-based or transactionless
 high- or low-level protocol

This section discusses each of these choices in turn.

General Purpose or Special Purpose

Your choice of protocol is very simple if there is only one protocol that
performs the function you are interested in. For example, if you want to
send a print job directly to an AppleTalk printer, you probably need to use
the Printer Access Protocol (PAP). On the other hand, if you want to
transfer data of a general natureions describe the factors you can take into
consideration in order to choose among those protocols.

Choice of Protocol Family

There are two sets of protocols, or protocol families, included with the
Open Transport system software: AppleTalk and TCP/IP. In addition,
other developers can provide protocols and protocol families compatible
with Open Transport. You must decide which protocol family to use for a
specific purpose. For information on the use of other protocols, see the
documentation that came with the software.

AppleTalk is a networking technology developed by Apple Computer, Inc.

Every Mac OS computer that has ever been made includes AppleTalk
hardware and system software. If your application needs to communicate
with other Mac OS computers, AppleTalk is a natural choice. Note that the
other computers need not be running Open Transport; the nodes must be
running the same protocol, but need not be using the same implementation
of the protocol.

TCP/IP, on the other hand, is the standard protocol family used by the
Worldwide Internet and by many networks owned by businesses and other
organizations. It offers faster performance compared to AppleTalk and
makes cross-platform applications easier to develop. If you wish to
communicate with the Worldwide Internet without going through a
gateway, or if you want to connect to a network that uses TCP/IP
protocols, choose one of the Open Transport TCP/IP protocols.

High-Level or Low-Level Protocol

Figure 1-1 shows the protocols provided by Apple Computer, Inc. with
Open Transport and where they fit in the OSI model. All the high-level
protocols (except UDP) shown in Figure 1-1 provide error checking and
error recovery services, including checking for correct packet sequence
and retransmission of lost or damaged packets.

If you use a high-level protocol that provides for reliable delivery of data
and error recovery, you need not implement these services yourself. On
the other hand, these protocols generate somewhat more network traffic
than the lower-level protocols, including handshake and control signals,
signals to maintain sessions, and retransmitted packets.
The network-layer protocols IP and DDP provide best-effort delivery
between nodes on a network. They are connectionless protocols and do not
correct for corruption of data, packet loss, or incorrect packet sequencing.
They generate the least possible amount of network traffic for the data
they transmit. These protocols are appropriate for applications that do not
require highly accurate data transmission and for applications that provide
their own error recovery. If you want to implement your own protocol
stack based on AppleTalk or TCP/IP protocols, these are the protocols to
use.

The high-level protocol UDP is unusual in that it comines attributes of

both high and low level protocols--that is, it does not provide error
recovery services but it checks for data corruption.

Connection-Oriented or Connectionless
Connection-oriented protocols ensure reliable delivery of data and do not
require you to repeat the recipient's address or repeat the connection
process for the duration of the session. Once you have established a
connection, the protocol maintains the connection, informing you if it has
closed for any reason. Because of the reliability of connection-oriented
protocols, they are a good choice whenever you have a lot of data to
exchange over a limited period of time. However, in order to maintain the
connection, these protocols sometimes send control signals, which result
in increased network traffic.

Open Transport AppleTalk offers two connection-oriented protocols:

ADSP and PAP. ADSP is a full-duplex transactionless protocol, well
suited to the transfer of large amounts of data. PAP is a transactionless
session-layer protocol and a client of ATP. It is intended primarily for
communication with AppleTalk printer products.

Open Transport TCP/IP provides one connection-oriented protocol, TCP,

which is a transactionless protocol. TCP, like ADSP, provides highly
reliable data delivery suitable for the transfer of large amounts of data.

Transaction-Based or Transactionless
A transaction-based protocol is suited to many client-server interactions
where the client requests services and there are a limited number of ways
in which the server can respond. File servers and printers are examples of
servers that can use these protocols. However, you should keep in mind
that transaction-based protocols limit transport independence: currently,
only Apple Talk uses these protocols. In addition, given that transaction-
based protocols incur some overhead to set up, you might consider
choosing one of the connection-oriented protocols instead; these also
involve the overhead of establishing the connection but offer more
possibility for transport-independence.

Open Transport AppleTalk includes the ATP transaction-based protocols.

An ATP transaction request must fit in a single packet; however, the
response can contain up to eight packets. ATP transactions are an efficient
means of transporting small amounts of data across the network. ATP
provides a semi-reliable loss-free transport service.

You should use ATP

 if you want to send a small amount of data

 if your application requires delivery of all packets
 if your application can tolerate a minor degree of performance
degradation
 if you do not want to incur the overhead involved in maintaining a
session

A workstation application that requires a state-dependent service should

use ADSP instead of ATP. State dependence means that the response to a
request is dependent on a previous request. For example, before a
workstation application connected to a file server can read a file, it must
have first issued a request to open the file. When a dialog is state
dependent, all requests must be delivered in order and duplicate packets
must not be sent; ADSP provides for this.

An ATP transaction-based request, such as a workstation application

requesting a server to return the time of day, is independent of other
requests and not state dependent.

The Open Transport system software does not include any transaction-
based protocols for the TCP/IP protocol family.

Summary
The following is a summary of the preceding sections:

1. If your application requires a specific protocol, use that one.

2. If your intended connectees are local Mac OS computers, use the
AppleTalk protocol family.
3. If your intended connectees are not Mac OS computers, or Mac OS
computers on a remote network, use the TCP/IP protocol family.
4. To take advantage of Open Transport's transport independence and
provide both AppleTalk and TCP/IP, let the user choose.
5. If you need reliability, use a connection-oriented protocol.
 6. If you need low overhead or you are writing a real-time
application, use a connectionless protocol.
7. Avoid transaction-based protocols.

Chapter 2 - Getting Started With

Open Transport
This chapter introduces the basic information needed to use Open
Transport. If you are writing an application or stand-alone code resource
that calls Open Transport functions, you must read the appropriate
sections in this chapter to find out how you initialize and close Open
Transport, how you configure providers, and how you specify addresses.
The code sample shown in Listing 2-4 includes material that is described
in greater detail in the next two chapters, "Providers" and "Endpoints";
however, it is highly recommended that you read through the sections in
this chapter that describe this code. Doing so will enable you to assimilate
information in the later chapters more easily and will give you a general
sense of what an Open Transport program is like.

The corresponding reference chapter, "Initializing and Closing Open

Transport Reference" provides more detailed information about the data
structures and functions introduced in this chapter.

Chapter Contents

Initializing Open Transport

Initializing From a Client Application
Initializing From a Stand-Alone Code Resource
Using ASLM and Open Transport
Using the Gestalt
Configuring and Opening a Provider
Creating a Configuration Structure
Opening a Provider
Reusing Provider Configurations
Specifying an Address
Addressing in Open Transport
Using TNetBuf Structures
Storing an Address in a TNetBuf Structure
Using Helper Routines to Initialize an Address
Closing Open Transport
Closing From Applications
Closing From Stand-Alone Code
Open Transport Libraries
Downloading a URL With HTTP
Using Threads for Easy Synchronous Processing
Specifying the Host Names and HTTP Commands
Opening an Endpoint and Setting the Mode of Operation
Connecting to the Host and Sending Data
Receiving Data From the Remote Endpoint
Error Handling
Unbinding the Endpoint and Final Clean-Up