.TCP is the protocol, frequently mentioned in the same breath as IP, that is used to get around these problems. What would happen if you wanted to send a book to someone, but the Post Office only accepted letters? What could you do? You could rip each page out of the book, put it in a separate envelope, and dump them all in a mailbox. The recipient would then have to make sure the pages all arrived and paste them together in the right order. This is what TCP does.
TCP takes the information you want to transmit and breaks it into pieces. It numbers each piece so receipt can be verified and the data can be put back in the proper order. In order to pass this sequence number across the network, it has an envelope of its own which has the information it requires "written on it" (Figure 3-3). A piece of your data is placed in a TCP envelope. The TCP envelope is, in turn, placed inside an IP envelope and given to the network. Once you have something in an IP envelope, the network can carry it.
On the -receiving side, a TCP software package collects the envelopes, extracts the data, and puts it in the proper order. If some are missing, it asks the sender to retransmit them. Once it has all the information in the proper order, it passes the data to whatever application program is using its services.
This is actually a slightly utopian view of TCP. In the real world not only do packets get lost, they can also be changed by glitches on telephone lines in transit. TCP also handles this problem. As it puts your data into an envelope, it calculates something called a cbecksum. A checksum is a number that allows the receiving TCP to detect errors in the packet.* When the packet arrives at its destination, the receiving TCP calculates what the checksum should be and compares it to the one sent by transmitter. if they don't match, an error has occurred in the packet. The receiving TCP throws that packet away and requests a retransmission.
*Here's a simple example, if you're interested. Let's assume that you're transmitting raw computer data in 8-bit chunks, or bytes. A very simple checksum would be to add all of these bytes together. Then stick an extra byte onto the end of your data that contains the sum. (Or, at least, as much of the sum as fits into 8 bits.) The receiver makes the same calculation. If any byte was changed during transmission, the checksums will disagree, and you'll know there was an error. Of course, if there were two effors, they might cancel each other out. But more complicated computations can handle multiple errors.
3-3: TCPpacket encapsulation
Making the Network Friendly
Now that we have the ability to transfer information between places on the network, we can start working on making the Internet more friendly. This is done by having software tailored to the task at hand, and using names rather than addresses to refer to computers.
Applications
Most people don't get really excited about having a guaranteed bit stream between machines, no matter how fast the lines or exotic the technology that creates it. They want to use that bit stream to do something useful, whether that is to move a file, access some data, or play a game. Applications are pieces of software that allow this to happen easily. They are yet another "layer" of software, built on top of the TCP or UDP services. Applications give you, the user, a way, to do the task at hand.
What an application is varies greatly. Applications can range from home-grown programs to proprietary programs supplied by a vendor. There are three "standard" Internet applications: remote login, file transfer, and electronic mail, as well as other commonly used but not standardized applications.
One problem with talking about applications is that the applications appearance to you is determined by your local system. The commands, messages, prompts, etc., may be slightly different on your screen than in the book or on someone else's screen. So, don't worry because the book says the message is "connection refused" and the error message you receive is "Unable to connect to remote host: refused"; they are the same. Try and distill the essence of the message, rather than matching the exact wording. And don't worry if some of the commands are named slightly differently; most of the applications have reasonable "help" facilities that will let you figure out the right command.