Inside Macintosh: Networking With Open Transport / Part 1 - Open Transport Essentials

Chapter 15 - Datagram Delivery Protocol (DDP)

Using DDP

To explicitly use DDP, you open and bind a DDP endpoint. You can then use that endpoint to send or receive data in discrete packets. For outgoing packets, DDP forms the packet header and hands the packet to the appropriate data link. For incoming packets, DDP examines the packet header and attempts to deliver any packet to the specified endpoint as long as the packet meets the following criteria:

• The destination address is valid.

• The default type of the packet matches that of the receiving endpoint.

• The length of the packet matches the length specified in the packet header and does not exceed the maximum for a DDP packet.

• The checksums match (if checksumming is enabled).

If any of these conditions is not satisfied, DDP discards the packet without notifying either the sender or the receiver of the packet. In addition, DDP has no provision for requesting the sender to retransmit a lost or damaged packet.

Binding a DDP Endpoint

As with any endpoint, before you can use it to send or receive data, you must bind it to a physical address. The OTBind function takes three parameters: one that specifies the endpoint to be bound, one that requests a specific address, and one that returns the actual address to which Open Transport bound the endpoint.

When binding a DDP endpoint, you can request a particular DDP address, including a static socket address. You can also choose to only specify a DDP type for the endpoint, in which case you set the other fields of the DDP address structure to 0 and allow DDP to dynamically assign a socket. The chapter "AppleTalk Addressing" describes the different address formats you can use to specify an endpoint address.

When you bind a DDP endpoint, there are a few considerations to bear in mind. For example, you do not have to specify the endpoint's socket and the DDP type, but DDP behaves differently depending on whether you specify them or not. Here are the points to remember:

• If you bind without specifying a socket, DDP uses a dynamically assigned one; if you specify a socket, DDP tries to use it (a statically assigned socket).

• If you bind by specifying a DDP type of 0 to a specific socket, Open Transport sets the endpoint's DDP type to a value of 11. This gives you exclusive access to the socket, which means that no other endpoint can bind to it.

• If you bind using a specific DDP type, Open Transport sets the endpoint's DDP type to that value. If you bind another DDP endpoint to that socket, you must give it a different type.

• If you bind with a combined DDP-NBP address, Open Transport uses the DDP part of the address as described in the two preceding bullets. If the bind succeeds, Open Transport registers the NBP name on the endpoint's socket.

• If you bind with an NBP address only, there is no socket number in that form of address, so DDP uses a dynamically assigned socket. If the bind succeeds, DDP registers the endpoint's NBP name on that socket. The endpoint has no default DDP type, so Open Transport sets the DDP type to a value of 11. This has the same effect as described in the earlier bullets.

Using the DDP Type Field to Filter Packet Delivery

You can choose to filter your packet delivery service by using the DDP type field in the endpoint's DDP address structure. The DDP type field is ignored by all protocols other than DDP, so you do not specify the DDP type when passing an address to an AppleTalk endpoint for all protocol layers above DDP.

If you specify a valid nonzero DDP type value when you bind an endpoint, Open Transport uses that value as the default DDP type for that endpoint, using it on all packets sent from that endpoint. If you do not specify a DDP type value or use a value of 0, Open Transport uses a DDP type value of 11 as the default DDP type for that endpoint. If you specify a different DDP type value for any individual packet that you send, Open Transport overrides the endpoint's default DDP type and uses the packet's DDP type.

When receiving incoming packets, a specified DDP type works as a filter: you only receive packets of that one type. If, however, you bind an endpoint without a DDP type or with a DDP type of 0, you receive all incoming packets.

Using the DDP type field when you bind a DDP endpoint has special significance for both sending and receiving packets, as shown in Table 15-1.

Table 15-1 Effects of using the DDP type field

Task	A nonzero DDP type specified at bind	No DDP type or a DDP type of 0 specified at bind
Send	Open Transport uses this DDP type for outgoing packets unless you specify a different DDP type on a per packet basis.	Open Transport uses a DDP type of 11 for outgoing packets unless you specify a different DDP type on a per packet basis.
Receive	You only receive incoming packets for this DDP type.	You receive all incoming packets.

Using the Self-Send and Checksum Options

DDP has two options you can use to control the behavior of DDP endpoints: the OPT_SELFSEND and the OPT_CHECKSUM options.

You can use the OPT_SELFSEND option with DDP to turn self-sending on, which means that when you send a broadcast packet, the packet will also be passed to the node itself for processing. To turn this on, you set this option with a value of 1. By default this option is turned on.

You can use the OPT_CHECKSUM option when sending packets to enable the calculation of checksums. A value is calculated when the packet is sent. When the packet is received, DDP calculates a checksum for the packet. If the calculated checksum does not match the packet's checksum, DDP assumes the packet has been corrupted and discards the packet without notifying its sender or receiver.

You can specify the OPT_CHECKSUM option on every call to OTSndUData and control the use of checksums on a per packet basis, or you can use the OTOptionManagement function to enable or disable checksums for all outgoing packets. The checksum option OPT_CHECKSUM can have one of two values: T_NO, which disables checksums, or T_YES, which enables it. By default this option is turned off.

For more information about using options, refer to the chapter "Option Management".

Using Echo Packets

You can use the AppleTalk Echo Protocol (AEP), a client of DDP, to measure the performance of an AppleTalk network or to test for the presence of a given node. Knowing the approximate speed at which an AppleTalk internet delivers packets is helpful in tuning the behavior of an application that uses a higher-level AppleTalk protocol, such as ATP and ADSP.

AEP is implemented in each node as a DDP client process referred to as the AEP Echoer. To use the AEP Echoer, you use the OTSndUData function to send a packet, called the echo request packet, to the target node, and you use the OTRcvUData function to receive a packet in response, called the echo reply packet.

AEP uses the statically assigned socket number 4, known as the echoer socket, to listen for echo packets. Whenever the endpoint associated with this socket receives a packet, AEP examines the packet's DDP type. A value of 4 identifies it as an AEP packet, and AEP then examines the first byte of the packet's data portion. A value of 1 identifies the packet as an echo request packet (sent out from your endpoint), and a value of 2 identifies the packet as an echo reply packet (returned to your endpoint from the remote node).

If the packet is an echo request packet, AEP changes this first byte to a value of 2 (an echo reply packet) before calling DDP to send the packet back to the socket from which it originated.

To test for the presence of a given node, you can iterate through a series of addresses--sending each several packets. If a node exists, AEP sends a packet back; if the node doesn't exist, no packet returns. Be sure to send each node address several packets in case one or more are lost in transmission.

To measure network performance, you need to know the round-trip time of a packet between two nodes on an AppleTalk internet. This is dependent on such factors as the network configuration, the number of routers and bridges that a packet must traverse, and the amount of traffic on the network. As these change, so does the packet transmission time. ATP protocol options let you specify retry-count and interval numbers whose optimum values you can better assess if you know the average round-trip time of a packet on your application's network.

Here are some general guidelines for using the AEP Echoer to measure network performance:

• Use the maximum packet size that you plan on using in your application.

• Accept only echo reply packets from the target node. Set the DDP type field of your endpoint to 4 to filter out all packets except for AEP packets.

• Send more than one packet and calculate the average round-trip time.

  Typically, you should receive an echo reply packet within a few milliseconds on a LAN and within a few seconds on a WAN. If you do not get a response after about 10 seconds, you can assume that DDP dropped or lost your echo request packet, and you can resend the packet.

  The echo reply packet contains the same data that you sent in the echo request packet. If you send multiple packets to determine an average turnaround time and to compensate for the possibility of lost or dropped packets, you should include different data in the data portion of each packet. This allows you to distinguish between replies to different request packets in the event that either some replies are not delivered in the same order that you sent them or that some packets are dropped.

• Bracket the code that sends and receives echo packets with a call to the OTGetTimeStamp function. This function gives much better resolution than the TickCount function.

Working With Multinodes

If you are using DDP, you can specify a multinode address for an endpoint. This allows you to bind endpoints to multiple node addresses on the same physical port, which can be useful for testing. Using only one physical machine, you can use multinode addressing to simulate multiple machines.

If a multinode client sends a broadcast or self-send packet, Open Transport makes copies of the packet for the other multinode clients on the same machine internally, thus reducing traffic on the network.

The significant fields for the multinode address format are the network number and node ID. You can request specific values for these address elements when you bind a multinode endpoint and the OTBind functionwill return the actual network and node values for the address to which Open Transport bound the endpoint. Multinode endpoints must use the DDP_OPT_SRCADDR option to specify the source DDP address for outgoing packets on a per-packet basis.

The DDP Source Address Option

DDP defines the option DDP_OPT_SRCADDR, which sets the source address for outgoing packets. This option is required for multinode endpoints, such as ARA, but can also be used with other types of endpoints.

The option's value must be a DDP address structure using the AF_ATALK_DDP address format. The source network number, node number, and source socket are taken from the DDP address.

This option allows a multinode endpoint to tell Open Transport which of its several sockets actually sent the packet.

Using General Open Transport Functions With DDP

This section describes any special considerations you must take into account for Open Transport functions when you use them with the Open Transport DDP implementation. DDP uses the following Open Transport functions:

• OTBind

  The OTBind function associates a local protocol address with the endpoint you specify with the ref parameter. You can only bind one DDP or multinode endpoint to a single protocol address.

• OTSndUData

  The OTSndUData function sends data through connectionless transactionless protocols.

  When you use this function with DDP, you can enable raw mode packet processing both on send and receive by sending a TNetBuf structure with the unitdata.addr.len field set to 0xffffffffUL. With raw mode enabled the contents of the unitdata.udata.buf field is the complete DDP packet that will be sent out by the OTSndUData function.

  To disable raw mode packet processing, send a standard DDP packet with the unitdata.addr structure fields filled in normally.

• OTRcvUData

  The OTRcvUData function receives data through connectionless transactionless protocols.

• OTRcvUDErr

  Clears an error condition arising in the course of data transmission and returns the reason for the error.

---

Subtopics

Binding a DDP Endpoint

Using the DDP Type Field to Filter Packet Delivery

Using the Self-Send and Checksum Options

Using Echo Packets

Working With Multinodes

The DDP Source Address Option

Using General Open Transport Functions With DDP