Data Communications

Swinburne University of Technology School of Information Technology

Data Communications

Assignment: Stage 2

Report due:Stage 2 due week 11 (6:00pm, Friday 24th May 2018)

Marks:    25% of final assessment

Group size:1 or 2 students

Aim

To design and develop a file transfer program utilisingUDP socket-based communications between two networked PCs. The program should implement the RDT Stop and Wait(Idle RQ) protocol for flow control and a time out/ repeat sending, for lost or delayed transmissions to allow a file to be transferred from a client to a server.

Basic Requirements

1. The text file transfer program written in Stage 1 is to be extended to include an RDT Stop and Wait error scheme. To implement the RDT Stop and Wait protocol, the file must be transmitted in frames of data with the necessary fields for frame de-limiters, frame number and a frame check sequence. The appropriate control characters according to ASCII should be used for error control and messaging (ACK & NAK), frame de­limiters (STX, ETX) and link management functions (EOT). (See https://www.asciitable.com/)

The format of the frame should be:

2. The program will build on the program developed in Stage 1. The client computer will ask the server to send a copy of a file to the client. The name of the file is to be sent to the server and the server asked if it has a copy. If it has, then the transfer starts, if not the server responds that it does not have the file and asked for another file nameor to terminate the connection. The file is sent by the server in packets using RDT Stop and Wait protocol. The file is to be of only ASCII characters (no binary files). The version of java will delete the transmission of strings for 0% of strings sent at present. This rate of lost is to be altered to 20% once a timeout system has been implemented. That is if there is a delay in an ACK coming back, due to a lost packet (string), then the packet must be retransmitted. This retransmission must be shown on the server’s screen. In RDT Stop and Wait if the server receives an ACK character, from the client it will transmit the next block. If it receives a NAK character from the server indicating the previous block has an error and another copy is needed. So if either a time out or an error in a block occurs then the block must be retransmitted. In part 1 you noted that the characters could be changed to #. To detect these errors then you will need to implement an error checking system. This should take the form of a total of the character’s ASCII numbers sent in the block (mod 128). The major change here is that the file contents are transmitted a line of characters at a time in frames. The value of N, currently set for­only the server, will need to be set for both the server and client in your program. There is 1 in N errors in characters sent. For test purposes this value can be set to about 400. You can experiment with this…
3. The server will send the first line of characters of the file in a frame. To assist the transfer there are functions called writeString()and readString(). You are required to use these functions in the transfer of these frames. The function writeString()has abuilt in failure rate of 20%. When client computer receives a complete frame, itshould first display the received frame and then check the frame for errors by looking at the FCS (frame check sequence). The FCSshould be calculated using 1’s compliment binary addition of each character in each frame. It is an8-bit (1-byte) checksum.
4. If there are no errors then an acknowledgment character (ACK) will be returned to the server computer and the client computer will store the frame in the file that has just been created. Upon receipt of the ACK, the server computer will then transmit the next frame. ACKs are sent in frames.
5. Should an error be detected, i.e. the received FCS byte does not equal the expected FCS byte, the client computer would return a NAK to the server. If the server receives a NAK, it will re-transmit the frame.
6. As some frames will fail to be sent (20% will fail) then the sender will not receive an acknowledgement back for it. In this case a timeout function at the sender’s end should detect the late arrival of the ACK and resend the frame.
7. This process of sending, checking and storing frames should continue until the complete file has been transmitted and received without error. Upon receipt of the final acknowledgement, the client computer should transmit an EOT (eg. ETX) character to the client to terminate the connection.
8. The program should implement both the timeout and error functionality as required by the RDT Stop and Wait protocol. The timer should run it it’s own thread to ensure accurate timing.
9. Note that since the ACKs are being sent using writeString() they too can be lost. This may lead to duplicate copies of a frame being sent. Both ACKs and Frames will need to be numbered with a “0” or a “1” alternatively to detect the duplicate transmissions.

Extensions (Optional)

An interface may be developed for the program that will display the frame number, frame contents, acknowledgment messages and the FCS as well as the line control information on both the source and destination computers. Windows can also be used to display this information.

Submission

Submissions consists of two parts:

1. An electronic submission consisting of the software, report and labs 5-10 (details below). Due 6:00pm, Friday 24th May 2019(end of week 11) through
2. A physical copy (print-out of the report and a demonstration of the software) in your normal lab session in week 12.

You will submission on-line (Canvas) will be a .zip file containing the following items:

1. A cover sheet including
   • The unit code,
   • Unit name,
   • Student ID(s)
   • Student name(s)
2. A group report (1 or 2 students)containing:
   • an introduction
   • the design of the structure of the frame
   • the modular structure of your program
   • a description of the protocols used – RDT Stop and Wait
   • the extension options implemented
   • conclusions
   • for a 2-person team: an attribution section indicating who did what. This will be used to apportion marks to individuals within 2-person teams.
     This report should be approximately 5 pages long; 6 with the cover sheet.
3. The source files (.java) of your software.
4. Scans of labs 5-10 initialed or signed by your tutor for each member of the team.Individual marks will be given for these reports.
5. If you are using 3^rd-party libraries, dlls, BlueJ project files, packages or compiled components in your software, include them in the .zip file.

The report you will hand to your tutor (at the demonstration) will include:

• A print-out of items 1 and 2 of your submitted report
• You do not have to print out scans of your lab sheets or the source code of your software.

Assessment

Assignment 2 is worth 25%, but the marking details will be out of 100.

• Basic file transfer program with FCS, usableinterface, appropriately documented code and use of appropriate ASCII characters –up to 40 marks, adjusted for the amount of work done by each student.
• Display of frame transfer –up to 10 marks
• Options – up to 10 marks
• Report — up to 15 marks
• Lab reports (individual) – up to 25 marks

The maximum mark for this assignment is 25% of the unit assessment.

Note:

All reports are to be submitted through Canvas. A hard copy is to be handed to the tutor at the time of the demonstration (week 12 lab).

No marks will be given if the program has not been demonstrated to the tutor or if the assignment has not been submitted to Canvas.