CS 450 - Introduction to Networking - Spring 2010 Homework Assignment

							                 CS 450 – Introduction to Networking – Spring 2010
                       Homework Assignment 3 – Pre Draft
                  Reliable Transport Over an Unreliable Medium

Due: ???. Electronic copy due at 1:30 P.M., paper copy at the beginning of class. ( Note:
     the paper copy must match the electronic copy exactly. )

Overall Assignment

      For this assignment you are to implement a subset of TCP functionality, specifically the
      implementation of a reliable transport mechanism over an unreliable medium. You will not need to
      support multiplexing / demultiplexing or congestion control.

Overall Architecture

      The overall architecture of this assignment is shown in the figure below:
The Transport Class

                                                       Transport

             double pctDrop, pctDelay, pctDupe, pctError

             static int connectionSocket

             int communicationSocket

             static boolean firstTime = true;

             Transport * static acceptConnection( int port ); // Server side

             int makeConnection( int IP, int port ); // Client side

             void percentDrop( double ); // sets the percentage chance of dropping packets

             double percentDrop( void ); // gets the percentage chance of dropping packets

             // Similar functions for percentDelay, percentDupe, and percentError

             int sendData( void *data, int nBytes ); // returns nBytes or less, incorporates garbler.

             int recvData( void *buffer, int size );

      Constructors and destructors will also be needed. Copy constructors, and assignment operators may
       also be needed.

      The acceptConnection method is run on the server side, by PacketMirror. The first time it is called it
       implements socket( ), bind( ), and listen( ), and stores the socket file descriptor in a static class variable
       for future reference. On every call, ( including the first ), it uses select( ) to determine if there is a
       request available on the connection socket.

           o If a new connection request is pending, then a new Transport object is created and returned to
             listen to this connection. ( The newly created Transport object performs accept( ) as part of its
             constructor. )

           o If there are no pending requests, then NULL is returned.

      makeConnection is run on the client side, to connect to a remote port. ( This functionality could also
       be implemented as part of a constructor. ) The return value is the error code returned by socket( ).

      percentDrop is overloaded as both a setter and a getter for the pctDrop variable, which should be a
       double in the range of 0.0 to 100.0 inclusive. Similar functions should be written for percentDelay,
       percentDupe, and percentError. Default values of all these variables is 0.0.

      The sendData function implements the garbling function, and then ( possibly ) creates an appropriate
       TCP packet and writes it out to the outgoing socket.

           o If there is no room available in the outgoing buffer window, then this function returns 0 and
             does nothing else. ( Alternatively if there is some room in the buffer but not enough, you can
             elect to accept for transmission as much data as you have room for, and return the number of
             bytes actually buffered for transmission. )

          o Otherwise the data is accepted, and copied into an outgoing buffer for transmission. This
            stored data is retained in its original undamaged state.

          o Whenever transmitting data, a random number is generated and compared against the pct
            variables. If it is less, then that particular error type occurs:

                    For dropped packets, no data is actually transmitted. A timer may be started as if the
                     packet had been transmitted.

                    For delayed packets the transmission does not occur immediately, but only after a
                     certain number of other packets have been transmitted. The intention is to generate out-
                     of-order packets resulting from slow versus fast transmission channels.

                    For duped packets, one copy is sent immediately, and another copy is sent after a few
                     other packets have been sent.

                    For error packets, the checksum is wrong, i.e. put in a random checksum value.

                    Only one error type can affect any given packet at the same time. The most accurate
                     approach is to define ranges based on the random R: ( R < pctDrop ), ( pctDrop ≤ R <
                     pctDrop + pctDelay ), ( pctDrop + pctDelay ≤ R < pctDrop + pctDelay + pctDupe ), etc.

Implementation of ( Multiple ) Timers

         The system call alarm( nSeconds ) sets a timer to send a SIGALARM signal to the process after
          nSeconds seconds. Setitimer( ) provides finer grain control and more options, and the cost of more
          complexity.

         Only one alarm can be set at any given time. If a process needs multiple alarms, it is the process’s
          responsibility to maintain a linked list ( or other structure ) of pending timeouts, and set the alarm
          for the earliest to occur. Calling alarm( ) replaces any pending alarms.

         The system call signal( ) defines a signal handler, i.e. it provides the address of a function to be
          called when the signal goes off. This method will probably need to be a static class member of the
          Transport class.

Server Operation and Details

         The syntax for running the server shall be:

             packetMirror [ TCP_port pctDrop pctDelay pctDupe pctErr ] ...

             o TCP_Port is the port to listen to for new TCP connections. Default value is 60607.
             o The default port to listen to for incoming UDP packets is one higher than the TCP port.
             o The pct arguments are the percentage chance that a given error type may occur. ( Floating
               point values in the range from 0.0 to 100.0 inclusive. )
             o You may support additional arguments to appear after the ones shown here, provided they
               are well documented in your README file.

         The server shall ( ultimately ) perform the following tasks:
             1. Create two sockets to listen for TCP connection requests and incoming UDP packets
                respectively.
             2. Use select( ) to determine which socket(s) have data available.
                     If new TCP connection requests are present, establish new connections and add the
                        new sockets to the list of sockets to listen to.
                     If new messages have arrived from clients, read the messages and respond
                        accordingly:
                             Add a unique ( unsigned long ) serial number to the data that was received,
                                and send the resulting packet back to the original sender, using the same
                                protocol by which the message was received. These numbers should begin
                                at 1 and increase by 1 each time a new packet is processed.
                             Overflow is not a problem for the server, but might need to be considered in
                                the clients.
                             You may include additional information if you find it helpful, but you must
                                document any additions completely in your readme file.
             3. Repeat step 2 forever, or until something stops the program.
             4. Close all sockets when exiting.

Client Operation and Details

         The syntax for running the client shall be:

            protocolAnalyzer remoteHostName [ nPackets ] [ TCP_port ]
                  [ pctDrop pctDelay pctDupe pctErr ]. . .

                The remote host name is the name of the computer running the server program.
                nPackets is the number of packets to use for testing each protocol.
                TCP_port is the port on the server that is listening for TCP connection requests, default
                 60607. The default port for the server to listen for UDP packets is one higher than the TCP
                 connection request port.
                The pct arguments are the percentage chance that a given error type may occur. ( Floating
                 point values in the range from 0.0 to 100.0 inclusive. )
                You may support additional arguments to appear after the ones shown here, provided they
                 are well documented in your README file.

         The client shall ( ultimately ) perform the following tasks:

             1. Contact the server to establish a new TCP connection.
             2. Send the server nPackets packets via TCP, each containing a unique unsigned long serial
                number, starting at 1 and incrementing by 1 with each packet. Make note of the time at
                which each outgoing packet is sent.
             3. Listen for packets being returned by the server. For each packet received, keep track of
                how long it took to make the round-trip, and what if any errors occurred. ( Missing packets,
                duplicated packets, packets out of order, etc. )
             4. Repeat steps 2 and 3 using the UDP protocol.
             5. Report all results to the screen, and close down all connections.

Socket Details

         The server needs to perform the following tasks regarding sockets:
             1. Call socket( ) to create a socket for accepting TCP connection requests. The type should be
                 AF_INET and SOCK_STREAM.
              2. Call bind( ) to assign a name ( port number ) to this socket.
              3. Call listen( ) to mark this socket as ready to accept connection requests.
              4. Call accept( ) to create new sockets based on connection requests received on the socket
                 created in step 2. All further communications with this client will be through the new
                 socket created by accept( ).
              5. Use read( ) and write( ) to communicate with this client via the newly created socket.
              6. Note: You can use select( ) to determine which socket(s) have data available to be read.
                 Note that the data structure sent to select gets modified, so you need to set it up again
                 before each call to select.
              7. Call close( ) when necessary to close down the socket.

          The client needs to perform the following tasks regarding sockets:

              1. Call gethostbyname( ) to lookup the IP address of the server.
              2. Call socket( ) to create a socket for communications with the server.
              3. Call connect( ) to request a connection from the server.
                     Connect will need to know the name used by the server in the bind( ) step listed
                        above.
                     Connect will fail if the client tries to connect before the server is ready. Check the
                        return value, and use a busy loop ( with a sleep( 1 ) call in it ) if connect fails with
                        errno equal to ENOENT.
              4. Use read( ) and write( ) to communicate with the server.

Evolutionary Development

It is recommended that the program be developed in the following order, making sure each step is working
before beginning development on the next step:

   1. Develop initially with the client and server running on the same computer, or on two adjacent
      computers in the computer lab.
   2. Develop simple server and client programs that create sockets and establish basic communications.
   3. Implement the requested tasks for the TCP protocol only, and let the server assume there will only be a
      single client. Select( ) is not needed in this case.
   4. Modify the program to implement the required tasks using UDP only. Select( ) is still not needed.
   5. Modify the program to handle TCP and then UDP sequentially. At this point you will need to either
      implement select( ) or figure out some other method for the client to notify the server when to switch
      protocols.
   6. Finally modify the server to handle multiple simultaneous TCP connections intermixed with arbitrary
      UDP packets. Select( ) will definitely be needed at this point
   7. Work out any remaining bugs so that the client-server system correctly solves the overall problem.
   8. Optional Enhancements – See below.

Data Packet Format and Contents

   o At a minimum, packets going from client to server will need a single unsigned long integer, and
     packets going from server back to the client will need two unsigned long integers, ( one created by the
     client and echoed back, and the other generated by the server. )
   o You are welcome to add any additional data fields you wish, provided they are well documented in
     your readme file.
           o In particular, you probably want a mechanism for the client to notify the server that the job is
             done and that the server should close up and quit.
           o The client may also want to inform the server of the total number of packets to expect.
           o The client could store the time at which each packet was originally transmitted in the packet
             itself, instead of trying to remember it in a separate data structure. The problem is that if
             packets get lost or garbled, then that information could be lost.

Required Output
          All programs should print your name and CS account ID as a minimum when they first start.
          Beyond that, this program should print the results as described above, suitably formatted.

Data Analysis

Once you have the program working, ( or possibly before ), use it to analyze the differences between TCP and
UDP performance and reliability.
      You will want to analyze the protocols under different conditions, ranging from the client and server
       running on the same computer to having them as “far apart” as possible in a networking sense.
      Can you determine a difference when one or both of the computers is communicating wirelessly, as
       opposed to using hard-wired connections?
      Are there certain environments that increase the differences between the two protocols?
      How does the load level on the server affect results? I.e. does it make a difference if the server is
       trying to handle TCP and UDP packets at the same time, and/or multiple simultaneous TCP
       connections?
      Average round-trip time is only one possible timing metric. You may also want to examine the
       maximum round-trip time ( for a non-lost packet ) and/or the variance in round-trip times.
      You may need to do some statistical analysis on the data you collect. Excel has some statistical
       analysis tools, or you can use any other program you wish. In this case you will probably want to have
       your client ( and possibly also the server ) record data into a file for external analysis, and only report
       summary statistics to the screen.

Other Details:
          A makefile is required, that will allow the TA to easily build your program. As always, you are
           free to develop wherever you wish, but the TA will be grading the programs based on their
           performance on the CS department Linux machines.
          ( The makefile may be omitted if compilation is straightforward, and documented in README. )
What to Hand In:
   1. Your code, including a makefile if needed, and a readme file, should be handed in electronically
      using Blackboard.
   2. The intended audience for the readme file is a general end user, who might want to use this program to
      perform some work. They do not get to see the inner workings of the code, and have not read the
      homework assignment. You can assume, however, that they are familiar with the problem domain
      ( e.g. computer networking. )
   3. A secondary purpose of the readme file is to make it as easy as possible for the grader to understand
      your program. If there is anything special the grader should know about your program, be sure to
      document it in the readme file. In particular, if you add any additional command-line parameters or
      special fields to the data packets or do any of the optional enhancements, then you need to document
      what they are and anything special the TA needs to do to run your program and understand the results.
   4. If there are problems that you know your program cannot handle, it is best to document them in the
      readme file, rather than have the TA wonder what is wrong with your program.
   5. Make sure that your name appears at the beginning of each of your files. Your program should also
      print this information when it runs.
   6. The readme file must specifically provide direction on how to run the program, i.e. what command line
      arguments are required and whether or not input needs to be redirected. It must also specifically
      document any optional information or command line arguments your program takes, as well as any
      differences between the printed and electronic version of your program.
   7. If there are problems that you know your program cannot handle, it is best to document them in the
      readme file, rather than have the TA wonder what is wrong with your program.
   8. A printed copy of your program, along with any supporting documents you wish to provide, ( such as
      hand-drawn sketches or diagrams ) should be handed in at the beginning of class on the date specified
      above.
   9. Make sure that your name and your CS account name appear at the beginning of each of your files.
      Your program should also print this information when it runs.

Optional Enhancements:
      It is course policy that students may go above and beyond what is called for in the base assignment if
      they wish. These optional enhancements will not raise any student’s score above 100 for any given
      assignment, but they may make up for points lost due to other reasons. Note that all optional
      enhancements need to be clearly documented in your readme files. The following are some ideas, or
      you may come up with some of your own:
       Compare the results that you attained with those of other network analysis tools. Document
           completely what other tools you used for comparison. ( Where to get them, how to use them, etc. )
       Anything else you can think of – Check with the TA for acceptability.