ISP: Assignment 4

The assignment is due at the beginning of class on Wednesday, November 17. Please follow the instructions in submitting your assignment.

1. A common network programming problem is that a thread waits for messages, blocking on a read(). At some point, another thread decides that the result is no longer needed (e.g., another socket has canceled the request that triggered waiting for input). Describe a way of solving this problem and see if your solution works on Linux as well as on Solaris. Provide a minimal program that demonstrates your solution.

2. How accurate is the timing of sleep() and select() for Solaris and Linux? (You can also do the equivalent for Windows NT.) Measure this while the system is idle and while another process is doing a CPU-intensive computation (e.g., solve some math problem). Below is code for the BeOS operating system to give you an idea of the code structure.

   #define SNOOZE_TIME 150000
   
   int main()
   {
     bigtime_t start, elapsed_time;
   
     /* set own thread priority */
     set_thread_priority(find_thread(NULL), 120);
     for (;;) {
       start = system_time();
       snooze(SNOOZE_TIME);
       elapsed_time = system_time() - start;
       printf("%Lu microseconds late\n", elapsed_time - SNOOZE_TIME);
     }
   
     return 0;
   }
   

3. Network time broadcaster: Periodically multicast the current time, in timeval format (two network-byte-order 32-bit integers), from one or more machines. Then, receive these multicasts using a program running on a different machine, and gather statistics on time dispersion compared to other machines on the local network. You can use the transmissions generated by the programs of other students to increase the number of samples. The transmission and reception can be done by a single program.

   Time dispersion is defined as measures of spread for the time, e.g., as variance, time difference (difference to slowest and fastest clocks) or average difference with respect to the local clock.

   You should multicast the time every 30 seconds. You do not have to worry about round-trip computation; this exercise just provides a rough notion how closely the time between machines is synchronized. Use the multicast address 239.1.2.3, a TTL of 16 and port 5678. The port number should be user-configurable with a -p parameter on the command line. If you need to do testing "undisturbed" by others, use port your uid + 1024.

4. Name resolution: using the resolver rather than gethostbyname(), find out how many dictionary words are already registered as domains in .com and how long it takes to resolve them successfully or to fail. Pick 250 consecutive words, starting at a random offset, from /usr/dict/words or any other appropriate English-language dictionary. Provide statistics for the distribution of success and failure times separately, in increments of 50 ms.

   You can download resparse-1.3 and take a look at its documentation, if you need it (but you can solve the problem without this).

5. Due Friday, November 19, 1999, 5 pm

   Sun RPC: Write an RPC-based calendar client and server. The client should be able to add and query appointments. Appointments consist of a start time, end time (both as Unix time) and a text string. Queries should be by time (all appointments that span this time) or string prefix match, so that a query for "Dinner" matches "Dinner with Joe" and "Dinner at home". Measure the request latency and find out how much this latency is due to marshalling. (In the next assignment, you will do something similar for Corba.)

6. Threaded tftp server: The Trivial File Transfer Protocol, documented in RFC 1350, is a very simple UDP-based file transfer protocol that is often used for installing boot images or updating software in embedded systems. Your task is to write a threaded read-only server. Thus, you only need to implement the RRQ, DATA, ACK and ERROR op codes. Only the octet mode needs to be implemented.

   You can use the tftp client to test your server.

   The default TFTP port of 69 is not accessible to user programs, so your server should be configurable (using a -p command line option), with a default of port 69.

   The server should be able to handle several requests at once, with requests from each client getting its own thread. (You may use as many threads as you deem appropriate.) Be careful about where subsequent requests are sent to. Initial time-out is one second. Sending of multiple files is handled by the client; to the server, this just looks like requests from several clients.

   Since you are using UDP, you can ignore the section labeled Internet User Datagram Header [2]. In other words, you do not have to be concerned with generating checksums.

   Use the syslog facility to log requests.