Software protocol
Tue, 2006-09-12 21:31 — NC.EWeek
Objective: To illustrate how computers communicate large amounts of information over a single wire or communication channel
Terms to know:
Protocol: A set of rules that are used to accomplish a task more quickly, more efficiently and more reliably.
Handshaking: An
indication that the current task has been completed. An example would
be acknowledging the receipt of a piece of e-mail by sending back a
reply.
Encoding: Putting
the information in a format that can be easily understood by the
program or person receiving it. Examples include: Web browser
instructions in web pages (HTML), printer instructions when you send a
document to your printer (Postscript), protection of your credit card
number when you order something on the web (encryption)
Half Duplex: This is when you can only send or receive information at one time using communication medium (example - telephone conversation)
Full Duplex: Being able to send and receive information simultaneously (example - web surfing while downloading a game)
Packet: A group of
information to be sent or received (example: when you download a new
program, it comes in pieces called packets. This way the sending
computer can try to resend just that piece of information if needed,
not the entire program)
Address: A way of identifying each user. In the Internet this is the same as a web address like www.netscape.com or www.ibm.com
Arbiter: This is
usually a software program that decides who gets to go first when
multiple requests come for accessing the same information. On the
Internet, this is what tells you that it failed to connect, try again
later when many people are visiting the same site like mp3.com.
Node: This is a
connection on the network. When you connect to the Internet, your
computer becomes a node or connection on the World Wide Web. Each node
has an address as well so that your computer can be identified from all
other ones.
Error detection/correction
- these is what happens when you make a request for information or send
an e-mail and it does not work. Example would be the e-mail system
may tell you that it failed to deliver your e-mail. A download you
try may also fail and have to restart.
Broadcast message:
This is when one person talks and all others on the network are
supposed to listen. An example of this would be an emergency warning
for a tornado on the radio.
One to One message : This is where you establish a conversation with another person or computer much like a telephone conversation
Materials required: 
For each group of 5 students you need:
½ of a wardrobe box (mover's supply) cut in height
4 sections of 1" PVC pipe cut in 2' lengths
4 sections of 1" PVC pipe cut in 6" lengths
1 4-way tee in 1" PVC
4 1" standard tees
4 1" 90 degree elbows
The illustration shows the setup where
this is a cross section of the wardrobe box with pipes passing through
it. One student is positioned at each of the four sides.
The purpose of the box is to obstruct your
view of the partner opposite. The pipe is the communication medium.
You are each given a short section of pipe and two pipe connectors to
form a headset like a phone so you can talk and listen.
As a group you need to select one student
to be the arbiter. This person will roam around the box and decide
who goes next. Conceptually, the arbiter in the network is shown at the
center but due to safety concerns we made this person roam. This
network will be used to perform two types of message passing, broadcast
and one to one.
Process Steps:
1) One person in the group is selected as an arbiter.
2) The other four students spread out and
stand next to a node. You are given a short piece of pipe, a
t-junction and an elbow to construct a headset
3) You will be given index cards with
messages to convey to your team. At the top of each card will be
written either Broadcast or the node name you need to send the
information to. In a broadcast you need to send it to all other
nodes.
4) Each time you need to speak, you need
to ask permission of the arbiter. This person will need to decide
when you can go. You ask permission by stating your node name and
then the intended audience. Like green broadcast or green to red.
You need to wait for the arbiter to grant permission before you can go.
5) Each message will be a few sentences
but you can only send 5 letters at a time before someone else takes a
turn. You need to include spaces or punctuation in the letter
count. For example, you may be asked to communicate:
"The sky looks like a storm is coming"
The first time you could pass The spaces then another person get a turn.
The 5 characters you send would be called a packet.
To indicate you are done with a message a special character called "done" should be sent.
6) The goal is to communicate all information on each of your cards first as a team. Points will be awarded as follows:
First to be done: 10 points
Second finished: 9 points
Third 8 points
Fourth 7 points
Fifth 6 points
Sixth 5 points
Message accuracy
Perfect message on the card send: 10 points each error deducts 1 point
Discussion questions
1) What worked best to help this process?
2) How could you improve accuracy or speed?
3) Which seems to help you get the most points?
Did you ever wonder how any of the following things happen?
1) You click on a web page link and see another page come to your screen
2) You pick up the telephone, dial a number and are connected to the person you want
3) You ask to print something from your computer and somehow it prints on your paper
4) You type on your keyboard and it shows up on your computer screen
5) You have a cable modem hooked to your computer and the computer
is not confused by seeing all the tv information that is on the same
cable
All of these are examples of software protocols in use. A
protocol is really nothing more than a set of rules used to communicate
information.
NOTE -
(Courtesey of Michael Riley and his team)These were just ideas that
worked for us. We were working with small-ish classes (~25 students)
of 11th and 12th graders. Your experiences may vary. These are just
ideas that occurred to us as we taught…
This note is divided as follows:
1. Rough Agenda
2. Intro Topics (i.e. - making "software protocol" relevant)
3. Extension Topics (i.e. - challenge exercises after the main lab)
4. Tricks we learned
Rough Agenda
If you have 90 minutes (we did):
- Introductions, outline agenda, set expectations - 10 minutes
- Intro topics (see below) - 10 minutes
- Lab instructions (distribute materials, help people with setup) - 5 minutes
- Run the lab - 20 minutes
- Stop the lab, task each team with getting ready to talk about "what worked/what didn't", tabulate and post results - 10 minutes
- Talk about (and possibly run) extensions to the experiment: mentioned below - 20 minutes
- Close
| If you
have 60 minutes, I'd consider shortening the lab a little bit, and
maybe not actually "run" any of the extensions. I wouldn't skip the
intro topics. We really found that if people didn't get the "why" of
the lab, then it was less interesting…. (i.e. - if they didn't
understand how this was relevant to their using email/IM/http, then
they didn't really get involved).
Intro Topics
Find out how many kids use email. Find out how many surf the web
- Find out how many kids have setup a network at home.
- Ask if kids have used IM
- Ease them
into thinking about the fact that computers need to talk with each
other. This isn't meant to be an in-depth analysis of
TCPIP/Token/whatever, but meant to give them an idea of the basic fact
that computers need to communicate with each other, and that they do so
in an extremely simple way (i.e. - coming back to that basic idea that
computers just do _simple_ things very, very quickly).
Extension Topics
Routers -
Assign each "LAN" a subnet name (we wrote our subnet names as letters
(e.g. - A, B, C …) on the bottom of each LAN's box), and then ask the
students how you a machine on one network could possibly send
information to a machine on another LAN… Get the arbiters involved
to route traffic to the other LANs and get them to come up with the
idea of "A.Yellow", … Bring this conversation around to the idea of
how different computers on the internet talk with each other (i.e. -
the kids of communicating among 5-7 LANs, while the internet is
millions upon millions currently…)
- Firewalls - Extend their idea of a router being able to filter traffic, as well as to pass it.
- Talk
through things that different teams did. We had teams that implemented
a basic round-robin for network sharing, teams that implemented
streaming strategies, and teams that did things in between. Use these
examples to talk about when those approaches are good and when they
aren't so good.
Tricks we learned
Have the
kids grade their own labs - with a little supervision. This will be a
great trick to keep the early-finishers busy a little longer, and helps
the kids realize what gave their own team troubles - which helps in the
"what worked/what didn't" discussions.. |