Docstoc

project2

Document Sample
project2 Powered By Docstoc
					CS455 Introduction to Computer Networks, WSU Vancouver



             Project : Simulate Pseudo-TCP with UDP

In this project you will create a Pseudo-TCP (PTCP) server and Pseudo-TCP client using
UDP sockets, implement the reliable data transfer protocol of TCP (more details refer
lecture slides page 70-78 of CS455-Transport-A.ppt or textbook). However, connection
establishment/release, flow control, congestion control is not necessary.
Recall that UDP sockets are connectionless, and do not guarantee the delivery of packets.
TCP sockets are connection oriented and provide reliable data transfer.
Your PTCP client and server implementation will be using the UDP sockets available and
provide reliability as in TCP. For example, you will read from a file of size greater than
10 MB and send it as multiple packets of size 100 bytes (e.g., MSS = 100) each to the
arbitrator code provided to you. YOU SHOULD RECORD DOWN ANY CHANGE
EVERY TIME YOU CHANGE THE CODE OF ARBITRATOR. ARBITRATOR
TAKES THE PACKET FROM THE CLIENT AND SENDS IT TO THE SERVER. IT
WILL RANDOMLY SELECT PACKETS FROM THE FLOW AND DROP IT. IT
COULD ALSO SEND THE PACKETS IN OUT OF ORDER. IT ALSO TAKES THE
ACK PACKETS AND DROPS THEM RANDOMLY AND COULD ALSO
REORDERS BEFORE SENDING BACK TO THE CLIENT. Each packet sent will have
a sequence number and you will keep track of the sequence numbers of the packets sent.
You need to maintain a timer to keep track of the sent time for the packets, see when the
timer expires and retransmit the unacked packets. The client will receive the
acknowledgment packets (ack) and do the necessary updating depending on the policy in
use. For the reliable data transfer protocol, you need to maintain n number of packet
details for retransmission. It will print the sequence number of the packets it sent and also
the sequence number of the packets that were acknowledged.
The client will send a file to the server in N(e.g., constant window size) packets of size
100 byte (e.g., MSS=100, it should be an adjustable parameter) each. It will receive the
acks and decide the next packet to be sent. The server receives the packet and sends an
ack as required. Print the sequence number of the packets. It will print the sequence
number of the packets it received. Both window size N and MSS should not be hard-
coded, in other words, they are adjustable parameters. In each experiment, you may keep
them constant for simplification (e.g., congestion control is NOT necessary).
The purposes of this project: to become familiar with TCP’s reliable data services and
UDP protocols. Learning file-handling operations is also a part of this project.

Logistics
You need write this program in C under Linux.
What to turn in:
  1. Printed listings of your code, Makefile, and README files are to be turned in
  during class on the due date.
CS455 Introduction to Computer Networks, WSU Vancouver

       As in previous projects, the README file should contain complete instructions
       for compiling and running, and report on some experiments that you ran and your
       insight into the additional features required.
   2. All files are also to be submitted electronically by using the “submit” command
       you have used in the Project 1 submission, prior to midnight (11:59PM) on the
       due date

During the week following the due date, if necessary, you will each need to schedule an
individual appointment with the TA to demonstrate your TCP implementation and to
describe its operation.


Specifications
You are to create an Pseudo TCP client that
   1. Takes input value of the port of arbitrator to send the file.
   2. Opens a file to send and reads it in blocks of MSS bytes.
   3. Opens a connection to the arbitrator.
   4. Send N number of packets after adding the Sequence number to the packets. The
   sequence number starts at 1. (instead of random for simplification)
   5. Gets the acks and does the necessary actions. Keeps track of all the packets that
   were dropped.
   6. Implements the required timers, and maintains an adaptive time-out interval. Upon
   time-out, it will have to retransmit the required packet(s).
Your Pseudo TCP server does the following
   1. Takes input value of the port on which it will receive the file from arbitrator.
   2. Waits on a specific port for a file from a client.
   3. Accepts a connection and gets the file in bytes of MSS.
   4. Reads the sequence number and sends an ack back.
   5. Keeps track of the missing packets and writes to the file in proper order.
   6.Keeps track of the out-of-order packets and, using a buffer, stores them.
   7. Has a fixed buffer size of N(the window size). YOU CANNOT STORE ALL THE
   PACKETS AND THEN WRITE TO A NEW FILE AT A TIME.
Acknowledgement for the packet should be cumulative (refer to slides 70-78)!


Development Hints
      Start with basic UDP and try implementing one of the methods with server and
       client on the same machine
      Implement the reliable data transfer without the arbitrator in between.
CS455 Introduction to Computer Networks, WSU Vancouver


      Implement the reliable data transfer using the arbitrator in between.
      Try for Pseudo TCP server and Pseudo TCP client on different machines.

Test your program
Test the efficiency of your Pseudo TCP server and client under different network
environments. The client will send a file to the server in N(e.g., constant window size)
packets of size 100 byte (e.g., MSS=100, it should be an adjustable parameter) each.
      Test the total packet transmission time, including packet retransmission, under
       different ACK random drop rate (ACK is from TCP server to TCP client) 10% to
       90% with 10% incremental step. The tips for modifying arbitrator to adjust the
       ACK drop rate are given in the appendix. REMEMBER YOU should have
       detailed record of what you have changed in arbitrator.
      Adjust the data drop rate (Data is from TCP client to TCP server) in arbit.c from
       10% to 90% with 10% incremental step. Record down the total data transmission
       time, including data retransmission time.
      Plot the packet transmission time vs. different ACK drop rate and different data
       drop rate in a 3-D mesh plot. Please submit this graph in your project report.


Advice
   1.The work YOU submit MUST be the result of the efforts of yourself. Do not copy
   code from others. See the course syllabus for the punitive actions that result from any
   cheating/plagiarism violations.
   2.Start early. This will help you to debug your application if your face some
   problems.
   3.Ask questions EARLY. The TA is available to help you several hours per week, but
   not for extensive help at the last minute.

Grading
   To summarize, grading will strictly follow the policy below:
    Totally 100 points, late submission will cause 20% penalty each day;
    75 points of the grade will be for working code. Your demonstration of your TCP
   server and Client to the TAs will be part of this grade.
    15 points for the README file, test report file and make file.
    10 points of the grade will subject to your code’s organization & modularity,
   readability & consistency, and robustness (bug-free). In other words, these points are
   rewarded according to your programming skills.
    If the program can not be compiled or run in Linux, 0 points will be awarded;
    If the source code is stolen from Internet, 0 points will be awarded;


Appendix: How to use the Arbitrator.
CS455 Introduction to Computer Networks, WSU Vancouver

The Arbitrator code takes the machine on which the client runs and the machine on which
the server is running as input values. To run this you must first compile the code as
                                   cc –o arbit arbit.c
             To run the code type arbit <client machine> <server machine>


                                 8600                       8500
                Client                    arbitrator                      Server
                                 8650                       8550


The arbit code works as follows. Arbitrator opens different processes to handle the packet
transmissions in both directions. It listens on port 8600 and 8550 for the information.
Once it gets some packets on port 8600, it decides if the packet should be forwarded or
dropped. If it has to be forwarded it just sends it back to the port 8500. YOU CAN
CHANGE THE DECISION POLICY TO TUNE THE DROP RATE. Your client will
send packets on port 8600 and your server will receive them on port 8500. The server
creates an acknowledgement for the packets and sends it back to the arbitrator on the port
8550. This packet is sent back to your client on port 8650. The client decides the next
packet to be sent based on the implementation. The client code needs multi threading
capability or else it won’t be able to send and receive packets at a time (remember the
recvfrom call is blocking receive).


EMail the TA or go to her office if you have any problems with this code. Try not to
change this code. If you have to change it write what all changes you had to make in the
comments file.

TIP-I: If you have binding errors change the port numbers in #define and it should work.

TIP-II: The specific code lines of arbitrator you need to change are from L127 to L148
(Client-to-Server direction) and from L227 to L247 (Server-to-Client direction). “Ran” is
a random number generated inside the while-loop. The sanity check on the variable of
“ran” is to decide whether to forward the packets or not. YOU can use the modulo
operation to fit the sanity check into different drop rates.

IF YOU HAVE TO ABRUPTLY CLOSE THE PROGRAM, MANUALLY CHECK IF
ALL PROCESSES ARE CLEANED.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:8
posted:3/5/2010
language:
pages:4