Just as with Ethernet, Localtalk can support different protocols, such as Appletalk, IP, DECnet etc. By connecting a gateway box between Localtalk and Ethernet, these protocols can be routed transparently between the two networks, with the result that users get similar facilities (at lower performance, of course) on the Localtalk network. The gateway box that we use is the "Compatible Systems EtherRoute/TCP", which has one Ethernet interface and two Localtalk interfaces.
Macintosh computers and printers come with built-in Localtalk electronics, needing only an inexpensive connector to link up to such a network. Localtalk interfaces for a PC can be purchased, but with PC Ethernet interfaces at less than £50 it hardly seems worth bothering: Mac Ethernet interfaces, on the other hand, although they have recently come down in price, are still quite a bit more expensive. We already have an adequate supply of Phonenet connectors, and unoccupied connections on our Farallon hubs, so, for the time being, we can connect Macs to Phonenet for no additional cost. Your choice is determined by your intended pattern of use, by the power of your machine (and by your budget, of course). I hardly need to point out the difference between 230kb/s of Localtalk and 10Mb/s of Ethernet (bits, not Bytes, remember). The LaserWriters are connected to the Localtalk network, so if your only interest in the network is for printing onto the LaserWriters, you get no benefit from an Ethernet connection. For occasional interactive network calls (TELNET, FTP) with relatively low-powered Macs, the Localtalk connection is also probably adequate. In any case, smaller Macs (Classic etc.) made no provision for an internal Ethernet interface, and the cost of an external (SCSI) Ethernet interface is out of all proportion for those low powered machines. But if you plan to access remote file servers, or make use of networked multi media applications, from a powerful Mac, then you best go for an Ethernet connection.
To get our terminology correct, I should point out that Localtalk (Phonenet) refers to the hardware, which can carry Appletalk and other protocols; Appletalk is a network protocol, which can be carried over Localtalk, and over other networks such as Ethernet. It's that "network layer-cake model" again.
Each port of a Phonenet hub can support up to 4 daisychains of stations. Each daisychain could have a couple of dozen stations, in theory, but in practice we limit each daisychain to one room, so there are rarely more than two or three stations per daisychain. I have wired our hubs to allow 2 daisychains per hub port, which seems appropriate to our circumstances.
Coming now to TCP/IP usage. In the early days of running TCP/IP software from Macs (particularly diskette-based Macs), we got tired of people handing around copies of their software complete with IP address, resulting in two or more stations trying to use the same IP address (bad news). So we decided to use the router box's facility to assign IP addresses on demand. The user takes advantage of this by selecting the "Server" button in the MacTCP control panel, and it takes away all that complication of configuring network number, subnet mask and default gateway (although you do still need to configure the nameserver). The router box has provision for handling up to 32 different IP addresses at any time, and with our pattern of use in the department that seems adequate. The box permits a mixture of server-allocated and static IP addresses, but we are not making use of any static addresses on the Localtalk network.
The situation if you use an Ethernet interface is completely different. On the Departmental Ethernet, each station is assigned a specific IP address, which has to be correctly configured into MacTCP. This address is allocated with due ceremony to the person responsible for that Mac (just the same as it is done for a PC or workstation), and that person accepts a certain responsibility for proper use. Such Macs generally have their system software on a hard disk, so there is fortunately much less risk of configured copies of system software being handed around.