Protocol Memories

Anthropomorphism is the secret to network protocol design.

Posted on by

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 just accepted a job in UGA’s computer center writing a system to keep track of student athletes 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 key card to open a vast expanse of locked-away printers, mainframes, disk drives, and tape drives behind a huge glass wall. That was the fish bowl.

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 Freeze brand refrigerater.

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 was not a very serious effort because IBM decided to use EBCDIC instead of ASCII. Only mainframe 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 to 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 they brought their 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 would 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 used often. He 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 IBM’s 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 would say things like, “He sent him the poll 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 8th 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 is a start bit the kicks off the receiver to clock in bits. At the end of the byte there is 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 is 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 have 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 to 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.

About the Author

Brantley CoileInventor, coder, and entrepreneur, Brantley Coile invented Stateful packet inspection, network address translation, and Web load balancing used in the Cisco LocalDirector. He went on to create the Coraid line of storage appliances, a product he continues to improve today.

Affordable, reliable, logical storage.

Coraid Etherdrive SRX™ software transforms simple hardware into high-performance Ethernet block storage at 10x price/performance advantage over Fibre Channel and iSCSI. Now shipping with new hardware, Coraid EtherDrive SRX now supports text/email notifications, 4K Advanced Format disk drives, VMware ESX 6.0/6.5 and more.

Get Started Today

←Previous | Blog Archive