Sliding Window Protocols

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

Sliding Window Protocol Features

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
2n - 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.

1 – Bit Sliding Window Protocol

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

A. 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 1st frame.
B. This is the state after the first frame has been sent. The window in the sending process
indicates that frame 0 has been sent.
C. 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.
D. 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 2n - 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…

a. Initial stage, when transmission has not commenced.

b. After the first frame has been sent.
c. After the first frame has been received.
 d. After the first acknowledgement has been received.

Error Control

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 :

a. 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.
b. 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.
The frame transmitted by the source could suffer an error. If the error is detected by the
destination, it discards the frame and sends a negative acknowledgement (NAK) back to
the sender, causing the source to retransmit the damaged frame. On the other hand, if the
transmitted frame is so corrupted by noise as not to be received, the destination will not
respond. To account for this possibility, the source is equipped with a timer. After a
frame is transmitted, the source waits for an acknowledgement (ACK or NAK). If no
recognizable acknowledgement is received during the timeout period, then the frame is
retransmitted. Hence, as can be seen the source station should maintain a copy of the
transmitted frame until an ACK is received for that frame.

The principal advantage of the Stop-and-Wait ARQ is its simplicity. However, its
disadvantage is that it is an inefficient protocol because of poor bandwidth utilization.
This demerit clearly assumes substantial proportions, especially when the transmission
time required for a frame to arrive at the receiver plus the transmission time for the
acknowledgement to come back is very high.
 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.

Consider that station A is sending frames to station B. After each transmission, A sets an
acknowledgement timer for the frame just transmitted. The go-back-N technique takes
into account the following contingencies …

1. Damaged frame

a. 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.
b. 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.
c. 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

a. 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.
b. 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.

As can be seen from the figure below depicting Selective Repeat, it is easily discernible
that the Selective Repeat approach minimizes the amount of retransmissions. However,
the receiver must also contain storage to save the post-NAK frames until the frame in
error is retransmitted, and moreover this retransmitted frame must also be inserted in the
correct sequence before the transmitted frames are passed on to the network layer. The
transmitter, too, will require more complex logic to be able to send frames out of
sequence. Due to such complications, the Selective Repeat (also known as Selective
Reject) is seldom implemented.
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.

Applet Design

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.

Review of Design

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.