answers.txt

# Fill in your name, student ID, and email address in this file.
# If you are working in a team, fill out the information for both team 
# members.

# SUBMIT THE LAB ONLY ONCE (from only one partner). This file will be
# automatically parsed in order to give both team members credit for the
# lab.

# You need to fill in the EXERCISE sections describing your solutions
# for Tasks 1, 2, and 3, as well as write the corresponding code.
# If you did one or more extra credit problems, indicate which one in the
# appropriate section below (remove the # sign first). If you have any other
# information you'd like us to know, please add it at the end of the file.

# Partner 1
Name: Peter Chang
Student ID: 703555852
Email: Tokenekie@ucla.edu

# Partner 2 (if you're working in a team)
Name: Matthew T. Miguel
Student ID: 903675486
Email: mmiguel6288@gmail.com

# EXERCISE 1: What method you used to make your peer download and upload
#    files in parallel?  (~1-3 sentences)

1) We used the pthreads.h library to implement multithreaded parallelization.
   There are predefined constants regarding the maximum number of threads that
   can be run at one time, and the maximum number of requests that can be 
   queued up in the case all threads are currently in use.

# EXERCISE 2A: What conditions did you find and fix that would have
#    triggered a buffer overrun bug?  (~1-3 sentences each)

1) Upload: Filename Overflow

      We fixed the buffer overrun bug regarding large filename requests from 
   bad peers. A bad peer could have sent our client a GET request containing a 
   filename larger FILENAMESIZ characters, causing t->filename buffer to
   overflow. To fix this problem, we calculated the length of the filename
   within the RPC request to determine if there would be an overflow or not,
   terminating the connection if it would overflow.
   

# EXERCISE 2B: What other robustness problems did you fix?  (~1-3 sentences
#    each)

1) Download: Infinite File Size

      Set a max file size limit of 65536 for any file downloaded. Any download
   task that downloads more than 65536 bytes will have its connection dropped.
   Ideally, trackers should provide the size of the files tracked so that
   clients can take precautions agains infinite file size attacks.

2) Upload: Restricted Files

      To prevent malicious peers from trying to download restricted files
   outside our specified p2p directory, I simply had osppeer check to see if
   the file requested exists in the specified directory. If it is not there,
   then the requested file is considered restricted and the connection should
   be closed immediately.

3) Upload: Infinite File Requests

      To deal with infinite file requests, we rely on long-term scheduling
   techniques to limit the number of requests we can handle at any specific
   time. We only allow a very few number requests to be processed by a
   specified number of threads. All other requests are put on pending wait
   lists that will be called after each active thread finishes on a first-come
   first-serve basis.

4) Hanging Peers

      To deal with hanging peer connections, I used the select() function in
   my read_to_taskbuf() function to timeout unresponsive file descriptors.
   select() basically takes a set of read/write file descriptors and checks to
   see when a read/write action will not block. I can also specify a timeout
   delay so that when a certain time has passed and I am unable to read
   anything from the file descriptor, I simply timeout, return an error, and
   drop the connection.

5) Oversize RPCs (Popular Tracker Bug)

      The popular tracker had trouble communicating with the original osppeer
   because the RPC containing the peer list was much larger than TASKBUFSIZ,
   which meant that the RPC would not fit into one task buffer at once. As
   with the original osppeer, a call to read_tracker_response() on an oversized
   RPC would result in a "premature" closed connection because a single task
   buffer would not be able to hold the closing RPC tokens. We fixed this
   by calling read_tracker_response() multiple times and reading the entire
   oversized RPC into a dynamically allocated array.


6) File Integrity
   
      See Extra Credit section.

# EXERCISE 3: Describe the attacks you implemented for "evil mode".  Why
#    are they attacks?  (~3-10 sentences each)

# Extra credit problems
#Extra credit problem: none

1) File Integrity:

# Add any other information you'd like us to know below this line.

1) Performance issues regarding forking:

      Everyone seems to say that using forking is a big performance hit.
   Although we did not go this route, we originally planned to because we
   did not see how forking could be significantly slower than, say, threads
   if forking was normally done as fork-on-write. The whole reason people say
   that forking is slower is because we have to copy ALL the program data to
   a new process. But if we use fork-on-write, isn't this performance hit
   mitigated?