Technical Notes on Asynchronous AppleTalk and the Sand Hill network reactor.
Asynchronous AppleTalk™ was first developed at Dartmouth College by Rich Brown and Steve Liggett of the Kiewitt Computing Center. It was developed in order to provide AppleTalk service to campus offices which could not be directly connected to an AppleTalk™ bus or just required the mobility of dial-in service.
The technique is simple really, just remove the normal AppleTalk Link Access Protocol drivers and replace them with a clever piece of code which imposes some very simple handshaking and address verification, then transmits AppleTalk packets asynchronously to what it believes is a bridge. The bridge then routes the packets according to the destination ID (or broadcasts the packet). Although the Dartmouth system ultimately joins with normal 230Kbps AppleTalk buses, in no way is this necessary to enjoy the benefits of such a well-supported LAN system.
The Sand Hill reactor operates somewhat like an AppleTalk bridge, but assumes that there are only asynchronous AppleTalk devices; devices that are termed 'semi-formal'which are addressable from other reactors but speak no flavor of AppleTalk (such as PC's, modems, printers etc.); and devices which are not addressable from the extended network.
The Sand Hill reactor naturally converts baud rates, byte length, parity and handshaking, and provides extended network routing and connectivity between any of the devices on a local or dial up reactor as well as with any devices on any reactors that may be connected to this one. In other words, large reactor nets may be constructed by connecting reactors with temporary or dedicated links.
Each of the reactors has a unique ID which translates in AppleTalk to a Network ID, with each physical port on a reactor being an AppleTalk Node. Data is packetized into AppleTalk-like blocks for ports which have no formal protocol, and are routed by the reactors automatically as determined by the destination address in the header of the block. Arriving at a reactor to which the destination device is connected, the data may be stripped of its formatting and delivered 'raw' or may keep its format and be delivered to a Mac or PC which knows what to do with data from this source.
The reactor allows devices such as printers, plotters, and modems to be spooled or contended, and provides automatic throttling to sources which may be local or remote. Thus the network cannot be strangled by a single source sending thru a dozen reactors to a plotter, etc.
The routing mechanism is similar to that found in other packet-switching systems, and is capable of finding alternate routes should a segment of the network fail or be temporarily disconnected. Recovery of any reactor, or its temporary appearance in a larger net is automatically recognized and blocks destined to it are permitted as long as the connection persists. The reactors maintain contact with each of their neighbors and build network routing tables dynamically. The longer the net remains in a configuration, the better the routing should become.
Although the reactor was designed originally without knowledge of the Printer Access Protocol (PAP) described in Inside AppleTalk™, its implementation is very similar and few changes will be necessary to provide complete connectivity between async AppleTalk devices and those which have no such capacity. Such a system will allow Macs to share LaserWriters™ using the 9600 baud Postscript mode with PC's running standard Postscript printer drivers.
Indeed it seems ridiculous to be reducing the bandwidth of AppleTalk, as it already seems crowded, but it is truly amazing to watch it work. In fact, that is the most interesting thing of all to a developer; you CAN watch it work. Have you ever observed AppleTalk traffic LIVE? Do you really know what your application is doing with the bus and can you observe all or only part of the bus activity while you're debugging? Get a dumb terminal with the capability to display control codes, and the reactor can be directed to send all activity from any node or nodes on that reactor to the display.
We have been quietly working on this for the past 5 months, and are becoming even more confident of its merit the more we use it. We have found some applications that are as yet incompatible with the async system, but that is because they sign-on to servers at boot time, and if connected to a reactor, it will find no real AppleTalk there. It would be a very simple thing indeed for an application to install the async drivers at boot, or to allow toggling between both types. It would also be a very simple thing for Apple to change the CHOOSER DA to have an 'ASYNCHRONOUS' button....!
We are hoping to be at the MacWorld Expo in SF, but may not get it together until the Seybold conference on Jan 28. We would like to join anyone who already has space, and are urgently seeking support from other developers who have AppleTalk™ or PC networking products.
If all of this seems confusing or you want more information, please call either myself or Rich Brown at the following addresses:
Michael Ferguson Rich Brown
Sand Hill Engineering Inc. Kiewitt Computation Center
