CS536 TA Notes - Fall 2019

General notes:

09/19/2019 - Sruthi: My original Wednesday's office hour has been changed to 09/19 1:00 - 2:00 pm.

09/23/2019 - Sruthi: My original Wednesday's office hour has been changed to 09/25 1:00 - 2:00 pm.

10/10/2019 - Sruthi: My Friday's office hour of this week has been changed to 10/11 12:00 - 1:00 pm.

10/21/2019 - Tinghan: Because of some unexpected accidents, I cannot go to my PSO today. You may still go to the PSO and discuss with other students. If you have any further questions that you need to discuss with the TA, send me an email.

11/22/2019 - Tinghan: I will be a little late for today's office hour. It will be extended 30 min.

Labs:

Lab2:

09/19/2019 - To ssh into the escher and pod machines, the host names are escher[01-24].cs.purdue.edu, and pod[1-5]-[1-5].cs.purdue.edu

09/27/2019 -

• Please keep the server side connection open when it decides to drop a request but close the client side socket. When the server side closes its connection, select() is returning 1 (instead of -1) which is causing ambiguity at the client.
• The client, after timeout, will close the previous connection and open a new connection to the server after which it resends the request. It does so up to 3 times. So the re-sending of dropped request is done over a new connection (likely with new port number).
• The problem specifies that server should be executed with arguments
  % myftpd filesize blocksize timeout cli-ip cli-port
  and the client
  % myftp srv-ip srv-port dropwhen
  This won't work as myftp requires the server's port number (ephemerally determined at the server) and, at the same time, the myftpd requires the client's port number (ephemerally determined at the client). The attempt to prevent port number collision leads to a deadlock.The simplest solution around this is to have the client run as
  % myftp dropwhen
  without specifying the server's port number (and IP address). Instead, after receiving the first packet from the server through recvfrom(), the client checks who the packet is from to send back an ACK.

Lab4:

10/24/2019 - In problem 1.4, the client must include its own IP address as part of the payload. Since the client binds to INADDR_ANY, to obtain the client's IP address from within the program, use a combination of gethostname(), gethostbyname/getaddrinfo, and inet_ntoa(). Both gethostbyname and getaddrinfo return lists of IP addresses, but for the pod/escher machines, the hostname should map to only one IP address. Refer to the following program on how to use either. Here, when using gethostbyname() we iterate through the list of addresses, and when using getaddrinfo, we use just the first address, though getaddrinfo's result can also be iterated through.

Lab5:

11/09/2019 - For both problem 1 and 2, there are 3 ports related to each router (assume k): (1) routerk-port, which router-k uses to listen to UDP connection request fowarded by the previous router; (2) transit-port1, which router-k uses to listen to the app's message (for example, terve); (3) transit-port2, which router-k uses to foward the connection request or the app's message to the next router.

lab6:

11/19/2019 - In lab6, you may use the same program structure involving 2 processes (parent forking child) at the client as at the server using nanosleep() and SIGIO/SIGPOLL handler to take care of events. If you used ualarm() to raise SIGALRM at the client, no need to change.

11/20/2019 - For lab6, recent lab upgrades to Ubuntu make writing to /dev/audio infeasible without introducing CPU scheduling and IPC (inter-process communication) through hacks that impact audio playback quality. Instead, please use the library functions mulatopen(), mulawrite(), mulaclose() provided in /homes/park/pub/testaudio.c to play audio data received at the client from the server to the client's audio device. Utilize the example code provided in testaudio.c of how to use the library functions.