A JAVA APPLET FOR ILLUSTRATING INTERNET ERROR CONTROL1

Mathematics and Computer Education, Fall 2004 by Holliday, Mark A

An interactive and animated Java applet uses the World Wide Web to illustrate how error control is implemented in the Internet. The illustration is intended to be accessible to students in any year of college.

INTRODUCTION

The Internet has become pervasive and consequently many students want to understand how it works. Fortunately, many of the key concepts in the design of the Internet are fundamentally simple. It should be possible to make them accessible to students in any year in college who major in any field, not necessarily computer science. This approach of focusing on a few key concepts in a manner understandable to the non-major was inspired by the text Great Ideas in Computer Science in Java [I].

As part of a long term project, the author has been investigating how to make some of these concepts accessible via interactive, graphical animations [5]. To make the animations as available as possible and since today's web browsers are Java-compliant, the animations use Java applets as the underlying programming technology. Java is a full-scale programming language that includes graphical support and other advanced features such as event-driven programming and threads for concurrency. Thus, Java is well-designed for developing interactive, graphical animations. Java applets are Java programs that can be invoked through a web browser. These applets have been tested successfully in our introductory course for students who do not intend to major in computer science, usually freshmen and sophomores.

This paper discusses the author's experiences developing a Java applet that illustrates how error control is implemented in the Transmission Control Protocol (TCP). One section discusses the concepts which the TCP error control Java applet is intended to convey, while the nature of the Java applet is covered in another section. We summarize and draw conclusions in the final section.

An earlier paper [4] discussed developing another of these Java applets which illustrated how media access is implemented in the Ethernet local area network protocol.

THE ILLUSTRATED CONCEPT

One of the main protocols in the Internet is the Transmission Control Protocol (TCP). Many Internet applications such as browsing the web and sending email are using TCP. The responsibility of TCP is to send a packet successfully from the sender computer to the receiver computer across the Internet. If the packet gets lost or corrupted, TCP is supposed to detect that an error has occurred and restransmit the packet. TCP continues retransmitting until the packet is sent successfully. This process is called reliable data transfer or error control. The subject of this paper is a Java applet that illustrates how TCP uses a reliable data transfer protocol to implement error control.

In the above definition of TCP error control a key term is retransmission. The approach TCP uses for error control in simplest terms is to keep on retransmitting a particular packet until the sender computer knows that packet has been successfully received by the receiver computer. Of course, a correct implementation of this idea that has good performance requires some care.

The simplest implementation of this idea is called the Stop-and-Wait protocol. In Stop-and-Wait the sender sends one data packet. When the receiver receives that data packet, the receiver checks to see if the data packet has been corrupted. If the data packet has not been corrupted, then the receiver sends an acknowledgement packet back to the sender. When the sender receives the acknowledgement, the sender can then send the next data packet.

What happens in Stop-and-Wait if something goes wrong? One case occurs when the sender's data packet is lost or corrupted. In this case the sender needs to recognize that the data packet should be retransmitted. Notice that the receiver will not send an acknowledgment if the data packet has been lost or corrupted. Consequently, the sender can use a timeout period. The timeout period starts when the data packet is sent. If the sender does not receive an acknowledgment packet by expiration of the timeout period, then, when the timeout period expires, the sender retransmits the data packet.

The second way things can go wrong in Stop-and-Wait occurs when the sender's data packet reaches the receiver and is not corrupted, but the receiver's acknowledgment packet is lost or corrupted. In this case the sender waits until the timeout period for the data packet expires and retransmits the data packet. The receiver will then receive a second copy of the data packet. The receiver discards the second copy of the data packet and retransmits the acknowledgment packet. This may happen several times until finally the acknowledgment packet reaches the sender uncorrupted and the sender stops retransmitting the data packet.

Once Stop-and-Wait addresses these two kinds of errors, Stop-and-Wait is correct. Unfortunately, Stop-and-Wait can perform poorly since the sender could be idle a large fraction of the tune. If the tune it takes for a packet to reach the receiver is much longer than the time it takes for the sender to transmit a packet, then the sender will spend most of its time idle, waiting for the acknowledgment. If the sender needs to send several packets, then the time until the last of the packets is sent might be quite long due to this waiting. A family of retransmission protocols called Pipelined protocols, extend the Stop-and-Wait protocol in order to solve this problem. In a Pipelined protocol the sender can start sending a second data packet before the sender, receives the acknowledgment for the first data packet. Thus, if the sender needs to send several packets, then the time until the last of the packets is sent will be shorter with a Pipelined protocol. As a result, Pipelined protocols have better performance than Stop-and-Wait.