Open In App

What is ATP (AppleTalk Transaction Protocol)?

Improve
Improve
Like Article
Like
Save
Share
Report

ATP stands for AppleTalk Transaction Protocol. It is a part of a series of networking protocols called the ‘AppleTalk’ developed by Apple Inc. It is a transport layer protocol that lets you transfer small amounts of data across a network. It provides an error-free and reliable means of communication in a client-server setup. It performs most of the transport layer functions like segmentation, packet sequencing, etc.

ATP works on top of an architecture that is similar to a client-server architecture. There is a requester that makes a request to another endpoint which is called a responder. The responder performs the needful and reverts back with a response.

Transactions in ATP:

The following diagram describes how a transaction occurs:

Transactions in ATP

Transactions in ATP

  1. The requester invokes the ATP interface. The interface then uses the ATP driver to establish a dedicated connection with the responder’s ATP driver.
  2. The driver at the responder side invokes the responder application which processes the incoming request and returns a response to be sent back to the requester.
  3. In order to send the response, the responder invokes its ATP interface which uses the pre-established connection to send the response back to the requester.

As mentioned before, ATP can be used to send small amounts of data. There is a restriction on the amount of data that can be transmitted by both the requester and the responder. For the requester, the data that can be transmitted is 578 bytes and for the responder, the limit is 4624 bytes.

Types of ATP Transactions:

There are two types of ATP transactions:

  1. At-Least-Once Transactions: In an ALO transaction, it is guaranteed that the responder will receive all the requests sent to it at least once. It offers no guarantee that the same request won’t be sent again to the responder.
  2. eXactly-Once Transactions: In an XO transaction, it is guaranteed that the responder will receive all the requests sent to it exactly once. It guarantees that a request that has been received once by the responder won’t be sent again.

The nature of the transaction to be used is determined by the kind of processing required by the request. If multiple executions of the same request are likely to cause some kind of inconsistency in the results obtained, then XO transactions are used. If multiple executions of the request are not likely to cause problems then ALO transactions are used.

ATP Packet Format:

An ATP packet consists of an ATP header followed by the data. The size of the ATP header is 8 bytes. The entire packet is stored inside a DDP (Datagram Delivery Protocol) datagram and is transported as a data link layer frame.

Following is the structure of an ATP packet:

Structure of an ATP Packet

Structure of an ATP Packet

The data part follows the ATP header which can be up to 578 bytes or up to 4624 bytes depending on whether the packet is being sent by the requester side or the responder side. 

Following is a detailed description of the fields of the ATP header:

Control Information Byte:

It is used to store control-related information about a request/response like the type of transaction, whether this packet is the last packet to be received or not etc. The control information byte stores the following information – 

Bit No. Description
0 Specifies whether to use the DDP checksum or not.
1 Specifies whether the transaction ID has been assigned for this request or not
2 Specifies whether this request uses an extended parameter block or not
3 Specifies whether the current packet is to be retransmitted immediately or not.
4 Specifies whether this is the last packet of the response (end-of-message) or not.
5 Specifies whether the current request is an exactly-once transaction or an at-least-once (AO) transaction.

Bitmap/Sequence Number:

The Bitmap/Sequence Number is 8 bits in size. ATP is well-known for the reliability it offers during data transmission. It guarantees that the requester will receive all the packets sent to it in response to its request. In order to do so, it needs to track which packets have been received by the requester and which are yet to be received. The approach used by ATP for the same is to assign sequence numbers to all the packets which are sent in response and to mark the last packet of response as “end-of-message” (indicated by bit 4 of the control information byte in ATP header). The requester assembles all the packets on receiving them, checks the sequence number and the control information byte of the ATP header, and determines whether it has received all the packets or not. If not, then the ATP driver on the receiver’s end initiates retransmission of the lost packets. 

Transaction ID:

The transaction ID is used to associate each request with its corresponding response. It is 16 bits in size. The requester can make multiple requests at any given time. Transaction ID helps ATP to keep track of all the requests made and to ensure that the response delivered for every request is correct. It is carried by the 3rd and the 4th byte of the ATP header.

User Data:

The last 4 bytes of the ATP header are not used by ATP. They are reserved for use by the requester and responder applications. The ATP driver supports pre-defined functions that let you set the values of these headers to what you want.

The following table summarizes the fields that are part of the ATP header:

Byte  No. Field Stored Size     (Bits) Description
1 Control Information 8 Is used to store control-related information about a request/response like the type of transaction, whether this packet is the last packet to be received or not etc.
2 Transaction Bitmap/ ATP Sequence Number 8 It is used to find the sequence number of the current packet if the packet was sent in response to a request(called ATP sequence number). In case the current packet is a request, it represents the number of buffers supported by the application (called Transaction Bitmap).
3-4 Transaction ID 16 It stores the transaction ID of every request. It is used by the responder to keep track of all the requests.
5-8 User Data 32 Carries application-specific information like checksum etc.

Last Updated : 22 Feb, 2022
Like Article
Save Article
Previous
Next
Share your thoughts in the comments
Similar Reads