Sliding Window Protocols

In this chapter, we study the Sliding Window Protocols and the implementation details of the applets designed to simulate their working.

The data link protocols such as the simplex protocols discussed in the preceding chapter allow only simplex transmission. However, in most practical situations, there is a need for transmitting data in both directions. An efficient implementation of duplex transmission makes use of the same circuit for data in both directions, instead of having two separate physical circuits and use each one for simplex data traffic (in different directions). Though interleaving data and control frames on the same circuit is an improvement over the above stated separate physical circuits, yet another improvement is possible. When a data frame arrives at the data link layer of a communicating machine, instead of immediately sending a separate control frame, the receiver waits till the network layer passes it the next packet to be transmitted. The acknowledgement is attached to the outgoing data frame (using the ‘ack’ field in the frame header). Thus there is no need for transmitting a separate acknowledgement frame. This technique of temporarily delaying outgoing acknowledgements so that they can be attached onto the next outgoing data frame is known as piggybacking.

The main advantage of using piggybacking over having distinct acknowledgement frames is a better use of the available channel bandwidth. The ‘ack’ field in the frame header occupies only a few bits, whereas a separate frame would need a header, the acknowledgement, and a checksum (for error detection). In addition, fewer frames sent means fewer ‘frame arrived’ interrupts, and perhaps fewer buffers in the receiver, depending on how the receiver’s software is organised. In most of the sliding window protocols, the piggyback field rarely occupies more than a few bits.

As shown, each outbound frame (the frame passed to the physical layer for transmission) contains a sequence number, ranging from 0 to some maximum. The maximum is usually 2ⁿ - 1, so the sequence number exactly occupies an n-bit field. The stop-and-wait sliding window protocol uses n = 1, but more sophisticated versions can use arbitrary n.

The main theory behind the sliding window protocols is that at any instant of time, the sender maintains a set of sequence numbers corresponding to frames it is permitted to send. These frames are said to fall within the sending window. Similarly, the receiver also maintains a receiving window corresponding to the set of frames it is permitted to accept. The sender’s window and the receiver’s window need not have the same lower and upper limits, or even have the same size. In some protocols they are of fixed size, but in others they can grow or shrink as frames are sent and received. It can be observed that the protocols give the data link layer more freedom about the order in which it may send and receive frames, and at the same time maintains the requirement that the protocol must deliver packets to the network layer of the destination machine in the same order that they were passed to the data link layer on the sending machine. Also, the requirement that all frames must be delivered in the order sent is not changed.

Consider the following scenario with a sliding window size of 1, with a 1-bit sequence number.

This is the initial state. The sender has not commenced transmission. So its sending window is empty. The receiver, on the other hand, is ready to receive the 1^st frame.

This is the state after the first frame has been sent. The window in the sending process indicates that frame 0 has been sent.

This is the state after the first frame has been received. The receiver’s window is advanced by 1 so that it is now ready to receive frame 1.

This is the state after the first acknowledgement has been received. The sender’s window is now advanced by 1 so that it is ready to transmit frame 1.

The sequence numbers within the sender’s window represent frames sent but as yet not acknowledged. Whenever a new packet arrives from the network layer, it is given the next highest sequence number, and the upper edge of the window is advanced by one. When an acknowledgement comes in, the lower edge is advanced by one. In this way, the window continuously maintains a list of unacknowledged frames. Since frames currently within the sender’s window may ultimately be lost or damaged in transit, the sender must keep all these frames in its memory for possible retransmission. Thus if the maximum window size is n, the sender needs n buffers to hold the acknowledgement frames. If the window ever grows to its maximum size, the sending data link layer must forcibly shut off the network layer until another buffer becomes free.

The receiver’s window corresponds to the frames it may accept. Any frame falling outside the window (not bearing the requisite seq. no.) is discarded straightaway. When a frame whose sequence number is equal to the lower edge of the window is received, it is passed to the network layer, an acknowledgement is generated, and the window is rotated by one. The sender’s window may change in size, but the receiver’s window always remains at its initial size. This is clearly illustrated in the above example.

So, in case of the n-bit sliding window protocol, the maximum window size will be 2ⁿ - 1 (i.e., for a 2-bit sliding window protocol maximum window size is 3, for a 3-bit sliding window protocol it is 7 and so on). A window size of 1 means that the data link layer only accepts frames in order (by seq. no.), but for larger windows this is not the case i.e. the receiver can accept frames out of order if they bear sequence numbers within the receiving window. However, the network layer is always fed data in the proper order, irrespective of the data link layer’s window size.

In Fig. 3-3 above, a sliding window of size 1 with a 3-bit sequence number has been depicted. The various stages are…

Initial stage, when transmission has not commenced.
After the first frame has been sent.
After the first frame has been received.
After the first acknowledgement has been received.

Error control refers to the mechanisms to detect and correct errors that occur in the transmission of frames. The two common types of errors are :

Lost frame : A frame fails to arrive at the other side. A noise burst may have damaged a frame to the extent that the receiver is not aware that a frame has been transmitted.

Damaged frame : A recognisable frame does arrive but some of the bits are in error (have been altered during transmission).

The most common techniques for error control are :

Error Detection : For error detection, typically Cyclic Redundancy Check (CRC) is used during transmission of frames.

Positive Acknowledgement : The destination station returns a positive acknowledgement for frames that have been successfully received and are error free.

Retransmission after timeout : The source retransmits a frame that has not been acknowledged after a predetermined amount of time.

Negative acknowledgement and retransmission : The destination returns a negative acknowledgement to frames in which an error is detected. The source after receiving the feedback retransmits such frames.

Collectively, these mechanisms are all referred to as automatic repeat request (ARQ). The three popular versions of ARQ with respect to the Sliding Window Protocol, have been described below :

Stop & Wait ARQ : The Stop & Wait ARQ is based on the stop-and-wait flow control technique as observed in the 1-bit Sliding Window Protocol, described above. The source station transmits a single frame and then waits for an acknowledgement (ACK). Data frames cannot be sent until the destination station’s reply arrives at the source station.

Go-back-N ARQ : The sliding window flow control technique can be adapted to provide more efficient line use, which is referred to as continuous ARQ. One variant of the continuous ARQ is known as go-back-N ARQ. In this technique, the sender may send a series of frames determined by the window size, using the sliding window flow control technique. While the occurrence of errors is nil, the destination will acknowledge (ACK) incoming frames as usual.

Station A transmits frame i. Station B detects an error and has previously successfully received frame (i-1). B sends a NAK i, indicating that frame i is rejected. When A receives this NAK, it must retransmit frame i and all subsequent frames that it has transmitted.

Frame i is lost in transit. Station A subsequently transmits frame (i+1). Station B receives frame(i +1) out of order, and sends a NAK i.

Frame i is lost in transit and station A does not soon send additional frames. Station B receives nothing and returns neither an ACK nor a NAK. Station A will timeout and retransmit frame i.

2. Damaged ACK

Station B receives frame i and sends ACK(i+1), which is lost in transit. Since ACK’s are cumulative (e.g., ACK 6 means that all frames through 5 are acknowledged), it may be that Station A will receive a subsequent ACK to a subsequent frame that will do the job of the lost ACK before the associated time expires.

If Station A’s timer expires, station A retransmits frame i and all subsequent frames.

3. Damaged NAK

If a NAK is lost, station A will eventually time out on the associated frame and retransmit that frame and all subsequent frames.

The above figure shows the frame flow for go-back-N ARQ on a full duplex line, assuming a 3-bit sequence number. As is evident, from the explanation in the preceding paragraph, it is not required that each individual frame be acknowledged. For example, station A sends frames 0,1, 2 and 3. Station B responds with ACK1 after frame 0, but then does not respond to frames 1 and 2. After frame 3 is received, station B issues ACK4, indicating that frame 3 and all previous frames have been accepted.

Selective Repeat ARQ : Another variant of continuous ARQ is the selective repeat ARQ. Selective Repeat, which is also used as an error-handling technique. When frames are pipelined, it makes the receiving data link layer store all the correct frames following the bad one. When the sender finally notices that something is wrong, it just retransmits all those frames that receives a NAK or those which time out. If the second try succeeds, the receiving data link layer will now have many correct frames in sequence, which can be handed over to the network layer and the highest number acknowledged.

The Go-back-N and the Selective Repeat approaches improve bandwidth utilisation by incorporating pipelining in their working. Both these approaches differ in the sense that the Go-back-N strategy is applicable to a window size of 1 (i.e., the receiving data link layer refuses to accept any frame except the next one it must give to the network layer). Also in go-back-N, a lot of bandwidth will be wasted if the error rate is high. On the other hand, the Selective Repeat strategy corresponds to a window size larger than 1 (i.e., any frame within the window may be accepted and buffered until all the preceding ones have been passed to the network layer). This approach can require larger amounts of data link layer memory if the window is large.

Thus, these two approaches are trade-offs between the bandwidth and data link layer buffer space. Depending on which resource is more valuable, one or the other can be implemented.

This section having dealt with the features and working of the Sliding Window Protocol, the remaining sections of this chapter explain the working and the class hierarchy of the Java applets designed as teaching tools, to study the behavior of this robust data-link protocol.

Since the simulator has been developed in Java, which is an Object-Oriented Language, the design entails the discussion of the classes (which represent the objects that a data link layer protocol implementing flow control using the sliding window protocol would contain) and their methods. These components have been listed below.

• Sliding : This is the main class that creates most of the objects required and also initialises the applet at run-time. It contains the following methods :

• init : This is the method which is executed when the applet is first loaded. Hence it is responsible for initialising the applet. The various controls are added to the applet in this method.
• actionPerformed : This is an event-handling method which is invoked whenever any of the buttons is clicked. Depending on the button clicked, it calls the appropriate method.
• Start : This method is invoked from the ‘actionPerformed’ method when the ‘Start’ button is clicked. It starts the simulation by initialising variables of the appropriate container classes and launches a new thread to handle the current simulation. Once the simulation begins, the ‘Start’, ‘Help’ and ‘Change Settings’ buttons are disabled.
• Stops : This method is invoked from the ‘actionPerformed’ method when the user clicks the ‘Stop’ button. It stops the simulation currently underway, destroys the active thread, and then refreshes the applet display by invoking the ‘paint’ method of the "Canvas1" class. Now the ‘Start’, ‘Help’ and ‘Change Settings’ buttons are enabled whereas the ‘Pause/Resume’ button is disabled.
• PauseorResume : This method is also called from the ‘actionPerformed’ method when the ‘Pause/Resume’ button is clicked. The action taken by this method depends on the caption on the ‘Pause/Resume’ button which in turn depends on the current state of the simulation. If the caption is "Pause" then the simulation is frozen in its current state so the user has more time to examine the happenings. If the caption is "Resume" then the simulation is resumed from the state in which the applet was, when the user had paused the simulation.
• run : This is a method which contains the code for the executing thread of the Sliding class. In this case the thread that this method represents runs only when the simulation is underway. It also determines when the direction of frame transfer is to be reversed and invokes another method ‘changedir’ to accomplish the change of direction.
• changedir : This method is used to invert the direction of frame transfer. It initialises specific variables in the various container classes

• Canvas1 : This class is derived from the Java "Canvas" class. It is used to manage a major part of the display. Except for the buttons, all the components are drawn on the canvas using this class. It contains a number of methods which control most of the working of the applet. These are described below :

• Canvas1 : This is the constructor for this class. It creates an instance of the class, which is used for controlling the simulation. It also initialises the variables.
• paint : This method is very important, since it is invoked whenever the display is to be refreshed. When invoked, this method draws the static elements only if simulation is not underway. If simulation is in progress, then the method either draws the frame at its new position, or erases it from its current position, depending on the value of the control variables - ‘clear’ and ‘active’.
• update : This is invoked whenever a call to the repaint method is made. The ‘update’ method is over-ridden so that the display is not cleared each time before drawing.
• settype : This makes the ‘Canvas1’ class aware of the type of simulation to be carried out. This information is passed on to the ‘Packet’ class which is contained in ‘Canvas1’.
• setlossno : This method sets the number of the first frame to be lost in either direction, depending on the type of simulation. This information is also passed on to the ‘Packet’ class which is contained in ‘Canvas1’.
• setmaxseq : This sets the maximum possible sequence number for a particular simulation. It is directly dependent on the number of bits used to represent the sequence number. This applet supports upto 3 - bit sequence numbers, and hence the maximum sequence numbers can be 1, 3 or 7 for 1-, 2-, and 3-bit sequence numbers respectively. This information is also passed on to the ‘Packet’ class which is contained in ‘Canvas1’.

• Packet : This is a user - defined class instantiated in the Canvas1 class, i.e. an object of class Packet is ‘contained’ in Canvas1 class. This class is completely responsible for managing the movement of the frame as it is transmitted from one station to another. It considers various parameters such as the maximum sequence number, the type of simulation, the frame to be lost, the station transmitting first, etc. and appropriately manages the simulation of the frame. The methods used for accomplishing this are described below :

• Packet : This is the constructor and creates an instance of this class. It accepts a parameter which sets the initial direction of transmission. It also instantiates two objects of class ‘terminal’ (to be discussed later) - A and B, representing the two stations respectively. This is also an example of Containership.
• sendinit : This method initialises the instance variables at the end of every simulation.
• settype : This makes the ‘Packet’ class aware of the type of simulation to be carried out. Its function is similar to the settype method discussed earlier for the Canvas1 class.
• setlossno : This method sets the number of the first frame to be lost in either direction, depending on the type of simulation.
• setmaxseq : This sets the maximum possible sequence number for a particular simulation. It is directly dependent on the number of bits used to represent the sequence number. This information is also passed on to the objects ‘A’ and ‘B’ by invoking their setmaxseq methods.
• setinitdir : As the name suggests, this method is used to set or change the initial direction after the user has made changes in the simulation parameters.
• changeturn : This method is invoked when it is the turn of the opposite station to transmit a frame. It makes certain initialisations which are essential for resuming the simulation in the opposite direction. This method is invoked after a successful transmission by the sending station or after a possible timeout at the receiving station. Also, whether the current transmission will be successful or not is determined in this method itself. Moreover, if the simulation settings are set to ‘random losses’, then the new sequence value for the next frame to be lost after a frame loss is also calculated in this method.
• nextxy : This method is concerned with updating the display coordinates of the frame. It calculates the new display coordinates of the current frame depending only on the station transmitting the frame. It returns a value ‘+1’ if it was successful in updating the x and y values within certain fixed boundaries, and a value ‘-1’ if the opposite station has been reached (y value exceeds or drops below a certain threshold). This value is used by the main class to determine whether the method ‘changedir’ is to be invoked or not.
• getx : This method returns the current x value of the frame position.
• gety : This method returns the current y value of the frame position.
• setxy : It sets the display position of the current frame to the x and y values passed as parameters to the method.
• sendpacket : This method is responsible for invoking the drawpacket and drawCircle methods (to be discussed) with appropriate parameters. Also, depending on the state of the simulation, it erases the frame from its current position. The frame is then redrawn at some adjoining position to give an animation effect.
• drawpacket : It uses the Java Graphics library to draw the frame at the specified location. The location is passed as a parameter to this method. It is invoked by the sendpacket method.
• drawCircle : This method is used to highlight the sending and receiving windows at either station. The parameters passed are the centre coordinates, start and end angles and the radius of the pie-slice.

• terminal : This class represents a station that uses the sliding window protocol to implement flow control. The instance variables ‘next_to_send’ and ‘frame_expected’ keep track of the sequence number of the next frame to be transmitted and the sequence number of the next frame to be received respectively. The number of the piggybacked acknowledgement is calculated from frame_expected by using the relation :

  ack = maxseq - frame_expected

  The various methods used in this class are discussed below :

• terminal : This is the constructor of the class and used to initialise the values of instance variables whenever an object of the class is first created. The variables next_to_send and frame_expected are initialised to ‘0’ and ack is also calculated using the above relation.
• reset : It performs a function similar to that of the constructor, except that it is invoked explicitly at the end of each simulation.
• receive : This function determines whether the received frame is the one which was expected. If the expected frame is in fact received, then appropriate changes are made to next_to_send and frame_expected. Otherwise, they are not updated.

The functionality of this method can be expressed as follows :

void receive(int rseq, int rack){

if (rseq == frame_expected){ if (frame_expected == maxseq) frame_expected = 0; else frame_expected++; } if (rack == next_to_send){ if (next_to_send == maxseq) next_to_send = 0; else next_to_send++; } }
• transmit : This function simply sets the instance variables seq and ack to the values required for the current transmission. The instance variable seq represents the sequence number of the frame to be transmitted and ack represents the piggybacked acknowledgement number for the frame received last.

The functionality of this method can be expressed as follows :

void transmit(){ seq = next_to_send;
ack = frame_expected - 1;
if (ack < 0) ack = maxseq;
}
• getseq : It returns the sequence number of the current frame.
• getack : It returns the acknowledgement number of the current frame.
• setmaxseq : This method sets the maximum sequence number to the value passed as a parameter to it.

• menu : This class, which is derived from the Java "Frame" class, is used to create an object which presents a pop-up screen for controlling the simulation parameters. An object of this class is embedded within the main class (Sliding). The simulation parameters are first set in an object of this class, and then passed onto objects of other classes which actually use those parameters. The important methods present in this class are as follows :

• menu : This is the constructor for the class. It gives the pop-up screen a name and also adds the various controls required for accepting the simulation parameters from the user in a convenient manner. The simulation parameters that can be modified using this class are :

• Size of the sequence number (1-/2-/3- bit) : This corresponds to a maximum sequence number of 1, 3 and 7 respectively. The user selects one of the three choices using a drop-down choice which lists the three options.
• The station transmitting first : Here there are only two choices- Station ‘A’ or Station ‘B’. Hence a checkboxgroup (radio buttons) is used to read the user’s choice.
• One way delay : The user can control the speed of simulation by entering an appropriate value in this field. Since the user should be able to specify the delay he/she wants directly, a textbox is used for the purpose.
• Type of Simulation : Type ‘0’ indicates an ideal scenario where there are no losses whatsoever, type ‘1’ indicates that there may be losses in transmission from station ‘A’ to station ‘B’, but not from station ‘B’ to station ‘A’. Similarly, type ‘2’ indicates that there may be losses only in transmission from station ‘B’ to station ‘A’; and type ‘3’ indicates there may be losses in frames when the transmission is in either direction. The user is required to select one of the four choices from a drop - down choice.
• Losses in frame transmission : The user can specify that every ‘x’ ^th frame be lost or he/she can also specify that the losses be random in nature. Hence a checkbox is used to select or de-select the random losses option. If the checkbox for random losses is de-selected, then the user has to specify a valid number for the frame number to be lost in the text boxes provided for the purpose.

• textValueChanged : This method is invoked when the text in either of the text boxes changes. It is used to keep track of the values entered by the user and also to check whether they are valid. Appropriate validation checks are performed on the parameters read from the text boxes to ensure that only valid parameters are passed to the various methods in various classes.
• itemStateChanged : This method is invoked when the user selects one of the options in either of the drop-down choices. It is also invoked when the user changes the selection in the checkboxgroup (radio button) or selects / de-selects the checkbox.
• getdelay : This function returns the one-way delay as set by the user.
• getmaxseq : This function returns the maximum sequence number (1/3/7 as discussed earlier), depending on the option selected by the user from the drop-down choice.
• getinitdir : This function returns a value ‘1’ if the initial transmission is to be from ‘A’ to ‘B’ and it returns a value ‘0’ if ‘B’ is to transmit first.
• gettype : This function returns a value (0/1/2/3) indicating the type of simulation specified by the user.
• getlossnoa : In cases where there is a possible loss of transmission from ‘A’ to ‘B’, this function returns a +ve number specifying the frame to be lost when it is ‘A’’s turn to transmit.
• getlossnob : In cases where there is a possible loss of transmission from ‘B’ to ‘A’, this function returns a +ve number specifying the frame to be lost when it is ‘B’’s turn to transmit.
• israndom : This function returns a true/false value specifying whether the current simulation has random losses or not.

• Help : Online help on using the applet is provided through this class. It is derived from the Java "Frame" class. Whenever the user clicks on the "Help" button, a window, which is an instance of this class, is displayed. It consists of the following methods :

• Help : This is the constructor for the class. The help text is added to the window in this method.
• processWindowEvent : This method is an event-handler that processes window events. In this case, it detects whether the "close window" button on the status bar has been clicked. If it has been clicked, the window is closed.

The foregoing discussion of the class structure suggests that the important objects essential for effective representation of the real-world sliding window protocol implementation have been identified and classes have been constructed for them.

The "Packet" class represents a data frame precisely. The sendPacket method of this class concentrates on the movement of the packet for the sliding window control and is a complete module in itself. It can be easily overloaded to simulate some other protocol while using the same class to represent the packet.

The "Canvas1" class contains most of the functionality of the applet, except that for handling the buttons and threads that control the simulation. Thread control is exercised completely by the main class i.e ‘Sliding’. This is essential as only the class at the top of the hierarchy should be trusted with the controlling of threads. The buttons are used for a very short time compared to the time the applet runs for, and since the action to be taken for handling the buttons is relatively straightforward, it can easily be handled by the main class itself. The various stages of simulation are drawn on the canvas thus making it very convenient to program and understand if most of the work is carried out in methods of this class.

A separate class is designed for displaying ‘help’ messages. This helps in achieving data and code abstraction, at the same time permitting code reusability. The contents of the ‘help’ can be easily changed without effecting rest of the design or the program. Similarly, a ‘help’ class developed for this applet can be conveniently reused for another applet by simply modifying the string that the help is supposed to display. Rest of the functionality is unchanged.

Thus the design appears to be well-structured and robust. The class ‘Containership’ mechanism is used effectively for passing of simulation parameters and for evenly distributing the complexity in the various classes. This helps in code maintainability and reusability. It is evident that the applet design is efficient and represents quite accurately the needs of the application.

In the next chapter we investigate the CSMA/CD protocol and its design in detail.