I was hoping to do a few technical posts but my lab is currently being moved, so I decided to kick off another series of posts I call “NetStalgia”. The TAC tales continue to be popular, but I only spent two years in TAC and most cases are pretty mundane and not worthy of a blog post. What about all those other stories I have from various times and places working on networks? I think there is some value in those stories, not the least because they show where we’ve come from, but also I think there are some universal themes. So, allow me to take you back to 1995, to a now-defunct company where I first ventured to work on a computer network.
I graduated college with a liberal arts degree, and like most liberal arts majors, I ended up working as an administrative assistant. I was hired on at company that both designed and built museum exhibits. It was a small company, with around 60 people, half of whom worked as fabricators, building the exhibits, while the other half worked as designers and office personnel. The fabricators consisted of carpenters, muralists, large and small model builders, and a number of support staff. The designers were architects, graphic designers, and museum design specialists. Only the office workers/designers had their own computers, so it was a quite small network of 30 machines, all Macs.
When the lead designer was spending too much time on maintaining the computer network, the VP of ops called me in and asked me to take over, since seemed to be pretty good with computers and technical stuff, like fixing the fax machine.
Back then, believe it or not, PCs did not come with networking capabilities built in. You had to install a NIC if you wanted to connect to a network. Macs actually did come with an Apple-proprietary interface called LocalTalk. The LocalTalk interface consisted of a round serial port, and with the appropriate connectors and cables, you could connect your Macs in a daisy-chain topology. Using thick serial cables with short lengths to network office computers was a big limitation, so an enterprising company named Farallon came up with a better solution, called PhoneNet. PhoneNet plugged into the rear LocalTalk port, but instead of using serial cables it converted the LocalTalk signal so that it ran on a single twisted pair of wires. The brilliance of this was that most offices had phone jacks at every desk, and PhoneNet could use the spare wires in the jacks to carry its signal. In our case, we had a digital phone system that consumed two pairs of our four-pair Cat 3 cables, so we could dedicate one to PhoneNet/LocalTalk and call it good.
PhoneNet connector with resistor
We used an internal email system called SnapMail from Cassidy and Greene. SnapMail was great for small companies because it could run in a peer-to-peer mode, without the need for an expensive server. In this mode, an email you sent to a colleague went directly to their machine. The obvious problem with this is that if I work the day shift, and you work the night shift, our computers will never be on at the same time and you won’t get my email. Thankfully, C&G also offered a server option for store-and-forward messaging, but even with the server enabled it would still attempt a peer-to-peer delivery if both sender and receiver were online.
One day I started getting complaints about the reliability of the email system. Messages were being sent but not getting delivered. Looking at some of the trouble devices, I could see that they were only partially communicating with each other and the failed messages were not being queued in the server. This was because the peers seemed to think each other was online, when in fact there was some communication breakdown.
Determining a cause for the problem was tough. Our network used the AppleTalk protocol suite and not IP. There was no ping to test connectivity. I had little idea what to do.
As I mentioned, PhoneNet used a single pair of phone wiring, and as we expanded, the way I added new users was as follows: when a new hire came on board, I would connect a new phone jack for him, and then go to the 66 punch-down block in a closet in the cafeteria and tie the wires into another operative jack. Then I would plug a little RJ11 with a resistor on it in the empty port of the LocalTalk dongle, because the dongle had a second port for daisy-chaining and this is what we were supposed to do if it was not in use. This was a supported configuration known in PhoneNet terminology as a “passive star”. Passive, because there was nothing in between the stations. This being before Google, I didn’t know that Farallon only supported 4 branches on a passive star. I had 30. Not only did we have too many stations and too much cable length, but the combined resistance on this giant circuit was huge because of all the resistors.
I had a walkthrough with our incredulous “systems integrator”, who refused to believe we had connected so many devices without a hub, which was called a “Star Controller” in Farallon terminology. When he figured out what I had done, we came up with a plan to remove some of the resistors and migrate the designers off of the LocalTalk network.
Some differences between now and then:
- Networking capability wasn’t built in on PCs, but it was on Macs.
- I was directly wiring together computers on a punch-down block.
- There was no Google to figure out why things weren’t working.
- We used peer-to-peer email systems.
Some lessons that stay the same:
- Understand thoroughly the limitations of your system.
- Call an expert when you need help.
- And of course: don’t put resistors on your network unless you really need to!
