Please consider a donation to the Higher Intellect project. See https://preterhuman.net/donate.php or the Donate to Higher Intellect page for more info.

Link-Access Protocol (LAP) Manager

From Higher Intellect Vintage Wiki
Jump to navigation Jump to search

A set of operating-system utilities that makes it possible for the user to select among AppleTalk connection files by using the Network control panel to specify which network is to be used for the node’s AppleTalk connection. The LAP Manager provides for AppleTalk’s data-link independence.

The Link-Access Protocol (LAP) Manager is a set of operating-system utilities that provide a standard interface between the higher-level AppleTalk protocols and the various link-access protocols, such as LocalTalk (LLAP), EtherTalk (ELAP), TokenTalk (TLAP), and FDDITalk (FLAP). This chapter describes the LAP Manager programming interfaces to the AppleTalk Transition Queue and the 802.2 packet protocol handlers only. This chapter does not discuss the LAP Manager interface to AppleTalk connection files of type 'adev' that comprise the data links. Apple Computer, Inc. recommends that you not write your own 'adev' files. However, for a description of the LAP Manager that includes the interface to AppleTalk connection files for EtherTalk and other AppleTalk connections, see the Macintosh AppleTalk Connections Programmer’s Guide.

About the LAP Manager

A Macintosh computer on an AppleTalk network can include one or more AppleTalk connection files. An AppleTalk connection file is a file of type 'adev' that contains a link-access protocol implementation for a data link (ELAP for EtherTalk, for example). One important function of an AppleTalk connection file is to implement the AppleTalk Address Resolution Protocol (AARP) that maps hardware layer addresses to AppleTalk node addresses. The LAP Manager makes it possible for the user to select among AppleTalk connection files by using the Network control panel to specify which network is to be used for the node’s AppleTalk connection. When the user selects a connection from the Network control panel, the LAP Manager routes AppleTalk communications through the selected link-access protocol and hence through the selected hardware. The LAP Manager acts as a switching mechanism, interceding between the higher-level AppleTalk protocols and the data links so that when a user selects or changes the type of data link to be used, the process is transparent to the higher-level AppleTalk protocols and has no effect on applications that are clients of these protocols.

In addition to providing an interface to AppleTalk connection files, the LAP Manager also maintains the AppleTalk Transition Queue, which is an operating-system queue that can notify your application each time an AppleTalk transition occurs. An AppleTalk transition is an event, such as an AppleTalk driver being opened or closed or a network connection being broken, that can affect your AppleTalk application.

At any given time there might be two or more applications running that use AppleTalk. If one of these applications opens the .MPP driver, the other AppleTalk applications that use the driver are affected. If the operating system closes the AppleTalk .MPP driver, all AppleTalk applications using the driver are affected. To ensure that your application is not adversely affected by such an event, your application can place an entry in the AppleTalk Transition Queue. The LAP Manager sends a message to each entry each time the operating system or any routine performs any of these operations:

  • opens the .MPP driver
  • closes the .MPP driver
  • indicates that it intends to close the .MPP driver
  • cancels its intention to close the .MPP driver
  • reports that it is changing the flagship name (This is a personalized name that a user can enter to identify the system when it is connected to an AppleTalk network.)
  • indicates that it intends to change the flagship name
  • cancels its intention to change the flagship name
  • reports that the network connectivity has changed (for example, that a previously interconnected network is no longer available)
  • reports that the cable range for the current network has been changed
  • changes the speed of the CPU
  • defines its own AppleTalk event and calls the AppleTalk Transition Queue to inform it that such an event occurred

Each of these events is referred to as an AppleTalk transition.

The LAP Manager also includes a protocol handler that reads 802.2 packets and provides an interface that allows you to attach your own protocol handler to receive 802.2 Type 1 packets. An 802.2 protocol handler is an application or process that receives, reads, and processes these 802.2 data packets. An 802.2 packet conforms to the 802.2 data-link standard called Logical Link Control (LLC) defined by the Institute of Electrical and Electronics Engineers (IEEE) for use on Ethernet, token ring, FDDI, and certain other data links. The 802.2 Type 1 protocol specifies a connectionless or datagram service. (The AppleTalk ELAP, TLAP, and FLAP implementations process 802.2 Type 1 packets.)

The LAP Manager and 802.2 Protocol Packets

The Institute of Electrical and Electronics Engineers (IEEE) has defined a series of communications protocols for use on a variety of networks. At the physical level, these protocols include the 802.3 CSMA/CD protocol, the 802.4 token bus protocol, and the 802.5 token ring protocol. At the data-link level, you access these protocols through the IEEE 802.2 Logical Link Control (LLC) protocol. If you write an application that handles 802.2 Type 1 data packets, you must include a protocol handler to read the data. You can install your application as a client of the LAP Manager to receive 802.2 packets from an Ethernet, token ring, or FDDI driver.

The LAP Manager includes two routines that allow you to attach and detach protocol handlers for 802.2 Type 1 data packets: the L802Attach and L802Detach routines. The LAP Manager contains a generic protocol handler that receives data from the hardware device drivers and determines for which application the 802.2 packet is meant based on the protocol type. The LAP Manager’s protocol handler then calls the destination application’s protocol handler to read in the data. This section uses Ethernet to illustrate how this process works; however, the same process applies to token ring and FDDI packets.

The ANSI/IEEE standards for the 802 protocols are published by the IEEE. The first 14 bytes of a packet sent or received by the .ENET driver constitute the header. The first 12 bytes consist of the destination and source data-link addresses, such as the Ethernet hardware addresses. If the value of the last 2 bytes in the header is greater than 1500, then the .ENET driver treats that field as an Ethernet protocol type discriminator; this indicates that the packet is an Ethernet Phase 1 packet. If the value of the last 2 bytes in the header is less than or equal to 1500, then the field contains the length of the 802.2 packet, not including the 14-byte header, and this indicates that the packet is an Ethernet Phase 2 packet. The .ENET driver passes all Phase 2 packets to the LAP Manager.

The IEEE LLC standard defines the concept of a Service Access Point (SAP). A SAP is a 1-byte value that is used to distinguish the different protocols using 802.2 in a single node. Most SAPs are reserved for use by IEEE standard protocols. IEEE has reserved one SAP, whose value is $AA, for use by protocols other than the standard IEEE protocols. AppleTalk and many other protocol families use SAP $AA. Because other protocol families can also use this SAP, the value of another field that contains the subnetwork access protocol (SNAP) type is used to discriminate for which protocol family a packet with a destination subnetwork access protocol value of $AA is intended.

At the physical level, a packet contains the 802.3 header, the data field of which contains either an Ethernet protocol type discriminator (for Phase 1 packets) or the 802.2 packet length (for Phase 2 packets). For all Phase 2 packets, the LAP Manager receives the entire 802.3 packet from the .ENET driver. The first 14 bytes of the 802.3 data constitute the frame header, and they are followed by the 802.2 protocol header.

The first byte of the 802.2 header is the destination service access point (DSAP). If the DSAP value is equal to $AA, then the first 5 bytes of the 802.2 data constitute a SNAP protocol type discriminator. If the SNAP type value is $00000080F3, indicating the AppleTalk Address Resolution Protocol (AARP), then the next 4 bytes of the 802.2 data constitute the AARP packet type field. AARP is not discussed at length in this book; for complete information about AARP, see Inside AppleTalk, second edition.

For Phase 2 packets, the last 2 bytes of the 802.3 header contain the 802.2 packet length, not including the 14-byte header; the 802.2 packet length is a value from 0 through 1500.

The Ethernet driver would deliver this entire packet to the LAP Manager; the 802.2 packet is enclosed in the 802.3 packet, which is also referred to as a frame. The data frame on the right shows an Ethernet 802.3 packet containing an 802.2 packet to be delivered to the Phase 2 Ethernet AARP handler; the SNAP type value is $00000080F3, indicating the AppleTalk Address Resolution Protocol (AARP).

When you call the L802Attach routine, you provide a pointer to your protocol handler, the reference number of the .ENET driver, and a pointer to a string containing one or more type fields. The type fields indicate the DSAP value and any other protocol type fields (such as the SNAP type and the AARP type). The LAP Manager delivers to your protocol handler any 802.2 data packets that have the protocol type you specify.

Attaching and Detaching 802.2 Protocol Handlers

You must use the LAP Manager to attach your protocol handler for 802.2 protocols to receive Ethernet Phase 2 packets and all token ring and FDDI packets.

The LAP Manager is designed to install a generic protocol handler that receives packets from the hardware device drivers for 802.2 protocols and that also serves as a dispatcher. The LAP Manager’s protocol handler maintains an index of registered protocol types and pointers to their protocol handlers. When an application calls the LAP Manager to attach a protocol handler, the LAP Manager adds an entry for the application’s protocol type and protocol handler to its protocol handler index.

The LAP Manager’s protocol handler determines for which application data is meant. When processing a packet, the LAP Manager reads the destination SAP; if the SAP value is $AA, the LAP Manager then checks the SNAP header for the protocol type, and then it searches for a protocol type match in its protocol handler index. If the LAP Manager finds a protocol type match, it calls the destination application’s protocol handler to read in the data. You cannot replace or override the permanent LAP Manager protocol handler.

The first time that a process or application calls the LAP Manager to attach a protocol handler for 802.2 packets, the LAP Manager calls the specified hardware device driver directly to install its own generic protocol handler. The LAP Manager then registers in its index the protocol handler and the protocol type for the process that initially called it. When a process or application subsequently calls the LAP Manager to attach a protocol handler to receive 802.2 packets from the same type of hardware device driver, the LAP Manager simply adds the protocol handler and protocol type information for that process to its index.

There are no high-level interfaces for the LAP Manager 802.2 protocol routines. You call these routines from assembly language by placing a routine selector in the D0 register and executing a JSR instruction to an offset 2 bytes past the start of the LAP Manager. The start of the LAP Manager is contained in the global variable LAPMgrPtr ($B18).

Before you call these routines, you must place the reference number of the .ENET driver in the D2 register and a pointer to the protocol type specification in the A1 register. Before you call the L802Attach routine, you must also place a pointer to your protocol handler in the A0 register. Both routines return a nonzero value in the D0 register if there is an error.

See Also