Computer Networks (CPE471)

Simulation Of Simplex Stop and Wait Protocol with PAR

Objective: This Programming assignment will help you understand data link transmission protocol for
noisy simplex channels, by simulating the simplex stop and wait protocol with positive acknowledgement and retransmission (PAR).

Brief Description :This exercise will simulate the simplex stop and wait protocol with positive
acknowledgement and retransmission(PAR).Simplex protocols for noisy channels are described on pages 197-202 of Tanenbaums Computer Networks(third edition).This program will transmit the contents of an ASCII data file .The basic solution requires a transmitter function, a receiver function, be implemented either in a single program or as multiple programs communicating through pipes .An example of program solution as follows. The transmitter reads data from the file, creates the data frame, calculates the checksum, applies the gremlin, and then calls the receiver. The receiver checks the checksum, writes the correct frame to out file, and returns the acknowledgement. This assignment requires a substantial design and programming effort and programming effort and should be solved by teams of two students.

Procedure :In this assignment you will simulate the simplex stop and wait protocol with positive
acknowledgement and retransmission (PAR).Use the language or compiler of your choice. You may work Either individually or with a partner. This problem itself is straightforward. The simplex stop and wait PAR is covered on pages 197-202 of Tanenbaum text and the algorithms for both sender and receiver are specified in Figure 3-11 of that text. Of course, the program can not just be typed in as is and run .For one thing ,the sender and receiver would have two separately running processes which can nevertheless communicate with each other as necessary. For another, the algorithm contains a timing mechanism and event waiting. The solution described here does not require concurrency. If you know how to write programs which can be run as separate processes and communicate via pipes. I courage you to pursue that solution strategy instead of the one outline here. If you want an even greater challenge, implement a full solution which handles lost frames and uses timers and signals for acknowledgement. The goal is to simulate the transmission of an ASCII file .The sender will read from the file(network layer) and read from the file (network layer) and transmit its content to the receiver ,which will write the information to another file (network layer).Filenames are entered at runtime. The datalink protocol implemented in your program must provide the network layer an error-free, sequenced transmission service. Your program into frames will break up the input stream. It will transmit the frames one by one according to protocol. It will reconstruct the data streams one by one according to the protocol. It will reconstruct the data stream at other end and write it to the file. The solution simplifies the algorithm by not requiring the timing mechanism or event waiting. Data frames may be damaged but not lost. The sender and receiver are two separate functions. The sender is given a stream of input data. It will break the data into data frames of eight bytes. If the total Length is not a multiple of eight, pad the last frame with 0s .If the total length is a multiple of eight, make the last data frame all 0s.This should be recognized on receiving side as the end of file. Each frame will also have a 16bit checksum attached ,using CRC coding based on CRC-CCITT generator polynomial . The most advanced solution requires a one-bit sequence number, which can be added as a one-byte field to frame structure. The others do not require sequence because frames are not lost or delivered out of order. The frame will first be passed to gremlin function, which occasionally damage the frame (this simulates Transmission errors). The result is then sent to receiver function .The sender then waits for ACK or NAK from the receiver .ACK means, the frame was received OK, so send the next. NAK means The

frame was damaged ,please send again. The sender gets ACK/NAK as the return value of receiver function. ACK/NAKS are never damaged or lost. The receiver will read each frame .It must first check for checksum errors. If no error occurred, it will return an ACK to the sender. Otherwise, it will return a NAK retransmission .Use any values you wish to represent ACK/NAK .It is the receivers responsibility to reassemble frames into output stream. The gremlin function uses a random-number generator to determine whether to damage a frame, and, if so How many and which bits to flip. The probability that a given frame will be damaged (d) will be entered at runtime. If the frame is to be damaged, the probability of flipping one bit is .5,the probability of flipping two bits is .3,and the probability of flipping three bits is .2.Every bit in the frame is equally likely to be damaged. Include trace option for both the sender and the receiver. If the trace is on, the sender will output the message: Frame: xxx transmitted --yyy Where xxx is the frame number (just maintain a counter of frames successfully transmitted), and yyy is the string either intact or damaged. Depending on whether the gremlin damages it or not. The receiver will likewise output the message : Frame: xxx received --yyy with the analogous meaning. The trace option is specified at run time. PROGRAM INPUT FROM USER: 1. Name of input file. 2. Name of Output file. 3. Probability that a frame will be damaged 4. Whether or not frame tracing should be enabled PROGRAM OUTPUT SCREEN (AFTER TRANSMISSION COMPLETE) 1. Total number of packets read from senders network layer 2. Total number of frames transmitted (correct plus damaged) 3. Total number of frames damaged. 4. Maximum number of retransmissions for any single frame. 5. Total number of packets delivered to receivers network layer Report: The report should include source and executables files and floppy disk.