Computers, servers, and routers are fairly reliable. But there are often several computers and cables or radio transmissions between you and the recipient of a data packet. So, every once in a while a IP packet will be lost. Devices on the Internet need to tolerate these faults. The Transmission Control Protocol (TCP) guarantees reliable transmission by breaking messages into packets and keeping track of which packets have been received successfully.
By contrast, old land line telephone systems established a long-term physical connection from one telephone to another, for as long as the phone call continued.
A packet is a small message. Typically, if you want to send a large message, your computer divides it into small chunks that it sends individually. This is important because if a router that's handling a chunk of your message fails, only that chunk has to be resent, rather than the entire message. The Internet is a packet switching network.
The TCP/IP end-to-end design of the Internet is an abstraction:
The routers at every connection point run the Internet Protocol (IP) that transmit the packets from one IP address to another, not caring that sometimes a packet will be lost, and not knowing anything about the purpose or meaning of a packet.
And the computers (including servers) at the endpoints run the Transmission Control Protocol (TCP) that guarantees reliable transmission. (The endpoint computers are also responsible for understanding application protocols such as HTTP.)
The routers don't have to know anything about the messages they carry over the net; all they care about is transmitting between the IP addresses at the beginning of each packet. The computers that send and receive the message are the only ones that have to think about what the messages mean. As a result, when someone invents a new application for the Internet, all the routers in the world don't have to be replaced or reprogrammed—to them it's all just bits.
Load this project. It provides a simulation of unreliable data transmission by Internet Protocol. You're going to write (a simplified) TCP to make the data packets arrive reliably.
Click the green flag to initialize the incoming transmission variables before each experiment.
Click either sprite to make it send a message to the other one.
Press left arrow or right arrow to send the alphabet in either direction (helpful for testing).
In this simulation, the complete message is a string of text that is divided into packets of one letter each. In reality, the packet length is not so strictly limited and messages are usually much longer.
On the stage there are two watchers: "Alice incoming transmission" and "Bob incoming transmission." But in the Variables palette there's only one variable name: "incoming transmission." These are actually two different local variables; one belongs to Alice and one belongs to Bob. (Local means not shared across sprites; global means shared across all sprites as we've been doing most of the course.) To make a local variable, click the "for this sprite only" button when creating a variable.
Click on one of the characters, and enter a message that it should send to the other.
Compare the result with what you sent. What problems do you see?
Compare notes with another pair.
Brainstorm what you could do to get around network unreliability.
In our simulation, a packet either arrives correctly (even if it's out of order) or it doesn't arrive at all, but on the real Internet, it's possible for a packet to arrive with erroneous data, so the real TCP has to check for that and request retransmission of packets with internal errors.
Watch the end of this video from code.org:
Build a simple TCP. Resolve the unreliability so that messages are received reliably despite the limitations of IP packets. You'll need to change:
The definition of
The script for each sprite that starts with
Note: because this is a simulation, you could always "solve" the problem by rewriting the program to simulate a perfect network instead of an imperfect one, but that's against the rules of this game. You may not change the definition of .
How can you keep track of the order of your data?
First, solve the problem of packets arriving out of order. That is, make it possible for the receiver to rearrange the packets into the intended order. This will require cooperation by both sender and receiver.
A packet can include any kind of data: text, numbers, or lists. You may include extra header information in a packet in addition to the one text character.
Then, solve the problem of packets not arriving at all. That is, make the transmission reliable even though IP is unreliable. This, too, will require changing both sender and receiver.
For the sake of the simulation, you can't do this by eliminating the unreliability of send IP packet. The sender will have to send a special end-of-transmission packet so that the receiver knows when to stop worrying about missing packets.
Compare the result with what you sent. What problems do you see?
Brainstorm what you could do to get around network unreliability.
On the stage there are two watchers: "Alice incoming transmission" and "Bob incoming transmission." But in the Variables palette there's only one variable name: "incoming transmission." These are actually two different local variables; one belongs to Alice and one belongs to Bob. (Local means not shared across sprites; global means shared across all sprites as we've been doing most of the course.) To make a local variable, click the "for this sprite only" button when creating a variable.
.