TCP/IP Lab Project: 5762 (2001-2)

TABLE OF CONTENTS

• NOTES
  1. Introduction
  2. General Rules
  3. Server Requirements
  4. Options and Exemptions
  5. Suggestions
• EDIT HISTORY

NOTES

1. Introduction: Your project is to write a TFTP server. Your entire grade is based on this project. Click here for more information on the TFTP protocol and how to use it at JCT. The document you are looking at describes rules for writing the project and how it is graded.

   [TABLE_OF_CONTENTS]

2. General Rules:

   1. Language: write the server in C or C++. Perl or other scripting languages are not allowed. For the time being Java is not allowed.

   2. Testing:

      1. We don't mind you writing the program as part of a team of 2-3 people. But each person will be tested by himself, and is required to understand the entire program, including what his partners wrote.

      2. The testing will be oral. There will not be any written exam in this lab other than the program itself.

      3. The student will have to bring a printout of his program, and demonstrate the running of his program.

         Each student will tested by the instructor of his section. Students cannot be tested by the other instructor without his instructors' permission.

   3. Due Date: all students are required to complete the project and be tested before Moed Alef of the exam period starts. By the time Moed Alef starts, you'll be done with this lab. You must make an appointment with your instructor to demonstrate your program and be tested. It may be possible to test some students during lab hours.

      Moed Alef starts 27/1/2002.

   4. Bonus Points: Some features are worth bonus points. That means that if you do not implement the features, you can still get 100 on your project. If you do implement the features, then we add the specified number of points.

      Although JCT will not give a student more than 100 for a course, bonus points can help if you lose points for other things.

   [TABLE_OF_CONTENTS]

3. Server Requirements: The server must do the following. Information about how many points are in square brackets, [].

   1. Transfer files without corrupting the file's data
      [if you don't do this, you'll lose about 25 points]

   2. Be able to handle files whose size are 0 or multiples of 512.
      [if you don't do this, you'll lose about 12 points]

   3. Record each packet that it receives/sends, either on the screen or in a file (do not use the syslog() function).
      [If you don't do this, you'll lose 10-50 points. It depends on how dificult it is to test what your program is doing.]

   4. Analyze a packet via structs and/or unions instead of just accessing elements of a char array. Click here for information on how to do this.
      [if you don't do this, you'll lose 10 points]

   5. You should use the ntohs(), htons(), etc. functions appropriately.
      [if you don't do this, you'll lose 10 points]

   6. Must use the 'n' versions of functions, if they exist, e.g.
      • strncpy() instead of strcpy()
      • snprintf() instead of sprintf()

      [if you don't do this, you'll lose 10 points]

      Buffer overflows are a very common way for crackers to break into UNIX systems. Using the 'n' version of functions minimizes the chances of that happening. If you want to read more about buffer overflows, try some of the following links:

      • StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks
      • A Look at the Buffer-Overflow Hack
      • Blocking Buffer Overflow Attacks

   7. Must be well documented. This includes comments and using #define constants instead of hard-coded numbers.

      NOTE: Many students program their servers using state transitions. In the past, they have simply assigned each state a hard-coded number. This makes it very hard for someone else to understand the program. If you use state transitions, use meaningful names.

      [Not doing this can cost you 10-20 points, depending on how hard the program is to understand]

   8. Must handle following errors:

      1. The client request to read a non-existent file.
         [If you don't do this, lose 5 points.]

      2. Timeout: if, in the middle of a transfer, the server does not receive a packet, it will terminate the transfer after a certain amount of time. Obviously, there is no timeout while the server waits for the next read or write request.

         There is an example of implementing timeouts.
         [If you don't do this, you lose 5 points.]

         If the server also retries, you get bonus points.

   [TABLE_OF_CONTENTS]

4. Options and Exemptions and other good news:

   1. Multiple Clients: If your server can handle more than one client at a time, we'll add 20 bonus points.

   2. Retries: above we mentioned that your server must handle timeouts. If it also handles retries, then we'll add 10 bonus points.

   3. Dallying: the RFC point 6 mentions "dallying" which means that the host which sends the final acknowledge will wait a period of time to see if the acknowledge was received. Implementing this will add about 5 bonus points.

   4. Modes: The RFC mentions 3 modes. Your implementation need only handle the 'octet' (binary) mode.

   5. Error Packets: Someone asked if the server has to acknowledge error packets that it receives. According to the RFC, error packets do not need to be acknowledged.

   [TABLE_OF_CONTENTS]

5. Suggestions:

   1. File I/O: I suggest that you use open(), read(), and write() for the file I/O instead of fopen(), fread(), and fwrite().
      fprintf() and fscanf() will almost certainly corrupt the file if it contains '%' characters (this has happened in past years!).

      open/read/write is the lowest level of I/O, which means that there is less unseen code and less to go wrong. Remember, regarding the file, your server is just a pipe; it does not care what the contents of the file are.

   2. Multiple Clients: if your server will be able to handle more than one client at a time, then you'll probably want to:

      1. use the fork() and/or select() functions. See the Related Functions page for more info.

      2. Use different sockets for listening to requests and actually transferring files. The RFC mentions this. This is similar to the accept() function for TCP; it returns a new socket descriptor for the session. This leaves the original socket free for listening to requests for connection.

   3. Related Functions: Click here for info on other functions that might be useful in programming this project.

   4. Stages of Development: I suggest that you develop the server a bit at a time and test each part. Here is one suggestion for stages of development:

      1. write a server that accepts requests, but does not actually transfer files. It should log the following info for each request:
         • type of request (read or write)
         • file name requested
         • IP and port of the client

      2. Transfer files that fit into one packet:
         • first, implement read requests
         • next, implement write requests

      3. Transfer files that are bigger than one packet
         • first, implement read requests
         • next, implement write requests

      4. Make sure that you handle various errors

      5. If you want to handle more than one client at a time:
         • when receiving a request, the server should create a new socket & transfer the file on that socket (leaving the first socket free to listen to new requests)
         • only then should you actually handle the rest of what is entailed in handling more than one client at a time.

   [TABLE_OF_CONTENTS]

EDIT HISTORY

2001/10/29 Nachum Danzig

Updated for new year and made minor textual changes.

2001/06/17, 23 Sivan 5761, Haim Roman

Added link to example of impelementing time outs.

2001/05/17, 24 Iyar 5761, Haim Roman

1. Specified the number of points for different parts of the program and different errors.
2. Updated the information and added links.

2001/05/15, 22 Iyar 5761, Haim Roman

Created this file

[TABLE_OF_CONTENTS]