Finally, Something that Looks Like a Computer! Ch. 4

Collaborative computing creates cooperation

Our teleprinter works great for sending short messages back and forth. But think about how cumbersome it would be for sending and receiving large documents. Not only is the 80 character wide printer not ideal for long messages, but it’s a mostly synchronous system that requires a person to input every reply one letter at a time. If Alice requests a document from Bob, Bob has to be there sitting at his machine in order to type out the document, letter by letter, to send back to Alice.

If we think about it for a bit, we can imagine a much better system that corrects some of the teleprinter’s flaws. Instead of a teleprinter, let’s design a machine that allows Bob or Alice to type out and save documents. Once saved, a document will then be available for the user on the other side of the connection to request at any time. After the request, the document will be delivered to them automatically. We can also add the capability to send files directly to the other user without them requesting it first.

Let’s spend a little time looking at how such a machine would work. We’ll call our machine a computer. Our previous teleprinter contained multiple microcontrollers, and a microcontroller is technically a computer, but our new machine is something that a non-technical person would look at and immediately recognize as a computer.

We’ll gloss over many of the aspects of our computer. An introductory survey of computer hardware is a whole book on its own, but we’ll cover the parts that are important to us.

We still have a keyboard, just like our original teleprinter did, but the keyboard has a few extra keys at the bottom.

The arrow keys don’t enter any visible characters–they are used to move the cursor around the screen. The enter key is used to submit input and to make selections. The return key inserts a newline character.

Instead of a printer, we have a small black and white monitor.

Inside the computer, we have a central processing unit (CPU). The CPU is essentially a more powerful version of the microcontroller in the letter writer. The CPU runs programs that are responsible for reading input from the keyboard, displaying output to the screen, and sending and receiving 1s and 0s to and from the bit transceiver. Instead of a separate box, our bit transceiver has been moved into a slot inside the body of the computer.

Despite its new location, the bit transceiver functions as it did in our teleprinter example. It accepts 1s and 0s from the CPU and translates them to electrical signals to send to the bit transceiver on the other side of the network. It also accepts electrical signals from the other computer and converts them to 1s and 0s to pass along to the CPU. The only difference between our new bit transceiver is that it’s now inside the body of the computer, so it connects directly to the CPU without the need for external wires.

Don’t shoot the messenger

The teleprinter’s microcontroller ran a single program. The program listened for keyboard presses and transformed them into the appropriate binary code to send to the bit transceiver, and it listened to the output from the bit transceiver and transformed that into messages to print out on the printer.

Our computer’s CPU can run a program that does nearly the same thing. We’ll call this program MESSENGER. But in addition to that it can also run other programs.

When the computer starts up, it automatically runs what we call a terminal program (some people call this a command line). Our terminal program is special, because no one has to tell it to run.

The terminal program reads letters from the keyboard and displays them on the screen. The letters appear on the current line after the prompt (\). Each line also displays the name of the current computer. You can use TERMINAL to type in the name of another program to run.

When we press enter, if the word we typed matches the name of a program the computer can run, it will start running that program. If we type a name the computer doesn’t recognize, the terminal will display an error message and give us a new blank line to type on.

Let’s see what happens when we type MESSENGER.

Once we press enter, The messenger program will start running. When MESSENGER is up and running, we can use the computer the same way as we did the teleprinter.

The messenger program has a prompt where we can type our message. When we press enter, the message gets sent to the computer on the other end of the connection. Assuming that computer is also running MESSENGER, the message will be displayed on its monitor.

But wait, there’s more!

Running MESSENGER gets us back to the same functionality we had with the teleprinters. What’s the advantage of the new system? For a start, we can run additional programs.

If we exit MESSENGER and type:

The computer will pull up a basic word processor program that will allow us to write a document and save it. Once we type something up, we can use the arrow keys on the keyboard to select the save command and press enter to save the file. When we do this, a prompt will pop up, asking us to input a name for the file.

After we enter a name, the file will be saved to the computer’s hard drive. The hard drive is the device inside the body of the computer that allows us to save files. We’re going to skip the details on the inner workings of a hard drive, but for our purposes we’ll say that our simplified hard drive works similarly to the protocol we used in the previous chapters to send messages.

This hypothetical hard drive is connected to the computer’s CPU just like the bit transceiver. When the user saves a file, the CPU sends the hard drive a message as a sequence of bits (using the same encoding we used in previous chapters) that translates to the following:

The message starts with the SAVE command followed by the file name. On a new line, the CPU then sends the contents of the file to be saved. In response, the hard drive will save the contents to a file named HELLO and respond back with:

WORD PROCESSOR has a few other commands that interact directly with the hard drive. The user can select a command called files to display a list of saved files. When the user does this, the CPU will send the hard drive a message that says:

And the hard drive will respond with a list of file names with one file name per line. Let’s stop including the non-printing characters to make this a little easier to read. Instead of writing \N, we’ll just use a line break, and we won’t write the \S, but you can assume that it’s always there at the end of the message. (You’ll notice that we didn’t have to use our START STOP protocol to communicate with the hard drive. This is because unlike when Alice and Bob are sending messages back and forth, the hard drive will never send a message to the CPU without being prompted, so there’s no chance of both the CPU and the hard drive trying to send a message at the same time.)

The word processor then lists out these file names in a popup for the user to select from. If a user selects one of the files, the CPU sends a message to the hard drive to retrieve it. Let’s select the HELLO file.

The hard drive will respond with:

And the word processor will display the contents for us to read or edit. If the hard drive doesn’t have a file named HELLO, it will respond with:

What if we want to edit the file? Let’s change it to add a line break after HI THERE. Once we insert the extra newline, we select save, press enter, and the CPU sends the following to the hard drive”

The hard drive will overwrite the copy of HELLO it has saved with the new data.

Down and out

Now that we can create and save documents, how do we make those available to the user on the other side of the network?

Let’s add a new program to our computer called SERVER. When we type SERVER into our terminal, the program launches and starts listening for incoming messages just like the messenger program.

However, unlike MESSENGER, SERVER won’t display the results of messages, and it doesn’t allow you to send messages. In fact, the server program doesn’t have a user interface at all. After we press enter to launch it, it just keeps running until we hit enter again. It listens for a special type of message that looks like this:

The first part, the header, is letting SERVER know what type of message this is. The second part, the body, is a file name. All together this message tells the server that the requestor wants a file named HELLO.

Once the server processes the message, it will ask the hard drive for a file named HELLO. If the hard drive finds and returns the file, the server will send the file over to the requestor:

If the file isn’t on the hard drive, the server will respond back with a message that doesn’t have a body:

To request a file, we need to use a program called DOWNLOAD. DOWNLOAD is another program that doesn’t have a graphical user interface. To run the program, we type DOWNLOAD followed by the file name, then press enter.

DOWNLOAD will ask the computer to send the message across the network:

If the other computer responds with FILE FOUND, DOWNLOAD will read the file body, save it to the hard drive, and exit. If the response is FILE NOT FOUND, DOWNLOAD will print out FILE NOT FOUND and exit.

One thing to note is that just like with the messenger protocol from the previous chapter, all of the above messages actually begin with the sender dispatching a START message. The receiving computer will then reply with OK before the sender proceeds with the rest of the message. The receiving computer will then keep listening until it reads the stop signal. Even though we aren’t showing /S, it’s still there at the end of each message. We’re just leaving it out to make it nicer to read.

Just like in the previous chapter, the START STOP protocol prevents collisions. START STOP also applies to the rest of the messages we describe. We’re simply omitting it from the examples to make them shorter.

Here’s an example of the previous exchange without omitting START STOP. We’ll also show each \N that is actually sent instead of showing the resulting line break.

Up and in

Now Bob or Alice can create a document, fire up SERVER, and walk away. The computer will handle sending the file over whenever the other user requests it.

Next let’s add the ability to send a file to the other user without them requesting it first.

We can add one more program called UPLOAD that works similarly to DOWNLOAD. We input the text UPLOAD followed by the file name (HELLO in this case), press enter, and the computer will ask its hard drive if it contains a file by that name.

If it does, the computer will send the following message across the network:

The first line of the message contains the commands that tell SERVER what kind of message this is. In this case PUT FILE tells SERVER exactly what to do–put the file onto the hard drive. The next line is the name of the file, and all the subsequent lines until the \S are the body of the file.

After receiving this command, SERVER will tell the hard drive to save a file named HELLO with the contents: “HI THERE \N HOW ARE YOU DOING”.

One key thing to remember is that the server program has to be running on the computer that receives this message or nothing will happen.

Computerized concurrency

It’s a bit limiting that our computers can only run one program at a time. If Alice wants to download a file from Bob, she has to use the download program. This means she can’t keep her server program running, so Bob can’t download anything from her. And no one can run their messenger program during any of this, so it’s hard to coordinate who should be running their server program and when.

To get around this, let’s add the capability to run multiple programs at once. We can do that by adding a primary program that is always running to control the other programs. We call this program the Operating System. In addition to controlling all the other programs, it handles displaying them inside separate, individual windows.

The operating system also handles communications with any hardware. Instead of sending messages to the hard drive, or bit transceiver directly, programs instead send a message to the operating system and it relays their messages for them.

You still launch programs by typing their names in the terminal and pressing enter (the terminal window will automatically launch when the computer boots up), but now the new program runs inside a new window that pops up on the screen. To make it easier to navigate between windows and resize them, we can add a mouse to our computer. The mouse lets us move around a pointer to select, reposition, and close windows.

The mouse also lets us select menu items. Clicking on a menu item on screen is equivalent to selecting it with the arrow keys and pressing enter.

Now that we can run multiple programs, what happens when we run MESSENGER and SERVER at the same time? When our computer could only run one program at a time, it was easy for it to figure out what to do with an incoming message–just let the running program handle it. However, now we need some way of telling the computer which program is supposed to handle which message.

We can add one additional line to the beginning of each message that names the program that the message is meant for. (MESSENGER messages don’t need to include the name of the protocol because MESSENGER only supports one type.)

When the CPU reads an incoming message, it hands it off to the operating system first. The Operating System (commonly called the OS) will strip off the first line, and then decide which program to try to send it to based on the name it read there. It will then send just the message without the first line to the correct program. The receiving program has to be running or the OS won’t have anywhere to send it, and the message will be dropped.

Working hard or hardly working

Let’s briefly examine what using our new system looks like. Alice and Bob sit down at their respective machines and boot them up. The terminal programs start up automatically, and they each start their messenger programs.

Alice asks Bob for the name of the report he’s working on. Bob responds that it’s called REPORT.

Alice then uses DOWNLOAD to request a copy of REPORT. Nothing happens because Bob forgot to start his server program. Remember that when a program isn’t open, the operating system has nowhere to send messages intended for it, so the OS just drops the messages. After waiting a while for the response, Alice’s download program gives up and shows an error, so Alice messages Bob again and asks him to start his server program.

Alice sends the download request again. This time Bob’s server responds with the file. You’ll notice that when SERVER responds to the request from download program it knows to include DOWNLOAD in the first line of the message.

This only works because DOWNLOAD is the only program that communicates with SERVER using the GET FILE command. If we later add other programs that use the GET FILE command, we’ll have to come up with a solution to let the server know which program is talking to it.

Once the download program finishes downloading the file, Alice fires up her word processor and opens the new REPORT file.

The report file mentions another file called SCHEDULE that Alice should download for more information, so Alice goes through the whole process again, asking Bob if the file is available, using the download program, and opening the file in her word processor.

A web that’s hardly world wide

From that example, it looks like we have enough parts to start doing useful work. We can send messages back and forth, download and upload files, and run multiple programs simultaneously. However, we can see that there’s a few missing pieces. Alice doesn’t have an easy way to see what files were available for download without asking Bob directly. We also don’t have a good way to link files together into a connected web of documents.

In the next chapter, we’ll work on developing a system to solve these two problems using a program called a web browser.