Sliding Window Mechanism
The sliding window mechanism is used in many protocols at many different layers. The sliding window helps in solving a number of problems. Retransmission of lost or damaged frames (or packets) and flow control problems are just examples of that. The sliding window protocol in its simplest form consists of the following:
Both sender and receiver agree on a maximum number of packets that the sender can send before it is forced to stop. That is known as the widow size. The window size also indicates the number of frames the sender must maintain in memory for possible retransmission. Subsequent frames can only be sent by the sender if an acknowledgement is received confirming all or some of the frames already sent. The receiver will send acknowledgement(s) for error free frames received correctly and in the expected sequence. Those frames kept by the sender for possible retransmission will no longer need to be kept if the receiver acknowledges that they have been received. Now, the sender can move the window so it will not include any acknowledged frames. More frames can now be sent. Notice that the window size remains the same for the duration of the session of the established link (or virtual channel)
The sliding window protocol places a requirement on the sender to keep in memory all frames sent until fully or partially acknowledged by the receiver. But the receiver normally does not need to keep copies of the received frames except in one form of the sliding window protocol. Flow control protocols we looked at are: Stop-and-wait, Go-back-N and the Selective Repeat. You are asked to use any Go-back-N protocol with a window size greater than one.
In the following example if the window size is 3, then in window A in figure 1, shows that the sender can only send frames numbers 0, 1 and 2. The sender must then stop until an acknowledgment is received or the timer expires. If for example an acknowledgment 2 is received. It indicates that frames 0 and 1 have been received and the receiver is expecting to next receive frame number 2. The sliding window at the sender should advance to look like the window B in figure 1
Design and implement by programming the idea in the sliding window as implemented in a data link layer. Your program design will consist of a simulation of two main processes (the sender and the receiver) operations. When sending, the sender process will read from a given file, create frames of data and place them in a sending or transmission queue called the Out-queue see Figure 2. The Out-queue will be the way normally the data link layer communicates with the physical layer.
When receiving frames, the receiver process will take frames from the physical layer through an In-queue and writes the data to corresponding files. Figure 3 is expected to represent the required implementation of the sender and receiver processes communicating through two separate queues.
Your program will involve at least the following points:
1. Use the frame structure shown in figure 3 to perform the sliding window protocol. The functions of error checking, link establishing and link disconnecting will not be required. Assume physical connection and data link are established.
(10 points)
2. An interface which will prompt the user for a file name to be used as input and for contents to be transferred; and a file name in which to save received data. Use default file names during development and testing. An error will be displayed if an input file is not found. When data transfer starts, the interface should indicate the numbers of frames sent and received. A message should be displayed indicating end of transfer for the outgoing file.
3. The interface should provide a mean to define the window size and the maximum size of the Information field to use during the communication before the actual communication starts. Use the cycled frame sequence numbers 0 to 7.
(10 points)
4. The sender process will place frames in the Out-queue for as long as the window size allows it to do so. The receiver process will take packets from the In-queue as long as the queue contains frames.
5. When a frame is received; the frame type is inspected. If the type indicates it is an Information frame then the following sequence of events is expected: (20 points)
• The sequence number of the frame is noted. Any acknowledgement number is noted. The data size is established.
• The data is taken from the user data field and written to the file.
• An acknowledgement is to be sent only in one case where there are no more frames in the incoming queue. In such case an RR frame (or acknowledgement frame) is created and the acknowledgement number is placed in the appropriate field. The frame is then placed in the out queue.
6. When all data has been read from an input file the file is closed. The sender process will indicate that on the user interface. The user interface must allow a command to close both files.
