Project for EECS122 - Spring 05

Time Line:

    4/13:  Project Description is out
    4/22: The document that describes your API is due (see project description)
    5/05:  Project due 

Contest Results are Out

The projects have been really awesome. Good job!
Here are the results of the contest (listing of clients with under 40 seconds download time for portland.mp3).

Rank

Download Time
(for portland.mp3)

Team Members

0.

35.03 s

TCP developers :)

1.

36.65 s

Noaa Avital, Jike Chong

2.

37.66 s

Joshua Chang, Ranjeet Jhutti, Jeffrey Woo

3.

38.03 s

Maung Y. Aung, Joo Young Lee

4.

38.27 s

Guang Li, Dawson Tan, Tina Tung

5.

39.16 s

Hy Thai, Yu Lisa Wu

6.

39.44 s

Whitney Chiu, Kan Shun Sit

 

Comments:

    5/04:  I have noticed that many groups have been misunderstanding the semantics of slow start. CWND is not doubled at
                the receipt of every packet, but at the receipt of CWND packets. To achieve this, CWND is incremented by one
                with the receipt of every packet (not doubled!), and thus after CWND packets, the window size doubles. Here is
                an example of what your slow start should look like:
               - client sends request for ADU 0 (CWND=1)
               - client receives PN#0 from server, slides window, and increments CWND by 1. Since CWND was 1 before, it has now doubled.
               - client sends request for ADU 1 and 2 within the same packet (CWND=2)
               - client receives PN#1, slides window, and increments CWND by 1.
               - client sends a request for ADU's 3 and 4 (CWND=3)
               - client receives PN#2, slides window, and increments CWND by 1.
               - client sends a request for ADU's 5 and 6 (CWND=4), and so on.
             Note that when slow start is followed, two new packets are requested for every packet received. Do not hardcode this
             behavior into your client -- it should do it automatically if you are incrementing your window properly. The main difference
             between slow start and congestion avoidance is how CWND is incremented. Whereas in slow start, CWND is incremented by
             one with the receipt of each packet (thus doubling after the receipt of an entire window), in congestion avoidance, CWND is
             incremented by one only after the receipt of an entire window's worth of packets.
             In summary: if your requests look like (0), (1, 2), (3, 4, 5, 6), (7, 8, 9, 10, 11, 12, 13, 14), etc.,
        then you are not doing slow start correctly. If they look like (0), (1, 2), (3, 4), (5, 6), ..., then you are.


    5/04:  When you are done, please email the project and final design report to daspek *at* gmail.com. Be sure to include
               a list of all your group members' names and SID's.
    5/04:  The interview signup sheets have been posted outside of Prof. Walrand's office. Sign up for a time that all of
                your group members can attend.
    5/04:  To check the md5sum of the files you transfer using WebTP, download this. **use the 'gmd5sum' command.**
                It's compiled to run on the sparc machines. If you want the source, get it here. 
    5/04:  You can now download the server source code by requesting WebTPserver.java, if you think it will help you.
    4/29:  Remember to make your client robust. Use the newly added servers below to test your client as you finish it.
    4/28:  Guidelines for the final report (due Thursday, May 5) are here
    4/24:  Marghoob will hold extra office hours 2-3p on Tue, Apr 26 in 197 Cory
    4/23:  You may start testing your code on the servers listed in the 'Servers' section below
    4/18:  The due dates for both the API design and the project have been pushed back to 4/22 and 5/05, respectively

 

Servers:   

Host

Port

Comments

daspek.com

12201

Does not intentionally drop any packets

daspek.com

12202

Drops one packet intentionally, near the start (to take you out of slow start)

daspek.com

12203

Only accepts packets from you if your checksum is correct.

daspek.com

12204

Corrupts some of the data packets (the checksum won't pass when you receive them).

daspek.com

12205

"Mystery Bug" -- if you're not careful, some parts of the file you receive may be wrong, even though the checksum passes. Think about how this can happen and what you can check to prevent it. Everything may look okay after you download it, but check the md5sum of your file against the posted one to see if your client is vulnerable.

 

Available Files:   

Name

Size

md5sum

timeserver.c

1226   (1.2k)

8f0957d9bb5e13d0187b70d7d768fdcd

timeclient.c

1726   (1.7k)

713d4e2973fc5f9773158ebfcb0f6914

timecliserv.c

3177   (3.2k)

ecb8a421321abfb7762ac1c0472747ae

WebTPJournal.pdf

563106   (550k)

97293d96c3186ebf3a6719dd190df1b1

portland.mp3

1586053   (1.6M)

28eea1a3879fa09f7e9857b134cf300f

rainydrive.avi

2108384   (2.1M)

b84a1a25ce6eee79a5359719b89d38c4

 

Last updated by Daron on 5/04/05