Related Info: AppleTalk Mgr

Appletalk Protocol Handlers

By Jörg Langowski, MacTutor Editorial Staff

“Appletalk protocol handlers”

Many of you may have used Appletalk in one or the other of their programs, but the way it really works is an interesting mystery to most of us. Since a recent project of mine will have to use some of the low-level features of Appletalk, I’d like to describe some of the hooks built into it that allow you to set up your own network protocols or change those provided by Apple.

Long-time readers of MacTutor will remember that we had a series of articles on Appletalk in V1#10 and #11 already; also one of my Forth columns (V4#9) showed some examples how to use the Appletalk services from Mach2. All these articles were mainly dealing with the high-level features of Appletalk, ATP and higher. The way the low-level stuff works was more or less taken for granted, and that’s the way 95% of all programs would normally use Appletalk. Why and when do we have to take a closer look?

Imagine, for instance, a program that implements a bridge between two Appletalk networks. One may be the Localtalk connection that your Mac is hooked up to through the serial port, the other the Ethernet that you have plugged into your Ethernet card. Apple’s Network CDEV lets you change from one network to the other, but you can’t (yet) choose two networks simultaneously. Infosphere’s LIAISON™, however, allows you to do just that, bridging Localtalk and Ethernet by a process that runs on your Mac in the background. Thus, there exists at least one example to show that an Appletalk bridge can be implemented as a background process on the Mac. (The other solution, of course, being a hardware box like Kinetics’ FastPath or the Gatorbox). Such programs must use the Appletalk routines at a lower level; and I’ll give some examples how to do that in the following.

DDP packets

Remember how internet addressing works on Appletalk: Each local network has a unique network number, each device on the network a unique node number, and each separate process on the device a unique socket number.

When a process on the Mac (e.g. a word processing program) wants to communicate with another device on the network (let’s say, a printer), it will first look up its internet address using the name binding protocol described in the articles mentioned above. Once the internet address is known, it can then send out a packet to the remote device over the network or receive packets from it. The two devices can be either on the same local network, or on two different networks that are connected through bridges. Depending whether the remote device is on the same local network or not, the Appletalk driver will send your data to the network in either of two different formats. You normally don’t see the difference; the datagram delivery protocol (DDP) takes care of checking whether the destination network number is the same as your own network number or not. The two different formats are called long or short DDP packets, and their format is shown in Fig. 1.

Fig.1 : short (left) and long (right) DDP packets

Typically, when the two communicating nodes are on the same local network, DDP will send short packets. When the two nodes are on different networks, DDP will send long packets; also when the two nodes are on the same network, but the sending node doesn’t know its own network number. In that case it will set the source network number of the packet to zero and send a long packet anyway.

The first two header bytes after the flag bytes (destination and source node #) determine the two nodes on the local network that communicate with each other. In a short packet, the destination node number is the number of the final node of the communication link. However, for a long packet that is routed through a bridge, the immediate destination node is that bridge; therefore the first header byte contains the bridge’s node number and the final destination is given further down in the packet.

The distinction between the two packet formats is made in the third byte of the header, the LAP protocol type. LAP stands for link access protocol, the lowest level of the Appletalk protocol which delivers data from one node to the other on the same local network. The LAP protocol then determines what to do with the packet after is has been received.

Node addressing

There is a lot of traffic going on on a typical Appletalk network, and each node has to filter out only those packets that it needs to receive, that is, those where the destination node ID matches its own ID, or where the destination ID is $FF (broadcast packets). This is a task that has to be done by dedicated hardware. We cannot expect the Macintosh CPU to look at each single packet and see whether it has the correct ID; doing that, we wouldn’t have time for doing any other work.

Fortunately, the Macintosh’s 8530 SCC chip (serial communications controller) can be programmed to automatically detect a flag byte - a 01111110 sequence - followed by an address byte - the destination address -, and send an interrupt only if the received address matches a preset value. That way a node will ignore all packets except those that it is actually supposed to receive.

LAP protocol handlers

Now, a packet is arriving that carries the correct node number in its header, what are we going to do with the data? Whatever we do, we should do it fast, because data is arriving at a rate of 260 KBaud. The SCC’s internal buffer holds three bytes, so we have only 95 µs to take any action required. The decision what to do with the packet depends on the value of the third header byte, the LAP protocol field. Each packet structure (DDP long/short, other structures that you might have implemented) corresponds to a different protocol number.

For each protocol number that the node understands, there will be an entry in a protocol handler table consisting of the protocol number and the handler’s address. The low-level packet reception routine will search the table for the protocol number, and transfer control to the corresponding handler if it is found. Otherwise, the packet will just be ignored.

The protocol handler table is located in the Appletalk global variable area; the address of this area is kept in the low-memory global ABusVars ($02D8). The structure of the Appletalk global variable area is described in part in Inside Macintosh II-328, the protocol table is not specified there. This is because the format of the protocol table depends on the specific Appletalk implementation, the MPP driver in the System file expects a different format than that in ROM. As an example, I’ll give the format for the MacII (and SE) when Appletalk has been loaded from ROM:

0 sysLAPAddr This node ID (byte)

1 toRHA read header area (24 bytes)

25 sysABridge Node ID of a bridge on the

local network (byte)

26 sysNetNum This network number (word)

28 vSCCEnable status register value to

re-enable SCC interrupts

(word)

(some unspecified bytes)

36 LAPprotNums LAP protocol numbers

(8 bytes)

44 LAPprotProcs LAP protocol handlers

(32 bytes = 8 pointers)

Each entry in the protocol table is either a protocol number at (36+i) and a corresponding address at (44 + 4*i) with i=0 to 7, or $FF and a zero address for free slots in the table. We see that a maximum of eight different protocols are allowed; this is because checking of the protocol type and control transfer to the handler must be completed in the allowed time frame of 95 µs.

Thus, when the protocol number of the packet corresponds to a valid protocol handler in the table, control will be transferred to that protocol handler. This month’s example program contains a protocol handler that can be installed instead of the default handler for long DDP packets (LAP type 2). A warning in advance: Installing this handler will completely screw up most of your Appletalk services, since your Mac won’t understand long DDP packets correctly anymore.

The default DDP protocol, after reading the packet header (Fig. 1), gets the address of a socket listener routine from the socket table, where socket numbers and listener routine pointers are arranged similar to the protocol handlers in the protocol table. The socket table is also kept in the ABusVars block pointed to by A2. The default protocol handler transfers control to a socket listener if it finds one in the table. For long DDP packets, we will now replace the default handler by one that simply reads the packet data into a buffer and does nothing else. You may then - from Mach2 - look at the packet data in the buffer. To restore normal Appletalk operation, you must disable and re-enable Appletalk from the Chooser. This restores the default handlers.

The new handler code is defined in the word myLAP2. When a packet arrives, it will first verify whether the destination network is the local network. If so, it will read the packet data into a buffer which is located just in front of the handler code. It will then construct a short DDP packet out of the long one by stripping all the network information. This packet could then be re-sent to the network; setting the SetSelfSend flag to true, the same node would receive it again, this time through the LAP type 1 protocol handler. The corresponding code is commented out, since it did not work for me in this simple manner. So far, the protocol handler can only be used to look at the raw packet data. I’ll keep you informed when I’ve found the reason why.

attach.ph and detach.ph are used to insert and remove handlers in the protocol table. A handler can only be attached to a protocol type if that type is not yet present in the table; therefore to change the LAP type 2 handler we have to remove the old one, then install the new one. change.prots gets a block in system heap space, moves the handler code with the buffer areas into that block, and installs the new protocol handler.

This almost concludes my short introduction into low-level Appletalk stuff; a lot of the information presented here is not documented in any Apple documentation that I’m aware of and could only be found out by disassembling into ROM. Disassembly also showed me the function of two more Appletalk system globals, the procedure pointers ATalkHk1 ($B14) and ATalkHk2 ($B18). Both are active when they are non-NIL: ATalkHk1 seems to be called on each _Control call to the .MPP driver, and ATalkHk2 on every writeLAP call. ATalkHk2, in particular, would enable you to define alternate link access protocols, as for Ethernet, ISDN, and the like (for more detail on this, see the Alternate Appletalk Connections Reference, APDA #KNB007).

Listing 1: LAP protocol handler example
only forth also assembler

\ Appletalk LAP protocol handler example
\ 12.05.89 JL
$904 constant currentA5

DECIMAL

12 constant ioCompletion
18 constant ioFileName
18 constant userData
24 constant ioRefNum
26 constant csCode
27 constant ioPermission
28 constant socket
28 constant protType
30 constant addrBlock
30 constant handler

9constant mppUnitNum 
mppUnitNum 1+ negate 
 constant mppRefNum

\ LAP defs
1constant LAPshortDDP
2constant LAPLongDDP
-94constant lapProtErr
-95constant lapExcessCollns

243constant lapWrite
244constant lapDetachPH
245constant lapAttachPH

-1 constant lapOverrunErr
-2 constant lapCRCErr
-3 constant lapUnderrunErr
-4 constant lapLengthErr

\ DDP defs
5constant ddpHdSzShort
13 constant ddpHdSzLong

1constant ddpRTMP
2constant ddpNBP
3constant ddpATP

$7Fconstant ddpMaxWKS
586constant ddpMaxData
$3ff  constant ddpLengthMask
128constant ddpWKS

-91constant ddpSktErr
-92constant ddpLenErr
-93constant ddpNoBridgeErr

\ CsCode values for DDP Control calls- MPP
246constant ddpWrite
247constant ddpCloseSkt
248constant ddpOpenSkt

256constant setSelfSend

$1FA  constant pRamByte
$1FB  constant SPConfig
$291  constant portBUse
$2D8  constant ABusVars
$2DC  constant ABusDCE

\ ABusVars block
0  constant sysLAPAddr
1  constant toRHA
8  constant dstNetNum
25 constant sysABridge
26 constant sysNetNum
28 constant vSCCEnable

header handler.start
header ATPblock 50 allot
header LAP1block 8 allot
header packet 586 allot
.trap   _control,async  $a404
.trap   _newptr,sys$a51E
CODE myLAP2
 moveq.l#ddpHdSzLong-2,D3
 move.w sysNetNum(a2),D2
 jsr    (a4)
 bne    @2
 cmp.w  dstNetNum(a2),d2
 bne    @1
 lea    packet,a3
 move.l #586,d3
 jsr    2(a4)
 bne    @2
 lea    LAP1block,a0
 move.b toRHA(a2),(a0)    \ dest node ID
 move.b toRHA+1(a2),1(a0) \ source node ID
 move.b #1,2(a0) \ LAP type = 1
 move.b toRHA+3(a2),3(a0) \ length field MSB
 move.b toRHA+4(a2),4(a0) \ length field LSB
 move.b toRHA+13(a2),5(a0)\ dest skt number
 move.b toRHA+14(a2),6(a0)\ src skt number
 move.b toRHA+15(a2),7(a0)\ DDP prot type
\_debugger
\ set up parameter block for LAPwrite call
\lea    ATPblock,a0
\move.w #mppRefNum,ioRefNum(a0)
\move.l #0,ioCompletion(a0)
\move.w #LAPwrite,csCode(a0)
\lea    LAP1block,a1
\move.l a1,addrBlock(a0)
\move.w vSCCEnable(a2),sr \ re-enable interrupts
\_control,async
@2 rts
@1 moveq.l#0,d3
 jmp    2(a4)
END-CODE
header handler.end
: call.mpp
 mppRefNum  [‘] ATPBlock ioRefNum + w!
 [‘] ATPBlock call control
;
: attach.ph ( protType handler -- flag )
 ( handler )  [‘] ATPBlock handler + !
 ( protType ) [‘] ATPBlock protType + c!
 lapAttachPH  [‘] ATPBlock csCode + w!
 call.mpp
;
: detach.ph ( protType -- flag )
 ( protType ) [‘] ATPBlock protType + c!
 lapDetachPH  [‘] ATPBlock csCode + w!
 call.mpp
;
: set.self.send ( self_send_flag | old_flag -- )
 setSelfSend [‘] ATPBlock csCode + w!
 ( flag ) [‘] ATPBlock 28 + c!
 call.mpp drop \ result code
 [‘] ATPBlock 29 + c@
;
: get.sys.block  
    [‘] handler.end [‘] handler.start - 
    MOVE.L (A6)+,D0
    _newptr,sys ( get memory block in system heap )
    MOVE.L A0,-(A6)
;
: change.prots { | protPtr -- }
 get.sys.block -> protPtr
 protPtr IF
 [‘] handler.start protPtr 
 [‘] handler.end [‘] handler.start - cmove
 2 detach.ph 
 abort” Could not detach protocol handler”
 2 [‘] myLAP2 [‘] handler.start -
 protPtr +
 attach.ph
 abort” Could not attach protocol handler”
 255 set.self.send drop
 ELSE .” Could not get memory for protocol handler”
 THEN
 cr .” Buffer area is at “ protPtr 50 + . cr
;