'15-'16 Packets and Making a Reliable Internet

CS Principles Unit and Lesson Discussion
1

Use this thread to discuss your questions and comments about how to run the lesson.

2

Just an FYI, I noticed a typo. On the link to the Activity Guide under Resources, Making is misspelled (Makig). I am unable to upload a picture because I am a new user.

3

Thanks Thomas! Great catch!

4

The “download” link for the The Internet: Packets, Routing, and Reliability video is not working. The youTube link is fine.

5

Hi Nik, thanks for alerting us to this! It is now fixed in the lesson plan. (And all student facing videos are also available in Code Studio. This one is available at https://studio.code.org/s/cspunit2/stage/5/puzzle/3 and there is a download link at the bottom.)

Thanks!
Sarah

6

I did this lesson today with my class and it went well. There was more structure for students to follow and the parameters were well explained. Students were frustrated by the frequency in which data was dropped, but I think it forced students to consider contingency plans. Most students numbered the packets, but the idea of sending back a “received or not” message was not used by all students. Here are some other strategies that students used:

  • Sending the messages twice to allow the user to get all of the information - although occasionally it dropped the same packet twice
  • Putting a packet in there letting the user know the end of the message had been sent.
  • Sending a message back to the original sender if anything was lost (but not necessarily if all messages was received.

I would suggest coming up with phrases to be sent ahead of time. I tried using fun ones that could also be mis-interpreted if un-numbered like “crazy cats keep calling cool cucumbers to come camping”. Students had fun with the “testing” piece of the activity.

We did not get to watching the video today, but I think students will greatly appreciate the connection to TCP after this experience.

7

Does 60 characters seem like a really long message to anyone else? I predict my students getting frustrated with the process when they can only put a few actual content characters in each message. It seems like it would take a really long time to get it through and feel rather tedious…

Anyone else have ideas or reactions to that?

I personally would suggest to the developers that the maximum # of characters in the should be increased in the tool itself.

8

Hey Andrew,

You’re definitely not the first person to think the same. Our hope with having a very small packet size was that you very quickly run into the crux of the problem. We chose a message length of 60 characters primarily to make a point that the message will need to be split over a non-trivial number of packets. Even with 20 characters though, this is still a challenging activity. I can see the case for making the packet size bigger, but I think the first modification I’d try is just making the message size smaller. One added benefit of small packets is that with so few letters in each packet the likelihood that a student can intuit the order of the packets by sight goes down. The need for the protocol is made more obvious. Hopefully with a shorter message the tedium is decreased but let us know how things go. If other people have similar feedback we’re happy to make changes!

Best,
GT

9

Makes sense. I gather that 60 was to ensure there are some dropped packets. Maybe shorter messages could work if the likelihood of dropped packets is increased.

10

That was something we considered as well. Honestly we weren’t sure what would cause more frustration since in either case we’re presenting a “broken” tool. I think one thing to emphasize to students is just that we’re simulating real problems on the Internet. Once they understand that messages are split into packets of limited size, that they can be dropped, and that they can arrive out of order, I’m not sure how much of their protocol development will involve testing on the Internet Simulator. As I imagine this lesson going it is more a tool for introducing the problem, but if it does its job well then I think you wouldn’t be using it that much until maybe you came back to test out your protocols at the end.

I could be wrong about how kids will want to use the tool, so let us know how it goes. We’ll definitely be tweaking and I’m curious to know what set up would prove least annoying while still getting across those key features (or deficiencies really) of the Internet.

11

Thanks for the suggestion.
I found some puns online to let them send:
Velcro is such a rip off.
I really wanted to make a joke about sodium, but later said Na.
The book I read about anti-gravity was impossible to put down.
Next weekend, they are selling dead batteries, free of charge.
Of course being a vegetarian is a huge missed steak.
Everyone knows that glass windows are a real pane.
I really wanted to be a butcher but I didn’t make the cut.
Most violin players will very often just fiddle around.
Most jack hammers are really just ground breakers.
Lots of people are self aware. You know who you are.
When crazy glue was invented, people got attached to it.

1 Like