Prose samples by Robert Elton Maas Top-down tutorial leading into technical description %% PROTO.WR2 (38k, 1978) Top-down tutorial about communication protocol THE DESIGN OF THE PERSONAL-COMPUTER NETWORK (PCNET) by Robert Elton Maas ... When designing this network, our goal was to provide message and file-transfer service between small microprocessor-based computer systems, using dialup telephone lines and Bell-103A compatible modems for maximum flexibility of topology and ease of having new nodes joining or old nodes dropping out at any time. We decided at the outset to protect all data against errors due to telephone line noise, and decided that error-detecting codes with retransmission of lost blocks was the best way to go. To allow messages to be sent several thousand miles along the lowest-cost route at the time of night when the telephone rates are lowest, and to allow computers with only one phone line to batch and relay messages, we decided to operate the net in a store-and-forward mode (virtual end-to-end simplex connections) rather than a connection mode (live end-to-end duplex connections). To allow a maximum of personal computers and larger but less-flexible timesharing houses (with large disks for storing messages in transit) access to the net, a 41-character subset of ASCII was chosen to be transmitted at 300 baud across the telephone line. (Between pairs of nodes that have full control over their telephone I/O ports, we offer the alternative of a full 256-character 8-bit mode which provides faster thruput. Also where equipment is compatible, datarates higher than 300 baud can be used.) The remainder of the design consists of emulating the good ideas of existing computer networks where applicable, and making minor adjustments and random choices in various details. ... TOP LEVEL At the very top we have 4 billion people, some of whom will have access to the net, of which most will have a "mailbox" on some computer where they can receive their network mail. Let us suppose one of these is Robert Maas, whose mailbox is on a computer called "ISR-GCD1", accessible via the telephone number 415-323-0720, located at latitude 37 28' North and longitude 122 8' West, and whose mailbox on this computer is called "REM". Say he wants to send a message to Abraham Hillman, whose mailbox called "HILLMAN" is on "UNM-10A" at 505-275-1200 located at 34 52' North and 98 16' West. First Mr. Maas logs into his computer (i.e. he identifies himself to the computer, probably by typing some password) and runs a program for constructing a message and sending it on its way. The program automatically places the following header at the start of the message: MAIL:34.52N098.16W505-275-1200,UNM-10A/HILLMAN FROM:37.28N122.08W415-323-0720,ISR-GCD1/REM By request of Mr. Maas while typing his message, a subject line and possibly other optional lines may be added to the header. Then a blank line is inserted after the header before the message proper. Everything except the complete MAIL: line and the first parts (up thru the colons) of the other header lines, is data-compressed and encrypted so that nodes that get the message will be able to forward it to its destination but not obtain much other information about it (and eavesdroppers on the line will be similarily handicapped). At the end of the compressed and encrypted data, a pseudo-random checksum (or hash) is placed so that upon receipt of the message the software at UNM-10A will be able to verify that the message was neither garbled (due to errors) nor munged (maliciously) nor counterfeited. The mail forwarder will now take over. If the UNM-10A node is known (how to log in and how to access PCNet server program) by the ISR-GCD1 node, a direct dial to 505-275-1200, which costs only $.20 for the first minute after 11 pm local time (PST or PDT). Alternatives might be direct-dial to a 1200-baud port on UNM-10A at a different phone number, or sending the message to a node in Palo Alto that batches several messages and transmits them all at once over a 4800-baud dialup line into Albuquerque. After a direct call or one or more relays, the message arrives at UNM-10A where it is deposited in the HILLMAN mailbox. The next time Mr. Hillman logs in, he is informed that he has mail from REM at ISR-GCD1. When he chooses, he runs a program to receive messages, which verifies that the pseudo-random checksum is correct (or warns Mr. Hillman that it is wrong and hence the message might be counterfeit or at least garbaged in some way), then de-encrypts and de-compresses the message, then presents it to Mr. Hillman for inspection and possible edit and/or saving in some file and/or listing on hardcopy and/or deleting and/or replying (automatic specification of destination of reply and of reference to the message-ID of the original message). ... SERVER-MESSAGE INTERFACE When REM finished composing his message to HILLMAN, and passed control to the mail-forwarder, what really happened was this. The SNDMSG program first compressed all data except the portions of the header that aren't supposed to be compressed, then encoded that data according to a code agreed upon by the ISR-GCD1 and UNM-10A nodes, then wrote all this data to a disk file. It then woke up the FORWARD server, telling it the name of the file, then exited. The FORWARD server then read the file, looked up the destination address in its directory of known nodes, and found an entry for it containing a list of its dialup ports and baud rates that are compatible with ISR-GCD1 equipment, and since the current time was only 6PM it wrote itself a reminder for 11PM to send the file via one of the dialup lines listed. (It did not decide to send the message to the Palo Alto global-relay node because it knows that that node doesn't yet have enough traffic to the Albuquerque area to warrent batching of messages.) At 11PM, the FORWARD server is woken up. It attaches itself to the low-level protocol software and issues a request for a dialout port with 1200 baud transmit and 150 baud receive. It gets back acknowledgement that it has port number 6. It then requests ICP (Initial Connection Protocol) on port 6 to 505-275-1275 using login protocol from the file TENEX2.ICP, and gets the reply that the line is busy. It then releases port 6 and requests a 300 baud dialout port, getting back acknowledgements that port 6 is released and that it now has port 2. It then requests ICP on port 2 to 505-275-1200 using TENEX2.ICP again, and gets the reply that successful connection and ICP has been obtained. It next sends the following internode message to the FTP/MAIL listener process (process #1) on the other (UNM-10A) node: PLEASE TAKE MAIL, 1997 BITS. It gets back the message I WILL TAKE MAIL, 2000 BITS, BUFFER 1024 BITS. It then sends a message on the same process-to-process stream (PPS) as its PLEASE TAKE MAIL message, with the contents of the message file in its entirety, broken up into PPS blocks of at most 1024 bits (128 bytes) each. It then gets back I HAVE FILE OK, SIZE 1997 BITS, CHECKSUM 3EDB9C10. The checksum agrees with what was computed locally, so it now sends QRU (I have nothing more) signal to its own control process, and detaches itself from the low-level protocol software. The FORWARD server exits, and the low-level protocol performs CCP (Close Connection Protocol) and hangs up the line because nobody else is using it. %% End of sample of top-down tutorial leading into technical description