Implementation

In this implementation, emphasis was laid on the development of a teaching tool in the form of a Java applet that simulates the working of a stop-and-wait sliding window protocol. The applet aims at simulating 1-/2-/3- bit sliding window protocols with a window size of 1. The simulation can be either lossy or lossless. In the lossless case, the channel is assumed to be ideal , i.e. every frame transmitted by a station will reach the station at the other end of the communication channel in perfect condition. However, in the other case, the channel is not assumed to be ideal, and hence a frame transmitted by a station may be lost or garbled by the time it reaches the destination.

Each frame transmitted by a station consists of three fields as explained earlier (seq, ack & info…the ‘kind’ field is dropped --- all packets are assumed to be data packets). The individual fields within a packet are clearly demarcated by using different colours, with a legend regarding the representation of each colour. The user interface is very simple…five buttons are provided which control the working of the applet.

• The ‘Start’ button starts the simulation. A frame is first transmitted from the first station to the second. On receiving the packet, the second station in turn transmits a frame to the first machine, which on receiving this packet transmits another to the second machine and the process continues indefinitely till it is stopped by the user. This button is disabled when simulation is in progress.

• The ‘Stop’ button stops the simulation and resets various parameters used internally to their initial values. After this, the simulation can be restarted by clicking the ‘Start’ button. This button is disabled when simulation is not in progress.

• The ‘Pause/Resume’ button serves a dual purpose. When the simulation is in progress, it serves as the ‘Pause’ button and can be used to freeze the simulation. The simulation is stopped for the time being so that the user has more time to examine the happenings. The caption on the button then changes to ‘Resume’ and clicking the button again restarts the simulation from exactly the same condition it was in before it was paused. This button is disabled when simulation is not in progress.

• The ‘Change Settings’ button is used to bring up a screen that allows the user to change the various parameters that control the simulation. The user can change various parameters such as the size of the sequence no., the station transmitting first, the type of simulation , etc. as discussed in the design.

• The ‘Help’ button provides a simple on-line help that the user would find very convenient in case of difficulties. The help contents include easy instructions about using the applet.

Here both the communicating data link layers have a sending and receiving window each for duplex communication. The sending window of station A (top) is vertically aligned with the receiving window of station B (bottom), and the receiving window of station A is vertically aligned with the sending window of station B. This enables the user to easily verify the protocol mechanism; that is, if A is transmitting a frame to B, then the sending window of A and the receiving window of B will be the same, and vice versa. This is further emphasised by using explicit ‘windows’ at either end, with the highlighted part indicating the currently active window.

Whenever a frame reaches the destination, the particular station adjusts both its sending and receiving windows, if it is the frame that is expected. For example, on receiving an acknowledgement for frame 0, the receiving station sends frame 1 and hence advances its sending window from 0 to 1. This is shown in the applet using a mechanism which clearly depicts the change in the active window at a destination.

Further, the applet is controlled by using ‘Threads’, which provide for direct control over the various events that may occur during the execution of the applet. Thread - handling in Java enables the use of buttons to control the flow of control in the program. This is achieved by associating the methods start(), stop(), suspend() & resume() provided by the Java ‘Thread’ class with the event handlers that handle the events associated with clicking of the buttons. Also the ‘Canvas’ class provided by Java is extended (by the use of inheritance mechanism) and used with the thread mechanism to support the simulation. The sender and the receiver are implemented as ‘objects’ of a separate user defined class, and the important members of the class are the sequence and acknowledgement numbers, and the information packet number. The various applet screen dumps that follow clearly depict the working of sliding window protocols in duplex communications.

Run the stop-and-wait sliding window protocol applet by following this link.

The design of the stop-and-wait sliding window protocol applet can be easily adapted to build an applet that simulates the sliding window protocols which uses ‘pipelining’ , i.e. protocols which use the ‘Go-back-n’ or ‘Selective Repeat’ approaches. The major enhancements include changing the functionality of the ‘terminal’ class so that it supports the necessary protocol and also changing the functionality of the ‘paint’ method to support the required simulation.

An applet that simulates the sliding window protocol using ‘Go-back-n’ has been designed and implemented by following the above approach. The user interface is exactly the same as it was in the applet that simulates the stop-and-wait sliding window protocol. However, this applet supports only two types of simulation compared to four in the previous case. These include the lossless or the ideal case, where there are no losses in frames whatsoever, and a lossy case, where there is a possible loss in frames when the frames travel from the sending station to the receiving station. However, there are no lost acknowledgements, an area to be explored in future work.

Run the "go back n" applet by following this link.

This applet provides an easy to use interface to the user. When the applet is loaded, only the Ethernet cable is visible. There are four buttons at the lower end which allow the user to control the applet. At the top are two sets of colour keys which indicate to the user the status of a node or packet when it is displayed in a particular colour. Initially only the "Add Node" and "Help" buttons are enabled. The user can view the online help by clicking the appropriate button. The help guides the user on using the applet and it is quite comprehensive.

When the "Add Node" button is clicked, the applet enters the "add" mode. In this the user can click anywhere on the cable to add a node. Acknowledgement is provided immediately since the node is drawn at the correct position. The path that the packets of this node will take is also labelled above the cable. Multiple nodes can be added in this way. The user can then click on the "Done" button to exit the "add" mode. If the user exceeds the maximum number of nodes permitted, an error message to this effect is displayed. Nodes are not allowed to overlap either. Therefore if a node is added too close to another one, an error message is displayed. All these features make the applet user-friendly since there is a graphical interface and the user just has to click at a few places to get his work done. Even if an error does occur it is handled by the applet and the user is informed.

Once a node has been added, the "Remove Node" button is enabled so that the user can remove nodes from the network if he so desires. Even this is a very convenient process. When the user clicks on the button, the applet enters the "remove" mode. The user can click on the cable where the node attaches to it to remove it. However, the node is not removed immediately, it is only marked for deletion. This is indicated to the user in the form of a red mark on the node. This is done so that the user can leave the node in the network if he changes his mind while still in the "remove" mode. This can be done by clicking at the same spot again. This unmarks the node and the red mark is erased from the node. The nodes can be removed from the network by clicking on the "Done" button. The applet exits the "remove" mode and the nodes are finally removed from the network.

Before starting the simulation, the user has to specify the node parameters. These include the rate of data transmission in Mbps and the node to which the data is to be delivered. The user can specify these by clicking on the appropriate node. A window pops up which prompts him for the parameters. If he changes his mind he can close the window by either clicking on the "Cancel" button or by clicking on the exit button on the status bar. However if he decides to save the values entered, he can click on the "Ok" button (which is enabled only if a valid value is entered for both the parameters). These values can be changed later if desired. For the user’s convenience, the previous values are displayed when the window pops up for editing the values. Once parameters for a node have been set, the "Start" button is enabled using which the simulation can be started.

When the user clicks on the "Start" button, the simulation begins. The "Add Node" and "Remove Node" buttons are disabled during the simulation. Only those nodes whose parameters have been set will transmit data. The user can stop the simulation at any time by clicking on the "Stop" button (in place of "Start" button), which will refresh the display to its state before the simulation started. The parameters can be edited if required and nodes can be added or removed.

The actual simulation takes place as follows – each node continuously generates packets which are stored in its queue which is assumed to be infinite. The packets are generated at the rate specified by the user. Packet transmission follows the CSMA/CD protocol. To allow for better understanding of the simulation, each node is assigned a different colour for each of the states it can be in. These states can be – node is idle (no packets in queue), node is waiting to transmit (either waiting for the line to become free or it is backing off and waiting for its slot) or node is transmitting the packet. Similarly each packet can be in either of two states – either it is undamaged or it has been involved in a collision. Different colours are assigned for each of these states. These colour codes are clearly specified in the colour keys at the top of the display.

For the user’s convenience details about each node are displayed below the respective node. These details are as follows – the first box below the node tells how many packets the node has transmitted successfully as well as how many packets are currently in its queue. The second box specifies in which backoff slot the node will be transmitting the collided packet and which backoff slot is currently running. In addition, another box displays the maximum number of backoff slots possible in this round of collision resolution. This information will help the user understand the protocol better.

In the next chapter we study some of the other protocols and algorithms implemented.