Protocol Memories

Picture this: I arrive at Georgia Tech to borrow some computer time, a phrase that dates me, on their IBM RS6000. The administrator leads me out of her office and back down the hall toward the lobby. To my surprise, the console is crammed almost under a flight of stairs, between some ficus trees and a fiddle leaf palm out in the atrium.

I had felt like I was working in a fishbowl, but this was the first time in my career I’d feel like I was working in a zoo.

A customer hired me to design a protocol that had to work on an IBM RISC System/6000. They didn’t have one but reassured me they could get access to one at Georgia Tech. They conveniently left out that it was in a lobby, and I neglected to ask. Go figure.

Here’s the thing, I didn’t much mind stooping over the console to study my code’s output between the houseplant leaves. I didn’t mind because I was designing a protocol.

One side effect for those of us with terminal curiosity is that we learn to do things others often don’t. I think that’s what led me to be a system programmer and protocol designer.

I can’t remember when my life-long curiosity started. It might have something to do with being born at a time when toys were metal and held together by thin tabs. Maybe it was because I grew up in a house with ready access to screwdrivers and pliers.

I vividly remember, however, the first day I became curious about network protocols. It was the early 80s. I was newly married and had just accepted ajob at the University of Georgia’s computer center, writing a system to keep track of students in the special studies program.

My desk was in the very back of the basement, a fantastic spot to work. To get there, I used my rarely granted machine-room keycard to open a vast expanse of locked-away printers, mainframes, disk drives, and tape drives.

We had two (count ’em TWO) IBM 370/158s in that basement, each with long strings of 3330 disk transports, and a couple of 3830 disk controllers, which looked remarkably like an off-white deep freezer.

My office was past the IBMs, and behind the Control Data Cyber 70/74, a revision of the famous CDC 6600, a Seymour Cray machine. I was even further back than the desks for the customer and field engineers (Different titles for the same job. Customer engineer was IBM’s name for it, but Control Data called them field engineers).

Behind the engineers were an IBM Series/1, IBM’s failed answer to the minicomputers of Data General and Digital Equipment Corporation (It wasn’t a very serious effort because IBM decided to use EBCDIC instead of ASCII. Only computer center folk used EBCDIC, and they didn’t need minicomputers). But it wasn’t any of these machines that sparked my interest in network protocols. On this day it was a Texas Instruments TI-990 minicomputer. As I walked toward my office, I passed a group of people leaning forward into a TI-990 chassis pulled out of its 19" rack.

(Not that the chassis could slide back in. A system programmer, who will forever remain nameless, had become so frustrated while chasing down a bug that he brought his fist down on the extended chassis hard enough to warp the rails.) What caught my eye was a new face in the otherwise familiar band of co-conspirators. He was older than most of us and held an assembler listing in one hand while he looked at the ceiling. “Let’s put a snap in right after that and run it again,” he said.

I followed his gaze and noticed extra cables emerging from the TI-990’s guts and running along the floor. There was a monitor on the table beside the machine, a card reader that hadn’t been there before. One of my buddies was busy editing an assembler program and recompiling it.

As I stopped to watch, they finished recompiling, ran the program, and hit the start button on the tabletop card reader. With a quick “bap,” it read a single card, and the lights on the front of the machine stopped blinking.

On the console, there was a snapshot of the sixteen registers of the machine. The older man let out a “hmm.” As I’d soon learn on a coffee break, his name was Lu Penn.

I had heard of Penn from reading his name in much of the code I was reading at work. He’d written for the new Statistics and Computer Science department that received a Control Data minicomputer I’d use often. His name was all over it. On this day, he was debugging his implementation of the User Terminal 200 protocol (UT-200), which turned into an opportunity for me to observe and learn how two computers talked to one another.

I gleaned that they were tied together with a synchronous serial connection that remote colleges could use to submit card jobs to the mainframes and get printouts back. It was implemented on the Control Data machine. (The IBMs used HASP, not UT-200.)

It didn’t take me long to see that Penn thought about the two machines as people having a conversation. He’d say things like, “He sent him the pool packet, and he didn’t send back an ack.”

Some of the topics he covered were familiar to me. Bytes have eight bits, seven of which were data, and the eighth parity. Packets start with a special byte and followed with some addresses. One of the bytes was the message type. At the end of the packet was a longitudinal parity byte to further check that the packet had no errors.

Penn showed me new things too. Like how the byte had no start or stop bits. Normally with serial there’s a start bit the kicks off the receiver to clock in bits. At the end of the byte there’s a stop bit of the opposite value to ensure a transition for the next start bit.

But this UT-200 stuff never stopped sending bytes. This was because the protocol was not asynchronous, but synchronous. It simply sent a byte called a “sync byte” when it had nothing to send. For ASCII it’s 0x16. This kept the phase-locked loops on the receiving synchronized.

I ended up learning a lot that day, and it sparked within me a curiosity that ended up dictating my career. I used what I learned from Penn about network protocols many times over the years.

Fast forward to 1992 in that Georgia Tech lobby: the IBM RS6000 console began spurting out “sync” and “ack,” along with sequence numbers.

I became so engrossed with the work that the bustling lobby faded away. I began to mutter to myself, talking about how he saw such-and-such and should’ve sent the ack, anthropomorphizing the two devices without thinking about it. A grad student walking briskly past must have heard this because he suddenly stops dead in his tracks and asks, “What are you doing?”

My reply is simple: “I’m trying to get these two guys to talk to each other.” Upon hearing this, he whips out his card, handing it to me as he declares, “If you are ever hiring, let me know. I love working with network protocols!”

I’ve long since lost the card and wouldn’t be in a position to hire anyone for a few years anyway, but for a moment in a Georgia Tech lobby I had a comrade, someone with the same terminal curiosity I had. Someone who understood the personification of computers.