SMBlog -- 15 November 2019

The Early History of Usenet, Part III: Hardware and Economics

15 November 2019

There was a planning meeting for what became Usenet at Duke CS. We knew three things, and three things only: we wanted something that could be used locally for administrative messages, we wanted a networked system, and we would use uucp for intersite communication. This last decision was more or less by default: there were no other possibilities available to us or to most other sites that ran standard Unix. Furthermore, all you needed to run uucp was a single dial-up modem port. (I do not remember who had the initial idea for a networked system, but I think it was Tom Truscott and the late Jim Ellis, both grad students at Duke.)

There was a problem with this last option, though: who would do the dialing? The problems were both economic and technical-economic. The latter issue was rooted in the regulatory climate of the time: hard-wired modems were quite unusual, and ones that could automatically dial were all but non-existent. (The famous Hayes Smartmodem was still a few years in the future.) The official solution was a leased Bell 801 autodialer and a DEC DN11 peripheral as the interface between the computer and the Bell 801. This was a non-starter for a skunkworks project; it was hard enough to manage one-time purchases like a modem or a DN11, but getting faculty to pay monthly lease costs for the autodialer just wasn’t going to happen. Fortunately, Tom and Jim had already solved that problem.

There was one type of modem that was affordable and purchasable: the acoustic coupler. It works just like it sounds like it would work: you put the handset of a phone into tight-fitting cups, while connecting the electronic side to the computer. So: when the computer sent bits, the acoustic coupler emitted actual sounds via a small speaker and sent them into the handset’s microphone. Similarly, a microphone in the acoustic coupler listened to noises corresponding to 0 or 1 bits and sent the appropriate voltage signal to the computer. Since the only connection to the phone network was via sounds, the phone company couldn’t object. (Well, AT&T had tried to, several years earlier, but were slapped down.)

This worked great for manual dialing—you picked up the handset, dialed the number, and put the handset into the coupler—but how could a computer dial using one of these? That’s where the cleverness came in. The computer was connected to the acoustic coupler via a standard known as RS-232. There were five pins of major interest: ground, transmit, receive, carrier detect (CD), and data terminal ready (DTR). (Aside: the full set of pins was far more complex, and back in the mists of time I had to deal with such arcana regularly. I won’t go into details, but I became intimately familiar with things like breakout boxes and null modems. You do not want details on these…) Briefly, when the computer wanted to use the modem—that is, when a program opened the serial port—the computer would assert the DTR signal; when the modem was connected, it would send CD back to the computer. If the far end dropped the connection, the modem would drop CD; this signal was passed back to the program. And if you’re a Unix programmer, you now know where the SIGHUP signal came from. Playing clever, hardware-assisted games with the DTR signal was the solution.

Duke implemented it first, but I thought the idea was sufficiently clever that I took it back to Chapel Hill and designed my own variant. The two solutions differed in detail, but since I know mine better and it was cleaner in a number of respects I’ll describe mine.

When a landline phone is not in use (that is, when it’s "on-hook"), it presents an open circuit to the phone line. (That’s not strictly true, since it had to be able to ring, but rings are AC signals, with a capacitor in series with the ringer; it thus appeared as an open circuit to the DC line signal.) To simulate on-hook, we put a normally open relay in series with the phone line. (It seems to be distinctly possible that the phone company would have regarded this as an improper way of connecting to the phone network, but I wouldn’t actually know that, would I?) When the computer wanted to use the modem, it asserted DTR; we wired the DTR line to close the relay and thus take the phone line off-hook. In other words, when the computer opened the device (for us, /dev/ttyz7, since we had a DZ11 terminal adapter and put the modem on port 7), it phone would go off-hook; when the device was closed, it went on-hook.

But how to dial? It turns out that old-fashioned rotary dial phones worked by interrupting the circuit briefly. When you dial, say, a 3, there are 3 momentary on-hook signals. This is called pulse dialing. The pulses are sent at 10 per second, with (in the US) a 2:3 make-break ratio. That is, for each dial pulse, the circuit would be interrupted for .6 seconds and then back on for .4 seconds before the next pulse. It turned out to be feasible to do this via softare control of the DTR signal. We couldn’t match the exact timing specs—the clock on the Unix systems of the time interrupted at 60 Hz—but we could do 1:2 (four timer ticks on-hook to six off-hook) and that was good enough. (Some of you may wonder if it was possible to dial calls by tapping the hook switch at the right frequency for the right number of pulses, a technique that could prove useful if there was, say, a dial lock in place. That is, umm, possible.)

That solved the hardware side of the dialing problem: software control of the DTR line could, via this relay, take a phone off-hook and pulse-dial desired numbers. However, we still needed a software interface. I wrote a driver that was compatible with the official DN11 driver, but instead talked to the DZ11 driver’s routines that controlled the DTR line. This strategy thus presented the modem and dialer as two separate devices, which is what the application software, e.g., uucp expected. (Again, Duke had a similar solution first. I worked with an excellent electronics tech at UNC Chapel Hill for the hardware side of ours. When, a year or so later, we bought a 1200 bps hardwired modem, he redesigned the funky dialer relay to handle the more complex signaling and timing requirements of this modem.)

Having solved the autodialer problem, we had to confront another problem: who was going to pay for the phone calls? Phone calls back then were remarkably expensive, and (even domestically) depended on distance and time of day. Calls during business hours cost the most; evening calls cost less, and late-night calls cost the least.

The solution agreed upon was simple: Duke had one of the few autodialers, so it would have to make the calls. Sites that wanted to join our network would have to set up an auto-answer modem (not exactly common, but much more common than dialers) and reimburse Duke for the phone calls. The calls would be made once or twice per night, depending on desire (i.e., willingness to pay) and traffic. Propagation of articles would be slow, but since Duke was the hub of this network they’d see all news articles sooner than anyone else.

We also knew that the system would not be strictly hub-and-spoke. In fact, the original network had four nodes (duke, duke34, a PDP-11/34, phs, the Physiology Department, and unc) with a loop: duke-phs, duke-unc, and phs-unc. We thus needed a protocol that could handle loops, but that’s the topic of the next post. In addition, Tom had interned at the Computer Science Research Group at Bell Labs (the organization from which Unix had come originally) and believed that his contacts there would be willing to call Duke to send and receive traffic. This solution worked for a while, but more on that later.

Note carefully that the original scheme involved money changing hands. In other words, management (i.e., faculty members) had to be very aware of this activity. People in the Duke and UNC CS department’s business offices were going to see sudden spikes in phone bills, and Duke was going to have to receive and process payments that other sites were going to have to make. Usenet was a skunkworks project, but one that had official sanction: we had faculty members who were wise enough to value innovation by grad students.

Next up: the original protocol design.

Here is the table of contents, actual and projected, for this series.