I wrote these bullet points for a forum member in PM and they encouraged me to post it as a thread here. Lots of people know IP fairly well, and a lot of that knowledge is transferrable to AppleTalk. Here's a very brisk guide to layers 2 and 3 in AppleTalk land.
First, "What is AppleTalk":
First, "What is AppleTalk":
- AppleTalk is a protocol on the same level as IP. It is very like IP, in fact: it's a packet-oriented routable protocol. AppleTalk addresses are three bytes long. The first two are a network number, and the last one is a host number. You can only have 255 hosts on a single AppleTalk network, like an IP /24, but you can have multiple AppleTalk networks plugged into each other with a router in the middle, like IP.
- You basically never see AppleTalk addresses, though, except on A/UX and MacOS X, because all addressing is dynamic. When a computer comes onto a network, it remembers the address it had last time, and tries to use it again: if the address is free, it uses it, if it isn't, it changes and tries again. There's no DHCP-equivalent, computers on a network agree addressing between them.
- Much like in IP, software can open sockets to communicate with other computers. Sockets have a "socket number", which is what IP calls a port number. But again, you almost never see a socket number in the UI, because of NBP.
- NBP is the equivalent of DNS (or mDNS). When a client wants to find a server, it sends out a broadcast NBP lookup saying "give me all servers of this type". So, when you click on AppleShare in the Chooser, it broadcasts a lookup saying "Hello all AppleShare servers, please reply to this message." They do, and those go in the list in the Chooser.
- Unlike DNS, however, these responses include the socket number. So the NBP reply says "connect to computer 2.7 at socket 27". This means there don't need to be any fixed socket numbers aside from some very low-level ones, because the user always discovers services via NBP, which tells you the socket number.
- Much like IP, AppleTalk can run over several different cabling systems. Ethernet is the most popular option these days. Note that this isn't "AppleTalk in IP over Ethernet", AppleTalk runs directly over Ethernet.
- LocalTalk is another option. LocalTalk is a bus network, where computers are daisychained through their serial ports. It uses RS485 as an electrical standard, and talks a protocol called SDLC over it, which was a very common way of building a low-cost network at the time.
- You can either bridge LocalTalk to Ethernet or route it. Bridging is kind of like what a WiFi AP does between WiFi and Ethernet: a computer on one side of the bridge sees a computer on the other as on the same network. Routing is like IP routing: two computers on two networks see each other as on different networks, but can send packets between them.
- Bridging is simpler, but has some wrinkles: routing is more flexible, but you have to configure it.
- Usually, when a computer has both AppleTalk and IP enabled, they act as separate network stacks, like running IPv4 and IPv6 on a modern computer. They can either share a network interface or use different network interfaces: IP applications send IP packets, which turn into IP-typed ethernet frames, and AppleTalk applications send AppleTalk packets, which turn into AppleTalk-typed Ethernet frames.
- The problem comes when you have LocalTalk in the picture. LocalTalk, for highly technical and rather silly reasons, can't run IP directly over it. So, if you want to give LocalTalk-connected Macs IP connectivity, this has to be done by tunneling it over AppleTalk - kind of like each LocalTalk-connected Mac has its own ad-hoc VPN over AppleTalk. The system of running IP over AppleTalk is called MacIP.
- Obviously, you need the other end to this little VPN: you need something that has "real" IP connectivity to unwrap the packets from AppleTalk and send them on. This is called a MacIP gateway, and there are a number of options, including the macipgw appliance maintained by a forum member.