A: monica.cs.rpi.edu has a tftp server running on the default tftp port. There are 3 files you can read, named small, medium and large. You can't "put" any files. Here is an example session showing how to turn on trace mode (shows each datagram sent and received):

/home1/b/hollingd tftp monica.cs.rpi.edu tftp> ? Commands may be abbreviated. Commands are: connect connect to remote tftp mode set file transfer mode put send file get receive file quit exit tftp verbose toggle verbose mode trace toggle packet tracing status show current status binary set mode to octet ascii set mode to netascii rexmt set per-packet retransmission timeout timeout set total retransmission timeout ? print help information tftp> trace Packet tracing on. tftp> verbose Verbose mode on. tftp> binary mode set to octet tftp> get small getting from monica.cs.rpi.edu:small to small [octet] sent RRQ <file=small, mode=octet> received DATA <block=1, 512 bytes> sent ACK <block=1> received DATA <block=2, 512 bytes> sent ACK <block=2> received DATA <block=3, 0 bytes> Received 1024 bytes in 0.5 seconds [16384 bits/sec] tftp>

A: Yes! (and it makes things much simpler and probably more portable).

A: No! Too much of this on Project 2!!! You many not share code in any way. You can discuss the project all you want, but do not show your code to anyone!!! Not convinced? Consider this:

Top 5 reasons to do the project yourself:

5. Cause Dave said "please".

4. Dave has a fancy program-comparison checking program. I think he lifed it from someone else...

3. Dave is in a bad mood, he is stuck using Windows98 until he gets a real computer.

2. Dave is known across campus as "Mr. Flunk-the-Cheaters"!

1. You might actually learn something useful.

A: No! I don't think any clients support it!

A: There is something in the Solaris tftp client that refuses to use port numbers greater than 32767 (the code is probably treating the 16 bit port number as signed, which is a mistake!). Use monica for running the tftp client or try requesting a specific port number (less than 32767)

A: You need to use the POSIX signal handling routines (sigaction() instead of signal()), and to specify that you want SIGALRM to interrupt, not to restart slow system calls. Check sections 5.8 and 5.9 in the text for more information.

This works for me:

/* ALARM handler does nothing */
static void alrm_handler( int sig) {
}

    ...
   struct sigaction act,old;


   act.sa_handler=alrm_handler;
   sigemptyset(&act.sa_mask);
   act.sa_flags=0;
   sigaction(SIGALRM,&act,&old);

   /* SIGALRM will now interrupt slow system calls */

A: I haven't found any use for this error code either. I assume this was included when "mail" transfer mode was supported (if it ever was).

A: If there is an error while writing the file, you should send back an error message - this one sounds reasonable. I don't expect you to actually determine the exact cause of an error while writing to a file, so you could assume the cause is that the disk is full. The important thing is that you notify the client that something went wrong and the file was not (completely) saved.

A: OK:

• For a RRQ, if you can't open the file you need to send either a 1 (file not found) or 2 (access violation). I don't care if you determine the actual cause of the open failure, either error code is fine.
• If the open fails for a WRQ you should return 2 (access violation).
• If the open for a WRQ was OK, but later one of the writes fails, you should return 3 (Disk full) - you don't need to determine if this is really the problem.
• Any unknown opcode should result in an error code 4. If you decide not to overwrite files (when receiving a WRQ) you can return an error code 6 (file already exists) - but you can overwrite if you want to.
• There is no condition I can think of that should result in error code 7 (no such user).

A: Yes, although if you really did the whole finite state machine thing, I will make sure you understand every line (and doing so is probably more work than simply writing your own server).

A: OK, but DISCLAIMER: this is the general idea, but there are many details not included. For example, I don't say what to do if you get something you are not looking for, or how long to wait before retransmitting, etc.

• Create and bind a udp socket, print out the port number.
• wait for a request (recvfrom on the "well known" udp socket).
• You can handle concurrency anyway you want, one way is to now fork off a child to handle this request.
• look at the opcode (first 2 bytes as a network byte order short) in the request. If the request is:
  • RRQ
    • Create a new udp socket to use with this client.
    • get the filename from the request and try to open the file. If the open fails send back an error (file does not exist) and we are done with the client. NOTE: see later section on lingering.
    • open succeeds - read first 512 bytes, package up as a TFTP message with block set to 1 and send it.
    • while (last block size == 512)
      • wait for ACK for last data sent. don't wait too long.
      • if timeout (no ACK) and total time is not too long, resend the data. If time too long - we are done with the client.
      • Got the ACK - now read the next 512 bytes of the file
    • transaction complete - close the file. done with client (see note on lingering).
  • WRQ
    • Create a new udp socket to use with this client.
    • get the filename from the request and try to open the file for writing. If the open fails send back an error (access violation) and we are done with the client. NOTE: see later section on lingering.
    • open succeeds : send an ACK #0 to the client.
    • while (last block rcvd == 512 bytes of data)
      • wait for next bock of data from client. don't wait too long.
      • if timeout (no DATA) and total time is not too long, resend the last ACK. If time too long - we are done with the client.
      • Got the DATA - write to the file. If write error, return a error to the client (disk full) and consider the client done.
      • Send ACK for data just received.
    • transaction complete - close the file and done with client (see note on lingering).