ASCII messages:

ASCII MESSAGES

Materials needed:

Pencils (one per student)
ASCII charts (at least one per group), they can be easily found on Google
lots of slips of paper with squares for writing the code that look like this:

at least two helpers to be “servers”

Process:

Split class into groups of two or three. Each group is a “computer”. Name these computers with a letter of the alphabet: A, B, C, D, etc. Assign each “computer” another “computer” to send a message to (for example: A sends to B; B sends to C; C sends to D; D sends to A)

Explain to the class that computers send messages over networks like the internet by first encoding the messages, then sending. The receiving computer must then take the encoded message and translate them back into data interpretable to the viewer. Explain that ASCII is a type of coding used by computers, changing letters into numbers because a computer can only send numerical values [ASCII= American Standard Code for Information Interchange]. Hand out the ASCII charts and have each group create a short message (no more than 20 characters, including spaces) to be sent to another “computer” and put it into ASCII. For example:

R - 082

o - 111

p - 112

e - 101

- 032

t - 116

r - 114

i - 105

c - 099

k - 107

s - 115

- 032

a - 097

r - 114

e - 101

- 032

f - 102

u - 117

n - 110

! - 033

Next, explain that a computer, when decoding, must have some way to ensure that the packets have not been compromised, and that the way to do this is to have a way to check that none of the numbers have been accidentally changed. So we add a number to the end, a “parity bit,” that will be used to check the validity of that letter. We will do this by adding a number to the end that will make the sum of the digits for that letter divisible by ten:

R: 0 + 8 + 2 = 10 + 0 = 10; 0820

o: 1 + 1 + 1= 3 + 7 = 10; 1117

Or if the digits add up to more than 10, have them add to 20:

c: 0 + 9 + 9 = 18 + 2 = 20; 0992

You can have the students figure out the pattern before you tell them how. Explain how patterns are important for mathematicians/computer science/computational science and have them find the algorithm.

1) All groups should now have a message and its code: four numbers per letter. Have each computer fill out ONE AND ONLY ONE packet to begin to send their message.

Make sure the students recognize that the packets do not cleanly fit into “letters”. Here we have 2 and 3/4 letters encoded. The next packet would start with the last digit of the third letter and then start on the fourth.

Have the “servers” collect the packets and bring them to the front of the room. The servers will look at the packets, be confused, and crumple the packets up and throw them away.

[REASON: Packets have no direction to servers on where to send them]

2) Next, have the groups fill out another packet with the letter of who they’re sending it to:

The “servers” collect them again, and take a packet to its destination. This time, the servers repetitively ask the computer for confirmation: “OK, computer B? OK, computer B? OK, computer B? OK, computer B?”

[REASON: Server needs to send verification back to sending computer]

Eventually, the group will get annoyed and say something like “you can go now.” Explain that this is exactly what the server needs to be told, and have the computers write “VERIFY” on the back of the packet after WRITING DOWN THE NUMBERS (they will not receive the packet again after they’ve sent it back)!!! You may wish to bring up the analogy to package delivery services, such as UPS or FedEx where the recipient is required to sign for the package. The servers will bring the verified messages to the front of the room, look at them, and then throw them away.

[REASON: Packets have no return address]

3) Have the groups fill out yet another packet, this time with both to and from addresses. Let the class decide on the protocol. Explain what “protocol” means and how you use it in transferring information. Explain that all of what we having been doing so far has been defining protocol: 4 numbers for a letter/to and from spaces in a packet/etc. One example of protocol is “to” at the beginning and “from” at the end:

Have the students now fill out THREE packets in this manner and send them. The servers collect them, give them OUT OF ORDER to the computers, and return the verified packets to the senders. Ask the students how they can tell which packets come in what order (they can’t), and decide to add yet another thing to our protocol:

Packet number

From

****THIS IS THE FINAL PROTOCOL FOR PACKETS*****

Finally, explain that the parity bit can be used to ensure that the Servers don’t mess things up in delivery, so the Computers should check that the numbers add up before writing “VERIFY”. If they don’t (sometimes they will have to wait for another packet to get all of a letter’s numbers. Remember that the messages don’t start at the beginning of a letter, just where the letter code left off), write “REJECT” on the back. The rejected message will go back to the sending Computer and that Computer will know to resend the packet. If a packet doesn’t come at all, a Computer can request a resend by the following protocol:

Computer to send info to

Requested Packet number

Computer that has the information

and “RESEND” written on the back

Example:

Computer B didn’t get packet 03 from Computer A. The request for resend would look like this:

with “RESEND” written on the back.

When A receives this message, it simply fills in the packet numbers and crosses out the “RESEND” on the back, and sends out the packet again.

****At this point, the Computers and Servers can just go about their business of transferring messages. Emphasize teamwork: messages will be going out and coming in simultaneously.

---------------------------------------------------------------------------------------------------------------------

Summary of Server Protocol:

If you have a packet that you can’t give to a computer, crumple it up and throw away (first with no “to”, then with no “from” on verified message)

If you have a packet that has something on the back, give it to the computer that is in the “from” position. Otherwise, give it to the computer in the “to” position.

During the final, unsupervised sending of messages, you can “accidentally” mess up some numbers, but DO NOT MESS UP THE PACKET NUMBERS OR THE TO OR FROM ADDRESSES. Also, DO NOT CHANGE MORE THAN ONE NUMBER IN A PACKET. The Computers should recognize the problem when checking with the parity bit, and write reject. Don’t change most of the packets, just a couple. You may also wish to fail to deliver a packet to a group, requiring them to request a resend. This should be done with the ability of the students and their apparent ease with this protocol in mind.

---------------------------------------

Summary of steps, simplified for the “servers”:

Normal packet, just numbers. Servers throw these away.
Packet with target computer written on it. Servers deliver the packet and then constantly bug the target with “OK Computer X?” statements
Using the same packet, have the target computer write “VERIFY” on the back to confirm receipt after they have written down the numbers. Servers will throw this packet away.
Three Packets with both target and original computers written on it will be written all at once. Servers will deliver packets out of order.
Packets now have the packet # order on it. Also introduced are new commands, VERIFY, REJECT, RESEND. Have the students write the packets in a stream, don’t let them give to the servers in a large batch. Servers are allowed to change the packets in minor ways at this point, but don’t make it obvious. Make sure the students know about the parity bit before it gets to this stage.