Appletalk Protocol
Volume Number: 5
Issue Number: 7
Column Tag: Forth Forum
Related Info: AppleTalk Mgr
Appletalk Protocol Handlers 
By Jörg Langowski, MacTutor Editorial Staff
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
“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